Consensus List for V.151 (Ex V.Toip)

INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 16 TELECOMMUNICATION TD 15 (WP 1/16) STANDARDIZATION SECTOR STUDY PERIOD 2009-2012 English only Original: English Question(s): 14/16 Geneva, 27 January - 6 February 2009 TEMPORARY DOCUMENT Source: Rapporteur Q14/16 Title: Consensus list for V.151 (ex V.ToIP)

This document contains the updated consensus list for V.151 agreed and approved at the closing of July 2007 meeting of Study Group 16.

CONTENTS

Introduction 2

Consensus points used for updates to V.151 2

Consensus points used for initial Consent and Approval V.151 4

(Full text available only in the electronic version)

Contact: Keith Chu Tel: +1 714 508 8728 Email: [email protected] Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T. - 2 - TD 15 (WP 1/16)

INTRODUCTION This document records the agreements that the experts group reach consensus upon concerning the work of V.151. Also contained are questions that will require resolving in the course of the development of this work. The Consensus points used to develop the Original version of V.151 have been moved to a separate section and new points which apply to the June 2006 published version of V.151 are indicated in a section that covers the maintenance and revision of the Recommendation.

CONSENSUS POINTS USED FOR UPDATES TO V.151

1 Scope of the V.151 (ex V.ToIP)

2 ToIP Architecture

3 IP Transport 3.1 (Previously 3.9.2.2) The group supports and encourages contributions on adding RFC 4103 support to V.151 as an Annex that provides complete procedures to allow interoperation between a legacy PSTN text telephone and IP text Devices that support only RFC. 3.1.1 It was agreed to use the text provided in Contribution 116 (November 2006) as the basis for a new Annex F of V.151. Editor will provide clean up and extract unnecessary material. This consensus list will document any agreed deviations from this text. 3.1.1.1 It was agreed that Annex F should be similar in content and style as that of Annex D. 3.1.2 Proposed text as agreed to in 3.1.1 needs to add clarification on the use of audio as used in conjunction with RFC 4103 as it pertains to the scope of this new Annex. This consensus item is considering the impact of merging the two channels of text and voice into a single media stream when transmitting to a PTP. The lack of synchronization between the two channels may have an impact on voice quality. It was agreed to keep the procedure simple by allowing text to have precedence over voice. The Annex will indicate that this side-effect may affect the voice quality. 3.1.2.1 For the 1 to 2 channel direction it was agreed to allow the negotiated voice codec to control the use of VAD/CNG transmission for the voice channel during periods of receiving text from the PTP. 3.1.3 It was recognised that the use of audio as an optional media stream as described in Contribution 116 (November 2006) may cause issues. This is a SIP issue and a solution needs to be considered. 3.1.4 The dynamic opening and closing of UDP/RTP ports as described in Contribution 116 (November 2006) may be problematic. It was agreed that text to Annex F be added to advise the implementer on the impact of this situation. Also additional latency may occur due to enabling of ports and the use of SIP re-invites. 3.1.5 It was agreed to add the necessary procedures for H.323 call control to new Annex F.

3.1.5.1 Should Annex F be constrained to SIP procedures only? - 3 - TD 15 (WP 1/16)

3.1.6 It was agreed to add examples of Call Control and Call Flow scenarios to supplement the procedures defined in new Annex F. 3.1.7 The baseline text for New Annex F is provided in Appendix II of this document. Based upon this version of text the following comments were noted

3.1.7.1 There is a section in F.3 about "deferring the advertisement" of RFC 4103 capability-- this is strictly a SIP function and not applicable to H.323. This will need to be cleaned up.

3.1.7.2 In general much of the text has to be written to ensure that it is not limited to SIP only and is written to be call control protocol agnostic as possible. Extensions to the text on SIP, H.245, H.248 specific can be added as appropriate.

3.1.7.3 F.3.1.1 (paragraph 2) stands in conflict with V.151 and Annex D, in particular. When a call is initiated, what we said in Annex D is to offer both V.151 and RFC 4103. Annex F should follow the same logic used as Annex D. Otherwise, there is a risk of not having two gateway devices communicate, because one implemented V.151 and the other followed Annex F strictly.

3.1.7.4 F.3.1.3: replace the use of "channel" with more protocol agnostic term. This term is used in H.323, but not SIP. In SIP, it's called an "RTP session", or just "session".

3.1.7.5 The second paragraph in F.4 seems to add no value.

3.1.7.6 Section F.7 needs to be made call control protocol agnostic.

3.1.7.7 There is an area yet addressed by the standards: interworking VBD systems with RFC 4103 systems. This is really part of the G/V.ipipgw work item. 3.2 Should the concept of using RFC 3840 and RFC 3841 for routing control as proposed in Contribution 116 (November 2006) be expanded to encompass all of V.151 and RFC 4351 as well as RFC 4301? 3.2.1 Agreed that definition of enhanced routing functionality is out of the scope of V.151. It was decided to remove all references to RFC 3840 and 3841 functionality from Annex F. However, if in the future it makes sense to add support of enhanced routing, then this could be added as a new annex or appendix as appropriate. 3.3 Agreed to add a new Annex E which adds the necessary text from the ‘historic’ RFC 4351 to make V.151 self reliant without the need to reference this RFC. 3.3.1 This requires changes to the text and appendices of V.151 as provided in TD-204R1 (WP1) of the July 2007 meeting.

4 Audio and Text Functionality

5 Media Switching

6 PSTN functions and Call Discrimination - 4 - TD 15 (WP 1/16)

CONSENSUS POINTS USED FOR INITIAL CONSENT AND APPROVAL V.151

1 Scope of the V.ToIP 1.1 It was agreed to create a new Recommendation for the support of legacy Text telephones over IP networks. V.ToIP shall be a standalone Recommendation, including inter-working with VoIP, with separate annexes that describe inter-working with other systems e.g. FoIP or MoIP. 1.1.1 The goal for completing V.ToIP shall be April 2006. 1.1.2. The Recommendation will make use of existing standards as appropriate (for example: ITU-T, TIA, IETF).

1.2 V.ToIP shall define Annexes for the different call signalling procedures (E.g. H.323/H.245, H.248, SIP, etc.) 1.2.1 It was agreed to use Annexes A & B of TIA-100 as the baseline text for the equivalent V.151 annexes for H.245 and SDP.

