Study Group 16 – Question 11
Location: / Washington DC, USA. August 11th – 13th, 2004
Source: / Editor (V.ToIP)
Title: / Consensus Points and Questions for V.ToIP
Contact: / Herb Wildfeur
Cisco Systems
USA / Tel:
Fax:
Email:
ABSTRACT
This document records the consensus points and questions on V.ToIP as agreed at the closing of the June TR30.1 meeting.during the August Q11/16 Rapporteur’s meeting.
Introduction
This document records the agreements that the experts group reach consensus upon concerning the work of V.ToIP. Also contained are questions that will require resolving in the course of the development of this work.
Consensus Points
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 Feb 2004.
1.1.2. The Recommendation will make use of existing standards as appropriate (for example: ITUT, 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.3 The implied version number of V.ToIP will be 0. When or if it becomes necessary The 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.
Question: Does the definition for PSTN Textphone as found in V.18 section 3.7 (included below) be 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.
1,8 V.ToIP shall where appropriate provide the strongest encouragement to use this standard.
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.
Figure 1: Reference Diagram for a Text-over-IP Network Architecture2.4.1 The inter-working between Gateway and IP Text telephone could be defined in an annex to V.ToIP. This Annex is under study. (More information is needed upon the protocols being used in IP Text telephone endpoints).
2.5 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.6 There should be a goal to define procedures and mechanisms for the I1 to G2 scenario in this Recommendation.
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 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 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. The CER shall be less than 1%. The delay shall be such that the end-to-end delay shall meet the requirements specified in G.114.
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 demodulator over a perfect network shall be < 0.01%. (Note this % has to be verified).
2.13 This consensus point is being changed. 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).
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), how does the gateway switch back to ToIP (or VBD)? (See Appendix III). (This question will be moved to MoIP issues list. Transitioning out of MoIP to ToIP will be defined in Appendix IV of V.150.1)
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.
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 2793 shall be the default Text Relay transport.
3.3.1. RFC 2793 is being 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 2793 bis’ 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.5 The use of RFC 2198 and RFC 2733 shall be a supported capability of a V.ToIP gateway but can be optionally enabled., where applicable, shall not be mandated, but encouraged in V.ToIP. An appendix will be created to either provide appropriate examples or add clarification of the use.
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 cbonnected 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 2793 bis 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%.
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.
3.9 It was felt that ToIP should define procedures for both single and dual UDP port operation.It was agreed that V.ToIP shall define procedures for single port operation. The use of multiple ports is not precluded.
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 2793 bis. 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. 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 RFC2793 bis MIME type audio/t140c shall be supported by ToIP gateways. The RFC 2793 MIME type text/t140c is not precluded so that interoperability with non-V.ToIP devices is stillmay be possible.
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.