ATIS 1000068-2017 Support of TTY Service Over IP Using Global Text Telephony.pdf

1、 TECHNICAL REPORT ATIS-1000068 Support of TTY Service Over IP Using Global Text Telephony As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industrys most pressing

2、business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support, o

3、perations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is accredited by the American National Sta

4、ndards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of the International Telecommunication Union (ITU), as well as a member of the Inter-American Telecom

5、munication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer video may optionally also be included. Assuming the terminating party also supports and accepts the offer with RTT, it will return the SDP answer that includes the text media type and other accepted media t

6、ypes. ATIS-1000068 8 Figure 3.5 GTT Call Flow with Text in Initial Offer If the terminating party does not support RTT or wishes not to use it, it can accept the audio/video stream of the offer and reject just the text media stream by setting the port of the Text stream to zero. The call can continu

7、e successfully using only audio/video. ATIS-1000068 9 Figure 3.6 GTT Call Flow with Text Initial Offer Rejected If the originating party does not know if the terminating party supports RTT or if they do not want to initially offer RTT, the originating party can send the initial INVITE request with a

8、n offer containing only audio/video media streams. If upon receiving the incoming call, the terminating party wishes to add text media, it must first accept the initial offer and then send a subsequent offer adding the new text media stream. ATIS-1000068 10 UEo NTWK11. SIP: INVITESDP offer: Audio/Vi

9、deoUEt3. SIP: INVITESDP offer: Audio/Video8. SIP: 180 RingingSDP answer: Audio/Video9. SIP: 180 RingingSDP answer: Audio/Video10. SIP: PRACK11. SIP: PRACK14. SIP: 200 OK (PRACK)15. SIP: 200 OK (PRACK)23. SIP: 200 OK (INVITE)24. SIP: 200 OK (INVITE)25. SIP: ACK26. SIP: ACK2. SIP: 100 Trying4. SIP: 10

10、0 Trying17. SIP: UPDATESDP offer: Audio/Video + Text18. SIP: UPDATESDP offer: Audio/Video + Text19. SIP: 200 OK (UPDATE)SDP answer: Audio/Video + Text20. SIP: 20 OK (UPDATE)SDP answer: Audio/Video + TextAudio/Video + Text5. SIP: INVITESDP offer: Audio/Video7. SIP: 180 RingingSDP answer: Audio/Video1

11、2. SIP: PRACK13. SIP: 200 OK (PRACK)22. SIP: 200 OK (INVITE)27. SIP: ACK6. SIP: 100 Trying16. SIP: UPDATESDP offer: Audio/Video + Text21. SIP: 20 OK (UPDATE)SDP answer: Audio/Video + TextNTWK2Figure 3.7 GTT Call Flow with Text in Subsequent Offer 3.4.3 Incoming Call Interworking When starting the (n

12、on-emergency) session setup signaling from a CS based network towards an IP network, the IWF in NTWK2 has no knowledge whether the call will attempt to use text telephony. The IWF offers only audio media when setting up a call towards the SIP terminal and waits for the SIP terminal desiring RTT medi

13、a to send a new offer adding RTT media attribute prior to inserting an Interworking function in the MGW. ATIS-1000068 11 The following shows an example call flow. Figure 3.8 CS Originated Session - Initial INVITE Offering Audio Only Upon receipt of an IAM request for a speech or 3.1 kHz audio call,

14、the IWF (e.g., MGCF and IM-MGW) starts the call setup by sending an INVITE request offering audio media applying the interworking procedures. SIP terminals supporting RTT and configured to use it will send a new SDP offer including an audio and a RTT media line within a subsequent UPDATE prior to an

15、swer or re-INVITE request after answer. When RTT interworking between IP and CS networks is required, the IWF shall reserve corresponding RTT media resources in the MGW and thereby request the insertion of the Interworking function, and if resources are available, return an SDP answer with audio and

16、 RTT media attributes. 3.4.4 Outgoing Call Interworking Figure 3.9 shows an example call flow where the SIP terminal requests RTT by sending an SDP offer including one audio line and one text media line within an initial INVITE message. ATIS-1000068 12 Figure 3.9 SIP Terminal Originated Session - In

17、itial INVITE Offering Audio and Text Upon receipt of a SIP INVITE request offering audio and text media, the IWF starts the call setup at the CS side by sending an IAM requesting a speech or 3.1 kHz bearer, and completes the call setup on the IP and CS sides, returning an SDP answer that includes au

18、dio and RTT media. The IWF triggers the insertion of an Interworking function in the MGW for the duration of the call if a RTT media stream is established. The IWF reserves corresponding RTT media resources in the MGW and activates the Interworking function, and if resources are available, returns a

19、n SDP answer with audio and RTT. 3.4.5 Subsequent SDP Offer/Answer Exchange Adding Text to an Existing Session If only audio and/or video media has been offered in the initial SDP offer, the SIP terminal can also request GTT support by sending a new SDP offer including audio/video and RTT when a SIP