1.3 The implied version number of V.ToIP will be 0. When or if it becomes necessary the Recommendation will support a version number scheme similar to that contained in V.150.1. 1.3.1 If it becomes necessary V.TOIP shall use the version numbering syntax as described in TR30.1/03-07-050. (Provisional) 1.3.2 Section 5 of TR30.1/03-07-050 may be useful when it becomes necessary to indicate in V.ToIP how to interoperate with IP textphones.

1.4 The term PSTN Textphone (PTP) is used in this Recommendation to represent both TDD and TTY. The definition for PSTN Textphone as found in V.18 section 3.7 (included below) is considered suitable for this Recommendation? Text telephone: A device incorporating text telephony functions. Text telephone mode: The operational mode when two devices are interconnected to provide text telephone communications. Text telephony: A telecommunications capability that supports real-time text conversation on communication networks.

1.5 V.ToIP shall use as a baseline the definition of VBD as provided in Section 8 of V.150.1. Modifications to this definition may be made, but care shall be taken to ensure they do not break the V.150.1 definition.

1.6 The definition of Text Telephony over Internet Protocol (ToIP) is the dependable transport of legacy PSTN text telephones over IP networks using text relay as defined by the methods and procedures defined in Recommendation V.ToIP.

1.7 The provisional number for V.ToIP is V.151. - 5 - TD 15 (WP 1/16)

1.8 V.ToIP shall where appropriate provide the strongest encouragement to use this standard.

1.9 Agreed to use this definition for Baudot. “A five bit code formerly used in Teletype machines including those text telephones that operate per TIA-825-A specification. The use of the term Baudot in this recommendation is expanded to also include the modulation used by text telephones complying to TIA-825-A specification” “Baudot: A five bit code formerly used in Teletype machines and now found in some all North American TTY devices (TIA-825-A).”

1.10 It was agreed that not to include any procedures for VBD only mode of operation. These are adequately covered in V.152. (Annex C of the August draft of V.ToIP is to be removed),

1.11 An informational appendix on how to use intelligent probing using optional SSE’s is to be added to V.ToIP. (If still required after procedures are fully defined).

1.12 Agreed to consent the version V.151 as provided in TD-121R1. A cleaned up version is to be provided as a Plenary TD. (04/06)

1.12.1 Agreed to ask the ITU-T TSB whether Appendix II of V.151 can be published as a separate file. This would provide easy management and use of the Recommendation. (04/06)

2 ToIP Architecture 2.1 This Recommendation defines gateways that support configurations for both Audio/PTP and V.150.1/PTP 2.2 This Recommendation does not require support of proprietary mechanisms but they are not precluded. Each of the signaling protocols being considered as part of this work contains mechanisms to signal proprietary media.

2.3 The Recommendation will give consideration to networks with various levels of Quality of Service (QoS). 2.4 The following diagrams are used to help explain the reference scenarios for ToIP. - 6 - TD 15 (WP 1/16)

IP Textphone

Central Office

SD PSTN Textphone 1 2 3 4 5 6 7 8 9 * 8 #

Gateway

Central Office

IP NETWORK

PSTN Textphone Gateway

1 2 3 4 5 6 7 8 9 * 8 #

IP Textphone

Voiceband signal Voiceband signal (audio/modem) IP Transport (audio/modem)

PSTN PACKET NETWORK PSTN T1 G1 G2 T2

Connection Scenario TR1: T1 to T1 via Access Gateways G1 and G2

IP Transport

PACKET NETWORK I1 I2

Connection Scenario TR2: I1 to I2 via Direct connect to IP Network

IP Transport Voiceband signal (audio/modem)

PACKET NETWORK PSTN I 1 G2 T2

Connection Scenario TR3: I1 to T2 via Access Gateway G2 - 7 - TD 15 (WP 1/16)

PSTN - based X text telephonetelephone (TTY/TDD) Acoustic Coupling IP Endpoint Acoustic Coupling (IP Phone) O One or more X IP Network(s) PSTN - based PSTNX X IPX Endpoint X IP Endpoint PSTN - based text telephone phone (IP Media (IP Media text telephone (TTY/TDD) Gateway) Gateway) IP OEndpoint (TTY/TDD) (Native IP Text telephone) Figure 1: Reference Diagram for a Text-over-IP Network Architecture 2.4.1 The inter-working between Gateway and IP Text telephone could be defined in an annex to V.ToIP. 2.4.2 Add annex in V.151 that describes interoperability between gateway and IP text devices that use audio/t140c. 2.4.1.1 For the I1 to G1 scenario case, a two-port approach (one for the text stream and one for the voice media stream) may be used. 2.5 (Place holder, it was 2.4.1.1) 2.6 It was agreed at the 10 August 2004 meeting that the goal to define procedures and mechanisms for the I1 to G2 scenario is beyond the scope of this version of V.ToIP and should be removed. The application should however be considered when defining V.ToIP procedures. 2.7 The Recommendation shall use the service definitions (where appropriate) from F.703. 2.7.1 Does F.703 adequately address the requirements where a packet network is placed between the end-point terminals? Note: Q11/16 Rapporteur to contact QH/16 Rapporteur and enquire. 2.8 The support of H.324 is beyond the scope of V.ToIP. 2.9 There shall be a goal to support protocol conversion where possible in this Recommendation. 2.9.1 It was recognized that protocol conversion would apply only to Text Relay. 2.9.2 Protocol Conversion in this context is the inter-working of dissimilar end-point text telephone terminals performed by the Access Gateways. 2.9.3 It was noted that T.140 and V.18 may not be fully defined especially in the use of the Latin- 1 supplement character set. 2.9.4 T.140 specifies that the newline character is encoded as 2028 hex. When converting this character to Baudot it shall be encoded separately as CR LF (Two characters) 2.10 It was agreed at the August 10, 2004 meeting of Q11/16 to delete the text in this item and item 2.10.1 (below in strikeout) from the draft standard. Due to the conflict of differing - 8 - TD 15 (WP 1/16)

