tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3435

 
 
 

Media Gateway Control Protocol (MGCP) Version 1.0

Part 8 of 8, p. 182 to 210
Prev RFC Part

 


prevText      Top      Up      ToC       Page 182 
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.

Top      Up      ToC       Page 183 
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.

Top      Up      ToC       Page 184 
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

Top      Up      ToC       Page 185 
   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:

Top      Up      ToC       Page 186 
      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

Top      Up      ToC       Page 187 
   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:

Top      Up      ToC       Page 188 
      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.

Top      Up      ToC       Page 189 
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 OK

F.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

Top      Up      ToC       Page 190 
   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

Top      Up      ToC       Page 191 
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

Top      Up      ToC       Page 192 
   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

Top      Up      ToC       Page 193 
   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:

Top      Up      ToC       Page 194 
      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

Top      Up      ToC       Page 195 
   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

Top      Up      ToC       Page 196 
   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

Top      Up      ToC       Page 197 
   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

Top      Up      ToC       Page 198 
   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

Top      Up      ToC       Page 199 
   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

Top      Up      ToC       Page 200 
   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.

Top      Up      ToC       Page 201 
            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

Top      Up      ToC       Page 202 
   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

Top      Up      ToC       Page 203 
   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

Top      Up      ToC       Page 204 
   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

Top      Up      ToC       Page 205 
   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

Top      Up      ToC       Page 206 
   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.

Top      Up      ToC       Page 207 
            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

Top      Up      ToC       Page 208 
   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

Top      Up      ToC       Page 209 
   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

Top      Up      ToC       Page 210 
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.