Talk:SMS: Difference between revisions

← Older edit

Talk:SMS (view source)

Revision as of 00:01, 3 March 2025

87 bytes added , 3 March

→‎Incoming messages

Michael

56

edits

Revision as of 21:12, 26 February 2022 (view source) Michael (talk \| contribs) m (correct active send number) ← Older edit		Latest revision as of 00:01, 3 March 2025 (view source) Michael (talk \| contribs) (→‎Incoming messages)
(8 intermediate revisions by the same user not shown)
== Incoming messages == # This mainly relies on voicemail being able to activate based on caller phone number, so if it is a SMS relay service such as BT Text or AQL calling, divert to voicemail: ~~# 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~~Then optionally play the initial FSK communication of ETSI ES 201 912, in the SM-TE role, to have a chance to get the SMS digitally # If the caller (SM-SC) replies with FSK quickly in accordance with ETSI ES 201 912 then accept the SMS digitally and deliver as an [[SMS#Inbound_SMS\|Inbound SMS]], otherwise: # 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. # send dialpad digits to have SM-SC play SMS as text-to-speech # 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 # then record it like voicemail, attempt send the recording [[VoIP_-_Voicemail\|via email]] and if successful, ask the SM-SC to delete the delivered SMS, then end the call. # 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://wiki.wireshark.org/SMPP SMPP]~~ == End user equipment interaction == ~~== Outgoing messages ==~~ End user SIP equipment may support ETSI ES 201 912 over RTP, if so then: ~~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.~~ * VoIP supplier could implement that by divert outgoing calls to well known SM-SC numbers to the provider SM-SC ~~# As with "annex A.1" If caller-id is not witheld, answer the call, in the SM-SC role~~ * Also have an option to rôle switch to SM-SC to deliver messages to it, after having [[SMS#Itemised_billing\|logged them]], if customer wanted that. ~~# Log the outgoing SMS if required and transmit onwards~~ = Experimenting = [[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.