requirements and non-specific “QoS” levels and impairments, it was agreed that it would be best to eliminate this section. Agreed to use this text as a basis in the Recommendation for the description on handling text telephony, when the network is High QoS. Solution for handling Text Telephony payloads in a High QoS Networks In benign environments with high QoS (e.g. ITU-T Y.1541 Class 0 or 1) and plenty of bandwidth, a codec that is friendly to text telephone operation may be consistently used. In this case, there is no detection of text telephone stimuli in the voice channel and subsequent change in media format. Examples of codecs that are friendly to text telephone operation are PCMU, PCMA, G726-40, G726-32 etc. The set of codecs used may differ from application to application. If QoS were not high, then there would be a need to supplement text telephone connections with fault-tolerance schemes such as RFC 2198 redundancy and RFC 2733 FEC. If text telephone stimuli were not detected on a call-by-call basis, then these fault- tolerance schemes would need to be applied to all calls. Although not precluded, this is not necessary in this case because of the high QoS of the network. 2.10.1 Agreed to add text to the introductory description of V.ToIP to explain the role and relevance of VBD and Text Relay modes as they apply to various network QoS types. 2.11 A Gateway should be allowed to negotiate during call setup the ability to stay in VBD (default) or to allow media switching between VBD and audio during the call. 2.12 Performance between the gateway’s PSTN interfaces shall be specified in CER (Character Error Rate) and delay. Delay should be minimized while still maintaining acceptable CER. Note: The gateway to gateway performance depends upon the network connected between the gateways and therefore any specified performance will depend upon the condition of that network. It is possible that any performance requirements will be stated for specific network conditions. (Note, there has been some discussion on this point. It is not clear whether it should be changed). One suggestion is to specify the performance of a gateway as being: The character error rate of the T.140 encoded data from output of the demodulator to the input of the modulator over a perfect network shall be < 0.01%. (Note this % has to be verified). Performance of the local link between the gateway and the PTP should conform to F.703. 2.12.1 We will not specify the CER between the gateways for real network conditions, nor the thresholds and network conditions. 2.13 This consensus point is being changed (8/11/04). The original text (in strikethrough) is being replaced by text in underline. Question: Exactly how should V.ToIP support VBD and Text Relay and what will be their relationship? Note: This question is querying whether V.ToIP shall mandate the support of both VBD and TR, or can either transport mechanism be used independently of each other. I.e. do we allow Text Relay or VBD only TOIP gateways types? V.ToIP defines Text Relay for PSTN legacy text telephones, V.152 shall be supported ro support the fall back cases of two conditions. These conditions are: a) At least one of the gateways does not support V.151 (or TIA-1001). - 9 - TD 15 (WP 1/16)

b) If the gateway determines that the connected terminal is using an unsupported modulation. 2.13.1 The relationship between VBD and text relay shall be explicitly defined in V.ToIP. E.g. ToIP will provide the procedures for switching /transitioning between VBD and Text relay and vice versa. 2.14 If a ToIP gateway is also MoIP enabled and an Answer Tone triggers the modem relay procedures (for example), need appendix/annex in V.151 on how does the gateway switch to ToIP (or VBD). 2.15 Agreed to add to section on Text Relay Throughput in the draft text an informative note on how to specify the transmit character rate and receive buffers to manage modems that have different data rates. 2.15.1 In the procedures, effort has been made to match modulation on both call legs so that throughput issues are avoided. In cases when protocol conversion does occur, gateways must ensure that appropriate buffering from the IP network take place. Vl51 needs to provide guidance as to the amount of buffering that will be required under different protocol conversion scenarios. 2.16 Recommend the advertisement of the CPS value to be greater than or equal to the highest signalling rate of the gateway supported modulations. Rational is to ensure that there is no corruption of data modem signals.

2.17 Q11/16 supports and encourages the consideration of V.151 as a tool to define system architectures that support the need of interoperating legacy PSTN text telephones with new and emerging text telephones.

3 IP Transport 3.1 This Recommendation shall specify the dependable transport of PTP signals over the IP network. (ToIP) 3.2 The Recommendation will support VBD as one the transport modes for ToIP. 3.3 RFC 4351 shall be the default Text Relay transport. 3.3.1. RFC 2793 has been revised to resolve the issue described by point 3.9.3. This revised version is now the preferred reference for V.ToIP. However, if this RFC is not completed in time, then V.ToIP, will extract the relevant differences from ‘RFC 4351 and create a separate normative section in V.ToIP. 3.4 V.ToIP shall support SPRT as a negotiated option for text relay transport. 3.4.1 SSE’s must be negotiated for SPRT to be used. 3.4.1 When SPRT is used as the transport channel, SPRT channel 3 shall not be used. 3.4.2 I_OCTET_INFO shall be the default data type. 3.5 RFC 2198 shall be a supported capability of a V.ToIP gateway but can be optionally enabled, An appendix will be created to either provide appropriate examples or add clarification of the use. - 10 - TD 15 (WP 1/16)

3.5.1 RFC 2733 can optionally be supported and enabled when needed. Issues with RFC-2733 used in ToIP (relative to RFC-2198 redundancy) a) Additional overhead, b) Algorithmic complexity c) Additional latency, d) Operational difficulties in networks e) Possible obsolescence with emerging RFC’s 3.6 The Recommendation supports DTMF tones over the IP network. The DTMF tones should be supported per RFC-2833, but may also be H.245 UserInputIndication in the case of H.245 systems. 3.7 Transport of PTP text character by character 3.7.1 In some cases the user of the PTP device may type very slow. Normal operation for terminals connected over the PSTN only is to send each character typed across the network without waiting for some form of end of line or end of message character. The gateway function should operate in a similar manner. For text relay, individual characters received by the gateway from the TDD should be sent into the IP network without delay. However, in cases where flow control is required (e.g. to honor the CPS value provided by the remote gateway) some buffering of the character data before sending into the IP network might be required.

Note: RFC 4351 has recommended a buffering time of 300ms to 500 msec. Since, for ToIP, text is received only off of a TDM interface, this buffering recommendation is not needed. 3.7.2 The Recommendation supports PTP’s operating at full character speed. 3.7.3 The Recommendation will recommend a maximum gateway-to-gateway character error rate of 1%. See 2.12 3.8 V.ToIP shall use the apostrophe character as the lost character symbol for Baudot. This symbol will be used to replace lost or missing characters when it is known that a character has been lost in the packet network for example due to packet loss. 3.8.1 The T.140 lost character (0xfffd) shall be mapped to the apostrophe for the conversion of T.140 to Baudot. 3.8.2 Question: what other lost character mappings are necessary to be defined. Answer: none. 3.8.3 It was agreed to stipulate the use of the apostrophe character for T.50 encodings as well as Baudot. (04/06) 3.9 It was agreed that V.ToIP shall define procedures for single port operation. The use of multiple ports is for further study. 3.9.1 It was also noted that for two port case, it may be necessary to always open two UDP ports whenever a connection is made regardless whether ToIP is to be used on that particular connection. 3.9.2 This issue and issues 3.9.3, 3.9.3.1, 3.9.4, 3.9.5, 3.9.6 and 3.9.7 have been superceded by the decision to use RFC 4351. Deleted text is shown in strikethrough. Issues with using a single UDP port for both text relay and voice are given in section 5.3 of RFC-1889 (RTP). This section states that RTP is not intended to support multiple media over a single UPD/IP port. - 11 - TD 15 (WP 1/16)

