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

CUBE making use of DSP resources via LTI

CUBE 9.0 Local Transcoding Interface (LTI)

Without LTI, see 

Unified Border Element Transcoding Configuration Example

4 drastically different types of codec that is under G.722 umbrella

Source: https://en.wikipedia.org/wiki/G.722.1

The numbering of the wideband ITU audio codecs is sometimes confusing. There are three principal codecs, which are unrelated, but all carrying the G.722 label. G.722 is the original 7 kHz codec, using ADPCM and operating at 48 – 64 kbit/s. G.722.1, another 7 kHz codec, operates at half the data rate while delivering comparable or better quality than G.722, but is a transform-based codec. G.722.1 Annex C is very similar to G.722.1, but provides twice the audio bandwidth, 14 kHz. And G.722.2, which operates onwideband speech and delivers very low bitrates, is an ACELP-based algorithm.

List

G.722
G.722.1
G.722.1 Annex C
G.722.2

For more info on CUCM Codec, see "Region" topics under CUCM System Guide, http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmsys/CUCM_BK_CD2F83FA_00_cucm-system-guide-90/CUCM_BK_CD2F83FA_00_system-guide_chapter_0101.html#CUCM_RF_RE6237E1_00

Regions

Regions provide capacity controls for Cisco Unified Communications Manager multi-site deployments where you may need to limit the bandwidth for individual calls that are sent across a WAN link, but where you want to use a higher bandwidth for internal calls. Additionally, the system uses regions also for applications that only support a specific codec; for example, an application that only uses G.711. Use regions to specify the maximum transport-independent bit rate that is used for audio and video calls within a region and between regions; in this case, codecs with higher bit rates do not get used for the call.

Cisco Unified Communications Manager prefers codecs with better audio quality. For example, despite having a maximum bit rate of 32 kb/s, G.722.1 sounds better than some codecs with higher bit rates, such as G.711, which has a bit rate of 64 kb/s.

When you configure the maximum audio bit rate setting in the Region Configuration window (or use the service parameter in the Service Parameter Configuration window), this setting serves as a filter. When an audio codec is selected for a call, Cisco Unified Communications Manager takes the matching codecs from both sides of a call leg, filters out the codecs that exceed the configured maximum audio bit rate, and then picks the preferred codec among the codecs that are remaining in the list.

The audio codec preference feature orders the audio preference in the following table for the default low-loss case by sound quality, and the table adds a separate preference list for the lossy case.

Table 2 Audio Codec Preference Order for Cisco Unified Communications Manager

If Low Loss Is Configured for Link Loss Type	If Lossy Is Configured for Link Loss Type
AMR-WB-24 kb/s	AMR-WB-24 kb/s
AMR-13 kb/s	AMR-13 kb/s
AAC-LD (MP4A-LATM)-128 kb/s	AAC-LD (MP4A-LATM)-128 kb/s
AAC-LD (mpeg4-generic)-64 kb/s	AAC-LD (mpeg4-generic)-64 kb/s
AAC-LD (MP4A-LATM)-64 kb/s	AAC-LD (MP4A-LATM)-64 kb/s
AAC-LD (MP4A-LATM)-56 kb/s	AAC-LD (MP4A-LATM)-56 kb/s
L16-256 kb/s	L16-256 kb/s
AAC-LD (MP4A-LATM)-48 kb/s	AAC-LD (MP4A-LATM)-48 kb/s
G.722 64k-64 kb/s	iSAC-32 kb/s
iSAC-32 kb/s	AAC-LD (MP4A-LATM)-32 kb/s
AAC-LD (MP4A-LATM)-32 kb/s	G.722 64k-64 kb/s
G.722.1 32k-32 kb/s	G.722.1 32k-32 kb/s
G.722 -56 kb/s	G.722 -56 kb/s
G.722.1-24 kb/s	G.722.1-24 kb/s
G.722-48 kb/s	G.722-48 kb/s
AAC-LD (MP4A-LATM)-24 kb/s	AAC-LD (MP4A-LATM)-24 kb/s
G.711 mu-law 64 k-64 kb/s	G.711 mu-law 64 k-64 kb/s
G.711 A-law 64k-64 kb/s	G.711 A-law 64k-64 kb/s
G.711 mu-law 56k-56 kb/s	G.711 mu-law 56k-56 kb/s
G.711 A-law 56k-56kb/s	G.711 A-law 56k-56kb/s
iLBC-16 kb/s	iLBC-16 kb/s
G.728-16 kb/s	G.728-16 kb/s
GSM Enhanced Full Rate-13 kb/s	GSM Enhanced Full Rate-13 kb/s
GSM Full Rate-13 kb/s	GSM Full Rate-13 kb/s
G.729b-8 kb/s	G.729b-8 kb/s
G.729ab-8 kb/s	G.729ab-8 kb/s
G.729-8 kb/s	G.729-8 kb/s
G.729a-8 kb/s	G.729a-8 kb/s
GSM Half Rate-7 kb/s	GSM Half Rate-7 kb/s
G.723.1-7 kb/s	G.723.1-7 kb/s

