Skip to main content

Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package
draft-stone-mgcp-vbd-10

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6498.
Authors Joe Stone , Rajesh Kumar , Flemming Andreasen
Last updated 2015-10-14 (Latest revision 2011-12-05)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6498 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Gonzalo Camarillo
Send notices to s.sharma@cablelabs.com
draft-stone-mgcp-vbd-10
Network                                                         J. Stone
Internet-Draft                                                  R. Kumar
Intended status: Informational                              F. Andreasen
Expires: June 7, 2012                                      Cisco Systems
                                                        December 5, 2011

 Media Gateway Control Protocol (MGCP) Voiceband Data Package (VBD) and
           General Purpose Media Descriptor Parameter Package
                        draft-stone-mgcp-vbd-10

Abstract

   This document defines Media Gateway Control Protocol (MGCP) packages
   that enable a Call Agent to authorize and monitor the transition of a
   connection to and from voiceband data (VBD) with or without
   redundancy and FEC (forward error correction).  Although the focus is
   on VBD, the General-Purpose Media Descriptor Parameter package can be
   used to authorize other modes of operation, not relevant to VBD, for
   a particular codec.  In addition to the definition of these new
   packages, this document describes the use of the Media Format
   Parameter package and Fax package with VBD, redundancy and FEC.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on June 7, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Stone, et al.             Expires June 7, 2012                  [Page 1]
Internet-Draft              MGCP VBD package               December 2011

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Stone, et al.             Expires June 7, 2012                  [Page 2]
Internet-Draft              MGCP VBD package               December 2011

Table of Contents

   1.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Voiceband Data Package Definition  . . . . . . . . . . . . . .  8
     4.1.  Events and Signals . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Gateway Controlled Voiceband Data  . . . . . . . . . .  8
       4.1.2.  No Negotiated Procedure for Voiceband Data . . . . . . 16
   5.  General-Purpose Media Descriptor Parameter Package
       Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     5.1.  LocalConnectionOptions . . . . . . . . . . . . . . . . . . 20
       5.1.1.  General-Purpose Media Descriptor Parameter . . . . . . 20
   6.  Use of Media Format Parameter Package with VBD and
       Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   7.  Use of Media Format Parameter Package with VBD and FEC . . . . 28
   8.  Use of Fax Package with VBD  . . . . . . . . . . . . . . . . . 30
   9.  Call Flow Examples . . . . . . . . . . . . . . . . . . . . . . 35
     9.1.  Modem Call with Gateway Controlled VBD . . . . . . . . . . 35
     9.2.  Fax Call with Gateway Controlled VBD and Call Agent
           Controlled T.38  . . . . . . . . . . . . . . . . . . . . . 40
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 51
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 53
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
   13. Summary of Changes . . . . . . . . . . . . . . . . . . . . . . 55
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 57
     14.2. Informative References . . . . . . . . . . . . . . . . . . 58
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59

Stone, et al.             Expires June 7, 2012                  [Page 3]
Internet-Draft              MGCP VBD package               December 2011

1.  Applicability Statement

   This document defines a mechanism that requires media stream
   integrity protection.  The document specifies different alternatives
   for this but does not choose one of them as mandatory-to-implement.
   Consequently, the use of this specification is only suitable in
   environments that specify and use at least one of these alternative
   mechanisms.  Please see the Security Considerations section for
   further details.

Stone, et al.             Expires June 7, 2012                  [Page 4]
Internet-Draft              MGCP VBD package               December 2011

2.  Introduction

   The term voiceband data (or simply VBD) refers to the use of a
   suitable voiceband codec (commonly G.711u or G.711a) for the
   transport of data payloads using the RTP protocol defined in IETF RFC
   3550 [RFC3550].  This document defines Media Gateway Control Protocol
   (MGCP) [RFC3435] packages that enable a Call Agent to authorize and
   monitor the transition of a connection to and from VBD with or
   without redundancy [RFC2198] and FEC (forward error correction)
   [RFC5109].

   There are a number of different VBD procedures.  These procedures
   vary in terms of how the transition to and from VBD is coordinated
   end to end.  Some coordination techniques are mutually negotiated by
   the two Gateways using the SDP [RFC4566].  These coordination
   techniques include,

   ITU-T Recommendation V.150.1 State Signalling Event (SSE) [V1501]
   ITU-T Recommendation V.152 Payload Type Switching [V152]

   Other coordination techniques are not negotiated.  For example, the
   detection of fax, modem and text tones in the direction from the IP
   to the General Switched Telephone Network (GSTN) may result in a
   switch to VBD or a change (e.g., disable echo cancellation) to the
   Gateway controlled VBD procedure already in place.  The IP-side
   detected tone serves as both a VBD stimulus and a coordination
   technique.

   IETF RFC 4733 [RFC4733] and RFC 4734 [RFC4734] can be used to convey
   fax and modem events and tones.  As with IP-side tone detection, the
   telephone event may serve as both a VBD stimulus and a coordination
   technique.  Note that while the use of RFC 4733 and RFC 4734 to
   convey fax and modem events and tones is negotiated, the use of RFC
   4733 and RFC 4734 as a Gateway VBD coordination technique (at
   present) is not.

   The Voiceband Data (VBD) package is defined to support all VBD
   procedures.  This document does not address the relative merits of
   different procedures nor advocate one procedure over another.

   We will use the term VBD to refer to Voiceband Data in general.  In
   referring to VBD the package, we will use the term VBD package.  We
   use the term "audio" (with double quotes) to refer to the IANA media
   type.  We use the term audio (without double quotes) to refer to the
   use of the "audio" media type for (most commonly) voice.

   A package is defined for the General-Purpose Media Descriptor
   Parameter [V152].  In the context of VBD, the General-Purpose Media

Stone, et al.             Expires June 7, 2012                  [Page 5]
Internet-Draft              MGCP VBD package               December 2011

   Descriptor Parameter (GPMD) package is used to authorize the
   negotiation of a particular codec for use with VBD.  The General-
   Purpose Media Descriptor Parameter is "general" in nature and may be
   used in applications other than VBD.

   The Media Format Parameter (FM) package [RFC3660] describes the use
   of the standard audio MIME subtype "RED" in conjunction with the
   "fmtp" LocalConnectionOption in order to authorize the negotiation of
   redundancy [RFC2198], to identify the levels of redundancy and the
   media format associated with each redundancy level.  This document
   will further explore the use of the FM package with VBD and
   redundancy.

   The VBD package is intended to complement the MGCP Fax (FXR) package
   [RFC5347].  This document will explore the use of the FXR package
   with VBD.

   The VBD package definition is provided in section 3.  The GPMD
   package definition is provided in section 4.  In section 5, we
   discuss the use of the FM package with VBD and redundancy.  In
   section 6, we discuss the use of the FM package with VBD and FEC.  In
   section 7, we discuss the use of the FXR package with VBD.  In
   section 8, we provide two call flow examples showing how to use the
   VBD and GPMD packages.  Security considerations are found in section
   9, followed by the IANA considerations and references.

Stone, et al.             Expires June 7, 2012                  [Page 6]
Internet-Draft              MGCP VBD package               December 2011

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Stone, et al.             Expires June 7, 2012                  [Page 7]
Internet-Draft              MGCP VBD package               December 2011

4.  Voiceband Data Package Definition

   This package is defined for (Voiceband Data) VBD.  The package
   defines new events as detailed below.

   Package Name: VBD

   Package Version: 0

4.1.  Events and Signals

   The following events are defined in support of the above:

    -------------------------------------------------------------------
   | Symbol |   Definition                    |  R  |  S  |  Duration  |
   |--------|---------------------------------|-----|-----|------------|
   | gwvbd  | Gateway Controlled VBD          |  x  |     |            |
   | nopvbd | No Negotiated Procedure for VBD |  x  |     |            |
    -------------------------------------------------------------------

   This is standard MGCP package format as defined in RFC 3435 (Section
   6.6).  The definitions of the individual events are provided in the
   following subsections.

4.1.1.  Gateway Controlled Voiceband Data

   The "gwvbd" procedure can be used by the gateway to control and
   decide how to handle VBD calls without Call Agent involvement.  The
   "Gateway Controlled Voiceband Data" (or simply "gwvbd") event occurs
   when a gwvbd procedure has been negotiated and VBD stimulus is
   detected.  The "gwvbd" event may occur when the gwvbd procedure is
   updated (e.g., upon detecting new stimulus) and when the procedure
   fails.  The "gwvbd" event occurs when the gwvbd procedure ends.  The
   gwvbd procedure MUST be negotiated with the other side by passing and
   recognizing relevant parameters via the LocalConnectionDescriptor and
   RemoteConnectionDescriptor.

   The following recommendations from MGCP [RFC3435] apply.

