[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-03.txt                 July 18, 2004
Category: Informational


               Media Gateway Control Protocol Fax Package


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance
   with RFC 3668.

   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.

   This Internet-Draft will expire on January 18, 2005.

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 January 2005                1
                           MGCP Fax Package                  July 2004

Table of Contents

1. Introduction......................................................3
2. Fax Package Definition............................................3
 2.1 LocalConnectionOptions..........................................3
  2.1.1 T.38 Procedure (Strict or Loose)............................5
  2.1.2 Gateway Procedure...........................................6
  2.1.3 Off Procedure...............................................6
  2.1.4 Mode Operation..............................................7
 2.2 Events and Signals..............................................8
  2.2.1 Gateway Controlled Fax (gwfax)..............................9
  2.2.2 No Special Fax Handling (nopfax)............................9
  2.2.3 T.38 fax relay(t38):.......................................10
 2.3 Connection Parameters..........................................11
 2.4 Media IP Address and Port for T.38.............................12
3. Call Flow Examples...............................................12
 3.1 Call Agent Controlled T.38 Strict..............................12
 3.2 Multiple and Different Options.................................18
4. Security Considerations..........................................25
5. IANA Considerations..............................................25
6. Normative References.............................................25
7. Informative References...........................................25
8. Acknowledgements.................................................26
9. Author's Address.................................................26




























Andreasen        Informational - Expires January 2005                2
                           MGCP Fax Package                  July 2004



1.
  Introduction

   This document defines a Media Gateway Control Protocol (MGCP)
   [RFC3435] 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
   using either UDPTL or TCP (see [T38]) 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 procedure to the Media Gateway.  The fax LCO
   contains an ordered list of desired fax handling procedures.  When
   the parameter is explicitly included in a command, the gateway MUST
   be able to use at least one of the listed procedures for the command
   to succeed.  The list can currently contain one or more of the
   following values (see Section 2.1.1 to 2.1.4 for further details on
   these):

   * T.38 Strict        Use T.38 [T38] with either UDPTL or TCP 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.




Andreasen        Informational - Expires January 2005                3
                           MGCP Fax Package                  July 2004

   * Off                Do not invoke any special procedure for fax,
     except for echo cancellation adjustment and possibly switching to
     another codec.

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

   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 value defaults to
   "gateway".  In ModifyConnection commands, the fax LCO value defaults
   to its current value on the connection.  Thus, if
   LocalConnectionOptions are either omitted or the fax LCO is not
   included in a ModifyConnection command, the previous fax LCO value
   for the connection will be retained, but without affecting the
   outcome of the command; consequently, the gateway may now not apply
   any special procedure to fax.  If the Call Agent wants to ensure
   that a command succeeds only when a fax procedure is applied, the
   command needs to include the fax LCO explicitly.

        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 for
        T.38; in that case, the ModifyConnection will succeed, however
        T.38 procedures will no longer be invoked upon fax detection.
        Had the Call Agent instead included the fax LCO set to "T.38
        Strict", 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 per [RFC3435]), 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".



Andreasen        Informational - Expires January 2005                4
                           MGCP Fax Package                  July 2004

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

   In the following subsections we provide additional detail on the
   above defined fax procedures.

2.1.1  T.38 Procedure (Strict or Loose)

   When a gateway is instructed to use one of the T.38 procedures, also
   known as Call Agent controlled T.38 mode, the "m=" line in the SDP
   returned will not indicate use of UDPTL-based or TCP-based T.38
   (unless the gateway was also instructed to use "image/t38" for the
   media stream).  Any other entity seeing this SDP will not know
   whether T.38 is supported or not and hence whether it is safe to
   attempt a switch to T.38 upon fax detection.  To remedy this
   dilemma, 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].

   Upon fax detection, a gateway which has successfully been instructed
   to use one of the T.38 procedures 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

