| 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 RFCEditor function is currently provided by the
Internet Society.