Sunday, 23 October 2016

Summary of CUCM Supported Codecs

I just thought to put a summary list of CUCM supported codecs


  • G.711: It has two versions, A-Law & Mu-Law. You can disable CUCM support for G711 using the service parameter G.711 mu-law Codec Enabled or G.711 a-law Codec Enabled
  • G.722: This is wideband codec that is always preferred by CUCM over G.711, unless Advertise G.722 Codec enterprise parameter is Disabled.

Enterprise Parameter Setting
Phone (Product-Specific) Parameter Setting
Phone Advertises G.722
Advertise G.722 Codec Enabled
Use System Default
Yes
Advertise G.722 Codec Enabled
Enabled
Yes
Advertise G.722 Codec Enabled
Disabled
No
Advertise G.722 Codec Disabled
Use System Default
No
Advertise G.722 Codec Disabled
Enabled
Yes
Advertise G.722 Codec Disabled
Disabled
No

When users use a headset that supports wideband, they can enable Wideband Headset feature from the phone settings for better quality. On the phone navigate to Settings > User Preferences > Audio Preferences > Wideband Headset.

Enabling the Advertise G.722 Codec parameter causes interoperability problems with UCCX CAD, call park and ad hoc conferences. Keep it disabled.

You can disable CUCM support for G722 from the service parameter G.722 Codec Enabled. If G722 Codec is disabled, Advertise G722 Codec enterprise parameter is ignored

  • G.722.1: A low-complexity wideband codec operating at 24 and 32 kb/s.
  • 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. The codec has 4 versions:
    • G729: original codec. Uses high-complexity algorithm
    • G729A or A annex: medium complexity variant of G.729 and it is compatible with G729. It is less complex but has slightly lower voice quality
    • G729B or B annex: G729 with VAD and not compatible with the previous ones. It requires a transcoder
    • G729AB: G729A with silence suppression and only compatible with G729B.

IOS can distinguish between all versions of G729 while CUCM can't. CUCM will treat G729r8 and G729ar8 equally. Similarly, CUCM will treat G729br8 and G729abr8 similarly.

By default Annex-B support is turned off in IOS and CUCM.

To enable AnnexB in IOS,

voice service voip
 sip
  g729 annexb-all

To enable AnnexB in CUCM, set the service parameter 'Strip G.729 Annex B (Silence Suppression) from Capabilities' to False

v=0
o=CiscoSystemsSIP-GW-UserAgent 2385 707 IN IP4 10.170.170.2
s=SIP Call
c=IN IP4 10.170.170.2
t=0 0
m=audio 29384 RTP/AVP 18 8 0 19
c=IN IP4 10.170.170.2
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

  • GSM: GSM enables the MNET system for GSM wireless handsets to operate with CUCM. 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.
  • AAC-LD (mpeg4-generic): Super-Wideband codec
  • AAC-LD (MP4A-LATM):  Super-Wideband codec
AAC-LD (mpeg4-generic) and AAC-LD (MPA4-LATM) are not compatible

  • iSAC
    • This is a wideband codec uses an adaptive bit rate of between 10 and 32 kb/s
    • Each packet can contain 30 or 60 msec of payload). It has better tolerance to jitter and packet loss compared to G722 at half the bit rate

It has two modes:
  • Adaptive: In this mode the target bit rate is adapted to give a bit rate corresponding to the available bandwidth on the channel. The available bandwidth is continuously estimated at the receiving iSAC and signaled in-band in the iSAC bit stream
  • Independent: In this mode target bit rate has to be provided to iSAC prior to encoding; the target bit rate can be changed over the time of the call.

  • iLBC: iLBC provides audio quality between that of G.711 and G.729 at bit rates of 15.2 kbps (38-bytes or 20msec) and 13.3 kbps (50 bytes or 30 msec). iLBC handles lossy networks in better way than G729 because it treats each packet independently. G729 depends on the previous packet to handle packet loss, jitter and delay which doesn't tolerate well in lossy networks.

Codec
Complexity
Protocol Support
Device Support
G711
Low
All
All
G722
High
    • SIP, H323, SCCP
    • MGCP isn't supported