For calls made between Cisco Unified Communications Manager and previous versions of Cisco Unified Communications Manager over SIP intercluster trunks, the Cisco Unified Communications Manager that makes the SDP Answer chooses the codec. Because of SIP Delayed Offer support, the Cisco Unified Communications Manager that initiates or resumes the call is the one that makes the SDP Answer, and hence, it is the one that determines the codec for the call.

For audio calls that involve H.323 intercluster trunks, Cisco Unified Communications Manager uses the preference list of codecs in the previous table only if both sides of the call run Cisco Unified Communications Manager 8.6(1). If both sides of the call do not run Cisco Unified Communications Manager 8.6(1), the codec list from the following table gets used.

For audio and video calls, Cisco Unified Communications Manager uses the preference order of codecs in the following table.

Table 3 Audio Codec Preference Order for H.323 Intercluster Trunks If Both Sides of Call Do Not Support Cisco Unified Communications Manager 8.5(1))

If Low Lossy Is Configured for Link Loss Type	If Lossy Is Configured for Link Loss Type
---	iLBC-16 kb/s
AAC-LD (mpeg4-generic)-256 kb/s	AAC-LD (mpeg4-generic)-256 kb/s
L16-256 kb/s	L16-256 kb/s
G.722.1 24k-24 kb/s	G.722.1 24k-24 kb/s
G.722.1 32k-32 kb/s	G.722.1 32k-32 kb/s
G.722 64k-64 kb/s	G.722 64k-64 kb/s
G.711 mu-law 64k-64 kb/s	G.711 mu-law 64k-64 kb/s
G.711 A-law 64k-64 kb/s	G.711 A-law 64k-64 kb/s
G.722 56k-56 kb/s	G.722 56k-56 kb/s
G.711 mu-law 56k-56 kb/s	G.711 mu-law 56k-56 kb/s
G.711 A-law 56k-56 kb/s	G.711 A-law 56k-56 kb/s
G.722 48k-48 kb/s	G.722 48k-48 kb/s
iLBC-16 kb/s	---
G.728-16 kb/s	G.728-16 kb/s
GSM Enhanced Full Rate-13 kb/s	GSM Enhanced Full Rate-13 kb/s
GSM Full Rate-13 kb/s	GSM Full Rate-13 kb/s
G.729b-8 kb/s	G.729b-8 kb/s
G.729ab-8kb/s	G.729ab-8kb/s
G.729-8 kb/s	G.729-8 kb/s
G.729a-8 kb/s	G.729a-8 kb/s
GSM Half Rate-7 kb/s	GSM Half Rate-7 kb/s
G.723.1-7 kb/s	G.723.1-7 kb/s

