DOC

50304013doc - Draft T38 (2002) Recommendation

By Rick James,2014-10-29 15:09
9 views 0
50304013doc - Draft T38 (2002) Recommendation

Telecommunications Industry Association TR-30.5/03-04-013

    (TIA)

    Arlington, VA April 7 8, 2003

    COMMITTEE CONTRIBUTION

    Technical Committee TR-30 Meetings

SOURCE: Cisco Systems, Inc.

CONTACT: Paul E. Jones

     Tel: +1 919 392 6948

     Email: paulej@packetizer.com

     Mehryar Garakani

     Tel: +1 805 961 3640

     Email: mgarakan@cisco.com

     Rajesh Kumar

     Tel: +1 408 527 0811

     Email: rkumar@cisco.com

    TITLE: Proposed draft amendment to ITU Recommendation T.38 to support optional RTP

    encapsulation

PROJECT:

DISTRIBUTION: Members of TR-30.5

    ____________________

    ABSTRACT

    This contribution proposes a draft amendment to the ITU Recommendation T.38 to support optional RTP encapsulation when using UDP transport. The optional RTP encapsulation is used when both gateways indicate this capability during call setup. The contribution includes encapsulation of IFP when using UDP/RTP. Also included is the use of redundancy and FEC in the context of UDP/RTP. Annex B and Annex D are updated to include negotiation of a RTP-based T.38 capability. All modifications are shown with respect to ITU-T Rec. T38 (04/2002) and marked with change bars with respect to this base document.

    1 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

1 Introduction

    This contribution proposes a draft amendment to the ITU Recommendation T.38 to support optional RTP encapsulation when using UDP transport. The optional RTP encapsulation is used when both gateways indicate this capability during call setup. The contribution includes encapsulation of IFP when using UDP/RTP. Also included is the use of redundancy and FEC in the context of UDP/RTP. Annex B and Annex D are updated to include negotiation of a RTP-based T.38 capability. All modifications are shown with respect to ITU-T Rec. T38 (04/2002) and marked with change bars with respect to this base document.

     Amendments to Rec. T.38 2

    2.1 Amendments to Section 2 Normative references

Add the following references to Section 2:

RFC 1889, RTP: A Transport Protocol for Real-Time Applications.

     RFC 2198, RTP Payload for Redundant Audio Data.

     RFC 2773, An RTP Payload Format for Generic Forward Error Correction.

2.2 Amendments to Section 4 Abbreviations

Add the following abbreviations to Section 2:

    RTP Real Time Protocol

    FEC Forward Error Correction

2.3 Amendments to Section 7.1.3 IFP Packet Layers for TCP/IP and UDP/IP

Amend section 7.1.3 as follows:

7.1.3 IFP Packet Layers for TCP/IP and UDP/IP

    The IFP packets described in 7.2 are combined with the appropriate headers for TCP/IP and

    UDP/IP as shown in Figures 4, 5 and 6.

    . To provide interoperability in H.323 environments, the TPKT header defined in RFC1006 shall

    precede the IFP Packet in TCP implementations as shown in Figure 4. Implementations using

    TPKT shall set the version to 1 or higher.

    Note: Implementations of T.38 with TCP/IP transport prior to version 1 were not required to

    support the TPKT facility.

    For the UDP transport, IFP data may be encapsulated in UDPTL, as shown in Figure 5, or

    alternatively encapsulated in RTP, as shown in Figure 6.

    3 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

    In Figure 5, the UDPTL header represents the additional header information required for error control over UDP. When UDPTL encapsulation is used, the payload structure is as defined in Annex A for UDPTLPacket.

    RTP encapsulation of T.38 facsimile signals may only be used if both gateways negotiate this capability during call setup. This negotiation is described in Annex B or Annex D. With RTP encapsulation, the optional redundancy and FEC mechanisms described in RFC 2198 and RFC 2733 may be used.

    Figure 6 represents the packet structure when optional RTP encapsulation is used. Within an RTP packet, an IFP packet may be optionally combined with a redundant IFP packet (RFC 2198) or with a FEC packet (RFC 2733 and RFC 2198). Another valid RFC 2733 option, not shown in Figure 6, allows FEC packets to be sent as a separate RTP stream rather than being combined with IFP packets into RTP packets. The RTP payload corresponds to a single IFP packet when RFC 2198 is not used to combine it with a redundant IFP packet or with a FEC packet.

     a) Layered model TPKT header IFP Packet ofIFP/TCP/IP packet

    TCP payload TCP header

    IP header IP payload

    b) Flat model of IFP/TCP/IP protocol

    TPKT header IP header TCP header IFP Packet

    T0827900-98/d05

    Figure 4/T.38 High-level TCP/TPKT/IP Packet Structure

    a) Layered model UDPTL header UDPTL payload = IFP Packet + Redundancy/FEC ofIFP/ UDPTL/UDP/IP packet

    UDP payload UDP header

    IP header IP payload

    b) Flat model of IFP/UDPTL/UDP/IP protocol

    IP header UDP header UDPTL header IFP Packet + Redundancy/FEC

    T0827900-98/d05

     Figure 5/T.38 High-level UDPTL/UDP/IP packet structure

    4 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