All
G722.1
Low
SIP and H323
All
G729
    • G729A & AB are medium
    • G729 & G729B are high
All
All
iLBC
High
    • SIP, SCCP, MGCP
    • H323 Slow Start
    • H323 Inbound Fast Start Only (Outbound Fast Start not supported)
All
LATM
High
SIP
    • Video Endpoints and CUBE are supported
    • RSVP is supported
    • Xcoder isn't supported
iSAC
High
SIP and SCCP
    • CUBE and new endpoints are supported (7945/65 aren't supported)
    • Media resources aren't supported

MoH Combined with other Media Resources


As we mentioned earlier MOH uses G711 is the only supported codec by default (other codecs can be enabled from IPVMS service parameters).
Let’s assume the following scenario, HQ-Region (which contains HQ-Phones, HQ-Servers, HQ-MediaResources) and BR1-Region (which contains BR1-Phones, BR1-MediaResources). In case HQ-Region to BR1-Region codec definition is G729 (and vice versa) and MOH Server at HQ site should be used by BR1-Phones, then how MOH will work??
NOTE: Here we are assuming that BR1 Phones are registered with HQ CUCM, i.e. no trunks are available between sites.
The simple way is to enable G729 codec for MOH Server from IPVMS service parameters. The other way is through XCODER. When MoH is invoked CUCM will realize that MOH is using G711 while the inter-region configuration should use G729. Therefore, it will invoke XCODE based on MoH MRGL. MOH MRGL can be assigned to MOH Device Pool; else MOH will pick XCODE from the null group.
NOTE: When CUCM invoke MOH, new call negotiation will take place between MOH and Phone including TCS negotiation, OLC, etc.
If we consider that BR1 Phones are registered to another cluster, for example CME, and HQ Site is connected to BR1 Site through ICT (H323/SIP). If HQ Phone places BR1 Phone on hold what will happen??
NOTE: We are maintaining the same assumption that HQ-Region to BR1-Region relation is G729. In this case BR1-Region is assigned to ICT.
In this case, CUCM will allocate MOH server based on ICT MRGL. Either G729 codec should be enabled from MOH server from IPVMS service parameters or XCODER will be invoked. An important note is that whether the ICT is running SIP or H323, MTP Required should be always enabled to get the functionality, This isn’t mandatory but due to bug only.
With MTP, the output will look as,
NOTE: When MOH is invoked new call negotiation will take place between CUCM and CME over ICT including TCS and OLC negotiations.
HQ#sh call leg act su
G  L     Elog A/O FAX T Codec    type Peer Address     IP R:
G0     L 83       N   ORG     T10    g729r8   VOIP        P         142.2.66.254:17734
G0     L 85       N   ORG     T4     g729r8   VOIP        P         142.2.64.254:17672
G0     L 86       N   ORG     T4     g729r8   VOIP        P         142.2.64.254:17502
G0     L 88       N   ORG     T4     g711ulaw VOIP        P         0.0.0.0:0

The bug details are,
CSCso85618 Bug Details
No Audio when Call is put on hold by remote party over Sip Trunk
Symptoms:
1. The MOH does not work between CM and CME.
2. There is no audio on the CME endpoint when the remote CCM party resumes the call on hold, conferences, or transfers with another CCM endpoint (scenario: CME - CUBE - CCM).
Conditions:
Symptom 1 is observed if the phone registered to the CME is put on hold by the CM, then the CME phone does not hear the MOH.
Symptom 2 is observed if the CCM endpoint does a conference, hold, or transfer.
Workaround: Use an MTP.
Important
The following restriction exists for multicast music on hold (MOH) when a media termination point (MTP) is invoked. When an MTP resource gets invoked in a call leg at a site that is using multicast MOH, the caller receives silence instead of music on hold. To avoid this scenario, configure unicast MOH or Tone on Hold instead of multicast MOH.
CTI devices do not support the multicast Music On Hold feature. If a CTI device is configured with a multicast MOH device in the media resource group list of the CTI device, call control issues may result. CTI devices do not support multicast media streaming.

Inter-Cluster Music on Hold (MoH)


You need to enable the network infrastructure to support multicasting including multicast routing and PIM
MMoH can't be transcoded, doesn't support E-LCAC/RSVP and doesn't support MTP
MMoH isn't supported on ICT video calls

The concept of Intercluster MoH is similar to Intracluster MoH. The same two steps:

  1. Stop the current media stream
  2. Start new stream with MoH server

In the scenario of ICT, the holder phone will select the source audio file, while SIP/H323 trunk will select the MoH server. Therefore, we will always have the holdee phone and MoH server in two separate clusters.

Stop the Current Media Stream

To disable the current media stream in SIP protocol, an SDP INVITE message is sent from the holder cluster with C=IN IP4 0.0.0.0 and a=inactive. The holdee cluster will respond with 200OK including a=inactive. This is always Early Offer regardless of the trunk configuration

 

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK201f1b3afe
……
Content-Type: application/sdp
Content-Length: 240
v=0
o=CiscoSystemsCCM-SIP 8 2 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24588 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK201f1b3afe
……
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsCCM-SIP 8 2 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 32004 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

To disable the current media stream in H323 protocol, the holder cluster sends TCS=0 (EmptyCapabilitySet). Then both clusters will exchange Close Logical Channel (CLC) and ACKs.


Start New Stream with MoH Server

Unicast Moh

SIP ICT can be configured as Delayed Offer or Early Offer. However, the flow of MoH messaging is fixed regardless of the ICT type.

  1. Holder cluster will send non-SDP INVITE message to establish call between holdee and MoH server

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2242496dea
From: < sip:2000@10.170.10.200> ;tag=8~7689b99f-a889-44ca-94c1-e77fb5464394-28366982
To: < sip:3000@10.45.230.10> ;tag=8~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384555
Date: Sun, 13 Dec 2015 10:19:28 GMT
Call-ID: f7c7c980-66d14628-4-c80aaa0a@10.170.10.200
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: < sip:2000@10.170.10.200>
Remote-Party-ID: < sip:2000@10.170.10.200> ;party=calling;screen=yes;privacy=off
Contact: < sip:2000@10.170.10.200:5060;transport=tcp>
Content-Length: 0

  1. After exchanging provisional messages, Holdee cluster will send 200OK with SDP contents indicating the supported capabilities of Holdee

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2242496dea
……
Content-Type: application/sdp
Content-Length: 417
v=0
o=CiscoSystemsCCM-SIP 8 3 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 32202 RTP/AVP 9 0 8 116 18 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

  1. Holder Cluster will verify the capabilities of the Holdee and accordingly select the suitable capabilities of the MoH stream
  2. Holder Cluster will send ACK message to holdee cluster confirming the agreed capabilities

ACK sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK2346a41b8
From: < sip:2000@10.170.10.200> ;tag=8~7689b99f-a889-44ca-94c1-e77fb5464394-28366982
To: < sip:3000@10.45.230.10> ;tag=8~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384555
Date: Sun, 13 Dec 2015 10:19:28 GMT
Call-ID: f7c7c980-66d14628-4-c80aaa0a@10.170.10.200
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 188
v=0
o=CiscoSystemsCCM-SIP 8 3 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 10.170.10.200
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendonly

Note that the message is including the following attributes:

a=X-cisco-media:umoh - This indicates to Holdee Cluster that the MoH stream is going to be Unicast Moh
c=IN IP4 10.170.10.200 - This indicates to Holdee Cluster the IP of the MoH server, for Holdee phone/gateway to connect. The port will be 4000
a=sendonly - This indicates to Holdee Cluster that the direction of the stream is unidirectional from MoH Server to Holdee phone/gateway

Multicast Moh

For MMoH the messaging is slightly different. MMoH isn't supported with EO ICT

  1. Holder cluster will send non-SDP INVITE message to probe the capabilities of the holdee

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK932d17d236
From: < sip:2000@10.170.10.200> ;tag=14~7689b99f-a889-44ca-94c1-e77fb5464394-28367010
To: < sip:3000@10.45.230.10> ;tag=14~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384562
Date: Sun, 13 Dec 2015 11:18:50 GMT
Call-ID: 44af9e00-66d15415-7-c80aaa0a@10.170.10.200
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: < sip:2000@10.170.10.200>
Remote-Party-ID: < sip:2000@10.170.10.200> ;party=calling;screen=yes;privacy=off
Contact: < sip:2000@10.170.10.200:5060;transport=tcp>
Content-Length: 0

  1. After exchanging provisional messages, Holdee cluster will send 200OK with SDP contents indicating the supported capabilities of Holdee

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK932d17d236
……
Content-Type: application/sdp
Content-Length: 418
v=0
o=CiscoSystemsCCM-SIP 14 3 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 10.170.4.226
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27928 RTP/AVP 9 0 8 116 18 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone

  1. Holder Cluster will verify the received capabilities and select the ones matching MoH server configuration
  2. Later, Holder Cluster will send ACK message confirming the selected capabilities back to Holdee Cluster

ACK sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK94686a6d9e
From: < sip:2000@10.170.10.200> ;tag=14~7689b99f-a889-44ca-94c1-e77fb5464394-28367010
To: < sip:3000@10.45.230.10> ;tag=14~8901f810-e3b7-43de-b8ef-31fe13e397a7-28384562
Date: Sun, 13 Dec 2015 11:18:50 GMT
Call-ID: 44af9e00-66d15415-7-c80aaa0a@10.170.10.200
Max-Forwards: 70
CSeq: 103 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 207
v=0
o=CiscoSystemsCCM-SIP 14 3 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24618 RTP/AVP 9
a=X-cisco-media:mmoh
a=rtpmap:9 G722/8000
a=ptime:20
a=inactive

Note that the message is including the following attributes:

c=IN IP4 0.0.0.0 - This indicates to Holdee Cluster that MoH stream is inactive
a=X-cisco-media:mmoh - This indicates to Holdee Cluster that the MoH stream is going to be Multicast Moh
a=inactive - This indicates to Holdee Cluster that MoH stream is inactive

  1. Holder Cluster will send SDP INVITE message to establish the call between MoH Server and Holdee

INVITE sip:3000@10.45.230.10:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK952d3086b5
……
Content-Type: application/sdp
Content-Length: 199
v=0
o=CiscoSystemsCCM-SIP 14 4 IN IP4 10.170.10.200
s=SIP Call
c=IN IP4 239.1.1.1
t=0 0
m=audio 16384 RTP/AVP 0
a=X-cisco-media:mmoh+ConnSendOnly
a=rtpmap:0 PCMU/8000
a=ptime:20
a=recvonly

Note that the message is including the following attributes:

c=IN IP4 239.1.1.1 - This indicates to Holdee Cluster the Multicast Group address for holdee endpoint to join using IGMP report
a=X-cisco-media:mmoh+ConnSendOnly - This indicates to Holdee Cluster that Moh stream will be multicast and unidirectional
a=recvonly - This indicates to Holdee Cluster that Moh stream will be unidirectional

  1. Holdee Cluster will respond with 200OK message indicating that Holder settings have been accepted

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.170.10.200:5060;branch=z9hG4bK952d3086b5
…….
Content-Type: application/sdp
Content-Length: 219
v=0
o=CiscoSystemsCCM-SIP 14 4 IN IP4 10.45.230.10
s=SIP Call
c=IN IP4 239.1.1.1
t=0 0
m=audio 16384 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=recvonly
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

  1. In the background, holdee will initiate IGMP process to join the MMoH stream

Note the difference between UMoH and MMoH signaling

  1. In UMoH, single Delayed Offer exchange is used to connect the Holdee to MoH server and get the stream
  2. In MMoH, two transactions are used
    1. Delayed Offer exchange with C=IN IP4 0.0.0.0/a=inactive to probe the capabilities of the holdee
    2. Early Offer exchange for holdee to join multicast group and get the stream

Resume Calls

Resuming held call follow the same steps which are:

  1. Stop the current media stream with MoH Server
  2. Start new stream with Holder. In this stage new codec negotiation will take place similar to new call setup. Also, this signaling will follow trunk type as EO or DO