Stone, et al.             Expires June 7, 2012                  [Page 8]
Internet-Draft              MGCP VBD package               December 2011

   In this section, we provide a formal description of the protocol
   syntax, following the "Augmented BNF for Syntax Specifications"
   defined in [RFC5234].  The syntax makes use of the core rules defined
   in [RFC5234], Section B.1 (Appendix B), which are not included here.
   Furthermore, the syntax follows the case-sensitivity rules of
   [RFC5234], i.e., MGCP is case-insensitive (but SDP is not). It should
   be noted, that ABNF does not provide for implicit specification of
   linear white space and MGCP messages MUST thus follow the explicit
   linear white space rules provided in the grammar below.  However, in
   line with general robustness principles, implementers are strongly
   encouraged to tolerate additional linear white space in messages
   received.

   The RequestedEvent is encoded as,

   GwVbdReqEvent = "gwvbd"

   The ObservedEvent is encoded as,

  GwVbdObsEvent = GwVbdObsEventStart / GwVbdObsEventUpdate /
                  GwVbdObsEventStop / GwVbdObsEventFailure

  GwVbdObsEventStart   = "gwvbd(start" Rc [Codec] [Coord] [Dir] ")"
  GwVbdObsEventUpdate  = "gwvbd(update" Rc [Codec] [Dir] ")"
  GwVbdObsEventStop    = "gwvbd(stop" [Rc] [Codec] ")"
  GwVbdObsEventFailure = "gwvbd(failure" [Rc] [Codec] ")"

  Codec = "," *WSP "codec=" CodecString
  CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / "." / "/")
  Coord = "," *WSP "coord=" CoordinationTechnique
  CoordinationTechnique = "v152ptsw" / "v150fw"
  Rc = "," *WSP "rc=" ReasonCode
  ReasonCode = 1*(ALPHA / DIGIT / "-" / "_" / "." / "/")
               ; Refer to the values listed in the tables below.
  Dir = "," *WSP "dir=" Direction
  Direction = "GstnToIp" / "IpToGstn"

   ABNF does not provide for position independent parameters.  The "rc",
   "codec", "coord", and "dir" parameters, if present, MUST appear in
   the relative order shown.

   The "start", "update", "stop" and "failure" ObservedEvent parameters
   are defined:

   1) VBD Start (start)

Stone, et al.             Expires June 7, 2012                  [Page 9]
Internet-Draft              MGCP VBD package               December 2011

   The gwvbd procedure was initiated.  The Call Agent SHOULD refrain
   from issuing media handling instructions to the Gateway until either
   a "gwvbd(stop)" or "gwvbd(failure)" event is generated.  One and only
   one "gwvbd(stop)" or "gwvbd(failure)" event is generated
   corresponding to each "gwvbd(start)" event.

   2) VBD Update (update)

   The gwvbd procedure was updated.  The "gwvbd(update)" event MUST only
   be generated after a "gwvbd(start)" event and before a "gwvbd(stop)"
   or "gwvbd(failure)" event.

   3) VBD Stop (stop)

   The gwvbd procedure ended and the Gateway did not detect any errors.
   Note that this does not necessarily imply a successful fax, modem, or
   text transmission.  It merely indicates that the gwvbd procedure has
   ended and the procedure itself did not encounter any errors.  The
   "stop" parameter may correspond to a change from VBD to a non-VBD
   "audio" codec or from VBD to another media type such as "image" or
   "text".  This change may be under Call Agent or Gateway control.  For
   example, the Gateway may coordinate the switch from VBD to "image/
   t38" through the exchange of SSEs [T38] and [V152].  For an example
   involving Call Agent control, refer to the "MC" Reason Code.  In both
   examples, the gwvbd procedure ends with the media change.

   4) VBD Failure (failure)

   The gwvbd procedure ended abnormally.  Some kind of problem was
   encountered in the gwvbd procedure and the procedure ended.

   When the "gwvbd" event is reported, exactly one of the "start",
   "update", "stop", or "failure" parameters MUST be present and MUST be
   the first parameter supplied.

   The "rc", "codec", "coord" and "dir" ObservedEvent parameters are
   defined:

   1) Coordination Technique (coord=<CoordinationTechnique>)

   The technique used to coordinate the transition to and from VBD with
   the remote endpoint.  The Coordination Techniques are summarized in
   the following table:

Stone, et al.             Expires June 7, 2012                 [Page 10]
Internet-Draft              MGCP VBD package               December 2011

             ------------------------------------------------------
            | CoordinationTechnique | Description                  |
            |-----------------------|------------------------------|
            | v152ptsw              | V.152 Payload Type Switching |
            | v150fw                | V.150.1 SSE                  |
             ------------------------------------------------------

   With the "v152ptsw" Coordination Technique, payload type switching
   [V152] is used to coordinate the transition to and from VBD.

   With the "v150fw" Coordination Technique, state signalling events
   [V1501] are used to coordinate the transition to and from VBD.

   The list of Coordination Techniques may be extended to include values
   with meaning mutually understood between the Gateway and the Call
   Agent.  Obviously, the use of extended values MUST be a provisionable
   option on the Gateway in order to ensure interoperability with the
   Call Agent.

   2) Reason Code (rc=<ReasonCode>)

   With the "start" and "update" parameter, the reason for triggering
   the switch/change to VBD.  With the "stop" and "failure" parameter,
   the reason for triggering the switch from VBD.  The Reason Codes in
   the following table, which are based on the ITU-T FAX/Textphone/Modem
   Tones Detection package [H2482], ITU-T V.150.1 Amendment 1 [V1501A1]
   and ITU-T V.152 [V152], may be used with the "start" and "update"
   parameter:

Stone, et al.             Expires June 7, 2012                 [Page 11]
Internet-Draft              MGCP VBD package               December 2011

    -------------------------------------------------------------------
   | ReasonCode | Description                                          |
   |------------|------------------------------------------------------|
   | CNG        | T.30 fax calling                                     |
   | V21flag    | V.21 tone and flags for fax answering                |
   | CIV18      | V.8 CI with V.18 call function                       |
   | XCI        | V.18 XCI                                             |
   | V18txp     | V.18 txp                                             |
   | Belltone   | Bell 103 carrier, high or low frequency channel      |
   |            | (ITU-T Recommendation V.18)                          |
   | Baudot     | Baudot initial tone and character (ITU-T             |
   |            | Recommendation V.18)                                 |
   | Edt        | EDT initial tone and character (ITU-T Recommendation |
   |            | V.18)                                                |
   | CIdata     | V.8 CI with any data call function                   |
   | CT         | V.25 calling tone                                    |
   | CIfax      | V.8 CI with facsimile call function                  |
   | V21tone    | V.21 carrier, high or low frequency channel          |
   | V23tone    | V.23 carrier, high or low frequency channel          |
   | V8bis      | V.8 bis modem handshaking signal                     |
   | ANS        | V.25 ANS, equivalent to T.30 CED from answering      |
   |            | terminal                                             |
   | /ANS       | V.25 ANS with periodic phase reversals               |
   | ANSam      | V.8 ANSam                                            |
   | /ANSam     | V.8 ANSam with periodic phase reversals              |
   | CMFax      | V.8 CM sequence indicating fax call function         |
   | JMFax      | V.8 JM sequence indicating fax call function         |
   | CMData     | V.8 CM sequence indicating unspecified data call     |
   |            | function                                             |
   | JMData     | V.8 JM sequence indicating unspecified data call     |
   |            | function                                             |
   | CMText     | V.8 CM sequence indicating text call function        |
   | JMText     | V.8 JM sequence indicating text call function        |
   | PTSW       | Payload type switch as defined in V.152              |
    -------------------------------------------------------------------

   For solutions involving textphones using a modulation with
   interspersed text and speech on the same "channel" such as Baudot and
   EDT, the Call Agent SHOULD interpret the ReasonCode parameter as part
   of the "vbd/gwvbd(start)" event in order to differentiate between
   fax, modem and text.  In the case of interspersed text and speech the
   Call Agent SHOULD remove the notification request for "vbd/gwvbd"
   upon receiving the "vbd/gwvbd(start)" event in order to avoid large
   numbers of notifications.  For example,

   vbd/gwvbd(start, rc=Baudot)

Stone, et al.             Expires June 7, 2012                 [Page 12]
Internet-Draft              MGCP VBD package               December 2011

   With a ReasonCode of "PTSW", the Call Agent cannot differentiate text
   from fax/modem.  In this case, the Call Agent SHOULD adopt a policy
   which guards against large numbers of notifications.  We consider
   several such policies.

   The Call Agent MAY remove the notification request for "vbd/gwvbd"
   upon receiving the "vbd/gwvbd(start, rc=PTSW)" event.  With this
   policy, "update", "stop" and "failure" notifications will not be
   generated with text AND fax/modem.

   The Call Agent MAY wait for a subsequent "vbd/gwvbd(update)" event
   which differentiates text from fax/modem.  If the ReasonCode
   indicates interspersed text and speech, the Call Agent SHOULD remove
   the notification request for "vbd/gwvbd".  For example,

   vbd/gwvbd(update, rc=Edt)

   The Call Agent MAY remove the notification request for "vbd/gwvbd"
   upon receiving a "vbd/gwvbd(stop)" event without having
   differentiated between text and fax/modem.

   The Call Agent MAY remove the notification request for "vbd/gwvbd"
   after having received a number of "vbd/gwvbd(start)" events without
   having differentiated between text and fax/modem.  The specific
   number of events after which the notification request is removed is
   considered an implementation detail outside the scope of this
   specification.

   Reason Codes applicable with the "stop" parameter:

                ------------------------------------------------------
               | ReasonCode | Description                             |
               |------------|-----------------------------------------|
               | SIL        | Bidirectional silence                   |
               | Voice      | Voice signals                           |
               | PTSW       | Payload type switch as defined in V.152 |
               | MC         | Media change                            |
                ------------------------------------------------------

   The "MC" Reason Code indicates that the media type has changed from
   "audio" (to "image", "text", ...) or the "audio" media format has
   changed from a VBD codec (for a reason other than "PTSW").  For
   example, the gwvbd procedure may be initiated upon detecting CED.
   Subsequently, the Call Agent controlled T.38 procedure of the MGCP
   Fax (FXR) package [RFC5347] may be initiated upon detecting V.21

