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]