Sunday, November 1, 2015

Understand MGCP Parameter Lines from RFC 3435

https://tools.ietf.org/html/rfc3435

Sample MGCP Trace

http://ccie-musketeers.blogspot.com.au/2011/04/mgcp-call-preservation-porcess-with.html


************************************************************
2nd CA sends AUEP to audit preserved calls. This is the AUEP for
1st B Channel -- S0/SU0/DS1-0/1.
************************************************************

Apr 24 06:07:55.615: MGCP Packet received from 177.1.10.10:2427--->
AUEP 47 S0/SU0/DS1-0/1@HQ-R1 MGCP 0.1
F: X, A, I
<---

Apr 24 06:07:55.623: MGCP Packet sent to 177.1.10.10:2427--->
200 47
I: 23
**************************************************************
This is connection identifier. If the call is preserved on a 
B-Channel, this returns a non-null value back to CA. NOw the
CA will send an AUCX for this channnel.
***************************************************************
X: 1
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---

###################################################################
STEP 3: CA sends AUCX. See the connection number corresponds to the 
one above (i=23) 
####################################################################

Apr 24 06:07:55.683: MGCP Packet received from 177.1.10.10:2427--->
AUCX 93 S0/SU0/DS1-0/1@HQ-R1 MGCP 0.1
I: 23
F: C, M
<---

Apr 24 06:07:55.687: MGCP Packet sent to 177.1.10.10:2427--->
200 93
C: D000000002cee91c000000F5800000a4
M: sendrecv
<---


MGCP Request



3.2.2 Parameter Lines

