5 Considerations for each host environment

23.2263GPPGlobal Text Telephony (GTT)Release 17Stage 2TS

5.1 GTT-IP: IP Multimedia

5.1.0 GTT-IP

IP Multimedia, supported by the IPMM subsystem, is a suitable environment for real time text conversation. GTT-IP stands for the Text Telephony in IMS via the Real-Time Text protocol over RTP. It shall use IETF SIP RFC 3261 [11] for the negotiation of the text media and IETF RFC 4103 [10] RTP-text for transport, with text coded according to ITU‑T Recommendation T.140 [5] as indicated in TS 26.235 [14]. This allows conversation in a selection of simultaneous media, such as voice, text and potentially also video.

Inclusion of the text conversation shall be done according to normal SIP and IPMM procedures, where the text media stream is handled as any other media. GTT-IP has no architecture influence on the 3G‑PS network, only that the components must allow handling of the standardised text media stream.

NOTE: This way of using mainstream procedures opens possibilities to utilize the flexibility of the SIP protocol for enhanced services. The user can interact in the service offering to optimise the stream handling. This may be used for flexible ways of invoking relay services for media conversion according to the desire of the users.

5.1.1 Interworking between Real-Time Text and PSTN Text Telephony

Interworking between Real-Time Text (RTT) and PSTN text telephony is provided by introducing conversion in the IMS-PLMN between IP-based Real-Time Text via RTP and modem based transmission of real-time text using ITU‑T Recommendation V.18 [4] or any of its specific sub-modes. See TS 26.114 [17].

The conversion function can be seen as a context containing a Text/RTP termination plus a voice/RTP termination and an ITU‑T Recommendation V.18 [4] text telephony termination with multiplexed V.18 and voice via PCM.

It can be symbolically documented as follows.

Figure 5.1.1.1: Interworking with PSTN

If the mobile terminal requests Real-Time Text telephony, the call shall be setup with the RTT media type in parallel to the voice media, and the MGCF / IMS-MGW shall insert the Interworking function between RTT and V.18. On the contrary, if the mobile does not request RTT support, no Interworking function is necessary (which would represent majority of calls).

Functional details of the interworking between Real-time text and PSTN Text telephony are specified in TS 29.163 [18].

5.1.2 Emergency call considerations for GTT-IP

Regional regulatory rules may require the capability to let a user use any Real-time text capable mobile terminal for a text call to emergency services on the PSTN. This is an example of interworking from Real-time text to the PSTN.

Depending on local regulation and operator’s policy, it may also be required to support emergency calls originated by a SIM-less UE or a UE without a valid subscription. In these cases RTT / V.18 interworking shall be supported as in case of emergency calls for UE with a valid UICC.

Call back from emergency services is handled as Mobile Terminating calls as specified in clause 5.1.1.

5.2 GTT-CS: Circuit switched Multimedia

Text conversation in Circuit Switched Multimedia is called GTT-CS. The host environment is 3G.324, according to TS 26.110 [6] Codec for circuit switched multimedia. GTT-CS Text is ITU‑T Recommendation T.140 [5] coded and transported in an AL1 channel. Any combination of Video, Text and Voice can be supported and used simultaneously.

GTT-CS has no architecture implications on the 3G network, only that the network components must allow the standardised handling of the text media channel as well as any other media channel.

5.3 GTT-Voice: Circuit switched voice channel

Voice channel transmission of text shall use CTM; Cellular Text telephone Modem, TS 26.226 [12]. It is possible to alternate between text and voice. Text shall be coded according to ITU‑T Recommendation T.140 [5] on the presentation level.

5.3.1 Interworking between GTT-Voice and PSTN Text Telephony

If GTT-Voice is provided, interworking to PSTN text telephony can be provided by introducing conversion in the PLMN between CTM and PSTN based text telephony using ITU‑T Recommendation V.18 [4] or any of its specific sub-modes.

A simple extension can be made of the conversion functionality described in H.248.2 [9]. CTM is included among the transport mechanisms by an extension of package txc.

For the CTM and PSTN text telephone case, a conversion function can be seen as a context containing a CTM termination and a ITU‑T Recommendation V.18 [4] text telephony termination. This combination is called the CTM channel. It is foreseen that the CTM channel need control to be initiated to the proper state for each call etc. Such functions are here collected in an entity called interworking control.