Stone, et al.             Expires June 7, 2012                 [Page 13]
Internet-Draft              MGCP VBD package               December 2011

   flags.  Upon receipt of a "t38(start)" event, the Call Agent will
   instruct the Gateway to switch from VBD to T.38 through the use of a
   ModifyConnection command involving a LocalConnectionOption encoding
   method of "L:a:image/t38" and/or a RemoteConnectionDescriptor with an
   "image/t38" media description.  This stops the gwvbd procedure.
   There is no specific interdependency between the VBD package and the
   FXR package (or any other package).  The gwvbd procedure is stopped
   as a consequence of the media change, not as a direct consequence of
   the T.38 procedure being initiated.  Note that in this situation the
   "t38(start)" event will be sent before the "gwvbd(stop)" event.  The
   Call Agent MAY choose to infer that the gwvbd procedure has ended
   upon receiving the "t38(start)" event and disable the notification of
   the "gwvbd" event.  Refer to the example call flow in section 8.2.

   Reason Codes applicable with the "failure" parameter:

                 ----------------------------------------------------
                | ReasonCode | Description                           |
                |------------|---------------------------------------|
                | TO         | Indicates that a timeout has occurred |
                 ----------------------------------------------------

   The list of Reason Codes may be extended to include values with
   meaning mutually understood between the Gateway and the Call Agent.
   Obviously, the use of extended values MUST be a provisionable option
   on the Gateway in order to ensure interoperability with the Call
   Agent.

   3) Codec String (codec=<CodecString>)

   With the "start" and "update" parameter, the codec parameter
   describes the MIME type associated with the switch/change to VBD
   (e.g., "audio/RED", "audio/PCMU", "audio/PCMA", "audio/G726-32",
   "audio/clearmode", ...).  With the "stop" and "failure" parameter,
   the codec parameter describes the MIME type associated with the
   switch from VBD (e.g., "audio/G729", "image/t38", "text/t140",
   "audio/v150mr", ...).  These strings should be full MIME types as
   listed in http://www.iana.org/assignments/media-types.

   4) Direction of Stimulus (dir=<Direction>)

   With the "start" and "update" parameter, the "dir" parameter
   describes the direction of the stimulus which resulted in the switch/
   change to VBD.

Stone, et al.             Expires June 7, 2012                 [Page 14]
Internet-Draft              MGCP VBD package               December 2011

                    -----------------------------------------------
                   | Direction | Description                       |
                   |-----------|-----------------------------------|
                   | GstnToIp  | Stimulus detected in the direction|
                   |           | from the GSTN to IP network,      |
                   |           | including: fax, modem and text    |
                   |           | tones.                            |
                   | IpToGstn  | Stimulus detected in the direction|
                   |           | from the IP to GSTN network,      |
                   |           | including: fax, modem, text tones |
                   |           | (e.g., IP-side tone detection);   |
                   |           | RTP packet with VBD payload type  |
                   |           | (e.g.,V.152 or V.150.1).          |
                    -----------------------------------------------

   Call Agents and Gateways MUST implement the "start" and "stop"
   parameters and MAY implement the "update" and "failure" parameters.
   Call Agents and Gateways MAY implement the "coord", "codec", and
   "dir" parameters.  Call Agents MAY and Gateways MUST implement the
   "rc" parameter in conjunction with the "start" and "update"
   parameters.  Call Agents and Gateways MAY implement the "rc"
   parameter in conjunction with the "stop" and "failure" parameters.  A
   Call Agent MUST ignore all unknown ObservedEvent parameters including
   parameters which are defined as part of this specification and not
   implemented.

4.1.1.1.  Gateway Controlled Voiceband Data Examples

   The following examples illustrate the encoding of the "gwvbd(start)"
   event,

           O: vbd/gwvbd(start, rc=ANS)
           O: vbd/gwvbd(start, rc=ANS, codec=audio/PCMU, coord=v152ptsw)
           O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)

   The following example illustrates the encoding of the "gwvbd(update)"
   event,

           O: vbd/gwvbd(update, rc=/ANSam, dir=IpToGstn)

Stone, et al.             Expires June 7, 2012                 [Page 15]
Internet-Draft              MGCP VBD package               December 2011

   The following examples illustrate the encoding of the "gwvbd(stop)"
   event,

           O: vbd/gwvbd(stop)
           O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
           O: vbd/gwvbd(stop, rc=MC, codec=image/t38)

   The following examples illustrate the encoding of the
   "gwvbd(failure)" event,

           O: vbd/gwvbd(failure, codec=audio/G729)
           O: vbd/gwvbd(failure, rc=TO, codec=audio/G729)

4.1.2.  No Negotiated Procedure for Voiceband Data

   The "No Negotiated Procedure for Voiceband Data" (or simply "nopvbd")
   event occurs when a VBD procedure has not been negotiated and VBD
   stimulus is detected.  The "nopvbd" event may occur when the
   procedure is updated (e.g., upon detecting new stimulus), when the
   procedure ends and when the procedure fails.  Even though a procedure
   was not negotiated, a VBD handling procedure MAY still be in place
   locally on the endpoint, as described further below.

   The nopvbd procedure MAY involve VBD handling including but not
   limited to adjusting gain and jitter, disabling voice activity
   detection and DC offset filters.  The nopvbd procedure MAY involve
   switching to another codec.  The Call Agent MAY have to issue further
   commands in response to the "nopvbd" event in order to ensure a
   successful VBD call.

   As with the "gwvbd" event, the same recommendations from MGCP
   [RFC3435] regarding ABNF, general robustness principles and white
   space apply.

Stone, et al.             Expires June 7, 2012                 [Page 16]
Internet-Draft              MGCP VBD package               December 2011

      The RequestedEvent is encoded as,

        NopVbdReqEvent = "nopvbd"

      The ObservedEvent is encoded as,

        NopVbdObsEvent = NopVbdObsEventStart / NopVbdObsEventUpdate /
                         NopVbdObsEventStop / NopVbdObsEventFailure

        NopVbdObsEventStart   = "nopvbd(start" Rc [Codec] [Dir] ")"
        NopVbdObsEventUpdate  = "nopvbd(update" Rc [Codec] [Dir] ")"
        NopVbdObsEventStop    = "nopvbd(stop" [Rc] [Codec] ")"
        NopVbdObsEventFailure = "nopvbd(failure" [Rc] [Codec] ")"

   The following ABNF notation is common with the "gwvbd" ObservedEvent.

  Codec = "," *WSP "codec=" CodecString
  CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" / "." / "/")
  Rc = "," *WSP "rc=" ReasonCode
  ReasonCode = 1*(ALPHA / DIGIT / "-" / "_" / "." / "/")
               ; Refer to the values listed in the tables above.
  Dir = "," *WSP "dir=" Direction
  Direction = "GstnToIp" / "IpToGstn"

   ABNF does not provide for position independent parameters.  The "rc",
   "codec", and "dir" parameters, if present, MUST appear in the
   relative order shown.

   The "start", "update", "stop" and "failure" ObservedEvent parameters
   are defined:

   1) VBD Start(start)

   The nopvbd procedure was initiated.  The Call Agent may have to issue
   further commands in order to ensure a successful VBD call (e.g.,
   switch to another codec).  At most one "nopvbd(stop)" or
   "nopvbd(failure)" event MAY be generated corresponding to each
   "nopvbd(start)" event.  The Call Agent MAY need to infer that the
   nopvbd procedure has ended.

   2) VBD Update (update)

   The nopvbd procedure was updated.  The "nopvbd(update)" event MUST
   only be generated after a "nopvbd(start)" event and before a

Stone, et al.             Expires June 7, 2012                 [Page 17]
Internet-Draft              MGCP VBD package               December 2011

   "nopvbd(stop)" or "nopvbd(failure)" event.

   3) VBD Stop (stop)

   The nopvbd procedure ended and the Gateway did not detect any errors.
   Note that this does not necessarily imply a successful fax, modem, or
   text transmission.  It merely indicates that the nopvbd procedure has
   ended and the procedure itself did not encounter any errors.  Refer
   to the definition of the "stop" parameter from the "gwvbd" event in
   section 3.1.1 for additional information.

   4) VBD Failure (failure)

   The nopvbd procedure ended abnormally.  Some kind of problem was
   encountered in the nopvbd procedure and the procedure ended.

   Call Agents and Gateways MUST implement the "start" parameter and MAY
   implement the "update", "stop" and "failure" parameters.  Call Agents
   MAY and Gateways MUST implement the "rc" parameter in conjunction
   with the "start" and "update" parameters.  Call Agents and Gateways
   MAY implement the "rc" parameter in conjunction with the "stop" and
   "failure" parameters.  A Call Agent MUST ignore all unknown
   ObservedEvent parameters including parameters which are defined as
   part of this specification and not implemented.

   The definitions of the "rc", "codec" and "dir" ObservedEvent
   parameters are taken from the "gwvbd" event.

   As with the "gwvbd" event, the same recommendations regarding
   interspersed text and speech apply.

4.1.2.1.  No Negotiated Procedure for Voiceband Data Examples

   The following examples illustrate the encoding of the "nopvbd(start)"
   event,

           O: vbd/nopvbd(start, rc=ANS)
           O: vbd/nopvbd(start, rc=ANS, codec=audio/PCMU)

   The following example illustrates the encoding of the
   "nopvbd(update)" event,

           O: vbd/nopvbd(update, rc=/ANSam, dir=IpToGstn)

