idnits 2.17.1 draft-srinath-mgcp-bus-packages-00.txt: -(645): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2000) is 8623 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'XX' on line 1327 ** Obsolete normative reference: RFC 2705 (ref. '1') (Obsoleted by RFC 3435) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Ashok Srinath 2 INTERNET DRAFT Gil Levendel 3 Document: draft-srinath-mgcp-bus-packages-00.txt Kent Fritz 4 Category: Informational Sylantro Systems 5 Raghuraman Kalyanaram 6 Wipro Systems 8 September 2000 10 MGCP Business Phone Packages 12 Status of this Document 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes a collection of MGCP packages that can be used 36 to take advantage of the feature keys and displays on digital business 37 phones and IP-Phones. These packages, when used in conjunction with 38 the packages currently defined in RFC 2705 (Media Gateway Control 39 Protocol Version 1.0), allow an MGCP call-agent to control these types 40 of endpoints. 42 Table of Contents 44 1. Introduction 45 1.1 General Information 46 1.2 Objectives 47 2. MGCP Packages for Business Phones 48 2.1 Feature Key Package 49 2.2 Business Phone Package 50 2.3 Display XML Package 51 3. Endpoint Naming 52 4. Functions that should be Locally Implemented 53 4.1 Volume Control 54 4.2 Audio Path 55 5. XML Package Support 56 5.1 XML Documents 57 5.2 XML Requests 58 5.3 XML Request History 59 5.4 XML Events 60 5.5 XML Tags 61 5.5.1 XML Tag 62 5.5.2 Card Tag 63 5.5.3 P Tag 64 5.5.4 Select Tag 65 5.5.5 Option Tag 66 5.5.6 Input Tag 67 5.5.7 Echo Tag 68 5.5.8 Calltimer Tag 69 5.5.9 Time Tag 70 5.5.10 Timer Tag 71 5.5.11 Do Tag 72 5.5.12 Go Tag 73 5.5.13 Prev Tag 74 6. Acknowledgements 75 7. References 76 8. Authors' Addresses 78 Appendix A: BNF description of XML grammar 80 Appendix B: Sample XML Documents, Renderings and Events 81 B.1 Sample Deck 1 (Itemized List Box) 82 B.2 Sample Deck 2 (Enumerated List Box) 83 B.3 Sample Deck 3 (Text Box) 84 B.4 Sample Deck 4 (Echo Box) 85 B.5 Sample Deck 5 (Input Box) 86 B.6 Sample Deck 6 (Timers) 88 Appendix C: Example usage of MGCP extension packages 89 C.1 Setting Labels on Phone 90 C.2 Activating a Feature on a Feature Key 91 C.3 Generating a Call using Feature Key as a Line Key 92 1. Introduction 94 The Media Gateway Control Protocol (MGCP) Version 1.0 defines a 95 protocol for controlling Voice over IP Telephony Gateways from external 96 call control elements. As defined, it supports external call control 97 elements called Media Gateway Controllers and assumes that these 98 Gateways can support collections of endpoints. The endpoint type known 99 as an "analog line" can be used as a client interface to provide 100 service to a basic analog telephone unit. The packages that are 101 currently defined to handle events and signals allow only for a basic 102 level of audio connection and signaling to such endpoints. 103 To handle more advanced capabilities commonly found on business phones 104 such as feature keys, speakerphone and displays, it is necessary to 105 define additional packages as extensions to the Version 1.0 MGCP 106 protocol. 108 The MGCP extension packages defined here are as follows: 110 - Feature Key Package 111 o Groups the events and signals associated with the 112 additional keys available on business phones that are non- 113 DTMF and not locally-implemented. These include: 114 - Feature Key event allows mapping key numbers to 115 feature keys any phone. 116 - Key State signal indicates the state of feature keys. 117 - Set Label signal can be used to display a label on 118 the LCD next to a feature key. 120 - Business Phone Package 121 o Groups signals that are not related to feature keys, including: 122 - Force Off-hook and Force On-hook signals to allow application 123 integration with speakerphone capabilities. 124 - Beep signal to play a beep on the phone. 126 - Display XML Package 127 o Used to convey XML [2] script data to and from the phone to 128 control the display and assign functions to the keys for event 129 reporting. 131 1.1 General Information 133 A generic business phone typically includes a number of features that 134 provide access to additional functionality and features useful in the 135 business environment. Beyond the basic handset and dial pad, a 136 Business Phone may optionally include a number of fixed buttons, line 137 keys and programmable feature keys, along with an LCD display and soft- 138 keys. 140 Specific examples of items that may be included on a Business Phone 141 are: 142 - Speakerphone microphone and speaker 143 - Speakerphone button and light 144 - Message button and light 145 - Redial button 146 - Volume up and down buttons 147 - Hold button and light 148 - Transfer button and light 149 - Forward button and light 150 - Conference button and light 151 - Microphone mute button and light 152 - Multiple feature keys with lights 153 - Multi-line LCD Display 154 - Multiple soft-keys next to the LCD display 155 - Navigation keys 157 1.2 Objectives 159 The high level objectives that were considered in generating the 160 extensions described here are: 162 - Provide a minimum set of extension packages to the MGCP Version 163 1.0 protocol to allow applications to take advantage of generic 164 business phone capabilities. 166 - Provide event and control extensions at a sufficiently low level 167 for an application to implement generic business phone functions 168 without generating excessive or redundant data traffic. (e.g. 169 Sending feature key information on both press and release would 170 be a "don't care" for a call-agent. All it cares about is that 171 the key was pressed.) 173 - Provide a mechanism to interface with LCD displays and allow 174 flexibility that will accommodate a variety of application needs 175 and different types of displays available. 177 2. MGCP Packages for Business Phones 179 The following packages should be implemented for Business Phones. The 180 G,D,L, and H packages are defined in RFC 2705 [1]. Packages KY, BP and 181 XML are defined in this specification. 182 ______________________________________________________ 183 | Package | Name | Defined | 184 |______________________________|_________|_____________| 185 | Generic Media Package | G |in RFC 2705 | 186 | DTMF package | D |in RFC 2705 | 187 | Line Package | L |in RFC 2705 | 188 | Handset Package | H |in RFC 2705 | 189 | Feature Key Package | KY |in this spec | 190 | Business Phone Package | BP |in this spec | 191 | Display XML Package | XML |in this spec | 192 |______________________________|_________|_____________| 194 In the tables of events for each package, there are five columns: 196 Symbol: the unique symbol used for the event 197 Definition: a short description of the event 199 R: an x appears in this column is the event can be Requested by 200 the call agent. 202 S: if nothing appears in this column for an event, then the event 203 cannot be signaled on command by the call agent. Otherwise,the 204 following symbols identify the type of event: 206 OO On/Off signal. The signal is turned on until commanded by the 207 call agent to turn it off, and vice versa. 209 TO Timeout signal. The signal lasts for a given duration unless 210 it is superseded by a new signal. 212 BR Brief signal. The event has a short, known duration. 214 Duration: specifies the duration of TO signals. 216 2.1 Feature Key Package 218 Package Name: KY 220 The Feature Key Package groups the events and signals that are 221 associated with the additional keys that are available on business 222 phones. 224 ____________________________________________________________________ 225 | Symbol | Definition | R | S Duration | 226 |__________|____________________________|_____|______________________| 227 | fk1-fk99 | Feature Key | x | | 228 | ks | Key State | | OO | 229 | sl | Set Label | | OO | 230 |__________|____________________________|_____|______________________| 232 Feature Key (fk1-fk99) 233 These events map to all the keys on the phone that are not DTMF 234 keys or locally implemented features (such as volume). The 235 mapping of fk number to key is expected to vary between phones. 237 Note: Some have suggested parameterizing an fk event, i.e. 238 sending an RQNT with "R: KY/fk" and notifying with "O: KY/fk(1)", 239 but this is problematic. It is desireable to request only the 240 keys that can be pressed in a given state, to eliminate the 241 chance that a mis-pressed button will cancel a timeout signal, 242 and to eliminate message traffic. This is not possible within 243 the confines of MGCP, as requested events cannot be 244 parameterized. 246 Key State (ks) 247 This signal is used to indicate the state of a feature key. This 248 signal has 2 parameters: key number and state. The key number 249 maps directly to the feature key number. 251 The state is a high level description of the state of the key. 252 This allows different phones to implement different indications 253 of state. For example, Phone A may have a multi-color LED 254 associated with feature keys that can blink at different 255 cadences. Phone B might have an LCD beside the keys that can 256 display text or icons. It is up to each phone vendor to 257 determine how to present the state indication. 259 The following states are used: 260 ______________________ 261 | State | Definition | 262 |_______|______________| 263 | en | enabled | 264 | db | disabled | 265 | id | idle | 266 | dt | dial tone | 267 | cn | connected | 268 | rg | ringing | 269 | rb | Ringback | 270 | ho | holding | 271 | he | held | 272 |_______|______________| 274 For example: an RQNT with "S: KY/ks(5,en)" will cause an 275 indicator corresponding to fk5 to indicate that it is enabled. 276 An RQNT with "S: KY/ks(2,rg)" will cause an indicator 277 corresponding to fk2 to indicate that it is ringing. 279 "en" state 280 The associated feature will be enabled. Used for keys that 281 turn a feature on or off, such as "Do Not Disturb." 283 "db" state 284 The associated feature will be disabled. Used for keys 285 that turn a feature on or off, such as "Do Not Disturb." 287 "id" state 288 The specified line appearance is in the idle state, 289 available for a call. 291 "dt" state 292 The specified line appearance is providing dial-tone. 294 "cn" state 295 The specified line appearance is actively in a call in the 296 connected state. 298 "rg" state 299 The specified line appearance is terminating an incoming 300 call in the ringing state. 302 "rb" state 303 The specified line appearance is originating a call in the 304 ringing-back state. 306 "ho" state 307 The specified line appearance is in the holding state, with 308 the far end held. 310 "he" state 311 The specified line appearance is in the held state, with 312 the far end holding. 314 Set Label (sl) 315 This signal is used to set the label on a key. This is used for 316 phones that have an LCD next to the feature keys. It should be 317 accepted but ignored for phones without this capability. 319 This signal has 2 parameters: key number and label. The key 320 number maps directly to the feature key number. The label is 321 free form text, restricted to the capabilities of the phone. 323 For example, an RQNT with "S: KY/sl(1,2200)" sets the label next 324 to the fk1 feature key with the extension 2200. 326 2.2 Business Phone Package 328 Package Name: BP 330 The Business Phone Package groups signals other than those related to 331 feature keys and displays. 333 ____________________________________________________________________ 334 | Symbol | Definition | R | S Duration | 335 |__________|____________________________|_____|______________________| 336 | hd | Force Offhook | | OO | 337 | hu | Force Onhook | | OO | 338 | beep | Beep | | BR | 339 |__________|____________________________|_____|______________________| 341 Force Offhook (hd) 342 This signal is used to force the phone offhook. If the phone has 343 a speakerphone, it should be activated. This signal can be 344 negated by the user by hanging up. 346 This can be used if a feature key causes a call to be initiated. 348 This can also be used for application integration. For example, 349 a user could select a number in an application on their PC, and 350 the phone would be forced offhook and a call initiated. 352 Force Onhook (hu) 353 This signal forces the phone onhook. This can be used when the 354 far-end disconnects. 356 Beep (beep) 357 Play a beep on the phone. 359 2.3 Display XML Package 361 Package Name: XML 363 The XML Package contains one event/signal that is used to convey XML 364 data to and from the phone. 365 _____________________________________________________________________ 366 | Symbol | Definition | R | S Duration | 367 |__________|____________________________|_____|______________________| 368 | xml | XML Data | x | OO | 369 |__________|____________________________|_____|______________________| 371 XML Data (xml) 372 As an event, if this event is requested in an RQNT with "R: 373 XML/xml", any posts of data from an XML script are returned in an 374 NTFY with "O: XML/xml(post data here)". 376 As a signal, the parameterized data indicates an URL to an XML 377 script (possibly local), as well as substitution values that 378 depend on the XML script selected. See Section 5 for more 379 information. 381 3. Endpoint Naming 383 Because the display state can be somewhat asyncronous from the 384 signaling state of the phone, it is desireable to address the display 385 as a separate MGCP endpoint in order to simplify the call-agent state 386 machine. 388 For example, suppose a call is presented to the phone, and a display is 389 presented that gives the user the option of redirecting the caller 390 immediately to voice-mail. Selecting the option via the display would 391 cause an XML post to occur, cancelling any timeout signals (the 392 ringing). 394 In order to simplify the handling of such scenarios, it is recommended 395 that the related display have a different MGCP endpoint name created by 396 inserting a prefix before the endpoint name. The prefix used shall be 397 "disp/". 399 For example, if the endpoint has the name "ep1@foo.whatever.net", the 400 display would be "disp/ep1@foo.whatever.net". 402 4. Functions that should be Locally Implemented 404 There are some functions that should be implemented locally on the 405 endpoint. They are listed in the following sections. 407 4.1 Volume Control 409 Volume for ringing, handset, and speakerphone should be implemented 410 locally on the endpoint. 412 4.2 Audio Path 414 If the phone includes a speakerphone, activating the speakerphone from 415 the idle state should generate an L/hd event. The user should then be 416 able to switch to handset by lifting the handset, and be able to switch 417 back to speakerphone without any interaction with the call-agent. De- 418 activating the speakerphone with the handset on-hook should generate an 419 L/hu event. 421 4.3 Microphone mute button and light 423 If the phone includes a microphone mute button and (optionally) an 424 associated indicator (e.g. light) the functionality of these items 425 should be implemented locally on the endpoint. 427 5. XML Package Support 429 Not all business phones have the same display and keypad capabilities. 430 To support these varying devices in a consistent manner, this section 431 outlines an XML framework that is used to drive the phone. In this 432 framework, the call agent pushes XML requests to the endpoints using 433 MGCP signals and events. These XML requests indicate the XML document 434 that is to be rendered on the phone. 436 5.1 XML Documents 438 When an XML request is sent to an endpoint, it indicates the XML 439 documents that the endpoint must process. These documents contain tags 440 that are a subset of the Wireless Markup Language (WML) [3] plus some 441 non-WML additions. The tags specify items to be displayed as well as 442 XML events that may be generated as the result of keypad input. 444 Each XML document, known as a card, defines a user interaction. A group 445 of cards is called a deck. One or more decks define an application. The 446 cards define soft key behavior as well as display behavior, and are 447 mapped to components that implement the behavior of a basic graphical 448 user interface on the display phone. Based on the available 449 requirements, the components needed are: 451 - Input box: 452 allows user input, including editing capabilities, via the keypad. 453 - Enumerated list box: 454 allows the user to select one of a list of items. 455 - Itemized list box: 456 allows the user to select an item using a soft key. 457 - Text box: 458 displays read-only text to the user. 459 - Echo box: 460 displays but does not process user input. 462 A card may have the following properties. 464 1. Timed content (e.g. card expiration) 465 2. Static content (e.g. text) 466 3. Dynamic content (e.g. call timers/time) 468 Additionally, cards may also contain variables that may be substituted 469 for values that are specified in an XML request. See the following 470 section for details on variable substitution. 472 There are cases where the XML scripts handling the display need to use 473 keys that are also used in MGCP. For example, the display could 474 present an enumerated list, where a particular item is selected by 475 pressing the associated number on the dial pad. All user key presses 476 must be routed through the XML component layer. 478 The XML component layer consumes the key presses or passes them on to 479 the MGCP layer for consumption. The code handling keypresses should 480 present a keypress to the XML code first. If the XML code does not 481 "use" the key, then the key should be presented to the MGCP code. This 482 gives precedence to the XML scripts for keypresses. 484 5.2 XML Requests 486 The XML framework uses MGCP as its transport for making requests to the 487 display phone. MGCP is also used to receive asynchronous events from 488 the display phone (e.g. an item has been selected, the user has entered 489 text, etc). 491 An XML request is made to an endpoint using the XML/xml signal. The 492 signal has the following format: 494 S: XML/xml(??$=?$=�) 496 The first component of the signal parameter is a URL to the deck. If no 497 scheme is indicated, the file is assumed to be local to the phone. Here 498 are some examples: 500 ftp://server.company.com/deck1?card1?$var1=val1 501 http://www.company.com/deck1?card1?$var1=val1 502 file:///deck1?card1?$var1=val1 503 deck1?card1?$var1=val1 505 A card identifier and a list of variable/value pairs follow the URL. 506 The card identifier indicates the card within the deck to display. 508 The variable/value pairs are substituted into the deck before it is 509 rendered to the display. This means that 1) the variables are deck- 510 scoped and 2) variables not defined in the requested card may be 511 specified in the request as long as they exist in the deck. 513 For example, a deck may contain the following cards: 515 516

