| Network | J.S. Stone |
| Internet-Draft | R.K. Kumar |
| Intended status: Informational | F.S.A. Andreasen |
| Expires: June 01, 2012 | Cisco Systems |
| December 2011 |
Media Gateway Control Protocol (MGCP) Voiceband Data Package (VBD) and General Purpose Media Descriptor Parameter Package
draft-stone-mgcp-vbd-10
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 01, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 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.
This document defines a mechanism that requires media stream integrity protection. The document specifies different alternatives for this but does not choose one of them as mandatory-to-implement. Consequently, the use of this specification is only suitable in environments that specify and use at least one of these alternative mechanisms. Please see the Security Considerations section for further details.
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.
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.
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].
This package is defined for (Voiceband Data) VBD. The package defines new events as detailed below.
Package Name: VBD
Package Version: 0
-------------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|--------|---------------------------------|-----|-----|------------|
| gwvbd | Gateway Controlled VBD | x | | |
| nopvbd | No Negotiated Procedure for VBD | x | | |
-------------------------------------------------------------------
The following events are defined in support of the above:
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.
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"
------------------------------------------------------
| CoordinationTechnique | Description |
|-----------------------|------------------------------|
| v152ptsw | V.152 Payload Type Switching |
| v150fw | V.150.1 SSE |
------------------------------------------------------
-------------------------------------------------------------------
| 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 |
-------------------------------------------------------------------
------------------------------------------------------
| ReasonCode | Description |
|------------|-----------------------------------------|
| SIL | Bidirectional silence |
| Voice | Voice signals |
| PTSW | Payload type switch as defined in V.152 |
| MC | Media change |
------------------------------------------------------
----------------------------------------------------
| ReasonCode | Description |
|------------|---------------------------------------|
| TO | Indicates that a timeout has occurred |
----------------------------------------------------
-----------------------------------------------
| 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). |
-----------------------------------------------
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.
GwVbdReqEvent = "gwvbd"
The ObservedEvent is encoded as,
The "start", "update", "stop" and "failure" ObservedEvent parameters are defined:
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] and [V152]. For an example involving Call Agent control, refer to the "MC" Reason Code. In both examples, the gwvbd procedure ends with the media change.
4) VBD Failure (failure)
The gwvbd procedure ended abnormally. Some kind of problem was encountered in the gwvbd procedure and the procedure ended.
When the "gwvbd" event is reported, exactly one of the "start", "update", "stop", or "failure" parameters MUST be present and MUST be the first parameter supplied.
The "rc", "codec", "coord" and "dir" ObservedEvent parameters are defined:
1) Coordination Technique (coord=<CoordinationTechnique>)
The technique used to coordinate the transition to and from VBD with the remote endpoint. The Coordination Techniques are summarized in the following table:
With the "v150fw" Coordination Technique, state signalling events [V1501] are used to coordinate the transition to and from VBD.
The list of Coordination Techniques may be extended to include values with meaning mutually understood between the Gateway and the Call Agent. Obviously, the use of extended values MUST be a provisionable option on the Gateway in order to ensure interoperability with the Call Agent.
2) Reason Code (rc=<ReasonCode>)
With the "start" and "update" parameter, the reason for triggering the switch/change to VBD. With the "stop" and "failure" parameter, the reason for triggering the switch from VBD. The Reason Codes in the following table, which are based on the ITU-T FAX/Textphone/Modem Tones Detection package [H2482], ITU-T V.150.1 Amendment 1 [V1501A1] and ITU-T V.152 [V152], may be used with the "start" and "update" parameter:
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:
Reason Codes applicable with the "failure" parameter:
3) Codec String (codec=<CodecString>)
With the "start" and "update" parameter, the codec parameter describes the MIME type associated with the switch/change to VBD (e.g., "audio/RED", "audio/PCMU", "audio/PCMA", "audio/G726-32", "audio/clearmode", ...). With the "stop" and "failure" parameter, the codec parameter describes the MIME type associated with the switch from VBD (e.g., "audio/G729", "image/t38", "text/t140", "audio/v150mr", ...). These strings should be full MIME types as listed in http://www.iana.org/assignments/media-types.
4) Direction of Stimulus (dir=<Direction>)
With the "start" and "update" parameter, the "dir" parameter describes the direction of the stimulus which resulted in the switch/change to VBD.
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)
O: vbd/gwvbd(update, rc=/ANSam, dir=IpToGstn)
O: vbd/gwvbd(stop)
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/gwvbd(stop, rc=MC, codec=image/t38)
O: vbd/gwvbd(failure, codec=audio/G729)
O: vbd/gwvbd(failure, rc=TO, codec=audio/G729)
The following examples illustrate the encoding of the "gwvbd(start)" event,
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"
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 "start", "update", "stop" and "failure" ObservedEvent parameters are defined:
1) VBD Start(start)
The nopvbd procedure was initiated. The Call Agent may have to issue further commands in order to ensure a successful VBD call (e.g., switch to another codec). At most one "nopvbd(stop)" or "nopvbd(failure)" event MAY be generated corresponding to each "nopvbd(start)" event. The Call Agent MAY need to infer that the nopvbd procedure has ended.
2) VBD Update (update)
The nopvbd procedure was updated. The "nopvbd(update)" event MUST only be generated after a "nopvbd(start)" event and before a "nopvbd(stop)" or "nopvbd(failure)" event.
3) VBD Stop (stop)
The nopvbd procedure ended and the Gateway did not detect any errors. Note that this does not necessarily imply a successful fax, modem, or text transmission. It merely indicates that the nopvbd procedure has ended and the procedure itself did not encounter any errors. Refer to the definition of the "stop" parameter from the "gwvbd" event in section 3.1.1 for additional information.
4) VBD Failure (failure)
The nopvbd procedure ended abnormally. Some kind of problem was encountered in the nopvbd procedure and the procedure ended.
Call Agents and Gateways MUST implement the "start" parameter and MAY implement the "update", "stop" and "failure" parameters. Call Agents MAY and Gateways MUST implement the "rc" parameter in conjunction with the "start" and "update" parameters. Call Agents and Gateways MAY implement the "rc" parameter in conjunction with the "stop" and "failure" parameters. A Call Agent MUST ignore all unknown ObservedEvent parameters including parameters which are defined as part of this specification and not implemented.
The definitions of the "rc", "codec" and "dir" ObservedEvent parameters are taken from the "gwvbd" event.
As with the "gwvbd" event, the same recommendations regarding interspersed text and speech apply.
O: vbd/nopvbd(start, rc=ANS)
O: vbd/nopvbd(start, rc=ANS, codec=audio/PCMU)
O: vbd/nopvbd(update, rc=/ANSam, dir=IpToGstn)
O: vbd/nopvbd(stop)
O: vbd/nopvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/nopvbd(stop, rc=MC, codec=image/t38)
O: vbd/nopvbd(failure, codec=audio/G729)
O: vbd/nopvbd(failure, rc=TO, codec=audio/G729)
The following examples illustrate the encoding of the "nopvbd(start)" event,
Package Name: GPMD
Package Version: 0
This package is defined for the General-Purpose Media Descriptor Parameter [V152]. The package defines a new LocalConnectionOption as detailed below.
------------------------------------------------------
| Symbol | Definition |
|--------|---------------------------------------------|
| gpmd | General-Purpose Media Descriptor Parameter |
------------------------------------------------------
The following LocalConnectionOption is defined in support of the above:
gpmd/gpmd:"<format> <parameter list>"
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY"
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
L: a:codec1;codec2;codec3, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY";
"codec3 parameterZ"
L: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
L:a:codec1;codec1, gpmd/gpmd:"codec1:2 parameterX"
A: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
or,
A: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes"
m=audio 12345 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yes
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"
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
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
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:
If it is possible for the same codec to be requested with and without the "gpmd" parameter, the following could result:
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:
If we combine V.152 and redundancy [RFC2198], an example LocalConnectionOption might look as follows. In the example below, G.729 is an audio codec and G.711u is a VBD codec with a redundancy level of one:
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"
L:a:codec1;codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2"
L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes",
fmtp:"RED PCMU:2/PCMU:2"
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
L: a:G729;RED;RED;PCMU, fmtp:"RED PCMU/PCMU/PCMU",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"
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
L: a:RED;G729;RED;PCMU, fmtp:"RED G729/G729/G729",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"
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
The MGCP Media Format Parameter (FM) package [RFC3660] in conjunction with the standard audio MIME subtype "RED" may be used by the Call Agent to authorize the negotiation of redundancy [RFC2198], to identify the levels of redundancy and the media format associated with each redundancy level. An example of this was demonstrated in section 4.
The FM package states that the "fmtp" LocalConnectionOption MUST be returned when auditing capabilities. Applying this to VBD and redundancy might result in:
A 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:PCMU;parityfec
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
L: a:G729;RED;PCMU;parityfec, gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/parityfec"
The corresponding media description might look like:
v=0
c=IN IP4 192.0.2.0
m=audio 49170 RTP/AVP 18 96 97 98
a=rtpmap:96 RED/8000
a=fmtp:96 97/98
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
a=rtpmap:98 parityfec/8000
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"
A Call Agent may authorize the negotiation of forward error correction (FEC) [RFC5109] with the standard audio MIME subtype "parityfec",
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
Gateway = "gw[" mimeType 0*("|" mimeType) "]"
mimeType = mimeMediaType "/" mimeSubType
; mimeMediaType and mimeSubType from,
; http://www.iana.org/assignments/media-types/
- 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]
- involving "audio/t38" (e.g., T.38oRTP),
L: a:G729;t38, fxr/fx:gw[audio/t38]
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
A: fxr/fx:t38;t38-loose;gw[audio/t38|image/t38];gw;off
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]
The MGCP Fax (FXR) package [RFC5347] is used by a Call Agent to authorize fax handling including Call Agent controlled T.38 and Gateway procedures such as V.152. With the FXR package, VBD falls into one of two categories: "special fax handling" as part of the Gateway procedure (resulting in the "gwfax" event); or "no special fax handling" as part of the Gateway and Off procedures (resulting in the "nopfax" event). In order for a VBD procedure to fall into the "special fax handling" category, support for it MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor.
A Gateway controlled VBD procedure such as V.152 MUST fall into the category of Gateway controlled mode involving "special fax handling". The resulting "gwfax" event is what informs the Call Agent to refrain from issuing media handling instructions which could otherwise have a negative impact on the Gateway procedure.
Consider the following example (with shorthand SDP notation):
A Call Agent can express a preference for a Gateway procedure involving "special fax handling" over a T.38 procedure (strict or loose). For example,
L: fxr/fx:gw;t38
and,
L: fxr/fx:gw;t38-loose
However, with the existing syntax of the FXR package, a Call Agent cannot express a preference for one Gateway procedure over another, each with possibly different preferences relative to a T.38 procedure.
The FXR package allows a Gateway to implement additional fax handling parameters. We define just such a parameter by qualifying the existing "gw" parameter with a list of one or more MIME types,
The "fx" LocalConnectionOption MAY now involve multiple instances of the "gw" parameter, each with a different list of MIME types. In order to authorize "no special fax handling", the Call Agent MUST include: the "gw" parameter without a MIME type; or the "off" parameter. The instance of the "gw" parameter without a MIME type should appear as the last instance of the "gw" parameter. In the following example,
L: a:G729;PCMU, fxr/fx:gw[image/t38];gw
the Call Agent authorizes the use of and expresses a preference for,
1. Gateway controlled image/t38 (e.g., T.38oUDPTL)
2. Any other Gateway procedure with "special fax handling"
3. No special fax handling (this is a function of the "fxr/fx:gw" parameter as defined in section 2.1 of the MGCP Fax (FXR) package [RFC5347])
If present, the "off" parameter should appear as the last parameter. In the following example,
L: a:G729;PCMU;t38, fxr/fx:gw[audio/t38];off
the Call Agent authorizes the use of and expresses a preference for,
1. Gateway controlled audio/t38 (e.g., T.38oRTP)
2. No special fax handling
We can express relative preferences for different Gateway controlled fax handling procedures, not only with respect to one another, but with respect to T.38 procedures. Consider the following preferential list of fax handling procedures,
1. Gateway controlled audio/t38 (e.g., T.38oRTP)
2. Gateway controlled image/t38 (e.g., T.38oUDPTL)
3. Call Agent Controlled image/t38
4. Gateway controlled VBD with Redundancy (e.g., PCMU, V.152 and RFC 2198)
5. Gateway controlled VBD without Redundancy (e.g., PCMU and V.152)
6. Any other Gateway procedure with "special fax handling"
7. No special fax handling (this is a function of the "fxr/fx:gw" parameter as defined in section 2.1 of the MGCP Fax (FXR) package [RFC5347])
This would be expressed as,
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].
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.
------------------------------------------------------------------
| #| 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 | | |
------------------------------------------------------------------
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
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
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
M: sendrecv
R: vbd/gwvbd, vbd/nopvbd
X: 20
Q: process, loop
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
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
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
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
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
X: 20
NTFY 1501 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=PTSW, codec=audio/G729)
X: 1
200 1501 OK
In this example, both sides support Gateway controlled VBD using V.152 with redundancy. We assume the originating and terminating Call Agents communicate via the Session Initiation Protocol (SIP) [RFC3261]:
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:
The Gateway acknowledges the command and includes SDP with codec information as well as V.152 and redundancy information:
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:
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:
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:
Step 8:
The Gateway acknowledges the command. At this point, a call is established using G.729 encoding, and if a VBD call is detected, the Gateway controlled VBD procedure will be initiated.
Step 9-10:
A modem call now occurs. The terminating Gateway detects a T.30 CED tone (a.k.a. V.25 ANS) in the GSTN to IP direction and begins transmitting RTP packets with the negotiated redundant VBD payload type (96).
The "gwvbd(start)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
200 2500 OK
Step 12:
Upon receiving a RTP packet with the redundant VBD payload type (96), the originating Gateway begins transmitting RTP packets with the redundant VBD payload type.
The "gwvbd(start)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
200 1500 OK
Step 14 - 15:
The modem call ends. The terminating Gateway detects bi-directional silence and begins transmitting RTP packets with the negotiated audio payload type (18).
The "gwvbd(stop)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
200 2501 OK
Step 17:
Upon receiving a RTP packet with the audio payload type (18), the originating Gateway begins transmitting RTP packets with the audio payload type.
The "gwvbd(stop)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
------------------------------------------------------------------
| #| 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 | | |
------------------------------------------------------------------
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
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
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
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
a=pmft: T38
m=audio 1296 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cdsc: 4 image udptl t38
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
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
200 2500 OK
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
200 1500 OK
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: fxr/t38(start)
X: 20
200 2500 OK
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
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
MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
R: fxr/t38
X: 2
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38
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
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
In this example, both sides support Gateway controlled VBD using V.152 with Redundancy and Call Agent controlled T.38. We assume the originating and terminating Call Agent communicate via the Session Initiation Protocol (SIP) [RFC3261]:
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:
The Gateway acknowledges the command and includes SDP with codec information as well as capability, V.152 and redundancy information:
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 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:
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:
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:
Step 8:
The Gateway acknowledges the command. At this point, a call is established using G.729 encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated. If a modem or text call is detected, the V.152 VBD procedure will be initiated.
Step 9-10:
The terminating Gateway detects the T.30 CED tone (a.k.a. V.25 ANS). Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 14, where the V.21 fax preamble is detected. The terminating Gateway begins transmitting RTP packets with the negotiated redundant VBD payload type (96).
The "gwvbd(start)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
Upon receiving a RTP packet with the redundant VBD payload type (96), the originating Gateway begins transmitting RTP packets with the redundant VBD payload type.
The "gwvbd(start)" event occurs and is notified to the Call Agent:
The Call Agent acknowledges the Notify command:
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:
The Call Agent acknowledges the Notify command:
The Call Agent then instructs the terminating Gateway to change to using the "image/t38" MIME type instead:
Step 18:
The terminating Gateway sends back a success response with its SDP which also includes the "image/t38" media description:
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:
The originating Gateway changes to T.38 and sends back a success response with updated SDP:
Step 22:
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).
Step 23:
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating Gateway:
This document defines two new packages, both of which have security considerations in two areas:
From an MGCP signaling security point of view, the MGCP VBD and GPMD packages define extensions to the basic MGCP signaling specification in accordance with the procedures specified in MGCP [RFC3435] and hence the MGCP signaling security considerations and recommendations provided in MGCP [RFC3435] Section 5 (namely use of IPsec) apply here as well. Lack of MGCP signaling integrity protection can in general be detrimental to any use of MGCP, and the two packages defined here do not change that. From a confidentiality point of view, the VBD package is not believed to convey any vulnerable or privacy-sensitive information. The GPMD package is slightly different inasmuch as it does not define any specific parameters that are believed to require confidentiality, however it is a generic parameter that can carry any codec parameter information, and hence it is possible that confidential information is conveyed through this parameter. If confidentiality of any such potential information is a concern, confidentiality protection of the MGCP signaling MUST be provided as well. It should be noted, that [RFC5406] Section 8 provides considerations for specifying the use of IPsec that are above and beyond those provided in [RFC3435], however given that IPsec use for MGCP applies to all of MGCP, and not just the MGCP VBD and GPMD packages, we do not specify such additional detail here.
From a media stream security point of view, the MGCP VBD and GPMD packages again define extensions that rely on the general use of media streams defined in MGCP [RFC3435] and hence the MGCP media stream security considerations and recommendations provided in MGCP [RFC3435] Section 5.1 apply here as well. Lack of media stream security can in general be detrimental to any media stream established via MGCP, and the two packages defined here do not change that. Confidentiality concerns apply as for any other media stream. Integrity concerns are furter compounded by the GPMD package's use of payload type switching, state signaling events and media stream in-band triggers to drive overall voiceband data operation: Integrity protection with replay protection MUST be used to counter these threats.
Ideally, there would be a single mandatory-to-implement media stream security mechanism to provide this integrity protection, and in theory there is since MGCP [RFC3435] defines a media stream security mechanism. However, the standard MGCP media stream security mechanism defined in [RFC3435] on relies on the encryption key ("k=') field defined in the original SDP specification [RFC2327], the use of which is no longer recommended in the updated SDP specification [RFC4566]. In practice, this mechanism has also seen very limited implementation and hence there is not much value in relying on it. Still, the integrity protection requirement remains, and there are several different ways this can be achieved:
Package Title Name Version
------------- ---- -------
Voiceband Data VBD 0
General-Purpose Media Descriptor Parameter GPMD 0
The IANA is hereby requested to register the following MGCP packages,
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.
Changes in 01:
* Number of formatting corrections (mainly to remove extra blank lines)
* Updated a number of internal section references (these were off by one due to addition of new section 2 Terminology as part of initial version 00 submission)
* In section 3.1.2, corrected Start VBD to VBD Start
* In section 4.1.1, added text to clarify that the first instance is assumed in the absence of <order>
Changes in 02:
* Fix errors, warnings and comments reported by ID nits
Changes in 03:
* Editorial corrections throughout the document
Changes in 04:
* No changes
Changes in 05:
* Make reference to the MGCP Fax RFC 5347, address expert review comments and add clarifications where needed.
Changes in 06:
* Editorial updates to address feedback from expert reviewer (Flemming).
Changes in 07:
* No changes.
Changes in 08:
* Address multiple last call comments from various directorates.
Changes in 09:
* Rewrote security considerations to resolve IESG review comments.
Changes in 10:
* Updated security considerations and added applicability statement.
| [RFC2327] | Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC3711] | Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. |
| [RFC5406] | Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009. |
| [T38] | International Telecommunications Union - Telecommunication Standardization Sector , "ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", ", April 2004. |