As stated in section 5.3 of RFC-1889, using separate SSRC's for the text-relay and voice will avoid problems 1 through 3 given in section 5.3, but we still have problems 4 and 5. Question: Do problems 4 and 5 of RFC-1889 section 5.3 apply to mixing of text-relay and voice in the same UDP/IP port? With the introduction of audio/t140c mime type into IETF, we are no longer have these issues. 3.9.2.1 RFC 4351 MIME type audio/t140c shall be supported by ToIP gateways. The RFC 4103MIME type text/t140 use is for further study so that interoperability with non-V.ToIP devices may be possible. 3.9.2.2 The group supports and encourages contributions on adding RFC 4103 support to V.151 as an Annex that provides complete procedures to allow interoperation between a legacy PSTN text telephone and IP text Devices that support only RFC . 3.9.3 How do we synchronize the voice-spurts with the text-spurt when using text-relay given that voice will be carried most likely using a 8000 Hz time source, whereas text-relay will be carried with a 1000 Hz time source? This synchronization problem exists regardless of how many UDP/IP ports are used to carry the voice and text-relay. This is not a problem when using audio/t140c since the clock rate for audio/t140c is identical to that used by the audio. 3.9.3.1 RFC 2793 bis will resolve this issue. (See point 3.3.1). 3.9.4 Another consideration is the concept that using two UDP ports may be more costly to a user, if charges are based upon a per port basis. 3.9.5 One possible solution is to use the NTP of RTCP to aid the synchronisation of the two timestamps. 3.9.6 V.ToIP should use the same type of language as used in V.150.1 when referring to UDP ports. 3.9.7 for single port operation, then RFC 3407 is recommended (See D.326). Note: (If ‘RFC-2793 bis’ is approved we will not need RFC-3407). 3.10 When in Text Relay, T.140 shall be used to encode all PTP data over the IP link. 3.11 For switching from VBD mode to Audio mode, in the case of supporting Text Telephones, the use of bi-directional silence shall not be used when the text telephones use carrier-less modulations. It may be used to switch when the text telephones do use carrier based modulations. [The sentence on carrier based needs expanding based upon discussions] Note: long periods of silence may occur in text conversations. 3.12 Should further clarification be provided in V.ToIP as how to handle redundancy in RTP streams for text relay? For example if redundancy is enabled how are the redundant packets to be played out when no characters are being transmitted. Are the redundant packets played out at a fixed interval per redundancy level, can they be sent as a group or do they wait until the next character? Agree to us the recommendations of RFC-4351 to answers these question. 3.13 ToIP gateways only need to consider T.50 and Baudot character sets for protocol conversion cases. Support for other character sets and character set conversion is for further study. 3.13.1 Which other T.140 encoded character mappings between character sets are necessary? - 12 - TD 15 (WP 1/16)

3.14 Issues have been identified dealing with mapping of national character sets. V.18 does not address this, so while it is possible to have text phones with different modulations to “connect” at the physical layer, communication may not occur. The support for character mapping beyond T.50/baudot and other national character sets is for further study.

4 Audio and Text Functionality 4.1 The Recommendation shall support the alternation of voice and text in a half-duplex manner. This includes scenarios such as where the deaf person is speaking and receiving responses via the PTP, or where a person with a speech disability is using text to transmit and is receiving voice responses. 4.2 This Recommendation shall support alternating Text and voice in the same direction For Example; Network Voice announcements may be preceded by a short burst of TDD (TIA-825). Following the voice announcement a longer TDD (TIA-825) message will be seen.

4.3 The support of Simultaneous voice and text (V.61) is for further study. 4.4 When Interactive Voice Response (IVR) systems are involved voice and TDD (TIA-825) messages appear in one direction with DTMF tones in the other. 4.5 To support IVR, a gateway shall enable its DTMF receiver concurrently with the text telephone modem. 4.5.1 If a text message is interrupted on the PSTN link by a DTMF signal, the gateway shall continue to playout all remaining text. 4.5.2 How would V.18 DTMF mode work with IVR? Since V.18 DTMF is treated as all other DTMF (e.g. for signalling or IVR), there is no issue here.

5 Media Switching 5.1 To use payload type indication as the default media switching mechanism for V.VBD, and V.ToIP. SSEs may be optionally negotiated. If both gateways negotiate the capability of SSEs then SSEs shall be used 5.1.1 V.150.1 Annex C is an optional method to perform media state switching as necessary. The accepted media states are Audio, Voice Band Data (VBD), Text Relay, and Text Probing. 5.1.2 If not using SSE’s (i.e. using payload type switching), no attempt to forcing matched modulations will be made since no indication of modulations being used is sent between gateways. 5.2 What are the criteria for the detection and allowable amount of leakage when; i. Switching from voice to VBD/Text Relay? ii. Switching from VBD/Text Relay to voice? 1) Leakage time should be as short as possible (should be held to a minimum) 2) If leakage > ½ bit time, it may generate an extraneous character 3) The start of playout of correct character should be one character time past the onset of the leakage (silence may be used to pad) - 13 - TD 15 (WP 1/16)

4) This prevents UART decode (extraneous characters, false character syncs) 5) When regenerating the first character during text relay, the character should be preceded with mark for at least 2 bit times. 5.2.1 Leakage as used in 5.2 means leaking signal into the IP network in either VBD or AUDIO encoding. 5.2.2 MAX leakage is character -1 bit. 5.3 Visual Flow Control will be an optional procedure by a gateway. 5.3.1 Is the concept of using ‘visual flow control’ procedure an acceptable method to prevent possible loss of received character? This mechanism uses the ability for a gateway to send a “Please Wait” type of message to the connected text telephone, while the modem probing occurs. Once the text telephones are determined and a connection is established the text telephone on ‘hold’ is given a “Please Continue” type of message (e.g. “GA”). No conclusion on the viability of this method was made. 5.3.2 Should a visual flow control for XON be defined? ‘GA’ is used in English speaking countries. ‘+’ is used in many European countries. 5.4 Is VBD good enough to support voice, so therefore alleviating the requirement to switch media streams when handling HCO and VCO scenarios? No longer an issue. 5.5 The Table shown below contains proposed RIC’s to be used for media switching to VBD when SSE’s are used. The codes are not exhaustive and may change by consensus.