Stone, et al.             Expires June 7, 2012                 [Page 18]
Internet-Draft              MGCP VBD package               December 2011

   The following examples illustrate the encoding of the "nopvbd(stop)"
   event,

           O: vbd/nopvbd(stop)
           O: vbd/nopvbd(stop, rc=SIL, codec=audio/G729)
           O: vbd/nopvbd(stop, rc=MC, codec=image/t38)

   The following examples illustrate the encoding of the
   "nopvbd(failure)" event,

           O: vbd/nopvbd(failure, codec=audio/G729)
           O: vbd/nopvbd(failure, rc=TO, codec=audio/G729)

Stone, et al.             Expires June 7, 2012                 [Page 19]
Internet-Draft              MGCP VBD package               December 2011

5.  General-Purpose Media Descriptor Parameter Package Definition

   This package is defined for the General-Purpose Media Descriptor
   Parameter [V152].  The package defines a new LocalConnectionOption as
   detailed below.

      Package Name:        GPMD
      Package Version:     0

5.1.  LocalConnectionOptions

   The following LocalConnectionOption is defined in support of the
   above:

       ------------------------------------------------------
      | Symbol |   Definition                                |
      |--------|---------------------------------------------|
      | gpmd   | General-Purpose Media Descriptor Parameter  |
       ------------------------------------------------------

   The definition of the LocalConnectionOption is provided in the
   following subsection.

5.1.1.  General-Purpose Media Descriptor Parameter

   The General-Purpose Media Descriptor Parameter LocalConnectionOption
   is similar to the "gpmd" SDP [RFC4566] attribute defined in ITU-T
   Recommendation V.152 [V152] and is applicable to all of the same
   media formats that the corresponding SDP "gpmd" attribute could be
   used with.

   The General-Purpose Media Descriptor Parameter is encoded as the
   keyword "gpmd" or "o-gpmd", followed by a colon and a quoted string
   beginning with the media format name (MIME subtype only) followed by
   a space, followed by the media format parameters associated with that
   media format,

         gpmd/gpmd:"<format> <parameter list>"

Stone, et al.             Expires June 7, 2012                 [Page 20]
Internet-Draft              MGCP VBD package               December 2011

   For simplicity, we will use the terms "codec" and "media format"
   interchangeably in the following.  Multiple media formats may be
   indicated by either repeating the "gpmd" LocalConnectionOption
   multiple times, such as:

         L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX",
                             gpmd/gpmd:"codec2 parameterY"

   or alternatively by having a single "gpmd" keyword followed by a
   colon, and a semi-colon separated list of quoted strings for each
   General-Purpose Media Descriptor Parameter, as in:

         L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
                                       "codec2 parameterY"

   The two formats may be mixed,

         L: a:codec1;codec2;codec3, gpmd/gpmd:"codec1 parameterX",
                                    gpmd/gpmd:"codec2 parameterY";
                                              "codec3 parameterZ"

   The carriage returns above are included for formatting reasons only
   and are not permissible in a real implementation.  This holds true
   for all of the examples in this document.

   If it is possible for the same codec to be requested with and without
   the "gpmd" parameter, the following could result:

         L: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"

   However, it would not be clear if the "gpmd" parameter was to be
   applied to the first or the second occurrence of the codec.  The
   problem is that codec ordering is important (i.e., codecs are listed
   in preferred order), and the above syntax does not provide a way to
   indicate if "parameterX" is preferred (i.e., associated with the
   first "codec1") or not (i.e., associated with the second "codec1").

Stone, et al.             Expires June 7, 2012                 [Page 21]
Internet-Draft              MGCP VBD package               December 2011

   In order to resolve this dilemma, the codec in the "gpmd" media
   format is followed by a colon and an <order>, where <order> is a
   number from one to N for occurrences of the same codec in the codec
   list i.e.:

         L:a:codec1;codec1, gpmd/gpmd:"codec1:2 parameterX"

   indicates that "parameterX" is associated with the second instance of
   "codec1" in the "a:codec1;codec1" list.  If an invalid instance
   number is supplied (e.g., instance 3 where there are only two
   instances), then error code 524 - inconsistency in local connection
   options will be returned.  In the absence of an <order>, the first
   instance is assumed.

   Pre-pending "gpmd" with the string "o-" (i.e., "o-gpmd") indicates
   that the parameter is optional.  In that case, the Gateway may decide
   not to use the "gpmd" parameter specified, or only use it in part.

   If the "gpmd" LocalConnectionOption parameter is not optional (i.e.,
   does not have "o-" in front of it), and the LocalConnectionOption
   parameter value is either not recognized or not supported, then the
   associated codec is considered "not supported".

   When auditing capabilities, the "gpmd" LocalConnectionOption
   parameter MUST be returned with a semi-colon separated list of
   supported formats and/or multiple independent "gpmd" parameters as
   in:

         A: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
                                       "codec2 parameterY"

       or,

         A: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"

   One example uses the General-Purpose Media Descriptor Parameter
   LocalConnectionOption in conjunction with Gateway controlled
   Voiceband Data (or simply VBD) using payload type switching [V152].
   In the context of VBD, the <format> must be an RTP/AVP payload type.
   The <parameter list> is a semicolon-separated list of
   "parameter=value" pairs,

Stone, et al.             Expires June 7, 2012                 [Page 22]
Internet-Draft              MGCP VBD package               December 2011

     L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"

   In the example below, G.729 is an audio codec and G.711u is a VBD
   codec,

         L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes"

   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

         m=audio 12345 RTP/AVP 18 96
         a=rtpmap:96 PCMU/8000
         a=gpmd:96 vbd=yes

   If a request is made to audit the capabilities of an endpoint, and
   the endpoint supports G.711u as both an audio and VBD codec, then the
   "gpmd" LocalConnectionOption parameter might look like:

         A: a:PCMU, p:10-40, e:on, s:on,
            m:sendonly;recvonly;sendrecv;inactive
         A: a:PCMU, p:10-40, e:on, s:off,
            m:sendonly;recvonly;sendrecv;inactive,
            gpmd/gpmd:"PCMU vbd=yes"

   Given that some parameters, such as e.g., silence suppression, are
   only compatible with G.711u as an audio codec, then the Gateway MUST
   return different capability sets corresponding to audio and VBD.

   If we combine V.152 and redundancy [RFC2198], an example
   LocalConnectionOption might look as follows.  In the example below,
   G.729 is an audio codec and G.711u is a VBD codec with a redundancy
   level of one:

     L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"

Stone, et al.             Expires June 7, 2012                 [Page 23]
Internet-Draft              MGCP VBD package               December 2011

   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

         m=audio 12345 RTP/AVP 18 96 97
         a=rtpmap:96 RED/8000
         a=fmtp:96 97/97
         a=rtpmap:97 PCMU/8000
         a=gpmd:97 vbd=yes

   Refer to section 5 for more examples involving V.152 and redundancy.

Stone, et al.             Expires June 7, 2012                 [Page 24]
Internet-Draft              MGCP VBD package               December 2011

6.  Use of Media Format Parameter Package with VBD and Redundancy

   The MGCP Media Format Parameter (FM) package [RFC3660] in conjunction
   with the standard audio MIME subtype "RED" may be used by the Call
   Agent to authorize the negotiation of redundancy [RFC2198], to
   identify the levels of redundancy and the media format associated
   with each redundancy level.  An example of this was demonstrated in
   section 4.

   The FM package states that the "fmtp" LocalConnectionOption MUST be
   returned when auditing capabilities.  Applying this to VBD and
   redundancy might result in:

         A: a:PCMU, p:10-40, e:on, s:on,
            m:sendonly;recvonly;sendrecv;inactive
         A: a:RED;PCMU, p:10-40, e:on, s:off,
            m:sendonly;recvonly;sendrecv;inactive,
            gpmd/gpmd:"PCMU vbd=yes",
            fmtp:"RED PCMU/PCMU"

      The FM package defines "instance syntax" in which,

        L:a:codec1;codec1, fmtp:"codec1:2 formatX"

   indicates that "formatX" is associated with the second instance of
   "codec1" in the "a:codec1;codec1" list.  The examples in the FM
   package are limited to the use of the instance syntax in conjunction
   with the media format.  We propose the use of the instance syntax in
   conjunction with the media format parameters,

        L:a:codec1;codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2"

   Let's build on the example of section 4.  In the example below, G.729
   is an audio codec, G.711u is both an audio codec and a VBD codec with
   a redundancy level of one:

        L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes",
                                 fmtp:"RED PCMU:2/PCMU:2"