The CTM channels are normally transparent but monitoring for text telephone signals or CTM signals. When a signal is discovered, the audio path is stopped and character conversion and transmission performed.

It can be symbolically documented as follows.

Figure 4: Interworking with PSTN

Since the PSTN text telephone protocols have states, resetting the state during the call should be avoided because it can cause loss or corruption of characters, loss of communication or a long ITU‑T Recommendation V.18 [4] handshake before reestablishment.

For the CTM-SRF core network node solution, already standardised routing and invocation mechanisms should be used to invoke CTM detection/conversion in the calls that may require text conversation.

The mechanisms for invocation of the CTM channel act on both Mobile Originating calls and Mobile Terminated calls.

5.3.2 Functional details of fixed network interworking

The default action of the call path in the CTM-detection/conversion function is to transfer audio transparently while monitoring for text telephone signals. When valid text telephone signals are detected, the converting action of the channel takes effect. The path converts between the detected PSTN text telephone method and CTM. This mode of operation continues until text signalling ceases. Then transparent audio transport is re-established, again monitoring for text signals. This way of action allows alternating use of text and voice during the call according to established conventions in text telephony.

TS 26.226 [12] describes the details of CTM and an indication of how CTM can be combined with a text telephone modem to compose a conversion function in the call path.

ITU‑T Recommendation H.248.2 [9] describes the principles of conversion between PSTN Text telephony as in the text telephone ITU‑T Recommendation V.18 [4] and any general real time text conversation feature. So, even if CTM is not mentioned in that Recommendation, its general descriptions are valid for this case. On the PSTN end it is valid also for specific sub-modes of ITU‑T Recommendation V.18 [4] (Including the US method Baudot 45). The handling is slightly different depending on if the selected ITU‑T Recommendation V.18 [4] sub-mode is carrier-based or carrier-less, and if the call is known to be with a textphone or being general.

The descriptions in ITU‑T Recommendation H.248.2 [9] can be taken as functional descriptions of the call path without full implementation in a H.248 environment.

5.3.3 Emergency call considerations for GTT-Voice

It may be required to let a user use any CTM capable mobile terminal for a text call to the emergency service. If a terminal can support CTM and establishes a call with the CTM active then it will be expected to provide the network with an indication that a CTM detection/conversion function is required in the network.

It may be required to handle emergency calls also when the call comes from a SIM-less phone or a phone with an invalid subscription. To meet this requirement, one configuration option, when the CTM-SRF is used, shall be to route emergency calls independent of subscription status through the CTM detection/conversion function.

If the terminal supports CTM and is SIM-less, then it will be expected to indicate to the core network that CTM detection/conversion is required in the network.

Call back from emergency services is handled as normal Mobile Terminating calls.

5.3.4 Interworking aspects

The following are known interworking issues between the different circuit switched voice solutions, and these should be considered carefully before deploying different approaches within one PLMN or regulatory area:

– It is critical that all mobile terminals requiring CTM detection/conversion indicate to the network when CTM is required, otherwise a network that has adopted the CTM circuit pooling solution will not be able to allocate the appropriate CTM capable circuit. This CTM indication should therefore be considered a mandatory terminal requirement.

– An indication from a mobile terminal that CTM detection/conversion is required will not result in any interworking issues if the indication is received by a network where all the transcoders are CTM capable or where a core network CTM-SRF solution has been chosen. This is because the indication is redundant in this case.

– If a subscriber, from a network where all the transcoders are CTM capable or a CTM circuit pooling solution has been adopted, roams to a network where a core network CTM-SRF solution has been chosen, then the subscriber will only receive CTM conversion for emergency calls. The reason is that the subscriber lacks the necessary subscription to a CAMEL service, which would route this normal call via a core network CTM-SRF.

– In the case where inter-MSC handover occurs between an MSC where all the transcoders are CTM capable or a CTM circuit pooling approach is in operation, and an MSC which relies on a core network CTM-SRF, then the subscriber will lose CTM conversion for all calls.

If a subscriber from a network where a core network CTM-SRF solution has been adopted roams to a network where all the transcoders are CTM capable or a CTM circuit pooling solution has been chosen, then the subscriber will receive CTM conversion for all calls. The presence of two CTM detection/conversion functions in tandem should not create any interworking issues.

Annex A (informative):
GTT-Voice specific information for CTM support in, or associated with, all transcoders