IETF MEGACO Working Group Internet Draft D. Walker draft-walker-megaco-mg-t38-transition-00.txt Nortel Networks Expires: April 2003 October 2002 CALL ESTABLISHMENT PROCEDURES FOR T.38 H.248/MEGACO MEDIA GATEWAYS CAPABLE OF AUTONOMOUS TRANSITION BETWEEN VoIP AND T.38 FoIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes MEGACO/H.248 [6,2] call-setup set up procedures that enable T.38 [4] capable media gateways to transition between a Voice over IP (VoIP) call and a Facsimile over IP (FoIP) (using ITU-T Rec. T.38) call either: a) with the real-time intervention of a Media Gateway Controller (MGC) using one of the existing mechanisms in Rec. T.38 Annex B/H.323, Rec. T.38 Annex D/SIP-SDP and Rec. T.38 Annex E/H.248, and Rec. H.323 Annex D. b) without the real-time intervention of a Media Gateway Controller (MGC). The only involvement of the MGC will be during initial connection capabilities negotiation between the media gateways. At this stage, both the MGs and the MGCs are unaware of the type of connection, (i.e. Voice, Fax, Modem, etc.). This contribution also describes how these call set-up procedures can be used in conjunction with the existing procedures of ITU-T Rec. Walker Expires - April 2003 [Page 1] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 H.323 Annex D to set-up two parallel channels, one for voice and the other for T.38, without any modifications of the procedures. Conventions used in this document Media Gateway Controller (MGC): throughout this document this term is used as do indicate a MGC as defined in ITU-T Recommendation H.248[2] as well as a gatekeeper as defined in ITU-T Recommendation H.323. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. Table of Contents 1. Introduction...................................................3 1.1 Advantages of implementing the T.38 Autonomous method......4 2. Basic call set-up for handling real-time facsimile over IP calls via T.38..........................................................5 3. T.38 Media Gateway Controller (MGC) Method.....................9 3.1 Facsimile-only connection.................................10 3.2 Voice and facsimile connection............................10 4. T.38 Autonomous Method........................................11 4.1 Facsimile-only connection.................................11 4.2 Voice and facsimile connection............................11 4.3 VoIP to T.38 FoIP Transition Criteria.....................12 5. Call Set-up Examples..........................................13 5.1 Voice to Fax call set-up with H.248 endpoints using the T.38 MGC Method....................................................15 5.2 Fax only between H.248 and H.323 endpoint.................29 5.3 Voice to Fax call setup with H.248 endpoints that support the T.38 Autonomous method........................................35 5.4 Voice to Fax call set-up between H.248 and H.323 endpoint that support the T.38 Autonomous method............................42 Security Considerations..........................................47 References.......................................................47 Acknowledgments..................................................47 Author's Addresses...............................................48 Walker Expires û April 2003 [Page 2] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 1. Introduction This document describes system level requirements and procedures for Internet aware facsimile implementations and Internet aware facsimile Gateways conforming to ITU-T Recommendation T.38 [4] to establish calls with other ITU-T T.38 implementations using either: a) A media gateway controller (MGC) controlled paradigm via the procedures defined by ITU-T Rec. H.248. This paradigm shall be referred to as the T.38 MGC method. These procedures use a single channel, replacing the voice channel with a fax channel as described in T.38 Annex D/SIP, in T.38 Annex E.2.2.1/H.248, or in H.323 Annex D.5 [5] 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). 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 proposal is an optional procedure that complements to the existing mechanisms in Rec. T.38 Annex B/H.323, Rec. T.38 Annex D/SIP- SDP and Rec. T.38 Annexe E/H.248, and Rec. H.323 Annex D. This paradigm shall be referred to as the T.38 Autonomous method. This method requires the terminals that support both voice and T.38, to use at least two different communication ports: at least one UDP port for audio and at least one UDP (and/or TCP) port for T.38 (H.323 Annex D3-D-4 already provides procedures for allowing the use of two parallel channels, one for voice and another for T.38). This document also describes how this mechanism can be used in conjunction with the existing procedures of H.323 Annex D to set-up two parallel channels, one for voice and the other for T.38, without any modifications of the procedures. Note: this document is thus fully backward compatible with H.323 Annex D as it explains the extensions necessary in H.248, MEGACO [6] and SIP [7] for supporting the procedures of H.323 Annex D. No in-band signaling is necessary for supporting those procedures: therefore, no additions to RTP is required, and the media streams will be undistinguishable from existing voice or T.38 media streams and will thus be backward compatible. Furthermore, there are no RFC2833 procedures necessary for supporting the proposals in this document, although they may be used by MGs to transmit Walker Expires û April 2003 [Page 3] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 tonal signals to the peer MG, either in-band(using the specified RFC2833 RTP payload type) or via RFC2833 defined Named Telephony Events (NTEs), in conjunction with this proposal. 1.1 Advantages of implementing the T.38 Autonomous method The advantages of implementing the T.38 Autonomous method are: 1) Reduces the processing load of the MGC. If the media gateways, during the initial capabilities negotiation, have accepted that they mutually support T.38 and have agreed on mutual set of T.38 options, then by allowing the MG to autonomously transition to T.38, on detection of the relevant facsimile tones (CNG or V.21 preamble), this will avoid all the message exchange between the MG and the MGC indicated in III.2.1 (sequence numbers 8 to 18) or in Rec. H.323 Annex D. Hence reducing the amount of processing load on the MGC. 2) By permitting the media gateways to autonomously discriminate the various tones, in order to transition between VoIP and FoIP, this will allow a H.248 MG to interoperate with other non-H.248 MG, and between H.248 MGs and an MGC that does not support the H.248 IP Fax package of Rec. H.248 Annex F. 3) The media gateways involved in a FoIP call, that is carried out via T.38, will be able to easily and quickly transition between VoIP mode and T.38 FoIP mode by muting the audio connection while transmitting the facsimile data via T.38, and then muting the T.38 (image/T38) connection, while transmitting audio, and so forth. Such an operation can only be done by the media gateways if the connection was initially set-up as both audio and image/T38. This scenario can arise between manual single page G3FE's, in which during a facsimile connection the terminals go to voice and then back to fax. In such cases, using the existing T.38 MGC method1 the MGs have to inform the MGC of every tone and let the MGC decide when to transition to T.38 (for the case of H.248) or renegotiate support of T.38 between MGs (as is the case of H.323 annex D or SIP MGs as described in Rec. T.38 annex D). If this communication is done over networks that are lossy and/or have considerable delay, the G3FEs may time out causing the FoIP call not to be set up. For the T.38 MGC controlled method that uses H.248, every time an MG sends a tone notification message (e.g. indicating that a CNG, CED or V21 preamble, as defined in T.30 [8], was detected) to the H.248 MGC, the H.248 MGC must respond with an ACK message and, maybe, a new Walker Expires û April 2003 [Page 4] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 message (i.e. a Modify message) in which the T.38 capabilities are re-negotiated between the MG via the MGC. Thus, if any of these messages are lost, corrupted or heavily delayed (quite likely if the communication between MGC and MG is over an IP network), the message is resent after a set time (which cannot be to short, to avoid unnecessary messages being sent due previous messages being delayed), which together with the normal delay of an IP network can very likely exceed G3FE timers hence resulting in the T.38 call not being set up. Note that, the delay between T.38 transitioning related messages is increased if the messages have to be exchanged between different MGCs that may support different call control protocols and be located physically at a distance and connected by an IP network (the T.38 Autonomous method avoids the exchange of such messages from being carried out at all). 2. Basic call set-up for handling real-time facsimile over IP calls via T.38. According to section 8.2.1 of ITU-T Recommendation of H.248: 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) A termination is an object that sources and/or sinks media streams; b) 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 set-up process initiated at the MG (e.g. H.323 fastStart Setup). It shall be possible to establish a facsimile over IP call using either of the following two mechanisms: 1) T.38 MGC method: A mechanism in which the MGC decides when and whether it is possible to transition from VoIP to T.38 FoIP based on tone events sent to it (via H.248) by the MGs. Described in section 3 of this document. (Note: in a H.323 environment, the replacement of a voice channel with a T.38 channel is done according to the procedures of H.323 Annex D.5.) Walker Expires û April 2003 [Page 5] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 2) T.38 Autonomous method: A mechanism for transitioning between a Voice over IP (VoIP) call and a Facsimile over IP (FoIP) call (using T.38) by MGs without the intervention of a media gateway controller (MGC), as described in section 4 of this document, or without the need to request modification of a call as described in Rec. T.38 annex D. Note: In an H.323 environment, the procedures of H.323 Annex D.3 (fastStart) or D.4 (non fastStart) are used to set-up two parallel channels. A MG shall indicate support of the T.38 Autonomous method by including in the initial capabilities exchange or set-up message support for both audio and image/t38 media streams, using mechanisms described below. Media gateways that use SDP to exchange capabilities (such as but not limited to SIP or H.248 MGs), SHALL indicate support for the T.38 Autonomous method by including in the first SDP to be exchanged at least one 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 only show the SDP portion and in which, for the purpose of this document, only the media line is important: * SDP Example illustrating support of T.38 Autonomous method: Example 1: v=0 c=IN IP4 124.124.124.222 m=audio 2222 RTP/AVP 0 (......... additional attributes may be included) v=0 c=IN IP4 124.124.124.222 m=image 4444 udptl t38 a=T38FaxVersion:1 a=T38FaxRateManagement:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBufferSize:2000 a=T38MaxDatagram:512 a=T38FaxMaxRate:14400 (......... additional attributes may be included) Example 2: v=0 c=IN IP4 124.124.124.222 Walker Expires û April 2003 [Page 6] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 m=audio 2222 RTP/AVP 0 8 13 a=ptime:20 (......... additional attributes may be included) v=0 c=IN IP4 124.124.124.222 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) v=0 c=IN IP4 124.124.124.222 m=image 4444 udptl t38 a=T38FaxRateManagement:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC (......... additional attributes may be included) * SDP Examples illustrating non-support of T.38 Autonomous 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) v=0 c=IN IP4 124.124.124.222 m=image 0 udptl t38 a=T38FaxRateManagement:transferredTCFlocalTCF 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) Walker Expires û April 2003 [Page 7] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Example 5: v=0 c=IN IP4 124.124.124.222 m=image 8190 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBufferSize:2000 (......... additional attributes may be included) Note that examples 3 and 4 shall construe as indicating that, at the instance of time the SDP was exchanged the T.38 Autonomous 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) Rec. T.38. In such 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/MEGACO), which if it is H.248, then the procedures in section 3 of this document 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 a H.248 Modify command or a SIP INVITE command) containing a media attribute of type image/t38 (as described either in Rec. T.38 Annex D or in section 3 of this document). Example 5 will cause both MGs to immediately transition to FoIP (using T.38), however any future transitioning to any other mode of operation (e.g. voice, voice band data, etc.) shall be controlled by the MGC. Although this document primarily deals with H.248 MGs, when interoperating with H.323 MG, note that a H.323 capable Media Gateway shall indicate support of the T.38 Autonomous 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 H.323 Annex D.3 for fastStart or Annex D.4 for non-fastStart. Two MGs that mutually support the T.38 Autonomous method shall autonomously, on detection of the appropriate facsimile signals or on reception of a 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 image or to let the MGs autonomously transition), based on data derived from capability messages exchanged (as described above) between the Media Gateways. Hence, only if two MGs that are Walker Expires û April 2003 [Page 8] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 establishing the connection have mutually indicated that they support the T.38 Autonomous method (by the means described above), then the MGC shall not control the transition between VoIP and FoIP. 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 H.323 Annex D.5), or it may consist of a separate channel for voice and a separate channel for T.38 as per H.323 Annex D.3. The latter shall be used by an MGC as indication that the MGs shall use the T.38 Autonomous 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 set-up, and will be instrumental in indicating that the autonomous or switchover procedures are supported). Absence of an MG indicating support of the T.38 Autonomous 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), and which can be one of the following: * T.38 MGC method (for H.248) described in section 3 of this document * The method described in Rec. T.38 Annex B/H.323 * The procedure described in Rec. T.38 Annex D/SIP-SDP. The fact that a MGC knows that T.38 Autonomous method shall be used for a particular call, does not preclude the possibility of the MGC of requesting 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. If different MGCs 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 SIP as described in T.38 Annex D). On confirmation of a connection, the on-ramp MGC instructs its media gateway to initiate a T.38 session with the off-ramp MG 3. T.38 Media Gateway Controller (MGC) Method Two cases exist for the use of this method: Walker Expires û April 2003 [Page 9] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 1) If the Call Agent (MGC & Gatekeeper) controls both MGs, then H.248 is 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/T.38). 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. 3.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 of ITU-T Recommendation T.38. 3.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. A voice connection is set up. Upon detection of CNG by the emitting media gateway (MG), the Calling Agent is informed (via H.248) of this event and instructs the destination MG to play CNG. If the destination MG then notifies the MGC of a 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 ITU-T Rec. H.248 Annex F.8. 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. An MGC shall not determine to switch to facsimile based solely on detection of a CED tone. The CED tone is the same tone as the ANS tone. The latter tone is sent by modems. It is recommended that a Media Gateway Controller determine to switch to facsimile based on notification of a V.21 preamble flags event. Note: 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 Walker Expires û April 2003 [Page 10] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 agent is informed (via H.248) of this event and may request that the connection be reverted to voice. 4. T.38 Autonomous Method To use this method the MGs MUST mutually agree to do so at the start of the call. Refer to section 2 of this document for the method to be used by an MG to indicate that it supports the T.38 Autonomous 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. Thus, T.38 options of a subsequent fax phase to the call are negotiated at the same time as the audio parameters. When using MEGACO/H.248 call set-up 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 method. It shall be in the creation of a context where such support is indicated. Hence, the H.248 MGC MUST include both an audio and an image descriptor in the Local descriptor portion of the Add Ephemeral command (refer to section 5 of this document for examples), with the port numbers set to $. Also, the MGC MUST include within the H.248 ôLocalControlö descriptor ôReserveGroup=Trueö (to ask the MG to take both audio and image media 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 audio port set to zero (recommended for compatibility with SIP[5] capable terminals) or be omitted altogether, thus indicating non-support of the T.38 Autonomous method as well as initializing the call as voice. 4.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/T.38. 4.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 Walker Expires û April 2003 [Page 11] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 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, a voice connection is set up and no T.38 packets are sent. The MGs remain in this mode until they detect such criteria (refer to section 4.3 of this document) that cause them to determine that a fax call is starting. At this point the MGs will 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. 4.3 VoIP to T.38 FoIP Transition Criteria Upon detection of CNG by the emitting media gateway (MG), it can 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. 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 whose source IP address corresponds with that of the remote MG, with which the T.38 Autonomous method (as well as the T.38 capabilities) was mutually successfully negotiated, can be assumed to be a T.38 packet (because only T.38 UDPTL packets must be sent to negotiated image/t38 UDP port number) and hence cause autonomous transition to T.38. Similar applies for T.38 TCP packets. The T.38 UDP (or TCP) port should only be activated if the T.38 Autonomous 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 the T.38 Autonomous method, described in this document, is not mutually supported between the MGs). 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 post-1993 version of Rec. T.30. Walker Expires û April 2003 [Page 12] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 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 G3FE 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 proposal of COM8-70E (the support of V.34 can be left for discussion). 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, will transition to T.38. 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 application of COM8-70E. Media gateways that support the T.38 Autonomous 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 Rec. V.25). The latter tone is sent by some non-fax modems. 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). 4.3. T38 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 CDN packet, the MG will play out the T.30 DCN and subsequently transition to voice. b) Detection of bi-directional silence. It is recommended that an MG transition back to voice mode after detecting more than 7 sec. of bi-directional silence (this value was chosen in order to allow for the T2 timer defined in ITU-T Rec. T.30). c) Detection of Voice Activity d) Receipt from the MGC of an appropriate command modifying the call to audio. Which may be a H.248 Modify, a SIP INVITE command in which only the audio descriptor is present or the appropriate messages as per H.323 annex D.5 can do this. 5. Call Set-up Examples Walker Expires û April 2003 [Page 13] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 This section describes examples of H.248 call set-up procedures between Media Gateways that support FoIP relay using ITU-T Rec. T.38 via a Media Gateway Controller. The procedures will enable a media gateway to transition between a VoIP state (which may include a Voice Band Data (VDB) state) and T.38 FoIP state using either the T38 MGC method (see section 5.1) or the T.38 Autonomous method (see section 5.3) that were described in this document. The examples refer to the decomposed gateway model shown in Figure 1. For completeness this section also contains an example of recommended call set-up procedures between a H.248 (megaco) capable Media Gateway and a H.323 Capable Media Gateway for both the T38 MGC method (see section 5.2) and the T.38 Autonomous method (see section 5.4) e.g. SS7 +------+ +------+ e.g. SS7 ---->----| SG | | SG |--<------ +------+ +------+ | | | | | | +------+ e.g. SIP +------+ | MGC |--<------------------------>-| MGC | +------+ +------+ | | | CONTROL Domain | - - | - - - - - - - - - - - - - - - - - | - - | TRANSPORT Domain | H.248 (megaco) H.248(megaco)/H.323 | | v v +-----------+ +----------+ | | | | -->-----| |-->------------->--------| |----<--- GSTN | MG1 | IP Network | MG2/ | GSTN --<-----| |-<-------------<---------| H.323 |---<--- | | | endpoint | +-----------+ +----------+ Figure 1: Typical Decomposed Gateway Model The examples in this document complement the mechanism of T.38 annex D/H.323, which describes a simple case without a decomposed gateway. The examples below assume only one MGC is involved, in the case where Walker Expires û April 2003 [Page 14] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 more than one MGC is involved then MGC-MGC communication is required, such as using SIP as described in ITU-T Recommendation T.38. _ 5.1 Voice to Fax call set-up with H.248 endpoints using the T.38 MGC 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 signaling in this example is not specified but any signaling protocols 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 MGC support the MGC procedure, including the detection of fax and switching from voice to fax. 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. 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 method or the T.38 MGC method as described in section 3 of this document. 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.0 [123.123.123.4]:55555 Transaction = 10 { Context = - {W-AuditValue = * {Audit{Media, Packages}}} } MG1 replies. MG1 to MGC: MEGACO/1.0 [125.125.125.111]:55555 Reply = 10 { Walker Expires û April 2003 [Page 15] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Context = - { AuditValue = * { Media { Stream = 1 { Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 0 v=0 c=IN IP4 $ m=image $ udptl t38 } ; RTP profile for G.711 is 0, G.729 is 18, Also T.38 udptl shall be used for FoIP relay. } }, 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 } } } 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 document. The end points 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 $ the fields in the sdp in Local that the MG Walker Expires û April 2003 [Page 16] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 will set itself. Also, in order for the to MGC to infer whether both gateways support the T.38 Autonomous method or T.38 MGC 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=True/false to ask for all/the-most-preferred Codec(s), however if omitted a MG by default must set this value to false). MGC to MG1: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 {al/on, ftmd/dtfmctyp/dtone, al/of} }, ; SCN termination prepared to listen for 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 }; IP termination for audio and image } } } } } Walker Expires û April 2003 [Page 17] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 4) MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. It also makes a choice for the codec based on the list of sdp blocks in Local. MG1 sets the RTP port to 2222. Note that MG1 could have sent back both codecs, to leave the final choice to MG2. Also, because MG1 does not support the T.38 Autonomous method for transitioning between VoIP & FoIP, it omits the image media descriptor line all together (alternatively it could have set the T.38 port to 0) MG1 to MGC: MEGACO/1.0 [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 } ; 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 method shall be used to transition between VoIP & FoIP, and will now associate DS0/2/2 with a new Context on MG2, and establish an RTP Stream (i.e, RTP/2/2 will be assigned), SendReceive connection Walker Expires û April 2003 [Page 18] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 through to the originating user, User 1. MG1 is only offering G.723.1 (see Remote), so MGC only offers that to MG2. MGC to MG2: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Add = DS0/2/2 { Media { Stream = 1 { LocalControl {Mode = SendReceive } } }, Events = 10 {al/of, ftmd/dtfmctyp, faxctyp/dtone{sdtt=cng}, faxctyp/dtone{sdtt=ansced}, ctyp/dtone{dtt=v21flag}, al/on }, Signals = {al/ri, ctyp/callsig, ctyp/ans} } }, Add = $ { Media { Stream = 1 { LocalControl {Mode = SendReceive }, 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 } ; 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 method shall be used for transitioning from a VoIP state to a FoIP state. The stream port number is 1111 (in the SDP). MG2 to MGC: MEGACO/1.0 [125.125.125.111]:55555 Reply = 30 { Context = 5000 { Add = DS0/2/2, Add = RTP/2 { Media { Walker Expires û April 2003 [Page 19] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Stream = 1 { Local { v=0 c=IN IP4 125.125.125.111 m=audio 1111 RTP/AVP 18 } } } } } } 7) The above IPAddr and UDPport need to be given to MG1 now. Also, because the MGC knows that the T.38 MGC 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.0 [123.123.123.4]:55555 Transaction = 12 { Context = 2000 { Modify = DS0/1/1 { Events = 10 { faxctyp/dtone{sdtt=cng}, faxctyp/dtone{sdtt=ansced}, ctyp/dtone{dtt=v21flag}}, ; detect facsimile tones Signals {cgal/rtri} }, ;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.0 [124.124.124.222]:55555 Reply = 12 { Context = 2000 {Modify = DS0/1/1, Modify = RTP/1} } Walker Expires û April 2003 [Page 20] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 8) The calling fax machine typically will start to generate CNG calling tones. It is envisioned that the CNG tone event will be detected by the first Media Gateway (MG1). This event will be reported to the Media Gateway Controller. The Media Gateway Controller then should 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 an the indicated audio codec such as G.723.1 and G.729A. from MG1 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 50 { Context = 2000 { Notify = DS0/1/1 { ObservedEvents = 1 { 19991212T22110001:faxctyp/dtone{dtst=cng} } } } } from MGC to MG1: MEGACO/1.0 [123.123.123.4]:55555 Reply = 50 { Context = 2000 {Notify = DS0/1/1} } MGC to MG2: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 31 { Context = 5000 { Modify = DS0/2/2 { Signals {faxctyp/callsig{callSigname=cng}}; issue CNG at remote end } } } MG2 to MGC: MEGACO/1.0 [125.125.125.111]:55555 Reply = 31 { Context = 5000 {Modify = DS0/2/2} } 9) In the previous step, the MG2 generated a CNG tone that the MGC asked it to in the Signals descriptor. In the typical case, if the final destination phone number is fax capable, this will result in the issuance of a CED tone by the recipient fax machine. This step is Walker Expires û April 2003 [Page 21] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 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.0 [123.123.123.4]:55555 Transaction = 70 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:faxctyp/dtone{dtst=ANSced}}; CED and ANS are equivalent. Reported under the name ANS. } } } from MGC to MG2: MEGACO/1.0 [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 V.25 and V.8. The modem answer tone without phase reversals is known as ANS in 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 and 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, 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.0 [123.123.123.4]:55555 Transaction = 13 { Context = 2000 { Modify = DS0/1/1 { Walker Expires û April 2003 [Page 22] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Signals {faxctyp/ans{anstype=ansced}} } } } MG1 to MGC: MEGACO/1.0 [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 signaled 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.0 [123.123.123.4]:55555 Transaction = 71 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:ctyp/dtone{dtst=v21flag}} } } } MGC responds. from MGC to MG2: MEGACO/1.0 [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.0 [123.123.123.4]:55555 Transaction = 5{ Context = 2000 { Modify = DS0/1/1 { Walker Expires û April 2003 [Page 23] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Signals {ctyp/ans{anstype=v21flags, SignalType=TimeOut}} Events = 2 { fax/faxconnchange} Media{ Stream=1{ LocalControl {fax/faxstate = Train; } } } } } } MG1 to MGC: MEGACO/1.0 [124.125.125.222]:55555 Reply = 5 { Context = 2000 {Modify = DS0/1/1} 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 it until its 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.0 [123.123.123.4]:55555 Transaction = 33{ Context = 5000 { Modify = DS0/2/2 { Events = 12 { fax/faxconnchange}, Signals{}, Media{ Stream=1{ LocalControl {fax/faxstate = TrainNegotiating; } } } } } } Walker Expires û April 2003 [Page 24] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 And MG2 responds. MG2 to MGC: MEGACO/1.0 [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.0 [123.123.123.4]:55555 Transaction = 15 { Context = 2000 { Modify = RTP/1 { Media { Stream = 1 { LocalControl {ipfax/faxstate = Negotiating; } Local { v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC } ; change to T.38 in the IP connection } } } } } 14) Following is the response from MG1. MG1 changes one of the ôa=ö fields: The T38 parameter transferredTCF is changed by MG1 to localTCF. MG1 may also change the port number if it doesn't want to Walker Expires û April 2003 [Page 25] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 use the existing voice channel for fax transport. In this example, it changes the port from 2222 to 3333. From MG1 to MGC: MEGACO/1.0 [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. From MGC to MG2: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 32 { Context = 5000 { Modify = RTP/2 { Media { Stream = 1 { LocalControl {ipfax/faxstate = Negotiating; } 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 Walker Expires û April 2003 [Page 26] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 } } } } } } 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.0 [125.125.125.111]:55555 Reply = 32 { Context = 5000 { Modify = RTP/2 { Media { Stream = 1 { Local { 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. From MGC to MG1: MEGACO/1.0 [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 } Walker Expires û April 2003 [Page 27] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 } } } } } From MG1 to MGC: MEGACO/1.0 [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 message from MG2 will be a T.30 Indicator packet containing V.21 flags. This will be generated by the continued appearance of V.21 FLAGS on the DS0 since the MG has no memory of previous events. Note that event fax/faxconnchange is left on the event list of both MGs and so each state change will result in a notify to MGC, however, MGC need not explicitly set the fax/faxstate in response, since faxstate should be set implicitly by each MG as it changes state. MGC 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, 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 voice band data capable mode (i.e. up speeding to G.711 or G.726) 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, requesting that the two media gateways switch to a T.38 mode. Walker Expires û April 2003 [Page 28] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 MG2 notifying MGC of V.21 carrier event: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 4 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:fax/dtone{st=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.0 [123.123.123.4]:55555 Transaction = 4 { Context = 5000 { Notify = DS0/2/2 { ObservedEvents = 10 { 19991212T22110031:faxctyp/dtone{dtst=ansam}} } } } 5.2 Fax only between H.248 and H.323 endpoint This facsimile only call flow example describes a facsimile call that originates in the SCN and is terminated in the packet network. The packet network signaling in this example is H.323 Annex D.3 fastStart but other signaling protocols such as SIP can be used, the purpose of the example is to describe MG/MGC interactions. The assumption is made that the signaling between the signaling gateway (SGW) and MGC is based on Q.931. This does not indicate that no other signaling can be used on this interface. Capabilities described here are generic line package descriptions (but could also be SDP or H.245 messages). Walker Expires û April 2003 [Page 29] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 The media gateway is configured for voice and fax, however the H.323 endpoint is fax only. Thus, the MGC will take the call into fax mode only (i.e., it is likely a T.38 Annex B endpoint). 1) The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch. From the Set-up 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 document. 2) 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 to MGC to infer whether both gateways support the T.38 Autonomous method or T.38 MGC 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 H.248): MGC to MG: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 {al/on, ftmd/dtfmctyp/dtone, faxctyp/dtone{dtst=cng}, faxctyp/dtone{dtst=cedans},ctyp/dtone, ctyp/dtone{dtt=cng}, ctyp/dtone{dtt=ans}, ctyp/dtone{dtt=v21flag}, 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 (G.711 PCMU) and 18 (G.729). } } } } } Walker Expires û April 2003 [Page 30] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 3) The MG accepts the Context creation and fills in the unknown ($) parameters. MG1 does not support the T.38 Autonomous method, hence it omits the image media line in the response: MEGACO/1.0 [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. } } } } } 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 a H.323 endpoint (terminal, GW, ...). 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, 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: From MGC to MG: MEGACO/1.0 [123.123.123.4]:55555 From MG to MGC: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 1450 { Context = 2000 { Walker Expires û April 2003 [Page 31] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Modify = RTP/1 { Media { 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 { fax/faxstate=Prepare; fax/trpt=T38UDPTL; Events=fax/faxconnchange; } } } } } } 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.0 [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=image 3333 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC }; The fax udptl/t38 transport channel is accepted on the IP session } } } } } Notify = DS0/1/1 { ObservedEvents = 1 { Walker Expires û April 2003 [Page 32] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 19991212T22110001:ctyp/dtone{dtt=cng} } } } } from MGC to MG: MEGACO/1.0 [123.123.123.4]:55555 Reply = 50 { Context = 2000 {Notify = DS0/1/1} } 8) The MGC sends an Alerting message to the SGW. 9) The called (H.323) endpoint at some instance sends a Connect message to the MGC once the G3FE goes offhook. Note that this message only contains facsimile capabilities and does not include a H.245 port. 10) A Modify command to the MG to change the mode of the SCN side termination to SendRecv and to fax mode. As well, 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.0 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Modify = DS0/1/1 { Media { Stream = 1 { LocalControl { fax/faxstate = Prepare, Mode=SendReceive } } }, Events = 10 {al/of,ftmd/dtfmctyp, faxctyp/dtone{st=cng}, faxctyp/dtone{st=ced}, al/on, fax/faxconnchange }, Signals = {al/ri, ctyp/ans, ctyp/callsig} } ; modify SCN termination to reflect that we are connected through Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=image 2222 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPFEC Walker Expires û April 2003 [Page 33] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 } ; modify media stream 1 to use image media , udptl transport for T38 LocalControl { Mode = SendReceive, ipfax/faxstate=Prepare, ipfax/trpt=T38UDPTL } } }, Events = 2 { ipfax/faxconnchng } } } } 11) The MGC sends a Connect message to the SGW to indicate the call is connected. 12) The MG accepts the Modify command: From MG to MGC: MEGACO/1.0 [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=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 } 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. 13) Note that, since the MG has been asked to indicate when the fax connection state changes, that after the V.21 flags packet is received, the MG notifies the MGC of this event. Walker Expires û April 2003 [Page 34] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 From MG to MGC: MEGACO/1.0 [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.0 [123.123.123.4]:55555 Reply = 60 { Context = 2000 {Notify = RTP/1} } 5.3 Voice to Fax call setup with H.248 endpoints that support the T.38 Autonomous 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 signaling in this example is not specified but any signaling 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 mode including indication to use the T.38 autonomous mode, the detection of fax and switching from voice to fax. 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 Walker Expires û April 2003 [Page 35] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 the MGC that it supports T.38, but because the port is set to '$' the audit shall not be used to indicate support of the T.38 Autonomous method. The MGC audits MG1: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 10 { Context = - {W-AuditCapability = * {Audit{Media, Packages}}} } MG1 replies to MGC: MEGACO/1.0 [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 } }, 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 } } } 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 signaling gateway (SG). The SG sends a Setup message to the MGC after receiving this IAM from a SCN switch Walker Expires û April 2003 [Page 36] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 that conveys the called and calling phone numbers. Sigtran's SCTP carries the SS7 signaling 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 document. The end points 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 $ the fields in the SDP in Local that the MG will set itself. Also, in order for the to MGC to infer whether both gateways support the T.38 Autonomous method or T.38 MGC method, the MGC instructs MG1 to respond with the values of both its audio RTP/AVP capabilities and its image/t38 capabilities (by setting to $ the ports for both the audio and the image media lines). 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). MGC to MG1: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Media { Stream = 1 { } } } Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly, ReserveGroup=True }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 18 V=0 c=IN IP4 $ m=image $ udptl t38 Walker Expires û April 2003 [Page 37] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 }; IP termination for audio } } } } } 4) MG1 acknowledges the new Termination and fills in the Local IP address and UDP port. It also makes a choice for the Codec based on the list within the media descriptor of the SDP block in Local. MG1 sets the RTP port to 2222. Because the MG supports T.38 Autonomous 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 the T.38 method for transitioning between VoIP & FoIP it would set the T.38 port to 0 or omit the image media descriptor line all together, and would proceed as indicated in III2.1. From MG1 to MGC: MEGACO/1.0 [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 v=0 c=IN IP4 124.124.124.222 m=image 4444 udptl t38 a=T38FaxRateManagement:transferredTCFlocalTCF 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/2 will be assigned) and a T.38 stream SendReceive connections through to the originating user, User 1. Also, because MG1 supports the T.38 Autonomous method, the MGC needs to find out whether the MG2 supports the T.38 Autonomous Walker Expires û April 2003 [Page 38] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 method, for which the MGC will ask MG2 by including a audio media descriptor and an image media descriptor with the ports set to $ in the Add ephemeral of the create context message, as well as indicating that the remote MG supports T.38 Autonomous method. 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) . MGC to MG2: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Add = DS0/2/2 { Media { Stream = 1 { LocalControl {Mode = SendReceive}, ReserveGroup=True } }, } }, Add = $ { Media { Stream = 1 { LocalControl {Mode = SendReceive }, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 0 18 v=0 c=IN IP4 $ m=image $ udptl t38 }, Remote { 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 4444 udptl t38 a=T38FaxRateManagement:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC } ; RTP profile for G.711 is 0 } } } } } Walker Expires û April 2003 [Page 39] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 6) This is acknowledged. Also, because MG2 supports the T.38 Autonomous 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 & FoIP using the T.38 Autonomous 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 method for transitioning from an audio/RTP connection to an image/t38 connection and the procedures in point 7 of III.2.1 follow. MG2 to MGC: MEGACO/1.0 [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:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC } } } } } } 7) The above IPAddr and UDPport need to be given to MG1 now. As well as indicating that MG2 supports the T.38 Autonomous method for transitioning between VoIP & FoIP. Also apply ringing toneringback to the DS0/1/1 termination and change it to a SendReceive MGC to MG1: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 12 { Context = 2000 { Walker Expires û April 2003 [Page 40] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 Modify = DS0/1/1 { Signals {cgal/rtri} }, ;apply ringing tone Modify = RTP/1 { Media { 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:transferredTCFlocalTCF a=T38FaxUdpEC:t38UDPFEC } } } } } } from MG1 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Reply = 12 { Context = 2000 {Modify = DS0/1/1, Modify = RTP/1} } 8) MG1 acknowledges, and shall use the T.38 Autonomous method for transitioning from audio/RTP connection to an image/t38 connection. 9) 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/T.38 mode, this packet will be decoded and analyzed to be of type CNG, thus playing out the appropriate CNG tone. In order to avoid any UDP packet that arrives at the T.38 UDP Walker Expires û April 2003 [Page 41] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 port, this port should be activated only if T.38 Autonomous method (and T.38 capabilities) was successfully negotiated before the call. From here on both MGs will operate in accordance with Rec. T.38. 10) 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 bi-directional silence. It is recommended to detect transition back to voice mode on detection of more than 7 sec of bi-directional 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. 5.4 Voice to Fax call set-up between H.248 and H.323 endpoint that support the T.38 Autonomous method. This facsimile only call flow example describes a facsimile call that originates in the SCN and is terminated in the packet network. The packet network signaling in this example is H.323 Annex D.3 but other signaling protocols such as SIP can be used, the purpose of the example is to describe MG/MGC interactions. The assumption is made that the signaling between the signaling gateway (SGW) and MGC is based on Q.931. This does not indicate that no other signaling 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 & 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. The sequence of the call Set-up events between the MG, the MGC and the H.323 endpoint should be as follows: 1) The SGW sends a Set-up message to the MGC after receiving an IAM from a SCN switch. 2) 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 document. Walker Expires û April 2003 [Page 42] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 3) 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 to MGC to infer whether both gateways support the T.38 Autonomous method or T.38 MGC 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=True to ask for all the codecs for which it can reserve resources for, however if omitted an MG by default must set this value to false and return the preferred codec): MGC to MG: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 11 { Context = $ { Add = DS0/1/1 { Events = 1 {al/on, ftmd/dtfmctyp/dtone, faxctyp/dtone{dtst=cng}, faxctyp/dtone{dtst=cedans},ctyp/dtone, ctyp/dtone{dtt=cng}, ctyp/dtone{dtt=ans}, ctyp/dtone{dtt=v21flag}, 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 method, hence it includes the image media line with an appropriate port number in the response: MEGACO/1.0 [124.124.124.222]:55555 Walker Expires û April 2003 [Page 43] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 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 0 v=0 c=IN IP4 124.124.124.222 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 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 a H.323 endpoint (terminal, GW, ...). Also, because it knows that the MG supports the T.38 Autonomous 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 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 offhook. Note that this message contains both the audio and facsimile capabilities and does not include a H.245 port. Walker Expires û April 2003 [Page 44] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 10) A Modify command is sent to the MG to change the mode of the SCN side termination to SendRecv as well as 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 method and that the call shall initially be set up as a voice call: MGC to MG: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 30 { Context = $ { Modify = DS0/1/1 { Media { Stream = 1 { LocalControl { fax/faxstate = Prepare, ReserveGroup=True } } }, Events = 10 {al/of, fax/faxconnchange },; the MGC request the MG to send it an event when it transitions to T.38. Signals = {al/ri, ctyp/callsig} } ; modify SCN termination to reflect that we are connected through Modify = RTP/1 { Media { Stream = 1 { Local { v=0 c=IN IP4 124.124.124.222 m=audio 1111 RTP/AVP 0 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, ipfax/faxstate=Prepare, ipfax/trpt=T38UDPTL } } }, Events = 2 { ipfax/faxconnchng } } } } Walker Expires û April 2003 [Page 45] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 11) The MGC sends a Connect message to the SGW to indicate the call is connected. 12) The MG accepts the Modify commands: from MG to MGC: MEGACO/1.0 [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 0 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 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 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. 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 Rec. T.38. The gateways 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 bi-directional silence. It is recommended to detect transition back to voice mode on detection of more than 7 sec of bi-directional silence to allow for the T.30 T2 timers (within the G3FEs) to time-out. Walker Expires û April 2003 [Page 46] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 c) Detection of Voice d) Reception of a Modify command in which only an audio media descriptor is present. Security Considerations Security considerations are addressed as per Section 10 of RFC 3015 [6]. Megaco/H.248 procedures for VBD transport service control inheriting the security requirements of Megaco/H.248. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 ITU-T Recommendation H.248, "Gateway Control Protocol", June 2000 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", June 1998 5 ITU-T Recommendation H.323, "Packet-Based Multimedia Communication Systems", 1998 6 Cuervo, et al., "Megaco Protocol Version 1.0", RFC 3015, November 2000 7 Handley, et al, ôSIP: Session Initiation Protocolö, RFC 2543, March 1999 8 ITU-T Recommendation T.30, ôProcedures for document facsimile transmission in the general switched telephone networkö, April 1999. Acknowledgments Walker Expires û April 2003 [Page 47] H.248 (megaco) MG Autonomous T38 Transitioning October 2002 This document is reflecting many ideas and thoughts of approved, draft, evolving, and work-in-progress standards. The author wishes to thank to all contributors, especially the Megaco/H.248, H.323 and FoIP (T.38 [4]). Author's Addresses Dominic Walker Nortel Networks Maidenhead Office Park, Westacott Way, Maidenhead, Berkshire SL6 3QH Great Britain Phone: +44 1279 403379 Email: dominic.walker@nortelnetworks.com Walker Expires û April 2003 [Page 48]