doc: Add RFC documents

1 files changed, 2635 insertions, 0 deletions

diff --git a/doc/rfc/rfc6498.txt b/doc/rfc/rfc6498.txt
new file mode 100644
index 0000000..15872d7
--- /dev/null
+++ b/doc/rfc/rfc6498.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Stone
+Request for Comments: 6498                                      R. Kumar
+Category: Informational                                     F. Andreasen
+ISSN: 2070-1721                                            Cisco Systems
+                                                           February 2012
+
+
+ Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and
+           General-Purpose Media Descriptor Parameter Package
+
+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 defining 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 document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6498.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                     [Page 1]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   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.                 Informational                     [Page 2]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+Table of Contents
+
+   1. Applicability Statement .........................................3
+   2. Introduction ....................................................3
+   3. Terminology .....................................................5
+   4. Voiceband Data Package Definition ...............................5
+      4.1. Events and Signals .........................................5
+           4.1.1. Gateway Controlled Voiceband Data ...................6
+           4.1.2. No Negotiated Procedure for Voiceband Data .........13
+   5. General-Purpose Media Descriptor Parameter Package Definition ..16
+      5.1. LocalConnectionOptions ....................................16
+           5.1.1. General-Purpose Media Descriptor Parameter .........17
+   6. Use of Media Format Parameter Package with VBD and Redundancy ..20
+   7. Use of Media Format Parameter Package with VBD and FEC .........22
+   8. Use of Fax Package with VBD ....................................23
+   9. Call Flow Examples .............................................27
+      9.1. Modem Call with Gateway Controlled VBD ....................27
+      9.2. Fax Call with Gateway Controlled VBD and Call
+           Agent Controlled T.38 .....................................33
+   10. Security Considerations .......................................42
+   11. IANA Considerations ...........................................44
+   12. Acknowledgements ..............................................44
+   13. References ....................................................44
+      13.1. Normative References .....................................44
+      13.2. Informative References ...................................46
+
+1.  Applicability Statement
+
+   This document defines a mechanism that requires media stream
+   integrity protection.  The document specifies different alternative
+   mechanisms 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.
+
+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 RTP as defined in 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].
+
+
+
+
+
+Stone, et al.                 Informational                     [Page 3]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 Session Description Protocol (SDP)
+   [RFC4566].  These coordination techniques include
+
+   o  ITU-T Recommendation V.150.1 State Signaling Event (SSE) [V1501]
+
+   o  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.
+
+   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 does it advocate one procedure over another.
+
+   We will use the term VBD to refer to Voiceband Data in general.  In
+   referring to VBD in the context of 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
+   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
+
+
+
+Stone, et al.                 Informational                     [Page 4]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 4.  The GPMD
+   package definition is provided in Section 5.  In Section 6, we
+   discuss the use of the FM package with VBD and redundancy.  In
+   Section 7, we discuss the use of the FM package with VBD and FEC.  In
+   Section 8, we discuss the use of the FXR package with VBD.  In
+   Section 9, we provide two call flow examples showing how to use the
+   VBD and GPMD packages.  Security considerations are found in
+   Section 10, followed by the IANA considerations (Section 11) and
+   references.
+
+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].
+
+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 Section 6.6 of
+   RFC 3435 [RFC3435].  The definitions of the individual events are
+   provided in the following subsections.
+
+
+
+
+Stone, et al.                 Informational                     [Page 5]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+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.
+
+   In this section, we provide a formal description of the protocol
+   syntax, using ABNF as defined in "Augmented BNF for Syntax
+   Specifications: ABNF" [RFC5234].  The syntax makes use of the core
+   rules defined in Appendix B.1 of [RFC5234], 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 parameter is encoded as
+
+      GwVbdReqEvent = "gwvbd"
+
+   The ObservedEvent parameter 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] ")"
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                     [Page 6]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      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 as follows:
+
+   1) VBD Start (start)
+
+      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] [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.
+
+
+
+
+
+Stone, et al.                 Informational                     [Page 7]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 as follows:
+
+   1) Reason Code (rc=<ReasonCode>)
+
+      With the "start" and "update" parameters, the reason for
+      triggering the switch/change to VBD.  With the "stop" and
+      "failure" parameters, 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" parameters:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                     [Page 8]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+       ---------------------------------------------------------------
+      | 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 fax 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.                 Informational                     [Page 9]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      With a ReasonCode of "PTSW", the Call Agent cannot differentiate
+      text from fax/modem.  In this case, the Call Agent SHOULD adopt a
+      policy that 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
+      that 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 are listed
+      below:
+
+             ------------------------------------------------------
+            | 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
+      called terminal identification (CED).  Subsequently, the Call
+      Agent controlled T.38 procedure of the MGCP Fax (FXR) package
+      [RFC5347] may be initiated upon detecting V.21 flags.  Upon
+      receipt of a "t38(start)" event, the Call Agent will instruct the
+
+
+
+Stone, et al.                 Informational                    [Page 10]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      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 9.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.
+
+   2) Codec String (codec=<CodecString>)
+
+      With the "start" and "update" parameters, 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"
+      parameters, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 11]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   3) 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:
+
+           ------------------------------------------------------
+          | 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 signaling 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.
+
+   4) Direction of Stimulus (dir=<Direction>)
+
+      With the "start" and "update" parameters, the "dir" parameter
+      describes the direction of the stimulus that resulted in the
+      switch/change to VBD.
+
+            ---------------------------------------------------
+           | 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, and text tones   |
+           |           | (e.g., IP-side tone detection);        |
+           |           | RTP packet with VBD payload type       |
+           |           | (e.g., V.152 or V.150.1).              |
+            ----------------------------------------------------
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 12]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 that 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)
+
+   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.
+
+
+
+
+Stone, et al.                 Informational                    [Page 13]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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.
+
+      The RequestedEvent parameter is encoded as
+
+        NopVbdReqEvent = "nopvbd"
+
+      The ObservedEvent parameter 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
+   parameter:
+
+     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.
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 14]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   The "start", "update", "stop", and "failure" ObservedEvent parameters
+   are defined as follows:
+
+   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
+      "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 4.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 that 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.
+
+
+
+
+Stone, et al.                 Informational                    [Page 15]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+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)
+
+   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)
+
+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 new LocalConnectionOptions field 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.
+
+
+
+Stone, et al.                 Informational                    [Page 16]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+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>"
+
+   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 semicolon-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"
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 17]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   However, it would not be clear whether 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 whether "parameterX" is preferred (i.e., associated with the
+   first "codec1") or not (i.e., associated with the second "codec1").
+   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.  For example,
+
+         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.
+
+   Prepending "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 semicolon-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"
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 18]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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:
+
+     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, 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 like the example below.  In this
+   example, 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.                 Informational                    [Page 19]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 6 for more examples involving V.152 and redundancy.
+
+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 5.
+
+   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"
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 20]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   Let's build on the example of Section 5.  In the example below, G.729
+   is an audio codec, and 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"
+
+   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
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 21]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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:
+
+        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
+
+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"
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 22]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      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,
+   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"
+
+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 that could otherwise have a
+   negative impact on the gateway procedure.
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 23]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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/
+   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, etc.).  However, the
+   two endpoints did successfully negotiate a gateway controlled VBD
+   procedure (e.g., V.152); therefore, a 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.
+
+
+
+
+Stone, et al.                 Informational                    [Page 24]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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:
+
+       - 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"
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 25]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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"
+
+   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])
+
+
+
+Stone, et al.                 Informational                    [Page 26]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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
+   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 that 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].
+
+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 that the originating and
+   terminating Call Agents communicate via the Session Initiation
+   Protocol (SIP) [RFC3261]:
+
+
+
+Stone, et al.                 Informational                    [Page 27]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+    ------------------------------------------------------------------
+   | #|     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:
+
+      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
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 28]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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:
+
+      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
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 29]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      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:
+
+      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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 30]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 that 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.
+
+   Steps 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 a Notify command is sent 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
+
+
+
+Stone, et al.                 Informational                    [Page 31]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   Step 11:
+
+      The Call Agent acknowledges the Notify command:
+
+           200 2500 OK
+
+   Step 12:
+
+      Upon receiving an 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 a Notify command is sent 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
+
+   Steps 14-15:
+
+      The modem call ends.  The terminating gateway detects
+      bidirectional silence and begins transmitting RTP packets with the
+      negotiated audio payload type (18).
+
+      The "gwvbd(stop)" event occurs, and a Notify command is sent 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
+
+   Step 16:
+
+      The Call Agent acknowledges the Notify command:
+
+           200 2501 OK
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 32]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   Step 17:
+
+      Upon receiving an 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 a Notify command is sent 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 that
+   the originating and terminating Call Agent communicate via the
+   Session Initiation Protocol (SIP) [RFC3261]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 33]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+    ------------------------------------------------------------------
+   | #|     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 as a VBD codec with a redundancy level of one:
+
+
+
+
+Stone, et al.                 Informational                    [Page 34]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+     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.
+
+   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
+
+
+
+Stone, et al.                 Informational                    [Page 35]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      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, 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
+
+
+
+Stone, et al.                 Informational                    [Page 36]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+           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:
+
+           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 that 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
+
+
+
+Stone, et al.                 Informational                    [Page 37]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+      RemoteConnectionDescriptor indicates that 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.
+
+   Steps 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).
+
+      The "gwvbd(start)" event occurs, and a Notify command is sent 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 an 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 a Notify command is sent 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
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 38]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   Step 13:
+
+      The Call Agent acknowledges the Notify command:
+
+           200 1500 OK
+
+   Steps 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,
+      and a Notify command is sent to the Call Agent:
+
+           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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 39]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   Step 18:
+
+      The terminating gateway sends back a success response with its
+      SDP, which also includes the "image/t38" media description:
+
+           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 notification would normally be sent 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:
+
+           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
+
+
+
+Stone, et al.                 Informational                    [Page 40]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+           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 the 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 notification would normally be sent at this
+      point; 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).
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 41]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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
+
+   Steps 24-32:
+
+      These steps correspond to the Call Agent controlled T.38 strict
+      procedure as defined in the MGCP Fax (FXR) package [RFC5347].
+
+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 Section 5 of [RFC3435] (namely the 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
+
+
+
+Stone, et al.                 Informational                    [Page 42]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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 Section 8 of [RFC5406]
+   provides considerations for specifying the use of IPsec that are
+   above and beyond those provided in [RFC3435]; however, given that the
+   use of IPsec 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
+   Section 5.1 of [RFC3435] 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 further 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
+   mechanism.  However, the standard MGCP media stream security
+   mechanism defined in [RFC3435] relies on the encryption key ("k=")
+   field defined in the original SDP specification [RFC2327], the use of
+   which is no longer recommended in the current 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 the time of this writing; however, such a mechanism
+      has currently not been defined for MGCP.
+
+   PacketCable Security:   The PacketCable Network-Based Call Signaling
+      Protocol [NCS] defines another media stream security mechanism
+      that is generally supported by PacketCable-compliant
+      implementations.  Implementations targeted for those environments
+      SHOULD implement this security mechanism.
+
+
+
+
+Stone, et al.                 Informational                    [Page 43]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   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.
+
+11.  IANA Considerations
+
+   The IANA has registered the following MGCP packages:
+
+      Package Title                               Name     Version
+      -------------                               ----     -------
+      Voiceband Data                              VBD      0
+      General-Purpose Media Descriptor Parameter  GPMD     0
+
+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.
+
+13.  References
+
+13.1.  Normative References
+
+   [H2482]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "Gateway control protocol:
+              Facsimile, text conversation and call discrimination
+              packages", ITU-T Recommendation H.248.2, November 2000.
+
+   [NCS]      CableLabs(R), "PacketCable(TM) 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.
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 44]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   [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., Ed., "RTP Payload Format for Generic Forward Error
+              Correction", RFC 5109, December 2007.
+
+   [RFC5234]  Crocker, D., Ed., 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 Telecommunication Union - Telecommunication
+              Standardization Sector, "Modem-over-IP networks:
+              Procedures for the end-to-end connection of V-series
+              DCEs", ITU-T Recommendation V.150.1, January 2003.
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 45]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+   [V1501A1]  International Telecommunication Union - Telecommunication
+              Standardization Sector, "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",
+              ITU-T Recommendation V.150.1 Amendment 1, January 2005.
+
+   [V152]     International Telecommunication Union - Telecommunication
+              Standardization Sector, "Procedures for supporting Voice-
+              Band Data over IP Networks", ITU-T Recommendation V.152,
+              January 2005.
+
+13.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 Telecommunication Union - Telecommunication
+              Standardization Sector, "Procedures for real-time Group 3
+              facsimile communication over IP networks",
+              ITU-T Recommendation T.38, April 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stone, et al.                 Informational                    [Page 46]
+
+RFC 6498                    MGCP VBD Package               February 2012
+
+
+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
+   Mail Stop SJCE/1/1
+   190 West Tasman Drive
+   San Jose, CA  95134
+   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.                 Informational                    [Page 47]
+