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]
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]