Internet Engineering Task Force Christian Huitema INTERNET DRAFT Flemming Andreasen Bellcore November 11, 1998 Mauricio Arango Expires: May 11, 1998 RSL COM Media Gateway Control Protocol (SGCP) Call Flows Christian Huitema, Flemming Andreasen, Mauricio Arango November 11, 1998 Status of this document 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. 1. Introduction In order to understand the way the MGCP interface will be used, we have described here two possible call flows between a TGW, which is a trunk- ing gateway that implements MGCP, and an RGW, which is a residential Huitema, Andreasen, Arango [Page 1] Internet draft MGCP Call Flows 11 November 1998 gateway that implements MGCP, as well as four 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 packages 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 [Page 2] Internet draft MGCP Call Flows 11 November 1998 2. Internet Telephony Call Flows. We present five Internet Telephony call flows: * 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". 2.1. 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 Huitema, Andreasen, Arango [Page 3] Internet draft MGCP Call Flows 11 November 1998 | | Ack | -> | | | | | | | | (cut in)| Call start | - -| -> | | | | |_______|__________|______________|_____|_____|__________|______|_____| __________________________________________________________________ | 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 command, repeating in the Huitema, Andreasen, Arango [Page 4] Internet draft MGCP Call Flows 11 November 1998 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 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 connec- tion. The create connection commands piggybacks 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: 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 session descrip- tion used to receive audio data: 200 1204 OK I:FDE234C8 Huitema, Andreasen, Arango [Page 5] Internet draft MGCP Call Flows 11 November 1998 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 pro- tocol (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" attri- bute 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 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 CreateConnection command has the same parameters as the command 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 connec- tions. 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 Huitema, Andreasen, Arango [Page 6] Internet draft MGCP Call Flows 11 November 1998 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 1296 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The Call Agent will relay the information to the ingress gateway, 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 modification: 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 announcements, 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 complete" message (ACM). The Call Agent will analyze the message to determine whether sig- nal are transmitted in band. If this is not the case, the Call Agent will instruct the RGW to generate ringing tones by sending a Notifica- tionRequest: RQNT 1207 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AE R: hu S: v Huitema, Andreasen, Arango [Page 7] Internet draft MGCP Call Flows 11 November 1998 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 residential 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 Huitema, Andreasen, Arango [Page 8] Internet draft MGCP Call Flows 11 November 1998 250 1211 OK P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48 At this point, 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 NotificationRequest 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 acknowledgement: 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 [Page 9] Internet draft MGCP Call Flows 11 November 1998 2.2. 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 [Page 10] Internet draft MGCP Call Flows 11 November 1998 _____________________________________________________________ | 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 con- nected 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 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: 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: Huitema, Andreasen, Arango [Page 11] Internet draft MGCP Call Flows 11 November 1998 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 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 pro- tocol (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" attri- bute 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 command 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 connec- tions. This is normal: the two connection belong to the same call, which Huitema, Andreasen, Arango [Page 12] Internet draft MGCP Call Flows 11 November 1998 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 gateway, 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 NotificationRequest, consisting of the fol- lowing 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 acknowledge the command, Huitema, Andreasen, Arango [Page 13] Internet draft MGCP Call Flows 11 November 1998 repeating in the acknowledgement message 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 ring- ing 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 Notifica- tionRequest 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 The trunking gateway will acknowledge that command: Huitema, Andreasen, Arango [Page 14] Internet draft MGCP Call Flows 11 November 1998 200 1242 OK The Call Agent can now send an answer message (ANM) to the calling 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 [Page 15] Internet draft MGCP Call Flows 11 November 1998 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 [Page 16] Internet draft MGCP Call Flows 11 November 1998 2.3. Basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW _______________________________________________________________________________________ | CO | R2 | CA | CDB| ACC| TGW | SS7/| CO | | | TGW | | | | | ISUP| | |_______|____________|________________|_______|_______|______________|________|_______| | | <- | Notification| | | | | | | | | Request | | | | | | | | Ack | -> | | | | | | |Trunk | | | | | | | | |seizure| | | | | | | | | & | | | | | | | | |Called | | | | | | | | |&callng| | | | | | | | |number | | | | | | | | |digit | | | | | | | | |collec-| | | | | | | | |tion | -> | | | | | | | | | Notify | -> | | | | | | | | <- | Ack | | | | | | | | <- | Notification| | | | | | | | | Request | | | | | | | | Ack | -> | | | | | | | | <- | Create | | | | | | | | | Connection | | | | | | | | Ack | -> | | | | | | | | | Query | | | | | | | | | (E.164 S,D) | -> | | | | | | | | <- | IP | | | | | | | | Create | | | | | | | | | Connection | - -| - -| -> | | | | | | | | | (cut in) | | | | | | <- | - -| - -| ack | | | | | | IAM | - -| - -| - - | -> | | | | <- | Modify | | | | IAM | -> | | | | Connection | | | | | | | | Ack | -> | | | | <- | ACM| | | | <- | - -| - -| - - | ACM | | | | | | | | | <- | ANM| | | | <- | - -| - -| - - | ANM | | | | <- | Modify | | | | | | | | | Connection | | | | | | | | Ack | -> | | | | | | | | (cut in)| Call start | - -| -> | | | | |_______|____________|________________|_______|_______|______________|________|_______| Huitema, Andreasen, Arango [Page 17] Internet draft MGCP Call Flows 11 November 1998 _________________________________________________________________________________ | CO | R2 | CA | CDB| ACC| TGW | SS7/| CO | | | TGW | | | | | ISUP| | |________|__________|________________|_______|_______|_________|________|_______| | | | | | | | <- | REL| | | | <- | - -| - -| - - | REL | | | | | Delete | | | | | | | | <- | Connection | | | | | | | | | | | | | | | | | Clear- | | | | | | | | <- | back | Delete | | | | | | | Clear- | | Connection | - -| - -| -> | | | | fwd | -> | | | | | | | | | Rel- | | | | | | | | <- | guard | | | | | | | | | | | | | | | | | | Perf | | | | | | | | | Data | -> | | | | | | | | | <- | - -| - -| Perf | | | | | | | | | data | | | | | | Call end | - -| -> | | | | | | <- | Notification| | | | | | | | | Request | | | | | | | | Ack | -> | | | | | | |________|__________|________________|_______|_______|_________|________|_______| The above diagram describes the call flow between a trunk with R2 sig- naling in a trunking gateway and an SS7 trunk in a trunking gateway. R2 is a type of Channel Associated Signaling (CAS) and this call flow assumes the use of an R2 package. The following diagram describes a sim- plified R2 package. In this package digit arrival events are not observed by the Call Agent and therefore cannot be part of a Notifica- tionRequest. 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 (destina- tion) and calling (source) and calling party numbers from the R2 regis- ters. 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 [Page 18] Internet draft MGCP Call Flows 11 November 1998 |_________|______________________|_______|________________________| 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 destination (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 [Page 19] Internet draft MGCP Call Flows 11 November 1998 The gateway immediately acknowledges the creation, sending back the identification of the newly created connection 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 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 v=0 Huitema, Andreasen, Arango [Page 20] Internet draft MGCP Call Flows 11 November 1998 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 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. 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 connection 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 P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 Huitema, Andreasen, Arango [Page 21] Internet draft MGCP Call Flows 11 November 1998 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 [Page 22] Internet draft MGCP Call Flows 11 November 1998 2.4. Basic call from an ISDN trunk in a business gateway to an SS7 trunk in a TGW ______________________________________________________________________________________________________ | PBX | Business | CA | CDB| ACC | TGW | SS7/| CO | | | | GW | | | | | ISUP| | | | - | | | | | | | | | |SETUP | -> | -> | | | | | | | | <- | <- | CALLPROC. | | | | | | | | | <- | Create | | | | | | | | | | Connection | | | | | | | | | Ack | -> | | | | | | | | | | Query | | | | | | | | | | (E.164 S,D) | -> | | | | | | | | | <- | IP | | | | | | | | | Create | | | | | | | | | | Connection | - -| - - | -> | | | | | | | | | | (cut in) | | | | | | | <- | - -| - - | ack | | | | | | | IAM | - -| - - | - - | -> | | | | | <- | Modify | | | | IAM | -> | | | | | Connection | | | | | | | | | Ack | -> | | | | <- | ACM| | | | | <- | - -| - - | - - | ACM | | | | <- | <- | ALERT | | | | | | | | | <- | Notification | | | | | | | | | | Request | | | | | | | | | Ack | -> | | | | | | | | <- | Ringing | | | | | | | | | | | | | | | <- | ANM| | | | | <- | - -| - - | - - | ANM | | | | | <- | RQNT+MDCX | | | | | | | | | Ack | -> | | | | | | | | | (cut in)| Call start | - -| -> | | | | | |_______|____________|_____________________|_______|______________|______________|________|_______|__| Huitema, Andreasen, Arango [Page 23] Internet draft MGCP Call Flows 11 November 1998 ____________________________________________________________________________________ | PBX | Business| CA | CDB| ACC| TGW | SS7/| CO | | | | GW | | | | | ISUP| | | |________|__________|________________|_______|_______|_________|________|_______|__| | | | | | | | <- | REL| | | | | <- | - -| - -| - - | REL | | | | | | Delete | | | | | | | | | <- | Connection | | | | | | | | | | | | | | | | | | <- | DISC | Delete | | | | | | | | | | Connection | - -| - -| -> | | | | | | Perf | | | | | | | | | | Data | -> | | | | | | | | | | <- | - -| - -| Perf | | | | | | | | | | data | | | | | | | Call end | - -| -> | | | | | | | | 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 "tunnelled" to the call agent. The tunnelling protocol, together with configuration tables, allows the call agent to associate the signalling messages to the endpoint corresponding 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 Huitema, Andreasen, Arango [Page 24] Internet draft MGCP Call Flows 11 November 1998 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 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 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 Huitema, Andreasen, Arango [Page 25] Internet draft MGCP Call Flows 11 November 1998 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: 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 Huitema, Andreasen, Arango [Page 26] Internet draft MGCP Call Flows 11 November 1998 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 [Page 27] Internet draft MGCP Call Flows 11 November 1998 2.5. 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 [Page 28] Internet draft MGCP Call Flows 11 November 1998 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 [Page 29] Internet draft MGCP Call Flows 11 November 1998 3. Interaction between an MGCP controlled gateway and an H.323 entity MGCP is not intended to replace H.323, or even to compete with it. In fact, we should mostly consider it as a tool to enable distributed implementations of H.323, as shown in the following picture. The combination of gateways and call agent behaves as a distributed H.323 system, using MGCP for internal communication. 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 Gate- keeper 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 [Page 30] Internet draft MGCP Call Flows 11 November 1998 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 [Page 31] Internet draft MGCP Call Flows 11 November 1998 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 acknowledge the request, repeating in the acknowledgement message the transac- tion 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 notification. 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, ask- ing for digits. The current example provides the gateway with a digit map, and requests the gateway to play a dialtone: Huitema, Andreasen, Arango [Page 32] Internet draft MGCP Call Flows 11 November 1998 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 notification. 200 2002 OK At this stage, the call agent seizes the incoming circuit, 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, sending back the identification of the newly created connection and the ses- sion description used to receive audio data: Huitema, Andreasen, Arango [Page 33] Internet draft MGCP Call Flows 11 November 1998 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 payload 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" element carries a set of open logical channel proposals, derived from the SDP description received from the calling gateway: Huitema, Andreasen, Arango [Page 34] Internet draft MGCP Call Flows 11 November 1998 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 alert- ing tones: RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1 X: 0123456789AE R: hu S: v Huitema, Andreasen, Arango [Page 35] Internet draft MGCP Call Flows 11 November 1998 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 communication: 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 residen- tial 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 transmission from the gateway to the H.323 entity. Huitema, Andreasen, Arango [Page 36] Internet draft MGCP Call Flows 11 November 1998 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 ack- nowledgement: 200 2005 OK The call agent will then clear the call, by sending a delete connection request to the calling gateway. This request is com- bined 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 The gateway will respond with a message that should include a "call parameters" header field: Huitema, Andreasen, Arango [Page 37] Internet draft MGCP Call Flows 11 November 1998 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 [Page 38] Internet draft MGCP Call Flows 11 November 1998 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 during a call from an H.323 user to a residential user. During these Huitema, Andreasen, Arango [Page 39] Internet draft MGCP Call Flows 11 November 1998 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 Gatekeeper. 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 } } } Upon reception of the set-up message, the call agent will Huitema, Andreasen, Arango [Page 40] Internet draft MGCP Call Flows 11 November 1998 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 connec- tion 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 "reverseLo- gicalChannelParameters" data elements. We derive the authorized payload type from the "dataType" element. We have however 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 calling user. When the off hook event is noticed, the gateway sends a Notify command to the call agent: Huitema, Andreasen, Arango [Page 41] Internet draft MGCP Call Flows 11 November 1998 NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B0 O: hd The call agent immediately acknowledges that notification. 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.1X: 0123456789B1 R: hu The gateway acknowledges that request: 200 1241 OK In parallel, the call agent will send a "connect" message 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 [Page 42] Internet draft MGCP Call Flows 11 November 1998 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 call agent will simply Huitema, Andreasen, Arango [Page 43] Internet draft MGCP Call Flows 11 November 1998 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 com- bined 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 [Page 44] Internet draft MGCP Call Flows 11 November 1998 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 demonstrate this inter- working, 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. 4.1. Call from a residential gateway (RGW) to a SIP user Huitema, Andreasen, Arango [Page 45] Internet draft MGCP Call Flows 11 November 1998 ___________________________________________________________________ | 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 notification request, sent by the call agent to the residential gateway. The request will consist of the following lines: Huitema, Andreasen, Arango [Page 46] Internet draft MGCP Call Flows 11 November 1998 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 acknowledge the request, repeating in the acknowledgement message the transac- tion 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 initiates 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 notification. 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, ask- ing for digits. It will also provide the gateway with a digit map, and requests the gateway to play a dialtone: 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 Huitema, Andreasen, Arango [Page 47] Internet draft MGCP Call Flows 11 November 1998 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 notification. 200 2002 OK At this stage, the call agent seizes the incoming circuit, 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, 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 SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), Huitema, Andreasen, Arango [Page 48] Internet draft MGCP Call Flows 11 November 1998 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, 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 immediate acknowledge- ment: 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: Huitema, Andreasen, Arango [Page 49] Internet draft MGCP Call Flows 11 November 1998 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 duplex connec- tion. The SDP payload, in that request, is copied from the SIP agent's response: Huitema, Andreasen, Arango [Page 50] Internet draft MGCP Call Flows 11 November 1998 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 ack- nowledgement: 200 2005 OK The call agent will then clear the call, by sending a delete connection request to the calling gateway. This request is com- bined 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 [Page 51] Internet draft MGCP Call Flows 11 November 1998 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 [Page 52] Internet draft MGCP Call Flows 11 November 1998 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 during 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 gate- way. 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 [Page 53] Internet draft MGCP Call Flows 11 November 1998 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 per- form call routing functions and determine the end point that corresponds to the invited user. It will then reserve the out- going 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 profile: Huitema, Andreasen, Arango [Page 54] Internet draft MGCP Call Flows 11 November 1998 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 initiates 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 notification. 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 The gateway acknowledges that request: Huitema, Andreasen, Arango [Page 55] Internet draft MGCP Call Flows 11 November 1998 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 agent, but there is no such message in SIP. In order to preserve the user experience, Huitema, Andreasen, Arango [Page 56] Internet draft MGCP Call Flows 11 November 1998 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: DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1 C: A3C47F21456789F0 X: 0123456789B3 R: hd I:FDE234C8 Huitema, Andreasen, Arango [Page 57] Internet draft MGCP Call Flows 11 November 1998 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 [Page 58] Internet draft MGCP Call Flows 11 November 1998 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 [Page 59] Internet draft MGCP Call Flows 11 November 1998 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 [Page 60] Internet draft MGCP Call Flows 11 November 1998 ______________________________________________________________ | 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 determines that the call is a data call (e.g., by bearer capability, the called number, etc.). Using configuration databases, the Call Agent selects the type of modem parameters and authentication parameters that correspond to the called number and to the cal- ling 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 [Page 61] Internet draft MGCP Call Flows 11 November 1998 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 identification 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 immedi- ately acknowledge the establishment of the connection, 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 prob- ably 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 calling modem requested. In fact, the number can also be used to identify the specific form of authentication that is requested (but not usu- ally). In our example, the call is completed when the calling modem hangs up. This triggers an ISUP release message, which is for- warded 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 [Page 62] Internet draft MGCP Call Flows 11 November 1998 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 [Page 63] Internet draft MGCP Call Flows 11 November 1998 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 [Page 64] Internet draft MGCP Call Flows 11 November 1998 ___________________________________________________________________ | 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 con- figurations, 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 ack- nowledgement: 200 2005 OK Huitema, Andreasen, Arango [Page 65] Internet draft MGCP Call Flows 11 November 1998 (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 protocols could be used instead of MGCP without affecting the discussion that follows.) The Call Agent deduces from the notification that a circuit should be established towards the dial-up user, or towards the dial-up router. Using configuration databases, 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, sending back the identification of the newly created connection. (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, 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 Huitema, Andreasen, Arango [Page 66] Internet draft MGCP Call Flows 11 November 1998 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 vali- dated, the gateway announces that it serves the local user. In our example, there is no address configuration 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 rout- ing 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 pre- fix 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 for- warded 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 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: Huitema, Andreasen, Arango [Page 67] Internet draft MGCP Call Flows 11 November 1998 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 | | | | |________|_____|______|_____|___________________________|_____| The PPP callback suppose that the modem first establishes an incoming connection, and go through the authentication exchange. The following diagram provides an example of these exchanges: Huitema, Andreasen, Arango [Page 68] Internet draft MGCP Call Flows 11 November 1998 ____________________________________________________________________ | 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 [Page 69] Internet draft MGCP Call Flows 11 November 1998 __________________________________________________________________________ | 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 confi- guration databases, the Call Agent selects the type of modem parameters and authentication parameters that correspond to the Huitema, Andreasen, Arango [Page 70] Internet draft MGCP Call Flows 11 November 1998 called number and to the calling number. It uses this knowledge to send a connection command to the NAS, programming the incom- ing 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, sending back the identification of the newly created connection. (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 immedi- ately acknowledge the establishment of the connection, 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 established, the modem of the calling PC will be synchronized with the modem associated to the trunk. The caller will then proceed to a nor- mal 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 func- tion 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 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 Huitema, Andreasen, Arango [Page 71] Internet draft MGCP Call Flows 11 November 1998 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 ack- nowledgement: 200 2005 OK The Call Agent will check that the call back request can be fol- lowed 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 for- warded 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. 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 [Page 72] Internet draft MGCP Call Flows 11 November 1998 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 [Page 73] Internet draft MGCP Call Flows 11 November 1998 _______________________________________________________________ | 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 information 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 confi- guration 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 incom- ing 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 a=framing:ppp-asynch Huitema, Andreasen, Arango [Page 74] Internet draft MGCP Call Flows 11 November 1998 a=dialed:18001234567 a=dialing:2345678901 The gateway immediately acknowledges the creation, sending back the identification 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 immedi- ately acknowledge the establishment of the connection, 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 established, the modem of the calling PC will be synchronized with the modem associated to the trunk. The caller will then proceed to a nor- mal PPP synchronization, which probably implies a PPP login. Once PPP has been properly synchronized, the NAS establishes 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 connection 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 tun- nel 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 for- warded 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 Huitema, Andreasen, Arango [Page 75] Internet draft MGCP Call Flows 11 November 1998 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 ___________________________________________________________________ | 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 | - -| - - | -> | | | | |_________|_____|______|___________|________________|_____|________| Huitema, Andreasen, Arango [Page 76] Internet draft MGCP Call Flows 11 November 1998 This diagram shows the various exchange of messages during 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 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 NAS 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: 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 "loop- back". It places the circuit in "loopback" mode (we assume that this is the adequate way to perform continuity 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 identification 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 Huitema, Andreasen, Arango [Page 77] Internet draft MGCP Call Flows 11 November 1998 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 modem call. Huitema, Andreasen, Arango [Page 78] Internet draft MGCP Call Flows 11 November 1998 6. Acknowledgements We want to thank here the many reviewers who helped design the MGCP flows, notably Ike Elliott and Chip Sharp. 7. 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 DESCRIPTION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga- Torremolinos, 1984; modified at Helsinki, 1993) [2] ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIGNALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993) * ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON- GUARANTEED QUALITY OF SERVICE." * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Com- munications Systems." * ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON- TELEPHONE SIGNALS." * Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", work in progress 8. 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 Flemming Andreasen Bellcore RRC-1M223 444 Hoes Lane Huitema, Andreasen, Arango [Page 79] Internet draft MGCP Call Flows 11 November 1998 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 Huitema, Andreasen, Arango [Page 80]