Internet Engineering Task Force Christian Huitema
`INTERNET DRAFT Flemming Andreasen
`<draft-huitema-mgcp-test1-00.txt> 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]
`
`Ex. 1024
`YMax Corporation
`Page 1 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 2 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 3 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 4 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 5 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 6 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 7 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 8 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 9 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 10 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 11 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 12 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 13 of 23
`
`

`
`
`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]
`
`Ex. 1024
`YMax Corporation
`Page 14 of 23
`
`

`
`
`Internet draft M