Talk:SMS: Difference between revisions

From AAISP Support Site
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:


= SMS and calls =
= SMS and calls theory =


If the incoming SMS delivery calls have a caller ID in the [https://www.bt.com/content/dam/bt/help/legacy-ug/new-pdf/BT%20SMS%20Text%20service%20centre%20numbers.pdf BT Text], the chances are there that it understands [https://www.etsi.org/deliver/etsi_es/201900_201999/201912/ 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 [https://wiki.asterisk.org/wiki/display/AST/Application_SMS in Asterisk]
If the incoming SMS delivery calls have a caller ID in the [https://www.bt.com/content/dam/bt/help/legacy-ug/new-pdf/BT%20SMS%20Text%20service%20centre%20numbers.pdf BT Text], the chances are there that it understands [https://www.etsi.org/deliver/etsi_es/201900_201999/201912/ 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 [https://wiki.asterisk.org/wiki/display/AST/Application_SMS in Asterisk]
Line 15: Line 15:
# 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
# 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 understand SMS "over, somehow" 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.
# if the real terminal equipment, with the internet suggesting that Gigaset devices understand SMS "over, somehow" 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 or instead be transferred via a variety of other methods, without analogue emulation, such as [https://datatracker.ietf.org/doc/html/rfc5194 real-time text].
# The message can also or instead be transferred via a variety of other methods, without analogue emulation, such as [https://wiki.wireshark.org/SMPP SMPP]


== Outgoing messages ==
== Outgoing messages ==
Line 23: Line 23:
# As with "annex A.1" If caller-id is not witheld, answer the call, in the SM-SC role
# 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
# Log the outgoing SMS if required and transmit onwards

= Experimenting =

Trying to send SMS from Vodafone to a BT number ported to AAISP does result in text-to-speech calls that come from 08456021111, which is different from the numbers in gigaset [https://gse.gigaset.com/fileadmin/legacy-assets/CustomerCare/Manuals/SL4xx/SL450_GO/A31008-M2721-L101-1-7619_en_IE-UK.pdf sl450a-go] that is use to get calls, so there likely be no need to support both the text to speech and FSK based SMS delivery.

The factory numbers are 1470P17094009* to send (as in active send=yes) and 0800587529* to receive (as in active send=no), it can be set to process these numbers on IP1 instead of "Fixed"
The asterisk apparently means to accept any follow-on digits, although it could mean asterisk literally also.

Therefore, the outstanding matters are to get BT to send AAISP SMS either via [https://www.bt.com/help/landline/set-up-and-use-bt-text SMS over PSTN], (by us [sending "register" to 00000 or BT delivering SMS over inter-operator transports such as text files over ftp over ipsec.


[[User:Michael|Michael]] ([[User talk:Michael|talk]]) 22:17, 12 October 2021 (BST)
[[User:Michael|Michael]] ([[User talk:Michael|talk]]) 22:17, 12 October 2021 (BST)

= Block SMS text to speech =

The user may prefer to lose incoming SMS completely than have them delivered as voice calls, such as where the ability to intercept calls from +448456021111 and +443333440000 to voicemail is not set up.

To do that the opt-out functions are used on both [https://www.bt.com/help/landline/set-up-and-use-bt-text BT] and [https://aql.com/aqltext/ AQL], with both pages used to opt back in later, such as to do further tests if progress on inbound digital delivery of SMS is known about.

Latest revision as of 20:23, 26 September 2022

SMS and calls theory

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:

Incoming messages

  1. 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
  2. Play the initial FSK communication, in the SM-TE role
  3. 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.
  4. 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
  5. if the real terminal equipment, with the internet suggesting that Gigaset devices understand SMS "over, somehow" 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.
  6. The message can also or instead be transferred via a variety of other methods, without analogue emulation, such as SMPP

Outgoing messages

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.

  1. As with "annex A.1" If caller-id is not witheld, answer the call, in the SM-SC role
  2. Log the outgoing SMS if required and transmit onwards

Experimenting

Trying to send SMS from Vodafone to a BT number ported to AAISP does result in text-to-speech calls that come from 08456021111, which is different from the numbers in gigaset sl450a-go that is use to get calls, so there likely be no need to support both the text to speech and FSK based SMS delivery.

The factory numbers are 1470P17094009* to send (as in active send=yes) and 0800587529* to receive (as in active send=no), it can be set to process these numbers on IP1 instead of "Fixed" The asterisk apparently means to accept any follow-on digits, although it could mean asterisk literally also.

Therefore, the outstanding matters are to get BT to send AAISP SMS either via SMS over PSTN, (by us [sending "register" to 00000 or BT delivering SMS over inter-operator transports such as text files over ftp over ipsec.

Michael (talk) 22:17, 12 October 2021 (BST)

Block SMS text to speech

The user may prefer to lose incoming SMS completely than have them delivered as voice calls, such as where the ability to intercept calls from +448456021111 and +443333440000 to voicemail is not set up.

To do that the opt-out functions are used on both BT and AQL, with both pages used to opt back in later, such as to do further tests if progress on inbound digital delivery of SMS is known about.