RFC 6498
Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package
Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package ✨
🎀 Heads up, bestie: this is part 1 of 8. The title block is worked in below, and the rest of the RFC is coming in the next parts. 🫶
Okay so this is an Informational RFC from February 2012 🌸. It was written by J. Stone, R. Kumar, and F. Andreasen, all from Cisco Systems. It's ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 💅.
Abstract 🦋
Okay, so this doc defines MGCP packages that let a Call Agent authorize and monitor a connection moving to and from Voiceband Data (VBD), with or without redundancy and FEC (forward error correction) 🎀. The main focus is VBD, but the General-Purpose Media Descriptor Parameter package can also authorize other modes that have nothing to do with VBD, as long as they're for a specific codec 🌈. On top of the new packages, it also explains how to use the Media Format Parameter package and the Fax package with VBD, redundancy, and FEC ✨.
Status of This Memo 📜
Not a Standards Track spec, bestie. It's just published for info 💜.
This is an IETF product 🌸. It reflects what the IETF community agrees on, it got public review, and the IESG approved it for publication. Not every IESG-approved doc is eligible for any level of Internet Standard, though, so check Section 2 of RFC 5741 if you want the details 🧚.
If you want the latest status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc6498 🔥.
Copyright Notice 💖
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅.
This doc might contain material from IETF Documents or IETF Contributions that were published or made public before November 10, 2008. The people who control the copyright on some of that material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process 😭. So unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶.
Table of Contents 🗂️
1. Applicability Statement .........................................3
2. Introduction ....................................................3
3. Terminology .....................................................5
4. Voiceband Data Package Definition ...............................5
4.1. Events and Signals .........................................5
4.1.1. Gateway Controlled Voiceband Data ...................6
4.1.2. No Negotiated Procedure for Voiceband Data .........13
5. General-Purpose Media Descriptor Parameter Package Definition ..16
5.1. LocalConnectionOptions ....................................16
5.1.1. General-Purpose Media Descriptor Parameter .........17
6. Use of Media Format Parameter Package with VBD and Redundancy ..20
7. Use of Media Format Parameter Package with VBD and FEC .........22
8. Use of Fax Package with VBD ....................................23
9. Call Flow Examples .............................................27
9.1. Modem Call with Gateway Controlled VBD ....................27
9.2. Fax Call with Gateway Controlled VBD and Call
Agent Controlled T.38 .....................................33
10. Security Considerations .......................................42
11. IANA Considerations ...........................................44
12. Acknowledgements ..............................................44
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................461. Applicability Statement 🎀
Okay, real talk: this doc defines a mechanism that requires media stream integrity protection 🔒. It lays out several different alternative mechanisms, but it doesn't pick one as mandatory-to-implement 🙅♀️. So this spec is only a good fit in environments that specify and use at least one of those alternatives 💜. For more details, check the Security Considerations section 🫶.
2. Introduction 🌸
So, "Voiceband Data" (or just VBD) means using a suitable voiceband codec (usually G.711u or G.711a) to carry data payloads over RTP, as defined in RFC 3550 [RFC3550] 🎧. This doc defines MGCP [RFC3435] packages that let a Call Agent authorize and monitor a connection moving to and from VBD, with or without redundancy [RFC2198] and FEC (forward error correction) [RFC5109] 🦋.
There are a bunch of different VBD procedures 🌈. They differ in how the switch to and from VBD gets coordinated end to end ✨. Some of those coordination techniques get mutually negotiated by the two gateways using the Session Description Protocol (SDP) [RFC4566] 💅. Those techniques include:
- ITU-T Recommendation V.150.1 State Signaling Event (SSE) [V1501]
- ITU-T Recommendation V.152 Payload Type Switching [V152]
Other coordination techniques aren't negotiated 🙈. For example, detecting fax, modem, or text tones in the direction from IP to the General Switched Telephone Network (GSTN) might lead to a switch to VBD, or to a change (like turning off echo cancellation) in the gateway controlled VBD procedure that's already running 🔥. The IP-side detected tone acts as both a VBD stimulus and a coordination technique, which is honestly iconic 👑.
RFC 4733 [RFC4733] and RFC 4734 [RFC4734] can be used to carry fax and modem events and tones 📞. Just like IP-side tone detection, the telephone event can be both a VBD stimulus and a coordination technique 💖. Here's the tea: using RFC 4733 and RFC 4734 to carry fax and modem events and tones is negotiated, but using them as a gateway VBD coordination technique is, at present, not negotiated 😭.
The Voiceband Data (VBD) package is defined to support all VBD procedures 🧚. This doc doesn't weigh the pros and cons of the different procedures, and it doesn't push one over another ⭐.
From here on, we'll use "VBD" to mean Voiceband Data in general 🌸. When we talk about VBD in the context of the package, we'll say "VBD package" 🎀. We put "audio" in double quotes when we mean the IANA media type, and we use audio without quotes for the use of the "audio" media type for (most commonly) voice 🦋.
There's a package for the General-Purpose Media Descriptor Parameter [V152] 💅. In the VBD context, the General-Purpose Media Descriptor Parameter (GPMD) package authorizes negotiating a particular codec for use with VBD ✨. The General-Purpose Media Descriptor Parameter is "general" by nature, so it can also be used in applications that aren't VBD 🌈.
The Media Format Parameter (FM) package [RFC3660] describes using the standard audio MIME subtype "RED" along with the "fmtp" LocalConnectionOption 🔥. That combo authorizes negotiating redundancy [RFC2198], and it identifies the redundancy levels and the media format for each level 👑. This doc goes further into using the FM package with VBD and redundancy 💜.
The VBD package is meant to complement the MGCP Fax (FXR) package [RFC5347] 🎀. This doc also explores using the FXR package with VBD 🌸.
Here's the roadmap 🗺️. The VBD package definition is in Section 4, and the GPMD package definition is in Section 5 ✨. Section 6 covers using the FM package with VBD and redundancy 💅. Section 7 covers using the FM package with VBD and FEC 🦋. Section 8 covers using the FXR package with VBD 🌈. Section 9 has two call flow examples showing how to use the VBD and GPMD packages 📞. Security considerations are in Section 10, followed by IANA considerations (Section 11) and the references 🫶.
3. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💖.
4. Voiceband Data Package Definition 🎀
This package is defined for Voiceband Data (VBD) 🌸. It defines new events, detailed below 🦋.
Package Name: VBD
Package Version: 04.1. Events and Signals ✨
These events are defined to support the above 💅:
-------------------------------------------------------------------
| Symbol | Definition | R | S | Duration |
|--------|---------------------------------|-----|-----|------------|
| gwvbd | Gateway Controlled VBD | x | | |
| nopvbd | No Negotiated Procedure for VBD | x | | |
-------------------------------------------------------------------This is standard MGCP package format, as defined in Section 6.6 of RFC 3435 [RFC3435] 🧚. The individual events are defined in the subsections below 🌈.
4.1.1. Gateway Controlled Voiceband Data 🔥
The gwvbd procedure lets the gateway control and decide how to handle VBD calls, without the Call Agent getting involved 👑. The "Gateway Controlled Voiceband Data" (or just "gwvbd") event happens when a gwvbd procedure has been negotiated and VBD stimulus is detected 💜. The "gwvbd" event can also happen when the gwvbd procedure gets updated (like when new stimulus shows up) and when the procedure fails 🎀. And the "gwvbd" event happens when the gwvbd procedure ends 😭. The gwvbd procedure MUST be negotiated with the other side, by passing and recognizing the relevant parameters through the LocalConnectionDescriptor and RemoteConnectionDescriptor 🔒.
The following recommendations from MGCP [RFC3435] apply 🌸.
Here we give a formal description of the protocol syntax, using ABNF as defined in "Augmented BNF for Syntax Specifications: ABNF" [RFC5234] 📐. The syntax uses the core rules from Appendix B.1 of [RFC5234], which aren't repeated here 🦋. The syntax also follows the case-sensitivity rules of [RFC5234], which means MGCP is case-insensitive (but SDP isn't) ✨. Heads up: ABNF doesn't support implicit linear white space, so MGCP messages MUST follow the explicit linear white space rules in the grammar below 💅. That said, in line with general robustness principles, implementers are strongly encouraged to tolerate extra linear white space in the messages they receive 🫶.
Bestie, that's the end of part 1 of 8. Part 2 picks up right after this, so stay tuned 💖🧚
okay so the RequestedEvent parameter is encoded super simply 💅
GwVbdReqEvent = "gwvbd"the ObservedEvent parameter is where it gets spicy 🌸
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 doesn't do position-independent parameters 🙈 so the rc, codec, coord, and dir parameters, if they show up, MUST appear in the relative order shown. no skipping ahead, bestie!
The start, update, stop, and failure ObservedEvent parameters work like this:
1) VBD Start (start)
The gwvbd procedure just got kicked off 🚀. 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 for each gwvbd(start) event, so every start gets its closer. ✨
2) VBD Update (update)
The gwvbd procedure got updated 🦋. The gwvbd(update) event MUST only be generated after a gwvbd(start) event and before a gwvbd(stop) or gwvbd(failure) event. the timing is everything here 💅
3) VBD Stop (stop)
The gwvbd procedure ended, and the gateway did not detect any errors 🍓. ngl this does NOT mean the fax, modem, or text transmission was successful. It only means the gwvbd procedure itself wrapped up without 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 like "image" or "text". This change may be under Call Agent or gateway control. For example, the gateway may coordinate the switch from VBD to "image/t38" through the exchange of SSEs [T38] [V152]. For an example involving Call Agent control, refer to the "MC" Reason Code. In both examples, the gwvbd procedure ends with the media change 🧚
4) VBD Failure (failure)
The gwvbd procedure ended abnormally 💀. Some kind of problem came up during the gwvbd procedure, and it ended.
When the "gwvbd" event is reported, exactly one of the start, update, stop, or failure parameters MUST be present, and it MUST be the first parameter supplied. main character rules 👑
The rc, codec, coord, and dir ObservedEvent parameters are defined like this:
1) Reason Code (rc=<ReasonCode>)
With the start and update parameters, this is the reason for triggering the switch or change to VBD 🌈. With the stop and failure parameters, it's the reason for triggering the switch away from VBD. The Reason Codes in the table below, which are based on the ITU-T Fax/Textphone/Modem Tones Detection package [H2482], ITU-T V.150.1 Amendment 1 [V1501A1], and ITU-T V.152 [V152], may be used with the start and update parameters:
---------------------------------------------------------------
| ReasonCode | Description |
|------------|--------------------------------------------------|
| CNG | T.30 fax calling |
| V21flag | V.21 tone and flags for fax answering |
| CIV18 | V.8 CI with V.18 call function |
| XCI | V.18 XCI |
| V18txp | V.18 txp |
| Belltone | Bell 103 carrier, high- or low-frequency channel |
| | (ITU-T Recommendation V.18) |
| Baudot | Baudot initial tone and character (ITU-T |
| | Recommendation V.18) |
| Edt | EDT initial tone and character (ITU-T |
| | Recommendation V.18) |
| CIdata | V.8 CI with any data call function |
| CT | V.25 calling tone |
| CIfax | V.8 CI with fax call function |
| V21tone | V.21 carrier, high- or low-frequency channel |
| V23tone | V.23 carrier, high- or low-frequency channel |
| V8bis | V.8 bis modem handshaking signal |
| ANS | V.25 ANS, equivalent to T.30 CED from answering |
| | terminal |
| /ANS | V.25 ANS with periodic phase reversals |
| ANSam | V.8 ANSam |
| /ANSam | V.8 ANSam with periodic phase reversals |
| CMFax | V.8 CM sequence indicating fax call function |
| JMFax | V.8 JM sequence indicating fax call function |
| CMData | V.8 CM sequence indicating unspecified data |
| | call function |
| JMData | V.8 JM sequence indicating unspecified data |
| | call function |
| CMText | V.8 CM sequence indicating text call function |
| JMText | V.8 JM sequence indicating text call function |
| PTSW | Payload type switch as defined in V.152 |
---------------------------------------------------------------For solutions involving textphones that use a modulation with interspersed text and speech on the same "channel", like Baudot and EDT, the Call Agent SHOULD interpret the ReasonCode parameter as part of the vbd/gwvbd(start) event. That's how it tells fax, modem, and text apart 📱. With interspersed text and speech, the Call Agent SHOULD remove the notification request for vbd/gwvbd as soon as it gets the vbd/gwvbd(start) event, so it doesn't get flooded with notifications 🙈
For example:
vbd/gwvbd(start, rc=Baudot)With a ReasonCode of PTSW, the Call Agent cannot tell text apart from fax/modem 😭. In this case, the Call Agent SHOULD adopt a policy that guards against large numbers of notifications. We consider several such policies:
The Call Agent MAY remove the notification request for vbd/gwvbd upon receiving the vbd/gwvbd(start, rc=PTSW) event. With this policy, update, stop, and failure notifications will not be generated with text AND fax/modem.
The Call Agent MAY wait for a later vbd/gwvbd(update) event that tells text apart 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 that work with the stop parameter are listed below:
------------------------------------------------------
| ReasonCode | Description |
|------------|-----------------------------------------|
| SIL | Bidirectional silence |
| Voice | Voice signals |
| PTSW | Payload type switch as defined in V.152 |
| MC | Media change |
------------------------------------------------------The MC Reason Code means 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 start when the called terminal identification (CED) is detected. Later, the Call Agent controlled T.38 procedure of the MGCP Fax (FXR) package [RFC5347] may kick in when V.21 flags are detected. Once the Call Agent gets a t38(start) event, it tells the gateway to switch from VBD to T.38 with a ModifyConnection command, using a LocalConnectionOption encoding method of L:a:image/t38 and/or a RemoteConnectionDescriptor with an image/t38 media description. That stops the gwvbd procedure ✨. There's no specific interdependency between the VBD package and the FXR package (or any other package). The gwvbd procedure stops because of the media change, not because the T.38 procedure was started. Note that in this situation, the t38(start) event is sent before the gwvbd(stop) event. The Call Agent MAY choose to infer that the gwvbd procedure has ended when it receives the t38(start) event, and then disable notification of the gwvbd event. Refer to the example call flow in Section 9.2 🎀
Reason Codes that apply with the failure parameter:
----------------------------------------------------
| ReasonCode | Description |
|------------|---------------------------------------|
| TO | Indicates that a timeout has occurred |
----------------------------------------------------The list of Reason Codes may be extended with values whose meaning is mutually understood by the gateway and the Call Agent. Obviously, using extended values MUST be a provisionable option on the gateway so that it stays interoperable with the Call Agent 🫶
2) Codec String (codec=<CodecString>)
With the start and update parameters, the codec parameter describes the MIME type associated with the switch or change to VBD (for example "audio/RED", "audio/PCMU", "audio/PCMA", "audio/G726-32", "audio/clearmode", ...). With the stop and failure parameters, the codec parameter describes the MIME type associated with the switch away from VBD (for example "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.
3) Coordination Technique (coord=<CoordinationTechnique>)
This is 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 |
------------------------------------------------------Okay so with v152ptsw, payload type switching [V152] is what coordinates the switch into and out of VBD. Bestie, that's giving clean handoff energy 🦋
With v150fw, state signaling events [V1501] do the coordinating for the transition to and from VBD. Two options, both iconic 💅
The list of coordination techniques can grow, as long as the new values have a meaning that both the gateway and the Call Agent understand. But here's the catch: using extended values MUST be a provisionable option on the gateway, so the two sides stay interoperable with each other ✨
4) Direction of Stimulus (dir=<Direction>)
With the "start" and "update" parameters, the "dir" parameter tells you which direction the stimulus was in when it caused the switch or change to VBD. Main character info 🎀
---------------------------------------------------
| Direction | Description |
|-----------|------------------------------------ |
| GstnToIp | Stimulus detected in the direction |
| | from the GSTN to IP network, |
| | including fax, modem, and text tones. |
| IpToGstn | Stimulus detected in the direction |
| | from the IP to GSTN network, |
| | including fax, modem, and text tones |
| | (e.g., IP-side tone detection); |
| | RTP packet with VBD payload type |
| | (e.g., V.152 or V.150.1). |
----------------------------------------------------Now the rules, and they're a lot 💀 Call Agents and gateways MUST implement the "start" and "stop" parameters, and they 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 alongside the "start" and "update" parameters. Call Agents and gateways MAY implement the "rc" parameter alongside the "stop" and "failure" parameters. And a Call Agent MUST ignore all unknown ObservedEvent parameters, including the ones defined in this specification that it doesn't implement. Ignoring is not the same as breaking, periodt 🙈
4.1.1.1. Gateway Controlled Voiceband Data Examples 🎀
Here's how the "gwvbd(start)" event gets encoded, bestie 🍓
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)And "gwvbd(update)" looks like this 🦋
O: vbd/gwvbd(update, rc=/ANSam, dir=IpToGstn)The "gwvbd(stop)" event has three flavors ✨
O: vbd/gwvbd(stop)
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/gwvbd(stop, rc=MC, codec=image/t38)Finally, "gwvbd(failure)" shows up like this 💀
O: vbd/gwvbd(failure, codec=audio/G729)
O: vbd/gwvbd(failure, rc=TO, codec=audio/G729)4.1.2. No Negotiated Procedure for Voiceband Data 🌸
Okay so the "No Negotiated Procedure for Voiceband Data" event (or just "nopvbd") happens when VBD stimulus shows up but no VBD procedure was ever negotiated. It can also fire when the procedure gets updated (like when new stimulus is detected), when the procedure ends, and when it fails. Even without a negotiated procedure, a VBD handling procedure MAY still be running locally on the endpoint, which we'll get into more below 👀
The nopvbd procedure MAY involve VBD handling, and that covers stuff like adjusting gain and jitter, turning off voice activity detection, and DC offset filters (but it's not limited to those). It MAY also switch to another codec. The Call Agent MAY have to send more commands in response to the "nopvbd" event so that the VBD call actually works 💅
Same deal as with the "gwvbd" event: the recommendations from MGCP [RFC3435] about ABNF, general robustness principles, and white space still apply 🫶
The RequestedEvent parameter gets encoded like this:
NopVbdReqEvent = "nopvbd"And the ObservedEvent parameter looks like this:
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] ")"This ABNF notation is shared with the "gwvbd" ObservedEvent parameter, so you'll see familiar faces 🌈
Codec = "," *WSP "codec=" CodecString
CodecString = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-" / "_" /
"." / "/")
Rc = "," *WSP "rc=" ReasonCode
ReasonCode = 1*(ALPHA / DIGIT / "-" / "_" / "." / "/")
; Refer to the values listed in the tables above.
Dir = "," *WSP "dir=" Direction
Direction = "GstnToIp" / "IpToGstn"ABNF doesn't do position-independent parameters, so the "rc", "codec", and "dir" parameters, if they're there at all, MUST show up in the relative order listed. No shuffling, bestie 🙅♀️
The "start", "update", "stop", and "failure" ObservedEvent parameters work like this:
1) VBD Start(start)
The nopvbd procedure got initiated. The Call Agent may have to send more commands to make sure the VBD call succeeds (like switching to another codec, for example). At most one "nopvbd(stop)" or "nopvbd(failure)" event MAY be generated for each "nopvbd(start)" event. The Call Agent MAY need to infer that the nopvbd procedure has ended 🕵️♀️
2) VBD Update (update)
The nopvbd procedure got updated. The "nopvbd(update)" event MUST only be generated after a "nopvbd(start)" event and before a "nopvbd(stop)" or "nopvbd(failure)" event. Timing is everything, babe ⏰
3) VBD Stop (stop)
The nopvbd procedure ended, and the gateway didn't detect any errors. Now, this does NOT automatically mean the fax, modem, or text transmission went through. It only tells you the procedure ended and didn't hit any errors along the way. For more on the "stop" parameter, check the "gwvbd" event definition in Section 4.1.1 🧚
4) VBD Failure (failure)
The nopvbd procedure ended abnormally. Something went wrong during the procedure, and then it ended. Rough, but that's the vibe 💔
Call Agents and gateways MUST implement the "start" parameter, and they MAY implement the "update", "stop", and "failure" parameters. Call Agents MAY, and gateways MUST, implement the "rc" parameter alongside the "start" and "update" parameters. Call Agents and gateways MAY implement the "rc" parameter alongside the "stop" and "failure" parameters. A Call Agent MUST ignore all unknown ObservedEvent parameters, including the ones defined in this specification that it doesn't implement 🫠
The "rc", "codec", and "dir" ObservedEvent parameters are defined the same way they are for the "gwvbd" event, so no need to relearn them 💖
As with the "gwvbd" event, the same recommendations about interspersed text and speech apply ✨
4.1.2.1. No Negotiated Procedure for Voiceband Data Examples 🧁
Let's see the "nopvbd(start)" event in action 🎀
O: vbd/nopvbd(start, rc=ANS)
O: vbd/nopvbd(start, rc=ANS, codec=audio/PCMU)The "nopvbd(update)" event looks like this 🦋
O: vbd/nopvbd(update, rc=/ANSam, dir=IpToGstn)And the "nopvbd(stop)" event has three versions 💅
O: vbd/nopvbd(stop)
O: vbd/nopvbd(stop, rc=SIL, codec=audio/G729)
O: vbd/nopvbd(stop, rc=MC, codec=image/t38)Last but not least, "nopvbd(failure)" 😭
O: vbd/nopvbd(failure, codec=audio/G729)
O: vbd/nopvbd(failure, rc=TO, codec=audio/G729)5. General-Purpose Media Descriptor Parameter Package Definition ✨
This package is defined for the General-Purpose Media Descriptor Parameter [V152]. It defines a new LocalConnectionOption, which is detailed below 👑
Package Name: GPMD
Package Version: 05.1. LocalConnectionOptions 🦋
The following new LocalConnectionOptions field is defined to support all of the above:
------------------------------------------------------
| Symbol | Definition |
|--------|---------------------------------------------|
| gpmd | General-Purpose Media Descriptor Parameter |
------------------------------------------------------The definition of the LocalConnectionOption is in the next subsection, so keep scrolling 🌸
5.1.1. General-Purpose Media Descriptor Parameter 🎀
okay so the General-Purpose Media Descriptor Parameter LocalConnectionOption is basically the bestie of the "gpmd" SDP [RFC4566] attribute from ITU-T Recommendation V.152 [V152] 💖 it works with all the same media formats that the SDP "gpmd" attribute could be used with. literally the same energy 🦋
the parameter gets encoded as the keyword "gpmd" or "o-gpmd", then a colon, then a quoted string. that string starts with the media format name (MIME subtype only), then a space, then the media format parameters for that format ✨
gpmd/gpmd:"<format> <parameter list>"quick note: we're going to use "codec" and "media format" interchangeably from here on, so don't get confused 🙈
you can indicate multiple media formats in two ways. you can repeat the "gpmd" LocalConnectionOption multiple times, like this:
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY"or you can use one single "gpmd" keyword with a colon, followed by a semicolon-separated list of quoted strings, one for each General-Purpose Media Descriptor Parameter:
L: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"and you can totally mix the two 💅
L: a:codec1;codec2;codec3, gpmd/gpmd:"codec1 parameterX",
gpmd/gpmd:"codec2 parameterY";
"codec3 parameterZ"the carriage returns in those examples are just there so they fit on the page. they are NOT allowed in a real implementation 🙅♀️ this goes for every example in this document, so keep that in mind, bestie.
now, what if the same codec can be requested both with and without the "gpmd" parameter? you might end up with something like this:
L: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"but this is where it gets messy 😭 nobody can tell whether "gpmd" was meant for the first codec1 or the second one. codec ordering matters here (codecs are listed in preferred order), and the syntax above has no way to say whether "parameterX" is for the preferred one (the first "codec1") or the other one (the second "codec1"). so to fix this, the codec inside the "gpmd" media format gets a colon and an <order>, where <order> is a number from one to N for the occurrences of that same codec in the codec list. for example:
L:a:codec1;codec1, gpmd/gpmd:"codec1:2 parameterX"this one says "parameterX" belongs to the second instance of "codec1" in the "a:codec1;codec1" list 🎯 if you put in an invalid instance number (like instance 3 when there are only two instances), then error code 524 -- inconsistency in local connection options -- will be returned. and if you leave out the <order> entirely, the first instance is assumed.
if you put the string "o-" in front of "gpmd" (so "o-gpmd"), that means the parameter is optional. in that case the gateway may decide not to use the "gpmd" parameter at all, or it may only use part of it 🌸
if the "gpmd" LocalConnectionOption parameter is NOT optional (so no "o-" in front), and its value is either not recognized or not supported, then the associated codec is considered "not supported" ❌
when it's time to audit capabilities, the "gpmd" LocalConnectionOption parameter MUST be returned. it comes back as a semicolon-separated list of supported formats and/or multiple independent "gpmd" parameters, like this:
A: a:codec1;codec2, gpmd/gpmd:"codec1 parameterX";
"codec2 parameterY"or like this:
A: a:codec1;codec1, gpmd/gpmd:"codec1 parameterX"one example uses the General-Purpose Media Descriptor Parameter LocalConnectionOption together with gateway controlled Voiceband Data (or just VBD) using payload type switching [V152]. in the VBD context, the <format> MUST be an RTP/AVP payload type. wait, sorry, I mean it's an RTP/AVP payload type, and the <parameter list> is a semicolon-separated list of "parameter=value" pairs 💜
L: a:codec1, gpmd/gpmd:"codec1 parameterX=ValueA;parameterY=ValueB"in the example below, G.729 is the audio codec and G.711u is the VBD codec 🎀
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes"the matching media description in the SDP, as part of the connection request acknowledgment, might look like this:
m=audio 12345 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yesnow imagine someone wants to audit an endpoint's capabilities, and that endpoint supports G.711u as both an audio codec and a VBD codec. the "gpmd" LocalConnectionOption parameter might look something like this:
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"here's the thing 👑 some parameters, like silence suppression, only work with G.711u as an audio codec. because of that, the gateway MUST return different capability sets for audio and for VBD. no mixing them up, periodt 💅
if we combine V.152 and redundancy [RFC2198], you can get an LocalConnectionOption like the one below. in this example, G.729 is the audio codec and G.711u is the VBD codec with a redundancy level of one 🦋
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"the corresponding SDP media description, as part of the connection request acknowledgment, might look like this:
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=yesfor more V.152 and redundancy examples, go check out Section 6 🧚
6. Use of Media Format Parameter Package with VBD and Redundancy ✨
so the MGCP Media Format Parameter (FM) package [RFC3660] works together with the standard audio MIME subtype "RED". the Call Agent can use this combo to authorize the negotiation of redundancy [RFC2198], and to identify the redundancy levels and the media format for each level. we already saw an example of this in Section 5 💖
the FM package says the "fmtp" LocalConnectionOption MUST be returned when auditing capabilities. applying that to VBD and redundancy might give you something like this:
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 also defines something called "instance syntax" 🤓 it looks like this:
L:a:codec1;codec1, fmtp:"codec1:2 formatX"and it means "formatX" belongs to the second instance of "codec1" in the "a:codec1;codec1" list. the examples in the FM package only use instance syntax with the media format itself. we're proposing to use instance syntax with the media format parameters too:
L:a:codec1;codec2;codec3;codec2, fmtp:"codec3 codec2:2/codec2:2"let's build on the Section 5 example. here G.729 is an audio codec, and G.711u is BOTH an audio codec and a VBD codec with a redundancy level of one 🌈
L: a:G729;PCMU;RED;PCMU, gpmd/gpmd:"PCMU:2 vbd=yes",
fmtp:"RED PCMU:2/PCMU:2"the corresponding SDP media description, as part of the connection request acknowledgment, might look like this:
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=yesone thing to notice: the relative preference of the LocalConnectionOption encoding methods is kept in the "audio" media formats (aka the payload types) inside the media description. in this example, that shows a preference for V.152 with redundancy over no V.152. no preference is inferred from the relative order of the different LocalConnectionOptions themselves ("a", "gpmd/gpmd", and "fmtp") 🙈
a Call Agent can authorize the negotiation of audio codecs and VBD codecs with different redundancy levels. 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 SDP media description, as part of the connection request acknowledgment, might look like this:
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=yesredundancy can be applied to audio codecs AND VBD codecs too 🫶 in the example below, G.729 is an audio codec with a redundancy level of two, and G.711u is a VBD codec with a redundancy level of one:
L: a:RED;G729;RED;PCMU, fmtp:"RED G729/G729/G729",
fmtp:"RED:2 PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes"the corresponding SDP media description, as part of the connection request acknowledgment, might look like this:
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=yes7. Use of Media Format Parameter Package with VBD and FEC ✨
a Call Agent may authorize the negotiation of forward error correction (FEC) [RFC5109] with the standard audio MIME subtype "parityfec" 🦋
L: a:PCMU;parityfecby default, we assume FEC packets are sent as a separate stream. the corresponding SDP media description, as part of the connection request acknowledgment, might look like this:
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.0if FEC is sent as a secondary codec in the redundant codec payload format [RFC2198], we again team up with the MGCP Media Format Parameter (FM) package [RFC3660] and 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 this:
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/8000the FM package says the "fmtp" LocalConnectionOption MUST be returned when auditing capabilities. applying that to VBD, redundancy and FEC might give you something like this:
A: a:PCMU, p:10-40, e:on, s:on,
m:sendonly;recvonly;sendrecv;inactive
A: a:RED;PCMU;parityfec, p:10-40, e:on, s:off,
m:sendonly;recvonly;sendrecv;inactive,
gpmd/gpmd:"PCMU vbd=yes",
fmtp:"RED PCMU/parityfec"8. Use of Fax Package with VBD ✨
okay bestie, so the MGCP Fax (FXR) package [RFC5347] is what a Call Agent uses to give the green light for fax handling 💅 That covers Call Agent controlled T.38 and gateway procedures like V.152. With FXR, VBD lands in one of two buckets: "special fax handling" as part of the gateway procedure (which gives you the "gwfax" event), or "no special fax handling" as part of the gateway and Off procedures (which gives you the "nopfax" event). 🦋 For a VBD procedure to count as "special fax handling," support for it MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor. no shortcuts, periodt 🫶
A gateway controlled VBD procedure such as V.152 MUST fall into the category of gateway controlled mode involving "special fax handling" 🔥 The "gwfax" event is what tells the Call Agent to chill and stop issuing media handling instructions that could mess with the gateway procedure. main character energy for the gateway, honestly 👑
Here's a vibe check example (shorthand SDP notation):
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 1
M: sendrecv
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:t38;gw
X: 1
R: fxr/t38, fxr/gwfax, fxr/nopfax
v=0
c=IN IP4 192.0.2.1
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yes
200 2000 OK
I: 1
v=0
c=IN IP4 192.0.2.2
m=audio 1296 RTP/AVP 18 96
a=rtpmap:96 PCMU/8000
a=gpmd:96 vbd=yesSo the RemoteConnectionDescriptor doesn't show image/t38 as a latent capability [RFC3407] 🙈 That means the gateway won't kick off the T.38 strict fax procedure, "t38," when it detects fax stimulus (CNG, V.21 flags, etc.). BUT the two endpoints did successfully negotiate a gateway controlled VBD procedure (e.g., V.152), so a gateway controlled mode with "special fax handling" is what's used. The "gwfax(start)" event gets generated once VBD (including fax) stimulus shows up ✨
A Call Agent can say it prefers a gateway procedure with "special fax handling" over a T.38 procedure (strict or loose). For example:
L: fxr/fx:gw;t38and
L: fxr/fx:gw;t38-looseStill, with the current FXR syntax, a Call Agent can't express a preference for one gateway procedure over another, especially when each one might have different preferences relative to a T.38 procedure 😭
The FXR package lets a gateway implement extra fax handling parameters, and we define exactly that kind of parameter 🎀 We qualify 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/Qualifying gw with MIME types narrows the scope of the gateway procedure. Check out these examples where the Call Agent authorizes a gateway controlled fax handling procedure:
- involving "image/t38" (e.g., T.38oUDPTL, T.38oTCP):
L: a:G729, fxr/fx:gw[image/t38]- involving VBD (e.g., PCMU and V.152):
L: a:G729;PCMU, gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/PCMU]- involving VBD with redundancy (e.g., PCMU, V.152, and RFC 2198):
L: a:G729;RED;PCMU, fmtp:"RED PCMU/PCMU",
gpmd/gpmd:"PCMU vbd=yes", fxr/fx:gw[audio/RED|audio/PCMU]Only "special fax handling" involving one of the listed MIME types is authorized 💖 Support for "special fax handling" involving one of those MIME types MUST be negotiated, or this "instance" of the gateway procedure doesn't get initiated. Here's one more where the Call Agent authorizes a gateway controlled fax handling procedure:
- involving "audio/t38" (e.g., T.38oRTP):
L: a:G729;t38, fxr/fx:gw[audio/t38]In this one, the call fails if the gateway can't negotiate "audio/t38" 💀
The "fx" LocalConnectionOption MAY now include multiple instances of the "gw" parameter, each with a different list of MIME types ✨ 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 "gw" without a MIME type should show up as the last instance of "gw." Like in this example:
L: a:G729;PCMU, fxr/fx:gw[image/t38];gwthe Call Agent authorizes, and states a preference for, these (in order):
- Gateway controlled image/t38 (e.g., T.38oUDPTL)
- Any other gateway procedure with "special fax handling"
- No special fax handling (this is a function of the
fxr/fx:gwparameter as defined in Section 2.1 of the MGCP Fax (FXR) package [RFC5347])
If it's there, the "off" parameter should be the last parameter. In this example:
L: a:G729;PCMU;t38, fxr/fx:gw[audio/t38];offthe Call Agent authorizes, and prefers, these (in order):
- Gateway controlled audio/t38 (e.g., T.38oRTP)
- No special fax handling
We can rank gateway controlled fax handling procedures not just against each other, but against T.38 procedures too 🌈 Here's a preference list of fax handling procedures:
- Gateway controlled audio/t38 (e.g., T.38oRTP)
- Gateway controlled image/t38 (e.g., T.38oUDPTL)
- Call Agent controlled image/t38
- Gateway controlled VBD with redundancy (e.g., PCMU, V.152, and RFC 2198)
- Gateway controlled VBD without redundancy (e.g., PCMU and V.152)
- Any other gateway procedure with "special fax handling"
- No special fax handling (this is a function of the
fxr/fx:gwparameter as defined in Section 2.1 of the MGCP Fax (FXR) package [RFC5347])
That gets 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⚠️ heads up: the bracketed form of the "gw" parameter is NOT defined as part of the VBD package. It's an extension to the FXR package instead. Gateways that implement the bracketed form of the "gw" parameter MUST return this form of the parameter when capabilities are audited, like this:
A: fxr/fx:t38;t38-loose;gw[audio/t38|image/t38];gw;offSupport 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 try the bracketed form of the "gw" parameter with an endpoint that says it supports the bracketed syntax in its capabilities 🙈 Call Agents and gateways that don't support this form of the "gw" parameter MUST ignore the bracketed MIME type information, consistent with the MGCP grammar [RFC3435]. ignore it and move on, no drama 💅
9. Call Flow Examples 🧚
okay so this section has two call flow examples 📞 The first shows a modem call under gateway control using V.152. The second shows a fax call under gateway control using V.152 plus Call Agent controlled T.38. let's gooo 🚀
9.1. Modem Call with Gateway Controlled VBD 📞✨
okay so bestie, this one is a modem call 📞 and both sides are totally on board with gateway controlled VBD using V.152 with redundancy 💅. we're assuming the originating and terminating Call Agents talk to each other over 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 sends a CreateConnection command to the gateway 🎀. It tells the gateway to use G.729 media encoding and to notify it of the "gwvbd" and "nopvbd" events. The Call Agent also gives the green light to negotiate G.711u as a VBD codec with a redundancy level of one ✨:
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
M: recvonly
R: vbd/gwvbd, vbd/nopvbd
X: 1
Q: process, loopStep 2: the gateway acknowledges the command 🦋 and includes SDP with its codec info, plus the V.152 and redundancy details:
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=yesStep 3: the originating Call Agent sends a SIP INVITE with that SDP over to the terminating Call Agent 💌.
Step 4: the terminating Call Agent sends a CreateConnection command to the terminating gateway 🧚. Same vibe as before: G.729 encoding, notify on "gwvbd" and "nopvbd", and the Call Agent again okays G.711u as a VBD codec with a redundancy level of one:
CRCX 2000 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU"
M: sendrecv
R: vbd/gwvbd, vbd/nopvbd
X: 20
Q: process, loop
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=yesStep 5: the terminating gateway supports V.152 and redundancy 🙌. The RemoteConnectionDescriptor it got says the other side supports them too, so it sends back a success response with its own SDP, which also has V.152 and redundancy info:
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=yesStep 6: the terminating Call Agent sends a SIP 200 OK back to the originating Call Agent 🥰, which then sends a SIP ACK (not shown).
Step 7: the originating Call Agent sends a ModifyConnection command to the originating gateway 💫:
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yesSince the RemoteConnectionDescriptor says the other side supports V.152 and redundancy, the gateway is actually able to use the gateway controlled VBD procedure with redundancy 🔥. Had there been no V.152 support in the RemoteConnectionDescriptor, this command would still have succeeded. The catch is that there would be no negotiated procedure for VBD handling 🙈.
Step 8: the gateway acknowledges the command ✅. At this point the call is established using G.729 encoding, and if a VBD call is detected, the gateway controlled VBD procedure gets kicked off 🎬.
Steps 9-10: the modem call happens now 📠. The terminating gateway detects a T.30 CED tone (a.k.a. V.25 ANS) in the GSTN-to-IP direction and starts sending RTP packets with the negotiated redundant VBD payload type (96) 🌈.
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent 📣:
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20Step 11: the Call Agent acknowledges the Notify command 👍:
200 2500 OKStep 12: once the originating gateway receives an RTP packet with the redundant VBD payload type (96), it starts sending RTP packets with that same payload type 🍓.
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent 📣:
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1Step 13: the Call Agent acknowledges the Notify command 💖:
200 1500 OKSteps 14-15: the modem call ends 👋. The terminating gateway detects bidirectional silence and starts sending RTP packets with the negotiated audio payload type (18) 🫧.
The "gwvbd(stop)" event occurs, and a Notify command is sent to the Call Agent 📣:
NTFY 2501 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=SIL, codec=audio/G729)
X: 20Step 16: the Call Agent acknowledges the Notify command ✨:
200 2501 OKStep 17: once the originating gateway receives an RTP packet with the audio payload type (18), it starts sending RTP packets with that audio payload type too 🦋.
The "gwvbd(stop)" event occurs, and a Notify command is sent to the Call Agent 📣:
NTFY 1501 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(stop, rc=PTSW, codec=audio/G729)
X: 1Step 18: the Call Agent acknowledges the Notify command 🥳:
200 1501 OKAnd that's the modem call, all wrapped up 🎀💅.
9.2. Fax Call with Gateway Controlled VBD and Call Agent Controlled T.38 📠🌸
in this one, both sides are supporting gateway controlled VBD using V.152 with redundancy AND Call Agent controlled T.38 🫶. Again we're assuming the originating and terminating Call Agents chat over 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| | | <- V.21 Preamble|
|15| | | <- NTFY(t38 start)|
|16| | | 200|-> |
|17| | | MDCX(t38)|-> |
|18| | | <-|200(sdp-t2) |
|19| | <-|INVITE(sdp-t2) | |
|20| <-|MDCX(sdp-t2) | | |
|21| 200(sdp-o2)|-> | | |
|22| | 200(sdp-o2)|-> | |
|23| | | MDCX(sdp-o2)|-> |
|24| | | <-|200 |
|25| V.21 Preamble |-> | | |
|26|NTFY(t38 start)|-> | | |
|27| <-|200 | | |
|--|---------------|---------------|---------------|---------------|
|28| | | | (fax ends) |
|29| | | <-|NTFY(t38 stop) |
|30| | | 200|-> |
|31|NTFY(t38 stop) |-> | | |
|32| <-|200 | | |
------------------------------------------------------------------Step 1: the Call Agent sends a CreateConnection command to the gateway 🎀. It tells the gateway to use G.729 media encoding and to use either the strict T.38 procedure or the gateway procedure 🧠. So the Call Agent asks to be notified of the "t38", "gwfax", "gwvbd", and "nopvbd" events 🔔. It also gives the green light to negotiate G.711u as a VBD codec with a redundancy level of one ✨:
CRCX 1000 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
L: a:G729;RED;PCMU, gpmd/gpmd:"PCMU vbd=yes", fmtp:"RED PCMU/PCMU",
fxr/fx:t38;gw
M: recvonly
R: fxr/t38, fxr/gwfax, vbd/gwvbd, vbd/nopvbd
X: 1
Q: process, loopStep 2: the gateway acknowledges the command 🦋 and includes SDP with codec info, plus capability, V.152, and redundancy information:
200 1000 OK
I:1v=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 t38Note 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. 💅✨ So if you want T.38 to win the fax race, you have to say so right at the session level, no skipping it 🙈
Step 3:
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent. 📨🦋
Step 4:
Okay this one is giving main character energy 👑 The terminating Call Agent issues a CreateConnection command to the terminating gateway, telling it to use G.729 media encoding and to use either the strict T.38 procedure or the gateway procedure. So the Call Agent asks to be notified about the t38, gwfax, gwvbd, and nopvbd events. And again, the Call Agent okays the negotiation of G.711u as a VBD codec with a redundancy level of one. Iconic 🔥
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 t38Step 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 that was requested can be used. ✨ The terminating gateway also supports V.152 and redundancy, and the RemoteConnectionDescriptor indicates that the other side supports V.152 and redundancy too, so gateway controlled VBD using V.152 and redundancy can be used for modem and text transmissions. The terminating gateway then sends back a success response with its SDP, which also includes capability, V.152, and redundancy information. Everyone's on the same page, periodt 🎀
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 t38Step 6:
The terminating Call Agent sends a SIP 200 OK response back to the originating Call Agent, which in turn sends a SIP ACK (not shown). 🫶
Step 7:
The originating Call Agent then sends a ModifyConnection command to the originating gateway. 🌸
MDCX 1001 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
M: sendrecv
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
a=pmft: T38
m=audio 1296 RTP/AVP 18 96 97
a=rtpmap:96 RED/8000
a=fmtp:96 97/97
a=rtpmap:97 PCMU/8000
a=gpmd:97 vbd=yes
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cdsc: 4 image udptl t38The ModifyConnection command does not repeat the LocalConnectionOptions that were sent before, so ngl the gateway just keeps doing what it was already doing for fax, which is strict Call Agent controlled T.38. 🧚 Since the capability information says the other side supports T.38, the gateway will actually be able to use the strict Call Agent controlled T.38 procedure. And since the RemoteConnectionDescriptor says the other side supports V.152 and redundancy, the gateway will actually be able to use the V.152 VBD procedure with redundancy. Both paths are open, bestie 🦋
Step 8:
The gateway acknowledges the command. 💖 At this point a call is established using G.729 encoding. If a fax call is detected, the Call Agent controlled T.38 procedure will be started. If a modem or text call is detected, the V.152 VBD procedure will be started instead. Choose your fighter 💅
Steps 9-10:
The terminating gateway detects the T.30 CED tone (a.k.a. V.25 ANS). Since both fax and modem calls can start with this sequence, it is not possible to tell that this is a fax call until step 14, where the V.21 fax preamble is detected. 🙈 The terminating gateway begins transmitting RTP packets with the negotiated redundant VBD payload type (96).
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent. 🔥
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=ANS, codec=audio/RED, coord=v152ptsw)
X: 20Step 11:
The Call Agent acknowledges the Notify command. 🍓
200 2500 OKStep 12:
Upon receiving an RTP packet with the redundant VBD payload type (96), the originating gateway begins transmitting RTP packets with the redundant VBD payload type too. Mirror mirror 🪞
The "gwvbd(start)" event occurs, and a Notify command is sent to the Call Agent.
NTFY 1500 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
O: vbd/gwvbd(start, rc=PTSW, codec=audio/RED)
X: 1Step 13:
The Call Agent acknowledges the Notify command. 💜
200 1500 OKSteps 14-15:
The terminating gateway detects the V.21 fax preamble. 📠✨ The terminating gateway is using the Call Agent controlled T.38 strict procedure for fax calls, so the "t38(start)" event occurs, and a Notify command is sent to the Call Agent. Plot twist, it's a fax 😭
NTFY 2500 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
O: fxr/t38(start)
X: 20Step 16:
The Call Agent acknowledges the Notify command. 🫶
200 2500 OKStep 17:
The Call Agent then tells the terminating gateway to switch over to 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: 21Note that the Call Agent is no longer requesting notification of the "gwvbd" event. 🙅♀️ It's giving "I'm moving on" energy.
Step 18:
The terminating gateway sends back a success response with its SDP, which also includes the "image/t38" media description. 💖
200 2002 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38The gwvbd procedure ends because the media type changed. ✨ The "gwvbd(stop)" event notification would normally be sent at this point, but 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. Smart, no notes 🧠
Step 19:
The terminating Call Agent sends a re-INVITE with the updated SDP to the originating Call Agent. 🔁
Step 20:
The originating Call Agent then sends a ModifyConnection command to the originating gateway. 💌
MDCX 1003 ds/ds1-1/1@gw-o.whatever.net MGCP 1.0
C: 1
I: 1
R: fxr/t38
X: 2
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
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 t38Step 21:
The originating gateway changes over to T.38 and sends back a success response with the updated SDP. 🎀
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38Again, the gwvbd procedure ends because the media type changed. ✨ The "gwvbd(stop)" event notification would normally be sent at this point, but the Call Agent is no longer requesting notification of the "gwvbd" event.
Step 22:
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown). 🫶
Step 23:
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway. 🧚
MDCX 2002 ds/ds1-1/2@gw-t.whatever.net MGCP 1.0
C: 2
I: 2
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18 96 97
a=cpar: a=rtpmap:96 RED/8000
a=cpar: a=fmtp:96 97/97
a=cpar: a=rtpmap:97 PCMU/8000
a=cpar: a=gpmd:97 vbd=yes
a=cdsc: 4 image udptl t38Steps 24-32:
These steps correspond to the Call Agent controlled T.38 strict procedure as defined in the MGCP Fax (FXR) package [RFC5347]. 🌈 Go check that one out if you want the rest of the fax story, iykyk 💅
10. Security Considerations ✨
okay so this section is SO important bestie 😭 🔐 it's basically the "don't get hacked" chapter and i'm obsessed with how thorough it is 💅
This document defines two new packages, both of which have security considerations in two areas:
- MGCP signaling message security
- Media stream security
From an MGCP signaling security point of view, the MGCP VBD and GPMD packages are extensions to the basic MGCP signaling spec, following the procedures in MGCP [RFC3435]. So the MGCP signaling security considerations and recommendations in Section 5 of [RFC3435] (namely the use of IPsec) apply here too 🛡️ Lack of MGCP signaling integrity protection can be detrimental to any use of MGCP, and these two packages don't change that 💀 From a confidentiality point of view, the VBD package isn't believed to convey any vulnerable or privacy-sensitive information 🌸 The GPMD package is a little different 👀 It doesn't define any specific parameters that are believed to need confidentiality, BUT it's a generic parameter that can carry any codec parameter information, so it's possible that confidential information gets conveyed through it. If confidentiality of any such potential information is a concern, confidentiality protection of the MGCP signaling MUST be provided as well 🚨 It's worth noting that Section 8 of [RFC5406] has considerations for specifying the use of IPsec that go above and beyond what [RFC3435] provides. However, since IPsec for MGCP applies to ALL of MGCP and not just the VBD and GPMD packages, we don't specify that extra 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]. So the MGCP media stream security considerations and recommendations in Section 5.1 of [RFC3435] apply here too 🎀 Lack of media stream security can be detrimental to any media stream established via MGCP, and these two packages don't change that. Confidentiality concerns apply just like for any other media stream. Integrity concerns are extra 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'd be a single mandatory-to-implement media stream security mechanism to provide this integrity protection, and in theory there is one, since MGCP [RFC3435] defines a media stream security mechanism 🤔 BUT the standard MGCP media stream security mechanism in [RFC3435] relies on the encryption key ("k=") field from the original SDP spec [RFC2327], and the use of that field is no longer recommended in the current SDP spec [RFC4566] 💀 In practice, this mechanism has also seen very limited implementation, so there's not much value in relying on it. Still, the integrity protection requirement remains, and there are several different ways to achieve it:
Secure RTP: For RTP-based media streams, using Secure RTP [RFC3711] with an associated key management mechanism is generally preferred at the time of this writing 🔥 however, such a mechanism has currently not been defined for MGCP.
PacketCable Security: The PacketCable Network-Based Call Signaling Protocol [NCS] defines another media stream security mechanism that is generally supported by PacketCable-compliant implementations. Implementations targeted for those environments SHOULD implement this security mechanism 💖
Lower-Level Security: In the absence of a common media stream security mechanism supported by both endpoints, a lower-level security mechanism, e.g., IPsec, MUST be used. Note that since there is no inherent MGCP signaling support for such a lower-level security mechanism, it MUST be configured by other means 🧚♀️
11. IANA Considerations 🦋
okay the IANA part is giving registry vibes 📋 the IANA has registered the following MGCP packages:
Package Title Name Version
------------- ---- -------
Voiceband Data VBD 0
General-Purpose Media Descriptor Parameter GPMD 012. Acknowledgements 🫶
so many people helped make this happen and i love that they got shoutouts 💜 several people contributed to the development of the MGCP VBD and GPMD packages, and to the use of the MIME subtypes "RED" and "parityfec" with the FM package for VBD with redundancy and FEC. the authors especially want to thank Flemming Andreasen, John Atkinson, Bill Foster, and the CableLabs PacketCable TGCP/NCS focus team for their contributions 🌈 and a big thank you 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 the final editor role were handled by Flemming Andreasen. Sandeep Sharma was editor on earlier versions of the document ✨
13. References 📚
13.1. Normative References
[H2482] International Telecommunication Union - Telecommunication
Standardization Sector, "Gateway control protocol:
Facsimile, text conversation and call discrimination
packages", ITU-T Recommendation H.248.2, November 2000.
[NCS] CableLabs(R), "PacketCable(TM) 1.5 Specifications:
Network-Based Call Signaling Protocol, PKT-SP-NCS1.5-I03-
070412", April 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002.
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3660] Foster, B. and F. Andreasen, "Basic Media Gateway Control
Protocol (MGCP) Packages", RFC 3660, December 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733,
December 2006.
[RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for
Modem, Fax, and Text Telephony Signals", RFC 4734,
December 2006.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5347] Andreasen, F. and D. Hancock, "Media Gateway Control
Protocol Fax Package", RFC 5347, October 2008.
[V1501] International Telecommunication Union - Telecommunication
Standardization Sector, "Modem-over-IP networks:
Procedures for the end-to-end connection of V-series
DCEs", ITU-T Recommendation V.150.1, January 2003.
[V1501A1] International Telecommunication Union - Telecommunication
Standardization Sector, "Modem-over-IP networks:
Procedures for the end-to-end connection of V-series DCEs,
Amendment 1: Modification to SSE reason identifier codes
to support voice band data and text relay",
ITU-T Recommendation V.150.1 Amendment 1, January 2005.
[V152] International Telecommunication Union - Telecommunication
Standardization Sector, "Procedures for supporting Voice-
Band Data over IP Networks", ITU-T Recommendation V.152,
January 2005.13.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, February 2009.
[T38] International Telecommunication Union - Telecommunication
Standardization Sector, "Procedures for real-time Group 3
facsimile communication over IP networks",
ITU-T Recommendation T.38, April 2004.Authors' Addresses 💌
Joe Stone
Cisco Systems
2200 East President George Bush Highway
Richardson, TX 75082
USA
EMail: joestone@cisco.com
URI: http://www.cisco.com/
Rajesh Kumar
Cisco Systems
Mail Stop SJCE/1/1
190 West Tasman Drive
San Jose, CA 95134
USA
EMail: rkumar@cisco.com
URI: http://www.cisco.com/
Flemming Andreasen
Cisco Systems
Iselin, NJ 08830
USA
EMail: fandreas@cisco.com
URI: http://www.cisco.com/That's the whole RFC, bestie! 🌈💖 You made it through all 8 parts 🎀🧚
📦 where this page comes from
- ietf: rfc6498 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms