idnits 2.17.1 draft-huitema-mgcp-test1-00.txt: 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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The abstract seems to contain references ([0]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1047, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '0' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Christian Huitema 3 INTERNET DRAFT Flemming Andreasen 4 Bellcore 5 February 25, 1999 Expires: August 25, 1999 7 Media Gateway Control Protocol (MGCP) 8 Call Flow Test Case 1 9 Christian Huitema, Flemming Andreasen 11 1. Status of this document 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 28 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 29 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 The IETF Megaco working group is currently working on defining a proto- 34 col for controlling Media Gateways (MG) from external control elements 35 such as a Media Gateway Controller (MGC). Different models have been 36 proposed to address this problem, and in order to judge the different 37 models, a series of test cases will be considered. 39 This document explains how the Media Gateway Control Protocol (MGCP) can 40 be used to handle the first test case, which considers a Voice over IP 41 gateway with directly subtending DTMF lines placing a call to an H.323 42 client. The document contains an introduction with further details on 43 the test case, two different call flows to solve it, followed by the 44 conclusion of the test case. MGCP is defined in a companion document 45 [0]. 47 Internet draft MGCP: test case 1 23 February 1999 49 2. Introduction 51 The Media Gateway Control Protocol can be used to control different 52 types of endpoints, such as "residential gateways", "trunking gateways" 53 or "packet relays". This document will show how MGCP can be used to con- 54 trol a residential gateway in the Megaco call flow test case 1, which 55 considers a Voice over IP gateway with directly subtending DTMF lines 56 placing a call to an H.323 client. We first present the Megaco test case 57 1, and we then present an example call flow for solving it. Following 58 that, we discuss possible optimizations to the call flow, and we then 59 present the conclusions reached in using MGCP to satisfy the test case. 61 3. Call Flow Test Case 1 - DTMF line dialing into VoIP Gateway 63 In this section we first present the problem statement for test case 1, 64 and we then present the assumptions for the test case that were made. 66 3.1. Problem Statement 68 In this section, we present the problem statement given for the Megaco 69 call flow test case 1. The problem is formulated as follows: 71 Setting: a VoIP Gateway provides service to directly subtending DTMF 72 lines.The standard North American dialling plan is in use: seven digits 73 beginning with 2-9 for a local number, 10 digits for a North American 74 toll number, the single digit 0 for an operator, 411 for directory 75 information, and 911 for emergency service. Overseas dialling is 011 76 followed by a variable number of digits. The subscriber actually dials 77 a seven-digit local number which has been assigned to a friend's H.323 78 client installation. The Gateway consults with an H.323 Gatekeeper to 79 resolve the dialled digits into the H.323 client's address, then sets up 80 an audio call to that client. At the end of the call the MGC component 81 of the Gateway is required to report to a billing system for billing 82 purposes the following items: 84 -- the time the call began (subscriber off-hook recorded) 86 -- the time media transfer between the calling and called parties 87 began 89 -- the time media transfer between the calling and called parties 90 ended 92 -- total media packets and octets respectively transmitted by the 93 Gateway to the called party 95 -- total media packets and octets respectively received by the Gateway 96 Internet draft MGCP: test case 1 23 February 1999 98 from the called party 100 -- difference between total media packets actually received at the 101 Gateway and the total number expected 103 -- mean interarrival jitter as calculated at the Gateway for received 104 packets. (Notice I don't trust the H.323 client to report anything 105 that can be used for billing.) 107 Call flow: 109 Calling Gateway Called Gatekeeper 110 | 1. Off-hook -->| | | 111 |<-- 2. Dial tone | | | 112 |3. First digit-->| | | 113 |<4. No dial tone | | | 114 |5. Digit -->| | | 115 ... 116 |10. Digit -->| | | 117 | | 11. Admission Request (ARQ)----> | 118 | |<---12. Admission confirm (ACF) | 119 | | 13. SETUP -->| | 120 | | | 14. ARQ --> | 121 | | |<-- 15. ACF | 122 | |<-- 16. ALERTING | | 123 |<-- 17. ringback | | | 124 | |<-- 18. CONNECT | | 125 |<- 19. cutthrough| | | 126 ... 127 | 20. On-hook -->| | | 128 | | 21. RELEASE -->| | 129 | |<-- 22. RLC | | 130 ... 132 Notes: (numbered by the steps to which they apply) 134 11. Admission Request contains dialled number as an E.164 address. 135 Also requests total bandwidth of 128 kbs (64 kbs in each direction 136 to accommodate G.711 coded audio). 138 12. Admission Confirm provides call signalling address and port for the 139 called H.323 client. It indicates that only 80 kbs is available. 141 13. To meet the bandwidth restriction, the SETUP message contains a 142 fastConnect element which offers to send G.711 mu-law audio and 143 receive G.729 Annex C audio or vice versa. It supplies port 144 addresses at which it will receive RTP (incoming media) and RTCP 145 (for the media it transmits). The SETUP message also contains a 147 Internet draft MGCP: test case 1 23 February 1999 149 Boolean indicating that the called H.323 client should not transmit 150 any media packets until it issues a CONNECT message. 152 14-15. 153 The called H.323 client gets permission for its intended bandwidth 154 usage. 156 16. The called H.323 indicates that it is alerting the called party, 157 and that it has chosen to receive G.711 mu-law and send G.729 Annex 158 C. It supplies the port at which it will receive the G.711 and the 159 port at which it will receive RTCP corresponding to the G.729 it 160 sends out. 162 17. It is assumed for this scenario that the Gateway is responsible for 163 supplying ringback tone to the caller. 165 18. The CONNECT message from the called H.323 client indicates that the 166 called party has answered and the call has entered talking state. 168 19. The Gateway must discontinue ringback tone and cut through talking 169 in both directions. 171 20. Assumed for this scenario that the caller is the first to hang up. 173 The Disengage sequences which must pass between the Gatekeeper and the 174 Other two H.323 entities at the end of the call are omitted, since they 175 are not relevant. 177 Assumptions 179 * The description of the dialing plan does not include any restric- 180 tions on the structure of the 10-digit number, and it is therefore 181 assumed that the 10-digit number may start with any digit, incl. 182 2-9. 184 * We assume that international numbers (excluding direct-dial prefix) 185 may consist of as few as 1 digit. 187 * We will be using H.323 version 2. 189 4. Call Flows 191 We present two different call flows to test case 1. The first call flow 192 illustrates how MGCP can be used to satisfy the test case when two 193 separate connections are used. The second call flow illustrates an 194 alternative solution where we only use one connection. 196 Internet draft MGCP: test case 1 23 February 1999 198 4.1. Two Connection Call Flow 200 The diagram below illustrates the basic call flow: 202 ________________________________________________________________________ 203 |Step | User | MG | MGC | H.323 EP | GK | 204 |_____|___________|_____________|________________|_____________|_______| 205 | 0| | <- | RQNT | | | 206 | | | Ack | -> | | | 207 | | | (ready) | | | | 208 | 1| Off- | NTFY | -> | | | 209 | 1a| hook | | (off-hook | | | 210 | | | | recorded) | | | 211 | | | <- | Ack | | | 212 | 2| (dial | <- | RQNT | | | 213 | | tone) | Ack | -> | | | 214 | 3| digit | | | | | 215 | 4| (no dial| | | | | 216 | | tone) | | | | | 217 | 5| digit | | | | | 218 | | ... | | | | | 219 | 10| digit | | | | | 220 | 10a| (match) | NTFY | -> | | | 221 | | | <- | Ack | | | 222 | 10b| | <- | RQNT+ | | | 223 | | | | CRCX-1 | | | 224 | | | Ack(SDP-1)| -> | | | 225 | 11| | | ARQ | - - | -> | 226 | 12| | | <- | - - | ACF | 227 | 12a| | <- | CRCX-2 | | | 228 | 12b| | Ack(SDP-2)| -> | | | 229 | 13| | | SETUP | -> | | 230 | 14| | | | ARQ | -> | 231 | 15| | | | <- | ACF | 232 | 16| | | <- | ALERTING | | 233 | 17| (ring | <- | RQNT + | | | 234 | | back) | | MDFY-1(SDP), | | | 235 | | | | MDFY-2(SDP) | | | 236 | | | Ack, Ack | -> | | | 237 | 18| | | <- | CONNECT | | 238 | 19| (cut- | <- | RQNT | | | 239 | | through)| | +MDFY-2 | | | 240 | | | Ack | -> | | | 241 | | | | (full-duplex | | | 242 | | | | media transfer| | | 243 | | | | recorded) | | | 244 |_____|___________|_____________|________________|_____________|_______| 245 Internet draft MGCP: test case 1 23 February 1999 247 ________________________________________________________________________ 248 |Step| User | MG | MGC | Acc| H.323 EP| GK | 249 |____|__________|___________|________________|______|___________|______| 250 | 20| on-hook| NTFY | -> | | | | 251 | | | <- | Ack | | | | 252 | 21*| | | RELEASE | | | | 253 | | | | COMPLETE | - -| -> | | 254 | 21a| | <- | RQNT+DLCX-1, | | | | 255 | | | | DLCX-2 | | | | 256 | 21b| | Ack, Ack| -> | | | | 257 | | | | (media | | | | 258 | | | | transfer | | | | 259 | | | | stopped) | | | | 260 | | | | (Accounting) | -> | | | 261 |____|__________|___________|________________|______|___________|______| 263 * H.323 only uses Release Complete, hence the test case was modified 264 accordingly. 266 We now describe each of the steps involved in more detail. 268 MGCP is used by the call agent to control the media gateway, which we 269 will refer to as a residential gateway in the following. The call placed 270 from the residential gateway will be routed to an H.323 endpoint. In 271 step 0, we show the first command which is a notification request, sent 272 by the call agent to the residential gateway. The request will consist 273 of the following lines: 275 RQNT 1201 endpoint/1@rgw-2567.example.net MGCP 0.1 276 N: ca@ca1.example.net:5678 277 X: 0123456789AB 278 R: hd 280 The gateway, at that point, is instructed to look for an off-hook event, 281 and to report it. It will first acknowledge the request, repeating in 282 the acknowledgement message the transaction id that the call agent 283 attached to the query. 285 200 1201 OK 287 Note that this command is not actually simultaneous with the call. It 288 can be issued long before the actual call, for example when the gateway 289 is turned on, or after the end of a previous call. 291 When the off hook event is noticed in step 1, the gateway sends a Notify 292 command to the call agent: 294 Internet draft MGCP: test case 1 23 February 1999 296 NTFY 2001 endpoint/1@rgw-2567.example.net MGCP 0.1 297 N: ca@ca1.example.net:5678 298 X: 0123456789AB 299 O: hd 301 This message does not contain the actual time the off-hook event 302 occurred. Instead the Call Agent records the actual time it receives the 303 off-hook notify message in step 1a. Through its extension mechanism, 304 MGCP however allows new experimental parameters to be used and further- 305 more specify whether they are critical extensions that must be under- 306 stood or not. 308 The call agent immediately acknowledges the notify message it received. 310 200 2001 OK 312 The call agent examines the services associated to an off hook action 313 (it could take special actions in the case of a direct line). In most 314 cases, it will send a notification request, asking for digits. The 315 current example instructs the gateway to look for an on-hook event, and 316 to accumulate digits according to the digit map provided. The gateway is 317 furthermore instructed to play dial-tone - step 2: 319 RQNT 1202 endpoint/1@rgw-2567.example.net MGCP 0.1 320 N: ca@ca1.example.net:5678 321 X: 0123456789AC 322 R: hu, [0-9#*T](D) 323 D: ([2-9]xxxxxx| 1xxxxxxxxxx| 0T| [49]11| 011x.T) 324 S: dl 326 The digit map provides the endpoint with a grammar according to which 327 dialed digits are to be accumulated. We discussed the structure of this 328 map in the previous example. 330 Alternatively, we could simply have requested the gateway to notify us 331 each individual digit as it is received, however that would have gen- 332 erated more message traffic, although a simpler gateway may wish to use 333 this mode of operation instead. 335 The gateway immediately acknowledges the notification. 337 200 1202 OK 339 As the user inputs the digits, the gateway will start accumulating 340 digits according to the digit map. When the first digit is entered in 341 step 3, the gateway will immediately stop playing dial-tone (step 4) as 342 the MGCP event detection is synchronized with the signals. When the 343 Internet draft MGCP: test case 1 23 February 1999 345 gateway has noticed a sufficient set of values to produce a digit match 346 (step 5,6,7,8,9,10), the gateway will notify the observed string to the 347 call agent (step 10a). In this case, we assume that the user enters the 348 7-digit destination number "2345678" - notice that the timer event is 349 included in the list of observed events: 351 NTFY 2002 endpoint/1@rgw-2567.example.net MGCP 0.1 352 N: ca@ca1.example.net:5678 353 X: 0123456789AC 354 O: 2,3,4,5,6,7,8,T 356 The call agent immediately acknowledges that notification. 358 200 2002 OK 360 At this stage, the call agent seizes the incoming circuit, creating a 361 connection. It will also send together with that creation request a 362 notification request, to stop collecting digits yet continue watch for 363 an on-hook transition (step 10a): 365 CRCX 1204 endpoint/1@rgw-2567.example.net MGCP 0.1 366 C: A3C47F21456789F0 367 L: p:10, a:PCMU 368 M: recvonly 369 X: 0123456789AD 370 R: hu 372 We notice, that the MGC intends to place a call using G.711 u-law in 373 both directions - a bidirectional channel in H.323 terms - and conse- 374 quently just specifies the codec type PCMU. 376 The gateway immediately acknowledges the creation, sending back the 377 identification of the newly created connection and the session descrip- 378 tion used to receive audio data: 380 200 1204 OK 381 I: FDE234C1 383 v=0 384 c=IN IP4 128.96.41.1 385 m=audio 3456 RTP/AVP 0 387 The SDP announcement, in our example, specifies the address at which the 388 gateway is ready to receive audio data (128.96.41.1), the transport pro- 389 tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio 390 profile refers to RFC 1890, which defines that the payload type 0 has 391 been assigned for G.711 u-law transmission. The IANA maintains a current 392 list of codecs and payload types. 394 Internet draft MGCP: test case 1 23 February 1999 396 In step 11, The call agent, having seized the incoming trunk, proceeds 397 with call routing. Using local databases, it determines that the dialed 398 digits ("2345678") correspond to an H.323 endpoint. The MGC contacts the 399 gatekeeper for the H.323 endpoint by sending an Admission Request (ARQ) 400 containing the dialed number and a request for 128 kbs of bandwidth. 402 In step 12, the gatekeeper returns the Admission Confirm (ACF) message 403 with the call signaling address and port for the called H.323 client. 405 In step 12a, the MGC realizes that using G.711 in both directions is not 406 possible given the bandwidth limitation. The MGC has two choices here in 407 MGCP. It can either choose to create a new connection and thereby main- 408 tain one connection per possible codec, or it can simply instruct the MG 409 to be prepared to used two codecs for this connection. In this case, the 410 MGC knows that it intends to use the H.323 fastStart procedure which 411 implies that the H.323 endpoint will only be able to use unidirectional 412 channels. The usage of the session description protocol in fact still 413 enables the MGC to only use a single connection with asymmetric codec 414 usage and multiple media port addresses, however, for clarity, we assume 415 that the MGC here decides to maintain a separate connection per H.323 416 logical channel. 418 The MGC therefor sends the following CreateConnection command to the MG: 420 CRCX 1205 endpoint/1@rgw-2567.example.net MGCP 0.1 421 C: A3C47F21456789F0 422 L: p:10, a:X-G729C 423 M: recvonly 425 The MG is prepared to use either codec and it therefore sends back an 426 acknowledgement with a new session description: 428 200 1205 OK 429 I: FDE234C2 431 v=0 432 c=IN IP4 128.96.41.1 433 m=audio 3458 RTP/AVP 96 434 a=rtpmap:96 X-G729C/8000 436 Since G.729C is not currently registered with the IANA, we here use the 437 extensibility of SDP and specify a dynamic payload type and an experi- 438 mental codec name for G.729C. 440 In step 13, The MGC will now setup a TCP-IP connection and send an 441 H.225.0 SETUP message to the H.323 entity. In this message, the 442 "fastStart" element carries a set of open logical channel proposals, 443 according to the test case described earlier. Again, it should be noted 444 Internet draft MGCP: test case 1 23 February 1999 446 here, that H.323 is limited to opening unidirectional channels when 447 using fastStart which is why we chose to create separate connections for 448 each of the codec choices. The "fastStart" element for the codec choices 449 will contain the following address information: 451 G.711 RTP receive address:128.96.41.1, 3456 452 G.711 RTCP receive address:128.96.41.1, 3457 454 G.729C RTP receive address:128.96.41.1, 3458 455 G.729C RTCP receive address:128.96.41.1, 3459 457 In step 14 and 15, the H.323 endpoint performs the ARQ and ACF exchange 458 with the gatekeeper and gets permission for its intended bandwidth 459 usage. 461 In step 16, the called H.323 client alerts the user, and sends an 462 H.225.0 ALERTING message to the MGC. The ALERTING message contains a 463 fastStart parameter specifying that the H.323 client will receive G.711 464 u-law and send G.729C thereby opening two unidirectional logical chan- 465 nels. The "fastStart" parameter contains the following address informa- 466 tion: 468 G.711 RTP receive address:128.96.63.25, 1296 469 G.711 RTCP receive address:128.96.63.25, 1297 471 G.729C RTP receive address:N/A 472 G.729C RTCP receive address:128.96.63.25, 1299 474 We note, that under normal circumstances, we could expect to have a sin- 475 gle bidirectional channel instead of two unidirectional channels. Furth- 476 ermore, such a channel should be able to use different codecs in each 477 direction. 479 In step 17, the MGC must now make the MG alert the phone attached, and 480 it must furthermore inform the MG that it needs to send G.711, and 481 receive G.729C, and provide the relevant addresses for each. The MGC 482 issues two commands using the MGCP piggy-backing functionality; a com- 483 bined modify connection and request notification command for the first 484 connection, and a modify connection command for the second connection: 486 Internet draft MGCP: test case 1 23 February 1999 488 MDCX 1206 endpoint/1@rgw-2567.example.net MGCP 0.1 489 C: A3C47F21456789F0 490 I: FDE234C1 491 L: p:10, a:PCMU 492 M: inactive 493 X: 0123456789AE 494 R: hu 495 S: v 497 v=0 498 c=IN IP4 128.96.63.25 499 m=audio 1296 RTP/AVP 0 500 a=sendonly 501 . 502 MDCX 1207 endpoint/1@rgw-2567.example.net MGCP 0.1 503 C: A3C47F21456789F0 504 I: FDE234C2 505 M: recvonly 507 v=0 508 c=IN IP4 128.96.63.25 509 m=audio 1298 RTP/AVP 96 510 a=rtpmap:96 X-G729C/8000 511 a=recvonly 513 We here note, that having to manage multiple connections is rather 514 cumbersome - it would be simpler if we only had to manage a single con- 515 nection instead. 517 The first ModifyConnection command contains instructions to play alert- 518 ing tones, and continue to look for on-hook events. The use of Session 519 Description Protocol (SDP) provides us with a standardized and flexible 520 method for specifying multimedia as we can see above. The session 521 description for the first connection specifies where to the media for 522 the connection should be sent as well as the payload type expected. It 523 also specifies that it will only be used in the send direction, although 524 the current mode for the connection is inactive, as specified by the 525 LocalConnectionOptions. 527 The session description for the second ModifyConnection command provides 528 a similar specification, however in this case we see that we will only 529 receive media. The IP-address and port specification included allows us 530 to send RTCP information to the sender though. 532 The MG immediately acknowledges the two commands above, again utilizing 533 the piggy-backing functionality (this is in fact an optimization - the 534 MG could equally well send two separate datagrams): 536 Internet draft MGCP: test case 1 23 February 1999 538 200 1206 OK 539 . 540 200 1207 OK 542 When the called H.323 user accepts the call, the H.323 endpoint sends an 543 H.225.0 CONNECT message to the MGC - step 18. 545 In step 19, the MGC must now cutthrough a full-duplex voice path and 546 stop the alerting tones - note that we up until now have had a half- 547 duplex path which, e.g. would enable the far-end side to play an 548 announcement if needed. The MGC sends the following combined modify con- 549 nection and notification request command to the MG: 551 MDCX 1208 endpoint/1@rgw-2567.example.net MGCP 0.1 552 C: A3C47F21456789F0 553 I: FDE234C1 554 M: sendonly 555 X: 0123456789AF 556 R: hu 558 The gateway immediately acknowledges the transaction: 560 200 1208 OK 562 When the MGC receives the response, it then knows that a full duplex 563 media path (although not connection) is in place between the two end- 564 points. The message does not contain the actual time the transaction was 565 completed and thus the full duplex path established. Instead the Call 566 Agent records the time it receives the response. Alternatively, the MGCP 567 extension mechanism could be used. 569 The call is now established. 571 In step 20, the calling party now hangs up the phone. This triggers a 572 Notify command to the MGC: 574 NTFY 2005 endpoint/1@rgw-2567.example.net MGCP 0.1 575 X: 0123456789AF 576 O: hu 578 The MGC immediately acknowledges the command: 580 200 2005 OK 582 The MGC then determines, that the call should end, and per step 21, it 583 therefore sends an H.225.0 RELEASE COMPLETE message to the H.323 end- 584 point. 586 Internet draft MGCP: test case 1 23 February 1999 588 The MGC also sends two commands to the MG using the piggy-backing func- 589 tionality; a combined delete connection and notification request command 590 for the first connection and simply a delete connection command for the 591 second connection - we note again the overhead associated with managing 592 multiple connections: 594 DLCX 1210 endpoint/1@rgw-2567.example.net MGCP 0.1 595 C: A3C47F21456789F0 596 I: FDE234C1 597 X: 0123456789B0 598 R: hd 599 . 600 DLCX 1211 endpoint/1@rgw-2567.example.net MGCP 0.1 601 C: A3C47F21456789F0 602 I: FDE234C2 604 We could in fact have used another form of the DeleteConnection command 605 here where we simply referred to the CallId for the endpoint, however 606 that would not have provided us with statistics for the connections. The 607 MG response as follows: 609 250 1210 OK 610 P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=0 611 . 612 250 1211 OK 613 P: PS=0, OS=0, PR=780, OR=45123, PL=10, JI=27, LA=48 615 The connection parameters returned provide us with statistics for the 616 connections. Specifically we see that we have statistics for media pack- 617 ets and octets sent and received, number of media packets lost, and mean 618 interarrival jitter as well. The response does not include the actual 619 time the media transfer stopped, however the MGC can use the time the 620 response was received, or perhaps the time the on-hook Notify message 621 was received. As another option, the MG could in fact use the MGCP 622 extension mechanism for connection parameters which allows it to pass 623 new connection parameter such as time to the MGC, as in: 625 P: PS=0, OS=0, PR=780, OR=45123, PL=10, JI=27, LA=48, X-T1=1234, 626 X-T2=4321 628 Internet draft MGCP: test case 1 23 February 1999 630 4.2. One Connection Call Flow 632 The diagram below illustrates the basic call flow: 634 ____________________________________________________________________ 635 |Step| User | MG | MGC | H.323 EP| GK | 636 |____|___________|___________|__________________|__________|_______| 637 | 0| | <- | RQNT | | | 638 | | | Ack | -> | | | 639 | | | (ready) | | | | 640 | 1| Off- | NTFY | -> | | | 641 | 1a| hook | | (off-hook | | | 642 | | | | recorded) | | | 643 | | | <- | Ack | | | 644 | 2| (dial | <- | RQNT | | | 645 | | tone) | Ack | -> | | | 646 | 3| digit | | | | | 647 | 4| (no | | | | | 648 | | dial | | | | | 649 | | tone) | | | | | 650 | 5| digit | | | | | 651 | | ... | | | | | 652 | 10| digit | | | | | 653 | 10a| (match) | NTFY | -> | | | 654 | | | <- | Ack | | | 655 | 10b| | <- | RQNT+CRCX | | | 656 | | | Ack(SDP)| -> | | | 657 | 11| | | ARQ | - - | -> | 658 | 12| | | <- | - - | ACF | 659 | 12a| | <- | MDCX | | | 660 | 12b| | Ack(SDP)| -> | | | 661 | 13| | | SETUP | -> | | 662 | 14| | | | ARQ | -> | 663 | 15| | | | <- | ACF | 664 | 16| | | <- | ALERTING| | 665 | 17| (ring | <- | RQNT+ | | | 666 | | back) | | MDFY(SDP) | | | 667 | | | Ack | -> | | | 668 | 18| | | <- | CONNECT | | 669 | 19| (cut- | <- | RQNT+MDFY | | | 670 | | through)| | Ack | -> | | 671 | | | | (full duplex | | | 672 | | | | media transfer | | | 673 | | | | recorded) | | | 674 |____|___________|___________|__________________|__________|_______| 675 Internet draft MGCP: test case 1 23 February 1999 677 ______________________________________________________________ 678 |Step| User | MG | MGC | ACC | H.323 EP | GK| 679 | _ | | | | | | | 680 | 20| on-hook| NTFY| -> | | | | 681 | | | <- | Ack | | | | 682 | 21| | | RELEASE | - -| -> | | 683 | 21a| | <- | RQNT+DLCX| | | | 684 | 21b| | Ack | -> | | | | 685 | 22| | | <- | - -| RELEASE | | 686 | | | | | | COMPLETE| | 687 |____|__________|_______|___________|______|___________|_____| 689 We now describe each of the steps involved in more detail. 691 MGCP is used by the call agent to control the media gateway, which we 692 will refer to as a residential gateway in the following. The call placed 693 from the residential gateway will be routed to an H.323 endpoint. In 694 step 0, we show the first command which is a notification request, sent 695 by the call agent to the residential gateway. The request will consist 696 of the following lines: 698 RQNT 1201 endpoint/1@rgw-2567.example.net MGCP 0.1 699 N: ca@ca1.example.net:5678 700 X: 0123456789AB 701 R: hd 703 The gateway, at that point, is instructed to look for an off-hook event, 704 and to report it. It will first acknowledge the request, repeating in 705 the acknowledgement message the transaction id that the call agent 706 attached to the query. 708 200 1201 OK 710 Note that this command is not actually simultaneous with the call. It 711 can be issued long before the actual call, for example when the gateway 712 is turned on, or after the end of a previous call. 714 When the off hook event is noticed in step 1, the gateway sends a Notify 715 command to the call agent: 717 NTFY 2001 endpoint/1@rgw-2567.example.net MGCP 0.1 718 N: ca@ca1.example.net:5678 719 X: 0123456789AB 720 O: hd 722 This message does not contain the actual time the off-hook event 723 occurred. Instead the Call Agent records the actual time it receives the 724 Internet draft MGCP: test case 1 23 February 1999 726 off-hook notify message in step 1a. 728 The call agent immediately acknowledges the notify message it received. 730 200 2001 OK 732 The call agent examines the services associated to an off hook action 733 (it could take special actions in the case of a direct line). In most 734 cases, it will send a notification request, asking for digits. The 735 current example instructs the gateway to look for an on-hook event, and 736 to accumulate digits according to the digit map provided. The gateway is 737 furthermore instructed to play dial-tone - step 2: 739 RQNT 1202 endpoint/1@rgw-2567.example.net MGCP 0.1 740 N: ca@ca1.example.net:5678 741 X: 0123456789AC 742 R: hu, [0-9#*T](D) 743 D: ([2-9]xxxxxx| 1xxxxxxxxxx| 0T| [49]11| 011x.T) 744 S: dl 746 The digit map provides the endpoint with a grammar according to which 747 dialed digits are to be accumulated. In this case, we have an ambiguous 748 grammar, due to a conflict between "0" and "011". A timer is therefore 749 included with the grammar for the 0 number. Since we don't have any res- 750 trictions on the valid length of an international number we simply 751 specified it as consisting of an arbitrary number of digits, where end 752 of input again is based on a timer. We could have specified, e.g. a 753 pound sign ("#") as well, if we wanted to allow the user to explicitly 754 signal that he has finished entering his destination number. 756 Alternatively, we could simply have requested the gateway to notify us 757 each individual digit as it is received, however that would have gen- 758 erated more message traffic, although a simpler gateway may wish to use 759 this mode of operation instead. 761 The gateway immediately acknowledges the notification. 763 200 1202 OK 765 As the user inputs the digits, the gateway will start accumulating 766 digits according to the digit map. When the first digit is entered in 767 step 3, the gateway will immediately stop playing dial-tone (step 4) as 768 the MGCP event detection is synchronized with the signals. When the 769 gateway has noticed a sufficient set of values to produce a digit match 770 (step 5,6,7,8,9,10), the gateway will notify the observed string to the 771 call agent (step 10a). In this case, we assume that the user enters the 772 7-digit destination number "2345678" - notice that the timer event is 773 included in the list of observed events: 775 Internet draft MGCP: test case 1 23 February 1999 777 NTFY 2002 endpoint/1@rgw-2567.example.net MGCP 0.1 778 N: ca@ca1.example.net:5678 779 X: 0123456789AC 780 O: 2,3,4,5,6,7,8,T 782 The call agent immediately acknowledges that notification. 784 200 2002 OK 786 At this stage, the call agent seizes the incoming circuit, creating a 787 connection. It will also send together with that creation request a 788 notification request, to stop collecting digits yet continue watch for 789 an on-hook transition (step 10a): 791 CRCX 1204 endpoint/1@rgw-2567.example.net MGCP 0.1 792 C: A3C47F21456789F0 793 L: p:10, a:PCMU 794 M: recvonly 795 X: 0123456789AD 796 R: hu 798 We notice, that the Call Agent intends to place a call using G.711 u-law 799 in both directions, and consequently just specifies the codec type PCMU. 801 The gateway immediately acknowledges the creation, sending back the 802 identification of the newly created connection and the session descrip- 803 tion used to receive audio data: 805 200 1204 OK 806 I: FDE234C8 808 v=0 809 c=IN IP4 128.96.41.1 810 m=audio 3456 RTP/AVP 0 812 The SDP announcement, in our example, specifies the address at which the 813 gateway is ready to receive audio data (128.96.41.1), the transport pro- 814 tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio 815 profile refers to RFC 1890, which defines that the payload type 0 has 816 been assigned for G.711 u-law transmission. The IANA maintains a current 817 list of codecs and payload types. 819 In step 11, The call agent, having seized the incoming trunk, proceeds 820 with call routing. Using local databases, it determines that the dialed 821 digits (2345678) correspond to an H.323 endpoint. The MGC now contacts 822 the gatekeeper for the H.323 endpoint by sending an Admission Request 823 (ACF) containing the dialed number and a request for 128 kbs of 824 Internet draft MGCP: test case 1 23 February 1999 826 bandwidth. 828 In step 12, the gatekeeper returns the Admission Confirm (ACF) message 829 with the call signaling address and port for the called H.323 client. 831 In step 12a, the MGC realizes that using G.711 in both directions is not 832 possible given the bandwidth limitation. The MGC has two choices here in 833 MGCP. It can either choose to create a new connection and thereby main- 834 tain one connection per possible codec, or it can simply instruct the MG 835 to be prepared to used two codecs for this connection. In this case, the 836 MGC finds it easier to simply instruct the MG to be prepared to use two 837 different codecs, and it therefore sends a ModifyConnection command to 838 the MG: 840 MDCX 1205 endpoint/1@rgw-2567.example.net MGCP 0.1 841 C: A3C47F21456789F0 842 I: FDE234C8 843 L: p:10, a:PCMU,G729C 844 M: recvonly 846 The MG is prepared to use either codec and it therefore sends back an 847 acknowledgement with a new session description: 849 200 1205 OK 851 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 18 853 Since G.729C is not currently registered with the IANA, we here use the 854 extensibility of SDP and specify a dynamic payload type and an experi- 855 mental codec name for G.729C. We note, that a single IP-address and port 856 can here be used with different codecs. 858 In step 13, The MGC will now setup a TCP-IP connection and send an 859 H.225.0 SETUP message to the H.323 entity. In this message, the 860 "fastStart" element carries a set of open logical channel proposals, 861 according to the test case described earlier. It should be noted here, 862 that H.323 is limited to opening unidirectional channels when using 863 fastStart. Regardless, for both G.711 and G.729C, the address informa- 864 tion will be as follows since the two codecs represent a choice: 866 RTP receive address:128.96.41.1, 3456 867 RTCP receive address:128.96.41.1, 3457 869 In step 14 and 15, the H.323 endpoint performs the ARQ and ACF 870 exchange with the gatekeeper and gets permission for its intended 871 bandwidth usage. 873 In step 16, the called H.323 client alerts the user, and sends an 874 Internet draft MGCP: test case 1 23 February 1999 876 H.225.0 ALERTING message to the MGC. The ALERTING message contains a 877 fastStart parameter specifying that it will receive G.711 u-law and send 878 G.729C thereby opening two unidirectional logical channels. 880 G.711 RTP receive address:128.96.63.25, 1296 881 G.711 RTCP address:128.96.63.25, 1297 883 G.729C RTP receive address:N/A 884 G.729C RTCP address:128.96.63.25, 1299 886 The MG can thus issue sender reports 888 Note, that under normal circumstances, we could expect to have a single 889 bidirectional channel instead of two unidirectional channels. 891 In step 17, the MGC must now make the MG alert the phone attached, and 892 it must furthermore inform the MG that it needs send G.711, and receive 893 G.729C, and provide the relevant addresses for each. It should be noted 894 that there in fact is a separate RTCP address to be used for each of 895 these unidirectional streams, however the H.323 endpoint will have one 896 SSRC identifier and the MG will have another SSRC identifier. Again, at 897 this point in time, the MGC could choose to create a new connection if 898 it wanted to have a separate connection for each logical channel. The 899 MGC issues the following combined modify connection and request notifi- 900 cation command: 902 MDCX 1206 endpoint/1@rgw-2567.example.net MGCP 0.1 903 C: A3C47F21456789F0 904 I: FDE234C8 905 L: p:10, a:PCMU 906 M: recvonly 907 X: 0123456789AE 908 R: hu 909 S: v 911 v=0 912 c=IN IP4 128.96.63.25 913 m=audio 1296 RTP/AVP 0 914 a=sendonly 915 m=audio 1298 RTP/AVP 96 916 a=rtpmap:96 X-G729C/8000 917 a=recvonly 919 We here note how the use of Session Description Protocol (SDP) allows us 920 to provide multiple media specifications, similar to H.245's logical 921 channels. A couple of things are worth noting above. First of all, the 922 LocalConnectionOptions specify the use of G.711 u-law informing the 923 gateway that it should use G.711 when sending media. The session 924 Internet draft MGCP: test case 1 23 February 1999 926 description informs the MG about the other end of the connection. For 927 G.711 media, we specify that it is only to be sent, and that it specifi- 928 cally is to be sent to IP-address 128.96.63.25 and port number 1296. For 929 G.729C, we currently specify that if it was to be sent, then it would be 930 sent to port number 1298, which allows us to infer that the RTCP port 931 number for G.729C is 1299. Since we have specified receive-only for 932 G.729C, and sendonly for G.711, we now have asymmetric codec usage for 933 the connection. 935 The call flow will then proceed in a manner very similar to our first 936 example. After receiving the "CONNECT" response, the MGC will send a 937 combination of notification request and modification command to validate 938 the two media Streams. At the end of the connection, the hangup will be 939 signalled, the connection will be released, and the statistics will be 940 collected. 942 5. Discussion 944 The call flows that we showed test, in a sense, one of the limits of 945 MGCP, i.e. its lack of optimization for the handling of multiple simul- 946 taneous connections. We also showed two minor limitations in the 947 "accounting" interface, i.e. some imprecision in the measurement of 948 time, and a lack of a clear signal indicating the moment at which a 949 media starts flowing. 951 We will discuss here how the protocol could be tuned to remove these 952 constraints. 954 5.1. Handling of multiple connections 956 MGCP has been mostly used to date in environments where connections 957 could be established in a "symmetric" manner, when both sides of the 958 connection would use the same parameters, and could use full-duplex con- 959 nections. There are definitive advantages to using full-duplex connec- 960 tions when possible, such as a simpler signalling exchange, simpler 961 accounting and also more efficient use of RTCP. 963 Having a full duplex connection does not mandate that the same compres- 964 sion algorithm be used in both directions. In fact, MGCP uses separate 965 "session descriptions" for each direction, and specifying different 966 algorithms in each of these is fairly straightforward. A full duplex 967 connection, however, can only use one RTCP port for both directions of 968 transmission. 970 H.323 allows both duplex and simplex logical channels. When simplex 971 channels are used, the two directions are constructed independently, 972 which results in the scenario showed in our first call flow. MGCP, as 973 showed in the first call flow, can indeed be used to construct simplex 974 Internet draft MGCP: test case 1 23 February 1999 976 connections, and we have used this capability to match one to one MGCP 977 connections and H.323 logical channels. 979 Managing two connections instead of one essentially results in twice as 980 many commands. MGCP could be optimized for this task, essentially by 981 using an extension of the "command embedding" proposed by Nancy Greene 982 developed in the "packet relay" draft [5]. The embedding will allow us 983 to easily combine commands related to different connections, as well as 984 notification requests, in a single "atomic" construct, without having to 985 repeat common parameters such as the names of endpoints. 987 5.2. Limitations of the accounting interface 989 The accounting interface showed two limitations. First, the reporting 990 is based on the arrival time of signalling packets, which includes a 991 variable transmission delay. Then, the media flows are assumed to start 992 immediately after the connection establishment, which is not necessarily 993 always true. 995 The timing imprecision resulting of command transmission delays is 996 bounded by these transmission delays. It is unlikely to exceed a frac- 997 tion of a second, thus meeting the requirements of most accounting pro- 998 cedures. Including timestamps in the various commands, responses and 999 event reports would be possible, but would only be valuable if every 1000 gateway was equipped with a synchronized clock, for example by using the 1001 Network Time Protocol. There are in fact many arguments for having syn- 1002 chronized clocks in all network equipments, such as better management 1003 and more precise logging procedures. However, the addition of this 1004 feature in low-end equipments such as residential gateways has been 1005 resisted by manufacturers, because of complexity and cost considera- 1006 tions. The accounting requirements are probably not sufficient to 1007 change the manufacturers' position. In any case, the time at which a 1008 call starts, or end, is by nature imprecise: both ends don't notice it 1009 at the same time. 1011 MGCP could very easily be used to provide a notification of the time at 1012 which media packet have started being exchanged. It suffices to define 1013 a "start of transmission" event in the RTP package, triggered when the 1014 first media packet is received, or sent, and to use standard event 1015 notification procedures. 1017 6. Conclusion 1019 This document has shown that MGCP satisfies Megaco call flow test case 1020 1. It has furthermore also demonstrated that MGCP provides a simply, yet 1021 powerful and flexible solution to Megaco. MGCP normally assumes bidirec- 1022 tional connections, while this test case fundamentally assumes the use 1023 of unidirectional media streams through the use of H.323 fastStart. MGCP 1024 Internet draft MGCP: test case 1 23 February 1999 1026 has proven that it could easily satisfy such a scenario. In the course 1027 of doing this, it was furthermore demonstrated, that it is preferable to 1028 not have to manage any more connections than necessary - the hybrid 1029 model that MGCP is based upon fully satisfies this. 1031 7. References 1033 [0] Arango, M., A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Media 1034 Gateway Control Protocol (MGCP)", work in progress. 1036 [1] ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYSTEMS AND EQUIP- 1037 MENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY 1038 OF SERVICE." 1040 [2] ITU-T, Recommendation H.225, "Call Signaling Protocols and Media 1041 Stream Packetization for Packet Based Multimedia Communications 1042 Systems." 1044 [3] ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-TELEPHONE 1045 SIGNALS." 1047 [4] Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session Initiation 1048 Protocol", work in progress 1050 [5] Huitema, C., Andreasen, F., "Media Gateway Control Protocol (MGCP) 1051 Support for Packet Relays" 1053 8. Authors' Addresses 1054 Internet draft MGCP: test case 1 23 February 1999 1056 Christian Huitema 1057 Bellcore 1058 MCC 1J236B 1059 445 South Street 1060 Morristown, NJ 07960 1061 U.S.A. 1063 Phone: +1 973-829-4266 1064 EMail: huitema@bellcore.com 1066 Flemming Andreasen 1067 Bellcore 1068 RRC-1M223 1069 444 Hoes Lane 1070 Piscataway, NJ 08854-4157 1071 U.S.A. 1073 Phone: +1 732 699-7351 1074 EMail: fandreas@notes.cc.bellcore.com