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 for the negotiation of the text media and RFC 4103 RTP-text for transport, with text coded according to ITU-T Recommendation T.140 [5] as indicated in TS 26.235. 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.

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. 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.

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.

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.

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.

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.

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 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.

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.

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.