$line1

517 518 519 520 521 523 524

$line2

525 527 And an XML request may look like: 529 S: XML/xml(deck?one?$line1=abc$line2=xyz) 531 After variable substitution, the deck will look like: 533 534

abc

535 537 538

$line2

539 541 Once variable substitution is complete, the card is rendered. If a 542 parameter variable does not exist in the specified card it should be 543 ignored. 545 When card two is invoked from card1 in response to the timeout action, 546 card two's variables are substituted with the variables values passed 547 as a request to card one. Card two will look like: 549 550

xyz

551 553 5.3 XML Request History 555 In order to support navigation through a request history such as when a 556 user cancels a card, the XML layer must maintain a last-in-first-out 557 history of requests made for the endpoint. (See the tag 558 definition in a following section) 560 5.4 XML Events 562 Whenever the XML layer determines that an event has occurred, it 563 reports the event using the MGCP observed event field: 565 O: 566 XML/xml(post???=?=) 568 Here, the event parameter contains the deck and card that generated the 569 event as well as data that is to be processed by the call agent. The 570 data being posted is in the form of a list of variable/value pairs. 572 In order for the endpoint to properly generate the XML event, it is 573 necessary for the call agent to request the event using the requested 574 events field: 576 R: XML/xml 578 This requested event should be combined with the signal request in an 579 RQNT. 581 5.5 XML Tags 583 Any XML implementation must at a minimum support the XML tags listed in 584 the table that follows. All tags have a terminator tag of the form 585 to indicate the end of the tag. See the XML grammar in Appendix 586 A. 587 _____________________________________________________________________ 588 | Name | Usage | 589 |_______________|_____________________________________________________| 590 | | Marks the beginning of a deck. | 591 |_______________|_____________________________________________________| 592 | | Marks the beginning of a card | 593 |_______________|_____________________________________________________| 594 |