a) Layered model RTP header RTP payload = IFP Packet + Redundancy*/FEC** ofIFP/RTP/UDP/IP packet

    UDP payload UDP header

    IP header IP payload * = Redundancy per RFC 2198

    ** = FEC per RFC 2733

    b) Flat model of IFP/RTP/UDP/IP protocol

    IP header UDP header RTP header IFP Packet + Redundancy*/FEC**

    T0827900-98/d05

     Figure 6/T.38 High-level RTP/UDP/IP packet structure

2.4 Rename Section 9

    9 IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP

2.5 Rename Figure 6 in Section 9.3

    Rename Figure 6 and references made to it in Section 9.3 to Figure 7. 2.6 Rename Figure 7 in Section 9.4.1

    Rename Figure 7 and references made to it in Section 9.4.1 to Figure 8. 2.7 New Section 10

    10 IFT over UDP transport using RTP protocol: IFT/RTP/UDP

    For UDP transport, the RTP protocol (RFC 1889) may be used as an alternative to UDPTL. The

    RTP protocol is used when both gateways negotiate this capability during call setup. This negotiation

    is described in Annex B or Annex D.

    Additional capabilities available to RTP streams may optionally be used as long as these are declared

    by both gateways. These include redundancy (RFC 2198) and FEC (RFC 2733).

    5 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

    There are a few differences which must be considered when using RTP instead of UDPTL. These

    differences result from differences in the payload format and operational procedures for RTP and

    UDPTL. Along with the similarities between these formats, these differences are highlighted in Table

    7.

    Table 7/T.38 Similarities and Differences between RTP and UDPTL

    Feature UDPTL mechanism RTP mechanism

    Payload Format Without redundancy and UDPTLPacket specified in

    FEC, RTP payload is a single Annex A

    IFP packet.

    When FEC packets constitute

    a separate stream (RFC

    2733), the RTP payload is a

    single IFP packet.

    With RFC 2198-based

    redundancy, the RTP payload

    structure is as specified in

    RFC 2198.

    With FEC that uses RFC

    2198 encapsulation, the RTP

    payload structure is as

    specified in RFC 2733 and

    RFC 2198.

    Negotiation necessary to use In order to be used, the In order to be used, the RTP-

    RTP or UDPTL protocol UDPTL-based T.38 based T.38 capability must

    capability must be proposed be proposed by one gateway

    by one gateway and and selected/accepted by the

    selected/accepted by the other gateway. The capability

    other gateway. The capability declaration and selection

    declaration and selection procedures are per Annexes B

    procedures are per Annexes B and D.

    and D.

    Payload Sequencing UDPTL sequence number RTP sequence number

    Redundancy Uses mechanism defined in RFC 2198

    Section 9

    FEC Uses mechanism defined in RFC 2733, with or without

    Annex C RFC 2198 encapsulation

    2.8 Amendments to Annex B Section B.3.1.2 Media channels

    Amend section B.3.1.2 as follows:

    6 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

B.3.1.2 Media channels

    ITU-T Rec. H.225.0 requires that T.38 facsimile packets are sent on a separate TCP/UDP port from H.225.0 call signalling (TCP). All required ports are established during the initial fastStart exchange.

    A minimal T.38 Annex B implementation requires a TCP port for call signalling and either a UDP port for UDPTL, two UDP ports for RTP (one for RTP and one for RTCP), or a TCP port for T.38 facsimile information.

