Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3435

Media Gateway Control Protocol (MGCP) Version 1.0

Pages: 210
Informational
Errata
Obsoletes:  2705
Updated by:  3661
Part 8 of 8 – Pages 182 to 210
First   Prev   None

Top   ToC   RFC3435 - Page 182   prevText

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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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   ToC   RFC3435 - 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.