| Marks the beginning of a paragraph. | 595 |_______________|_____________________________________________________| 596 | tag to | 600 | | specify an individual item that may be selected. | 601 |_______________|_____________________________________________________| 602 | | Marks the beginning of user input (an input box). | 603 |_______________|_____________________________________________________| 604 | | Marks the beginning of an echo box. | 605 |_______________|_____________________________________________________| 606 | | Call Timer. An incremental timer usually used to | 607 | | maintain the duration of a call. | 608 |_______________|_____________________________________________________| 609 | | Card timer. Allows an event to be generated when | 610 | | the timer expires. | 611 |_______________|_____________________________________________________| 612 |

tag marks the beginning of a new paragraph. 686 This tag has the following attributes: 687 _______________ _____________________ _______________________________ 688 |Attribute Name | Values (default) | Usage | 689 |_______________|_____________________|_______________________________| 690 |Mode | Enum: wrap/nowrap | Specifies whether the | 691 | | (wrap) | paragraph wraps or is | 692 | | | truncated when it extends past| 693 | | | the display width. | 694 |_______________|_____________________|_______________________________| 695 | Align | Align | Specifies alignment of the | 696 | | | paragraph. | 697 |_______________|_____________________|_______________________________| 699 5.5.4 Select Tag 701 The tag, the

