Network S. Sharma, Ed.
Internet-Draft CableLabs
Intended status: Standards Track J. Stone
Expires: December 8, 2007 R. Kumar
Cisco Systems
June 6, 2007
Media Gateway Control Protocol Voiceband Data Package and General
Purpose Media Descriptor Parameter Package
draft-stone-mgcp-vbd-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 8, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Sharma, Ed., et al. Expires December 8, 2007 [Page 1]
Internet-Draft MGCP VBD package June 2007
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Voiceband Data Package Definition . . . . . . . . . . . . . . 6
3.1. Events and Signals . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Gateway Controlled Voiceband Data . . . . . . . . . . 6
3.1.2. No Negotiated Procedure for Voiceband Data . . . . . . 14
4. General-Purpose Media Descriptor Parameter Package
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. LocalConnectionOptions . . . . . . . . . . . . . . . . . . 17
4.1.1. General-Purpose Media Descriptor Parameter . . . . . . 17
5. Use of Media Format Parameter Package with VBD and
Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Use of Media Format Parameter Package with VBD and FEC . . . . 25
7. Use of Fax Package with VBD . . . . . . . . . . . . . . . . . 27
8. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Modem Call with Gateway Controlled VBD . . . . . . . . . . 32
8.2. Fax Call with Gateway Controlled VBD and Call Agent
Controlled T.38 . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
12. Summary of Changes . . . . . . . . . . . . . . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Normative References . . . . . . . . . . . . . . . . . . . 52
13.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55
Sharma, Ed., et al. Expires December 8, 2007 [Page 2]
Internet-Draft MGCP VBD package June 2007
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)
[RFC2733].
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 GSTN network MAY result in 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 2833 [RFC2833] 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 2833 to convey fax and modem events and tones is
negotiated, the use of RFC 2833 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-
Sharma, Ed., et al. Expires December 8, 2007 [Page 3]
Internet-Draft MGCP VBD package June 2007
Purpose Media Descriptor Parameter is "general" in nature and may be
used in applications other than VBD.
The Media Format Parameter (FM) package [FMPKG] 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
[FAXPKG]. 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.
Sharma, Ed., et al. Expires December 8, 2007 [Page 4]
Internet-Draft MGCP VBD package June 2007
2. 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].
Sharma, Ed., et al. Expires December 8, 2007 [Page 5]
Internet-Draft MGCP VBD package June 2007
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
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 | | |
-------------------------------------------------------------------
The definitions of the individual events are provided in the
following subsections.
3.1.1. Gateway Controlled Voiceband Data
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 [RFC2234]. The syntax makes use of the core rules defined
in [RFC2234], Section 6.1, which are not included here. Furthermore,
the syntax follows the case-sensitivity rules of [RFC2234], 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
Sharma, Ed., et al. Expires December 8, 2007 [Page 6]
Internet-Draft MGCP VBD package June 2007
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 7]
Internet-Draft MGCP VBD package June 2007
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 8]
Internet-Draft MGCP VBD package June 2007
[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.
* 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 [H1501A1]
and ITU-T V.152 [V152], may be used with the "start" and "update"
parameter:
Sharma, Ed., et al. Expires December 8, 2007 [Page 9]
Internet-Draft MGCP VBD package June 2007
-------------------------------------------------------------------
| 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)
Sharma, Ed., et al. Expires December 8, 2007 [Page 10]
Internet-Draft MGCP VBD package June 2007
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 [FAXPKG] may be initiated upon detecting V.21
Sharma, Ed., et al. Expires December 8, 2007 [Page 11]
Internet-Draft MGCP VBD package June 2007
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.
* Codec String (codec=<CodecString>)
With the "start" and "update" parameter, 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 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 direction of the
stimulus which resulted in the switch/change to VBD.
Sharma, Ed., et al. Expires December 8, 2007 [Page 12]
Internet-Draft MGCP VBD package June 2007
-----------------------------------------------
| Direction | Description |
|-----------|-----------------------------------|
| GstnToIp | Stimulus detected from GSTN to IP |
| IpToGstn | Stimulus detected from IP to GSTN |
-----------------------------------------------
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
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)
Sharma, Ed., et al. Expires December 8, 2007 [Page 13]
Internet-Draft MGCP VBD package June 2007
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)
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.
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] ")"
The following ABNF notation is common with the "gwvbd" ObservedEvent.
Sharma, Ed., et al. Expires December 8, 2007 [Page 14]
Internet-Draft MGCP VBD package June 2007
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 below.
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 15]
Internet-Draft MGCP VBD package June 2007
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
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)
Sharma, Ed., et al. Expires December 8, 2007 [Page 16]
Internet-Draft MGCP VBD package June 2007
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.
Package Name: GPMD
Package Version: 0
4.1. LocalConnectionOptions
The following LocalConnectionOption is defined in support of the
above:
------------------------------------------------------
| Symbol | Definition |
|--------|---------------------------------------------|
| gpmd | General-Purpose Media Descriptor Parameter |
------------------------------------------------------
The definition of the LocalConnectionOption is provided in the
following subsection.
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,
gpmd/gpmd:"<format> <parameter list>"
Sharma, Ed., et al. Expires December 8, 2007 [Page 17]
Internet-Draft MGCP VBD package June 2007
For simplicity, we will use the terms "codec" and "media format"
interchangeably in the following. Multiple media formats may be
indicated by either repeating the "gpmd" LocalConnectionOption
multiple times, such as:
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY"
or alternatively by having a single "gpmd" keyword followed by a
colon, and a semi-colon separated list of quoted strings for each
General-Purpose Media Descriptor Parameter, as in:
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
The two formats may be mixed,
L: a:codec1;codec2;codec3, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY";
"codec3 parameterZ"
The carriage returns above are included for formatting reasons only
and are not permissible in a real implementation. This holds true
for all of the examples in this document.
If it is possible for the same codec to be requested with and without
the "gpmd" parameter, the following could result:
L: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
However, it would not be clear if the "gpmd" parameter was to be
applied to the first or the second occurrence of the codec. The
problem with that 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
Sharma, Ed., et al. Expires December 8, 2007 [Page 18]
Internet-Draft MGCP VBD package June 2007
"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.:
L:a:codec1;codec1, gpmd/gpmd:"codec1:2 parameterX"
indicates that "parameterX" is associated with the second instance of
"codec1" in the "a:codec1;codec1" list. If an invalid instance
number is supplied (e.g., instance 3 where there are only two
instances), then error code 524 - inconsistency in local connection
options will be returned. In the absence of an <order>, the first
instance is assumed.
Pre-pending "gpmd" with the string "o-" (i.e., "o-gpmd") indicates
that the parameter is optional. In that case, the Gateway may decide
not to use the "gpmd" parameter specified, or only use it in part.
If the "gpmd" LocalConnectionOption parameter is not optional (i.e.,
does not have "o-" in front of it), and the LocalConnectionOption
parameter value is either not recognized or not supported, then the
associated codec is considered "not supported".
When auditing capabilities, the "gpmd" LocalConnectionOption
parameter MUST be returned with a semi-colon separated list of
supported formats and/or multiple independent "gpmd" parameters as
in:
A: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"
or,
A: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"
One example uses the General-Purpose Media Descriptor Parameter
LocalConnectionOption in conjunction with Gateway controlled
Voiceband Data (or simply VBD) using payload type switching [V152].
In the context of VBD, the <format> must be an RTP/AVP payload type.
The <parameter list> is a semicolon-separated list of
"parameter=value" pairs,
Sharma, Ed., et al. Expires December 8, 2007 [Page 19]
Internet-Draft MGCP VBD package June 2007
L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"
In the example below, G.729 is an audio codec and G.711u is a VBD
codec,
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes"
The corresponding media description in the SDP as part of the
connection request acknowledgment might look like:
m=audio 12345 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yes
If a request is made to audit the capabilities of an endpoint, and
the endpoint supports G.711u as both an audio and VBD codec, then the
"gpmd" LocalConnectionOption parameter might look like:
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes"
Given that some parameters, such as e.g., silence suppression, are
only compatible with G.711u as an audio codec, then the Gateway MUST
return different capability sets corresponding to audio and VBD.
If we combine V.152 and redundancy [RFC2198], an example
LocalConnectionOption might look as follows. In the example below,
G.729 is an audio codec and G.711u is a VBD codec with a redundancy
level of one:
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
Sharma, Ed., et al. Expires December 8, 2007 [Page 20]
Internet-Draft MGCP VBD package June 2007
The corresponding media description in the SDP as part of the
connection request acknowledgment might look like:
m=audio 12345 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
Refer to section 5 for more examples involving V.152 and redundancy.
Sharma, Ed., et al. Expires December 8, 2007 [Page 21]
Internet-Draft MGCP VBD package June 2007
5. Use of Media Format Parameter Package with VBD and Redundancy
The MGCP Media Format Parameter (FM) package [FMPKG] in conjunction
with the standard audio MIME subtype "RED" may be used by the Call
Agent to authorize the negotiation of redundancy [RFC2198], to
identify the levels of redundancy and the media format associated
with each redundancy level. An example of this was demonstrated in
section 4.
The FM package states that the "fmtp" LocalConnectionOption MUST be
returned when auditing capabilities. Applying this to VBD and
redundancy might result in:
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:RED;PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/PCMU"
The FM package defines "instance syntax" in which,
L:a:codec1;codec1, fmtp:"codec1:2 formatX"
indicates that "formatX" is associated with the second instance of
"codec1" in the "a:codec1;codec1" list. The examples in the FM
package are limited to the use of the instance syntax in conjunction
with the media format. We propose the use of the instance syntax in
conjunction with the media format parameters,
L:a:codec1;codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2"
Let's build on the example of section 4. In the example below, G.729
is an audio codec, G.711u is both an audio codec and a VBD codec with
a redundancy level of one:
L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes",
fmtp:"RED PCMU:2/PCMU:2"
Sharma, Ed., et al. Expires December 8, 2007 [Page 22]
Internet-Draft MGCP VBD package June 2007
The corresponding media description in the SDP as part of the
connection request acknowledgment might look like:
m=audio 12345 RTP/AVP 18 0 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
Note that the relative preference of the LocalConnectionOption
encoding methods is preserved in the "audio" media formats (i.e.,
payload types) as part of the media description. In this example,
this reflects a preference for V.152 with redundancy versus without.
No preference is inferred from the relative order of the different
LocalConnectionOptions, namely "a", "gpmd/gpmd" and "fmtp".
A Call Agent can authorize the negotiation of audio codecs and VBD
codecs involving different levels of redundancy. In the example
below, G.711u is a VBD codec with a redundancy level of two
(preferred) or one:
L: a:G729;RED;RED;PCMU, fmtp:"RED PCMU/PCMU/PCMU",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"
The corresponding media description in the SDP as part of the
connection request acknowledgment might look like:
m=audio 12345 RTP/AVP 18 96 97 98
a=rtpmap:96 RED/8000
a=fmtp:96 98/98/98
a=rtpmap:97 RED/8000
a=fmtp:97 98/98
a=rtpmap:98 PCMU/8000
a=gpmd:98 vbd=yes
Redundancy can be applied to both audio codecs and VBD codecs. In
the example below, G.729 is an audio codec with a redundancy level of
two and G.711u is a VBD codec with a redundancy level of one:
Sharma, Ed., et al. Expires December 8, 2007 [Page 23]
Internet-Draft MGCP VBD package June 2007
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 24]
Internet-Draft MGCP VBD package June 2007
6. Use of Media Format Parameter Package with VBD and FEC
A Call Agent may authorize the negotiation of forward error
correction (FEC) [RFC2733] 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 224.2.17.12
m=audio 49170 RTP/AVP 0 96
a=rtpmap:96 parityfec/8000
a=fmtp:96 49172 IN IP4 224.2.17.12
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 [FMPKG] in conjunction with the standard audio
MIME subtype "RED",
L: a:G729;RED;PCMU;parityfec, gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/parityfec"
The corresponding media description might look like:
v=0
c=IN IP4 224.2.17.12
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,
Sharma, Ed., et al. Expires December 8, 2007 [Page 25]
Internet-Draft MGCP VBD package June 2007
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"
Sharma, Ed., et al. Expires December 8, 2007 [Page 26]
Internet-Draft MGCP VBD package June 2007
7. Use of Fax Package with VBD
The MGCP Fax (FXR) package [FAXPKG] is used by a Call Agent to
authorize fax handling including Call Agent controlled T.38 and
Gateway procedures such as V.152. With the FXR package, VBD falls
into one of two categories: "special fax handling" as part of the
Gateway procedure (resulting in the "gwfax" event); or "no special
fax handling" as part of the Gateway and Off procedures (resulting in
the "nopfax" event). In order for a VBD procedure to fall into the
"special fax handling" category, support for it MUST be negotiated
with the other side by passing and recognizing relevant parameters
via the LocalConnectionDescriptor and RemoteConnectionDescriptor.
A Gateway controlled VBD procedure such as V.152 MUST fall into the
category of Gateway controlled mode involving "special fax handling".
The resulting "gwfax" event is what informs the Call Agent to refrain
from issuing media handling instructions which could otherwise have a
negative impact on the Gateway procedure.
Consider the following example (with shorthand SDP notation):
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 1
M: sendrecv
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:t38;gw
X: 1
R: fxr/t38, fxr/gwfax, fxr/nopfax
v=0
c=IN IP4 128.96.41.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
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 27]
Internet-Draft MGCP VBD package June 2007
will not initiate the T.38 strict fax procedure, "t38", upon
detecting fax stimulus (i.e., CNG, V.21 flags, ...). However, the
two endpoints did successfully negotiate a Gateway controlled VBD
procedure (e.g., V.152), therefore, Gateway controlled mode involving
"special fax handling" is used. The "gwfax(start)" event will be
generated upon detecting VBD (including fax) stimulus.
A Call Agent can express a preference for a Gateway procedure
involving "special fax handling" over a T.38 procedure (strict or
loose). For example,
L: fxr/fx:gw;t38
and,
L: fxr/fx:gw;t38-loose
However, with the existing syntax of the FXR package, a Call Agent
cannot express a preference for one Gateway procedure over another,
each with possibly different preferences relative to a T.38
procedure.
The FXR package allows a Gateway to implement additional fax handling
parameters. We define just such a parameter by qualifying the
existing "gw" parameter with a list of one or more MIME types,
Gateway = "gw[" mimeType 0*("|" mimeType) "]"
mimeType = mimeMediaType "/" mimeSubType
; mimeMediaType and mimeSubType from,
; http://www.iana.org/assignments/media-types/
By qualifying the "gw" parameter with a list of MIME types, we narrow
the scope of the Gateway procedure. Consider the following examples
in which the Call Agent authorizes the use of a Gateway controlled
fax handling procedure:
Sharma, Ed., et al. Expires December 8, 2007 [Page 28]
Internet-Draft MGCP VBD package June 2007
- involving "image/t38" (e.g., T.38oUDPTL, T.38oTCP),
L: a:G729, fxr/fx:gw[image/t38]
- involving VBD (e.g., PCMU and V.152),
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/PCMU]
- involving VBD with redundancy (e.g., PCMU, V.152 and RFC 2198),
L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU", gpmd/gpmd:"PCMU vbd=yes",
fxr/fx:gw[audio/RED|audio/PCMU]
Only "special fax handling" involving one of the specified MIME types
is authorized. Support for "special fax handling" involving one of
the specified MIME types MUST be negotiated or this "instance" of the
Gateway procedure is not initiated. Consider the following example
in which the Call Agent authorizes the use of a Gateway controlled
fax handling procedure:
- involving "audio/t38" (e.g., T.38oRTP),
L: a:G729;t38, fxr/fx:gw[audio/t38]
In this example, the call will fail if the Gateway fails to negotiate
"audio/t38".
The "fx" LocalConnectionOption MAY now involve multiple instances of
the "gw" parameter, each with a different list of MIME types. In
order to authorize "no special fax handling", the Call Agent MUST
include: the "gw" parameter without a MIME type; or the "off"
parameter. The instance of the "gw" parameter without a MIME type
should appear as the last instance of the "gw" parameter. In the
following example,
L: a:G729;PCMU, fxr/fx:gw[image/t38];gw
the Call Agent authorizes the use of and expresses a preference for,
1. Gateway controlled image/t38 (e.g., T.38oUDPTL)
2. Any other Gateway procedure with "special fax handling"
Sharma, Ed., et al. Expires December 8, 2007 [Page 29]
Internet-Draft MGCP VBD package June 2007
3. No special fax handling
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 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
Sharma, Ed., et al. Expires December 8, 2007 [Page 30]
Internet-Draft MGCP VBD package June 2007
following example:
A: fxr/fx:t38;t38-loose;gw[audio/t38|image/t38];gw;off
Support for the bracketed "gw" parameter MAY be spread across
multiple capability lines,
A: a:RED;PCMU, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/PCMU",
fxr/fx:gw[audio/RED|audio/PCMU]
A: a:t38, fxr/fx:gw[audio/t38]
A: a:image/t38, fxr/fx:t38;t38-loose;gw[image/t38]
A Call Agent SHOULD only attempt to leverage the bracketed form of
the "gw" parameter in conjunction with an endpoint which indicates
support for the bracketed syntax as part of the 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].
Sharma, Ed., et al. Expires December 8, 2007 [Page 31]
Internet-Draft MGCP VBD package June 2007
8. Call Flow Examples
In this section, we provide two example call flows. 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.
8.1. Modem Call with Gateway Controlled VBD
In this example, both sides support Gateway controlled VBD using
V.152 with redundancy. We assume the originating and terminating
Call Agent communicate via the Session Initiation Protocol (SIP)
[RFC3261]:
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | |<- ANS/T.30 CED|
|10| | | <- NTFY(gwvbd start)|
|11| | | 200|-> |
|12|NTFY(gwvbd start) -> | | |
|13| <-|200 | | |
|--|---------------|---------------|---------------|---------------|
|14| | | | (modem ends) |
|15| | | <- NTFY(gwvbd stop) |
|16| | | 200|-> |
|17|NTFY(gwvbd stop) -> | | |
|18| <-|200 | | |
------------------------------------------------------------------
Step 1:
The Call Agent issues a CreateConnection command to the Gateway
instructing it to use G.729 media encoding and to notify it of the
"gwvbd" and "nopvbd" events. The Call Agent authorizes the
negotiation of G.711u as a VBD codec with a redundancy level of one:
Sharma, Ed., et al. Expires December 8, 2007 [Page 32]
Internet-Draft MGCP VBD package June 2007
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
M: recvonly
R: vbd/gwvbd, vbd/nopvbd
X: 1
Q: process, loop
Step 2:
The Gateway acknowledges the command and includes SDP with codec
information as well as V.152 and redundancy information:
200 1000 OK
I:1
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 33]
Internet-Draft MGCP VBD package June 2007
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 128.96.41.1
s=-
c=IN IP4 128.96.41.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 128.96.41.2
s=-
c=IN IP4 128.96.41.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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 34]
Internet-Draft MGCP VBD package June 2007
The terminating Call Agent sends back a SIP 200 OK response to the
originating Call Agent, which in turn sends a SIP ACK (not shown).
Step 7:
The originating Call Agent in turns sends a ModifyConnection command
to the originating Gateway:
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=audio 1296 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
Since the RemoteConnectionDescriptor indicates the other side
supports V.152 and redundancy, the Gateway will in fact be able to
use the Gateway controlled VBD procedure with redundancy. Had there
not been any support for V.152 in the RemoteConnectionDescriptor,
then this command would still have succeeded, however there would be
no negotiated procedure for VBD handling.
Step 8:
The Gateway acknowledges the command. At this point, a call is
established using G.729 encoding, and if a VBD call is detected, the
Gateway controlled VBD procedure will be initiated.
Step 9-10:
A modem call now occurs. The terminating Gateway detects a T.30 CED
tone (a.k.a. V.25 ANS) in the GSTN to IP direction and begins
transmitting RTP packets with the negotiated redundant VBD payload
type (96).
The "gwvbd(start)" event occurs and is notified to the Call Agent:
Sharma, Ed., et al. Expires December 8, 2007 [Page 35]
Internet-Draft MGCP VBD package June 2007
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20
Step 11:
The Call Agent acknowledges the Notify command:
200 2500 OK
Step 12:
Upon receiving a RTP packet with the redundant VBD payload type (96),
the originating Gateway begins transmitting RTP packets with the
redundant VBD payload type.
The "gwvbd(start)" event occurs and is notified to the Call Agent:
NTFY 1500 ds/ds1-1/1@gw-0.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
Step 13:
The Call Agent acknowledges the Notify command:
200 1500 OK
Step 14 - 15:
The modem call ends. The terminating Gateway detects bi-directional
silence and begins transmitting RTP packets with the negotiated audio
payload type (18).
The "gwvbd(stop)" event occurs and is notified to the Call Agent:
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
X: 20
Sharma, Ed., et al. Expires December 8, 2007 [Page 36]
Internet-Draft MGCP VBD package June 2007
Step 16:
The Call Agent acknowledges the Notify command:
200 2501 OK
Step 17:
Upon receiving a RTP packet with the audio payload type (18), the
originating Gateway begins transmitting RTP packets with the audio
payload type.
The "gwvbd(stop)" event occurs and is notified to the Call Agent:
NTFY 1501 ds/ds1-1/1@gw-0.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.
8.2. Fax Call with Gateway Controlled VBD and Call Agent Controlled
T.38
In this example, both sides support Gateway controlled VBD using
V.152 with Redundancy and Call Agent controlled T.38. We assume the
originating and terminating Call Agent communicate via the Session
Initiation Protocol (SIP) [RFC3261]:
Sharma, Ed., et al. Expires December 8, 2007 [Page 37]
Internet-Draft MGCP VBD package June 2007
------------------------------------------------------------------
| #| 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| | | | (fax ends) |
|26| | | <-|NTFY(t38 stop) |
|27| | | 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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 38]
Internet-Draft MGCP VBD package June 2007
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 128.96.41.1
s=-
c=IN IP4 128.96.41.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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 39]
Internet-Draft MGCP VBD package June 2007
The terminating Call Agent issues a CreateConnection command to the
terminating Gateway instructing it to use G.729 media encoding and to
use either the strict T.38 procedure or the Gateway procedure.
Consequently, the Call Agent requests notification of the "t38",
"gwfax", "gwvbd" and "nopvbd" events. Again, the Call Agent
authorizes the negotiation of G.711u as a VBD codec with a redundancy
level of one:
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU",
fxr/fx:t38;gw
M: sendrecv
R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd
X: 20
Q: process, loop
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 40]
Internet-Draft MGCP VBD package June 2007
200 2000 OK
I:2
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
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 turns sends a ModifyConnection command
to the originating Gateway:
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
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
Sharma, Ed., et al. Expires December 8, 2007 [Page 41]
Internet-Draft MGCP VBD package June 2007
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cdsc: 4 image udptl t38
The ModifyConnection command does not repeat the
LocalConnectionOptions sent previously. As far as fax handling is
concerned, the Gateway therefore attempts to continue using the
current fax handling procedure, i.e. strict Call Agent controlled
T.38. Since the capability information indicates the other side
supports T.38, the Gateway will in fact be able to use the strict
Call Agent controlled T.38 procedure. Since the
RemoteConnectionDescriptor indicates the other side supports V.152
and redundancy, the Gateway will in fact be able to use the V.152 VBD
procedure with redundancy.
Step 8:
The Gateway acknowledges the command. At this point, a call is
established using G.729 encoding, and if a fax call is detected, the
Call Agent controlled T.38 procedure will be initiated. If a modem
or text call is detected, the V.152 VBD procedure will be initiated.
Step 9-10:
The terminating Gateway detects the T.30 CED tone (a.k.a. V.25 ANS).
Since both fax and modem calls can start with this sequence, it is
not possible to determine that this is a fax call until step 14,
where the V.21 fax preamble is detected. The terminating Gateway
begins transmitting RTP packets with the negotiated redundant VBD
payload type (96).
The "gwvbd(start)" event occurs and is notified to the Call Agent:
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20
Step 11:
The Call Agent acknowledges the Notify command:
200 2500 OK
Sharma, Ed., et al. Expires December 8, 2007 [Page 42]
Internet-Draft MGCP VBD package June 2007
Step 12:
Upon receiving a RTP packet with the redundant VBD payload type (96),
the originating Gateway begins transmitting RTP packets with the
redundant VBD payload type.
The "gwvbd(start)" event occurs and is notified to the Call Agent:
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1
Step 13:
The Call Agent acknowledges the Notify command:
200 1500 OK
Step 14 - 15:
The terminating Gateway detects the V.21 fax preamble.
The terminating Gateway is using the Call Agent controlled T.38
strict procedure for fax calls, so the "t38(start)" event occurs:
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:
Sharma, Ed., et al. Expires December 8, 2007 [Page 43]
Internet-Draft MGCP VBD package June 2007
The Call Agent then instructs the terminating Gateway to change to
using the "image/t38" MIME type instead:
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
L: a:image/t38
R: fxr/t38
X: 21
Note that the Call Agent is no longer requesting notification of the
"gwvbd" event.
Step 18:
The terminating Gateway sends back a success response with its SDP
which also includes the "image/t38" media description:
200 2002 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38
The gwvbd procedure ends due to the media type change. The
"gwvbd(stop)" event would normally be notified at this point,
however, the Call Agent is no longer requesting notification of the
"gwvbd" event. The Call Agent would have inferred from the
"t38(start)" event that the gwvbd procedure ended.
Step 19:
Sharma, Ed., et al. Expires December 8, 2007 [Page 44]
Internet-Draft MGCP VBD package June 2007
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 128.96.41.2
s=-
c=IN IP4 128.96.41.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38
Step 21:
The originating Gateway changes to T.38 and sends back a success
response with updated SDP:
Sharma, Ed., et al. Expires December 8, 2007 [Page 45]
Internet-Draft MGCP VBD package June 2007
200 1003 OK
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38
Again, the gwvbd procedure ends due to the media type change. The
"gwvbd(stop)" event would normally be notified at this point,
however, the Call Agent is no longer requesting notification of the
"gwvbd" event.
Step 22:
The originating Call Agent sends a SIP 200 OK response with the
updated SDP to the terminating Call Agent, which in turn sends a SIP
ACK (not shown).
Step 23:
The terminating Call Agent sends a ModifyConnection with the updated
SDP to the terminating Gateway:
Sharma, Ed., et al. Expires December 8, 2007 [Page 46]
Internet-Draft MGCP VBD package June 2007
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38
Step 24 - 29: These steps correspond to the Call Agent controlled
T.38 strict procedure as defined in the MGCP Fax (FXR) package
[FAXPKG].
Sharma, Ed., et al. Expires December 8, 2007 [Page 47]
Internet-Draft MGCP VBD package June 2007
9. Security Considerations
The MGCP VBD package itself is not known to introduce any new
security concerns. VBD media is transported over RTP. If security
services are in place to protect RTP media streams, these will also
be in effect for the VBD media stream.
The MGCP GPMD package does not require any further security
considerations beyond those indicated in MGCP [RFC3435].
Sharma, Ed., et al. Expires December 8, 2007 [Page 48]
Internet-Draft MGCP VBD package June 2007
10. IANA Considerations
The IANA is hereby requested to register the following MGCP packages,
Package Title Name Version
------------- ---- -------
Voiceband Data VBD 0
General-Purpose Media Descriptor Parameter GPMD 0
and the following LocalConnectionOption,
Field Name
------- ----
General-Purpose Media Descriptor Parameter gpmd
Sharma, Ed., et al. Expires December 8, 2007 [Page 49]
Internet-Draft MGCP VBD package June 2007
11. 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.
Sharma, Ed., et al. Expires December 8, 2007 [Page 50]
Internet-Draft MGCP VBD package June 2007
12. Summary of Changes
Changes in 01:
* Number of formatting corrections (mainly to remove extra blank
lines)
* Updated a number of internal section references (these were off by
one due to addition of new section 2 Terminology as part of initial
version 00 submission)
* In section 3.1.2, corrected Start VBD to VBD Start
* In section 4.1.1, added text to clarify that the first instance is
assumed in the absence of <order>
Sharma, Ed., et al. Expires December 8, 2007 [Page 51]
Internet-Draft MGCP VBD package June 2007
13. References
13.1. Normative References
[FAXPKG] Andreasen, F., ""Media Gateway Control Protocol Fax
Package"", Mar 2005.
[FMPKG] Andreasen, F., ""Basic Media Gateway Control Protocol
(MGCP) Packages"", Dec 2003.
[H1501A1] International Telecommunications Union - Telecommunication
Standardization Sector, "ITU-T Recommendation V.150.1
Amendment 1, "Modem-over-IP networks: Procedures for the
end-to-end connection of V-series DCEs, Amendment 1:
Modification to SSE reason identifier codes to support
voice band data and text relay",", Jan 2005.
[H2482] International Telecommunications Union - Telecommunication
Standardization Sector, "ITU-T Recommendation H.248.2,
"Gateway control protocol: Facsimile, text conversation
and call discrimination packages"", Nov 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733,
December 1999.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833,
May 2000.
[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.
Sharma, Ed., et al. Expires December 8, 2007 [Page 52]
Internet-Draft MGCP VBD package June 2007
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[V1501] International Telecommunications Union - Telecommunication
Standardization Sector, "ITU-T Recommendation V.150.1,
"Modem-over-IP networks: Procedures for the end-to-end
connection of V-series DCEs"", Jan 2003.
[V152] International Telecommunications Union - Telecommunication
Standardization Sector, "ITU-T Recommendation V.152,
"Procedures for supporting Voice-Band Data over IP
Networks"", Jan 2005.
13.2. Informative References
[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.
[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.
Sharma, Ed., et al. Expires December 8, 2007 [Page 53]
Internet-Draft MGCP VBD package June 2007
Authors' Addresses
Sandeep Sharma (Editor)
CableLabs
858 Coal Creek Circle
Louisville, Co 80027
USA
Email: s.sharma@cablelabs.com
URI: http://www.cablelabs.com/
Joe Stone
Cisco Systems
2200 East President George Bush Highway
Richardson, Tx 75082
USA
Email: joestone@cisco.com
URI: http://www.cisco.com/
Rajesh Kumar
Cisco Systems
771 Alder Drive
Milpitas, CA 75082
USA
Email: rkumar@cisco.com
URI: http://www.cisco.com/
Sharma, Ed., et al. Expires December 8, 2007 [Page 54]
Internet-Draft MGCP VBD package June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sharma, Ed., et al. Expires December 8, 2007 [Page 55]