Stone, et al.             Expires June 7, 2012                 [Page 25]
Internet-Draft              MGCP VBD package               December 2011

   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

        m=audio 12345 RTP/AVP 18 0 96 97
        a=rtpmap:96 RED/8000
        a=fmtp:96 97/97
        a=rtpmap:97 PCMU/8000
        a=gpmd:97 vbd=yes

   Note that the relative preference of the LocalConnectionOption
   encoding methods is preserved in the "audio" media formats (i.e.,
   payload types) as part of the media description.  In this example,
   this reflects a preference for V.152 with redundancy versus without.
   No preference is inferred from the relative order of the different
   LocalConnectionOptions, namely "a", "gpmd/gpmd" and "fmtp".

   A Call Agent can authorize the negotiation of audio codecs and VBD
   codecs involving different levels of redundancy.  In the example
   below, G.711u is a VBD codec with a redundancy level of two
   (preferred) or one:

          L: a:G729;RED;RED;PCMU, fmtp:"RED PCMU/PCMU/PCMU",
                                    fmtp:"RED:2 PCMU/PCMU",
                                    gpmd/gpmd:"PCMU vbd=yes"

   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

        m=audio 12345 RTP/AVP 18 96 97 98
        a=rtpmap:96 RED/8000
        a=fmtp:96 98/98/98
        a=rtpmap:97 RED/8000
        a=fmtp:97 98/98
        a=rtpmap:98 PCMU/8000
        a=gpmd:98 vbd=yes

   Redundancy can be applied to both audio codecs and VBD codecs.  In
   the example below, G.729 is an audio codec with a redundancy level of
   two and G.711u is a VBD codec with a redundancy level of one:

Stone, et al.             Expires June 7, 2012                 [Page 26]
Internet-Draft              MGCP VBD package               December 2011

        L: a:RED;G729;RED;PCMU, fmtp:"RED G729/G729/G729",
                                fmtp:"RED:2 PCMU/PCMU",
                                gpmd/gpmd:"PCMU vbd=yes"

   The corresponding media description in the SDP as part of the
   connection request acknowledgment might look like:

        m=audio 12345 RTP/AVP 96 18 97 98
        a=rtpmap:96 RED/8000
        a=fmtp:96 18/18/18
        a=rtpmap:97 RED/8000
        a=fmtp:97 98/98
        a=rtpmap:98 PCMU/8000
        a=gpmd:98 vbd=yes

Stone, et al.             Expires June 7, 2012                 [Page 27]
Internet-Draft              MGCP VBD package               December 2011

7.  Use of Media Format Parameter Package with VBD and FEC

   A Call Agent may authorize the negotiation of forward error
   correction (FEC) [RFC5109] with the standard audio MIME subtype
   "parityfec",

          L: a:PCMU;parityfec

   By default, we assume that FEC packets are to be sent as a separate
   stream.  The corresponding media description in the SDP as part of
   the connection request acknowledgment might look like:

         v=0
         c=IN IP4 192.0.2.0
         m=audio 49170 RTP/AVP 0 96
         a=rtpmap:96 parityfec/8000
         a=fmtp:96 49172 IN IP4 192.0.2.0

   If FEC is to be sent as a secondary codec in the redundant codec
   payload format [RFC2198], we again leverage the MGCP Media Format
   Parameter (FM) package [RFC3660] in conjunction with the standard
   audio MIME subtype "RED",

         L: a:G729;RED;PCMU;parityfec, gpmd/gpmd:"PCMU vbd=yes",
                                       fmtp:"RED PCMU/parityfec"

      The corresponding media description might look like:

         v=0
         c=IN IP4 192.0.2.0
         m=audio 49170 RTP/AVP 18 96 97 98
         a=rtpmap:96 RED/8000
         a=fmtp:96 97/98
         a=rtpmap:97 PCMU/8000
         a=gpmd:97 vbd=yes
         a=rtpmap:98 parityfec/8000

   The FM package states that the "fmtp" LocalConnectionOption MUST be
   returned when auditing capabilities.  Applying this to VBD,

Stone, et al.             Expires June 7, 2012                 [Page 28]
Internet-Draft              MGCP VBD package               December 2011

   redundancy and FEC might result in:

         A: a:PCMU, p:10-40, e:on, s:on,
            m:sendonly;recvonly;sendrecv;inactive
         A: a:RED;PCMU;parityfec, p:10-40, e:on, s:off,
            m:sendonly;recvonly;sendrecv;inactive,
            gpmd/gpmd:"PCMU vbd=yes",
            fmtp:"RED PCMU/parityfec"

Stone, et al.             Expires June 7, 2012                 [Page 29]
Internet-Draft              MGCP VBD package               December 2011

8.  Use of Fax Package with VBD

   The MGCP Fax (FXR) package [RFC5347] is used by a Call Agent to
   authorize fax handling including Call Agent controlled T.38 and
   Gateway procedures such as V.152.  With the FXR package, VBD falls
   into one of two categories: "special fax handling" as part of the
   Gateway procedure (resulting in the "gwfax" event); or "no special
   fax handling" as part of the Gateway and Off procedures (resulting in
   the "nopfax" event).  In order for a VBD procedure to fall into the
   "special fax handling" category, support for it MUST be negotiated
   with the other side by passing and recognizing relevant parameters
   via the LocalConnectionDescriptor and RemoteConnectionDescriptor.

   A Gateway controlled VBD procedure such as V.152 MUST fall into the
   category of Gateway controlled mode involving "special fax handling".
   The resulting "gwfax" event is what informs the Call Agent to refrain
   from issuing media handling instructions which could otherwise have a
   negative impact on the Gateway procedure.

   Consider the following example (with shorthand SDP notation):

           CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           C: 1
           M: sendrecv
           L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:t38;gw
           X: 1
           R: fxr/t38, fxr/gwfax, fxr/nopfax

           v=0
           c=IN IP4 192.0.2.1
           m=audio 3456 RTP/AVP 18 96
           a=rtpmap:96 PCMU/8000
           a=gpmd:96 vbd=yes

           200 2000 OK
           I: 1

           v=0
           c=IN IP4 192.0.2.2
           m=audio 1296 RTP/AVP 18 96
           a=rtpmap:96 PCMU/8000
           a=gpmd:96 vbd=yes

   The RemoteConnectionDescriptor does not indicate support for "image/

Stone, et al.             Expires June 7, 2012                 [Page 30]
Internet-Draft              MGCP VBD package               December 2011

   t38" as a latent capability [RFC3407].  Consequently, the Gateway
   will not initiate the T.38 strict fax procedure, "t38", upon
   detecting fax stimulus (i.e., CNG, V.21 flags, ...).  However, the
   two endpoints did successfully negotiate a Gateway controlled VBD
   procedure (e.g., V.152), therefore, Gateway controlled mode involving
   "special fax handling" is used.  The "gwfax(start)" event will be
   generated upon detecting VBD (including fax) stimulus.

   A Call Agent can express a preference for a Gateway procedure
   involving "special fax handling" over a T.38 procedure (strict or
   loose).  For example,

   L: fxr/fx:gw;t38

   and,

   L: fxr/fx:gw;t38-loose

   However, with the existing syntax of the FXR package, a Call Agent
   cannot express a preference for one Gateway procedure over another,
   each with possibly different preferences relative to a T.38
   procedure.

   The FXR package allows a Gateway to implement additional fax handling
   parameters.  We define just such a parameter by qualifying the
   existing "gw" parameter with a list of one or more MIME types,

        Gateway  = "gw[" mimeType 0*("|" mimeType) "]"
        mimeType = mimeMediaType "/" mimeSubType
        ; mimeMediaType and mimeSubType from,
        ;   http://www.iana.org/assignments/media-types/

   By qualifying the "gw" parameter with a list of MIME types, we narrow
   the scope of the Gateway procedure.  Consider the following examples
   in which the Call Agent authorizes the use of a Gateway controlled
   fax handling procedure:

Stone, et al.             Expires June 7, 2012                 [Page 31]
Internet-Draft              MGCP VBD package               December 2011

      - involving "image/t38" (e.g., T.38oUDPTL, T.38oTCP),

         L: a:G729, fxr/fx:gw[image/t38]

     - involving VBD (e.g., PCMU and V.152),

         L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/PCMU]

     - involving VBD with redundancy (e.g., PCMU, V.152 and RFC 2198),

     L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU", gpmd/gpmd:"PCMU vbd=yes",
        fxr/fx:gw[audio/RED|audio/PCMU]

   Only "special fax handling" involving one of the specified MIME types
   is authorized.  Support for "special fax handling" involving one of
   the specified MIME types MUST be negotiated or this "instance" of the
   Gateway procedure is not initiated.  Consider the following example
   in which the Call Agent authorizes the use of a Gateway controlled
   fax handling procedure:

        - involving "audio/t38" (e.g., T.38oRTP),

            L: a:G729;t38, fxr/fx:gw[audio/t38]

   In this example, the call will fail if the Gateway fails to negotiate
   "audio/t38".

   The "fx" LocalConnectionOption MAY now involve multiple instances of
   the "gw" parameter, each with a different list of MIME types.  In
   order to authorize "no special fax handling", the Call Agent MUST
   include: the "gw" parameter without a MIME type; or the "off"
   parameter.  The instance of the "gw" parameter without a MIME type
   should appear as the last instance of the "gw" parameter.  In the
   following example,

   L: a:G729;PCMU, fxr/fx:gw[image/t38];gw

   the Call Agent authorizes the use of and expresses a preference for,

   1.  Gateway controlled image/t38 (e.g., T.38oUDPTL)

   2.  Any other Gateway procedure with "special fax handling"

