# HG changeset patch # User Mychaela Falconia # Date 1703227096 0 # Node ID b203ebebe9b3b2e1c81b1103459b685c5ce6d810 # Parent c4f8a32af08884bf1e7e266c0e2354d4327c26fa doc/Arch-design: fill out sections 2.4.[2-5] diff -r c4f8a32af088 -r b203ebebe9b3 doc/Arch-design --- a/doc/Arch-design Wed Dec 20 09:27:05 2023 +0000 +++ b/doc/Arch-design Fri Dec 22 06:38:16 2023 +0000 @@ -445,15 +445,87 @@ 2.4.2. Permission to send to the uplink -To be described. +Not every local phone number served by ThemWi-SMSC is allowed to send SMS to +our upstream interconnection point with Bandwidth.com SMPP server. As explained +in section 1.2, our access to Bandwidth P2P SMS interconnection service is +through a reseller (Sopranica Telecom), and our arrangement is such that we +have to pay for each individual phone number for which P2P SMS interconnection +service is provided. The economics of the situation are such that the total +set of NANP numbers (good for calls) we rent from BulkVS is greater than the +subset for which we enable outside SMS interconnection service through +Bandwidth+Sopranica. Therefore, we have a flag in our themwi-nanp database of +locally owned numbers (NUMBER_FLAG_SMSPROV) which we set only on certain +numbers, those that are provisioned for outside SMS interconnection and which +are therefore allowed to send SMS to the outside world. All other locally +owned phone numbers (those without this flag) can only exchange SMS within our +fiefdom, including our downstream peers. + +For each newly submitted SM, themwi-smsc-core will make a routing determination +per the previous section, and if the destination is SME_CLASS_UPSTREAM, the +identity of the sender will be checked. The sender will need to be a locally +owned number with upstream SMS permission bit set, otherwise the message is +rejected. 2.4.3. PID and DCS constraints -To be described. +Special codes in PID and DCS octets can invoke many special functions that go +far beyond ordinary human-to-human SMS: setting and clearing voice mail waiting +indication flags, SIM OTA communication, silent SMS etc. While there are +legitimate use cases for all of these special services, and an SMSC +implementation should provide a way for duly authorized network components to +send such special SMS to local GSM subscribers, it would be irresponsible for +a public MNO to allow any Alice to send such SMS-encoded trojans to any Bob, or +to accept the same from Big Bad outside world and forward them directly to +unsuspecting local users. + +The solution adopted for ThemWi-SMSC is that each sw component that accepts SMs +from untrusted parties will apply filtering rules to both PID and DCS octets. +In the case of messages originated from local GSM MS, themwi-smsc-gsmif will be +responsible for preening PID and DCS, whereas in the case of messages coming +from the outside world, the responsibility falls on themwi-smsc-uplink instead. + +The specific masks or ACLs of which PID and DCS codes should be accepted will +be configurable; the recommended default is to: + +* allow any PID in 000xxxxx range (0x00 through 0x1F), but no others; + +* allow DCS 0x00 (GSM7 text) and 0x08 (UCS-2 text), but no others. 2.4.4. Validity period and expiry time -To be described. +Given the store-and-forward nature of SMS, the amount of work spent trying to +deliver a message to a "difficult" destination must be bounded. The standard +SMS architecture of GSM 03.40 provides the notion of a validity period, +optionally specified by message senders, as the mechanism for limiting the +lifetime of a message that cannot be delivered right away. + +Message validity periods and expiry times will be handled as follows in +ThemWi-SMSC: + +* At the socket interface from message-submitting components to + themwi-smsc-core, the VP will always be communicated in relative form, as a + count of seconds. Special value 0 means that the source is not setting the + VP, and a system-wide default needs to be applied. + +* If themwi-smsc-gsmif receives an absolute-format VP from GSM MS, it will + convert to relative seconds-from-present before submitting the SM to + themwi-smsc-core. + +* themwi-smsc-core will have two configurable settings with regard to message + longevity: default VP and maximum VP. The default VP setting will be applied + when no VP is set at the message source: themwi-smsc-submit without explicit + VP, MO SM from a GSM MS without VP setting, or a message from the outside + world where SMPP never provides a VP on incoming messages. OTOH, the maximum + VP setting will serve as a cap in case a user did specify an explicit VP, but + it is unreasonably long. + +2.4.5. Duplicate message detection + +One can easily envision various scenarios in which a duplicate copy is received +for an earlier message which is still active, i.e., still queued for delivery +to its destination. Instead of adding such duplicates to the queue, it is +desirable to be able to detect and suppress them. The details remain to be +worked out. 3. SMS communication via direct shell access