--- 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