(TIA)
Lake Buena Vista, FL December 6-7, 2006
DOCUMENT SUBMITTED TO
TR-30.1 Meeting
The document to which this cover statement is attached is submitted to a Formulating Group or sub-element thereof of the Telecommunications Industry Association (TIA) in accordance with the provisions of Sections 6.4.1-6.4.6 inclusive of the TIA Engineering Manual dated March 2005, all of which provisions are hereby incorporated by reference.SOURCE: Editor, TIA-1001-A
CONTACT: Fred Lucas
FAL Associates
Telephone: 410-239-0248
Email:
TITLE: Proposed new Annex text for TIA-1001-A
PROJECT: PN-3-0098-RV1
DISTRIBUTION: Members of TR-30.1
INTENDED PURPOSE OF DOCUMENT: / _X__ / FOR INCORPORATION INTO A TIA PUBLICATION____ / FOR INFORMATION ONLY
____ / OTHER (please describe):
______
ABSTRACT
This document is proposed text for inclusion in an Annex of TIA-1001-A. It is based upon TR-30.1/06-12-075. The proposed text is a result of discussions which took place during the December 2006 TR-30.1 meeting.
Payload Format and Signaling Syntax for Real-Time Text Transported within
an Audio Stream
_.1 Overview
This Annex defines the payload type, payload format specification, and SDP syntax necessary to transport real-time text over IP networks within an audio stream. The payload format for these packets utilizes ITU-T Recommendation T.140 for the character encoding, while transmitting said characters through an audio stream switched with voice packets.
_.2 Payload format
When transporting real-time text within an audio steam, text packets are differentiated from audio packets, SSE messages, DTMF signals, or other packets by the payload type value negotiated during session establishment or when the session is later modified. Text packets shall be assigned a payload type value that allows the endpoint to unambiguously recognize text packets from other packets transmitted within the audio stream.
The real-time text packets shall utilize T.140 for character encoding, transported using the Real-Time Transport Protocol (RTP), and shall be encoded as shown in Figure _.1.
Figure _.1 – Payload Format
The definition of the first 3 octets is found in Section 5.1 of RFC 3550. Implementations shall adhere to the following usage of these fields:
This M-bit shall be set to ‘1’ for the initial packet transmitted for any given SSRC value presented on the wire and shall be set to ‘1’ following a period of ‘silence’ where no RTP packets are transmitted. In all other cases where packets are transmitted successively, this bit shall be set to ‘0’. A period of ‘silence’ is defined to be more than 300ms without transmitting a packet.
The Payload Type (PT) field shall contain a dynamic payload type value negotiated by the two endpoints.
The Sequence Number and Timestamp fields shall increase in accordance with RFC 3550. The SSRC used for text shall be the same SSRC value as used for other audio, allowing for synchronized interleaving of audio and text. This means that the clock rate used for audio transmission will be the same rate as used for text packets.
The actual payload of the RTP packet is comprised of a T.140 Block Counter and zero or more T.140-encoded data elements. Those two components of the payload are described in the following Clauses.
_.2.1 T.140 Block Counter
The T.140 Block Counter is similar in purpose to the Sequence Number and is necessary since text packets and audio packets share the same sequence number space. Without this counter, it would not otherwise be possible to detect lost text packets.
The T.140 Block Counter shall be initialized to zero for the first text packet transmitted and, once passing the value 0xFFFF, shall be reset to zero.
Devices that receive a text packet containing a T.140 Block Counter that has incremented higher than expected shall assume that the difference between the recently received counter value and the expected counter value indicates the number of lost text packets. Note, however, that there may multiple characters within a text packet, so this does not serve to indicate the number of lost characters.
_.2.2 T.140-Encoded Data Block
The T.140-encoded data block (“T.140 block”) contains text information as described in Recommendation T.140. The contents of this field shall be UTF-8 encoded and shall include no extra framing.
It should be noted that, in most cases, this field is comprised of one or more text characters. However, it is permissible to have zero characters for the purpose of enabling transmission of redundant data packets. It should also be noted that, while most elements within this field constitute single characters, some elements are multiple-character sequences. Any composite character sequence (CSS) elements should be placed in a single RTP packet.
_.3 H.323 Signaling Capability Definitions
The following generic capability is defined for the transport of text within an audio channel.
Capability name: / T140AudioCapability class: / Audio Capability
Capability identifier type / Standard.
Capability identifier value / itu-t (0) recommendation (0) h (8) 323 annex(1) g (7) audio(0)
maxBitRate / The maxBitRate field shall be included and indicate the maximum bits per second. When using the Flow Control Command or other signals in relation to this capability, any maxBitRate field shall be interpreted to be in units of bits/sec, as opposed to the typical 100bits/sec used in H.245. This is due to the low bit rate nature of real-time text communication, including the low bit rates used by many PSTN textphone protocols.
nonCollapsing / This field shall not be included and shall be ignored if received.
nonCollapsingRaw / This field shall not be included and shall be ignored if received.
transport / This field shall not be included.
_.3.1 Characters per Second Generic Parameter
When using the generic audio to signal text, an endpoint may also advertise, either in the terminal capability set, the Open Logical Channel, or both, the capability to receive a specified number of characters per second. This parameter is defined is signaled as follows:
Parameter name: / cpsParameter description: / This is a collapsing capability.
Indicates the maximum number of characters per second that may be received on a session. When carried inside an OLC, it indicates the maximum transmission rate that the other endpoint may use if it opens a corresponding text session.
Parameter identifier value: / standard: 0
Parameter status: / Optional
Parameter type: / unsignedMin
Supersedes: / -
Devices in receipt of this parameter shall adhere to the request by transmitting characters at a rate at or below the specified <unsignedMin> value. In absence of this parameter, devices shall not transmit more than 30 characters per second.
_.4 SDP Syntax and Semantics
This section defines the Session Description Protocol (SDP) syntax used to signal support for real-time text transmission through the audio stream and the associated semantics of the syntax.
Text is represented as an “audio” MIME type in SDP and is identified by “audio/t140c”.
_.4.1 CPS
In some cases, it is necessary to limit the rate at which characters are transmitted. For example, when a PSTN gateway is interworking between an IP device and a PSTN textphone, it may be necessary to limit the character rate from the IP device in order to avoid throwing away characters in case of buffer overflow at the PSTN gateway.
To control the character transmission rate, the MIME parameter "cps" in the "fmtp" attribute is defined. It is used in SDP with the following syntax:
a=fmtp:<format> cps=<integer>
The <format> field is populated with the payload type that is used for text. The <integer> field contains an integer representing the maximum number of characters that may be received per second. The value shall be used as a mean value over any 10 second interval.
Devices in receipt of this parameter shall adhere to the request by transmitting characters at a rate at or below the specified <integer> value. In absence of this parameter, devices shall not transmit more than 30 characters per second.
_.4.2 SDP Examples [Editors Note: This section may be redundant with Annex B]
Below is an example of SDP describing RTP text interleaved with G.711 audio packets within the same RTP session from port 7200 and at a maximum text rate of 6 characters per second:
m=audio 7200 RTP/AVP 0 98
a=rtpmap:98 t140c/8000
a=fmtp:98 cps=6
Below is an example using RFC 2198 to provide the recommended two levels of redundancy to the text packets in an RTP session with interleaving text and G.711 at a text rate no faster than 20 characters per second:
m=audio 7200 RTP/AVP 0 98 100
a=rtpmap:98 t140c/8000
a=fmtp:98 cps=20
a=rtpmap:100 red/8000
a=fmtp:100 98/98/98