FreeCalypso > hg > themwi-smsc

comparison doc/Arch-design @ 2:b203ebebe9b3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Arch-design: fill out sections 2.4.[2-5]
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 22 Dec 2023 06:38:16 +0000
parents c4f8a32af088
children b084a9542471
comparison
equal deleted inserted replaced
1:c4f8a32af088 2:b203ebebe9b3
443 routing step, with the destination preset to SME_CLASS_GSM and dest_imsi 443 routing step, with the destination preset to SME_CLASS_GSM and dest_imsi
444 prefilled. 444 prefilled.
445 445
446 2.4.2. Permission to send to the uplink 446 2.4.2. Permission to send to the uplink
447 447
448 To be described. 448 Not every local phone number served by ThemWi-SMSC is allowed to send SMS to
449 our upstream interconnection point with Bandwidth.com SMPP server. As explained
450 in section 1.2, our access to Bandwidth P2P SMS interconnection service is
451 through a reseller (Sopranica Telecom), and our arrangement is such that we
452 have to pay for each individual phone number for which P2P SMS interconnection
453 service is provided. The economics of the situation are such that the total
454 set of NANP numbers (good for calls) we rent from BulkVS is greater than the
455 subset for which we enable outside SMS interconnection service through
456 Bandwidth+Sopranica. Therefore, we have a flag in our themwi-nanp database of
457 locally owned numbers (NUMBER_FLAG_SMSPROV) which we set only on certain
458 numbers, those that are provisioned for outside SMS interconnection and which
459 are therefore allowed to send SMS to the outside world. All other locally
460 owned phone numbers (those without this flag) can only exchange SMS within our
461 fiefdom, including our downstream peers.
462
463 For each newly submitted SM, themwi-smsc-core will make a routing determination
464 per the previous section, and if the destination is SME_CLASS_UPSTREAM, the
465 identity of the sender will be checked. The sender will need to be a locally
466 owned number with upstream SMS permission bit set, otherwise the message is
467 rejected.
449 468
450 2.4.3. PID and DCS constraints 469 2.4.3. PID and DCS constraints
451 470
452 To be described. 471 Special codes in PID and DCS octets can invoke many special functions that go
472 far beyond ordinary human-to-human SMS: setting and clearing voice mail waiting
473 indication flags, SIM OTA communication, silent SMS etc. While there are
474 legitimate use cases for all of these special services, and an SMSC
475 implementation should provide a way for duly authorized network components to
476 send such special SMS to local GSM subscribers, it would be irresponsible for
477 a public MNO to allow any Alice to send such SMS-encoded trojans to any Bob, or
478 to accept the same from Big Bad outside world and forward them directly to
479 unsuspecting local users.
480
481 The solution adopted for ThemWi-SMSC is that each sw component that accepts SMs
482 from untrusted parties will apply filtering rules to both PID and DCS octets.
483 In the case of messages originated from local GSM MS, themwi-smsc-gsmif will be
484 responsible for preening PID and DCS, whereas in the case of messages coming
485 from the outside world, the responsibility falls on themwi-smsc-uplink instead.
486
487 The specific masks or ACLs of which PID and DCS codes should be accepted will
488 be configurable; the recommended default is to:
489
490 * allow any PID in 000xxxxx range (0x00 through 0x1F), but no others;
491
492 * allow DCS 0x00 (GSM7 text) and 0x08 (UCS-2 text), but no others.
453 493
454 2.4.4. Validity period and expiry time 494 2.4.4. Validity period and expiry time
455 495
456 To be described. 496 Given the store-and-forward nature of SMS, the amount of work spent trying to
497 deliver a message to a "difficult" destination must be bounded. The standard
498 SMS architecture of GSM 03.40 provides the notion of a validity period,
499 optionally specified by message senders, as the mechanism for limiting the
500 lifetime of a message that cannot be delivered right away.
501
502 Message validity periods and expiry times will be handled as follows in
503 ThemWi-SMSC:
504
505 * At the socket interface from message-submitting components to
506 themwi-smsc-core, the VP will always be communicated in relative form, as a
507 count of seconds. Special value 0 means that the source is not setting the
508 VP, and a system-wide default needs to be applied.
509
510 * If themwi-smsc-gsmif receives an absolute-format VP from GSM MS, it will
511 convert to relative seconds-from-present before submitting the SM to
512 themwi-smsc-core.
513
514 * themwi-smsc-core will have two configurable settings with regard to message
515 longevity: default VP and maximum VP. The default VP setting will be applied
516 when no VP is set at the message source: themwi-smsc-submit without explicit
517 VP, MO SM from a GSM MS without VP setting, or a message from the outside
518 world where SMPP never provides a VP on incoming messages. OTOH, the maximum
519 VP setting will serve as a cap in case a user did specify an explicit VP, but
520 it is unreasonably long.
521
522 2.4.5. Duplicate message detection
523
524 One can easily envision various scenarios in which a duplicate copy is received
525 for an earlier message which is still active, i.e., still queued for delivery
526 to its destination. Instead of adding such duplicates to the queue, it is
527 desirable to be able to detect and suppress them. The details remain to be
528 worked out.
457 529
458 3. SMS communication via direct shell access 530 3. SMS communication via direct shell access
459 531
460 To be filled. 532 To be filled.
461 533