Andreasen        Informational - Expires January 2005                5
                           MGCP Fax Package                  July 2004

   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 needs to include
   an "m=" line with "image/t38" as an acceptable media format in order
   for the command to succeed.  The gateway may choose between the
   UDPTL and TCP transport protocols at its own discretion subject to
   the normal MGCP codec negotiation procedures (in practice, TCP-based
   implementations are currently rare).

   If a RemoteConnectionDescriptor was not included with the
   ModifyConnection command sent to a gateway that initiated the T.38
   procedure, it is possible (in fact likely), that the last received
   RemoteConnectionDescriptor did not include an "m=" line listing
   "image/t38" as an acceptable media format.  In that case, the
   endpoint cannot send T.38 media to the other side.  The endpoint
   MUST instead wait for an updated RemoteConnectionDescriptor with
   "image/t38" as an acceptable media format and a supported transport
   protocol (UDPTL or TCP).  The T.38 fax procedure continues when an
   acceptable RemoteConnectionDescriptor is received; an acceptable
   RemoteConnectionDescriptor contains an "m=" line with the
   "image/t38" MIME type (using the normal SDP syntax) and a supported
   transport protocol (UDPTL or TCP). If the fax call fails, e.g., due
   to a fax timeout, while waiting for an acceptable
   RemoteConnectionDescriptor, a "t38(stop)" or a "t38(failure)" event
   will be generated.  When the T.38 procedure ends, a "t38(stop)" or
   "t38(failure)" event will be generated.

2.1.2  Gateway Procedure

   A gateway using the gateway procedure, also known as 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 Procedure

   A gateway using the "off" procedure 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

Andreasen        Informational - Expires January 2005                6
                           MGCP Fax Package                  July 2004

   alternative codec as needed (in particular, this does not preclude
   the use of RTP-based T.38).  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
      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 MIME media type, e.g. "image/t38", is included in
        the "m=" line in the RemoteConnectionDescriptor, or

      * the relevant MIME media type 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 can always be supported by an implementation that
      supports this package.

   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.

Andreasen        Informational - Expires January 2005                7
                           MGCP Fax Package                  July 2004


   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/t38"), 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", i.e. use
   of T.38 in "strict" mode, 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.

   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 media stream with "image/t38", 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:






Andreasen        Informational - Expires January 2005                8
                           MGCP Fax Package                  July 2004

    ------------------------------------------------------------------
   | Symbol  |   Definition               |  R  |   S     Duration    |
   |---------|----------------------------|-----|---------------------|
   |  gwfax  | Gateway controlled fax     |  x  |                     |
   |  nopfax | No special fax handling    |  x  |                     |
   |  t38    | T.38 fax relay             |  x  |                     |
    ------------------------------------------------------------------

   The definitions of the individual events are provided in the
   following subsections.

2.2.1  Gateway Controlled Fax (gwfax)

   The "gateway controlled fax" event occurs when the gateway handled
   fax procedure either starts, stops or fails. The event is encoded as
   "gwfax" and the following event parameters, which apply to
   ObservedEvents only, are defined:

     * start           Gateway controlled fax procedure 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 procedure 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 procedure started.

     * failure         The gateway controlled fax 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 procedure
       started.

   One of the above parameters will be present when the event is
   reported.  The "gwfax" event MAY be parameterized with additional
   parameters in ObservedEvents, 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)

2.2.2  No Special Fax Handling (nopfax)



Andreasen        Informational - Expires January 2005                9
                           MGCP Fax Package                  July 2004

   The "no special fax handling" event occurs when there is no special
   fax handling procedure in place and a fax call is detected.  This
   can happen either due to no special fax handling procedure being
   requested (including "off"), or negotiation leading to no special
   fax handling procedure being possible.  The event is encoded as
   "nopfax" and the following event parameter, which applies to
   ObservedEvents only, is defined:

     * start           No special fax handling procedure 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 above parameter will be present when the event is reported.  The
   "nopfax" event MAY be parameterized with additional parameters on
   ObservedEvents, 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)