20、 dialogue (early or confirmed) has already been established. The IWF will then be triggered to provide the conversion. 3.5 GTT Procedures Utilizing Text Media Feature Tag When a party has multiple devices registered under the same number, e.g., a residential gateway supporting an RJ11-attached POTS

21、phone (no RTT support) and a Wi-Fi-attached tablet with an RTT-capable softphone, the presence of the RTT tag (“text” as defined by IETF RFC 3840 RFC 3840) during the SDP offer/answer exchange will permit the network to selectively direct session offers featuring RTT to the RTT-capable endpoint (eit

22、her exclusively or in conjunction with the POTS phone). If a tag was not provided during the SDP offer/answer exchange, this would not be possible. For example: Bob has VoIP service with both a POTS phone gateway (RJ11 jack) and a Wi-Fi tablet connected and registered. The tablet is running an RTT c

23、lient. Voice-only calls to Bobs telephone number (TN) will ring only the POTS phone gateway, but calls offering RTT support can be directed automatically to the tablet exclusively or in parallel with the POTS phone. ATIS-1000068 13 The presence of the RTT tag in the SIP response allows the network t

24、o differentiate between the case where the terminating party supports RTT, but elects not to use it (no transcoder required), and the case where the terminating party doesnt support RTT (transcoder must be provided). In both of these cases, the RTT media line will have a port=0 setting indicating th

25、at RTT is not desired, but the presence of the RTT tag in the contact header of the response will allow the network to know that RTT is being declined as a choice rather than because it is not supported. When transcoding is introduced, the audio and text media streams will be transcoded to G.711 cod

26、ec using Baudot inband tones along with possible audio. When the IWF introduces transcoding, it will perform an additional offer/answer exchange with the SDP reflecting the IWF media function addressing information. It will also place PCMU (G.711) codec as the preferred codec. In the call flows that

27、 follow: WB is used to represent the Wideband AMR codec. NB is used to represent the Narrowband AMR codec. G711 is used to represent the PCMU codec. “p=0” represents port set to zero in the associated SDP media (m) line. ”text” presents the text media feature tag in the Contact header. The IWF is ou

28、tside of the MGCF. The flows represent examples; additional and alternative flows are possible. 3.5.1 VoLTE Mobile Origination to PSTN or 3G with VoLTE RTT at Start Of Call Use Case: Alice is a VoLTE user with an RTT-capable smartphone and calls Bob. Alice knows Bob uses TTY service exclusively, so

29、Alice has her phone configured for RTT operation at the start of the call and as such, Alices SDP offer includes the m=text line. Bob answers the call using his circuit device with Baudot protocol. The network has provided a transcoder from the start of the call. ATIS-1000068 14 Figure 3.10 VoLTE Mo

30、bile Origination w/RTT to PSTN or 3G For this flow, the originating UE is configured to use RTT from the start of the call. Transcoder Invoke: 1. IWF knows that SDP answer without the RTT tag (“text”) to an SDP offer with RTT means that far end is not RTT-capable so RTT-TC is needed. Therefore, for

31、this case, RTT-TC is needed. 2. Reserve RTT-TC. 3. Send UPDATE to far end with RTT-TC port for G711 preferred. 4. After 200 OK (UPD), send SDP answer to UEo with RTT-TC ports supporting NB and RTT. NOTE: Flow would work the same if G711 was selected in message 5 rather than NB. UPDATE would still be

32、 needed to change to TC ports (depends on IWF architecture for managing the various transcoders) ATIS-1000068 15 3.5.2 VoLTE Mobile Termination from PSTN or 3G with VoLTE RTT at Start Of Call Use Case: Alice is using her PSTN line to call Bobs VoLTE phone. Bob uses TTY service exclusively so Bobs Vo

33、LTE handset is in TTY mode when he receives Alices call. Alice knows that Bob uses TTY service exclusively so Alice has placed this call from her Baudot protocol device connected to her PSTN line. Bob answers Alices call and renegotiates the dialog to include RTT prior to answering the call. The ses

34、sion uses TTY service transcoded by the network from the start of the call. Figure 3.11 VoLTE Mobile Termination w/RTT From PSTN or 3G ATIS-1000068 16 For this flow, the originating UE is configured to use TTY from the start of the call. This will result in the terminating UE immediately sending an

35、UPDATE offering RTT after the completion of the initial offer/answer exchange. Transcoder Invoke: 1. From step 13, the IWF knows that SDP answer without the RTT tag (“text”) to an offer with RTT means that far end is not RTT-capable so RTT-TC is needed. 2. Reserve RTT-TC. 3. Send UPDATE to far end w

