RFC 3435
Media Gateway Control Protocol (MGCP) Version 1.0
Appendix E: Endpoint Naming Conventions
The following sections provide some RECOMMENDED endpoint naming conventions.E.1 Analog Access Line Endpoints
The string "aaln", should be used as the first term in a local endpoint name for analog access line endpoints. Terms following "aaln" should follow the physical hierarchy of the gateway so that if the gateway has a number of RJ11 ports, the local endpoint name could look like the following: aaln/# where "#" is the number of the analog line (RJ11 port) on the gateway. On the other hand, the gateway may have a number of physical plug-in units, each of which contain some number of RJ11 ports, in which case, the local endpoint name might look like the following: aaln/<unit #>/# where <unit #> is the number of the plug in unit in the gateway and "#" is the number of the analog line (RJ11 port) on that unit. Leading zeroes MUST NOT be used in any of the numbers ("#") above.E.2 Digital Trunks
The string "ds" should be used for the first term of digital endpoints with a naming convention that follows the physical and digital hierarchy such as: ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #> where: <unit-type> identifies the particular hierarchy level. Some example values of <unit-type> are: "s", "su", "oc3", "ds3", "e3", "ds2", "e2", "ds1", "e1" where "s" indicates a slot number and "su" indicates a sub-unit within a slot. Leading zeroes MUST NOT be used in any of the numbers ("#") above. The <unit #> is a decimal number which is used to reference a particular instance of a <unit-type> at that level of the hierarchy. The number of levels and naming of those levels is based on the physical hierarchy within the media gateway.
E.3 Virtual Endpoints
Another type of endpoint is one that is not associated with a physical interface (such as an analog or digital endpoint). This type of endpoint is called a virtual endpoint and is often used to represent some DSP resources that gives the endpoint some capability. Examples are announcement, IVR or conference bridge devices. These devices may have multiple instances of DSP functions so that a possible naming convention is: <virtual-endpoint-type>/<endpoint-#> where <virtual-endpoint-type> may be some string representing the type of endpoint (such as "ann" for announcement server or "cnf" for conference server) and <endpoint-#> would identify a particular virtual endpoint within the device. Leading zeroes MUST NOT be used in the number ("#") above. If the physical hierarchy of the server includes plug-in DSP cards, another level of hierarchy in the local endpoint name may be used to describe the plug in unit. A virtual endpoint may be created as the result of using the "any of" wildcard. Similarly, a virtual endpoint may cease to exist once the last connection on the virtual endpoint is deleted. The definition of the virtual endpoint MUST detail both of these aspects. When a <virtual-endpoint-type> creates and deletes virtual endpoints automatically, there will be cases where no virtual endpoints exist at the time a RestartInProgress command is to be issued. In such cases, the gateway SHOULD simply use the "all of" wildcard in lieu of any specific <endpoint-#> as in, e.g.: ann/*@mygateway.whatever.net If the RestartInProgress command refers to all endpoints in the gateway (virtual or not), the <virtual-endpoint-id> can be omitted as in, e.g.: *@mygateway.whatever.net Commands received by the gateway will still have to refer to an actual endpoint (possibly created by that command by use of the "any of" wildcard) in order for the command to be processed though.
E.4 Media Gateway
MGCP only defines operation on endpoints in a media gateway. It may be beneficial to define an endpoint that represents the gateway itself as opposed to the endpoints managed by the gateway. Implementations that wish to do so should use the local endpoint name "mg" (for media gateway) as in: mg@mygateway.whatever.net Note that defining such an endpoint does not change any of the protocol semantics, i.e., the "mg" endpoint and other endpoints (e.g., digital trunks) in the gateway are still independent endpoints and MUST be treated as such. For example, RestartInProgress commands MUST still be issued for all endpoints in the gateway as usual.E.5 Range Wildcards
As described in Section 2.1.2, the MGCP endpoint naming scheme defines the "all of" and "any of" wildcards for the individual terms in a local endpoint name. While the "all of" wildcard is very useful for reducing the number of messages, it can by definition only be used when we wish to refer to all instances of a given term in the local endpoint name. Furthermore, in the case where a command is to be sent by the gateway to the Call Agent, the "all of" wildcard can only be used if all of the endpoints named by it have the same "notified entity". Implementations that prefer a finer-grained wildcarding scheme can use the range wildcarding scheme described here. A range wildcard is defined as follows: RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ] Note that white space is not permitted. Also, since range wildcards use the character "[" to indicate the start of a range, the "[" character MUST NOT be used in endpoint names that use range wildcards. The length of a range wildcard SHOULD be bounded to a reasonably small value, e.g., 128 characters. Range wildcards can be used anywhere an "all of" wildcard can be used. The semantics are identical for the endpoints named. However, it MUST be noted, that use of the range wildcarding scheme requires support on both the gateway and the Call Agent. Therefore, a gateway MUST NOT assume that it's Call Agent supports range wildcarding and vice versa. In practice, this typically means that both the gateway and Call Agent will need to be provisioned consistently in order to
use range wildcards. Also, if a gateway or Call Agent using range
wildcards receives an error response that could indicate a possible
endpoint naming problem, they MUST be able to automatically revert to
not using range wildcards.
The following examples illustrates the use of range wildcards:
ds/ds1-1/[1-12]
ds/ds1-1/[1,3,20-24]
ds/ds1-[1-2]/*
ds/ds3-1/[1-96]
The following example illustrates how to use it in a command:
RSIP 1204 ds/ds3-1/[1-96]@tgw-18.whatever.net MGCP 1.0
RM: restart
RD: 0
Appendix F: Example Command Encodings
This appendix provides examples of commands and responses shown with
the actual encoding used. Examples are provided for each command.
All commentary shown in the commands and responses is optional.
F.1 NotificationRequest
The first example illustrates a NotificationRequest that will ring a
phone and look for an off-hook event:
RQNT 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: l/hd(N)
S: l/rg
The response indicates that the transaction was successful:
200 1201 OK
The second example illustrates a NotificationRequest that will look
for and accumulate an off-hook event, and then provide dial-tone and
accumulate digits according to the digit map provided. The "notified
entity" is set to "ca@ca1.whatever.net:5678", and since the
SignalRequests parameter is empty (it could have been omitted as
well), all currently active TO signals will be stopped. All events
in the quarantine buffer will be processed, and the list of events to
detect in the "notification" state will include fax tones in addition
to the "requested events" and persistent events:
RQNT 1202 aaln/1@rgw-2567.whatever.net MGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AC
R: L/hd(A, E(S(L/dl),R(L/oc, L/hu, D/[0-9#*T](D))))
D: (0T|00T|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
S:
Q: process
T: G/ft
The response indicates that the transaction was successful:
200 1202 OK
F.2 Notify
The example below illustrates a Notify message that notifies an off-
hook event followed by a 12-digit number beginning with "91". A
transaction identifier correlating the Notify with the
NotificationRequest it results from is included. The command is sent
to the current "notified entity", which typically will be the actual
value supplied in the NotifiedEntity parameter, i.e.,
"ca@ca1.whatever.net:5678" - a failover situation could have changed
this:
NTFY 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0
N: ca@ca1.whatever.net:5678
X: 0123456789AC
O: L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/9,D/4,D/2,D/6,D/6
The Notify response indicates that the transaction was successful:
200 2002 OK
F.3 CreateConnection
The first example illustrates a CreateConnection command to create a
connection on the endpoint specified. The connection will be part of
the specified CallId. The LocalConnectionOptions specify that G.711
mu-law will be the codec used and the packetization period will be 10
ms. The connection mode will be "receive only":
CRCX 1204 aaln/1@rgw-2567.whatever.net MGCP 1.0
C: A3C47F21456789F0
L: p:10, a:PCMU
M: recvonly
The response indicates that the transaction was successful, and a
connection identifier for the newly created connection is therefore
included. A session description for the new connection is included
as well - note that it is preceded by an empty line.
200 1204 OK
I: FDE234C8
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
The second example illustrates a CreateConnection command containing
a notification request and a RemoteConnectionDescriptor:
CRCX 1205 aaln/1@rgw-2569.whatever.net MGCP 1.0
C: A3C47F21456789F0
L: p:10, a:PCMU
M: sendrecv
X: 0123456789AD
R: L/hd
S: L/rg
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
The response indicates that the transaction failed, because the phone
was already off-hook. Consequently, neither a connection-id nor a
session description is returned:
401 1205 Phone off-hook
Our third example illustrates the use of the provisional response and
the three-way handshake. We create another connection and
acknowledge the previous response received by using the response
acknowledgement parameter:
CRCX 1206 aaln/1@rgw-2569.whatever.net MGCP 1.0
K: 1205
C: A3C47F21456789F0
L: p:10, a:PCMU
M: inactive
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=-
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 0
A provisional response is returned initially:
100 1206 Pending
I: DFE233D1
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 3456 RTP/AVP 0
A little later, the final response is received:
200 1206 OK
K:
I: DFE233D1
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 3456 RTP/AVP 0
The Call Agent acknowledges the final response as requested:
000 1206
and the transaction is complete.
F.4 ModifyConnection
The first example shows a ModifyConnection command that simply sets the connection mode of a connection to "send/receive" - the "notified entity" is set as well: MDCX 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 N: ca@ca1.whatever.net M: sendrecv The response indicates that the transaction was successful: 200 1209 OK In the second example, we pass a session description and include a notification request with the ModifyConnection command. The endpoint will start playing ring-back tones to the user: MDCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 M: recvonly X: 0123456789AE R: L/hu S: G/rt v=0 o=- 4723891 7428910 IN IP4 128.96.63.25 s=- c=IN IP4 128.96.63.25 t=0 0 m=audio 3456 RTP/AVP 0 The response indicates that the transaction was successful: 200 1206 OKF.5 DeleteConnection (from the Call Agent)
In this example, the Call Agent simply instructs the gateway to delete the connection "FDE234C8" on the endpoint specified: DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8
The response indicates success, and that the connection was deleted.
Connection parameters for the connection are therefore included as
well:
250 1210 OK
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
F.6 DeleteConnection (from the gateway)
In this example, the gateway sends a DeleteConnection command to the
Call Agent to instruct it that a connection on the specified endpoint
has been deleted. The ReasonCode specifies the reason for the
deletion, and Connection Parameters for the connection are provided
as well:
DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
C: A3C47F21456789F0
I: FDE234C8
E: 900 - Hardware error
P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48
The Call Agent sends a success response to the gateway:
200 1210 OK
F.7 DeleteConnection (multiple connections from the Call Agent)
In the first example, the Call Agent instructs the gateway to delete
all connections related to call "A3C47F21456789F0" on the specified
endpoint:
DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0
C: A3C47F21456789F0
The response indicates success and that the connection(s) were
deleted:
250 1210 OK
In the second example, the Call Agent instructs the gateway to delete
all connections related to all of the endpoints specified:
DLCX 1210 aaln/*@rgw-2567.whatever.net MGCP 1.0
The response indicates success:
250 1210 OK
F.8 AuditEndpoint
In the first example, the Call Agent wants to learn what endpoints are present on the gateway specified, hence the use of the "all of" wild-card for the local portion of the endpoint-name: AUEP 1200 *@rgw-2567.whatever.net MGCP 1.0 The gateway indicates success and includes a list of endpoint names: 200 1200 OK Z: aaln/1@rgw-2567.whatever.net Z: aaln/2@rgw-2567.whatever.net In the second example, the capabilities of one of the endpoints is requested: AUEP 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 F: A The response indicates success and the capabilities as well. Two codecs are supported, however with different capabilities. Consequently two separate capability sets are returned: 200 1201 OK A: a:PCMU, p:10-100, e:on, s:off, v:L;S, m:sendonly; recvonly;sendrecv;inactive;netwloop;netwtest A: a:G729, p:30-90, e:on, s:on, v:L;S, m:sendonly; recvonly;sendrecv;inactive;confrnce;netwloop Note that the carriage return in the Capabilities lines are shown for formatting reasons only - they are not permissible in a real implementation. In the third example, the Call Agent audits several types of information for the endpoint: AUEP 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0 F: R,D,S,X,N,I,T,O,ES
The response indicates success:
200 2002 OK
R: L/hu,L/oc(N),D/[0-9](N)
D:
S: L/vmwi(+)
X: 0123456789B1
N: [128.96.41.12]
I: 32F345E2
T: G/ft
O: L/hd,D/9,D/1,D/2
ES: L/hd
The list of requested events contains three events. Where no package
name is specified, the default package is assumed. The same goes for
actions, so the default action - Notify - must therefore be assumed
for the "L/hu" event. The omission of a value for the "digit map"
means the endpoint currently does not have a digit map. There are
currently no active time-out signals, however the OO signal "vmwi" is
currently on and is consequently included - in this case it was
parameterized, however the parameter could have been excluded. The
current "notified entity" refers to an IP-address and only a single
connection exists for the endpoint. The current value of
DetectEvents is "G/ft", and the list of ObservedEvents contains the
four events specified. Finally, the event-states audited reveals
that the phone was off-hook at the time the transaction was
processed.
F.9 AuditConnection
The first example shows an AuditConnection command where we audit the
CallId, NotifiedEntity, LocalConnectionOptions, Connection Mode,
LocalConnectionDescriptor, and the Connection Parameters:
AUCX 2003 aaln/1@rgw-2567.whatever.net MGCP 1.0
I: 32F345E2
F: C,N,L,M,LC,P
The response indicates success and includes information for the
RequestedInfo:
200 2003 OK
C: A3C47F21456789F0
N: ca@ca1.whatever.net
L: p:10, a:PCMU
M: sendrecv
P: PS=395, OS=22850, PR=615, OR=30937, PL=7, JI=26, LA=47
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 1296 RTP/AVP 0
In the second example, we request to audit RemoteConnectionDescriptor
and LocalConnectionDescriptor:
AUCX 1203 aaln/2@rgw-2567.whatever.net MGCP 1.0
I: FDE234C8
F: RC,LC
The response indicates success, and includes information for the
RequestedInfo. In this case, no RemoteConnectionDescriptor exists,
hence only the protocol version field is included for the
RemoteConnectionDescriptor:
200 1203 OK
v=0
o=- 4723891 7428910 IN IP4 128.96.63.25
s=-
c=IN IP4 128.96.63.25
t=0 0
m=audio 1296 RTP/AVP 0
v=0
F.10 RestartInProgress
The first example illustrates a RestartInProgress message sent by an
gateway to inform the Call Agent that the specified endpoint will be
taken out-of-service in 300 seconds:
RSIP 1200 aaln/1@rgw-2567.whatever.net MGCP 1.0
RM: graceful
RD: 300
The Call Agent's response indicates that the transaction was
successful:
200 1200 OK
In the second example, the RestartInProgress message sent by the
gateway informs the Call Agent, that all of the gateway's endpoints
are being placed in-service in 0 seconds, i.e., they are currently in
service. The restart delay could have been omitted as well:
RSIP 1204 *@rgw-2567.whatever.net MGCP 1.0
RM: restart
RD: 0
The Call Agent's response indicates success, and furthermore provides
the endpoints in question with a new "notified entity":
200 1204 OK
N: CA-1@whatever.net
Alternatively, the command could have failed with a new "notified
entity" as in:
521 1204 OK
N: CA-1@whatever.net
In that case, the command would then have to be retried in order to
satisfy the "restart procedure", this time going to Call Agent "CA-
1@whatever.net".
Appendix G: Example Call Flows
The message flow tables in this section use the following
abbreviations:
* rgw = Residential Gateway
* ca = Call Agent
* n+ = step 'n' is repeated one or more times
Note that any use of upper and lower case within the text of the messages is to aid readability and is not in any way a requirement. The only requirement involving case is to be case insensitive at all times.G.1 Restart
G.1.1 Residential Gateway Restart
The following table shows a message sequence that might occur when a call agent (ca) is contacted by two independent residential gateways (rgw1 and rgw2) which have restarted. Table F.1: Residential Gateway Restart --------------------------------------------------------------------- |step#| usr1 | rgw1 | ca | rgw2 | usr2 | |=====|============|============|============|============|===========| | 1 | | rsip -> | | | | | | | | <- ack | | | |-----|------------|------------|------------|------------|-----------| | 2 | | | <- auep | | | | | | ack -> | | | | |-----|------------|------------|------------|------------|-----------| | 3+ | | | <- rqnt | | | | | | ack -> | | | | |-----|------------|------------|------------|------------|-----------| | 4 | | | | <- rsip | | | | | | ack -> | | | |-----|------------|------------|------------|------------|-----------| | 5 | | | auep -> | | | | | | | | <- ack | | |-----|------------|------------|------------|------------|-----------| | 6+ | | | rqnt -> | | | | | | | | <- ack | | --------------------------------------------------------------------- Step 1 - RestartInProgress (rsip) from rgw1 to ca rgw1 uses DNS to determine the domain name of ca and send to the default port of 2727. The command consists of the following: rsip 1 *@rgw1.whatever.net mgcp 1.0 rm: restart
The "*" is used to inform ca that all endpoints of rgw1 are being
restarted, and "restart" is specified as the restart method. The
Call Agent "ca" acknowledges the command with an acknowledgement
message containing the transaction-id (in this case 1) for the
command. It sends the acknowledgement to rgw1 using the same port
specified as the source port for the rsip. If none was indicated, it
uses the default port of 2727.
200 1 ok
A response code is mandatory. In this case, "200", indicates "the
requested transaction was executed normally". The response string is
optional. In this case, "ok" is included as an additional
description.
Step 2 - AuditEndpoint (auep) from ca to rgw1
The command consists of the following:
auep 153 *@rgw1.whatever.net mgcp 1.0
The "*" is used to request audit information from rgw1 of all its
endpoints. rgw1 acknowledges the command with an acknowledgement
message containing the transaction-id (in this case 153) of the
command, and it includes a list of its endpoints. In this example,
rgw1 has two endpoints, aaln/1 and aaln/2.
200 153 ok
Z: aaln/1@rgw1.whatever.net
Z: aaln/2@rgw1.whatever.net
Once it has the list of endpoint ids, ca may send individual
AuditEndpoint commands in which the "*" is replaced by the id of the
given endpoint. As its response, rgw1 would replace the endpoint id
list returned in the example with the info requested for the
endpoint. This optional message exchange is not shown in this
example.
Step 3 - NotificationRequest (rqnt) from ca to each endpoint of rgw1
In this case, ca sends two rqnts, one for aaln/1:
rqnt 154 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hd(n)
x: 3456789a0
and a second for aaln/2:
rqnt 155 aaln/2@rgw1.whatever.net mgcp 1.0
r: l/hd(n)
x: 3456789a1
Note that in the requested events parameter line, the event is fully
specified as "l/hd", i.e., with the package name, in order to avoid
any potential ambiguity. This is the recommended behavior. For the
sake of clarity, the action, which in this case is to Notify, is
explicitly specified by including the "(n)". If no action is
specified, Notify is assumed as the default regardless of the event.
If any other action is desired, it must be stated explicitly.
The expected response from rgw1 to these requests is an
acknowledgement from aaln/1 as follows:
200 154 ok
and from aaln/2:
200 155 ok
Step 4 RestartInProgress (rsip) from rgw2 to ca
rsip 0 *@rgw2.whatever.net mgcp 1.0
rm: restart
followed by the acknowledgement from ca:
200 0 ok
Step 5 - AuditEndpoint (auep) from ca to rgw2
auep 156 *@rgw2.whatever.net mgcp 1.0
followed by an acknowledgement from rgw2:
200 156 ok
z: aaln/1@rgw2.whatever.net
z: aaln/2@rgw2.whatever.net
Step 6 - NotificationRequest (rqnt) from ca to each endpoint of rgw2
rqnt 157 aaln/1@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
x: 3456789a2
followed by:
rqnt 158 aaln/2@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
x: 3456789a3
with rgw2 acknowledging for aaln/1:
200 157 ok
and for aaln/2:
200 158 ok
G.1.2 Call Agent Restart
The following table shows the message sequence which occurs when a
call agent (ca) restarts. How it determines the address information
of the gateways, in this case rgw1 and rgw2, is not covered in this
document. For interoperability, it is RECOMMENDED to provide the
ability to configure the call agent to send AUEP (*) to specific
addresses and ports.
Table F.2: Residential Gateway Restart
---------------------------------------------------------------------
| # | usr1 | rgw1 | ca | rgw2 | usr2 |
|===|=============|============|============|============|============|
| 1 | | | <- auep | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 2+| | | <- rqnt | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 3 | | | auep -> | | |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
| 4+| | | rqnt -> | | |
| | | | | <- ack | |
---------------------------------------------------------------------
Step 1 - AuditEndpoint (auep) from ca to rgw1
The command consists of the following:
auep 0 *@rgw1.whatever.net mgcp 1.0
The "*" is used to request audit information from rgw1 of all its
endpoints. rgw1 acknowledges the command with an acknowledgement
message containing the transaction id (in this case 0) of the
command, and it includes a list of its endpoints. In this example,
rgw1 has two endpoints, aaln/1 and aaln/2.
200 0 ok
z: aaln/1@rgw1.whatever.net
z: aaln/2@rgw1.whatever.net
Once it has the list of endpoint ids, ca may send individual
AuditEndpoint commands in which the "*" is replaced by the id of the
given endpoint. As its response, rgw1 would replace the endpoint id
list returned in the example with the info requested for the
endpoint. This optional message exchange is not shown in this
example.
Step 2 - NotificationRequest (rqnt) off-hook from ca to rgw1
In this case, ca sends two rqnts, one for aaln/1:
rqnt 1 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hd(n)
x: 234567890
and a second for aaln/2:
rqnt 2 aaln/2@rgw1.whatever.net mgcp 1.0
r: l/hd(n)
x: 234567891
The expected response from rgw1 to these requests is an
acknowledgement from aaln/1 as follows:
200 1 ok
and from aaln/2:
200 2 ok
Step 3 - AuditEndpoint (auep) from ca to rgw2
auep 3 *@rgw2.whatever.net mgcp 1.0
followed by an acknowledgement from rgw2:
200 3 ok
z: aaln/1@rgw2.whatever.net
z: aaln/2@rgw2.whatever.net
Step 4 - NotificationRequest (rqnt) from ca to each endpoint of rgw2
rqnt 4 aaln/1@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
x: 234567892
followed by:
rqnt 5 aaln/2@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
x: 234567893
with rgw2 acknowledging for aaln/1:
200 4 ok
and for aaln/2:
200 5 ok
G.2 Connection Creation
G.2.1 Residential Gateway to Residential Gateway
The following table shows the message sequence which occurs when a
user (usr1) makes a call through a residential gateway (rgw1) to a
user served by another residential gateway (rgw2). This example
illustrates the communication between the residential gateways and
the call agent (ca) only. The local name of the endpoints in this
example is aaln/1 for both gateways, and references within the
description of the steps to rgw1 and rgw2 can be assumed to refer to
aaln/1 of rgw1 and aaln/1 of rgw2. Note that this is only an example
and is not the only legal call scenario.
Table F.3: Residential Gateway Connection Creation
---------------------------------------------------------------------
| # | usr1 | rgw1 | ca | rgw2 | usr2 |
|===|=============|============|============|============|============|
| 1 | offhook -> | ntfy -> | | | |
| | | | <- ack | | |
|---|-------------|------------|------------|------------|------------|
| 2 | <- dialtone | | <- rqnt | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 3 | digits -> | ntfy -> | | | |
| | | | <- ack | | |
|---|-------------|------------|------------|------------|------------|
| 4 | | | <- rqnt | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 5 | <- recvonly | | <- crcx | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 6 | | | crcx -> | | sendrcv -> |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
| 7 | <- recvonly | | <- mdcx | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 8 | <- ringback | | <- rqnt | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 9 | | | rqnt -> | | ringing -> |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
|10 | | | | <- ntfy | <- offhook |
| | | | ack -> | | |
|---|-------------|------------|------------|------------|------------|
|11 | | | rqnt -> | | |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
|12 | | | <- rqnt | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
|13 | <- sendrcv | | <- mdcx | | |
| | | ack -> | | | |
---------------------------------------------------------------------
Step 1 - Notify (ntfy) offhook from rgw1 to ca
This ntfy is the result of usr1 going offhook and assumes ca had
previously sent an rqnt with RequestId "445678944" to rgw1 requesting
notification in the event of an offhook:
ntfy 12 aaln/1@rgw1.whatever.net mgcp 1.0
o: l/hd
x: 445678944
Acknowledgement from ca:
200 12 ok
Step 2 - Request Notification (rqnt) for digits from ca to rgw1
Request rgw1 to notify if on-hook and collect digits according to the
digit map, and to provide dialtone:
rqnt 1057 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hu(n), d/[0-9#*T](d)
s: l/dl
x: 445678945
d: 5xxx
Acknowledgement from rgw1:
200 1057 ok
Step 3 - Notify (ntfy) digits from rgw1 to ca
ntfy 13 aaln/1@rgw1.whatever.net mgcp 1.0
o: d/5, d/0, d/0, d/1
x: 445678945
Acknowledgement from ca:
200 13 ok
Step 4 - Request Notification (rqnt) from ca to rgw1
Request rgw1 to notify in the event of an on-hook transition:
rqnt 1058 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hu(n)
x: 445678946
Acknowledgement from rgw1:
200 1058 ok
Step 5 - Create Connection (crcx) from ca to rgw1
Request a new connection on rgw1 with the specified local connection
options, including 20 msec as the packetization period, G.711 mu-law
as the codec, and receive only as the mode:
crcx 1059 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
l: p:20, a:PCMU
m: recvonly
Acknowledgement from rgw1 that a new connection, "456789fedcba5", has
been created, followed by a blank line and then the SDP parameters:
200 1059 ok
i: 456789fedcba5
v=0
o=- 23456789 98765432 IN IP4 192.168.5.7
s=-
c=IN IP4 192.168.5.7
t=0 0
m=audio 6058 RTP/AVP 0
Step 6 - Create Connection (crcx) from ca to rgw2
Request a new connection on rgw2. The request includes the session
description returned by rgw1 such that a two way connection can be
initiated:
crcx 2052 aaln/1@rgw2.whatever.net mgcp 1.0
c: 9876543210abcdef
l: p:20, a:PCMU
m: sendrecv
v=0
o=- 23456789 98765432 IN IP4 192.168.5.7
s=-
c=IN IP4 192.168.5.7
t=0 0
m=audio 6058 RTP/AVP 0
Acknowledgement from rgw2 that a new connection, "67890af54c9", has
been created; followed by a blank line and then the SDP parameters:
200 2052 ok
i: 67890af54c9
v=0
o=- 23456889 98865432 IN IP4 192.168.5.8
s=-
c=IN IP4 192.168.5.8
t=0 0
m=audio 6166 RTP/AVP 0
Step 7 - Modify Connection (mdcx) from ca to rgw1
Request rgw1 to modify the existing connection, "456789fedcba5", to
use the session description returned by rgw2 establishing a half
duplex connection which, though not used in this example, could be
used to provide usr1 with in band ringback tone, announcements, etc:
mdcx 1060 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 456789fedcba5
l: p:20, a:PCMU
M: recvonly
v=0
o=- 23456889 98865432 IN IP4 192.168.5.8
s=-
c=IN IP4 192.168.5.8
t=0 0
m=audio 6166 RTP/AVP 0
Acknowledgement from rgw1:
200 1060 ok
Step 8 - Request Notification (rqnt) from ca for rgw1 to provide
ringback
Request rgw1 to notify in the event of an on-hook transition, and
also to provide ringback tone:
rqnt 1061 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hu(n)
s: g/rt
x: 445678947
Acknowledgement from rgw1:
200 1061 ok
Step 9 - Request Notification (rqnt) from ca to rgw2 to provide
ringing
Request rgw2 to continue to look for offhook and provide ringing:
rqnt 2053 aaln/1@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
s: l/rg
x: 445678948
Acknowledgement from rgw2:
200 2053 ok
Step 10 - Notify (ntfy) offhook from rgw2 to ca
ntfy 27 aaln/1@rgw2.whatever.net mgcp 1.0
o: l/hd
x: 445678948
Acknowledgement from ca:
200 27 ok
Step 11 - Request Notification (rqnt) of on-hook from ca to rgw2
rqnt 2054 aaln/1@rgw2.whatever.net mgcp 1.0
r: l/hu(n)
x: 445678949
Acknowledgement from rgw2:
200 2054 ok
Step 12 - Request Notification (rqnt) of on-hook from ca to rgw1
rqnt 1062 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hu(n)
x: 445678950
Acknowledgement from rgw1:
200 1062 ok
Step 13 - Modify Connection (mdcx) from ca to rgw1
Request rgw1 to modify the existing connection, "456789fedcba5", to
sendrecv such that a full duplex connection is initiated:
mdcx 1063 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 456789fedcba5
m: sendrecv
Acknowledgement from rgw1:
200 1063 ok
G.3 Connection Deletion
G.3.1 Residential Gateway to Residential Gateway
The following table shows the message sequence which occurs when a
user (usr2) initiates the deletion of an existing connection on a
residential gateway (rgw2) with a user served by another residential
gateway (rgw1). This example illustrates the communication between
the residential gateways and the call agent (ca) only. The local
name of the endpoints in this example is aaln/1 for both gateways,
and references within the description of the steps to rgw1 and rgw2
can be assumed to refer to aaln/1 of rgw1 and aaln/1 of rgw2.
Table F.4: Residential Gateway Connection Deletion
---------------------------------------------------------------------
| # | usr1 | rgw1 | ca | rgw2 | usr2 |
|===|=============|============|============|============|============|
| 1 | | | | <- ntfy | <- on-hook |
| | | | ack -> | | |
|---|-------------|------------|------------|------------|------------|
| 2 | | | dlcx -> | | |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
| 3 | | | <- dlcx | | |
| | | ack -> | | | |
|---|-------------|------------|------------|------------|------------|
| 4 | | | rqnt -> | | |
| | | | | <- ack | |
|---|-------------|------------|------------|------------|------------|
| 5 | on-hook -> | ntfy -> | | | |
| | | | <- ack | | |
|---|-------------|------------|------------|------------|------------|
| 6 | | | <- rqnt | | |
| | | ack -> | | | |
---------------------------------------------------------------------
Step 1 - Notify (ntfy) offhook from rgw1 to ca
This ntfy is the result of usr2 going on-hook and assumes that ca had
previously sent an rqnt to rgw2 requesting notification in the event
of an on-hook (see end of Connection Creation sequence):
ntfy 28 aaln/1@rgw2.whatever.net mgcp 1.0
o: l/hu
x: 445678949
Acknowledgement from ca:
200 28 ok
Step 2 - Delete Connection (dlcx) from ca to rgw2
Requests rgw2 to delete the connection "67890af54c9":
dlcx 2055 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 67890af54c9
Acknowledgement from rgw2. Note the response code of "250" meaning
"the connection was deleted":
250 2055 ok
Step 3 - Delete Connection (dlcx) from ca to rgw1
Requests rgw1 to delete the connection "456789fedcba5":
dlcx 1064 aaln/1@rgw1.whatever.net mgcp 1.0
c: 9876543210abcdef
i: 456789fedcba5
Acknowledgement from rgw1:
250 1064 ok
Step 4 - NotificationRequest (rqnt) from ca to rgw2
Requests rgw2 to notify ca in the event of an offhook transition:
rqnt 2056 aaln/1@rgw2.whatever.net mgcp 1.0
r: l/hd(n)
x: 445678951
Acknowledgement from rgw2:
200 2056 ok
Step 5 - Notify (ntfy) on-hook from rgw1 to ca
Notify ca that usr1 at rgw1 went back on-hook:
ntfy 15 aaln/1@rgw1.whatever.net mgcp 1.0
o: l/hu
x: 445678950
Acknowledgement from ca:
200 15 ok
Step 6 - NotificationRequest (rqnt) offhook from ca to rgw1
Requests rgw1 to notify ca in the event of an offhook transition:
rqnt 1065 aaln/1@rgw1.whatever.net mgcp 1.0
r: l/hd(n)
x: 445678952
Acknowledgement from rgw1:
200 1065 ok
Authors' Addresses
Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th Floor
Edison, NJ 08837
EMail: fandreas@cisco.com
Bill Foster
Cisco Systems
771 Alder Drive
Milpitas, CA 95035
EMail: bfoster@cisco.com
Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.