| 966 |______________|_|____________________________________________________| 967 |COMPONENTS |:|COMPONENT | COMPONENT COMPONENTS | 968 |______________|_|____________________________________________________| 969 |COMPONENT |:|TEXT | INPUTBOX | SELECTBOX | STIME | CALLTIMER | 970 |______________|_|____________________________________________________| 971 |CONTROL |:| ACTION | 972 |______________|_|____________________________________________________| 973 |CONDITION | |type=["accept" | "prev" | "ontimer"] label=STRING | | 974 | | |type=["accept" | "prev" |"ontimer"] | 975 |______________|_|____________________________________________________| 976 |DIGITS |:|DIGIT | DIGIT DIGITS | 977 |______________|_|____________________________________________________| 978 |DIGIT |:|0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 979 |______________|_|____________________________________________________| 980 |DML |:| CARDS | 981 |______________|_|____________________________________________________| 982 |ECHO |:| | | 983 |______________|_|____________________________________________________| 984 |ECHOMODE |:|mode=["on" | "off"] | 985 |______________|_|____________________________________________________| 986 |HREFSTRING |:|CARDREFERENCE | POSTSTRING | 987 |______________|_|____________________________________________________| 988 |INPUTBOX |:| | 989 |______________|_|____________________________________________________| 990 |INPUTATTRS |:|INPUTATTR | INPUTATTR INPUTATTRS | 991 |______________|_|____________________________________________________| 992 |INPUTATTR |:|name=STRING | type=["text" | "password"] | | 993 | | | value=STRING | 994 |______________|_|____________________________________________________| 995 |NAMEVALUES |:|NAMEVALUE | NAMEVALUE?NAMEVALUES | 996 |______________|_|____________________________________________________| 997 |NAMEVALUE |:|NAMEVALUEELEM=NAMEVALUELEM | 998 |______________|_|____________________________________________________| 999 |NAMEVALUELEM |:|%TEXT | TEXT | 1000 |______________|_|____________________________________________________| 1001 |OPTIONS |:|OPTION | OPTION OPTIONS | 1002 |______________|_|____________________________________________________| 1003 |OPTION |:| | 1005 |______________|_|____________________________________________________| 1006 |PARAGRAPH |:|

