[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 5347

Internet Engineering Task Force                            F. Andreasen
Internet Draft                                            Cisco Systems
Document: draft-andreasen-mgcp-fax-01.txt                 January, 2003
Category: Informational


                            MGCP 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 [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 defines an 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
   [2].











Andreasen         Informational - Expires July 2003                 1
                           MGCP Fax Package               January 2003

Table of Contents

1. Fax Package Definition.............................................3
 1.2 LocalConnectionOptions..........................................3
  1.2.1 T.38 Mode (Strict or Loose)..................................4
  1.2.2 Gateway Mode.................................................5
  1.2.3 Off Mode.....................................................5
  1.2.4 Mode Operation...............................................6
 1.3 Events and Signals..............................................7
 1.4 Connection Parameters...........................................9
 1.5 Additional Considerations......................................10
  1.5.1 Media IP Address and Port...................................10
2. Call Flow Examples................................................10
 2.1 Call Agent Controlled T.38 Strict..............................10
 2.2 Multiple and Different Options.................................16
3. Security Considerations...........................................23
4. References........................................................23
5. Acknowledgements..................................................23
6. Author's Address..................................................24

































Andreasen         Informational - Expires July 2003                 2
                           MGCP Fax Package               January 2003



1. 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

1.2 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, the gateway MUST be able to use at
   least one of the listed options for the command to succeed. The list
   may currently contain one or more of the following:

   * T.38 Strict        Use T.38 [3] for fax relay and have the Call
     Agent control it. Assuming the procedure can be used, a switch to
     T.38 procedures will be initiated upon fax detection and a
     "t38(start)" event will be generated (see Section 1.3). This mode
     requires an indication of T.38 support from the remote side in
     order to be used.

   * 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.

   * 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 1.3). The Call Agent SHOULD then refrain
     from issuing potentially conflicting commands to the gateway until
     the gateway ends it's special fax handling.

   A gateway that ends up not being able to invoke any special
   procedure for fax will generate a "nopfax(start)" event upon
   detection of fax.

   The set of possible values for the Fax LCO is extensible. The
   prefixes "x-", which indicates an optional extension, and "x+",
   which indicates a mandatory extension, are reserved for vendor
   specific use. In CreateConnection, the Fax LCO defaults to
   "gateway". In ModifyConnection, it defaults to its current value on

Andreasen         Informational - Expires July 2003                 3
                           MGCP Fax Package               January 2003

   the connection. If LocalConnectionOptions are either omitted or the
   fax parameter is not included, 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). If multiple fax parameter values are
   provided, the gateway MUST choose one of the values. Please refer to
   Section 1.2.5 for further details.

   The fax 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

   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.

1.2.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 [7] 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

   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).

Andreasen         Informational - Expires July 2003                 4
                           MGCP Fax Package               January 2003


   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 t38 would
   achieve the same). Per the normal codec negotiation procedures, 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 will 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.

1.2.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 is outside the scope of this document. However, in
   order to use special fax handling, support for it MUST be negotiated
   with the other side by passing and recognizing relevant parameters
   via the SDP. 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.

1.2.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.





Andreasen         Informational - Expires July 2003                 5
                           MGCP Fax Package               January 2003

1.2.4 Mode Operation

   For each of the above modes, the RemoteConnectionDescriptor provides
   information on what procedure 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
      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 [7])
        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, 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 1.2). 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.
      T.38), the most recently received RemoteConnectionDescriptor MUST
      include a corresponding media line.

   The following examples illustrate the use of the above rules.



Andreasen         Informational - Expires July 2003                 6
                           MGCP Fax Package               January 2003

   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 Fax handling 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 included either "t38-loose", "gw" or "off",
   the command would have succeeded and any of the procedures included
   could have been selected.

   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 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 CNG and the
   terminating fax detects V.21 fax preamble before the switch to T.38
   has been performed on the terminating side.

1.3 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.

Andreasen         Informational - Expires July 2003                 7
                           MGCP Fax Package               January 2003


     * 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 occurred.

     * 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 occurred.

     The "gwfax" event may be parameterized with additional parameters,
     however it is RECOMMENDED that one of the above parameters will be
     the first parameter supplied.

     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
       commands in order to ensure a successful fax call.

     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, 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

Andreasen         Informational - Expires July 2003                 8
                           MGCP Fax Package               January 2003

       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.

     * 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.

     The "t38" event may be parameterized with additional parameters,
     however it is RECOMMENDED that one of the above parameters will be
     the first parameter supplied.

     The following example illustrates the encoding of the "t38" event:

        O: fxr/t38(start)
        O: fxr/t38(foobar, stop)

1.4 Connection Parameters

   The connection parameters for the connection measuring packets and
   octets sent and received 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 July 2003                 9
                           MGCP Fax Package               January 2003

1.5 Additional Considerations

1.5.1 Media IP Address and Port

   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
   this will minimize Quality of Service interactions from the change.
   However, if an endpoint has a good reason, it MAY choose not to
   follow this recommendation.

2. 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.

2.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 SIP (see e.g. [6]):
































Andreasen         Informational - Expires July 2003                10
                           MGCP Fax Package               January 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 capability information:





Andreasen         Informational - Expires July 2003                11
                           MGCP Fax Package               January 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 honored. The terminating gateway sends back a
   success response with its SDP which also includes capability
   information:




Andreasen         Informational - Expires July 2003                12
                           MGCP Fax Package               January 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 gateway.

   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.



Andreasen         Informational - Expires July 2003                13
                           MGCP Fax Package               January 2003

   Step 9-11:

   First, the T.30 CED tone (aka. V.25 ANS) occurs 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 T.30 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 July 2003                14
                           MGCP Fax Package               January 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.

   Step 19:

   The terminating Call Agent sends a ModifyConnection with the updated
   SDP to the terminating gateway:

Andreasen         Informational - Expires July 2003                15
                           MGCP Fax Package               January 2003


        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.

2.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 July 2003                16
                           MGCP Fax Package               January 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 July 2003                17
                           MGCP Fax Package               January 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 July 2003                18
                           MGCP Fax Package               January 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 gateway.

   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 July 2003                19
                           MGCP Fax Package               January 2003

   Step 8:

   The gateway acknowledges the command. At this point, a call is
   established is using PCMU encoding.

   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, however 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 T.30 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 July 2003                20
                           MGCP Fax Package               January 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 July 2003                21
                           MGCP Fax Package               January 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.

   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)
        X: 3

Andreasen         Informational - Expires July 2003                22
                           MGCP Fax Package               January 2003


   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.

3. 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.

4. References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997

   [3]  ITU-T Recommendation T.38.

   [4]  ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment
        Procedures".

   [5]  ITU-T T.38, Amendment 1, 4/99.

   [6]  Mule, J., and J. Li, "SIP Support for Real-time Fax: Call Flow
        Examples and Best Current Practices", work in progress.

   [7]  F. Andreasen, "Session Description Protocol (SDP) Simple
        Capability Declaration", RFC 3407, October 2002.

5. 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 PacketCable NCS
   focus team for their contributions.







Andreasen         Informational - Expires July 2003                23
                           MGCP Fax Package               January 2003

6. Author's Address

   Flemming Andreasen
   Cisco Systems
   499 Thornall Street, 8th Floor
   Edison, NJ 08837

   Email: fandreas@cisco.com














































Andreasen         Informational - Expires July 2003                24
                           MGCP Fax Package               January 2003


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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.























Andreasen         Informational - Expires July 2003                25


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/