One document matched: draft-andreasen-mgcp-fax-02.txt
Differences from draft-andreasen-mgcp-fax-01.txt
Internet Engineering Task Force F. Andreasen
Internet Draft Cisco Systems
Document: draft-andreasen-mgcp-fax-02.txt October, 2003
Category: Informational
Media Gateway Control Protocol Fax Package
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
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 defines a Media Gateway Control Protocol (MGCP)
package to support fax calls. The package allows for fax calls to
be supported in two different ways. The first one utilizes ITU-T
Recommendation T.38 for fax relay under the control of the Call
Agent. The second one lets the gateway decide upon a method as well
as handle the details of the fax call without Call Agent
involvement.
Conventions used in this document
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 BCP 14, RFC-2119
[RFC2119].
Andreasen Informational - Expires April 2004 1
MGCP Fax Package October 2003
Table of Contents
1. Introduction......................................................3
2. Fax Package Definition............................................3
2.1 LocalConnectionOptions..........................................3
2.1.1 T.38 Mode (Strict or Loose).................................5
2.1.2 Gateway Mode................................................6
2.1.3 Off Mode....................................................6
2.1.4 Mode Operation..............................................6
2.2 Events and Signals..............................................8
2.3 Connection Parameters..........................................10
2.4 Media IP Address and Port for T.38.............................11
3. Call Flow Examples...............................................11
3.1 Call Agent Controlled T.38 Strict..............................11
3.2 Multiple and Different Options.................................17
4. Security Considerations..........................................24
5. IANA Considerations..............................................24
6. Normative References.............................................24
7. Informative References...........................................24
8. Acknowledgements.................................................25
9. Author's Address.................................................25
Intellectual Property Statement.....................................26
Acknowledgement.....................................................27
Andreasen Informational - Expires April 2004 2
MGCP Fax Package October 2003
1. Introduction
This document defines a Media Gateway Control Protocol (MGCP)
[RFC3407] package that enables MGCP controlled gateways to support
fax calls. The package enables fax calls to be supported in two
different ways. The first one utilizes ITU-T Recommendation T.38
for fax relay under the control of the Call Agent. The second one
lets the gateway decide upon a method as well as handle the details
of the fax call without Call Agent involvement.
The fax package definition is provided in Section 2 and in Section 3
we provide two call flow examples showing how to use it. Security
considerations are found in Section 4, followed by the IANA
considerations and references.
2. Fax Package Definition
A package is defined for fax. The package defines new
LocalConnectionOptions, events, and connection parameters as
detailed below.
Package Name: FXR
Package Version: 0
2.1 LocalConnectionOptions
A new Fax LocalConnectionOptions (LCO) parameter is defined for fax
handling. The Call Agent supplies this fax LCO to indicate the
desired fax handling to the Media Gateway. The fax parameter
contains an ordered list of desired fax handling options. When the
parameter is explicitly included in a command, the gateway MUST be
able to use at least one of the listed options for the command to
succeed. The list can currently contain one or more of the
following (see Section 2.1.1 to 2.1.4 for further details on these):
* T.38 Strict Use T.38 [T38] for fax relay and have the Call
Agent control it. Assuming the procedure can be used (see Section
2.1.1), a switch to T.38 procedures will be initiated upon fax
detection and a "t38(start)" event will be generated (see Section
2.2). This mode requires an indication of T.38 support from the
remote side in order to be used, as described further in Section
2.1.1.
* T.38 Loose Identical to T.38 Strict mode, except that an
indication of T.38 support from the remote side is not required
for the mode to be used.
* Off Do not invoke any special procedure for fax,
except for echo cancellation adjustment and possibly switching to
another codec.
Andreasen Informational - Expires April 2004 3
MGCP Fax Package October 2003
* Gateway Let the gateway control and decide how to
handle fax calls without Call Agent involvement. This includes
the case where the gateway does not do anything special for fax,
hence by definition this option can always be supported. If the
gateway does invoke a special procedure upon detection of fax, it
will generate a "gwfax(start)" event so the Call Agent can be
notified about it (see Section 2.2). The Call Agent SHOULD then
refrain from issuing potentially conflicting commands to the
gateway until the gateway ends its special fax handling.
A gateway that ends up not being able to invoke any special
procedure for fax will generate a "nopfax(start)" event (see Section
2.2) upon detection of fax.
The set of possible values for the Fax LCO is extensible. The
prefix "x-", which indicates an optional extension, and the prefix
"x+", which indicates a mandatory extension, are reserved for vendor
specific use. In CreateConnection commands, the Fax LCO defaults to
"gateway". In ModifyConnection commands, it defaults to its current
value on the connection. If LocalConnectionOptions are either
omitted or the fax parameter is not included in a ModifyConnection
command, the previous fax parameter value for the connection will
thus be retained, but without affecting the outcome of the command
(consequently, the gateway may not apply any special procedure to
fax - if the Call Agent wants to ensure that either a procedure is
applied or the command fails, it MUST include the fax LCO parameter
again).
As an example of this, assume that the CreateConnection command
successfully specified the use of "T.38 Strict", and a
ModifyConnection command is now received without the Fax LCO,
but with a RemoteConnectionDescriptor indicating no support of
T.38; in that case, the ModifyConnection will succeed, however
T.38 procedures will no longer be invoked upon fax. Had the
Call Agent instead included the Fax LCO set to "T.38 Strict"
with the ModifyConnection command, the command would have
failed.
If multiple fax parameter values are provided, the gateway MUST
choose one of the values. Please refer to Section 2.1.4 for further
details.
The fax LCO parameter is encoded as the keyword "fx" (prefixed with
the package name), followed by a colon and a semicolon separated
list of values where T.38 Strict is encoded as "t38", T.38 Loose is
encoded as "t38-loose", gateway is encoded as "gw", and off is
encoded as "off".
The following example illustrates use of PCMU or G.729 for audio
encoding and T.38 Strict fax relay (preferred) or gateway control
for fax:
L: a:PCMU;G729, fxr/fx:t38;gw
Andreasen Informational - Expires April 2004 4
MGCP Fax Package October 2003
When auditing capabilities, the "fax" LCO may be returned with a
semi-colon separated list of supported fax handling parameters. The
values "t38", "off" and "gw" MAY be omitted from such a list as they
are always implied. Gateways that implement additional parameters
SHOULD return these additional parameters when capabilities are
audited as illustrated by the following example:
A: a:image/t38, fxr/fx:mypar, ...
We now provide additional detail on the above defined fax modes.
2.1.1 T.38 Mode (Strict or Loose)
When a gateway is instructed to operate in Call Agent controlled
T.38 mode, the "m=" line in the SDP returned will not indicate T.38
(unless the gateway was also instructed to use T.38 for the media
stream), however capability information for T.38 (if supported)
using the SDP Simple Capability Declaration extensions [RFC3407]
SHOULD be included as illustrated in the following example - other
capability information MAY be included as well:
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18
a=cdsc: 2 image udptl t38
For a list of T.38 related parameters to be included in the SDP,
please refer to T.38 Annex D [T38]. A gateway operating in Call
Agent controlled T.38 mode that detects a fax will:
1. Initiate the T.38 fax relay procedure and mute the media channel
(unless the media channel is already using T.38).
2. Generate a "t38(start)" event.
3. Await further instructions from the Call Agent in order to
initiate the actual media change.
The Call Agent instructs the gateway to perform the media change by
sending it a ModifyConnection command with "image/t38" listed as the
encoding method in the LocalConnectionOptions (receipt of a
ModifyConnection command without LocalConnectionOptions but with a
RemoteConnectionDescriptor containing an "m=" line with the MIME
type "image/t38" would achieve the same). Per the normal MGCP codec
negotiation procedures (see [RFC3435] Section 2.6), if a
RemoteConnectionDescriptor was included as well, it MUST include an
"m=" line listing T.38 fax relay as an acceptable media format in
order for the command to succeed. If a RemoteConnectionDescriptor
was not included with the ModifyConnection command sent to a gateway
under Call Agent T.38 control, it is possible (in fact likely), that
the last received RemoteConnectionDescriptor did not include an "m="
line listing T.38 fax relay as an acceptable media format. In that
case, the endpoint cannot send T.38 media. The endpoint MUST
Andreasen Informational - Expires April 2004 5
MGCP Fax Package October 2003
instead wait for an updated RemoteConnectionDescriptor with T.38 fax
relay listed as an acceptable media format. If the fax call fails,
e.g. due to a fax timeout, while waiting for the updated
RemoteConnectionDescriptor with T.38, a "t38(stop)" or a
"t38(failure)" event will be generated. Otherwise, the procedure
continues when an acceptable RemoteConnectionDescriptor is received.
When the T.38 procedure ends, a "t38(stop)" or "t38(failure)" event
will be generated.
2.1.2 Gateway Mode
A gateway operating in Gateway controlled mode may initiate special
fax handling upon detecting a fax call. The details of this special
fax handling are outside the scope of this document. However, in
order to use any special fax handling, support for it MUST be
negotiated with the other side by passing and recognizing relevant
parameters via the RemoteConnectionDescriptor. If the other side
has not indicated support for the special fax handling desired, the
gateway MUST NOT attempt to initiate it. When special fax handling
is initiated, a "gwfax(start)" event is generated thereby enabling
the Call Agent to differ between the Call Agent and gateway
controlled mode while still being informed about the actual change
to fax. The special gateway handling of fax ends when a
"gwfax(stop)" or "gwfax(failure)" event is generated.
2.1.3 Off Mode
A gateway using the "off" mode will not invoke any special fax
procedures, e.g. T.38, when detecting a fax. However, the gateway
may still adjust local echo cancellation and/or switch to an
alternative voice codec as needed. Also, a "nopfax(start)" event
will be generated; a corresponding "stop" event however will not.
Generating a "stop" event would imply that the gateway had to
infer when the fax call ends, which involves processing of the
media stream. However, when using the "off" mode, such processing
is not expected to occur.
2.1.4 Mode Operation
For each of the above modes, the RemoteConnectionDescriptor provides
information on what procedure(s) the other side supports. The
following rules are used to determine which procedure to use:
1. Whatever the Call Agent specified in the Fax
LocalConnectionOptions for the current command MUST be adhered
to. If the gateway cannot satisfy any of the options, the
command fails (error code 532 - unsupported value(s) in
LocalConnectionOptions is RECOMMENDED).
2. If both Fax LocalConnectionOptions and a
RemoteConnectionDescriptor are provided, the procedure selected
Andreasen Informational - Expires April 2004 6
MGCP Fax Package October 2003
MUST be supported by both sides - this is currently only an issue
for "T.38 Strict". A procedure can be satisfied by the remote
side if:
* the relevant media format, e.g. T.38, is included in the "m="
line in the RemoteConnectionDescriptor, or
* the relevant media format is included as a capability (see
[RFC3407]) in the RemoteConnectionDescriptor.
If the gateway cannot select any of the procedures in the Fax
LocalConnectionOptions, the command fails (error code 532 is
RECOMMENDED). Note that "T.38 Loose", "gateway", and "off" by
definition will not lead to failure.
3. If the Call Agent did not include any Fax LocalConnectionOptions
or a RemoteConnectionDescriptor with the command, the gateway
MUST continue using whichever procedure it is currently using.
4. If the Call Agent did not include any Fax LocalConnectionOptions,
but a RemoteConnectionDescriptor was included, the gateway
follows rule 2 in selecting a procedure. In so doing, the
default Fax LocalConnectionOptions, i.e. "gateway" in
CreateConnection, or the current value in ModifyConnection, will
be used. In the case of ModifyConnection, the outcome of the
command does not depend on the gateway being able to select one
of these "default" procedures (as described in Section 2.1). Note
that this is not an issue for CreateConnection, since the default
value can always be supported by definition.
5. A previously received RemoteConnectionDescriptor does not affect
what procedure can be selected. Only a
RemoteConnectionDescriptor supplied with the current command
affects the procedure selection. However, in order to send media
of a given type (e.g. "image/T.38"), the most recently received
RemoteConnectionDescriptor MUST include a corresponding media
line.
The following examples illustrate the use of the above rules:
Per rule 1, a gateway that only supports standard T.38 fax relay
will fail a command that only contains the fax option "mypar"
whereas it will succeed a command that contains, "t38-loose", "gw",
"off" or no Fax LCO. A command that only contained "t38" may or may
not succeed (depending on the RemoteConnectionDescriptor).
A gateway supporting T.38 that receives a CreateConnection command
with the fax handling LCO set to "t38" and a
RemoteConnectionDescriptor with neither a T.38 capability nor a T.38
media stream will fail per rule 2. Had the fax handling LCO
included either "t38-loose", "gw" or "off", the command would have
succeeded and any of the procedures included could have been
selected.
Andreasen Informational - Expires April 2004 7
MGCP Fax Package October 2003
Assume a gateway supporting T.38 has successfully executed a
CreateConnection command with fax handling set to "t38". If the
gateway now receives a ModifyConnection command without a fax
handling LCO but with a RemoteConnectionDescriptor that has neither
a T.38 capability nor a T.38 media stream, the command will succeed
(since rule 1 has no effect in that case). However, per rule 2 and
4, there will not be any T.38 procedure in place. Had the CA
instead included a fax handling LCO set to "t38" again, the command
would have failed per rule 2.
Finally, it should be noted that a switch to T.38 can be initiated
by either one or both of the originating and terminating gateways
and hence implementations MUST be prepared to handle this. This
includes the case where both sides initiate the switch, which for
example can occur when the originating fax generates Calling Tone
(CNG) and the terminating fax detects V.21 fax preamble (see [T30])
before the switch to T.38 has been performed on the terminating
side.
2.2 Events and Signals
The following events are defined in support of the above:
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| gwfax | Gateway controlled fax | x | |
| nopfax | No special fax handling | x | |
| t38 | T.38 fax relay | x | |
------------------------------------------------------------------
The definition of the individual events are as follows:
Gateway Controlled Fax (gwfax):
Gateway controlled fax handling. The gateway controlled fax event
is parameterized with one of the following:
* start Gateway controlled fax was initiated. The Call
Agent SHOULD refrain from issuing media handling instructions to
the gateway until either a "gwfax(stop)" or "gwfax(failure)"
event is generated.
* stop Gateway controlled fax ended and the gateway
did not detect any errors. Note that this does not necessarily
imply a successfully transmitted fax. It merely indicates that
the gateway controlled fax procedure has ended and the procedure
itself did not encounter any errors. Media parameters for the
connection are as before the gateway handled fax started.
* failure The procedure ended abnormally. Some kind of
problem was encountered in the gateway controlled fax procedure
and the procedure ended. Media parameters are as before the
gateway handled fax started.
Andreasen Informational - Expires April 2004 8
MGCP Fax Package October 2003
The "gwfax" event MAY be parameterized with additional parameters,
however it is RECOMMENDED that one of the above parameters is the
first parameter supplied. Unknown parameters MUST be ignored.
The following example illustrates the encoding of the "gwfax"
event:
O: fxr/gwfax(start)
O: fxr/gwfax(stop, foobar)
No Special Fax Handling(nopfax):
There is no special fax handling in place, however a fax call is
now detected. This can happen either due to no special procedure
being requested (including "off"), or negotiation leading to no
special fax handling being possible. The event is parameterized
with the following:
* start No special fax handling is in place, however a
fax call is now detected. The Call Agent may have to issue
further commands in order to ensure a successful fax call (e.g.
switch to another codec).
The "nopfax" event MAY be parameterized with additional
parameters, however it is RECOMMENDED that the above parameter is
the first parameter supplied. Unknown parameters MUST be ignored.
Note, that this event currently cannot be parameterized with
"stop" or "failure" as it only detects the beginning of a fax
call.
The following example illustrates the encoding of the "nopfax"
event:
O: fxr/nopfax(start)
T.38 fax relay(t38):
Call Agent controlled T.38 fax relay. The Call Agent controlled
T.38 fax relay event is parameterized with one of the following:
* start Call Agent controlled T.38 fax relay was
initiated. The Call Agent SHOULD modify each side of the
connection to start using T.38 media format, unless they already
do.
* stop Call Agent controlled T.38 fax relay ended and
the gateway did not detect any errors. Note that this does not
necessarily imply a successfully transmitted fax. It merely
indicates that the Call Agent controlled T.38 fax relay
procedure has ended and the procedure itself did not encounter
any errors. The Call Agent may want to modify the media
parameters for each side of the connection (note that, in
contrast to the gateway controlled fax case, media parameters
such as codecs do not automatically revert to their values
before the start of the fax call; echo cancellation and silence
Andreasen Informational - Expires April 2004 9
MGCP Fax Package October 2003
suppression however does per the procedures in [RFC3435] Section
2.3.5).
* failure Call Agent controlled T.38 fax relay ended
abnormally. Some kind of problem in the Call Agent controlled
T.38 fax relay procedure was encountered and the procedure
ended. The Call Agent may want to modify the media parameters
for each side of the connection (note that, in contrast to the
gateway controlled fax case, media parameters such as codecs do
not automatically revert to their state before the start of the
fax call; echo cancellation and silence suppression however does
per the procedures in [RFC3435] Section 2.3.5).
The "t38" event MAY be parameterized with additional parameters,
however it is RECOMMENDED that one of the above parameters is the
first parameter supplied. Unknown parameters MUST be ignored.
The following example illustrates the encoding of the "t38" event:
O: fxr/t38(start)
O: fxr/t38(foobar, stop)
2.3 Connection Parameters
The connection parameters for the connection, that measures packets
and octets sent and received, MUST include packets and octets for
fax handling as well. Interarrival jitter and average transmission
delay calculation however MAY not be performed while fax is in
progress, e.g., if T.38 is used. In such cases, the interarrival
jitter and average transmission delay calculations are simply
suspended until calculations can resume, e.g., by changing back to
an RTP media stream again.
In addition to these connection parameters, the fax package defines
the following connection parameters, which gateways MAY support:
Number of fax pages sent (PGS):
The cumulative number of fax pages sent by the endpoint for the
life of the connection. The parameter is encoded as "PGS" and the
value supplied is a string of up to nine decimal digits.
Number of fax pages received (PGR):
The cumulative number of fax pages sent by the endpoint for the
life of the connection. The parameter is encoded as "PGR" and the
value supplied is a string of up to nine decimal digits.
The following example illustrates the use of these parameters:
P: FXR/PGS=3, FXR/PGS=0, PS=1245, OS=62345, ...
Andreasen Informational - Expires April 2004 10
MGCP Fax Package October 2003
2.4 Media IP Address and Port for T.38
When an endpoint is instructed to change to or from T.38 for a media
stream, it SHOULD continue using the same IP address and port as the
media stream is currently using, since this will minimize any
Quality of Service, and NAT and Firewall interactions from the
change. However, if an endpoint has a good reason, it MAY choose
not to follow this recommendation.
3. Call Flow Examples
In this section, we provide two example call flows. The first one
illustrates a T.38 fax call under Call Agent control on both the
originating and terminating side. The second one illustrates the
use of multiple and different options on the two sides.
3.1 Call Agent Controlled T.38 Strict
In this example, both sides are under strict T.38 Call Agent
control. We assume the originating and terminating Call Agent
communicate via the Session Initiation Protocol (SIP) [RFC3261]
(also, see [SIPfax]):
Andreasen Informational - Expires April 2004 11
MGCP Fax Package October 2003
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | | <- ANS/ |
| | | | | T.30 CED |
|10| | | | <- T.30 fax |
| | | | | preamble |
|11| | | <-|NTFY(t38 start)|
|12| | | 200|-> |
|13| | | MDCX(t38)|-> |
|14| | | <-|200(sdp-t2) |
|15| | <-|INVITE(sdp-t2) | |
|16| <-|MDCX(sdp-t2) | | |
|17| 200(sdp-o2)|-> | | |
|18| | 200(sdp-o2)|-> | |
|19| | | MDCX(sdp-o2)|-> |
|20| | | <-|200 |
|--|---------------|---------------|---------------|---------------|
|21| | | | (fax ends) |
|22| | | <-|NTFY(t38 stop) |
|24| | | 200|-> |
------------------------------------------------------------------
Step 1:
The Call Agent issues a CreateConnection command to the gateway
instructing it to use PCMU media encoding and to use the strict Call
Agent controlled T.38 mode. Consequently, the Call Agent asks the
gateway to notify it of the t38 event:
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38
M: recvonly
R: fxr/t38
X: 1
Step 2:
The gateway acknowledges the command and includes SDP with codec
information as well as RFC 3407 capability information:
Andreasen Informational - Expires April 2004 12
MGCP Fax Package October 2003
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 3:
The originating Call Agent sends a SIP INVITE message with the SDP
to the terminating Call Agent.
Step 4:
The terminating Call Agent issues a CreateConnection command to the
terminating gateway instructing it to use PCMU media encoding and to
use the strict Call Agent controlled T.38 mode. Consequently, the
Call Agent asks the gateway to notify it of the t38 event:
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:t38
M: sendrecv
R: fxr/t38
X: 20
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 5:
The terminating gateway supports T.38, and the
RemoteConnectionDescriptor included indicates that the other side
supports T.38 as well, so the strict T.38 Call Agent controlled mode
requested can be used. The terminating gateway sends back a success
response with its SDP which also includes capability information:
Andreasen Informational - Expires April 2004 13
MGCP Fax Package October 2003
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 6:
The terminating Call Agent sends back a SIP 200 OK response to the
originating Call Agent, which in turn sends a SIP ACK (not shown).
Step 7:
The originating Call Agent in turns sends a ModifyConnection command
to the originating gateway:
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
The ModifyConnection command does not repeat the
LocalConnectionOptions sent previously. As far as fax handling is
concerned, the gateway therefore attempts to continue using the
current fax handling, i.e. strict Call Agent controlled T.38. Since
the capability information indicates the other side supports T.38,
the gateway will in fact be able to use strict Call Agent controlled
T.38. Had there not been any support for T.38 in the
RemoteConnectionDescriptor, then this command would still have
succeeded, however there would be no special fax handling.
Step 8:
The gateway acknowledges the command. At this point, a call is
established is using PCMU encoding, and if a fax call is detected,
the Call Agent controlled T.38 procedure will be initiated.
Andreasen Informational - Expires April 2004 14
MGCP Fax Package October 2003
Step 9-11:
A fax call now occurs. First, the T.30 CED tone (aka. V.25 ANS) is
sent which in this case is simply passed through the current PCMU
encoding. Since both fax and modem calls can start with this
sequence, it is not possible to determine that this is a fax call
until step 10, where the V.21 fax preamble is detected.
Since the gateway is instructed to apply the Call Agent controlled
T.38 procedure for fax calls, the "t38(start)" event occurs, which
is notified to the Call Agent:
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: fxr/t38(start)
X: 20
Step 12:
The Call Agent acknowledges the Notify command:
200 2500 OK
Step 13:
The Call Agent then instructs the terminating gateway to change to
using the T.38 codec instead:
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
Step 14:
The gateway changes to T.38, and sends back a success response with
updated SDP:
200 2002 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Note, that since the gatewayÆs current RemoteConnectionDescriptor
(as opposed to the LocalConnectionDescriptor returned here) does not
Andreasen Informational - Expires April 2004 15
MGCP Fax Package October 2003
list "image/t38" as a valid encoding method, the terminating gateway
is still muting the media and is now waiting for an updated
RemoteConnectionDescriptor with "image/t38".
Step 15:
The terminating Call Agent sends a re-INVITE to the originating Call
Agent with the updated SDP.
Step 16:
The originating Call Agent then sends a ModifyConnection command to
the originating gateway:
MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
v=0
o=- 25678 753850 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 17:
The originating gateway changes to T.38 and sends back a success
response with updated SDP:
200 1003 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 18:
The originating Call Agent sends a SIP 200 OK response with the
updated SDP to the terminating Call Agent, which in turn sends a SIP
ACK (not shown).
Step 19:
Andreasen Informational - Expires April 2004 16
MGCP Fax Package October 2003
The terminating Call Agent sends a ModifyConnection with the updated
SDP to the terminating gateway:
MDCX 2003 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 20:
The terminating gateway sends back a success response:
200 2003 OK
Since the terminating gateway now has a RemoteConnectionDescriptor
with "image/t38" as valid media, it can start exchanging T.38 with
the originating gateway.
Step 21, 22:
When the fax ends, a "t38(stop)" event is generated, which is
notified to the Call Agent:
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: t38(stop)
X: 3
Step 23:
The Call Agent acknowledges the Notify command:
200 2501 OK
The fax call is now over. The Call Agent may now decide to change
back to a voice codec, delete the connection, or something
different.
3.2 Multiple and Different Options
In this example, the originating gateway is instructed to use the
gateway mode whereas the terminating gateway is given a choice
between gateway mode and strict t38 mode. Furthermore, the
originating fax machine is generating CNG tone.
Andreasen Informational - Expires April 2004 17
MGCP Fax Package October 2003
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| CNG ->| | | |
|10| | | |<- ANS/T.30 CED|
|11| | | |<- T.30 fax p. |
|12| | | <-|NTFY(t38 start)|
|13| | | 200|-> |
|14| | | MDCX(t38)|-> |
|15| | | <-|200(sdp-t2) |
|16| | <-|INVITE(sdp-t2) | |
|17| <-|MDCX(sdp-t2) | | |
|18| 200(sdp-o2)|-> | | |
|19| | 200(sdp-o2)|-> | |
|20| | | MDCX(sdp-o2)|-> |
|21| | | <-|200 |
|--|---------------|---------------|---------------|---------------|
|22| | | | (fax ends) |
|23| | | <-|NTFY(t38 stop) |
|24| | | 200|-> |
------------------------------------------------------------------
Step 1:
The Call Agent issues a CreateConnection command to the gateway
instructing it to use PCMU media encoding and to use the gateway
mode. Consequently, the Call Agent asks the gateway to notify it of
the gwfax event:
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:gw
M: recvonly
R: fxr/gwfax
X: 1
Step 2:
The gateway acknowledges the command and includes SDP with codec
information as well as capability information:
Andreasen Informational - Expires April 2004 18
MGCP Fax Package October 2003
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme123
We assume the gateway supports some other fax scheme and it
indicates this by including an attribute "FaxScheme123"
Step 3:
The originating Call Agent sends a SIP INVITE message with the SDP
to the terminating Call Agent.
Step 4:
The terminating Call Agent issues a CreateConnection command to the
terminating gateway instructing it to use PCMU media encoding and to
use either the gateway mode or strict Call Agent controlled T.38
mode. Consequently, the Call Agent asks the gateway to notify it of
both the gwfax and t38 events:
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:gw,t38
M: sendrecv
R: fxr/t38, fxr/gwfax
X: 20
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme123
Step 5:
The terminating gateway does not support any special gateway fax
handling, however it does support T.38, and the
RemoteConnectionDescriptor included indicates that the other side
Andreasen Informational - Expires April 2004 19
MGCP Fax Package October 2003
supports T.38 as well, so the strict T.38 Call Agent controlled mode
requested can be honored. The terminating gateway sends back a
success response with its SDP which also includes capability
information:
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 6:
The terminating Call Agent sends back a SIP 200 OK response to the
originating Call Agent, which in turn sends a SIP ACK (not shown).
Step 7:
The originating Call Agent in turns sends a ModifyConnection command
to the originating gateway:
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
The ModifyConnection command does not repeat the
LocalConnectionOptions sent previously. As far as fax handling is
concerned, the gateway therefore attempts to continue using the
current fax handling, i.e. the gateway mode. The SDP information
returned however does not indicate support for the "FaxScheme123",
and hence the originating gateway will not invoke any special fax
handling for this call.
Andreasen Informational - Expires April 2004 20
MGCP Fax Package October 2003
Step 8:
The gateway acknowledges the command. At this point, a call is
established using PCMU encoding and if a fax call is detected, no
special fax handling will occur.
Step 9-12:
First, a CNG tone is generated by the originating fax thereby
indicating a fax call. If the gateway was using either of the T.38
modes, or it had negotiated support for special gateway handling
with the other side, a "t38(start)" or "gwfax(start)" event would
now have been generated and the switch to T.38 (or special gateway
handling) could start. However, since the negotiation with the
terminating gateway resulted in the originating gateway not doing
anything special for fax, no such event is generated. Instead, the
"nopfax(start)" event is now generated, but since the Call Agent has
not requested this event, it is not detected and hence not reported
to the Call Agent. Consequently, the CNG tone is simply passed
through the current PCMU encoding without the (originating) Call
Agent being aware of the fax call.
Subsequently, the T.30 CED tone (aka. V.25 ANS) occurs which in this
case is also simply passed through the current PCMU encoding. Since
both fax and modem calls can start with this sequence, it is not
possible to determine that this is a fax call until step 11, where
the V.21 fax preamble is detected.
Since the terminating gateway is using the Call Agent controlled
T.38 procedure for fax calls, the "t38(start)" event occurs, which
is notified to the Call Agent:
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: fxr/t38(start)
X: 20
Step 13:
The Call Agent acknowledges the Notify command:
200 2500 OK
Step 14:
The Call Agent then instructs the terminating gateway to change to
using the T.38 codec instead:
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
Andreasen Informational - Expires April 2004 21
MGCP Fax Package October 2003
Step 15:
The gateway changes to T.38, and sends back a success response with
updated SDP:
200 2002 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Note, that since the terminating gatewayÆs last received
RemoteConnectionDescriptor (as opposed to the
LocalConnectionDescriptor returned here) did not list "image/t38" as
a valid encoding method, the terminating gateway is still muting the
media and is now waiting for an updated RemoteConnectionDescriptor
with "image/t38".
Step 16:
The terminating Call Agent sends a re-INVITE to the originating Call
Agent with the updated SDP.
Step 17:
The originating Call Agent then sends a ModifyConnection command to
the originating gateway:
MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
v=0
o=- 25678 753850 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 18:
The originating gateway changes to T.38 and sends back a success
response with updated SDP:
Andreasen Informational - Expires April 2004 22
MGCP Fax Package October 2003
200 1003 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 19:
The originating Call Agent sends a SIP 200 OK response with the
updated SDP to the terminating Call Agent, which in turn sends a SIP
ACK (not shown).
Step 20:
The terminating Call Agent sends a ModifyConnection with the updated
SDP to the terminating gateway:
MDCX 2003 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 21:
The terminating gateway sends back a success response:
200 2003 OK
Since the terminating gateway now has a RemoteConnectionDescriptor
with "image/t38" as valid media, it can start exchanging T.38 with
the originating gateway.
Step 22, 23:
When the fax ends, a "t38(stop)" event is generated, which is
notified to the Call Agent:
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: t38(stop)
Andreasen Informational - Expires April 2004 23
MGCP Fax Package October 2003
X: 3
Step 24:
The Call Agent acknowledges the Notify command:
200 2501 OK
The fax call is now over. The Call Agent may now decide to change
back to a voice codec, delete the connection, or something
different.
4. Security Considerations
The MGCP fax package itself is not known to introduce any new
security concerns. However, implementers should note, that T.38
media is currently transported over UDP or TCP in clear and without
any integrity protection. If for example security services are in
place to protect RTP media streams, these will thus not be in effect
for the T.38 media stream. If such lack of security is a concern,
the fax LocalConnectionOptions allowing T.38 in this package SHOULD
NOT be used, i.e. the "off" (or a new secure extension) fax
LocalConnectionOption should be used. @@
5. IANA Considerations
The IANA is hereby requested to register the following MGCP package:
Package Title Name Version
------------- ---- -------
Fax FXR 0
6. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3435] F. Andreasen, B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[T38] ITU-T Recommendation T.38, "Procedures for real-time
Group 3 facsimile communication over IP networks", 03/2002.
[RFC3407] F. Andreasen, "Session Description Protocol (SDP)
Simple Capability Declaration", RFC 3407, October 2002.
7. Informative References
Andreasen Informational - Expires April 2004 24
MGCP Fax Package October 2003
[T30] ITU-T Recommendation T.30, "Procedures for document
facsimile transmission in the general switched telephone network",
07/03.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[SIPfax] Mule, J., and J. Li, "SIP Support for Real-time Fax:
Call Flow Examples and Best Current Practices", work in progress.
8. Acknowledgements
Several people have contributed to the development of the MGCP fax
package. In particular, the author would like to thank Gary Kelly,
Rajesh Kumar, Dave Horwitz, Rob Thompson and the CableLabs
PacketCable NCS focus team for their contributions.
9. Author's Address
Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th Floor
Edison, NJ 08837
Email: fandreas@cisco.com
Andreasen Informational - Expires April 2004 25
MGCP Fax Package October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright(C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Andreasen Informational - Expires April 2004 26
MGCP Fax Package October 2003
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andreasen Informational - Expires April 2004 27
| PAFTECH AB 2003-2026 | 2026-04-24 01:43:55 |