Supported Audio Codecs

Cisco Unified Communications Manager supports video stream encryption and various audio/video codecs, such as G.722. Cisco Unified Communications Manager supports the following audio codecs:

•  
  G.711-The most commonly supported codec, used over the public switched telephone network.
•  
  G.722-G.722 is wideband codec that is always preferred by Cisco Unified Communications Manager over G.711, unless G.722 is disabled. Audio codec often used in video conferences. See the Codec Usage of the Cisco Unified IP Phones chapter for a detailed discussion of the Advertise G.722 Codec enterprise parameter, which determines whether Cisco Unified IP Phones will advertise the G.722 codec to Cisco Unified Communications Manager.

•  
  G.722.1-G.722.1 is a low-complexity wideband codec operating at 24 and 32 kb/s. The audio quality approaches that of G.722 while using at most half the bit rate. As it is optimized for both speech and music, G.722.1 has slightly lower speech quality than the speech-optimized iSAC codec. G.722.1 is supported for SIP and H.323 devices.
•  
  G.723.1-Low-bit-rate codec with 6.3 or 5.3 kb/s compression for Cisco IP Phone 12 SP+ and Cisco IP Phone 30 VIP devices.
•  
  G.728-Low-bit-rate codec that video endpoints support.
•  
  G.729-Low-bit-rate codec with 8-kb/s compression that is supported by Cisco Unified IP Phone 7900. Typically, you would use low-bit-rate codecs for calls across a WAN link because they use less bandwidth. For example, the factory default intraregion maximum audio bit rate is 64 kbps, while the factory default interregion maximum audio bit rate is 8 kbps.
•  
  GSM--The global system for mobile communications (GSM) codec. GSM enables the MNET system for GSM wireless handsets to operate withCisco Unified Communications Manager. Assign GSM devices to a device pool that specifies 13 kb/s as the audio codec for calls within the GSM region and between other regions. Depending on device capabilities, this includes GSM EFR (enhanced full rate) and GSM FR (full rate).
•  
  L16-Uncompressed 16-bit linear pulse-code modulation (PCM) encoded audio with a 16-kHz sampling rate provides wideband audio at 256 kb/s. Works with phones with handsets, acoustics, speakers, and microphones that can support high-quality audio bandwidth, such as the Cisco Unified IP Phone7900 Series.

•  
  AAC-LD (mpeg4-generic)-Advanced Audio Coding-Low Delay (AAC-LD) is a super-wideband audio codec that provides superior sound quality for voice and music. This codec provides equal or improved sound quality over older codecs, even at lower bit rates. 
  AAC-LD (mpeg4-generic) is supported for SIP devices, in particular, Cisco TelePresence systems.
•  
  AAC-LD (MP4A-LATM)-Advanced Audio Coding-Low Delay (AAC-LD) Low-overhead MPEG-4 Audio Transport Multiplex (LATM) is a super-wideband audio codec that provides superior sound quality for voice and music. This codec provides equal or improved sound quality over older codecs, even at lower bit rates. 
  AAC-LD (MP4A-LATM) is supported for SIP devices including Tandberg and some third-party endpoints.

  Note	AAC-LD (mpeg4-generic) and AAC-LD (MPA4-LATM) are not compatible.

•  
  iSAC-Internet Speech Audio Codec (iSAC) is an adaptive wideband audio codec, specially designed to deliver wideband sound quality with low delay in both low and medium-bit rate applications. 
  Using an adaptive bit rate of between 10 and 32 kb/s, iSAC provides audio quality approaching that of G.722 while using less than half the bandwidth. In deployments with significant packet loss, delay, or jitter, such as over a WAN, iSAC audio quality is superior to that of G.722 due to its robustness. 
  iSAC is supported for SIP and SCCP devices. The Cisco Unified Communications Manager IP Voice Media Streaming App (IPVMSApp), which includes Media Termination Point, Conference Bridge, Music on Hold Server, and Annunciator does not support iSAC. MGCP devices are not supported.