2.9 Amendments to Annex B Section B.3.3 Capabilities negotiation

    Amend section B.3.3 as follows:

    B.3.3 Capabilities negotiation

    There are several options that need to be negotiated to determine which options the gateways support and use. See Table B.1.

    Table B.1/T.38 Gateway option capability support indications

    Option Description

    Data rate management Method 1, local generation of TCF is required for use with TCP. Method 2, method transfer of TCF is required for use with UDP (UDPTL or RTP). Method 2 is

    not recommended for use with TCP.

    Data transport protocol The emitting gateway may indicate a preference for either UDP (UDPTL or

    RTP), or TCP for transport of T.38 IFP-Packets. The receiving device selects

    the transport protocol.

    Fill bit removal Indicates the capability to remove and insert fill bits in Phase C, non-ECM

    data to reduce bandwidth in the packet network. Optional. See Note.

    MMR transcoding Indicates the ability to convert to/from MMR from/to the line format for

    increasing the compression of the data and reducing the bandwidth in the

    packet network. Optional. See Note.

    JBIG transcoding Indicates the ability to convert to/from JBIG to reduce bandwidth. Optional.

    See Note.

    Maximum buffer size For UDP (UDPTL or RTP) modes, this option indicates the maximum

    number of octets that can be stored on the remote device before an overflow

    condition occurs. It is the responsibility of the transmitting application to

    limit the transfer rate to prevent an overflow. The negotiated data rate should

    be used to determine the rate at which data is being removed from the buffer.

    Maximum datagram size This option indicates the maximum size of a UDPTL packet or the maximum

    size of the payload within an RTP packet that can be accepted by the remote

    device.

    Version This is the version number of ITU-T Rec. T.38. New versions shall be

    compatible with previous versions.

    NOTE Bandwidth reduction shall only be done on suitable Phase C data, i.e. MH, MR and in the case of transcoding to JBIG

     MMR. MMR and JBIG require reliable data transport such as that provided by TCP. When transcoding is selected, it shall be applied to every suitable page in a call.

    These capabilities are negotiated using the OLC elements as defined in the T38faxProfile of H.245 V10 (ed: or 11?).

    Two unidirectional, reliable or unreliable, logical channels (sender to receiver channel and receiver to sender channel) as shown in Figure B.1 or, optionally, one bidirectional reliable channel as shown in

    7 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

    Figure B.2 shall be opened for the transfer of T.38 packets. T.38 packets can be transferred using either TCP or UDP (UDPTL or RTP). In general, the usage of TCP is more effective when the bandwidth for facsimile communication is limited, or for IAF to IAF transfers since TCP provides flow control. On the other hand, the usage of UDP (UDPTL or RTP) may be more effective when the bandwidth for facsimile communication is sufficient.

    SourceDestinationSending logical channel

    Receiving logical channel

    T1610890-02

    Figure B.1/T.38 A pair of unidirectional channels

    SourceDestinationSending stream

    Receiving stream

    T1610900-02

    Figure B.2/T.38 A single of bidirectional channels

    The sender terminal specifies a TCP/UDP port in the OpenLogicalChannel in the fastStart element

    of Setup. The receiver terminal shall provide its TCP (or UDP) port in the OpenLogicalChannel of

    the fastStart element as specified by the procedures in 8.1.7/H.323: "Fast connect".

    The receiver should open the TCP/UDP port based on the preference of the sender. If the sender terminal has a preference for UDP (UDPTL or RTP) or TCP, then it shall provide its preference in the OpenLogicalChannel with the appropriate port in the fastStart sequence. The receiving terminal

    can select the transport, TCP or UDP (UDPTL or RTP), by specifying one of the two in OpenLogicalChannel structures in the fastStart element of Connect.

    All T.38 Annex B implementations shall include a T38fax OLC with t38FaxUdpOptions and

    transferredTCF and a T38fax OLC with t38FaxRtpOptions and transferredTCF set in the

    fastStart structure, each selecting udp as the t38FaxProtocol choice. Note that all H.323 Annex D

    devices also are required to include these structures. In addition, T.38 Annex B devices shall include

    an OLC with t38FaxTcpOptions and localTCF set and with tcp selected as the t38FaxProtocol

    choice. As described in 8.1.7/H.323, the order in which OLCs are included in the fastStart element

    indicates preference on the part of the sender. The receiver only includes the OLCs that it wishes to use in the fastStart element of the Connect.

    NOTE In the first version of Annex B, it was not possible to use a single bidirectional reliable channel. In order to retain backward

    compatibility, the endpoint may specify support for bidirectional reliable channels by including the t38FaxTcpOptions SEQUENCE

    and setting the t38TCPBidirectionalMode field to TRUE. If the other endpoint does not include the t38FaxTcpOptions

    SEQUENCE, the endpoint shall assume that a single bidirectional reliable channel for T.38 is not supported and shall use either two

    unidirectional reliable or unreliable channels.

    8 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

    2.10 Amendments to Annex B Section B.3.4 Examples of call set-up OLCs Amend section B.3.4 as follows:

    B.3.4 Examples of call set-up OLCs

    The examples in this clause illustrate the OLC elements that are sent in various cases. The rules of 8.1.7/H.323 are followed using OLC definitions in ITU-T Rec. H.245. Refer to ITU-T Rec. H.245 for the relevant ASN.1.

    B.3.4.1 TCP, UDP (UDPTL or RTP) support

    The default case requires support for both TCP and UDP (UDPTL and RTP). In this case, the sender shall send OLCs for T38/TCP&localTCF, T38/RTP&transferredTCF and

    T38/UDPTL&transferredTCF. If the receiver wishes to use UDP, an OLC for

    T38/UDPTL&transferredTCF is returned. If the receiver wishes to use RTP, an OLC for T38/RTP&transferredTCF is returned. Otherwise, the OLC for T38/TCP&localTCF is returned.

    B.3.4.2 UDP (UDPTL or RTP) with data rate management method 1 support For the case where the sender wishes to use data rate management method 1 and UDP (UDPTL or RTP) for data transport, it may send OLCs for T38/UDPTL&transferredTCF,

    T38/UDPTL&localTCF, T38/RTP&transferredTCF, T38/RTP&localTCF,

    T38/TCP&localTCF. If the receiver agrees to use UDPTL&localTCF or RTP&localTCF, an OLC

    for T38/UDPTL&localTCF or T38/RTP&localTCF is returned, respectfully.

    2.11 Amendments to Annex B Section B.3.7 Usage of the maxBitRate in messages Amend section B.3.7 as follows:

    B.3.7 Usage of the maxBitRate in messages

    When TCP is used for T.38 fax transmission, maxBitRate in the ARQ/BRQ does not include the fax

    data rate. When UDP (UDPTL or RTP) is used for T.38 fax transmission, maxBitRate in the

    ARQ/BRQ does include the bit rate needed for the fax session. The endpoint (terminal, gateway) shall send BRQs to the gatekeeper as bandwidth needs change during the call. It is noted that the maxBitRate in the OpenLogicalChannel element in the Setup during fast start is different from the

    maxBitRate in ARQ/BRQ, and does refer to the peak bit rate that the fax call will use.

