ATIS 1000068-2015 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, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support, opera

3、tions, 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 Standar

4、ds 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 and major U.S. contributor to the International Telecommunication Union (ITU), as well as a member of

5、the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer audio and/or 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 tex

6、t media type and other accepted media types. ATIS-1000068 8 UEo NTWK11. SIP: INVITESDP offer: Audio/Video + TextUEt3. SIP: INVITESDP offer: Audio/Video + Text8. SIP: 180 RingingSDP answer: Audio/Video + Text9. SIP: 180 RingingSDP answer: Audio/Video + Text10. SIP: PRACK11. SIP: PRACK14. SIP: 200 OK

7、(PRACK)15. SIP: 200 OK (PRACK)17. SIP: 200 OK (INVITE)18. SIP: 200 OK (INVITE)19. SIP: ACK20. SIP: ACK2. SIP: 100 Trying4. SIP: 100 TryingAudio/Video + TextNTWK25. SIP: INVITESDP offer: Audio/Video + Text7. SIP: 180 RingingSDP answer: Audio/Video + Text12. SIP: PRACK13. SIP: 200 OK (PRACK)16. SIP: 2

8、00 OK (INVITE)6. SIP: 100 Trying21. SIP: ACKFigure 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 zer

9、o. The call can continue 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 initia

10、l INVITE request with an 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: IN

11、VITESDP offer: Audio/VideoUEt3. 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. SI

12、P: 100 Trying4. SIP: 100 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 RingingS

13、DP answer: Audio/Video12. 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 Interworki

