Internet DRAFT - draft-ietf-megaco-mgcp-firewall
draft-ietf-megaco-mgcp-firewall
Internet Engineering Task Force Christian Huitema
INTERNET DRAFT Flemming Andreasen
<draft-ietf-megaco-mgcp-firewall-00.txt> Bellcore
February 16, 1999 Expires: August 16, 1999
Media Gateway Control Protocol (MGCP)
Support for Packet Relays
Christian Huitema, Flemming Andreasen
Status of this document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except for the right to produce
derivative works.
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 explains how MGCP
can be used to handle "packet relays", such as firewalls. It contains
an introduction, two example call flows, and a discussion of some open
questions.
Huitema, Andreasen [Page 1]
Internet draft MGCP and packet relays 16 February 1999
1. Introduction
The Media Gateway Control Protocol can be used to control different
types of endpoints, such as "residential gateways", "trunking gateways"
or "packet relays." As stated in the MGCP specification,
A packet relay endpoint is a specific form of conference bridge,
that typically only supports two connections. Packets relays can
be found in firewalls between a protected and an open network, or
in transcoding servers used to provide interoperation between
incompatible gateways, for example gateways that do not support
compatible compression algorithms, or gateways that operate over
different transmission networks such as IP and ATM.
+-------
+---------------------+ |
|Packet relay endpoint| 2 connections
+---------------------+ |
+-------
It has been incorrectly stated that the "single endpoint" model adopted
by MGCP would not support these relays. This document will show that on
the contrary, MGCP does indeed support this mode of operation, by show-
ing the use of the protocol on two example call flows. We will then dis-
cuss the specific issues posed by the support of packet relays, and how
MGCP could be modified to better support these relays.
2. Call flows
The following two call flows are example of usage of packet relays in a
VoIP environment. In our examples, the packet relay is a firewall that
protects a local area network. We will in fact go through two detailed
call flows:
* a call from a PSTN user to a residential gateway (RGW), through a
trunking gateway (TGW) and a firewall (FW).
* a call from an H.323 terminal to a residential gateway (RGW),
through a firewall (FW).
In the PSTN case, we assume that the same call agent controls all the
network elements. We choose this hypothesis to avoid having to
represent in our diagrams the actual exchanges between call agents, for
which several solutions are available.
Huitema, Andreasen [Page 2]
Internet draft MGCP and packet relays 16 February 1999
2.1. Call from a TGW to a firewalled RGW
___________________________________________________________
| CO | SS7/| TGW | CA | FW | RGW | Usr |
|____|______|______|___________|_______|_______|___________|
| IAM| -> | | | | | |
| | IAM | - - | -> | | | |
| | | <- | CRCX | | | |
| | | Ack | -> | | | |
| | | | CRCX(1) | -> | | |
| | | | <- | Ack | | |
| | | | CRCX(2) | -> | | |
| | | | <- | Ack | | |
| | | | CRCX+RQNT| - - | -> | ring |
| | | | <- | - - | Ack | |
| | | | MDCX(2) | -> | | |
| | | | <- | Ack | | |
| | <- | - - | ACM | | | |
| <- | ACM | | | | | |
| | | | | | | off-hook |
| | | | <- | - - | NTFY | |
| | | | NTRQ | - - | -> | |
| | | | <- | - - | Ack | |
| | | <- | MDCX | | | |
| | | Ack | -> | | | |
| | <- | - - | ANM | | | |
| <- | ANM | | | | | |
|____|______|______|___________|_______|_______|___________|
| | | | <- | - - | NTFY | on-hook |
| | | | Ack | - - | -> | |
| | | | DLCX(1) | -> | | |
| | | | <- | perf | | |
| | | | | data| | |
| | | | DLCX(2) | -> | | |
| | | | <- | perf | | |
| | | | | data | | |
| | | | DLCX+RQNT| - - | -> | |
| | | | <- | - - | perf | |
| | | | | | data | |
| | | <- | DLCX | | | |
| | | Perf| | | | |
| | | data| -> | | | |
| | <- | - - | REL | | | |
| <- | REL | | | | | |
| RLC| -> | | | | | |
| | RLC | - - | -> | | | |
|____|______|______|___________|_______|_______|___________|
Huitema, Andreasen [Page 3]
Internet draft MGCP and packet relays 16 February 1999
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 through a firewall. During these
exchanges the Call Agent uses MGCP to control the TGW, the firewall and
the residential gateway.
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.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
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:
200 1237 OK
I: FDE234C8
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
The SDP announcement, in our example, specifies the address at which the
gateway is ready to receive audio data (128.96.41.1), the transport pro-
tocol (RTP), the RTP port (3456) and the audio profile (AVP).
The Call Agent, having seized the incoming trunk, must now reserve a
"pass-through" conenction in the firewall. It does so by first opening
an "external" connection to a "packet-relay" endpoint in the firewall:
CRCX 1238 relay/$@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
This message carries the session description returned by the ingress
gateway. The firewall acknowledges the creation of the connection, and
the selection of a relay endpoint:
Huitema, Andreasen [Page 4]
Internet draft MGCP and packet relays 16 February 1999
200 1238 OK
Z:relay/17@fw.example.net
I:32F345E2
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The call agent will then request the creation of a second connection on
the same endpoint on the firewall, in order to build up the "protected"
leg of the call:
CRCX 1239 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
The firewall acknowledges the creation of this connection:
200 1239 OK
I:32F345E3
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
In our example, the firewall responds with exactly the same session
description that was used for the first command; it could indeed used a
different description if it wanted to use, for example, different ports.
The call agent can now send a connection creation request to the
residential gateway, together with an embedded Notification Request.
CRCX 1240 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
X: 0123456789B1
R: hd
S: rg
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The residential gateway will acknowledge the connection command, sending
in the session description its own parameters such as address, ports and
Huitema, Andreasen [Page 5]
Internet draft MGCP and packet relays 16 February 1999
RTP profile:
200 1240 OK
I:12345678
v=0
c=IN IP4 10.0.13.17
m=audio 1296 RTP/AVP 0
The Call Agent will relay the information to the firewall using a
ModifyConnection command:
MDCX 1241 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
I:32F345E3
M: sendrecv
v=0
c=IN IP4 10.0.13.17
m=audio 1296 RTP/AVP 0
The firewall immediately acknowledges the modification:
200 1241 OK
At this stage, the Call Agent has established a half-duplex transmission
path. The residential gateway is instructed to look for an off-hook
event, and to report it. The Call Agent sends an address complete mes-
sage (ACM) to the calling switch. (We assume that this switch will gen-
erate ringing 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.example.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
Huitema, Andreasen [Page 6]
Internet draft MGCP and packet relays 16 February 1999
on the occurrence of an on-hook event. It does so by sending a Notifica-
tionRequest to the residential gateway:
RQNT 1242 endpoint/1@rgw-2567.example.net MGCP 0.1
X: 0123456789B1
R: hu
The gateway acknowledges that command:
200 1242 OK
In parallel, the Call Agent will send a ModifyConnection command to the
trunking gateway, to place the connection in full duplex mode. This
commands, in our example, also informs the trunking gateway of the ses-
sion data of the firewall.
MDCX 1243 card23/21@trgw-7.example.net MGCP 0.1
C: A3C47F21456789F0
I:FDE234C8
M: sendrecv
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The trunking gateway will acknowledge that command:
200 1243 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.example.net MGCP 0.1
X: 0123456789B1
O: hu
The Call Agent acknowledges the notification.
200 2005 OK
Huitema, Andreasen [Page 7]
Internet draft MGCP and packet relays 16 February 1999
It will then a DeleteConnection command to the trunking gateway, another
to the residential gateway, and two delete connection commands for the
two connections that were established on the firewall. These two com-
mands can be grouped on a single message. The command sent to the
residential gateway also carries a notification request, to prepare the
gateway for the next call.
DLCX 1244 endpoint/1@rgw-2567.example.net MGCP 0.1
C:A3C47F21456789F0
I:32F345E2
X:0123456789B3
R:hd
DLCX 1245 card23/21@trgw-7.example.net MGCP 0.1
C:A3C47F21456789F0
I:FDE234C8
DLCX 1246 relay/17@fw.example.net MGCP 0.11
C:A3C47F21456789F0
I:32F345E2
.
DLCX 1247 relay/17@fw.example.net MGCP 0.11
C:A3C47F21456789F0
I:32F345E3
The gateways and the firewall 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, PL=0, JI=12, LA=6
250 1245 OK
P: PS=790, OS=45700, PR=1230, OR=61875, PL=15, JI=27, LA=48
250 1246 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
250 1247 OK
P: PS=780, OS=45123, PR=1245, OR=62345, PL=0, JI=12, LA=6
The four commands are processed in parallel. As soon as it receives the
acknowledgement of the Delete Connection command from the trunking gate-
way, the Call Agent sends an ISUP "Release" message to the adjacent
switch, and then waits for a "Release confirmed" message.
Both gateways, at this point, are ready for the next call.
Huitema, Andreasen [Page 8]
Internet draft MGCP and packet relays 16 February 1999
2.2. Call from a residential gateway (RGW) to an H.323 user
________________________________________________________________________
| Usr | RGW | FW | CA | H.323 | Usr | GK |
|___________|________|_____|______________|___________|__________|_____|
| | <- | - -| RQNT | | | |
| | Ack | - -| -> | | | |
| | | | | | | |
| Off-hook | Notify| - -| -> | | | |
| | <- | - -| Ack | | | |
| (D.tone) | <- | - -| RQNT | | | |
| | Ack | - -| -> | | | |
| | | | | | | |
| Digits | Notify| - -| -> | | | |
| <- | - - | Ack| | | | |
| (prog.) | <- | - -| CRCX+RQNT | | | |
| | Ack | - -| -> | | | |
| | | <- | CRCX(1) | | | |
| | | Ack| -> | | | |
| | | <- | CRCX(2) | | | |
| | | Ack| -> | | | |
| | <- | - -| MDCX | | | |
| | 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| -> | | | |
| | <- | - -| RQNT | | | |
| | Ack | - -| -> | | | |
| dialtone | | | (call est.) | | | |
|___________|________|_____|______________|___________|__________|_____|
Huitema, Andreasen [Page 9]
Internet draft MGCP and packet relays 16 February 1999
_____________________________________________________________________
| Usr | RGW | FW | CA | H.323 | Usr | GK |
|__________|________|___________|_________|__________|_________|_____|
| on hook | Notify| - - | -> | | | |
| <- | - - | Ack | | | | |
| <- | - - | DLCX+RQNT| | | | |
| perf data| - - | -> | | | | |
| | | <- | DLCX(1)| | | |
| | | perf data| -> | | | |
| | | <- | DLCX(2)| | | |
| | | perf data| -> | | | |
| | | | Rel. C.| -> | | |
| | | | TCP-FIN| -> | | |
| | | | <- | FIN, ACK| | |
| | | | TCP ACK| -> | | |
| | | | | (signal)| On-hook| |
| | | | | DRQ | - - - | -> |
| | | | | <- | - - - | DCF|
|__________|________|___________|_________|__________|_________|_____|
During these exchanges the MGCP is used by the call agent to control the
residential gateway and the firewall. 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.example.net MGCP 0.1
N: ca@ca1.example.net:5678
X: 0123456789AB
R: hd
The gateway, at that point, is instructed to look for an off-hook event,
and to report it. It will first acknowledge the request, repeating in
the acknowledgement message the transaction id that the call agent
attached to the query.
200 1201 OK
Note that this command is not actually simultaneous with the call. It
can be issued long before the actual call, for example when the gateway
is turned on, or after the end of a previous call.
When the off hook event is noticed, the gateway sends a Notify command
to the call agent:
Huitema, Andreasen [Page 10]
Internet draft MGCP and packet relays 16 February 1999
NTFY 2001 endpoint/1@rgw-2567.example.net MGCP 0.1
N: ca@ca1.example.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, asking for digits. The
current example provides the gateway with a digit map, and requests the
gateway to play a dialtone:
RQNT 1202 endpoint/1@rgw-2567.example.net MGCP 0.1
N: ca@ca1.example.net:5678
X: 0123456789AC
R: hu, [0-9#*T](D)
D: (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.example.net MGCP 0.1
N: ca@ca1.example.net:5678
X: 0123456789AC
O: 9,1,9,7,3,8,2,9,4,2,6,6
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
Huitema, Andreasen [Page 11]
Internet draft MGCP and packet relays 16 February 1999
notification request, to stop collecting digits yet continue watch for
an on-hook transition:
CRCX 1204 endpoint/1@rgw-2567.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: recvonly
X: 0123456789AD
R: hu
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 10.11.12.13
m=audio 3456 RTP/AVP 0
The call agent must now create two connections on the firewall. We will
assume in this example that the call agent manages the packet endpoints
on the firewall, and is thus able to select an endpoint without using
the "wildcard" command. When this is the case, the two create connec-
tion commands can be sent in parallel, or grouped in a single packet:
CRCX 1205 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: recvonly
v=0
c=IN IP4 10.11.12.13
m=audio 3456 RTP/AVP 0
.
CRCX 1206 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
The firewall acknowledges the two creations, possibly in a single mes-
sage:
Huitema, Andreasen [Page 12]
Internet draft MGCP and packet relays 16 February 1999
200 1205 OK
I: 12345678
v=0
c=IN IP4 128.96.41.1
m=audio 1234 RTP/AVP 0
.
200 1206 OK
I: 12345679
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
The call agent, having seized the incoming circuit and "opened a hole"
in the firewall, proceeds with call routing. In parallel, it will com-
plete the set-up of the residential gateway by sending a modify command
to establish a full duplex connection with the firewall:
MDCX 1207 endpoint/1@rgw-2567.example.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 1234 RTP/AVP 0
The residential gateway will acknowledge the modification:
200 1207 OK
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 [Page 13]
Internet draft MGCP and packet relays 16 February 1999
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 ringback tones:
RQNT 1208 endpoint/1@rgw-2567.example.net MGCP 0.1
X: 0123456789AE
R: hu
S: G/rt
The residential gateway acknowledges this request:
Huitema, Andreasen [Page 14]
Internet draft MGCP and packet relays 16 February 1999
200 1208 OK
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 con-
tain 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 notification request to the residential gate-
way, to suppress the ring back tone:
RQNT 1209 endpoint/1@rgw-2567.example.net MGCP 0.1
X: 0123456789AF
R: hu
The call agent also sends, in parallel, a connection modification
Huitema, Andreasen [Page 15]
Internet draft MGCP and packet relays 16 February 1999
request to the firewall, 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.
MDCX 1210 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
I: 12345679
M: sendrecv
v=0
c=IN IP4 128.96.63.25
m=audio 1296 RTP/AVP 0
The firewall and the gateway will acknowledge these request:
200 1209 OK
200 1210 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.example.net MGCP 0.1
X: 0123456789AF
O: hu
After this notification, the call agent should send an acknowledgement:
200 2005 OK
The call agent will then clear the call, by sending a delete connection
request to the calling gateway. This request is combined with a notifi-
cation request, to be ready to detect the next call issued by the
residential gateway:
DLCX 1211 endpoint/1@rgw-2567.example.net MGCP 0.1
C: A3C47F21456789F0
I: FDE234C8
X: 0123456789B0
R: hd
Huitema, Andreasen [Page 16]
Internet draft MGCP and packet relays 16 February 1999
The gateway will respond with a message that should include a "call
parameters" header field:
250 1211 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=0, JI=11, LA=5
In parallel, the call agent also sends two delete connection commands to
the firewall, in order to clear the firewall connections:
DLCX 1212 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
I: 12345678
.
DLCX 1213 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
I: 12345679
The firewall will send reports in response to these commands:
250 1211 OK
P: PS=780, OS=45123, PR=1245, OR=62345, PL=0, JI=11, LA=5
.
250 1211 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 connec-
tion. 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 [Page 17]
Internet draft MGCP and packet relays 16 February 1999
3. Open issues
The preceding call flows demonstrate the adequacy of MGCP to handle
"packet to packet" gateways, of which firewalls are a prime example.
But the discussions of the packet-relay endpoint leads to three open
issues, which may or may not require enhancement to the base protocol:
* How do we handle packet reformating ?
* How do we handle the change of medias, such as going from ATM/AAL1,
or ATM/AAL2, to IP/UDP/RTP, and how do we specify which interface
should be used ?
* How do we handle several connection simultaneously ?
We will debate these issues in the following paragraphs.
3.1. Packet reformating
Packet reformatting occurs when one side of the packet relay uses a dif-
ferent formatting than the other side, such as G.711 versus G.723.1.
MGCP can easily be used to specify that such a transformation is
required. For example, in the RGW-to-H.323 example, we could have used
different parameters for the two create connection commands sent to the
firewall:
CRCX 1205 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: recvonly
v=0
c=IN IP4 10.11.12.13
m=audio 3456 RTP/AVP 0
.
CRCX 1206 relay/17@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.723
M: sendrecv
The first command specifies a G.711 encoding with mu-law samples (PCMU,
content type 0), while the second specifies a G.723 encoding (content
type 4). The firewall, through these commands, is effectively asked to
compress the G.711 packets coming from the RGW endpoint and to reformat
them as G.723 packets before transmission to the H.323 terminal, and
vice versa.
Huitema, Andreasen [Page 18]
Internet draft MGCP and packet relays 16 February 1999
The problem, here, does not lie in the expressiveness of the connection
creation and modification commands, but rather in the difficulty of
assessing the capabilities of the packet relay:
* When used in pure relay mode, without reformatting, the relay can
obviously support any compression algorithm.
* When reformatting is required, the relay needs to be able to exe-
cute the algorithm, which requires both knowledge and computing
power.
If we wanted to use the protocol to express the capacities of the relay,
we would need to distinguish between these two modes.
3.2. Changes of media, multiple interfaces
The change of media is a variation of the packet reformatting problem.
It occurs when an end to end connection spans different types of net-
work, such as:
* ATM and IP,
* ATM AAL1 and ATM AAL2,
* Frame-relay and IP,
* Frame-relay and ATM,
* Private and Public IP network.
The problem here is in fact similar to the generic problem of gateways
that are connected to several networks: when we create a connection, we
have to specify over which network the connection shall be created.
There are two extreme ways to solve this problem:
* On a circuit switched network, the network is specified by specify-
ing the circuit over which the connection will be set. In MGCP,
this done by specifying an "endpoint."
* On a fully connected packet network, the network is specified
through its type, that essentially defines a set of reachable des-
tinations.
The call flows that we presented here fall in the second category. The
firewall is asked to set-up "an IP connection", on the assumption that
all of the firewall addresses can be reached equally efficiently from
the interior and exterior network. That solution may however not be
generic enough, and we may need to extend the possibilities of MGCP.
Huitema, Andreasen [Page 19]
Internet draft MGCP and packet relays 16 February 1999
For example, we could have needed to specify that some connections were
"interior" and other were "exterior." Today, the only parameter used to
specify the outgoing network is the "network type" in the "local connec-
tion options". This parameter could be extended to specify not only a
type of connectivity but also:
* An addressing domain, such as "IPv4" or "UNI",
* An actual address, or an address prefix, such as "192.96.41.1" or
"10.11.12/24",
* In some cases, a port number.
Such extensions could be useful not only to packet relays, but also to
the control of large "multi-network" gateways.
3.3. Multiple commands
At several points in our call flows example, we have had to create or
delete several connections at the same time. The delete connections
requests could always be grouped in a single packet, but in at least one
case, the call agent had to wait the answer to a "wildcard" create con-
nection request before a second connection creation request could be
issued.
One way to solve this could be to create special purpose commands, that
would for example "create two connections" in one command, with the
obvious idea that these two commands would work on the same endpoint.
But the creation of new types of embedded commands is not very generic.
In fact, we should consider replacing the special purpose embedding
facilities, that allow for the encapsulation of a "notification request"
or an "endpoint configuration" in a connection creation or modification
command, by a more generic mechanism, such as the one suggested by Nancy
Greene in an e-mail to the MEGACO list.
Instead of
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:
where R: and S: indicate an embedded NotificationRequest, Nancy
Huitema, Andreasen [Page 20]
Internet draft MGCP and packet relays 16 February 1999
proposed the following:
CRCX 1204 endpoint/1@rgw-2567.whatever.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:G.711;G.726-32
M: recvonly
Embedded-RQNT
X: D/0123456789AD
R: hu
S:
The embedded NotificationRequest is clearly indicated with the line
Embedded-RQNT
The embedded NotificationRequest shares the same transactionId,
endpointId, and MGCP version number as the CreateConnection, so
they are not repeated. (Actually we may want to have syntax that
would allow a different version number for the embedded RQNT.)
Pushing a good idea one step further, we can extend the concept of
embedding so that we can embed arbitrary command, separated by a marker
whose syntax would be:
embedded-marker = "Embedded-" MGCPVerb [endpointName]
The embedded command would share the same transactionId, and MGCP ver-
sion number as the main command. If no endpointName is specified, the
embedded command would share the endpointName of the main connection. As
in the current version of MGCP, the embedding will imply fate sharing:
if one command fails, they will all fail - embedding the commands means
either they all are executed or none of them are. This would allow us,
in our first example, to embed the two create connection commands, as
in:
CRCX 1238 relay/$@fw.example.net MGCP 0.1
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
v=0
c=IN IP4 128.96.41.1
m=audio 3456 RTP/AVP 0
Embedded-CRCX
C: A3C47F21456789F0
Huitema, Andreasen [Page 21]
Internet draft MGCP and packet relays 16 February 1999
L: p:10, a:PCMU
M: sendrecv
In fact, there may be a need to go one step further than this, and to
also allow for the various attribute values (such as endpointName) to be
derived from the response of the main command. This would allow us, for
example, to specify the endpoint configuration in a "two endpoint"
create connection command, as in:
CRCX 1234 trunk/1/$@gw2.example.net
C: 1234567890abcdef
M: sendrecv
Z2: trunk/3/$@gw2.example.net
Embedded-EPCF =Z
B: e:A
Embedded-EPCF =Z2
B: e:A
Obviously, any such modification to the protocol should first be dis-
cussed on the MEGACO mailing list.
4. Acknowledgements
We want to thank here the many reviewers who helped design the MGCP
flows, notably Ike Elliott and Chip Sharp. The proposal to extend the
embedding capabalities of MGCP was suggested by Nancy Greene.
5. 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 SIG-
NALS 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 EQUIP-
MENT 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 Communications
Systems."
Huitema, Andreasen [Page 22]
Internet draft MGCP and packet relays 16 February 1999
* ITU-T, Recommendation H.245, "LINE TRANSMISSION OF NON-TELEPHONE
SIGNALS."
* Handley, Shulzrinne, Schooler, Rosenberg, "SIP: Session Initiation
Protocol", work in progress
6. 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
Piscataway, NJ 08854-4157
U.S.A.
Phone: +1 732 699-7351
EMail: fandreas@notes.cc.bellcore.com
Huitema, Andreasen [Page 23]