Table 1: Proposed Additional RICs for SSE:VBD

Name Code (decimal) Additional Informational Content Baudot 31 None at present/TBD (45.45 bps) Baudot (50 bps) 32 None at present/TBD EDT (European Deaf Telephone) 33 None at present/TBD Bell 103 modem 34 None at present/TBD "Old" V.21 text telephone, 35 None at present/TBD T.50 encoding (not V.18 text telephone) V.23 text (Minitel) 36 None at present/TBD V.18 text telephone, 37 None at present/TBD T.140 encoding CTM 38 None at present/TBD

5.5.1 The definitive definition of the RIC codes is in Table 12/V.150.1. 5.6 Should payload type switching be the default method used for media switching in V.ToIP instead of SSE’s (per clause 5.1). – Deleted (See Point 5.1) 5.7 For VBD and Text Relay the first character from the PCM to the IP shall not be lost nor shall it be repeated erroneously. - 14 - TD 15 (WP 1/16)

6 PSTN functions and Call Discrimination 6.1 Note the expected behavior is for carrier-based systems to use the same mode as when connecting to V.18 capable devices connecting through the PSTN. 6.2 V.ToIP Text Relay shall support one or more of the text telephone protocols specified in ITU-T Rec. V.18, but does not require support for all. With the exception that Annex B will be optional. The actual support of textphone protocols shall be advertised between the peers, not unlike modem modulations advertised in V.18. The experts should agree upon an attribute name for SDP and appropriate H.245 capability structure for enumerating the list of supported protocols.

V.18 defines the following modes; a. ITU V.18 text telephone. This is the standard for PTP terminals worldwide. It uses the ITU T.140 text conversation protocol and V.21 modulation. The difference from (i) below is the character encoding and the V.8 connection procedure for native V.18 terminals defined in this procedure allows the identification of native V.18 terminals on the basis of the V.8 Call Indicator (CI) signal. When a V.8 CI indication of call function = textphone is absent, then the connection procedure reverts to V.25 and the terminals are identified as the old V.21 terminals in item (i) below. b. 5-bit, FSK Baudot terminals at 45.45 bits/s, described in V.18. This is used in North America, and Ireland. c. 5-bit, FSK Baudot terminals at 50 bits/s, described in V.18. This is used in Australasia. Whether the two Baudot modes remain as separate modes or coupled is still an open issue. It was agreed at the August, 2004 Rapporteur meeting that both the 45.45 and 50 bit/s modes shall be coupled. d. DTMF-based TTY terminals, used in the Netherlands. e. EDT, European Deaf Telephone, which uses ITU V.21 frequencies at 110 bits/s half duplex transmission. It is in vogue in Germany, Switzerland, Italy, Spain and Austria. f. Bell 103 terminals. These terminals are used in North America. g. ITU V.23 Videotex terminals ('Minitel'). These are used in France and Belgium. h. ITU V.21 terminals at 300 bits/s in full duplex mode. These are used in the United Kingdom, Iceland, Norway, Sweden, Finland and Denmark. The characters are encoded per the national character sets in ITU T.50. 6.2.1 Should the proposal as described Delayed 407 to specify a minimum support of text telephony modulation support in a V.ToIP gateway be accepted? This modifies the previous consensus on requirements as stated in 6.2. “That ToIP should support all of the textphone protocol specified in V.18, but not require support for all.” It was agreed at SG16 meeting to delay any decision on this question to allow further technical contributions to be submitted and discussed. - 15 - TD 15 (WP 1/16)

At the August 10, 2004 Rapporteur meeting it was agreed to accept the proposal contained in D-407 being there were no technical comments or contributions addressed against this proposal. (SEE modifications to 6.2). 6.2.2 Add a note to the text that informs that if a gateway has only a single modulation supported then it is encouraged that modulation be specific to the region of deployment. 6.3 Question: Should a tiered or a classed method of modes be defined for the non-Hi QoS network support? (See Q1103-07R2) 6.4 The procedures defined in V.151 will deal with all modulation discrimination ambiguities.

6.5 V.ToIP should consider a complete taxonomy of call scenarios to help resolve the call discrimination requirements. 6.6 Gateways shall monitor and detect V.8 bis dual tone on the PSTN link and prevent further V.8 bis signals from being transmitted into the IP network. The support of V.8 bis is for further study. 6.7 The diagrams shown in Appendix I provide example call discrimination for ToIP. They are only for illustrative purposes. No procedure or agreement is implied by them. 6.8 Appendix 1 of V.18 provides recommendation for the order of probing. Any modulation information about the remote TTY type can be used to influence the probe order. Example could be: to use the country specific probing as described in Appendix I of V.18; to use knowledge of the remote TTY type to start the sequence. (This may reduce connect time for like to like cases, but increase connect time for protocol conversion cases.) 6.8.1 For SSE’s, probing shall start with the modulation indicated in the SSE for constant carrier modulations (if supported by the gateway). Probing should start with the modulation indicated in the SSE for non-constant carrier modulations. 6.9 Should the hypothesis that if a ToIP Gateway with Text Relay detects a V.21 modulated signal and incorrectly assumes it to be a Textphone, then as long as the signalling channel between the gateways does not corrupt the data and both call legs are the same modulation, then there is no harm done and relay becomes a free side effect be used? (See Appendix III of this document) 6.10 Question: Is there a need to provide a messaging scheme to support text terminal inter- working with respect to a disjoint capabilities scenario? Not open anymore, procedures take care of this. 6.11 “Visual Flow Control” is the introduction of text by the gateway during the call discrimination phase providing feedback to the PTP end user about the status of the end-to- end PTP connection. An example would be sending a “please hold while establishing connection” phrase to the user. Visual flow control is recommended during call discrimination that involve significant delays (e.g. connecting with different devices that requires a long probing stage on one end or the other) or call discrimination phases that may involve initial loss of user data (e.g. when switching from text relay to VBD due to unsupported modulation mode on either of the gateways). 6.11.1 How should the language for visual flow control be determined? This is a local configuration at the gateway. - 16 - TD 15 (WP 1/16)