14、ng When starting the (non-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 ter

15、minal desiring RTT media 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. UEtAudio + baudot2. SIP: INVITESDP offer: Audio4. SIP: 180 RingingSDP answer: Audio6. SIP: PRACK7. SIP: 200 OK (PR

16、ACK)10. SIP: 200 OK (INVITE)12. SIP: ACK3. SIP: 100 Trying8. SIP: UPDATESDP offer: Audio + Text9. SIP: 20 OK (UPDATE)SDP answer: Audio + TextNTWK2NTWK11. ISUP: IAM5. ISUP: ACM11. ISUP: ANMAudio + TextTCFigure 3.8 CS Originated Session - Initial INVITE Offering Audio Only Upon receipt of an IAM reque

17、st for a speech or 3.1 kHz audio call, 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

18、 within a subsequent UPDATE prior to answer 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 availab

19、le, return an SDP answer with audio and 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

20、.9 SIP Terminal Originated Session - Initial INVITE Offering Audio and Text Upon receipt of a SIP INVITE request offering text media (possibly combined with audio 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 setu

21、p on IP and CS side, but returning an SDP answer including RTT media (possibly combined with audio media if audio media has been offered). 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 corresp

22、onding RTT media resources in the MGW and activates the Interworking function, and if resources are available, returns an 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

23、offer, the SIP terminal can also request GTT support by sending a new SDP offer including audio/video and RTT when a SIP 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 pa

24、rty has multiple devices registered under the same number, e.g., a residential gateway supporting an RJ11-attached POTS 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/ans

25、wer exchange will permit the network to selectively direct session offers featuring RTT to the RTT-capable endpoint (either 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 servic

26、e with both a POTS phone gateway (RJ11 jack) and a Wi-Fi tablet connected and registered. The tablet is running an RTT client. 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

27、or in parallel with the POTS phone. ATIS-1000068 13 The presence of the RTT tag in the SIP response allows the network to 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 suppor

28、t RTT (transcoder must be provided). In both of these cases, the RTT media line will have a port=0 setting indicating that 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 becau

29、se it is not supported. When transcoding is introduced, the audio and text media streams will be transcoded to G.711 codec 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 med

30、ia function addressing information. It will also place PCMU (G.711) codec as the preferred codec. In the call flows that 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 ze

31、ro in the associated SDP media (m) line. ”text” presents the text media feature tag in the Contact header. The IWF is outside 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 CAS

32、E: 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 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

33、 Baudot protocol. The network has provided a transcoder from the start of the call. ATIS-1000068 14 UEo IWF1. SIP: INVITE Contact:textSDP offer: WB,NB + Text3. SIP: INVITE Contact:textSDP offer: WB,NB,G711 + Text5. SIP: 183 Session ProgressSDP answer: NB + Text:p=010. SIP: 183 Session ProgressSDP an

34、swer: NB + Text11. SIP: PRACK6. SIP: PRACK7. SIP: 200 OK (PRACK)12. SIP: 200 OK (PRACK)19. SIP: 200 OK (INVITE)20. SIP: 200 OK (INVITE)21. SIP: ACK22. SIP: ACK2. SIP: 100 Trying4. SIP: 100 TryingNB + TextMGCF8. SIP: UPDATE Contact:textSDP offer: G711,NB + Text:p=09. SIP: 200 OK (UPDATE)SDP answer: G

35、711 + Text:p=0Transcoding Included13. SIP: 180 Ringing16. SIP: PRACK17. SIP: 200 OK (PRACK)14. SIP: 180 Ringing15. SIP: PRACK18. SIP: 200 OK (PRACK)G711TCFigure 3.10 VoLTE Mobile Origination w/RTT to PSTN or 3G For this flow, the originating UE is configured to use RTT from the start of the call. Tr

36、anscoder 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 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

37、 (UPD), send SDP answer to UEo with RTT-TC ports supporting NB and RTT. ATIS-1000068 15 NOTE: Flow would work the same if G711 was selected in message 5 rather than NB. UPDATE would still be needed to change to TC ports (depends on IWF architecture for managing the various transcoders) 3.5.2 VoLTE M

38、obile 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 VoLTE handset is in TTY mode when he receives Alices call. Alice knows that Bob uses TTY service exclusively so Alice has placed

39、 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 session uses TTY service transcoded by the network from the start of the call. ATIS-1000068 16 UEt IWF1. SIP: INVITESDP offer: NB

40、,G7115. SIP: 183 Session Progress Contact:textSDP answer: NB7. SIP: PRACK9. SIP: 200 OK (PRACK)23. SIP: 200 OK (INVITE)25. SIP: ACK2. SIP: 100 TryingNB + TextMGCF11. SIP: UPDATE Contact:textSDP offer: NB + Text13. SIP: 200 OK (UPDATE)SDP answer: G711 + Text:p=0Transcoding Included17. SIP: 180 Ringin

41、g19. SIP: PRACK21. SIP: 200 OK (PRACK)G711TC3. SIP: INVITESDP offer: NB,G7114. SIP: 100 Trying6. SIP: 183 Session Progress Contact:textSDP answer: NB8. SIP: PRACK10. SIP: 200 OK (PRACK)12. SIP: UPDATE Contact:textSDP offer: NB,G711 + Text14. SIP: UPDATE Contact:textSDP offer: G711,NB + Text:p=015. S

42、IP: 200 OK (UPDATE)SDP answer: G711 + Text:p=016. SIP: 200 OK (UPDATE)SDP answer: NB + Text18. SIP: 180 Ringing20. SIP: PRACK22. SIP: 200 OK (PRACK)24. SIP: 200 OK (INVITE)26. SIP: ACKFigure 3.11 VoLTE Mobile Termination w/RTT From PSTN or 3G For this flow, the originating UE is configured to use TT

43、Y from the start of the call. This will result in the terminating UE immediately sending an 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 fa

44、r end is not RTT-capable so RTT-TC is needed. ATIS-1000068 17 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 UEt with RTT-TC ports supporting NB and RTT. NOTE: Timing of UPDATE vs. 180 response can be flexible from what is

45、shown here. NOTE: Message 12 must include m=text line, but whether it should re-offer it or send it as port=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

46、 Carol. Alice doesnt know Carol but knows she is a friend of Bob and so might be a TTY service user. Alice has 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

47、phone supports RTT, it is not configured to use it and declines the m=text line in Alices SDP offer. The call is answered as a voice call and no transcoder is needed nor provided. ATIS-1000068 18 UEo NTWK25. SIP: 200 OK (INVITE)WBNTWK1. SIP: INVITE Contact:textSDP offer: WB,NB + Text2. SIP: 100 Tryi

48、ng7. SIP: 183 Session Progress Contact:textSDP answer: WB + Text:p=010. SIP: PRACK28. SIP: ACKUEt3. SIP: INVITE Contact:textSDP offer: WB,NB,G711 + Text5. SIP: INVITE Contact:textSDP offer: WB,NB,G711 + Text4. SIP: 100 Trying6. SIP: 100 Trying8. SIP: 183 Session Progress Contact:textSDP answer: WB +

49、 Text:p=09. SIP: 183 Session Progress Contact:textSDP answer: WB + Text:p=011. SIP: PRACK12. SIP: PRACK13. SIP: 200 OK (PRACK)14. SIP: 200 OK (PRACK)15. SIP: 200 OK (PRACK)16. SIP: 180 Ringing19. SIP: PRACK20. SIP: PRACK21. SIP: PRACK22. SIP: 200 OK (PRACK)23. SIP: 200 OK (PRACK)17. SIP: 180 Ringing18. SIP: 180 Ringing24. SIP: 200 OK (PRACK)26. SIP: 200 OK (INVITE)27. SIP: 200 OK (INVITE)29. SIP: ACK30. SIP: ACKFigure 3.12 VoLTE Mobile Origination with RTT to VoLTE