Saturday, June 13, 2015
On srTCM vs trTCM (Single Rate/Dual Rate Traffic Color Marking -- Green/Yellow/Red)
A Single Rate Three Color Marker (RFC, 1999)
http://www.rfc-base.org/rfc-2697.html
A Two Rate Three Color Marker (RFC, 1999)
http://www.rfc-base.org/rfc-2698.html
Understanding the “shape peak” command
http://blog.ine.com/2008/08/26/understanding-the-shape-peak-command/
The Meaning of Bc with Traffic Policing
http://blog.ine.com/2009/12/12/the-meaning-of-bc-with-traffic-policing/
Understanding Single-Rate and Dual-Rate Traffic Policing
http://blog.ine.com/2011/05/22/understanding-single-rate-and-dual-rate-traffic-policing/
Cisco Medianet QoS Recommendations
See more at http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/vrn.html
See Also:
RFC 4594 outlines twelve classes of media applications that have unique service level requirements:
•
VoIP Telephony—This service class is intended for VoIP telephony (bearer-only) traffic (VoIP signaling traffic is assigned to the "Call Signaling" class). Traffic assigned to this class should be marked EF (DSCP 46). This class is provisioned with an Expedited Forwarding (EF) Per-Hop Behavior (PHB). The EF PHB—defined in RFC 3246—is a strict-priority queuing service, and as such, admission to this class should be controlled. Example traffic includes G,711 and G,729a.
•Broadcast Video—This service class is intended for broadcast TV, live events, video surveillance flows, and similar "inelastic" streaming media flows ("inelastic" flows refer to flows that are highly drop sensitive and have no retransmission and/or flow-control capabilities). Traffic in this class should be marked Class Selector 5 (CS5/DSCP 40) and may be provisioned with an EF PHB; as such, admission to this class should be controlled (either by an explicit admission control mechanisms or by explicit bandwidth provisioning). Examples traffic includes live Cisco Digital Media System (DMS) streams to desktops or to Cisco Digital Media Players (DMPs), live Cisco Enterprise TV (ETV) streams, and Cisco IP Video Surveillance (IPVS).
•Real-time Interactive—This service class is intended for (inelastic) room-based, high-definition interactive video applications and is intended primarily for audio and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to the "Transactional Data" traffic class. Traffic in this class should be marked CS4 (DSCP 32) and may be provisioned with an EF PHB; as such, admission to this class should be controlled. An example application is Cisco TelePresence.
•Multimedia Conferencing—This service class is intended for desktop software multimedia collaboration applications and is intended primarily for audio and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to the "Transactional Data" traffic class. Traffic in this class should be marked Assured Forwarding5 Class 4 (AF41/DSCP 34) and should be provisioned with a guaranteed bandwidth queue with DSCP-based Weighted-Random Early Detect (DSCP-WRED) enabled. Admission to this class should be controlled; additionally, traffic in this class may be subject to policing and re-marking6 . Example applications include Cisco Unified Personal Communicator, Cisco Unified Video Advantage, and the Cisco Unified IP Phone 7985G.
•Multimedia Streaming—This service class is intended for Video-on-Demand (VoD) streaming media flows which, in general, are more elastic than broadcast/live streaming flows. Traffic in this class should be marked Assured Forwarding Class 3 (AF31/DSCP 26) and should be provisioned with a guaranteed bandwidth queue with DSCP-based WRED enabled. Admission control is recommended on this traffic class (though not strictly required) and this class may be subject to policing and re-marking. Example applications include Cisco Digital Media System Video-on-Demand streams to desktops or to Digital Media Players.
•Network Control—This service class is intended for network control plane traffic, which is required for reliable operation of the enterprise network. Traffic in this class should be marked CS6 (DSCP 48) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as network control traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes EIGRP, OSPF, BGP, HSRP, IKE, etc.
•Call-Signaling—This service class is intended for signaling traffic that supports IP voice and video telephony; essentially, this traffic is control plane traffic for the voice and video telephony infrastructure. Traffic in this class should be marked CS3 (DSCP 24) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as call-signaling traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SCCP, SIP, H.323, etc.
•Operations/Administration/Management (OAM)—This service class is intended for—as the name implies—network operations, administration, and management traffic. This class is important to the ongoing maintenance and support of the network. Traffic in this class should be marked CS2 (DSCP 16) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as OAM traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SSH, SNMP, Syslog, etc.
•Transactional Data (or Low-Latency Data)—This service class is intended for interactive, "foreground" data applications ("foreground" applications refer to applications that users are expecting a response—via the network—in order to continue with their tasks; excessive latency in response times of foreground applications directly impacts user productivity). Traffic in this class should be marked Assured Forwarding Class 2 (AF21 / DSCP 18) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include data components of multimedia collaboration applications, Enterprise Resource Planning (ERP) applications, Customer Relationship Management (CRM) applications, database applications, etc.
•Bulk Data (or high-throughput data)—This service class is intended for non-interactive "background" data applications ("background" applications refer to applications that the users are not awaiting a response—via the network—in order to continue with their tasks; excessive latency in response times of background applications does not directly impact user productivity. Furthermore, as most background applications are TCP-based file-transfers, these applications—if left unchecked—could consume excessive network resources away from more interactive, foreground applications). Traffic in this class should be marked Assured Forwarding Class 1 (AF11/DSCP 10) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include E-mail, backup operations, FTP/SFTP transfers, video and content distribution, etc.
•Best Effort (or default class)—This service class is the default class. As only a relative minority of applications will be assigned to priority, preferential, or even to deferential service classes, the vast majority of applications will continue to default to this best effort service class; as such, this default class should be adequately provisioned7 . Traffic in this class is marked Default Forwarding8 (DF or DSCP 0) and should be provisioned with a dedicated queue. WRED is recommended to be enabled on this class. Although, since all the traffic in this class is marked to the same "weight" (of DSCP 0), the congestion avoidance mechanism is essentially Random Early Detect (RED).
•Scavenger (or Low-Priority Data)—This service class is intended for non-business related traffic flows, such as data or media applications that are entertainment-oriented. The approach of a less-than best effort service class for non-business applications (as opposed to shutting these down entirely) has proven to be a popular, political compromise: these applications are permitted on enterprise networks, as long as resources are always available for business-critical voice, video, and data applications. However, as soon the network experiences congestion, this class is the first to be penalized and aggressively dropped. Furthermore, the scavenger class can be utilized as part of an effective strategy for DoS and worm attack mitigation9 . Traffic in this class should be marked CS110 (DSCP 8) and should be provisioned with a minimal bandwidth queue that is the first to starve should network congestion occur. Example traffic includes YouTube, Xbox Live/360 Movies, iTunes, BitTorrent, etc.
12 Traffic Class - Figure 8 Cisco Media QoS Recommendations (RFC 4594-based)
RFC 4594 outlines twelve classes of media applications that have unique service level requirements:
•
VoIP Telephony—This service class is intended for VoIP telephony (bearer-only) traffic (VoIP signaling traffic is assigned to the "Call Signaling" class). Traffic assigned to this class should be marked EF (DSCP 46). This class is provisioned with an Expedited Forwarding (EF) Per-Hop Behavior (PHB). The EF PHB—defined in RFC 3246—is a strict-priority queuing service, and as such, admission to this class should be controlled. Example traffic includes G,711 and G,729a.•
Broadcast Video—This service class is intended for broadcast TV, live events, video surveillance flows, and similar "inelastic" streaming media flows ("inelastic" flows refer to flows that are highly drop sensitive and have no retransmission and/or flow-control capabilities). Traffic in this class should be marked Class Selector 5 (CS5/DSCP 40) and may be provisioned with an EF PHB; as such, admission to this class should be controlled (either by an explicit admission control mechanisms or by explicit bandwidth provisioning). Examples traffic includes live Cisco Digital Media System (DMS) streams to desktops or to Cisco Digital Media Players (DMPs), live Cisco Enterprise TV (ETV) streams, and Cisco IP Video Surveillance (IPVS).•
Real-time Interactive—This service class is intended for (inelastic) room-based, high-definition interactive video applications and is intended primarily for audio and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to the "Transactional Data" traffic class. Traffic in this class should be marked CS4 (DSCP 32) and may be provisioned with an EF PHB; as such, admission to this class should be controlled. An example application is Cisco TelePresence.•
Multimedia Conferencing—This service class is intended for desktop software multimedia collaboration applications and is intended primarily for audio and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to the "Transactional Data" traffic class. Traffic in this class should be marked Assured Forwarding5 Class 4 (AF41/DSCP 34) and should be provisioned with a guaranteed bandwidth queue with DSCP-based Weighted-Random Early Detect (DSCP-WRED) enabled. Admission to this class should be controlled; additionally, traffic in this class may be subject to policing and re-marking6 . Example applications include Cisco Unified Personal Communicator, Cisco Unified Video Advantage, and the Cisco Unified IP Phone 7985G.•
Multimedia Streaming—This service class is intended for Video-on-Demand (VoD) streaming media flows which, in general, are more elastic than broadcast/live streaming flows. Traffic in this class should be marked Assured Forwarding Class 3 (AF31/DSCP 26) and should be provisioned with a guaranteed bandwidth queue with DSCP-based WRED enabled. Admission control is recommended on this traffic class (though not strictly required) and this class may be subject to policing and re-marking. Example applications include Cisco Digital Media System Video-on-Demand streams to desktops or to Digital Media Players.•
Network Control—This service class is intended for network control plane traffic, which is required for reliable operation of the enterprise network. Traffic in this class should be marked CS6 (DSCP 48) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as network control traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes EIGRP, OSPF, BGP, HSRP, IKE, etc.•
Call-Signaling—This service class is intended for signaling traffic that supports IP voice and video telephony; essentially, this traffic is control plane traffic for the voice and video telephony infrastructure. Traffic in this class should be marked CS3 (DSCP 24) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as call-signaling traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SCCP, SIP, H.323, etc.•
Operations/Administration/Management (OAM)—This service class is intended for—as the name implies—network operations, administration, and management traffic. This class is important to the ongoing maintenance and support of the network. Traffic in this class should be marked CS2 (DSCP 16) and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as OAM traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SSH, SNMP, Syslog, etc.•
Transactional Data (or Low-Latency Data)—This service class is intended for interactive, "foreground" data applications ("foreground" applications refer to applications that users are expecting a response—via the network—in order to continue with their tasks; excessive latency in response times of foreground applications directly impacts user productivity). Traffic in this class should be marked Assured Forwarding Class 2 (AF21 / DSCP 18) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include data components of multimedia collaboration applications, Enterprise Resource Planning (ERP) applications, Customer Relationship Management (CRM) applications, database applications, etc.•
Bulk Data (or high-throughput data)—This service class is intended for non-interactive "background" data applications ("background" applications refer to applications that the users are not awaiting a response—via the network—in order to continue with their tasks; excessive latency in response times of background applications does not directly impact user productivity. Furthermore, as most background applications are TCP-based file-transfers, these applications—if left unchecked—could consume excessive network resources away from more interactive, foreground applications). Traffic in this class should be marked Assured Forwarding Class 1 (AF11/DSCP 10) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include E-mail, backup operations, FTP/SFTP transfers, video and content distribution, etc.•
Best Effort (or default class)—This service class is the default class. As only a relative minority of applications will be assigned to priority, preferential, or even to deferential service classes, the vast majority of applications will continue to default to this best effort service class; as such, this default class should be adequately provisioned7 . Traffic in this class is marked Default Forwarding8 (DF or DSCP 0) and should be provisioned with a dedicated queue. WRED is recommended to be enabled on this class. Although, since all the traffic in this class is marked to the same "weight" (of DSCP 0), the congestion avoidance mechanism is essentially Random Early Detect (RED).•
Scavenger (or Low-Priority Data)—This service class is intended for non-business related traffic flows, such as data or media applications that are entertainment-oriented. The approach of a less-than best effort service class for non-business applications (as opposed to shutting these down entirely) has proven to be a popular, political compromise: these applications are permitted on enterprise networks, as long as resources are always available for business-critical voice, video, and data applications. However, as soon the network experiences congestion, this class is the first to be penalized and aggressively dropped. Furthermore, the scavenger class can be utilized as part of an effective strategy for DoS and worm attack mitigation9 . Traffic in this class should be marked CS110 (DSCP 8) and should be provisioned with a minimal bandwidth queue that is the first to starve should network congestion occur. Example traffic includes YouTube, Xbox Live/360 Movies, iTunes, BitTorrent, etc.Detail SIP Protocol Support on CUCM 10.x
Session Initiation Protocol (SIP) on CUCM System Guide is quite good. It can be useful (in some case) as a reference on CUCM behavior with regard to SIP protocol. (See http://goo.gl/MQiQGZ)
I find that information in some sections are quite incomplete. e.g. SIP Line Side overview, CUCM SIP EndPoint overview vs B2BUA. Namely, it mentioned some phone models and not the other. Very terse with no background whatsoever.
In addition, more obvious information is not described, e.g. DTMF interopt between SCCP Phones and SIP Phones. (See MTP Section below) Reader has to assume a lot wihtout the background, for example, that DTMF Interopt is more problematic for IVR or AA where User Input needs to be relayed. It is not significant in the case of Phone to Phone conversation.
Note, in the context of the documentation, there are two types of SIP protocol, Line Side SIP and Trunk Side SIP.
I find that information in some sections are quite incomplete. e.g. SIP Line Side overview, CUCM SIP EndPoint overview vs B2BUA. Namely, it mentioned some phone models and not the other. Very terse with no background whatsoever.
Note, in the context of the documentation, there are two types of SIP protocol, Line Side SIP and Trunk Side SIP.
DTMF Interoperation between SCCP & SIP Phone (Section Media Termination Point (MTP) Devices)
You can configure Cisco Unified Communications Manager SIP devices (lines and trunks) to always use an MTP. If the configuration parameters are set to not use an MTP (default case), Cisco Unified Communications Manager will attempt to dynamically allocate an MTP if the DTMF methods for the call are not compatible. For example, phones that are running SCCP support only out-of-band DTMF, and Cisco Unified IP Phones using SIP (7905, 7912, 7940, 7960) support only RFC2833. Because the DTMF methods are not identical, Cisco Unified Communications Manager will dynamically allocate an MTP. If, however, a phone that is running SCCP that supports RFC2833 and out of band, such as Cisco Unified IP Phone 7971, calls a Cisco Unified IP Phone 7940 that is using SIP, Cisco Unified Communications Manager will not allocate an MTP because both phones support RFC2833. By having the same type of DTMF method supported on each phone, no need for an MTP exists.MTP Allocation for In-band vs Out-of-band Endpoints
Forward DTMF Digits From SIP Devices to Gateways or Interactive Voice Response (IVR) Systems for Dissimilar DTMF Methods
The following figure shows the MTP software device that is processing inband DTMF digits from the phone that is running SIP to communicate with the Primary Rate Interface (PRI) gateway. The RTP stream carries RFC 2833 DTMF, as indicated by a dynamic payload type.
The previous figure begins with media streaming, and the MTP device has been informed of the DTMF dynamic payload type.
- The phone that is running SIP initiates a payload type response when the user enters a number on the keypad. The phone that is running SIP transfers the DTMF inband digit (per RFC 2833) to the MTP device.
- The MTP device extracts the inband DTMF digit and passes the digit out of band to Cisco Unified Communications Manager.
- Cisco Unified Communications Manager then relays the DTMF digit out of band to the gateway or IVR system.
Generate DTMF Digits for Dissimilar DTMF Methods
As discussed in DTMF Relay Calls Between SIP Endpoints and Cisco Unified Communications Manager, SIP sends DTMF inband digits, while Cisco Unified Communications Manager only supports out-of-band digits. The software MTP device receives the DTMF out-of-band tones and generates DTMF inband tones to the SIP client.
The figure shown begins with media streaming, and the MTP device has been informed of the dynamic DTMF payload type.
- The SCCP IP phone user presses buttons on the keypad. Cisco Unified Communications Manager collects the out-of-band digits from the SCCP IP phone.
- Cisco Unified Communications Manager passes the out-of-band digits to the MTP device.
- The MTP device converts the digits to RFC 2833 RTP-compliant inband digits and forwards them to the SIP client.
SIP Standards Supported by CUCM
- RFC3261 RFC3262 (PRACK) RFC3264 (Offer/Answer) RFC3311 (UPDATE) 3PCC
- RFC3515 (REFER) Also Replaces and Referred-By Headers
- Remote Party Id (RPID) Header
- Diversion Header
- Replaces Header
- Join Header
- P-Charging-Vector Header
- RFC3265 + Dialog Package
- RFC3265 + Presence Package
- RFC3265 + KPML Package
- RFC3265 + RFC3842 MWI Package (Unsolicited Notify)
- Remotecc
- RFC4028 Session Timers
Cisco Unified Communications Manager Functionality on SIP Phones
- BLF Call Pickup
- Calling Party Normalization
- CTI Support
- Dial Plans
- Directed Call Pickup
- Do Not Disturb
- Do Not Disturb (DND) Call Reject
- DSCP Configuration
- E.164
- iX Media Channel
- Join and Join Across Lines
- Malicious Call Identification (MCID)
- Network Time Protocol (NTP)
- PLAR
- Programmable Line Keys
- Single Button Barge/cBarge
- Single Call UI
- SIP Profiles for Endpoints
- Soft Client Dual Registration
- Softkey Handling
- Unified Mobile Communications Server (UMCS) Integration
SIP OPTIONS
In Cisco Unified Communications Manager, the SIP OPTIONS method allows a SIP trunk to track the status of remote destinations. By sending outgoing OPTIONS and checking the incoming response message, the SIP trunk knows whether remote peers are ready to receive a new request. The SIP trunk does not attempt to set up new calls to unreachable remote peers; this approach allows for quick failovers.
Cisco Unified Communications Manager uses SIP OPTIONS as a keep-alive mechanism on the SIP trunk. Cisco Unified Communications Manager periodically sends an OPTIONS request to the configured destination address on the SIP trunk. If the remote SIP device fails to respond or returns a SIP error response, Cisco Unified Communications Manager tries to reroute the calls by using other trunks or by using a different address, depending on the configuration.
The OPTIONS request lies outside the context of a call; therefore, the request allows Cisco Unified Communications Manager to detect failures even if no calls are present on the SIP trunk. This approach allows any subsequent calls to be rerouted more quickly. The SIP OPTIONS method prevents calls from incurring large timeout and retry delays before the calls get rerouted.
Cisco Unified Communications Manager Configuration Tips
The following configuration tips apply to Cisco Unified Communications Manager Administration when a SIP trunk is configured for OPTIONS:
- Configure a SIP profile to enable SIP OPTIONS. (Use the menu option in Cisco Unified Communications Manager Administration.) Copy the Standard SIP Profile and rename the copy; for example, OPTIONS Profile. Check the Enable OPTIONS Ping to monitor destination status for trunks with service type "None (Default)" check box. SIP OPTIONS is disabled by default.
SIP Line Side Overview (as opposed to SIP Trunk Side)
The SIP line side feature affects Cisco Unified Communications Manager architecture, the TFTP server, and the Cisco Unified IP Phones. The phone features of the phone that is running SIP, which are equivalent to the phone features of the phone that is running SCCP, behave similarly. Cisco Unified IP Phones 7941/61/71/70/11 support all features and most CTI applications. Cisco Unified IP Phones 7905/12/40/60 support a reduced feature set (for example, limited MOH and failover capabilities). SIP trunk side applications work for both phones that are running SCCP and phones that are running SIP.
CUCM Softkey Configuration
From CUCM System Guide 10.0(1), Chapter Cisco Unified IP Phones. (Ref: http://goo.gl/GhP14P)
Table 36-8 lists the call states.
Call State
|
Description
|
|---|---|
Connected
|
Displays when call is connected
|
Connected Conference
|
Consultation call for conference in connected call state
|
Connected Transfer
|
Consultation call for transfer in connected call state
|
Digits After First
|
Off-hook call state after user enters the first digit
|
Off Hook
|
Dial tone presented to phone
|
Off Hook With Feature
|
Off-hook call state for transfer or conference consultation call
|
On Hold
|
Call on hold
|
On Hook
|
No call exists for that phone.
|
Remote In Use
|
Another device that shares the same line uses call.
|
Ring In
|
Call received and ringing
|
Ring Out
|
Call initiated and the destination ringing
|
Table 8 Programmable Line Keys for Cisco Unified IP Phones
Feature
|
Phone Model 7971, 7970, 7961, 7941, 7914, 7915, 7916
|
Phone Model 7931 (SCCP only)
|
|---|---|---|
Redial
|
Yes
|
No, uses existing line button
|
Hold
|
Yes
|
No, uses existing line button
|
Transfer
|
Yes
|
No, uses existing line button
|
Privacy
|
Yes
|
Yes
|
Forward All
|
Yes
|
Yes
|
Meet Me
|
Yes
|
Yes
|
Conference
|
Yes
|
Yes
|
Park
|
Yes
|
Yes
|
Pickup
|
Yes
|
Yes
|
Group Call Pickup
|
Yes
|
Yes
|
Malicious Caller ID (MCID)
|
Yes
|
Yes
|
Conf List
|
Yes
|
Yes
|
Remove Last Participant
|
Yes
|
Yes
|
QRT
|
Yes
|
Yes
|
Call Back
|
Yes
|
Yes
|
Other Call Pickup
|
Yes
|
Yes
|
Video Mode
|
Yes
|
Yes
|
New Call
|
Yes
|
Yes
|
End Call
|
Yes
|
Yes
|
HLog (Hunt Group)
|
Yes
|
Yes
|
Mobility
|
Yes
|
Yes
|
Settings
|
No, uses existing button
|
Yes
|
Information
|
No, uses existing button
|
No
|
Services
|
No, uses existing button
|
Yes
|
Messages
|
No, uses existing button
|
Yes
|
Directories
|
No, uses existing button
|
Yes
|
AppMenu
|
No, uses existing button
|
Yes
|
Headset
|
No, uses existing button
|
Yes
|
Codec Supports on CUCM 10.x
CUCM System Guides provides detail list of the codecs as well as some of their characteristics. (See CUCM System Guides 10.x here http://goo.gl/VhVCsp)
Link Loss Type = Lossless
G.722 64k-64 kb/s
iSAC-32 kb/s
AAC-LD (MP4A-LATM)-32 kb/s
Link Loss Type = Lossy
iSAC-32 kb/s
AAC-LD (MP4A-LATM)-32 kb/s
G.722 64k-64 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...."
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.
Codec Preference Order within CUCM and over SIP Intercluster Trunk
One of the key takeaway is the codec preference on Lossless vs Lossy links. (Refer to table 2 on the page)Link Loss Type = Lossless
G.722 64k-64 kb/s
iSAC-32 kb/s
AAC-LD (MP4A-LATM)-32 kb/s
Link Loss Type = Lossy
iSAC-32 kb/s
AAC-LD (MP4A-LATM)-32 kb/s
G.722 64k-64 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...."
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
|
Codec Preference Order on H323 Intercluster Trunk
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.
- 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.
- 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.
Bandwidth Required per Call
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
| ||
AAC-LD (MP4A-LATM)
|
56 kb/s
|
Not applicable
|
80 kb/s
| ||
AAC-LD (LATM)
|
48 kb/s
|
Not applicable
|
72 kb/s
| ||
AAC-LD (MP4A-LATM)
|
32 kb/s
|
Not applicable
|
56 kb/s
| ||
AAC-LD (MP4A-LATM)
|
24 kb/s
|
Not applicable
|
48 kb/s
| ||
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)
Subscribe to:
Posts (Atom)