2.12 Rename Annex C

    Rename Annex C Title as follows:

    The Optional Forward Error Correction Scheme for UDPTL

    2.13 Amendments to Annex D Section D.1 Introduction

    Amend section D.1 by adding the following note.

    Note: RFC 2543 has been obsoleted by RFC 3261.

    2.14 Amendments to Annex D Section D.2.3 Capabilities negotiation

    Amend section D.2.3 as follows:

    9 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

D.2.3 Capabilities negotiation

    There are several capabilities that need to be negotiated to determine which options the gateways

    support and use. These are described in Table B.1/T.38. The IETF RFC 2327 Session Description Protocol (SDP) provides mechanisms for describing

    sessions for SIP. However, new attributes (section 6 of SDP) are required to support ITU-T T.38.

    Specifically, the following options are registered with IANA as valid att-field and att-value values per

    the procedure noted in Appendix B of SDP (IETF RFC 2327). Note that options without values are

    boolean their presence indicates that they are valid for the session. These capabilities are negotiated

    using the following ABNF elements defined for use with ITU-T T.38: Version

     Att-field=T38FaxVersion

     Att-value = 1*(DIGIT)

     ;Version 0, the default, refers to T.38 (1998)

    Maximum Bit Rate

     Att-field=T38MaxBitRate

     Att-value = 1*(DIGIT)

    Fill Bit Removal

     Att-field=T38FaxFillBitRemoval

    MMR Transcoding

     Att-field=T38FaxTranscodingMMR

    JBIG Transcoding

     Att-field=T38FaxTranscodingJBIG

    Data Rate Management Method

     Att-field=T38FaxRateManagement

     Att-value = localTCF | transferredTCF

    UDPTL Options

    Maximum Buffer Size

     Att-field=T38FaxMaxBuffer

     Att-value = 1*(DIGIT)

     ;optional

    Maximum Datagram Size

     Att-field=T38FaxMaxDatagram

     Att-value = 1*(DIGIT)

     ;optional

    Error Correction

     Att-field=T38FaxUdpEC

     Att-value = t38UDPFEC | t38UDPRedundancy

    RTP Options

    Maximum Buffer Size

     Att-field=T38FaxMaxBuffer

     Att-value = 1*(DIGIT)

     ;optional

    10 DRAFT AMMENDMENT TO ITU-T REC. T.38 (04/2002)

Report this document

For any questions or suggestions please email
cust-service@docsford.com