Parameter lines are composed of a parameter name, which in most cases is composed of one or two characters, followed by a colon, optional white space(s) and the parameter value. The parameters that can be present in commands are defined in the following table:

    ------------------------------------------------------------------
   |Parameter name        | Code |  Parameter value                   |
   |----------------------|------|------------------------------------|
   |BearerInformation     |   B  |  See description (3.2.2.1).        |
   |CallId                |   C  |  See description (3.2.2.2).        |
   |Capabilities          |   A  |  See description (3.2.2.3).        |
   |ConnectionId          |   I  |  See description (3.2.2.5).        |
   |ConnectionMode        |   M  |  See description (3.2.2.6).        |
   |ConnectionParameters  |   P  |  See description (3.2.2.7).        |
   |DetectEvents          |   T  |  See description (3.2.2.8).        |
   |DigitMap              |   D  |  A text encoding of a digit map.   |
   |EventStates           |   ES |  See description (3.2.2.9).        |
   |LocalConnectionOptions|   L  |  See description (3.2.2.10).       |
   |MaxMGCPDatagram       |   MD |  See description (3.2.2.11).       |
   |NotifiedEntity        |   N  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string   |
   |                      |      |  and of the domain name of the     |
   |                      |      |  requesting entity, possibly com-  |
   |                      |      |  pleted by a port number, as in:   |
   |                      |      |    Call-agent@ca.example.net:5234  |
   |                      |      |  See also Section 3.2.1.3.         |
   |ObservedEvents        |   O  |  See description (3.2.2.12).       |
   |PackageList           |   PL |  See description (3.2.2.13).       |
   |QuarantineHandling    |   Q  |  See description (3.2.2.14).       |
   |ReasonCode            |   E  |  A string with a 3 digit integer   |
   |                      |      |  optionally followed by a set of   |
   |                      |      |  arbitrary characters (3.2.2.15).  |
   |RequestedEvents       |   R  |  See description (3.2.2.16).       |
   |RequestedInfo         |   F  |  See description (3.2.2.17).       |
   |RequestIdentifier     |   X  |  See description (3.2.2.18).       |
   |ResponseAck           |   K  |  See description (3.2.2.19).       |
   |RestartDelay          |   RD |  A number of seconds, encoded as   |
   |                      |      |  a decimal number.                 |
   |RestartMethod         |   RM |  See description (3.2.2.20).       |
   |SecondConnectionId    |   I2 |  Connection Id.                    |
   |SecondEndpointId      |   Z2 |  Endpoint Id.                      |
   |SignalRequests        |   S  |  See description (3.2.2.21).       |
   |SpecificEndPointId    |   Z  |  An identifier, in RFC 821 format, |
   |                      |      |  composed of an arbitrary string,  |
   |                      |      |  followed by an "@" followed by    |
   |                      |      |  the domain name of the gateway to |
   |                      |      |  which this endpoint is attached.  |
   |                      |      |  See also Section 3.2.1.3.         |
   |----------------------|------|------------------------------------|

   |RemoteConnection-     |   RC |  Session Description.              |
   |         Descriptor   |      |                                    |
   |LocalConnection-      |   LC |  Session Description.              |
   |         Descriptor   |      |                                    |
    ------------------------------------------------------------------

   The parameters are not necessarily present in all commands.  The
   following table provides the association between parameters and
   commands.  The letter M stands for mandatory, O for optional and F
   for forbidden.  Unless otherwise specified, a parameter MUST NOT be
   present more than once.

   ------------------------------------------------------------------
   | Parameter name      | EP | CR | MD | DL | RQ | NT | AU | AU | RS |
   |                     | CF | CX | CX | CX | NT | FY | EP | CX | IP |
   |---------------------|----|----|----|----|----|----|----|----|----|
   | BearerInformation   |  O*|  O |  O |  O |  O |  F |  F |  F |  F |
   | CallId              |  F |  M |  M |  O |  F |  F |  F |  F |  F |
   | Capabilities        |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | ConnectionId        |  F |  F |  M |  O |  F |  F |  F |  M |  F |
   | ConnectionMode      |  F |  M |  O |  F |  F |  F |  F |  F |  F |
   | Connection-         |  F |  F |  F |  O*|  F |  F |  F |  F |  F |
   |   Parameters        |    |    |    |    |    |    |    |    |    |
   | DetectEvents        |  F |  O |  O |  O |  O |  F |  F |  F |  F |
   | DigitMap            |  F |  O |  O |  O |  O |  F |  F |  F |  F |
   | EventStates         |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | LocalConnection-    |  F |  O |  O |  F |  F |  F |  F |  F |  F |
   |            Options  |    |    |    |    |    |    |    |    |    |
   | MaxMGCPDatagram     |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | NotifiedEntity      |  F |  O |  O |  O |  O |  O |  F |  F |  F |
   | ObservedEvents      |  F |  F |  F |  F |  F |  M |  F |  F |  F |
   | PackageList         |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | QuarantineHandling  |  F |  O |  O |  O |  O |  F |  F |  F |  F |
   | ReasonCode          |  F |  F |  F |  O |  F |  F |  F |  F |  O |
   | RequestedEvents     |  F |  O |  O |  O |  O*|  F |  F |  F |  F |
   | RequestIdentifier   |  F |  O*|  O*|  O*|  M |  M |  F |  F |  F |
   | RequestedInfo       |  F |  F |  F |  F |  F |  F |  O |  M |  F |
   | ResponseAck         |  O |  O |  O |  O |  O |  O |  O |  O |  O |
   | RestartDelay        |  F |  F |  F |  F |  F |  F |  F |  F |  O |
   | RestartMethod       |  F |  F |  F |  F |  F |  F |  F |  F |  M |
   | SecondConnectionId  |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | SecondEndpointId    |  F |  O |  F |  F |  F |  F |  F |  F |  F |
   | SignalRequests      |  F |  O |  O |  O |  O*|  F |  F |  F |  F |
   | SpecificEndpointId  |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   |---------------------|----|----|----|----|----|----|----|----|----|
   | RemoteConnection-   |  F |  O |  O |  F |  F |  F |  F |  F |  F |
   |          Descriptor |    |    |    |    |    |    |    |    |    |
   | LocalConnection-    |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   |          Descriptor |    |    |    |    |    |    |    |    |    |
    ------------------------------------------------------------------

   Notes (*):

   * The BearerInformation parameter is only conditionally optional as
     explained in Section 2.3.2.

   * The RequestIdentifier parameter is optional in connection creation,
     modification and deletion commands, however it becomes REQUIRED if
     the command contains an encapsulated notification request.

   * The RequestedEvents and SignalRequests parameters are optional in
     the NotificationRequest.  If these parameters are omitted the
     corresponding lists will be considered empty.

   * The ConnectionParameters parameter is only valid in a
     DeleteConnection request sent by the gateway.