2.2.3  T.38 fax relay(t38):

   The "T.38 fax relay" event occurs when one of the T.38 fax relay
   procedures (strict or loose) either starts, stops or fails. The
   event is encoded as "t38" and the following event parameters, which
   apply to ObservedEvents only, are defined:

     * start           Call Agent controlled T.38 fax relay procedure
       was initiated.  The Call Agent SHOULD modify each side of the
       connection to start using the "image/t38" media format, unless
       they already do.

     * stop            Call Agent controlled T.38 fax relay procedure
       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 procedure case, media
       parameters such as codecs do not automatically revert to their
       values before the start of the fax call; echo cancellation and
       silence suppression however does per the procedures in [RFC3435]
       Section 2.3.5.

     * failure         Call Agent controlled T.38 fax relay procedure
       ended abnormally.  Some kind of problem in the Call Agent

Andreasen        Informational - Expires January 2005               10
                           MGCP Fax Package                  July 2004

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

   One of the above parameters will be present when the event is
   reported.  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-based 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 January 2005               11
                           MGCP Fax Package                  July 2004



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, Network Address Translator (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 January 2005               12
                           MGCP Fax Package                  July 2004

    ------------------------------------------------------------------
   | #|     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 procedure.  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 January 2005               13
                           MGCP Fax Package                  July 2004

        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 procedure.  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
   procedure requested can be used.  The terminating gateway sends back
   a success response with its SDP which also includes capability
   information:





Andreasen        Informational - Expires January 2005               14
                           MGCP Fax Package                  July 2004

        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 procedure, 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 the strict
   Call Agent controlled T.38 procedure.  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 procedure (since strict mode could not be
   supported).

   Step 8:




Andreasen        Informational - Expires January 2005               15
                           MGCP Fax Package                  July 2004

   The gateway acknowledges the command.  At this point, a call is
   established using PCMU encoding, and if a fax call is detected, the
   Call Agent controlled T.38 procedure will be initiated.

   Step 9-11:

   A fax call now occurs.  First, the T.30 CED tone (a.k.a. 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.

   The gateway was instructed to apply the Call Agent controlled T.38
   procedure for fax calls, so the "t38(start)" event occurs and 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 "image/t38" MIME type 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

Andreasen        Informational - Expires January 2005               16
                           MGCP Fax Package                  July 2004



   Note, that since the gatewayÆs current RemoteConnectionDescriptor
   (as opposed to the LocalConnectionDescriptor returned here) does 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 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).

Andreasen        Informational - Expires January 2005               17
                           MGCP Fax Package                  July 2004


   Step 19:

   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 procedure whereas the terminating gateway is given a choice

Andreasen        Informational - Expires January 2005               18
                           MGCP Fax Package                  July 2004

   between gateway procedure and strict t38 procedure. Furthermore, the
   originating fax machine is generating CNG tone.

    ------------------------------------------------------------------
   | #|     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
   procedure.  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 January 2005               19
                           MGCP Fax Package                  July 2004

        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 procedure or strict Call Agent controlled
   T.38 procedure.  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 January 2005               20
                           MGCP Fax Package                  July 2004

   supports T.38 as well, so the strict T.38 Call Agent controlled
   procedure 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 procedure.  The SDP
   information returned however does not indicate support for the
   "FaxScheme123", and hence the originating gateway will not invoke
   any special fax handling procedure for this call.





Andreasen        Informational - Expires January 2005               21
                           MGCP Fax Package                  July 2004

   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 procedure 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
   procedure 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 (a.k.a. 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.

   The terminating gateway is using the Call Agent controlled T.38
   procedure for fax calls, so the "t38(start)" event occurs and 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 "image/t38" MIME type 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 January 2005               22
                           MGCP Fax Package                  July 2004

   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 January 2005               23
                           MGCP Fax Package                  July 2004

        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 January 2005               24
                           MGCP Fax Package                  July 2004

        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 (UDPTL) 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

   [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

   [T30]        ITU-T Recommendation T.30, "Procedures for document
   facsimile transmission in the general switched telephone network",
   07/03.


Andreasen        Informational - Expires January 2005               25
                           MGCP Fax Package                  July 2004

   [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 January 2005               26
                           MGCP Fax Package                  July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the IETF's procedures with respect to rights in IETF
   Documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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










Andreasen        Informational - Expires January 2005               27


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