Internet Engineering Task Force Christian Huitema INTERNET DRAFT Flemming Andreasen Bellcore February 25, 1999 Expires: August 25, 1999 Media Gateway Control Protocol (MGCP) Call Flow Test Case 1 Christian Huitema, Flemming Andreasen 1. Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents 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 IETF Megaco working group is currently working on defining a proto- col for controlling Media Gateways (MG) from external control elements such as a Media Gateway Controller (MGC). Different models have been proposed to address this problem, and in order to judge the different models, a series of test cases will be considered. This document explains how the Media Gateway Control Protocol (MGCP) can be used to handle the first test case, which considers a Voice over IP gateway with directly subtending DTMF lines placing a call to an H.323 client. The document contains an introduction with further details on the test case, two different call flows to solve it, followed by the conclusion of the test case. MGCP is defined in a companion document [0]. Huitema, Andreasen [Page 1] Internet draft MGCP: test case 1 23 February 1999 2. Introduction The Media Gateway Control Protocol can be used to control different types of endpoints, such as "residential gateways", "trunking gateways" or "packet relays". This document will show how MGCP can be used to con- trol a residential gateway in the Megaco call flow test case 1, which considers a Voice over IP gateway with directly subtending DTMF lines placing a call to an H.323 client. We first present the Megaco test case 1, and we then present an example call flow for solving it. Following that, we discuss possible optimizations to the call flow, and we then present the conclusions reached in using MGCP to satisfy the test case. 3. Call Flow Test Case 1 - DTMF line dialing into VoIP Gateway In this section we first present the problem statement for test case 1, and we then present the assumptions for the test case that were made. 3.1. Problem Statement In this section, we present the problem statement given for the Megaco call flow test case 1. The problem is formulated as follows: Setting: a VoIP Gateway provides service to directly subtending DTMF lines.The standard North American dialling plan is in use: seven digits beginning with 2-9 for a local number, 10 digits for a North American toll number, the single digit 0 for an operator, 411 for directory information, and 911 for emergency service. Overseas dialling is 011 followed by a variable number of digits. The subscriber actually dials a seven-digit local number which has been assigned to a friend's H.323 client installation. The Gateway consults with an H.323 Gatekeeper to resolve the dialled digits into the H.323 client's address, then sets up an audio call to that client. At the end of the call the MGC component of the Gateway is required to report to a billing system for billing purposes the following items: -- the time the call began (subscriber off-hook recorded) -- the time media transfer between the calling and called parties began -- the time media transfer between the calling and called parties ended -- total media packets and octets respectively transmitted by the Gateway to the called party -- total media packets and octets respectively received by the Gateway Huitema, Andreasen [Page 2] Internet draft MGCP: test case 1 23 February 1999 from the called party -- difference between total media packets actually received at the Gateway and the total number expected -- mean interarrival jitter as calculated at the Gateway for received packets. (Notice I don't trust the H.323 client to report anything that can be used for billing.) Call flow: Calling Gateway Called Gatekeeper | 1. Off-hook -->| | | |<-- 2. Dial tone | | | |3. First digit-->| | | |<4. No dial tone | | | |5. Digit -->| | | ... |10. Digit -->| | | | | 11. Admission Request (ARQ)----> | | |<---12. Admission confirm (ACF) | | | 13. SETUP -->| | | | | 14. ARQ --> | | | |<-- 15. ACF | | |<-- 16. ALERTING | | |<-- 17. ringback | | | | |<-- 18. CONNECT | | |<- 19. cutthrough| | | ... | 20. On-hook -->| | | | | 21. RELEASE -->| | | |<-- 22. RLC | | ... Notes: (numbered by the steps to which they apply) 11. Admission Request contains dialled number as an E.164 address. Also requests total bandwidth of 128 kbs (64 kbs in each direction to accommodate G.711 coded audio). 12. Admission Confirm provides call signalling address and port for the called H.323 client. It indicates that only 80 kbs is available. 13. To meet the bandwidth restriction, the SETUP message contains a fastConnect element which offers to send G.711 mu-law audio and receive G.729 Annex C audio or vice versa. It supplies port addresses at which it will receive RTP (incoming media) and RTCP (for the media it transmits). The SETUP message also contains a Huitema, Andreasen [Page 3] Internet draft MGCP: test case 1 23 February 1999 Boolean indicating that the called H.323 client should not transmit any media packets until it issues a CONNECT message. 14-15. The called H.323 client gets permission for its intended bandwidth usage. 16. The called H.323 indicates that it is alerting the called party, and that it has chosen to receive G.711 mu-law and send G.729 Annex C. It supplies the port at which it will receive the G.711 and the port at which it will receive RTCP corresponding to the G.729 it sends out. 17. It is assumed for this scenario that the Gateway is responsible for supplying ringback tone to the caller. 18. The CONNECT message from the called H.323 client indicates that the called party has answered and the call has entered talking state. 19. The Gateway must discontinue ringback tone and cut through talking in both directions. 20. Assumed for this scenario that the caller is the first to hang up. The Disengage sequences which must pass between the Gatekeeper and the Other two H.323 entities at the end of the call are omitted, since they are not relevant. Assumptions * The description of the dialing plan does not include any restric- tions on the structure of the 10-digit number, and it is therefore assumed that the 10-digit number may start with any digit, incl. 2-9. * We assume that international numbers (excluding direct-dial prefix) may consist of as few as 1 digit. * We will be using H.323 version 2. 4. Call Flows We present two different call flows to test case 1. The first call flow illustrates how MGCP can be used to satisfy the test case when two separate connections are used. The second call flow illustrates an alternative solution where we only use one connection. Huitema, Andreasen [Page 4] Internet draft MGCP: test case 1 23 February 1999 4.1. Two Connection Call Flow The diagram below illustrates the basic call flow: ________________________________________________________________________ |Step | User | MG | MGC | H.323 EP | GK | |_____|___________|_____________|________________|_____________|_______| | 0| | <- | RQNT | | | | | | Ack | -> | | | | | | (ready) | | | | | 1| Off- | NTFY | -> | | | | 1a| hook | | (off-hook | | | | | | | recorded) | | | | | | <- | Ack | | | | 2| (dial | <- | RQNT | | | | | tone) | Ack | -> | | | | 3| digit | | | | | | 4| (no dial| | | | | | | tone) | | | | | | 5| digit | | | | | | | ... | | | | | | 10| digit | | | | | | 10a| (match) | NTFY | -> | | | | | | <- | Ack | | | | 10b| | <- | RQNT+ | | | | | | | CRCX-1 | | | | | | Ack(SDP-1)| -> | | | | 11| | | ARQ | - - | -> | | 12| | | <- | - - | ACF | | 12a| | <- | CRCX-2 | | | | 12b| | Ack(SDP-2)| -> | | | | 13| | | SETUP | -> | | | 14| | | | ARQ | -> | | 15| | | | <- | ACF | | 16| | | <- | ALERTING | | | 17| (ring | <- | RQNT + | | | | | back) | | MDFY-1(SDP), | | | | | | | MDFY-2(SDP) | | | | | | Ack, Ack | -> | | | | 18| | | <- | CONNECT | | | 19| (cut- | <- | RQNT | | | | | through)| | +MDFY-2 | | | | | | Ack | -> | | | | | | | (full-duplex | | | | | | | media transfer| | | | | | | recorded) | | | |_____|___________|_____________|________________|_____________|_______| Huitema, Andreasen [Page 5] Internet draft MGCP: test case 1 23 February 1999 ________________________________________________________________________ |Step| User | MG | MGC | Acc| H.323 EP| GK | |____|__________|___________|________________|______|___________|______| | 20| on-hook| NTFY | -> | | | | | | | <- | Ack | | | | | 21*| | | RELEASE | | | | | | | | COMPLETE | - -| -> | | | 21a| | <- | RQNT+DLCX-1, | | | | | | | | DLCX-2 | | | | | 21b| | Ack, Ack| -> | | | | | | | | (media | | | | | | | | transfer | | | | | | | | stopped) | | | | | | | | (Accounting) | -> | | | |____|__________|___________|________________|______|___________|______| * H.323 only uses Release Complete, hence the test case was modified accordingly. We now describe each of the steps involved in more detail. MGCP is used by the call agent to control the media gateway, which we will refer to as a residential gateway in the following. The call placed from the residential gateway will be routed to an H.323 endpoint. In step 0, we show the first command which 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.example.net MGCP 0.1 N: ca@ca1.example.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 transaction id that the call agent attached to the query. 200 1201 OK Note that this command is not actually simultaneous with the call. It can be issued long before the actual call, for example when the gateway is turned on, or after the end of a previous call. When the off hook event is noticed in step 1, the gateway sends a Notify command to the call agent: Huitema, Andreasen [Page 6] Internet draft MGCP: test case 1 23 February 1999 NTFY 2001 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AB O: hd This message does not contain the actual time the off-hook event occurred. Instead the Call Agent records the actual time it receives the off-hook notify message in step 1a. Through its extension mechanism, MGCP however allows new experimental parameters to be used and further- more specify whether they are critical extensions that must be under- stood or not. The call agent immediately acknowledges the notify message it received. 200 2001 OK The call agent examines the services associated to an off hook action (it could take special actions in the case of a direct line). In most cases, it will send a notification request, asking for digits. The current example instructs the gateway to look for an on-hook event, and to accumulate digits according to the digit map provided. The gateway is furthermore instructed to play dial-tone - step 2: RQNT 1202 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AC R: hu, [0-9#*T](D) D: ([2-9]xxxxxx| 1xxxxxxxxxx| 0T| [49]11| 011x.T) S: dl The digit map provides the endpoint with a grammar according to which dialed digits are to be accumulated. We discussed the structure of this map in the previous example. Alternatively, we could simply have requested the gateway to notify us each individual digit as it is received, however that would have gen- erated more message traffic, although a simpler gateway may wish to use this mode of operation instead. The gateway immediately acknowledges the notification. 200 1202 OK As the user inputs the digits, the gateway will start accumulating digits according to the digit map. When the first digit is entered in step 3, the gateway will immediately stop playing dial-tone (step 4) as the MGCP event detection is synchronized with the signals. When the Huitema, Andreasen [Page 7] Internet draft MGCP: test case 1 23 February 1999 gateway has noticed a sufficient set of values to produce a digit match (step 5,6,7,8,9,10), the gateway will notify the observed string to the call agent (step 10a). In this case, we assume that the user enters the 7-digit destination number "2345678" - notice that the timer event is included in the list of observed events: NTFY 2002 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AC O: 2,3,4,5,6,7,8,T 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 (step 10a): CRCX 1204 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:PCMU M: recvonly X: 0123456789AD R: hu We notice, that the MGC intends to place a call using G.711 u-law in both directions - a bidirectional channel in H.323 terms - and conse- quently just specifies the codec type PCMU. 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: FDE234C1 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 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 u-law transmission. The IANA maintains a current list of codecs and payload types. Huitema, Andreasen [Page 8] Internet draft MGCP: test case 1 23 February 1999 In step 11, The call agent, having seized the incoming trunk, proceeds with call routing. Using local databases, it determines that the dialed digits ("2345678") correspond to an H.323 endpoint. The MGC contacts the gatekeeper for the H.323 endpoint by sending an Admission Request (ARQ) containing the dialed number and a request for 128 kbs of bandwidth. In step 12, the gatekeeper returns the Admission Confirm (ACF) message with the call signaling address and port for the called H.323 client. In step 12a, the MGC realizes that using G.711 in both directions is not possible given the bandwidth limitation. The MGC has two choices here in MGCP. It can either choose to create a new connection and thereby main- tain one connection per possible codec, or it can simply instruct the MG to be prepared to used two codecs for this connection. In this case, the MGC knows that it intends to use the H.323 fastStart procedure which implies that the H.323 endpoint will only be able to use unidirectional channels. The usage of the session description protocol in fact still enables the MGC to only use a single connection with asymmetric codec usage and multiple media port addresses, however, for clarity, we assume that the MGC here decides to maintain a separate connection per H.323 logical channel. The MGC therefor sends the following CreateConnection command to the MG: CRCX 1205 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:X-G729C M: recvonly The MG is prepared to use either codec and it therefore sends back an acknowledgement with a new session description: 200 1205 OK I: FDE234C2 v=0 c=IN IP4 128.96.41.1 m=audio 3458 RTP/AVP 96 a=rtpmap:96 X-G729C/8000 Since G.729C is not currently registered with the IANA, we here use the extensibility of SDP and specify a dynamic payload type and an experi- mental codec name for G.729C. In step 13, The MGC will now setup a TCP-IP connection and send an H.225.0 SETUP message to the H.323 entity. In this message, the "fastStart" element carries a set of open logical channel proposals, according to the test case described earlier. Again, it should be noted Huitema, Andreasen [Page 9] Internet draft MGCP: test case 1 23 February 1999 here, that H.323 is limited to opening unidirectional channels when using fastStart which is why we chose to create separate connections for each of the codec choices. The "fastStart" element for the codec choices will contain the following address information: G.711 RTP receive address:128.96.41.1, 3456 G.711 RTCP receive address:128.96.41.1, 3457 G.729C RTP receive address:128.96.41.1, 3458 G.729C RTCP receive address:128.96.41.1, 3459 In step 14 and 15, the H.323 endpoint performs the ARQ and ACF exchange with the gatekeeper and gets permission for its intended bandwidth usage. In step 16, the called H.323 client alerts the user, and sends an H.225.0 ALERTING message to the MGC. The ALERTING message contains a fastStart parameter specifying that the H.323 client will receive G.711 u-law and send G.729C thereby opening two unidirectional logical chan- nels. The "fastStart" parameter contains the following address informa- tion: G.711 RTP receive address:128.96.63.25, 1296 G.711 RTCP receive address:128.96.63.25, 1297 G.729C RTP receive address:N/A G.729C RTCP receive address:128.96.63.25, 1299 We note, that under normal circumstances, we could expect to have a sin- gle bidirectional channel instead of two unidirectional channels. Furth- ermore, such a channel should be able to use different codecs in each direction. In step 17, the MGC must now make the MG alert the phone attached, and it must furthermore inform the MG that it needs to send G.711, and receive G.729C, and provide the relevant addresses for each. The MGC issues two commands using the MGCP piggy-backing functionality; a com- bined modify connection and request notification command for the first connection, and a modify connection command for the second connection: Huitema, Andreasen [Page 10] Internet draft MGCP: test case 1 23 February 1999 MDCX 1206 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C1 L: p:10, a:PCMU M: inactive X: 0123456789AE R: hu S: v v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 a=sendonly . MDCX 1207 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C2 M: recvonly v=0 c=IN IP4 128.96.63.25 m=audio 1298 RTP/AVP 96 a=rtpmap:96 X-G729C/8000 a=recvonly We here note, that having to manage multiple connections is rather cumbersome - it would be simpler if we only had to manage a single con- nection instead. The first ModifyConnection command contains instructions to play alert- ing tones, and continue to look for on-hook events. The use of Session Description Protocol (SDP) provides us with a standardized and flexible method for specifying multimedia as we can see above. The session description for the first connection specifies where to the media for the connection should be sent as well as the payload type expected. It also specifies that it will only be used in the send direction, although the current mode for the connection is inactive, as specified by the LocalConnectionOptions. The session description for the second ModifyConnection command provides a similar specification, however in this case we see that we will only receive media. The IP-address and port specification included allows us to send RTCP information to the sender though. The MG immediately acknowledges the two commands above, again utilizing the piggy-backing functionality (this is in fact an optimization - the MG could equally well send two separate datagrams): Huitema, Andreasen [Page 11] Internet draft MGCP: test case 1 23 February 1999 200 1206 OK . 200 1207 OK When the called H.323 user accepts the call, the H.323 endpoint sends an H.225.0 CONNECT message to the MGC - step 18. In step 19, the MGC must now cutthrough a full-duplex voice path and stop the alerting tones - note that we up until now have had a half- duplex path which, e.g. would enable the far-end side to play an announcement if needed. The MGC sends the following combined modify con- nection and notification request command to the MG: MDCX 1208 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C1 M: sendonly X: 0123456789AF R: hu The gateway immediately acknowledges the transaction: 200 1208 OK When the MGC receives the response, it then knows that a full duplex media path (although not connection) is in place between the two end- points. The message does not contain the actual time the transaction was completed and thus the full duplex path established. Instead the Call Agent records the time it receives the response. Alternatively, the MGCP extension mechanism could be used. The call is now established. In step 20, the calling party now hangs up the phone. This triggers a Notify command to the MGC: NTFY 2005 endpoint/1@rgw-2567.example.net MGCP 0.1 X: 0123456789AF O: hu The MGC immediately acknowledges the command: 200 2005 OK The MGC then determines, that the call should end, and per step 21, it therefore sends an H.225.0 RELEASE COMPLETE message to the H.323 end- point. Huitema, Andreasen [Page 12] Internet draft MGCP: test case 1 23 February 1999 The MGC also sends two commands to the MG using the piggy-backing func- tionality; a combined delete connection and notification request command for the first connection and simply a delete connection command for the second connection - we note again the overhead associated with managing multiple connections: DLCX 1210 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C1 X: 0123456789B0 R: hd . DLCX 1211 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C2 We could in fact have used another form of the DeleteConnection command here where we simply referred to the CallId for the endpoint, however that would not have provided us with statistics for the connections. The MG response as follows: 250 1210 OK P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=0 . 250 1211 OK P: PS=0, OS=0, PR=780, OR=45123, PL=10, JI=27, LA=48 The connection parameters returned provide us with statistics for the connections. Specifically we see that we have statistics for media pack- ets and octets sent and received, number of media packets lost, and mean interarrival jitter as well. The response does not include the actual time the media transfer stopped, however the MGC can use the time the response was received, or perhaps the time the on-hook Notify message was received. As another option, the MG could in fact use the MGCP extension mechanism for connection parameters which allows it to pass new connection parameter such as time to the MGC, as in: P: PS=0, OS=0, PR=780, OR=45123, PL=10, JI=27, LA=48, X-T1=1234, X-T2=4321 Huitema, Andreasen [Page 13] Internet draft MGCP: test case 1 23 February 1999 4.2. One Connection Call Flow The diagram below illustrates the basic call flow: ____________________________________________________________________ |Step| User | MG | MGC | H.323 EP| GK | |____|___________|___________|__________________|__________|_______| | 0| | <- | RQNT | | | | | | Ack | -> | | | | | | (ready) | | | | | 1| Off- | NTFY | -> | | | | 1a| hook | | (off-hook | | | | | | | recorded) | | | | | | <- | Ack | | | | 2| (dial | <- | RQNT | | | | | tone) | Ack | -> | | | | 3| digit | | | | | | 4| (no | | | | | | | dial | | | | | | | tone) | | | | | | 5| digit | | | | | | | ... | | | | | | 10| digit | | | | | | 10a| (match) | NTFY | -> | | | | | | <- | Ack | | | | 10b| | <- | RQNT+CRCX | | | | | | Ack(SDP)| -> | | | | 11| | | ARQ | - - | -> | | 12| | | <- | - - | ACF | | 12a| | <- | MDCX | | | | 12b| | Ack(SDP)| -> | | | | 13| | | SETUP | -> | | | 14| | | | ARQ | -> | | 15| | | | <- | ACF | | 16| | | <- | ALERTING| | | 17| (ring | <- | RQNT+ | | | | | back) | | MDFY(SDP) | | | | | | Ack | -> | | | | 18| | | <- | CONNECT | | | 19| (cut- | <- | RQNT+MDFY | | | | | through)| | Ack | -> | | | | | | (full duplex | | | | | | | media transfer | | | | | | | recorded) | | | |____|___________|___________|__________________|__________|_______| Huitema, Andreasen [Page 14] Internet draft MGCP: test case 1 23 February 1999 ______________________________________________________________ |Step| User | MG | MGC | ACC | H.323 EP | GK| | _ | | | | | | | | 20| on-hook| NTFY| -> | | | | | | | <- | Ack | | | | | 21| | | RELEASE | - -| -> | | | 21a| | <- | RQNT+DLCX| | | | | 21b| | Ack | -> | | | | | 22| | | <- | - -| RELEASE | | | | | | | | COMPLETE| | |____|__________|_______|___________|______|___________|_____| We now describe each of the steps involved in more detail. MGCP is used by the call agent to control the media gateway, which we will refer to as a residential gateway in the following. The call placed from the residential gateway will be routed to an H.323 endpoint. In step 0, we show the first command which 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.example.net MGCP 0.1 N: ca@ca1.example.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 transaction id that the call agent attached to the query. 200 1201 OK Note that this command is not actually simultaneous with the call. It can be issued long before the actual call, for example when the gateway is turned on, or after the end of a previous call. When the off hook event is noticed in step 1, the gateway sends a Notify command to the call agent: NTFY 2001 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AB O: hd This message does not contain the actual time the off-hook event occurred. Instead the Call Agent records the actual time it receives the Huitema, Andreasen [Page 15] Internet draft MGCP: test case 1 23 February 1999 off-hook notify message in step 1a. The call agent immediately acknowledges the notify message it received. 200 2001 OK The call agent examines the services associated to an off hook action (it could take special actions in the case of a direct line). In most cases, it will send a notification request, asking for digits. The current example instructs the gateway to look for an on-hook event, and to accumulate digits according to the digit map provided. The gateway is furthermore instructed to play dial-tone - step 2: RQNT 1202 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AC R: hu, [0-9#*T](D) D: ([2-9]xxxxxx| 1xxxxxxxxxx| 0T| [49]11| 011x.T) S: dl The digit map provides the endpoint with a grammar according to which dialed digits are to be accumulated. In this case, we have an ambiguous grammar, due to a conflict between "0" and "011". A timer is therefore included with the grammar for the 0 number. Since we don't have any res- trictions on the valid length of an international number we simply specified it as consisting of an arbitrary number of digits, where end of input again is based on a timer. We could have specified, e.g. a pound sign ("#") as well, if we wanted to allow the user to explicitly signal that he has finished entering his destination number. Alternatively, we could simply have requested the gateway to notify us each individual digit as it is received, however that would have gen- erated more message traffic, although a simpler gateway may wish to use this mode of operation instead. The gateway immediately acknowledges the notification. 200 1202 OK As the user inputs the digits, the gateway will start accumulating digits according to the digit map. When the first digit is entered in step 3, the gateway will immediately stop playing dial-tone (step 4) as the MGCP event detection is synchronized with the signals. When the gateway has noticed a sufficient set of values to produce a digit match (step 5,6,7,8,9,10), the gateway will notify the observed string to the call agent (step 10a). In this case, we assume that the user enters the 7-digit destination number "2345678" - notice that the timer event is included in the list of observed events: Huitema, Andreasen [Page 16] Internet draft MGCP: test case 1 23 February 1999 NTFY 2002 endpoint/1@rgw-2567.example.net MGCP 0.1 N: ca@ca1.example.net:5678 X: 0123456789AC O: 2,3,4,5,6,7,8,T 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 (step 10a): CRCX 1204 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 L: p:10, a:PCMU M: recvonly X: 0123456789AD R: hu We notice, that the Call Agent intends to place a call using G.711 u-law in both directions, and consequently just specifies the codec type PCMU. 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 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 u-law transmission. The IANA maintains a current list of codecs and payload types. In step 11, The call agent, having seized the incoming trunk, proceeds with call routing. Using local databases, it determines that the dialed digits (2345678) correspond to an H.323 endpoint. The MGC now contacts the gatekeeper for the H.323 endpoint by sending an Admission Request (ACF) containing the dialed number and a request for 128 kbs of Huitema, Andreasen [Page 17] Internet draft MGCP: test case 1 23 February 1999 bandwidth. In step 12, the gatekeeper returns the Admission Confirm (ACF) message with the call signaling address and port for the called H.323 client. In step 12a, the MGC realizes that using G.711 in both directions is not possible given the bandwidth limitation. The MGC has two choices here in MGCP. It can either choose to create a new connection and thereby main- tain one connection per possible codec, or it can simply instruct the MG to be prepared to used two codecs for this connection. In this case, the MGC finds it easier to simply instruct the MG to be prepared to use two different codecs, and it therefore sends a ModifyConnection command to the MG: MDCX 1205 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 L: p:10, a:PCMU,G729C M: recvonly The MG is prepared to use either codec and it therefore sends back an acknowledgement with a new session description: 200 1205 OK v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 18 Since G.729C is not currently registered with the IANA, we here use the extensibility of SDP and specify a dynamic payload type and an experi- mental codec name for G.729C. We note, that a single IP-address and port can here be used with different codecs. In step 13, The MGC will now setup a TCP-IP connection and send an H.225.0 SETUP message to the H.323 entity. In this message, the "fastStart" element carries a set of open logical channel proposals, according to the test case described earlier. It should be noted here, that H.323 is limited to opening unidirectional channels when using fastStart. Regardless, for both G.711 and G.729C, the address informa- tion will be as follows since the two codecs represent a choice: RTP receive address:128.96.41.1, 3456 RTCP receive address:128.96.41.1, 3457 In step 14 and 15, the H.323 endpoint performs the ARQ and ACF exchange with the gatekeeper and gets permission for its intended bandwidth usage. In step 16, the called H.323 client alerts the user, and sends an Huitema, Andreasen [Page 18] Internet draft MGCP: test case 1 23 February 1999 H.225.0 ALERTING message to the MGC. The ALERTING message contains a fastStart parameter specifying that it will receive G.711 u-law and send G.729C thereby opening two unidirectional logical channels. G.711 RTP receive address:128.96.63.25, 1296 G.711 RTCP address:128.96.63.25, 1297 G.729C RTP receive address:N/A G.729C RTCP address:128.96.63.25, 1299 The MG can thus issue sender reports Note, that under normal circumstances, we could expect to have a single bidirectional channel instead of two unidirectional channels. In step 17, the MGC must now make the MG alert the phone attached, and it must furthermore inform the MG that it needs send G.711, and receive G.729C, and provide the relevant addresses for each. It should be noted that there in fact is a separate RTCP address to be used for each of these unidirectional streams, however the H.323 endpoint will have one SSRC identifier and the MG will have another SSRC identifier. Again, at this point in time, the MGC could choose to create a new connection if it wanted to have a separate connection for each logical channel. The MGC issues the following combined modify connection and request notifi- cation command: MDCX 1206 endpoint/1@rgw-2567.example.net MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 L: p:10, a:PCMU M: recvonly X: 0123456789AE R: hu S: v v=0 c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 a=sendonly m=audio 1298 RTP/AVP 96 a=rtpmap:96 X-G729C/8000 a=recvonly We here note how the use of Session Description Protocol (SDP) allows us to provide multiple media specifications, similar to H.245's logical channels. A couple of things are worth noting above. First of all, the LocalConnectionOptions specify the use of G.711 u-law informing the gateway that it should use G.711 when sending media. The session Huitema, Andreasen [Page 19] Internet draft MGCP: test case 1 23 February 1999 description informs the MG about the other end of the connection. For G.711 media, we specify that it is only to be sent, and that it specifi- cally is to be sent to IP-address 128.96.63.25 and port number 1296. For G.729C, we currently specify that if it was to be sent, then it would be sent to port number 1298, which allows us to infer that the RTCP port number for G.729C is 1299. Since we have specified receive-only for G.729C, and sendonly for G.711, we now have asymmetric codec usage for the connection. The call flow will then proceed in a manner very similar to our first example. After receiving the "CONNECT" response, the MGC will send a combination of notification request and modification command to validate the two media Streams. At the end of the connection, the hangup will be signalled, the connection will be released, and the statistics will be collected. 5. Discussion The call flows that we showed test, in a sense, one of the limits of MGCP, i.e. its lack of optimization for the handling of multiple simul- taneous connections. We also showed two minor limitations in the "accounting" interface, i.e. some imprecision in the measurement of time, and a lack of a clear signal indicating the moment at which a media starts flowing. We will discuss here how the protocol could be tuned to remove these constraints. 5.1. Handling of multiple connections MGCP has been mostly used to date in environments where connections could be established in a "symmetric" manner, when both sides of the connection would use the same parameters, and could use full-duplex con- nections. There are definitive advantages to using full-duplex connec- tions when possible, such as a simpler signalling exchange, simpler accounting and also more efficient use of RTCP. Having a full duplex connection does not mandate that the same compres- sion algorithm be used in both directions. In fact, MGCP uses separate "session descriptions" for each direction, and specifying different algorithms in each of these is fairly straightforward. A full duplex connection, however, can only use one RTCP port for both directions of transmission. H.323 allows both duplex and simplex logical channels. When simplex channels are used, the two directions are constructed independently, which results in the scenario showed in our first call flow. MGCP, as showed in the first call flow, can indeed be used to construct simplex Huitema, Andreasen [Page 20] Internet draft MGCP: test case 1 23 February 1999 connections, and we have used this capability to match one to one MGCP connections and H.323 logical channels. Managing two connections instead of one essentially results in twice as many commands. MGCP could be optimized for this task, essentially by using an extension of the "command embedding" proposed by Nancy Greene developed in the "packet relay" draft [5]. The embedding will allow us to easily combine commands related to different connections, as well as notification requests, in a single "atomic" construct, without having to repeat common parameters such as the names of endpoints. 5.2. Limitations of the accounting interface The accounting interface showed two limitations. First, the reporting is based on the arrival time of signalling packets, which includes a variable transmission delay. Then, the media flows are assumed to start immediately after the connection establishment, which is not necessarily always true. The timing imprecision resulting of command transmission delays is bounded by these transmission delays. It is unlikely to exceed a frac- tion of a second, thus meeting the requirements of most accounting pro- cedures. Including timestamps in the various commands, responses and event reports would be possible, but would only be valuable if every gateway was equipped with a synchronized clock, for example by using the Network Time Protocol. There are in fact many arguments for having syn- chronized clocks in all network equipments, such as better management and more precise logging procedures. However, the addition of this feature in low-end equipments such as residential gateways has been resisted by manufacturers, because of complexity and cost considera- tions. The accounting requirements are probably not sufficient to change the manufacturers' position. In any case, the time at which a call starts, or end, is by nature imprecise: both ends don't notice it at the same time. MGCP could very easily be used to provide a notification of the time at which media packet have started being exchanged. It suffices to define a "start of transmission" event in the RTP package, triggered when the first media packet is received, or sent, and to use standard event notification procedures. 6. Conclusion This document has shown that MGCP satisfies Megaco call flow test case 1. It has furthermore also demonstrated that MGCP provides a simply, yet powerful and flexible solution to Megaco. MGCP normally assumes bidirec- tional connections, while this test case fundamentally assumes the use of unidirectional media streams through the use of H.323 fastStart. MGCP Huitema, Andreasen [Page 21] Internet draft MGCP: test case 1 23 February 1999 has proven that it could easily satisfy such a scenario. In the course of doing this, it was furthermore demonstrated, that it is preferable to not have to manage any more connections than necessary - the hybrid model that MGCP is based upon fully satisfies this. 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 H.323, "VISUAL TELEPHONE SYSTEMS AND EQUIP- MENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE." [2] ITU-T, Recommendation H.225, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems." [3] ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-TELEPHONE SIGNALS." [4] Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", work in progress [5] Huitema, C., Andreasen, F., "Media Gateway Control Protocol (MGCP) Support for Packet Relays" 8. Authors' Addresses Huitema, Andreasen [Page 22] Internet draft MGCP: test case 1 23 February 1999 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 Piscataway, NJ 08854-4157 U.S.A. Phone: +1 732 699-7351 EMail: fandreas@notes.cc.bellcore.com Huitema, Andreasen [Page 23]