36、ith RTT-TC port for G711 preferred. 4. After 200 OK (UPD), send SDP answer to UEt with RTT-TC ports supporting NB and RTT. NOTE: Timing of UPDATE vs. 180 response can be flexible from what is shown here. NOTE: Message 12 must include m=text line, but whether it should re-offer it or send it as port=

37、0 is unknown; the former is shown here. 3.5.3 VoLTE Mobile Origination with RTT to VoLTE Mobile Termination without RTT Use Case: Alice is a VoLTE user with an RTT-capable smartphone and calls Carol. Alice doesnt know Carol but knows she is a friend of Bob and so might be a TTY service user. Alice h

38、as configured her phone for TTY operation at the start of the call and as such Alices SDP offer includes the m=text line. Carol is also a VoLTE user but is not a TTY service user so while her phone supports RTT, it is not configured to use it and declines the m=text line in Alices SDP offer. The cal

39、l is answered as a voice call and no transcoder is needed nor provided. ATIS-1000068 17 Figure 3.12 VoLTE Mobile Origination with RTT to VoLTE MT without RTT For this flow, the originating UE is configured to use TTY service from the start of the call and the terminating UE is configured to not use

40、TTY/RTT from the start of the call. NOTE: Presence of RTT tag (“text”) in SDP answer suppresses transcoder logic at IWF. In this case the terminating UE is indicating that it supports RTT but does not want to use it. 3.5.4 VoLTE Mobile Origination with TTY to VoLTE Mobile Termination with RTT Use Ca

41、se: Alice is a VoLTE user with an RTT-capable smartphone and calls Bob. Alice knows Bob uses TTY service exclusively so Alice has her phone configured for TTY operation at the start of the call and as such, Alices SDP offer includes the m=text line. Bob answers the call using his RTT-capable VoLTE s

42、martphone which is also configured for TTY operation at the start of the call. The network sees that RTT is offered and accepted in the SDP answer and so no transcoder is needed. ATIS-1000068 18 Figure 3.13 VoLTE Mobile Origination with RTT to VoLTE Mobile Termination with RTT For this flow, both th

43、e originating and terminating UEs are configured to use TTY from the start of the call NOTE: Presence of RTT tag (“text”) in SDP answer suppresses transcoder logic at IWF. 3.5.5 VoLTE Mobile Origination to PSTN mid-call upgrade to use RTT Use Case: Alice is a VoLTE user with an RTT-capable smartphon

44、e and calls Carol. Alice doesnt know if Carol is a TTY service user and so has not configured her phone for operation. As such, Alices SDP offer does not include the m=text line. Carol is on the PSTN and uses TTY service exclusively. When Carol answers the call, she has her TTY device connected usin

45、g Baudot protocol. Alice hears the Baudot tones coming from Carol and at step 21 switches her smartphone to RTT mode. The network inserts the transcoder and Alice and Carol can communicate. ATIS-1000068 19 UEo IWF1. SIP: INVITE Contact:textSDP offer: WB,NB3. SIP: INVITE Contact:textSDP offer: WB,NB,

46、G7115. SIP: 183 Session ProgressSDP answer: NB7. SIP: PRACK9. SIP: 200 OK (PRACK)16. SIP: 200 OK (PRACK)17. SIP: 200 OK (INVITE)18. SIP: 200 OK (INVITE)19. SIP: ACK20. SIP: ACK2. SIP: 100 Trying4. SIP: 100 TryingNB + TextMGCFTranscoding Included11. SIP: 180 RingingG711TC6. SIP: 183 Session ProgressS

47、DP answer: NB8. SIP: PRACK10. SIP: 200 OK (PRACK)12. SIP: 180 Ringing13. SIP: PRACK14. SIP: PRACK15. SIP: 200 OK (PRACK)21. SIP: reINVITE Contact:textSDP offer: NB + Text23. SIP: reINVITE Contact:textSDP offer: NB,G711 + Text22. SIP: 100 Trying24. SIP: 100 Trying25. SIP: 200 OK (INVITE)SDP answer: N

48、B + Text:p=026. SIP: ACK27. SIP: reINVITE Contact:textSDP offer: G711,NB + Text:p=028. SIP: 100 Trying29. SIP: 200 OK (INVITE)SDP answer: G711 + Text:p=031. SIP: ACK30. SIP: 200 OK (INVITE)SDP answer: NB + Text32. SIP: ACKFigure 3.14 VoLTE Mobile Origination to PSTN Mid-call Upgrade to Use RTT For t

49、his flow, the originating UE is not configured to use TTY from the start of the call. Instead, the originating user decides to add RTT for TTY service to the call after it has been established. ATIS-1000068 20 Transcoder Invoke: 1. From step 25, the IWF knows that SDP answer without the RTT tag (“text”) to an offer with RTT means that far end is not RTT capable so RTT-TC is needed. 2. Reserve RTT-TC. 3. Send reINVITE to far end for G711 preferred with RTT-TC port. 4. After 200 OK (reINV), send SDP an