Stone, et al.             Expires June 7, 2012                 [Page 32]
Internet-Draft              MGCP VBD package               December 2011

   3.  No special fax handling (this is a function of the "fxr/fx:gw"
   parameter as defined in section 2.1 of the MGCP Fax (FXR) package
   [RFC5347])

   If present, the "off" parameter should appear as the last parameter.
   In the following example,

   L: a:G729;PCMU;t38, fxr/fx:gw[audio/t38];off

   the Call Agent authorizes the use of and expresses a preference for,

   1.  Gateway controlled audio/t38 (e.g., T.38oRTP)

   2.  No special fax handling

   We can express relative preferences for different Gateway controlled
   fax handling procedures, not only with respect to one another, but
   with respect to T.38 procedures.  Consider the following preferential
   list of fax handling procedures,

   1.  Gateway controlled audio/t38 (e.g., T.38oRTP)

   2.  Gateway controlled image/t38 (e.g., T.38oUDPTL)

   3.  Call Agent Controlled image/t38

   4.  Gateway controlled VBD with Redundancy (e.g., PCMU, V.152 and RFC
   2198)

   5.  Gateway controlled VBD without Redundancy (e.g., PCMU and V.152)

   6.  Any other Gateway procedure with "special fax handling"

   7.  No special fax handling (this is a function of the "fxr/fx:gw"
   parameter as defined in section 2.1 of the MGCP Fax (FXR) package
   [RFC5347])

   This would be expressed as,

     L: a:G729;PCMU;t38;RED;PCMU,
        gpmd/gpmd:"PCMU:2 vbd=yes",
        fmtp:"RED PCMU:2/PCMU:2",
        fxr/fx:gw[audio/t38|image/t38];t38;gw[audio/RED|audio/PCMU:2];gw

   Note that the bracketed form of the "gw" parameter is NOT defined as

Stone, et al.             Expires June 7, 2012                 [Page 33]
Internet-Draft              MGCP VBD package               December 2011

   part of the VBD package.  The bracketed form of the "gw" parameter is
   defined as an extension to the FXR package.  Gateways that implement
   the bracketed form of the "gw" parameter MUST return this form of the
   parameter when capabilities are audited as illustrated by the
   following example:

        A: fxr/fx:t38;t38-loose;gw[audio/t38|image/t38];gw;off

   Support for the bracketed "gw" parameter MAY be spread across
   multiple capability lines,

        A: a:RED;PCMU, p:10-40, e:on, s:off,
           m:sendonly;recvonly;sendrecv;inactive,
           gpmd/gpmd:"PCMU vbd=yes",
             fmtp:"RED PCMU/PCMU",
             fxr/fx:gw[audio/RED|audio/PCMU]
        A: a:t38, fxr/fx:gw[audio/t38]
        A: a:image/t38, fxr/fx:t38;t38-loose;gw[image/t38]

   A Call Agent SHOULD only attempt to leverage the bracketed form of
   the "gw" parameter in conjunction with an endpoint which indicates
   support for the bracketed syntax as part of its capabilities.

   Call Agents and Gateways that do not support this form of the "gw"
   parameter MUST ignore the bracketed MIME type information consistent
   with the MGCP grammar [RFC3435].

Stone, et al.             Expires June 7, 2012                 [Page 34]
Internet-Draft              MGCP VBD package               December 2011

9.  Call Flow Examples

   In this section, we provide two call flow examples.  The first one
   illustrates a modem call under Gateway control using V.152.  The
   second one illustrates a fax call under Gateway control using V.152
   and Call Agent controlled T.38.

9.1.  Modem Call with Gateway Controlled VBD

   In this example, both sides support Gateway controlled VBD using
   V.152 with redundancy.  We assume the originating and terminating
   Call Agents communicate via the Session Initiation Protocol (SIP)
   [RFC3261]:

     ------------------------------------------------------------------
    | #|     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|               |               |           <- NTFY(gwvbd start)|
    |11|               |               |            200|->             |
    |12|NTFY(gwvbd start) ->           |               |               |
    |13|             <-|200            |               |               |
    |--|---------------|---------------|---------------|---------------|
    |14|               |               |               | (modem ends)  |
    |15|               |               |           <- NTFY(gwvbd stop) |
    |16|               |               |            200|->             |
    |17|NTFY(gwvbd stop) ->            |               |               |
    |18|             <-|200            |               |               |
     ------------------------------------------------------------------

   Step 1:

   The Call Agent issues a CreateConnection command to the Gateway
   instructing it to use G.729 media encoding and to notify it of the
   "gwvbd" and "nopvbd" events.  The Call Agent authorizes the
   negotiation of G.711u as a VBD codec with a redundancy level of one:

Stone, et al.             Expires June 7, 2012                 [Page 35]
Internet-Draft              MGCP VBD package               December 2011

      CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
      C: 1
      L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
      M: recvonly
      R: vbd/gwvbd, vbd/nopvbd
      X: 1
      Q: process, loop

   Step 2:

   The Gateway acknowledges the command and includes SDP with codec
   information as well as V.152 and redundancy information:

           200 1000 OK
           I:1

           v=0
           o=- 25678 753849 IN IP4 192.0.2.1
           s=-
           c=IN IP4 192.0.2.1
           t=0 0
           m=audio 3456 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes

   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 G.729 media encoding and to
   notify it of the "gwvbd" and "nopvbd" events.  Again, the Call Agent
   authorizes the negotiation of G.711u as a VBD codec with a redundancy
   level of one:

Stone, et al.             Expires June 7, 2012                 [Page 36]
Internet-Draft              MGCP VBD package               December 2011

      CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
      C: 2
      L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
      M: sendrecv
      R: vbd/gwvbd, vbd/nopvbd
      X: 20
      Q: process, loop

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 18 96 97
      a=rtpmap:96 RED/8000
      a=fmtp:96 97/97
      a=rtpmap:97 PCMU/8000
      a=gpmd:97 vbd=yes

   Step 5:

   The terminating Gateway supports V.152 and redundancy, and the
   RemoteConnectionDescriptor included indicates that the other side
   supports V.152 and redundancy.  The terminating Gateway sends back a
   success response with its SDP which also includes V.152 and
   redundancy information:

           200 2000 OK
           I:2

           v=0
           o=- 25678 753849 IN IP4 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           m=audio 1296 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes

   Step 6:

Stone, et al.             Expires June 7, 2012                 [Page 37]
Internet-Draft              MGCP VBD package               December 2011

   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 turn 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 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           m=audio 1296 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes

   Since the RemoteConnectionDescriptor indicates the other side
   supports V.152 and redundancy, the Gateway will in fact be able to
   use the Gateway controlled VBD procedure with redundancy.  Had there
   not been any support for V.152 in the RemoteConnectionDescriptor,
   then this command would still have succeeded, however there would be
   no negotiated procedure for VBD handling.

   Step 8:

   The Gateway acknowledges the command.  At this point, a call is
   established using G.729 encoding, and if a VBD call is detected, the
   Gateway controlled VBD procedure will be initiated.

   Step 9-10:

   A modem call now occurs.  The terminating Gateway detects a T.30 CED
   tone (a.k.a.  V.25 ANS) in the GSTN to IP direction and begins
   transmitting RTP packets with the negotiated redundant VBD payload
   type (96).

   The "gwvbd(start)" event occurs and is notified to the Call Agent:

Stone, et al.             Expires June 7, 2012                 [Page 38]
Internet-Draft              MGCP VBD package               December 2011

           NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
           X: 20

   Step 11:

   The Call Agent acknowledges the Notify command:

   200 2500 OK

   Step 12:

   Upon receiving a RTP packet with the redundant VBD payload type (96),
   the originating Gateway begins transmitting RTP packets with the
   redundant VBD payload type.

   The "gwvbd(start)" event occurs and is notified to the Call Agent:

           NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
           O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
           X: 1

   Step 13:

   The Call Agent acknowledges the Notify command:

   200 1500 OK

   Step 14 - 15:

   The modem call ends.  The terminating Gateway detects bi-directional
   silence and begins transmitting RTP packets with the negotiated audio
   payload type (18).

   The "gwvbd(stop)" event occurs and is notified to the Call Agent:

           NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
           X: 20

Stone, et al.             Expires June 7, 2012                 [Page 39]
Internet-Draft              MGCP VBD package               December 2011

   Step 16:

   The Call Agent acknowledges the Notify command:

   200 2501 OK

   Step 17:

   Upon receiving a RTP packet with the audio payload type (18), the
   originating Gateway begins transmitting RTP packets with the audio
   payload type.

   The "gwvbd(stop)" event occurs and is notified to the Call Agent:

           NTFY 1501 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
           O: vbd/gwvbd(stop, rc=PTSW, codec=audio/G729)
           X: 1

   Step 18:

   The Call Agent acknowledges the Notify command:

           200 1501 OK

   The modem call is now over.

9.2.  Fax Call with Gateway Controlled VBD and Call Agent Controlled
      T.38

   In this example, both sides support Gateway controlled VBD using
   V.152 with Redundancy and Call Agent controlled T.38.  We assume the
   originating and terminating Call Agent communicate via the Session
   Initiation Protocol (SIP) [RFC3261]:

