CUBE - SIP - Enhanced 180 Provisional Response Handling

Source: http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/vb_book/vb_book/vb_1506.html

Information About SIP—Enhanced 180 Provisional Response Handling

The Session Initiation Protocol (SIP) feature allows you to specify whether 180 messages with Session Description Protocol (SDP) are handled in the same way as 183 responses with SDP. The 180 Ringing message is a provisional or informational response used to indicate that the INVITE message has been received by the user agent and that alerting is taking place. The 183 Session Progress response indicates that information about the call state is present in the message body media information. Both 180 and 183 messages may contain SDP, which allows an early media session to be established prior to the call being answered.

Prior to this feature, Cisco gateways handled a 180 Ringing response with SDP in the same manner as a 183 Session Progress response; that is, the SDP was assumed to be an indication that the far end would send early media. Cisco gateways handled a 180 response without SDP by providing local ringback, rather than early media cut-through. This feature provides the capability to ignore the presence or absence of SDP in 180 messages, and as a result, treat all 180 messages in a uniform manner. The SIP—Enhanced 180 Provisional Response Handling feature allows you to specify which call treatment, early media or local ringback, is provided for 180 responses with SDP:

Table 1 shows the call treatments available with this feature:

Table 1 Call Treatments with SIP Enhanced 180 Provisional Response Handling 

Response Message	SIP Enhanced 180 Provisional Response Handling Status	Treatment
180 response with SDP	Enabled (default)	Early media cut-through
180 response with SDP	Disabled	Local ringback
180 response without SDP	Not affected by the SIP—Enhanced 180 Provisional Response Handling feature	Local ringback
183 response with SDP	Not affected by the SIP—Enhanced 180 Provisional Response Handling feature	Early media cut-through

CUCM-based Call Recording and Silent Monitoring

Source: Call Recording and Monitoring

Silent Monitoring

Cisco Unified CM uses an architecture based on the IP phones to provide call monitoring and recording for audio calls. It uses the IP phone built-in bridge (BIB) to enable call monitoring and recording.

For call monitoring, the agent phone combines the two voice RTP streams on the agent phone and sends the resulting stream to the supervisor phone. Call monitoring can be invoked by call center applications through the JTAPI or TAPI interfaces of Unified CM.

The call recording device is configured on Unified CM as a SIP trunk device. For recording, the agent phone forks the two streams to the recording server. The two streams, one for the agent voice and one for the customer voice, get recorded separately. The recorded streams can be mixed to produce the conversation using third-party applications.

Figure 25-2 illustrates the basic call recording setup using Unified CM Silent Call Monitoring and Call Recording features. Agent and supervisor phones are CTI controlled.

Figure 25-2 Call Monitoring and Recording with Unified CM

For details on the Unified CM Silent Call Monitoring and Call Recording features, refer to the latest version of the Cisco Unified Communications Manager Features and Services Guide , available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Call Recording

Figure 25-3 illustrates a basic Unified CM deployment for call recording. Once a call is established from a signaling perspective, the media flows directly between the external phone and the internal IP phone. The IP phone is configured to fork media to Cisco MediaSense for call recording. If the call gets transferred to another IP phone, call recording ends unless the phone that accepts the transferred call is also configured for recording.

Figure 25-3 Call Recording with Cisco Unified CM and MediaSense

Shaping vs Policing

Source:
Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting

Selection Criteria

The following table lists the differences between shaping and policing to help you choose the best solution.

	Shaping	Policing
Objective	Buffer and queue excess packets above the committed rates.	Drop (or remark) excess packets above the committed rates. Does not buffer.*
Token Refresh Rate	Incremented at the start of a time interval. (Minimum number of intervals is required.)	Continuous based on formula: 1 / committed information rate
Token Values	Configured in bits per second.	Configured in bytes.
Configuration Options	shape command in the modular quality of service command-line interface (MQC) to implement class-based shaping. frame-relay traffic-shape command to implement Frame Relay Traffic Shaping (FRTS). traffic-shape command to implement Generic Traffic Shaping (GTS).	police command in the MQC to implement class-based policing. rate-limit command to implement committed access rate (CAR).
Applicable on Inbound	No	Yes
Applicable on Outbound	Yes	Yes
Bursts	Controls bursts by smoothing the output rate over at least eight time intervals. Uses a leaky bucket to delay traffic, which achieves a smoothing effect.	Propagates bursts. Does no smoothing.
Advantages	Less likely to drop excess packets since excess packets are buffered. (Buffers packets up to the length of the queue. Drops may occur if excess traffic is sustained at high rates.) Typically avoids retransmissions due to dropped packets.	Controls the output rate through packet drops. Avoids delays due to queuing.
Disadvantages	Can introduce delay due to queuing, particularly deep queues.	Drops excess packets (when configured), throttling TCP window sizes and reducing the overall output rate of affected traffic streams. Overly aggressive burst sizes may lead to excess packet drops and throttle the overall output rate, particularly with TCP-based flows.
Optional Packet Remarking	No	Yes (with legacy CAR feature).

* Although policing does not apply buffering, a configured queuing mechanism applies to "conformed" packets that may need to be queued while waiting to be serialized at the physical interface.

Sources of Delay in VoIP Network

Source: Understanding Delay in Packet Voice Networks

Sources of Delay

Coder (Processing) Delay

Packetization Delay

Serialization Delay

Queuing/Buffering Delay

Network Switching Delay

De-Jitter Delay

Summary of IP Phone Firmware Distribution Model

The table below is taken directly from the following Cisco document.

Source: Cisco Unified IP Phone Firmware Distribution Methods

It is here as a preview of the document above.

Table 1. Summary of Distribution Models

	Peer Firmware Sharing	Load Server	Traditional TFTP
Advantages	• Hierarchy is automatic • One download per phone model on a subnet • Uses TCP • Fails back to TFTP • Speeds up LAN upgrades • Reduces TFTP CPU load during upgrade	• Has same download time as LAN image distribution • Distributes TFTP load over multiple TFTP servers	• Proven distribution • Default behavior
Disadvantages	• Must be enabled on each phone • Hierarchy is formed for each phone model • Hierarchy is limited to subnet	• IP must be set on each phone • Administrator must manually file copy to load server • No failback to TFTP on error • More prone to user error	• High-bandwidth requirements • Multiple requests for same file • High CPU usage on TFTP server