that shows the phone's extension.
2. A clock (<time>). The clock is aligned to the right.
3. An itemized list (<select>) containing one item (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 as follows:
--------------------
|2344 11:59|
| MENU |
--------------------
[XX] [XX] [XX]
Here, MENU maps to the first soft key below the display. If the user
presses the first soft key, the following event will be generated:
O: XML/xml(post?basic?home?Menu=1).
B.2 Sample Deck 2 (Enumerated List Box)
The next sample 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:
1. A paragraph (<p>). The paragraph contains a title variable
describing the list contents.
2. An enumerated list (<select>) containing five items. When an
item is selected, the XML layer sends the XML/xml event to the
Call Agent.
3. A do tag (<do>) indicating that when a "previous" event has
occurred, to 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 as follows:
--------------------
|SELECT A CAR |
|1. Porsche v|
--------------------
[XX] [XX] [XX]
Here, the display may be scrolled to reveal the additional items that
may be selected and the keypad '1', '2', etc may be used to select
the item. These details are phone-specific. For instance, on a
larger 4-line display containing navigation keys, the XML may be
rendered as follows:
--------------------
|SELECT A CAR |
|=>Porsche<= |
| Chevrolet |
| Toyota v|
--------------------
When the user selects item 1, the following message will be 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 sample shows how to implement a simple text box:
<xml>
<card id="generic">
<p>$cldpty</p>
<p>CALL FAILED</p>
</card>
</xml>
The card (generic) contains two paragraphs. The absence of a
selectable list, input box or echo box indicates that this is a text
box.
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 as follows:
--------------------
|JOHN DOE |
|CALL FAILED |
--------------------
[XX] [XX] [XX]
B.4 Sample Deck 4 (Echo Box)
This sample show how to implement a simple echo box. The XML layer
does not consume any keystrokes.
<xml>
<card id="getdigits">
<p>Dial Number:</p>
<echo mode="$mode" align="left"/>
</card>
</xml>
The card (getdigits) contains 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 as follows:
--------------------
|DIAL NUMBER: |
| |
--------------------
[XX] [XX] [XX]
All user input is displayed but not consumed by the XML layer.
B.5 Sample Deck 5 (Input Box)
This sample implements a basic input box:
<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>
The card (ginput) contains:
1. A paragraph <p>. The paragraph contains a title.
2. An input box <input>. The input box consumes keypad events and
reports them when input is complete.
3. Two event handlers <do>. The first handles the accept event.
This event indicates that the user has completed keypad input
and posts an observed event to the Call Agent. The second
handles the prev event. This event indicates that the user has
requested to revert back to the previous card.
An XML request for this deck and card might look like:
S: XML/xml(deck?ginput?$title=Enter Digits:)
After variable substitution, the phone may render the XML to the
display as follows:
--------------------
|ENTER DIGITS: |
|_ |
--------------------
[XX] [XX] [XX]
It is up to the individual business phone implementation to determine
which soft keys or keypad keys map to functions such as "backspace",
"reset line", etc.
B.6 Sample Deck 6 (Timers)
To illustrate timers and deck-scoped variable substitution, a two-
card deck is provided:
<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>
In this example, when the timer expires in card connected1, it
generates an ontimer event. This event is consumed by the <do> tag
and causes the XML layer to load card with the identifier connected2.
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 might be rendered 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
Step 1. Call Agent sets labels on several used keys. Should be done
at startup. The first 2 keys are line appearance keys. fk8 is a Do
Not Disturb function.
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: 1873
Step 2. Gateway responds.
200 1876 OK
C.2 Activating a Function on a Feature Key
This example shows a feature key that is assigned to "Do Not Disturb"
being activated and deactivated.
Step 1. User presses DND key, which is assigned to fk8. Gateway
sends NTFY to Call Agent.
NTFY 957 d003@da-003.syltrx.com MGCP 1.0
K: 956
N: cs@sage.syltrx.com:2427
X: 45
O: KY/fk8
Step 2. Call Agent responds.
200 957 OK
Step 3. Call Agent sends new RQNT, indicating that DND indicator be
activated. Note that the Call Agent also re-sends the state of fk1,
which is not actually necessary. The Call Agent requests
notification of several of the 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-2744
Step 4. Gateway responds.
200 2822 OK
Step 5. User presses DND key again to de-activate DND. Gateway sends
NTFY to Call Agent.
NTFY 958 d003@da-003.syltrx.com MGCP 1.0
K: 957
N: cs@sage.syltrx.com:2427
X: 45
O: KY/fk8
Step 6. Call Agent responds.
200 958 OK
Step 7. Call Agent sends new RQNT, DND indicator is de-activated.
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: 2822
Step 8. Gateway responds.
200 2823 OK
C.3 Generating a Call using a Feature Key as a Line Key
This example shows the MGCP messages for dialing an extension after
pressing a feature key that is configured as a line appearance key.
Step 1. 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/fk1
Step 2. Call Agent responds.
200 959 OK
Step 3. Call Agent puts the line key in 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: 2823
Step 4. Gateway responds.
200 2833 OK
Step 5. 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. Gateway responds.
200 2834 OK
Step 7. User dials 2362. 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/2
Step 8. Call Agent responds.
200 960 OK
Step 9. Call Agent puts line in the ringback state. Ringback not
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, 2834
Step 10. Gateway responds.
200 2836 OK
Step 11. Call Agent creates connection.
CRCX 2838 d003@da-003.syltrx.com MGCP 1.0
C: 10B
M: RECVONLY
Step 12. 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/8000
Step 13. 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/hd
Step 14. Gateway responds.
200 2841 OK
Step 15. Call Agent modifies 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 0
Step 16. Gateway responds.
200 2848 OK
Step 17. Call Agent puts line in connected state. Added 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: 2842
Step 18. Gateway responds.
200 2849 OK
Step 19. Far end disconnects. Call Agent deletes connection.
DLCX 2873 d003@da-003.syltrx.com MGCP 1.0
C: 10B
I: 101
K: 2848, 2849
Step 20. Gateway responds.
250 2873 Connection Deleted
Step 21. Call Agent forces 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: 2873
Step 22. Gateway responds.
200 2876 OK
C.4 Determining the Make and Model of a Phone
Step 1. Gateway restarts.
RSIP 1 *@alpha175.sylantro.com MGCP 1.0
RM: restart
Step 2. Call Agent responds.
200 1 OK
Step 3. Call Agent audits the Gateway to determine list of endpoints
AUEP 1000 *@alpha175.sylantro.com MGCP 1.0
Step 4. Gateway responds.
200 1000 OK
Z: a004@alpha175.sylantro.com
Z: d001@alpha175.sylantro.com
Z: d002@alpha175.sylantro.com
Z: d003@alpha175.sylantro.com
Step 5. For each endpoint, Call Agent determines capabilities and
user-agent (phone-type)
AUEP 1040 d003@alpha175.sylantro.com MGCP 1.0
K: 1039
F: A,X-UA
Step 6. Gateway responds.
200 1040 OK
A: v:D;L;KY;X-BP;G;BP
X-UA: Sylantro/DKT2010-CA204#CA010
Appendix D: BNF Description of X-UA Parameter
Since parts of the X-UA parameter must be parseable in order for a
Call Agent to treat similar phones in a similar manner, a formal
grammar for this parameter is provided.
______________ _ ____________________________________________________
|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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.