RFC 3149
MGCP Business Phone Packages
MGCP Business Phone Packages 📞✨
Okay bestie, here are the deets 🎀 This is RFC 3149, filed under the Network Working Group 🌸 It's an Informational doc, so it's giving "here's some useful info for the community," not an Internet standard 💅 It was written by A. Srinath, G. Levendel, and K. Fritz from Sylantro Systems, plus R. Kalyanaram from Wipro Systems, and it's dated September 2001 🍓 The header doesn't list anything it obsoletes or updates 🦋
Status of This Memo 📝
This memo is here to provide information for the Internet community 🫶 It does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved. 💜
Abstract 🦋
This doc describes a collection of MGCP (Media Gateway Control Protocol) packages that let you use the feature keys and displays on digital business phones and IP-Phones. It's giving main character energy for business phones 💼✨
IESG Note 👑
Okay, this part is important 😭 The doc is being published for the info of the community, and it describes a non-IETF protocol that's already being deployed in a bunch of products 🔥 Implementers should know that the IETF Megaco working group and the ITU-T Study Group 16 made a standards track RFC called "Megaco Protocol Version 1.0" (RFC 3015, also published as ITU recommendation H.248). That one tackles the same problem space, and they're working on extensions for this kind of stuff too 🙈
Table of Contents 🗂️
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 General Information. . . . . . . . . . . . . . . . . . 4
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . 5
2. MGCP Packages for Business Phones . . . . . . . . . . . . . 5
2.1 Feature Key Package. . . . . . . . . . . . . . . . . . 6
2.2 Business Phone Package . . . . . . . . . . . . . . . . 9
2.3 Display XML Package. . . . . . . . . . . . . . . . . . 9
3. Endpoint Naming and Phone Type Determination. . . . . . . .10
4. Functions that should be Locally Implemented. . . . . . . .11
4.1 Volume Control . . . . . . . . . . . . . . . . . . . .11
4.2 Audio Path . . . . . . . . . . . . . . . . . . . . . .11
4.3 Microphone mute button and light . . . . . . . . . . .11
5. XML Package Support . . . . . . . . . . . . . . . . . . . .12
5.1 XML Documents. . . . . . . . . . . . . . . . . . . . .12
5.2 XML Requests . . . . . . . . . . . . . . . . . . . . .13
5.3 XML Request History. . . . . . . . . . . . . . . . . .15
5.4 XML Events . . . . . . . . . . . . . . . . . . . . . .15
5.5 XML Tags . . . . . . . . . . . . . . . . . . . . . . .15
5.5.1 XML Tag. . . . . . . . . . . . . . . . . . . . . . .17
5.5.2 Card Tag . . . . . . . . . . . . . . . . . . . . . .18
5.5.3 P Tag. . . . . . . . . . . . . . . . . . . . . . . .18
5.5.4 Select Tag . . . . . . . . . . . . . . . . . . . . .18
5.5.5 Option Tag . . . . . . . . . . . . . . . . . . . . .19
5.5.6 Input Tag. . . . . . . . . . . . . . . . . . . . . .20
5.5.7 Echo Tag . . . . . . . . . . . . . . . . . . . . . .20
5.5.8 Calltimer Tag. . . . . . . . . . . . . . . . . . . .21
5.5.9 Time Tag . . . . . . . . . . . . . . . . . . . . . .21
5.5.10 Timer Tag . . . . . . . . . . . . . . . . . . . . .21
5.5.11 Do Tag. . . . . . . . . . . . . . . . . . . . . . .22
5.5.12 Go Tag. . . . . . . . . . . . . . . . . . . . . . .22
5.5.13 Prev Tag. . . . . . . . . . . . . . . . . . . . . .23
6. Security Considerations . . . . . . . . . . . . . . . . . .23
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . .23
8. References. . . . . . . . . . . . . . . . . . . . . . . . .23
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . .24
Appendix A: BNF description of XML grammar . . . . . . . . . .25
Appendix B: Sample XML Documents, Renderings and Events. . . .27
B.1 Sample Deck 1 (Itemized List Box). . . . . . . . . . .27
B.2 Sample Deck 2 (Enumerated List Box). . . . . . . . . .28
B.3 Sample Deck 3 (Text Box) . . . . . . . . . . . . . . .29
B.4 Sample Deck 4 (Echo Box) . . . . . . . . . . . . . . .30
B.5 Sample Deck 5 (Input Box). . . . . . . . . . . . . . .31
B.6 Sample Deck 6 (Timers) . . . . . . . . . . . . . . . .32
Appendix C: Example usage of MGCP extension packages . . . . .33
C.1 Setting Labels on Phone. . . . . . . . . . . . . . . .33
C.2 Activating a Feature on a Feature Key. . . . . . . . .33
C.3 Generating a Call using Feature Key as a Line Key. . .35
C.4 Determining Make and Model of a Phone. . . . . . . . .38
Appendix D: BNF Description of X-UA Parameter. . . . . . . . .39
Full Copyright Statement . . . . . . . . . . . . . . . . . . .411. Introduction ✨
Okay so, the Media Gateway Control Protocol (MGCP) Version 1.0 is the protocol for controlling Voice over IP Telephony Gateways from external call control elements 📞 Those elements are called Media Gateway Controllers, and MGCP assumes the gateways can support collections of endpoints 🦋 An endpoint type called an "analog line" can act as a client interface for a basic analog telephone unit. The packages defined so far for handling events and signals only allow a basic level of audio connection and signaling to those endpoints 🙄 So to handle the more advanced stuff on business phones, like feature keys, speaker phones, and displays, we need to define extra packages as extensions to MGCP 🔥
These packages work together with the packages already defined in RFC 2705 (Media Gateway Control Protocol Version 1.0) [1], and they let an MGCP Call Agent control business phone endpoints 💖
The MGCP extension packages defined here are:
- Feature Key Package 🔑
- Groups events and signals tied to the extra keys on business phones that aren't DTMF and aren't locally implemented. These include:
- Feature Key event, to map key numbers to features.
- Key State signal, to show the state of feature keys.
- Set Label signal, to display a label on the LCD next to a feature key.
- Groups events and signals tied to the extra keys on business phones that aren't DTMF and aren't locally implemented. These include:
- Business Phone Package 📱
- Groups signals that aren't about feature keys, including:
- Force Off-hook and Force On-hook signals, for application integration with speaker phone capabilities.
- Beep signal, to play a beep on the phone.
- Groups signals that aren't about feature keys, including:
- Display XML Package 🖥️
- Used to send XML [2] script data to and from the phone, to control the display and assign functions to the display soft-keys for event reporting. These include:
- XML event, to report user input or selection.
- XML signal, to render text on the LCD display.
- Used to send XML [2] script data to and from the phone, to control the display and assign functions to the display soft-keys for event reporting. These include:
There's also an MGCP experimental parameter defined here 🧪
- User Agent Parameter 🪪
- Used to determine the make and model of a phone.
1.1. General Information 🎀
A generic business phone usually has a bunch of features that give you extra functionality for a work environment 💼 Past the basic handset and dial pad, a business phone may optionally include some fixed buttons, line keys, and programmable feature keys, plus an LCD display and soft-keys 💅
Some examples of stuff that can be on a business phone:
- Speaker phone microphone and speaker
- Speaker phone button and light
- Messages button and light
- Redial button
- Volume up and down buttons
- Hold button and light
- Transfer button and light
- Forward button and light
- Conference button and light
- Microphone mute button and light
- Multiple feature keys with lights
- Multi-line LCD Display
- Multiple soft-keys next to the LCD display
- Navigation keys
Examples of fixed button functions are 'hold', 'transfer', 'redial', 'conference', 'call-logs', 'directories', and 'messages' 📒 Fixed buttons may vary from phone to phone 🙃 The packages here would let these be reported to a Call Agent, but the Call Agent would also need to figure out which feature key number goes with a particular pre-assigned function 🧠
Okay, here's the big picture 🖼️ MGCP runs on a call control setup where the call control "intelligence" lives outside the Gateways, in external call control elements. So programming the feature keys is handled by the Call Agent 👑 If the user presses the 'hold' button, the phone just reports the key number. Then it's up to the Call Agent to recognize that this feature key is assigned to 'hold' and to provide that functionality 💀
1.2. Objectives 🌸
These are the high-level objectives that were considered when the packages were made 📋
- Provide a minimum set of extension packages to the MGCP Version 1.0 protocol, so applications can use generic business phone capabilities.
- Provide event and control extensions at a low enough level for an application to implement generic business phone functions without generating excessive or redundant data traffic. (For example, sending feature key info on both press and release would be a "don't care" for a Call Agent. All it cares about is that the key was pressed 🔑)
- Provide a way to interface with LCD displays, with enough flexibility for a variety of application needs and the different kinds of displays out there 🖥️
2. MGCP Packages for Business Phones 📦
The following packages should be implemented for business phones 💖 The G, D, L, and H packages are defined in RFC 2705 [1]. Packages KY, BP, and XML are defined in this specification ✨
______________________________________________________
| Package | Name | Defined |
|______________________________|_________|_____________|
| Generic Media Package | G |in RFC 2705 |
| DTMF package | D |in RFC 2705 |
| Line Package | L |in RFC 2705 |
| Handset Package | H |in RFC 2705 |
| Feature Key Package | KY |in this spec |
| Business Phone Package | BP |in this spec |
| Display XML Package | XML |in this spec |
|______________________________|_________|_____________|In the event tables for each package, there are five columns 📊 Here's what each one means:
- Symbol: the unique symbol used for the event.
- Definition: a short description of the event.
- R: an
xappears in this column if the Call Agent can request the event. - S: if nothing appears in this column for an event, the event can't be signalled on command by the Call Agent. Otherwise, these symbols identify the type of signal:
OO: On/Off signal. The signal stays on until the Call Agent requests it to turn off, and vice versa.TO: Timeout signal. The signal lasts for a given duration unless a new signal supersedes it.BR: Brief signal. The event has a short, known duration.
- Duration: specifies the duration of
TOsignals ⏱️
2.1 Feature Key Package ✨
Package Name: KY 🎀
The Feature Key Package is the bundle of events and signals for all the extra keys on business phones. Basically, it's the fancy-key starter pack 💅
____________________________________________________________________
| Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________|
| fk1-fk99 | Feature Key | x | |
| ks | Key State | | OO |
| ls | Set Label | | OO |
|__________|____________________________|_____|______________________|Feature Key (fk1-fk99) 🔑
okay so these events cover every key on the phone that isn't a DTMF key or a locally handled function (like volume) 🔊. The mapping of fk number to physical key is expected to vary between phones, so don't assume fk5 is the same button everywhere 🙈
Note: Some people have suggested parameterizing the fk event, so you'd send an RQNT withR: KY/fkand get an NTFY withO: KY/fk(1). But this is problematic 💀 It's desirable to request only the keys that can be pressed in a given state, so a mis-pressed button can't cancel a timeout signal, and it also cuts down on message traffic. This isn't possible within the confines of MGCP, because requested events can't be parameterized.
Key State (ks) 💡
This signal tells the phone what state a feature key is in. Phones without this capability should ignore it 🫶
It has two parameters: the key number and the state. The key number maps directly to the feature key number. The state is a high-level description, which lets each phone show it differently. For example, Phone A might have a multi-color LED on its feature keys that blinks at different cadences, while Phone B has an LCD beside the keys that can show text or icons 🌈 It's up to each phone vendor to decide how the state gets shown. Iconic, honestly.
The following states are used:
______________________
| State | Definition |
|_______|______________|
| en | enabled |
| db | disabled |
| id | idle |
| dt | dial tone |
| cn | connected |
| dc | disconnected |
| rg | ringing |
| rb | ringback |
| ho | holding |
| he | held |
|_______|______________|For example: an RQNT with S: KY/ks(5,en) makes the indicator for fk5 show that it's enabled ✅ And an RQNT with S: KY/ks(2,rg) makes the indicator for fk2 show that it's ringing 🔔
"en" state 🟢
The associated feature is enabled. This is for keys that turn a feature on or off, like "Do Not Disturb" 🌸
"db" state ⭕
The associated feature is disabled. This is for keys that turn a feature on or off, like "Do Not Disturb" 🙅♀️
"id" state 🫧
The specified line appearance is idle, available for a call 📞
"dt" state 🎶
The specified line appearance is providing dial tone.
"cn" state 📲
The specified line appearance is actively in a call, in the connected state 💜
"dc" state 📴
The specified line appearance is disconnected, but the corresponding line is still active (the user is still offhook). Main character energy in limbo 😭
"rg" state 🛎️
The specified line appearance is terminating an incoming call, in the ringing state.
"rb" state 📤
The specified line appearance is originating an outgoing call, in the ringing-back state.
"ho" state 🤲
The specified line appearance is in the holding state, with the far end held.
"he" state 🫴
The specified line appearance is in the held state, with the far end holding.
Set Label (ls) 🏷️
This signal sets the label on a key. It's used for phones that have an LCD next to the feature keys. Phones without this capability should ignore it 🙈
It has 2 parameters: the key number and the label. The key number maps directly to the feature key number. The label is free-form text, limited by what the phone can display.
For example, an RQNT with S: KY/ls(1,2200) sets the label next to the fk1 feature key to the string "2200" (a phone extension) 📱✨
2.2 Business Phone Package 📠
Package Name: BP 💼
The Business Phone Package groups the signals that aren't about feature keys or displays. Think of it as the everything-else drawer 🧚
____________________________________________________________________
| Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________|
| hd | Force Offhook | | OO |
| hu | Force Onhook | | OO |
| beep | Beep | | BR |
|__________|____________________________|_____|______________________|Force Offhook (hd) 📞
This signal forces the phone offhook. If the phone has a speaker phone, it should be activated 🔊 The user can undo this just by hanging up 🙌
This can be used if a feature key causes a call to be initiated. Check out the sample call flow in Appendix C, it's giving instructions 📖
It can also be used for application integration! For example, a user could select a number in an application on their PC, and the phone would be forced offhook and a call initiated 💻✨
Force Onhook (hu) 📴
This signal forces the phone onhook. It can be used when the far end disconnects, or if a feature key causes a call to be terminated 🫶
Beep (beep) 🔔
Plays a beep on the phone. Simple, iconic, no notes 🫧
2.3 Display XML Package 🖥️
Package Name: XML 🌷
The XML Package contains one event/signal, and its whole job is carrying XML data to and from the phone 💜
_____________________________________________________________________
| Symbol | Definition | R | S Duration |
|__________|____________________________|_____|______________________|
| xml | XML Data | x | OO |
|__________|____________________________|_____|______________________|XML Data (xml) 📄
As an event: if this event is requested in an RQNT with R: XML/xml, any posts of data from an XML script get sent back in an NTFY with O: XML/xml(post data here) 📬
As a signal: the parameterized data points to a URL for an XML script (which might be local), along with substitution values that depend on which XML script is selected. See section 5 for more information 🌈
3. Endpoint Naming and Phone Type Determination 🧭
Because the display state can be asynchronous from the signaling state of the phone, it's desirable to address the display as its own separate MGCP endpoint 💅
For example, say a call comes in, and the display shows a choice to redirect the caller straight to voice-mail. Picking that option on the display would cause an XML post to happen, which cancels any timeout signals (the ringing) 📞🚫
To keep these scenarios simple, the related display is expected to have a different MGCP endpoint name. You make it by putting a prefix in front of the phone endpoint name. The prefix used shall be disp/ 🎀
For example, if the phone endpoint is named ep1@foo.whatever.net, the display endpoint would be named disp/ep1@foo.whatever.net 🦋
The Call Agent must be able to figure out which feature key number matches a particular pre-assigned function. For example, one phone might have the pre-assigned functions 'redial' and 'hold' mapped to feature keys fk1 and fk23, respectively. Another phone might not report fk23 at all, and have the pre-assigned function 'transfer' mapped to fk1 🤯 Also, since the programming of feature keys lives in the Call Agent, a user interface that lets people program these keys must know which keys the phone supports, so the Call Agent can request the right feature keys 🧠
Figuring out these basic capabilities must happen the moment the phone sends its first RSIP message to a Call Agent ⏰ It might be possible to define packages with events and signals that allow an exhaustive discovery of a phone's layout, but a simpler, more reasonable approach is for the Call Agent to discover the make and model of the phone, and then work out its capabilities from that 💖 To do this, an experimental parameter, X-UA, has been introduced for use in the Requested-Info field (F:) of the AUEP method. The response to X-UA is expected to be a string that uniquely identifies the make and model of the phone 🪞
Note that per RFC 2705, a Gateway must ignore experimental parameters prefixed as X- that it can't support, rather than responding with an error code such as 511 (Unrecognized extension) 🙃 See the sample call flow in Appendix C.
4. Functions that should be Locally Implemented 🏠
Some functions should be implemented locally on the Gateway. They're listed in the following sections 🍓
4.1 Volume Control 🔊
Volume for ringing, handset, and speaker phone should be implemented locally on the Gateway. Hands off the volume knob, Call Agent 🙌
4.2 Audio Path 🎧
If the phone includes a speaker phone, activating the speaker phone from the idle state should generate an offhook (L/hd) event 📞 The user should then be able to switch to handset mode by lifting the handset, and be able to switch back to speaker phone mode without any interaction with the Call Agent 🔄 De-activating the speaker phone with the handset on-hook should generate an onhook (L/hu) event 📴
4.3 Microphone mute button and light 🎤
If the phone includes a microphone mute button and (optionally) an associated indicator (e.g., light), the functionality of these items should be implemented locally on the Gateway. Mute energy, 100% locally handled 🤫✨
5. XML Package Support 🌈
Not all business phones have the same display and keypad capabilities 🎹 To support these different devices in a consistent way, this section outlines an XML framework that drives the phone. In this framework, the Call Agent pushes XML requests to the Gateway using MGCP signals, and those XML requests point to the XML document that should be rendered on the phone 🖼️
When a user types in data or makes a selection from a display, the Gateway "posts" an XML request back to the Call Agent using MGCP events 📤💅
5.1 XML Documents 💅
okay so when an XML signal request gets sent to an endpoint, it's basically saying "hey, these are the XML docs you need to process" 🎀 those docs are made of tags that are a subset of the Wireless Markup Language (WML) [3], plus a few non-WML extras. The tags say what to display and which XML events can get reported back when the user does something 👀
Each XML document is called a card and it defines one user interaction. A group of cards is a deck, and one or more decks make up an application 🧚 Cards control soft key behavior and display behavior. They map onto components that build a basic graphical user interface on the display phone. Based on the requirements, these are the components we need:
- Input box: allows user input, including editing capabilities, via the keypad ⌨️
- Enumerated list box: lets the user pick one item from a list 📋
- Itemized list box: lets the user pick an item using a soft key 🔘
- Text box: shows read-only text to the user 📖
- Echo box: displays things but doesn't process user input 🪞
A card can have these properties:
- Timed content (e.g., card expiration) ⏰
- Static content (e.g., text) 🪨
- Dynamic content (e.g., call timers/time) 🌈
Cards can also hold variables that get swapped out for values given in an XML request. more on that in section 5.2 ✨
okay this part is a little tricky 🙈 the XML scripts that handle the display sometimes need the same keys the phone uses. like, the display might show an enumerated list where you pick an item by pressing its number on the dial pad. so all user key presses have to go through the XML component layer first. the display layer either eats the key press or passes it along to the phone layer 💖
so the code handling key presses shows the key press to the display code first. if the display code doesn't "use" it, then it goes to the phone code. basically the XML scripts get first dibs on key presses 👑
5.2 XML Requests 🦋
the XML framework uses MGCP as its transport for making requests to the display phone 📡 MGCP also carries the asynchronous events coming back from the display phone, like when an item gets selected or the user types some text 💜
an XML request goes to an endpoint using the XML/xml signal. it looks like this:
S: XML/xml(<url>?<card>?$<variable1>=<value1>?$<variable2>=<value2>)the first part of the signal parameter is a URL to the deck. if there's no scheme, the deck is assumed to live locally on the phone 🏠 some examples:
ftp://server.company.com/deck1?card1?$var1=val1
http://www.company.com/deck1?card1?$var1=val1
file://deck1?card1?$var1=val1
deck1?card1?$var1=val1after the URL you get a card identifier and a list of variable/value pairs. the card identifier says which card in the deck to show 🎯
here's the fun part 🌸 the variable/value pairs get substituted into the deck before it's rendered to the display. that makes the variables deck-scoped, which means any variable that isn't defined in the requested card has to be filled in by other cards in the same deck, if it's defined there 🧩
for example, a deck might have these cards:
<card id="one">
<p>$line1</p>
<timer value="2"/>
<do type="ontimer">
<go href="#two"/>
</do>
</card>
<card id="two">
<p>$line2</p>
</card>and an XML request could look like this:
S: XML/xml(deck?one?$line1=abc$line2=xyz)after substitution, the deck looks like this:
<card id="one">
<p>abc</p>
</card>
<card id="two">
<p>$line2</p>
</card>once the substitution is done, the card gets rendered. oh and if a parameter variable doesn't exist anywhere in the deck, it should be ignored 🙃
when card two gets invoked from card1 because of the timeout action, card two's variables get substituted with the values that were passed in the request to card one. so card two ends up looking like this:
<card id="two">
<p>xyz</p>
</card>5.3 XML Request History 🕰️
so when a user cancels a card and needs to navigate back, the XML layer has to keep a last-in-first-out history of the requests made for the endpoint 📚 (check out the <prev> tag definition in section 5.5.13 for more on this one 💅)
5.4 XML Events 🔔
whenever the XML layer figures out that an event happened, it reports it using the MGCP observed event field 👀
O:
XML/xml(post?<deck>?<card>?<variable1>=<value1>?<variable2>=<value2>)so the event parameter carries the deck and card that generated the event, plus the data the Call Agent needs to process. the data comes through as a list of variable/value pairs 🎁
for the Gateway to actually generate the XML event, the Call Agent has to request it using the requested events field:
R: XML/xmlthis requested event should be combined with the signal request in an RQNT ✨
5.5 XML Tags 🏷️
any XML implementation must, at a minimum, support the XML tags in the table below 🫶 every tag has a terminator of the form </tag> to mark where it ends. the XML grammar lives in Appendix A 📖
_____________________________________________________________________
| Name | Usage |
|_______________|_____________________________________________________|
| <xml> | Marks the beginning of a deck. |
|_______________|_____________________________________________________|
| <card> | Marks the beginning of a card. |
|_______________|_____________________________________________________|
| <p> | Marks the beginning of a paragraph. |
|_______________|_____________________________________________________|
| <select> | Defines a list of items that may be selected (an |
| | enumerated or itemized list box). |
|_______________|_____________________________________________________|
| <option> | Used in conjunction with the <select> tag to |
| | specify an individual item that may be selected. |
|_______________|_____________________________________________________|
| <input> | Marks the beginning of user input (an input box). |
|_______________|_____________________________________________________|
| <echo> | Marks the beginning of an echo box. |
|_______________|_____________________________________________________|
| <calltimer> | Call Timer. An incremental timer usually used to |
| | maintain the duration of a call. |
|_______________|_____________________________________________________|
| <timer> | Card timer. Allows an event to be generated when |
| | the timer expires. |
|_______________|_____________________________________________________|
| <time> | A tag indicating the current time. |
|_______________|_____________________________________________________|
| <do> | Event consumer. |
|_______________|_____________________________________________________|
| <go> | Used in conjunction with the <do> tag to indicate |
| | a new page to be displayed. |
|_______________|_____________________________________________________|
| <prev> | Used in conjunction with the <do> tag to indicate |
| | that the previous card in the history should be |
| | displayed. |
|_______________|_____________________________________________________|most of these tags have attributes 🎀 and each attribute is one of these types: String, Time, Enum, Align, Action or URL 💖
_______________ _____________________________________________________
| Type | Format |
|_______________|_____________________________________________________|
| String | Any string. May not contain any white spaces |
| | (tab, space or newline). |
|_______________|_____________________________________________________|
| Time | A string of the format hh:mm:ss where hh indicates |
| | the hour (24-hour format), mm indicates the |
| | minutes and ss indicates the seconds. |
|_______________|_____________________________________________________|
| Enum | Enumeration. A list of acceptable string values. |
|_______________|_____________________________________________________|
| Align | Indicates text alignment (left justified, centered |
| | or right justified). Valid values are: left, |
| | center, right. The default value is: left. |
|_______________|_____________________________________________________|
| Action | Defines a string to be sent to the Call Agent. |
| | This string has the format: |
| | post?%var1[=%val1[?%var2[=%val2]]] |
| | where variables that should be substituted before |
| | sending the string to the Call Agent begin |
| | with a '%'. |
| | The tags that make up the card determine what |
| | variables are available to this string. See the |
| | following sections for variables that are defined |
| | for each tag. |
|_______________|_____________________________________________________|
| URL | The URL may have take several forms: |
| | 1. #<card> to indicate another card within |
| | the same deck |
| | 2. A string of type Action |
| | 3. #<prev> to indicate the previous card in |
| | the history |
|_______________|_____________________________________________________|5.5.1 XML Tag 🌷
the <xml> tag has to be the first tag in the deck, since it marks where the deck begins 🎬 this tag has no attributes, so there's nothing extra to set up 🫧
5.5.2 Card Tag 🃏
the <card> tag marks the start of a new card ✨ it has this attribute:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| Id | String | Defines the card identifier. |
| | | This identifier is referenced |
| | | in XML requests. |
|_______________|_____________________|_______________________________|5.5.3 P Tag 💜
the <p> tag marks the start of a new paragraph 📝 it has these attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values (default) | Usage || _______________ | _____________________ | _______________________________ |
|---|---|---|
| Mode | Enum: wrap/nowrap | Specifies whether the |
| (wrap) | paragraph wraps or is | |
| truncated when it extends past | ||
| the display width. | ||
| _______________ | _____________________ | _______________________________ |
| Align | Align | Specifies alignment of the |
| paragraph. | ||
| _______________ | _____________________ | _______________________________ |
5.5.4 Select Tag 🎀
Okay so the <select> tag is the bouncer for a list of stuff you can pick from 💅 It marks where the list starts, and every item in it gets defined with an <option> tag, which we'll get to in section 5.5.5 🧚
Here are its attributes, bestie:
_______________ _____________________ _______________________________
|Attribute Name | Values (default) | Usage |
|_______________|_____________________|_______________________________|
| type | Enum: item/enum | Specifies the type of list: |
| | (enum) | itemized or enumerated. An |
| | | itemized list maps options to |
| | | soft keys. |
|_______________|_____________________|_______________________________|
| name | String | Specifies name of the list. |
| | | This attribute is available to|
| | | any Action string in the card |
| | | by using the %name variable. |
|_______________|_____________________|_______________________________|
| iname | String | Defines an index variable with|
| | | the specified name. This |
| | | variable is used in the |
| | | <option> tag to specify the |
| | | index of an item that is |
| | | selected. The value of this |
| | | attribute is available to any |
| | | Action string in the card by |
| | | using the %iname variable. The|
| | | value of the index variable is|
| | | available by using the |
| | | %<string value> variable. |
| | | See examples below. |
|_______________|_____________________|_______________________________|5.5.5 Option Tag 🌸
When it's paired with <select>, the <option> tag is the one that defines a single item you can pick from that list ✨ Its attributes are:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| value | String | Defines the value of the item.|
| | | This is used when reporting an|
| | | event to the Call Agent. The |
| | | value of this attribute is |
| | | available to any Action string|
| | | in the card by using the |
| | | %value variable. |
|_______________|_____________________|_______________________________|
| onpick | Action | Defines the string to be sent |
| | | to the Call Agent when the |
| | | item is selected. |
|_______________|_____________________|_______________________________|5.5.6 Input Tag 💜
The <input> tag says that user input is required, so it's basically asking for your attention 🫶 Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| name | String | Specifies the name of the |
| | | input tag. The value of this |
| | | attribute is available to any |
| | | Action string in the card by |
| | | using the %name variable. |
|_______________|_____________________|_______________________________|
| type | Enum: password/text | Specifies whether the input |
| | (text) | box is in password mode |
| | | (password) or normal mode |
| | | (text). When in password mode,|
| | | user input should be masked. |
|_______________|_____________________|_______________________________|5.5.7 Echo Tag 🦋
The <echo> tag also means user input is required 👀 The twist is that any keypad activity gets reported to the XML layer but not consumed when this tag is in use. Its attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values (default) | Usage |
|_______________|_____________________|_______________________________|
| mode | Enum: on/off (on) | Specifies whether the echo box|
| | | is in password mode (off) or |
| | | normal mode (on). When in |
| | | password mode, user input |
| | | should be masked. |
|_______________|_____________________|_______________________________|
| align | Align | Specifies the alignment of the|
| | | echo tag. |
|_______________|_____________________|_______________________________|5.5.8 Calltimer Tag ⏰
The <calltimer> tag is used when you want an incrementing timer on the display ⏰ Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| value | Time | Specifies the initial value of|
| | | the call timer. |
|_______________|_____________________|_______________________________|
| align |Align | Specifies the alignment of the|
| | | call timer. |
|_______________|_____________________|_______________________________|5.5.9 Time Tag 🍓
The <time> tag shows the current time on the phone, very simple, very iconic 🕰️ Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| align | Align | Specifies the alignment of the|
| | | time. |
|_______________|_____________________|_______________________________|5.5.10 Timer Tag ⏳
The <timer> tag sets up a timeout for the card 💅 When the timeout happens, the XML Layer goes looking for the right <do> tag so it knows what to do next 👑 Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values | Usage |
|_______________|_____________________|_______________________________|
| Value | Time | Specifies the initial value of|
| | | the timer. The timer will |
| | | decrement the time until it |
| | | reaches zero at which point |
| | | the <do> tag is consulted. |
|_______________|_____________________|_______________________________|5.5.11 Do Tag 🎯
The <do> tag is for an action that runs when a specified event happens 🔥 Right now it can handle three events: prev, ontimer and accept.
prev means the user asked to cancel the current card.
ontimer means the timer set up with the <timer> tag has expired.
accept means the user is done typing on the keypad.
Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values (default) | Usage |
|_______________|_____________________|_______________________________|
|Type | Enum: | Indicates the event on which |
| | prev/ontimer/accept | the tag operates. |
|_______________|_____________________|_______________________________|5.5.12 Go Tag 🌈
The <go> tag teams up with the <do> tag to name a URL that gets loaded when the event fires 🚀 Attributes:
_______________ _____________________ _______________________________
|Attribute Name | Values (default) | Usage |
|_______________|_____________________|_______________________________|
| href | URL | Defines the URL of the next |
| | | XML page. |
|_______________|_____________________|_______________________________|5.5.13 Prev Tag 🔙
The <prev> tag also pairs with <do>, and it means the previous page in the display history should be rendered 🦋 This tag has no attributes, so there's no table, just vibes ✨
6. Security Considerations 🔒
Okay, this one's short but serious 😤 This extension introduces no new security considerations beyond those discussed in RFC 2705 [1]. Anything security-related that matters here already lives in that RFC, so keep it in your back pocket 💀
7. Acknowledgements 🫶
Huge thanks to these companies and individuals for sharing their experience and thoughts for this document 💖
Arnie Chencinski, Sylantro Systems
Bill Foster, Cisco Systems
Howard Holgate, Cisco Systems
John Weald, Sylantro Systems
Michael Chack, Sylantro Systems
Naga Surendran, Sylantro Systems
Sunil Veluvali, Sylantro Systems8. References 📚
- [1] Arango, M., Dugan A., Elliot, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP)" RFC 2705, October 1999.
- [2] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C Proposed Recommendation, February 10, 1998.
- [3] "Wireless Application Protocol Wireless Markup Language Specification Version 1.2", WAP Forum, November 1999.
9. Authors' Addresses ✍️
Ashok Srinath
Sylantro Systems
910 E. Hamilton Avenue
Campbell, Ca. 95008
EMail: Ashok.Srinath@sylantro.com
Gil Levendel
Sylantro Systems
910 E. Hamilton Avenue
Campbell, Ca. 95008
EMail: Gil.Levendel@sylantro.com
Kent Fritz
Sylantro Systems
910 E. Hamilton Avenue
Campbell, Ca. 95008
EMail: Kent.Fritz@sylantro.com
Raghuraman Kalyanaram
Wipro Systems
Keonics Electronic City
Hosur Road, Bangalore-561 229, India
EMail: Raghuraman.Kal@wipro.comAppendix A: BNF description of XML grammar ✨
okay so the parser is case sensitive, bestie 💅 here are the conventions we're vibing with:
- lowercase stuff = terminals 🌸
- ALL CAPS strings = non-terminals 🎀
[A | B]means A or B has to show up right there 🫶\t,\n,\r, and blank space are separators 🦋
______________ _ ____________________________________________________
|ACTION |:|<go href="HREFSTRING"/> | <prev/> |
|______________|_|____________________________________________________|
|ALIGN |:|Align=["left" | "right" ] |
|______________|_|____________________________________________________|
|CALLTIMER |:|<calltimer CALLTIMERATTRS/> |
|______________|_|____________________________________________________|
|CALLTIMERATTRS|:|CALLTIMERATTR | CALLTIMERATTR CALLTIMERATTRS |
|______________|_|____________________________________________________|
|CALLTIMERATTR |:|value=STRING | ALIGN |
|______________|_|____________________________________________________|
|CARDS |:|CARD | CARD CARDS |
|______________|_|____________________________________________________|
|CARD |:|<card id=STRING> CLUSTERS </card> |
|______________|_|____________________________________________________|
|CARDREFERENCE |:|#STRING |
|______________|_|____________________________________________________|
|CLUSTERS |:|CLUSTER | CLUSTER CLUSTERS |
|______________|_|____________________________________________________|
|CLUSTER |:|CONTROL | TIMER | ECHO | PARAGRAPH COMPONENTS </p> |
|______________|_|____________________________________________________|
|COMPONENTS |:|COMPONENT | COMPONENT COMPONENTS |
|______________|_|____________________________________________________|
|COMPONENT |:|TEXT | INPUTBOX | SELECTBOX | STIME | CALLTIMER |
|______________|_|____________________________________________________|
|CONTROL |:|<do CONDITION> ACTION </do> |
|______________|_|____________________________________________________|
|CONDITION | |type=["accept" | "prev" | "ontimer"] label=STRING | |
| | |type=["accept" | "prev" |"ontimer"] |
|______________|_|____________________________________________________|
|DIGITS |:|DIGIT | DIGIT DIGITS |
|______________|_|____________________________________________________|
|DIGIT |:|0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|______________|_|____________________________________________________|
|DECK |:|<xml id=STRING> CARDS </xml> |
|______________|_|____________________________________________________|
|ECHO |:|<echo/> | <echo ECHOMODE/> |
|______________|_|____________________________________________________|
|ECHOMODE |:|mode=["on" | "off"] |
|______________|_|____________________________________________________|
|HREFSTRING |:|CARDREFERENCE | POSTSTRING |
|______________|_|____________________________________________________|
|INPUTBOX |:|<input INPUTATTRS/> |
|______________|_|____________________________________________________|
|INPUTATTRS |:|INPUTATTR | INPUTATTR INPUTATTRS |
|______________|_|____________________________________________________|
|INPUTATTR |:|name=STRING | type=["text" | "password"] | |
| | | value=STRING |
|______________|_|____________________________________________________|
|NAMEVALUES |:|NAMEVALUE | NAMEVALUE?NAMEVALUES |
|______________|_|____________________________________________________|
|NAMEVALUE |:|NAMEVALUEELEM | NAMEVALUEELEM=NAMEVALUELEM |
|______________|_|____________________________________________________|
|NAMEVALUELEM |:|%TEXT | TEXT |
|______________|_|____________________________________________________|
|OPTIONS |:|OPTION | OPTION OPTIONS |
|______________|_|____________________________________________________|
|OPTION |:|<option value=STRING onpick=HREFSTRING> TEXT |
| | | </option> |
|______________|_|____________________________________________________|
|PARAGRAPH |:|<p TXTFORMAT> | <p> |
|______________|_|____________________________________________________|
|POSTSTRING |:|post?%deck?%id?NAMEVALUES | post?NAMEVALUES |
|______________|_|____________________________________________________|
|SELECTBOX |:|<select SELECTATTRS> OPTIONS </select> |
|______________|_|____________________________________________________|
|SELECTATTRS |:|SELECTATTR | SELECTATTR SELECTATTRS |
|______________|_|____________________________________________________|
|SELECTATTR |:|name=STRING | iname=STRING | type="item" |
|______________|_|____________________________________________________|
|STIME |:|<time STIMEATTRS/> |
|______________|_|____________________________________________________|
|STIMEATTRS |:|STIMEATTR | STIMEATTR STIMEATTRS |
|______________|_|____________________________________________________|
|STIMEATTR |:|value=STRING | format=STRING | ALIGN |
|______________|_|____________________________________________________|
|STRING |:|Any string enclosed in a pair of quotes ("") |
|______________|_|____________________________________________________|
|TEXT |:|TEXTELEM | TEXTELEM TEXT |
|______________|_|____________________________________________________|
|TEXTELEM |:|any string outside of the < .. > and which consists |
| | |of any symbols except '<' and '\n' |
|______________|_|____________________________________________________|
|TIMER |:|<timer value="DIGITS"/> |
|______________|_|____________________________________________________|
|TXTFORMAT |:|ALIGN | TXTMODE | ALIGN TXTMODE | TXTMODE ALIGN |
|______________|_|____________________________________________________|
|TXTMODE |:|mode=["wrap" | "nowrap"] |
|______________|_|____________________________________________________|
______________ _ ____________________________________________________
| | |\t, \n, \r, blank space are separators. |
|______________|_|____________________________________________________|Appendix B: Sample XML Documents, Renderings and Events ✨
this part shows off some sample XML docs and how they get translated onto a business phone with a simple LCD display 📞🩷
B.1 Sample Deck 1 (Itemized List Box) 🍓
here's a tiny deck with one card that makes a super simple main menu using an itemized list box:
<xml>
<card id="home">
<p mode="nowrap">$dn <time align="right"></time>
<select type="item" name="Menu" iname="StrMenu">
<option value="1" onpick="post?%deck?%id?%name=%value">MENU</option>
</select>
</p>
</card>
</xml>the card (home) has three components, ngl so organized:
- a paragraph (
<p>). the paragraph holds a variable ($dn) that shows the phone's extension 📱 - a clock (
<time>). the clock is aligned to the right ⏰ - an itemized list (
<select>) with one item in it (MENU) 💅
an XML request for this deck and card might look like:
S: XML/xml(deck?home?$dn=2344)after variable substitution, the phone may render the XML to the display like this:
--------------------
|2344 11:59|
| MENU |
--------------------
[XX] [XX] [XX]so MENU maps to the first soft key below the display. if the user presses the first soft key, this event gets generated:
O: XML/xml(post?basic?home?Menu=1).B.2 Sample Deck 2 (Enumerated List Box) 🎀
the next deck defines a simple enumerated list box card 🦋
<xml>
<card id="gelist">
<p>$title
<select name="x-name" iname="x-iname">
<option value="$value1"
onpick="post?%deck?%id?%name=%value?%iname=%x-iname">$opt1
</option>
<option value="$value2"
onpick="post?%deck?%id?%name=%value?%iname=%x-iname">$opt2
</option>
<option value="$value3"
onpick="post?%deck?%id?%name=%value?%iname=%x-iname">$opt3
</option>
<option value="$value4"
onpick="post?%deck?%id?%name=%value?%iname=%x-iname">$opt4
</option>
<option value="$value5"
onpick="post?%deck?%id?%name=%value?%iname=%x-iname">$opt5
</option>
</select>
</p>
<do type="prev">
<prev></prev>
</do>
</card>
</xml>the card (gelist) contains four components, bestie 🌈:
- a paragraph (
<p>). the paragraph has a title variable that describes what's in the list 🧚 - an enumerated list (
<select>) with five items. when an item gets selected, the XML layer sends the XML/xml event to the Call Agent 📤 - a do tag (
<do>) that says when a "previous" event has occurred, go to the previous page (<prev>) 🔙
an XML request for this deck and card might look like:
S: XML/xml(list?gelist?$title=Select a Car?
$value1=Item1?$opt1=Porsche?
$value2=Item2?$opt2=Chevrolet?
$value3=Item3?$opt3=Toyota?
$value4=Item4?$opt4=Daewoo?
$value5=Item5?$opt5=Yugo)after variable substitution, the phone may render the XML to the display like this:
--------------------
|SELECT A CAR |
|1. Porsche v|
--------------------
[XX] [XX] [XX]so the display may scroll to show the extra items that can be selected, and the keypad '1', '2', etc may be used to pick an item. these details are phone-specific 🫶 for instance, on a bigger 4-line display with navigation keys, the XML may be rendered like this:
--------------------
|SELECT A CAR |
|=>Porsche<= |
| Chevrolet |
| Toyota v|
--------------------when the user selects item 1, this message gets sent to the Call Agent:
O: XML/xml(post?list?gelist?x-name=Item1?x-iname=1)B.3 Sample Deck 3 (Text Box) 💜
this one shows how to make a simple text box, no drama 🙈
<xml>
<card id="generic">
<p>$cldpty</p>
<p>CALL FAILED</p>
</card>
</xml>the card (generic) has two paragraphs. no selectable list, input box or echo box means it's a text box, iykyk ✨
an XML request for this deck and card might look like:
S: XML/xml(deck?generic?$cldpty=John Doe)after variable substitution, the phone may render the XML to the display like this:
--------------------
|JOHN DOE |
|CALL FAILED |
--------------------
[XX] [XX] [XX]B.4 Sample Deck 4 (Echo Box) 🧚♀️
this one shows how to make a simple echo box. the XML layer does not consume any keystrokes, which is giving main character energy 💖
<xml>
<card id="getdigits">
<p>Dial Number:</p>
<echo mode="$mode" align="left"/>
</card>
</xml>the card (getdigits) has a paragraph of text and an echo box 🌸
an XML request for this deck and card might look like:
S: XML/xml(deck?getdigits?$mode=on)after variable substitution, the phone may render the XML to the display like this:
--------------------
|DIAL NUMBER: |
| |
--------------------
[XX] [XX] [XX]all user input is displayed but not consumed by the XML layer 🦋✨
B.5 Sample Deck 5 (Input Box)
okay bestie, this one is a basic input box, and it's giving main character energy 💅✨
<xml>
<card id="ginput">
<p>$title
<input name="x-name"/>
</p>
<do type="accept">
<go href="post?%deck?%id?%name=%value"/>
</do>
<do type="prev">
<prev></prev>
</do>
</card>
</xml>so the card (ginput) has three things going on 🎀
- A paragraph
<p>. It holds a title. - An input box
<input>. It eats keypad events and reports them once the input is complete 🔥 - Two event handlers
<do>. The first one handles the accept event, which means the user is done typing and an observed event gets posted to the Call Agent 💌 The second one handles the prev event, which means the user wants to go back to the previous card 🔙
here's what an XML request for this deck and card might look like:
S: XML/xml(deck?ginput?$title=Enter Digits:)after the variable substitution, the phone might render it on the display like this 🌸
--------------------
|ENTER DIGITS: |
|_ |
--------------------
[XX] [XX] [XX]it's up to each business phone implementation to decide which soft keys or keypad keys map to things like "backspace", "reset line", etc. that part is totally their call 🤷♀️
B.6 Sample Deck 6 (Timers)
to show off timers and deck-scoped variable substitution, we've got a two-card deck 🧚
<xml>
<card id="connected1">
<timer value="$tvalue"/>
<p mode="nowrap">$cldpty
<select type="item" name="x-name" iname="x-iname">
<option value="1"
onpick="post?TRNSINIT">TRNS
</option>
<option value="2"
onpick="post?CONFINIT">CONF
</option>
<option value="3"
onpick="post?%deck?%card?%name=%value">MENU
</option>
</select>
</p>
<do type="ontimer">
<go href="#connected2"/>
</do>
</card>
<card id="connected2">
<p mode="nowrap">
<calltimer value="$calltimer" align="right"/>
<select type="item" name="x-name">
<option value="1"
onpick="post?TRNSINIT">TRNS
</option>
<option value="2"
onpick="post?CONFINIT">CONF
</option>
<option value="3"
onpick="post?%deck?%card?%name=%value" >MENU
</option>
</select>
</p>
</card>
</xml>so when the timer runs out in connected1, it fires an ontimer event ⏰ the <do> tag catches that event and makes the XML layer load the card with the identifier connected2. iconic 👑
an XML request for these cards might look like:
S: XML/xml(deck?connected1?$tvalue=00:00:05?$cldpty=John
Doe?$calltimer=00:00:00)and it might render as:
--------------------
|JOHN DOE |
| TRNS CONF MENU |
--------------------
[XX] [XX] [XX]once the timer expires, the XML layer loads the referenced page 🦋
--------------------
| 00:00:05|
| TRNS CONF MENU |
--------------------
[XX] [XX] [XX]Appendix C: Example usage of MGCP extension packages
C.1 Setting Labels on a Phone
okay so this is the setup step, and it should happen at startup 🚀 the first 2 keys are line appearance keys, and fk8 is a Do Not Disturb function.
Step 1. The Call Agent sets labels on several used keys.
RQNT 1876 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ls(1,2315), KY/ls(2,2315), KY/ls(8,DND)
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd
T: L/hu
K: 1873Step 2. The gateway responds.
200 1876 OKC.2 Activating a Function on a Feature Key
this one shows a feature key assigned to "Do Not Disturb" getting turned on and off again 🌙
Step 1. The user presses the DND key, which is assigned to fk8. The gateway sends NTFY to the Call Agent.
NTFY 957 d003@da-003.syltrx.com MGCP 1.0
K: 956
N: cs@sage.syltrx.com:2427
X: 45
O: KY/fk8Step 2. The Call Agent responds.
200 957 OKStep 3. The Call Agent sends a new RQNT, asking for the DND indicator to be activated. The Call Agent also re-sends the state of fk1, which is not actually necessary 🙈 It requests notifications for several feature keys: fk1 and fk2 are line keys, fk8 is DND, fk22 is redial, and fk23 is messages.
RQNT 2822 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,id), KY/ks(8,en)
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd
T: L/hu
K: 2743-2744Step 4. The gateway responds.
200 2822 OKStep 5. The user presses the DND key again to turn DND off. The gateway sends NTFY to the Call Agent.
NTFY 958 d003@da-003.syltrx.com MGCP 1.0
K: 957
N: cs@sage.syltrx.com:2427
X: 45
O: KY/fk8Step 6. The Call Agent responds.
200 958 OKStep 7. The Call Agent sends a new RQNT, and the DND indicator is deactivated.
RQNT 2823 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,id), KY/ks(8,db)
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd
T: L/hu
K: 2822Step 8. The gateway responds.
200 2823 OKC.3 Generating a Call using a Feature Key as a Line Key
this example is the full flow for dialing an extension after pressing a feature key that's set up as a line appearance key 📞✨
Step 1. The user presses fk1, which is configured as a line key.
NTFY 959 d003@da-003.syltrx.com MGCP 1.0
K: 958
N: cs@sage.syltrx.com:2427
X: 45
O: KY/fk1Step 2. The Call Agent responds.
200 959 OKStep 3. The Call Agent puts the line key into the "dial tone" state and forces the phone offhook.
RQNT 2833 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,dt), BP/hd
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu
T: L/hd
K: 2823Step 4. The gateway responds.
200 2833 OKStep 5. The Call Agent applies dial-tone.
RQNT 2834 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: L/dl, KY/ks(1,dt)
R: D/[0-9*#T](D), KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu
T: L/hd
D: (*xx|[1-7]xxx|9)Step 6. The gateway responds.
200 2834 OKStep 7. The user dials 2362. The gateway sends NTFY.
NTFY 960 d003@da-003.syltrx.com MGCP 1.0
K: 959
N: cs@sage.syltrx.com:2427
X: 45
O: D/2,D/3,D/6,D/2Step 8. The Call Agent responds.
200 960 OKStep 9. The Call Agent puts the line into the ringback state. Ringback isn't applied yet 🔔
RQNT 2836 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,rb)
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu
T: L/hd
K: 2833, 2834Step 10. The gateway responds.
200 2836 OKStep 11. The Call Agent creates the connection.
CRCX 2838 d003@da-003.syltrx.com MGCP 1.0
C: 10B
M: RECVONLYStep 12. The gateway responds.
200 2838 OK
I: 101
v=0
o=- 998557784 998557784 IN IP4 38.187.114.41
s=MGCP RTP Session
c=IN IP4 172.16.130.32
t=0 0
m=audio 1108 RTP/AVP 0
a=rtpmap:0 PCMU/8000Step 13. The Call Agent applies ringback.
RQNT 2841 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,rb), G/rt
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu
T: L/hdStep 14. The gateway responds.
200 2841 OKStep 15. The Call Agent modifies the connection.
MDCX 2848 d003@da-003.syltrx.com MGCP 1.0
C: 10B
I: 101
M: SENDRECV
K: 2841-2842
v=0
o=- 7960 7960 IN IP4 38.187.114.215
s=MGCP Call
c=IN IP4 172.16.130.31
t=0 0
m=audio 1124 RTP/AVP 0Step 16. The gateway responds.
200 2848 OKStep 17. The Call Agent puts the line into the connected state. It also adds requested events looking for hold (fk21) and conference/transfer (fk24) 🙌
RQNT 2849 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,cn)
R: KY/fk1, KY/fk2, KY/fk8, KY/fk21, KY/fk24, L/hu
T: L/hd
K: 2842Step 18. The gateway responds.
200 2849 OKStep 19. The far end disconnects. The Call Agent deletes the connection.
DLCX 2873 d003@da-003.syltrx.com MGCP 1.0
C: 10B
I: 101
K: 2848, 2849Step 20. The gateway responds.
250 2873 Connection DeletedStep 21. The Call Agent forces the endpoint onhook/idle.
RQNT 2876 d003@da-003.syltrx.com MGCP 1.0
N: cs@sage.syltrx.com:2427
X: 45
S: KY/ks(1,id), BP/hu
R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd
T: L/hu
K: 2873Step 22. The gateway responds.
200 2876 OKC.4 Determining the Make and Model of a Phone
this is the detective episode 🕵️♀️ where the Call Agent figures out what phone it's talking to
Step 1. The gateway restarts.
RSIP 1 *@alpha175.sylantro.com MGCP 1.0
RM: restartStep 2. The Call Agent responds.
200 1 OKStep 3. The Call Agent audits the gateway to get the list of endpoints.
AUEP 1000 *@alpha175.sylantro.com MGCP 1.0Step 4. The gateway responds.
200 1000 OK
Z: a004@alpha175.sylantro.com
Z: d001@alpha175.sylantro.com
Z: d002@alpha175.sylantro.com
Z: d003@alpha175.sylantro.comStep 5. For each endpoint, the Call Agent checks the capabilities and the user-agent (phone-type) 🔍
AUEP 1040 d003@alpha175.sylantro.com MGCP 1.0
K: 1039
F: A,X-UAStep 6. The gateway responds.
200 1040 OK
A: v:D;L;KY;X-BP;G;BP
X-UA: Sylantro/DKT2010-CA204#CA010Appendix D: BNF Description of X-UA Parameter
okay so the X-UA parameter has to be parseable, because that's how a Call Agent can treat similar phones in a similar way 🧠 that's why there's a formal grammar for it, and it's lowkey genius 💖
______________ _ ____________________________________________________
|X-UA |:|ENDPOINTINFO |
|______________|_|____________________________________________________|
|ENDPOINTINFO |:|MAKE/MODEL[-VENDORINFO] |
|______________|_|____________________________________________________|
|MAKE |:|1*32 MAKECHAR |
|______________|_|____________________________________________________|
|MODEL |:|1*32 MODELCHAR |
|______________|_|____________________________________________________|
|VENDORINFO |:|1*32 VENDORCHAR |
|______________|_|____________________________________________________|
|MAKECHAR |:|ALPHA | DIGIT |
|______________|_|____________________________________________________|
|MODELCHAR |:|ALPHA | DIGIT |
|______________|_|____________________________________________________|
|VENDORCHAR |:|ALPHA | DIGIT | OTHER |
|______________|_|____________________________________________________|Full Copyright Statement ✨
Copyright (C) The Internet Society (2001). All Rights Reserved. 💖 okay so this is the legal bit, and yes it's giving very official 💅 The Internet Society owns the copyright on this one, and that's that.
okay so here's the vibe on sharing it 🦋 You're allowed to copy this document and pass it around to your friends, and you can even translate it. You're also allowed to write derivative works that comment on or explain it, or that help people actually implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to be included on every copy and every derivative work 🎀
But the document itself? Hands off the original 🙅♀️ You may not modify it in any way, like removing the copyright notice or taking out the references to the Internet Society or other Internet organizations. There are two exceptions to that. The first is when you need it for developing Internet standards, and in that case the copyright procedures in the Internet Standards process must be followed. The second is when you need to translate it into a language other than English 🌈
The permissions granted above are perpetual, and the Internet Society, its successors, and its assigns will never revoke them. Iconic commitment 👑
THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS IS" BASIS AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Translation: the document comes as is, and the Internet Society and the Internet Engineering Task Force don't promise it's perfect 🙈 Literally all caps because it's serious legal energy 💀
Acknowledgement ✨
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶 So the people keeping the RFC series running are funded by the Internet Society right now, and that's a whole mood 🧚
📦 where this page comes from
- ietf: rfc3149 2001-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms