SMS and calls
If the incoming SMS delivery calls have a caller ID in the BT Text, the chances are there that it understands ETSI ES 201 912, and for incoming SMS, refers to the caller as the SM-SC and recipient as SM-TE, or use the implementation in Asterisk
This may be true even where the call is really SIP and RTP over IP, so there is digital (SMS) over analogue (FSK) over digital going on. (voice codec)
Having the message recovered digitally by the Voip service provider may be helpful for the "tight delay bounds" issue on the asterisk article, even if it is then relayed via a role switch:
- As per "annex A.2" When the call is not witheld and caller id = BT Text receive number, answer the call in the network, and perhaps, start recording as a fallback
- Play the initial FSK communication, in the SM-TE role
- the SM-SC, hopefully, detects it is talking to an SM-TE rather than a person, and cancels any text-to-speech, once successful confirmation is obtained according to the protocol then call recording can stop and any recording discarded.
- receive the SMS, it can then be logged digitally if the customer wants that, leaving the communication channel open for the next steps if required to deliver confirmation the message has reached its destination
- if the real terminal equipment, with the internet suggesting that Gigaset devices sends SMS "over" RTP, understands the ETSI specification equally whether the analogue or IP based interface is used, then switch roles to SM-SC, setting the caller ID to a recognised BT Text number so the station knows to answer it automatically.
- The message can also be transferred via a variety of other methods, without analogue emulation, such as real-time text.
If the station supports SMS on PSTN, it may support the same interface over IP codecs, then "calls" to BT Text outgoing shortcodes are very likely attempts to send an SMS this way.
- As with "annex A.1" If caller-id is not witheld, answer the call, in the SM-SC role
- Log the outgoing SMS if required and transmit onwards