Stone, et al.             Expires June 7, 2012                 [Page 40]
Internet-Draft              MGCP VBD package               December 2011

     ------------------------------------------------------------------
    | #|     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|               |               |           <- NTFY(gwvbd start)|
    |11|               |               |            200|->             |
    |12|NTFY(gwvbd start) ->           |               |               |
    |13|             <-|200            |               |               |
    |14|               |               |               <- V.21 Preamble|
    |15|               |               |             <- NTFY(t38 start)|
    |16|               |               |            200|->             |
    |17|               |               |      MDCX(t38)|->             |
    |18|               |               |             <-|200(sdp-t2)    |
    |19|               |             <-|INVITE(sdp-t2) |               |
    |20|             <-|MDCX(sdp-t2)   |               |               |
    |21|    200(sdp-o2)|->             |               |               |
    |22|               |    200(sdp-o2)|->             |               |
    |23|               |               |   MDCX(sdp-o2)|->             |
    |24|               |               |             <-|200            |
    |25| V.21 Preamble |->             |               |               |
    |26|NTFY(t38 start)|->             |               |               |
    |27|             <-|200            |               |               |
    |--|---------------|---------------|---------------|---------------|
    |28|               |               |               |   (fax ends)  |
    |29|               |               |             <-|NTFY(t38 stop) |
    |30|               |               |            200|->             |
    |31|NTFY(t38 stop) |->             |               |               |
    |32|             <-|200            |               |               |
     ------------------------------------------------------------------

   Step 1:

   The Call Agent issues a CreateConnection command to the Gateway
   instructing it to use G.729 media encoding and to use either the
   strict T.38 procedure or the Gateway procedure.  Consequently, the
   Call Agent requests notification of the "t38", "gwfax", "gwvbd" and
   "nopvbd" events.  The Call Agent authorizes the negotiation of G.711u

Stone, et al.             Expires June 7, 2012                 [Page 41]
Internet-Draft              MGCP VBD package               December 2011

   as a VBD codec with a redundancy level of one:

     CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
     C: 1
     L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU",
        fxr/fx:t38;gw
     M: recvonly
     R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd
     X: 1
     Q: process, loop

   Step 2:

   The Gateway acknowledges the command and includes SDP with codec
   information as well as capability, V.152 and redundancy information:

           200 1000 OK
           I:1

           v=0
           o=- 25678 753849 IN IP4 192.0.2.1
           s=-
           c=IN IP4 192.0.2.1
           t=0 0
           a=pmft: T38
           m=audio 3456 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cdsc: 4 image udptl t38

   Note that V.152 requires the use of the session-level "a=pmft" SDP
   attribute in order to express a preference for T.38 over V.152 for
   fax handling.

   Step 3:

   The originating Call Agent sends a SIP INVITE message with the SDP to
   the terminating Call Agent.

Stone, et al.             Expires June 7, 2012                 [Page 42]
Internet-Draft              MGCP VBD package               December 2011

   Step 4:

   The terminating Call Agent issues a CreateConnection command to the
   terminating Gateway instructing it to use G.729 media encoding and to
   use either the strict T.38 procedure or the Gateway procedure.
   Consequently, the Call Agent requests notification of the "t38",
   "gwfax", "gwvbd" and "nopvbd" events.  Again, the Call Agent
   authorizes the negotiation of G.711u as a VBD codec with a redundancy
   level of one:

     CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
     C: 2
     L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU",
        fxr/fx:t38;gw
     M: sendrecv
     R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd
     X: 20
     Q: process, loop

     v=0
     o=- 25678 753849 IN IP4 192.0.2.1
     s=-
     c=IN IP4 192.0.2.1
     t=0 0
     a=pmft: T38
     m=audio 3456 RTP/AVP 18 96 97
     a=rtpmap:96 RED/8000
     a=fmtp:96 97/97
     a=rtpmap:97 PCMU/8000
     a=gpmd:97 vbd=yes
     a=sqn: 0
     a=cdsc: 1 audio RTP/AVP 18 96 97
     a=cdsc: 4 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 supports
   V.152 and redundancy, and the RemoteConnectionDescriptor included
   indicates that the other side supports V.152 and redundancy, so
   Gateway controlled VBD using V.152 and redundancy can be used for
   modem and text transmissions.  The terminating Gateway sends back a
   success response with its SDP which also includes capability, V.152

Stone, et al.             Expires June 7, 2012                 [Page 43]
Internet-Draft              MGCP VBD package               December 2011

   and redundancy information:

           200 2000 OK
           I:2

           v=0
           o=- 25678 753849 IN IP4 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           a=pmft: T38
           m=audio 1296 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cdsc: 4 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 turn sends a ModifyConnection command
   to the originating Gateway:

Stone, et al.             Expires June 7, 2012                 [Page 44]
Internet-Draft              MGCP VBD package               December 2011

           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 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           a=pmft: T38
           m=audio 1296 RTP/AVP 18 96 97
           a=rtpmap:96 RED/8000
           a=fmtp:96 97/97
           a=rtpmap:97 PCMU/8000
           a=gpmd:97 vbd=yes
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cdsc: 4 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.  Since the
   RemoteConnectionDescriptor indicates the other side supports V.152
   and redundancy, the Gateway will in fact be able to use the V.152 VBD
   procedure with redundancy.

   Step 8:

   The Gateway acknowledges the command.  At this point, a call is
   established using G.729 encoding, and if a fax call is detected, the
   Call Agent controlled T.38 procedure will be initiated.  If a modem
   or text call is detected, the V.152 VBD procedure will be initiated.

   Step 9-10:

   The terminating Gateway detects the T.30 CED tone (a.k.a.  V.25 ANS).
   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 14,
   where the V.21 fax preamble is detected.  The terminating Gateway
   begins transmitting RTP packets with the negotiated redundant VBD
   payload type (96).

Stone, et al.             Expires June 7, 2012                 [Page 45]
Internet-Draft              MGCP VBD package               December 2011

   The "gwvbd(start)" event occurs and is notified to the Call Agent:

           NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
           X: 20

   Step 11:

   The Call Agent acknowledges the Notify command:

           200 2500 OK

   Step 12:

   Upon receiving a RTP packet with the redundant VBD payload type (96),
   the originating Gateway begins transmitting RTP packets with the
   redundant VBD payload type.

   The "gwvbd(start)" event occurs and is notified to the Call Agent:

           NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
           O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
           X: 1

   Step 13:

   The Call Agent acknowledges the Notify command:

           200 1500 OK

   Step 14 - 15:

   The terminating Gateway detects the V.21 fax preamble.

   The terminating Gateway is using the Call Agent controlled T.38
   strict procedure for fax calls, so the "t38(start)" event occurs:

Stone, et al.             Expires June 7, 2012                 [Page 46]
Internet-Draft              MGCP VBD package               December 2011

           NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           O: fxr/t38(start)
           X: 20

   Step 16:

   The Call Agent acknowledges the Notify command:

           200 2500 OK

   Step 17:

   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

   Note that the Call Agent is no longer requesting notification of the
   "gwvbd" event.

   Step 18:

   The terminating Gateway sends back a success response with its SDP
   which also includes the "image/t38" media description:

Stone, et al.             Expires June 7, 2012                 [Page 47]
Internet-Draft              MGCP VBD package               December 2011

           200 2002 OK

           v=0
           o=- 25678 753850 IN IP4 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           m=image 1296 udptl t38
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cpar: a=rtpmap:96 RED/8000
           a=cpar: a=fmtp:96 97/97
           a=cpar: a=rtpmap:97 PCMU/8000
           a=cpar: a=gpmd:97 vbd=yes
           a=cdsc: 4 image udptl t38

   The gwvbd procedure ends due to the media type change.  The
   "gwvbd(stop)" event would normally be notified at this point,
   however, the Call Agent is no longer requesting notification of the
   "gwvbd" event.  The Call Agent would have inferred from the
   "t38(start)" event that the gwvbd procedure ended.

   Step 19:

   The terminating Call Agent sends a re-INVITE to the originating Call
   Agent with the updated SDP.

   Step 20:

   The originating Call Agent then sends a ModifyConnection command to
   the originating Gateway:

Stone, et al.             Expires June 7, 2012                 [Page 48]
Internet-Draft              MGCP VBD package               December 2011

           MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
           C: 1
           I: 1
           R: fxr/t38
           X: 2

           v=0
           o=- 25678 753850 IN IP4 192.0.2.2
           s=-
           c=IN IP4 192.0.2.2
           t=0 0
           m=image 1296 udptl t38
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cpar: a=rtpmap:96 RED/8000
           a=cpar: a=fmtp:96 97/97
           a=cpar: a=rtpmap:97 PCMU/8000
           a=cpar: a=gpmd:97 vbd=yes
           a=cdsc: 4 image udptl t38

   Step 21:

   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 192.0.2.1
           s=-
           c=IN IP4 192.0.2.1
           t=0 0
           m=image 3456 udptl t38
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cpar: a=rtpmap:96 RED/8000
           a=cpar: a=fmtp:96 97/97
           a=cpar: a=rtpmap:97 PCMU/8000
           a=cpar: a=gpmd:97 vbd=yes
           a=cdsc: 4 image udptl t38

   Again, the gwvbd procedure ends due to the media type change.  The
   "gwvbd(stop)" event would normally be notified at this point,

Stone, et al.             Expires June 7, 2012                 [Page 49]
Internet-Draft              MGCP VBD package               December 2011

   however, the Call Agent is no longer requesting notification of the
   "gwvbd" event.

   Step 22:

   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 23:

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

           MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
           C: 2
           I: 2

           v=0
           o=- 25678 753850 IN IP4 192.0.2.1
           s=-
           c=IN IP4 192.0.2.1
           t=0 0
           m=image 3456 udptl t38
           a=sqn: 0
           a=cdsc: 1 audio RTP/AVP 18 96 97
           a=cpar: a=rtpmap:96 RED/8000
           a=cpar: a=fmtp:96 97/97
           a=cpar: a=rtpmap:97 PCMU/8000
           a=cpar: a=gpmd:97 vbd=yes
           a=cdsc: 4 image udptl t38

   Step 24 - 32: These steps correspond to the Call Agent controlled
   T.38 strict procedure as defined in the MGCP Fax (FXR) package
   [RFC5347].