|

| 1007 |______________|_|____________________________________________________| 1008 |POSTSTRING |:|post?%deck?%id?NAMEVALUES | 1009 |______________|_|____________________________________________________| 1010 |SELECTBOX |:| | 1011 |______________|_|____________________________________________________| 1012 |SELECTATTRS |:|SELECTATTR | SELECTATTR SELECTATTRS | 1013 |______________|_|____________________________________________________| 1014 |SELECTATTR |:|name=STRING | iname=STRING | type="item" | 1015 |______________|_|____________________________________________________| 1016 |STIME |:|

$dn 1052 1055

1056 1057 1059 The card (home) contains three components: 1061 1. A paragraph (

). The paragraph contains a variable ($dn) that 1062 determines the phone's extension. 1063 2. A clock (

1109 1110 1111 1112 1113 1115 The card (gelist) contains four components: 1116 1. A paragraph (

). The paragraph contains a title variable 1117 describing the list contents. 1118 2. An enumerated list ( 1224

1225 1226 1227 1228 1229 1230 1231 1232 1234 The card (ginput) contains: 1235 1. A paragraph

. The paragraph contains a title. 1236 2. An input box . The input box consumes keypad events and 1237 reports them when input is complete. 1238 3. Two event handlers . The first handles the accept event. This 1239 event indicates that the user has completed keypad input and 1240 posts an observed event to the call agent. The second handles the 1241 prev event. This event indicates that the user has requested to 1242 cancel the current card. 1244 An XML request for this deck and card might look like: 1246 S: XML/xml(deck?ginput?$title=Enter Digits:) 1248 After variable substitution, the phone may render the XML to the 1249 display as follows: 1251 -------------------- 1252 |ENTER DIGITS: | 1253 |_ | 1254 -------------------- 1255 [XX] [XX] [XX] 1257 It is up to the individual business phone implementation to determine 1258 which soft keys or keypad keys map to such things as "backspace" and 1259 "reset line", etc. 1261 B.6 Sample Deck 6 (Timers) 1262 To illustrate timers and deck-scoped variable substitution, a two-card 1263 deck is provided: 1265 1266 1267 1268

$cldpty 1269 1280

1281 1282 1283 1284 1286 1287

1288 1289 1300

1301 1302 1304 In this example, when the timer expires in card connected1, it 1305 generates an ontimer event. This event is consumed by the tag and 1306 causes the XML layer to load card with the identifier connected2. 1308 An XML request for these cards might look like: 1310 S: XML/xml(deck?connected1?$tvalue=00:00:05?$cldpty=John 1311 Doe?$calltimer=00:00:00) 1313 And might be rendered as: 1315 -------------------- 1316 |JOHN DOE | 1317 | TRNS CONF MENU | 1318 -------------------- 1319 [XX] [XX] [XX] 1321 Once the timer expires, the XML layer loads the referenced page: 1323 -------------------- 1324 | 00:00:05| 1325 | TRNS CONF MENU | 1326 -------------------- 1327 [XX] [XX] [XX] 1328 Appendix C: Example usage of MGCP extension packages 1330 C.1 Setting Labels on Phone 1332 Step 1. Call-agent sets labels on several used keys. Should be done at 1333 startup. The first 2 keys are line appearance keys. fk8 is a Do Not 1334 Disturb function. 1336 RQNT 1876 d003@da-003.syltrx.com MGCP 1.0 1337 N: cs@sage.syltrx.com:2427 1338 X: 45 1339 S: KY/sl(1,2315), KY/sl(2,2315), KY/sl(8,DND) 1340 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd 1341 T: L/hu 1342 K: 1873 1344 Step 2. Endpoint responds. 1346 200 1876 OK 1348 C.2 Activating a Feature on a Feature Key 1350 This example shows a feature key that is assigned to "Do Not Disturb" 1351 being activated and deactivated. 1353 Step 1. User presses DND key, which is assigned to fk8. Endpoint sends 1354 NTFY to call-agent. 1356 NTFY 957 d003@da-003.syltrx.com MGCP 1.0 1357 K: 956 1358 N: cs@sage.syltrx.com:2427 1359 X: 45 1360 O: KY/fk8 1362 Step 2. Call-agent responds. 1364 200 957 OK 1366 Step 3. Call-agent sends new RQNT, indicating that DND indicator be 1367 activated. Note that the Call-agent also re-sends the state of fk1, 1368 which is not actually necessary. The call-agent requests notification 1369 of several of the feature keys: fk1 and fk2 are line keys, fk8 is DND, 1370 fk22 is redial, and fk23 is Msg. 1372 RQNT 2822 d003@da-003.syltrx.com MGCP 1.0 1373 N: cs@sage.syltrx.com:2427 1374 X: 45 1375 S: KY/ks(1,id), KY/ks(8,en) 1376 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd 1377 T: L/hu 1378 K: 2743-2744 1380 Step 4. Endpoint responds. 1382 200 2822 OK 1384 Step 5. User presses DND key again to de-activate DND. Endpoint sends 1385 NTFY to call-agent. 1387 NTFY 958 d003@da-003.syltrx.com MGCP 1.0 1388 K: 957 1389 N: cs@sage.syltrx.com:2427 1390 X: 45 1391 O: KY/fk8 1393 Step 6. Call-agent responds. 1395 200 958 OK 1397 Step 7. Call-agent sends new RQNT, DND indicator is de-activated. 1399 RQNT 2823 d003@da-003.syltrx.com MGCP 1.0 1400 N: cs@sage.syltrx.com:2427 1401 X: 45 1402 S: KY/ks(1,id), KY/ks(8,db) 1403 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd 1404 T: L/hu 1405 K: 2822 1407 Step 8. Endpoint responds. 1409 200 2823 OK 1411 C.3 Generating a Call using Feature Key as a Line Key 1413 This example shows the MGCP messages for dialing an extension after 1414 pressing a feature key that is configured as a line appearance key. 1416 Step 1. User presses fk1, which is configured as a line key. 1418 NTFY 959 d003@da-003.syltrx.com MGCP 1.0 1419 K: 958 1420 N: cs@sage.syltrx.com:2427 1421 X: 45 1422 O: KY/fk1 1424 Step 2. Call-agent responds. 1426 200 959 OK 1428 Step 3. Call-agent puts the line key in the "dial tone" state and 1429 forces the phone offhook. 1431 RQNT 2833 d003@da-003.syltrx.com MGCP 1.0 1432 N: cs@sage.syltrx.com:2427 1434 X: 45 1435 S: KY/ks(1,dt), BP/hd 1436 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu 1437 T: L/hd 1438 K: 2823 1440 Step 4. Endpoint responds. 1442 200 2833 OK 1443 Step 5. Call-agent applies dial-tone. 1445 RQNT 2834 d003@da-003.syltrx.com MGCP 1.0 1446 N: cs@sage.syltrx.com:2427 1447 X: 45 1448 S: L/dl, KY/ks(1,dt) 1449 R: D/[0-9*#T](D), KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu 1450 T: L/hd 1451 D: (*xx|[1-7]xxx|9) 1453 Step 6. Endpoint responds. 1455 200 2834 OK 1457 Step 7. User dials 2362. Endpoint sends NTFY. 1459 NTFY 960 d003@da-003.syltrx.com MGCP 1.0 1460 K: 959 1461 N: cs@sage.syltrx.com:2427 1462 X: 45 1463 O: D/2,D/3,D/6,D/2 1465 Step 8. Call-agent responds. 1467 200 960 OK 1469 Step 9. Call-agent puts line in the ringback state. Ring not applied 1470 yet. 1472 RQNT 2836 d003@da-003.syltrx.com MGCP 1.0 1473 N: cs@sage.syltrx.com:2427 1474 X: 45 1475 S: KY/ks(1,rb) 1476 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu 1477 T: L/hd 1478 K: 2833, 2834 1480 Step 10. Endpoint responds. 1482 200 2836 OK 1484 Step 11. Call-agent creates connection. 1486 CRCX 2838 d003@da-003.syltrx.com MGCP 1.0 1487 C: 10B 1488 M: RECVONLY 1490 Step 12. Endpoint responds. 1492 200 2838 OK 1493 I: 101 1495 v=0 1496 c=IN IP4 172.16.130.32 1497 m=audio 1108 RTP/AVP 0 1499 Step 13. Call-agent applies ringback. 1501 RQNT 2841 d003@da-003.syltrx.com MGCP 1.0 1502 N: cs@sage.syltrx.com:2427 1503 X: 45 1504 S: KY/ks(1,rb), G/rt 1505 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hu 1506 T: L/hd 1508 Step 14. Endpoint responds. 1510 200 2841 OK 1512 Step 15. Call-agent modifies connection. 1514 MDCX 2848 d003@da-003.syltrx.com MGCP 1.0 1515 C: 10B 1516 I: 101 1517 M: SENDRECV 1518 K: 2841-2842 1520 v=0 1521 c=IN IP4 172.16.130.31 1522 m=audio 1124 RTP/AVP 0 1524 Step 16. Endpoint responds. 1526 200 2848 OK 1528 Step 17. Call-agent puts line in connected state. Added requested 1529 events looking for hold (fk21) and conference/transfer (fk24). 1531 RQNT 2849 d003@da-003.syltrx.com MGCP 1.0 1532 N: cs@sage.syltrx.com:2427 1533 X: 45 1534 S: KY/ks(1,cn) 1535 R: KY/fk1, KY/fk2, KY/fk8, KY/fk21, KY/fk24, L/hu 1536 T: L/hd 1537 K: 2842 1539 Step 18. Endpoint responds. 1541 200 2849 OK 1543 Step 19. Far end disconnects. Call agent deletes connection. 1545 DLCX 2873 d003@da-003.syltrx.com MGCP 1.0 1546 C: 10B 1547 I: 101 1548 K: 2848, 2849 1550 Step 20. Endpoint responds. 1552 250 2873 Connection Deleted 1554 Step 21. Call-agent forces endpoint onhook/idle. 1556 RQNT 2876 d003@da-003.syltrx.com MGCP 1.0 1557 N: cs@sage.syltrx.com:2427 1558 X: 45 1559 S: KY/ks(1,id), BP/hu 1560 R: KY/fk1, KY/fk2, KY/fk8, KY/fk22, KY/fk23, L/hd 1561 T: L/hu 1562 K: 2873 1564 Step 22. Endpoint responds. 1566 200 2876 OK