6.11.2 What level of specification of visual flow control should be included in the recommendation? 6.11.3 “Visual Flow Control” phrases should take into account typical line sizes used PTP. 6.12 CI/XCI can optionally be transported using VBD, or can be carried in audio mode. If carried in audio mode, there is no guarantee of the signal being detected, but per V.8, CI/XCI are not reliable signals anyway. Worst case, if CI/XCI is corrupted, there could be up to 3 sec delay until the ANSam is generated. 6.13 PLACEHOLDER 6.14 For payload switching, when receiving a TR payload, the gateway shall start the automode probing sequence with its local PTP device. 6.15 Gateway that received TR payload causing start of automode probing sequence as described in 6.14, upon timeout during automode probing sequence shall initiate a transition to VBD mode. 6.16 The following set of call flow diagrams are enough to describe the set of call discrimination cases for payload type switching

Originator PTP Answer PTP V.18 V.18 non V.18 V.18 X Constant carrier non V.18 X non-constant carrier non V.18

6.17 The following table describes the taxonomy of call discrimination cases.

T1/G1 T2/G2 T1/T2 Mode Communications Y Y Y TR YES Y Y N TR YES N Y Y VBD YES N Y N VBD NO Y N Y VBD YES Y N N VBD NO N N Y AUDIO MAYBE N N N AUDIO NO Note if V.152 is also supported with PTP detectors, the mode will be VBD for the last two rows. Tx/Gx column indicates if the Gateway Gx supports text relay for the modulation used by Tx. 6.18 Autonomous operation is where both gateways independently connect with their PTP devices. The triggering mechanisms into autonomous operation are still to be defined. - 17 - TD 15 (WP 1/16)

6.18.1 Autonomous operation is for further study. 6.18.2 Should there be a preference negotiated for autonomous operation or should it be mandated when both gateways are full automoding. 6.19 For call discrimination cases when there is probing from the PTP device, how do we discriminate carrier based signals from data modem signals for the purpose of initiating switch to TR mode? This applies to Figure III.3 in call discrimination diagrams. See procedure. 6.20 If both PTP terminals are V.18 and one or both of the gateways do not support native V.18, the V.ToIP call discrimination procedures will result with VBD being used with V.18 native between the terminals if SSE’s are not used. If SSE’s are used, text relay will be used if possible. 6.21 When connected to a known V.18 PTP terminal, and a TR-SSE is received while the gateway is in VBD or VOICE mode and the TR-SSE indicates the modulation used between the remote gateway and it’s PTP terminal in the reason code, use this modulation between the gateway and it’s local PTP terminal if the gateway supports this modulation. Matching the modulations on the two legs in this manner will result in predictable throughput performance and few buffering issues. 6.22 Probing by gateway to determine local PTP modulation is only performed when the gateways are using SSE for state control. When not using SSE’s (i.e. payload switching), the gateway does not perform probing. Note that not allowing probing will limit the possibility of protocol conversion happing on the connection. 6.22.1 The call discrimination flows that involve probing require the ability to indicate probing failure so as to fall back to VBD and the ability to indication successful negation with the local PTP device to the remote gateway to control the remote gateways probing.. Only through the use of SSE’s is this possible. 6.23 If a gateway supports V.18 native, it must support at least one other modulation defined in V.18. 6.24 The call flows developed at June 2005 Arlington TIA TR-30 meeting and refined at the July 2005 ITU SG16 meeting shall be used in appendix II of V.151 as examples of text call flows, and used as basis of development of SDL to define call discrimination procedures. 6.25 The SDL’s derived from the call flows in Appendix II of V.151 shall be used as basis of call discrimination procedures for ToIP. 6.26 SSE-RIC shall be used for ToIP call discrimination that uses the optional SSE protocol. 6.26.1 For constant carrier modulations, use the SSE-RIC code that indicates the carrier (i.e. HI/LO). 6.26.2 Add tone1270 CI/XCI and CJ RIC codes to the SSE RIC codes in V.150.1 6.27 In scenarios 17&19 (and possibly others), should the gateway send SSE TP/TR w/ indication of bit rate for baudot (45.45/50) or use a generic RIC code that doesn’t include the bit rate? 6.28 When transmitting Baudot at a given bit rate (possibly based on bit rate indicated in SSE(TR/TP)) and the gateway receives a Baudot modulation at the other bit rate, the gateway should switch to transmitting at the bit rate received. - 18 - TD 15 (WP 1/16)

6.28.1 Since, in the SSE cases, upon the detection of Baudot, gateways enter the TP state, and there is no mechanism for transmitting characters to the remote gateway. So the gateway performing the probing shall use predefined characters for its probing per V.18. 6.29 Switching out of Text Relay mode - Switch is implementation specific. For half-duplex, need to put recommendations in order to minimize superfluous switches in and out of text relay. Example: Switching on silence alone is not recommended as this may cause too many transitions which in turn may cause excess character leakage and undue complexity. - remember last mode so as to use this and avoid probing when text comes back on. This should not be remembered across calls. If the gateways does not know call state, there should be some kind of memory loss mechanism implemented. - For SSE case, stay in text relay mode until an SSE(audio) is either transmitted or received. - for duplex modulations, silence could be used for initiating transition out of text relay mode. 6.30 If negotiated by the gateways, answer tones can be encoded using RFC-2833 in either audio or VBD modes.

APPENDIX I

Suggested Call Flows for ToIP Transitions

Deleted information material used to develop V.151 (04/06).

------

APPENDIX II

Baseline text for Annex on using RFC 4103 IP text terminals.

Annex F

Interworking between IP text devices and V.151 Gateways using the protocol defined in RFC 4103 (Baseline)

F.1 Introduction Real-time text can be transported in IP networks using standard IP protocols. Non-Gateway IP devices in the network, such as multimedia telephones, IVR systems, voicemail systems, IP phones, or other devices, may support the transmission of real-time text over IP networks and, ideally, interwork with V.151-compliant Gateways in order to provide a means by which PSTN textphone devices can communicate with those IP devices. This class of devices is referred to herein as an "IP Text Device", ITD. - 19 - TD 15 (WP 1/16)