Stone, et al.             Expires June 7, 2012                 [Page 50]
Internet-Draft              MGCP VBD package               December 2011

10.  Security Considerations

   This document defines two new packages, both of which have security
   considerations in two areas:

   1.  MGCP signaling message security

   2.  Media stream security

   From an MGCP signaling security point of view, the MGCP VBD and GPMD
   packages define extensions to the basic MGCP signaling specification
   in accordance with the procedures specified in MGCP [RFC3435] and
   hence the MGCP signaling security considerations and recommendations
   provided in MGCP [RFC3435] Section 5 (namely use of IPsec) apply here
   as well.  Lack of MGCP signaling integrity protection can in general
   be detrimental to any use of MGCP, and the two packages defined here
   do not change that.  From a confidentiality point of view, the VBD
   package is not believed to convey any vulnerable or privacy-sensitive
   information.  The GPMD package is slightly different inasmuch as it
   does not define any specific parameters that are believed to require
   confidentiality, however it is a generic parameter that can carry any
   codec parameter information, and hence it is possible that
   confidential information is conveyed through this parameter.  If
   confidentiality of any such potential information is a concern,
   confidentiality protection of the MGCP signaling MUST be provided as
   well.  It should be noted, that [RFC5406] Section 8 provides
   considerations for specifying the use of IPsec that are above and
   beyond those provided in [RFC3435], however given that IPsec use for
   MGCP applies to all of MGCP, and not just the MGCP VBD and GPMD
   packages, we do not specify such additional detail here.

   From a media stream security point of view, the MGCP VBD and GPMD
   packages again define extensions that rely on the general use of
   media streams defined in MGCP [RFC3435] and hence the MGCP media
   stream security considerations and recommendations provided in MGCP
   [RFC3435] Section 5.1 apply here as well.  Lack of media stream
   security can in general be detrimental to any media stream
   established via MGCP, and the two packages defined here do not change
   that.  Confidentiality concerns apply as for any other media stream.
   Integrity concerns are furter compounded by the GPMD package's use of
   payload type switching, state signaling events and media stream in-
   band triggers to drive overall voiceband data operation: Integrity
   protection with replay protection MUST be used to counter these
   threats.

   Ideally, there would be a single mandatory-to-implement media stream
   security mechanism to provide this integrity protection, and in
   theory there is since MGCP [RFC3435] defines a media stream security

Stone, et al.             Expires June 7, 2012                 [Page 51]
Internet-Draft              MGCP VBD package               December 2011

   mechanism.  However, the standard MGCP media stream security
   mechanism defined in [RFC3435] on relies on the encryption key ("k=')
   field defined in the original SDP specification [RFC2327], the use of
   which is no longer recommended in the updated SDP specification
   [RFC4566].  In practice, this mechanism has also seen very limited
   implementation and hence there is not much value in relying on it.
   Still, the integrity protection requirement remains, and there are
   several different ways this can be achieved:

   Secure RTP:   For RTP-based media streams, the use of Secure RTP
      [RFC3711] with an associated key management mechanism is generally
      preferred at time of writing, however such a mechanism has
      currently not been defined for MGCP.

   PacketCable Security:   PacketCable Network-Based Call Signalling
      Protocol [NCS] defines another media stream security mechanism
      which is generally supported by PacketCable compliant
      implementations.  Implementations targeted for those environments
      SHOULD implement this security mechanism.

   Lower Level Security:   In the absence of a common media stream
      security mechanism supported by both endpoints, a lower level
      security mechanism, e.g.  IPsec MUST be used.  Note that since
      there is no inherent MGCP signaling support for such a lower level
      security mechanism, it MUST be configured by other means.

Stone, et al.             Expires June 7, 2012                 [Page 52]
Internet-Draft              MGCP VBD package               December 2011

11.  IANA Considerations

   The IANA is hereby requested to register the following MGCP packages,

         Package Title                               Name     Version
         -------------                               ----     -------
         Voiceband Data                              VBD      0
         General-Purpose Media Descriptor Parameter  GPMD     0

Stone, et al.             Expires June 7, 2012                 [Page 53]
Internet-Draft              MGCP VBD package               December 2011

12.  Acknowledgements

   Several people have contributed to the development of the MGCP VBD
   and GPMD packages and the use of the MIME subtypes "RED" and
   "parityfec" with the FM package for VBD with redundancy and FEC.  In
   particular, the authors would like to thank Flemming Andreasen, John
   Atkinson, Bill Foster and the CableLabs PacketCable TGCP/NCS focus
   team for their contributions.  Many thanks to Billy Hare for doing a
   thorough review of this document.

   Joe Stone and Rajesh Kumar are the main authors of this document;
   security considerations and final editor role were provided by
   Flemming Andreasen.  Sandeep Sharma was editor on earlier versions of
   the document.

Stone, et al.             Expires June 7, 2012                 [Page 54]
Internet-Draft              MGCP VBD package               December 2011

13.  Summary of Changes

   Changes in 01:

   * Number of formatting corrections (mainly to remove extra blank
   lines)

   * Updated a number of internal section references (these were off by
   one due to addition of new section 2 Terminology as part of initial
   version 00 submission)

   * In section 3.1.2, corrected Start VBD to VBD Start

   * In section 4.1.1, added text to clarify that the first instance is
   assumed in the absence of <order>

   Changes in 02:

   * Fix errors, warnings and comments reported by ID nits

   Changes in 03:

   * Editorial corrections throughout the document

   Changes in 04:

   * No changes

   Changes in 05:

   * Make reference to the MGCP Fax RFC 5347, address expert review
   comments and add clarifications where needed.

   Changes in 06:

   * Editorial updates to address feedback from expert reviewer
   (Flemming).

   Changes in 07:

   * No changes.

   Changes in 08:

   * Address multiple last call comments from various directorates.

   Changes in 09:

Stone, et al.             Expires June 7, 2012                 [Page 55]
Internet-Draft              MGCP VBD package               December 2011

   * Rewrote security considerations to resolve IESG review comments.

   Changes in 10:

   * Updated security considerations and added applicability statement.

Stone, et al.             Expires June 7, 2012                 [Page 56]
Internet-Draft              MGCP VBD package               December 2011

14.  References

14.1.  Normative References

   [H2482]    International Telecommunications Union - Telecommunication
              Standardization Sector, "ITU-T Recommendation H.248.2,
              "Gateway control protocol: Facsimile, text conversation
              and call discrimination packages"", Nov 2000.

   [NCS]      CableLabs(R) Packetcable(TM), "PacketCable 1.5
              Specifications: Network-Based Call Signaling Protocol,
              PKT-SP-NCS1.5-I03-070412", April 2007.

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

   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
              Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
              September 1997.

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

   [RFC3435]  Andreasen, F. and B. Foster, "Media Gateway Control
              Protocol (MGCP) Version 1.0", RFC 3435, January 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3660]  Foster, B. and F. Andreasen, "Basic Media Gateway Control
              Protocol (MGCP) Packages", RFC 3660, December 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
              December 2006.

   [RFC4734]  Schulzrinne, H. and T. Taylor, "Definition of Events for
              Modem, Fax, and Text Telephony Signals", RFC 4734,
              December 2006.

   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

Stone, et al.             Expires June 7, 2012                 [Page 57]
Internet-Draft              MGCP VBD package               December 2011

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5347]  Andreasen, F. and D. Hancock, "Media Gateway Control
              Protocol Fax Package", RFC 5347, October 2008.

   [V1501]    International Telecommunications Union - Telecommunication
              Standardization Sector, "ITU-T Recommendation V.150.1,
              "Modem-over-IP networks: Procedures for the end-to-end
              connection of V-series DCEs"", Jan 2003.

   [V1501A1]  International Telecommunications Union - Telecommunication
              Standardization Sector, "ITU-T Recommendation V.150.1
              Amendment 1, "Modem-over-IP networks: Procedures for the
              end-to-end connection of V-series DCEs, Amendment 1:
              Modification to SSE reason identifier codes to support
              voice band data and text relay",", Jan 2005.

   [V152]     International Telecommunications Union - Telecommunication
              Standardization Sector, "ITU-T Recommendation V.152,
              "Procedures for supporting Voice-Band Data over IP
              Networks"", Jan 2005.

14.2.  Informative References

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC5406]  Bellovin, S., "Guidelines for Specifying the Use of IPsec
              Version 2", BCP 146, RFC 5406, February 2009.

   [T38]      International Telecommunications Union - Telecommunication
              Standardization Sector, "ITU-T Recommendation T.38,
              "Procedures for real-time Group 3 facsimile communication
              over IP networks",", April 2004.

Stone, et al.             Expires June 7, 2012                 [Page 58]
Internet-Draft              MGCP VBD package               December 2011

Authors' Addresses

   Joe Stone
   Cisco Systems
   2200 East President George Bush Highway
   Richardson, Tx  75082
   USA

   Email: joestone@cisco.com
   URI:   http://www.cisco.com/

   Rajesh Kumar
   Cisco Systems
   771 Alder Drive
   Milpitas, CA  75082
   USA

   Email: rkumar@cisco.com
   URI:   http://www.cisco.com/

   Flemming Andreasen
   Cisco Systems
   Iselin, NJ  08830
   USA

   Email: fandreas@cisco.com
   URI:   http://www.cisco.com/

Stone, et al.             Expires June 7, 2012                 [Page 59]