Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

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

1. Introduction
2. Terminology
3. Voiceband Data Package Definition
    3.1. Events and Signals
        3.1.1. Gateway Controlled Voiceband Data
        3.1.2. No Negotiated Procedure for Voiceband Data
4. General-Purpose Media Descriptor Parameter Package Definition
    4.1. LocalConnectionOptions
        4.1.1. General-Purpose Media Descriptor Parameter
5. Use of Media Format Parameter Package with VBD and Redundancy
6. Use of Media Format Parameter Package with VBD and FEC
7. Use of Fax Package with VBD
8. Call Flow Examples
    8.1. Modem Call with Gateway Controlled VBD
    8.2. Fax Call with Gateway Controlled VBD and Call Agent Controlled T.38
9. Security Considerations
10. IANA Considerations
11. Acknowledgements
12. Summary of Changes
13. References
    13.1. Normative References
    13.2. Informative References
§ Authors' Addresses

1. Introduction

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

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

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

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

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

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

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

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

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

This document will explore the use of the FM package with VBD and FEC.

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

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

2. Terminology

3. Voiceband Data Package Definition

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

Package Name: VBD

Package Version: 0

3.1. Events and Signals


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

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

3.1.1. Gateway Controlled Voiceband Data

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

The RequestedEvent is encoded as,

GwVbdReqEvent = "gwvbd"

The ObservedEvent is encoded as,


  GwVbdObsEvent = GwVbdObsEventStart / GwVbdObsEventUpdate /
                  GwVbdObsEventStop / GwVbdObsEventFailure

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

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

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

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

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

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

* VBD Stop (stop)

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

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

* 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 signalling events [V1501] are used to coordinate the transition to and from VBD.

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

* Reason Code (rc=<ReasonCode>)

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


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

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

vbd/gwvbd(start, rc=Baudot)

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

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

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

vbd/gwvbd(update, rc=Edt)

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

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

Reason Codes applicable with the "stop" parameter:


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

The "MC" Reason Code indicates that the media type has changed from "audio" (to "image", "text", ...) or the "audio" media format has changed from a VBD codec (for a reason other than "PTSW"). For example, the gwvbd procedure may be initiated upon detecting CED. Subsequently, the Call Agent controlled T.38 procedure of the MGCP Fax (FXR) package [RFC5347] may be initiated upon detecting V.21 flags. Upon receipt of a "t38(start)" event, the Call Agent will instruct the Gateway to switch from VBD to T.38 through the use of a ModifyConnection command involving a LocalConnectionOption encoding method of "L:a:image/t38" and/or a RemoteConnectionDescriptor with an "image/t38" media description. This stops the gwvbd procedure. There is no specific interdependency between the VBD package and the FXR package (or any other package). The gwvbd procedure is stopped as a consequence of the media change, not as a direct consequence of the T.38 procedure being initiated. Note that in this situation the "t38(start)" event will be sent before the "gwvbd(stop)" event. The Call Agent MAY choose to infer that the gwvbd procedure has ended upon receiving the "t38(start)" event and disable the notification of the "gwvbd" event. Refer to the example call flow in section 8.2.

Reason Codes applicable with the "failure" parameter:


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

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

* Codec String (codec=<CodecString>)

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

http://www.iana.org/assignments/media-types

* Direction of Stimulus (dir=<Direction>)

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


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

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

3.1.1.1. Gateway Controlled Voiceband Data Examples

3.1.2. No Negotiated Procedure for Voiceband Data

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

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

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


   The RequestedEvent is encoded as,

     NopVbdReqEvent = "nopvbd"

   The ObservedEvent is encoded as,

     NopVbdObsEvent = NopVbdObsEventStart / NopVbdObsEventUpdate /
                      NopVbdObsEventStop / NopVbdObsEventFailure

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


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

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

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

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

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

* VBD Stop (stop)

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

* VBD Failure (failure)

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

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

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

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

3.1.2.1. No Negotiated Procedure for Voiceband Data Examples

4. General-Purpose Media Descriptor Parameter Package Definition

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

4.1. LocalConnectionOptions


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

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

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

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:

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

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:

However, it would not be clear if the "gpmd" parameter was to be applied to the first or the second occurrence of the codec. The problem is that codec ordering is important (i.e., codecs are listed in preferred order), and the above syntax does not provide a way to indicate if "parameterX" is preferred (i.e., associated with the first "codec1") or not (i.e., associated with the second "codec1"). In order to resolve this dilemma, the codec in the "gpmd" media format is followed by a colon and an <order>, where <order> is a number from one to N for occurrences of the same codec in the codec list i.e.:

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

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

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

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

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,