ITU - Telecommunication Standardization Sector STUDY GROUP 8 Geneva, 2 _ 10 February 2000 Question: 4/8 SOURCE: CHAIRMAN OF STUDY GROUP 8 TITLE: COMMUNICATION TO ISOC ON IANA REGISTRATIONS FOR REC. T. 38 ANNEX D COMMUNICATION TO: ISOC/IANA APPROVAL: Study Group 8 (2-10 Feb 2000) FOR: Action DEADLINE: 1 March 2000 CONTACT: Glenn Parsons gparsons@nortelnetworks.com Tel: +1-613-763-7582 1. SDP Attribute Name (_att-field_) Registrations To: iana@iana.org Subject: SDP att-field registration Contact Information: Glenn Parsons gparsons@nortelnetworks.com +1-613-763-7582 Information Legend: a) Name as it appears in SDP b) Long form name in English c) Type of attribute (media-level, session-level, or both) d) Subject to charset attribute? e) Specification of appropriate values f) Explanation of purpose of attribute Extension Attributes: 1) a) T38FaxVersion b) T.38 Version c) media-level d) no e) 1*(DIGIT) version 0, the default, refers to T.38 (1998) f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. This is the version number of the T.38 Annex D call = setup. New versions shall be compatible with previous versions. 2) a) T38maxBitRate b) Maximum Bit Rate c) media-level d) no e) 1*(DIGIT) f) Indicates the maximum Rec. T.38 bit rate for the session 3) a) T38FaxFillBitRemoval b) Fill Bit Removal c) media-level d) no e) none (boolean) f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. Indicates the capability to remove and insert fill = bits in Phase C, non-ECM data to reduce bandwidth in the packet network. See Note below. 4) a) T38FaxTranscodingMMR b) MMR Transcoding c) media-level d) no e) none (boolean) f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. 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. See Note below. 5) a) T38FaxTranscodingJBIG b) JBIG Transcoding c) media-level d) no e) none (boolean) f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. It indicates the ability to convert to/from JBIG to = reduce bandwidth. See Note below. 6) a) T38FaxRateManagement b) Data Rate Management Method c) media-level d) no e) localTCF | transferredTCF f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. There are two methods of handling the TCF signal = for determining the high speed data rate. Either of these methods insures that both the PSTN facsimile sessions be conducted at the same speed. The localTCF value for this attribute requires that the TCF signal = be generated locally by the receiving gateway. Data rate = management is performed by the emitting gateway based on training results = from both PSTN connections. When a CFR (Confirmation to receive) or and = FTT (Failure to train) is received from the Group 3 Fax Equipment (G3FE) at the receiving gateway, a T.30 HDLC packet (indicating = CFR or FTT respectively) should be forwarded to the emitting gateway. According to the result of the TCF received from a G3FE and the = T.30 HDLC packet (CFR or FTT) forwarded from a receiving gateway, an emitting gateway transmits either FTT or CFR according to a table (Table 6 found in ITU-T Rec. T.38). This option is used for TCP implementations and is optional for UDP implementations. The transferredTCF value requires the TCF be transferred from the sending G3FE to the receiving G3FE rather than having the = receiving gateway generate it locally. Speed selection is done by the G3FEs = in the same way as they would on a regular PSTN connection. This = option is mandatory for use with UDP and is not recommended for use with TCP. 7) a) T38FaxMaxBuffer b) Maximum Buffer Size c) media-level d) no e) 1*(DIGIT) ;optional f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. For UDP mode, 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. 8) a) T38FaxMaxDatagram b) Maximum Datagram Size c) media-level d) no e) 1*(DIGIT) ;optional f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. This option indicates the maximum size of a UDPTL packet that can be accepted by the remote device. 9) a) T38FaxUdpEC b) Error Correction c) media-level d) no e) t38UDPFEC | t38UDPRedundancy f) This attribute is specified for use with ITU-T Recommendation T.38 Annex D. During H.323 capabilities exchange, a gateway shall indicate its support of the available error protection schemes, parity FEC, or redundancy. If a capability is indicated to receive both parity error correction frames and redundant frames, then either scheme = may be used. If, however, a gateway indicates a capability to receive only redundant error protection frames, then the transmitting gateway may not send parity FEC frames. For the t38UDPRedundancy value: The IFP packet in a UDPTL payload = is referred to as the "primary". As packets, and therefore primaries, = are assigned unique and linearly increasing sequence numbers, receiving gateways can detect packet loss and re-sequencing requirements. By imposing a simple structure it is possible to provide error recovery by means of transmitting redundant information in the form of prior primary packets within each payload. The strategy used is to assemble an additional n prior packets after the primary with monotonically decreasing sequence numbers. Thus, should each payload contain a primary and two or = more secondary fields, a loss of two consecutive UDPTL packets will be protected against. In order to provide a redundancy service in the = UDPTL, it is necessary to maintain a buffer of "old" primaries for = assembly into new packets. For the t38UDPFEC value: An FEC contains a parity encoded representation of a number of primaries. The number of primary IFP = packets represented by an FEC field is given by an element (fec-n- packets) of the UDPTLPacket. 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. (taken from Rec. T.38 Annex B, Table = B-1.) 2. SDP Protocol _proto_ Registrations To: iana@iana.org Subject: SDP proto registration Contact Information: Glenn Parsons gparsons@nortelnetworks.com +1-613-763-7582 Name as appears in SDP: UDPTL Long-form English name: User Datagram Protocol Transport Layer Type of name: proto Explanation of Purpose of registered name: Previously only UDP was indicated as the transport for T.38, this = is an error as the transport described in Rec. T.38 is UDPTL. Reference to specification of the registered name: ITU-T Rec. T.38 Section 9 To: iana@iana.org Subject: SDP proto registration Contact Information: Glenn Parsons gparsons@nortelnetworks.com +1-613-763-7582 Name as appears in SDP: TCP Long-form English name: Transmission Control Protocol Type of name: proto Explanation of Purpose of registered name: Only UDP is defined as a transport protocol in SDP. However, some = applications (like ITU-T Rec. T.38) require the option of TCP transport. Reference to specification of the registered name: RFC 793 _ Transmission Control Protocol 3. SDP Protocol _fmt_ Registration To: ietf-types@iana.org Subject: Registration of MIME media type image/t38 MIME media type name: image MIME subtype name: t38 Required parameters: none Optional parameters: none Encoding considerations: no appropriate file format Security considerations: None known Interoperability considerations: This is not intended to be used as a MIME type in email, but as part of an SDP message. Published specification: ITU-T Rec. T.38 This format is described in Annex D of T.38 Applications which use this media type: Primarily T.38 real time fax call establishment Additional information: None. Person & email address to contact for further information: Glenn Parsons Gparsons@nortelnetworks.com Intended usage: COMMON Author/Change controller: Glenn Parsons