idnits 2.17.1 draft-huitema-megaco-mgcp-flows-01.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 Internet-Drafts being working documents. ** 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. == 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 an Authors' Addresses Section. ** There are 804 instances of too long lines in the document, the longest one being 32 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 63 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 95 has weird spacing: '...ic call from ...' == Line 1275 has weird spacing: '...Request to st...' == Line 2127 has weird spacing: '...ataType g711...' == Line 2140 has weird spacing: '...ameters none...' == Line 2143 has weird spacing: '...ataType g711...' == (10 more instances...) -- 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 5165 looks like a reference -- Missing reference section? '0' on line 5161 looks like a reference -- Missing reference section? '2' on line 5170 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 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 January 20, 1999 Mauricio Arango 6 Expires: June 18, 1999 RSL COM 7 Prakash K 8 TELESOFT INC 10 Media Gateway Control Protocol (MGCP) Call Flows 11 Christian Huitema, Flemming Andreasen, Mauricio Arango, Prakash K 13 Status of this document 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026 except for the right to produce 17 derivative works. 19 This document is an Internet-Draft. Internet-Drafts are working docu- 20 ments of the Internet Engineering Task Force (IETF), its areas, and its 21 working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as "work in progress." 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 32 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 33 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 The Media Gateway Control Protocol (MGCP) organizes the communication 38 between a Media Gateway controller, or call agent, and a Media Gateway, 39 e.g. a Voice over IP gateway or a Network Access Server. MGCP is 40 defined in a companion document [1]. This document provides example of 41 MGCP usage by providing a variety of call flows, in the case of 42 telephony and network access servers. 44 Internet draft MGCP Call Flows 20 January 1999 46 Table of Contents Page 48 1. Introduction .............................................. 2 49 2. Internet Telephony Call Flows. ............................ 2 50 3. Interaction between an MGCP gateway and an H.323 entity ... 2 51 4. Interworking between SIP and MGCP ......................... 2 52 5. Data calls ................................................ 2 53 6. Audit and Restart ......................................... 2 54 7. Using MGCP to control an IVR .............................. 2 55 8. Acknowledgements .......................................... 2 56 9. References ................................................ 2 57 10. Authors' Addresses ....................................... 2 58 Internet draft MGCP Call Flows 20 January 1999 60 1. Introduction 62 In order to understand the way the MGCP interface will be used, we have 63 described here several possible call flows between a TGW, which is a 64 trunking gateway that implements MGCP, and an RGW, which is a residen- 65 tial gateway that implements MGCP, as well as several call flows 66 describing how MGCP could be used to control a network access service. 67 For each of these call flows it is assumed that the default event pack- 68 ages are as follows: 70 TGW Trunk package 72 RGW Line package 74 NAS Network Access Server package 76 The diagrams also show a Common Database (CDB) that can be queried for 77 authorization and routing information, and an Accounting Gateway (ACC) 78 that collects accounting information at the start and the end of calls. 80 These diagrams are solely meant to exhibit the behavior of the MGCP, and 81 to help understanding this protocol. They are not meant as a tutorial on 82 the implementation of a Call Agent. They may very well include miscel- 83 laneous errors and imprecisions. 85 Internet draft MGCP Call Flows 20 January 1999 87 2. Internet Telephony Call Flows. 89 We present seven Internet Telephony call flows: 91 * A basic call between two "trunking gateways", 93 * A basic call from a "residential gateway" to a "trunking gateway", 95 * A basic call from a "trunking gateway" to a "residential gateway". 97 * A basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW. 99 * A basic call from an ISDN trunk in a business gateway to an SS7 100 trunk in a TGW. 102 * A basic call with continuity test, from a "trunking gateway" to a 103 "residential gateway". 105 * A "hairpin" connection between two endpoints on a trunking gateway, 106 using regular call set-up procedures. 108 * A "hairpin" connection between two endpoints on a residential gate- 109 way, using accelerated procedures. 111 Internet draft MGCP Call Flows 20 January 1999 113 2.1. Connection from a TGW to another TGW 115 The figure below gives the flow that results in a connection between two 116 trunking gateways. 118 ______________________________________ 119 | sw1| SG1| TGW1| CA | TGW2| SG2| 120 |____|_____|______|______|______|_____| 121 | IAM| -> | | | | | 122 | | IAM| - - | -> | | | 123 | | | <- | CRCX| | | 124 | | | ACK | -> | | | 125 | | | | CRCX| -> | | 126 | | | | <-| ACK | | 127 | | | | IAM | - - | -> | 128 | | | | | | IAM| 129 | | | | | | <-| 130 | | | | <-| - - | ACM| 131 | | | <- | ACM | | | 132 | <-| - -| ACM | | | | 133 | | ...| | | | | 134 | | | | | | <-| 135 | | | | <-| - - | ACM| 136 | | | <- | MDCX| | | 137 | | | ACK | -> | | | 138 | | <-| - - | ANM | | | 139 | <-| ANM| | | | | 140 | REL| -> | | | | | 141 | | REL| - - | -> | | | 142 | | | <- | DLCX| | | 143 | | | Perf| -> | | | 144 | | | data| | | | 145 | | <-| - - | RLC | | | 146 | <-| RLC| | | | | 147 | | | | DLCX| -> | | 148 | | | | <-| Perf| | 149 | | | | | data| | 150 | | | | REL | - - | -> | 151 | | | | | | REL| 152 | | | | | | <-| 153 | | | | <-| - - | RLC| 154 |____|_____|______|______|______|_____| 156 During these exchanges the MGCP is used by the Call Agent to control the 157 two endpoints located on the two TGW. 159 The exchanges start with the arrival from the first switch (SW1) of an 160 Internet draft MGCP Call Flows 20 January 1999 162 SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call 163 Agent. The call agent performs the routing, and determines that the 164 call will have to be relayed towards the second switch (SW2), using a 165 trunk located on TGW2. 167 The call agent starts the exchange by seizing the endpoint referenced in 168 the IAM message: 170 CRCX 1204 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 171 C: A3C47F21456789F0 172 L: p:10, a:G.711 173 M: recvonly 175 Upon reception of that command, the trunking gateway prepares a connec- 176 tion description. 178 200 1204 OK 179 I:FDE234C8 181 v=0 182 c=IN IP4 128.96.41.1 183 m=audio 3456 RTP/AVP 0 185 The call agent, upon reception of this acknowledgement, sends a connec- 186 tion request to the trunking gateway, asking the gateway to reserve a 187 trunk in the group connected to the second switch: 189 CRCX 1205 trunk-group-2/$@tgw2.whatever.net MGCP 0.1 190 C: A3C47F21456789F0 191 M: sendrecv 193 v=0 194 c=IN IP4 128.96.41.1 195 m=audio 3456 RTP/AVP 0 197 The call agent selects a trunk in the group, and acknowledges the crea- 198 tion: 200 200 1204 OK 201 I:abc0 203 v=0 204 c=IN IP4 128.96.63.25 205 m=audio 1296 RTP/AVP 0 207 Internet draft MGCP Call Flows 20 January 1999 209 The two commands have created a one way path, suitable for forwarding 210 ring tones and announcements to the calling party. The call agent can 211 now relay the call by sending an IAM message to the second switch. When 212 the ACM is received, it is immediately relayed to the first switch. 214 After some time, the call is answered, and an ANM message is relayed 215 from the second switch to the call agent. The call agent will first 216 validate the call by asking the first end-point to place the connection 217 in duplex mode: 219 MDCX 1206 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 220 C: A3C47F21456789F0 221 I:FDE234C8 222 M: sendrecv 224 v=0 225 c=IN IP4 128.96.63.25 226 m=audio 1296 RTP/AVP 0 228 The trunking gateway executes and acknowledges the modification: 230 200 1206 OK 232 The call agent can now relay the ANM message to the calling 233 switch, and both parties can talk. 235 At the end of the call, in our example, the calling party hangs 236 up. The first switch sends a release message to the call agent, 237 through the signalling gateway. The call agent releases the 238 connection on the first endpoint: 240 DLCX 1207 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 241 C: A3C47F21456789F0 242 I:FDE234C8 244 The gateway acknowledges the deletion, sending the connection 245 parameters: 247 250 1217 OK 248 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 250 The call agent can now confirm the release of the trunk, sending 251 an RLC message to the first switch. 253 In parallel, the call agent releases the connection to the 254 second endpoint: 256 Internet draft MGCP Call Flows 20 January 1999 258 DLCX 1208 trunk-group-2/13@tgw2.whatever.net MGCP 0.1 259 C: A3C47F21456789F0 260 I:abc0 262 The gateway acknowledges the deletion, sending the connection 263 parameters: 265 250 1218 OK 266 P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48 268 After receiving the acknowledgement, the call agent can relay 269 the release message to the second switch. The switch will in 270 turn acknowledge the release. 272 Internet draft MGCP Call Flows 20 January 1999 274 2.2. Basic call, RGW to TGW 276 ______________________________________________________________________ 277 | Usr | RGW | CA | CDB| ACC| TGW | SS7/| CO | 278 | | | | | | | ISUP| | 279 |_______|__________|______________|_____|_____|__________|______|_____| 280 | | <- | RQNT | | | | | | 281 | | Ack | -> | | | | | | 282 | Off | | | | | | | | 283 | -hook | (local | | | | | | | 284 | (Dial | action) | | | | | | | 285 | -tone)| | | | | | | | 286 | Digits| Notify | -> | | | | | | 287 | | <- | Ack | | | | | | 288 | (pro- | <- | CRCX+RQNT | | | | | | 289 | gress)| Ack | -> | | | | | | 290 | | | Query | | | | | | 291 | | | (E.164 S,D) | -> | | | | | 292 | | | <- | IP | | | | | 293 | | | CRCX | - -| - -| -> | | | 294 | | | | | | (cut in)| | | 295 | | | <- | - -| - -| ack | | | 296 | | | IAM | - -| - -| - - | -> | | 297 | | <- | MDCX | | | | IAM | -> | 298 | | Ack | -> | | | | <- | ACM| 299 | | | <- | - -| - -| - - | ACM | | 300 | | <- | Notification| | | | | | 301 | | | Request | | | | | | 302 | | Ack | -> | | | | | | 303 | | | | | | | <- | ANM| 304 | | | <- | - -| - -| - - | ANM | | 305 | | <- | MDCX+RQNT | | | | | | 306 | | Ack | -> | | | | | | 307 | | (cut in)| Call start | - -| -> | | | | 308 |_______|__________|______________|_____|_____|__________|______|_____| 310 Internet draft MGCP Call Flows 20 January 1999 312 __________________________________________________________________ 313 | Usr | RGW | CA | CDB| ACC| TGW | SS7/| CO | 314 | | | | | | | ISUP| | 315 |________|________|______________|_____|_____|_______|______|_____| 316 | | | | | | | <- | REL| 317 | | | <- | - -| - -| - - | REL | | 318 | | <- | Delete | | | | | | 319 | | | Connection | | | | | | 320 | | | Delete | | | | | | 321 | | | Connection | - -| - -| -> | | | 322 | | Perf | | | | | | | 323 | | Data | -> | | | | | | 324 | | | <- | - -| - -| perf | | | 325 | | | | | | data | | | 326 | | | Call end | - -| -> | | | | 327 | On-hook| Notify| -> | | | | | | 328 | | <- | Ack | | | | | | 329 | | <- | Notification| | | | | | 330 | | | Request | | | | | | 331 | | Ack | -> | | | | | | 332 |________|________|______________|_____|_____|_______|______|_____| 334 During these exchanges the MGCP is used by the Call Agent to 335 control both the TGW and the residential gateway. The exchanges 336 occur on two sides. 338 The first command is a NotificationRequest, sent by the Call 339 Agent to the residential gateway. The request will consist of 340 the following lines: 342 RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 343 N: ca@ca1.whatever.net:5678 344 X: 0123456789AC 345 R: hd(E(dl;hu, D/[0-9#*T](D);) 346 D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 347 S: 349 That transaction illustrates the power of the "embedded" action. 350 The gateway is instructed to look for an off-hook event, and, 351 upon its detection, to provide a dial-tone and to start looking 352 for DTMF digits. The gateway immediately acknowledges the com- 353 mand, repeating in the acknowledgement message the transaction 354 id that the Call Agent attached to the query. 356 200 1201 OK 358 Internet draft MGCP Call Flows 20 January 1999 360 When the off hook event is noticed, the gateway provides the 361 dial tone to the line (the delay between off-hook and dialtone 362 is thus minimal.) 364 The gateway will start accumulating digits according to that 365 digit map. When it has noticed a sufficient set of values, it 366 will notify the observed string to the Call Agent: 368 NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 369 N: ca@ca1.whatever.net:5678 370 X: 0123456789AC 371 O: 912018294266 373 The Call Agent immediately acknowledges that notification. 375 200 2002 OK 377 The Call Agent will then seize the incoming circuit, creating a 378 connection. The create connection commands piggybacks a notifi- 379 cation request, to stop collecting digits yet continue watch for 380 an on-hook transition: 382 CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 383 C: A3C47F21456789F0 384 L: p:10, a:G.711;G.726-32 385 M: recvonly 386 X: D/0123456789AD 387 R: hu 388 S: 390 We should note at this point that the call agent could send 391 the acknowledgement of the Notify and the CRCX in a single 392 UDP packet, as explained in the "piggy backing" section of 393 [1]. There are many possible groupings of that nature in 394 the various examples. 396 The gateway immediately acknowledges the creation, sending back 397 the identification of the newly created connection and the ses- 398 sion description used to receive audio data: 400 200 1204 OK 401 I:FDE234C8 403 v=0 404 c=IN IP4 128.96.41.1 406 Internet draft MGCP Call Flows 20 January 1999 408 m=audio 3456 RTP/AVP 0 96 409 a=rtpmap:96 G726-32/8000 411 The SDP announcement, in our example, specifies the address at 412 which the gateway is ready to receive audio data (128.96.41.1), 413 the transport protocol (RTP), the RTP port (3456) and the audio 414 profile (AVP). The audio profile refers to RFC 1890, which 415 defines that the payload type 0 has been assigned for G.711 416 transmission. The gateway is also ready to use ADPCM encoding at 417 32 kbps (G.726 -4). There is no standard payload type associated 418 to ADPCM, so the gateway mentions its readiness to use a non 419 standard payload associated to the dynamic type 96. The "rtpmap" 420 attribute entry associates the payload type 96 to G726-32/4. 422 The Call Agent, having seized the incoming trunk and completed a 423 routing look up to identify the outgoing gateway, must now seize 424 the outgoing trunk. It does so by sending a connection command 425 to the e-gress gateway: 427 CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 428 C: A3C47F21456789F0 429 L: p:10, a:G.711;G.726-32 430 M: sendrecv 432 v=0 433 c=IN IP4 128.96.41.1 434 m=audio 3456 RTP/AVP 0 96 435 a=rtpmap:96 G726-32/8000 437 The CreateConnection command has the same parameters as the com- 438 mand sent to the ingress gateway, with two differences: 440 * The EndpointId points towards the outgoing trunk, 442 * The message carries the session description returned by the 443 ingress gateway, 445 * Because the session description is present, the "mode" 446 parameter is set to "send/receive". 448 We observe that the call identifier is identical for the two 449 connections. This is normal: the two connections belong to the 450 same call, which has a global identifier in our system. 452 The trunking gateway will acknowledge the connection command, 453 sending in the session description its own parameters such as 455 Internet draft MGCP Call Flows 20 January 1999 457 address, ports and RTP profile: 459 200 1205 OK 460 I:32F345E2 462 v=0 463 c=IN IP4 128.96.63.25 464 m=audio 1296 RTP/AVP 0 96 465 a=rtpmap:96 G726-32/8000 467 The Call Agent will relay the information to the ingress gate- 468 way, using a ModifyConnection command: 470 MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 471 C: A3C47F21456789F0 472 I:FDE234C8 473 M: recvonly 475 v=0 476 c=IN IP4 128.96.63.25 477 m=audio 1296 RTP/AVP 0 96 478 a=rtpmap:96 G726-32/8000 480 The residential gateway immediately acknowledges the modifica- 481 tion: 483 200 1206 OK 485 At this stage, the Call Agent has established a half duplex 486 transmission path. The phone attached to the residential gateway 487 will be able to receive the signals, such as tones or announce- 488 ments, that the remote switch may send through the trunking 489 gateway. 491 When the call progresses, the Call Agent will receive from the 492 remote switch progress messages, for example an "address com- 493 plete" message (ACM). The Call Agent will analyze the message to 494 determine whether signal are transmitted in band. If this is not 495 the case, the Call Agent will instruct the RGW to generate ring- 496 ing tones by sending a NotificationRequest: 498 RQNT 1207 endpoint/1@rgw-2567.whatever.net MGCP 0.1 499 X: 0123456789AE 500 R: hu 501 S: v 503 Internet draft MGCP Call Flows 20 January 1999 505 The gateway immediately acknowledges the command: 507 200 1207 OK 509 After the called user answers the call, the Call Agent will 510 receive an answering message (ANM) from the CO switch. At that 511 point, it will send a ModifyConnection command, to the residen- 512 tial gateway, to place the connection in full duplex mode. The 513 command embeds NotificationRequest to stop the ringing tones. 515 MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 516 C: A3C47F21456789F0 517 I:FDE234C8 518 M: sendrecv 519 X: 0123456789AF 520 R: hu 521 S: 523 The residential gateway will acknowledge this command: 525 200 1209 OK 527 At this point, the connection is established. 529 When the Call Agent receives the REL message from the CO switch, 530 it will have to tear down the call. It will do so by sending to 531 both gateways a DeleteConnection command: 533 DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 534 C: A3C47F21456789F0 535 I:FDE234C8 537 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 538 C: A3C47F21456789F0 539 I:32F345E2 541 The gateways will respond with acknowledgements that should 542 include a "call parameters" header fields: 544 250 1210 OK 545 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 547 250 1211 OK 548 P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48 550 Internet draft MGCP Call Flows 20 January 1999 552 At this point, the phone attached to the residential gateway, in 553 our scenario, goes on-hook. This event is notified to the Call 554 Agent, according to the policy received in the last Notifica- 555 tionRequest by sending a Notify command: 557 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 558 X: 0123456789AF 559 O: hu 561 After this notification, the Call Agent should send an ack- 562 nowledgement: 564 200 2005 OK 566 It should then issue a new NotificationRequest, to be ready to 567 receive the next off-hook detected by the residential gateway: 569 RQNT 1212 endpoint/1@rgw-2567.whatever.net MGCP 0.1 570 X: 0123456789B0 571 R: hd(E(dl;hu, [0-9#*T](D);) 572 D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 573 S: 575 The gateway will acknowledge this message: 577 200 1212 OK 579 Both gateways, at this point, are ready for the next call. 581 Internet draft MGCP Call Flows 20 January 1999 583 2.3. Basic call, TGW to RGW 585 ___________________________________________________________________ 586 | CO | SS7/| TGW | CA | CDB| ACC| RGW | Usr | 587 | | ISUP| | | | | | | 588 |____|______|__________|_______________|_____|_____|________|______| 589 | IAM| -> | | | | | | | 590 | | IAM | - - | -> | | | | | 591 | | | | Check | -> | | | | 592 | | | | <- | IP | | | | 593 | | | <- | Create | | | | | 594 | | | | Connection | | | | | 595 | | | Ack | -> | | | | | 596 | | | | Create | | | | | 597 | | | | Connection | - -| - -| -> | | 598 | | | | <- | - -| - -| Ack | | 599 | | | <- | Modify | | | | | 600 | | | | Connection | | | | | 601 | | | Ack | -> | | | | | 602 | | | | Notification | | | | | 603 | | | | Request | - -| - -| -> | ring| 604 | | | | <- | - -| - -| Ack | | 605 | | <- | - - | ACM | | | | | 606 | <- | ACM | | | | | | | 607 | | | | | | | | off | 608 | | | | | | | | hook| 609 | | | | <- | - -| - -| Notify| | 610 | | | | Ack | - -| - -| -> | | 611 | | | | Notification | | | | | 612 | | | | Request | - -| - -| -> | | 613 | | | | <- | - -| - -| Ack | | 614 | | | <- | Modify | | | | | 615 | | | | Connection | | | | | 616 | | | Ack | -> | | | | | 617 | | | (cut-in)| Call start | - -| -> | | | 618 | | <- | - - | ANM | | | | | 619 | <- | ANM | | | | | | | 620 |____|______|__________|_______________|_____|_____|________|______| 622 Internet draft MGCP Call Flows 20 January 1999 624 _____________________________________________________________ 625 | CO| SS7/| TGW | CA | CDB| ACC| RGW | Usr | 626 | | ISUP| | | | | | | 627 |___|______|______|______________|_____|_____|________|______| 628 | | | | | | | | on | 629 | | | | | | | | hook| 630 | | | | <- | - -| - -| Notify| | 631 | | | | Ack | - -| - -| -> | | 632 | | | | Delete | | | | | 633 | | | | Connection | - -| - -| -> | | 634 | | | <- | Delete | | | | | 635 | | | | Connection | | | | | 636 | | <- | - - | REL | | | | | 637 | <-| REL | | | | | | | 638 | | | Perf| | | | | | 639 | | | data| -> | | | | | 640 | | | | <- | - -| - -| perf | | 641 | | | | | | | data | | 642 | | | | Call end | - -| -> | | | 643 | | | | Notification| | | | | 644 | | | | Request | - -| - -| -> | | 645 | | | | <- | - -| - -| Ack | | 646 |___|______|______|______________|_____|_____|________|______| 648 This diagram shows the various exchange of messages during a 649 call from a telephone user on the circuit-switched PSTN to a 650 residential user connected to a residential gateway. During 651 these exchanges the Call Agent uses MGCP to control both the TGW 652 and the residential gateway. The exchanges occur on two sides. 654 Upon reception of the IAM message, the Call Agent immediately 655 sends a CreateConnection request to the trunking gateway to con- 656 nect to the incoming trunk, creating a connection: 658 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 659 C: A3C47F21456789F0 660 L: p:10, a:G.711;G.726-32 661 M: recvonly 663 The trunking gateway immediately acknowledges the creation, 664 sending back the identification of the newly created connection 665 and the session description used to receive audio data: 667 200 1237 OK 669 Internet draft MGCP Call Flows 20 January 1999 671 I: FDE234C8 673 v=0 674 c=IN IP4 128.96.41.1 675 m=audio 3456 RTP/AVP 0 96 676 a=rtpmap:96 G726-32/8000 678 The SDP announcement, in our example, specifies the address at 679 which the gateway is ready to receive audio data (128.96.41.1), 680 the transport protocol (RTP), the RTP port (3456) and the audio 681 profile (AVP). The audio profile refers to RFC 1890, which 682 defines that the payload type 0 has been assigned for G.711 683 transmission. The gateway is also ready to use ADPCM encoding at 684 32 kbps (G.726 -4). There is no standard payload type associated 685 to ADPCM, so the gateway mentions its readiness to use a non 686 standard payload associated to the dynamic type 96. The "rtpmap" 687 attribute entry associates the payload type 96 to G726/4. 689 The Call Agent, having seized the incoming trunk, must now 690 reserve the outgoing circuit. It does so by sending a connection 691 command to the residential gateway: 693 CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 694 C: A3C47F21456789F0 695 L: p:10, a:G.711;G.726-32 696 M: sendrecv 698 v=0 699 c=IN IP4 128.96.41.1 700 m=audio 3456 RTP/AVP 0 96 701 a=rtpmap:96 G726-32/8000 703 The CreateConnection command has the same parameters as the com- 704 mand sent to the ingress gateway, with two differences: 706 * The EndpointId points towards the outgoing trunk, 708 * The message carries the session description returned by the 709 ingress gateway, 711 * Because the session description is present, the "mode" 712 parameter is set to "send/receive". 714 We observe that the call identifier is identical for the two 715 connections. This is normal: the two connection belong to the 717 Internet draft MGCP Call Flows 20 January 1999 719 same call, which has a global identifier in our system. 721 The residential gateway will acknowledge the connection command, 722 sending in the session description its own parameters such as 723 address, ports and RTP profile: 725 200 1238 OK 726 I:32F345E2 728 v=0 729 c=IN IP4 128.96.63.25 730 m=audio 1296 RTP/AVP 0 96 731 a=rtpmap:96 G726-32/8000 733 The Call Agent will relay the information to the ingress gate- 734 way, using a ModifyConnection command: 736 MDCX 1239 card23/21@trgw-7.whatever.net MGCP 0.1 737 C: A3C47F21456789F0 738 I:FDE234C8 739 M: recvonly 741 v=0 742 c=IN IP4 128.96.63.25 743 m=audio 1296 RTP/AVP 0 96 744 a=rtpmap:96 G726-32/8000 746 The trunking gateway immediately acknowledges the modification: 748 200 1239 OK 750 At this stage, the Call Agent has established a half-duplex 751 transmission path. The Call Agent must now tells the residential 752 gateway to ring the called line. It will send a NotificationRe- 753 quest, consisting of the following lines: 755 RQNT 1240 endpoint/1@rgw-2567.whatever.net MGCP 0.1 756 X: 0123456789B1 757 R: hd 758 S: rg 760 The residential gateway, at that point, is instructed to look 761 for an off-hook event, and to report it. It will first 763 Internet draft MGCP Call Flows 20 January 1999 765 acknowledge the command, repeating in the acknowledgement mes- 766 sage the transaction id that the Call Agent attached to the 767 query. 769 200 1240 OK 771 Upon reception of this message, the Call Agent sends an address 772 complete message (ACM) to the calling switch, which we assume 773 will generate ringing tones for the calling user. 775 When the gateway notices the off hook event, it sends a Notify 776 command to the Call Agent: 778 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 779 X: 0123456789B0 780 O: hd 782 The Call Agent immediately acknowledges that notification. 784 200 2001 OK 786 The Call Agent now asks the residential gateway to send a Notify 787 command on the occurrence of an on-hook event. It does so by 788 sending a NotificationRequest to the residential gateway: 790 RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1 791 X: 0123456789B1 792 R: hu 794 The gateway acknowledges that command: 796 200 1241 OK 798 In parallel, the Call Agent will send a ModifyConnection command 799 to the trunking gateway, to place the connection in full duplex 800 mode: 802 MDCX 1242 card23/21@trgw-7.whatever.net MGCP 0.1 803 C: A3C47F21456789F0 804 I:FDE234C8 805 M: sendrecv 807 Internet draft MGCP Call Flows 20 January 1999 809 The trunking gateway will acknowledge that command: 811 200 1242 OK 813 The Call Agent can now send an answer message (ANM) to the cal- 814 ling switch. 816 After some time, the Call Agent will have to tear down the call. 817 In our example, this is triggered by the residential user, who 818 hangs up. The Notify command is sent to the Call Agent: 820 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 821 X: 0123456789B1 822 O: hu 824 The Call Agent acknowledges the notification. 826 200 2005 OK 828 It will then send to both gateways a DeleteConnection command: 830 DLCX 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 831 C: A3C47F21456789F0 832 I:32F345E2 834 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 835 C: A3C47F21456789F0 836 I:FDE234C8 838 The gateways will respond with a message that should include a 839 "call parameters" header fields: 841 250 1243 OK 842 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 844 250 1244 OK 845 P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48 847 The Call Agent should now issue a new NotificationRequest to the 848 residential gateway to detect the next off-hook event: 850 Internet draft MGCP Call Flows 20 January 1999 852 RQNT 1245 endpoint/1@rgw-2567.whatever.net MGCP 0.1 853 X: 0123456789B2 854 R: hd 856 The residential gateway will acknowledge this command: 858 200 1245 OK 860 Both gateways, at this point, are ready for the next call. 862 Internet draft MGCP Call Flows 20 January 1999 864 2.4. Basic call from an R2 trunk in a TGW to an SS7 trunk in a 865 TGW 867 ________________________________________________________________ 868 | CO | R2 | CA | TGW | SS7/| CO | 869 | | TGW | | | ISUP| | 870 |________|___________|_______________|___________|_______|______| 871 | | <- | NTRQ | | | | 872 | | Ack | -> | | | | 873 | Trunk | | | | | | 874 | seizure| | | | | | 875 | & | | | | | | 876 | Called | | | | | | 877 | &callng| | | | | | 878 | number | | | | | | 879 | digit | | | | | | 880 | collec-| | | | | | 881 | tion | -> | | | | | 882 | | Notify | -> | | | | 883 | | <- | Ack | | | | 884 | | <- | Notification| | | | 885 | | | Request | | | | 886 | | Ack | -> | | | | 887 | | <- | Create | | | | 888 | | | Connection | | | | 889 | | Ack | -> | | | | 890 | | | Create | | | | 891 | | | Connection | -> | | | 892 | | | | (cut in)| | | 893 | | | <- | ack | | | 894 | | | IAM | - - | -> | | 895 | | <- | Modify | | IAM | -> | 896 | | | Connection | | | | 897 | | Ack | -> | | <- | ACM| 898 | | | <- | - - | ACM | | 899 | | | | | <- | ANM| 900 | | | <- | - - | ANM | | 901 | | <- | Modify | | | | 902 | | | Connection | | | | 903 | | Ack | -> | | | | 904 | | (cut in)| | | | | 905 |________|___________|_______________|___________|_______|______| 907 Internet draft MGCP Call Flows 20 January 1999 909 _____________________________________________________________ 910 | CO | R2 | CA | TGW | SS7/| CO | 911 | | TGW | | | ISUP| | 912 |_________|__________|_______________|________|_______|______| 913 | | | | | <- | REL| 914 | | | <- | - - | REL | | 915 | | | Delete | | | | 916 | | <- | Connection | | | | 917 | | Clear- | | | | | 918 | <- | back | Delete | | | | 919 | Clear- | | Connection | -> | | | 920 | fwd | -> | | | | | 921 | | Rel- | | | | | 922 | <- | guard | | | | | 923 | | Perf | | | | | 924 | | Data | -> | | | | 925 | | | <- | Perf | | | 926 | | | | data | | | 927 | | <- | Notification| | | | 928 | | | Request | | | | 929 | | Ack | -> | | | | 930 |_________|__________|_______________|________|_______|______| 932 The above diagram describes the call flow between a trunk with 933 R2 signaling in a trunking gateway and an SS7 trunk in a trunk- 934 ing gateway. R2 is a type of Channel Associated Signaling (CAS) 935 and this call flow assumes the use of an R2 package. The follow- 936 ing diagram describes a simplified R2 package. In this package 937 digit arrival events are not observed by the Call Agent and 938 therefore cannot be part of a NotificationRequest. The first 939 event that the Call Agent can observe in an R2 trunk is a 940 "call-in" event which is a combination of the arrival at the 941 gateway of a trunk seizure signal and collection of the called 942 (destination) and calling (source) and calling party numbers 943 from the R2 registers. The notification for a call-in event 944 occurs when digit collection is completed. The clear forward 945 event indicates that the exchange at the other side released the 946 trunk. 948 ______________________________________________________________ 949 Symbol Definition R S Duration 950 ______________________________________________________________ 951 ci Call in x 952 cf Clear forward x 953 dn Destination number 954 sn Source number 955 ______________________________________________________________ 957 Internet draft MGCP Call Flows 20 January 1999 959 | | | | | 961 The first command is a NotificationRequest, sent by the Call 962 Agent to the R2 trunking gateway. The request will consist of 963 the following lines: 965 RQNT 1201 trunk-group-1/*@r2tgw-2567.whatever.net MGCP 0.1 966 N: ca@ca1.whatever.net:5678 967 X: 0123456789AB 968 R: ci 970 The gateway, at that point, is instructed to look for a call-in 971 event in any of the trunks corresponding to a trunk group named 972 trunk-group-1. The gateway responds with the acknowledgement 973 message: 975 200 1201 OK 977 When the call-in event is detected, the gateway sends a Notify 978 to the Call Agent: 980 NTFY 2001 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 981 N: ca@ca1.whatever.net:5678 982 X: 0123456789AB 983 O: ci, dn(5313456789), sn(5845430978) 985 This notification indicates the occurrence of a call-in event in 986 trunk #5 in trunk-group-1. It also contains the collected desti- 987 nation (dn) and source (sn) party numbers. The Call Agent 988 immediately acknowledges that notification. 990 200 2001 OK 992 At this stage, the Call Agent sends a NotificationRequest to 993 wait for a trunk release signal: RQNT 1203 trunk-group- 994 1/5@r2tgw-2567.whatever.net MGCP 0.1 X: 0123456789AD R: cf The 995 Call Agent immediately acknowledges that command. 997 200 1203 OK 999 The Call Agent will then seize the incoming circuit, creating a 1000 connec- tion: 1002 CRCX 1204 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 1003 C: A3C47F21456789F0 1004 L: p:10, a:G.711;G.726-32 1005 M: recvonly 1007 Internet draft MGCP Call Flows 20 January 1999 1009 The gateway immediately acknowledges the creation, sending back 1010 the identification of the newly created connection and the ses- 1011 sion description used to receive audio data: 1013 200 1204 OK 1014 I:FDE234C8 1016 v=0 1017 c=IN IP4 128.96.41.1 1018 m=audio 3456 RTP/AVP 0 96 1019 a=rtpmap:96 G726-32/8000 1021 The Call Agent, having seized the incoming trunk and completed a 1022 routing look up to identify the outgoing gateway, seizes the 1023 outgoing trunk. It does so by sending a connection command to 1024 the egress gate- way: 1026 CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 1027 C: A3C47F21456789F0 1028 L: p:10, a:G.711;G.726-32 1029 M: sendrecv 1031 v=0 1032 c=IN IP4 128.96.41.1 1033 m=audio 3456 RTP/AVP 0 96 1034 a=rtpmap:96 G726-32/8000 1036 The SS7 trunking gateway acknowledges the connection command, 1037 sending in the session description its own parameters such as 1038 address, ports and RTP profile: 1040 200 1205 OK 1041 I:32F345E2 1043 v=0 1044 c=IN IP4 128.96.63.25 1045 m=audio 1297 RTP/AVP 0 96 1046 a=rtpmap:96 G726-32/8000 1048 The Call Agent relays the information to the ingress gateway, 1049 using a ModifyConnection command: 1051 MDCX 1206 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 1052 C: A3C47F21456789F0 1053 I:FDE234C8 1054 M: recvonly 1056 Internet draft MGCP Call Flows 20 January 1999 1058 v=0 1059 c=IN IP4 128.96.63.25 1060 m=audio 1297 RTP/AVP 0 96 1061 a=rtpmap:96 G726-32/8000 1063 The R2 trunking gateway immediately acknowledges the modifica- 1064 tion: 1066 200 1206 OK 1068 At this stage, the Call Agent has established a half duplex 1069 transmission path. The subscriber that originated the call will 1070 be able to receive signals, such as tones or announcements, that 1071 the remote switch may send through the trunking gateways. 1073 After the called user answers the call, the Call Agent will 1074 receive an answering message (ANM) from the CO switch. At that 1075 point, it sends a ModifyConnection command, to place the connec- 1076 tion in full-duplex mode: 1078 MDCX 1209 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 1079 C: A3C47F21456789F0 1080 I:FDE234C8 1081 M: sendrecv 1083 The R2 trunking gateway acknowledges the modify command: 1085 200 1209 OK 1087 At this point, the connection is established. 1089 When the Call Agent receives the REL message from the CO switch, 1090 it will have to tear down the call. It will do so by sending to 1091 both gateways a DeleteConnection command: 1093 DLCX 1094 1210 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 1095 C: A3C47F21456789F0 1096 I:FDE234C8 1098 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 1099 C: A3C47F21456789F0 1100 I:32F345E2 1102 The gateways will respond with acknowledgements that should 1103 include a "call parameters" header fields: 1105 250 1210 OK 1107 Internet draft MGCP Call Flows 20 January 1999 1109 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, 1110 LA=48 1112 250 1211 OK 1113 P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, 1114 LA=48 1116 Finally, the Call Agent issues a new NotificationRequest, to be 1117 ready to receive the next call-in event detected by the trunking 1118 gateway at the specified trunk: 1120 RQNT 1212 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 1121 X: 0123456789B0 1122 R: hd 1124 The gateway will acknowledge this message: 1126 200 1212 OK 1128 Both gateways, at this point, are ready for the next call. 1130 Internet draft MGCP Call Flows 20 January 1999 1132 2.5. Basic call, from an ISDN gateway to an SS7/TGW 1134 _________________________________________________________________________ 1135 | PBX | Business | CA | TGW | SS7/| CO | 1136 | | GW | | | ISUP| | 1137 |_______|____________|___________________|___________|_______|___________| 1138 | SETUP | -> | -> | | | | 1139 | <- | <- | CALLPROC. | | | | 1140 | | <- | CRCX | | | | 1141 | | Ack | -> | | | | 1142 | | | CRCX | -> | | | 1143 | | | | (cut in)| | | 1144 | | | <- | ack | | | 1145 | | | IAM | -> | | | 1146 | | <- | MDCX | | IAM | -> | 1147 | | Ack | -> | | <- | ACM | 1148 | | | <- | - - | ACM | | 1149 | <- | <- | ALERT | | | | 1150 | | <- | RQNT | | | | 1151 | | Ack | -> | | | | 1152 | <- | Ringing | | | | | 1153 | | | | | <- | ANM | 1154 | | | <- | - - | ANM | | 1155 | | <- | RQNT+MDCX | | | | 1156 | | Ack | -> | | | | 1157 | | | | | <- | REL | 1158 | | | <- | - - | REL | | 1159 | | <- | DLCX | | | | 1160 | | | DLCX | -> | | | 1161 | | Perf | | | | | 1162 | | Data | -> | | | | 1163 | | | <- | Perf | | | 1164 | | | | data | | | 1165 | | | RLC | - - | -> | -> | 1166 | <- | <- | RLSE | | | | 1167 | RLCOM | -> | -> | | | | 1168 |_______|____________|___________________|___________|_______|___________| 1170 The above diagram describes the call flow between a trunk with 1171 ISDN signaling in a business gateway and an SS7 trunk in a 1172 trunking gateway. 1174 This call flow assumes that the ISDN Q.931 signaling messages 1175 are "back-hauled" to the call agent. The tunnelling protocol, 1176 together with configuration tables, allows the call agent to 1177 associate the signalling messages to the endpoint corresponding 1179 Internet draft MGCP Call Flows 20 January 1999 1181 to the B-channel. The specifics of the tunnelling protocol are 1182 being worked on by the IETF. 1184 The call is triggered by the arrival of a SETUP command, which 1185 is relayed to the Call Agent. The call agent analyzes teh com- 1186 mand, to obtain the destination (dn) and source (sn) party 1187 numbers. The call agent sends a call progress message, which is 1188 tunneled to the gateay and relayed over the D-Channel. The Call 1189 Agent then seizes the incoming circuit, creating a connection: 1191 CRCX 1204 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 1192 C: A3C47F21456789F0 1193 L: p:10, a:G.711;G.726-32 1194 M: recvonly 1196 The gateway immediately acknowledges the creation, sending back 1197 the identification of the newly created connection and the ses- 1198 sion descrip- tion used to receive audio data: 1200 200 1204 OK I:FDE234C8 1202 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 1203 G726-32/8000 1205 The Call Agent, having seized the incoming trunk and completed a 1206 routing look up to identify the outgoing gateway, seizes the 1207 outgoing trunk. It does so by sending a connection command to 1208 the egress gate- way: 1210 CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 1211 C: A3C47F21456789F0 1212 L: p:10, a:G.711;G.726-32 1213 M: sendrecv 1215 v=0 1216 c=IN IP4 128.96.41.1 1217 m=audio 3456 RTP/AVP 0 96 1218 a=rtpmap:96 G726-32/8000 1220 The SS7 trunking gateway acknowledges the connection command, 1221 sending in the session description its own parameters such as 1222 address, ports and RTP profile: 1224 200 1205 OK 1225 I:32F345E2 1227 Internet draft MGCP Call Flows 20 January 1999 1229 v=0 1230 c=IN IP4 128.96.63.25 1231 m=audio 1297 RTP/AVP 0 96 1232 a=rtpmap:96 G726-32/8000 1234 The Call Agent relays the information to the ingress gateway, 1235 using a ModifyConnection command: 1237 MDCX 1206 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 1238 C: A3C47F21456789F0 1239 I:FDE234C8 1240 M: recvonly 1242 v=0 1243 c=IN IP4 128.96.63.25 1244 m=audio 1297 RTP/AVP 0 96 1245 a=rtpmap:96 G726-32/8000 1247 The business gateway immediately acknowledges the modification: 1249 200 1206 OK 1251 At this stage, the Call Agent has established a half duplex 1252 transmission path. The subscriber that originated the call will 1253 be able to receive signals, such as tones or announcements, that 1254 the remote switch may send through the trunking gateways. 1256 When the call progresses, the Call Agent will receive from the 1257 remote switch progress messages, for example an "address com- 1258 plete" message (ACM). The Call Agent will tunnel an ALERT mes- 1259 sage to the originating PBX. It may, if needed, send a notifi- 1260 cation request command to the gateway, to generate alerting 1261 tones over the B-channel: 1263 RQNT 1207 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 1264 X: 0123456789AE 1265 S: rt 1267 The gateway immediately acknowledges the command: 1269 200 1207 OK 1271 After the called user answers the call, the Call Agent will 1272 receive an answering message (ANM) from the CO switch. At that 1273 point, it will send a ModifyConnection command to the business 1274 gateway, to place the connection in full duplex mode, and an 1275 embedded NotificationRequest to stop the ringing tones: 1277 Internet draft MGCP Call Flows 20 January 1999 1279 MDCX 1209 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 1280 C: A3C47F21456789F0 1281 I: FDE234C8 1282 M: sendrecv 1283 X: 0123456789AF 1284 S: 1286 The business gateway will acknowledge the command: 1288 200 1209 OK 1290 At this point, the connection is established. 1292 When the Call Agent receives the REL message from the CO switch, 1293 it will have to tear down the call. It will do so by sending to 1294 both gateways a DeleteConnection command: 1296 DLCX 1210 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 1297 C: A3C47F21456789F0 1298 I:FDE234C8 1300 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 1301 C: A3C47F21456789F0 1302 I:32F345E2 1304 The gateways will respond with acknowledgements that should 1305 include a "call parameters" header fields: 1307 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, 1308 JI=27, LA=48 1310 250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, 1311 JI=27, LA=48 1313 Having freed the local resource, the call agent will confirm the 1314 release by sending a RLC message to the next switch, and will 1315 also send a release message through the Q.931 tunnel to the PBX. 1316 The PBX will send back a release confirmation. 1318 Both gateways, at this point, are ready for the next call. 1320 Internet draft MGCP Call Flows 20 January 1999 1322 2.6. Basic call with continuity test, TGW to RGW 1324 _______________________________________________________ 1325 | CO | SS7/| TGW| CA | CDB| ACC| RGW| Usr| 1326 | | ISUP| | | | | | | 1327 |____|______|_____|____________|_____|_____|_____|_____| 1328 | IAM| -> | | | | | | | 1329 | | IAM | - -| -> | | | | | 1330 | | | | Check | -> | | | | 1331 | | | | <- | IP | | | | 1332 | | | <- | Create | | | | | 1333 | | | | Connection| | | | | 1334 | | | Ack| -> | | | | | 1335 | COT| -> | | | | | | | 1336 | | COT | - -| -> | | | | | 1337 | | | <- | Modify | | | | | 1338 | | | | Connection| | | | | 1339 | | | | Create | | | | | 1340 | | | | Connection| - -| - -| -> | | 1341 | | | | <- | - -| - -| Ack| | 1342 |____|______|_____|____________|_____|_____|_____|_____| 1344 This diagram shows the various exchange of messages during the 1345 beginning of a call from a telephone user on the circuit- 1346 switched PSTN to a residential user connected to a residential 1347 gateway. During these exchanges the Call Agent uses MGCP to con- 1348 trol both the TGW and the residential gateway. The circuit 1349 switch decides to execute a continuity test during the call 1350 establishment. The exchanges occur on two sides. 1352 Upon reception of the IAM message, the Call Agent recognizes 1353 that a continuity test has been requested. It immediately sends 1354 a CreateConnection request to the trunking gateway to connect to 1355 the incoming trunk, creating a connection: 1357 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 1358 C: A3C47F21456789F0 1359 L: p:10, a:G.711;G.726-32 1360 M: conttest 1362 The trunking gateway recognizes that the mode is set to 1363 "conttest". It places the circuit in "continuity test" mode, 1364 ready to send back the 2010 Hz return tone if it receives a 1780 1365 Hz tone. The gateway acknowledges the creation of the connec- 1366 tion, sending back the identification of the newly created con- 1367 nection and the session description used to receive audio data: 1369 Internet draft MGCP Call Flows 20 January 1999 1371 200 1237 OK 1372 I: FDE234C8 1374 v=0 1375 c=IN IP4 128.96.41.1 1376 m=audio 3456 RTP/AVP 0 96 1377 a=rtpmap:96 G726-32/8000 1379 At this point, the call agent is waiting for the result of the 1380 continuity test. The calling switch is sending the test tone 1381 (1780 Hz); if it receives the return tone (2010 Hz), it will 1382 send a "continuity passed" message (COT). At this point, the 1383 call agent will send a modify connection message to the gateway, 1384 in order to place the connection in "recvonly" mode: 1386 MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1 1387 C: A3C47F21456789F0 1388 I: FDE234C8 1389 M: recvonly 1391 The gateway will immediately acknowledge that command: 1393 200 1238 OK 1395 The Call Agent will then proceed with the establishment of the 1396 call. 1398 Internet draft MGCP Call Flows 20 January 1999 1400 2.7. Hairpin connection, regular set-up 1402 The figure below gives the flow that results in an hairpin con- 1403 nection on the same gateway. In this flow, we assume that the 1404 exchange of messages is exactly comparable to what would happen 1405 in a call relayed between two trunking gateways, with the sole 1406 difference that the call will be relayed on a local connection. 1408 ________________________________________ 1409 | sw1| sw2| SG | CA | TGW-1| TGW-2| 1410 |____|_____|_____|______|_______|_______| 1411 | IAM| - -| -> | | | | 1412 | | | IAM| -> | | | 1413 | | | | CRCX| -> | | 1414 | | | | <-| ACK | | 1415 | | | | CRCX| - - | -> | 1416 | | | | <-| - - | ACK | 1417 | | | <-| IAM | | | 1418 | | <-| IAM| | | | 1419 | | ACM| -> | | | | 1420 | | | ACM| -> | | | 1421 | | | <-| ACM | | | 1422 | <-| - -| ACM| | | | 1423 | | ...| | | | | 1424 | | ANM| -> | | | | 1425 | | | ANM| -> | | | 1426 | | | | MDCX| -> | | 1427 | | | | <-| ACK | | 1428 | | | <-| ANM | | | 1429 | <-| - -| ANM| | | | 1430 | REL| - -| -> | | | | 1431 | | | REL| -> | | | 1432 | | | | DLCX| -> | | 1433 | | | | <-| ACK | | 1434 | | | <-| RLC | | | 1435 | <-| - -| RLC| | | | 1436 | | | | DLCX| -> | | 1437 | | | | <-| Perf | | 1438 | | | | | data | | 1439 | | | <-| REL | | | 1440 | | <-| REL| | | | 1441 | | RLC| -> | | | | 1442 | | | RLC| -> | | | 1443 |____|_____|_____|______|_______|_______| 1445 During these exchanges the MGCP is used by the Call Agent to 1446 control two endpoints located on the same TGW. 1448 Internet draft MGCP Call Flows 20 January 1999 1450 The exchanges start with the arrival from the first switch (SW1) 1451 of an SS7/ISUP "IAM" message, relayed by the signalling gateway 1452 to the Call Agent. The call agent performs the routing, and 1453 determines that the call will have to be relayed towards the 1454 second switch (SW2), using a trunk located on the same gateway. 1456 The call agent starts the exchange by seizing the endpoint 1457 referenced in the IAM message: 1459 CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 1460 C: A3C47F21456789F0 1461 L: nt=LOCAL 1462 M: recvonly 1464 Upon reception of that command, the trunking gateway prepares a 1465 "local" connection description. 1467 200 1204 OK 1468 I:FDE234C8 1470 v=0 1471 c=IN tgw.whatever.net trunk-group-1/17 1472 m=audio 0 LOCAL 0 1474 The call agent, upon reception of this acknowledgement, sends a 1475 connection request to the trunking gateway, asking the gateway 1476 to reserve a trunk in the group connected to the second switch: 1478 CRCX 1205 trunk-group-2/$@tgw.whatever.net MGCP 0.1 1479 C: A3C47F21456789F0 1480 L: nt=LOCAL 1481 M: sendrecv 1483 v=0 1484 c=IN tgw.whatever.net trunk-group-1/17 1485 m=audio 0 LOCAL 0 1487 The call agent selects a trunk in the group, and acknowledges 1488 the creation: 1490 200 1204 OK 1491 I:abc0 1493 v=0 1494 c=IN tgw.whatever.net trunk-group-2/13 1496 Internet draft MGCP Call Flows 20 January 1999 1498 m=audio 0 LOCAL 0 1500 The two commands have created a one way path, suitable for for- 1501 warding ring tones and announcements to the calling party. The 1502 call agent can now relay the call by sending an IAM message to 1503 the second switch. When the ACM is received, it is immediately 1504 relayed to the first switch. 1506 After some time, the call is answered, and an ANM message is 1507 relayed from the second switch to the call agent. The call agent 1508 will first validate the call by asking the first end-point to 1509 place the connection in duplex mode: 1511 MDCX 1206 trunk-group-1/17@tgw.whatever.net MGCP 0.1 1512 C: A3C47F21456789F0 1513 I:FDE234C8 1514 M: sendrecv 1516 v=0 1517 c=IN tgw.whatever.net trunk-group-2/13 1518 m=audio 0 LOCAL 0 1520 The trunking gateway executes and acknowledges the modification: 1522 200 1206 OK 1524 The call agent can now relay the ANM message to the cal- 1525 ling switch, and both parties can talk. 1527 At the end of the call, in our example, the calling 1528 party hangs up. The first switch sends a release mes- 1529 sage to the call agent, through the signalling gateway. 1530 The call agent releases the connection on the first end- 1531 point: 1533 DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 1534 C: A3C47F21456789F0 1535 I:FDE234C8 1537 The gateway acknowledges the deletion, sending the con- 1538 nection parameters: 1540 250 1217 OK 1541 P: OS=62345, OR=62345 1543 The call agent can now confirm the release of the trunk, 1545 Internet draft MGCP Call Flows 20 January 1999 1547 sending an RLC message to the first switch. 1549 In parallel, the call agent releases the connection to 1550 the second endpoint: 1552 DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1 1553 C: A3C47F21456789F0 1554 I:abc0 1556 The gateway acknowledges the deletion, sending the con- 1557 nection parameters: 1559 250 1218 OK 1560 P: OS=62345, OR=62345 1562 After receiving the acknowledgement, the call agent can 1563 relay the release message to the second switch. The 1564 switch will in turn acknowledge the release. 1566 Internet draft MGCP Call Flows 20 January 1999 1568 2.8. Hairpin connection, accelerated set-up 1570 The figure below gives the flow that results in an hair- 1571 pin connection on the same gateway. Contrary to the 1572 previous example, we will assume that the call agent 1573 uses a special-case software, and takes full benefit of 1574 the call's locality to accelerate the call set-up. 1576 _________________________________________________ 1577 | User1 | User2 | RGW | CA | 1578 |_________|___________|___________|______________| 1579 | | | <-- | RQNT | 1580 | | | ACK | --> | 1581 | OFF HOOK| --- | --> | | 1582 | <-- | --- | dialtone| | 1583 | digits | --- | NTFY | --> | 1584 | | | | | 1585 | | | <-- | ACK | 1586 | | | | | 1587 | | | <-- | CRCX+RQNT, | 1588 | | Ring | <-- | CRCX+RQNT | 1589 | | | ACK | --> | 1590 | | | ACK | --> | 1591 | | OFF HOOK | NTFY | --> | 1592 | | | <-- | ACK | 1593 | | | <-- | RQNT | 1594 | | | ACK | --> | 1595 | | | | | 1596 | on-hook | --- | NTFY | --> | 1597 | | | <-- | ACK | 1598 | | | <-- | DLCX+RQNT | 1599 | | | <-- | DLCX | 1600 | | | ACK | --> | 1601 | | | ACK | --> | 1602 | | on-hook | NTFY | --> | 1603 | | | <-- | ACK | 1604 | | | <-- | RQNT | 1605 | | | ACK | --> | 1606 |_________|___________|___________|______________| 1608 The first command is a NotificationRequest, sent by the 1609 Call Agent to the residential gateway. The request will 1610 consist of the following lines: 1612 RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1613 N: ca@ca1.whatever.net:5678 1614 X: 0123456789AC 1615 R: hd(E(dl;hu, D/[0-9#*T](D);) 1617 Internet draft MGCP Call Flows 20 January 1999 1619 D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 1621 The gateway immediately acknowledges the command, 1622 repeating in the acknowledgement message the transaction 1623 id that the Call Agent attached to the query. 1625 200 1201 OK 1627 When the off hook event is noticed, the gateway provides 1628 the dial tone to the line (the delay between off-hook 1629 and dialtone is thus minimal.) The gateway will then 1630 start accumulating digits according to that digit map. 1631 When it has noticed a sufficient set of values, it will 1632 notify the observed string to the Call Agent: 1634 NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1635 N: ca@ca1.whatever.net:5678 1636 X: 0123456789AC 1637 O: 912018294266 1639 The Call Agent immediately acknowledges that notifica- 1640 tion. 1642 200 2002 OK 1644 The call agent analyzes the called number and determines 1645 that this is an hairpin connection: the called party is 1646 located on the same gateway, on endpoint/2. The Cal- 1647 lAgent can prepare two simultaneous CreateConnection 1648 commands, creating the two legs of the connection. 1649 Because we are not too concerned at this stage with tax 1650 evasion, the The Call Agent will then seize the incoming 1651 circuit, creating a connection. The create connection 1652 sent to the first endpoint piggybacks a notification 1653 request, to stop collecting digits yet continue watch 1654 for an on-hook transition. The CreateConnection sent to 1655 the second endpoint piggybacks a request to generate 1656 ringing and look for off-hook. Both commands can be sent 1657 in a single UDP packet: 1659 CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1660 C: A3C47F21456789F0 1661 X: 0123456789AD 1662 M: sendrecv 1663 R: hu 1665 Internet draft MGCP Call Flows 20 January 1999 1667 S: 1669 v=0 1670 c=LOCAL rgw-2567.whatever.net endpoint/2 1671 m=audio 0 LOCAL 0 1672 . 1673 CRCX 1205 endpoint/2@rgw-2567.whatever.net MGCP 0.1 1674 C: A3C47F21456789F0 1675 X: 9875659876 1676 M: sendrecv 1677 R: hd 1678 S: rg 1680 v=0 1681 c=LOCAL rgw-2567.whatever.net endpoint/1 1682 m=audio 0 LOCAL 0 1684 We should note that the call agent does not send 1685 the local connection options since it knows that it 1686 is a local (a.k.a. "hairpin") connection: the con- 1687 nections are entirely described by the SDP text. 1689 The gateway immediately acknowledges the creations, 1690 sending back in two messages the identification of the 1691 newly created connections: 1693 200 1204 OK 1694 I:FDE234C8 1695 . 1696 200 1204 OK 1697 I:9867659A 1699 The residential gateway, at that point, is instructed to 1700 look for an off-hook event on the second endpoint, and 1701 to report it. When the gateway notices the off hook 1702 event, it sends a Notify command to the Call Agent: 1704 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1705 X: 9875659876 1706 O: hd 1708 The Call Agent immediately acknowledges that notifica- 1709 tion: 1711 200 2001 OK 1713 Internet draft MGCP Call Flows 20 January 1999 1715 The Call agent will now send a NotificationRequest com- 1716 mand to the gateway, asking to look for an off-hook 1717 event on the second end-point: 1719 RQNT 1206 endpoint/2@rgw-2567.whatever.net MGCP 0.1 1720 X: 987565989A 1721 R: hu 1722 S: 1724 The gateway acknowledges that command: 1726 200 1206 OK 1728 At this point the call is active between the two 1729 residential gateway users. 1731 When the first user goes off hook, it sends a notifica- 1732 tion to the call agent: 1734 NTFY 2010 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1735 X: 987565989A 1736 O: hu 1738 The call agent acknowledges the notification. It can, 1739 in a single UDP message, send the acknowledgement and 1740 the DeleteConnection commands that will clear the call. 1741 For the first gateway, the command embeds a notification 1742 request that readies that gateway for the next call: 1744 200 2010 OK 1745 . 1746 DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 1747 C: A3C47F21456789F0 1748 I: FDE234C8 1749 N: ca@ca1.whatever.net:5678 1750 X: 012345673FDE 1751 R: hd(E(dl;hu, D/[0-9#*T](D);) 1752 S: 1753 . 1754 DLCX 1211 endpoint/2@rgw-2567.whatever.net MGCP 0.1 1755 C: A3C47F21456789F0 1756 I: 9867659A 1757 X: A3C5F0 1758 R: hu 1759 S: 1761 The gateway will acknowledge the commands in a single 1762 UDP message that will carry the "local connection" 1764 Internet draft MGCP Call Flows 20 January 1999 1766 version of the connection parameters. 1768 250 1243 OK 1769 P: OS=62345, OR=62345 1770 . 1771 250 1244 OK 1772 P: OS=62345, OR=62345 1774 When the second user goes off hook, the gateway sends a 1775 Notify commands 1777 NTFY 2020 endpoint/2@rgw-2567.whatever.net MGCP 0.1 1778 X: A3C5F0 1779 O: hu 1781 The Call agent follows with a notification requests, 1782 transmitted in the same packet as the acknowledgement, 1783 in order to ready the line for the next call: 1785 200 2020 OK 1786 . 1787 RQNT 1220 enpoint/1@rgw-2567.whatever.net MGCP 0.1 1788 N: ca@ca1.whatever.net:5678 1789 X: 0123456793E5 1790 R: hd(E(dl;hu, D/[0-9#*T](D);) 1791 S: 1793 The gateway acknowledges the command, signalling that 1794 the second endpoint is now ready. 1796 200 1220 OK 1798 Internet draft MGCP Call Flows 20 January 1999 1800 2.9. Hairpin connection, double end-point model 1802 The figure below gives the flow that results in an hair- 1803 pin connection on the same gateway. In this flow, we 1804 assume that we use the "double endpoint" extensions to 1805 the create-connection command. 1807 ________________________________________ 1808 | sw1| sw2| SG | CA | TGW-1| TGW-2| 1809 |____|_____|_____|______|_______|_______| 1810 | IAM| - -| -> | | | | 1811 | | | IAM| -> | | | 1812 | | | | CRCX| -> | (->) | 1813 | | | | <-| ACK | (ACK)| 1814 | | | <-| IAM | | | 1815 | | <-| IAM| | | | 1816 | | ACM| -> | | | | 1817 | | | ACM| -> | | | 1818 | | | <-| ACM | | | 1819 | <-| - -| ACM| | | | 1820 | | ...| | | | | 1821 | | ANM| -> | | | | 1822 | | | ANM| -> | | | 1823 | | | <-| ANM | | | 1824 | <-| - -| ANM| | | | 1825 | REL| - -| -> | | | | 1826 | | | REL| -> | | | 1827 | | | | DLCX| -> | | 1828 | | | | <-| Perf | | 1829 | | | | | data | | 1830 | | | <-| RLC | | | 1831 | <-| - -| RLC| | | | 1832 | | | | DLCX| -> | | 1833 | | | | <-| Perf | | 1834 | | | | | data | | 1835 | | | <-| REL | | | 1836 | | <-| REL| | | | 1837 | | RLC| -> | | | | 1838 | | | RLC| -> | | | 1839 |____|_____|_____|______|_______|_______| 1841 During these exchanges the MGCP is used by the Call 1842 Agent to control two endpoints located on the same TGW. 1844 The exchanges start with the arrival from the first 1845 switch (SW1) of an SS7/ISUP "IAM" message, relayed by 1846 the signalling gateway to the Call Agent. The call 1848 Internet draft MGCP Call Flows 20 January 1999 1850 agent performs the routing, and determines that the call 1851 will have to be relayed towards the second switch (SW2), 1852 using a trunk located on the same gateway. 1854 The call agent starts the exchange by seizing the end- 1855 point referenced in the IAM message: 1857 CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 1858 C: A3C47F21456789F0 1859 L: nt=LOCAL 1860 M: sendrecv 1861 E2: trunk-group-2/$ 1863 Upon reception of that command, the trunking gateway 1864 prepares a "local" connection description between the 1865 specified endpoint (trunk-group-1/17) and an endpoint 1866 that it selects within the secund trunk group (trunk- 1867 group-2/13). The gateway acknowledges the two creations 1868 in a single message: 1870 200 1204 OK 1871 I:FDE234C8 1872 Z2:trunk-group-2/13@tgw.whatever.net 1873 I2:abc0 1875 The command has created a path, between the two end- 1876 points. The call agent can now relay the call by sending 1877 an IAM message to the second switch. When the ACM is 1878 received, it is immediately relayed to the first switch. 1880 After some time, the call is answered, and an ANM mes- 1881 sage is relayed from the second switch to the call 1882 agent. The call agent immediately relays the ANM mes- 1883 sage to the calling switch, and both parties can talk. 1885 At the end of the call, in our example, the calling 1886 party hangs up. The first switch sends a release mes- 1887 sage to the call agent, through the signalling gateway. 1888 The call agent releases the connection on the first end- 1889 point: 1891 DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 1892 C: A3C47F21456789F0 1893 I:FDE234C8 1895 The gateway acknowledges the deletion, sending the 1897 Internet draft MGCP Call Flows 20 January 1999 1899 connection parameters: 1901 250 1217 OK 1902 P: OS=62345, OR=62345 1904 The call agent can now confirm the release of the trunk, 1905 sending an RLC message to the first switch. 1907 In parallel, the call agent releases the connection to 1908 the second endpoint: 1910 DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1 1911 C: A3C47F21456789F0 1912 I:abc0 1914 The gateway acknowledges the deletion, sending the con- 1915 nection parameters: 1917 250 1218 OK 1918 P: OS=62345, OR=62345 1920 After receiving the acknowledgement, the call agent can 1921 relay the release message to the second switch. The 1922 switch will in turn acknowledge the release. 1924 Internet draft MGCP Call Flows 20 January 1999 1926 3. Interaction between an MGCP gateway and an H.323 1927 entity 1929 MGCP is not intended to replace H.323, or even to com- 1930 pete with it. In fact, we should mostly consider it as a 1931 tool to enable distributed implementations of H.323. The 1932 combination of gateways and call agent behaves as a dis- 1933 tributed H.323 system, using MGCP for internal communi- 1934 cation. This system appears to H.323 users as a larger 1935 H.323 system, or, if one prefers, as an H.323 gatekeeper 1936 that implements the Gatekeeper routed call model. 1938 In order to demonstrate the compatibility between MGCP 1939 and H.323, we provide here a step by step demonstration 1940 of 2 call set up scenarios: 1942 * Call from an MGCP controlled residential gateway to 1943 an H.323 entity, 1945 * Call from an H.323 entity to an MGCP controlled 1946 residential gateway. 1948 We suppose, in these scenarios, that the H.323 entity is 1949 capable of using the fast start procedure defined in 1950 H.323v2. 1952 Internet draft MGCP Call Flows 20 January 1999 1954 3.1. Call from a residential gateway (RGW) to an H.323 1955 user 1957 _____________________________________________________________________ 1958 | Usr | RGW | CA | H.323 | Usr | GK | 1959 |____________|___________|______________|___________|__________|_____| 1960 | | <- | RQNT | | | | 1961 | | Ack | -> | | | | 1962 | | | | | | | 1963 | Off-hook | Notify | -> | | | | 1964 | <- | Ack | | | | | 1965 | (Dial-tone)| <- | RQNT | | | | 1966 | | Ack | -> | | | | 1967 | | | | | | | 1968 | Digits | Notify | -> | | | | 1969 | <- | Ack | | | | | 1970 | (progress) | <- | CRCX+RQNT | | | | 1971 | | Ack | -> | | | | 1972 | | | (processing)| | | | 1973 | | | TCP-SYN | -> | | | 1974 | | | <- | SYN, ACK | | | 1975 | | | Set-up+ | | | | 1976 | | | faststart | -> | | | 1977 | | | | ARQ | - - - | -> | 1978 | | | | <- | - - - | ACF| 1979 | | | <- | alerting | ring | | 1980 | | | TCP ACK | -> | | | 1981 | (ring back)| <- | RQNT | | | | 1982 | | Ack | -> | | | | 1983 | | | <- | connect +| off hook| | 1984 | | | | faststart| | | 1985 | | | TCP ACK | -> | | | 1986 | | <- | MDCX+RQNT | | | | 1987 | | Ack | -> | | | | 1988 | | | (call est.) | | | | 1989 | on hook | Notify | -> | | | | 1990 | <- | Ack | | | | | 1991 | <- | DLCX+RQNT| | | | | 1992 | perf data | -> | | | | | 1993 | | | Rel. C. | -> | | | 1994 | | | TCP-FIN | -> | | | 1995 | | | <- | FIN, ACK | | | 1996 | | | TCP ACK | -> | | | 1997 | | | | (signal) | On-hook | | 1998 | | | | DRQ | - - - | -> | 1999 | | | | <- | - - - | DCF| 2000 |____________|___________|______________|___________|__________|_____| 2002 Internet draft MGCP Call Flows 20 January 1999 2004 During these exchanges the MGCP is used by the call 2005 agent to control the residential gateways. The call will 2006 be routed to an H.323 entity. The first command is a 2007 notification request, sent by the call agent to the 2008 residential gateway. The request will consist of the 2009 following lines: 2011 RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2012 N: ca@ca1.whatever.net:5678 2013 X: 0123456789AB 2014 R: hd 2016 The gateway, at that point, is instructed to look for an 2017 off-hook event, and to report it. It will first ack- 2018 nowledge the request, repeating in the acknowledgement 2019 message the transaction id that the call agent attached 2020 to the query. 2022 200 1201 OK 2024 Note that this command is not actually simultaneous with 2025 the call. It can be issued long before the actual call, 2026 for example when the gateway is turned on, or after the 2027 end of a previous call. 2029 When the off hook event is noticed, the gateway sends a 2030 Notify command to the call agent: 2032 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2033 N: ca@ca1.whatever.net:5678 2034 X: 0123456789AB 2035 O: hd 2037 The call agent immediately acknowledges that notifica- 2038 tion. 2040 200 2001 OK 2042 The call agent examines the services associated to an 2043 off hook action (it could take special actions in the 2044 case of a direct line). In most cases, it will send a 2045 notification request, asking for digits. The current 2046 example provides the gateway with a digit map, and 2047 requests the gateway to play a dialtone: 2049 Internet draft MGCP Call Flows 20 January 1999 2051 RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2052 N: ca@ca1.whatever.net:5678 2053 X: 0123456789AC 2054 R: hu, [0-9#*T](D) 2055 D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx | 9011x.T) 2056 S: dl 2058 The gateway immediately acknowledges that request. 2060 200 1202 OK 2062 The gateway will start accumulating digits according to 2063 that digit map. When it has noticed a sufficient set of 2064 values, it will notify the observed string to the call 2065 agent: 2067 NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2068 N: ca@ca1.whatever.net:5678 2069 X: 0123456789AC 2070 O: 912018294266 2072 The call agent immediately acknowledges that notifica- 2073 tion. 2075 200 2002 OK 2077 At this stage, the call agent seizes the incoming cir- 2078 cuit, creating a connection. It will also send together 2079 with that creation request a notification request, to 2080 stop collecting digits yet continue watch for an on-hook 2081 transition: 2083 CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2084 C: A3C47F21456789F0 2085 L: p:10, a:G.711;G.726-32 2086 M: recvonly 2087 X: 0123456789AD 2088 R: hu 2090 The gateway immediately acknowledges the creation, send- 2091 ing back the identification of the newly created connec- 2092 tion and the session description used to receive audio 2094 Internet draft MGCP Call Flows 20 January 1999 2096 data: 2098 200 1204 OK 2099 I: FDE234C8 2101 v=0 2102 c=IN IP4 128.96.41.1 2103 m=audio 3456 RTP/AVP 0 2105 The SDP announcement, in our example, specifies the 2106 address at which the gateway is ready to receive audio 2107 data (128.96.41.1), the transport protocol (RTP), the 2108 RTP port (3456) and the audio profile (AVP). The audio 2109 profile refers to RFC 1890, which defines that the pay- 2110 load type 0 has been assigned for G.711 transmission. 2112 The call agent, having seized the incoming trunk, 2113 proceeds with call routing. Using local databases, it 2114 determines that the dialed digits (912018294266) 2115 correspond to a H.323 entity. It will set up a TCP-IP 2116 connection and send an H.225/Q.931 "set-up" message to 2117 the H.323 entity. In this message, the "faststart" ele- 2118 ment carries a set of open logical channel proposals, 2119 derived from the SDP description received from the cal- 2120 ling gateway: 2122 Internet draft MGCP Call Flows 20 January 1999 2124 faststart-1 OpenLogicalChannel ::= { 2125 forwardLogicalChannelNumber 1, 2126 forwardLogicalChannelParameters { 2127 dataType g711Ulaw64k 160, -- 20 ms G.711 frame 2128 multiplexParameters 2129 h2250LogicalChannelParameters H2250LogicalChannelParameters { 2130 sessionID 1, 2131 silenceSuppression FALSE 2132 } 2133 } 2134 } 2136 faststart-2 OpenLogicalChannel ::= { 2137 forwardLogicalChannelNumber 2, 2138 forwardLogicalChannelParameters { 2139 dataType nullData, -- pro forma 2140 multiplexParameters none 2141 }, 2142 reverseLogicalChannelParameters { 2143 dataType g711Ulaw64k 160, -- 20 ms frame 2144 multiplexParameters 2145 h2250LogicalChannelParameters H2250LogicalChannelParameters { 2146 sessionID 2, 2147 mediaChannel unicastAddress iPAddress { 2148 network '80602901'H, -- 128.96.41.1 2149 tsapIdentifier 3456 -- port 2150 }, 2151 mediaControlChannel unicastAddress iPAddress { 2152 network '80602901'H, -- 128.96.41.1 2153 tsapIdentifier 3457 -- port 2154 }, 2155 silenceSuppression FALSE 2156 } 2157 } 2158 } 2160 The H.323 alerts the user, and sends an H.225/Q.931 2161 "alerting" message. On reception of this message, the 2162 call agent will send a notification request that 2163 instruct the RGW to generate alerting tones: 2165 RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2166 X: 0123456789AE 2167 R: hu 2168 S: v 2170 Internet draft MGCP Call Flows 20 January 1999 2172 When the called user accepts the call, the H.323 entity 2173 sends an H.225/Q.931 2175 set-up 2176 message to the call agent. If the H.323 entity accepted 2177 the fast start procedure, the faststart 2178 parameter will contain the confirmation of the open 2179 logical channel creations in the two directions of com- 2180 munication: 2182 faststart-1 OpenLogicalChannel ::= { 2183 forwardLogicalChannelNumber 1, 2184 forwardLogicalChannelParameters { 2185 dataType g711Ulaw64k 160, -- 20 ms frame 2186 multiplexParameters h2250LogicalChannelParameters { 2187 sessionID 1, 2188 mediaChannel unicastAddress iPAddress { 2189 network '80603F19'H, 2190 tsapIdentifier 3456, -- port 2191 } , 2192 mediaControlChannel unicastAddress iPAddress { 2193 network '80603F19'H, 2194 tsapIdentifier 3457, -- port 2195 } , 2196 silenceSuppression FALSE 2197 } 2198 } 2199 } 2200 faststart-2 OpenLogicalChannel ::= { 2201 forwardLogicalChannelNumber 2, 2202 forwardLogicalChannelParameters { 2203 dataType g711Ulaw64k 160, -- 20 ms frame 2204 multiplexParameters h2250LogicalChannelParameters { 2205 sessionID 2, 2206 silenceSuppression FALSE 2207 } 2208 } 2209 } 2211 The call agent will send a modification request to the 2212 residential gateway, in order to establish a full duplex 2213 connection. The SDP payload, in that request, is derived 2214 from the parameters of the logical channel for transmis- 2215 sion from the gateway to the H.323 entity. 2217 Internet draft MGCP Call Flows 20 January 1999 2219 MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2220 C: A3C47F21456789F0 2221 I: FDE234C8 2222 M: sendrecv 2223 X: 0123456789AF 2224 R: hu 2226 v=0 2227 c=IN IP4 128.96.63.25 2228 m=audio 1296 RTP/AVP 0 2230 The gateway will acknowledge this request: 2232 200 1209 OK 2234 At this point, the connection is established. 2236 In our example, the call is terminated when the calling 2237 party hangs up. This triggers a Notify command to the 2238 call agent: 2240 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2241 X: 0123456789AF 2242 O: hu 2244 After this notification, the call agent should send an 2245 acknowledgement: 2247 200 2005 OK 2249 The call agent will then clear the call, by sending a 2250 delete connection request to the calling gateway. This 2251 request is combined with a notification request, to be 2252 ready to detect the next call issued by the residential 2253 gateway: 2255 DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2256 C: A3C47F21456789F0 2257 I: FDE234C8 2258 X: 0123456789B0 2259 R: hd 2261 Internet draft MGCP Call Flows 20 January 1999 2263 The gateway will respond with a message that should 2264 include a "call parameters" header field: 2266 250 1210 OK 2267 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 2269 The call agent will in parallel sends an H.225/Q.931 2270 "release complete" message to the H.323 entity. It will 2271 then tear down the TCP-IP connection. The gateway, at 2272 this point, is ready for the next call. The H.323 user 2273 will be ready as soon as the H.323 entity notices that 2274 the phone is back on hook. 2276 Internet draft MGCP Call Flows 20 January 1999 2278 3.2. Basic call, H.323 to RGW 2280 ___________________________________________________________________ 2281 | User | H.323 | GK | CA | RGW | Usr | 2282 |_______|____________|_______|______________|___________|__________| 2283 | call | -> | | | | | 2284 | | ARQ | -> | | | | 2285 | | <- | ACF | | | | 2286 | | TCP SYN | - - -| -> | | | 2287 | | <- | - - -| SYN+ACK | | | 2288 | | set-up+ | | | | | 2289 | | fast start| - - -| -> | | | 2290 | | | | (call | | | 2291 | | | | processing) | | | 2292 | | | | CRCX+RQNT | -> | ring | 2293 | | | | <- | Ack | | 2294 | | <- | - - -| alerting | | | 2295 | | TCP ACK | - - -| -> | | | 2296 | | (ringing) | | | | | 2297 | | | | <- | Notify | off hook| 2298 | | | | Ack | -> | | 2299 | | | | RQNT | -> | | 2300 | | | | <- | Ack | | 2301 | | <- | - - -| connect + | | | 2302 | | | | fast start | | | 2303 | | TCP ACK | - - -| -> | | | 2304 | | | | (call | | | 2305 | | | | established)| | | 2306 | | | | | | | 2307 | | | | <- | Notify | on hook | 2308 | | | | Ack | -> | | 2309 | | | | (no | | | 2310 | | | | suspension) | | | 2311 | | | | RQNT | -> | | 2312 | | | | <- | Ack | | 2313 | hangup| detected | | | | | 2314 | | Rel. C. | | | | | 2315 | | TCP FIN | - - -| -> | | | 2316 | | <- | - - -| FIN ACK | | | 2317 | | | | DLCX+RQNT | -> | | 2318 | | | | <- | perf data| | 2319 | | DRQ | -> | | | | 2320 | | <- | DCF | | | | 2321 |_______|____________|_______|______________|___________|__________| 2323 This diagram shows the various exchange of messages dur- 2324 ing a call from an H.323 user to a residential user. 2326 Internet draft MGCP Call Flows 20 January 1999 2328 During these exchanges the MGCP is used by the call 2329 agent to control the residential gateway. 2331 When the user initiates the call, the H.323 entity will 2332 perform a RAS transaction with its designated Gate- 2333 keeper. As a result of this transaction, it will learn 2334 the TCP-IP address of the call agent, and will set up a 2335 TCP-IP connection with the call agent. Once the TCP-IP 2336 connection is established, the H.323 entity sends a 2337 Q.931/H.225 connect message to the call agent. The mes- 2338 sage, in its user-to-user parameter, includes a "fast 2339 start" parameter that lists a set of OpenLogicalChannel 2340 proposals, such as for example: 2342 faststart-1 OpenLogicalChannel ::= { 2343 forwardLogicalChannelNumber 1, 2344 forwardLogicalChannelParameters { 2345 dataType g711Ulaw64k 160, -- 20 ms G.711 frame 2346 multiplexParameters h2250LogicalChannelParameters { 2347 sessionID 1, 2348 silenceSuppression FALSE 2349 } 2350 } 2351 } 2352 faststart-2 OpenLogicalChannel ::= { 2353 forwardLogicalChannelNumber 2, 2354 forwardLogicalChannelParameters { 2355 dataType nullData, -- pro forma 2356 multiplexParameters none 2357 }, 2358 reverseLogicalChannelParameters { 2359 dataType g711Ulaw64k 160, -- 20 ms frame 2360 multiplexParameters h2250LogicalChannelParameters { 2361 sessionID 2, 2362 mediaChannel unicastAddress iPAddress { 2363 network '80602901'H, -- 128.96.41.1 2364 tsapIdentifier 3456, -- port 2365 }, 2366 mediaControlChannel unicastAddress iPAddress { 2367 network '80602901'H, -- 128.96.41.1 2368 tsapIdentifier 3457, -- port 2369 }, 2370 silenceSuppression FALSE 2371 } 2372 } 2373 } 2375 Internet draft MGCP Call Flows 20 January 1999 2377 Upon reception of the set-up message, the call agent 2378 will perform called routing functions and determine the 2379 end point that correspond to the called party number. It 2380 will reserve the outgoing circuit. It does so and at the 2381 same time it requests ringing, by sending to the 2382 residential gateway a create connection request combined 2383 with a notification request: 2385 CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2386 C: A3C47F21456789F0 2387 L: p:10, a:G.711 2388 M: sendrecv 2389 X: 0123456789B1 2390 R: hd 2391 S: rg 2393 v=0 2394 c=IN IP4 128.96.41.1 2395 m=audio 3456 RTP/AVP 0 2397 In this command, the SDP announcement is obtained by 2398 translating the "faststart" parameters corresponding to 2399 the receive channel announced by the caller - channel 2 2400 in our case. The IP address, RTP port and authorized 2401 payload are derived from the "reverseLogicalChannel- 2402 Parameters" data elements. We derive the authorized 2403 payload type from the "dataType" element. We have how- 2404 ever to check that this value is proposed in at least 2405 one of the forward channels. 2407 The gateway will acknowledge the connection request, 2408 sending in the session description its own parameters 2409 such as address, ports and RTP profile: 2411 200 1238 OK 2412 I: 32F345E2 2414 v=0 2415 c=IN IP4 128.96.63.25 2416 m=audio 1296 RTP/AVP 0 2418 The phone is ringing, and the gateway, is instructed to 2419 look for an off-hook event, and to report it. The call 2420 agent sends an alerting message to the calling switch, 2421 which we assume will generate ringing tones for the cal- 2422 ling user. 2424 Internet draft MGCP Call Flows 20 January 1999 2426 When the off hook event is noticed, the gateway sends a 2427 Notify command to the call agent: 2429 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B0 2430 O: hd 2432 The call agent immediately acknowledges that notifica- 2433 tion. 2435 200 2001 OK 2437 The call agent must now ask the residential gateway to 2438 notify the occurrence of an on-hook event. It does so by 2439 sending a notification request to the residential gate- 2440 way: 2442 RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B1 2443 R: hu 2445 The gateway acknowledges that request: 2447 200 1241 OK 2449 In parallel, the call agent will send a "connect" mes- 2450 sage to the H.323 agent. The message includes the "fast 2451 start" parameter, which will validate and complement the 2452 proposals that the caller sent: 2454 Internet draft MGCP Call Flows 20 January 1999 2456 faststart-1 OpenLogicalChannel ::= { 2457 forwardLogicalChannelNumber 1, 2458 forwardLogicalChannelParameters { 2459 dataType g711Ulaw64k 160, -- 20 ms frame 2460 multiplexParameters h2250LogicalChannelParameters { 2461 sessionID 1, 2462 mediaChannel unicastAddress iPAddress { 2463 network '80603F19'H, 2464 tsapIdentifier 3456, -- port 2465 } , 2466 mediaControlChannel unicastAddress iPAddress { 2467 network '80603F19'H, 2468 tsapIdentifier 3457, -- port 2469 } , 2470 silenceSuppression FALSE 2471 } 2472 } 2473 } 2474 faststart-2 OpenLogicalChannel ::= { 2475 forwardLogicalChannelNumber 2, 2476 forwardLogicalChannelParameters { 2477 dataType g711Ulaw64k 160, -- 20 ms frame 2478 multiplexParameters h2250LogicalChannelParameters ( 2479 sessionID 1, 2480 silenceSuppression FALSE 2481 } 2482 } 2483 } 2485 After some time, in our example, the residential user 2486 hangs up. The notify request is sent to the call agent: 2488 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2489 X: 0123456789B1 2490 O: hu 2492 The call agent acknowledges the notification. 2494 200 2005 OK 2496 Upon reception of that notification, the call agent 2497 should send a "suspend" message to the calling H.323 2498 entity, but the Q.931 suspend message should not be sent 2499 in H.225. In order to preserve the user experience, the 2501 Internet draft MGCP Call Flows 20 January 1999 2503 call agent will simply initiate a timer, after which it 2504 would actually release the call. (In North-America, the 2505 call is not actually terminated if the called party 2506 hangs up. If it hangs down in a short interval, the call 2507 will be resumed.) The call agent, in any case, sends a 2508 notification request to the gateway, to look for an 2509 off-hook event. 2511 RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2512 X: 0123456789B2 2513 R: hd 2515 The gateway will acknowledge this request: 2517 200 1243 OK 2519 In our example, the calling user releases the call 2520 immediately. The H.323 agent sends a "release complete" 2521 message to the call agent, which will then send a delete 2522 connection request to the residential gateway. The 2523 request sent to the gateway is combined with a request 2524 to detect a off-hook event, which will be used to detect 2525 rare conditions where the user would have gone off hook 2526 simultaneously with the release on the other side: 2528 DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2529 C: A3C47F21456789F0 2530 X: 0123456789B3 2531 R: hd 2532 I: FDE234C8 2534 The gateway will respond with a message that should 2535 include a "call parameters" header fields: 2537 200 1244 OK 2538 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 2540 The gateway, at this point, is ready for the next call. 2542 Internet draft MGCP Call Flows 20 January 1999 2544 4. Interworking between SIP and MGCP 2546 The use of SDP in both MGCP and SIP makes interworking 2547 between these protocols very easy. In order to demon- 2548 strate this interworking, we provide here a step by step 2549 demonstration of 2 call set-up scenarios: 2551 * Call from an MGCP controlled residential gateway to 2552 a SIP agent, 2554 * Call from a SIP agent to an MGCP controlled 2555 residential gateway. 2557 Internet draft MGCP Call Flows 20 January 1999 2559 4.1. Call from a residential gateway (RGW) to a SIP 2560 user 2562 ___________________________________________________________________ 2563 | Usr | RGW | CA | SIP | Usr | 2564 |____________|___________|______________|________________|_________| 2565 | | <- | RQNT | | | 2566 | | Ack | -> | | | 2567 | | | | | | 2568 | Off-hook | Notify | -> | | | 2569 | | <- | | | | 2570 | Ack | | | | | 2571 | (Dial-tone)| <- | RQNT | | | 2572 | | Ack | -> | | | 2573 | | | | | | 2574 | Digit | Notify | -> | | | 2575 | | <- | Ack | | | 2576 | (progress) | <- | | | | 2577 | CRCX+RQNT | | | | | 2578 | | Ack | -> | | | 2579 | | | (processing)| | | 2580 | | | INVITE | -> | | 2581 | ring | | | | | 2582 | | | <- | resp. 180 | | 2583 | | | | (ringing) | | 2584 | (ringing) | <- | RQNT | | | 2585 | | Ack | -> | | | 2586 | | | | | | 2587 | | | <- | resp. 200 (OK)| | 2588 | off hook | | | | | 2589 | | | Ack | -> | | 2590 | | <- | MDCX+RQNT | | | 2591 | | Ack | -> | | | 2592 | | | (call | | | 2593 | | | established)| | | 2594 | on hook | Notify | -> | | | 2595 | | <- | Ack | | | 2596 | | <- | DLCX+RQNT | | | 2597 | | perf data| -> | | | 2598 | | | BYE | -> | | 2599 | | | <- | resp. 200 (OK)| | 2600 | | | | (local) | On-hook| 2601 |____________|___________|______________|________________|_________| 2603 During these exchanges the MGCP is used by the call 2604 agent to control the residential gateways. The call will 2605 be routed to a SIP agent. The first command is a 2607 Internet draft MGCP Call Flows 20 January 1999 2609 notification request, sent by the call agent to the 2610 residential gateway. The request will consist of the 2611 following lines: 2613 RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2614 N: ca@ca1.whatever.net:5678 2615 X: 0123456789AB 2616 R: hd 2618 The gateway, at that point, is instructed to look for an 2619 off-hook event, and to report it. It will first ack- 2620 nowledge the request, repeating in the acknowledgement 2621 message the transaction id that the call agent attached 2622 to the query. 2624 200 1201 OK 2626 Note that this command is not actually simultaneous 2627 with the call. It can be issued long before the 2628 actual call, for example when the gateway is turned 2629 on, or after the end of a previous call. 2631 When the off hook event is noticed, the gateway ini- 2632 tiates a notification request to the call agent: 2634 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2635 N: ca@ca1.whatever.net:5678 2636 X: 0123456789AB 2637 O: hd 2639 The call agent immediately acknowledges that notifica- 2640 tion. 2642 200 2001 OK 2644 The call agent examines the services associated to an 2645 off hook action (it could take special actions in the 2646 case of a direct line). In most cases, it will send a 2647 notification request, asking for digits. It will also 2648 provide the gateway with a digit map, and requests the 2649 gateway to play a dialtone: 2651 Internet draft MGCP Call Flows 20 January 1999 2653 RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2654 N: ca@ca1.whatever.net:5678 2655 X: 0123456789AC 2656 R: hu, D/[0-9#*T](D) 2657 D: (0T | 1xxxxxxxxxx | [2-9]xxxxxx | [4789]11 | 011x.T) 2658 S: dl 2660 The gateway immediately acknowledges that request. 2662 200 1202 OK 2664 The gateway will start accumulating digits according to 2665 that digit map. When it has noticed a sufficient set of 2666 values, it will notify the observed string to the call 2667 agent: 2669 NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2670 N: ca@ca1.whatever.net:5678 2671 X: 0123456789AC 2672 O: 912018294266 2674 The call agent immediately acknowledges that notifica- 2675 tion. 2677 200 2002 OK 2679 At this stage, the call agent seizes the incoming cir- 2680 cuit, creating a connection. It will also send together 2681 with that creation request a notification request, to 2682 stop collecting digits yet continue watch for an on-hook 2683 transition: 2685 CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2686 C: A3C47F21456789F0 2687 L: p:10, a:G.711;G.726-32 2688 M: recvonly 2689 X: 0123456789AD 2690 R: hu 2692 The gateway immediately acknowledges the creation, send- 2693 ing back the identification of the newly created connec- 2694 tion and the session description used to receive audio 2696 Internet draft MGCP Call Flows 20 January 1999 2698 data: 2700 200 1204 OK 2701 I:FDE234C8 2703 v=0 2704 c=IN IP4 128.96.41.1 2705 m=audio 3456 RTP/AVP 0 96 2706 a=rtpmap:96 G726-32/8000 2708 The SDP announcement, in our example, specifies the 2709 address at which the gateway is ready to receive audio 2710 data (128.96.41.1), the transport protocol (RTP), the 2711 RTP port (3456) and the audio profile (AVP). The audio 2712 profile refers to RFC 1890, which defines that the pay- 2713 load type 0 has been assigned for G.711 transmission. 2714 The gateway is also ready to use ADPCM encoding at 32 2715 kbps (G.726 -4). There is no standard payload type asso- 2716 ciated to ADPCM, so the gateway mentions its readiness 2717 to use a non standard payload associated to the dynamic 2718 type 96. The "rtpmap" attribute entry associates the 2719 payload type 96 to G726-32/4. 2721 The call agent, having seized the incoming trunk, 2722 proceeds with call routing. Using local databases, it 2723 determines that the dialed digits (912018294266) 2724 correspond to a SIP agent. It will send an invitation 2725 to that agent: 2727 INVITE sip:huitema@sip-station.bellcore.com SIP/2.0 2728 Via: SIP/2.0/UDP 128.96.41.12 2729 From: sip:123456789@ca.whatever.net 2730 To: Christian Huitema 2731 Call-ID: A3C47F21456789F0@ca.whatever.net 2732 Cseq: 1 INVITE 2733 Content-type: application/sdp 2734 Content-Length: ... 2736 v=0 2737 c=IN IP4 128.96.41.1 2738 m=audio 3456 RTP/AVP 0 96 2739 a=rtpmap:96 G726-32/8000 2741 The SDP attachment, in the INVITE message, is directly 2742 copied from the acknowledgement of the Create Connection 2743 request. The SIP agent alerts the user, and sends an 2745 Internet draft MGCP Call Flows 20 January 1999 2747 immediate acknowledgement: 2749 SIP/2.0 180 Ringing 2750 Via: SIP/2.0/UDP 128.96.41.12 2751 From: Christian Huitema 2752 To: 123456789@ca.whatever.net 2753 Call-ID: A3C47F21456789F0@ca.whatever.net 2754 Cseq: 1 INVITE 2756 The call agent will send a notification request that 2757 instruct the RGW to generate alerting tones: 2759 RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2760 X: 0123456789AE 2761 R: hu 2762 S: v 2764 When the called user accepts the call, the SIP agent 2765 sends an acceptation message to the call agent: 2767 SIP/2.0 200 OK 2768 Via: SIP/2.0/UDP 128.96.41.12 2769 From: "Christian Huitema" 2770 To: sip:123456789@ca.whatever.net 2771 Call-ID: A3C47F21456789F0@ca.whatever.net 2772 CSeq: 1 INVITE 2773 Content-type: application/sdp 2774 Content-Length:... 2776 v=0 2777 c=IN IP4 128.96.63.25 2778 m=audio 1296 RTP/AVP 0 96 2779 a=rtpmap:96 G726-32/8000 2781 The gateway immediately acknowledges the call set up: 2783 ACK huitema@sip-station.bellcore.com SIP/2.0 2784 Via: SIP/2.0/UDP 128.96.41.12 2785 From: 123456789@ca.whatever.net 2786 To: huitema@sip-station.bellcore.com (Christian Huitema) 2787 Call-ID: 187602141351@ca.whatever.net 2789 Then, the call agent will send a modification request to 2790 the residential gateway, in order to establish a full 2792 Internet draft MGCP Call Flows 20 January 1999 2794 duplex connection. The SDP payload, in that request, is 2795 copied from the SIP agent's response: 2797 MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2798 C: A3C47F21456789F0 2799 I:FDE234C8 2800 M: sendrecv 2801 X: 0123456789AF 2802 R: hu 2804 v=0 2805 c=IN IP4 128.96.63.25 2806 m=audio 1296 RTP/AVP 0 96 2807 a=rtpmap:96 G726-32/8000 2808 + 2810 The gateway will acknowledge this request: 2812 200 1209 OK 2814 At this point, the connection is established. In our 2815 example, the call is terminated when the calling party 2816 hangs up. This triggers a Notify command to the call 2817 agent: 2819 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2820 X: 0123456789AF 2821 O: hu 2823 After this notification, the call agent should send an 2824 acknowledgement: 2826 200 2005 OK 2828 The call agent will then clear the call, by sending a 2829 delete connection request to the calling gateway. This 2830 request is combined with a notification request, to be 2831 ready to detect the next call issued by the residential 2832 gateway: 2834 Internet draft MGCP Call Flows 20 January 1999 2836 DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2837 C: A3C47F21456789F0 2839 I:FDE234C8 2840 X: 0123456789B0 2841 R: hd 2843 The gateway will respond with a message that should 2844 include a "call parameters" header field: 2846 250 1210 OK 2847 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 2849 The call agent will in parallel sends a BYE request to 2850 the SIP agent: 2852 BYE sip:huitema@sip-station.bellcore.com SIP/2.0 2853 Via: SIP/2.0/UDP 128.96.41.12 2854 From: sip:123456789@ca.whatever.net 2855 To: "Christian Huitema" 2856 Call-ID: A3C47F21456789F0@ca.whatever.net 2857 CSeq: 2 BYE 2859 The SIP agent will acknowledge that request: 2861 SIP/2.0 200 OK 2862 Via: SIP/2.0/UDP 128.96.41.12 2863 From: "Christian Huitema" 2864 To: sip:123456789@ca.whatever.net 2865 Call-ID: A3C47F21456789F0@ca.whatever.net 2866 CSeq: 2 BYE SIP/2.0 200 OK 2868 The gateway, at this point, is ready for the next call. 2869 The SIP user will be ready as soon as the SIP agent 2870 notices that the phone is back on hook. 2872 Internet draft MGCP Call Flows 20 January 1999 2874 4.2. Basic call, SIP to RGW 2876 _______________________________________________________________ 2877 | User | SIP agent| CA | RGW | Usr | 2878 |_______|___________|___________________|___________|__________| 2879 | call | -> | | | | 2880 | | INVITE | -> | | | 2881 | | | (call processing)| | | 2882 | | | CRCX+RQNT | -> | | 2883 | ring | | | | | 2884 | | | <- | | | 2885 | Ack | | | | | 2886 | | <- | resp. 180 | | | 2887 | | (ringing)| (ringing) | | | 2888 | | | <- | Notify | off hook| 2889 | | | Ack | -> | | 2890 | | | RQNT | -> | | 2891 | | | <- | Ack | | 2892 | | <- | resp. 200 (OK) | | | 2893 | | ACK | -> | | | 2894 | | | (call | | | 2895 | | | established) | | | 2896 | | | | | | 2897 | | | <- | Notify | on hook | 2898 | | | Ack | -> | | 2899 | | | (no susp. | | | 2900 | | | message) | | | 2901 | | | RQNT | -> | | 2902 | | | <- | Ack | | 2903 | | | | | | 2904 | hangup| detected | | | | 2905 | | BYE | -> | | | 2906 | | | DLCX+RQNT | -> | | 2907 | | | <- | perf data| | 2908 |_______|___________|___________________|___________|__________| 2910 This diagram shows the various exchange of messages dur- 2911 ing a call from a 2912 SIP user to a residential user. During these exchanges 2913 the MGCP is used by the call agent to control the 2914 residential gateway. 2916 When the user initiates the call, the SIP agent will 2917 send an invitation to the call agent. (Our diagram 2918 assumes that the SIP agent sends that invitation 2919 directly; in fact, there could be several relays.) An 2920 example of invitation could be: 2922 Internet draft MGCP Call Flows 20 January 1999 2924 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 2925 Via: SIP/2.0/UDP 169.130.12.5 2926 From: "A. Bell" 2927 To: "T. A. Watson" 2928 Call-ID: 187602141351@worcester.bell-telephone.com 2929 CSeq: 1 INVITE 2930 Subject: Mr. Watson, come here. 2931 Content-type: application/sdp 2932 Content-Length: ... 2934 v=0 2935 o=bell 53655765 2353687637 IN IP4 128.3.4.5 2936 c=IN IP4 135.180.144.94 2937 m=audio 3456 RTP/AVP 0 3 4 5 2939 Upon reception of the set-up message, the call agent 2940 will perform call routing functions and determine the 2941 end point that corresponds to the invited user. It will 2942 then reserve the outgoing circuit. It does so at the 2943 same time that it requests ringing, by sending to the 2944 residential gateway a connection request combined with a 2945 notification request: 2947 CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2948 C: A3C47F21456789F0 2949 L: p:10, a:G.711 2950 M: sendrecv 2951 X: 0123456789B1 2952 R: hd 2953 S: rg 2955 v=0 2956 o=bell 53655765 2353687637 IN IP4 128.3.4.5 2957 c=IN IP4 135.180.144.94 2958 m=audio 3456 RTP/AVP 0 3 4 5 2960 In this command, the SDP announcement is directly copied 2961 from the invitation. The gateway will acknowledge the 2962 connection request, sending in the session description 2963 its own parameters such as address, ports and RTP pro- 2964 file: 2966 Internet draft MGCP Call Flows 20 January 1999 2968 200 1238 OK 2969 I:32F345E2 2971 v=0 2972 c=IN IP4 128.96.63.25 2973 m=audio 1296 RTP/AVP 0 3 2975 The phone is ringing, and the gateway, is instructed to 2976 look for an off-hook event, and to report it. The call 2977 agent sends an alerting message to the calling SIP 2978 agent, which will generate ringing tones for the calling 2979 user: 2981 SIP/2.0 180 Ringing 2982 Via: SIP/2.0/UDP 169.130.12.5 2983 From: "A. Bell" 2984 To: sip:watson@bell-telephone.com 2985 Call-ID: 187602141351@worcester.bell-telephone.com 2986 CSeq: 1 INVITE 2988 When the off hook event is noticed, the gateway ini- 2989 tiates a notification request to the call agent: 2991 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 2992 X: 0123456789B0 2993 O: hd 2995 The call agent immediately acknowledges that notifica- 2996 tion. 2998 200 2001 OK 3000 The call agent must now ask the residential gateway to 3001 notify the occurrence of an on-hook event. It does so 3002 by sending a notification request to the residential 3003 gateway: 3005 RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1 3006 X: 0123456789B1 3007 R: hu 3009 Internet draft MGCP Call Flows 20 January 1999 3011 The gateway acknowledges that request: 3013 200 1241 OK 3015 In parallel, the call agent will send a final answer to 3016 the SIP agent. The message, in its payload, copies the 3017 SDP announcement that was sent by the gateway: 3019 SIP/2.0 200 OK 3020 From: "A. Bell" 3021 To: sip:watson@bell-telephone.com 3022 Call-ID: 187602141351@worcester.bell-telephone.com 3023 CSeq: 1 INVITE 3024 Contact: sip://watson@boston.bell-telephone.com 3025 Content-Length: ... 3027 v=0 3028 c=IN IP4 128.96.63.25 3029 m=audio 1296 RTP/AVP 0 3 3031 The SIP agent acknowledges the set-up: 3033 ACK sip:watson@boston.bell-telephone.com SIP/2.0 3034 Via: SIP/2.0/UDP 169.130.12.5 3035 From: "A. Bell" 3036 To: "T. A. Watson" 3037 Call-ID: 187602141351@worcester.bell-telephone.com 3038 CSeq: 1 ACK 3040 At this point, the call is established. After some 3041 time, in our example, the residential user hangs up. The 3042 notify request is sent to the call agent: 3044 NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 3045 X: 0123456789B1 3046 O: hu 3048 The call agent acknowledges the notification. 3050 200 2005 OK 3052 Upon reception of that notification, the call agent 3053 should send a "suspend" message to the calling SIP 3055 Internet draft MGCP Call Flows 20 January 1999 3057 agent, but there is no such message in SIP. In order to 3058 preserve the user experience, the call agent will simply 3059 initiate a timer, after which it would actually release 3060 the call. (In North-America, the call is not actually 3061 terminated if the called party hangs up. If it hangs 3062 down in a short interval, the call will be resumed.) The 3063 call agent, in any case, sends a notification request to 3064 the gateway, to look for an off-hook event. 3066 RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 3067 X: 0123456789B2 3068 R: hd 3070 The gateway will acknowledge this request: 3072 200 1243 OK 3074 In our example, the calling user releases the call 3075 immediately. The SIP agent sends a BYE message to the 3076 call agent: 3078 BYE sip:watson@boston.bell-telephone.com SIP/2.0 3079 Via: SIP/2.0/UDP 169.130.12.5 3080 From: "A. Bell" 3081 To: "T. A. Watson" 3082 Call-ID: 187602141351@worcester.bell-telephone.com 3083 CSeq: 2 BYE 3085 The call agent acknowledges that message: 3087 SIP/2.0 200 OK 3088 From: "A. Bell" 3089 To: sip:watson@bell-telephone.com 3090 Call-ID: 187602141351@worcester.bell-telephone.com 3091 CSeq: 2 BYE 3093 The call agent then sends a delete connection request to 3094 the residential gateway. The request sent to the gateway 3095 is combined with a request to detect a off-hook event, 3096 which will be used to detect rare conditions where the 3097 user would have gone off hook simultaneously with the 3098 release on the other side: 3100 Internet draft MGCP Call Flows 20 January 1999 3102 DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1 3103 C: A3C47F21456789F0 3104 X: 0123456789B3 3105 R: hd 3106 I:FDE234C8 3108 The gateway will respond with a message that should 3109 include a "call parameters" header fields: 3111 200 1244 OK 3112 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 3114 The gateway, at this point, is ready for the next call. 3116 Internet draft MGCP Call Flows 20 January 1999 3118 5. Data calls 3120 We present here a set of call flows corresponding to 3121 data calls: 3123 * Basic data call, 3125 * Outgoing data call through a NAS, 3127 * Call back, using a NAS, 3129 * Data call to a NAS, using L2TP, 3131 * Basic data call with continuity test. 3133 Internet draft MGCP Call Flows 20 January 1999 3135 5.1. Basic data call to a NAS 3137 _______________________________________________________________________ 3138 | PC | CO | SS7/| NAS | CA | ACC| Radius| 3139 | | | ISUP| | | | | 3140 |___________|_____|______|_____________|________________|_____|________| 3141 | dials in | | | | | | | 3142 | | IAM| -> | | | | | 3143 | | | IAM | - - | -> | | | 3144 | | | | | Check called | | | 3145 | | | | | number. | | | 3146 | | | | | Notices | | | 3147 | | | | | data call. | | | 3148 | | | | | Call start | -> | | 3149 | | | | <- | Create | | | 3150 | | | | | Connection | | | 3151 | | | | | (data) | | | 3152 | | | | Ack | -> | | | 3153 | | | | | Connection | | | 3154 | | | | | is completed. | | | 3155 | | | | | Call | | | 3156 | | | | | established | -> | | 3157 | | | <- | - - | ANM | | | 3158 | | <- | ANM | | | | | 3159 | modem | - -| - - | -> | | | | 3160 | <- | - -| - - | handshake | | | | 3161 | PPP | - -| - - | -> | | | | 3162 | | | | obtain | | | | 3163 | | | | user-id, | | | | 3164 | | | | password | | | | 3165 | | | | Check | - - | - -| -> | 3166 | | | | <- | - - | - -| Ack | 3167 | <- | - -| - - | Validates | | | | 3168 | | | | call, | | | | 3169 | <- | - -| - - | procures | | | | 3170 | | | | IP | | | | 3171 | | | | address | | | | 3172 | Connected | | | | | | | 3173 | to | | | | | | | 3174 | the | | | | | | | 3175 | Internet | | | | | | | 3176 |___________|_____|______|_____________|________________|_____|________| 3178 Internet draft MGCP Call Flows 20 January 1999 3180 ______________________________________________________________ 3181 | PC | CO | SS7/| NAS | CA | ACC| Radius| 3182 | | | ISUP| | | | | 3183 |____________|_____|______|_______|____________|_____|________| 3184 | Closes | | | | | | | 3185 | connection.| | | | | | | 3186 | | REL| -> | | | | | 3187 | | | REL | - - | -> | | | 3188 | | | | <- | Delete | | | 3189 | | | | | Connection| | | 3190 | | | | Perf | | | | 3191 | | | | data | -> | | | 3192 | | | <- | - - | RLC | | | 3193 | | <- | RLC | | | | | 3194 | | | | | Call end | -> | | 3195 |____________|_____|______|_______|____________|_____|________| 3197 This diagram shows the exchange of messages during a 3198 call from a modem user to an Internet Service Provider, 3199 using a trunking gateway that doubles as a Network 3200 Access Server. During these exchanges the MGCP is used 3201 by the Call Agent to control both the trunking gateway. 3202 Since there is no "other end" of the call, only the 3203 trunk gateway is involved in the call. 3205 Upon reception of the IAM message, the Call Agent deter- 3206 mines that the call is a data call (e.g., by bearer 3207 capability, the called number, etc.). Using configura- 3208 tion databases, the Call Agent selects the type of modem 3209 parameters and authentication parameters that correspond 3210 to the called number and to the calling number. It uses 3211 this knowledge to send a CreateConnection command to the 3212 NAS, programming the incoming trunk: 3214 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 3215 C: A3C47F21456789F0 3216 M: data 3217 X: 0123456789B1 3218 R: cl, ax 3220 v=0 3221 m=nas/radius 3222 c=IN IP4 radius.example.net 3223 a=bearer:v.32 3224 a=framing:ppp-asynch 3225 a=dialed:18001234567 3226 a=dialing:2345678901 3228 Internet draft MGCP Call Flows 20 January 1999 3230 The trunking gateway checks that it has adequate 3231 resources for the call. If the trunking gateway did not 3232 have adequate resources, for example if it could not 3233 support the requested modem type, it should refuse the 3234 creation and send an error response to the Call Agent. 3235 If the gateway has sufficient resources, it immediately 3236 acknowledges the creation, sending back the identifica- 3237 tion of the newly created connection. (There is no need 3238 to transmit a session description in the case of a data 3239 call.) 3241 200 1237 OK 3242 I: FDE234C8 3244 The Call Agent, knowing that this is a data call, can 3245 immediately acknowledge the establishment of the connec- 3246 tion, sending an ANM message back to the calling switch. 3248 The trunk gateway connects the incoming trunk to a DSP 3249 loaded with the specified modem code. Once the call is 3250 established, the modem of the calling PC will start a 3251 training sequence with the modem associated to the trunk 3252 in the trunk gateway. The caller will then proceed to a 3253 normal PPP synchronization, which probably implies a PPP 3254 login. The authentication parameters, in our example, 3255 are checked using Radius. The Radius server that will be 3256 used is typically chosen as a function of the called 3257 number, which identifies the data service that the cal- 3258 ling modem requested. In fact, the number can also be 3259 used to identify the specific form of authentication 3260 that is requested (but not usually). 3262 In our example, the call is completed when the calling 3263 modem hangs up. This triggers an ISUP release message, 3264 which is forwarded to the Call Agent. The Call Agent 3265 will request the NAS to delete the connection: 3267 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 3268 C: A3C47F21456789F0 3269 I: FDE234C8 3271 The gateways will respond with a message that should 3272 include a "call parameters" header fields: 3274 250 1244 OK 3275 P: PS=1245, OS=62345, PR=780, OR=45123 3277 Internet draft MGCP Call Flows 20 January 1999 3279 We should note that, because this is a data call, the 3280 call parameters only include a count of the packets and 3281 octets that were sent and received. 3283 Internet draft MGCP Call Flows 20 January 1999 3285 5.2. Outgoing data call through a NAS 3287 _____________________________________________________________________ 3288 | PC | CO | SS7/| NAS | CA | ACC| Router | 3289 | | | ISUP| | | | | 3290 |___________|_____|______|____________|_____________|_____|__________| 3291 | | | | | | | notices | 3292 | | | | | | | packet | 3293 | | | | | | | to PC | 3294 | | | | | <- | - -| NTFY | 3295 | | | | | Ack | - -| -> | 3296 | | | | | Decides to | | | 3297 | | | | | place an | | | 3298 | | | | | outgoing | | | 3299 | | | | | call. | | | 3300 | | | | | Call start | -> | | 3301 | | | | <- | Create | | | 3302 | | | | | Connection | | | 3303 | | | | | (data) | | | 3304 | | | | Ack | -> | | | 3305 | | | <- | - - | IAM | | | 3306 | (rings) | <- | IAM | | | | | 3307 | | ACM| -> | | | | | 3308 | | | ACM | - - | -> | | | 3309 | (answer) | ANM| -> | | | | | 3310 | | | ANM | - - | -> | | | 3311 | | | | | Connection | | | 3312 | | | | | complete. | | | 3313 | | | | | Call | | | 3314 | | | | | established| -> | | 3315 | PPP | - -| - - | -> | | | | 3316 | <- | - -| - - | Validates | | | | 3317 | | | | call, | | | | 3318 | | | | announces | | | | 3319 | | | | IP address| - - | - -| -> | 3320 | Connected | | | | | | | 3321 | to the | | | | | | | 3322 | Internet | | | | | | | 3323 | | | | | | | | 3324 |___________|_____|______|____________|_____________|_____|__________| 3326 Internet draft MGCP Call Flows 20 January 1999 3328 ___________________________________________________________________ 3329 | PC | CO | SS7/| NAS | CA | ACC| Router| 3330 | | | ISUP| | | | | 3331 |____________|_____|______|____________|____________|_____|________| 3332 | Closes | | | | | | | 3333 | connection.| | | | | | | 3334 | | REL| -> | | | | | 3335 | | | REL | - - | -> | | | 3336 | | | | <- | Delete | | | 3337 | | | | | Connection| | | 3338 | | | | ceases | | | | 3339 | | | | announcing| | | | 3340 | | | | IP address| - - | - -| -> | 3341 | | | | Perf | | | | 3342 | data | -> | | | | | | 3343 | | | <- | - - | RLC | | | 3344 | | <- | RLC | | | | | 3345 | | | | | Call end | -> | | 3346 |____________|_____|______|____________|____________|_____|________| 3348 This diagram shows the exchange of messages during a 3349 call from an an Internet Service Provider to a modem, 3350 using a trunking gateway that doubles as a Network 3351 Access Server. During these exchanges the MGCP is used 3352 by the Call Agent to control both the NAS, and will also 3353 be used between the Call Agent and a default router of 3354 the ISP. 3356 In the example configuration, the calls are set on 3357 demand, when data have to actually be sent from the 3358 Internet to the dial-up user. When no connection is 3359 established, the local routing is configured to send the 3360 packets towards a default router which may or may not be 3361 the same machine as the NAS. In redundant configura- 3362 tions, there could be many default routers. Each of 3363 these default routers has been programmed (through a 3364 notification request) to send a notification to the Call 3365 Agent when it receives a packet on the default route: 3367 NTFY 2005 default-route@router25.whatever.net MGCP 0.1 3368 X: 3369 0123456789AF 3370 O: pa(192.96.41.1) 3372 After this notification, the Call Agent should send an 3373 acknowledgement: 3375 Internet draft MGCP Call Flows 20 January 1999 3377 200 2005 OK 3379 (We should note here that using MGCP for this function 3380 is a stretch. There are other protocols, notably RMON, 3381 that already provide an adequate service. These proto- 3382 cols could be used instead of MGCP without affecting the 3383 discussion that follows.) 3385 The Call Agent deduces from the notification that a cir- 3386 cuit should be established towards the dial-up user, or 3387 towards the dial-up router. Using configuration data- 3388 bases, the Call Agent selects the number that should be 3389 called, and also the type of modem parameters and 3390 authentication parameters that correspond to the called 3391 number. The Call Agent uses its routing table to select 3392 an adequate NAS, with an available outgoing trunk. It 3393 uses a create connection command to seize this outgoing 3394 trunk: 3396 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 3397 C: A3C47F21456789F0 3398 M: data 3399 X: 0123456789B1 3400 R: cl 3402 v=0 3403 m=nas/none 3404 c=IN IP4 128.96.41.1 3405 a=subnet:IN IP4 123.45.67.64/26 3406 a=bearer:isdn64 3407 a=framing:ppp-hdlc 3408 a=dialed:18001234567 3409 a=dialing:2345678901 3411 The gateway immediately acknowledges the creation, send- 3412 ing back the identification of the newly created connec- 3413 tion. (There is no session description in the case of a 3414 data call.) 3416 200 1237 OK 3417 I: FDE234C8 3419 Once the trunk has been seized, the Call Agent will send 3420 an IAM message to the switch that controls the trunk. 3421 The dialed PC will "ring" and eventually take the call, 3423 Internet draft MGCP Call Flows 20 January 1999 3425 triggering the arrival of progress messages and then an 3426 answer message (ANM). At that point, the Call Agent 3427 knows that the call is established. 3429 The DSP associated to the incoming trunk has been loaded 3430 with the specified modem code - a simple HDLC framing in 3431 our example. Once the call is established, the calling 3432 PC will train with the modem associated with the trunk. 3433 In our example, no authentication is requested: the Call 3434 Agent has identified the dialed user through its called 3435 number. 3437 Once the association is established and the IP service 3438 is validated, the gateway announces that it serves the 3439 local user. In our example, there is no address confi- 3440 guration performed through PPP: the dialed user has a 3441 permanent address, which has been programmed when it 3442 subscribed to the service. However, one the circuit is 3443 validated, the gateway should start announcing its 3444 access to this permanent address in the routing tables. 3445 In our example, the dialed station is in fact an access 3446 point to a local network, and the NAS should start 3447 announcing accessibility of that local network 3448 (123.45.67.64/26) through the local routing procedures 3449 (an IGP such as RIP, OSPF or EIGRP). 3451 Note that the current design makes the hypothesis that 3452 the Call Agent "tells" the address of the LAN to the 3453 NAS. This is a very debatable design. If a secure IGP is 3454 used (e.g. using embedded keyed MD5 authentication, or 3455 using IPSEC) then the routing prefix will be naturally 3456 exchanged through this IGP. On the other hand, some form 3457 of configuration can provide a "double check" against 3458 user errors. 3460 In our example, the call is completed when the called 3461 modem hangs up. This triggers an ISUP release message, 3462 which is forwarded to the Call Agent. The Call Agent 3463 will request the NAS to delete the connection: 3465 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 3466 C: A3C47F21456789F0 3467 I: FDE234C8 3469 The gateways will respond with a message that should 3470 include a "call parameters" header fields: 3472 Internet draft MGCP Call Flows 20 January 1999 3474 250 1244 OK 3475 P: PS=1245, OS=62345, PR=780, OR=45123 3477 We should note that, because this is a data call, the 3478 call parameters only include a count of the packets and 3479 octets that were sent and received. 3481 5.3. Call back, using a NAS 3483 There are three classic forms of call-back: 3485 1- ANI-based Callback 3487 2- PPP Callback (Microsoft Callback is a variant of 3488 this) 3490 3- Login-based callback 3492 The ANI based call-back can be implemented entirely in 3493 the Call Agent, as indicated in the following diagram: 3495 ______________________________________________________________ 3496 PC CO SS7/ NAS CA ACC 3497 ISUP 3498 ______________________________________________________________ 3499 dials IAM -> 3500 IAM - - -> 3501 Notices that the 3502 called number corresponds 3503 to a call back service, 3504 and that the calling 3505 number has subscribed 3506 to that service. 3507 Terminates the 3508 incoming call. 3509 <- - - REL 3510 <- REL 3511 RLC -> 3512 hangup RLC - - -> 3513 Decides to place 3514 an outgoing call. 3515 Call start -> 3516 <- Create 3517 Connection (data) 3518 Ack -> 3519 <- - - IAM 3520 (rings) <- IAM 3522 Internet draft MGCP Call Flows 20 January 1999 3524 |________|_____|______|_____|___________________________|_____| 3526 The PPP callback suppose that the modem first estab- 3527 lishes an incoming connection, and go through the 3528 authentication exchange. The following diagram provides 3529 an example of these exchanges: 3531 Internet draft MGCP Call Flows 20 January 1999 3533 ____________________________________________________________________ 3534 | PC | CO | SS7/| NAS | CA | ACC| Radius| 3535 | | | ISUP| | | | | 3536 |_________|_____|______|____________|________________|_____|________| 3537 | dials in| | | | | | | 3538 | | IAM| -> | | | | | 3539 | | | IAM | - - | -> | | | 3540 | | | | | Checks called | | | 3541 | | | | | number. | | | 3542 | | | | | Notices | | | 3543 | | | | | data call. | | | 3544 | | | | | Call start | -> | | 3545 | | | | <- | Create | | | 3546 | | | | | Connection | | | 3547 | | | | | (data) | | | 3548 | | | | Ack | -> | | | 3549 | | | | | Connection | | | 3550 | | | | | completed. | | | 3551 | | | | | Call | | | 3552 | | | | | established | -> | | 3553 | | | <- | - - | ANM | | | 3554 | | <- | ANM | | | | | 3555 | modem | - -| - - | -> | | | | 3556 | <- | - -| - - | handshake | | | | 3557 | PPP | - -| - - | -> | | | | 3558 | | | | obtain | | | | 3559 | | | | user-id, | | | | 3560 | | | | password | | | | 3561 | | | | Check | - - | - -| -> | 3562 | | | | <- | - - | - -| Ack | 3563 | | | | reports | | | | 3564 | | | | call back | | | | 3565 | | | | condition | | | | 3566 | | | | NTFY | -> | | | 3567 | | | | <- | ACK | | | 3568 | | | | | Decides | | | 3569 | | | | | to place an | | | 3570 | | | | | outgoing call.| | | 3571 | | | | <- | Delete | | | 3572 | | | | | Connection | | | 3573 | | | | Perf | | | | 3574 | | | | data | -> | | | 3575 | | | <- | - - | REL | | | 3576 | | <- | REL | | | | | 3577 | | REL| -> | | | | | 3578 | hangup | | REL | - - | -> | | | 3579 |_________|_____|______|____________|________________|_____|________| 3581 Internet draft MGCP Call Flows 20 January 1999 3583 __________________________________________________________________________ 3584 | PC | CO | SS7/| NAS | CA | ACC| Radius| 3585 | | | ISUP| | | | | 3586 |____________|_____|______|__________________|_____________|_____|________| 3587 | | | | | Call start | -> | | 3588 | | | | <- | Create | | | 3589 | | | | | Connection | | | 3590 | | | | | (data) | | | 3591 | | | | Ack | -> | | | 3592 | | | <- | - - | IAM | | | 3593 | (rings) | <- | IAM | | | | | 3594 | | ACM| -> | | | | | 3595 | | | ACM | - - | -> | | | 3596 | (answer) | ANM| -> | | | | | 3597 | | | ANM | - - | -> | | | 3598 | | | | | Connection | | | 3599 | | | | | complete. | | | 3600 | | | | | Call | | | 3601 | | | | | established| -> | | 3602 | PPP | - -| - - | -> | | | | 3603 | <- | - -| - - | Validates call, | | | | 3604 | Connected | | | | | | | 3605 | to the | | | | | | | 3606 | Internet | | | | | | | 3607 | | | | | | | | 3608 | Closes | | | | | | | 3609 | connection.| | | | | | | 3610 | | REL| -> | | | | | 3611 | | | REL | - - | -> | | | 3612 | | | | <- | Delete | | | 3613 | | | | | Connection | | | 3614 | | | | Perf data | -> | | | 3615 | | | <- | - - | RLC | | | 3616 | | <- | RLC | | | | | 3617 | | | | | Call end | -> | | 3618 |____________|_____|______|__________________|_____________|_____|________| 3620 This diagram shows the exchange of messages during a 3621 call from a modem user to an Internet Service Provider, 3622 using a trunking gateway that doubles as a Network 3623 Access Server. During these exchanges the MGCP is used 3624 by the Call Agent to control the NAS. 3626 Upon reception of the IAM message, the Call Agent 3627 notices that the called number corresponds to a data 3628 service. Using configuration databases, the Call Agent 3630 Internet draft MGCP Call Flows 20 January 1999 3632 selects the type of modem parameters and authentication 3633 parameters that correspond to the called number and to 3634 the calling number. It uses this knowledge to send a 3635 connection command to the NAS, programming the incoming 3636 trunk: 3638 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 3639 C: A3C47F21456789F0 3640 M: data 3641 X: 0123456789B1 3642 R: cl, cbk 3644 v=0 3645 m=nas/radius 3646 c=radius.example.net 3647 a=bearer:v.32 3648 a=framing:ppp-asynch 3649 a=dialed:18001234567 3650 a=dialing:2345678901 3652 The gateway immediately acknowledges the creation, send- 3653 ing back the identification of the newly created connec- 3654 tion. (There is no session description in the case of a 3655 data call.) 3657 200 1237 OK 3658 I: FDE234C8 3660 The Call Agent, knowing that this is a data call, can 3661 immediately acknowledge the establishment of the connec- 3662 tion, sending an ANM message back to the calling switch. 3664 The DSP associated to the incoming trunk has been loaded 3665 with the specified modem code. Once the call is esta- 3666 blished, the modem of the calling PC will be synchron- 3667 ized with the modem associated to the trunk. The caller 3668 will then proceed to a normal PPP synchronization, which 3669 probably implies a PPP login. The login parameters, in 3670 our example, are checked using Radius. The Radius server 3671 that will be used is typically chosen as a function of 3672 the called number, which identifies the data service 3673 that the calling modem requested. In fact, the number 3674 can also be used to identify the specific form of 3675 authentication that is requested. 3677 In the call back example, the Radius server will 3679 Internet draft MGCP Call Flows 20 January 1999 3681 indicate that the call cannot be completed as such, and 3682 that the user should be called back (for example, using 3683 a "Callback Framed" service type in its access-accept 3684 response.) The NAS will thus send a Notify message to 3685 the Call Agent, indicating that a call-back is 3686 requested: 3688 NTFY 2005 card23/21@trgw-7.whatever.net MGCP 0.1 3689 X: 0123456789B1 3690 O: cbk(user-id) 3692 After this notification, the Call Agent should send an 3693 acknowledgement: 3695 200 2005 OK 3697 The Call Agent will check that the call back request can 3698 be followed through. In its databases, it will find the 3699 regular address associated to the "user-id," and prepare 3700 to set up a call to that address. It will first clear 3701 the incoming call, sending a DeleteConnection command to 3702 the NAS: 3704 In our example, the call is completed when the calling 3705 modem hangs up. This triggers an ISUP release message, 3706 which is forwarded to the Call Agent. The Call Agent 3707 will request the NAS to delete the connection, and reset 3708 the list of observed events: 3710 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 3711 C: A3C47F21456789F0 3712 I: FDE234C8 3713 X: 0123456789B2 3714 R: 3716 The gateways will respond with a message that should 3717 include a "call parameters" header fields: 3719 250 1244 OK 3720 P: PS=2, OS=345, PR=1, OR=123 3722 We should note that, because this is a data call, the 3723 call parameters only include a count of the packets and 3724 octets that were sent and received. 3726 Internet draft MGCP Call Flows 20 January 1999 3728 The Call Agent will then proceed to set up an outgoing 3729 data call. This call may be routed through the same NAS 3730 that received the incoming call, but can also be routed 3731 through an entirely different endpoint , for example if 3732 the calling user has moved out of its normal region. 3734 Internet draft MGCP Call Flows 20 January 1999 3736 5.4. Data call to a NAS, using L2TP 3738 ________________________________________________________________________ 3739 | PC | CO | SS7/| NAS | CA | ACC| LNS | 3740 | | | ISUP| | | | | 3741 |___________|_____|______|_______________|______________|_____|_________| 3742 | dials in | | | | | | | 3743 | | IAM| -> | | | | | 3744 | | | IAM | - - | -> | | | 3745 | | | | | Check called| | | 3746 | | | | | number. | | | 3747 | | | | | Notices | | | 3748 | | | | | data call. | | | 3749 | | | | | Call start | -> | | 3750 | | | | <- | Create | | | 3751 | | | | | Connection | | | 3752 | | | | | (data) | | | 3753 | | | | Ack | -> | | | 3754 | | | | | Connection | | | 3755 | | | | | complete. | | | 3756 | | | | | Call | | | 3757 | | | | | established | -> | | 3758 | | | <- | - - | ANM | | | 3759 | | <- | ANM | | | | | 3760 | modem | - -| - - | -> | | | | 3761 | <- | - -| - - | handshake | | | | 3762 | PPP | - -| - - | -> | | | | 3763 | | | | obtain | | | | 3764 | | | | user-id, | | | | 3765 | | | | password | | | | 3766 | | | | Establish | | | | 3767 | | | | Tunnel | | | | 3768 | | | | SCC-REQ | - - | - -| -> | 3769 | | | | <- | - - | - -| SCC-REP| 3770 | | | | <- | - - | - -| SCC-CON| 3771 | | | | IC-REQ | - - | - -| -> | 3772 | | | | <- | - - | - -| IC-REP | 3773 | | | | <- | - - | - -| IC-CON | 3774 | | | | Spoof PPP/LCP| - - | - -| -> | 3775 | <- | - -| - - | Relays PPP | - - | - -| -> | 3776 | Connected | | | | | | | 3777 | to the | | | | | | | 3778 | Internet | | | | | | | 3779 |___________|_____|______|_______________|______________|_____|_________| 3781 Internet draft MGCP Call Flows 20 January 1999 3783 _______________________________________________________________ 3784 | PC | CO | SS7/| NAS | CA | ACC| LNS| 3785 | | | ISUP| | | | | 3786 |____________|_____|______|___________|____________|_____|_____| 3787 | Closes | | | | | | | 3788 | connection.| | | | | | | 3789 | | REL| -> | | | | | 3790 | | | REL | - - | -> | | | 3791 | | | | <- | Delete | | | 3792 | | | | | Connection| | | 3793 | | | | Perf | | | | 3794 | | | | data | -> | | | 3795 | | | <- | - - | RLC | | | 3796 | | <- | RLC | | | | | 3797 | | | | CDN | - - | - -| -> | 3798 | | | | Stop-CC-N| - - | - -| -> | 3799 | | | | | Call end | -> | | 3800 |____________|_____|______|___________|____________|_____|_____| 3802 This diagram shows the exchange of messages during a 3803 call from a modem user to an Internet Service Provider, 3804 using a trunking gateway that doubles as a Network 3805 Access Server. During these exchanges the MGCP is used 3806 by the Call Agent to control the NAS. The PPP informa- 3807 tion is relayed to a network server (LNS) using L2TP. 3809 Upon reception of the IAM message, the Call Agent 3810 notices that the called number corresponds to a data 3811 service. Using configuration databases, the Call Agent 3812 selects the type of modem parameters and authentication 3813 parameters that correspond to the called number and to 3814 the calling number. It uses this knowledge to send a 3815 connection command to the NAS, programming the incoming 3816 trunk: 3818 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 3819 C: A3C47F21456789F0 3820 M: data 3821 X: 0123456789B1 3822 R: cl 3824 v=0 3825 c=IN IP4 access.example.net 3826 m=nas/l2tp 3827 k=clear:some-shared-secret 3828 a=bearer:v.32 3830 Internet draft MGCP Call Flows 20 January 1999 3832 a=framing:ppp-asynch 3833 a=dialed:18001234567 3834 a=dialing:2345678901 3836 The gateway immediately acknowledges the creation, send- 3837 ing back the identification of the newly created connec- 3838 tion. (There is no need to transmit a session descrip- 3839 tion in the case of a data call.) 3841 200 1237 OK 3842 I: FDE234C8 3844 The Call Agent, knowing that this is a data call, can 3845 immediately acknowledge the establishment of the connec- 3846 tion, sending an ANM message back to the calling switch. 3848 The DSP associated to the incoming trunk has been loaded 3849 with the specified modem code. Once the call is esta- 3850 blished, the modem of the calling PC will be synchron- 3851 ized with the modem associated to the trunk. The caller 3852 will then proceed to a normal PPP synchronization, which 3853 probably implies a PPP login. 3855 Once PPP has been properly synchronized, the NAS estab- 3856 lishes a tunnel towards the LNS. Because L2TP is a two- 3857 layer protocol, the NAS must first establish an L2TP 3858 control connection between itself and the LNS. This con- 3859 nection may or may not have been established prior to 3860 the call set-up. 3862 Tunnel establishment requires a shared secret between 3863 the LNS and the NAS; in our example, that secret is 3864 passed by the Call Agent, along with the name of the 3865 LNS. Once the supporting tunnel is installed, the NAS 3866 has to establish an L2TP tunnel, to relay the "incoming 3867 call." Once the call is established, the PPP packets 3868 received on the trunk will be relayed over the L2TP tun- 3869 nel, and vice-versa. 3871 In our example, the call is completed when the calling 3872 modem hangs up. This triggers an ISUP release message, 3873 which is forwarded to the Call Agent. The Call Agent 3874 will request the NAS to delete the connection: 3876 Internet draft MGCP Call Flows 20 January 1999 3878 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 3879 C: A3C47F21456789F0 3880 I: FDE234C8 3882 The gateways will respond with a message that should 3883 include a "call parameters" header fields: 3885 250 1244 OK 3886 P: PS=1245, OS=62345, PR=780, OR=45123 3888 We should note that, because this is a data call, the 3889 call parameters only include a count of the packets and 3890 octets that were sent and received. 3892 5.5. Basic data call with continuity test 3894 Internet draft MGCP Call Flows 20 January 1999 3896 ___________________________________________________________________ 3897 | PC | CO | SS7/| NAS | CA | ACC| Radius| 3898 | | | ISUP| | | | | 3899 |_________|_____|______|___________|________________|_____|________| 3900 | dials in| | | | | | | 3901 | | IAM| -> | | | | | 3902 | | | IAM | - - | -> | | | 3903 | | | | | Check called | | | 3904 | | | | | number. | | | 3905 | | | | | Notices | | | 3906 | | | | | data call, | | | 3907 | | | | | continuity | | | 3908 | | | | | test. | | | 3909 | | | | | Call start | -> | | 3910 | | | | <- | Create | | | 3911 | | | | | Connection | | | 3912 | | | | | (loopback) | | | 3913 | | | | Ack | -> | | | 3914 | | COT| -> | | | | | 3915 | | | COT | - - | -> | | | 3916 | | | | <- | Modify | | | 3917 | | | | | Connection | | | 3918 | | | | | (data) | | | 3919 | | | | Ack | -> | | | 3920 | | | | | Connection | | | 3921 | | | | | is completed. | | | 3922 | | | | | Call | | | 3923 | | | | | established | -> | | 3924 | | | <- | - - | ANM | | | 3925 | | <- | ANM | | | | | 3926 | modem | - -| - - | -> | | | | 3927 | <- | - -| - - | handshake| | | | 3928 | PPP | - -| - - | -> | | | | 3929 |_________|_____|______|___________|________________|_____|________| 3931 This diagram shows the various exchange of messages dur- 3932 ing the beginning of a call from a data user on the 3933 circuit-switched PSTN to a NAS. During these exchanges 3934 the Call Agent uses MGCP to control the NAS and the 3935 residential gateway. The circuit switch decides to exe- 3936 cute a continuity test during the call establishment. 3937 The exchanges occur on two sides. 3939 Upon reception of the IAM message, the Call Agent recog- 3940 nizes that a continuity test has been requested. It 3941 immediately sends a CreateConnection request to the NAS 3942 to connect to the incoming trunk, creating a connection: 3944 Internet draft MGCP Call Flows 20 January 1999 3946 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 3947 C: A3C47F21456789F0 3948 L: p:10, a:G.711;G.726-32 3949 M: loopback 3950 X: 0123456789B1 3951 R: cl 3953 v=0 3954 m=nas/radius 3955 c=IN IP4 radius.example.net 3956 a=bearer:v.32 3957 a=framing:ppp-asynch 3958 a=dialed:18001234567 3959 a=dialing:2345678901 3961 The trunking gateway recognizes that the mode is set to 3962 "loopback". It places the circuit in "loopback" mode 3963 (we assume that this is the adequate way to perform con- 3964 tinuity test in this specific environment). The gateway 3965 is then ready to send back a 2010 Hz return tone if it 3966 receives a 2010 Hz test tone. The gateway acknowledges 3967 the creation of the connection, sending back the iden- 3968 tification of the newly created connection: 3970 200 1237 OK 3971 I: FDE234C8 3973 At this point, the call agent is waiting for the result 3974 of the continuity test. The calling switch is sending 3975 the test tone (2010 Hz); if it receives the return tone 3976 (2010 Hz), it will send a "continuity passed" message 3977 (COT). At this point, the call agent will send a modify 3978 connection message to the NAS, in order to place the 3979 connection in "data" mode: 3981 MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1 3982 C: A3C47F21456789F0 3983 I: FDE234C8 3984 M: data 3986 The NAS will immediately acknowledge that command: 3988 200 1238 OK 3990 The NAS will then proceed with the establishment of the 3992 Internet draft MGCP Call Flows 20 January 1999 3994 modem call. 3996 Internet draft MGCP Call Flows 20 January 1999 3998 6. Audit and Restart 4000 The following call flows provide examples of the audit 4001 and restart commands. 4003 6.1. Using the Audit commands 4005 __________________________________________________________________ 4006 | CO | SS7| TGW | CA | CDB | ACC | RGW| Usr| 4007 |____|_____|_______|__________________|_______|_______|_____|_____| 4008 | | | | | | | | | 4009 | | | <- | Audit Endpoint | | | | | 4010 | | | | (endpoints) | | | | | 4011 | | | Ack | -> | | | | | 4012 | | | <- | Audit | | | | | 4013 | | | | Endpoint | | | | | 4014 | | | | (capabilities) | | | | | 4015 | | | Ack | -> | | | | | 4016 | | | | | | | | | 4017 | | | | Audit Endpoint | - - -| - - -| -> | | 4018 | | | | (endpoints) | | | | | 4019 | | | | <- | - - -| - - -| Ack| | 4020 | | | | Audit Endpoint | - - -| - - -| -> | | 4021 | | | | (capabilities) | | | | | 4022 | | | | <- | - - -| - - -| Ack| | 4023 | | | | | | | | | 4024 | IAM| -> | | | | | | | 4025 | | IAM| - - -| -> | | | | | 4026 | | | | (proceed with | | | | | 4027 | | | | call setup) | | | | | 4028 | | | | ... | | | | | 4029 | | <- | - - -| ANM | | | | | 4030 | <- | ANM| | | | | | | 4031 | | | | | | | | | 4032 | | | <- | Audit Endpoint | | | | | 4033 | | | | (misc) | | | | | 4034 | | | Ack | -> | | | | | 4035 | | | <- | Audit Connection| | | | | 4036 | | | Ack | -> | | | | | 4037 | | | | | | | | | 4038 | | | | Audit Endpoint | | | | | 4039 | | | | (misc) | - - -| - - -| -> | | 4040 | | | | <- | - - -| - - -| Ack| | 4041 | | | | Audit Connection| - - -| - - -| -> | | 4042 | | | | <- | - - -| - - -| Ack| | 4043 | | | | | | | | | 4044 |____|_____|_______|__________________|_______|_______|_____|_____| 4046 Internet draft MGCP Call Flows 20 January 1999 4048 This diagram shows the various exchanges of messages 4049 during auditing of a trunk gateway and a residential 4050 gateway. First, both gateways are auditing to learn 4051 about the endpoints supported by each. Secondly, capa- 4052 bilities information is audited for one of these end- 4053 points. The procedure is carried out for the residential 4054 gateway as well. A call then arrives from the PSTN and 4055 is established exactly as described in the "basic call 4056 from TGW to RGW". After the call has been established, 4057 both endpoints involved in the call are audited -- this 4058 time in order to retrieve endpoint info and subsequently 4059 connection info associated with the call. 4061 The Call Agent initially sends an AuditEndpoint command 4062 to the trunking gateway in order to discover what end- 4063 points the trunking gateway has: 4065 AUEP 1200 *@trgw-7.whatever.net MGCP 0.1 4066 F: 4068 Since we use the wildcard naming convention, we cannot 4069 retrieve any endpoint specific information but the 4070 RequestedInfo field must still be included. Had we 4071 specified any RequestedInfo, the trunking gateway would 4072 simply have ignored it. 4074 The trunking gateway immediately acknowledges the audit- 4075 ing command and sends back the list of endpoints it con- 4076 tains. Our trunking gateway has two cards in it -- 4077 card23 and card24 each supporting two circuits: 4079 200 1200 OK 4080 Z: card23/20@trgw-7.whatever.net 4081 Z: card23/21@trgw-7.whatever.net 4082 Z: card24/20@trgw-7.whatever.net 4083 Z: card24/21@trgw-7.whatever.net 4085 Now that the Call Agent has learned about the endpoints 4086 present in the trunking gateway, it requests capability 4087 information for one of the endpoints. We here assume 4088 that all similar endpoints have the same capabilities 4089 and thus only audit one of them for capabilities, 4090 although it is possible that different endpoints have 4091 different capabilities: 4093 AUEP 1201 card23/20@trgw-7.whatever.net 4095 Internet draft MGCP Call Flows 20 January 1999 4097 F: A 4099 The trunking gateway acknowledges the command by return- 4100 ing to the Call Agent a response describing the capabil- 4101 ities it supports for the endpoint in question: 4103 200 1201 OK 4104 L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:T;D, 4105 m:sendonly;recvonly;sendrecv;inactive;conttest 4107 The Call Agent thereby learns, that the endpoint sup- 4108 ports two codecs; G.711 and G.726-32 which can each be 4109 used with a packetization period of between 10 and 100 4110 msec. Echo cancellation is supported while silence 4111 suppression is not, and the event packages supported are 4112 Trunk and DTMF. Since Trunk is the first package speci- 4113 fied it is furthermore the default package. Also, con- 4114 nections can be established in either of the modes "Send 4115 Only", "Receive Only", "Send/Receive", "Inactive", and 4116 "Continuity Test". Finally, several parameters were not 4117 specified and default or deduced values will therefore 4118 apply. These parameters are Bandwidth (deduce from 4119 codec), Gain Control (supported), Type of Service (sup- 4120 ported), Resource Reservation (best effort), Encryption 4121 Key (no encryption), or Type of Network (guess) was pro- 4122 vided and default or deduced values for each of these 4123 will therefore apply. Next the Call Agent queries the 4124 residential gateway to discover what endpoints are 4125 present in it: 4127 AUEP 2000 *@rgw.whatever.net MGCP 0.1 4128 F: 4130 As before, we use the wildcard naming convention and can 4131 therefore not retrieve any endpoint specific informa- 4132 tion, however the RequestedInfo field must still be 4133 included. If any values had been specified for it, they 4134 would simply be ignored. 4136 The residential gateway acknowledges the command and 4137 includes a list of endpoints it contains: 4139 200 2000 OK 4140 Z: endpoint/1@rgw-2567.whatever.net 4141 Z: endpoint/2@rgw-2567.whatever.net 4143 Internet draft MGCP Call Flows 20 January 1999 4145 The Call Agent thereby learns, that the residential 4146 gateway contains the two endpoints endpoint/1 and end- 4147 point/2. Having learned about the endpoints present, 4148 the Call Agent next requests capability information for 4149 one of the endpoints. Again, we assume that all similar 4150 endpoints have the same capabilities and thus only audit 4151 one of them for capabilities, although it is possible 4152 that different endpoints have different capabilities: 4154 AUEP 2001 endpoint/1@rgw-2567.whatever.net 4155 F: A 4157 The residential gateway acknowledges the command by 4158 returning to the Call Agent a response describing the 4159 capabilities it supports for the endpoint in question: 4161 200 1201 OK 4162 L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:L;D, 4163 m:sendonly;recvonly;sendrecv;inactive 4164 L: a:G.723.1; p:30-90, e:on, s:on, v:L;D, 4165 m:sendonly;recvonly;sendrecv;inactive;confrnce 4167 The Call Agent thereby learns, that the endpoint sup- 4168 ports three codecs; G.711, G.726-32, and G.723.1. 4170 G.711 and G.726-32 can each be used with a packetization 4171 period of between 10 and 100 msec. Echo cancellation is 4172 supported while silence suppression is not, and the 4173 event packages supported are Line and DTMF. Since Line 4174 is the first package specified it is furthermore the 4175 default package. Also, connections can be established in 4176 either of the modes "Send Only", "Receive Only", 4177 "Send/Receive", and "Inactive". Finally, several parame- 4178 ters were not specified and default or deduced values 4179 will therefore apply. These parameters are Bandwidth 4180 (deduce from codec), Gain Control (supported), Type of 4181 Service (supported), Resource Reservation (best effort), 4182 Encryption Key (no encryption), or Type of Network 4183 (guess) was provided and default or deduced values for 4184 each of these will therefore apply. 4186 G.723.1 can be used with a packetization period of 4187 between 30 and 90 msec. Both echo cancellation and 4188 silence suppression are supported, and the event pack- 4189 ages supported are Line and DTMF with Line being the 4190 default package. Connections can be established in 4192 Internet draft MGCP Call Flows 20 January 1999 4194 either of the modes "Send Only", "Receive Only", 4195 "Send/Receive", "Inactive", and "Conference". Finally, 4196 default or deduced values will be applied for the param- 4197 eters that were not supplied. 4199 The Call Agent now knows all endpoints as well as their 4200 capabilities in the trunking and the residential gate- 4201 way. 4203 An IAM signaling a call for the residential gateway now 4204 arrives from the PSTN. The call is then setup as 4205 described in Section 2.2. After the call has been suc- 4206 cessfully setup, the Call Agent now decides to audit the 4207 endpoint in the trunking gateway for information about 4208 RequestedEvents, DigitMap, SignalRequests, RequestIden- 4209 tifier, NotifiedEntity, ConnectionIdentifiers, and 4210 DetectEvents: 4212 AUEP 1202 card23/21@trgw-7.whatever.net MGCP 0.1 4213 F: R,D,S,X,N,I,T 4215 The trunking gateway acknowledges the command by return- 4216 ing to the Call Agent a response with the requested info 4217 for the endpoint in question: 4219 200 1202 OK 4220 R: 4221 D: 4222 S: 4223 X: 4224 N: [128.96.41.12] 4225 I: FDE234C8, ABCD123 4226 T: 4228 The Call Agent thus sees, that there are currently no 4229 RequestedEvents, no DigitMap, no SignalRequests, no 4230 RequestIdentifier, and no DetectEvents for the endpoint 4231 in question. Instead of supplying empty list for these 4232 parameters, the gateway could simply have omitted them 4233 altogether in the response. 4235 In the last command the call agent sent to the endpoint, 4236 it had not specified a NotifiedEntity, thus the notified 4237 entity returned here is the source IP address of the 4238 call agent encoded in RFC 821 format. Finally, the end- 4239 point currently has two connections associated with it. 4241 Internet draft MGCP Call Flows 20 January 1999 4243 The first one was created during the call setup. Depend- 4244 ing on previous message exchanges, the second one may or 4245 may not be valid. If the call agent believes it is 4246 stale, it could simply instruct the gateway to delete 4247 it. 4249 In this case, the Call Agent decides to audit the con- 4250 nection FDE234C8 for further information and it there- 4251 fore sends an AuditConnection command to the endpoint 4252 for information about CallId, NotifiedEntity, LocalCon- 4253 nectionOptions, Mode, LocalConnectionDescriptor, 4254 RemoteConnectionDescriptor, and ConnectionParameters: 4256 AUCX 1203 card23/21@trgw-7.whatever.net MGCP 0.1 4257 I: FDE234C8 4258 F: C,N,L,M,LD,RD,P 4260 When the trunking gateway receives the command it 4261 immediately sends a response to the Call Agent with the 4262 requested info: 4264 200 1203 OK 4265 C: A3C47F21456789F0 4266 N: [128.96.41.12] 4267 L: p:10, a:G.711;G.726-32 4268 M: sendrecv 4269 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 4271 v=0 4272 c=IN IP4 128.96.41.1 4273 m=audio 1296 RTP/AVP 0 4274 v=0 4275 c=IN IP4 128.96.63.25 4276 m=audio 1296 RTP/AVP 0 96 4277 a=rtpmap:96 G726-32/8000 4279 Thus the CallId, LocalConnectionOptions, and Mode are as 4280 expected for this connection. The same holds for the 4281 RemoteConnectionDescriptor which is supplied as the last 4282 parameter separated by an empty line. The last connec- 4283 tion handling command issued to the endpoint for this 4284 connection did not include the NotifiedEntity parameter, 4285 so the notified entity defaults to the source IP address 4286 for that command which is encoded in RFC 821 format. 4287 Finally, the Call Agent also obtained the current packet 4288 statistics for the call. 4290 Internet draft MGCP Call Flows 20 January 1999 4292 Next, the Call Agent audits the endpoint in the residen- 4293 tial gateway for information about RequestedEvents, 4294 DigitMap, SignalRequests, RequestIdentifier, NotifiedEn- 4295 tity, ConnectionIdentifiers, and DetectEvents: 4297 AUEP 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4298 F: R,D,S,X,N,I,T 4300 The trunking gateway acknowledges the command by return- 4301 ing to the Call Agent a response with the requested info 4302 for the endpoint in question: 4304 200 2002 OK 4305 R: L/hu 4306 D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) 4307 S: 4308 X: 0123456789B1 4309 N: [128.96.41.12] 4310 I: 32F345E2 4311 T: hu 4313 The Call Agent thus sees, that currently, the only event 4314 being looked for is the "On hook" event from the Line 4315 package. Since the Line package is the default package, 4316 the gateway could have simply specified this as "hu" 4317 instead. Although the residential gateway is currently 4318 not accumulating any digits, a digit map is still sup- 4319 plied. This digit map is the last one used by the end- 4320 point used -- we here assume the endpoint was previously 4321 originated a call, e.g. as in Section 2.1. There are 4322 currently no signals being applied so the SignalRequests 4323 parameter is simply empty. There is however an active 4324 NotificationRequest thus the RequestIdentifier for that 4325 one is supplied. As before, no NotifiedEntity has been 4326 specified for the last NotificationRequest for this end- 4327 point, so the source IP address of that request is sup- 4328 plied as the notified entity. There is only one Connec- 4329 tionId for this endpoint, namely 32F345E2 as expected. 4330 Finally, since the last NotificationRequest did not 4331 specify any special value for DetectEvents, this parame- 4332 ter simply defaults to the same as RequestedEvents. In 4333 this case we omitted the specification of the Line pack- 4334 age in the event name since the Line package is the 4335 default package for this endpoint. 4337 Having audited the endpoint, the Call Agent decides to 4339 Internet draft MGCP Call Flows 20 January 1999 4341 audit the connection for that endpoint and the Call 4342 Agent therefore sends an AuditConnection command to the 4343 requesting information about CallId, NotifiedEntity, 4344 LocalConnectionOptions, Mode, LocalConnectionDescriptor, 4345 RemoteConnectionDescriptor and ConnectionParameters. 4347 AUCX 2003 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4348 I: 32F345E2 4349 F: C,N,L,M,LD,RD,P 4351 When the residential gateway receives the command it 4352 immediately sends a response to the Call Agent with the 4353 requested info: 4355 200 2003 OK 4356 C: A3C47F21456789F0 4357 N: [128.96.41.12] 4358 L: p:10, a:G.711;G.726-32 4359 M: sendrecv 4361 v=0 4362 c=IN IP4 128.96.63.25 4363 m=audio 1296 RTP/AVP 0 96 4364 a=rtpmap:96 G726-32/8000 4366 v=0 4367 c=IN IP4 128.96.41.1 4368 m=audio 1296 RTP/AVP 0 4369 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 4371 Thus the CallId, LocalConnectionOptions, and Mode are as 4372 expected for this connection. The same holds for the 4373 LocalConnectionDescriptor which is supplied as the last 4374 parameter separated by an empty line. The last connec- 4375 tion handling command issued to the endpoint for this 4376 connection did not include the NotifiedEntity parameter, 4377 so the notified entity defaults to the source IP address 4378 for that command which is encoded in RFC 821 format. 4379 Finally, the Call Agent also obtained the current packet 4380 statistics for the call. 4382 Internet draft MGCP Call Flows 20 January 1999 4384 6.2. Using the RestartInProgress command 4386 __________________________________________________________________ 4387 | Management System | TGW | CA-1 | CA-2| 4388 |_________________________|________________________|_______|______| 4389 | | | | | 4390 | Preparing for taking | | | | 4391 | endpoints out of | | | | 4392 | service when idle. | RSIP | -> | | 4393 | | (graceful: indefinite)| | | 4394 | | <- | Ack | | 4395 | | | | | 4396 | Preparing to take | | | | 4397 | endpoints out of | | | | 4398 | service in 5 minutes | RSIP | -> | | 4399 | (graceful: 5 min) | | | | 4400 | | <- | Ack | | 4401 | | | | | 4402 | Circuit failure leads | | | | 4403 | to an endpoint becoming | | | | 4404 | unavailable. | RSIP | -> | | 4405 | (forced: 0 min) | | | | 4406 | | <- | Ack | | 4407 | | | | | 4408 | Courtesy message | | | | 4409 | that all endpoints are | | | | 4410 | now out of service | RSIP | -> | | 4411 | (forced: 0 min) | | | | 4412 | | <- | Ack | | 4413 | | | | | 4414 | All endpoints back | | | | 4415 | in service | RSIP | - - -| -> | 4416 | (restart: 0 min) | | | | 4417 | | <- | - - -| Ack | 4418 | | | | | 4419 |_________________________|________________________|_______|______| 4421 This diagram shows the various exchanges of messages 4422 during restart of some of the endpoints in a trunking 4423 gateway. Our example assumes the existence of an exter- 4424 nal management system controlling the gateway, and the 4425 resulting changes in endpoint availability are then com- 4426 municated to the Call Agent via the RestartInProgress 4427 command. First all endpoints are to be taken out-of- 4428 service gracefully, and later a warning is sent to the 4429 Call Agent, that all endpoints will now be taken out of 4430 service within 5 minutes. Following this, we assume a 4432 Internet draft MGCP Call Flows 20 January 1999 4434 problem occurs on the gateway resulting in the immediate 4435 unavailability of a circuit. A little later, the gateway 4436 then informs the Call Agent that all endpoints are now 4437 out of service. Finally, we assume that the trunking 4438 gateway rebooted and placed all endpoints back in ser- 4439 vice which the gateway informs its default Call Agent 4440 about. 4442 The trunking gateway initially sends a RestartInProgress 4443 command to the Call Agent (CA-1) informing it of an 4444 intention to take all endpoints out of service: 4446 RSIP 1200 *@trgw-7.whatever.net MGCP 0.1 4447 RM: graceful 4448 RD: 0 4450 The Call Agent thereby sees, that the trunking gateway 4451 is planning on making all its endpoints unavailable 4452 gracefully. Since the restart delay is specified to be 4453 zero, the Call Agent furthermore knows, that it can 4454 safely leave all existing connections on the gateway, 4455 however it should not attempt to establish any new con- 4456 nections for these endpoints -- or at least only estab- 4457 lish connections related to existing calls. 4459 The Call Agent immediately acknowledges the command: 4461 200 1200 OK 4463 Later, the external management system decides that it 4464 will no longer wait indefinitely for the existing con- 4465 nections to cease to exist. The gateway therefore sends 4466 a RestartInProgress message to the Call Agent informing 4467 it, that all the endpoints will become unavailable 4468 within 5 minutes (300 seconds), and any connections 4469 existing at that point in time will be torn down: 4471 RSIP 1201 *@trgw-7.whatever.net MGCP 0.1 4472 RM: graceful 4473 RD: 300 4475 The Call Agent immediately acknowledges the command: 4477 200 1201 OK 4479 Internet draft MGCP Call Flows 20 January 1999 4481 The Call Agent now has 5 minutes to tear down any exist- 4482 ing connections. 4484 Before the 5 minutes have elapsed, we imagine a hardware 4485 problem develops with one of the circuits on card23 in 4486 the trunking gateway and that the circuit immediately 4487 must be taken out service. The gateway informs the Call 4488 Agent about this by issuing the RestartInProgress com- 4489 mand as follows: 4491 RSIP 1202 card23/20@trgw-7.whatever.net MGCP 0.1 4492 RM: forced 4494 In this case, no restart delay was specified since a 4495 "forced" restart always takes effect immediately. If a 4496 restart delay had been specified, it would simply have 4497 been ignored. Any connections that existed for the end- 4498 point will have been lost. 4500 The Call Agent immediately acknowledges the command and 4501 notes that card23/20 is out of service: 4503 200 1202 OK 4505 A little later, the 5 minutes grace period the Call 4506 Agent was notified about earlier has now passed, and - 4507 as a courtesy - the trunking gateway informs the Call 4508 Agent that all endpoints have now been taken out of ser- 4509 vice: 4511 RSIP 1203 *@trgw-7.whatever.net MGCP 0.1 4512 RM: forced 4514 Although the Call Agent has already been informed that 4515 card23/20 is out of service, the trunking gateway 4516 includes it in the list of endpoints here anyway. This 4517 is perfectly valid since placing an out-of-service end- 4518 point in out-of-service can be considered idempotent as 4519 long as the gateway deletes all connections associated 4520 with those endpoints (out-of-service endpoints should 4521 not have any connections created on them). However, this 4522 would not be the case with placing in-service endpoints 4523 in-service as such operations have side-effects on 4524 existing connections. In that case, the Call Agent would 4526 Internet draft MGCP Call Flows 20 January 1999 4528 therefore assume, that endpoints already in-service had 4529 been restarted to be in-service again. 4531 The Call Agent immediately acknowledges the command: 4533 200 1203 OK 4535 At this point, all endpoints in the trunking gateway are 4536 now out of service. 4538 We then assume that the trunking gateway is rebooted and 4539 all endpoints are placed back in service. After the 4540 reboot, the trunking gateway informs its default Call 4541 Agent (CA-2), that all its endpoints are now back in 4542 service by sending the following RestartInProgress com- 4543 mand: 4545 RSIP 1204 *@trgw-7.whatever.net MGCP 0.1 4546 RM: restart 4547 RD: 0 4549 Since the restart delay specified is zero, all endpoints 4550 are in-service at this point in time. However, it should 4551 be noted, that this does not necessarily imply that the 4552 same endpoints are available as before. For instance, 4553 card23 could have been removed from the trunking gateway 4554 to correct the aforementioned circuit problem. 4556 The Call Agent (CA-2) recognizes that CA-1 is the pre- 4557 ferred Call Agent for this trunking gateway and when 4558 CA-2 acknowedges the command, it therefore includes CA-1 4559 as the NotifiedEntity. Furthermore, CA-2 notes that any 4560 connections that may have existed for these endpoints 4561 prior to receiving this command no longer exists. CA-2 4562 is expected to communicate this information to CA-1 in 4563 order to achieve the internal Call Agent synchronization 4564 required: 4566 200 1204 OK 4567 N: CA-1@whatever.net 4569 Internet draft MGCP Call Flows 20 January 1999 4571 7. Using MGCP to control an IVR 4573 This section describes the call flows between the CA,MG 4574 and IVR in order to understand the way MGCP organises 4575 the communication between the Media gateway 4576 controller/call agent and the Media gateway or an IVR. 4578 The IVR is controlled by the call agent using only the 4579 existing MGCP primitives. 4581 The number of calls that an IVR can support is defined 4582 as the number of endpoints on that IVR. These end points 4583 may be maintained by the IVR itself in which case the 4584 Call agent always uses wildcards for createconnection or 4585 it may be maintained by the Call agent. There are a 4586 variety of scripts that can be executed on a particular 4587 ivr endpoint.They may be as simple as just playing a 4588 message (in which case the IVR is used as a simple 4589 anouncement server) or playing a message collect digits 4590 and give it to the call agent or as complex as an admin- 4591 istrative script which allows a remote administrator to 4592 configure the call agent . 4594 The format of the script and the implementation of the 4595 script may be vendor specific. 4597 The only assumtion is that the call agent is pre config- 4598 ured with the script names and it knows what script to 4599 use when. 4601 The MGCP primitives are interpreted by the IVR in the 4602 following way 4604 CreateConnection: 4605 When this command is received by the IVR it allo- 4606 cates the resources and returns the RTP profile 4607 associated with the logical endpoint. The connec- 4608 tion mode should always be inactive. Note that the 4609 IVR starts executing the script if the connection 4610 mode is not set to inactive. 4612 ModifyConnection: 4613 This is used by the Call agent to trigger the exe- 4614 cution of the script. Here the connection mode is 4615 set to sendrecv.If it is set to sendonly the IVR 4616 can play message or tones but cannot collect dtmf. 4618 NotificationRequest: 4620 Internet draft MGCP Call Flows 20 January 1999 4622 Notifies the Call agent when the script has fin- 4623 ished executed and returns the result.For now the 4624 result is only in the form of digits. 4626 DeleteConnection: 4627 Stops executing the script if it is not already 4628 terminated and frees the resources. 4630 NOTE : The call flows do not show the Delete connection 4631 on the Incoming side when the IVR terminates. This is 4632 because the incomming call may be routed to another des- 4633 tination by the call agent depending on the notification 4634 results got from the IVR. 4636 7.1. Connecting a Residential Gateway to the IVR 4638 7.1.1. Connection from RGW to IVR 4640 __________________________________________ 4641 | USER | RGW | CA | IVR | 4642 |__________|________|_____________|_______| 4643 | | <-- | RQNT | | 4644 | | ACK | --> | | 4645 | OFF HOOK | NTFY | --> | | 4646 | | <-- | ACK | | 4647 | | <-- | CRCX+RQNT | | 4648 | | ACK | --> | | 4649 | | | CRCX+RQNT | --> | 4650 | | | <-- | ACK | 4651 | | <-- | MDCX | | 4652 | | ACK | --> | | 4653 | | | MDCX | --> | 4654 | | | <-- | ACK | 4655 |__________|________|_____________|_______| 4657 The first command is a NotificationRequest, sent by the 4658 Call Agent to the residential gateway. The request will 4659 consist of the following lines: 4661 RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4662 N: ca@ca1.whatever.net:5678 4663 X: 0123456789AC 4664 R: hd 4666 The gateway immediately acknowledges the command, 4668 Internet draft MGCP Call Flows 20 January 1999 4670 repeating in the acknowledgement message the transaction 4671 id that the Call Agent attached to the query. 4673 200 1201 OK 4675 When the off hook event is noticed the gateway will 4676 notify the event to the Call Agent: 4678 NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4679 N: ca@ca1.whatever.net:5678 4680 X: 0123456789AC 4681 O: hd 4683 The Call Agent immediately acknowledges that notifica- 4684 tion. 4686 200 2002 OK 4688 The Call Agent will then seize the incoming circuit, 4689 creating a connec- tion. The create connection command 4690 piggybacks a notification request, to watch for an on- 4691 hook transition: 4693 CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4694 C: A3C47F21456789F0 4695 L: p:10, a:G.711;G.726-32 4696 M: recvonly 4697 X: D123456789AD 4698 R: hu 4700 The gateway immediately acknowledges the creation, send- 4701 ing back the identification of the newly created connec- 4702 tion and the session descrip- tion used to receive audio 4703 data: 4705 200 1204 OK 4706 I:FDE234C8 4708 v=0 4709 c=IN IP4 128.96.41.1 4710 m=audio 3456 RTP/AVP 0 96 4711 a=rtpmap:96 G726-32/8000 4713 Internet draft MGCP Call Flows 20 January 1999 4715 The Call Agent, having seized the incoming trunk and 4716 deciding that the call has to be terminated on the IVR 4717 and that a script will be executed, sends a connection 4718 command to the IVR. 4720 CRCX 1205 #@ivr45.whatever.net MGCP 0.1 4721 C: A3C47F21456789F0 4722 L: p:10, a:G.711;G.726-32 4723 M: inactive 4725 v=0 4726 c=IN IP4 128.96.41.1 4727 m=audio 3456 RTP/AVP 0 96 4728 a=rtpmap:96 G726-32/8000 4730 The CreateConnection is sent to a generic endpoint, 4731 asking the IVR to pick one of its available ports. 4733 The IVR will acknowledge the connection command, sending 4734 in the identification of the selected endpoint, the con- 4735 nection identifier and the session description its own 4736 parameters such as address, ports and RTP profile: 4738 200 1205 OK 4739 Z:17@ivr45.whatever.net 4740 I:32F345E2 4742 v=0 4743 c=IN IP4 128.96.63.25 4744 m=audio 1296 RTP/AVP 0 96 4745 a=rtpmap:96 G726-32/8000 4747 The Call Agent will relay the information to the Media 4748 gateway, using a ModifyConnection command: 4750 MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4751 C: A3C47F21456789F0 4752 I:FDE234C8 4753 M: sendrecv 4755 v=0 4756 c=IN IP4 128.96.63.25 4757 m=audio 1296 RTP/AVP 0 96 4758 a=rtpmap:96 G726-32/8000 4760 Internet draft MGCP Call Flows 20 January 1999 4762 The media gateway immediately acknowledges the modifica- 4763 tion: 4765 200 1206 OK 4767 At this point the caller is ready, a duplex path has 4768 been established between the caller and the IVR, all the 4769 resources have been allocated and the Call agent has to 4770 trigger the script execution. It does this by sending a 4771 ModificationRequest with an embedded NotificationRequest 4772 command to the IVR. 4774 MDCX 1207 17@ivr45.whatever.net MGCP 0.1 4775 C: A3C47F21456789F0 4776 M: sendrecv 4777 X: D23456789AD 4778 R: Script/oc, Script/of 4779 D: Script/perl(http://database.whatever.net/script-23.prl) 4781 The IVR immediately acknowledges the modification: 4783 200 1207 OK 4785 At this point the caller is interacting with the IVR. 4786 This ends with either the caller going on hook or the 4787 IVR deciding it has to notify the Call agent. 4789 7.1.2. Disconnecting the user from IVR:(termination by 4790 IVR) 4792 ____________________________________ 4793 | USER | RGW | CA | IVR | 4794 |______|_______|__________|_________| 4795 | | | <-- | NTFY | 4796 | | | ACK | --> | 4797 | | | DLCX-- | --> | 4798 | | | <-- | ---ACK| 4799 |______|_______|__________|_________| 4801 When the call agent receives 4803 NTFY 2002 17@ivr45.whatever.net MGCP 0.1 4804 N: ca@ca1.whatever.net:5678 4805 X: D23456789AD 4807 Internet draft MGCP Call Flows 20 January 1999 4809 O: script/oc(54321) 4811 The Call agent immediately acknowledges the notifica- 4812 tion: 4814 200 2002 OK 4816 and send a delete connection to the IVR 4818 DLCX 1211 script23/21@ivr45.whatever.net MGCP 0.1 4819 C: 567F21456789F0 4820 I:32F345E2 4822 the IVR frees up the resources and responds with 4824 200 1211 OK 4825 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 4827 The call agent may now deal with the incoming call by 4828 sending a delete connection, execute another script on 4829 the IVR, or route the call to another gateway, and so 4830 on. 4832 7.1.3. Disconnecting The User From Ivr:(Termination By 4833 Caller) 4835 ___________________________________ 4836 | USER | RGW | CA | IVR | 4837 |_________|_______|________|_______| 4838 | On hook | NTFY| --> | | 4839 | | <-- | ACK | | 4840 | | | DLCX | --> | 4841 | | | <-- | ACK | 4842 | | <-- | DLCX | | 4843 | | ACK | --> | | 4844 |_________|_______|________|_______| 4846 When the call agent receives 4848 NTFY 2056 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4849 N: ca@ca1.whatever.net:5678 4850 X: D123456789AD 4851 O: hu 4853 Internet draft MGCP Call Flows 20 January 1999 4855 it responds with 4857 200 2056 OK 4859 and deletes the connections on both the IVR 4861 DLCX 1211 17@ivr45.whatever.net MGCP 0.1 4862 C: A3C47F21456789F0 4863 I:32F345E2 4865 IVR frees up the resources and responds with 4867 200 1211 OK 4868 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 4870 and the media gateway 4872 DLCX 1261 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4873 C: A3C47F21456789F0 4874 I:FDE234C8 4876 Gateway frees up the resources and responds with 4878 200 1261 OK 4879 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 4881 7.2. Connection between a TGW and an IVR 4883 7.2.1. Setting up the connection from TGW to IVR 4885 The figure below gives the flow for the IVR connected to 4886 a TGW 4888 Internet draft MGCP Call Flows 20 January 1999 4890 ___________________________________________ 4891 | SS7/ISUP | TGW | CA | IVR | 4892 |__________|_______|_______________|_______| 4893 | IAM | --- | --> | | 4894 | | <-- | CRCX | | 4895 | | ACK | --> | | 4896 | <-- | --- | ACM | | 4897 | | | CRCX+RQNT-->| | 4898 | | <-- | ---ACK | | 4899 | | <-- | -MDCX | | 4900 | | ACK | --> | | 4901 | <-- | --- | ANM | | 4902 | | | MDCX | --> | 4903 | | <-- | ----ACK | | 4904 |__________|_______|_______________|_______| 4906 When the CA detects an incoming call it sends a 4907 CreateConnection command to the media gateway. 4909 CRCX 1204 ss7end/1@tgw90.whatever.net MGCP 0.1 4910 C: A3C47F21456789F0 4911 L: p:10, a:G.711;G.726-32 4912 M: recvonly 4914 The media gateway responds with 4916 200 1204 OK 4917 I:FDE234C8 4919 v=0 4920 c=IN IP4 128.96.41.1 4921 m=audio 3456 RTP/AVP 0 96 4922 a=rtpmap:96 G726-32/8000 4924 The CA then creates a connection on the IVR 4926 CRCX 1205 #@ivr45.whatever.net MGCP 0.1 4927 C: A3C47F21456789F0 4928 L: p:10, a:G.711;G.726-32 4929 M: inactive 4931 v=0 4932 c=IN IP4 128.96.41.1 4933 m=audio 3456 RTP/AVP 0 96 4934 a=rtpmap:96 G726-32/8000 4936 Internet draft MGCP Call Flows 20 January 1999 4938 The IVR will acknowledge the connection command, sending 4939 in the session description its own parameters such as 4940 address, ports and RTP profile: 4942 200 1205 OK 4943 Z: 17@ivr45.whatever.net 4944 I:32F345E2 4946 v=0 4947 c=IN IP4 128.96.63.25 4948 m=audio 1296 RTP/AVP 0 96 4949 a=rtpmap:96 G726-32/8000 4951 The Call Agent will relay the information to the Media 4952 gateway, using a ModifyConnection command: 4954 MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 4955 C: A3C47F21456789F0 4956 I:FDE234C8 4957 M: sendrecv 4959 v=0 4960 c=IN IP4 128.96.63.25 4961 m=audio 1296 RTP/AVP 0 96 4962 a=rtpmap:96 G726-32/8000 4964 The media gateway immediately acknowledges the modifica- 4965 tion: 4967 200 1206 OK 4969 At this point the caller is ready,a duplex path has been 4970 established between the caller and the IVR ,all the 4971 resources have been allocated and the Call agent has to 4972 trigger the script execution. It does this by sending a 4973 ModifyConnection command to the IVR, with an embedded 4974 notification request. 4976 MDCX 1206 17@ivr45.whatever.net MGCP 0.1 4977 C: A3C47F21456789F0 4978 I:32F345E2 4979 X: D23456789AD 4980 M: sendrecv 4981 R: Script/oc, Script/of 4982 D: Script/perl(http://database.whatever.net/script-12.prl) 4984 Internet draft MGCP Call Flows 20 January 1999 4986 The IVR immediately acknowledges the modification: 4988 200 1206 OK 4990 At this point the caller is interacting with the 4991 IVR.This ends with either the caller going on hook or 4992 the IVR deciding it has to notify the Call agent. 4994 7.2.2. Disconnecting The User From IVR:TGW 4996 Termination by the IVR: 4998 ________________________________________ 4999 | SS7/ISUP | TGW | CA | IVR | 5000 |__________|_______|__________|_________| 5001 | | | <-- | --NTFY| 5002 | | | ACK-- | --> | 5003 | | | DLCX-- | --> | 5004 | | | <-- | ---ACK| 5005 |__________|_______|__________|_________| 5007 7.2.3. Termination by the Caller 5009 ______________________________________________________ 5010 | SS7/ISUP | TGW | CA | IVR | 5011 | REL | --- | --> | | 5012 | | | | | 5013 | | | DLCX | --> | 5014 | | | <-- | ACK | 5015 | | <-- | -DLCX | | 5016 | | ACK | --> | | 5017 | <-- | --- | RLC | | 5018 |__________|_______|__________________________|_______| 5020 Internet draft MGCP Call Flows 20 January 1999 5022 7.3. Hairpin IVR connection, double end-point model 5024 The figure below gives the flow that results in an hair- 5025 pin connection to an IVR device located on the same 5026 gateway as the trunk on which the call is incoming. In 5027 this flow, we assume that we use the "double endpoint" 5028 extensions to the create-connection command, and, as an 5029 example, assume that the IVR exchange results in an 5030 automatic disconnection. 5032 _________________________________________ 5033 | sw1| sw2| SG | CA | TGW-1| IVR | 5034 |____|_____|_____|_______|_______|_______| 5035 | IAM| - -| -> | | | | 5036 | | | IAM| -> | | | 5037 | | | | CRCX+| -> | (->) | 5038 | | | | RQNT | -> | (->) | 5039 | | | | <- | ACK | (ACK)| 5040 | | | <-| ANM | | | 5041 | <-| - -| ANM| | | | 5042 | | | | <- | - - | NTFY | 5043 | | | | ACK | - - | -> | 5044 | | | | DLCX | -> | | 5045 | | | | <- | Perf | | 5046 | | | | | data | | 5047 | | | <-| REL | | | 5048 | <-| - -| REL| | | | 5049 | | | | DLCX | | -> | 5050 | | | | <- | - - | Perf | 5051 | | | | | | data | 5052 |____|_____|_____|_______|_______|_______| 5054 During these exchanges the MGCP is used by the Call 5055 Agent to control two endpoints located on the same TGW. 5057 The exchanges start with the arrival from the first 5058 switch (SW1) of an SS7/ISUP "IAM" message, relayed by 5059 the signalling gateway to the Call Agent. The call 5060 agent performs the routing, and determines that the call 5061 will have to be relayed towards the second switch (SW2), 5062 using a trunk located on the same gateway. 5064 The call agent starts the exchange by seizing the end- 5065 point referenced in the IAM message, and by requesting a 5066 local connection between that endpoint and the IVR dev- 5067 ice. The command also instruct the IVR to start execut- 5068 ing a script on the selected IVR endpoint: 5070 Internet draft MGCP Call Flows 20 January 1999 5072 CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 5073 C: A3C47F21456789F0 5074 L: nt=LOCAL 5075 M: sendrecv 5076 2/E: IVR/$ 5077 2/X: D23456789AD 5078 2/R: Script/oc, Script/of 5079 2/D: Script/perl(http://database.whatever.net/script-12.prl) 5081 Upon reception of that command, the trunking gateway 5082 prepares a "local" connection description between the 5083 specified endpoint (trunk-group-1/17) and an endpoint 5084 that it selects within the IVR (IVR/6). The gateway 5085 acknowledges the two creations in a single message: 5087 200 1204 OK 5088 I:FDE234C8 5090 v=0 5091 c=IN tgw.whatever.net trunk-group-1/17 5092 m=audio 0 LOCAL 0 5093 2/Z:IVR/13@tgw.whatever.net 5094 2/I:abc0 5095 2/ 5096 v=0 5097 c=IN tgw.whatever.net IVR/13 5098 m=audio 0 LOCAL 0 5100 The command has created a path between the endpoint and 5101 the IVR. Because the IVR is in fact answering the call, 5102 the call agent can immediately relay an ANM message to 5103 the calling switch. 5105 At this point the caller is interacting with the IVR. 5106 This ends with either the caller going on hook or the 5107 IVR deciding it has to notify the Call agent. 5109 NTFY 2001 IVR/13@tgw.whatever.net MGCP 0.1 5110 X: D23456789AD 5111 O: Script/oc(123245) 5113 The call agent immediately acknowledges the notifica- 5114 tion: 5116 200 2001 OK 5118 Internet draft MGCP Call Flows 20 January 1999 5120 The call agent should then remove the connections. The 5121 call agent releases the connection on the first end- 5122 point: 5124 DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 5125 C: A3C47F21456789F0 5126 I:FDE234C8 5128 The gateway acknowledges the deletion, sending the con- 5129 nection parameters: 5131 250 1217 OK 5132 P: OS=62345, OR=62345 5134 The call agent can now notify the release of the trunk 5135 to the switch which will in response send an RLC mes- 5136 sage. 5138 In parallel, the call agent releases the connection to 5139 the IVR: 5141 DLCX 1208 IVR/13@tgw.whatever.net MGCP 0.1 5142 C: A3C47F21456789F0 5143 I:abc0 5145 The gateway acknowledges the deletion, sending the con- 5146 nection parameters: 5148 250 1218 OK 5149 P: OS=62345, OR=62345 5151 Internet draft MGCP Call Flows 20 January 1999 5153 8. Acknowledgements 5155 We want to thank here the many reviewers who helped 5156 design the MGCP flows, notably Ike Elliott and Chip 5157 Sharp. 5159 9. References 5161 [0] Arango, M., A. Dugan, I. Elliott, C. Huitema, S. 5162 Pickett, "Media Gateway Control Protocol (MGCP)", 5163 work in progress. 5165 [1] ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIP- 5166 TION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 5167 7", (Malaga-Torremolinos, 1984; modified at Hel- 5168 sinki, 1993) 5170 [2] ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF 5171 MESSAGES AND SIGNALS OF THE ISDN USER PART OF SIG- 5172 NALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; 5173 modified at Helsinki, 1993) 5175 * ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYS- 5176 TEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH 5177 PROVIDE A NON-GUARANTEED QUALITY OF SERVICE." 5179 * ITU-T, Recommendation H.225, "Call Signaling Proto- 5180 cols and Media Stream Packetization for Packet 5181 Based Multimedia Communications Systems." 5183 * ITU-T, Recommendation H.245, "LINE TRANSMISSION OF 5184 NON-TELEPHONE SIGNALS." 5186 * Handley, Shulzrinne, Schooler, Rosenberg, "SIP: 5187 Session Initiation Protocol", work in progress 5189 10. Authors' Addresses 5191 Christian Huitema 5192 Bellcore 5193 MCC 1J236B 5194 445 South Street 5195 Morristown, NJ 07960 5196 U.S.A. 5198 Phone: +1 973-829-4266 5199 EMail: huitema@bellcore.com 5201 Internet draft MGCP Call Flows 20 January 1999 5203 Flemming Andreasen 5204 Bellcore 5205 RRC-1M223 5206 444 Hoes Lane 5207 Piscataway, NJ 08854-4157 5208 U.S.A. 5210 Phone: +1 732 699-7351 5211 EMail: fandreas@notes.cc.bellcore.com 5213 Mauricio Arango 5214 RSL COM Latin America 5215 6300 N.W. 5th Way, Suite 100 5216 Ft. Lauderdale, FL 33309 5218 Phone: (954) 492-0913 5219 Email: marango@rslcom.com 5221 Prakash K 5222 TELESOFT INC 5223 3000, Custer Road 5224 Suite 270 5225 Plano, Texas - 75075 5226 U.S.A 5228 Tel: 972-596-4158 5229 Fax: 817-323-1605 5230 EMail: prakashk@indts.com