•  
  iLBC-Internet Low Bit Rate Codec (iLBC) provides audio quality between that of G.711 and G.729 at bit rates of 15.2 and 13.3 kb/s, while allowing for graceful speech quality degradation in a lossy network due to the speech frames being encoded independently. By comparison, G.729 does not handle packet loss, delay, and jitter well, due to the dependence between speech frames. 
  iLBC is supported for SIP, SCCP, H323, and MGCP devices.

Note	H.323 Outbound FastStart does not support the iLBC codec.

•  
  AMR-Adaptive Multi-Rate (AMR) codec is the required standard codec for 2.5G/3G wireless networks based on GSM (WDMA, EDGE, GPRS). This codec encodes narrowband (200-3400 Hz) signals at variable bit rates ranging from 4.75 to 12.2 kb/s with toll quality speech starting at 7.4 kbps. 
  AMR is supported only for SIP devices.
•  
  AMR-WB-Adaptive Multi-Rate Wideband (AMR-WB) is codified as G.722.2, an ITU-T standard speech codec, formally known as Wideband coding of speech for about 16 kb/s. This codec is preferred since it provides excellent speech quality due to a wider speech bandwidth of 50 Hz to 7000 Hz compared to other narrowband speech codecs. 
  AMR-WB is supported only for SIP devices.

Note	AMR-WB is preferred by Cisco Unified Communications Manager over AMR and other supported codecs, G.711 in particular.

The total bandwidth that is used per call stream depends on the audio codec type as well as factors such

as data packet size and overhead (packet header size)

Note	Each call includes two streams, one in each direction.

Note	For information on bandwidth usage for each codec, see the Cisco Unified Communications Solution Reference Network Design (SRND) for the current release of Cisco Unified Communications Manager.

Table 4 Bandwidth Used Per Call by Each Codec Type in IPv4

Audio Codec	Bandwidth Used for Data Packets Only (Fixed Regardless of Packet Size)	Bandwidth Used Per Call (Including IP Headers) With 30-ms Data Packets	Bandwidth Used Per Call (Including IP Headers) With 20-ms Data Packets
G.711	64 kb/s	80 kb/s	88 kb/s
G.722	64 kb/s	80 kb/s	88 kb/s
G.722.1	24 kb/s	Not applicable	40 kb/s
G.722.1	32 kb/s	Not applicable	48 kb/s
iSAC	32 kb/s	32 kb/s
G.723.1	6.3 or 5.3 kb/s	24 kb/s	Not applicable
G.728	16 kb/s	26.66 kb/s for G.728
iLBC	15.2 or 13.3 kb/s	24 kb/s for iLBC
G.729	8 kb/s	24 kb/s	32 kb/s
L16	256 kb/s	272 kb/s	280 kb/s
AAC-LD (mpeg4-generic)	256 kb/s	272 kb/s
AAC-LD (MP4A-LATM)	128 kb/s	Not applicable	156 kb/s1.
AAC-LD (MP4A-LATM)	64 kb/s	Not applicable	88 kb/s Note    See footnote 1.
AAC-LD (MP4A-LATM)	56 kb/s	Not applicable	80 kb/s Note    See footnote 1.
AAC-LD (LATM)	48 kb/s	Not applicable	72 kb/s Note    See footnote 1.
AAC-LD (MP4A-LATM)	32 kb/s	Not applicable	56 kb/s Note    See footnote 1.
AAC-LD (MP4A-LATM)	24 kb/s	Not applicable	48 kb/s Note    See footnote 1.
GSM (Global system for mobile communications)	13 kb/s	29 kb/s	37 kb/s

1 AAC-LD (MP4A-LATM) does not specify the packetization period (20 ms or 30 ms) in SDP (it assumes the maximum overhead of 24K, which is in 20 ms)