I n t e r n a t i o n a l
T e l e c o m m u n i c a t i o n
U n i o n
ITU-T
T.38
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU
(04/2007)
SERIES T: TERMINALS FOR TELEMATIC SERVICES Facsimile – Group 3 protocols
Procedures for real-time Group 3 facsimile communication over IP networks
ITU-T Recommendation T.38
ITU-T T-SERIES RECOMMENDATIONS TERMINALS FOR TELEMATIC SERVICES Facsimile – Framework Still-image compression – Test charts Facsimile – Group 3 protocols Colour representation Character coding Facsimile – Group 4 protocols Telematic services – Framework Still-image compression – JPEG-1, Bi-level and JBIG Telematic services – ISDN Terminals and protocols Videotext – Framework Data protocols for multimedia conferencing Telewriting Multimedia and hypermedia framework Cooperative document handling Telematic services – Interworking Open document architecture Document transfer and manipulation Document application profile Communication application profile Telematic services – Equipment characteristics Still-image compression – JPEG 2000 Still-image compression – JPEG-1 extensions For further details, please refer to the list of ITU-T Recommendations.
T.0–T.19 T.20–T.29 T.30–T.39 T.40–T.49 T.50–T.59 T.60–T.69 T.70–T.79 T.80–T.89 T.90–T.99 T.100–T.109 T.120–T.149 T.150–T.159 T.170–T.189 T.190–T.199 T.300–T.399 T.400–T.429 T.430–T.449 T.500–T.509 T.510–T.559 T.560–T.649 T.800–T.849 T.850–T.899
ITU-T Recommendation T.38 Procedures for real-time Group 3 facsimile communication over IP networks
Summary This Recommendation defines the procedures to be applied to allow Group 3 facsimile transmission between terminals where in addition to the PSTN or ISDN a portion of the transmission path used between terminals includes an IP network, e.g., the Internet. This revision of ITU-T Recommendation T.38 clarifies H.323, H.248.1, SIP and SDP call establishment and improves the compatibility between T.38 gateways and Group 3 facsimile.
Source ITU-T Recommendation T.38 was approved on 6 April 2007 by ITU-T Study Group 16 (2005-2008) under the ITU-T Recommendation A.8 procedure.
ITU-T Rec. T.38 (04/2007)
i
FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.
NOTE In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http://www.itu.int/ITU-T/ipr/.
© ITU 2008 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.
ii
ITU-T Rec. T.38 (04/2007)
CONTENTS Page 1
Scope ............................................................................................................................
1
2
Normative references....................................................................................................
1
3
Definitions ....................................................................................................................
2
4
Abbreviations................................................................................................................
2
5
Introduction ..................................................................................................................
3
6
Communication between gateways .............................................................................. 6.1 Internet protocol – TCP or UDP..................................................................... 6.2 Gateway facsimile data transfer functions .....................................................
5 5 5
7
IFT protocol definition and procedures ........................................................................ 7.1 General ........................................................................................................... 7.2 IFP packet format ........................................................................................... 7.3 TYPE definitions ............................................................................................ 7.4 The IFP DATA element ................................................................................. 7.5 Limitation of V.21 frame packet size .............................................................
6 6 8 9 11 13
8
IFP message flow for facsimile modulations up to V.17.............................................. 8.1 Data rate management method 1 .................................................................... 8.2 Data rate management method 2 ....................................................................
14 14 14
9
IFT over UDP transport ................................................................................................ 9.1 IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP............. 9.2 IFT over UDP transport using RTP protocol: IFT/RTP/UDP........................
15 15 17
10
Message flow for V.8 signals and Annex F/V.34 facsimile ......................................... 10.1 V.8 negotiation ............................................................................................... 10.2 V.34 data rate management ............................................................................ 10.3 Facsimile mode............................................................................................... 10.4 Compatibility with equipment conforming to prior versions of this Recommendation............................................................................................
18 18 19 21
Annex A – ASN.1 notation ...................................................................................................... A.1 T.38 (2002) ASN.1 notation........................................................................... A.2 T.38 (1998) ASN.1 notation...........................................................................
24 24 25
Annex B – H.323 call establishment procedures ..................................................................... B.1 Introduction .................................................................................................... B.2 Communication between facsimile terminal and gateway............................. B.3 Communication between gateways ................................................................
27 27 27 27
Annex C – The optional forward error correction scheme for UDPTL................................... C.1 Overview of the optional forward error correction mechanism ..................... C.2 Parity encode/decode scheme operation and characteristics ..........................
34 34 34
ITU-T Rec. T.38 (04/2007)
iii
23
Page Annex D – SIP/SDP call establishment procedures ................................................................ D.1 Introduction .................................................................................................... D.2 Communication between gateways ................................................................
39 39 39
Annex E – H.248.1 call establishment procedures .................................................................. E.1 Introduction .................................................................................................... E.2 Communication between gateways ................................................................
49 49 49
Annex F – Interworking procedures: T.38 and V.150.1 in the same gateway......................... F.1 Introduction .................................................................................................... F.2 SSE reason identifier codes for T.38 transition.............................................. F.3 Mode Override from V.34 Group 3 facsimile to standard Group 3 facsimile ......................................................................................................... F.4 External signalling..........................................................................................
59 59 60
Annex G – H.245 Capability Definition for T.38 over RTP....................................................
63
Appendix I – Session examples ............................................................................................... I.1 Session examples............................................................................................ I.2 IAF device ......................................................................................................
65 65 70
Appendix II – Examples of call establishment procedures described in Annex B/T.38 ......... II.1 Sequence examples of call establishment procedures .................................... II.2 Protocol data used in call establishment procedures ......................................
72 72 76
Appendix III – H.248 call establishment procedure examples for facsimile-capable media gateways ....................................................................................................................... III.1 Introduction .................................................................................................... III.2 Examples of call setup....................................................................................
81 81 81
Appendix IV – V.34 session examples .................................................................................... IV.1 V.34 session examples....................................................................................
109 109
Appendix V – T.38 Implementation Guidelines...................................................................... V.1 General issue .................................................................................................. V.2 IAF issues ....................................................................................................... V.3 Call-setup issues ............................................................................................. V.4 Others .............................................................................................................
120 120 121 121 122
iv
ITU-T Rec. T.38 (04/2007)
60 62
ITU-T Recommendation T.38 Procedures for real-time Group 3 facsimile communication over IP network 1
Scope
This Recommendation defines the procedures to be applied to allow Group 3 facsimile transmission between terminals where in addition to the PSTN or ISDN a portion of the transmission path used between terminals includes an IP network, e.g., the Internet. 2
Normative references
The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. –
ITU-T Recommendation F.185 (1998), Internet facsimile: Guidelines for the support of the communication of facsimile documents.
–
ITU-T Recommendation H.225.0 (2003), Call signalling protocols and media stream packetization for packet-based multimedia communication systems.
–
ITU-T Recommendation H.248.1 (2005), Gateway control protocol, Version 3.
−
ITU-T Recommendation H.248.2 (2005), Gateway control protocol: Facsimile, text conversation and call discrimination packages.
–
ITU-T Recommendation H.323 (2003), Packet-based multimedia communications systems.
–
ITU-T Recommendation Q.850 (1998), Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN user part.
–
ITU-T Recommendation T.4 (2003), Standardization of Group 3 facsimile terminals for document transmission.
–
ITU-T Recommendation T.6 (1988), Facsimile coding schemes and coding control functions for Group 4 facsimile apparatus.
–
ITU-T Recommendation T.30 (2005), Procedures for document facsimile transmission in the general switched telephone network.
–
ITU-T Recommendation V.8 (2000), Procedures for starting sessions of data transmission over the public switched telephone network.
–
ITU-T Recommendation V.34 (1998), A modem operating at data signalling rates of up to 33 600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits.
–
ITU-T Recommendation V.150.1 (2003), Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs.
–
ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation.
–
ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002, Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). ITU-T Rec. T.38 (04/2007)
1
–
IETF RFC 768 (1980), User Datagram Protocol.
–
IETF RFC 791 (1981), Internet Protocol – DARPA Internet Program – Protocol Specification.
–
IETF RFC 793 (1981), Transmission Control Protocol – DARPA Internet Program – Protocol Specification.
–
IETF RFC 1006 (1987), ISO transport services on top of the TCP: Version 3.
–
IEFT RFC 2198 (1997), RTP Payload for Redundant Audio Data.
−
IETF RFC 2327 (1998), SDP: Session Description Protocol.
−
IETF RFC 2543 (1999), SIP: Session Initiation Protocol.
–
IETF RFC 2733 (1999), An RTP Payload Format for Generic Forward Error Correction.
–
IETF RFC 2833 (2000), RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
–
IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications.
3
Definitions
Unless otherwise noted, the definitions in ITU-T Rec. F.185 shall apply. This Recommendation defines the following terms: 3.1 emitting gateway: The IFP peer which initiates IFT service for a calling G3FE. It initiates a TCP or UDP connection to a receiving gateway to begin an IFT session. 3.2 receiving gateway: The IFP peer which accepts a TCP or UDP connection from an emitting gateway, providing IFT service to a called G3FE. 3.3 G3 facsimile equipment (G3FE): In this Recommendation, G3FE refers to any entity which presents a communications interface conforming to ITU-T Recs T.30, T.4, and, optionally, T.6. A G3FE may be a traditional G3 facsimile machine, an application with a T.30 protocol engine, or any of the other possibilities mentioned in the network model for IP Facsimile. 4
Abbreviations
This Recommendation uses the following abbreviations: ANSam
amplitude-modulated ANSwer tone
CI
Call Indicator (signal)
CM
Call Menu (signal)
CJ
Call Menu terminator (signal)
ECM
Error Correction Mode
FEC
Forward Error Correction
IAF
Internet-Aware Fax device
IFP
Internet Facsimile Protocol
IFT
Internet Facsimile Transfer
INFOh
Half duplex INFO sequence
IP
Internet Protocol
JM
Joint Menu (signal)
2
ITU-T Rec. T.38 (04/2007)
LSB
Least Significant Bit
MPh
V.34 half-duplex Modulation Parameter sequence
MSB
Most Significant Bit
OLC
Open Logical Channel
RTP
Real Time Protocol
RTCP
Real Time Control Protocol
SUB
Sub-address
TCF
Training check
TCP
Transmission Control Protocol
TPKT
Transport Protocol Data Unit Packet
UDP
User Datagram Protocol
UDPTL
Facsimile UDP Transport Layer (protocol)
5
Introduction
The availability of IP networks such as the Internet for international communication provides the potential for utilizing this transmission medium in the transfer of Group 3 facsimile messages between terminals. Since the characteristics of IP networks differ from those provided by the PSTN or ISDN, some additional provisions need to be standardized to maintain successful facsimile operation. The protocol defined in this Recommendation specifies the messages and data exchanged between facsimile gateways and/or IAFs connected via an IP network. The reference model for this Recommendation is shown in Figure 1. This model shows a traditional Group 3 facsimile terminal connected to a gateway emitting a facsimile through an IP network to a receiving gateway which makes a PSTN call to the called Group 3 facsimile equipment. Once the PSTN calls are established on both ends, the two Group 3 terminals are virtually linked. All standard T.30 session establishment and capabilities negotiation is carried out between the terminals. For non-V.34 G3FEs, TCF is either generated locally or transferred between the terminals, depending on the mode of operation to synchronize modulation rates between the gateways and G3FEs. An alternate scenario would be a connection to a facsimile-enabled device (for example, a PC) which is directly connected to an IP network. In this case, there is a virtual receiving gateway as part of the device's facsimile-enabling software and/or hardware. In other environments, the roles could be reversed, or there might be two facsimile-enabled network devices. The protocol defined by this Recommendation operates directly between the emitting and receiving gateways. Communication between the gateways and facsimile terminals and/or other devices is outside the scope of this Recommendation. The protocol defined in this Recommendation was chosen on the basis of efficiency and economy. For optimum performance, the IP transmission paths should have reasonably low delays to meet the F.185 requirements. Good image quality is provided by error control in the network in addition to the means provided by the T.30 protocol. Reliable data transport is provided in two ways: by using TCP over IP networks, or by using UDP over IP networks with optional means for error control.
ITU-T Rec. T.38 (04/2007)
3
Three call control protocols are supported: H.323, SIP, and H.248. H.323 systems may utilize either method as described in Annex D/H.323. These environments are being used to support voice transmission over IP as an alternative to the PSTN. Since facsimile generally uses the same facilities as voice communications, it may be desirable to utilize these environments when implementing facsimile over IP.
Figure 1 – Model for facsimile transmission over IP Networks Under some circumstances it may be necessary to make some adjustments to the procedures between the gateway and the Group 3 terminal. Any such adjustments should not go beyond those available in the T.30 protocol. These adjustments are implementation-dependent. The protocol defined in this Recommendation focuses on the interval where a network connection has been established between two peers (gateway or IAF) implementing the Real-Time Facsimile document transfer over Internet Protocol. Management issues, such as directory services (converting PSTN numbers to IP addresses when required), network hunting, user authentication and CDR (Call Detail Record) collection and network management (SNMP or others) are important but are not addressed in this Recommendation. Standardization of these issues will allow the implementation of a network based on third party management devices, including sharing such devices with other Internet gateways such as Internet telephony and video, remote access and e-mail. In addition, user interface aspects, such as the way that the facsimile operator selects the PSTN number of the destination or identifies himself to the system (for security purposes) are also not in the scope of this Recommendation. However, it is reasonable to assume that the facsimile operator uses the Group 3 terminal equipment keypad (using DTMF signals) or the IAF keyboard to provide the gateway with the required information. Some of these issues mentioned here are being addressed in other ITU-T and IETF Recommendations. Specifically, ITU-T Recs H.323/H.225.0, H.248, and SIP and the Gatekeeper/Call Agent Recommendations address some of the above-mentioned dependencies.
4
ITU-T Rec. T.38 (04/2007)
It is intended that all procedures in this Recommendation conform to the requirements of ITU-T Rec. F.185. The main body of this Recommendation describes the protocol and communication procedures between the emitting gateway and the receiving gateway. Communication between the gateways and the calling and called G3FEs as well as call control procedures are described in Annexes B, D, E, and F. T.38 ASN.1 version numbers ASN.1 version
Version-dependent content summary
Original documentation
0
1998 ASN.1 syntax
Initial publication (1998), Amendment 1 (1999), Amendment 2 (02/00)
1
1998 ASN.1 syntax, TPKT, IAF support
Amendment 3 (11/00) NOTE – Some early implementations supporting TPKT indicate version 0.
2
2002 ASN.1 syntax
3
V.34, V.33 support, 2002 Syntax extended
Updated Recommendation (2002)
The T.38 version number is a mandatory attribute (see Table B.1) that shall be exchanged between the emitting and receiving gateways. An endpoint shall signal the version that it supports in the T38Version attribute in its offer. The recipient of the offer shall accept that version or modify the version attribute to be an equal or lower version when transmitting an answer to the initial offer. The recipient of an offer shall not respond with an answer containing a higher version than that which was offered. Early implementations of T.38 equipment may not provide a T.38 version number. In receipt of SDP without the version attribute, the endpoint shall assume that the version is 0. Version 0 devices are recommended to explicitly advertise their version. 6
Communication between gateways
6.1
Internet protocol – TCP or UDP
The public Internet service provides two principal modes of data transmission: • TCP (Transmission Control Protocol) – A session-based, confirmed delivery service; • UDP (User Datagram Protocol) – Datagram service, non-confirmed delivery. This Recommendation allows the use of either TCP or UDP depending on the service environment. It defines a layered protocol such that the T.38 messages exchanged for TCP and UDP implementations are identical. 6.2
Gateway facsimile data transfer functions
The emitting gateway shall demodulate the T.30 transmission received from the calling terminal. The T.30 facsimile control and image data shall be transferred in an octet stream structure using the IFP packets, over a transport protocol (TCP or UDP). The following signals are not transferred between gateways but are generated or handled locally between the gateway and the G3FE: CNG, CED, and in one mode, TCF. The gateways may indicate the detection of the tonal signals CNG and CED so that the other gateway can generate them.
ITU-T Rec. T.38 (04/2007)
5
The receiving gateway shall decode the transferred information and establish communication with the called facsimile terminal using normal T.30 procedures. The receiving gateway shall forward all relevant responses from the called terminal to the emitting gateway. The facsimile data transfer structure is described in 7.1.3. The flow between gateways is described in clause 8. 6.2.1
Treatment of non-standard facilities requests
The emitting gateway may optionally ignore NSF, NCS and NSS, take appropriate action or pass the information to the receiving gateway. The receiving gateway may optionally ignore NSF, NCS and NSS or take appropriate action including passing the information to the receiving G3FE. Information in other frames related directly to these frames may be altered by the gateway. 7
IFT protocol definition and procedures
7.1
General
This clause contains the textual description of the IFT protocol. The IFT protocol is specified by the ASN.1 description in Annex A. In the case of a conflict between the ASN.1 and the text, the ASN.1 governs. The ASN.1 encoding in Annex A should employ the BASIC-ALIGNED version of Packed Encoding Rules (PER) according to ITU-T Rec. X.691 | ISO/IEC 8825-2:2002. 7.1.1
Bit and octet transmission order
Transmission order is as defined in RFC 791 "Internet Protocol", quoted herein as reference: – The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. 0 0
1
2
3
4
5
6
7
8
9
1 0
1 5 9
1
2
3
4
5
6
7
8
2 6 10
9
2 0
1
2
3
4
5
6
3 7 11
7
8
9
3 0
1
4 8 12
Figure 2 – Transmission order of octets (based on RFC 791, Figure 10) –
Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. This is, the bit labelled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). 0 1
1 0
2 1
3 0
4 1
5 0
6 1
7 0
Figure 3 – Significance of bit (based on RFC 791, Figure 11) –
6
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.
ITU-T Rec. T.38 (04/2007)
7.1.2
Mapping of the T.30 bit stream
The T.30 bit stream is mapped so that bit order is maintained between the PSTN and IP networks. This means that the first bit transmitted is stored in the MSB of the first octet, where the MSB is defined as in 7.1.1. 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. In Figure 4, the UDPTL header represents the additional header information required for error control over UDP. The TPKT header defined in RFC 1006 shall precede the IFP Packet in TCP implementations as shown in Figure 4. Implementations using TPKT shall set the version to 1 or higher. Version 0 implementations shall not use TPKT.
Figure 4 – High-level TCP/TPKT/IP packet structure 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. 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. UDPTL header
UDP payload
UDP header
IP header
UDPTL payload = IFP packet + Redundancy/FEC
IP Payload a) Layered model of IFP/UDPTL/UDP/IP packet
IP header
UDP header
UDPTL Header
IFP packet + Redundancy/FEC T.38_F5
b) Flat model of IFP/UDPTL/UDP/IP protocol
Figure 5 – High-level UDPTL/UDP/IP packet structure
ITU-T Rec. T.38 (04/2007)
7
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 Annexes B, D, E, or Annex D/H.323. 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.
Figure 6 – High-level RTP/UDP/IP packet structure 7.2
IFP packet format
In the following discussion, a message is the protocol or data information transferred in one direction from a G3FE to or from a gateway during a single period. It may include, for example, one or more HDLC frames, or a "page" of Phase C data. Messages may be sent across the IP network in multiple packets. The packets may, for example, contain partial or full, singular or multiple HDLC frames. Support for multiple packets is provided in this protocol. The DATA element uses Fields to support partial and full HDLC frames. IFP operates (listens) over TCP/IP or UDP/IP using a port determined during call setup. All communication between IFP Peers is done using packets, identified as IFPPackets. Table 1 summarizes the IFP Packets (for full explanation, refer to the following subclauses). Table 1 – IFP packet elements
7.2.1
Field
Description
TYPE
Type of message
DATA
Dependent on TYPE
T.38 packet
The T.38 packet element provides an alert for the start of a message. It is used by the IFP peer to verify message alignment. It is identified by an ASN.1 Application tag. When data is read by the peer from its TCP/IP or UDP/IP stack, and the expected tag is not present, the session should be immediately aborted by the receiver. 8
ITU-T Rec. T.38 (04/2007)
7.2.2
TYPE
The TYPE element describes the function of, and optionally the data of, the packet. The legitimate TYPEs are given in Table 2. Each TYPE is separately explained in the following subclauses. The table also indicates whether the TYPEs are Mandatory or Optional for implementations using TCP and UDP. If the TYPE element is not recognized, it and the related data element shall be ignored. Table 2 – IFP packet TYPE field TYPE
DATA Type
Mandatory
T30_INDICATOR
Regular
Yes
Carries indication about the presence of a facsimile signal (CED/CNG), preamble flags or modulation indications
Field
Yes
T.30 HDLC Control and Phase C data (e.g., T.4/T.6 image segment)
T30_DATA
Description
NOTE – If both G3FE devices are identified via DIS/DCS exchange as Internet-aware fax (IAF) devices, the use of T30_INDICATOR is optional.
7.2.3
DATA-Field
The DATA-Field element contains the T.30 HDLC control data and the Phase C image (or BFT) data. The structure of the DATA-Field is defined in 7.4. The structure carries the modulation data as well as indicators for the end of an HDLC frame, the status of the Frame Check Sequence (FCS) for an HDLC frame, and whether the data represents the end of a message. 7.3
TYPE definitions
The following subclauses describe the message TYPEs. 7.3.1
T30_INDICATOR
The T30_INDICATOR TYPE is used by the gateways to indicate the detection of signals such as CED, HDLC preamble flags, and modem modulation training. It is sent by the receiving gateway to the emitting gateway, and by the emitting gateway to the receiving gateway. The use of this message is mandatory, except in the case where both G3FE devices are identified via DIS/DCS exchange as Internet-aware fax devices. A peer may send this message in order to notify its peer about upcoming messages. The T30_INDICATOR TYPE has one of the following values (see Table 3):
ITU-T Rec. T.38 (04/2007)
9
Table 3 – Listing of T30_INDICATOR values Signal/Indication No signal CNG (1100 Hz) CED (2100 Hz) V.21 preamble V.27 2400 modulation training V.27 4800 modulation training V.29 7200 modulation training V.29 9600 modulation training V.17 7200 modulation short training V.17 7200 modulation long training V.17 9600 modulation short training V.17 9600 modulation long training V.17 12 000 modulation short training V.17 12 000 modulation long training V.17 14 400 modulation short training V.17 14 400 modulation long training V.8 ANSam signal V.8 signal V.34-cntl-channel-1200 V.34-pri-channel V.34-CC-retrain V.33 12 000 modulation training V.33 14 400 modulation training
"No signal" indicator may be sent whenever there is no signal in TDM input. For example, it may be used when modem is changed, from V.21 modem to V.17 one or from V.17 modem to V.21 one. NOTE – It is the responsibility of the gateway receiving the indicator to properly generate the appropriate analogue signal, including, for example, the ON-OFF cadence, and to terminate it appropriately.
7.3.2
T30_DATA TYPE
The T30_DATA TYPE is used to indicate that the packet contains data in the DATA element and what modulation was used to carry the data. The T30_DATA TYPE is used to indicate HDLC control data, Phase C data (T.4/T.6 or other) and, whenever V.34 modulation is used, the V.8 control signal data and V.34 control and primary channel data. It has the following values (see Table 4):
10
ITU-T Rec. T.38 (04/2007)
Table 4 – Listing of T30_DATA values Modulation V.21 Channel 2 V.27 ter 2400 V.27 ter 4800 V.29 7200 V.29 9600 V.17 7200 V.17 9600 V.17 12 000 V.17 14 400 V.8 V.34-pri-rate V.34-CC-1200 V.34-Pri-Ch V.33 12 000 V.33 14 400 NOTE – If both G3FE devices are identified via DIS/DCS exchange as IAF devices, T30_DATA values shall be ignored.
7.4
The IFP DATA element
The DATA Element of the IFP packets contains the data from the PSTN connections and some indication of the data format. The DATA element is a structure containing one or more Fields. Each Field has two parts: the first part indicates the Field-Type; the second part contains the Field-Data. The meanings for the Field-Type are shown in Table 5. Table 5 – Field-Type and Field-Data description Field-Type HDLC data
Field-Type description Data transmitted over the PSTN connection as HDLC. This includes the T.30 control messages as well as Phase C data sent using ECM. The Field-Data that follows contains some, or all, of a single HDLC data frame starting with the address frame of the HDLC frame, up to but not including FCS. Bit stuffing is removed from all data. The end of a frame is indicated by the FCS field. The gateway is responsible for bit stuffing, FCS generation, and separating frames with one or more flag (0x7E) when sending the HDLC data to a G3FE.
HDLC-Sig-End
Indicates that the HDLC power level has dropped below the turnoff threshold. There is no Field-Data with this Field-Type. This field type can be used during V.34 operation for terminating control channel at the end of a session.
HDLC-FCS-OK
Indicates the end of an HDLC frame and that the proper FCS was received. It also indicates that this frame is not the final frame. There is no Field-Data with this Field-Type.
ITU-T Rec. T.38 (04/2007)
11
Table 5 – Field-Type and Field-Data description Field-Type
Field-Type description
HDLC-FCS-Bad
Indicates the end of an HDLC frame and that the proper FCS was not received. It also indicates that this frame is not the final frame. There is no Field-Data with this Field-Type.
HDLC-FCS-OK-Sig-End
Indicates the end of an HDLC frame and that the proper FCS was received. In non-V.34 mode, it also indicates that V.21 modulation should terminate. In V.34 mode, flags shall be sent following the frame. There is no FieldData with this Field-Type.
HDLC-FCS-BAD-Sig-End
Indicates the end of an HDLC frame and that the proper FCS was not received and transmission should terminate. It also indicates that this frame is the final frame. There is no Field-Data with this Field-Type.
T.4-Non-ECM
T.4 Phase C data that is not sent using ECM or TCF data in the case of Method 2 of Rate Adaptation. It also indicates that this is not the end of the Phase C data. The Field-Data that follow are the demodulated Phase C data, including fill bits and RTC.
T.4-Non-ECM-Sig-End
T.4 phase C data that is not sent using ECM or TCF data in the case of Method 2 of Rate Adaptation. It also indicates that this is the end of the Phase C data. The Field-Data that follow are the demodulated Phase C data, including fill bits and RTC.
cm-message
The data of the CM signal is translated into the Facsimile Application Profile (see Table 8). The Field-Data is a single IA5 character of the Profile Number in Table 8. For example, a "1" indicates Profile 1.
jm-message
Response to the cm-message as defined in 10.1. The Field-Data is an IA5 character string of length two octets. The first character is "A" if it is an ACK, or "N" if it is a nACK. The second character is "0" if the first character is "A" and the appropriate nACK value as shown in Table 9. For example, nACK(1) is represented as "N1".
ci-message
Data transmitted in the V.8 CI signal is mapped to an IA5 character. The Field-Data that follows contains the IA5 character octet of either "4" or "5" based on the decode of bits 6-8 of the CI Call Function bits. Note that b8 is the MSB and b6 the LSB.
V.34-rate
Indicates the negotiated Primary Channel data signalling rate between receiving gateway and receiving G3FE. The Field-Data is an IA5 character string of length three octets – the two least significant digits are always 0 and not represented. The first octet after the V.34-pri-rate field type is the most significant digit of the data rate (e.g., "024" represents 2400 bit/s). (Note that the rate of 2400 bit/s between receiving gateway and receiving G3FE is disallowed due to possible symbol-rate mismatch.)
12
ITU-T Rec. T.38 (04/2007)
Multiple fields can appear in a single IFP DATA Element. The example below shows two HDLC frames arranged in a single DATA Element. Field-Type Field part description
HDLC-Data
FCS-OK
HDLC-Data
Indicates end of First HDLC frame. The HDLC octets with HDLC frame and zero stuffing and FCS more data to follow removed in the FieldData.
Second HDLC frame
FCS-OK-Sig-End Indicates end of HDLC frame and end of HDLC data
NOTE – When the Field-Type DATA element is received, the receiver should analyse it by examining each field separately. If the receiver does not recognize a certain Field-Type of the field it is examining, the entire field shall be skipped, and the receiver shall continue with the next field.
The IFP peer may elect to send the message data in several packets. Although relatively large packets may be sent, smaller data packets are recommended. It is entirely up to the emitting gateway to decide on the size of packets being sent. The xx-Sig-End Field-Types indicate the end of the message data. Note that for each packet sent, the whole header is repeated. A message with zero length data field may be sent to indicate, as early as possible, that T30_DATA messages are coming. Alternately, the appropriate T30_INDICATOR signal for High Speed could be sent. Implementations shall support both methods. Partial HDLC frames are also supported. The next example shows how two HDLC frames would be transmitted using three consecutive IFP packets. (Data transport headers are not shown.) TYPE element
DATA element
V.21 Data
FieldType: HDLC Data
HDLC Address (0xff)
HDLC Control
HDLC Octet 1
HDLC Octet 2
V.21 Data
FieldType: HDLC Data
HDLC Octet 7
HDLC Octet 8
HDLC Octet 9
FieldType FCSOK
V.21 Data
FieldType: HDLC Data
HDLC Address (0xff)
HDLC Control
HDLC Octet 1
FieldType FCSOKSigEnd
7.5
HDLC Octet 3
HDLC Octet 4
HDLC Octet 5
HDLC Octet 6
Limitation of V.21 frame packet size
To reduce the gateway processing delay, the use of smaller V.21 frame data packets is more beneficial for interconnected gateways to flexibly perform jitter buffer adjustment according to the network situation and compatibility of the facsimile terminal. The maximum V.21 packet size shall be 7 bytes, except for IAF devices. Larger V.21 frames shall be sent in multiple packets. NOTE – The implementation that conforms to the 2005 and the previous versions of this Recommendation may not limit the size.
ITU-T Rec. T.38 (04/2007)
13
8
IFP message flow for facsimile modulations up to V.17
The gateways follow the T.30 message flow and use the packet format in clause 7 to transmit these messages. This means, for example, that error correction in ECM mode is done between the sending G3FE and the receiving G3FE. The PPS, PPR, etc., signals are sent between the end G3FE devices. In another example, negotiation of security keys, etc., as proscribed in Annex H/T.30 is done between the end G3FE devices. Examples of typical message flows are shown in Appendix I. There are two methods of handling the TCF signal for determining the high-speed data rate. Either of these methods ensures that both PSTN facsimile sessions be conducted at the same speed. 8.1
Data rate management method 1
Method 1 of data rate management requires that the TCF training 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. Method 1 is used for TCP implementations and is optional for UDP implementations. When a confirmation to receive (CFR) or a failure to train (FTT) is received from a G3FE at the receiving gateway, a T.30 HDLC packet (indicating CFR or FTT respectively) should be forwarded to the emitting gateway. Based on the results of a TCF received from a G3FE and the T.30 HDLC packet (CFR or FTT) forwarded from a receiving gateway, an emitting gateway shall transmit FTT or CFR according to Table 6. Table 6 – Decision table of signalling rate of an emitting gateway T.30 signal message forwarded from receiving gateway
TCF signal received from a G3FE at emitting gateway
Signal to be transmitted to G3FE (emitter)
CFR
Success
CFR
FTT
Success
FTT
CFR
Failure
FTT
FTT
Failure
FTT
In the case where the Emitting Device is an Internet-aware fax (IAF) device and there is no emitting gateway, the IAF device shall respond to FTTs from the receiving gateway with appropriate DCS responses, including possibly modulation changes. In the case where the Receiving Device is an IAF device and there is no receiving gateway, the IAF device shall respond to DCS from the emitting gateway with CFR, but shall be prepared for a DCS in case the emitting gateway generates an FTT. In the case where the emitting device and the receiving device are IAF devices, the emitting device shall send DCS with the modulation bits set to 0, and the receiving device shall respond with CFR. The data rate over the IP network is established during call setup. 8.2
Data rate management method 2
Data rate management method 2 requires that 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. In the case where the emitting device is an Internet-aware fax (IAF) device and there is no emitting gateway, the IAF device shall respond to FTTs from the receiving gateway with appropriate DCS + TCF responses, including possibly modulation changes. 14
ITU-T Rec. T.38 (04/2007)
In the case where the receiving device is an IAF device and there is no receiving gateway, the IAF device shall respond to DCS from the emitting gateway with either CFR or FTT, depending upon the received TCF signal. In the case where the emitting device and the receiving device are IAF devices, the emitting device shall send DCS with the modulation bits set to 0, and the receiving device shall respond with CFR. The data rate over the IP network is established during call setup. Data Rate Management Method 2 is mandatory for use with UDP. Method 2 is not recommended either for use with TCP, or for the case where both G3FE devices are identified via DIS/DCS exchange as IAF devices. 9
IFT over UDP transport
9.1
IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP
9.1.1
Overview of UDPTL protocol
In the following discussion, a packet is regarded as a block of information which has the overall structure of that presented in 7.1.3. The layered model in Figure 5-a may be visualised more simply (Figure 5-b) in a flat space which allows packets to be regarded as a composite of headers plus the IFP payload. It is the IFP payload which is used to convey facsimile related information between gateways; all other information should be regarded as overhead necessary for the safe transportation and interpretation of IFP messages as described in clause 7. This clause describes the UDPTL payload. Descriptions of the IP and UDP headers and payloads are found in RFCs 791 and 768 respectively. UDPTL packets comprise a sequence number and a variable length, octet aligned, payload. UDPTL packets are based upon the principle of framing. Each packet may contain one or more IFP packets in its payload section. The first packet in any payload is always formatted in accordance with the specifications of clause 7 and must correspond to the sequence number supplied in the header (for instance, the first field in a payload with sequence number 15 must have been generated 5 payloads later than the first field in the payload with sequence number 10). The IFP packet in a UDPTL payload is referred to as the "primary". Additional fields may be included in a payload after the primary. These fields are referred to as "secondaries" and may or may not be formatted as per clause 7 specifications depending on their form. 9.1.2
UDPTL header section format
The UDPTL sequence number is used to identify the sequencing in a payload. 9.1.2.1
UDPTL sequence number element
Each packet, and therefore primary field, has its own corresponding unique sequence number which specifies an ordering at the receiving gateway should packets arrive out of sequence. To enable gateways to be synchronized upon receipt of any packet, the first primary field transmitted shall have sequence number zero. Successive primaries shall have linearly increasing (integer adjacent) sequence numbers. 9.1.3
UDPTL payload section format
During H.323 capabilities exchange, a gateway shall indicate its support of the available error protection schemes, parity FEC, or redundancy. Based on these capabilities, a choice may be made on which scheme is used for error protection. 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. The support of parity FEC is optional; a gateway
ITU-T Rec. T.38 (04/2007)
15
providing parity FEC receive services should, however, also be capable of receiving redundant messages. The IFP payload section comprises one or more fields. The basic format of an UDPTL payload is as shown in Figure 7. Figure 7 specifies the order in which different messages are to be assembled into the UDPTL payload. It is invalid to transmit both redundant and FEC fields within the same packet. OPTIONAL REDUNDANT MESSAGE
OPTIONAL REDUNDANT MESSAGE SEQUENCE NUMBER
MANDATORY MESSAGE (PRIMARY)
OR n packets
OPTIONAL FEC MESSAGE
…
OR OPTIONAL FEC MESSAGE
Figure 7 – Basic format of UDPTL payload section (UDP header not shown) 9.1.3.1
UDPTL FEC message format
An FEC contains a parity-encoded representation of a number of primaries. The number of primary IPF packets represented by an FEC field is given by the fec-n-packets element of the UDPTLPacket. 9.1.4
IFP/UDP facsimile data transfer functions
9.1.4.1
Use of redundancy messages
Each primary contains an IFP packet. 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. An illustration of such a buffer is provided in Figure 8 to demonstrate the principles of redundancy transfer by example.
45 44 43 42 41 T.38_F8
Figure 8 – Including prior (secondary) IFP packets (fields) into an UDPTL packet
16
ITU-T Rec. T.38 (04/2007)
Note that the UDPTL scheme is only capable of transmitting a block of redundant IFP packets whose sequence numbers are contiguous. Thus, if the current IFP packet has sequence number C and it is desired to redundantly transmit the IFP packet from UDPTL packet sequence number C-2, then the UDPTL packet must contain all the IFP packets from C, C-1, C-2 in the order given. Gateways need not be capable of transmitting redundant packets. Receiving gateways may ignore them. 9.2
IFT over UDP transport using RTP protocol: IFT/RTP/UDP
For UDP transport, the RTP protocol (RFC 3550) 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 Annexes B and D. Additional capabilities available to RTP streams may optionally be used as long as these are negotiated by both gateways. These include redundancy (RFC 2198) and FEC (RFC 2733). 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 – Similarities and differences between RTP and UDPTL Feature Payload format
UDPTL mechanism UDPTLPacket specified in Annex A
RTP mechanism Without redundancy and FEC, RTP payload is a single 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 RTP or UDPTL protocol
In order to be used, the UDPTL-based T.38 capability must be proposed by one gateway and selected/accepted by the other gateway. The capability declaration and negotiation procedures are per Annexes B, D, and E, or Annex D/H.323.
In order to be used, the RTP-based T.38 capability must be proposed by one gateway and selected/accepted by the other gateway. The capability declaration and negotiation procedures are per Annexes B, D, and E, or Annex D/H.323.
Payload sequencing
UDPTL sequence number
RTP sequence number
Redundancy
Uses mechanism defined in clause 9
RFC 2198
FEC
Uses mechanism defined in Annex C
RFC 2733, with or without RFC 2198 encapsulation
ITU-T Rec. T.38 (04/2007)
17
Each RTP packet starts with a fixed RTP header. The following describes the payload specific fields of the RTP fixed header when the RTP packet encapsulates fax: – Payload Type (PT): The payload type for fax is a dynamic payload type identified by the name "t38". If redundancy is used per RFC 2198, the payload type must indicate the payload format RED (as per RFC 2198). – Marker (M) bit: The marker bit is not used for fax and MUST be set to zero. The Marker bit should be ignored by the receiver of the packet. 10
Message flow for V.8 signals and Annex F/V.34 facsimile
10.1
V.8 negotiation
V.8 is used as a means to negotiate capabilities of facsimile and modem devices. This includes the modulations and the applications supported by the devices. During the negotiation procedure the ANSam, CI, CM, JM and CJ signals are interchanged between the calling and called G3FEs. The CM and JM signals are compelled end-to-end in order to fully verify a matching application or capability set. In the T.38 reference configuration, the CM information received by the emitting gateway from the calling G3FE is transferred to the receiving gateway that then uses it appropriately (possibly modifying it) and transmits it to the receiving G3FE. The receiving G3FE in response, transmits its JM signal to the receiving gateway. The receiving gateway then passes the information (again modifying it if necessary) to the emitting gateway, that in turn, transmits it to the calling G3FE. Once the emitting gateway has the JM information, it has full knowledge of the connection capabilities. At the initiation of a call, the ANSam signal begins the V.8 exchange for both V.34 facsimile and V.8-based modems. Call initiation in a multimode gateway, including V.8-based modems and V.34 G3FEs, is described in Annex F. This clause describes the handling of ANSam and the V.8 exchange for call initiation in facsimile-only gateways as well as for supporting V.34 turn-around polling (see 10.3.5) and re-starting V.34 in manual mode (see 10.3.6). ANSam shall be detected by the receiving gateway and generated by the emitting gateway. When ANSam is detected by the receiving gateway, it shall be reported using the v8-ansam indicator if the emitting gateway is V.34 capable. If the emitting gateway is not V.34 capable, the receiving gateway shall report ANSam using the ced t30-indicator. In the event that there is a timeout in response to an ANSam generated by the emitting gateway, resulting in a V.21 response, either gateway may elect to prevent a possible return to V.8 negotiations by resetting the V.8 bit of the DIS message (bit 6, first octet). An emitting gateway shall report the Facsimile Application Profile (FAP) to the receiving gateway when it has detected two identical/consecutive CM signals, and has verified that the Call Function Category octet contains a facsimile function. If the Call Function is not a valid facsimile value, then the call can be terminated as being a non-supported call type. The profile is transmitted to the receiving gateway using the cm-message data Field-Type, where it is regenerated for transmission to the receiving G3FE. The Facsimile Application Profile contains a base profile number. The base profile represents the contents of the Call Function and Modulation Modes of the V.8 CM signal. Table 8 shows the six possible valid facsimile profiles.
18
ITU-T Rec. T.38 (04/2007)
Table 8 – List of valid facsimile profiles Description
V.8 identifying code-points
G3 Facsimile Terminal: (Sending Facsimile)
Call Function = 4
G3 Facsimile Terminal: (Receiving Facsimile)
Call Function = 5
V.34 HDX and G3 Facsimile Terminal: (Sending Facsimile)
Call Function = 4
V.34 HDX and G3 Facsimile Terminal: (Receiving Facsimile)
Call Function = 5
V.34 HDX-only Facsimile Terminal: (Sending Facsimile)
Call Function = 4
V.34 HDX-only Facsimile Terminal: (Receiving Facsimile)
Call Function = 5
Profile No.
Modulation = V.17, V.29, V.27 ter, V.21
Modulation = V.17, V.29, V.27 ter, V.21
Modulation = V.34 HDX, V.17, V.29, V.27 ter, V.21 Modulation = V.34 HDX, V.17, V.29, V.27 ter, V.21
1
2
3 4 5
Modulation = V.34 HDX-only
6
Modulation = V.34 HDX-only
The receiving gateway shall transmit an acknowledgement (ACK) when it has received two identical/consecutive JM signals, and has determined that the profile being requested by the emitting gateway is acceptable to the remote terminal. The receiving gateway shall transmit a Negative Acknowledgement (NAK) to the emitting gateway if the profile is not acceptable. The value of the NAK depends upon the JM response. See Table 9. Table 9 – Negative Acknowledgement (NAK) message to invalid profiles NAK(0)
No compatible mode available
NAK(1)
No V.34 fax, use G3 fax – Response for profiles 1 and 2
NAK(2)
V.34 fax only. Response for profiles 5 and 6
Upon completion of the V.8 signalling, the emitting and receiving gateways shall proceed with the appropriate modulation specified indicated by the jm-message response. 10.2
V.34 data rate management
The two gateways shall independently proceed with phase 2 and phase 3 of V.34 half-duplex handshake as described in clause 12/V.34. To prevent the overflow of data from the calling terminal (calling G3FE) being transmitted to the answering terminal (receiving G3FE), the primary channel data signalling rate of the calling G3FE/emitting gateway terminal-gateway pair shall be less than or equal to the primary channel data signalling rate of the receiving gateway/receiving G3FE terminal gateway pair. Preference is to ensure that the rates are equal and the fastest compatible rate is selected. In the case where the calling G3FE/emitting gateway rate is less than that of the receiving gateway/receiving G3FE rate and the data is arriving at rate slower than being transmitted to the receiving G3FE terminal, gaps may be filled with HDLC flags between frames. Note that the only possibility of a data signalling rate incompatibility can be avoided by the receiving gateway disallowing a data rate of 2400 bit/s. Once a T.30 session has begun, data rate changes shall be managed to preserve these requirements.
ITU-T Rec. T.38 (04/2007)
19
10.2.1 Control channel start-up Control channel start-up can occur after training of the primary channel or after sending data in the primary channel (T.30 Phase C) if there is no request to change the primary channel data rate via a control channel retrain. The control channel rate shall be 1200 bit/s. Support for control channel rate of 2400 bit/s is for further study. The data rate shall be negotiated in the control channel start-up or control channel retrain of the V.34 half-duplex handshake. The emitting gateway shall be responsible for the correct selection of the data rates for the primary channel of the G3FEs. It is not necessary to constrain the equipment at both ends to the same symbol rate. The emitting gateway, once trained up, shall exchange HDLC flags in the control channel until it receives the primary channel signalling rate of the receiving gateway/receiving G3FE pair via the v34-pri-rate message. Once the emitting gateway has information of both its own negotiated data rate and the data rate selected by the receiving gateway/receiving G3FE pair, the emitting gateway shall determine if it must change the primary channel rate between itself and the calling G3FE, using a control channel retrain with a modified MPh. The local rate parameter shall be set to a value that is less than or (preferably) equal to the receiving G3FE value. Once the rate selection criteria has been met, the receiving gateway and the emitting gateway can pass on the T.30 DIS, DCS signals, etc., as normal. If the T.30 messages such as DIS are received from the receiving gateway while a control channel retrain is in progress between the emitting gateway and the calling G3FE, the emitting gateway shall buffer the incoming message and delay transmission of the T.30 messages until the rate selection and negotiation procedure is completed. Once completed, DIS, etc., can be transmitted from the emitting gateway to the calling G3FE. 10.2.2 Control channel retrain Once a T.30 session is established (i.e., after T.30 Phase B has started with the exchange of DIS), the primary channel data rate can be changed between pages or between partial pages via control channel retrain. Either the sending G3FE or the receiving G3FE can initiate a data rate change by sending AC. A control channel retrain from the G3FEs can be signalled using the v34-CC-retrain indicator. A gateway may initiate a retrain sequence at an appropriate time in response to this indicator. The retrain sequence can cause an MPh exchange between a gateway and a G3FE, resulting in a new data signalling rate for the primary channel. When a control channel retrain occurs in an attempt to change the primary channel data rate, the requirement to prevent data overflow, as defined in 10.2, shall be preserved. Either the calling G3FE or the receiving G3FE may initiate a data rate change request, leading to two main cases to consider. For each case, the rate may increase or decrease. The behaviour for each case is defined below: • Retrain initiated by the calling G3FE In this case, no signals are sent from the emitting gateway to the receiving gateway. a) The calling G3FE requests a rate increase. If the rate request would result in the calling G3FE rate to be greater than the rate between the receiving gateway and the receiving G3FE, the emitting gateway shall not allow the rate increase, else it may allow it. b) The calling G3FE requests a rate decrease. The emitting gateway may change the rate as requested.
20
ITU-T Rec. T.38 (04/2007)
•
Retrain initiated by the receiving G3FE In this case, the receiving gateway shall send the v34-CC-retrain indicator, followed by the v34-pri-rate message with the new data rate that is selected. a) The receiving G3FE requests a rate increase. The receiving gateway may change the rate as requested. The emitting gateway may, at an appropriate time, initiate a control-channel retrain with the sending G3FE, and increase the data rate of the calling G3FE if it is less than or equal to the new rate of the receiving G3FE. b) The receiving G3FE requests a rate decrease. The receiving gateway may change the rate as requested. If the new rate indicated by the v34-pri-rate message is less than the calling G3FE rate, the emitting gateway shall, at the appropriate time, initiate a control-channel retrain with the sending G3FE and decrease the primary channel data rate of the calling G3FE so that it is less than or equal to the new rate of the receiving G3FE. Note that a control channel retrain may be initiated at any time when the control channel is active. One appropriate time for the emitting gateway to initiate the required retrain is after the post-page message exchange but before the start-up of the primary channel.
10.3
Facsimile mode
10.3.1 Control channel Control channel data exchange begins after the MPh exchanges are complete and the parameters for the control channel rate and the primary channel rate have been agreed. The control channel is a full duplex channel that, unlike the non-V.34 fax modes, sends flags in the absence of data (compared to silence for the non-V.34 modes). It is the responsibility of the gateway or IAF to generate flags as needed during control channel operations. Control channel packets are sent using v34-CC-1200 t30-data "modulation" value with Field-Types of hdlc-xxx. The hdlc-xxx-sig-end Field-Types indicate the end of an HDLC message. Flags shall be sent after this instead of "silence" as in non-V.34 operation. 10.3.2 Switch from control channel to primary channel The source terminal indicates its intention to shut down the control channel and switch to the primary channel by sending continuous ONEs of at least 40 in number and until it detects that the recipient terminal has stopped sending flags. An emitting gateway shall signal a receiving gateway or IAF that it is ready to transition to the primary channel by sending the v34-primary-channel indicator. 10.3.3 Primary channel Annex F/T.30 requires that all image data be sent using ECM. This means that primary channel data shall be sent in packets using v34-primary-channel Data Value and Field-Types of hdlc-xxx. In the case where the calling G3FE/emitting gateway primary rate is less than that of the receiving gateway/receiving G3FE rate, causing the data to arrive at a rate slower than is being transmitted to the receiving G3FE, HDLC flags shall be used to fill between frames.
ITU-T Rec. T.38 (04/2007)
21
10.3.4 Switch from primary channel to control channel The emitting gateway shall send the v34-control-channel-1200 indicator after the primary channel turn-off sequence is complete. After receiving the v34-control-channel-1200 indicator, the receiving gateway shall initiate the turn-off of the primary channel between it and the called G3FE. If a change in the primary channel bit rate is not desired, the control channel starts up per 10.3.1. If a change in primary channel bit rate is desired, the v34-CC-retrain t30-indicator is sent per 10.2.2 instead of the v34-control channel t30-indicator. 10.3.5 Turn-around polling mode Turn-around polling is accomplished by shutting down the control channel after a DTC command and initiating a V.8 exchange with CM (ANSam is not used). The source terminal (calling G3FE) indicates its intention to do turn-around polling by sending DTC and sends flags until continuous ONEs are detected. After the ONEs are detected, the source terminal is quiet for 70 ms and then initiates CM. The receiving terminal indicates its intention to shut down the control channel and switch to V.8 exchange by sending continuous ONEs of at least 40 in number and until it detects that the source terminal has stopped sending flags. Turn-around polling shall be supported between the calling G3FE and the receiving G3FE as follows. The receiving gateway shall detect the T.30 DTC signal. After receiving DTC, the receiving gateway shall prepare to detect continuous ONEs from the receiving G3FE. Upon detection of continuous ONEs, it shall send the v8 indicator to the emitting gateway. The emitting gateway, after receiving the v8 indicator from the receiving gateway, shall send continuous ONEs to the emitting G3FE until the G3FE stops sending flags. The emitting gateway will then shut down the control channel, and prepare to receive the CM message from the emitting G3FE device. Upon receipt of the CM message, it shall forward the Facsimile Application Profile (FAP) to the receiving gateway using the cm-message. The receiving gateway, upon detecting turn-off of the control channel, from the receiving G3FE, shall go quiet until it receives the Facsimile Application Profile. Upon receiving the profile it shall send the appropriate CM to the receiving G3FE. The emitting gateway shall transmit an (ACK or nACK) to the receiving gateway after it has received two identical JM signals from the emitting G3FE, as described in 10.1. The operation is identical to normal V.8 negotiation except the emitting and receiving gateways switch behaviour. 10.3.6 Manual entry into Annex F/V.34 operation Manual entry into V.34 is accomplished by the calling G3FE responding with CI to a DIS from the receiving G3FE with bit 6 set to 1. The receiving G3FE responds to CI with ANSam, thus initiating the normal V.8 sequence described in 10.1. To support manual entry, the emitting gateway shall be capable of detecting CI after sending DIS in non-V.34 mode. If CI is received in response to DIS, the emitting gateway shall send a ci-message to the receiving gateway, and prepare to receive the V.8ANSam signal in response. When the receiving gateway, operating in non-V.34 mode, receives the ci-message, it shall regenerate the CI signal to the receiving G3FE, and prepare to receive ANSam from it. 10.3.7 Disconnect At the end of a call, a gateway shall indicate the end of the control channel with the hdlc-xxx-sig-end or the no-sig indicator to the remote gateway.
22
ITU-T Rec. T.38 (04/2007)
10.4
Compatibility with equipment conforming to prior versions of this Recommendation
A T.38 device conforming to earlier versions of ITU-T Rec. T.38 (ASN.1 versions 0, 1, 2) will not be able to interpret some messages added to enable V.34 capability. This generally should not present a problem because the gateways should discover during the call setup exchange what their respective capabilities are, including what version of ITU-T Rec. T.38 is supported. (See for example Annexes B, D and E). The following table shows the possible combinations and the resulting compatibility. Emitting gateway V.34 HDX capable
Receiving gateway V.34 HDX capable
No
No
Standard T.38
No
Yes
Fallback to Standard T.38
Yes
No
Fallback to Standard T.38
Yes
Yes
V.34 HDX T.38 procedures used
Comment
A non-V.34 (V.8) facsimile device will not recognize the amplitude modulation or phase reversals on an ANSam signal and will treat the signal as CED. A T.38 device conforming to earlier versions of this Recommendation will not be able to understand the T30_INDICATOR V.8 ANSam signal. A T.38 device conforming to this version of ITU-T Rec. T.38 shall only send signals defined in previous versions of T.38 to another device conforming to previous versions of T.38. A T.38 device detecting a T30_INDICATOR V.8 ANSam signal shall map this signal into a T30_INDICATOR CED signal before sending it to a T.38 device indicating version 0, 1, or 2 capability. A T.38 gateway conforming to version 3 of ITU-T Rec. T.38 may not advertise V.8 capability or respond to V.8 handshake with an external facsimile device when interoperating with a version 0, 1, or 2 T.38 device.
ITU-T Rec. T.38 (04/2007)
23
Annex A ASN.1 notation A.1
T.38 (2002) ASN.1 notation
T38 DEFINITIONS AUTOMATIC TAGS ::= BEGIN IFPPacket ::= SEQUENCE { type-of-msg Type-of-msg, data-field Data-Field OPTIONAL } Type-of-msg ::= CHOICE { t30-indicator ENUMERATED { no-signal, cng, ced, v21-preamble, v27-2400-training, v27-4800-training, v29-7200-training, v29-9600-training, v17-7200-short-training, v17-7200-long-training, v17-9600-short-training, v17-9600-long-training, v17-12000-short-training, v17-12000-long-training, v17-14400-short-training, v17-14400-long-training, …, v8-ansam, v8-signal, v34-cntl-channel-1200, v34-pri-channel, v34-CC-retrain, v33-12000-training, v33-14400-training }, t30-data ENUMERATED { v21, v27-2400, v27-4800, v29-7200, v29-9600, v17-7200, v17-9600, v17-12000, v17-14400, …, v8,
24
ITU-T Rec. T.38 (04/2007)
v34-pri-rate, v34-CC-1200, v34-pri-ch, v33-12000, v33-14400 } } Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end, …, cm-message, jm-message, ci-message, v34rate }, field-data
OCTET STRING (SIZE(1..65535)) OPTIONAL
} UDPTLPacket ::= SEQUENCE { seq-number INTEGER (0..65535), primary-ifp-packet TYPE-IDENTIFIER.&Type(IFPPacket), error-recovery CHOICE { secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket), fec-info SEQUENCE { fec-npackets INTEGER, fec-data SEQUENCE OF OCTET STRING } } } END
A.2
T.38 (1998) ASN.1 notation
T38 DEFINITIONS AUTOMATIC TAGS ::= BEGIN IFPPacket ::= SEQUENCE { type-of-msg Type-of-msg, data-field Data-Field OPTIONAL } Type-of-msg ::= CHOICE { t30-indicator ENUMERATED {
ITU-T Rec. T.38 (04/2007)
25
no-signal, cng, ced, v21-preamble, v27-2400-training, v27-4800-training, v29-7200-training, v29-9600-training, v17-7200-short-training, v17-7200-long-training, v17-9600-short-training, v17-9600-long-training, v17-12000-short-training, v17-12000-long-training, v17-14400-short-training, v17-14400-long-training, … }, data ENUMERATED { v21, v27-2400, v27-4800, v29-7200, v29-9600, v17-7200, v17-9600, v17-12000, v17-14400, … } } Data-Field ::= SEQUENCE OF SEQUENCE { field-type ENUMERATED { hdlc-data, hdlc-sig-end, hdlc-fcs-OK, hdlc-fcs-BAD, hdlc-fcs-OK-sig-end, hdlc-fcs-BAD-sig-end, t4-non-ecm-data, t4-non-ecm-sig-end }, field-data OCTET STRING (SIZE (1..65535)) OPTIONAL } UDPTLPacket ::=SEQUENCE { sE-NUMBER INTEGER (0..65535), primary-ifp-packet TYPE-IDENTIFIER.&Type(IFPPacket), error-recovery CHOICE { secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket), fec-info SEQUENCE { fec-npackets INTEGER, fec-data SEQUENCE OF OCTET STRING } } } END
26
ITU-T Rec. T.38 (04/2007)
Annex B H.323 call establishment procedures B.1
Introduction
This annex describes system level requirements and procedures for Internet-aware facsimile implementations and Internet-aware facsimile gateways conforming to this Recommendation to establish calls with other T.38 implementations including those using the procedures defined in this annex as well as Annex D/H.323. B.2
Communication between facsimile terminal and gateway
Communication between a sending Group 3 facsimile terminal and the incoming gateway is generally effected using dial-up procedures over the PSTN. Basic and optional T.30 procedures are supported. The gateway may receive the facsimile transmission from the calling terminal as a modem signal on the PSTN if the gateway supports a direct dial-in procedure. Where the gateway is located within the network, it may receive the transmission in the form of a PCM-encoded digital channel. Internet-aware facsimile (IAF) implementations are connected directly to the IP network and act as a gateway for call establishment. B.2.1
Transfer of addressing information
The conveyance of the E.164 address of the called terminal from the calling terminal to the emitting gateway may be by manual procedures using prompts, by means of double dialling, or by any other suitable means. In addition, there are some applications which may benefit from placing the destination E.164 address in the IRA (Internet Routing Address)/ISP (Internet Selective Polling) signals, as described in ITU-T Rec. T.30. B.3
Communication between gateways
B.3.1
Overview
B.3.1.1
Call setup
Call setup for T.38 Annex B compliant implementations is based on the Fast Connect Procedure defined in ITU-T Rec. H.323. T.38 implementations may operate in two distinct H.323 compatible environments. 1) A facsimile-only over IP environment. In this environment, no voice support is provided. The procedures and requirements of this annex shall apply to implementations operating in this environment unless they are superseded by an H.323 Annex D implementation. 2) A facsimile and voice over IP environment. Implementations in this environment shall use the methods described in Annex D/H.323. T.38 Annex B implementations shall use the Fast Connect Procedure for call setup and shall not initiate H.245 negotiation. However, T.38 Annex B devices shall support H.245 in case the remote device is not a T.38 Annex B device or otherwise needs to start H.245.
ITU-T Rec. T.38 (04/2007)
27
B.3.1.2
Media channels
Annex D/H.323 requires that T.38 facsimile packets are sent on a separate TCP/UDP port from H.225.0 call signalling. All required ports are usually 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, or two UDP ports for RTP (one for RTP and one for RTCP), or a TCP port for T.38 facsimile information. B.3.1.3
Usage of ITU-T Rec. H.245
Endpoints conforming to this annex are required to support ITU-T Rec. H.245, but shall not initiate communication over the H.245 control channel. Rather, T.38 Annex B devices shall only transmit H.245 messages over the H.245 control channel after first either receiving a TCS message or a request to establish a separate H.245 control channel. T.38 Annex B devices shall advertise T.38 support in the initial TCS message that it sends and it should indicate support for G.711 in order to be interoperable with the broadest range of H.323 devices. NOTE – Previous versions of this annex specified that devices shall only support Fast Connect procedures, so it is important for interoperability with older devices that newer devices do not initiate H.245 communication unless the other device initiates H.245 communication first.
B.3.2
Basic call setup
H.323 implementations have a multi-phase call setup procedure, which includes: – RAS (Registration, Admissions and Status) signalling using UDP between the endpoint and the gatekeeper. – H.225.0 call signalling either directly between endpoints, or between endpoints and gatekeeper depending on the call model in use, using TCP/IP. – H.245 capability negotiation and logical channel management using TCP/IP, with messages either tunnelled within the H.225.0 call signalling channel or transmitted via a separate TCP/IP connection. Although support for RAS is mandatory, an H.323 endpoint is not required to use RAS unless a gatekeeper is present in the network and willing to provide service to the endpoint. Thus, an Annex B implementation could be used with or without a gatekeeper. It could obtain its IP addresses in any fashion desired, such as LDAP or a personal directory. However, if placed in a gatekeeper environment, it would register and operate as per ITU-T Rec. H.323. Implementations conforming to this annex shall conform to H.323 RAS signalling. RAS signalling allows a T.38 implementation to initiate a call, using the H.323 well-known TCP port, and provides dynamic assignment of the port to use for the T.38 messages. Implementations conforming to this annex utilize H.323 call setup messages as described in 8.1.1/H.323: "Basic call setup – neither endpoint registered" assuming this to be the case. The initial text of 8.1/H.323: "Phase A – Call Setup" is also relevant to T.38 implementations. The rest of 8.1/H.323 applies if one or both endpoints are registered with a gatekeeper. Implementations conforming to this annex shall initially start calls by opening a TCP/IP session and sending an H.225.0 SETUP message with the fast connect fields filled in as described in 8.1.7/H.323. The receiving terminal replies with an H.225.0 ALERTING, CALL PROCEEDING, PROGRESS, or CONNECT message as per the procedures of ITU-T Rec. H.323 "fast connect". The Annex B implementation may include video, voice, or data OLC elements in the "fastStart" structure, but if present such data types shall follow OLC elements containing facsimile proposal(s). The OLC elements pertinent to facsimile are described in the next clause.
28
ITU-T Rec. T.38 (04/2007)
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 – Gateway option capability support indications Option
Description
Data rate management method
Method 1: Local generation of TCF is required for use with TCP.
Data transport protocol
The emitting gateway may indicate a preference for either UDP/UDPTL, or UDP/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.
Method 2: Transfer of TCF is required for use with UDP (UDPTL or RTP). Method 2 is not recommended for use with TCP.
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 V7 (or higher). 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 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.
ITU-T Rec. T.38 (04/2007)
29
T.38_FB.1
Figure B.1 – A pair of unidirectional channels
T.38_FB.2
Figure B.2 – A single bidirectional channel The sender terminal specifies a TCP/UDP port in the OpenLogicalChannel in the fastStart element of Setup when transmitting T.38 via TCP or UDPTL. 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. When transmitting T.38 over RTP, the OpenLogicalChannel contains the generic audio capability defined in Annex G and shall be included in the fastStart element in the Setup message as specified in 8.1.7/H.323: "Fast Connect". The parameter names in the generic audio capability are named the same as those used in the H.245 ASN.1. All T.38 Annex B implementations shall include a T38fax OLC with t38FaxUdpOptions and transferredTCF set in the fastStart structure. Note that all H.323 Annex D devices supporting T.38 also are required to include these structures. In addition, T.38 Annex B devices shouldinclude an OLC with t38FaxTcpOptions and localTCF set and with tcp selected as the t38FaxProtocol choice. Optionally, T.38 Annex B devices may include an OLC with the T38RTP generic audio capability specified with the transferredTCF included in the fastStart structure. 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 message or other message containing the fastStart element. NOTE – In the first version of this annex, 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.
30
ITU-T Rec. T.38 (04/2007)
B.3.4
Examples of call setup 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). In this case, the sender shall send OLCs for T38/TCP&localTCF and T38/UDPTL&transferredTCF. Optionally, the sender may send OLCs for T38RTP&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 T38RTP&transferredTCF is returned. Otherwise, the OLC for T38/TCP&localTCF is returned. B.3.4.2
UDP (UDPTL) with data rate management method 1 support
For the case where the sender wishes to use data rate management method 1 and UDP (UDPTL) for data transport, it shall send OLCs for T38/UDPTL&transferredTCF, T38/UDPTL&localTCF, T38/TCP&localTCF. If the receiver agrees to use UDPTL&localTCF, an OLC for T38/UDPTL&localTCF is returned. B.3.4.3
RTP with data rate management method 1 support
For the case where the sender wishes to use data rate management method 1 and RTP for data transport, it shall send OLCs for T38RTP&transferredTCF and T38RTP&localTCF. If the receiver agrees to use RTP&localTCF, an OLC for T38RTP&localTCF is returned. B.3.5
Mandatory call setup messages
The Annex B implementation shall support the following clauses of H.225.0 for call setup: – Mandatory elements in Table 4/H.225.0, i.e., ALERTING, CONNECT, CALL PROCEEDING, SETUP, RELEASE COMPLETE, etc. shall be supported by T.38 endpoints conforming to Annex B. Note that there is no requirement to send ALERTING if CONNECT, CALL PROCEEDING, or RELEASE COMPLETE is sent within 4 seconds of the receipt of SETUP, as described in ITU-T Rec. H.323. Note also that gateways shall send CALL PROCEEDING. – The Information elements of FACILITY as described in 7.4.1/H.225.0. – The Information elements of ALERTING as described in 7.3.1/H.225.0. – The Information elements of CALL PROCEEDING as described in 7.3.2/H.225.0. – The Information elements of CONNECT as described in 7.3.3/H.225.0 – The information elements of PROGRESS as described in 7.3.7/H.225.0. – The Information elements of RELEASE COMPLETE as described in 7.3.9/H.225.0. – The Information elements of SETUP as described in 7.3.10/H.225.0. – The ASN.1 of H.225.0 as described in ITU-T Rec. H.225.0. NOTE – H.225.0 ASN.1 supports a large number of optional features. T.38 Annex B implementations may implement the full range of optional H.225.0 features, including authentication features that are potentially available. They may also implement H.450.x supplementary services. H.225.0 options are outside (i.e., prior) to the OLC negotiations. If a real time fax endpoint (H.323 Annex D or T.38 Annex B) makes use of H.450.x supplementary services, it must take into account that the remote endpoint may or may not support them. In the worst case, the supplementary service is ignored by the receiver. Thus the requesting endpoint must handle this condition, with, for example, a timeout mechanism.
ITU-T Rec. T.38 (04/2007)
31
B.3.6
Mapping of call progress signals
For call setup and call progress, the return signals can be simplified to the set shown in Table B.2. These are all returned prior to or instead of a connect message. The CONNECT message is returned when the gateway, by some means, determines that a connection to the terminal G3FE has been established. If CED or FSK flags are detected, the appropriate T.38 messages can be sent. This level of call setup and progress works in both H.323 as well as non-H.323 environments. Table B.2 – Call Progress Mapping Meaning
Mapping/Comments
Busy1. Subscriber busy tone as defined in ITU-T Rec. E.180/Q.35. Q.850 cause value 17. Busy2. Sometimes referred to as "Distinctive Busy" on some PABX models.
Q.850 cause value 17.
Congestion busy as defined in ITU-T Rec. E.180/Q.35.
Q.850 cause value 34.
Ring1. Ringing tone as defined in ITU-T Rec. E.180/Q.35. This is an intermediate call progress indicator. It can be used to generate a ringback signal to the originating G3FE as if it were an end-to-end PSTN connection.
ALERTING
Ring2. Ringing tone similar to Ring1 where two short rings are generated instead of one long ring. This is an intermediate call progress result.
ALERTING
SIT Intercept. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. Intercept Tone is one combination of tones – frequency and duration.
Q.850 cause value 4.
SIT Vacant. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. Circuit Vacant Tone is one combination of tones – frequency and duration.
Q.850 cause value 4.
SIT Reorder. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. Reorder Tone is one combination of tones – frequency and duration.
Q.850 cause value 4.
SIT No Circuit. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. No Circuit Tone is one combination of tones – frequency and duration.
Q.850 cause value 4.
32
ITU-T Rec. T.38 (04/2007)
NOTE – SIT tones are not distinguished because they generally indicate a problem with the number to dial.
B.3.7
Usage of the maxBitRate in messages
T.38 is a data application (UDPTL or TCP) or audio capability (RTP) per ITU-T Rec. H.245. An H.245 OLC requires that the maxBitRate field be set. For gateway implementations, this field should indicate the maximum modem rate for the TDM network that is supported by the gateway. The rate for IAF devices is TBD but shall not be set to zero. Note that the units for maxBitRate is 100 bit/s. The maxBitRate field shall not be used to negotiate fax transmission rates and is included only as a hint to the called party as to the maximum required bandwidth. B.3.8
DTMF transmission
UserInputIndication as described in Annex D/H.323 is an H.245 signal and may be used if the H.245 control channel is utilized. Other mechanisms as described in H.323 or H.225.0 may also be employed. B.3.9
Interoperability
Both H.323 direct call model and T.38 Annex B require a well-known port to initiate call signalling. As described in Appendix IV/H.225.0, the H.323 well-known port for call signalling via TCP is 1720. T.38 Annex B endpoints should use the H.323 well-known port. In order for a single implementation (such as a gateway) to support multiple endpoints, dynamic ports must be used. A facsimile gateway conforming to this annex shall support H.323 RAS. T.38 Annex B implementations shall set h245Tunnelling to TRUE in all H.225.0 messages.
ITU-T Rec. T.38 (04/2007)
33
Annex C The optional forward error correction scheme for UDPTL C.1
Overview of the optional forward error correction mechanism
The parity FEC scheme is symmetrical in that it is identical in both encode and decode modes, and may be computed for an arbitrary number of arbitrarily sized IFP messages. A transmitting gateway generates FEC messages by passing in a number of primary IFP packets; these FEC messages may then be assembled into a packet in accordance with Figure 5. Receiving gateways which detect the loss of a primary IFP packet that is covered by an FEC message may be able to reconstruct it by passing in the remaining (received) primary IFP packets and the FEC message itself to the parity encode/decode algorithm. Certain conditions apply in order for a lost primary IFP packet to be recovered using the parity encoder/decoder; these shall be discussed in the following clauses. C.2
Parity encode/decode scheme operation and characteristics
The parity scheme accepts a number of arbitrarily sized IFP messages. It aligns them vertically and zero pads the shorter length messages to produce a 2D matrix as shown in Figure C.1 a). A one-bit piece-wise sum is then performed on a column by column basis (equivalent to exclusive OR logic function) across the width of the matrix, each summation resulting in a binary digit. This process is illustrated in Figure C.1 b). The output from the parity scheme is the row of resulting binary data. The basic error recovery scheme works by assuming that 1 loss in n packets may occur. If the (n + 1)th packet contains an FEC message generated from the primary IFP packets of the n preceding packets, then provided no more than one of the first n packets is lost, any missing IFP message can be reconstructed. The generation and reconstruction of primary IFP packets using the parity scheme outlined above is described in the following subclauses.
34
ITU-T Rec. T.38 (04/2007)
b) Parity function application
a) Length normalization example Input frame 1
0
1
0
0
1
1
1
0
1
Input frame 2
1
0
1
1
1
0
0
0
1
Input frame 3
0
0
0
1
1
0
1
0
0
0
1
0
0
0
1
0
1
1
0
NORMALIZE
Input frame 1
0
1
0
0
1
1
1
0
1
0
0
0
1
0
1
1
Input frame 2
1
0
1
1
1
0
0
0
1
0
0
0
0
0
0
0
0
0
0
1
1
0
1
0
0
1
0
0
0
0
0
0
Input frame 3
Input frame 1
0
1
0
0
1
1
1
0
1
0
0
0
1
0
1
1
Input frame 2
1
0
1
1
1
0
0
0
1
0
0
0
0
0
0
0
Input frame 3
0
0
0
1
1
0
1
0
0
1
0
0
0
0
0
0
Column-based binary Sum (carry discarded)
⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕
Resulting output
1
1
1
0
1
1
0
0
0
1
0
0
1
0
1
1
T.38_FC.1
Figure C.1 – Illustration of Length normalization and Parity function operation
35
ITU-T Rec. T.38 (04/2007)
C.2.1
Generating and transmitting FEC messages
By utilizing a buffer similar to that shown in Figure C.2, it is possible to pass multiple prior primary IFP packets into the parity FEC algorithm for processing. The FEC scheme returns with a frame of encoded data that may then be assembled into a packet after the current primary IFP packet. The transmitting gateway must decide in advance the number of prior IFP messages it shall use to generate the FEC information. The n prior primary IFP packets are sent to the parity encoding scheme which results in a single message of FEC data of length l octets where l is the largest message length value encountered in the list of primary IFP packets plus 2 octets. Finally, the newly generated FEC message is assembled as in Figure C.2 and inserted into the packet after the primary IFP packet. SEQUENCE NUMBER ( 45 )
PRIMARY MESSAGE
FEC MESSAGE
IFP MESSAGE Parity FEC scheme
IFP MESSAGE IFP MESSAGE IFP MESSAGE IFP MESSAGE T.38_FC.2
Figure C.2 – Generation and packetization of a single parity FEC frame Multiple FEC messages may be sent in a single packet, each generated from fec_npackets (i.e., the number of) prior primary IFP packets. Unlike the instance where only one FEC message is present, when multiple FEC messages are transmitted in a single packet, the contributing primary IFP packets for each FEC message are not consecutive, but are interleaved. This is illustrated in Figure C.3 which shows an example providing protection against a burst of three consecutive lost packets.
36
ITU-T Rec. T.38 (04/2007)
SEQUENCE NUMBER ( 45 )
Sequence
PRIMARY MESSAGE
FEC MESSAGE 1
FEC MESSAGE 2
Frame data
45
IFP MESSAGE
44
IFP MESSAGE
Parity FEC scheme
43
IFP MESSAGE
+
42
IFP MESSAGE
41
IFP MESSAGE
40
IFP MESSAGE
39
IFP MESSAGE
38
IFP MESSAGE
37
IFP MESSAGE
36
IFP MESSAGE
Parity FEC scheme +
Parity FEC scheme +
T.38_FC.3
Figure C.3 – Generating multiple FEC messages to protect against burst errors
37
ITU-T Rec. T.38 (04/2007)
FEC MESSAGE n
C.2.2
Receiving FEC messages and primary IFP packet reconstruction
A gateway in receipt of FEC messages in a packet must determine from the UDPTL packet: • the number of FEC messages present in the packet; • the sequence numbers of the primary IFP packets contained in each FEC message; • the sequence numbers of any packets which have been "lost" over the network. In order to determine the sequence numbers of the primary IFP packets encoded in a given FEC message, the receiving gateway must extract the number of primary IFP packets covered by that frame. For a packet containing a single FEC message, the sequence numbers covered by that message are simply those from [Seq – 1] to [Seq – (n + 1)] where n is the value in the fec_npackets element and Seq is the value in the seq-number element. For a UDPTL packet containing m FEC messages with sequence number Seq and a message control field setting of n, the sequence number ranges for FEC message I (for 1 ≤ I ≤ m) are trivially extracted from the following equations: StartSeq = Seq – I EndSeq = Seq – I – (n – 1)m Intermediate sequence numbers between these ranges are linearly spaced with gap m. Once the sequence numbers of the primary IFP packets encoded in an FEC message have been determined, the receiving gateway may check to determine whether any of the primary IFP packets listed has failed to arrive. If one, and only one, of these primary IFP packets has failed to arrive, then the FEC message and the remaining (delivered) primary IFP packets may be sent to the parity algorithm to recover the missing sequence. The number of FEC messages, m, is the number of octet strings contained in the fec-data element (as encoded in the SEQUENCE OF construct)
38
ITU-T Rec. T.38 (04/2007)
Annex D SIP/SDP call establishment procedures D.1
Introduction
This annex describes system level requirements and procedures for Internet-aware facsimile implementations and Internet-aware facsimile gateways conforming to ITU-T Rec. T.38 to establish calls with other ITU-T T.38 implementations using the procedures defined in RFC 2543 (SIP) and RFC 2327 (SDP). D.2
Communication between gateways
D.2.1
Overview
D.2.1.1
Call setup
Call setup for Annex D/T.38 compliant implementations is based on SIP (Session Initiation Protocol) defined in RFC 2543. As in Annex B, implementations may operate in two distinct compatible environments: 1)
A facsimile-only over IP environment − In this environment, no voice support is provided. The procedures and requirements of D.2.2.3 shall apply to implementations operating in this environment.
2)
A facsimile and voice over IP environment − The procedures and requirements of this annex shall apply to implementations operating in this environment.
D.2.1.2
Media channels
ITU-T T.38 facsimile packets are sent on a separate TCP/UDP port from SIP call signalling. A minimal Annex D/T.38 implementation requires a TCP/UDP port (default is 5060) for call signalling and either a UDP port or a TCP port for ITU-T T.38 facsimile information. D.2.1.3
Usage of SDP
Endpoints conforming to this annex are required to support SDP, including the extensions described below. D.2.1.3.1 SDP parameter definitions The following SDP parameters are defined: Mandatory parameters: T38FaxRateManagement: Indicates the fax rate management model as defined in T.38. Values may be "localTCF" or "transferredTCF". Optional parameters: T38FaxVersion: This is the version number of ITU-T Rec. T.38. New versions shall be compatible with previous versions. Absence of this parameter indicates version 0. The version is expressed as an integer value. T38MaxBitRate: Indicates the maximum fax transmission rate supported by the endpoint and shall not be used to negotiate actual transmission speeds. T38FaxFillBitRemoval: Indicates the capability to remove and insert fill bits in Phase C (refer to ITU-T Rec. T.30), non-ECM data to reduce bandwidth. This is a boolean parameter (inclusion = true, exclusion = false).
ITU-T Rec. T.38 (04/2007)
39
T38FaxTranscodingMMR: 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. This is a boolean parameter (inclusion = true, exclusion = false). T38FaxTranscodingJBIG: Indicates the ability to convert to/from JBIG to reduce bandwidth. This is a boolean parameter (inclusion = true, exclusion = false). T38FaxMaxBuffer: 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. Value is an integer. T38FaxMaxDatagram: The maximum size of the payload within an RTP packet that can be accepted by the remote device. This is an integer value. T38FaxUdpEC: Indicates any desired error correction scheme, either FEC or redundancy. Valid options are "t38UDPFEC" and "t38UDPRedundancy". This parameter shall only be present when using UDPTL as the transport for T.38. T38VendorInfo: Indicates the manufacturer of the endpoint. D.2.2
Basic call setup
D.2.2.1
Choosing call setup mechanism
Annex B indicates that H.323 FastCall Setup is the basic mechanism for establishing a T.38 call. The method described in this annex is intended for use in conjunction with this mechanism in a decomposed gateway model. In addition, this annex may also be used if the emitting gateway is aware that the destination gateway supports the call establishment mechanism of this annex. D.2.2.2
SIP call setup
According to RFC 2543 section 1, SIP supports a five-phase process for establishing and terminating a call: User location
determination of the end system to be used for communication
User capabilities
determination of the media and media parameters to be used
User availability
determination of the willingness of the called party to engage in communications
Call setup
"ringing", establishment of call parameters at both called and calling party
Call handling
including transfer and termination of calls
SIP can also be used in conjunction with other call setup and signalling protocols, for example in an H.248 to H.323 interworking function. SIP can invite users to sessions with and without resource reservation. SIP does not reserve resources, but can convey to the invited system the information necessary to do this. D.2.2.3
Facsimile-only connection
The emitting gateway sends a SIP INVITE request (with the appropriate options set) for a T.38 facsimile connection with the receiving SIP server. The receiving server will likely be the receiving gateway; however, it may also proxy or redirect the SIP connection to the actual gateway through SIP or other means. In any case, a response will be sent to the emitting gateway indicating acceptance, redirection or failure of the request. If accepted (or a redirected INVITE is accepted), the T.38 facsimile call proceeds. Once the call is completed, the call may be disconnected with a SIP BYE command.
40
ITU-T Rec. T.38 (04/2007)
D.2.2.4
Voice and facsimile connection
A SIP INVITE is made to the called party requesting a voice connection per the requirements of RFC 2543. A voice connection is then established. Upon detection of facsimile by the receiving gateway, a SIP INVITE request is sent to the emitting gateway (with the same Call-ID as the existing voice connection) for a T.38 facsimile connection. Upon completion of the facsimile call establishment (noted in D.2.2.3), the T.38 facsimile call proceeds with a T.38 V.21 flags indicator packet. Note that during this switchover and the facsimile call, it may be useful to mute the voice channel. The voice channel may be used again once the end of facsimile transmission is detected. Alternately, some implementations may choose to replace the voice channel with a facsimile channel. Once the call is completed, the call may be disconnected with a SIP BYE command. 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. RFC 2327 Session Description Protocol (SDP) provides mechanisms for describing sessions for SIP. There are several T.38 specific parameters that may be negotiated when establishing a T.38 media stream. For historic reasons, this is done differently for the UDPTL/TCP transport and the RTP transport. D.2.3.1
UDPTL and TCP negotiation
New attributes (section 6 of SDP) are required to support this Recommendation when using the UDPTL and TCP transports. Note that the attributes defined below are specific to the use of T.38 with either the UDPTL or TCP transport and do not apply to the use of T.38 with RTP (see D.2.3.2). 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 (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 this Recommendation: 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
ITU-T Rec. T.38 (04/2007)
41
Maximum Datagram Size Att-field=T38FaxMaxDatagram Att-value = 1*(DIGIT) ;optional Error Correction Att-field=T38FaxUdpEC Att-value = t38UDPFEC | t38UDPRedundancy T38VendorInfo Att-field=T38VendorInfo Att-value = t35country-code SP t35extention SP manufacturer-code t35country-code = 1*(DIGIT) t35extension = 1*(DIGIT) manufacturer-code = 1*(DIGIT) ;optional ;0 to 255 for t35country-code and t35extension ;t35country-code is defined in T.35 Annex A. ;t35extension is defined in T.35 Annex B ;The value of "manufacturer-code" is assigned nationally ;and identifies an equipment manufacturer. ;Example a=T38VendorInfo:0 0 37
D.2.3.2
RTP negotiation
The MIME type registration for "audio/T38" defines several optional parameters that may be used with T.38 over RTP. Those parameters are supplied in a semi-colon separated list of "parameter" or "parameter=value" pairs using the "a=fmtp" parameter defined in SDP; the "parameter" form is used for boolean values, where presence equals "true" and absence "false". The parameter definitions are repeated here: Version Name=T38FaxVersion Value= 1*(DIGIT) ;Version 0, the default, refers to T.38 (1998) Maximum Bit Rate Name=T38MaxBitRate Value= 1*(DIGIT) Fill Bit Removal Name=T38FaxFillBitRemoval ;Boolean MMR Transcoding Name=T38FaxTranscodingMMR ;Boolean JBIG Transcoding Name=T38FaxTranscodingJBIG ;Boolean Data Rate Management Method Name=T38FaxRateManagement Value = "localTCF" | "transferredTCF" Maximum Buffer Size Name=T38FaxMaxBuffer Value = 1*(DIGIT) ;optional Maximum Datagram Size Name=T38FaxMaxDatagram Value = 1*(DIGIT) ;optional T38VendorInfo Att-field=T38VendorInfo Att-value = t35country-code SP t35extention SP manufacturer-code t35country-code = 1*(DIGIT) t35extension = 1*(DIGIT) manufacturer-code = 1*(DIGIT) ;optional ;0 to 255 for t35country-code and t35extension ;t35country-code is defined in T.35 Annex A.
42
ITU-T Rec. T.38 (04/2007)
;t35extension is defined in T.35 Annex B ;The value of "manufacturer-code" is assigned nationally ;and identifies an equipment manufacturer. ;Example a=T38VendorInfo:0 0 37
NOTE – There is no Error Correction defined for this Recommendation over RTP Redundancy and FEC can be declared for RTP payloads according to the SDP usage defined in RFCs 2198 and 2733.
D.2.3.3
Declaration of T.38 in SDP
The image/t38 MIME content type in SDP indicates this Recommendation. This choice is consistent with image/tiff used in ITU-T Rec. T.37 and image/g3fax used for ITU-T Rec. X.420. D.2.3.4
Use of either TCP or UDP
Two logical channels (sender to receiver channel and receiver to sender channel) shall be opened for the transfer of T.38 packets. T.38 packets can be transferred using either TCP or UDP. 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 may be more effective when the bandwidth for facsimile communication is sufficient. Note that during the SIP call setup, the calling party suggests the transport (TCP or UDP) by listing its preferred first in the SDP of a SIP INVITE. The receiver should open the TCP/UDP port based on the preference of the sender, but the receiver decides. In support of T.38 choice of UDP or TCP transport, SDP extensions: • indicate UDPTL (facsimile user datagram protocol transport layer) as a valid transport value (third field); • indicate TCP (transmission control protocol) as a valid transport value (third field); • indicate RTP/AVP (Real Time Protocol/Audio-Video Profile) as a valid transport value (third field); • indicate RTP/SAVP (Real Time Protocol/Secure Audio-Video Profile) as a valid transport value (third field); • indicate other RTP profiles (e.g., AVPF and SAVPF) as a valid transport value (third field); • include t38 as a valid format type value (fourth field). This value is used when the transport value is UDPTL or TCP; • include an RTP payload type as a valid format type value (fourth field). This value is used when the transport value is RTP/AVP or RTP/SAVP. This payload type is mapped via an 'rtpmap' attribute to the MIME type "audio/t38". When the transport layer is RTP, standard RTP mechanisms for packet redundancy (RFC 2198) and FEC protection (RFC 2733) may be used. The declaration of these mechanisms in SDP is described in RFC 2198 and RFC 2733. NOTE − As t38 is not an RTP-defined value, it has to be a MIME sub-type of the media type. As a result, this is awaiting the publication of an IETF RFC to define the registration of audio/t38 with IANA as a valid MIME content-type per the procedure noted in Appendix B of SDP (RFC 2327).
ITU-T Rec. T.38 (04/2007)
43
D.2.3.5
SDP parameter definitions
This clause describes the use of T.38 SDP parameters when utilized with the SIP offer/answer model. T38MaxBitRate is declarative and the answer is independent of the offer. The parameter simply indicates the maximum transmission bit rate supported by the endpoint. T38FaxFillBitRemoval is negotiated. If the answering entity does not support this capability or if the capability was not in the offer, this parameter shall not be present in the answer. T38FaxTranscodingMMR is negotiated. If the answering entity does not support this capability or if the capability was not in the offer, this parameter shall not be present in the answer. T38FaxTranscodingJBIG is negotiated. If the answering entity does not support this capability or if the capability was not in the offer, this parameter shall not be present in the answer. T38FaxRateManagement is declarative and the answer must contain the same value. T38FaxVersion is negotiated. The entity answering the offer shall return the same or a lower version number. T38FaxMaxBuffer is declarative and the answer is independent of the offer. This parameter simply signals the buffer space available on the offering endpoint and the answering endpoint. The answering endpoint may have more or less buffer space than the offering endpoint. Each endpoint should be considerate of the available buffer space on the opposite endpoint. T38FaxMaxDatagram is declarative and the answer is independent of the offer. This parameter signals the largest acceptable datagram for the offering endpoint and the answering endpoint (i.e., the maximum size of the RTP payload). The answering endpoint may accept a larger or smaller datagram than the offering endpoint. Each endpoint should be considerate of the maximum datagram size of the opposite endpoint. T38FaxUdpEC is negotiated only when using UDPTL as the transport. If the answering endpoint supports the offered error correction mode, then it shall return the same value in the answer, otherwise the T38FaxUdpEC parameter shall not be present in the answer. T38VendorInfo is declarative and the answer is independent of the offer. The parameter merely indicates the manufacturer of the endpoint. D.2.4 D.2.4.1
Examples of call setup Facsimile-only invite
The default case requires support for both TCP and UDP. A UDPTL or RTP encapsulation method may be used in conjunction with UDP transport. In this case, two 'm=' lines are listed with the preferred one first in the INVITE. The rejected media connection will be indicated with a port number set to zero in the response. For a two-party facsimile-only call between T.38 gateways, when UDPTL encapsulation is used in conjunction with the UDP transport protocol: C->S: INVITE sip:
[email protected] SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Subject: Mr. Watson, here is a fax Content-Type: application/sdp Content-Length: … v=0 o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
44
ITU-T Rec. T.38 (04/2007)
[email protected] t=2873397496 0 c=IN IP4 128.59.19.68 m=image 49170 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC m=image 49172 tcp t38 a=T38FaxRateManagement:localTCF S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Contact: sip:
[email protected] Content-Type: application/sdp Content-Length: … v=0 o=faxwatson 4858949 4858949 IN IP4 192.1.2.3 c=IN IP4 boston.bell-tel.com m=image 5002 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC m=image 0 tcp t38
For a two-party facsimile-only call between T.38 gateways, when RTP encapsulation is used in conjunction with the UDP transport protocol: C->S: INVITE sip:
[email protected] SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Subject: Mr. Watson, here is a fax Content-Type: application/sdp Content-Length: … v=0 o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
[email protected] t=2873397496 0 c=IN IP4 128.59.19.68 m=audio 49170 RTP/AVP 100 101 a=rtpmap:100 t38/8000 a=fmtp:100 T38FaxRateManagement=transferredTCF a=rtpmap:101 parityfec/8000 a=fmtp:101 49173 IN IP4 128.59.19.68 m=image 49172 tcp t38 a=T38FaxRateManagement:localTCF S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Contact: sip:
[email protected] Content-Type: application/sdp Content-Length: … v=0 o=faxwatson 4858949 4858949 IN IP4 192.1.2.3 c=IN IP4 boston.bell-tel.com m=audio 5002 RTP/AVP 100 101
ITU-T Rec. T.38 (04/2007)
45
a=rtpmap:100 t38/8000 a=fmtp:100 T38FaxRateManagement=transferredTCF a=rtpmap:101 parityfec/8000 a=fmtp:101 5004 IN IP4 192.1.2.3 m=image 0 tcp t38
This example shows forward error correction (FEC) as defined for RTP media streams in RFC 2733. In this case, a separate UDP port is allocated to the FEC stream. For the case when RFC 2198 encapsulation is used in conjunction with FEC, the SDP descriptors in this example will need to be modified per RFC 2733. For secure RTP, the third field (transport protocol) on the 'm=' lines would have been RTP/SAVP rather than RTP/AVP. For a two-party voice and fax call between gateways, when RTP encapsulation is used in conjunction with the UDP transport protocol: C->S: INVITE sip:
[email protected] SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Subject: Mr. Watson, here is a fax Content-Type: application/sdp Content-Length: … v=0 o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
[email protected] t=2873397496 0 c=IN IP4 128.59.19.68 m=audio 49170 RTP/AVP 121 0 100 a=rtpmap:100 t38/8000 a=fmtp:100 T38FaxRateManagement=transferredTCF a=rtpmap:121 red/8000 a=fmtp:121 100/100 m=image 49172 tcp t38 a=T38FaxRateManagement:localTCF S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID:
[email protected] Cseq: 1 INVITE Contact: sip:
[email protected] Content-Type: application/sdp Content-Length: … v=0 o=faxwatson 4858949 4858949 IN IP4 192.1.2.3 c=IN IP4 boston.bell-tel.com m=audio 5002 RTP/AVP 121 0 100 a=rtpmap:100 t38/8000 a=fmtp:100 T38FaxRateManagement=transferredTCF a=rtpmap:121 red/8000 a=fmtp:121 100/100 m=image 0 tcp t38
This example shows redundant encoding for RTP fax as defined in RFC 2198. For G.711 encoding of voice, redundancy is not used.
46
ITU-T Rec. T.38 (04/2007)
D.2.5
Minimum call setup messages
The implementation of this annex shall support the minimum requirements for a SIP client and server as defined in RFC 2543 sections A.1 and A.2: All clients MUST be able to generate the INVITE and ACK requests. Clients MUST generate and parse the Call-ID, Content-Length, Content-Type, CSeq, From and To headers. Clients MUST also parse the Require header. A minimal implementation MUST understand SDP (RFC 2327). It MUST be able to recognize the status code classes 1 through 6 and act accordingly. A minimally compliant server implementation MUST understand the INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also understand CANCEL. It MUST parse and generate, as appropriate, the Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-Forwards, Require, To and Via headers. It MUST echo the CSeq and Timestamp headers in the response. It SHOULD include the Server header in its responses. D.2.6
Mapping of call progress signals
For call setup and call progress, the return signals can be simplified to the following set. These are all returned prior to or instead of a 200 OK response to the INVITE request. Table D.1 – Call progress mapping Meaning
SIP response mapping
Busy1. Subscriber busy tone as defined in ITU-T Rec. E.180/Q.35.
486 Busy here
Busy2. Sometimes referred to as Distinctive Busy on some PABX models.
486 Busy here
Congestion busy as defined in ITU-T Rec. E.180/Q.35.
600 Busy everywhere
Ring1. Ringing tone as defined in ITU-T Rec. E.180/Q.35. This is an intermediate call progress indicator. It can be used to generate a ringback signal to the originating G3FE as if it there were an end-to-end PSTN connection.
180 Ringing
Ring2. Ringing tone similar to Ring1 where two short rings are generated instead of one long ring. This is an intermediate call progress result.
180 Ringing
SIT Intercept. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. 503 Service Unavailable Intercept Tone is one combination of tones − frequency and duration. SIT vacant. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. Circuit Vacant Tone is one combination of tones – frequency and duration.
503 Service Unavailable
SIT Reorder. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. Reorder Tone is one combination of tones − frequency and duration.
503 Service Unavailable
SIT No Circuit. Special Information Tones are defined in ITU-T Rec. E.180/Q.35. No Circuit Tone is one combination of tones – frequency and duration.
503 Service Unavailable
NOTE − SIT tones are not distinguished because it generally indicates a problem with the number dialled.
The 200 OK message in response to an INVITE request is returned when the gateway, by some means, determines that a connection to the terminal G3FE has been established. If CED or FSK flags are detected, the appropriate T.38 messages can be sent. D.2.7
DTMF transmission
SIP can transfer collected DTMF dialling digits as a SIP URL as defined in RFC 2543 section 2: sip:
[email protected];user=phone DTMF transmission during an established voice and facsimile connection may be completed using the RTP tone payload described in RFC 2833. ITU-T Rec. T.38 (04/2007)
47
D.2.8
Interoperability
Both SIP and Annex B require a well-known port to initiate call signalling. As described in SIP, its well-known port is 5060. Endpoints in this annex shall use the SIP well-known port by default.
48
ITU-T Rec. T.38 (04/2007)
Annex E H.248.1 call establishment procedures E.1
Introduction
This annex describes system level requirements and procedures for Internet-aware facsimile implementations and Internet-aware facsimile gateways conforming to ITU-T Rec. T.38 to establish calls with other T.38 implementations using ITU-T Rec. H.248.1 and either one of the following procedures: a) A media gateway controlled paradigm via the procedures defined by ITU-T Rec. H.248.1. This paradigm shall be referred to as the T.38 MGC Transitioning method. Using this method a call is setup using the normal procedures as described in ITU-T Rec. H.248 (see [E1]), but if T.38 has to be supported, the packages as described in ITU-T Rec. H.248.2 [E2] are taken into account, so the detection and generation of fax tones are enabled. Upon detection of fax signals, the MGC is notified by the emitting MG about the event, and gives the command to the receiving part via its controlling MGC to generate the signals. Answering signals are handled in the same way. When all signals needed are communicated between both fax terminals via the MGs and MGCs, the MGCs will modify the contexts to put them into fax-mode. This scenario can take up to 20 Megaco commands. b) A paradigm that allows for transitioning between a VoIP call and a FoIP call (using T.38) by media gateways (MG) that support T.38 without the real-time intervention of a media gateway controller (MGC). Note that throughout this annex the term "media gateway controller" is used as to indicate a MGC as defined in ITU-T Rec. H.248 as well as a gatekeeper as defined in ITU-T Rec. H.323. The only involvement of the MGC will be during initial connection capabilities negotiation between the media gateways using SDP descriptors. At this stage, both the MGs and the MGCs are unaware of the type of connection (i.e., voice, fax, modem, etc.). The mechanism in this alternative is an optional procedure that complements the existing mechanisms in Annex B (H.323 procedures), Annex D (SIP-SDP procedures), Annex E (H.248.1 procedures), and Annex D/H.323. This paradigm shall be referred to as the T.38 Autonomous Transitioning method. E.2
Communication between gateways
E.2.1
Overview
E.2.1.1
Gateway architecture
The method described in this annex is intended for use in conjunction with other methods in a decomposed gateway model as shown in Figure E.1. In this model, the media gateway controller (MGC) has knowledge of all the endpoints within a domain and has control over connections being created and terminated at its media gateways (MG).
ITU-T Rec. T.38 (04/2007)
49
SS7
PSTN
SG
SG
MGC
MGC
MG
IP network
MG
SS7
PSTN
T.38_FE.1
Figure E.1 − Typical decomposed model The mechanism in this annex complements the mechanism of Annex D/H.323 (which describes a simple case without a decomposed gateway). In the situation where more than one MGC is involved in a call, the mechanism in this annex (other methods are for further study) is used to signal between them. E.2.1.2
Call setup
Call setup for implementations compliant to this annex is based on ITU-T Rec. H.248.1. As in the basic Annex B, implementations may operate in two distinct compatible environments: 1)
A facsimile-only over IP environment − In this environment, no voice support is provided. The procedures and requirements of D.2.2.1 shall apply to implementations operating in this environment.
2)
A facsimile and voice over IP environment − The procedures and requirements of E.2.2.2 shall apply to implementations operating in this environment.
E.2.1.3
Media channels
T.38 facsimile packets are sent on a separate TCP/UDP port from H.248 message transport. A minimal implementation of this annex requires a TCP port for call signalling and either a UDP port or a TCP port for T.38 facsimile information. E.2.2
Basic call setup
According to 8.2.1/H.248.1: – the connection model for the protocol describes the logical entities, or objects, within the media gateway that can be controlled by the media gateway controller. The main abstractions used in the connection model are Terminations and Contexts; – a termination is an object that sources and/or sinks media streams; – a context represents a collection of terminations in a single conference. Terminations recognize events that invoke a response by the MGC to create another event (e.g., recognizing off-hook invokes play dial tone). This interaction proceeds throughout a typical call setup process initiated at the MG (e.g., H.323 Fast Connect Setup).
50
ITU-T Rec. T.38 (04/2007)
It shall be possible to establish a facsimile over IP call using either of the following two mechanisms: 1) T.38 MGC Transitioning method: A mechanism in which the MGC decides when and whether it is possible to transition from VoIP to T.38 FoIP based in tone events sent to it (via H.248 and the packages described in Annex F/H.248) by the MGs. For H.248 it is described in E.2.2.1. In an H.323 environment, the replacement of a voice channel with a T.38 channel is done according to the procedures of D.5/H.323. 2) T.38 Autonomous Transitioning method: A mechanism for transitioning between a VoIP call and a FoIP call (using T.38) by MGs without the intervention of a media gateway controller (MGC), as described in E.2.2.2, or without the need to request modification of a call as described in Annex D (SIP/SDP). Note that the packages described in H.248.2 are not needed when supporting this method. In an H.323 environment, the procedures of D.3/H.323 (fastStart) or D.4/H.323 (non-fastStart) are used to setup two parallel channels. A MG shall indicate support of the T.38 Autonomous Transitioning method by including in the initial capabilities exchange or setup message support for both audio and image/t38 media streams, using mechanisms described below. Media gateways that use SDP (see [E3]) to exchange capabilities (such as, but not limited to, SIP or H.248 MGs), shall indicate support for the T.38 Autonomous Transitioning method by including in the first SDP to be exchanged at least two media descriptors (i.e., "m=…" lines), one of type audio and one media descriptor of type image/t38, in which the port number is not set to zero (this is for compatibility with SIP terminals, for which setting the port to zero means non-support of that media type). This is illustrated in the following examples, which show only the SDP portion and in which only the media line is important. Also, note that when using H.248, the media descriptors must be separated by a version descriptor (aka v-line), as shown in Appendix III: • SDP examples illustrating support of the T.38 Autonomous Transitioning method: – Example 1: v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 0 (… additional attributes may be included) m=image 4444 udptl t38 a=T38FaxVersion:1 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBufferSize:2000 a=T38MaxDatagram:512 a=T38MaxBitRate:14400 (… additional attributes may be included)
–
Example 2: v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 0 8 13 a=ptime:20 (… additional attributes may be included) m=audio 1111 RTP/AVP 18 129 a=ptime10 a=rtpmap:129 telephone-event/8000 a=fmtp:129 0-15 (… additional attributes may be included)
ITU-T Rec. T.38 (04/2007)
51
m=image 4444 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC (… additional attributes may be included)
•
SDP examples illustrating non-support of the T.38 Autonomous Transitioning method: – Example 3: v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 0 8 13 140 a=ptime:20 a=rtpmap:140 telephone-event/8000 a=fmtp:140 0-15 (… additional attributes may be included) m=image 0 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBufferSize:1536 a=T38MaxDatagram:512 (… additional attributes may be included)
–
Example 4: v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 0 8 13 140 a=ptime:20 a=rtpmap:140 telephone-event/8000 a=fmtp:140 0-15 (… additional attributes may be included)
–
Example 5: v=0 c=IN IP4 124.124.124.222 m=image 8190 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBufferSize:2000 (… additional attributes may be included)
Note that examples 3 and 4 shall be construed as indicating that, at the instance of time the SDP was exchanged, the T.38 Autonomous Transitioning method shall not be used, as well as indicating that the media gateway that sent the SDP does not support (at that instance of time) ITU-T Rec. T.38. In such a case the call will proceed as mandated by the call establishment control protocol being used (which may be, but not limited to, H.323, SIP, or H.248); if it is H.248, then the procedures in E.2.2.1 shall be used. Also, note that, although in examples 3 and 4 the SDP does not indicate support of T.38, this does not mean that either the MG or the MGC cannot request, at a later stage of the call, to transition to T.38 by sending a new SDP (for example within an H.248 Modify command or a SIP INVITE command) containing a media attribute of type image/t38 (as described either in Annex D or in E.2.2.1). Example 5 will cause both MG to immediately transition to FoIP (using T.38); however any future transitioning to any other mode of operation (e.g., voice, voiceband data, etc.) shall be controlled by the MGC. An H.323-capable media gateway shall indicate support of the T.38 Autonomous Transitioning method during the H.245 capabilities exchange by opening two parallel channels in each direction, one for voice, the other for T.38, as described in D.3/H.323 for fastStart or in D.4/H.323 for 52
ITU-T Rec. T.38 (04/2007)
non-fastStart. Two MGs that mutually support the T.38 Autonomous Transitioning method shall autonomously, on detection of the appropriate facsimile signals or on reception of a T.38 UDP (or TCP) packet at its T.38 UDP (or TCP) port, mute the audio channel and transition to the T.38 channel. The media gateway controller shall decide at the start of the call which method to use (i.e., whether to control the transitioning from audio to facsimile or to let the MGs autonomously transition), based on data derived from capability messages exchanged as described above between the media gateways. Hence, the MGC shall not control the transition between VoIP and FoIP only if both MGs that are establishing the connection have mutually indicated that they support the T.38 Autonomous Transitioning method (by the means described above). Note that in H.323 fastStart, there is no explicit negotiation of which method to use, autonomous or MGC-based: the fastStart element will indicate that the call is either a pure voice call (which may turn out eventually to be switched to a T.38 call using D.5/H.323), or it may consist of a separate channel for voice and a separate channel for T.38 as per D.3/H.323. The latter shall be used by an MGC (i.e., Gatekeeper) as indication that the MGs shall use the T.38 Autonomous Transitioning method. When non-fastStart procedures are used, the terminal capability negotiation will indicate if T.38 and voice can be used simultaneously or not (the terminal capability negotiation procedures may also be used after a fastStart call setup, and will be instrumental in indicating that the autonomous or MGC switchover procedures are supported). Absence of an MG indicating support of the T.38 Autonomous Transitioning method must be construed, by both the MGs and the MGCs, as an indication to use the existing call establishment procedures which depend on the call control protocol being used (SIP, H.323 or H.248), which can be one of the following: – T.38 MGC Transitioning method (for H.248) described in E.2.2.1; – the method described in Annex B (H.323 procedures); – the procedure described in Annex D (SIP/SDP procedures). The fact that a MGC knows that the T.38 Autonomous Transitioning method shall be used for a particular call does not preclude the possibility of the MGC to request to receive notifications from the MGs indicating detection of facsimile tones or transition to FoIP (using T.38). The possible usage of such notifications is out of the scope of this Recommendation. E.2.2.1
T.38 media gateway controller (MGC) method
Note that two cases exist for the use of this mechanism: 1) If the call agent (MGC & Gatekeeper) controls both MGs, then H.248 and the packages described in Annex F/H.248 are used to modify the existing connection between the two MGs. 2) If different call agents are involved (e.g., when two different service providers are involved in completing a call), then MGC-MGC communication is required (i.e., using the mechanism of Annex D). On confirmation of a connection, the on-ramp call agent instructs its media gateway (via H.248) to initiate a T.38 session with the off-ramp MG. This method of transitioning from VoIP to FoIP shall be the default method unless the MGs have indicated mutual support of the T.38 Autonomous Transitioning method using the mechanisms described in this clause.
ITU-T Rec. T.38 (04/2007)
53
E.2.2.1.1 Facsimile-only connection Digits are collected by the media gateway (MG) and sent to the calling agent to invite the called party on a facsimile call. Once connected, the call proceeds as in Annex B. E.2.2.1.2 Voice and facsimile connection Digits are collected by the media gateway (MG) and sent to the calling agent to invite the called party to a voice connection as defined in ITU-T Rec. H.248.1. A voice connection is set up. Upon detection of CNG by the emitting media gateway (MG), the calling agent is informed (via H.248.1) of this event and instructs the destination MG to play CNG. If the destination MG then notifies the MGC of a CED (or V.21 flags) event and is capable of T.38, the MGC requests that each MG open a T.38 connection. Details for discrimination of the call as facsimile is described in clause 8/H.248.2. The MGC may also request that a new MG handle the facsimile connection. The T.38 protocol proceeds with a T.38 V.21 flags indicator packet. Note that if T.38 is not supported by one of the MGs, the MGC may decide to attempt the facsimile call over G.711 (using G.711 in this case is beyond the scope of this annex). Full flexibility of switching between MGs (e.g., voice+facsimile, voice-only or facsimile-only) and deciding on options will not be possible if the MGC is not notified of the facsimile events (and the MG alone detects facsimile and switches blindly to T.38). Upon completion of the facsimile call (T.38 completion) by the off-ramp media gateway (MG), the calling agent is informed (via H.248.1) of this event and may request that the connection be reverted to voice. E.2.2.2
T.38 Autonomous Transitioning method
To use this method the MGs must mutually agree to do so at the start of the call. Refer to E.2.2 (Basic call setup) for the mechanisms to be used by an MG to indicate to the MGC and the remote MG that it supports the T.38 Autonomous Transitioning method. The MG will negotiate at the start of the call all possible media descriptors; thus, an audio descriptor and an image/t38 descriptor would both be included. Therefore, T.38 options of a subsequent fax phase to the call are negotiated at the same time as the audio parameters. Note that for the case of using H.248 call setup procedures, the fact that both MGs may have indicated in the audit that they support T.38 as well as audio (and responded with two media descriptor lines) shall not be used as an indication of support of the T.38 Autonomous Transitioning method. It shall be in the creation of a context where support of the T.38 Autonomous Transitioning method is indicated. Hence, the H.248 MGC will need to include both an audio and an image descriptor in the Local descriptor portion of the Add Ephemeral command (refer to III.2.2 3) for an example, with the port numbers set to $, and with the ReserveGroup property, of the LocalControl descriptor, set to True, thus effectively asking the MGs to reserve resources for both the image and audio descriptors. However, if for some reason, (e.g., lack of resources) both audio and image resources cannot be reserved at the time of the start of the call, the image media descriptor, within the response SDP, shall either have its port set to zero (recommended for compatibility with SIP capable terminals) or be omitted altogether, thus indicating non-support of the T.38 Autonomous Transitioning method as well as initializing the call as voice, and hence by default both gateways and the media gateway controller shall use the MGC method. E.2.2.2.1 Facsimile-only connection Digits are collected by the media gateway (MG) and sent to the calling agent to invite the called party on a facsimile call. Once connected, the call proceeds as in Annex B. 54
ITU-T Rec. T.38 (04/2007)
E.2.2.2.2 Voice and facsimile connection Digits are collected by the media gateway (MG) and sent to the calling agent to invite the called party to a voice connection as defined in ITU-T Rec. H.248. Because the MGC and the MGs have no indication that a call is going to be voice or facsimile, the MGs shall set up a voice connection and no T.38 packets are sent. The MGs remain in this mode until they detect such criteria (refer to E.2.2.2.2.1) that cause them to determine that a fax call is starting. At this point the MGs shall start the image/t38 connection and mute the audio connection. The MGs will remain in fax mode until they detect such criteria that cause them to determine that the fax transmission is complete, at which point they will mute the image/t38 connection and re-enable the audio/RTP connection. This process may continue indefinitely until the call is terminated. E.2.2.2.2.1
MG-to-MG signalling of facsimile tones/signals
When using voice high-compression encoding techniques such as, but not limited to, G.729, some fax tonal signals may not get correctly transported across the packet network. Hence, it is recommended that a gateway detect these signals and transport them across the packet network via other mechanisms. The following methods exist to pass information about the detected signals and tones to the peer fax terminal over the packet network: Method 1 Tone pass through: The tone is sent in-band using a lower compression algorithm such as the one used for Voiceband Data (VBD), e.g., encoded using G.711 or G.726-32k over RTP/UDP/IP. Upon detection of a tone, the MG switches autonomously to VBD, in which mode an appropriate codec is used (e.g., G.711), and passes the tone in the voice RTP payload. The receiving gateway has to detect the tone from the packet network, and has to switch to VBD, to pass the signal to the fax terminal. This method should only be used if both media gateways have indicated support of a common lower compression codec or support of the VBD state. The mechanisms used for indicating such support may be via SDP exchange or other mechanisms, which are outside the scope of this Recommendation. Method 2 Tone relay (RFC 2833 – RTP Payload Format for Telephony Tones); see [E4]. All information needed to regenerate the tone is passed in the RTP payload. The BIWF in the peer MG has to generate the tones towards the fax terminal. Before using this method, it is recommended that media gateways should mutually indicate support of this method via SDP (see [E3]) exchange or other call capability exchange mechanisms, which are beyond the scope of this Recommendation. A gateway that does not support this RTP payload type must be capable of discarding these packets without affecting its operation. Method 3 Tone detection indication (RFC 2833 – RTP Payload Format for Named Telephone Events): Event messages (NTE) are used to pass events as described in RFC 2833 [E4], chapter 3.11 (Data modems and Fax Events). The peer MG may use this message to switch to VBD or T.38, dependent of the current state, and shall generate the tones with the characteristics as described in ITU-T Rec. T.30 [E5].
ITU-T Rec. T.38 (04/2007)
55
When using this method, the following events are to be sent, as defined in Table 3 of RFC 2833 [E4]: Event Encoding (decimal) ANS (=CED) 32 CNG 36 V.21 channel 2,"0" bit 39 (see Note) V.21 channel 2,"1" bit: 40 (see Note) NOTE – In the existing RFC 2833, for V.21 preamble flags there exists no RFC 2833 event. Only V.21 channel 2, bit "0" and bit "1" events exist, which are passed to the transmitting MG. To be able to discriminate between a fax and a data call, the receiving MG must be able to decode the preamble flag, out of the RFC 2833 NTE messages. However, there is currently an IETF draft, RFC 2833bis [E6] (in the IETF AVT working group), in which there exists an event for the V.21 preamble flag that has the (decimal) encoding number 52. It is recommended that when RFC 2833bis is approved, an implementation should use this V.21 preamble flags event instead of the V.21 channel 2 bit "0" and bit "1" events.
The number of flags to be detected before switch-over is a parameter which must be chosen in such a way that the receiving MG sends enough RFC 2833 messages towards the transmitting MG, before it switches to T.38. After the switch-over to T.38, the V.21 flags are passed over UDPTL. Before using this method, it is recommended that media gateways should mutually indicate support of the RTP payload types indicated above via SDP (see [E3]) exchange or other call capability exchange mechanisms, which are beyond the scope of this Recommendation. A gateway that does not support these RTP payload types must be capable of discarding these packets without affecting its operation. Method 4 After switch-over to T.38, if the tonal signals still exist, then the media gateway shall send T.38 packets of Type t30-indicator, to signal the presence of facsimile signals. E.2.2.2.2.2
VoIP to FoIP transition criteria
Upon detection of CNG by the emitting media gateway (MG), it is possible to determine with sufficient confidence that it is a facsimile call because CNG is only sent by a G3FE. Hence, if a T.38 capability has been mutually successfully negotiated between the MGs, the MG will switch to T.38 and, in accordance with the T.38 protocol, transmit to the remote MG the T.38 CNG indicator packet. The remote MG will switch to T.38, on receipt at its T.38 UDP (or TCP) port, of the T.38 CNG indicator packet. When in audio/RTP mode, receipt of any T.38 packet at a designated T.38 UDP (or TCP) port, should be a criterion for switching to image/t38 mode (see E.2.2.2.2.1). The implementation of how this is done is out of the scope of this Recommendation. However, one recommended method is that of which, receipt at its local T.38 UDP (or TCP) port of a valid UDP (or TCP) packet can be assumed to be a T.38 packet and hence cause autonomous transition to T.38, if the source IP address of that packet corresponds with that of the remote MG, with which the T.38 Autonomous Transitioning method (as well as the T.38 capabilities) was mutually successfully negotiated, because only T.38 UDPTL packets must be sent to negotiated image/t38 UDP port number. The same applies for T.38 TCP packets. The T.38 UDP (or TCP) port should only be activated if the T.38 Autonomous Transitioning method (and a mutual set of T.38 capabilities) is supported by the MGs establishing the call. (This would avoid falsely transitioning autonomously to T.38 on receipt of any valid UDP packet if T.38 Autonomous Transitioning method is not mutually supported between the MGs.)
56
ITU-T Rec. T.38 (04/2007)
MGs that are operating with the autonomous method must not rely solely on detection of the CNG tone, as this tone is only mandatory for automatic G3FEs and manual G3FEs conforming to the post-1993 version of ITU-T Rec. T.30. If CNG is not present, then the MGs shall transition to T.38 on detection of the V.21 preamble, which is sent by all G3FEs except V.34 G3FEs. V.34 facsimiles use V.8 signals that will have to be detected by the MG in order to support the procedures in clause 10. The T.38 protocol proceeds with a T.38 V.21 flags indicator packet. The emitting MG, on receipt of the T.38 V.21 flags indicator packet, shall transition to T.38 if not already in T.38 mode. Optionally, if mutually supported by the media gateways involved in the call (via SDP exchange or other means), a media gateway may choose to transmit the V.21 preamble to the peer gateway over the packet network using RFC 2833 events (i.e., the method 3 stated in E.2.2.2.2.1). RFC 2833 has defined four dedicated events (37-40) for relaying FSK-encoded binary information per channel. When using this method, RFC 2833 RTP packets shall be generated by grouping events as well as by using the redundancy mechanisms as defined in RFC 2833/RFC 2198. Detection of the call function set to facsimile within the V.8 signals CI/CM/JM shall also indicate transition to image/t38 mode and the procedures in clause 10. See also Annex F. Media gateways that support the T.38 Autonomous Transitioning method should not determine to switch to facsimile based on detection of a CED tone. The CED tone is the same tone as the ANS tone (defined in ITU-T Rec. V.25). The latter tone is sent by some non-fax modems. Note that if T.38 is not supported by one of the MGs, the MGs may decide to attempt the facsimile call over G.711 only if G.711 was received in audio media descriptor (using G.711 in this case is beyond the scope of this annex). E.2.2.2.2.3
FoIP to VoIP transition criteria
The MGs shall autonomously transition from fax (image/t38 connection) to a voice (audio/RTP connection) when the MG detect one of the following: a) Detection of the T.30 DCN message: Following detection of the T.30 DCN message, the MG will transmit the corresponding T.38 packet and subsequently transition to voice. Following receipt of T.38/T.30 DCN packet, the MG will play out the T.30 DCN and subsequently transition to voice. b) Detection of bidirectional silence: It is recommended that an MG transition back to voice mode after detecting more than 7 s of bidirectional silence (this value was chosen in order to allow for the T.30 T2 timer). c) Receipt from the MGC of an appropriate command modifying the call to audio. A H.248 Modify, a SIP INVITE command in which only the audio descriptor is present or the appropriate messages as per D.5/H.323 can do this. E.2.3
Event and signal indication
There are several events and signals that need to be transferred from the MG to the MGC and vice versa during the setup of a fax call. These events are defined in H.248 packages. The base packages are in Annex E/H.248.1. Additional signals for fax are defined in ITU-T Rec. H.248.2. E.2.4
Capabilities negotiation
There are several options that need to be negotiated to determine which options the gateways support and use. These are described in Table B.1 and are defined as SDP extensions in D.2.3. They are also defined as binary types in the IP Fax package of ITU-T Rec. H.248.2.
ITU-T Rec. T.38 (04/2007)
57
A T.38 Annex E implementation may use the SDP extensions to describe the fax media terminations in text mode of the protocol. An H.248.1 implementation shall use the IP fax package as the preferred method to describe the fax media termination. These media descriptors indicate the capabilities of, or requested of a media gateway (e.g., TCP, UDPTL or RTP transport). In addition, as well as being able to identify that a call is using T.38 transport for facsimile, ITU-T Rec. H.248.1 may also indicate other transports. E.2.5
Examples of call setup
Examples of the T.38 MGC procedure are described in III.2.1 and III.2.2. Examples of the T.38 Autonomous Transitioning method are described in III.2.3 and III.2.4. E.2.6
Minimum call setup messages
The implementation of this annex shall support the minimum requirements for ITU-T Rec. H.248.1 as noted in 8.2/H.248.1. E.2.7
Mapping of call progress signals
For call setup and call progress, the return signals are identical to those in Annex B (for H.323 Fast Connect setup) and Annex D (for SIP). E.2.8
DTMF transmission
ITU-T Rec. H.248 supports collection of DTMF digits to make a call. DTMF tones transmission during an established voice and facsimile call is handled within the DTMF packages of E.5 and E.6/H.248.1. E.2.9
Interoperability
Both ITU-T Rec. H.248.1 and Annex B require a well-known port to initiate call signalling. T.38 Annex E endpoints shall use the H.248.1 well-known port of 2944 for the text protocol and 2945 for the binary protocol. References [E1]
ITU-T Recommendation H.248 (2005), Gateway control protocol.
[E2]
ITU-T Recommendation H.248.2 (2005), Gateway control protocol: Facsimile, text conversation and call discrimination packages.
[E3]
HANDLEY (M.), JACOBSON (V.): SDP: Session Description Protocol, RFC 2327, April 1998.
[E4]
SCHULZRINNE (H.), PETRACK (S.): RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, RFC 2833, May 2000.
[E5]
ITU-T Recommendation T.30 (2005), Procedures for document facsimile transmission in the general switched telephone network.
[E6]
SCHULZRINNE (H.), PETRACK (S.): RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, draft-ietf-avt-rfc2833bis-2.txt, November 2005.
58
ITU-T Rec. T.38 (04/2007)
Annex F Interworking procedures: T.38 and V.150.1 in the same gateway F.1
Introduction
This annex describes the procedures that shall be used by gateways that have both T.38 and V.150.1 capabilities in the same gateway. Such a gateway shall indicate these capabilities by use of the appropriate external signalling mechanism (H.323, H.248 or SIP/SDP) as defined in the relevant Recommendations. The terms "FoIP" and "MoIP" as used in this annex are synonymous to ITU-T Recs T.38 and V.150.1 respectively. This type of gateway shall only transition to FoIP from MoIP. These procedures do not include any transitions directly from audio to FoIP nor do they replace the audio and T.38 configuration procedures as defined in Annexes B, D and E. A gateway with these joint capabilities shall initially behave as a V.150.1 gateway. That is all the call discrimination procedures up to the point at which T.38 procedures are invoked are defined in clause 20/V.150.1. The transition from MoIP to FoIP occurs when a gateway (in MoIP mode) detects and verifies the presence of a T.30 facsimile signal such as V.21 Channel 2 HDLC encoded flags or a V.8 CM signal on the telephony link to the gateway. This switching mechanism shall use State Signalling Event (SSE) protocol as defined in Annex C/V.150.1. Figures F.1 and F.2 illustrate this transition for two facsimile triggering events. Figure F.1 shows a transition to Standard G3 facsimile and Figure F.2 shows a similar transition to V.34 facsimile.
T.38_F1(AF)
Figure F.1 – T.38 FoIP (MoIP transition to T.30 fax)
T.38_F2(AF)
Figure F.2 – T.38 FoIP (MoIP transition to V.34 fax)
ITU-T Rec. T.38 (04/2007)
59
Upon the detection of a facsimile event, the gateway shall transmit a SSE:f(RIC) to the peer gateway, where SSE:f is the FAX RELAY SSE transition indication. RICs are reason identifier codes and are defined in F.2. The use of SSE shall comply with Annex C/V.150.1. ITU-T Rec. V.150.1 defines the SSE:f event code in C.5.2/V.150.1 and it has a decimal value of 4. F.2
SSE reason identifier codes for T.38 transition
The following RICs are defined for the SSE:f event: V21Flags: This RIC indicates that the gateway has detected and verified that it has received HDLC flags modulated on V.21 channel 2 as defined in ITU-T Rec. T.30. V8Profile: This RIC indicates that the gateway has received a V.8 CM sequence that is a valid facsimile connection request. This RIC has as additional information – the Profile and T.66 codes (if present) – that is used in the "t30-data(cm-message)" of this Recommendation. P' State Transition: This is the same signal as used in MoIP. It performs the same behaviour as an ACK. The value is chosen to be consistent with ITU-T Rec. V.150.1. The table below summarizes the RICs for T.38 SSEs. Name
Code (decimal)
Additional informational content
Null
0
None
V21Flags
1
None
V8Profile
2
"cm-message"
p' State Transition
19
None
In both examples, the use of SSE:f may be used as an equivalent signal from T.38. For example SSE:f(V21Flags) may be used as t30-indicator:FLAGS and SSE:f(V8profile(cm-message)) may be used as t30-data:cm-message. A gateway is not required to wait for the SSE:f(p') message in response to its SSE:f request. The gateway shall transmit the equivalent T.38 IFP message immediately after issuing the SSE:fr request. The gateway shall then follow the procedures as defined in this Recommendation. F.3
Mode Override from V.34 Group 3 facsimile to standard Group 3 facsimile
This annex describes a procedure by which V.34 HDX-enabled terminals can be forced by media gateways to operate in standard Group 3 mode. The procedures can be used if both facsimile terminals are V.34 G3FEs and if either or both of the connecting gateways do not support the T.38/V.34 procedures as defined in clause 10. Upon detection of a V.8 CM signal the gateway should determine from the Call Function if the CM is being transmitted by the V.34 capable facsimile terminal. If so verified the ingress gateway shall block the audio transmission and transmit silence. In order to prevent call failure the gateway shall prevent transmission of more than a single CM sequence. Blocking the transmission of CM to the answering terminal will cause a timeout and standard T.30 signals will be generated as a consequence (see Figure 6a/T.30 and Figure 6b/T.30). The transition from MoIP to FoIP occurs when the gateway detects and verifies the presence of a T.30 facsimile signal such as V.21 flags on the telephony link to the gateway. To prevent any further attempts of the terminals to connect using V.34, the V.8 bit in the T.30 DIS message relayed by the gateways should be set to 0.
60
ITU-T Rec. T.38 (04/2007)
This switching mechanism shall use State Signalling Event (SSE) protocol as defined in Annex C/V.150.1 or payload type procedures as defined in clause 10/V.152. Figure F.3 shows a transition to Standard G3 facsimile using SSE switching procedures.
Figure F.3 – T.38 FoIP (MoIP fallback and transition to T.30 fax by SSE)
ITU-T Rec. T.38 (04/2007)
61
Figure F.4 shows a transition to standard G3 facsimile using payload type switching procedures.
Fig ure F.4 – T.38 FoIP (MoIP fallback and transition to T.30 fax by Payload) F.4
External signalling
The use of SSEs is negotiated during the call setup phase. Annexes E and F/V.150.1 describe the SDP and H.323 syntax accordingly to be incorporated by a MoIP/FoIP gateway. NOTE – The definition of the H.248 syntax for ITU-T Rec. V.150.1 is to be defined.
62
ITU-T Rec. T.38 (04/2007)
Annex G H.245 Capability Definition for T.38 over RTP This annex defines a generic H.245 capability that allows for the transport of T.38 over RTP. It is intended that this capability would be signalled as an audioCapability within H.245-based systems. Note that ITU-T Rec. H.245 already defines a T.38 capability for transport of IFP packets over UDP and TCP, which is a dataApplicationCapability. The capability definition in this annex is not intended to replace that definition, but rather to provide a means of transporting T.38 IFP packets over RTP only. Capability name:
T38RTP
Capability class:
Audio Capability
Capability identifier type:
Standard
Capability identifier value:
itu-t (0) recommendation (0) t (20) 38 h245-audio-capability(0)
maxBitRate:
This parameter is optional.
collapsing:
This field shall not be included and shall be ignored if received.
nonCollapsing:
This field shall be present and consist of the parameters defined below.
nonCollapsingRaw:
This field shall not be included and shall be ignored if received.
transport:
This field shall not be included.
Parameters for this capability are defined in the following tables: Parameter name:
BooleanOptions
Parameter description:
This is a nonCollapsing capability. Contains various Boolean options that must be conveyed.
Parameter identifier value:
0
Parameter status:
Mandatory
Parameter type:
BooleanArray LSB is bit 0. Bit value 1 = TRUE. Bit 0 – fillBitRemoval Bit 1 – transcodingJBIG Bit 2 – transcodingMMR All other bits are reserved and shall be ignored.
Supersedes:
–
Parameter name:
Version
Parameter description:
This is a nonCollapsing capability. This identifies the version of the T.38 protocol.
Parameter identifier value:
1
Parameter status:
Optional. If absent, version 0 is assumed.
Parameter type:
unsignedMin
Supersedes:
–
ITU-T Rec. T.38 (04/2007)
63
Parameter name:
T38FaxRateManagement
Parameter description:
This is a nonCollapsing capability. This specifies the fax rate management modes.
Parameter identifier value:
2
Parameter status:
Required. Only one sub-parameter of T38FaxRateManagement may be included in this parameter.
Parameter type:
genericParameter
Supersedes:
–
Parameter name:
T38FaxRateManagement-localTCF
Parameter description:
This is a nonCollapsing capability that is an element of T38FaxRateManagement.
Parameter identifier value:
0
Parameter status:
Optional
Parameter type:
logical
Supersedes:
–
Parameter name:
T38FaxRateManagement-transferredTCF
Parameter description:
This is a nonCollapsing capability that is an element of T38FaxRateManagement.
Parameter identifier value:
1
Parameter status:
Optional
Parameter type:
logical
Supersedes:
–
Parameter name:
t38FaxMaxBuffer
Parameter description:
This is a nonCollapsing capability. This specifies the maximum buffer size.
Parameter identifier value:
3
Parameter status:
Optional
Parameter type:
unsigned32Max
Supersedes:
–
Parameter name:
t38FaxMaxDatagram
Parameter description:
This is a nonCollapsing capability. This specifies the maximum datagram size.
Parameter identifier value:
4
Parameter status:
Optional
Parameter type:
unsigned32Max
Supersedes:
–
64
ITU-T Rec. T.38 (04/2007)
Appendix I Session examples I.1
Session examples
This appendix contains a number of examples to show how the sending and receiving G3FEs communicate with the gateways and what packets the gateways exchange. All examples show a TCP implementation using Method 1 Rate Adaptation. Time proceeds downward. Information flows on the solid lines in the direction of the arrows. The box superimposed on each line indicates what information is being transmitted. All information between the G3FE and a gateway is T.30/T.4/T.6-conforming information. Information transmitted between the gateways is in the form of packets as described in this Recommendation. The contents of the labelling box on a packet transmission indicates the packet type, followed by any additional information which is carried in the packet's payload. Dashed lines are used to clarify the point in time at which a piece of information begins transmission (for example, T30_INDICATOR: Flags packets are sent when flags are noticed, not necessarily when the flags begin or end transmission). Dashed lines do not indicate any type of information flow. Packet labels indicate the type of packet as well as any field information, for field-type packets. For example, a label such as "V.21:HDLC:TSI/FCS" indicates a V.21 HDLC (T.30 Control) packet with a field containing TSI information and a field indicating FCS. Due to space constraints, the FCS is generalized to include FCS and FCS-Sig-End. I.1.1
Two traditional facsimile devices communicating using ECM
Figure I.1 shows two traditional Group 3 facsimile devices that use the PSTN for communicating with facsimile gateways. ECM is used for image transfer. The example begins after the transport connection/session has been established and the receiving G3FE has answered a call from the receiving gateway and is about to generate CED. I.1.2
Traditional facsimile device and Internet-aware facsimile device
Figure I.2 shows a traditional Group 3 facsimile device sending to an Internet-aware facsimile device without using ECM. The example begins after the transport connection/session has been established and the Receiving is about to generate CED. I.1.3
Two traditional facsimile devices using frequent frames
Figure I.3 shows two traditional Group 3 facsimile devices that use the PSTN for communicating with facsimile gateways. It is similar to the scenario described in I.1.1 except that the image transfer does not use ECM and the receiving gateway does not wait for complete HDLC BCS sequences before beginning to send frames.
ITU-T Rec. T.38 (04/2007)
65
V.17:HDLC: Image Data V.17:HDLC: Image Data: FCS-Sig-End
PPSNULL PPSNULL
T.38_FI.1a(APPI)
Figure I.1 – Two Group 3 facsimile devices communicating through gateways (sheet 1 of 2)
66
ITU-T Rec. T.38 (04/2007)
T.38_FI.1b(APPI)
Figure I.1 – Two Group 3 facsimile devices communicating through gateways (sheet 2 of 2)
ITU-T Rec. T.38 (04/2007)
67
Figure I.2 – Traditional facsimile device and Internet-aware device
68
ITU-T Rec. T.38 (04/2007)
MCF
Figure I.3 – Use of multiple frames per BCS sequence
ITU-T Rec. T.38 (04/2007)
69
I.2
IAF device
This clause addresses the sequences that are considered in IAF device communication. I.2.1
Sender is an IAF device, receiver is G3fax
CFR signal receive timing at the IAF device It is recommended that IAF devices wait to receive the CFR signal, taking into account the period during which the Gateway sends TCF to G3fax. As Figure I.4 shows, this prevents the DCS signal of the IAF device from colliding at the Gateway with the CFR signal of the G3fax. IAF
G3fax
DIS DIS DCS DCS
TCF
CFR CFR
Figure I.4 – IAF transmit timing from DCS to CFR
70
ITU-T Rec. T.38 (04/2007)
I.2.2
Receiver is an IAF device, sender is G3fax
CFR signal send timing at the IAF device It is recommended that IAF devices send the CFR signal, after taking into account the period during which the Gateway receives TCF from the G3fax device. As Figure I.5 shows, this prevents the TCF from colliding with the CFR signal from the IAF device. G3fax
IAF
DIS DIS DCS DCS
TCF
CFR CFR
Figure I.5 – IAF receive timing from DCS to CFR
ITU-T Rec. T.38 (04/2007)
71
Appendix II Examples of call establishment procedures described in Annex B/T.38 II.1
Sequence examples of call establishment procedures
II.1.1
Between Annex B/T.38 gateways Annex B/T.38
Annex B/T.38 Sending G3FE
Emitting GW
Receiving GW
Receiving G3FE
Off hook Dial tone Dialling number Q:CALL PROC Q:ALERT
Ringing Off hook
Open FAX channel
c)
Open FAX channel
c)
T.38 session On hook Q:REL COMP
On hook
Q: H: Optional Conditional
72
ITU-T Rec. T.38 (04/2007)
Q.931 message within H.225.0 H.245 message
II.1.2 II.1.2.1
Between Annex B/T.38 and Annex D/H.323 gateways Normal connection and disconnection sequence (Annex B/T.38 supporting only FAX) Annex D/H.323
Sending G3FE
Annex B/T.38 Receiving GW Receiving G3FE
Emitting GW Off hook Dial tone Dialling number Q:CALL PROC
Ringing
Q:ALERT
Off hook Q:FACILITY
c)
Q:FACILITY
c)
Open FAX channel Open FAX channel
T.38 session On hook Q:REL COMP
On hook
ITU-T Rec. T.38 (04/2007)
73
II.1.2.2
Normal connection and disconnection sequence (Annex B/T.38 supporting FAX and voice) Annex B/T.38
Annex D/H.323 Sending G3FE
Emitting GW
Receiving GW
Receiving G3FE
Off hook Dial tone Dialling number Q:CALL PROC Ringing
Q:ALERT
Off hook
Voice session Open FAX channel
c)
c)
Open FAX channel
T.38 session On hook Q:REL COMP
On hook
74
ITU-T Rec. T.38 (04/2007)
II.1.2.3
Connection rejected sequence 1 (when the calling side, Annex D/H.323, does not support Fast Connect Procedures) Annex B/T.38
Annex D/H.323 Sending G3FE Emitting GW
Receiving GW
Receiving G3FE
Off hook Dial tone Dialling number Q:REL COMP
a)
II.1.2.4
a)
Annex B/T.38 implementation rejects connection by sending Q.931: RELEASE COMPLETE when it receives SETUP message without fastStart element.
Connection rejected sequence 2 (when the called side, Annex D/H.323, does not support Fast Connect Procedures)
Annex B/T.38 Sending G3FE
Annex D/H.323 Receiving GW
Emitting GW
Receiving G3FE
Off hook Dial tone Dialling number
Q:REL COMP
a)
ITU-T Rec. T.38 (04/2007)
75
II.1.3 II.1.3.1
Between Annex B/T.38 supporting FAX and Annex D/H.323 gateways that are both registered to the same Gatekeeper Normal connection sequence (when Gatekeeper has chosen Direct Call Signalling)
II.2
Protocol data used in call establishment procedures
II.2.1
General
Two Recommendations − ITU-T Rec. H.225.0 (as a subset of ITU-T Rec. Q.931) and ITU-T Rec. H.245 − define the protocol data used in Call establishment procedures of Annex B, while ITU-T Rec. H.323 gives the general protocol design of the whole system. For example SETUP message is defined in Table 13/H.225.0 and its User-user Information Element (UUIE) is defined as Setup-UUIE under H323-UU-PDU in ITU-T Rec. H.225.0. Then fastStart element which is defined as SEQUENCE OF OCTET STRING by ASN.1 definition of Setup-UUIE encapsulates OpenLogicalChannel which is defined under MultimediaSystemControlMessage in ITU-T Rec. H.245.
76
ITU-T Rec. T.38 (04/2007)
Additionally, RAS messages need to be understood to fully implement Annex B. RAS is also defined in ITU-T Rec. H.225.0 as RasMessage using ASN.1 and Table 18/H.225.0 gives its support requirements. II.2.2
Examples of the protocol data
II.2.2.1
Supported H.225.0 (Q.931) message types
Tables II.1 to II.3 show the supported H.225.0 (Q.931) message types in three phases. Table II.1 − Messages of call setup phase Message type
transmit
receive
CMa)
M
a)
M
ALERT CALL PROC
CM
CONNECT
M
M
CONNECT ACK
F
F
PROGRESS
O
O
SETUP
M
M
SETUP ACK
O
O
M
Mandatory
O
Optional
F
Forbidden
CM
Conditional Mandatory
a)
Note that gateways shall send ALERT and CALL PROC messages while IAF (Internet-aware fax) may not send them. Note that an Annex D/H.323 GW may send ALERTING or CALL PROC to an IAF.
Table II.2 − Messages of call release phase Message type
transmit
receive
DISCONNECT
F
F
RELEASE
F
F
RELEASE COMP
M
M
Table II.3 − Messages of other phase Message type FACILITY a)
transmit
receive
CMa)
Ma)
Note that Annex B/T.38 implementation shall receive and send FACILITY when connecting to Annex D/H.323 implementation.
II.2.2.2
Information elements of SETUP
Tables II.4 to II.6 show information elements of SETUP message.
ITU-T Rec. T.38 (04/2007)
77
Table II.4 − Information elements of SETUP Information element Protocol discriminator Call reference Message type Bearer capability Calling party number Calling party subaddress Called party number Called party subaddress User-user
Parameter
Status
Reference H.225.0 Reference H.225.0 Reference H.225.0 Reference H.225.0 Reference H.225.0 Reference H.225.0 Reference H.225.0 Reference H.225.0 protocolIdentifier SourceInfo destinationAddress destCallSignalAddress
M M M M O CM O CM M M M M
activeMC conferenceID conferenceGoal callType callIdentifier mediaWaitForConnect canOverlapSend
M M M M M M M
fastStart
M
Description
H.225.0 version number EndpointType Used by Gatekeeper TransportAddress (IP address + Port number) FALSE NULL NULL PointToPoint GloballyUniqueID TRUE if TRUE, support overlap sending Reference Table II.5
Table II.5 − Parameters of fastStart(OpenLogicalChannel) Parameters ForwardLogicalChannelNumber ForwardLogicalChannelParameters PortNumber DataType
MultiplexParameters ReverseLogicalChannelParameters DataType
MultiplexParameters
78
ITU-T Rec. T.38 (04/2007)
Description
Reference Table II.6 dateType is linked with DataApplicationCapability in Annex B. Note that DataApplicationCapability in Annex B is only extraction among CHOICEs of application of H.245. sessionID, mediaChannel and mediaControlChannel in H2250LogicalChannelParameters Reference Table II.6 dateType is linked with DataApplicationCapability in Annex B. Note that DataApplicationCapability in Annex B is only extraction among CHOICEs of application of H.245. sessionID, mediaChannel and mediaControlChannel in H2250LogicalChannelParameters
Table II.6 − Parameters of dataType(DataApplicationCapability) Parameter
Status
Description
Application
−
t38fax
M
t38FaxProtocol
M
t38FaxProfile
M
FilBitRemoval
M
TranscodingJBIG
M
TranscodingMMR
M
Version
M
t38FaxRateManagement
M
t38FaxUdpOptions
O
t38FaxMaxBuffer
O
t38FaxMaxDatagram
O
t38FaxUdpEC
O
CHOICE index shall be encoded to indicate the use of t38UDPFEC or t38UDPRedundancy.
M
Units 100 bit/s
MaxBitRate
II.2.2.3
CHOICE index shall be encoded to indicate the use of t38fax. CHOICE index of DataProtocolCapability shall be encoded to indicate the use of TCP or UDP.
CHOICE index shall be encoded to indicate the use of localTCF or transferredTCF.
Information elements of ALERT
Table II.7 shows information elements of ALERT message. Table II.7 − Information elements of ALERT Information element
Parameter
Status
Protocol discriminator
Reference H.225.0
M
Call reference
Reference H.225.0
M
Message type
Reference H.225.0
M
User-user
Reference H.225.0
M
II.2.2.4
Description
Information elements of CALL PROC
Table II.8 shows information elements of CALL PROC message. Table II.8 − Information elements of CALL PROC Information element
Parameter
Status
Protocol discriminator
Reference H.225.0
M
Call reference
Reference H.225.0
M
Message type
Reference H.225.0
M
User-user
Reference H.225.0
M
Description
ITU-T Rec. T.38 (04/2007)
79
II.2.2.5
Information elements of CONNECT
Table II.9 shows information elements of CONNECT message. Table II.9 − Information elements of CONNECT Information element
Parameter
Status
Description
Protocol discriminator
Reference H.225.0
M
Call reference
Reference H.225.0
M
Message type
Reference H.225.0
M
User-user
protocolIdentifier
M
H.225.0 version number
destinationInfo
M
EndpointType
conferenceID
M
NULL
callIdentifier
M
GloballyUniqueID
FastStart
M
Reference Table II.5
II.2.2.6
Information elements of RELEASE COMPLETE
Table II.10 shows information elements of RELEASE COMPLETE message. Table II.10 − Information elements of RELEASE COMPLETE Information element
Parameter
Status
Protocol discriminator
Reference H.225.0
M
Call reference
Reference H.225.0
M
Message type
Reference H.225.0
M
Cause
Reference H.225.0
CM
User-user
Reference H.225.0
M
II.2.2.7
Description
Either the Cause IE or ReleaseCompleteReason in User-user shall be present.
Information elements of FACILITY
Table II.11 shows information elements of FACILITY message. Table II.11 − Information elements of FACILITY Information element
Parameter
Status
Description
Protocol discriminator
Reference H.225.0
M
Call reference
Reference H.225.0
M
Message type
Reference H.225.0
M
User-user
protocolIdentifier
M
H.225.0 version number
reason
M
FacilityReason
callIdentifier
M
GloballyUniqueID
80
ITU-T Rec. T.38 (04/2007)
Appendix III H.248 call establishment procedure examples for facsimile-capable media gateways III.1
Introduction
This appendix describes examples of the procedures for Internet-aware facsimile implementations and Internet-aware facsimile gateways conforming to this Recommendation to establish calls with other T.38 implementations using the procedures defined by Annex E and ITU-T Rec. H.248. In addition, this appendix describes examples of MG/MGC interactions for establishing a call between H.248 endpoints and H.323 endpoints. The examples are divided into two main categories: • Call setup procedures that allow MGs to transition from voice/audio state to T.38 state using the MGC controlled method; • Call setup procedures that allow MGs to autonomously transition from voice/audio state to T.38 state. III.2
Examples of call setup
III.2.1 Voice to fax call setup with H.248 endpoints using the T.38 Transitioning Method This call flow example describes a voice call that originates and terminates in the SCN and is transported through the packet network. The packet network signalling in this example is not specified but any signalling protocol such as H.323 or SIP can be used – the purpose of the example is to describe MG/MGC interactions, involved when the MGs and the MGC support the MGC procedure, including the detection of fax and switching from voice to fax.
ITU-T Rec. T.38 (04/2007)
81
Figure III.1 – Voice to fax call setup with H.248 endpoints
82
ITU-T Rec. T.38 (04/2007)
The sequence of events is as follows: 1) At some point before a call, the media gateway controller will have issued an audit capabilities command to the media gateways under its control and will know what the voice and fax capabilities are for each gateway. In the scenarios below, if both Media Gateways support T.38, then this is the preferred mode for IP fax operations. In the event that one or both media gateways do not support T.38, then the fax call may proceed over the IP voice channel. However, since T.30 facsimile may fail over a compressed voice codec, it would be preferable to use a G.711 codec for communication between the media gateways. 'W-' is used to indicate that a wild-card answer with a union of information on all terminations on the MG is requested, not an audit of each termination on the MG. In the example MG1 indicates support of T.38, however the audit shall not be used to infer support of either the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method as described in E.2.2. This shall be done on a call-by-call basis during the Add Ephemeral (see point 3 below). The MGC audits MG1. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9 { Context = - {W-AuditValue = * {Audit{Packages}}} }
MG1 replies. MG1 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 9 { Context = - { AuditValue = * { Packages {al, rtp, ipfax, fax, ctyp, cg} ; al = analog line pkg, rtp = rtp pkg, ipfax = T.38 fax pkg, fax = fax pkg ; ftmd = fax/textphone/modem tones detection pkg ; ctyp = Call Type Discrimination package) ; cg =call progress tones generator pkg } } }
MEGACO/1 [123.123.123.4]:55555 Transaction = 10 { Context = - {W-AuditCapabilities = * {Audit{Media }}} }
MG1 replies. MG1 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 10 { Context = - { AuditValue = * { Media { Stream = 1 { Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 18 v=0 c=IN IP4 $ m=image $ udptl t38 } ; RTP profile for G.711 is 0, G.729 is 18, t38 is T.38 } }, } } }
ITU-T Rec. T.38 (04/2007)
83
A similar exchange happens between the MGC and MG2. 2) The End User decides to send a fax from device F1 and enters the phone number. The fax device gets dial tone and then dials the phone number. As a result, the central office within the local SCN loop sends an SS7 message to the signalling gateway (SG). The SG sends a Setup message to the MGC after receiving this IAM from a SCN switch that conveys the called and calling phone numbers. SCTP (for example) carries the SS7 signalling from the SG to the MGC. 3) From the IAM message, the MGC may infer which circuit on which MG is involved and where to terminate the call. How the MGC does this is outside the scope of this appendix. The endpoints are found by the media gateway controller (MGC) and it sets up the audio channel between the two media gateways and instructs the SS7 facility of the receiving CO to connect to the end phone destination, which results in the generation of ringing. So, to start, the controller determines that a connection needs to be made from MG1 to MG2. The MGC creates a Context for the call. Both the TDM termination DS0/1/1, and an RTP termination are added to a new context in MG1. Mode is ReceiveOnly since Remote descriptor values are not yet specified. Preferred codecs are in the MGC's preferred order of choice. The MGC sets to CHOOSE (i.e., $) the fields in the SDP in the Local descriptor that the MG will set itself. Also, in order for the MGC to infer whether both gateways support the T.38 Autonomous Transitioning method or T.38 MGC Transitioning method, the MGC instructs MG1 to respond with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities. Note that this is achieved by including in the LocalControl descriptor "ReserveGroup=True" to ask the MG to reserve resources for both audio and image media descriptors. In addition "ReserveValue = True" to ask the MG to reserve resources for all the possible codecs offered in the media descriptor (alternatively, an MGC may include ReserveValue=false to ask for the most preferred codec; however, if omitted, a MG by default must set this value to false). MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 {al/on, ctyp/dtone } }, ; SCN termination prepared to listen for tones Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, ReserveGroup = True, ReserveValue = True}, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 }; IP termination for audio } } } } }
4)
84
MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. In this example, MG1 supports both offered codecs, hence returns both codecs in the same preference order provided by the MGC (thus leaving the final choice to MG2). MG1 sets the RTP port to 2222. Also, because MG1 does not support the T.38 Autonomous
ITU-T Rec. T.38 (04/2007)
Transitioning method for transitioning between VoIP and FoIP, it omits the image media descriptor line all together (alternatively, it could have set the T.38 port to 0). MEGACO/1 [124.124.124.222]:55555 Reply = 11 { Context = 2000 { Add = DS0/1/1, ; SCN termination added Add = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 0 ;MG1 supports both offered codecs a=ptime:20 } ; IP termination added } } } } }
5)
Assume that the MGC has control over the remote MG2 also. The MGC, based on the reply of MG1, has inferred that the T.38 MGC Transitioning method shall be used to transition between VoIP and FoIP, and will now associate DS0/2/2 with a new Context on MG2, and establish an RTP Stream (i.e., RTP/2 will be assigned), SendReceive connection through to the originating user, User 1. MGC includes in the LocalControl descriptor of the ephemeral termination the property "ReserveValue=False" to indicate to MG2 to select a codec.
MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Add = DS0/2/2 { Media { Stream = 1 { LocalControl {Mode = SendReceive } } }, Events = 10 {al/of, ctyp/dtone }, Signals = {al/ri } } }, Add = $ { Media { Stream = 1 { LocalControl {Mode = SendReceive, ReserveValue=False }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 }, Remote { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 0 a=ptime:20 } ; RTP profile for G.729 is 18 } } } } }
6)
This is acknowledged. Also, based on the remote SDP provided, MG2 can infer that the T.38 MGC Transitioning method shall be used for transitioning from a VoIP state to a FoIP state. The stream port number is 1111 (in the SDP). Also, MG2 selects the first codec in the offered priority codec list as the preferred codec, i.e., G.729 (RTP payload type = 18).
ITU-T Rec. T.38 (04/2007)
85
MG2 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 30 { Context = 5000 { Add = DS0/2/2, Add = RTP/2 { Media { Stream = 1 { Local { v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP 18 } } } } } }
7)
The above IPAddr, UDPport, and selected codec need to be given to MG1 now. Also, because the MGC knows that the T.38 MGC Transitioning method shall be used, it needs to indicate to MG1 that it has to detect facsimile tones and inform it appropriately as well as apply ringing tone ringback to the DS0/1/1 termination and change it to a SendReceive.
MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 12 { Context = 2000 { Modify = DS0/1/1 { Events = 10 { ctyp/dtone}, ; detect facsimile tones Signals {cg/rt} }, ;apply ringing tone Modify = RTP/1 { Media { Stream = 1 { LocalControl {Mode = SendReceive } Remote { v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP 18 } } } } } }
from MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 12 { Context = 2000 {Modify = DS0/1/1, Modify = RTP/1} }
8)
The calling fax machine typically will start to generate CNG calling tones. When the CNG tone event is detected by the first media gateway (MG1), this event shall be reported to the media gateway controller. The media gateway controller then shall issue a command to the second media gateway (MG2) to generate a CNG tone. At this point, the full duplex channel is still in a voice mode and using the indicated audio codec such as G.723.1 and G.729A.
from MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Transaction = 50 { Context = 2000 { Notify = DS0/1/1 {
86
ITU-T Rec. T.38 (04/2007)
ObservedEvents = 1 { 19991212T22110001: ctyp/dtone{dtt=cng} } } } }
from MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Reply = 50 { Context = 2000 {Notify = DS0/1/1} }
MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 31 { Context = 5000 { Modify = DS0/2/2 { Signals {ctyp/callsig{callSigname=cng}}; issue CNG at remote end } } }
MG2 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 31 { Context = 5000 {Modify = DS0/2/2} }
9)
In the previous step, the MG2 generated a CNG tone requested by the MGC in the Signals descriptor. In the typical case, if the final destination phone number is fax capable, a CED tone will be generated by the recipient fax machine. This step is illustrated here. However, if there is not a fax receiver on the line, the typical response will be via voice.
from MG2 to MGC: MEGACO/1 [123.123.123.4]:55555 Transaction = 70 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031: ctyp/dtone{dtt=ANS}}; CED and ANS are equivalent. Reported under the name ANS. } } }
from MGC to MG2: MEGACO/1 [125.125.125.111]:55555 Reply = 70 { Context = 5000 {Notify = DS0/2/2} }
10)
Assuming that a CED has been generated by the recipient fax device, the MG2 will then receive the CED and uses its tone detection algorithms to detect that it actually is a CED. (NOTE – Some research was done to check out modem answer tones, which are defined in ITU-T Recs V.25 and V.8. The modem answer tone without phase reversals is known as ANS in ITU-T Rec. V.25 and with answer tones is ANS (with a bar on top denoting Phase reversals). Some modems and DSPs may have a difficult time distinguishing among the CED, ANS and ANS(bar). However, the group felt that if a CED-like tone was generated in response to a CNG, there is a very high likelihood that the tone is indeed a CED and not one of the ANS tones. Higher end modems are able to discriminate between ANSam and the other modem and fax tones.).
Since a CNG was reported by the calling side and a CED by the called side, the Media Gateway Controller will issue a command instructing MG1 to play the CED. Both media gateways to shift into a fax mode (either T.38 if supported, or G.711). From this point, the V.21 fax data will be conveyed between the media gateways. Note that at this point, the MGC could decide that there is sufficient confidence to switch to fax, unless, for example, ITU-T Rec. T.38 (04/2007)
87
some other answer tone has been detected, such as ANSam (see step 18). For the purpose of this example, it does not believe it has sufficient confidence. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 13 { Context = 2000 { Modify = DS0/1/1 { Signals {ctyp/ans{anstype=ans}} } } }
MG1 to MGC: MEGACO/1 [124.125.125.222]:55555 Reply = 13 { Context = 2000 {Modify = DS0/1/1} }
11)
When MG2 detects a V.21 carrier followed by flags, it will send a message to the MGC reporting this event. At this point, the MGC is certain that the call is a fax and will initiate a switch, first on the DS0 terminations. Note that V.21 flags are not signalled to MG1. The event causes the MGC to ask MG1 to play v21flags to its SCN termination.
MG2 notifying MGC of V.21 carrier event: from MG2 to MGC: MEGACO/1 [123.123.123.4]:55555 Transaction = 71 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:ctyp/dtone{dtt=v21flag}} } } }
MGC responds. from MGC to MG2: MEGACO/1 [125.125.125.111]:55555 Reply = 71 { Context = 5000 {Notify = DS0/2/2} }
MGC sends a command to MG1 to send the V.21 flags on its SCN termination and hand over the continuation of the session to the fax package. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 5{ Context = 2000 { Modify = DS0/1/1 { Signals {ctyp/ans{anstype=v21flags, SignalType=TimeOut}} Events = 2 { fax/faxconnchange} Media{ TerminationState {fax/faxstate = TrainT; } } } } }
MG1 to MGC: MEGACO/1 [124.125.125.222]:55555 Reply = 5 { Context = 2000 {Modify = DS0/1/1}
88
ITU-T Rec. T.38 (04/2007)
The MG must generate the V21flags signal until the V21 flags indication arrives in the T.38 media stream (see step 17) and then continue until the V21 flags termination is indicated in the T.38 media stream. 12) At this point the SCN termination on MG2 and MG1 shall be put into fax mode (this stage is Negotiating). Only the example of MG2 is shown. Note that in the case of MG2, since the ctyp package is not mentioned in the Events Descriptor, the MG is no longer required to perform call type discrimination event notification. Also, since CNG is not mentioned in the signal descriptor, this signal is terminated. MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 33{ Context = 5000 { Modify = DS0/2/2 { Events = 12 { fax/faxconnchange} Signals{}, Media{ TerminationState {fax/faxstate = Negotiating; } } } } }
And MG2 responds. MG2 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 33 { Context = 5000 {Modify = DS0/2/2}
13)
At this point in the call, the switch to fax continues with a request for each MG to switch to T.38 mode. Note that the MGC is aware that the MGs support T.38 as a result of a previous audit. If T.38 was not available, then the audio mode may be changed to G.711 (the details of this are out of scope). Selection among the voice, fax and data modes will have been achieved, unless some other answer tone has been detected, such as ANSam. In the event that ANSam is detected, the two MGs should be switched into a mode where they can conduct a V.8 session to further determine the type of call (e.g., V.34 fax, V.90 data, text telephone, etc.). The handling of V.34 fax calls in this environment is for further study.
MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 15 { Context = 2000 { Modify = RTP/1 { Media { TerminationState {ipfax/faxstate = Negotiating; } Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } ; change to T.38 in the IP connection } } } } }
ITU-T Rec. T.38 (04/2007)
89
14)
Following is the response from MG1. MG1 changes one of the a= fields: The T.38 parameter transferredTCF is changed by MG1 to localTCF. MG1 may also change the port number if it does not want to switch the use of the existing voice channel to faxport. In this example, it changes the port from 2222 to 3333.
from MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 15 { Context = 2000 {Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 3333 udptl t38 a=T38FaxRateManagement:localTCF a=T38FaxUdpEC:t38UDPFEC }; the IP connection brought into fax mode } } } } }
15)
The new media information must be passed on to MG2.
MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 32 { Context = 5000 { Modify = RTP/2 { Media { TerminationState } Stream = 1 { Local { v=0 c=IN IP4 125.125.125.111 m=image 1111 udptl t38 a=T38FaxRateManagement:localTCF a=T38FaxUdpEC:t38UDPFEC }, Remote { v=0 c=IN IP4 124.124.124.222 m=image 3333 udptl t38 a=T38FaxRateManagement:localTCF a=T38FaxUdpEC:t38UDPFEC } } } } } }
16)
This is acknowledged MG2 elects NOT to change the port (it remains as 1111), and does not change any T.38 parameters.
MG2 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 32 { Context = 5000 { Modify = RTP/2 { Media { Stream = 1 { Local {
90
{ipfax/faxstate = Negotiating;
ITU-T Rec. T.38 (04/2007)
v=0 c=IN IP4 125.125.125.111 m=image 1111 udptl t38 a=T38FaxRateManagement:localTCF a=T38FaxUdpEC:t38UDPFEC } } } } } }
17)
Now, MG1 needs to be given the new media information from MG2.
MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 15 { Context = 2000 { Modify = RTP/1 { Media { Stream = 1 { Remote { v=0 c=IN IP4 125.125.125.111 m=image 1111 udptl t38 a=T38FaxRateManagement:localTCF a=T38FaxUdpEC:t38UDPFEC } } } } } }
from MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 15 { Context = 2000 { Modify = RTP/1} }
The fax call will now proceed in T.38 mode between the MGs. The first from MG2 message will be a T.30 Indicator packet containing V.21 flags. This will be generated by the continued appearance of this signal on the DS0 since the MG has no memory of previous events. Note that the event/faxconnchange is left on the event list of both MGs and so each state change will result in a Notify to MCG; however, MCG need not explicitly set the fax/faxstate in response since faxstate should be set implicitly by each MG as it changes state. MCG may take no action for most state changes but will likely take appropriate action for states such as Disconnect. 18) Variant: In the event that a CED or similar tone is detected by the MG2, it will always report this to the MGC. For the case where the MGC had not previously received notification of CNG detection by MG1, the group felt that it is still not clear whether a fax or data mode is applicable. However, the compressed voice codecs are not adequate in either case, so the MGC should place both MGs into a data-capable mode (i.e., G.711) or wait for additional tones to further discriminate the call. 19) If the MG2 has the facility to detect a V.21 carrier followed by flags, it will send a message to the MGC reporting this event. (It is assumed that MGs will generally not have memory of prior events, so that the notification of V.21 and flags will be sent even if the MGC has already placed the two MGs into a fax mode.) If the MGC had not previously placed the two MGs into a fax mode, it will do so now. If the MGs are already in a G.711 mode, the MGC shall have the choice of not requesting a mode change or of requesting that the two media gateways switch to a T.38 mode.
ITU-T Rec. T.38 (04/2007)
91
MG2 notifying MGC of V.21 carrier event: from MG2 to MGC: MEGACO/1 [123.123.123.4]:55555 Transaction = 4 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:ctyp/dtone{dtt=v21flag}} } } }
20)
Variant: At this point in the call, the selection among the voice, fax and data modes will have been achieved, unless some other answer tone has been detected, such as ANSam. In the event that ANSam is detected, the two MGs should be switched into a mode where they can conduct a V.8 session to further determine the type of call (e.g., V.34 fax, V.90 data, text, telephone, etc.) The handling of V.34 fax calls in this environment is for further study.
MG notifying MG2 of an ANSam event: from MG2 to MGC: MEGACO/1 [123.123.123.4]:55555 Transaction = 4 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:ctyp/dtone{dtt=ansam}} } } }
III.2.2 Fax-only call setup between H.248 and an H.323 endpoint This facsimile-only call flow example (see Figure III.2), describes a facsimile call that originates in the SCN and is terminated in the packet network. The packet network signalling in this example is H.323 but other signalling protocols such as SIP can be used. The purpose of the example is to describe MG/MGC interactions. The assumption is made that the signalling between the signalling gateway (SGW) and MGC is based on ITU-T Rec. Q.931. This does not indicate that no other signalling can be used on this interface. Capabilities described here are generic line package descriptions (but could also be SDP or H.245 messages). The media gateway is configured for voice and fax; however, the H.323 endpoint is fax only, taking the calls into fax-only mode. (i.e., it is likely a T.38 Annex B endpoint).
92
ITU-T Rec. T.38 (04/2007)
Figure III.2 – Fax-only call setup between H.248 and an H.323 endpoint
ITU-T Rec. T.38 (04/2007)
93
1)
2)
The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch. From the Setup message, the MGC may infer which circuit on which MG is involved and where to terminate the call. How the MGC does this is outside the scope of this Recommendation. The MGC creates a Context for the call. The Context contains two terminations: one for the SCN side and one for the packet side. Also, in order for the MGC to infer whether both gateways support the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method, the MGC instructs MG1 to respond with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities. Note that in the LocalControl descriptor, ReserveGroup = True to ask the MG to take both audio and image media descriptors (in addition, an MGC may include ReserveValue = false to ask for the most preferred codec. However, if omitted, an MG by default must set this value to false in accordance with ITU-T Rec. H.248):
MGC to MG: MEGACO/1 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 { ctyp/dtone, fax/faxconnchange, al/of} }, ; the SCN side termination listening for call type indicating tones Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, ReserveGroup = True }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 } ; the IP side term. showing capability of RTP audio with PT 0 (G.711 PCMU) and 18 (G.729). } } } } }
3)
The MG accepts the Context creation and fills in the unknown ($) parameters. MG1 does not support the T.38 Autonomous Transitioning method; hence, it omits the image media line in the response: MEGACO/1 [124.124.124.222]:55555 Reply = 11 { Context = 2000 { Add = DS0/1/1,; the SCN termination is accepted Add = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 } ; the IP RTP termination is accepted with audio payload type 18. } } } } }
94
ITU-T Rec. T.38 (04/2007)
This shows how the MG reports to the MGC what parameters it filled in. 4) The MGC sends a Setup message to the destination endpoint, here assumed to be an H.323 endpoint (terminal, GW, etc.). It indicates in the fastStart element that either the capability to use UDP or TCP may be used for the T.38 facsimile stream. 5) The H.323 endpoint sends a CallProceeding message followed by an Alerting message back to the MGC, informing it of the mode to be used (assume UDP for both directions) and the transport address; followed by an Alerting message, indicating that it is ringing the G3FE. 6) The MGC sends a Modify command to the MG to set the mode and remote termination description on the packet side: MGC to MG: MEGACO/1 [123.123.123.4]:55555 Transaction = 1450 { Context = 2000 { Modify = RTP/1 { Events= 3 {fax/faxconnchange}, Media { TerminationState { fax/faxstate=Prepare; ipfax/ipftrpt=T38UDPTL; } Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } ; modify media stream 1 to use image media , udptl transport for T38 } } } } }
7)
The MG accepts the Modify commands. At about this time, the MG may detect a CNG on the line; thus notifies the MGC, which acknowledges. Since there is no way to initiate a playing of CNG on the H.323 endpoint, the MGC will wait until the connection is open. Note that the MGC may not receive a CNG before the H.323 Connect:
from MG to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 1450 { Context = 2000 {Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 3333 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC }; The fax udptl/t38 transport channel is accepted on the IP session } } } } MEGACO/1 [124.124.124.222]:55555 Transaction = 50 { Context = 2000 {
ITU-T Rec. T.38 (04/2007)
95
Notify = DS0/1/1 { ObservedEvents = 1 { 19991212T22110001:ctyp/dtone{dtt=cng} } } } }
from MGC to MG: MEGACO/1 [123.123.123.4]:55555 Reply = 50 { Context = 2000 {Notify = DS0/1/1} }
8) 9)
10)
The MGC sends an Alerting message to the SGW. The called endpoint, at some instance, sends a Connect message to the MGC once the G3FE goes off-hook. Note that this message only contains facsimile capabilities and does not include an H.245 port A Modify command to the MG to change the mode of the SCN side termination to SendRecv and to fax mode. Also, the indication of fax capabilities to be setup on the T.38 is also included in this command (this information was included in the Connect from the H.323 endpoint):
MGC to MG: MEGACO/1 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Modify = DS0/1/1 { Media { TerminationState { fax/faxstate = Prepare}, Stream = 1 { LocalControl { Mode=SendReceive } } }, Events = 10 {al/of, ctyp/dtone, fax/faxconnchange }, Signals = {al/ri } } ; modify SCN termination to reflect that we are connected through Modify = RTP/1 { Media { TerminationState { ipfax/faxstate = Prepare, ipfax/ipftrpt=T38UDPTL }, Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } ; modify media stream 1 to use image media , udptl transport for T38 LocalControl { Mode = SendReceive } } }, Events = 2 { ipfax/faxconnchng } } } }
11) 12)
The MGC sends a Connect message to the SGW to indicate the call is connected. The MG accepts the Modify command that was sent to it earlier (see point 10).
from MG to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 14 { Context = 2000 { Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222
96
ITU-T Rec. T.38 (04/2007)
m=image 3333 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC }; The fax udptl/t38 transport channel is accepted on the IP session } } }, Modify = DS0/1/1 }; The modify is accepted on the DS0 session }
13)
At this point the call proceeds in T.38 mode between the gateways. Likely the originating G3FE is still sending CNG so this will be sent first, followed by CED from the destination G3FE. Note that since the MG has been asked to indicate when the fax connection state changes, after the V.21 flags packet is received, the MG notifies the MGC of this event.
from MG to MGC: MEGACO/1 [124.124.124.222]:55555 Transaction = 60 { Context = 2000 { Notify = RTP/1 { ObservedEvents = 1 { 19991212T22110001:ipfax/faxconnchange{faxconnchng=Negotiating } } } }
from MGC to MG: MEGACO/1 [123.123.123.4]:55555 Reply = 60 { Context = 2000 {Notify = RTP/1} }
III.2.3 Voice to fax call setup with H.248 endpoints that support the T.38 Autonomous Transitioning method This call flow example (see Figure III.3) describes a voice call that originates and terminates in the SCN and is transported through the packet network. The packet network signalling in this example is not specified but any signalling protocols such as H.323 or SIP can be used. The purpose of the example is to describe MG/MGC interactions when operating in the T.38 Autonomous Transitioning mode including indication of support of the T.38 Autonomous Transitioning mode, the detection of fax and switching from voice to fax. Note that, in contrast to the switch-over to T.38 fax mode under control of the MGC (i.e., the T.38 MGC Transitioning method), the fax package defined in Annex F/H.248 does not need to be supported by the MGs.
ITU-T Rec. T.38 (04/2007)
97
Figure III.3 – Voice to fax call setup with H.248 endpoints that support Autonomous Transition between VoIP and FoIP
98
ITU-T Rec. T.38 (04/2007)
The sequence of events is as follows: 1) At some point before a call, the media gateway controller will have issued an audit capabilities command to the media gateways under its control and will know what the voice and fax capabilities are for each gateway. In the scenarios below, if both media gateways support T.38, then this is the preferred mode for IP fax operations. In the event that one or both media gateways do not support T.38, then the fax call may proceed over the IP voice channel. However, since T.30 facsimile may fail over a compressed voice codec, it would be preferable to use a G.711 codec for communication between the media gateways. 'W-' is used to indicate that a wild-carded answer with a union of information on all terminations on the MG is requested, not an audit of each termination on the MG. Note that MG1 indicates to the MGC that it supports T.38; however, the audit shall not be used to indicate support of the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method (as described in E.2.2). This shall be done on a call-by-call basis during the Add ephemeral (see point 3 below). The MGC audits MG1. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9 { Context = - {W-AuditValue = * {Audit{Packages}}} }
MG1 replies. MG1 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 9 { Context = - { AuditValue = * { Packages {al, rtp, ipfax, fax, ctyp, cg} ; al = analog line pkg, rtp = rtp pkg, ipfax = T.38 fax pkg, fax = fax pkg ; ftmd = fax/textphone/modem tones detection pkg ; ctyp = Call Type Discrimination package) ; cg =call progress tones generator pkg } } }
MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 10 { Context = - {W-AuditCapability = * {Audit{Media }}} }
MG1 replies. MG1 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 10 { Context = - { AuditCapability = * { Media { Stream = 1 { Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 18 v=0 c=IN IP4 $ m=image $ udptl t38 } ; RTP profile for G.711 is 0, G.729 is 18, t38 is T.38 } }, } } }
ITU-T Rec. T.38 (04/2007)
99
A similar exchange happens between the MGC and MG2. 2) The End User decides to send a fax from device F1 and enters the phone number. The fax device gets dial tone and then dials the phone number. As a result, the central office within the local SCN loop sends an SS7 message to the signalling gateway (SG). The SG sends a Setup message to the MGC after receiving this IAM from a SCN switch that conveys the called and calling phone numbers. Sigtran's SCTP carries the SS7 signalling from the SG to the MGC. 3) From the IAM message, the MGC may infer which circuit on which MG is involved and where to terminate the call. How the MGC does this is outside the scope of this Recommendation. The endpoints are found by the media gateway controller (MGC) and it sets up the audio channel between the two media gateways and instructs the SS7 facility of the receiving CO to connect to the end phone destination, which results in the generation of ringing. So, to start, the controller determines that a connection needs to be made from MG1 to MG2. The MGC creates a Context for the call. A TDM termination DS0/1/1, an audio/RTP termination and an image/t38 termination are added to a new context in MG1. Mode is ReceiveOnly since Remote descriptor values are not yet specified. Preferred codecs are in the MGC's preferred order of choice. The MGC sets to CHOOSE (i.e., $) the fields in the SDP in the Local descriptor that the MG will set itself. Also, in order for the MGC to infer whether both gateways support the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method, the MGC instructs MG1 to respond with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities. Note that this is achieved by including in the LocalControl descriptor "ReserveGroup=True" to ask the MG to reserve resources for both audio and image media descriptors. In addition "ReserveValue=True" to ask the MG to reserve resources for all the possible codecs offered in the media descriptor (alternatively an MGC may include ReserveValue=false to ask for the most preferred codec; however, if omitted a MG by default must set this value to false). MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Media { Stream = 1 { } } } Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, ReserveGroup=True, ReserveValue=True }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 }; IP termination for audio } } } } }
4)
100
MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. It also supports and can reserve resources for all the codecs offered in the list within the media descriptor of the SDP block in Local, thus leaving the final choice of codec for the ITU-T Rec. T.38 (04/2007)
remote gateway. MG1 sets the RTP port to 2222. Because the MG supports the T.38 Autonomous Transitioning method for transitioning between VoIP and FoIP; it also sets the T.38 port to 4444 and includes the supported T.38 capabilities. If the MG did not support autonomous transitioning between VoIP and FoIP; it would set the T.38 port to 0 or omit the image media descriptor line altogether, and would proceed as indicated in III.2.1. MEGACO/1 [124.124.124.222]:55555 Reply = 11 { Context = 2000 { Add = DS0/1/1, ; SCN termination added Add = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 0 ; MG1 can reserve resources for both codecs v=0 c=IN IP4 124.124.124.222 m=image 4444 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } ; IP termination added } } } } }
5)
The MGC will now associate DS0/2/2 with a new Context on MG2, and establish an RTP Stream (i.e., RTP/2 will be assigned) and T.38 stream SendReceive connections through to the originating user, User 1. Also, because MG1 supports the T.38 Autonomous Transitioning method, the MGC needs to find out whether the MG2 supports the T.38 Autonomous Transitioning method, for which the MGC will ask MG2 by including an audio media descriptor and an image media descriptor with the ports set to $ in the Add ephemeral of the create context message and including, in the LocalControl descriptor, the property "ReserveGroup=True" to ask the MG to take both audio and image media descriptors, as well as indicating that the remote MG supports the T.38 Autonomous Transitioning method. Note that in addition the MGC includes ReserveValue=false to ask for the most preferred Code.
MGC to MG2: MEGACO/1 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Add = DS0/2/2 { Media { Stream = 1 { LocalControl {Mode = SendReceive}, ReserveGroup=True, ReserveValue=false } }, } }, Add = $ { Media { Stream = 1 { LocalControl {Mode = SendReceive }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 }, Remote {
ITU-T Rec. T.38 (04/2007)
101
v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 0 v=0 c=IN IP4 124.124.124.222 m=image 4444 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } ; RTP profile for G.711 is 0 } } } } }
6)
This is acknowledged. Also, because MG2 supports the T.38 Autonomous Transitioning method for transitioning between VoIP and FoIP, it includes in the SDP response both an audio and an image media descriptor with valid port numbers. The RTP stream port number is different from the Megaco/H.248 control port number. In this case it is 1111 (in the SDP). The T.38 stream port number is different from the Megaco/H.248 control port number. In this case it is 5555 (in the SDP). Also, from the remote SDP, MG2 knows that it shall transition between VoIP and FoIP using the T.38 Autonomous Transitioning method. If the remote SDP did not have both the audio and an image media descriptor, MG2 would have defaulted to using the T.38 MGC Transitioning method for transitioning from an audio/RTP connection to an image/t38 connection and the procedures in point 7 of III.2.1 follow. Also, MG2 chooses G.729 (payload type = 18) as the voice codec to use.
MG2 to MGC: MEGACO/1 [125.125.125.111]:55555 Reply = 30 { Context = 5000 { Add = DS0/2/2, Add = RTP/2 { Media { Stream = 1 { Local { v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP 18 v=0 c=IN IP4 125.125.125.111 m=image 5555 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC } } } } } }
7)
The above IPAddr and UDPport and voice codec need to be given to MG1 now. As well as indicating that MG2 supports the T.38 Autonomous Transitioning method for transitioning between VoIP & FoIP. Also apply ringing tone ringback to the DS0/1/1 termination and change it to a SendReceive.
MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 12 { Context = 2000 { Modify = DS0/1/1 { Signals {cg/rt} }, ;apply ringing tone Modify = RTP/1 { Media {
102
ITU-T Rec. T.38 (04/2007)
Stream = 1 { LocalControl {Mode = SendReceive, ReserveGroup=True }, Remote { v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP 18 v=0 c=IN IP4 125.125.125.111 m=image 5555 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC
} } } } } }
from MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 12 { Context = 2000 {Modify = DS0/1/1, Modify = RTP/1} }
8) 9)
10)
MG1 acknowledges, and shall use the T.38 Autonomous Transitioning method for transitioning from audio/RTP connection to an image/t38 connection. The calling fax machine typically will start to generate CNG calling tones. It is envisioned that the first media gateway (MG1) will detect the CNG tone event and will determine that a facsimile call is commencing. Hence, MG1 will switch to image/t38 mode, mute its audio/RTP connection and transmit (via its image/t38 connection) to MG2 the T.38 CNG indicator packet. MG2, on receipt of the T.38 CNG indicator packet, will transition to image/t38 mode. This may be implemented such that receipt at its T.38 UDP port of a valid IP/UDP packet whose source IP address corresponds to that of MG1 can be assumed to be a T.38 packet causing a transition to T.38. Hence, on transition to image/t38 mode, this packet will be decoded and analysed to be of type CNG, thus playing out the appropriate CNG tone. In order to avoid any unwanted UDP packet arriving at the T.38 UDP port, this port should be activated only if the T.38 Autonomous Transitioning method (and T.38 capabilities) was successfully negotiated before the call. From here on both MGs will operate in accordance with this Recommendation. If there were no CNG tone, then MG1 would transition the T.38 on detection of a sufficient number of T.30 preamble flags (aka the V.21 preamble flags) and send the corresponding T.38 V.21 preamble indicator packet. Alternatively: If RFC 2833 telephone events is supported by both MGs (i.e., methods 2 and 3 described in E.2.2.2.2.1), and indicated either via SDP exchange or other mechanisms beyond the scope of this Recommendation, then a MG1 may choose to send the corresponding CNG, CED and V.21 preamble across the packet network as described in E.2.2.2.2.1 and transition to T.38 only on detection of a sufficient number of V.21 preamble flags. The MGs shall revert back to the audio/RTP connection (VoIP) based on detection of any of the following: a) Detection of a T.30 DCN message; b) Detection of bidirectional silence. It is recommended to detect transition back to voice mode on detection of more than 7 s of bidirectional silence to allow for the T.30 T2 timers (within the G3FEs) to time out; c) Detection of voice; d) Reception of a Modify command in which only an audio media descriptor is present.
ITU-T Rec. T.38 (04/2007)
103
III.2.4 Voice to fax call setup between H.248 and H.323 endpoints that support the T.38 Autonomous Transitioning method This facsimile-only call flow example (see Figure III.4) describes a facsimile call that originates in the SCN and is terminated in the packet network. The packet network signalling in this example is D.3/H.323 but other signalling protocols such as SIP can be used. The purpose of the example is to describe MG/MGC interactions. The assumption is made that the signalling between the signalling gateway (SGW) and MGC is based on ITU-T Rec. Q.931. This does not indicate that no other signalling can be used on this interface. Capabilities described here are generic line package descriptions (but could also be SDP or H.245 messages). The media gateway and the H.323 endpoint are configured for voice and fax. The purpose of the example is to describe MG/MGC and H.323-endpoint/MGC interactions when operating in the T.38 Autonomous mode including indication to use the T.38 Autonomous mode, the detection of fax and switching from voice to fax.
104
ITU-T Rec. T.38 (04/2007)
Figure III.4 – Voice to fax call setup with H.248 and H.323 endpoints that support T.38 Autonomous Transition between VoIP and FoIP
ITU-T Rec. T.38 (04/2007)
105
1) 2)
3)
The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch. From the IAM message, the MGC may infer which circuit on which MG is involved and where to terminate the call. How the MGC does this is outside the scope of this Recommendation. The MGC creates a Context for the call. The Context contains two terminations: one for the SCN side and one for the packet side. The MGC sets to CHOOSE (i.e., $) the fields in the SDP in the Local descriptor that the MG will set itself. Also, in order for the MGC to infer whether MG1 supports the T.38 Autonomous Transitioning method or the T.38 MGC Transitioning method, the MGC instructs MG1 to respond with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities. Note that this is achieved by including in the LocalControl descriptor "ReserveGroup=True" to ask the MG to reserve resources for both audio and image media descriptors. In addition the MGC may include ReserveValue=false to ask for the most preferred codec; however, if omitted, an MG by default should set this value to false:
MGC to MG: MEGACO/1 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 { ctyp/dtone, fax/faxconnchange, al/of} }, ; the SCN side termination listening for call type indicating tones Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, ReserveGroup=True }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 } ; the IP side termination showing capability of RTP audio with PT 0 and 18. } } } } }
4)
The MG accepts the Context creation and fills in the unknown ($) parameters. The MG supports the T.38 Autonomous Transitioning method; hence, it includes the image media line with an appropriate port number in the response and select G.729 as the preferred codec: MEGACO/1 [124.124.124.222]:55555 Reply = 11 { Context = 2000 { Add = DS0/1/1,; the SCN termination is accepted Add = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 v=0 c=IN IP4 124.124.124.222
106
ITU-T Rec. T.38 (04/2007)
m=image 5555 udptl t38 } ; the IP RTP termination is accepted with audio payload type 0. Also, the MG indicates that it supports the T.38 Autonomous Transitioning method for transitioning between VoIP and FoIP. } } } } }
This shows how the MG reports to the MGC what parameters it filled in. 5) The MGC sends a Setup message to the destination endpoint, here assumed to be an H.323 endpoint (terminal, GW, etc.). Also, because it knows that the MG supports the T.38 Autonomous Transitioning method, it indicates this in the fastStart element by the capability of simultaneous support of at least one audio codec and of receiving and transmitting T.38 FoIP. 6) The H.323 endpoint sends a CallProceeding message followed by an Alerting message with fastStart back to the MGC, informing it that it supports the T.38 Autonomous Transitioning method by indicating its capability of simultaneous support of at least one audio codec and of receiving and transmitting T.38 FoIP. 7) The MGC sends an Alerting message to the SGW. 8) The MGC sends a Modify command to the MG to set the mode and remote termination description on the packet side. 9) The called endpoint at some instance sends a Connect message to the MGC once the G3FE goes off-hook. Note that this message contains both the audio and facsimile capabilities and does not include an H.245 port. 10) A Modify command is sent to the MG to change the mode of the SCN side termination to SendRecv. The remote endpoints audio and fax capabilities are also included in this command (this information was included in the Connect from the H.323 endpoint). This also indicates that the remote endpoint supports the T.38 Autonomous Transitioning method and that the call shall initially be set up as a voice call. MGC to MG: MEGACO/1 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Modify = DS0/1/1 { Media { TerminationState { fax/faxstate = Prepare}, Stream = 1 { LocalControl { ReserveGroup=True } } }, Events = 10 {al/of, fax/faxconnchange },; the MGC requests the MG to send it an event when it transitions to T.38. Signals = {al/ri } } ; modify SCN termination to reflect that we are connected through Modify = RTP/1 { Media { TerminationState {ipfax/faxstate=Prepare, ipfax/ipftrpt=T38UDPTL }, Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 1111 RTP/AVP 18 v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCF
ITU-T Rec. T.38 (04/2007)
107
a=T38FaxUdpEC:t38UDPFEC } ; modify media stream 1 to use image media, udptl transport for T38 LocalControl { Mode = SendReceive } } }, Events = 2 { ipfax/faxconnchng } } } }
11) 12)
The MGC sends a Connect message to the SGW to indicate the call is connected. The MG accepts the Modify commands:
from MG to MGC: MEGACO/1 [124.124.124.222]:55555 Reply = 14 { Context = 2000 { Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 18 v=0 c=IN IP4 124.124.124.222 m=image 3333 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC }; The fax udptl/t38 transport channel is accepted on the IP session and the T.38 Autonomous Transitioning method shall be used for transitioning between VoIP and FoIP } } }, Modify = DS0/1/1 }; The modify is accepted on the DS0 session }
At this point the call proceeds in voice mode between the gateways. The MGC knows from the responses from both gateways that the T.38 Autonomous Transitioning method shall be used by both gateways for transitioning between VoIP and FoIP. Likely, the originating G3FE would send a CNG at which point the originating gateway will mute its audio/RTP port and transition to FoIP mode and send over the IP network the corresponding T.38 T.30_Indicator (CNG) packet. If no CNG tone was sent or detected, then the MGs would use the V.21 preamble as the transitioning criteria. Because the destination gateway received the UDP packet at its UDP port that has been assigned for T.38, it assumes that it is a T.38 packet and that it must transition to T.38 mode. From here on both gateways will operate in accordance with this Recommendation. Alternatively: If RFC 2833 telephone events is supported by both MGs (i.e., methods 2 and 3 described in E.2.2.2.2.1), and indicated either via SDP exchange or other mechanisms beyond the scope of this Recommendation, then a MG1 may choose to send the corresponding CNG, CED and V.21 preamble across the packet network as described in E.2.2.2.2.1 and transition to T.38 only on detection of a sufficient number of V.21 preamble flags. The gateways shall revert back to the audio/RTP connection (VoIP) based on detection of any of the following: – Detection of a T.30 DCN message; – Detection of bidirectional silence. It is recommended to detect transition back to voice mode on detection of more than 7 s of bidirectional silence to allow for the T.30 T2 timers (within the G3FEs) to timeout.
108
ITU-T Rec. T.38 (04/2007)
Appendix IV V.34 session examples IV.1
V.34 session examples
This clause contains several examples of signal flow in a V.34 half-duplex fax session. In the diagrams, the labels F1, G1, G2 and F2 are used as shorthand for emitting G3FE, emitting gateway, receiving gateway and receiving G3FE, respectively.
Figure IV.1 – V.8 signalling (using profiles and acks)
ITU-T Rec. T.38 (04/2007)
109
Figure IV.2 – Data rate negotiation and control channel start-up 110
ITU-T Rec. T.38 (04/2007)
Figure IV.3 – Between partial pages
ITU-T Rec. T.38 (04/2007)
111
Figure IV.4 – Last page
112
ITU-T Rec. T.38 (04/2007)
Figure IV.5 – Data rate change sequence when receiving G3FE initiates retraining
ITU-T Rec. T.38 (04/2007)
113
Figure IV.6 – Data rate change sequence when calling G3FE initiates retraining
114
ITU-T Rec. T.38 (04/2007)
Figure IV.7 – Data rate change sequence when receiving gateway initiates retraining
ITU-T Rec. T.38 (04/2007)
115
Figure IV.8 – Data rate change sequence when emitting gateway initiates retraining
116
ITU-T Rec. T.38 (04/2007)
F1
G1
G2
F2
t30-data(v34-pri-ch:HDLC:image octets) DATA
DATA t30-data(v34-pri-ch:HDLC-FCS-OK-Sig-End) Flags
Flags
t30-indicator(v34-cntl-channel-1200)
Sh
Sh Sh*
Sh
Sh*
Sh* ALT E
Sh Sh*
ALT
ALT E
E
ALT E
T30-data(v34-CC-1200:HDLC:PPS-EOM)
PPSEOM
Flags Flags
T30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)
PPSEOM
T30-data(v34-CC-1200:HDLC:MCF)
Flags
MCF
T30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)
Flags MCF
T30-data(v34-CC-1200:HDLC:DIS) Flags DIS
Flags T30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End)
T30-data(v34-CC-1200:HDLC:DTC)
DTC Flags Flags
DIS
Flags
T30-data(v34-CC-1200:HDLC-FCS-OK-Sig-End) DTC t30-indicator(v8)
Flags
1s
1s
CM CM CM CM CM CM CM CM
T30-data(v8:cm-message:FAP Prof 4) CM CM CM CM
T30-data(v8:jm-message:A0)
INFO0c INFO0c
INFO0a
INFO0a T.38_FIV.9(APPIV)
Figure IV.9 – Turn-around polling ITU-T Rec. T.38 (04/2007)
117
T.38_FIV.10(APPIV)
Figure IV.10 – Manual Transmit (DIS has bit 6 set to 1 to indicate V.8 capability)
118
ITU-T Rec. T.38 (04/2007)
F1
F2
t30-indicator(v21-preamble)
t30-indicator(v21-preamble)
t30-indicator(v8-ansam)
T.38_FIV.11(APPIV)
Figure IV.11 – Manual Receive (DIS has bit 6 set to 1 to indicate V.8 capability)
ITU-T Rec. T.38 (04/2007)
119
Appendix V T.38 Implementation Guidelines This appendix provides guidance for implementers to improve interoperability amongst T.38 devices, based on experience gained with actual implementations of the T.38 specification. V.1
General issue
V.1.1
Transmission bit order
The transmission bit order complies with 7.1.1 and 7.1.2. As an example, DIS frame starts with "7E FF C8 01 …": 7E
FF
C8
01
01111110 11111111 11001000 00000001 B
E
B
E
B
E
B
E
'B' means "beginning" and 'E' means "end" in each octet. 'B' bit is first stored in an octet of IP packet and is first transmitted. V.1.2
Interval between packets
An interval between a preamble packet and a T.30 signal packet, and an interval between a training packet and an image packet, may be necessary for some gateway implementations, because they do not have enough buffers for dealing with multiple packets. When multiple T.30 signals like CSI and DIS are sent, an interval between the signals may be necessary for some gateway implementations for the same reason. In addition, when packets are sent to gateway, they should be sent at the negotiated modem speed in DIS/DCS exchange. IAF implementations may be particularly prone to this problem because there is no fax terminal connected to GSTN where the modem limits the rate at which packets can be created. V.1.3
Preamble packet between T.30 signals
Some implementations incorrectly send a preamble packet between T.30 signal packets. A T.38 implementation that receives a sequence of this type, should handle it properly. For example, the received preamble packet before "sig-end" in field-type should be regarded as flag (0x7e). V.1.4
Disassembly of one signal in packet
Some implementations send one T.30 signal frame in one packet and other implementations send it in multiple packets. Therefore, a T.38 implementation should handle both situations and assemble the multiple packets when necessary. This principle applies to image packets as well. Some implementations place an entire HDLC frame (between flags) into a single packet, others may ignore the frame boundaries when inserting the data into packets. V.1.5
Limitation of packet size
Some implementations limit the packet size to receive even in tcp mode. The limitation often relates to the size of one ECM packet. It is the responsibility of the sender to address this situation. One possibility is to use the same packet size regardless of whether the transport protocol is tcp or udp and regardless of whether the remote side is an IAF or a gateway. In udp mode, the t38FaxMaxDatagram value negotiated in call-setup, should be used to determine the size of the packets.
120
ITU-T Rec. T.38 (04/2007)
V.1.6
Packet of Transferred TCF
A series of ZEROs for 1.5 s must be sent in one or more packets in transferred TCF, based on the negotiated modem speed in DIS/DCS exchange. An IAF sender must generate the TCF if the receiving T.38 devices is not an IAF. V.2
IAF issues
V.2.1
T.30 Timer value
When both implementations are IAFs, T.30 timer values may be extended by two or three times. Extension of the timers allows two terminals to have successful facsimile transactions in certain difficult environments. These environments include narrow-band transports or when there is a high degree of network delay and/or loss of packets. Bit 123 in DIS/DCS is the negotiation bit that indicates an IAF device. V.2.2
The data rate between IAFs
When TCP is selected, the data rate between IAFs is not limited by modem speeds indicated in DIS/DTC (see 8.1) and can be as fast a rate as both sides can support. TCP allows both sides to ignore the MaxBitRate attribute and rely on the protocol itself to throttle the data transfer between the two IAFs. V.2.3
Data rate between IAFs and gateways
If a gateway does not support TCP, an IAF shall send data so as to not cause a buffer overflow in the receiving gateway. A potential problem arises because the messages and data are sent without HDLC framing (insertion of FLAGs and ZEROs) and an IAF is not limited by a fax modem in the speed that it can generate messages and data. The likely effect of this problem for image data is one or more ECM frames in error. The sending IAF should send packets that, by some means, account for the overhead due to the HDLC framing that is added by the receiving gateway, so as to not overflow the gateway's buffer. V.3
Call-setup issues
V.3.1
CalledPartyNumber in Setup (Annex B)
The destination fax number should be set in CalledPartyNumber of Setup. Some receiving gateways have several fax ports and use the information to select one. V.3.2
Announcement of voice capability
H.323 gateway implementations generally support voice communication as the default and initial call type. When a T.38 Annex B implementation calls an H.323 Annex D implementation, the T.38 implementation may need to indicate voice capability in call setup, even if it wants only fax communication. V.3.3
Incorrect use of the colon (":") in several T.38 attributes in Annex D
Some equipment vendors have incorrectly implemented the ABNF as defined in Annex D for several parameters: T38FaxFillBit Removal, T38FaxTranscodingMMR, and T38FaxTranscodingJBIG. These implementers have made incorrect use of the colon (":"). Implementers should avoid this mistake, and make their implementations robust by interpreting ":1" as support for the attribute, and ":0" as not supporting the attribute. The correct behaviour of these parameters is defined in D.2.3.1 and D.2.3.2.
ITU-T Rec. T.38 (04/2007)
121
V.3.4
Case sensitivity of udptl and T38MaxBitRate in SIP and H.248.1
There are case differences between the T.38 and IANA definitions of updtl (UDPTL) and T38MaxBitRate (T38maxBitRate) for SIP and H.248.1. The preferred implementation is the T.38 definitions, namely udptl and T38MaxBitRate. V.4
Others
V.4.1
Delay to report the DCN to MGC
It is possible for a gateway after receiving a DCN signal from a transmitting facsimile terminal to initiate the transition to AUDIO. If this mode switch is too fast there is a possibility that the playout of the DCN signal from the remote gateway may be truncated prematurely due to receiving the transition request from a media gateway controller. When the DCN transition mode is adopted, delay (for example, 600 ms) is needed between when the MG(DSP) detects the DCN and reports this event to the MGC, to ensure that the gateway can send the complete DCN to the facsimile terminal. G3FE 1
MG 1
MG C
MG 2
G3FE 2
T.38 mode DCN T.38 package with DCN 600 ms
DCN event:fax-end Modify
Modify
ACK
ACK Voice mode T.38(07)_FV.1
Figure V.1 – MG1 uses timer before initiating mode transition request
122
ITU-T Rec. T.38 (04/2007)
SERIES OF ITU-T RECOMMENDATIONS Series A
Organization of the work of ITU-T
Series D
General tariff principles
Series E
Overall network operation, telephone service, service operation and human factors
Series F
Non-telephone telecommunication services
Series G
Transmission systems and media, digital systems and networks
Series H
Audiovisual and multimedia systems
Series I
Integrated services digital network
Series J
Cable networks and transmission of television, sound programme and other multimedia signals
Series K
Protection against interference
Series L
Construction, installation and protection of cables and other elements of outside plant
Series M
Telecommunication management, including TMN and network maintenance
Series N
Maintenance: international sound programme and television transmission circuits
Series O
Specifications of measuring equipment
Series P
Telephone transmission quality, telephone installations, local line networks
Series Q
Switching and signalling
Series R
Telegraph transmission
Series S
Telegraph services terminal equipment
Series T
Terminals for telematic services
Series U
Telegraph switching
Series V
Data communication over the telephone network
Series X
Data networks, open system communications and security
Series Y
Global information infrastructure, Internet protocol aspects and next-generation networks
Series Z
Languages and general software aspects for telecommunication systems
Printed in Switzerland Geneva, 2008