This Annex defines the optional procedures that allow interworking between V.151 Gateways and IP text devices using the protocol defined in. RFC4103. This Annex describes how has been specified by the IETF to support the carriage of real-time text in RTP packets between IP text devices. This Annex specifies the use RFC 4103 as the text transport method between gateways and IP text devices. The transport method for real-time text used in IP networks has no relation to the audio coded modulations used for text transport in PSTN. All aspects of textphone modulation and demodulation are supposed to take place in gateways. rReal-time text and audio when presented in different media streams communicating with a RFC 4103 based IP text device can be interfaced and converted to a multiplexed real-time text and audio transmission to a PTP. is a component in VoIP and IP multimedia telephony. The audio component of these services can be transferred through the gateway considering the need to taking turns between audio transmission and transmission of text in form of modulated audio as specified for the PSTN textphone protocols.

F.2 Functional goals of the procedures The procedures described in this Annex are designed with the following functional requirements in mind.  It shall be possible for the gateway to open text channels only in calls where it is evident or likely that text will be used.. This possibility is introduced to satisfy requirements from gateway environments where it is considered to be unfavorable to open text channels that are not used.  The procedures shall support a phased introduction of real-time text capable gateways. It shall be possible to direct calls where it is evident or likely that text will be used to gateways capable of handling real-time text. Calls without the need for text support may still be handled by gateways not capable of handling text.  The procedures shall support IP text devices using the real-time transport of text described in RFC 4103, “RTP Payload for text conversation” connecting to gateways compliant to this Recommendation. The support of RFC 4103 to RFC 4103 IP text terminals is beyond the scope of this Recommendation. . This text transport specification is described in a number of specifications to be the default transport of real-time text for IP terminals, emergency services, wireless services etc.  The procedures shall support calls where text use starts at any time during the call.

F.3 Exchanging capabilities and opening media streams This annex specifies functions to be implemented on the call control and media channel establishment level. For exact protocol details, the reader should consult the referred protocol descriptions. When establishing a call with a V.151 gateway, an IP text device may advertise support for real- time text in accordance with IETF RFC 4103. IP text devices transmit text characters when communicating with other IP text devices using RFC 4103, whichby specifyingies the establishment of a separate RTP text medium stream specifically for for the transmission oftransmitting text characters. V.151 PSTN gateway devices used for gateway to gatewaygateway-to-gateway operation are specified to use interleaved audio and text data according to RFC 4351. - 20 - TD 15 (WP 1/16)

When a gateway is used for both IP terminal communication and gateway-to-gateway communication, the gateways need to support both RFC 4103 to interwork with IP text devices and RFC 4351 for communicating with other PSTN gateways. In calls where it is not evident if the answering part is a terminal or a gateway, V.151 gateways supporting this Annex are recommended to indicate support for both transport methods initially when exchanging capability information. However, relatively few calls use real-time text in the PSTN, and therefore Iit may be desirable for some gateways to not to open the a text channel until either party in the call explicitly acts requests to use real-time text. Thus, the procedures described here allow the V.151 gateway to not defer the declaration of the e capability for RFC 4103 initially in the call, and allow the parties to open a text channel whenever if needed during the call. According to normal procedures in IP multimedia systems, it is allowable to indicate capability for other transport protocols for real-time text as well as RFC 4103 and connect such alternatives. Therefore, the procedures in Annex D can be used in parallel with the procedures described in this annex. F.3.1 Systems based on SIP and SDP In SIP-based systems, the IP text device and the gateway SHALL announce text the capability for text in the SIP header according to RFC 3840. They MAY may indicate a preference or a requirement for text according to RFC 3841. Many PSTN text telephones can only operate in a turn-taking manner. Limitations in simultaneity may affect both the two text transmission directions and the transmission of text versus audio. It is preferable to use an indication from the gateway in the call setup that will allow IP text devices to inform users of the need to communicate in a turn-taking manner. F.3.1.1 Call from PSTN A V.151 Gateway should indicate text capability in the SIP headerduring the call set up phase of a call. If the gateway at call setup time already has an indicationit is known that text will is to be required, in the call, a the capability for requirement for text shall be included in the SIP headerset up exchange, and a media description for real-time text according to RFC 4103. The reason to include text when offering the call may be because textphone tones have already been detected on the PSTN line, the gateway may be configured to be a dedicated text gateway, or it may be known by subscription or any other external means that either user has preference for text. Audio would normally be offered initially in the call per standard negotiating procedures. An answering device that is an ITDIP Text Device that supports RFC 4103 where the user has indicated a preference for text, would accept the text medium and optionally audio. However the answering IP Text Device may optionally deny the text medium, but still indicates its capability during the call set up negotiation. An answering device that is an ITD where the user has not configured it for text preference, may deny this initial offering of the text medium, but still indicate text capability in the SIP header. Note that connection of a text channel in the initial call setup is only possible when the gateway had included the text medium in the offer. For other cases when a text channel is required, the terminal needs to accept the call with any common media and do a rRe-invite or equivalent to add text during the call. - 21 - TD 15 (WP 1/16)

F.3.1.2 Call from IP terminal A calling ITD IP Text Device configured for requiring real-time text support shall indicate text capability and text requirement in the SIP headerduring the call set up phase, and issue a text media description according to RFC 4103 in the sdp. By declaring the text requirement in the SIP header, SIP routing will prioritize connection to a text capable gateway. The gateway should acknowledge and connect the text channel initially, because of the indication that text is required. The gateway should also start text channel connection procedures on the PSTN side per V.151 procedures. That will cause initiate the transmission of text telephone tones to be sent on the PSTN line., making it occasionally interrupting any voice transmission. Therefore, users will not use this indicator unless requiring text support. If on the other hand, the IP device user is not depending on text, but want to have it available for occasional use,If the IP Text Device does not initially require text capability the IP device can be configured to only declare text capability in the call SIP headerset-up negotiation and optionally include the sdp text media descriptor according to RFC 4103. SIP routing will in this case prioritize to connect to a text capable gateway, but may connect through a non capable. TheA gateway may decide to not acknowledge the text channel initially, but shall indicate its text capability in the SIP header. In case the text channel was not connected initially, but is required later in the call, there is a possibility to issue a SIP rRe-invite or similar by any party in the call in order to add the text channel. The procedure to follow for that case is described below. F.3.1.3 Text channel establishment during a call If at a later stage in the call, either party in the call starts text activity, and no text channel was set up initially, a text channel should can be added to the session by a SIP rRe-invite operation. The rRe-invite shall follow SIP the appropriate procedures and include sdp declaration of all media wanted required after the rRe-invite. Text declaration shall follow conform to RFC 4103. The other party should answer respond with a similar saccordinglydp. F.3.2 Systems based on H.323 and H.245 Procedures for systems based on H.323 and H.245 can be established following similar principles as above, based on H.323 Annex G. – See clause XXX

