Internet Engineering Task Force Christian Huitema INTERNET DRAFT Flemming Andreasen Bellcore January 20, 1999 Mauricio Arango Expires: June 18, 1999 RSL COM Prakash K TELESOFT INC Media Gateway Control Protocol (MGCP) Call Flows Christian Huitema, Flemming Andreasen, Mauricio Arango, Prakash K Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Media Gateway Control Protocol (MGCP) organizes the communication between a Media Gateway controller, or call agent, and a Media Gateway, e.g. a Voice over IP gateway or a Network Access Server. MGCP is defined in a companion document [1]. This document provides example of MGCP usage by providing a variety of call flows, in the case of telephony and network access servers. Huitema, Andreasen, Arango, Prakash [Page 1] Internet draft MGCP Call Flows 20 January 1999 Table of Contents Page 1. Introduction .............................................. 2 2. Internet Telephony Call Flows. ............................ 2 3. Interaction between an MGCP gateway and an H.323 entity ... 2 4. Interworking between SIP and MGCP ......................... 2 5. Data calls ................................................ 2 6. Audit and Restart ......................................... 2 7. Using MGCP to control an IVR .............................. 2 8. Acknowledgements .......................................... 2 9. References ................................................ 2 10. Authors' Addresses ....................................... 2 Huitema, Andreasen, Arango, Prakash [Page 2] Internet draft MGCP Call Flows 20 January 1999 1. Introduction In order to understand the way the MGCP interface will be used, we have described here several possible call flows between a TGW, which is a trunking gateway that implements MGCP, and an RGW, which is a residen- tial gateway that implements MGCP, as well as several call flows describing how MGCP could be used to control a network access service. For each of these call flows it is assumed that the default event pack- ages are as follows: TGW Trunk package RGW Line package NAS Network Access Server package The diagrams also show a Common Database (CDB) that can be queried for authorization and routing information, and an Accounting Gateway (ACC) that collects accounting information at the start and the end of calls. These diagrams are solely meant to exhibit the behavior of the MGCP, and to help understanding this protocol. They are not meant as a tutorial on the implementation of a Call Agent. They may very well include miscel- laneous errors and imprecisions. Huitema, Andreasen, Arango, Prakash [Page 3] Internet draft MGCP Call Flows 20 January 1999 2. Internet Telephony Call Flows. We present seven Internet Telephony call flows: * A basic call between two "trunking gateways", * A basic call from a "residential gateway" to a "trunking gateway", * A basic call from a "trunking gateway" to a "residential gateway". * A basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW. * A basic call from an ISDN trunk in a business gateway to an SS7 trunk in a TGW. * A basic call with continuity test, from a "trunking gateway" to a "residential gateway". * A "hairpin" connection between two endpoints on a trunking gateway, using regular call set-up procedures. * A "hairpin" connection between two endpoints on a residential gate- way, using accelerated procedures. Huitema, Andreasen, Arango, Prakash [Page 4] Internet draft MGCP Call Flows 20 January 1999 2.1. Connection from a TGW to another TGW The figure below gives the flow that results in a connection between two trunking gateways. ______________________________________ | sw1| SG1| TGW1| CA | TGW2| SG2| |____|_____|______|______|______|_____| | IAM| -> | | | | | | | IAM| - - | -> | | | | | | <- | CRCX| | | | | | ACK | -> | | | | | | | CRCX| -> | | | | | | <-| ACK | | | | | | IAM | - - | -> | | | | | | | IAM| | | | | | | <-| | | | | <-| - - | ACM| | | | <- | ACM | | | | <-| - -| ACM | | | | | | ...| | | | | | | | | | | <-| | | | | <-| - - | ACM| | | | <- | MDCX| | | | | | ACK | -> | | | | | <-| - - | ANM | | | | <-| ANM| | | | | | REL| -> | | | | | | | REL| - - | -> | | | | | | <- | DLCX| | | | | | Perf| -> | | | | | | data| | | | | | <-| - - | RLC | | | | <-| RLC| | | | | | | | | DLCX| -> | | | | | | <-| Perf| | | | | | | data| | | | | | REL | - - | -> | | | | | | | REL| | | | | | | <-| | | | | <-| - - | RLC| |____|_____|______|______|______|_____| During these exchanges the MGCP is used by the Call Agent to control the two endpoints located on the two TGW. The exchanges start with the arrival from the first switch (SW1) of an Huitema, Andreasen, Arango, Prakash [Page 5] Internet draft MGCP Call Flows 20 January 1999 SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call Agent. The call agent performs the routing, and determines that the call will have to be relayed towards the second switch (SW2), using a trunk located on TGW2. The call agent starts the exchange by seizing the endpoint referenced in the IAM message: CRCX 1204 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711 M: recvonly Upon reception of that command, the trunking gateway prepares a connec- tion description. 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 The call agent, upon reception of this acknowledgement, sends a connec- tion request to the trunking gateway, asking the gateway to reserve a trunk in the group connected to the second switch: CRCX 1205 trunk-group-2/$@tgw2.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: sendrecv v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 The call agent selects a trunk in the group, and acknowledges the crea- tion: 200 1204 OK I:abc0 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 Huitema, Andreasen, Arango, Prakash [Page 6] Internet draft MGCP Call Flows 20 January 1999 The two commands have created a one way path, suitable for forwarding ring tones and announcements to the calling party. The call agent can now relay the call by sending an IAM message to the second switch. When the ACM is received, it is immediately relayed to the first switch. After some time, the call is answered, and an ANM message is relayed from the second switch to the call agent. The call agent will first validate the call by asking the first end-point to place the connection in duplex mode: MDCX 1206 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 The trunking gateway executes and acknowledges the modification: 200 1206 OK The call agent can now relay the ANM message to the calling switch, and both parties can talk. At the end of the call, in our example, the calling party hangs up. The first switch sends a release message to the call agent, through the signalling gateway. The call agent releases the connection on the first endpoint: DLCX 1207 trunk-group-1/17@tgw1.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 The gateway acknowledges the deletion, sending the connection parameters: 250 1217 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 The call agent can now confirm the release of the trunk, sending an RLC message to the first switch. In parallel, the call agent releases the connection to the second endpoint: Huitema, Andreasen, Arango, Prakash [Page 7] Internet draft MGCP Call Flows 20 January 1999 DLCX 1208 trunk-group-2/13@tgw2.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:abc0 The gateway acknowledges the deletion, sending the connection parameters: 250 1218 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48 After receiving the acknowledgement, the call agent can relay the release message to the second switch. The switch will in turn acknowledge the release. Huitema, Andreasen, Arango, Prakash [Page 8] Internet draft MGCP Call Flows 20 January 1999 2.2. Basic call, RGW to TGW ______________________________________________________________________ | Usr | RGW | CA | CDB| ACC| TGW | SS7/| CO | | | | | | | | ISUP| | |_______|__________|______________|_____|_____|__________|______|_____| | | <- | RQNT | | | | | | | | Ack | -> | | | | | | | Off | | | | | | | | | -hook | (local | | | | | | | | (Dial | action) | | | | | | | | -tone)| | | | | | | | | Digits| Notify | -> | | | | | | | | <- | Ack | | | | | | | (pro- | <- | CRCX+RQNT | | | | | | | gress)| Ack | -> | | | | | | | | | Query | | | | | | | | | (E.164 S,D) | -> | | | | | | | | <- | IP | | | | | | | | CRCX | - -| - -| -> | | | | | | | | | (cut in)| | | | | | <- | - -| - -| ack | | | | | | IAM | - -| - -| - - | -> | | | | <- | MDCX | | | | IAM | -> | | | Ack | -> | | | | <- | ACM| | | | <- | - -| - -| - - | ACM | | | | <- | Notification| | | | | | | | | Request | | | | | | | | Ack | -> | | | | | | | | | | | | | <- | ANM| | | | <- | - -| - -| - - | ANM | | | | <- | MDCX+RQNT | | | | | | | | Ack | -> | | | | | | | | (cut in)| Call start | - -| -> | | | | |_______|__________|______________|_____|_____|__________|______|_____| Huitema, Andreasen, Arango, Prakash [Page 9] Internet draft MGCP Call Flows 20 January 1999 __________________________________________________________________ | Usr | RGW | CA | CDB| ACC| TGW | SS7/| CO | | | | | | | | ISUP| | |________|________|______________|_____|_____|_______|______|_____| | | | | | | | <- | REL| | | | <- | - -| - -| - - | REL | | | | <- | Delete | | | | | | | | | Connection | | | | | | | | | Delete | | | | | | | | | Connection | - -| - -| -> | | | | | Perf | | | | | | | | | Data | -> | | | | | | | | | <- | - -| - -| perf | | | | | | | | | data | | | | | | Call end | - -| -> | | | | | On-hook| Notify| -> | | | | | | | | <- | Ack | | | | | | | | <- | Notification| | | | | | | | | Request | | | | | | | | Ack | -> | | | | | | |________|________|______________|_____|_____|_______|______|_____| During these exchanges the MGCP is used by the Call Agent to control both the TGW and the residential gateway. The exchanges occur on two sides. The first command is a NotificationRequest, sent by the Call Agent to the residential gateway. The request will consist of the following lines: RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: hd(E(dl;hu, D/[0-9#*T](D);) D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) S: That transaction illustrates the power of the "embedded" action. The gateway is instructed to look for an off-hook event, and, upon its detection, to provide a dial-tone and to start looking for DTMF digits. The gateway immediately acknowledges the com- mand, repeating in the acknowledgement message the transaction id that the Call Agent attached to the query. 200 1201 OK Huitema, Andreasen, Arango, Prakash [Page 10] Internet draft MGCP Call Flows 20 January 1999 When the off hook event is noticed, the gateway provides the dial tone to the line (the delay between off-hook and dialtone is thus minimal.) The gateway will start accumulating digits according to that digit map. When it has noticed a sufficient set of values, it will notify the observed string to the Call Agent: NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: 912018294266 The Call Agent immediately acknowledges that notification. 200 2002 OK The Call Agent will then seize the incoming circuit, creating a connection. The create connection commands piggybacks a notifi- cation request, to stop collecting digits yet continue watch for an on-hook transition: CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly X: D/0123456789AD R: hu S: We should note at this point that the call agent could send the acknowledgement of the Notify and the CRCX in a single UDP packet, as explained in the "piggy backing" section of [1]. There are many possible groupings of that nature in the various examples. The gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the ses- sion description used to receive audio data: 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 Huitema, Andreasen, Arango, Prakash [Page 11] Internet draft MGCP Call Flows 20 January 1999 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), the transport protocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio profile refers to RFC 1890, which defines that the payload type 0 has been assigned for G.711 transmission. The gateway is also ready to use ADPCM encoding at 32 kbps (G.726 -4). There is no standard payload type associated to ADPCM, so the gateway mentions its readiness to use a non standard payload associated to the dynamic type 96. The "rtpmap" attribute entry associates the payload type 96 to G726-32/4. The Call Agent, having seized the incoming trunk and completed a routing look up to identify the outgoing gateway, must now seize the outgoing trunk. It does so by sending a connection command to the e-gress gateway: CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: sendrecv v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The CreateConnection command has the same parameters as the com- mand sent to the ingress gateway, with two differences: * The EndpointId points towards the outgoing trunk, * The message carries the session description returned by the ingress gateway, * Because the session description is present, the "mode" parameter is set to "send/receive". We observe that the call identifier is identical for the two connections. This is normal: the two connections belong to the same call, which has a global identifier in our system. The trunking gateway will acknowledge the connection command, sending in the session description its own parameters such as Huitema, Andreasen, Arango, Prakash [Page 12] Internet draft MGCP Call Flows 20 January 1999 address, ports and RTP profile: 200 1205 OK I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent will relay the information to the ingress gate- way, using a ModifyConnection command: MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: recvonly v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The residential gateway immediately acknowledges the modifica- tion: 200 1206 OK At this stage, the Call Agent has established a half duplex transmission path. The phone attached to the residential gateway will be able to receive the signals, such as tones or announce- ments, that the remote switch may send through the trunking gateway. When the call progresses, the Call Agent will receive from the remote switch progress messages, for example an "address com- plete" message (ACM). The Call Agent will analyze the message to determine whether signal are transmitted in band. If this is not the case, the Call Agent will instruct the RGW to generate ring- ing tones by sending a NotificationRequest: RQNT 1207 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AE R: hu S: v Huitema, Andreasen, Arango, Prakash [Page 13] Internet draft MGCP Call Flows 20 January 1999 The gateway immediately acknowledges the command: 200 1207 OK After the called user answers the call, the Call Agent will receive an answering message (ANM) from the CO switch. At that point, it will send a ModifyConnection command, to the residen- tial gateway, to place the connection in full duplex mode. The command embeds NotificationRequest to stop the ringing tones. MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv X: 0123456789AF R: hu S: The residential gateway will acknowledge this command: 200 1209 OK At this point, the connection is established. When the Call Agent receives the REL message from the CO switch, it will have to tear down the call. It will do so by sending to both gateways a DeleteConnection command: DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 The gateways will respond with acknowledgements that should include a "call parameters" header fields: 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,LA=48 Huitema, Andreasen, Arango, Prakash [Page 14] Internet draft MGCP Call Flows 20 January 1999 At this point, the phone attached to the residential gateway, in our scenario, goes on-hook. This event is notified to the Call Agent, according to the policy received in the last Notifica- tionRequest by sending a Notify command: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AF O: hu After this notification, the Call Agent should send an ack- nowledgement: 200 2005 OK It should then issue a new NotificationRequest, to be ready to receive the next off-hook detected by the residential gateway: RQNT 1212 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B0 R: hd(E(dl;hu, [0-9#*T](D);) D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) S: The gateway will acknowledge this message: 200 1212 OK Both gateways, at this point, are ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 15] Internet draft MGCP Call Flows 20 January 1999 2.3. Basic call, TGW to RGW ___________________________________________________________________ | CO | SS7/| TGW | CA | CDB| ACC| RGW | Usr | | | ISUP| | | | | | | |____|______|__________|_______________|_____|_____|________|______| | IAM| -> | | | | | | | | | IAM | - - | -> | | | | | | | | | Check | -> | | | | | | | | <- | IP | | | | | | | <- | Create | | | | | | | | | Connection | | | | | | | | Ack | -> | | | | | | | | | Create | | | | | | | | | Connection | - -| - -| -> | | | | | | <- | - -| - -| Ack | | | | | <- | Modify | | | | | | | | | Connection | | | | | | | | Ack | -> | | | | | | | | | Notification | | | | | | | | | Request | - -| - -| -> | ring| | | | | <- | - -| - -| Ack | | | | <- | - - | ACM | | | | | | <- | ACM | | | | | | | | | | | | | | | off | | | | | | | | | hook| | | | | <- | - -| - -| Notify| | | | | | Ack | - -| - -| -> | | | | | | Notification | | | | | | | | | Request | - -| - -| -> | | | | | | <- | - -| - -| Ack | | | | | <- | Modify | | | | | | | | | Connection | | | | | | | | Ack | -> | | | | | | | | (cut-in)| Call start | - -| -> | | | | | <- | - - | ANM | | | | | | <- | ANM | | | | | | | |____|______|__________|_______________|_____|_____|________|______| Huitema, Andreasen, Arango, Prakash [Page 16] Internet draft MGCP Call Flows 20 January 1999 _____________________________________________________________ | CO| SS7/| TGW | CA | CDB| ACC| RGW | Usr | | | ISUP| | | | | | | |___|______|______|______________|_____|_____|________|______| | | | | | | | | on | | | | | | | | | hook| | | | | <- | - -| - -| Notify| | | | | | Ack | - -| - -| -> | | | | | | Delete | | | | | | | | | Connection | - -| - -| -> | | | | | <- | Delete | | | | | | | | | Connection | | | | | | | <- | - - | REL | | | | | | <-| REL | | | | | | | | | | Perf| | | | | | | | | data| -> | | | | | | | | | <- | - -| - -| perf | | | | | | | | | data | | | | | | Call end | - -| -> | | | | | | | Notification| | | | | | | | | Request | - -| - -| -> | | | | | | <- | - -| - -| Ack | | |___|______|______|______________|_____|_____|________|______| This diagram shows the various exchange of messages during a call from a telephone user on the circuit-switched PSTN to a residential user connected to a residential gateway. During these exchanges the Call Agent uses MGCP to control both the TGW and the residential gateway. The exchanges occur on two sides. Upon reception of the IAM message, the Call Agent immediately sends a CreateConnection request to the trunking gateway to con- nect to the incoming trunk, creating a connection: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly The trunking gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the session description used to receive audio data: 200 1237 OK Huitema, Andreasen, Arango, Prakash [Page 17] Internet draft MGCP Call Flows 20 January 1999 I: FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), the transport protocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio profile refers to RFC 1890, which defines that the payload type 0 has been assigned for G.711 transmission. The gateway is also ready to use ADPCM encoding at 32 kbps (G.726 -4). There is no standard payload type associated to ADPCM, so the gateway mentions its readiness to use a non standard payload associated to the dynamic type 96. The "rtpmap" attribute entry associates the payload type 96 to G726/4. The Call Agent, having seized the incoming trunk, must now reserve the outgoing circuit. It does so by sending a connection command to the residential gateway: CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: sendrecv v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The CreateConnection command has the same parameters as the com- mand sent to the ingress gateway, with two differences: * The EndpointId points towards the outgoing trunk, * The message carries the session description returned by the ingress gateway, * Because the session description is present, the "mode" parameter is set to "send/receive". We observe that the call identifier is identical for the two connections. This is normal: the two connection belong to the Huitema, Andreasen, Arango, Prakash [Page 18] Internet draft MGCP Call Flows 20 January 1999 same call, which has a global identifier in our system. The residential gateway will acknowledge the connection command, sending in the session description its own parameters such as address, ports and RTP profile: 200 1238 OK I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent will relay the information to the ingress gate- way, using a ModifyConnection command: MDCX 1239 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: recvonly v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The trunking gateway immediately acknowledges the modification: 200 1239 OK At this stage, the Call Agent has established a half-duplex transmission path. The Call Agent must now tells the residential gateway to ring the called line. It will send a NotificationRe- quest, consisting of the following lines: RQNT 1240 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 R: hd S: rg The residential gateway, at that point, is instructed to look for an off-hook event, and to report it. It will first Huitema, Andreasen, Arango, Prakash [Page 19] Internet draft MGCP Call Flows 20 January 1999 acknowledge the command, repeating in the acknowledgement mes- sage the transaction id that the Call Agent attached to the query. 200 1240 OK Upon reception of this message, the Call Agent sends an address complete message (ACM) to the calling switch, which we assume will generate ringing tones for the calling user. When the gateway notices the off hook event, it sends a Notify command to the Call Agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B0 O: hd The Call Agent immediately acknowledges that notification. 200 2001 OK The Call Agent now asks the residential gateway to send a Notify command on the occurrence of an on-hook event. It does so by sending a NotificationRequest to the residential gateway: RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 R: hu The gateway acknowledges that command: 200 1241 OK In parallel, the Call Agent will send a ModifyConnection command to the trunking gateway, to place the connection in full duplex mode: MDCX 1242 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv Huitema, Andreasen, Arango, Prakash [Page 20] Internet draft MGCP Call Flows 20 January 1999 The trunking gateway will acknowledge that command: 200 1242 OK The Call Agent can now send an answer message (ANM) to the cal- ling switch. After some time, the Call Agent will have to tear down the call. In our example, this is triggered by the residential user, who hangs up. The Notify command is sent to the Call Agent: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 O: hu The Call Agent acknowledges the notification. 200 2005 OK It will then send to both gateways a DeleteConnection command: DLCX 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 The gateways will respond with a message that should include a "call parameters" header fields: 250 1243 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 250 1244 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48 The Call Agent should now issue a new NotificationRequest to the residential gateway to detect the next off-hook event: Huitema, Andreasen, Arango, Prakash [Page 21] Internet draft MGCP Call Flows 20 January 1999 RQNT 1245 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B2 R: hd The residential gateway will acknowledge this command: 200 1245 OK Both gateways, at this point, are ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 22] Internet draft MGCP Call Flows 20 January 1999 2.4. Basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW ________________________________________________________________ | CO | R2 | CA | TGW | SS7/| CO | | | TGW | | | ISUP| | |________|___________|_______________|___________|_______|______| | | <- | NTRQ | | | | | | Ack | -> | | | | | Trunk | | | | | | | seizure| | | | | | | & | | | | | | | Called | | | | | | | &callng| | | | | | | number | | | | | | | digit | | | | | | | collec-| | | | | | | tion | -> | | | | | | | Notify | -> | | | | | | <- | Ack | | | | | | <- | Notification| | | | | | | Request | | | | | | Ack | -> | | | | | | <- | Create | | | | | | | Connection | | | | | | Ack | -> | | | | | | | Create | | | | | | | Connection | -> | | | | | | | (cut in)| | | | | | <- | ack | | | | | | IAM | - - | -> | | | | <- | Modify | | IAM | -> | | | | Connection | | | | | | Ack | -> | | <- | ACM| | | | <- | - - | ACM | | | | | | | <- | ANM| | | | <- | - - | ANM | | | | <- | Modify | | | | | | | Connection | | | | | | Ack | -> | | | | | | (cut in)| | | | | |________|___________|_______________|___________|_______|______| Huitema, Andreasen, Arango, Prakash [Page 23] Internet draft MGCP Call Flows 20 January 1999 _____________________________________________________________ | CO | R2 | CA | TGW | SS7/| CO | | | TGW | | | ISUP| | |_________|__________|_______________|________|_______|______| | | | | | <- | REL| | | | <- | - - | REL | | | | | Delete | | | | | | <- | Connection | | | | | | Clear- | | | | | | <- | back | Delete | | | | | Clear- | | Connection | -> | | | | fwd | -> | | | | | | | Rel- | | | | | | <- | guard | | | | | | | Perf | | | | | | | Data | -> | | | | | | | <- | Perf | | | | | | | data | | | | | <- | Notification| | | | | | | Request | | | | | | Ack | -> | | | | |_________|__________|_______________|________|_______|______| The above diagram describes the call flow between a trunk with R2 signaling in a trunking gateway and an SS7 trunk in a trunk- ing gateway. R2 is a type of Channel Associated Signaling (CAS) and this call flow assumes the use of an R2 package. The follow- ing diagram describes a simplified R2 package. In this package digit arrival events are not observed by the Call Agent and therefore cannot be part of a NotificationRequest. The first event that the Call Agent can observe in an R2 trunk is a "call-in" event which is a combination of the arrival at the gateway of a trunk seizure signal and collection of the called (destination) and calling (source) and calling party numbers from the R2 registers. The notification for a call-in event occurs when digit collection is completed. The clear forward event indicates that the exchange at the other side released the trunk. ______________________________________________________________ Symbol Definition R S Duration ______________________________________________________________ ci Call in x cf Clear forward x dn Destination number sn Source number ______________________________________________________________ Huitema, Andreasen, Arango, Prakash [Page 24] Internet draft MGCP Call Flows 20 January 1999 | | | | | The first command is a NotificationRequest, sent by the Call Agent to the R2 trunking gateway. The request will consist of the following lines: RQNT 1201 trunk-group-1/*@r2tgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB R: ci The gateway, at that point, is instructed to look for a call-in event in any of the trunks corresponding to a trunk group named trunk-group-1. The gateway responds with the acknowledgement message: 200 1201 OK When the call-in event is detected, the gateway sends a Notify to the Call Agent: NTFY 2001 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB O: ci, dn(5313456789), sn(5845430978) This notification indicates the occurrence of a call-in event in trunk #5 in trunk-group-1. It also contains the collected desti- nation (dn) and source (sn) party numbers. The Call Agent immediately acknowledges that notification. 200 2001 OK At this stage, the Call Agent sends a NotificationRequest to wait for a trunk release signal: RQNT 1203 trunk-group- 1/5@r2tgw-2567.whatever.net MGCP 0.1 X: 0123456789AD R: cf The Call Agent immediately acknowledges that command. 200 1203 OK The Call Agent will then seize the incoming circuit, creating a connec- tion: CRCX 1204 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly Huitema, Andreasen, Arango, Prakash [Page 25] Internet draft MGCP Call Flows 20 January 1999 The gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the ses- sion description used to receive audio data: 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent, having seized the incoming trunk and completed a routing look up to identify the outgoing gateway, seizes the outgoing trunk. It does so by sending a connection command to the egress gate- way: CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: sendrecv v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SS7 trunking gateway acknowledges the connection command, sending in the session description its own parameters such as address, ports and RTP profile: 200 1205 OK I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1297 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent relays the information to the ingress gateway, using a ModifyConnection command: MDCX 1206 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: recvonly Huitema, Andreasen, Arango, Prakash [Page 26] Internet draft MGCP Call Flows 20 January 1999 v=0 c=IN IP4 128.96.63.25 m=audio 1297 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The R2 trunking gateway immediately acknowledges the modifica- tion: 200 1206 OK At this stage, the Call Agent has established a half duplex transmission path. The subscriber that originated the call will be able to receive signals, such as tones or announcements, that the remote switch may send through the trunking gateways. After the called user answers the call, the Call Agent will receive an answering message (ANM) from the CO switch. At that point, it sends a ModifyConnection command, to place the connec- tion in full-duplex mode: MDCX 1209 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv The R2 trunking gateway acknowledges the modify command: 200 1209 OK At this point, the connection is established. When the Call Agent receives the REL message from the CO switch, it will have to tear down the call. It will do so by sending to both gateways a DeleteConnection command: DLCX 1210 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 The gateways will respond with acknowledgements that should include a "call parameters" header fields: 250 1210 OK Huitema, Andreasen, Arango, Prakash [Page 27] Internet draft MGCP Call Flows 20 January 1999 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48 Finally, the Call Agent issues a new NotificationRequest, to be ready to receive the next call-in event detected by the trunking gateway at the specified trunk: RQNT 1212 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1 X: 0123456789B0 R: hd The gateway will acknowledge this message: 200 1212 OK Both gateways, at this point, are ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 28] Internet draft MGCP Call Flows 20 January 1999 2.5. Basic call, from an ISDN gateway to an SS7/TGW _________________________________________________________________________ | PBX | Business | CA | TGW | SS7/| CO | | | GW | | | ISUP| | |_______|____________|___________________|___________|_______|___________| | SETUP | -> | -> | | | | | <- | <- | CALLPROC. | | | | | | <- | CRCX | | | | | | Ack | -> | | | | | | | CRCX | -> | | | | | | | (cut in)| | | | | | <- | ack | | | | | | IAM | -> | | | | | <- | MDCX | | IAM | -> | | | Ack | -> | | <- | ACM | | | | <- | - - | ACM | | | <- | <- | ALERT | | | | | | <- | RQNT | | | | | | Ack | -> | | | | | <- | Ringing | | | | | | | | | | <- | ANM | | | | <- | - - | ANM | | | | <- | RQNT+MDCX | | | | | | Ack | -> | | | | | | | | | <- | REL | | | | <- | - - | REL | | | | <- | DLCX | | | | | | | DLCX | -> | | | | | Perf | | | | | | | Data | -> | | | | | | | <- | Perf | | | | | | | data | | | | | | RLC | - - | -> | -> | | <- | <- | RLSE | | | | | RLCOM | -> | -> | | | | |_______|____________|___________________|___________|_______|___________| The above diagram describes the call flow between a trunk with ISDN signaling in a business gateway and an SS7 trunk in a trunking gateway. This call flow assumes that the ISDN Q.931 signaling messages are "back-hauled" to the call agent. The tunnelling protocol, together with configuration tables, allows the call agent to associate the signalling messages to the endpoint corresponding Huitema, Andreasen, Arango, Prakash [Page 29] Internet draft MGCP Call Flows 20 January 1999 to the B-channel. The specifics of the tunnelling protocol are being worked on by the IETF. The call is triggered by the arrival of a SETUP command, which is relayed to the Call Agent. The call agent analyzes teh com- mand, to obtain the destination (dn) and source (sn) party numbers. The call agent sends a call progress message, which is tunneled to the gateay and relayed over the D-Channel. The Call Agent then seizes the incoming circuit, creating a connection: CRCX 1204 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly The gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the ses- sion descrip- tion used to receive audio data: 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent, having seized the incoming trunk and completed a routing look up to identify the outgoing gateway, seizes the outgoing trunk. It does so by sending a connection command to the egress gate- way: CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: sendrecv v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SS7 trunking gateway acknowledges the connection command, sending in the session description its own parameters such as address, ports and RTP profile: 200 1205 OK I:32F345E2 Huitema, Andreasen, Arango, Prakash [Page 30] Internet draft MGCP Call Flows 20 January 1999 v=0 c=IN IP4 128.96.63.25 m=audio 1297 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent relays the information to the ingress gateway, using a ModifyConnection command: MDCX 1206 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: recvonly v=0 c=IN IP4 128.96.63.25 m=audio 1297 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The business gateway immediately acknowledges the modification: 200 1206 OK At this stage, the Call Agent has established a half duplex transmission path. The subscriber that originated the call will be able to receive signals, such as tones or announcements, that the remote switch may send through the trunking gateways. When the call progresses, the Call Agent will receive from the remote switch progress messages, for example an "address com- plete" message (ACM). The Call Agent will tunnel an ALERT mes- sage to the originating PBX. It may, if needed, send a notifi- cation request command to the gateway, to generate alerting tones over the B-channel: RQNT 1207 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 X: 0123456789AE S: rt The gateway immediately acknowledges the command: 200 1207 OK After the called user answers the call, the Call Agent will receive an answering message (ANM) from the CO switch. At that point, it will send a ModifyConnection command to the business gateway, to place the connection in full duplex mode, and an embedded NotificationRequest to stop the ringing tones: Huitema, Andreasen, Arango, Prakash [Page 31] Internet draft MGCP Call Flows 20 January 1999 MDCX 1209 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 M: sendrecv X: 0123456789AF S: The business gateway will acknowledge the command: 200 1209 OK At this point, the connection is established. When the Call Agent receives the REL message from the CO switch, it will have to tear down the call. It will do so by sending to both gateways a DeleteConnection command: DLCX 1210 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 The gateways will respond with acknowledgements that should include a "call parameters" header fields: 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48 Having freed the local resource, the call agent will confirm the release by sending a RLC message to the next switch, and will also send a release message through the Q.931 tunnel to the PBX. The PBX will send back a release confirmation. Both gateways, at this point, are ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 32] Internet draft MGCP Call Flows 20 January 1999 2.6. Basic call with continuity test, TGW to RGW _______________________________________________________ | CO | SS7/| TGW| CA | CDB| ACC| RGW| Usr| | | ISUP| | | | | | | |____|______|_____|____________|_____|_____|_____|_____| | IAM| -> | | | | | | | | | IAM | - -| -> | | | | | | | | | Check | -> | | | | | | | | <- | IP | | | | | | | <- | Create | | | | | | | | | Connection| | | | | | | | Ack| -> | | | | | | COT| -> | | | | | | | | | COT | - -| -> | | | | | | | | <- | Modify | | | | | | | | | Connection| | | | | | | | | Create | | | | | | | | | Connection| - -| - -| -> | | | | | | <- | - -| - -| Ack| | |____|______|_____|____________|_____|_____|_____|_____| This diagram shows the various exchange of messages during the beginning of a call from a telephone user on the circuit- switched PSTN to a residential user connected to a residential gateway. During these exchanges the Call Agent uses MGCP to con- trol both the TGW and the residential gateway. The circuit switch decides to execute a continuity test during the call establishment. The exchanges occur on two sides. Upon reception of the IAM message, the Call Agent recognizes that a continuity test has been requested. It immediately sends a CreateConnection request to the trunking gateway to connect to the incoming trunk, creating a connection: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: conttest The trunking gateway recognizes that the mode is set to "conttest". It places the circuit in "continuity test" mode, ready to send back the 2010 Hz return tone if it receives a 1780 Hz tone. The gateway acknowledges the creation of the connec- tion, sending back the identification of the newly created con- nection and the session description used to receive audio data: Huitema, Andreasen, Arango, Prakash [Page 33] Internet draft MGCP Call Flows 20 January 1999 200 1237 OK I: FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 At this point, the call agent is waiting for the result of the continuity test. The calling switch is sending the test tone (1780 Hz); if it receives the return tone (2010 Hz), it will send a "continuity passed" message (COT). At this point, the call agent will send a modify connection message to the gateway, in order to place the connection in "recvonly" mode: MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 M: recvonly The gateway will immediately acknowledge that command: 200 1238 OK The Call Agent will then proceed with the establishment of the call. Huitema, Andreasen, Arango, Prakash [Page 34] Internet draft MGCP Call Flows 20 January 1999 2.7. Hairpin connection, regular set-up The figure below gives the flow that results in an hairpin con- nection on the same gateway. In this flow, we assume that the exchange of messages is exactly comparable to what would happen in a call relayed between two trunking gateways, with the sole difference that the call will be relayed on a local connection. ________________________________________ | sw1| sw2| SG | CA | TGW-1| TGW-2| |____|_____|_____|______|_______|_______| | IAM| - -| -> | | | | | | | IAM| -> | | | | | | | CRCX| -> | | | | | | <-| ACK | | | | | | CRCX| - - | -> | | | | | <-| - - | ACK | | | | <-| IAM | | | | | <-| IAM| | | | | | ACM| -> | | | | | | | ACM| -> | | | | | | <-| ACM | | | | <-| - -| ACM| | | | | | ...| | | | | | | ANM| -> | | | | | | | ANM| -> | | | | | | | MDCX| -> | | | | | | <-| ACK | | | | | <-| ANM | | | | <-| - -| ANM| | | | | REL| - -| -> | | | | | | | REL| -> | | | | | | | DLCX| -> | | | | | | <-| ACK | | | | | <-| RLC | | | | <-| - -| RLC| | | | | | | | DLCX| -> | | | | | | <-| Perf | | | | | | | data | | | | | <-| REL | | | | | <-| REL| | | | | | RLC| -> | | | | | | | RLC| -> | | | |____|_____|_____|______|_______|_______| During these exchanges the MGCP is used by the Call Agent to control two endpoints located on the same TGW. Huitema, Andreasen, Arango, Prakash [Page 35] Internet draft MGCP Call Flows 20 January 1999 The exchanges start with the arrival from the first switch (SW1) of an SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call Agent. The call agent performs the routing, and determines that the call will have to be relayed towards the second switch (SW2), using a trunk located on the same gateway. The call agent starts the exchange by seizing the endpoint referenced in the IAM message: CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: nt=LOCAL M: recvonly Upon reception of that command, the trunking gateway prepares a "local" connection description. 200 1204 OK I:FDE234C8 v=0 c=IN tgw.whatever.net trunk-group-1/17 m=audio 0 LOCAL 0 The call agent, upon reception of this acknowledgement, sends a connection request to the trunking gateway, asking the gateway to reserve a trunk in the group connected to the second switch: CRCX 1205 trunk-group-2/$@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: nt=LOCAL M: sendrecv v=0 c=IN tgw.whatever.net trunk-group-1/17 m=audio 0 LOCAL 0 The call agent selects a trunk in the group, and acknowledges the creation: 200 1204 OK I:abc0 v=0 c=IN tgw.whatever.net trunk-group-2/13 Huitema, Andreasen, Arango, Prakash [Page 36] Internet draft MGCP Call Flows 20 January 1999 m=audio 0 LOCAL 0 The two commands have created a one way path, suitable for for- warding ring tones and announcements to the calling party. The call agent can now relay the call by sending an IAM message to the second switch. When the ACM is received, it is immediately relayed to the first switch. After some time, the call is answered, and an ANM message is relayed from the second switch to the call agent. The call agent will first validate the call by asking the first end-point to place the connection in duplex mode: MDCX 1206 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv v=0 c=IN tgw.whatever.net trunk-group-2/13 m=audio 0 LOCAL 0 The trunking gateway executes and acknowledges the modification: 200 1206 OK The call agent can now relay the ANM message to the cal- ling switch, and both parties can talk. At the end of the call, in our example, the calling party hangs up. The first switch sends a release mes- sage to the call agent, through the signalling gateway. The call agent releases the connection on the first end- point: DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 The gateway acknowledges the deletion, sending the con- nection parameters: 250 1217 OK P: OS=62345, OR=62345 The call agent can now confirm the release of the trunk, Huitema, Andreasen, Arango, Prakash [Page 37] Internet draft MGCP Call Flows 20 January 1999 sending an RLC message to the first switch. In parallel, the call agent releases the connection to the second endpoint: DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:abc0 The gateway acknowledges the deletion, sending the con- nection parameters: 250 1218 OK P: OS=62345, OR=62345 After receiving the acknowledgement, the call agent can relay the release message to the second switch. The switch will in turn acknowledge the release. Huitema, Andreasen, Arango, Prakash [Page 38] Internet draft MGCP Call Flows 20 January 1999 2.8. Hairpin connection, accelerated set-up The figure below gives the flow that results in an hair- pin connection on the same gateway. Contrary to the previous example, we will assume that the call agent uses a special-case software, and takes full benefit of the call's locality to accelerate the call set-up. _________________________________________________ | User1 | User2 | RGW | CA | |_________|___________|___________|______________| | | | <-- | RQNT | | | | ACK | --> | | OFF HOOK| --- | --> | | | <-- | --- | dialtone| | | digits | --- | NTFY | --> | | | | | | | | | <-- | ACK | | | | | | | | | <-- | CRCX+RQNT, | | | Ring | <-- | CRCX+RQNT | | | | ACK | --> | | | | ACK | --> | | | OFF HOOK | NTFY | --> | | | | <-- | ACK | | | | <-- | RQNT | | | | ACK | --> | | | | | | | on-hook | --- | NTFY | --> | | | | <-- | ACK | | | | <-- | DLCX+RQNT | | | | <-- | DLCX | | | | ACK | --> | | | | ACK | --> | | | on-hook | NTFY | --> | | | | <-- | ACK | | | | <-- | RQNT | | | | ACK | --> | |_________|___________|___________|______________| The first command is a NotificationRequest, sent by the Call Agent to the residential gateway. The request will consist of the following lines: RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: hd(E(dl;hu, D/[0-9#*T](D);) Huitema, Andreasen, Arango, Prakash [Page 39] Internet draft MGCP Call Flows 20 January 1999 D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) The gateway immediately acknowledges the command, repeating in the acknowledgement message the transaction id that the Call Agent attached to the query. 200 1201 OK When the off hook event is noticed, the gateway provides the dial tone to the line (the delay between off-hook and dialtone is thus minimal.) The gateway will then start accumulating digits according to that digit map. When it has noticed a sufficient set of values, it will notify the observed string to the Call Agent: NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: 912018294266 The Call Agent immediately acknowledges that notifica- tion. 200 2002 OK The call agent analyzes the called number and determines that this is an hairpin connection: the called party is located on the same gateway, on endpoint/2. The Cal- lAgent can prepare two simultaneous CreateConnection commands, creating the two legs of the connection. Because we are not too concerned at this stage with tax evasion, the The Call Agent will then seize the incoming circuit, creating a connection. The create connection sent to the first endpoint piggybacks a notification request, to stop collecting digits yet continue watch for an on-hook transition. The CreateConnection sent to the second endpoint piggybacks a request to generate ringing and look for off-hook. Both commands can be sent in a single UDP packet: CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 X: 0123456789AD M: sendrecv R: hu Huitema, Andreasen, Arango, Prakash [Page 40] Internet draft MGCP Call Flows 20 January 1999 S: v=0 c=LOCAL rgw-2567.whatever.net endpoint/2 m=audio 0 LOCAL 0 . CRCX 1205 endpoint/2@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 X: 9875659876 M: sendrecv R: hd S: rg v=0 c=LOCAL rgw-2567.whatever.net endpoint/1 m=audio 0 LOCAL 0 We should note that the call agent does not send the local connection options since it knows that it is a local (a.k.a. "hairpin") connection: the con- nections are entirely described by the SDP text. The gateway immediately acknowledges the creations, sending back in two messages the identification of the newly created connections: 200 1204 OK I:FDE234C8 . 200 1204 OK I:9867659A The residential gateway, at that point, is instructed to look for an off-hook event on the second endpoint, and to report it. When the gateway notices the off hook event, it sends a Notify command to the Call Agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 9875659876 O: hd The Call Agent immediately acknowledges that notifica- tion: 200 2001 OK Huitema, Andreasen, Arango, Prakash [Page 41] Internet draft MGCP Call Flows 20 January 1999 The Call agent will now send a NotificationRequest com- mand to the gateway, asking to look for an off-hook event on the second end-point: RQNT 1206 endpoint/2@rgw-2567.whatever.net MGCP 0.1 X: 987565989A R: hu S: The gateway acknowledges that command: 200 1206 OK At this point the call is active between the two residential gateway users. When the first user goes off hook, it sends a notifica- tion to the call agent: NTFY 2010 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 987565989A O: hu The call agent acknowledges the notification. It can, in a single UDP message, send the acknowledgement and the DeleteConnection commands that will clear the call. For the first gateway, the command embeds a notification request that readies that gateway for the next call: 200 2010 OK . DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 N: ca@ca1.whatever.net:5678 X: 012345673FDE R: hd(E(dl;hu, D/[0-9#*T](D);) S: . DLCX 1211 endpoint/2@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: 9867659A X: A3C5F0 R: hu S: The gateway will acknowledge the commands in a single UDP message that will carry the "local connection" Huitema, Andreasen, Arango, Prakash [Page 42] Internet draft MGCP Call Flows 20 January 1999 version of the connection parameters. 250 1243 OK P: OS=62345, OR=62345 . 250 1244 OK P: OS=62345, OR=62345 When the second user goes off hook, the gateway sends a Notify commands NTFY 2020 endpoint/2@rgw-2567.whatever.net MGCP 0.1 X: A3C5F0 O: hu The Call agent follows with a notification requests, transmitted in the same packet as the acknowledgement, in order to ready the line for the next call: 200 2020 OK . RQNT 1220 enpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456793E5 R: hd(E(dl;hu, D/[0-9#*T](D);) S: The gateway acknowledges the command, signalling that the second endpoint is now ready. 200 1220 OK Huitema, Andreasen, Arango, Prakash [Page 43] Internet draft MGCP Call Flows 20 January 1999 2.9. Hairpin connection, double end-point model The figure below gives the flow that results in an hair- pin connection on the same gateway. In this flow, we assume that we use the "double endpoint" extensions to the create-connection command. ________________________________________ | sw1| sw2| SG | CA | TGW-1| TGW-2| |____|_____|_____|______|_______|_______| | IAM| - -| -> | | | | | | | IAM| -> | | | | | | | CRCX| -> | (->) | | | | | <-| ACK | (ACK)| | | | <-| IAM | | | | | <-| IAM| | | | | | ACM| -> | | | | | | | ACM| -> | | | | | | <-| ACM | | | | <-| - -| ACM| | | | | | ...| | | | | | | ANM| -> | | | | | | | ANM| -> | | | | | | <-| ANM | | | | <-| - -| ANM| | | | | REL| - -| -> | | | | | | | REL| -> | | | | | | | DLCX| -> | | | | | | <-| Perf | | | | | | | data | | | | | <-| RLC | | | | <-| - -| RLC| | | | | | | | DLCX| -> | | | | | | <-| Perf | | | | | | | data | | | | | <-| REL | | | | | <-| REL| | | | | | RLC| -> | | | | | | | RLC| -> | | | |____|_____|_____|______|_______|_______| During these exchanges the MGCP is used by the Call Agent to control two endpoints located on the same TGW. The exchanges start with the arrival from the first switch (SW1) of an SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call Agent. The call Huitema, Andreasen, Arango, Prakash [Page 44] Internet draft MGCP Call Flows 20 January 1999 agent performs the routing, and determines that the call will have to be relayed towards the second switch (SW2), using a trunk located on the same gateway. The call agent starts the exchange by seizing the end- point referenced in the IAM message: CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: nt=LOCAL M: sendrecv E2: trunk-group-2/$ Upon reception of that command, the trunking gateway prepares a "local" connection description between the specified endpoint (trunk-group-1/17) and an endpoint that it selects within the secund trunk group (trunk- group-2/13). The gateway acknowledges the two creations in a single message: 200 1204 OK I:FDE234C8 Z2:trunk-group-2/13@tgw.whatever.net I2:abc0 The command has created a path, between the two end- points. The call agent can now relay the call by sending an IAM message to the second switch. When the ACM is received, it is immediately relayed to the first switch. After some time, the call is answered, and an ANM mes- sage is relayed from the second switch to the call agent. The call agent immediately relays the ANM mes- sage to the calling switch, and both parties can talk. At the end of the call, in our example, the calling party hangs up. The first switch sends a release mes- sage to the call agent, through the signalling gateway. The call agent releases the connection on the first end- point: DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 The gateway acknowledges the deletion, sending the Huitema, Andreasen, Arango, Prakash [Page 45] Internet draft MGCP Call Flows 20 January 1999 connection parameters: 250 1217 OK P: OS=62345, OR=62345 The call agent can now confirm the release of the trunk, sending an RLC message to the first switch. In parallel, the call agent releases the connection to the second endpoint: DLCX 1208 trunk-group-2/13@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:abc0 The gateway acknowledges the deletion, sending the con- nection parameters: 250 1218 OK P: OS=62345, OR=62345 After receiving the acknowledgement, the call agent can relay the release message to the second switch. The switch will in turn acknowledge the release. Huitema, Andreasen, Arango, Prakash [Page 46] Internet draft MGCP Call Flows 20 January 1999 3. Interaction between an MGCP gateway and an H.323 entity MGCP is not intended to replace H.323, or even to com- pete with it. In fact, we should mostly consider it as a tool to enable distributed implementations of H.323. The combination of gateways and call agent behaves as a dis- tributed H.323 system, using MGCP for internal communi- cation. This system appears to H.323 users as a larger H.323 system, or, if one prefers, as an H.323 gatekeeper that implements the Gatekeeper routed call model. In order to demonstrate the compatibility between MGCP and H.323, we provide here a step by step demonstration of 2 call set up scenarios: * Call from an MGCP controlled residential gateway to an H.323 entity, * Call from an H.323 entity to an MGCP controlled residential gateway. We suppose, in these scenarios, that the H.323 entity is capable of using the fast start procedure defined in H.323v2. Huitema, Andreasen, Arango, Prakash [Page 47] Internet draft MGCP Call Flows 20 January 1999 3.1. Call from a residential gateway (RGW) to an H.323 user _____________________________________________________________________ | Usr | RGW | CA | H.323 | Usr | GK | |____________|___________|______________|___________|__________|_____| | | <- | RQNT | | | | | | Ack | -> | | | | | | | | | | | | Off-hook | Notify | -> | | | | | <- | Ack | | | | | | (Dial-tone)| <- | RQNT | | | | | | Ack | -> | | | | | | | | | | | | Digits | Notify | -> | | | | | <- | Ack | | | | | | (progress) | <- | CRCX+RQNT | | | | | | Ack | -> | | | | | | | (processing)| | | | | | | TCP-SYN | -> | | | | | | <- | SYN, ACK | | | | | | Set-up+ | | | | | | | faststart | -> | | | | | | | ARQ | - - - | -> | | | | | <- | - - - | ACF| | | | <- | alerting | ring | | | | | TCP ACK | -> | | | | (ring back)| <- | RQNT | | | | | | Ack | -> | | | | | | | <- | connect +| off hook| | | | | | faststart| | | | | | TCP ACK | -> | | | | | <- | MDCX+RQNT | | | | | | Ack | -> | | | | | | | (call est.) | | | | | on hook | Notify | -> | | | | | <- | Ack | | | | | | <- | DLCX+RQNT| | | | | | perf data | -> | | | | | | | | Rel. C. | -> | | | | | | TCP-FIN | -> | | | | | | <- | FIN, ACK | | | | | | TCP ACK | -> | | | | | | | (signal) | On-hook | | | | | | DRQ | - - - | -> | | | | | <- | - - - | DCF| |____________|___________|______________|___________|__________|_____| Huitema, Andreasen, Arango, Prakash [Page 48] Internet draft MGCP Call Flows 20 January 1999 During these exchanges the MGCP is used by the call agent to control the residential gateways. The call will be routed to an H.323 entity. The first command is a notification request, sent by the call agent to the residential gateway. The request will consist of the following lines: RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB R: hd The gateway, at that point, is instructed to look for an off-hook event, and to report it. It will first ack- nowledge the request, repeating in the acknowledgement message the transaction id that the call agent attached to the query. 200 1201 OK Note that this command is not actually simultaneous with the call. It can be issued long before the actual call, for example when the gateway is turned on, or after the end of a previous call. When the off hook event is noticed, the gateway sends a Notify command to the call agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB O: hd The call agent immediately acknowledges that notifica- tion. 200 2001 OK The call agent examines the services associated to an off hook action (it could take special actions in the case of a direct line). In most cases, it will send a notification request, asking for digits. The current example provides the gateway with a digit map, and requests the gateway to play a dialtone: Huitema, Andreasen, Arango, Prakash [Page 49] Internet draft MGCP Call Flows 20 January 1999 RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: hu, [0-9#*T](D) D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx | 9011x.T) S: dl The gateway immediately acknowledges that request. 200 1202 OK The gateway will start accumulating digits according to that digit map. When it has noticed a sufficient set of values, it will notify the observed string to the call agent: NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: 912018294266 The call agent immediately acknowledges that notifica- tion. 200 2002 OK At this stage, the call agent seizes the incoming cir- cuit, creating a connection. It will also send together with that creation request a notification request, to stop collecting digits yet continue watch for an on-hook transition: CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly X: 0123456789AD R: hu The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion and the session description used to receive audio Huitema, Andreasen, Arango, Prakash [Page 50] Internet draft MGCP Call Flows 20 January 1999 data: 200 1204 OK I: FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 The SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), the transport protocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio profile refers to RFC 1890, which defines that the pay- load type 0 has been assigned for G.711 transmission. The call agent, having seized the incoming trunk, proceeds with call routing. Using local databases, it determines that the dialed digits (912018294266) correspond to a H.323 entity. It will set up a TCP-IP connection and send an H.225/Q.931 "set-up" message to the H.323 entity. In this message, the "faststart" ele- ment carries a set of open logical channel proposals, derived from the SDP description received from the cal- ling gateway: Huitema, Andreasen, Arango, Prakash [Page 51] Internet draft MGCP Call Flows 20 January 1999 faststart-1 OpenLogicalChannel ::= { forwardLogicalChannelNumber 1, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms G.711 frame multiplexParameters h2250LogicalChannelParameters H2250LogicalChannelParameters { sessionID 1, silenceSuppression FALSE } } } faststart-2 OpenLogicalChannel ::= { forwardLogicalChannelNumber 2, forwardLogicalChannelParameters { dataType nullData, -- pro forma multiplexParameters none }, reverseLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters H2250LogicalChannelParameters { sessionID 2, mediaChannel unicastAddress iPAddress { network '80602901'H, -- 128.96.41.1 tsapIdentifier 3456 -- port }, mediaControlChannel unicastAddress iPAddress { network '80602901'H, -- 128.96.41.1 tsapIdentifier 3457 -- port }, silenceSuppression FALSE } } } The H.323 alerts the user, and sends an H.225/Q.931 "alerting" message. On reception of this message, the call agent will send a notification request that instruct the RGW to generate alerting tones: RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AE R: hu S: v Huitema, Andreasen, Arango, Prakash [Page 52] Internet draft MGCP Call Flows 20 January 1999 When the called user accepts the call, the H.323 entity sends an H.225/Q.931 set-up message to the call agent. If the H.323 entity accepted the fast start procedure, the faststart parameter will contain the confirmation of the open logical channel creations in the two directions of com- munication: faststart-1 OpenLogicalChannel ::= { forwardLogicalChannelNumber 1, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters { sessionID 1, mediaChannel unicastAddress iPAddress { network '80603F19'H, tsapIdentifier 3456, -- port } , mediaControlChannel unicastAddress iPAddress { network '80603F19'H, tsapIdentifier 3457, -- port } , silenceSuppression FALSE } } } faststart-2 OpenLogicalChannel ::= { forwardLogicalChannelNumber 2, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters { sessionID 2, silenceSuppression FALSE } } } The call agent will send a modification request to the residential gateway, in order to establish a full duplex connection. The SDP payload, in that request, is derived from the parameters of the logical channel for transmis- sion from the gateway to the H.323 entity. Huitema, Andreasen, Arango, Prakash [Page 53] Internet draft MGCP Call Flows 20 January 1999 MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 M: sendrecv X: 0123456789AF R: hu v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 The gateway will acknowledge this request: 200 1209 OK At this point, the connection is established. In our example, the call is terminated when the calling party hangs up. This triggers a Notify command to the call agent: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AF O: hu After this notification, the call agent should send an acknowledgement: 200 2005 OK The call agent will then clear the call, by sending a delete connection request to the calling gateway. This request is combined with a notification request, to be ready to detect the next call issued by the residential gateway: DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 X: 0123456789B0 R: hd Huitema, Andreasen, Arango, Prakash [Page 54] Internet draft MGCP Call Flows 20 January 1999 The gateway will respond with a message that should include a "call parameters" header field: 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 The call agent will in parallel sends an H.225/Q.931 "release complete" message to the H.323 entity. It will then tear down the TCP-IP connection. The gateway, at this point, is ready for the next call. The H.323 user will be ready as soon as the H.323 entity notices that the phone is back on hook. Huitema, Andreasen, Arango, Prakash [Page 55] Internet draft MGCP Call Flows 20 January 1999 3.2. Basic call, H.323 to RGW ___________________________________________________________________ | User | H.323 | GK | CA | RGW | Usr | |_______|____________|_______|______________|___________|__________| | call | -> | | | | | | | ARQ | -> | | | | | | <- | ACF | | | | | | TCP SYN | - - -| -> | | | | | <- | - - -| SYN+ACK | | | | | set-up+ | | | | | | | fast start| - - -| -> | | | | | | | (call | | | | | | | processing) | | | | | | | CRCX+RQNT | -> | ring | | | | | <- | Ack | | | | <- | - - -| alerting | | | | | TCP ACK | - - -| -> | | | | | (ringing) | | | | | | | | | <- | Notify | off hook| | | | | Ack | -> | | | | | | RQNT | -> | | | | | | <- | Ack | | | | <- | - - -| connect + | | | | | | | fast start | | | | | TCP ACK | - - -| -> | | | | | | | (call | | | | | | | established)| | | | | | | | | | | | | | <- | Notify | on hook | | | | | Ack | -> | | | | | | (no | | | | | | | suspension) | | | | | | | RQNT | -> | | | | | | <- | Ack | | | hangup| detected | | | | | | | Rel. C. | | | | | | | TCP FIN | - - -| -> | | | | | <- | - - -| FIN ACK | | | | | | | DLCX+RQNT | -> | | | | | | <- | perf data| | | | DRQ | -> | | | | | | <- | DCF | | | | |_______|____________|_______|______________|___________|__________| This diagram shows the various exchange of messages dur- ing a call from an H.323 user to a residential user. Huitema, Andreasen, Arango, Prakash [Page 56] Internet draft MGCP Call Flows 20 January 1999 During these exchanges the MGCP is used by the call agent to control the residential gateway. When the user initiates the call, the H.323 entity will perform a RAS transaction with its designated Gate- keeper. As a result of this transaction, it will learn the TCP-IP address of the call agent, and will set up a TCP-IP connection with the call agent. Once the TCP-IP connection is established, the H.323 entity sends a Q.931/H.225 connect message to the call agent. The mes- sage, in its user-to-user parameter, includes a "fast start" parameter that lists a set of OpenLogicalChannel proposals, such as for example: faststart-1 OpenLogicalChannel ::= { forwardLogicalChannelNumber 1, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms G.711 frame multiplexParameters h2250LogicalChannelParameters { sessionID 1, silenceSuppression FALSE } } } faststart-2 OpenLogicalChannel ::= { forwardLogicalChannelNumber 2, forwardLogicalChannelParameters { dataType nullData, -- pro forma multiplexParameters none }, reverseLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters { sessionID 2, mediaChannel unicastAddress iPAddress { network '80602901'H, -- 128.96.41.1 tsapIdentifier 3456, -- port }, mediaControlChannel unicastAddress iPAddress { network '80602901'H, -- 128.96.41.1 tsapIdentifier 3457, -- port }, silenceSuppression FALSE } } } Huitema, Andreasen, Arango, Prakash [Page 57] Internet draft MGCP Call Flows 20 January 1999 Upon reception of the set-up message, the call agent will perform called routing functions and determine the end point that correspond to the called party number. It will reserve the outgoing circuit. It does so and at the same time it requests ringing, by sending to the residential gateway a create connection request combined with a notification request: CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711 M: sendrecv X: 0123456789B1 R: hd S: rg v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 In this command, the SDP announcement is obtained by translating the "faststart" parameters corresponding to the receive channel announced by the caller - channel 2 in our case. The IP address, RTP port and authorized payload are derived from the "reverseLogicalChannel- Parameters" data elements. We derive the authorized payload type from the "dataType" element. We have how- ever to check that this value is proposed in at least one of the forward channels. The gateway will acknowledge the connection request, sending in the session description its own parameters such as address, ports and RTP profile: 200 1238 OK I: 32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 The phone is ringing, and the gateway, is instructed to look for an off-hook event, and to report it. The call agent sends an alerting message to the calling switch, which we assume will generate ringing tones for the cal- ling user. Huitema, Andreasen, Arango, Prakash [Page 58] Internet draft MGCP Call Flows 20 January 1999 When the off hook event is noticed, the gateway sends a Notify command to the call agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B0 O: hd The call agent immediately acknowledges that notifica- tion. 200 2001 OK The call agent must now ask the residential gateway to notify the occurrence of an on-hook event. It does so by sending a notification request to the residential gate- way: RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B1 R: hu The gateway acknowledges that request: 200 1241 OK In parallel, the call agent will send a "connect" mes- sage to the H.323 agent. The message includes the "fast start" parameter, which will validate and complement the proposals that the caller sent: Huitema, Andreasen, Arango, Prakash [Page 59] Internet draft MGCP Call Flows 20 January 1999 faststart-1 OpenLogicalChannel ::= { forwardLogicalChannelNumber 1, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters { sessionID 1, mediaChannel unicastAddress iPAddress { network '80603F19'H, tsapIdentifier 3456, -- port } , mediaControlChannel unicastAddress iPAddress { network '80603F19'H, tsapIdentifier 3457, -- port } , silenceSuppression FALSE } } } faststart-2 OpenLogicalChannel ::= { forwardLogicalChannelNumber 2, forwardLogicalChannelParameters { dataType g711Ulaw64k 160, -- 20 ms frame multiplexParameters h2250LogicalChannelParameters ( sessionID 1, silenceSuppression FALSE } } } After some time, in our example, the residential user hangs up. The notify request is sent to the call agent: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 O: hu The call agent acknowledges the notification. 200 2005 OK Upon reception of that notification, the call agent should send a "suspend" message to the calling H.323 entity, but the Q.931 suspend message should not be sent in H.225. In order to preserve the user experience, the Huitema, Andreasen, Arango, Prakash [Page 60] Internet draft MGCP Call Flows 20 January 1999 call agent will simply initiate a timer, after which it would actually release the call. (In North-America, the call is not actually terminated if the called party hangs up. If it hangs down in a short interval, the call will be resumed.) The call agent, in any case, sends a notification request to the gateway, to look for an off-hook event. RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B2 R: hd The gateway will acknowledge this request: 200 1243 OK In our example, the calling user releases the call immediately. The H.323 agent sends a "release complete" message to the call agent, which will then send a delete connection request to the residential gateway. The request sent to the gateway is combined with a request to detect a off-hook event, which will be used to detect rare conditions where the user would have gone off hook simultaneously with the release on the other side: DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 X: 0123456789B3 R: hd I: FDE234C8 The gateway will respond with a message that should include a "call parameters" header fields: 200 1244 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 The gateway, at this point, is ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 61] Internet draft MGCP Call Flows 20 January 1999 4. Interworking between SIP and MGCP The use of SDP in both MGCP and SIP makes interworking between these protocols very easy. In order to demon- strate this interworking, we provide here a step by step demonstration of 2 call set-up scenarios: * Call from an MGCP controlled residential gateway to a SIP agent, * Call from a SIP agent to an MGCP controlled residential gateway. Huitema, Andreasen, Arango, Prakash [Page 62] Internet draft MGCP Call Flows 20 January 1999 4.1. Call from a residential gateway (RGW) to a SIP user ___________________________________________________________________ | Usr | RGW | CA | SIP | Usr | |____________|___________|______________|________________|_________| | | <- | RQNT | | | | | Ack | -> | | | | | | | | | | Off-hook | Notify | -> | | | | | <- | | | | | Ack | | | | | | (Dial-tone)| <- | RQNT | | | | | Ack | -> | | | | | | | | | | Digit | Notify | -> | | | | | <- | Ack | | | | (progress) | <- | | | | | CRCX+RQNT | | | | | | | Ack | -> | | | | | | (processing)| | | | | | INVITE | -> | | | ring | | | | | | | | <- | resp. 180 | | | | | | (ringing) | | | (ringing) | <- | RQNT | | | | | Ack | -> | | | | | | | | | | | | <- | resp. 200 (OK)| | | off hook | | | | | | | | Ack | -> | | | | <- | MDCX+RQNT | | | | | Ack | -> | | | | | | (call | | | | | | established)| | | | on hook | Notify | -> | | | | | <- | Ack | | | | | <- | DLCX+RQNT | | | | | perf data| -> | | | | | | BYE | -> | | | | | <- | resp. 200 (OK)| | | | | | (local) | On-hook| |____________|___________|______________|________________|_________| During these exchanges the MGCP is used by the call agent to control the residential gateways. The call will be routed to a SIP agent. The first command is a Huitema, Andreasen, Arango, Prakash [Page 63] Internet draft MGCP Call Flows 20 January 1999 notification request, sent by the call agent to the residential gateway. The request will consist of the following lines: RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB R: hd The gateway, at that point, is instructed to look for an off-hook event, and to report it. It will first ack- nowledge the request, repeating in the acknowledgement message the transaction id that the call agent attached to the query. 200 1201 OK Note that this command is not actually simultaneous with the call. It can be issued long before the actual call, for example when the gateway is turned on, or after the end of a previous call. When the off hook event is noticed, the gateway ini- tiates a notification request to the call agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AB O: hd The call agent immediately acknowledges that notifica- tion. 200 2001 OK The call agent examines the services associated to an off hook action (it could take special actions in the case of a direct line). In most cases, it will send a notification request, asking for digits. It will also provide the gateway with a digit map, and requests the gateway to play a dialtone: Huitema, Andreasen, Arango, Prakash [Page 64] Internet draft MGCP Call Flows 20 January 1999 RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: hu, D/[0-9#*T](D) D: (0T | 1xxxxxxxxxx | [2-9]xxxxxx | [4789]11 | 011x.T) S: dl The gateway immediately acknowledges that request. 200 1202 OK The gateway will start accumulating digits according to that digit map. When it has noticed a sufficient set of values, it will notify the observed string to the call agent: NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: 912018294266 The call agent immediately acknowledges that notifica- tion. 200 2002 OK At this stage, the call agent seizes the incoming cir- cuit, creating a connection. It will also send together with that creation request a notification request, to stop collecting digits yet continue watch for an on-hook transition: CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly X: 0123456789AD R: hu The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion and the session description used to receive audio Huitema, Andreasen, Arango, Prakash [Page 65] Internet draft MGCP Call Flows 20 January 1999 data: 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), the transport protocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio profile refers to RFC 1890, which defines that the pay- load type 0 has been assigned for G.711 transmission. The gateway is also ready to use ADPCM encoding at 32 kbps (G.726 -4). There is no standard payload type asso- ciated to ADPCM, so the gateway mentions its readiness to use a non standard payload associated to the dynamic type 96. The "rtpmap" attribute entry associates the payload type 96 to G726-32/4. The call agent, having seized the incoming trunk, proceeds with call routing. Using local databases, it determines that the dialed digits (912018294266) correspond to a SIP agent. It will send an invitation to that agent: INVITE sip:huitema@sip-station.bellcore.com SIP/2.0 Via: SIP/2.0/UDP 128.96.41.12 From: sip:123456789@ca.whatever.net To: Christian Huitema Call-ID: A3C47F21456789F0@ca.whatever.net Cseq: 1 INVITE Content-type: application/sdp Content-Length: ... v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The SDP attachment, in the INVITE message, is directly copied from the acknowledgement of the Create Connection request. The SIP agent alerts the user, and sends an Huitema, Andreasen, Arango, Prakash [Page 66] Internet draft MGCP Call Flows 20 January 1999 immediate acknowledgement: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 128.96.41.12 From: Christian Huitema To: 123456789@ca.whatever.net Call-ID: A3C47F21456789F0@ca.whatever.net Cseq: 1 INVITE The call agent will send a notification request that instruct the RGW to generate alerting tones: RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AE R: hu S: v When the called user accepts the call, the SIP agent sends an acceptation message to the call agent: SIP/2.0 200 OK Via: SIP/2.0/UDP 128.96.41.12 From: "Christian Huitema" To: sip:123456789@ca.whatever.net Call-ID: A3C47F21456789F0@ca.whatever.net CSeq: 1 INVITE Content-type: application/sdp Content-Length:... v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The gateway immediately acknowledges the call set up: ACK huitema@sip-station.bellcore.com SIP/2.0 Via: SIP/2.0/UDP 128.96.41.12 From: 123456789@ca.whatever.net To: huitema@sip-station.bellcore.com (Christian Huitema) Call-ID: 187602141351@ca.whatever.net Then, the call agent will send a modification request to the residential gateway, in order to establish a full Huitema, Andreasen, Arango, Prakash [Page 67] Internet draft MGCP Call Flows 20 January 1999 duplex connection. The SDP payload, in that request, is copied from the SIP agent's response: MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv X: 0123456789AF R: hu v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 + The gateway will acknowledge this request: 200 1209 OK At this point, the connection is established. In our example, the call is terminated when the calling party hangs up. This triggers a Notify command to the call agent: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AF O: hu After this notification, the call agent should send an acknowledgement: 200 2005 OK The call agent will then clear the call, by sending a delete connection request to the calling gateway. This request is combined with a notification request, to be ready to detect the next call issued by the residential gateway: Huitema, Andreasen, Arango, Prakash [Page 68] Internet draft MGCP Call Flows 20 January 1999 DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 X: 0123456789B0 R: hd The gateway will respond with a message that should include a "call parameters" header field: 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 The call agent will in parallel sends a BYE request to the SIP agent: BYE sip:huitema@sip-station.bellcore.com SIP/2.0 Via: SIP/2.0/UDP 128.96.41.12 From: sip:123456789@ca.whatever.net To: "Christian Huitema" Call-ID: A3C47F21456789F0@ca.whatever.net CSeq: 2 BYE The SIP agent will acknowledge that request: SIP/2.0 200 OK Via: SIP/2.0/UDP 128.96.41.12 From: "Christian Huitema" To: sip:123456789@ca.whatever.net Call-ID: A3C47F21456789F0@ca.whatever.net CSeq: 2 BYE SIP/2.0 200 OK The gateway, at this point, is ready for the next call. The SIP user will be ready as soon as the SIP agent notices that the phone is back on hook. Huitema, Andreasen, Arango, Prakash [Page 69] Internet draft MGCP Call Flows 20 January 1999 4.2. Basic call, SIP to RGW _______________________________________________________________ | User | SIP agent| CA | RGW | Usr | |_______|___________|___________________|___________|__________| | call | -> | | | | | | INVITE | -> | | | | | | (call processing)| | | | | | CRCX+RQNT | -> | | | ring | | | | | | | | <- | | | | Ack | | | | | | | <- | resp. 180 | | | | | (ringing)| (ringing) | | | | | | <- | Notify | off hook| | | | Ack | -> | | | | | RQNT | -> | | | | | <- | Ack | | | | <- | resp. 200 (OK) | | | | | ACK | -> | | | | | | (call | | | | | | established) | | | | | | | | | | | | <- | Notify | on hook | | | | Ack | -> | | | | | (no susp. | | | | | | message) | | | | | | RQNT | -> | | | | | <- | Ack | | | | | | | | | hangup| detected | | | | | | BYE | -> | | | | | | DLCX+RQNT | -> | | | | | <- | perf data| | |_______|___________|___________________|___________|__________| This diagram shows the various exchange of messages dur- ing a call from a SIP user to a residential user. During these exchanges the MGCP is used by the call agent to control the residential gateway. When the user initiates the call, the SIP agent will send an invitation to the call agent. (Our diagram assumes that the SIP agent sends that invitation directly; in fact, there could be several relays.) An example of invitation could be: Huitema, Andreasen, Arango, Prakash [Page 70] Internet draft MGCP Call Flows 20 January 1999 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: "A. Bell" To: "T. A. Watson" Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-type: application/sdp Content-Length: ... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5 Upon reception of the set-up message, the call agent will perform call routing functions and determine the end point that corresponds to the invited user. It will then reserve the outgoing circuit. It does so at the same time that it requests ringing, by sending to the residential gateway a connection request combined with a notification request: CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711 M: sendrecv X: 0123456789B1 R: hd S: rg v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180.144.94 m=audio 3456 RTP/AVP 0 3 4 5 In this command, the SDP announcement is directly copied from the invitation. The gateway will acknowledge the connection request, sending in the session description its own parameters such as address, ports and RTP pro- file: Huitema, Andreasen, Arango, Prakash [Page 71] Internet draft MGCP Call Flows 20 January 1999 200 1238 OK I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 3 The phone is ringing, and the gateway, is instructed to look for an off-hook event, and to report it. The call agent sends an alerting message to the calling SIP agent, which will generate ringing tones for the calling user: SIP/2.0 180 Ringing Via: SIP/2.0/UDP 169.130.12.5 From: "A. Bell" To: sip:watson@bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 1 INVITE When the off hook event is noticed, the gateway ini- tiates a notification request to the call agent: NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B0 O: hd The call agent immediately acknowledges that notifica- tion. 200 2001 OK The call agent must now ask the residential gateway to notify the occurrence of an on-hook event. It does so by sending a notification request to the residential gateway: RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 R: hu Huitema, Andreasen, Arango, Prakash [Page 72] Internet draft MGCP Call Flows 20 January 1999 The gateway acknowledges that request: 200 1241 OK In parallel, the call agent will send a final answer to the SIP agent. The message, in its payload, copies the SDP announcement that was sent by the gateway: SIP/2.0 200 OK From: "A. Bell" To: sip:watson@bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 1 INVITE Contact: sip://watson@boston.bell-telephone.com Content-Length: ... v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 3 The SIP agent acknowledges the set-up: ACK sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: "A. Bell" To: "T. A. Watson" Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 1 ACK At this point, the call is established. After some time, in our example, the residential user hangs up. The notify request is sent to the call agent: NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B1 O: hu The call agent acknowledges the notification. 200 2005 OK Upon reception of that notification, the call agent should send a "suspend" message to the calling SIP Huitema, Andreasen, Arango, Prakash [Page 73] Internet draft MGCP Call Flows 20 January 1999 agent, but there is no such message in SIP. In order to preserve the user experience, the call agent will simply initiate a timer, after which it would actually release the call. (In North-America, the call is not actually terminated if the called party hangs up. If it hangs down in a short interval, the call will be resumed.) The call agent, in any case, sends a notification request to the gateway, to look for an off-hook event. RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789B2 R: hd The gateway will acknowledge this request: 200 1243 OK In our example, the calling user releases the call immediately. The SIP agent sends a BYE message to the call agent: BYE sip:watson@boston.bell-telephone.com SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: "A. Bell" To: "T. A. Watson" Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 2 BYE The call agent acknowledges that message: SIP/2.0 200 OK From: "A. Bell" To: sip:watson@bell-telephone.com Call-ID: 187602141351@worcester.bell-telephone.com CSeq: 2 BYE The call agent then sends a delete connection request to the residential gateway. The request sent to the gateway is combined with a request to detect a off-hook event, which will be used to detect rare conditions where the user would have gone off hook simultaneously with the release on the other side: Huitema, Andreasen, Arango, Prakash [Page 74] Internet draft MGCP Call Flows 20 January 1999 DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 X: 0123456789B3 R: hd I:FDE234C8 The gateway will respond with a message that should include a "call parameters" header fields: 200 1244 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 The gateway, at this point, is ready for the next call. Huitema, Andreasen, Arango, Prakash [Page 75] Internet draft MGCP Call Flows 20 January 1999 5. Data calls We present here a set of call flows corresponding to data calls: * Basic data call, * Outgoing data call through a NAS, * Call back, using a NAS, * Data call to a NAS, using L2TP, * Basic data call with continuity test. Huitema, Andreasen, Arango, Prakash [Page 76] Internet draft MGCP Call Flows 20 January 1999 5.1. Basic data call to a NAS _______________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Radius| | | | ISUP| | | | | |___________|_____|______|_____________|________________|_____|________| | dials in | | | | | | | | | IAM| -> | | | | | | | | IAM | - - | -> | | | | | | | | Check called | | | | | | | | number. | | | | | | | | Notices | | | | | | | | data call. | | | | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | | | Connection | | | | | | | | is completed. | | | | | | | | Call | | | | | | | | established | -> | | | | | <- | - - | ANM | | | | | <- | ANM | | | | | | modem | - -| - - | -> | | | | | <- | - -| - - | handshake | | | | | PPP | - -| - - | -> | | | | | | | | obtain | | | | | | | | user-id, | | | | | | | | password | | | | | | | | Check | - - | - -| -> | | | | | <- | - - | - -| Ack | | <- | - -| - - | Validates | | | | | | | | call, | | | | | <- | - -| - - | procures | | | | | | | | IP | | | | | | | | address | | | | | Connected | | | | | | | | to | | | | | | | | the | | | | | | | | Internet | | | | | | | |___________|_____|______|_____________|________________|_____|________| Huitema, Andreasen, Arango, Prakash [Page 77] Internet draft MGCP Call Flows 20 January 1999 ______________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Radius| | | | ISUP| | | | | |____________|_____|______|_______|____________|_____|________| | Closes | | | | | | | | connection.| | | | | | | | | REL| -> | | | | | | | | REL | - - | -> | | | | | | | <- | Delete | | | | | | | | Connection| | | | | | | Perf | | | | | | | | data | -> | | | | | | <- | - - | RLC | | | | | <- | RLC | | | | | | | | | | Call end | -> | | |____________|_____|______|_______|____________|_____|________| This diagram shows the exchange of messages during a call from a modem user to an Internet Service Provider, using a trunking gateway that doubles as a Network Access Server. During these exchanges the MGCP is used by the Call Agent to control both the trunking gateway. Since there is no "other end" of the call, only the trunk gateway is involved in the call. Upon reception of the IAM message, the Call Agent deter- mines that the call is a data call (e.g., by bearer capability, the called number, etc.). Using configura- tion databases, the Call Agent selects the type of modem parameters and authentication parameters that correspond to the called number and to the calling number. It uses this knowledge to send a CreateConnection command to the NAS, programming the incoming trunk: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: data X: 0123456789B1 R: cl, ax v=0 m=nas/radius c=IN IP4 radius.example.net a=bearer:v.32 a=framing:ppp-asynch a=dialed:18001234567 a=dialing:2345678901 Huitema, Andreasen, Arango, Prakash [Page 78] Internet draft MGCP Call Flows 20 January 1999 The trunking gateway checks that it has adequate resources for the call. If the trunking gateway did not have adequate resources, for example if it could not support the requested modem type, it should refuse the creation and send an error response to the Call Agent. If the gateway has sufficient resources, it immediately acknowledges the creation, sending back the identifica- tion of the newly created connection. (There is no need to transmit a session description in the case of a data call.) 200 1237 OK I: FDE234C8 The Call Agent, knowing that this is a data call, can immediately acknowledge the establishment of the connec- tion, sending an ANM message back to the calling switch. The trunk gateway connects the incoming trunk to a DSP loaded with the specified modem code. Once the call is established, the modem of the calling PC will start a training sequence with the modem associated to the trunk in the trunk gateway. The caller will then proceed to a normal PPP synchronization, which probably implies a PPP login. The authentication parameters, in our example, are checked using Radius. The Radius server that will be used is typically chosen as a function of the called number, which identifies the data service that the cal- ling modem requested. In fact, the number can also be used to identify the specific form of authentication that is requested (but not usually). In our example, the call is completed when the calling modem hangs up. This triggers an ISUP release message, which is forwarded to the Call Agent. The Call Agent will request the NAS to delete the connection: DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 The gateways will respond with a message that should include a "call parameters" header fields: 250 1244 OK P: PS=1245, OS=62345, PR=780, OR=45123 Huitema, Andreasen, Arango, Prakash [Page 79] Internet draft MGCP Call Flows 20 January 1999 We should note that, because this is a data call, the call parameters only include a count of the packets and octets that were sent and received. Huitema, Andreasen, Arango, Prakash [Page 80] Internet draft MGCP Call Flows 20 January 1999 5.2. Outgoing data call through a NAS _____________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Router | | | | ISUP| | | | | |___________|_____|______|____________|_____________|_____|__________| | | | | | | | notices | | | | | | | | packet | | | | | | | | to PC | | | | | | <- | - -| NTFY | | | | | | Ack | - -| -> | | | | | | Decides to | | | | | | | | place an | | | | | | | | outgoing | | | | | | | | call. | | | | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | <- | - - | IAM | | | | (rings) | <- | IAM | | | | | | | ACM| -> | | | | | | | | ACM | - - | -> | | | | (answer) | ANM| -> | | | | | | | | ANM | - - | -> | | | | | | | | Connection | | | | | | | | complete. | | | | | | | | Call | | | | | | | | established| -> | | | PPP | - -| - - | -> | | | | | <- | - -| - - | Validates | | | | | | | | call, | | | | | | | | announces | | | | | | | | IP address| - - | - -| -> | | Connected | | | | | | | | to the | | | | | | | | Internet | | | | | | | | | | | | | | | |___________|_____|______|____________|_____________|_____|__________| Huitema, Andreasen, Arango, Prakash [Page 81] Internet draft MGCP Call Flows 20 January 1999 ___________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Router| | | | ISUP| | | | | |____________|_____|______|____________|____________|_____|________| | Closes | | | | | | | | connection.| | | | | | | | | REL| -> | | | | | | | | REL | - - | -> | | | | | | | <- | Delete | | | | | | | | Connection| | | | | | | ceases | | | | | | | | announcing| | | | | | | | IP address| - - | - -| -> | | | | | Perf | | | | | data | -> | | | | | | | | | <- | - - | RLC | | | | | <- | RLC | | | | | | | | | | Call end | -> | | |____________|_____|______|____________|____________|_____|________| This diagram shows the exchange of messages during a call from an an Internet Service Provider to a modem, using a trunking gateway that doubles as a Network Access Server. During these exchanges the MGCP is used by the Call Agent to control both the NAS, and will also be used between the Call Agent and a default router of the ISP. In the example configuration, the calls are set on demand, when data have to actually be sent from the Internet to the dial-up user. When no connection is established, the local routing is configured to send the packets towards a default router which may or may not be the same machine as the NAS. In redundant configura- tions, there could be many default routers. Each of these default routers has been programmed (through a notification request) to send a notification to the Call Agent when it receives a packet on the default route: NTFY 2005 default-route@router25.whatever.net MGCP 0.1 X: 0123456789AF O: pa(192.96.41.1) After this notification, the Call Agent should send an acknowledgement: Huitema, Andreasen, Arango, Prakash [Page 82] Internet draft MGCP Call Flows 20 January 1999 200 2005 OK (We should note here that using MGCP for this function is a stretch. There are other protocols, notably RMON, that already provide an adequate service. These proto- cols could be used instead of MGCP without affecting the discussion that follows.) The Call Agent deduces from the notification that a cir- cuit should be established towards the dial-up user, or towards the dial-up router. Using configuration data- bases, the Call Agent selects the number that should be called, and also the type of modem parameters and authentication parameters that correspond to the called number. The Call Agent uses its routing table to select an adequate NAS, with an available outgoing trunk. It uses a create connection command to seize this outgoing trunk: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: data X: 0123456789B1 R: cl v=0 m=nas/none c=IN IP4 128.96.41.1 a=subnet:IN IP4 123.45.67.64/26 a=bearer:isdn64 a=framing:ppp-hdlc a=dialed:18001234567 a=dialing:2345678901 The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion. (There is no session description in the case of a data call.) 200 1237 OK I: FDE234C8 Once the trunk has been seized, the Call Agent will send an IAM message to the switch that controls the trunk. The dialed PC will "ring" and eventually take the call, Huitema, Andreasen, Arango, Prakash [Page 83] Internet draft MGCP Call Flows 20 January 1999 triggering the arrival of progress messages and then an answer message (ANM). At that point, the Call Agent knows that the call is established. The DSP associated to the incoming trunk has been loaded with the specified modem code - a simple HDLC framing in our example. Once the call is established, the calling PC will train with the modem associated with the trunk. In our example, no authentication is requested: the Call Agent has identified the dialed user through its called number. Once the association is established and the IP service is validated, the gateway announces that it serves the local user. In our example, there is no address confi- guration performed through PPP: the dialed user has a permanent address, which has been programmed when it subscribed to the service. However, one the circuit is validated, the gateway should start announcing its access to this permanent address in the routing tables. In our example, the dialed station is in fact an access point to a local network, and the NAS should start announcing accessibility of that local network (123.45.67.64/26) through the local routing procedures (an IGP such as RIP, OSPF or EIGRP). Note that the current design makes the hypothesis that the Call Agent "tells" the address of the LAN to the NAS. This is a very debatable design. If a secure IGP is used (e.g. using embedded keyed MD5 authentication, or using IPSEC) then the routing prefix will be naturally exchanged through this IGP. On the other hand, some form of configuration can provide a "double check" against user errors. In our example, the call is completed when the called modem hangs up. This triggers an ISUP release message, which is forwarded to the Call Agent. The Call Agent will request the NAS to delete the connection: DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 The gateways will respond with a message that should include a "call parameters" header fields: Huitema, Andreasen, Arango, Prakash [Page 84] Internet draft MGCP Call Flows 20 January 1999 250 1244 OK P: PS=1245, OS=62345, PR=780, OR=45123 We should note that, because this is a data call, the call parameters only include a count of the packets and octets that were sent and received. 5.3. Call back, using a NAS There are three classic forms of call-back: 1- ANI-based Callback 2- PPP Callback (Microsoft Callback is a variant of this) 3- Login-based callback The ANI based call-back can be implemented entirely in the Call Agent, as indicated in the following diagram: ______________________________________________________________ PC CO SS7/ NAS CA ACC ISUP ______________________________________________________________ dials IAM -> IAM - - -> Notices that the called number corresponds to a call back service, and that the calling number has subscribed to that service. Terminates the incoming call. <- - - REL <- REL RLC -> hangup RLC - - -> Decides to place an outgoing call. Call start -> <- Create Connection (data) Ack -> <- - - IAM (rings) <- IAM Huitema, Andreasen, Arango, Prakash [Page 85] Internet draft MGCP Call Flows 20 January 1999 |________|_____|______|_____|___________________________|_____| The PPP callback suppose that the modem first estab- lishes an incoming connection, and go through the authentication exchange. The following diagram provides an example of these exchanges: Huitema, Andreasen, Arango, Prakash [Page 86] Internet draft MGCP Call Flows 20 January 1999 ____________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Radius| | | | ISUP| | | | | |_________|_____|______|____________|________________|_____|________| | dials in| | | | | | | | | IAM| -> | | | | | | | | IAM | - - | -> | | | | | | | | Checks called | | | | | | | | number. | | | | | | | | Notices | | | | | | | | data call. | | | | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | | | Connection | | | | | | | | completed. | | | | | | | | Call | | | | | | | | established | -> | | | | | <- | - - | ANM | | | | | <- | ANM | | | | | | modem | - -| - - | -> | | | | | <- | - -| - - | handshake | | | | | PPP | - -| - - | -> | | | | | | | | obtain | | | | | | | | user-id, | | | | | | | | password | | | | | | | | Check | - - | - -| -> | | | | | <- | - - | - -| Ack | | | | | reports | | | | | | | | call back | | | | | | | | condition | | | | | | | | NTFY | -> | | | | | | | <- | ACK | | | | | | | | Decides | | | | | | | | to place an | | | | | | | | outgoing call.| | | | | | | <- | Delete | | | | | | | | Connection | | | | | | | Perf | | | | | | | | data | -> | | | | | | <- | - - | REL | | | | | <- | REL | | | | | | | REL| -> | | | | | | hangup | | REL | - - | -> | | | |_________|_____|______|____________|________________|_____|________| Huitema, Andreasen, Arango, Prakash [Page 87] Internet draft MGCP Call Flows 20 January 1999 __________________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Radius| | | | ISUP| | | | | |____________|_____|______|__________________|_____________|_____|________| | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | <- | - - | IAM | | | | (rings) | <- | IAM | | | | | | | ACM| -> | | | | | | | | ACM | - - | -> | | | | (answer) | ANM| -> | | | | | | | | ANM | - - | -> | | | | | | | | Connection | | | | | | | | complete. | | | | | | | | Call | | | | | | | | established| -> | | | PPP | - -| - - | -> | | | | | <- | - -| - - | Validates call, | | | | | Connected | | | | | | | | to the | | | | | | | | Internet | | | | | | | | | | | | | | | | Closes | | | | | | | | connection.| | | | | | | | | REL| -> | | | | | | | | REL | - - | -> | | | | | | | <- | Delete | | | | | | | | Connection | | | | | | | Perf data | -> | | | | | | <- | - - | RLC | | | | | <- | RLC | | | | | | | | | | Call end | -> | | |____________|_____|______|__________________|_____________|_____|________| This diagram shows the exchange of messages during a call from a modem user to an Internet Service Provider, using a trunking gateway that doubles as a Network Access Server. During these exchanges the MGCP is used by the Call Agent to control the NAS. Upon reception of the IAM message, the Call Agent notices that the called number corresponds to a data service. Using configuration databases, the Call Agent Huitema, Andreasen, Arango, Prakash [Page 88] Internet draft MGCP Call Flows 20 January 1999 selects the type of modem parameters and authentication parameters that correspond to the called number and to the calling number. It uses this knowledge to send a connection command to the NAS, programming the incoming trunk: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: data X: 0123456789B1 R: cl, cbk v=0 m=nas/radius c=radius.example.net a=bearer:v.32 a=framing:ppp-asynch a=dialed:18001234567 a=dialing:2345678901 The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion. (There is no session description in the case of a data call.) 200 1237 OK I: FDE234C8 The Call Agent, knowing that this is a data call, can immediately acknowledge the establishment of the connec- tion, sending an ANM message back to the calling switch. The DSP associated to the incoming trunk has been loaded with the specified modem code. Once the call is esta- blished, the modem of the calling PC will be synchron- ized with the modem associated to the trunk. The caller will then proceed to a normal PPP synchronization, which probably implies a PPP login. The login parameters, in our example, are checked using Radius. The Radius server that will be used is typically chosen as a function of the called number, which identifies the data service that the calling modem requested. In fact, the number can also be used to identify the specific form of authentication that is requested. In the call back example, the Radius server will Huitema, Andreasen, Arango, Prakash [Page 89] Internet draft MGCP Call Flows 20 January 1999 indicate that the call cannot be completed as such, and that the user should be called back (for example, using a "Callback Framed" service type in its access-accept response.) The NAS will thus send a Notify message to the Call Agent, indicating that a call-back is requested: NTFY 2005 card23/21@trgw-7.whatever.net MGCP 0.1 X: 0123456789B1 O: cbk(user-id) After this notification, the Call Agent should send an acknowledgement: 200 2005 OK The Call Agent will check that the call back request can be followed through. In its databases, it will find the regular address associated to the "user-id," and prepare to set up a call to that address. It will first clear the incoming call, sending a DeleteConnection command to the NAS: In our example, the call is completed when the calling modem hangs up. This triggers an ISUP release message, which is forwarded to the Call Agent. The Call Agent will request the NAS to delete the connection, and reset the list of observed events: DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 X: 0123456789B2 R: The gateways will respond with a message that should include a "call parameters" header fields: 250 1244 OK P: PS=2, OS=345, PR=1, OR=123 We should note that, because this is a data call, the call parameters only include a count of the packets and octets that were sent and received. Huitema, Andreasen, Arango, Prakash [Page 90] Internet draft MGCP Call Flows 20 January 1999 The Call Agent will then proceed to set up an outgoing data call. This call may be routed through the same NAS that received the incoming call, but can also be routed through an entirely different endpoint , for example if the calling user has moved out of its normal region. Huitema, Andreasen, Arango, Prakash [Page 91] Internet draft MGCP Call Flows 20 January 1999 5.4. Data call to a NAS, using L2TP ________________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| LNS | | | | ISUP| | | | | |___________|_____|______|_______________|______________|_____|_________| | dials in | | | | | | | | | IAM| -> | | | | | | | | IAM | - - | -> | | | | | | | | Check called| | | | | | | | number. | | | | | | | | Notices | | | | | | | | data call. | | | | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | | | Connection | | | | | | | | complete. | | | | | | | | Call | | | | | | | | established | -> | | | | | <- | - - | ANM | | | | | <- | ANM | | | | | | modem | - -| - - | -> | | | | | <- | - -| - - | handshake | | | | | PPP | - -| - - | -> | | | | | | | | obtain | | | | | | | | user-id, | | | | | | | | password | | | | | | | | Establish | | | | | | | | Tunnel | | | | | | | | SCC-REQ | - - | - -| -> | | | | | <- | - - | - -| SCC-REP| | | | | <- | - - | - -| SCC-CON| | | | | IC-REQ | - - | - -| -> | | | | | <- | - - | - -| IC-REP | | | | | <- | - - | - -| IC-CON | | | | | Spoof PPP/LCP| - - | - -| -> | | <- | - -| - - | Relays PPP | - - | - -| -> | | Connected | | | | | | | | to the | | | | | | | | Internet | | | | | | | |___________|_____|______|_______________|______________|_____|_________| Huitema, Andreasen, Arango, Prakash [Page 92] Internet draft MGCP Call Flows 20 January 1999 _______________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| LNS| | | | ISUP| | | | | |____________|_____|______|___________|____________|_____|_____| | Closes | | | | | | | | connection.| | | | | | | | | REL| -> | | | | | | | | REL | - - | -> | | | | | | | <- | Delete | | | | | | | | Connection| | | | | | | Perf | | | | | | | | data | -> | | | | | | <- | - - | RLC | | | | | <- | RLC | | | | | | | | | CDN | - - | - -| -> | | | | | Stop-CC-N| - - | - -| -> | | | | | | Call end | -> | | |____________|_____|______|___________|____________|_____|_____| This diagram shows the exchange of messages during a call from a modem user to an Internet Service Provider, using a trunking gateway that doubles as a Network Access Server. During these exchanges the MGCP is used by the Call Agent to control the NAS. The PPP informa- tion is relayed to a network server (LNS) using L2TP. Upon reception of the IAM message, the Call Agent notices that the called number corresponds to a data service. Using configuration databases, the Call Agent selects the type of modem parameters and authentication parameters that correspond to the called number and to the calling number. It uses this knowledge to send a connection command to the NAS, programming the incoming trunk: CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: data X: 0123456789B1 R: cl v=0 c=IN IP4 access.example.net m=nas/l2tp k=clear:some-shared-secret a=bearer:v.32 Huitema, Andreasen, Arango, Prakash [Page 93] Internet draft MGCP Call Flows 20 January 1999 a=framing:ppp-asynch a=dialed:18001234567 a=dialing:2345678901 The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion. (There is no need to transmit a session descrip- tion in the case of a data call.) 200 1237 OK I: FDE234C8 The Call Agent, knowing that this is a data call, can immediately acknowledge the establishment of the connec- tion, sending an ANM message back to the calling switch. The DSP associated to the incoming trunk has been loaded with the specified modem code. Once the call is esta- blished, the modem of the calling PC will be synchron- ized with the modem associated to the trunk. The caller will then proceed to a normal PPP synchronization, which probably implies a PPP login. Once PPP has been properly synchronized, the NAS estab- lishes a tunnel towards the LNS. Because L2TP is a two- layer protocol, the NAS must first establish an L2TP control connection between itself and the LNS. This con- nection may or may not have been established prior to the call set-up. Tunnel establishment requires a shared secret between the LNS and the NAS; in our example, that secret is passed by the Call Agent, along with the name of the LNS. Once the supporting tunnel is installed, the NAS has to establish an L2TP tunnel, to relay the "incoming call." Once the call is established, the PPP packets received on the trunk will be relayed over the L2TP tun- nel, and vice-versa. In our example, the call is completed when the calling modem hangs up. This triggers an ISUP release message, which is forwarded to the Call Agent. The Call Agent will request the NAS to delete the connection: Huitema, Andreasen, Arango, Prakash [Page 94] Internet draft MGCP Call Flows 20 January 1999 DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 The gateways will respond with a message that should include a "call parameters" header fields: 250 1244 OK P: PS=1245, OS=62345, PR=780, OR=45123 We should note that, because this is a data call, the call parameters only include a count of the packets and octets that were sent and received. 5.5. Basic data call with continuity test Huitema, Andreasen, Arango, Prakash [Page 95] Internet draft MGCP Call Flows 20 January 1999 ___________________________________________________________________ | PC | CO | SS7/| NAS | CA | ACC| Radius| | | | ISUP| | | | | |_________|_____|______|___________|________________|_____|________| | dials in| | | | | | | | | IAM| -> | | | | | | | | IAM | - - | -> | | | | | | | | Check called | | | | | | | | number. | | | | | | | | Notices | | | | | | | | data call, | | | | | | | | continuity | | | | | | | | test. | | | | | | | | Call start | -> | | | | | | <- | Create | | | | | | | | Connection | | | | | | | | (loopback) | | | | | | | Ack | -> | | | | | COT| -> | | | | | | | | COT | - - | -> | | | | | | | <- | Modify | | | | | | | | Connection | | | | | | | | (data) | | | | | | | Ack | -> | | | | | | | | Connection | | | | | | | | is completed. | | | | | | | | Call | | | | | | | | established | -> | | | | | <- | - - | ANM | | | | | <- | ANM | | | | | | modem | - -| - - | -> | | | | | <- | - -| - - | handshake| | | | | PPP | - -| - - | -> | | | | |_________|_____|______|___________|________________|_____|________| This diagram shows the various exchange of messages dur- ing the beginning of a call from a data user on the circuit-switched PSTN to a NAS. During these exchanges the Call Agent uses MGCP to control the NAS and the residential gateway. The circuit switch decides to exe- cute a continuity test during the call establishment. The exchanges occur on two sides. Upon reception of the IAM message, the Call Agent recog- nizes that a continuity test has been requested. It immediately sends a CreateConnection request to the NAS to connect to the incoming trunk, creating a connection: Huitema, Andreasen, Arango, Prakash [Page 96] Internet draft MGCP Call Flows 20 January 1999 CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: loopback X: 0123456789B1 R: cl v=0 m=nas/radius c=IN IP4 radius.example.net a=bearer:v.32 a=framing:ppp-asynch a=dialed:18001234567 a=dialing:2345678901 The trunking gateway recognizes that the mode is set to "loopback". It places the circuit in "loopback" mode (we assume that this is the adequate way to perform con- tinuity test in this specific environment). The gateway is then ready to send back a 2010 Hz return tone if it receives a 2010 Hz test tone. The gateway acknowledges the creation of the connection, sending back the iden- tification of the newly created connection: 200 1237 OK I: FDE234C8 At this point, the call agent is waiting for the result of the continuity test. The calling switch is sending the test tone (2010 Hz); if it receives the return tone (2010 Hz), it will send a "continuity passed" message (COT). At this point, the call agent will send a modify connection message to the NAS, in order to place the connection in "data" mode: MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 M: data The NAS will immediately acknowledge that command: 200 1238 OK The NAS will then proceed with the establishment of the Huitema, Andreasen, Arango, Prakash [Page 97] Internet draft MGCP Call Flows 20 January 1999 modem call. Huitema, Andreasen, Arango, Prakash [Page 98] Internet draft MGCP Call Flows 20 January 1999 6. Audit and Restart The following call flows provide examples of the audit and restart commands. 6.1. Using the Audit commands __________________________________________________________________ | CO | SS7| TGW | CA | CDB | ACC | RGW| Usr| |____|_____|_______|__________________|_______|_______|_____|_____| | | | | | | | | | | | | <- | Audit Endpoint | | | | | | | | | (endpoints) | | | | | | | | Ack | -> | | | | | | | | <- | Audit | | | | | | | | | Endpoint | | | | | | | | | (capabilities) | | | | | | | | Ack | -> | | | | | | | | | | | | | | | | | | Audit Endpoint | - - -| - - -| -> | | | | | | (endpoints) | | | | | | | | | <- | - - -| - - -| Ack| | | | | | Audit Endpoint | - - -| - - -| -> | | | | | | (capabilities) | | | | | | | | | <- | - - -| - - -| Ack| | | | | | | | | | | | IAM| -> | | | | | | | | | IAM| - - -| -> | | | | | | | | | (proceed with | | | | | | | | | call setup) | | | | | | | | | ... | | | | | | | <- | - - -| ANM | | | | | | <- | ANM| | | | | | | | | | | | | | | | | | | <- | Audit Endpoint | | | | | | | | | (misc) | | | | | | | | Ack | -> | | | | | | | | <- | Audit Connection| | | | | | | | Ack | -> | | | | | | | | | | | | | | | | | | Audit Endpoint | | | | | | | | | (misc) | - - -| - - -| -> | | | | | | <- | - - -| - - -| Ack| | | | | | Audit Connection| - - -| - - -| -> | | | | | | <- | - - -| - - -| Ack| | | | | | | | | | | |____|_____|_______|__________________|_______|_______|_____|_____| Huitema, Andreasen, Arango, Prakash [Page 99] Internet draft MGCP Call Flows 20 January 1999 This diagram shows the various exchanges of messages during auditing of a trunk gateway and a residential gateway. First, both gateways are auditing to learn about the endpoints supported by each. Secondly, capa- bilities information is audited for one of these end- points. The procedure is carried out for the residential gateway as well. A call then arrives from the PSTN and is established exactly as described in the "basic call from TGW to RGW". After the call has been established, both endpoints involved in the call are audited -- this time in order to retrieve endpoint info and subsequently connection info associated with the call. The Call Agent initially sends an AuditEndpoint command to the trunking gateway in order to discover what end- points the trunking gateway has: AUEP 1200 *@trgw-7.whatever.net MGCP 0.1 F: Since we use the wildcard naming convention, we cannot retrieve any endpoint specific information but the RequestedInfo field must still be included. Had we specified any RequestedInfo, the trunking gateway would simply have ignored it. The trunking gateway immediately acknowledges the audit- ing command and sends back the list of endpoints it con- tains. Our trunking gateway has two cards in it -- card23 and card24 each supporting two circuits: 200 1200 OK Z: card23/20@trgw-7.whatever.net Z: card23/21@trgw-7.whatever.net Z: card24/20@trgw-7.whatever.net Z: card24/21@trgw-7.whatever.net Now that the Call Agent has learned about the endpoints present in the trunking gateway, it requests capability information for one of the endpoints. We here assume that all similar endpoints have the same capabilities and thus only audit one of them for capabilities, although it is possible that different endpoints have different capabilities: AUEP 1201 card23/20@trgw-7.whatever.net Huitema, Andreasen, Arango, Prakash [Page 100] Internet draft MGCP Call Flows 20 January 1999 F: A The trunking gateway acknowledges the command by return- ing to the Call Agent a response describing the capabil- ities it supports for the endpoint in question: 200 1201 OK L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:T;D, m:sendonly;recvonly;sendrecv;inactive;conttest The Call Agent thereby learns, that the endpoint sup- ports two codecs; G.711 and G.726-32 which can each be used with a packetization period of between 10 and 100 msec. Echo cancellation is supported while silence suppression is not, and the event packages supported are Trunk and DTMF. Since Trunk is the first package speci- fied it is furthermore the default package. Also, con- nections can be established in either of the modes "Send Only", "Receive Only", "Send/Receive", "Inactive", and "Continuity Test". Finally, several parameters were not specified and default or deduced values will therefore apply. These parameters are Bandwidth (deduce from codec), Gain Control (supported), Type of Service (sup- ported), Resource Reservation (best effort), Encryption Key (no encryption), or Type of Network (guess) was pro- vided and default or deduced values for each of these will therefore apply. Next the Call Agent queries the residential gateway to discover what endpoints are present in it: AUEP 2000 *@rgw.whatever.net MGCP 0.1 F: As before, we use the wildcard naming convention and can therefore not retrieve any endpoint specific informa- tion, however the RequestedInfo field must still be included. If any values had been specified for it, they would simply be ignored. The residential gateway acknowledges the command and includes a list of endpoints it contains: 200 2000 OK Z: endpoint/1@rgw-2567.whatever.net Z: endpoint/2@rgw-2567.whatever.net Huitema, Andreasen, Arango, Prakash [Page 101] Internet draft MGCP Call Flows 20 January 1999 The Call Agent thereby learns, that the residential gateway contains the two endpoints endpoint/1 and end- point/2. Having learned about the endpoints present, the Call Agent next requests capability information for one of the endpoints. Again, we assume that all similar endpoints have the same capabilities and thus only audit one of them for capabilities, although it is possible that different endpoints have different capabilities: AUEP 2001 endpoint/1@rgw-2567.whatever.net F: A The residential gateway acknowledges the command by returning to the Call Agent a response describing the capabilities it supports for the endpoint in question: 200 1201 OK L: a:G.711;G.726-32, p:10-100, e:on, s:off, v:L;D, m:sendonly;recvonly;sendrecv;inactive L: a:G.723.1; p:30-90, e:on, s:on, v:L;D, m:sendonly;recvonly;sendrecv;inactive;confrnce The Call Agent thereby learns, that the endpoint sup- ports three codecs; G.711, G.726-32, and G.723.1. G.711 and G.726-32 can each be used with a packetization period of between 10 and 100 msec. Echo cancellation is supported while silence suppression is not, and the event packages supported are Line and DTMF. Since Line is the first package specified it is furthermore the default package. Also, connections can be established in either of the modes "Send Only", "Receive Only", "Send/Receive", and "Inactive". Finally, several parame- ters were not specified and default or deduced values will therefore apply. These parameters are Bandwidth (deduce from codec), Gain Control (supported), Type of Service (supported), Resource Reservation (best effort), Encryption Key (no encryption), or Type of Network (guess) was provided and default or deduced values for each of these will therefore apply. G.723.1 can be used with a packetization period of between 30 and 90 msec. Both echo cancellation and silence suppression are supported, and the event pack- ages supported are Line and DTMF with Line being the default package. Connections can be established in Huitema, Andreasen, Arango, Prakash [Page 102] Internet draft MGCP Call Flows 20 January 1999 either of the modes "Send Only", "Receive Only", "Send/Receive", "Inactive", and "Conference". Finally, default or deduced values will be applied for the param- eters that were not supplied. The Call Agent now knows all endpoints as well as their capabilities in the trunking and the residential gate- way. An IAM signaling a call for the residential gateway now arrives from the PSTN. The call is then setup as described in Section 2.2. After the call has been suc- cessfully setup, the Call Agent now decides to audit the endpoint in the trunking gateway for information about RequestedEvents, DigitMap, SignalRequests, RequestIden- tifier, NotifiedEntity, ConnectionIdentifiers, and DetectEvents: AUEP 1202 card23/21@trgw-7.whatever.net MGCP 0.1 F: R,D,S,X,N,I,T The trunking gateway acknowledges the command by return- ing to the Call Agent a response with the requested info for the endpoint in question: 200 1202 OK R: D: S: X: N: [128.96.41.12] I: FDE234C8, ABCD123 T: The Call Agent thus sees, that there are currently no RequestedEvents, no DigitMap, no SignalRequests, no RequestIdentifier, and no DetectEvents for the endpoint in question. Instead of supplying empty list for these parameters, the gateway could simply have omitted them altogether in the response. In the last command the call agent sent to the endpoint, it had not specified a NotifiedEntity, thus the notified entity returned here is the source IP address of the call agent encoded in RFC 821 format. Finally, the end- point currently has two connections associated with it. Huitema, Andreasen, Arango, Prakash [Page 103] Internet draft MGCP Call Flows 20 January 1999 The first one was created during the call setup. Depend- ing on previous message exchanges, the second one may or may not be valid. If the call agent believes it is stale, it could simply instruct the gateway to delete it. In this case, the Call Agent decides to audit the con- nection FDE234C8 for further information and it there- fore sends an AuditConnection command to the endpoint for information about CallId, NotifiedEntity, LocalCon- nectionOptions, Mode, LocalConnectionDescriptor, RemoteConnectionDescriptor, and ConnectionParameters: AUCX 1203 card23/21@trgw-7.whatever.net MGCP 0.1 I: FDE234C8 F: C,N,L,M,LD,RD,P When the trunking gateway receives the command it immediately sends a response to the Call Agent with the requested info: 200 1203 OK C: A3C47F21456789F0 N: [128.96.41.12] L: p:10, a:G.711;G.726-32 M: sendrecv P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 v=0 c=IN IP4 128.96.41.1 m=audio 1296 RTP/AVP 0 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 Thus the CallId, LocalConnectionOptions, and Mode are as expected for this connection. The same holds for the RemoteConnectionDescriptor which is supplied as the last parameter separated by an empty line. The last connec- tion handling command issued to the endpoint for this connection did not include the NotifiedEntity parameter, so the notified entity defaults to the source IP address for that command which is encoded in RFC 821 format. Finally, the Call Agent also obtained the current packet statistics for the call. Huitema, Andreasen, Arango, Prakash [Page 104] Internet draft MGCP Call Flows 20 January 1999 Next, the Call Agent audits the endpoint in the residen- tial gateway for information about RequestedEvents, DigitMap, SignalRequests, RequestIdentifier, NotifiedEn- tity, ConnectionIdentifiers, and DetectEvents: AUEP 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 F: R,D,S,X,N,I,T The trunking gateway acknowledges the command by return- ing to the Call Agent a response with the requested info for the endpoint in question: 200 2002 OK R: L/hu D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) S: X: 0123456789B1 N: [128.96.41.12] I: 32F345E2 T: hu The Call Agent thus sees, that currently, the only event being looked for is the "On hook" event from the Line package. Since the Line package is the default package, the gateway could have simply specified this as "hu" instead. Although the residential gateway is currently not accumulating any digits, a digit map is still sup- plied. This digit map is the last one used by the end- point used -- we here assume the endpoint was previously originated a call, e.g. as in Section 2.1. There are currently no signals being applied so the SignalRequests parameter is simply empty. There is however an active NotificationRequest thus the RequestIdentifier for that one is supplied. As before, no NotifiedEntity has been specified for the last NotificationRequest for this end- point, so the source IP address of that request is sup- plied as the notified entity. There is only one Connec- tionId for this endpoint, namely 32F345E2 as expected. Finally, since the last NotificationRequest did not specify any special value for DetectEvents, this parame- ter simply defaults to the same as RequestedEvents. In this case we omitted the specification of the Line pack- age in the event name since the Line package is the default package for this endpoint. Having audited the endpoint, the Call Agent decides to Huitema, Andreasen, Arango, Prakash [Page 105] Internet draft MGCP Call Flows 20 January 1999 audit the connection for that endpoint and the Call Agent therefore sends an AuditConnection command to the requesting information about CallId, NotifiedEntity, LocalConnectionOptions, Mode, LocalConnectionDescriptor, RemoteConnectionDescriptor and ConnectionParameters. AUCX 2003 endpoint/1@rgw-2567.whatever.net MGCP 0.1 I: 32F345E2 F: C,N,L,M,LD,RD,P When the residential gateway receives the command it immediately sends a response to the Call Agent with the requested info: 200 2003 OK C: A3C47F21456789F0 N: [128.96.41.12] L: p:10, a:G.711;G.726-32 M: sendrecv v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 v=0 c=IN IP4 128.96.41.1 m=audio 1296 RTP/AVP 0 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 Thus the CallId, LocalConnectionOptions, and Mode are as expected for this connection. The same holds for the LocalConnectionDescriptor which is supplied as the last parameter separated by an empty line. The last connec- tion handling command issued to the endpoint for this connection did not include the NotifiedEntity parameter, so the notified entity defaults to the source IP address for that command which is encoded in RFC 821 format. Finally, the Call Agent also obtained the current packet statistics for the call. Huitema, Andreasen, Arango, Prakash [Page 106] Internet draft MGCP Call Flows 20 January 1999 6.2. Using the RestartInProgress command __________________________________________________________________ | Management System | TGW | CA-1 | CA-2| |_________________________|________________________|_______|______| | | | | | | Preparing for taking | | | | | endpoints out of | | | | | service when idle. | RSIP | -> | | | | (graceful: indefinite)| | | | | <- | Ack | | | | | | | | Preparing to take | | | | | endpoints out of | | | | | service in 5 minutes | RSIP | -> | | | (graceful: 5 min) | | | | | | <- | Ack | | | | | | | | Circuit failure leads | | | | | to an endpoint becoming | | | | | unavailable. | RSIP | -> | | | (forced: 0 min) | | | | | | <- | Ack | | | | | | | | Courtesy message | | | | | that all endpoints are | | | | | now out of service | RSIP | -> | | | (forced: 0 min) | | | | | | <- | Ack | | | | | | | | All endpoints back | | | | | in service | RSIP | - - -| -> | | (restart: 0 min) | | | | | | <- | - - -| Ack | | | | | | |_________________________|________________________|_______|______| This diagram shows the various exchanges of messages during restart of some of the endpoints in a trunking gateway. Our example assumes the existence of an exter- nal management system controlling the gateway, and the resulting changes in endpoint availability are then com- municated to the Call Agent via the RestartInProgress command. First all endpoints are to be taken out-of- service gracefully, and later a warning is sent to the Call Agent, that all endpoints will now be taken out of service within 5 minutes. Following this, we assume a Huitema, Andreasen, Arango, Prakash [Page 107] Internet draft MGCP Call Flows 20 January 1999 problem occurs on the gateway resulting in the immediate unavailability of a circuit. A little later, the gateway then informs the Call Agent that all endpoints are now out of service. Finally, we assume that the trunking gateway rebooted and placed all endpoints back in ser- vice which the gateway informs its default Call Agent about. The trunking gateway initially sends a RestartInProgress command to the Call Agent (CA-1) informing it of an intention to take all endpoints out of service: RSIP 1200 *@trgw-7.whatever.net MGCP 0.1 RM: graceful RD: 0 The Call Agent thereby sees, that the trunking gateway is planning on making all its endpoints unavailable gracefully. Since the restart delay is specified to be zero, the Call Agent furthermore knows, that it can safely leave all existing connections on the gateway, however it should not attempt to establish any new con- nections for these endpoints -- or at least only estab- lish connections related to existing calls. The Call Agent immediately acknowledges the command: 200 1200 OK Later, the external management system decides that it will no longer wait indefinitely for the existing con- nections to cease to exist. The gateway therefore sends a RestartInProgress message to the Call Agent informing it, that all the endpoints will become unavailable within 5 minutes (300 seconds), and any connections existing at that point in time will be torn down: RSIP 1201 *@trgw-7.whatever.net MGCP 0.1 RM: graceful RD: 300 The Call Agent immediately acknowledges the command: 200 1201 OK Huitema, Andreasen, Arango, Prakash [Page 108] Internet draft MGCP Call Flows 20 January 1999 The Call Agent now has 5 minutes to tear down any exist- ing connections. Before the 5 minutes have elapsed, we imagine a hardware problem develops with one of the circuits on card23 in the trunking gateway and that the circuit immediately must be taken out service. The gateway informs the Call Agent about this by issuing the RestartInProgress com- mand as follows: RSIP 1202 card23/20@trgw-7.whatever.net MGCP 0.1 RM: forced In this case, no restart delay was specified since a "forced" restart always takes effect immediately. If a restart delay had been specified, it would simply have been ignored. Any connections that existed for the end- point will have been lost. The Call Agent immediately acknowledges the command and notes that card23/20 is out of service: 200 1202 OK A little later, the 5 minutes grace period the Call Agent was notified about earlier has now passed, and - as a courtesy - the trunking gateway informs the Call Agent that all endpoints have now been taken out of ser- vice: RSIP 1203 *@trgw-7.whatever.net MGCP 0.1 RM: forced Although the Call Agent has already been informed that card23/20 is out of service, the trunking gateway includes it in the list of endpoints here anyway. This is perfectly valid since placing an out-of-service end- point in out-of-service can be considered idempotent as long as the gateway deletes all connections associated with those endpoints (out-of-service endpoints should not have any connections created on them). However, this would not be the case with placing in-service endpoints in-service as such operations have side-effects on existing connections. In that case, the Call Agent would Huitema, Andreasen, Arango, Prakash [Page 109] Internet draft MGCP Call Flows 20 January 1999 therefore assume, that endpoints already in-service had been restarted to be in-service again. The Call Agent immediately acknowledges the command: 200 1203 OK At this point, all endpoints in the trunking gateway are now out of service. We then assume that the trunking gateway is rebooted and all endpoints are placed back in service. After the reboot, the trunking gateway informs its default Call Agent (CA-2), that all its endpoints are now back in service by sending the following RestartInProgress com- mand: RSIP 1204 *@trgw-7.whatever.net MGCP 0.1 RM: restart RD: 0 Since the restart delay specified is zero, all endpoints are in-service at this point in time. However, it should be noted, that this does not necessarily imply that the same endpoints are available as before. For instance, card23 could have been removed from the trunking gateway to correct the aforementioned circuit problem. The Call Agent (CA-2) recognizes that CA-1 is the pre- ferred Call Agent for this trunking gateway and when CA-2 acknowedges the command, it therefore includes CA-1 as the NotifiedEntity. Furthermore, CA-2 notes that any connections that may have existed for these endpoints prior to receiving this command no longer exists. CA-2 is expected to communicate this information to CA-1 in order to achieve the internal Call Agent synchronization required: 200 1204 OK N: CA-1@whatever.net Huitema, Andreasen, Arango, Prakash [Page 110] Internet draft MGCP Call Flows 20 January 1999 7. Using MGCP to control an IVR This section describes the call flows between the CA,MG and IVR in order to understand the way MGCP organises the communication between the Media gateway controller/call agent and the Media gateway or an IVR. The IVR is controlled by the call agent using only the existing MGCP primitives. The number of calls that an IVR can support is defined as the number of endpoints on that IVR. These end points may be maintained by the IVR itself in which case the Call agent always uses wildcards for createconnection or it may be maintained by the Call agent. There are a variety of scripts that can be executed on a particular ivr endpoint.They may be as simple as just playing a message (in which case the IVR is used as a simple anouncement server) or playing a message collect digits and give it to the call agent or as complex as an admin- istrative script which allows a remote administrator to configure the call agent . The format of the script and the implementation of the script may be vendor specific. The only assumtion is that the call agent is pre config- ured with the script names and it knows what script to use when. The MGCP primitives are interpreted by the IVR in the following way CreateConnection: When this command is received by the IVR it allo- cates the resources and returns the RTP profile associated with the logical endpoint. The connec- tion mode should always be inactive. Note that the IVR starts executing the script if the connection mode is not set to inactive. ModifyConnection: This is used by the Call agent to trigger the exe- cution of the script. Here the connection mode is set to sendrecv.If it is set to sendonly the IVR can play message or tones but cannot collect dtmf. NotificationRequest: Huitema, Andreasen, Arango, Prakash [Page 111] Internet draft MGCP Call Flows 20 January 1999 Notifies the Call agent when the script has fin- ished executed and returns the result.For now the result is only in the form of digits. DeleteConnection: Stops executing the script if it is not already terminated and frees the resources. NOTE : The call flows do not show the Delete connection on the Incoming side when the IVR terminates. This is because the incomming call may be routed to another des- tination by the call agent depending on the notification results got from the IVR. 7.1. Connecting a Residential Gateway to the IVR 7.1.1. Connection from RGW to IVR __________________________________________ | USER | RGW | CA | IVR | |__________|________|_____________|_______| | | <-- | RQNT | | | | ACK | --> | | | OFF HOOK | NTFY | --> | | | | <-- | ACK | | | | <-- | CRCX+RQNT | | | | ACK | --> | | | | | CRCX+RQNT | --> | | | | <-- | ACK | | | <-- | MDCX | | | | ACK | --> | | | | | MDCX | --> | | | | <-- | ACK | |__________|________|_____________|_______| The first command is a NotificationRequest, sent by the Call Agent to the residential gateway. The request will consist of the following lines: RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: hd The gateway immediately acknowledges the command, Huitema, Andreasen, Arango, Prakash [Page 112] Internet draft MGCP Call Flows 20 January 1999 repeating in the acknowledgement message the transaction id that the Call Agent attached to the query. 200 1201 OK When the off hook event is noticed the gateway will notify the event to the Call Agent: NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: hd The Call Agent immediately acknowledges that notifica- tion. 200 2002 OK The Call Agent will then seize the incoming circuit, creating a connec- tion. The create connection command piggybacks a notification request, to watch for an on- hook transition: CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly X: D123456789AD R: hu The gateway immediately acknowledges the creation, send- ing back the identification of the newly created connec- tion and the session descrip- tion used to receive audio data: 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 Huitema, Andreasen, Arango, Prakash [Page 113] Internet draft MGCP Call Flows 20 January 1999 The Call Agent, having seized the incoming trunk and deciding that the call has to be terminated on the IVR and that a script will be executed, sends a connection command to the IVR. CRCX 1205 #@ivr45.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: inactive v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The CreateConnection is sent to a generic endpoint, asking the IVR to pick one of its available ports. The IVR will acknowledge the connection command, sending in the identification of the selected endpoint, the con- nection identifier and the session description its own parameters such as address, ports and RTP profile: 200 1205 OK Z:17@ivr45.whatever.net I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent will relay the information to the Media gateway, using a ModifyConnection command: MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 Huitema, Andreasen, Arango, Prakash [Page 114] Internet draft MGCP Call Flows 20 January 1999 The media gateway immediately acknowledges the modifica- tion: 200 1206 OK At this point the caller is ready, a duplex path has been established between the caller and the IVR, all the resources have been allocated and the Call agent has to trigger the script execution. It does this by sending a ModificationRequest with an embedded NotificationRequest command to the IVR. MDCX 1207 17@ivr45.whatever.net MGCP 0.1 C: A3C47F21456789F0 M: sendrecv X: D23456789AD R: Script/oc, Script/of D: Script/perl(http://database.whatever.net/script-23.prl) The IVR immediately acknowledges the modification: 200 1207 OK At this point the caller is interacting with the IVR. This ends with either the caller going on hook or the IVR deciding it has to notify the Call agent. 7.1.2. Disconnecting the user from IVR:(termination by IVR) ____________________________________ | USER | RGW | CA | IVR | |______|_______|__________|_________| | | | <-- | NTFY | | | | ACK | --> | | | | DLCX-- | --> | | | | <-- | ---ACK| |______|_______|__________|_________| When the call agent receives NTFY 2002 17@ivr45.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: D23456789AD Huitema, Andreasen, Arango, Prakash [Page 115] Internet draft MGCP Call Flows 20 January 1999 O: script/oc(54321) The Call agent immediately acknowledges the notifica- tion: 200 2002 OK and send a delete connection to the IVR DLCX 1211 script23/21@ivr45.whatever.net MGCP 0.1 C: 567F21456789F0 I:32F345E2 the IVR frees up the resources and responds with 200 1211 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 The call agent may now deal with the incoming call by sending a delete connection, execute another script on the IVR, or route the call to another gateway, and so on. 7.1.3. Disconnecting The User From Ivr:(Termination By Caller) ___________________________________ | USER | RGW | CA | IVR | |_________|_______|________|_______| | On hook | NTFY| --> | | | | <-- | ACK | | | | | DLCX | --> | | | | <-- | ACK | | | <-- | DLCX | | | | ACK | --> | | |_________|_______|________|_______| When the call agent receives NTFY 2056 endpoint/1@rgw-2567.whatever.net MGCP 0.1 N: ca@ca1.whatever.net:5678 X: D123456789AD O: hu Huitema, Andreasen, Arango, Prakash [Page 116] Internet draft MGCP Call Flows 20 January 1999 it responds with 200 2056 OK and deletes the connections on both the IVR DLCX 1211 17@ivr45.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 IVR frees up the resources and responds with 200 1211 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 and the media gateway DLCX 1261 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 Gateway frees up the resources and responds with 200 1261 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48 7.2. Connection between a TGW and an IVR 7.2.1. Setting up the connection from TGW to IVR The figure below gives the flow for the IVR connected to a TGW Huitema, Andreasen, Arango, Prakash [Page 117] Internet draft MGCP Call Flows 20 January 1999 ___________________________________________ | SS7/ISUP | TGW | CA | IVR | |__________|_______|_______________|_______| | IAM | --- | --> | | | | <-- | CRCX | | | | ACK | --> | | | <-- | --- | ACM | | | | | CRCX+RQNT-->| | | | <-- | ---ACK | | | | <-- | -MDCX | | | | ACK | --> | | | <-- | --- | ANM | | | | | MDCX | --> | | | <-- | ----ACK | | |__________|_______|_______________|_______| When the CA detects an incoming call it sends a CreateConnection command to the media gateway. CRCX 1204 ss7end/1@tgw90.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: recvonly The media gateway responds with 200 1204 OK I:FDE234C8 v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The CA then creates a connection on the IVR CRCX 1205 #@ivr45.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:G.711;G.726-32 M: inactive v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 Huitema, Andreasen, Arango, Prakash [Page 118] Internet draft MGCP Call Flows 20 January 1999 The IVR will acknowledge the connection command, sending in the session description its own parameters such as address, ports and RTP profile: 200 1205 OK Z: 17@ivr45.whatever.net I:32F345E2 v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent will relay the information to the Media gateway, using a ModifyConnection command: MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 M: sendrecv v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The media gateway immediately acknowledges the modifica- tion: 200 1206 OK At this point the caller is ready,a duplex path has been established between the caller and the IVR ,all the resources have been allocated and the Call agent has to trigger the script execution. It does this by sending a ModifyConnection command to the IVR, with an embedded notification request. MDCX 1206 17@ivr45.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:32F345E2 X: D23456789AD M: sendrecv R: Script/oc, Script/of D: Script/perl(http://database.whatever.net/script-12.prl) Huitema, Andreasen, Arango, Prakash [Page 119] Internet draft MGCP Call Flows 20 January 1999 The IVR immediately acknowledges the modification: 200 1206 OK At this point the caller is interacting with the IVR.This ends with either the caller going on hook or the IVR deciding it has to notify the Call agent. 7.2.2. Disconnecting The User From IVR:TGW Termination by the IVR: ________________________________________ | SS7/ISUP | TGW | CA | IVR | |__________|_______|__________|_________| | | | <-- | --NTFY| | | | ACK-- | --> | | | | DLCX-- | --> | | | | <-- | ---ACK| |__________|_______|__________|_________| 7.2.3. Termination by the Caller ______________________________________________________ | SS7/ISUP | TGW | CA | IVR | | REL | --- | --> | | | | | | | | | | DLCX | --> | | | | <-- | ACK | | | <-- | -DLCX | | | | ACK | --> | | | <-- | --- | RLC | | |__________|_______|__________________________|_______| Huitema, Andreasen, Arango, Prakash [Page 120] Internet draft MGCP Call Flows 20 January 1999 7.3. Hairpin IVR connection, double end-point model The figure below gives the flow that results in an hair- pin connection to an IVR device located on the same gateway as the trunk on which the call is incoming. In this flow, we assume that we use the "double endpoint" extensions to the create-connection command, and, as an example, assume that the IVR exchange results in an automatic disconnection. _________________________________________ | sw1| sw2| SG | CA | TGW-1| IVR | |____|_____|_____|_______|_______|_______| | IAM| - -| -> | | | | | | | IAM| -> | | | | | | | CRCX+| -> | (->) | | | | | RQNT | -> | (->) | | | | | <- | ACK | (ACK)| | | | <-| ANM | | | | <-| - -| ANM| | | | | | | | <- | - - | NTFY | | | | | ACK | - - | -> | | | | | DLCX | -> | | | | | | <- | Perf | | | | | | | data | | | | | <-| REL | | | | <-| - -| REL| | | | | | | | DLCX | | -> | | | | | <- | - - | Perf | | | | | | | data | |____|_____|_____|_______|_______|_______| During these exchanges the MGCP is used by the Call Agent to control two endpoints located on the same TGW. The exchanges start with the arrival from the first switch (SW1) of an SS7/ISUP "IAM" message, relayed by the signalling gateway to the Call Agent. The call agent performs the routing, and determines that the call will have to be relayed towards the second switch (SW2), using a trunk located on the same gateway. The call agent starts the exchange by seizing the end- point referenced in the IAM message, and by requesting a local connection between that endpoint and the IVR dev- ice. The command also instruct the IVR to start execut- ing a script on the selected IVR endpoint: Huitema, Andreasen, Arango, Prakash [Page 121] Internet draft MGCP Call Flows 20 January 1999 CRCX 1204 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 L: nt=LOCAL M: sendrecv 2/E: IVR/$ 2/X: D23456789AD 2/R: Script/oc, Script/of 2/D: Script/perl(http://database.whatever.net/script-12.prl) Upon reception of that command, the trunking gateway prepares a "local" connection description between the specified endpoint (trunk-group-1/17) and an endpoint that it selects within the IVR (IVR/6). The gateway acknowledges the two creations in a single message: 200 1204 OK I:FDE234C8 v=0 c=IN tgw.whatever.net trunk-group-1/17 m=audio 0 LOCAL 0 2/Z:IVR/13@tgw.whatever.net 2/I:abc0 2/ v=0 c=IN tgw.whatever.net IVR/13 m=audio 0 LOCAL 0 The command has created a path between the endpoint and the IVR. Because the IVR is in fact answering the call, the call agent can immediately relay an ANM message to the calling switch. At this point the caller is interacting with the IVR. This ends with either the caller going on hook or the IVR deciding it has to notify the Call agent. NTFY 2001 IVR/13@tgw.whatever.net MGCP 0.1 X: D23456789AD O: Script/oc(123245) The call agent immediately acknowledges the notifica- tion: 200 2001 OK Huitema, Andreasen, Arango, Prakash [Page 122] Internet draft MGCP Call Flows 20 January 1999 The call agent should then remove the connections. The call agent releases the connection on the first end- point: DLCX 1207 trunk-group-1/17@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:FDE234C8 The gateway acknowledges the deletion, sending the con- nection parameters: 250 1217 OK P: OS=62345, OR=62345 The call agent can now notify the release of the trunk to the switch which will in response send an RLC mes- sage. In parallel, the call agent releases the connection to the IVR: DLCX 1208 IVR/13@tgw.whatever.net MGCP 0.1 C: A3C47F21456789F0 I:abc0 The gateway acknowledges the deletion, sending the con- nection parameters: 250 1218 OK P: OS=62345, OR=62345 Huitema, Andreasen, Arango, Prakash [Page 123] Internet draft MGCP Call Flows 20 January 1999 8. Acknowledgements We want to thank here the many reviewers who helped design the MGCP flows, notably Ike Elliott and Chip Sharp. 9. References [0] Arango, M., A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Media Gateway Control Protocol (MGCP)", work in progress. [1] ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIP- TION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; modified at Hel- sinki, 1993) [2] ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIGNALS OF THE ISDN USER PART OF SIG- NALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993) * ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYS- TEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE." * ITU-T, Recommendation H.225, "Call Signaling Proto- cols and Media Stream Packetization for Packet Based Multimedia Communications Systems." * ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-TELEPHONE SIGNALS." * Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", work in progress 10. Authors' Addresses Christian Huitema Bellcore MCC 1J236B 445 South Street Morristown, NJ 07960 U.S.A. Phone: +1 973-829-4266 EMail: huitema@bellcore.com Huitema, Andreasen, Arango, Prakash [Page 124] Internet draft MGCP Call Flows 20 January 1999 Flemming Andreasen Bellcore RRC-1M223 444 Hoes Lane Piscataway, NJ 08854-4157 U.S.A. Phone: +1 732 699-7351 EMail: fandreas@notes.cc.bellcore.com Mauricio Arango RSL COM Latin America 6300 N.W. 5th Way, Suite 100 Ft. Lauderdale, FL 33309 Phone: (954) 492-0913 Email: marango@rslcom.com Prakash K TELESOFT INC 3000, Custer Road Suite 270 Plano, Texas - 75075 U.S.A Tel: 972-596-4158 Fax: 817-323-1605 EMail: prakashk@indts.com Huitema, Andreasen, Arango, Prakash [Page 125]