Internet DRAFT - draft-huitema-mgcp-flows
draft-huitema-mgcp-flows
Internet Engineering Task Force Christian Huitema
INTERNET DRAFT Flemming Andreasen
<draft-huitema-mgcp-flows-00.txt> Bellcore
November 11, 1998 Mauricio Arango
Expires: May 11, 1998 RSL COM
Media Gateway Control Protocol (SGCP) Call Flows
Christian Huitema, Flemming Andreasen, Mauricio Arango
November 11, 1998
Status of this document
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
The Media Gateway Control Protocol (MGCP) organizes the communication
between a Media Gateway controller, or call agent, and a Media Gateway,
e.g. a Voice over IP gateway or a Network Access Server. MGCP is
defined in a companion document [1]. This document provides example of
MGCP usage by providing a variety of call flows, in the case of
telephony and network access servers.
1. Introduction
In order to understand the way the MGCP interface will be used, we have
described here two possible call flows between a TGW, which is a trunk-
ing gateway that implements MGCP, and an RGW, which is a residential
Huitema, Andreasen, Arango [Page 1]
Internet draft MGCP Call Flows 11 November 1998
gateway that implements MGCP, as well as four call flows describing how
MGCP could be used to control a network access service. For each of
these call flows it is assumed that the default event packages are as
follows:
TGW Trunk package
RGW Line package
NAS Network Access Server package
The diagrams also show a Common Database (CDB) that can be queried for
authorization and routing information, and an Accounting Gateway (ACC)
that collects accounting information at the start and the end of calls.
These diagrams are solely meant to exhibit the behavior of the MGCP, and
to help understanding this protocol. They are not meant as a tutorial on
the implementation of a Call Agent. They may very well include miscel-
laneous errors and imprecisions.
Huitema, Andreasen, Arango [Page 2]
Internet draft MGCP Call Flows 11 November 1998
2. Internet Telephony Call Flows.
We present five Internet Telephony call flows:
* A basic call from a "residential gateway" to a "trunking gateway",
* A basic call from a "trunking gateway" to a "residential gateway".
* A basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW.
* A basic call from an ISDN trunk in a business gateway to an SS7
trunk in a TGW.
* A basic call with continuity test, from a "trunking gateway" to a
"residential gateway".
2.1. Basic call, RGW to TGW
______________________________________________________________________
Usr RGW CA CDB ACC TGW SS7/ CO
ISUP
______________________________________________________________________
<- RQNT
Ack ->
Off
-hook (local
(Dial action)
-tone)
Digits Notify ->
<- Ack
(pro- <- CRCX+RQNT
gress) Ack ->
Query
(E.164 S,D) ->
<- IP
CRCX - - - - ->
(cut in)
<- - - - - ack
IAM - - - - - - ->
<- MDCX IAM ->
Ack -> <- ACM
<- - - - - - - ACM
<- Notification
Request
Ack ->
<- ANM
<- - - - - - - ANM
<- MDCX+RQNT
Huitema, Andreasen, Arango [Page 3]
Internet draft MGCP Call Flows 11 November 1998
| | Ack | -> | | | | | |
| | (cut in)| Call start | - -| -> | | | |
|_______|__________|______________|_____|_____|__________|______|_____|
__________________________________________________________________
| Usr | RGW | CA | CDB| ACC| TGW | SS7/| CO |
| | | | | | | ISUP| |
|________|________|______________|_____|_____|_______|______|_____|
| | | | | | | <- | REL|
| | | <- | - -| - -| - - | REL | |
| | <- | Delete | | | | | |
| | | Connection | | | | | |
| | | Delete | | | | | |
| | | Connection | - -| - -| -> | | |
| | Perf | | | | | | |
| | Data | -> | | | | | |
| | | <- | - -| - -| perf | | |
| | | | | | data | | |
| | | Call end | - -| -> | | | |
| On-hook| Notify| -> | | | | | |
| | <- | Ack | | | | | |
| | <- | Notification| | | | | |
| | | Request | | | | | |
| | Ack | -> | | | | | |
|________|________|______________|_____|_____|_______|______|_____|
During these exchanges the MGCP is used by the Call Agent to control
both the TGW and the residential gateway. The exchanges occur on two
sides.
The first command is a NotificationRequest, sent by the Call Agent to
the residential gateway. The request will consist of the following
lines:
RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: hd(E(dl;hu, D/[0-9#*T](D);)
D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
S:
That transaction illustrates the power of the "embedded" action. The
gateway is instructed to look for an off-hook event, and, upon its
detection, to provide a dial-tone and to start looking for DTMF digits.
The gateway immediately acknowledges the command, repeating in the
Huitema, Andreasen, Arango [Page 4]
Internet draft MGCP Call Flows 11 November 1998
acknowledgement message the transaction id that the Call Agent attached
to the query.
200 1201 OK
When the off hook event is noticed, the gateway provides the dial tone
to the line (the delay between off-hook and dialtone is thus minimal.)
The gateway will start accumulating digits according to that digit map.
When it has noticed a sufficient set of values, it will notify the
observed string to the Call Agent:
NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
O: 912018294266
The Call Agent immediately acknowledges that notification.
200 2002 OK
The Call Agent will then seize the incoming circuit, creating a connec-
tion. The create connection commands piggybacks a notification request,
to stop collecting digits yet continue watch for an on-hook transition:
CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
X: D/0123456789AD
R: hu
S:
We should note at this point that the call agent could send the
acknowledgement of the Notify and the CRCX in a single UDP packet,
as explained in the "piggy backing" section of [1]. There are many
possible groupings of that nature in the various examples.
The gateway immediately acknowledges the creation, sending back the
identification of the newly created connection and the session descrip-
tion used to receive audio data:
200 1204 OK
I:FDE234C8
Huitema, Andreasen, Arango [Page 5]
Internet draft MGCP Call Flows 11 November 1998
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP announcement, in our example, specifies the address at which the
gateway is ready to receive audio data (128.96.41.1), the transport pro-
tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio
profile refers to RFC 1890, which defines that the payload type 0 has
been assigned for G.711 transmission. The gateway is also ready to use
ADPCM encoding at 32 kbps (G.726 -4). There is no standard payload type
associated to ADPCM, so the gateway mentions its readiness to use a non
standard payload associated to the dynamic type 96. The "rtpmap" attri-
bute entry associates the payload type 96 to G726-32/4.
The Call Agent, having seized the incoming trunk and completed a routing
look up to identify the outgoing gateway, must now seize the outgoing
trunk. It does so by sending a connection command to the e-gress gate-
way:
CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The CreateConnection command has the same parameters as the command sent
to the ingress gateway, with two differences:
* The EndpointId points towards the outgoing trunk,
* The message carries the session description returned by the ingress
gateway,
* Because the session description is present, the "mode" parameter is
set to "send/receive".
We observe that the call identifier is identical for the two connec-
tions. This is normal: the two connections belong to the same call,
which has a global identifier in our system.
The trunking gateway will acknowledge the connection command, sending in
Huitema, Andreasen, Arango [Page 6]
Internet draft MGCP Call Flows 11 November 1998
the session description its own parameters such as address, ports and
RTP profile:
200 1205 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent will relay the information to the ingress gateway, using
a ModifyConnection command:
MDCX 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The residential gateway immediately acknowledges the modification:
200 1206 OK
At this stage, the Call Agent has established a half duplex transmission
path. The phone attached to the residential gateway will be able to
receive the signals, such as tones or announcements, that the remote
switch may send through the trunking gateway.
When the call progresses, the Call Agent will receive from the remote
switch progress messages, for example an "address complete" message
(ACM). The Call Agent will analyze the message to determine whether sig-
nal are transmitted in band. If this is not the case, the Call Agent
will instruct the RGW to generate ringing tones by sending a Notifica-
tionRequest:
RQNT 1207 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AE
R: hu
S: v
Huitema, Andreasen, Arango [Page 7]
Internet draft MGCP Call Flows 11 November 1998
The gateway immediately acknowledges the command:
200 1207 OK
After the called user answers the call, the Call Agent will receive an
answering message (ANM) from the CO switch. At that point, it will send
a ModifyConnection command, to the residential gateway, to place the
connection in full duplex mode. The command embeds NotificationRequest
to stop the ringing tones.
MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
X: 0123456789AF
R: hu
S:
The residential gateway will acknowledge this command:
200 1209 OK
At this point, the connection is established.
When the Call Agent receives the REL message from the CO switch, it will
have to tear down the call. It will do so by sending to both gateways a
DeleteConnection command:
DLCX
1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:32F345E2
The gateways will respond with acknowledgements that should include a
"call parameters" header fields:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,
LA=48
Huitema, Andreasen, Arango [Page 8]
Internet draft MGCP Call Flows 11 November 1998
250 1211 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,
LA=48
At this point, phone attached to the residential gateway, in our
scenario, goes on-hook. This event is notified to the Call Agent,
according to the policy received in the last NotificationRequest by
sending a Notify command:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AF
O: hu
After this notification, the Call Agent should send an acknowledgement:
200 2005 OK
It should then issue a new NotificationRequest, to be ready to receive
the next off-hook detected by the residential gateway:
RQNT 1212 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B0
R: hd(E(dl;hu, [0-9#*T](D);)
D: (0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
S:
The gateway will acknowledge this message:
200 1212 OK
Both gateways, at this point, are ready for the next call.
Huitema, Andreasen, Arango [Page 9]
Internet draft MGCP Call Flows 11 November 1998
2.2. Basic call, TGW to RGW
___________________________________________________________________
| CO | SS7/| TGW | CA | CDB| ACC| RGW | Usr |
| | ISUP| | | | | | |
|____|______|__________|_______________|_____|_____|________|______|
| IAM| -> | | | | | | |
| | IAM | - - | -> | | | | |
| | | | Check | -> | | | |
| | | | <- | IP | | | |
| | | <- | Create | | | | |
| | | | Connection | | | | |
| | | Ack | -> | | | | |
| | | | Create | | | | |
| | | | Connection | - -| - -| -> | |
| | | | <- | - -| - -| Ack | |
| | | <- | Modify | | | | |
| | | | Connection | | | | |
| | | Ack | -> | | | | |
| | | | Notification | | | | |
| | | | Request | - -| - -| -> | ring|
| | | | <- | - -| - -| Ack | |
| | <- | - - | ACM | | | | |
| <- | ACM | | | | | | |
| | | | | | | | off |
| | | | | | | | hook|
| | | | <- | - -| - -| Notify| |
| | | | Ack | - -| - -| -> | |
| | | | Notification | | | | |
| | | | Request | - -| - -| -> | |
| | | | <- | - -| - -| Ack | |
| | | <- | Modify | | | | |
| | | | Connection | | | | |
| | | Ack | -> | | | | |
| | | (cut-in)| Call start | - -| -> | | |
| | <- | - - | ANM | | | | |
| <- | ANM | | | | | | |
|____|______|__________|_______________|_____|_____|________|______|
Huitema, Andreasen, Arango [Page 10]
Internet draft MGCP Call Flows 11 November 1998
_____________________________________________________________
| CO| SS7/| TGW | CA | CDB| ACC| RGW | Usr |
| | ISUP| | | | | | |
|___|______|______|______________|_____|_____|________|______|
| | | | | | | | on |
| | | | | | | | hook|
| | | | <- | - -| - -| Notify| |
| | | | Ack | - -| - -| -> | |
| | | | Delete | | | | |
| | | | Connection | - -| - -| -> | |
| | | <- | Delete | | | | |
| | | | Connection | | | | |
| | <- | - - | REL | | | | |
| <-| REL | | | | | | |
| | | Perf| | | | | |
| | | data| -> | | | | |
| | | | <- | - -| - -| perf | |
| | | | | | | data | |
| | | | Call end | - -| -> | | |
| | | | Notification| | | | |
| | | | Request | - -| - -| -> | |
| | | | <- | - -| - -| Ack | |
|___|______|______|______________|_____|_____|________|______|
This diagram shows the various exchange of messages during a call from a
telephone user on the circuit-switched PSTN to a residential user con-
nected to a residential gateway. During these exchanges the Call Agent
uses MGCP to control both the TGW and the residential gateway. The
exchanges occur on two sides.
Upon reception of the IAM message, the Call Agent immediately sends a
CreateConnection request to the trunking gateway to connect to the
incoming trunk, creating a connection:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
The trunking gateway immediately acknowledges the creation, sending back
the identification of the newly created connection and the session
description used to receive audio data:
Huitema, Andreasen, Arango [Page 11]
Internet draft MGCP Call Flows 11 November 1998
200 1237 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP announcement, in our example, specifies the address at which the
gateway is ready to receive audio data (128.96.41.1), the transport pro-
tocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio
profile refers to RFC 1890, which defines that the payload type 0 has
been assigned for G.711 transmission. The gateway is also ready to use
ADPCM encoding at 32 kbps (G.726 -4). There is no standard payload type
associated to ADPCM, so the gateway mentions its readiness to use a non
standard payload associated to the dynamic type 96. The "rtpmap" attri-
bute entry associates the payload type 96 to G726/4.
The Call Agent, having seized the incoming trunk, must now reserve the
outgoing circuit. It does so by sending a connection command to the
residential gateway:
CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The CreateConnection command has the same parameters as the command sent
to the ingress gateway, with two differences:
* The EndpointId points towards the outgoing trunk,
* The message carries the session description returned by the ingress
gateway,
* Because the session description is present, the "mode" parameter is
set to "send/receive".
We observe that the call identifier is identical for the two connec-
tions. This is normal: the two connection belong to the same call, which
Huitema, Andreasen, Arango [Page 12]
Internet draft MGCP Call Flows 11 November 1998
has a global identifier in our system.
The residential gateway will acknowledge the connection command, sending
in the session description its own parameters such as address, ports and
RTP profile:
200 1238 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent will relay the information to the ingress gateway, using
a ModifyConnection command:
MDCX 1239 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The trunking gateway immediately acknowledges the modification:
200 1239 OK
At this stage, the Call Agent has established a half-duplex transmission
path. The Call Agent must now tells the residential gateway to ring the
called line. It will send a NotificationRequest, consisting of the fol-
lowing lines:
RQNT 1240 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
R: hd
S: rg
The residential gateway, at that point, is instructed to look for an
off-hook event, and to report it. It will first acknowledge the command,
Huitema, Andreasen, Arango [Page 13]
Internet draft MGCP Call Flows 11 November 1998
repeating in the acknowledgement message the transaction id that the
Call Agent attached to the query.
200 1240 OK
Upon reception of this message, the Call Agent sends an address complete
message (ACM) to the calling switch, which we assume will generate ring-
ing tones for the calling user.
When the gateway notices the off hook event, it sends a Notify command
to the Call Agent:
NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B0
O: hd
The Call Agent immediately acknowledges that notification.
200 2001 OK
The Call Agent now asks the residential gateway to send a Notify command
on the occurrence of an on-hook event. It does so by sending a Notifica-
tionRequest to the residential gateway:
RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
R: hu
The gateway acknowledges that command:
200 1241 OK
In parallel, the Call Agent will send a ModifyConnection command to the
trunking gateway, to place the connection in full duplex mode:
MDCX 1242 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
The trunking gateway will acknowledge that command:
Huitema, Andreasen, Arango [Page 14]
Internet draft MGCP Call Flows 11 November 1998
200 1242 OK
The Call Agent can now send an answer message (ANM) to the calling
switch.
After some time, the Call Agent will have to tear down the call. In our
example, this is triggered by the residential user, who hangs up. The
Notify command is sent to the Call Agent:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
O: hu
The Call Agent acknowledges the notification.
200 2005 OK
It will then send to both gateways a DeleteConnection command:
DLCX
1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:32F345E2
DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
The gateways will respond with a message that should include a "call
parameters" header fields:
250 1243 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,
LA=48
250 1244 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,
LA=48
The Call Agent should now issue a new NotificationRequest to the
residential gateway to detect the next off-hook event:
Huitema, Andreasen, Arango [Page 15]
Internet draft MGCP Call Flows 11 November 1998
RQNT 1245 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B2
R: hd
The residential gateway will acknowledge this command:
200 1245 OK
Both gateways, at this point, are ready for the next call.
Huitema, Andreasen, Arango [Page 16]
Internet draft MGCP Call Flows 11 November 1998
2.3. Basic call from an R2 trunk in a TGW to an SS7 trunk in a TGW
_______________________________________________________________________________________
| CO | R2 | CA | CDB| ACC| TGW | SS7/| CO |
| | TGW | | | | | ISUP| |
|_______|____________|________________|_______|_______|______________|________|_______|
| | <- | Notification| | | | | |
| | | Request | | | | | |
| | Ack | -> | | | | | |
|Trunk | | | | | | | |
|seizure| | | | | | | |
| & | | | | | | | |
|Called | | | | | | | |
|&callng| | | | | | | |
|number | | | | | | | |
|digit | | | | | | | |
|collec-| | | | | | | |
|tion | -> | | | | | | |
| | Notify | -> | | | | | |
| | <- | Ack | | | | | |
| | <- | Notification| | | | | |
| | | Request | | | | | |
| | Ack | -> | | | | | |
| | <- | Create | | | | | |
| | | Connection | | | | | |
| | Ack | -> | | | | | |
| | | Query | | | | | |
| | | (E.164 S,D) | -> | | | | |
| | | <- | IP | | | | |
| | | Create | | | | | |
| | | Connection | - -| - -| -> | | |
| | | | | | (cut in) | | |
| | | <- | - -| - -| ack | | |
| | | IAM | - -| - -| - - | -> | |
| | <- | Modify | | | | IAM | -> |
| | | Connection | | | | | |
| | Ack | -> | | | | <- | ACM|
| | | <- | - -| - -| - - | ACM | |
| | | | | | | <- | ANM|
| | | <- | - -| - -| - - | ANM | |
| | <- | Modify | | | | | |
| | | Connection | | | | | |
| | Ack | -> | | | | | |
| | (cut in)| Call start | - -| -> | | | |
|_______|____________|________________|_______|_______|______________|________|_______|
Huitema, Andreasen, Arango [Page 17]
Internet draft MGCP Call Flows 11 November 1998
_________________________________________________________________________________
| CO | R2 | CA | CDB| ACC| TGW | SS7/| CO |
| | TGW | | | | | ISUP| |
|________|__________|________________|_______|_______|_________|________|_______|
| | | | | | | <- | REL|
| | | <- | - -| - -| - - | REL | |
| | | Delete | | | | | |
| | <- | Connection | | | | | |
| | | | | | | | |
| | Clear- | | | | | | |
| <- | back | Delete | | | | | |
| Clear- | | Connection | - -| - -| -> | | |
| fwd | -> | | | | | | |
| | Rel- | | | | | | |
| <- | guard | | | | | | |
| | | | | | | | |
| | Perf | | | | | | |
| | Data | -> | | | | | |
| | | <- | - -| - -| Perf | | |
| | | | | | data | | |
| | | Call end | - -| -> | | | |
| | <- | Notification| | | | | |
| | | Request | | | | | |
| | Ack | -> | | | | | |
|________|__________|________________|_______|_______|_________|________|_______|
The above diagram describes the call flow between a trunk with R2 sig-
naling in a trunking gateway and an SS7 trunk in a trunking gateway. R2
is a type of Channel Associated Signaling (CAS) and this call flow
assumes the use of an R2 package. The following diagram describes a sim-
plified R2 package. In this package digit arrival events are not
observed by the Call Agent and therefore cannot be part of a Notifica-
tionRequest. The first event that the Call Agent can observe in an R2
trunk is a "call-in" event which is a combination of the arrival at the
gateway of a trunk seizure signal and collection of the called (destina-
tion) and calling (source) and calling party numbers from the R2 regis-
ters. The notification for a call-in event occurs when digit collection
is completed. The clear forward event indicates that the exchange at the
other side released the trunk.
__________________________________________________________________
Symbol Definition R S Duration
__________________________________________________________________
ci Call in x
cf Clear forward x
dn Destination number
sn Source number
Huitema, Andreasen, Arango [Page 18]
Internet draft MGCP Call Flows 11 November 1998
|_________|______________________|_______|________________________|
The first command is a NotificationRequest, sent by the Call Agent to
the R2 trunking gateway. The request will consist of the following
lines:
RQNT 1201 trunk-group-1/*@r2tgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
R: ci
The gateway, at that point, is instructed to look for a call-in event in
any of the trunks corresponding to a trunk group named trunk-group-1.
The gateway responds with the acknowledgement message:
200 1201 OK
When the call-in event is detected, the gateway sends a Notify to the
Call Agent:
NTFY 2001 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
O: ci, dn(5313456789), sn(5845430978)
This notification indicates the occurrence of a call-in event in trunk
#5 in trunk-group-1. It also contains the collected destination (dn) and
source (sn) party numbers. The Call Agent immediately acknowledges that
notification.
200 2001 OK
At this stage, the Call Agent sends a NotificationRequest to wait for a
trunk release signal:
RQNT 1203 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
X: 0123456789AD
R: cf The Call Agent immediately acknowledges that command.
200 1203 OK
The Call Agent will then seize the incoming circuit, creating a connec-
tion:
CRCX 1204 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
Huitema, Andreasen, Arango [Page 19]
Internet draft MGCP Call Flows 11 November 1998
The gateway immediately acknowledges the creation, sending back the
identification of the newly created connection and the session descrip-
tion used to receive audio data:
200 1204 OK
I:FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent, having seized the incoming trunk and completed a routing
look up to identify the outgoing gateway, seizes the outgoing trunk. It
does so by sending a connection command to the egress gate- way:
CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SS7 trunking gateway acknowledges the connection command, sending in
the session description its own parameters such as address, ports and
RTP profile:
200 1205 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent relays the information to the ingress gateway, using a
ModifyConnection command:
MDCX 1206 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
Huitema, Andreasen, Arango [Page 20]
Internet draft MGCP Call Flows 11 November 1998
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The R2 trunking gateway immediately acknowledges the modification:
200 1206 OK
At this stage, the Call Agent has established a half duplex transmission
path. The subscriber that originated the call will be able to receive
signals, such as tones or announcements, that the remote switch may send
through the trunking gateways.
After the called user answers the call, the Call Agent will receive an
answering message (ANM) from the CO switch. At that point, it sends a
ModifyConnection command, to place the connection in full-duplex mode:
MDCX 1209 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
The R2 trunking gateway acknowledges the modify command:
200 1209 OK
At this point, the connection is established.
When the Call Agent receives the REL message from the CO switch,
it will have to tear down the call. It will do so by sending to
both gateways a DeleteConnection command:
DLCX
1210 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:32F345E2
The gateways will respond with acknowledgements that should
include a "call parameters" header fields:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,
LA=48
Huitema, Andreasen, Arango [Page 21]
Internet draft MGCP Call Flows 11 November 1998
250 1211 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,
LA=48
Finally, the Call Agent issues a new NotificationRequest, to be
ready to receive the next call-in event detected by the trunking
gateway at the specified trunk:
RQNT 1212 trunk-group-1/5@r2tgw-2567.whatever.net MGCP 0.1
X: 0123456789B0
R: hd
The gateway will acknowledge this message:
200 1212 OK
Both gateways, at this point, are ready for the next call.
Huitema, Andreasen, Arango [Page 22]
Internet draft MGCP Call Flows 11 November 1998
2.4. Basic call from an ISDN trunk in a business gateway to an
SS7 trunk in a TGW
______________________________________________________________________________________________________
| PBX | Business | CA | CDB| ACC | TGW | SS7/| CO | |
| | GW | | | | | ISUP| | |
| - | | | | | | | | |
|SETUP | -> | -> | | | | | | |
| <- | <- | CALLPROC. | | | | | | |
| | <- | Create | | | | | | |
| | | Connection | | | | | | |
| | Ack | -> | | | | | | |
| | | Query | | | | | | |
| | | (E.164 S,D) | -> | | | | | |
| | | <- | IP | | | | | |
| | | Create | | | | | | |
| | | Connection | - -| - - | -> | | | |
| | | | | | (cut in) | | | |
| | | <- | - -| - - | ack | | | |
| | | IAM | - -| - - | - - | -> | | |
| | <- | Modify | | | | IAM | -> | |
| | | Connection | | | | | | |
| | Ack | -> | | | | <- | ACM| |
| | | <- | - -| - - | - - | ACM | | |
| <- | <- | ALERT | | | | | | |
| | <- | Notification | | | | | | |
| | | Request | | | | | | |
| | Ack | -> | | | | | | |
| <- | Ringing | | | | | | | |
| | | | | | | <- | ANM| |
| | | <- | - -| - - | - - | ANM | | |
| | <- | RQNT+MDCX | | | | | | |
| | Ack | -> | | | | | | |
| | (cut in)| Call start | - -| -> | | | | |
|_______|____________|_____________________|_______|______________|______________|________|_______|__|
Huitema, Andreasen, Arango [Page 23]
Internet draft MGCP Call Flows 11 November 1998
____________________________________________________________________________________
| PBX | Business| CA | CDB| ACC| TGW | SS7/| CO | |
| | GW | | | | | ISUP| | |
|________|__________|________________|_______|_______|_________|________|_______|__|
| | | | | | | <- | REL| |
| | | <- | - -| - -| - - | REL | | |
| | | Delete | | | | | | |
| | <- | Connection | | | | | | |
| | | | | | | | | |
| <- | DISC | Delete | | | | | | |
| | | Connection | - -| - -| -> | | | |
| | Perf | | | | | | | |
| | Data | -> | | | | | | |
| | | <- | - -| - -| Perf | | | |
| | | | | | data | | | |
| | | Call end | - -| -> | | | | |
| | | RLC | - - | - - | - - | -> | -> | |
| <- | <- | RLSE | | | | | | |
|RLCOM | -> | -> | | | | | | |
|________|__________|________________|_______|_______|_________|________|_______|__|
The above diagram describes the call flow between a trunk with
ISDN signaling in a business gateway and an SS7 trunk in a
trunking gateway.
This call flow assumes that the ISDN Q.931 signaling messages
are "tunnelled" to the call agent. The tunnelling protocol,
together with configuration tables, allows the call agent to
associate the signalling messages to the endpoint corresponding
to the B-channel. The specifics of the tunnelling protocol are
being worked on by the IETF.
The call is triggered by the arrival of a SETUP command, which
is relayed to the Call Agent. The call agent analyzes teh com-
mand, to obtain the destination (dn) and source (sn) party
numbers. The call agent sends a call progress message, which is
tunneled to the gateay and relayed over the D-Channel. The Call
Agent then seizes the incoming circuit, creating a connection:
CRCX 1204 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection and the
Huitema, Andreasen, Arango [Page 24]
Internet draft MGCP Call Flows 11 November 1998
session descrip- tion used to receive audio data:
200 1204 OK
I:FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent, having seized the incoming trunk and completed a
routing look up to identify the outgoing gateway, seizes the
outgoing trunk. It does so by sending a connection command to
the egress gate- way:
CRCX 1205 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SS7 trunking gateway acknowledges the connection command,
sending in the session description its own parameters such as
address, ports and RTP profile:
200 1205 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The Call Agent relays the information to the ingress gateway,
using a ModifyConnection command:
MDCX 1206 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: recvonly
v=0
c=IN IP4 128.96.63.25
Huitema, Andreasen, Arango [Page 25]
Internet draft MGCP Call Flows 11 November 1998
m=audio 1297 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The business gateway immediately acknowledges the modification:
200 1206 OK
At this stage, the Call Agent has established a half duplex
transmission path. The subscriber that originated the call will
be able to receive signals, such as tones or announcements, that
the remote switch may send through the trunking gateways.
When the call progresses, the Call Agent will receive from the
remote switch progress messages, for example an "address com-
plete" message (ACM). The Call Agent will tunnel an ALERT mes-
sage to the originating PBX. It may, if needed, send a notifi-
cation request command to the gateway, to generate alerting
tones over the B-channel:
RQNT 1207 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
X: 0123456789AE
S: rt
The gateway immediately acknowledges the command:
200 1207 OK
After the called user answers the call, the Call Agent will
receive an answering message (ANM) from the CO switch. At that
point, it will send a ModifyConnection command to the business
gateway, to place the connection in full duplex mode, and an
embedded NotificationRequest to stop the ringing tones:
MDCX 1209 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
X: 0123456789AF
S:
The business gateway will acknowledge the command:
200 1209 OK
At this point, the connection is established.
When the Call Agent receives the REL message from the CO switch,
it will have to tear down the call. It will do so by sending to
Huitema, Andreasen, Arango [Page 26]
Internet draft MGCP Call Flows 11 November 1998
both gateways a DeleteConnection command:
DLCX 1210 isdn-trunk-group-1/3@isdngw-45.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
DLCX 1211 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:32F345E2
The gateways will respond with acknowledgements that should
include a "call parameters" header fields:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,
LA=48
250 1211 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27,
LA=48
Having freed the local resource, the call agent will confirm the
release by sending a RLC message to the next switch, and will
also send a release message through the Q.931 tunnel to the PBX.
The PBX will send back a release confirmation.
Both gateways, at this point, are ready for the next call.
Huitema, Andreasen, Arango [Page 27]
Internet draft MGCP Call Flows 11 November 1998
2.5. Basic call with continuity test, TGW to RGW
_______________________________________________________
| CO | SS7/| TGW| CA | CDB| ACC| RGW| Usr|
| | ISUP| | | | | | |
|____|______|_____|____________|_____|_____|_____|_____|
| IAM| -> | | | | | | |
| | IAM | - -| -> | | | | |
| | | | Check | -> | | | |
| | | | <- | IP | | | |
| | | <- | Create | | | | |
| | | | Connection| | | | |
| | | Ack| -> | | | | |
| COT| -> | | | | | | |
| | COT | - -| -> | | | | |
| | | <- | Modify | | | | |
| | | | Connection| | | | |
| | | | Create | | | | |
| | | | Connection| - -| - -| -> | |
| | | | <- | - -| - -| Ack| |
|____|______|_____|____________|_____|_____|_____|_____|
This diagram shows the various exchange of messages during the
beginning of a call from a telephone user on the circuit-
switched PSTN to a residential user connected to a residential
gateway. During these exchanges the Call Agent uses MGCP to con-
trol both the TGW and the residential gateway. The circuit
switch decides to execute a continuity test during the call
establishment. The exchanges occur on two sides.
Upon reception of the IAM message, the Call Agent recognizes
that a continuity test has been requested. It immediately sends
a CreateConnection request to the trunking gateway to connect to
the incoming trunk, creating a connection:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: conttest
The trunking gateway recognizes that the mode is set to
"conttest". It places the circuit in "continuity test" mode,
ready to send back the 2010 Hz return tone if it receives a 1780
Hz tone. The gateway acknowledges the creation of the connec-
tion, sending back the identification of the newly created con-
nection and the session description used to receive audio data:
Huitema, Andreasen, Arango [Page 28]
Internet draft MGCP Call Flows 11 November 1998
200 1237 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
At this point, the call agent is waiting for the result of the
continuity test. The calling switch is sending the test tone
(1780 Hz); if it receives the return tone (2010 Hz), it will
send a "continuity passed" message (COT). At this point, the
call agent will send a modify connection message to the gateway,
in order to place the connection in "recvonly" mode:
MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
M: recvonly
The gateway will immediately acknowledge that command:
200 1238 OK
The Call Agent will then proceed with the establishment of the
call.
Huitema, Andreasen, Arango [Page 29]
Internet draft MGCP Call Flows 11 November 1998
3. Interaction between an MGCP controlled gateway and an H.323
entity
MGCP is not intended to replace H.323, or even to compete with
it. In fact, we should mostly consider it as a tool to enable
distributed implementations of H.323, as shown in the following
picture. The combination of gateways and call agent behaves as a
distributed H.323 system, using MGCP for internal communication.
This system appears to H.323 users as a larger H.323 system, or,
if one prefers, as an H.323 gatekeeper that implements the Gate-
keeper routed call model.
In order to demonstrate the compatibility between MGCP and
H.323, we provide here a step by step demonstration of 2 call
set up scenarios:
* Call from an MGCP controlled residential gateway to an
H.323 entity,
* Call from an H.323 entity to an MGCP controlled residential
gateway.
We suppose, in these scenarios, that the H.323 entity is capable
of using the fast start procedure defined in H.323v2.
Huitema, Andreasen, Arango [Page 30]
Internet draft MGCP Call Flows 11 November 1998
3.1. Call from a residential gateway (RGW) to an H.323 user
_____________________________________________________________________
| Usr | RGW | CA | H.323 | Usr | GK |
|____________|___________|______________|___________|__________|_____|
| | <- | RQNT | | | |
| | Ack | -> | | | |
| | | | | | |
| Off-hook | Notify | -> | | | |
| <- | Ack | | | | |
| (Dial-tone)| <- | RQNT | | | |
| | Ack | -> | | | |
| | | | | | |
| Digits | Notify | -> | | | |
| <- | Ack | | | | |
| (progress) | <- | CRCX+RQNT | | | |
| | Ack | -> | | | |
| | | (processing)| | | |
| | | TCP-SYN | -> | | |
| | | <- | SYN, ACK | | |
| | | Set-up+ | | | |
| | | faststart | -> | | |
| | | | ARQ | - - - | -> |
| | | | <- | - - - | ACF|
| | | <- | alerting | ring | |
| | | TCP ACK | -> | | |
| (ring back)| <- | RQNT | | | |
| | Ack | -> | | | |
| | | <- | connect +| off hook| |
| | | | faststart| | |
| | | TCP ACK | -> | | |
| | <- | MDCX+RQNT | | | |
| | Ack | -> | | | |
| | | (call est.) | | | |
| on hook | Notify | -> | | | |
| <- | Ack | | | | |
| <- | DLCX+RQNT| | | | |
| perf data | -> | | | | |
| | | Rel. C. | -> | | |
| | | TCP-FIN | -> | | |
| | | <- | FIN, ACK | | |
| | | TCP ACK | -> | | |
| | | | (signal) | On-hook | |
| | | | DRQ | - - - | -> |
| | | | <- | - - - | DCF|
|____________|___________|______________|___________|__________|_____|
Huitema, Andreasen, Arango [Page 31]
Internet draft MGCP Call Flows 11 November 1998
During these exchanges the MGCP is used by the call agent to
control the residential gateways. The call will be routed to an
H.323 entity. The first command is a notification request, sent
by the call agent to the residential gateway. The request will
consist of the following lines:
RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
R: hd
The gateway, at that point, is instructed to look for an off-
hook event, and to report it. It will first acknowledge the
request, repeating in the acknowledgement message the transac-
tion id that the call agent attached to the query.
200 1201 OK
Note that this command is not actually simultaneous with the
call. It can be issued long before the actual call, for example
when the gateway is turned on, or after the end of a previous
call.
When the off hook event is noticed, the gateway sends a Notify
command to the call agent:
NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent examines the services associated to an off hook
action (it could take special actions in the case of a direct
line). In most cases, it will send a notification request, ask-
ing for digits. The current example provides the gateway with a
digit map, and requests the gateway to play a dialtone:
Huitema, Andreasen, Arango [Page 32]
Internet draft MGCP Call Flows 11 November 1998
RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: hu, [0-9#*T](D)
D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx | 9011x.T)
S: dl
The gateway immediately acknowledges that request.
200 1202 OK
The gateway will start accumulating digits according to that
digit map. When it has noticed a sufficient set of values, it
will notify the observed string to the call agent:
NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
O: 912018294266
The call agent immediately acknowledges that notification.
200 2002 OK
At this stage, the call agent seizes the incoming circuit,
creating a connection. It will also send together with that
creation request a notification request, to stop collecting
digits yet continue watch for an on-hook transition:
CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
X: 0123456789AD
R: hu
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection and the ses-
sion description used to receive audio data:
Huitema, Andreasen, Arango [Page 33]
Internet draft MGCP Call Flows 11 November 1998
200 1204 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
The SDP announcement, in our example, specifies the address at
which the gateway is ready to receive audio data (128.96.41.1),
the transport protocol (RTP), the RTP port (3456) and the audio
profile (AVP). The audio profile refers to RFC 1890, which
defines that the payload type 0 has been assigned for G.711
transmission.
The call agent, having seized the incoming trunk, proceeds with
call routing. Using local databases, it determines that the
dialed digits (912018294266) correspond to a H.323 entity. It
will set up a TCP-IP connection and send an H.225/Q.931 "set-up"
message to the H.323 entity. In this message, the "faststart"
element carries a set of open logical channel proposals, derived
from the SDP description received from the calling gateway:
Huitema, Andreasen, Arango [Page 34]
Internet draft MGCP Call Flows 11 November 1998
faststart-1 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 1,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms G.711 frame
multiplexParameters
h2250LogicalChannelParameters H2250LogicalChannelParameters {
sessionID 1,
silenceSuppression FALSE
}
}
}
faststart-2 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 2,
forwardLogicalChannelParameters {
dataType nullData, -- pro forma
multiplexParameters none
},
reverseLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters
h2250LogicalChannelParameters H2250LogicalChannelParameters {
sessionID 2,
mediaChannel unicastAddress iPAddress {
network '80602901'H, -- 128.96.41.1
tsapIdentifier 3456 -- port
},
mediaControlChannel unicastAddress iPAddress {
network '80602901'H, -- 128.96.41.1
tsapIdentifier 3457 -- port
},
silenceSuppression FALSE
}
}
}
The H.323 alerts the user, and sends an H.225/Q.931 "alerting"
message. On reception of this message, the call agent will send
a notification request that instruct the RGW to generate alert-
ing tones:
RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AE
R: hu
S: v
Huitema, Andreasen, Arango [Page 35]
Internet draft MGCP Call Flows 11 November 1998
When the called user accepts the call, the H.323 entity sends an
H.225/Q.931
set-up
message to the call agent. If the H.323 entity accepted the
fast start procedure, the faststart
parameter will contain the confirmation of the open logical
channel creations in the two directions of communication:
faststart-1 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 1,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters h2250LogicalChannelParameters {
sessionID 1,
mediaChannel unicastAddress iPAddress {
network '80603F19'H,
tsapIdentifier 3456, -- port
} ,
mediaControlChannel unicastAddress iPAddress {
network '80603F19'H,
tsapIdentifier 3457, -- port
} ,
silenceSuppression FALSE
}
}
}
faststart-2 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 2,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters h2250LogicalChannelParameters {
sessionID 2,
silenceSuppression FALSE
}
}
}
The call agent will send a modification request to the residen-
tial gateway, in order to establish a full duplex connection.
The SDP payload, in that request, is derived from the parameters
of the logical channel for transmission from the gateway to the
H.323 entity.
Huitema, Andreasen, Arango [Page 36]
Internet draft MGCP Call Flows 11 November 1998
MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
M: sendrecv
X: 0123456789AF
R: hu
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The gateway will acknowledge this request:
200 1209 OK
At this point, the connection is established.
In our example, the call is terminated when the calling party
hangs up. This triggers a Notify command to the call agent:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AF
O: hu
After this notification, the call agent should send an ack-
nowledgement:
200 2005 OK
The call agent will then clear the call, by sending a delete
connection request to the calling gateway. This request is com-
bined with a notification request, to be ready to detect the
next call issued by the residential gateway:
DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
X: 0123456789B0
R: hd
The gateway will respond with a message that should include a
"call parameters" header field:
Huitema, Andreasen, Arango [Page 37]
Internet draft MGCP Call Flows 11 November 1998
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
The call agent will in parallel sends an H.225/Q.931 "release
complete" message to the H.323 entity. It will then tear down
the TCP-IP connection. The gateway, at this point, is ready for
the next call. The H.323 user will be ready as soon as the H.323
entity notices that the phone is back on hook.
Huitema, Andreasen, Arango [Page 38]
Internet draft MGCP Call Flows 11 November 1998
3.2. Basic call, H.323 to RGW
___________________________________________________________________
| User | H.323 | GK | CA | RGW | Usr |
|_______|____________|_______|______________|___________|__________|
| call | -> | | | | |
| | ARQ | -> | | | |
| | <- | ACF | | | |
| | TCP SYN | - - -| -> | | |
| | <- | - - -| SYN+ACK | | |
| | set-up+ | | | | |
| | fast start| - - -| -> | | |
| | | | (call | | |
| | | | processing) | | |
| | | | CRCX+RQNT | -> | ring |
| | | | <- | Ack | |
| | <- | - - -| alerting | | |
| | TCP ACK | - - -| -> | | |
| | (ringing) | | | | |
| | | | <- | Notify | off hook|
| | | | Ack | -> | |
| | | | RQNT | -> | |
| | | | <- | Ack | |
| | <- | - - -| connect + | | |
| | | | fast start | | |
| | TCP ACK | - - -| -> | | |
| | | | (call | | |
| | | | established)| | |
| | | | | | |
| | | | <- | Notify | on hook |
| | | | Ack | -> | |
| | | | (no | | |
| | | | suspension) | | |
| | | | RQNT | -> | |
| | | | <- | Ack | |
| hangup| detected | | | | |
| | Rel. C. | | | | |
| | TCP FIN | - - -| -> | | |
| | <- | - - -| FIN ACK | | |
| | | | DLCX+RQNT | -> | |
| | | | <- | perf data| |
| | DRQ | -> | | | |
| | <- | DCF | | | |
|_______|____________|_______|______________|___________|__________|
This diagram shows the various exchange of messages during a
call from an H.323 user to a residential user. During these
Huitema, Andreasen, Arango [Page 39]
Internet draft MGCP Call Flows 11 November 1998
exchanges the MGCP is used by the call agent to control the
residential gateway.
When the user initiates the call, the H.323 entity will perform
a RAS transaction with its designated Gatekeeper. As a result of
this transaction, it will learn the TCP-IP address of the call
agent, and will set up a TCP-IP connection with the call agent.
Once the TCP-IP connection is established, the H.323 entity
sends a Q.931/H.225 connect message to the call agent. The mes-
sage, in its user-to-user parameter, includes a "fast start"
parameter that lists a set of OpenLogicalChannel proposals, such
as for example:
faststart-1 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 1,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms G.711 frame
multiplexParameters h2250LogicalChannelParameters {
sessionID 1,
silenceSuppression FALSE
}
}
}
faststart-2 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 2,
forwardLogicalChannelParameters {
dataType nullData, -- pro forma
multiplexParameters none
},
reverseLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters h2250LogicalChannelParameters {
sessionID 2,
mediaChannel unicastAddress iPAddress {
network '80602901'H, -- 128.96.41.1
tsapIdentifier 3456, -- port
},
mediaControlChannel unicastAddress iPAddress {
network '80602901'H, -- 128.96.41.1
tsapIdentifier 3457, -- port
},
silenceSuppression FALSE
}
}
}
Upon reception of the set-up message, the call agent will
Huitema, Andreasen, Arango [Page 40]
Internet draft MGCP Call Flows 11 November 1998
perform called routing functions and determine the end point
that correspond to the called party number. It will reserve the
outgoing circuit. It does so and at the same time it requests
ringing, by sending to the residential gateway a create connec-
tion request combined with a notification request:
CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711
M: sendrecv
X: 0123456789B1
R: hd
S: rg
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
In this command, the SDP announcement is obtained by translating
the "faststart" parameters corresponding to the receive channel
announced by the caller - channel 2 in our case. The IP address,
RTP port and authorized payload are derived from the "reverseLo-
gicalChannelParameters" data elements. We derive the authorized
payload type from the "dataType" element. We have however to
check that this value is proposed in at least one of the forward
channels.
The gateway will acknowledge the connection request, sending in
the session description its own parameters such as address,
ports and RTP profile:
200 1238 OK
I: 32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The phone is ringing, and the gateway, is instructed to look for
an off-hook event, and to report it. The call agent sends an
alerting message to the calling switch, which we assume will
generate ringing tones for the calling user.
When the off hook event is noticed, the gateway sends a Notify
command to the call agent:
Huitema, Andreasen, Arango [Page 41]
Internet draft MGCP Call Flows 11 November 1998
NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B0
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent must now ask the residential gateway to notify
the occurrence of an on-hook event. It does so by sending a
notification request to the residential gateway:
RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1X: 0123456789B1
R: hu
The gateway acknowledges that request:
200 1241 OK
In parallel, the call agent will send a "connect" message to the
H.323 agent. The message includes the "fast start" parameter,
which will validate and complement the proposals that the caller
sent:
Huitema, Andreasen, Arango [Page 42]
Internet draft MGCP Call Flows 11 November 1998
faststart-1 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 1,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters h2250LogicalChannelParameters {
sessionID 1,
mediaChannel unicastAddress iPAddress {
network '80603F19'H,
tsapIdentifier 3456, -- port
} ,
mediaControlChannel unicastAddress iPAddress {
network '80603F19'H,
tsapIdentifier 3457, -- port
} ,
silenceSuppression FALSE
}
}
}
faststart-2 OpenLogicalChannel ::= {
forwardLogicalChannelNumber 2,
forwardLogicalChannelParameters {
dataType g711Ulaw64k 160, -- 20 ms frame
multiplexParameters h2250LogicalChannelParameters (
sessionID 1,
silenceSuppression FALSE
}
}
}
After some time, in our example, the residential user hangs up.
The notify request is sent to the call agent:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
O: hu
The call agent acknowledges the notification.
200 2005 OK
Upon reception of that notification, the call agent should send
a "suspend" message to the calling H.323 entity, but the Q.931
suspend message should not be sent in H.225. In order to
preserve the user experience, the call agent will simply
Huitema, Andreasen, Arango [Page 43]
Internet draft MGCP Call Flows 11 November 1998
initiate a timer, after which it would actually release the
call. (In North-America, the call is not actually terminated if
the called party hangs up. If it hangs down in a short interval,
the call will be resumed.) The call agent, in any case, sends a
notification request to the gateway, to look for an off-hook
event.
RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B2
R: hd
The gateway will acknowledge this request:
200 1243 OK
In our example, the calling user releases the call immediately.
The H.323 agent sends a "release complete" message to the call
agent, which will then send a delete connection request to the
residential gateway. The request sent to the gateway is com-
bined with a request to detect a off-hook event, which will be
used to detect rare conditions where the user would have gone
off hook simultaneously with the release on the other side:
DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
X: 0123456789B3
R: hd
I: FDE234C8
The gateway will respond with a message that should include a
"call parameters" header fields:
200 1244 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
The gateway, at this point, is ready for the next call.
Huitema, Andreasen, Arango [Page 44]
Internet draft MGCP Call Flows 11 November 1998
4. Interworking between SIP and MGCP
The use of SDP in both MGCP and SIP makes interworking between
these protocols very easy. In order to demonstrate this inter-
working, we provide here a step by step demonstration of 2 call
set-up scenarios:
* Call from an MGCP controlled residential gateway to a SIP
agent,
* Call from a SIP agent to an MGCP controlled residential
gateway.
4.1. Call from a residential gateway (RGW) to a SIP user
Huitema, Andreasen, Arango [Page 45]
Internet draft MGCP Call Flows 11 November 1998
___________________________________________________________________
| Usr | RGW | CA | SIP | Usr |
|____________|___________|______________|________________|_________|
| | <- | RQNT | | |
| | Ack | -> | | |
| | | | | |
| Off-hook | Notify | -> | | |
| | <- | | | |
| Ack | | | | |
| (Dial-tone)| <- | RQNT | | |
| | Ack | -> | | |
| | | | | |
| Digit | Notify | -> | | |
| | <- | Ack | | |
| (progress) | <- | | | |
| CRCX+RQNT | | | | |
| | Ack | -> | | |
| | | (processing)| | |
| | | INVITE | -> | |
| ring | | | | |
| | | <- | resp. 180 | |
| | | | (ringing) | |
| (ringing) | <- | RQNT | | |
| | Ack | -> | | |
| | | | | |
| | | <- | resp. 200 (OK)| |
| off hook | | | | |
| | | Ack | -> | |
| | <- | MDCX+RQNT | | |
| | Ack | -> | | |
| | | (call | | |
| | | established)| | |
| on hook | Notify | -> | | |
| | <- | Ack | | |
| | <- | DLCX+RQNT | | |
| | perf data| -> | | |
| | | BYE | -> | |
| | | <- | resp. 200 (OK)| |
| | | | (local) | On-hook|
|____________|___________|______________|________________|_________|
During these exchanges the MGCP is used by the call agent to
control the residential gateways. The call will be routed to a
SIP agent. The first command is a notification request, sent by
the call agent to the residential gateway. The request will
consist of the following lines:
Huitema, Andreasen, Arango [Page 46]
Internet draft MGCP Call Flows 11 November 1998
RQNT 1201 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
R: hd
The gateway, at that point, is instructed to look for an off-
hook event, and to report it. It will first acknowledge the
request, repeating in the acknowledgement message the transac-
tion id that the call agent attached to the query.
200 1201 OK
Note that this command is not actually simultaneous with
the call. It can be issued long before the actual call, for
example when the gateway is turned on, or after the end of
a previous call.
When the off hook event is noticed, the gateway initiates a
notification request to the call agent:
NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AB
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent examines the services associated to an off hook
action (it could take special actions in the case of a direct
line). In most cases, it will send a notification request, ask-
ing for digits. It will also provide the gateway with a digit
map, and requests the gateway to play a dialtone:
RQNT 1202 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: hu, D/[0-9#*T](D)
D: (0T | 1xxxxxxxxxx | [2-9]xxxxxx | [4789]11 | 011x.T)
S: dl
Huitema, Andreasen, Arango [Page 47]
Internet draft MGCP Call Flows 11 November 1998
The gateway immediately acknowledges that request.
200 1202 OK
The gateway will start accumulating digits according to that
digit map. When it has noticed a sufficient set of values, it
will notify the observed string to the call agent:
NTFY 2002 endpoint/1@rgw-2567.whatever.net MGCP 0.1
N: ca@ca1.whatever.net:5678
X: 0123456789AC
O: 912018294266
The call agent immediately acknowledges that notification.
200 2002 OK
At this stage, the call agent seizes the incoming circuit,
creating a connection. It will also send together with that
creation request a notification request, to stop collecting
digits yet continue watch for an on-hook transition:
CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
X: 0123456789AD
R: hu
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection and the ses-
sion description used to receive audio data:
200 1204 OK
I:FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP announcement, in our example, specifies the address at
which the gateway is ready to receive audio data (128.96.41.1),
Huitema, Andreasen, Arango [Page 48]
Internet draft MGCP Call Flows 11 November 1998
the transport protocol (RTP), the RTP port (3456) and the audio
profile (AVP). The audio profile refers to RFC 1890, which
defines that the payload type 0 has been assigned for G.711
transmission. The gateway is also ready to use ADPCM encoding at
32 kbps (G.726 -4). There is no standard payload type associated
to ADPCM, so the gateway mentions its readiness to use a non
standard payload associated to the dynamic type 96. The "rtpmap"
attribute entry associates the payload type 96 to G726-32/4.
The call agent, having seized the incoming trunk, proceeds with
call routing. Using local databases, it determines that the
dialed digits (912018294266) correspond to a SIP agent. It will
send an invitation to that agent:
INVITE sip:huitema@sip-station.bellcore.com SIP/2.0
Via: SIP/2.0/UDP 128.96.41.12
From: sip:123456789@ca.whatever.net
To: Christian Huitema <huitema@sip-station.bellcore.com>
Call-ID: A3C47F21456789F0@ca.whatever.net
Cseq: 1 INVITE
Content-type: application/sdp
Content-Length: ...
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The SDP attachment, in the INVITE message, is directly copied
from the acknowledgement of the Create Connection request. The
SIP agent alerts the user, and sends an immediate acknowledge-
ment:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 128.96.41.12
From: Christian Huitema <huitema@sip-station.bellcore.com>
To: 123456789@ca.whatever.net
Call-ID: A3C47F21456789F0@ca.whatever.net
Cseq: 1 INVITE
The call agent will send a notification request that instruct
the RGW to generate alerting tones:
Huitema, Andreasen, Arango [Page 49]
Internet draft MGCP Call Flows 11 November 1998
RQNT 1206 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AE
R: hu
S: v
When the called user accepts the call, the SIP agent sends an
acceptation message to the call agent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 128.96.41.12
From: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
To: sip:123456789@ca.whatever.net
Call-ID: A3C47F21456789F0@ca.whatever.net
CSeq: 1 INVITE
Content-type: application/sdp
Content-Length:...
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The gateway immediately acknowledges the call set up:
ACK huitema@sip-station.bellcore.com SIP/2.0
Via: SIP/2.0/UDP 128.96.41.12
From: 123456789@ca.whatever.net
To: huitema@sip-station.bellcore.com (Christian Huitema)
Call-ID: 187602141351@ca.whatever.net
Then, the call agent will send a modification request to the
residential gateway, in order to establish a full duplex connec-
tion. The SDP payload, in that request, is copied from the SIP
agent's response:
Huitema, Andreasen, Arango [Page 50]
Internet draft MGCP Call Flows 11 November 1998
MDCX 1209 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
X: 0123456789AF
R: hu
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 96
a=rtpmap:96 G726-32/8000
The gateway will acknowledge this request:
200 1209 OK
At this point, the connection is established. In our example,
the call is terminated when the calling party hangs up. This
triggers a Notify command to the call agent:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789AF
O: hu
After this notification, the call agent should send an ack-
nowledgement:
200 2005 OK
The call agent will then clear the call, by sending a delete
connection request to the calling gateway. This request is com-
bined with a notification request, to be ready to detect the
next call issued by the residential gateway:
DLCX 1210 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
X: 0123456789B0
R: hd
Huitema, Andreasen, Arango [Page 51]
Internet draft MGCP Call Flows 11 November 1998
The gateway will respond with a message that should include a
"call parameters" header field:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
The call agent will in parallel sends a BYE request to the SIP
agent:
BYE sip:huitema@sip-station.bellcore.com SIP/2.0
Via: SIP/2.0/UDP 128.96.41.12
From: sip:123456789@ca.whatever.net
To: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
Call-ID: A3C47F21456789F0@ca.whatever.net
CSeq: 2 BYE
The SIP agent will acknowledge that request:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 128.96.41.12
From: "Christian Huitema" <sip:huitema@sip-station.bellcore.com>
To: sip:123456789@ca.whatever.net
Call-ID: A3C47F21456789F0@ca.whatever.net
CSeq: 2 BYE SIP/2.0 200 OK
The gateway, at this point, is ready for the next call. The SIP
user will be ready as soon as the SIP agent notices that the
phone is back on hook.
Huitema, Andreasen, Arango [Page 52]
Internet draft MGCP Call Flows 11 November 1998
4.2. Basic call, SIP to RGW
_______________________________________________________________
| User | SIP agent| CA | RGW | Usr |
|_______|___________|___________________|___________|__________|
| call | -> | | | |
| | INVITE | -> | | |
| | | (call processing)| | |
| | | CRCX+RQNT | -> | |
| ring | | | | |
| | | <- | | |
| Ack | | | | |
| | <- | resp. 180 | | |
| | (ringing)| (ringing) | | |
| | | <- | Notify | off hook|
| | | Ack | -> | |
| | | RQNT | -> | |
| | | <- | Ack | |
| | <- | resp. 200 (OK) | | |
| | ACK | -> | | |
| | | (call | | |
| | | established) | | |
| | | | | |
| | | <- | Notify | on hook |
| | | Ack | -> | |
| | | (no susp. | | |
| | | message) | | |
| | | RQNT | -> | |
| | | <- | Ack | |
| | | | | |
| hangup| detected | | | |
| | BYE | -> | | |
| | | DLCX+RQNT | -> | |
| | | <- | perf data| |
|_______|___________|___________________|___________|__________|
This diagram shows the various exchange of messages during a
call from a
SIP user to a residential user. During these exchanges the
MGCP is used by the call agent to control the residential gate-
way.
When the user initiates the call, the SIP agent will send an
invitation to the call agent. (Our diagram assumes that the SIP
agent sends that invitation directly; in fact, there could be
several relays.) An example of invitation could be:
Huitema, Andreasen, Arango [Page 53]
Internet draft MGCP Call Flows 11 November 1998
INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: "T. A. Watson" <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-type: application/sdp
Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
Upon reception of the set-up message, the call agent will per-
form call routing functions and determine the end point that
corresponds to the invited user. It will then reserve the out-
going circuit. It does so at the same time that it requests
ringing, by sending to the residential gateway a connection
request combined with a notification request:
CRCX 1238 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711
M: sendrecv
X: 0123456789B1
R: hd
S: rg
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
c=IN IP4 135.180.144.94
m=audio 3456 RTP/AVP 0 3 4 5
In this command, the SDP announcement is directly copied from
the invitation. The gateway will acknowledge the connection
request, sending in the session description its own parameters
such as address, ports and RTP profile:
Huitema, Andreasen, Arango [Page 54]
Internet draft MGCP Call Flows 11 November 1998
200 1238 OK
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 3
The phone is ringing, and the gateway, is instructed to look for
an off-hook event, and to report it. The call agent sends an
alerting message to the calling SIP agent, which will generate
ringing tones for the calling user:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 169.130.12.5
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: sip:watson@bell-telephone.com
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 1 INVITE
When the off hook event is noticed, the gateway initiates a
notification request to the call agent:
NTFY 2001 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B0
O: hd
The call agent immediately acknowledges that notification.
200 2001 OK
The call agent must now ask the residential gateway to notify
the occurrence of an on-hook event. It does so by sending a
notification request to the residential gateway:
RQNT 1241 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
R: hu
The gateway acknowledges that request:
Huitema, Andreasen, Arango [Page 55]
Internet draft MGCP Call Flows 11 November 1998
200 1241 OK
In parallel, the call agent will send a final answer to the SIP
agent. The message, in its payload, copies the SDP announcement
that was sent by the gateway:
SIP/2.0 200 OK
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: sip:watson@bell-telephone.com
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 1 INVITE
Contact: sip://watson@boston.bell-telephone.com
Content-Length: ...
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0 3
The SIP agent acknowledges the set-up:
ACK sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: "T. A. Watson" <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 1 ACK
At this point, the call is established. After some time, in our
example, the residential user hangs up. The notify request is
sent to the call agent:
NTFY 2005 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B1
O: hu
The call agent acknowledges the notification.
200 2005 OK
Upon reception of that notification, the call agent should send
a "suspend" message to the calling SIP agent, but there is no
such message in SIP. In order to preserve the user experience,
Huitema, Andreasen, Arango [Page 56]
Internet draft MGCP Call Flows 11 November 1998
the call agent will simply initiate a timer, after which it
would actually release the call. (In North-America, the call is
not actually terminated if the called party hangs up. If it
hangs down in a short interval, the call will be resumed.) The
call agent, in any case, sends a notification request to the
gateway, to look for an off-hook event.
RQNT 1243 endpoint/1@rgw-2567.whatever.net MGCP 0.1
X: 0123456789B2
R: hd
The gateway will acknowledge this request:
200 1243 OK
In our example, the calling user releases the call immediately.
The SIP agent sends a BYE message to the call agent:
BYE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: "T. A. Watson" <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 2 BYE
The call agent acknowledges that message:
SIP/2.0 200 OK
From: "A. Bell" <sip:a.g.bell@bell-telephone.com>
To: sip:watson@bell-telephone.com
Call-ID: 187602141351@worcester.bell-telephone.com
CSeq: 2 BYE
The call agent then sends a delete connection request to the
residential gateway. The request sent to the gateway is combined
with a request to detect a off-hook event, which will be used to
detect rare conditions where the user would have gone off hook
simultaneously with the release on the other side:
DLCX 1244 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
X: 0123456789B3
R: hd
I:FDE234C8
Huitema, Andreasen, Arango [Page 57]
Internet draft MGCP Call Flows 11 November 1998
The gateway will respond with a message that should include a
"call parameters" header fields:
200 1244 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
The gateway, at this point, is ready for the next call.
Huitema, Andreasen, Arango [Page 58]
Internet draft MGCP Call Flows 11 November 1998
5. Data calls
We present here a set of call flows corresponding to data calls:
* Basic data call,
* Outgoing data call through a NAS,
* Call back, using a NAS,
* Data call to a NAS, using L2TP,
* Basic data call with continuity test.
Huitema, Andreasen, Arango [Page 59]
Internet draft MGCP Call Flows 11 November 1998
5.1. Basic data call to a NAS
_______________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Radius|
| | | ISUP| | | | |
|___________|_____|______|_____________|________________|_____|________|
| dials in | | | | | | |
| | IAM| -> | | | | |
| | | IAM | - - | -> | | |
| | | | | Check called | | |
| | | | | number. | | |
| | | | | Notices | | |
| | | | | data call. | | |
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | | | Connection | | |
| | | | | is completed. | | |
| | | | | Call | | |
| | | | | established | -> | |
| | | <- | - - | ANM | | |
| | <- | ANM | | | | |
| modem | - -| - - | -> | | | |
| <- | - -| - - | handshake | | | |
| PPP | - -| - - | -> | | | |
| | | | obtain | | | |
| | | | user-id, | | | |
| | | | password | | | |
| | | | Check | - - | - -| -> |
| | | | <- | - - | - -| Ack |
| <- | - -| - - | Validates | | | |
| | | | call, | | | |
| <- | - -| - - | procures | | | |
| | | | IP | | | |
| | | | address | | | |
| Connected | | | | | | |
| to | | | | | | |
| the | | | | | | |
| Internet | | | | | | |
|___________|_____|______|_____________|________________|_____|________|
Huitema, Andreasen, Arango [Page 60]
Internet draft MGCP Call Flows 11 November 1998
______________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Radius|
| | | ISUP| | | | |
|____________|_____|______|_______|____________|_____|________|
| Closes | | | | | | |
| connection.| | | | | | |
| | REL| -> | | | | |
| | | REL | - - | -> | | |
| | | | <- | Delete | | |
| | | | | Connection| | |
| | | | Perf | | | |
| | | | data | -> | | |
| | | <- | - - | RLC | | |
| | <- | RLC | | | | |
| | | | | Call end | -> | |
|____________|_____|______|_______|____________|_____|________|
This diagram shows the exchange of messages during a call from a
modem user to an Internet Service Provider, using a trunking
gateway that doubles as a Network Access Server. During these
exchanges the MGCP is used by the Call Agent to control both the
trunking gateway. Since there is no "other end" of the call,
only the trunk gateway is involved in the call.
Upon reception of the IAM message, the Call Agent determines
that the call is a data call (e.g., by bearer capability, the
called number, etc.). Using configuration databases, the Call
Agent selects the type of modem parameters and authentication
parameters that correspond to the called number and to the cal-
ling number. It uses this knowledge to send a CreateConnection
command to the NAS, programming the incoming trunk:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
M: data
X: 0123456789B1
R: cl, ax
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
Huitema, Andreasen, Arango [Page 61]
Internet draft MGCP Call Flows 11 November 1998
The trunking gateway checks that it has adequate resources for
the call. If the trunking gateway did not have adequate
resources, for example if it could not support the requested
modem type, it should refuse the creation and send an error
response to the Call Agent. If the gateway has sufficient
resources, it immediately acknowledges the creation, sending
back the identification of the newly created connection. (There
is no need to transmit a session description in the case of a
data call.)
200 1237 OK
I: FDE234C8
The Call Agent, knowing that this is a data call, can immedi-
ately acknowledge the establishment of the connection, sending
an ANM message back to the calling switch.
The trunk gateway connects the incoming trunk to a DSP loaded
with the specified modem code. Once the call is established, the
modem of the calling PC will start a training sequence with the
modem associated to the trunk in the trunk gateway. The caller
will then proceed to a normal PPP synchronization, which prob-
ably implies a PPP login. The authentication parameters, in our
example, are checked using Radius. The Radius server that will
be used is typically chosen as a function of the called number,
which identifies the data service that the calling modem
requested. In fact, the number can also be used to identify the
specific form of authentication that is requested (but not usu-
ally).
In our example, the call is completed when the calling modem
hangs up. This triggers an ISUP release message, which is for-
warded to the Call Agent. The Call Agent will request the NAS to
delete the connection:
DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
The gateways will respond with a message that should include a
"call parameters" header fields:
250 1244 OK
P: PS=1245, OS=62345, PR=780, OR=45123
Huitema, Andreasen, Arango [Page 62]
Internet draft MGCP Call Flows 11 November 1998
We should note that, because this is a data call, the call
parameters only include a count of the packets and octets that
were sent and received.
Huitema, Andreasen, Arango [Page 63]
Internet draft MGCP Call Flows 11 November 1998
5.2. Outgoing data call through a NAS
_____________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Router |
| | | ISUP| | | | |
|___________|_____|______|____________|_____________|_____|__________|
| | | | | | | notices |
| | | | | | | packet |
| | | | | | | to PC |
| | | | | <- | - -| NTFY |
| | | | | Ack | - -| -> |
| | | | | Decides to | | |
| | | | | place an | | |
| | | | | outgoing | | |
| | | | | call. | | |
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | <- | - - | IAM | | |
| (rings) | <- | IAM | | | | |
| | ACM| -> | | | | |
| | | ACM | - - | -> | | |
| (answer) | ANM| -> | | | | |
| | | ANM | - - | -> | | |
| | | | | Connection | | |
| | | | | complete. | | |
| | | | | Call | | |
| | | | | established| -> | |
| PPP | - -| - - | -> | | | |
| <- | - -| - - | Validates | | | |
| | | | call, | | | |
| | | | announces | | | |
| | | | IP address| - - | - -| -> |
| Connected | | | | | | |
| to the | | | | | | |
| Internet | | | | | | |
| | | | | | | |
|___________|_____|______|____________|_____________|_____|__________|
Huitema, Andreasen, Arango [Page 64]
Internet draft MGCP Call Flows 11 November 1998
___________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Router|
| | | ISUP| | | | |
|____________|_____|______|____________|____________|_____|________|
| Closes | | | | | | |
| connection.| | | | | | |
| | REL| -> | | | | |
| | | REL | - - | -> | | |
| | | | <- | Delete | | |
| | | | | Connection| | |
| | | | ceases | | | |
| | | | announcing| | | |
| | | | IP address| - - | - -| -> |
| | | | Perf | | | |
| data | -> | | | | | |
| | | <- | - - | RLC | | |
| | <- | RLC | | | | |
| | | | | Call end | -> | |
|____________|_____|______|____________|____________|_____|________|
This diagram shows the exchange of messages during a call from
an an Internet Service Provider to a modem, using a trunking
gateway that doubles as a Network Access Server. During these
exchanges the MGCP is used by the Call Agent to control both the
NAS, and will also be used between the Call Agent and a default
router of the ISP.
In the example configuration, the calls are set on demand, when
data have to actually be sent from the Internet to the dial-up
user. When no connection is established, the local routing is
configured to send the packets towards a default router which
may or may not be the same machine as the NAS. In redundant con-
figurations, there could be many default routers. Each of these
default routers has been programmed (through a notification
request) to send a notification to the Call Agent when it
receives a packet on the default route:
NTFY 2005 default-route@router25.whatever.net MGCP 0.1
X:
0123456789AF
O: pa(192.96.41.1)
After this notification, the Call Agent should send an ack-
nowledgement:
200 2005 OK
Huitema, Andreasen, Arango [Page 65]
Internet draft MGCP Call Flows 11 November 1998
(We should note here that using MGCP for this function is a
stretch. There are other protocols, notably RMON, that already
provide an adequate service. These protocols could be used
instead of MGCP without affecting the discussion that follows.)
The Call Agent deduces from the notification that a circuit
should be established towards the dial-up user, or towards the
dial-up router. Using configuration databases, the Call Agent
selects the number that should be called, and also the type of
modem parameters and authentication parameters that correspond
to the called number. The Call Agent uses its routing table to
select an adequate NAS, with an available outgoing trunk. It
uses a create connection command to seize this outgoing trunk:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
M: data
X: 0123456789B1
R: cl
v=0
m=nas/none
c=IN IP4 128.96.41.1
a=subnet:IN IP4 123.45.67.64/26
a=bearer:isdn64
a=framing:ppp-hdlc
a=dialed:18001234567
a=dialing:2345678901
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection. (There is no
session description in the case of a data call.)
200 1237 OK
I: FDE234C8
Once the trunk has been seized, the Call Agent will send an IAM
message to the switch that controls the trunk. The dialed PC
will "ring" and eventually take the call, triggering the arrival
of progress messages and then an answer message (ANM). At that
point, the Call Agent knows that the call is established.
The DSP associated to the incoming trunk has been loaded with
the specified modem code - a simple HDLC framing in our example.
Once the call is established, the calling PC will train with the
modem associated with the trunk. In our example, no
Huitema, Andreasen, Arango [Page 66]
Internet draft MGCP Call Flows 11 November 1998
authentication is requested: the Call Agent has identified the
dialed user through its called number.
Once the association is established and the IP service is vali-
dated, the gateway announces that it serves the local user. In
our example, there is no address configuration performed through
PPP: the dialed user has a permanent address, which has been
programmed when it subscribed to the service. However, one the
circuit is validated, the gateway should start announcing its
access to this permanent address in the routing tables. In our
example, the dialed station is in fact an access point to a
local network, and the NAS should start announcing accessibility
of that local network (123.45.67.64/26) through the local rout-
ing procedures (an IGP such as RIP, OSPF or EIGRP).
Note that the current design makes the hypothesis that the Call
Agent "tells" the address of the LAN to the NAS. This is a very
debatable design. If a secure IGP is used (e.g. using embedded
keyed MD5 authentication, or using IPSEC) then the routing pre-
fix will be naturally exchanged through this IGP. On the other
hand, some form of configuration can provide a "double check"
against user errors.
In our example, the call is completed when the called modem
hangs up. This triggers an ISUP release message, which is for-
warded to the Call Agent. The Call Agent will request the NAS to
delete the connection:
DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
The gateways will respond with a message that should include a
"call parameters" header fields:
250 1244 OK
P: PS=1245, OS=62345, PR=780, OR=45123
We should note that, because this is a data call, the call
parameters only include a count of the packets and octets that
were sent and received.
5.3. Call back, using a NAS
There are three classic forms of call-back:
Huitema, Andreasen, Arango [Page 67]
Internet draft MGCP Call Flows 11 November 1998
1- ANI-based Callback
2- PPP Callback (Microsoft Callback is a variant of this)
3- Login-based callback
The ANI based call-back can be implemented entirely in the Call
Agent, as indicated in the following diagram:
______________________________________________________________
| PC | CO | SS7/| NAS| CA | ACC|
| | | ISUP| | | |
|________|_____|______|_____|___________________________|_____|
| dials | IAM| -> | | | |
| | | IAM | - -| -> | |
| | | | | Notices that the | |
| | | | | called number corresponds| |
| | | | | to a call back service, | |
| | | | | and that the calling | |
| | | | | number has subscribed | |
| | | | | to that service. | |
| | | | | Terminates the | |
| | | | | incoming call. | |
| | | <- | - -| REL | |
| | <- | REL | | | |
| | RLC| -> | | | |
| hangup | | RLC | - -| -> | |
| | | | | Decides to place | |
| | | | | an outgoing call. | |
| | | | | Call start | -> |
| | | | <- | Create | |
| | | | | Connection (data) | |
| | | | Ack| -> | |
| | | <- | - -| IAM | |
| (rings)| <- | IAM | | | |
|________|_____|______|_____|___________________________|_____|
The PPP callback suppose that the modem first establishes an
incoming connection, and go through the authentication exchange.
The following diagram provides an example of these exchanges:
Huitema, Andreasen, Arango [Page 68]
Internet draft MGCP Call Flows 11 November 1998
____________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Radius|
| | | ISUP| | | | |
|_________|_____|______|____________|________________|_____|________|
| dials in| | | | | | |
| | IAM| -> | | | | |
| | | IAM | - - | -> | | |
| | | | | Checks called | | |
| | | | | number. | | |
| | | | | Notices | | |
| | | | | data call. | | |
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | | | Connection | | |
| | | | | completed. | | |
| | | | | Call | | |
| | | | | established | -> | |
| | | <- | - - | ANM | | |
| | <- | ANM | | | | |
| modem | - -| - - | -> | | | |
| <- | - -| - - | handshake | | | |
| PPP | - -| - - | -> | | | |
| | | | obtain | | | |
| | | | user-id, | | | |
| | | | password | | | |
| | | | Check | - - | - -| -> |
| | | | <- | - - | - -| Ack |
| | | | reports | | | |
| | | | call back | | | |
| | | | condition | | | |
| | | | NTFY | -> | | |
| | | | <- | ACK | | |
| | | | | Decides | | |
| | | | | to place an | | |
| | | | | outgoing call.| | |
| | | | <- | Delete | | |
| | | | | Connection | | |
| | | | Perf | | | |
| | | | data | -> | | |
| | | <- | - - | REL | | |
| | <- | REL | | | | |
| | REL| -> | | | | |
| hangup | | REL | - - | -> | | |
|_________|_____|______|____________|________________|_____|________|
Huitema, Andreasen, Arango [Page 69]
Internet draft MGCP Call Flows 11 November 1998
__________________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Radius|
| | | ISUP| | | | |
|____________|_____|______|__________________|_____________|_____|________|
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | <- | - - | IAM | | |
| (rings) | <- | IAM | | | | |
| | ACM| -> | | | | |
| | | ACM | - - | -> | | |
| (answer) | ANM| -> | | | | |
| | | ANM | - - | -> | | |
| | | | | Connection | | |
| | | | | complete. | | |
| | | | | Call | | |
| | | | | established| -> | |
| PPP | - -| - - | -> | | | |
| <- | - -| - - | Validates call, | | | |
| Connected | | | | | | |
| to the | | | | | | |
| Internet | | | | | | |
| | | | | | | |
| Closes | | | | | | |
| connection.| | | | | | |
| | REL| -> | | | | |
| | | REL | - - | -> | | |
| | | | <- | Delete | | |
| | | | | Connection | | |
| | | | Perf data | -> | | |
| | | <- | - - | RLC | | |
| | <- | RLC | | | | |
| | | | | Call end | -> | |
|____________|_____|______|__________________|_____________|_____|________|
This diagram shows the exchange of messages during a call from a
modem user to an Internet Service Provider, using a trunking
gateway that doubles as a Network Access Server. During these
exchanges the MGCP is used by the Call Agent to control the NAS.
Upon reception of the IAM message, the Call Agent notices that
the called number corresponds to a data service. Using confi-
guration databases, the Call Agent selects the type of modem
parameters and authentication parameters that correspond to the
Huitema, Andreasen, Arango [Page 70]
Internet draft MGCP Call Flows 11 November 1998
called number and to the calling number. It uses this knowledge
to send a connection command to the NAS, programming the incom-
ing trunk:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
M: data
X: 0123456789B1
R: cl, cbk
v=0
m=nas/radius
c=radius.example.net
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection. (There is no
session description in the case of a data call.)
200 1237 OK
I: FDE234C8
The Call Agent, knowing that this is a data call, can immedi-
ately acknowledge the establishment of the connection, sending
an ANM message back to the calling switch.
The DSP associated to the incoming trunk has been loaded with
the specified modem code. Once the call is established, the
modem of the calling PC will be synchronized with the modem
associated to the trunk. The caller will then proceed to a nor-
mal PPP synchronization, which probably implies a PPP login. The
login parameters, in our example, are checked using Radius. The
Radius server that will be used is typically chosen as a func-
tion of the called number, which identifies the data service
that the calling modem requested. In fact, the number can also
be used to identify the specific form of authentication that is
requested.
In the call back example, the Radius server will indicate that
the call cannot be completed as such, and that the user should
be called back (for example, using a "Callback Framed" service
type in its access-accept response.) The NAS will thus send a
Notify message to the Call Agent, indicating that a call-back is
Huitema, Andreasen, Arango [Page 71]
Internet draft MGCP Call Flows 11 November 1998
requested:
NTFY 2005 card23/21@trgw-7.whatever.net MGCP 0.1
X: 0123456789B1
O: cbk(user-id)
After this notification, the Call Agent should send an ack-
nowledgement:
200 2005 OK
The Call Agent will check that the call back request can be fol-
lowed through. In its databases, it will find the regular
address associated to the "user-id," and prepare to set up a
call to that address. It will first clear the incoming call,
sending a DeleteConnection command to the NAS:
In our example, the call is completed when the calling modem
hangs up. This triggers an ISUP release message, which is for-
warded to the Call Agent. The Call Agent will request the NAS to
delete the connection, and reset the list of observed events:
DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
X: 0123456789B2
R:
The gateways will respond with a message that should include a
"call parameters" header fields:
250 1244 OK
P: PS=2, OS=345, PR=1, OR=123
We should note that, because this is a data call, the call
parameters only include a count of the packets and octets that
were sent and received.
The Call Agent will then proceed to set up an outgoing data
call. This call may be routed through the same NAS that received
the incoming call, but can also be routed through an entirely
different endpoint , for example if the calling user has moved
out of its normal region.
Huitema, Andreasen, Arango [Page 72]
Internet draft MGCP Call Flows 11 November 1998
5.4. Data call to a NAS, using L2TP
________________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| LNS |
| | | ISUP| | | | |
|___________|_____|______|_______________|______________|_____|_________|
| dials in | | | | | | |
| | IAM| -> | | | | |
| | | IAM | - - | -> | | |
| | | | | Check called| | |
| | | | | number. | | |
| | | | | Notices | | |
| | | | | data call. | | |
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | | | Connection | | |
| | | | | complete. | | |
| | | | | Call | | |
| | | | | established | -> | |
| | | <- | - - | ANM | | |
| | <- | ANM | | | | |
| modem | - -| - - | -> | | | |
| <- | - -| - - | handshake | | | |
| PPP | - -| - - | -> | | | |
| | | | obtain | | | |
| | | | user-id, | | | |
| | | | password | | | |
| | | | Establish | | | |
| | | | Tunnel | | | |
| | | | SCC-REQ | - - | - -| -> |
| | | | <- | - - | - -| SCC-REP|
| | | | <- | - - | - -| SCC-CON|
| | | | IC-REQ | - - | - -| -> |
| | | | <- | - - | - -| IC-REP |
| | | | <- | - - | - -| IC-CON |
| | | | Spoof PPP/LCP| - - | - -| -> |
| <- | - -| - - | Relays PPP | - - | - -| -> |
| Connected | | | | | | |
| to the | | | | | | |
| Internet | | | | | | |
|___________|_____|______|_______________|______________|_____|_________|
Huitema, Andreasen, Arango [Page 73]
Internet draft MGCP Call Flows 11 November 1998
_______________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| LNS|
| | | ISUP| | | | |
|____________|_____|______|___________|____________|_____|_____|
| Closes | | | | | | |
| connection.| | | | | | |
| | REL| -> | | | | |
| | | REL | - - | -> | | |
| | | | <- | Delete | | |
| | | | | Connection| | |
| | | | Perf | | | |
| | | | data | -> | | |
| | | <- | - - | RLC | | |
| | <- | RLC | | | | |
| | | | CDN | - - | - -| -> |
| | | | Stop-CC-N| - - | - -| -> |
| | | | | Call end | -> | |
|____________|_____|______|___________|____________|_____|_____|
This diagram shows the exchange of messages during a call from a
modem user to an Internet Service Provider, using a trunking
gateway that doubles as a Network Access Server. During these
exchanges the MGCP is used by the Call Agent to control the NAS.
The PPP information is relayed to a network server (LNS) using
L2TP.
Upon reception of the IAM message, the Call Agent notices that
the called number corresponds to a data service. Using confi-
guration databases, the Call Agent selects the type of modem
parameters and authentication parameters that correspond to the
called number and to the calling number. It uses this knowledge
to send a connection command to the NAS, programming the incom-
ing trunk:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
M: data
X: 0123456789B1
R: cl
v=0
c=IN IP4 access.example.net
m=nas/l2tp
k=clear:some-shared-secret
a=bearer:v.32
a=framing:ppp-asynch
Huitema, Andreasen, Arango [Page 74]
Internet draft MGCP Call Flows 11 November 1998
a=dialed:18001234567
a=dialing:2345678901
The gateway immediately acknowledges the creation, sending back
the identification of the newly created connection. (There is no
need to transmit a session description in the case of a data
call.)
200 1237 OK
I: FDE234C8
The Call Agent, knowing that this is a data call, can immedi-
ately acknowledge the establishment of the connection, sending
an ANM message back to the calling switch.
The DSP associated to the incoming trunk has been loaded with
the specified modem code. Once the call is established, the
modem of the calling PC will be synchronized with the modem
associated to the trunk. The caller will then proceed to a nor-
mal PPP synchronization, which probably implies a PPP login.
Once PPP has been properly synchronized, the NAS establishes a
tunnel towards the LNS. Because L2TP is a two-layer protocol,
the NAS must first establish an L2TP control connection between
itself and the LNS. This connection may or may not have been
established prior to the call set-up.
Tunnel establishment requires a shared secret between the LNS
and the NAS; in our example, that secret is passed by the Call
Agent, along with the name of the LNS. Once the supporting tun-
nel is installed, the NAS has to establish an L2TP tunnel, to
relay the "incoming call." Once the call is established, the PPP
packets received on the trunk will be relayed over the L2TP tun-
nel, and vice-versa.
In our example, the call is completed when the calling modem
hangs up. This triggers an ISUP release message, which is for-
warded to the Call Agent. The Call Agent will request the NAS to
delete the connection:
DLCX 1244 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
Huitema, Andreasen, Arango [Page 75]
Internet draft MGCP Call Flows 11 November 1998
The gateways will respond with a message that should include a
"call parameters" header fields:
250 1244 OK
P: PS=1245, OS=62345, PR=780, OR=45123
We should note that, because this is a data call, the call
parameters only include a count of the packets and octets that
were sent and received.
5.5. Basic data call with continuity test
___________________________________________________________________
| PC | CO | SS7/| NAS | CA | ACC| Radius|
| | | ISUP| | | | |
|_________|_____|______|___________|________________|_____|________|
| dials in| | | | | | |
| | IAM| -> | | | | |
| | | IAM | - - | -> | | |
| | | | | Check called | | |
| | | | | number. | | |
| | | | | Notices | | |
| | | | | data call, | | |
| | | | | continuity | | |
| | | | | test. | | |
| | | | | Call start | -> | |
| | | | <- | Create | | |
| | | | | Connection | | |
| | | | | (loopback) | | |
| | | | Ack | -> | | |
| | COT| -> | | | | |
| | | COT | - - | -> | | |
| | | | <- | Modify | | |
| | | | | Connection | | |
| | | | | (data) | | |
| | | | Ack | -> | | |
| | | | | Connection | | |
| | | | | is completed. | | |
| | | | | Call | | |
| | | | | established | -> | |
| | | <- | - - | ANM | | |
| | <- | ANM | | | | |
| modem | - -| - - | -> | | | |
| <- | - -| - - | handshake| | | |
| PPP | - -| - - | -> | | | |
|_________|_____|______|___________|________________|_____|________|
Huitema, Andreasen, Arango [Page 76]
Internet draft MGCP Call Flows 11 November 1998
This diagram shows the various exchange of messages during the
beginning of a call from a data user on the circuit-switched
PSTN to a NAS. During these exchanges the Call Agent uses MGCP
to control the NAS and the residential gateway. The circuit
switch decides to execute a continuity test during the call
establishment. The exchanges occur on two sides.
Upon reception of the IAM message, the Call Agent recognizes
that a continuity test has been requested. It immediately sends
a CreateConnection request to the NAS to connect to the incoming
trunk, creating a connection:
CRCX 1237 card23/21@trgw-7.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: loopback
X: 0123456789B1
R: cl
v=0
m=nas/radius
c=IN IP4 radius.example.net
a=bearer:v.32
a=framing:ppp-asynch
a=dialed:18001234567
a=dialing:2345678901
The trunking gateway recognizes that the mode is set to "loop-
back". It places the circuit in "loopback" mode (we assume that
this is the adequate way to perform continuity test in this
specific environment). The gateway is then ready to send back a
2010 Hz return tone if it receives a 2010 Hz test tone. The
gateway acknowledges the creation of the connection, sending
back the identification of the newly created connection:
200 1237 OK
I: FDE234C8
At this point, the call agent is waiting for the result of the
continuity test. The calling switch is sending the test tone
(2010 Hz); if it receives the return tone (2010 Hz), it will
send a "continuity passed" message (COT). At this point, the
call agent will send a modify connection message to the NAS, in
order to place the connection in "data" mode:
MDCX 1238 card23/21@trgw-7.whatever.net MGCP 0.1
Huitema, Andreasen, Arango [Page 77]
Internet draft MGCP Call Flows 11 November 1998
C: A3C47F21456789F0
I: FDE234C8
M: data
The NAS will immediately acknowledge that command:
200 1238 OK
The NAS will then proceed with the establishment of the modem
call.
Huitema, Andreasen, Arango [Page 78]
Internet draft MGCP Call Flows 11 November 1998
6. Acknowledgements
We want to thank here the many reviewers who helped design the
MGCP flows, notably Ike Elliott and Chip Sharp.
7. References
[0] Arango, M., A. Dugan, I. Elliott, C. Huitema, S. Pickett,
"Media Gateway Control Protocol (MGCP)", work in progress.
[1] ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE
ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-
Torremolinos, 1984; modified at Helsinki, 1993)
[2] ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES
AND SIGNALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No.
7", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993)
* ITU-T, Recommendation H.323, "VISUAL TELEPHONE SYSTEMS AND
EQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-
GUARANTEED QUALITY OF SERVICE."
* ITU-T, Recommendation H.225, "Call Signaling Protocols and
Media Stream Packetization for Packet Based Multimedia Com-
munications Systems."
* ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-
TELEPHONE SIGNALS."
* Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session
Initiation Protocol", work in progress
8. Authors' Addresses
Christian Huitema
Bellcore
MCC 1J236B
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 973-829-4266
EMail: huitema@bellcore.com
Flemming Andreasen
Bellcore
RRC-1M223
444 Hoes Lane
Huitema, Andreasen, Arango [Page 79]
Internet draft MGCP Call Flows 11 November 1998
Piscataway, NJ 08854-4157
U.S.A.
Phone: +1 732 699-7351
EMail: fandreas@notes.cc.bellcore.com
Mauricio Arango
RSL COM Latin America
6300 N.W. 5th Way, Suite 100
Ft. Lauderdale, FL 33309
Phone: (954) 492-0913
Email: marango@rslcom.com
Huitema, Andreasen, Arango [Page 80]