F.4 Procedure for terminals including both RFC 4103 and RFC 4351 support In the case when a terminal implements both RFC 4103 and RFC 4351 for text transport, the procedures in Annex D should shall be applied. in the terminal in addition to the procedures described in this Annex. When establishing a call, an ITD may advertise support for real-time text in IP according to the procedures described above, and also the procedures described in Annex D. The capabilities of the other party in the call setup will lead to text transport either according to RFC 4103 or according to RFC 4351.

F.5 State transition and text handling The following description assumes that a V.151 -compliant Gateway gateway is in communication with an IP Text Device and media streams have been established to transport text over IP in accordance with RFC 4103. - 22 - TD 15 (WP 1/16)

When the gateway compliant to this annex detects signals from a PSTN textphonePTP that it supports using text relay, it shall autonomously connect to the textphonePTP. After connection on the PSTN side is established, the gateway shall open the a text channel to the IP Ttext Ddevice. It shall decode transmit the characters received and transmit them to the IP text device taking into account the , giving proper respect to the maximum character-per-second (CPS) parameter advertised by the IP text device. There is no requirement for the gateway to inform the IP Text Device of the type of PTP it has connected to. For transmission of text from the IP Text Device to the PTP, if not already done so the gateway and IP Text Device shall open a text channel between them. Once the channel is opened Determining the type of PSTN textphone device in use is the responsibility of the Gateway and the IP text device need not concern itself with what kind of PSTN textphone device is connected to the Gateway. Likewise, when the IP text device has characters to send to the Gateway using the real-time text payload type, the IP text device shall open the text channel if it was not opened before. After the text channel is opened, the the IP text device shall transmit the text characters to the Gateway. The gateway initiates a call to an answering PTP and autonomously establishes a text connection. During the PTP to gateway call establishment phase, the gateway shall buffer characters received from the IP text Device. Once connected the gateway relays the buffered characters to the PTP. Editor Note: Flow conrol? The Gateway shall perform the required signaling in-line in the PSTN line, to determine the type of PSTN device connected, if any. While negotiating a connecting, the Gateway shall buffer any characters received. These buffered characters shall be transmitted when the gateway is connected to the text phone. The recommended size of the character buffer size the gateway should support enough characters at its advertised maximum character-per-second rate (CPS) for at least 60 seconds. is a matter of implementation, but should support the reception and buffering of characters for at least 60 seconds at the specified maximum character-per-second (CPS) value signaled to the IP text device . [Editor’s Note: Replace this with the one below???If the Gateway does not support the modulation used by the PSTN textphone device, the Gateway may transmit the received textphone signals via Voice Band Data or the audio stream, depending on the capabilities of the IP text device . Further, the Gateway may simply discard characters received from the IP text device or transmit them to the PSTN textphone device using a pre-provisioned modulation ] Procedures for the gateway in the case where it does not support the modulation(s) of PTP it is attempting to connect to are for further study. depending on the capabilities of the IP text device . Further, the Gateway may simply discard characters received from the IP text device or transmit them to the PSTN textphone device using a pre-provisioned modulation.

F.6 Handling of audio The methods how Most text telephones in the PTP manage the text and audio are varied, STN can only handlesome use alternating between use of voice and real-time text, some . Many text telephones can only handletransmit text transmission in one direction at a time. Among text-capable IP Text Ddevices it is normal that bothcan transmit and receive text and voice can be used simultaneously and in both directions at the same time. - 23 - TD 15 (WP 1/16)

When bridging between these two environments, the assumption is that users will accommodate the turn-takingalternating methods in their use of the system schemes must be introduced both by the human users and by the gateways. The following procedures should be applied: F.6.1 Non-constant carrier PTP devices and audio For the non-constant carrier text telephone methodsconnections, audio received from the PTO is transmitted through the gateway between the PSTN circuit andon the the audio stream of the IP text device. If a PTP modulation is detected on the PSTN side the demodulated characters are transmitted to the IP Text device on the text channel. This is done as long as there is no text to transmit or receive on the PSTN side. Text transmission and reception has priority over audio transmission. When text is being transmitted the audio channel shall operate as if there is silence. Initially the audio channel from the IP Text Device is connected to the PSTN, If text is detected from the IP Text Device, the PTP will establish its modulated connection and transmit the received characters per clause F.5. [editor’s note: due to the text and audio streams having different SSRC, the interruption of text on audio may cause interference.] F.6.2 Constant-carrier PTP devices and audio For calls with the constant-carrier based PSTN text telephonePTP types, the recommended procedure is: As long as carrier is maintained from the PSTN side, it is maintained from the gateway, and text transmission can occur. Although no characters may be present. The audio channel from the gateway to the IP Text Device shall behave as though transmitting silence. If carrier is dropped from the PSTN terminal, the gateway shall transmit any remaining characters to the PSTN side and then itself drop carrier and transmit connect the PSTN to the audio channel. When carrier is received again from the PSTN, carrier transmission is also resumed from the gateway and text may be transmitted as described above.. If, during a period of end-to-end audio transmission, text is received from the IP Ttext Ddevice the , audio transmission is interrupted, carrier is re-established and text transmitted. Text having priority over the audio. If, during a period of carrier or text transmission, a ITU-T Recommendation T.140 the Interrupt command (INT) is received in the T.140on the text channel from the IP text device, PTP carrier should shall be dropped and transmission IP Text Deviceof audio through the gateway establishedis connected through the gateway to the PSTN. The IP text device may use the T.140 Interrupt command is used to request audio transmission. In most cases the control of the carrier can be left to the PSTN terminal user.

F.7 Procedures for supporting routing to real-time text capable gateways Elements introduced in the procedures described in this annex are intended to support routing of calls to real-time text capable gateways. The exact routing procedures are outside the scope of this annex. The use of text capabilities and text preferences in the Contact and Accept-contact fields as described above can be used to route calls to text capable gateways according to the procedures described in RFC 3840 and RFC 3841. - 24 - TD 15 (WP 1/16)

ENUM can be used to support routing of calls to IP devices who have registered interest to have their calls routed through text capable gateways. For the configuration cases where the gateway is directly wired to the PSTN device, some support of PTP device communication is needed in the gateway. If that support is not made according to this Annex, the calls may be routed through a second gateway step that supports RFC 4103. Such routing may use the same procedures and invocation methods as described above.

______