====

3.2.2.8 DetectEvents
The DetectEvents parameter is encoded as a comma separated list of events (see Section 3.2.2.4), such as for example: T: L/hu,L/hd,L/hf,D/[0-9#*] It should be noted, that no actions can be associated with the events, however event parameters may be provided.


3.2.2.12 ObservedEvents
The observed events parameter provides the list of events that have been observed. The event codes are the same as those used in the NotificationRequest. Events that have been accumulated according to the digit map may be grouped in a single string, however such practice is discouraged; they SHOULD be reported as lists of isolated events if other events were detected during the digit accumulation. Examples of observed events are: O: L/hu O: D/8295555T O: D/8,D/2,D/9,D/5,D/5,L/hf,D/5,D/5,D/T O: L/hf, L/hf, L/hu


3.2.2.18 RequestIdentifier
The request identifier correlates a Notify command with the NotificationRequest that triggered it. A RequestIdentifier is a hexadecimal string, at most 32 characters in length. RequestIdentifiers are compared as strings rather than numerical value. The string "0" is reserved for reporting of persistent events in the case where a NotificationRequest has not yet been received after restart.




3.2.2.20 RestartMethod
The RestartMethod parameter is encoded as one of the keywords "graceful", "forced", "restart", "disconnected" or "cancel-graceful" as for example: RM: restart The set of restart methods can be extended through packages.




MGCP Response

3.3 Format of response headers

The response header is composed of a response line, optionally followed by headers that encode the response parameters. An example of a response header could be: 200 1203 OK The response line starts with the response code, which is a three digit numeric value. The code is followed by a white space, and the transaction identifier. Response codes defined in packages (8xx) are followed by white space, a slash ("/") and the package name. All response codes may furthermore be followed by optional commentary preceded by a white space. The following table describes the parameters whose presence is mandatory or optional in a response header, as a function of the command that triggered the response. The letter M stands for mandatory, O for optional and F for forbidden. Unless otherwise specified, a parameter MUST NOT be present more than once. Note that the table only reflects the default for responses that have not defined any other behavior. If a response is received with a parameter that is either not understood or marked as forbidden, the offending parameter(s) MUST simply be ignored.

    ------------------------------------------------------------------
   | Parameter name      | EP | CR | MD | DL | RQ | NT | AU | AU | RS |
   |                     | CF | CX | CX | CX | NT | FY | EP | CX | IP |
   |---------------------|----|----|----|----|----|----|----|----|----|
   | BearerInformation   |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | CallId              |  F |  F |  F |  F |  F |  F |  F |  O |  F |
   | Capabilities        |  F |  F |  F |  F |  F |  F |  O*|  F |  F |
   | ConnectionId        |  F |  O*|  F |  F |  F |  F |  O*|  F |  F |
   | ConnectionMode      |  F |  F |  F |  F |  F |  F |  F |  O |  F |
   | Connection-         |  F |  F |  F |  O*|  F |  F |  F |  O |  F |
   |   Parameters        |    |    |    |    |    |    |    |    |    |
   | DetectEvents        |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | DigitMap            |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | EventStates         |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | LocalConnection-    |  F |  F |  F |  F |  F |  F |  F |  O |  F |
   |            Options  |    |    |    |    |    |    |    |    |    |
   | MaxMGCPDatagram     |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | NotifiedEntity      |  F |  F |  F |  F |  F |  F |  O |  O |  O |
   | ObservedEvents      |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | QuarantineHandling  |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | PackageList         |  O*|  O*|  O*|  O*|  O*|  O*|  O |  O*|  O*|
   | ReasonCode          |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | RequestIdentifier   |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | ResponseAck         |  O*|  O*|  O*|  O*|  O*|  O*|  O*|  O*|  O*|
   | RestartDelay        |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | RestartMethod       |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | RequestedEvents     |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | RequestedInfo       |  F |  F |  F |  F |  F |  F |  F |  F |  F |
   | SecondConnectionId  |  F |  O |  F |  F |  F |  F |  F |  F |  F |
   | SecondEndpointId    |  F |  O |  F |  F |  F |  F |  F |  F |  F |
   | SignalRequests      |  F |  F |  F |  F |  F |  F |  O |  F |  F |
   | SpecificEndpointId  |  F |  O |  F |  F |  F |  F |  O*|  F |  F |
   |---------------------|----|----|----|----|----|----|----|----|----|
   | LocalConnection-    |  F |  O*|  O |  F |  F |  F |  F |  O*|  F |
   |         Descriptor  |    |    |    |    |    |    |    |    |    |
   | RemoteConnection-   |  F |  F |  F |  F |  F |  F |  F |  O*|  F |
   |         Descriptor  |    |    |    |    |    |    |    |    |    |
    ------------------------------------------------------------------

   Notes (*):

   * The PackageList parameter is only allowed with return code 518
     (unsupported package), except for AuditEndpoint, where it may also
     be returned if audited.
   * The ResponseAck parameter MUST NOT be used with any other responses
     than a final response issued after a provisional response for the
     transaction in question.  In that case, the presence of the
     ResponseAck parameter SHOULD trigger a Response Acknowledgement -
     any ResponseAck values provided will be ignored.

   * In the case of a CreateConnection message, the response line is
     followed by a Connection-Id parameter and a
     LocalConnectionDescriptor.  It may also be followed a Specific-
     Endpoint-Id parameter, if the creation request was sent to a
     wildcarded Endpoint-Id.  The connection-Id and
     LocalConnectionDescriptor parameter are marked as optional in the
     Table.  In fact, they are mandatory with all positive responses,
     when a connection was created, and forbidden when the response is
     negative, and no connection was created.

   * A LocalConnectionDescriptor MUST be transmitted with a positive
     response (code 200) to a CreateConnection.  It MUST also be
     transmitted in response to a ModifyConnection command, if the
     modification resulted in a modification of the session parameters.
     The LocalConnectionDescriptor is encoded as a "session
     description", as defined in section 3.4.  It is separated from the
     response header by an empty line.

   * Connection-Parameters are only valid in a response to a non-
     wildcarded DeleteConnection command sent by the Call Agent.

   * Multiple ConnectionId, SpecificEndpointId, and Capabilities
     parameters may be present in the response to an AuditEndpoint
     command.

   * When several session descriptors are encoded in the same response,
     they are encoded one after each other, separated by an empty line.
     This is the case for example when the response to an audit
     connection request carries both a local session description and a
     remote session description, as in:



          200 1203 OK
          C: A3C47F21456789F0
          N: [128.96.41.12]
          L: p:10, a:PCMU;G726-32
          M: sendrecv
          P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27,LA=48

          v=0
          o=- 25678 753849 IN IP4 128.96.41.1
          s=-
          c=IN IP4 128.96.41.1
          t=0 0
          m=audio 1296 RTP/AVP 0

          v=0
          o=- 33343 346463 IN IP4 128.96.63.25
          s=-
          c=IN IP4 128.96.63.25
          t=0 0
          m=audio 1296 RTP/AVP 0 96
          a=rtpmap:96 G726-32/8000

     In this example, according to the SDP syntax, each description
     starts with a "version" line, (v=...).  The local description is
     always transmitted before the remote description.  If a connection
     descriptor is requested, but it does not exist for the connection
     audited, that connection descriptor will appear with the SDP
     protocol version field only.


3.3.1 CreateConnection Response

In the case of a CreateConnection message, the response line is followed by a Connection-Id parameter with a successful response (code 200). A LocalConnectionDescriptor is furthermore transmitted with a positive response. The LocalConnectionDescriptor is encoded as a "session description", as defined by SDP (RFC 2327). It is separated from the response header by an empty line, e.g.:
      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 96
      a=rtpmap:96 G726-32/8000

   When a provisional response has been issued previously, the final
   response SHOULD furthermore contain the Response Acknowledgement
   parameter (final responses issued by entities adhering to this
   specification will include the parameter, but older RFC 2705
   implementations MAY not):

      200 1204 OK
      K:
      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 96
      a=rtpmap:96 G726-32/8000

   The final response SHOULD then be acknowledged by a Response
   Acknowledgement:

      000 1204

3.3.2 ModifyConnection Response

In the case of a successful ModifyConnection message, the response line is followed by a LocalConnectionDescriptor, if the modification resulted in a modification of the session parameters (e.g., changing only the mode of a connection does not alter the session parameters). The LocalConnectionDescriptor is encoded as a "session description", as defined by SDP. It is separated from the response header by an empty line.

      200 1207 OK

      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

   When a provisional response has been issued previously, the final
   response SHOULD furthermore contain the Response Acknowledgement
   parameter as in:

      200 1207 OK
      K:

   The final response SHOULD then be acknowledged by a Response
   Acknowledgement:

      000 1207 OK

3.3.3 DeleteConnection Response

Depending on the variant of the DeleteConnection message, the response line may be followed by a Connection Parameters parameter line, as defined in Section 3.2.2.7. 250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48

3.3.4 NotificationRequest Response

A successful NotificationRequest response does not include any additional response parameters.

3.3.5 Notify Response

A successful Notify response does not include any additional response parameters.

3.3.6 AuditEndpoint Response

In the case of a successful AuditEndPoint the response line may be followed by information for each of the parameters requested - each parameter will appear on a separate line. Parameters for which no

   value currently exists, e.g., digit map, will still be provided but
   with an empty value.  Each local endpoint name "expanded" by a
   wildcard character will appear on a separate line using the
   "SpecificEndPointId" parameter code, e.g.:

      200 1200 OK
      Z: aaln/1@rgw.whatever.net
      Z: aaln/2@rgw.whatever.net

   When connection identifiers are audited and multiple connections
   exist on the endpoint, a comma-separated list of connection
   identifiers SHOULD be returned as in:

      200 1200 OK
      I: FDE234C8, DFE233D1

   Alternatively, multiple connection id parameter lines may be returned
   - the two forms should not be mixed although doing so does not
   constitute an error.

   When capabilities are audited, the response may include multiple
   capabilities parameter lines as in:

      200 1200 OK
      A: a:PCMU;G728, p:10-100, e:on, s:off, t:1, v:L,
          m:sendonly;recvonly;sendrecv;inactive
      A: a:G729, p:30-90, e:on, s:on, t:1, v:L,
          m:sendonly;recvonly;sendrecv;inactive;confrnce

   Note:  The carriage return for Capabilities shown above is present
   for formatting reasons only.  It is not permissible in a real command
   encoding.

3.3.7 AuditConnection Response

In the case of a successful AuditConnection, the response may be followed by information for each of the parameters requested. Parameters for which no value currently exists will still be provided. Connection descriptors will always appear last and each will be preceded by an empty line, as for example:


      200 1203 OK
      C: A3C47F21456789F0
      N: [128.96.41.12]
      L: p:10, a:PCMU;G728
      M: sendrecv
      P: PS=622, OS=31172, PR=390, OR=22561, PL=5, JI=29, LA=50

      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 96
      a=rtpmap:96 G726-32/8000

   If both a local and a remote connection descriptor are provided, the
   local connection descriptor will be the first of the two.  If a
   connection descriptor is requested, but it does not exist for the
   connection audited, that connection descriptor will appear with the
   SDP protocol version field only ("v=0"), as for example:

      200 1203 OK

      v=0

3.3.8 RestartInProgress Response

A successful RestartInProgress response may include a NotifiedEntity parameter, but otherwise does not include any additional response parameters. Also, a 521 response to a RestartInProgress MUST include a NotifiedEntity parameter with the name of another Call Agent to contact when the first Call Agent redirects the endpoint to another Call Agent as in: 521 1204 Redirect N: CA-1@whatever.net