Overload Prevention Techniques
With any network, there is a risk of exceeding the supported or intended capacity of the design. This could pose a risk to the service being provided by the call processing platform if the capacity is exceeded to a point where the platform can no longer sufficiently process calls. This condition, referred to as overload, is defined as a server not having “sufficient resources to process all incoming … messages” (RFC 7339, p. 4).
Overload can occur due to several different external factors, including the following:
Current solution design not intended to meet the growth or demand of the actual call volume
A malfunction or failure in the upstream load-balancing architecture, resulting in atypically larger volume across a subset of call paths
A call loop triggered by a misconfiguration in call routing
Physical world emergencies or unplanned events driving above-average call volume over what has been planned
DoS attack on the network
Steps can be taken to prevent overload scenarios, such as appropriately sizing deployments with enough headroom for growth (as discussed in this chapter), implementing DoS prevention techniques (as discussed in Chapter 13, “Security Threat Mitigation”), and by proactively alarming (as discussed in Chapter 14, “Monitoring and Management”). Even with the preventive measures, however, it may not be adequate to protect against scenarios where a call processing platform would be at risk of degraded performance. As a result, there is a need for additional control of overload scenarios, through both the proactive mechanisms of detection and prevention. and the reactive mechanisms to refuse calls over a specific threshold.
This section outlines a number of mechanisms for controlling overload of SBCs through SIP overload specifications, as well as with CAC mechanisms such as RSVP. The approaches can be either reactive (such as rejecting calls when reaching the platform limitation) or proactive (such as with SIP overload, where guidance can be sent upstream to redirect or reduce the density of call requests to that peer).
SIP Overload Specifications
The SIP protocol can use the mechanism of sending a 503 Service Unavailable error back to the sender when experiencing significant load (such as during a processing overload scenario). This behavior alone, though, is not enough to prevent an overload scenario. RFC 6357 suggests that responding with a 503 response in these overload conditions may actually contribute to and exacerbate the overload problem. The reasoning for this is that if there is signaling congestion, responding with additional messages such as a 503 response will add to the pile of messages; if these responses are not delivered in a timely manner, the sending client may have to retransmit the original message again, which would continue to increase the severity of the overload condition.
To help add extra protection in these scenarios, some recent RFCs have been developed to suggest and define alternative methods of using SIP signaling to detect and either prevent or recover from these overload scenarios. These controls provide a more robust architecture when external factors result in an increase in call volume that may test the capability of the platform.
RFC 6357 defines theoretical approaches for overload control, but it doesn’t define specific protocols for the methods. SIP overload controls are split into two main methods of control: explicit and implicit. With explicit overload control, a server indicates to upstream peers that it is reaching its capacity limit, allowing for upstream devices to adjust their transmission rates. In contrast, implicit control uses the absence of messages from a downstream peer as an indication that overload has occurred on that device. This results in steering requests away from the overloaded device until it either hears from the device again or a timer expires. These approaches can be further split into the following defined approaches for overload control:
Explicit control—This approach defines mechanisms for the receiver to indicate how much traffic it can receive.
Rate based—Communication back to the sender to limit the request rate to a maximum number of requests per second.
Loss based—Instruction sent by the receiver to the sender to reduce message transmission by a specific percentage.
Window based—Allows a sender to send a defined number of messages before requiring a response from the receiver to continue. Much as with TCP windowing, the window size here can dynamically grow to a size that will performed without notice of overload issues.
Overload signal based—The receiver transmits a 503 Service Unavailable message during a load condition, upon which the sender reduces the transmission rate and continues to do so until the overload scenario and 503 responses are eliminated.
On/off—Allows the receiver to send a 503 Service Unavailable message with a Retry-After header to define a temporary duration of time that messages should not be sent to this receiver.
Implicit control—The transmission rate is decreased or stopped when a receiver indicates overload. The sender should sense this condition (such as through signaling or slow/nil responses) and then decrease the transmission rate or stop transmitting altogether for a period of time.
RFC 7339: Overload Control Communication Scheme
RFC 7339 defines a loss-based SIP overload control mechanism that is advertised through the Via header and defined through four parameters:
oc—Indicates a reduction in the number of requests arriving at the server.
oc-algo — Lists tokens corresponding to the class of overload control algorithms supported by the client. One of the algorithms is chosen and indicated in the response.
oc-validity—Establishes a time limit for which overload control is in effect.
oc-seq—Provides a sequence number in the form of a timestamp for overload messaging to aid in sequencing any out-of-order responses to determine the most recent overload status.
Upon first contact with a server, a client that supports SIP overload must insert the oc parameter without any values and must also include the oc-algo parameter with a list of the algorithms supported. The list of supported algorithms must always include at least the loss algorithm.
After negotiation of the overload algorithm to be used, an overload condition is then signaled through setting the oc parameter to a nonzero value.
The presence of overload control can be terminated either through implicit expiration of the oc-validity time (the specified validity time expiring since the last message) or the subject transmitting oc-validity=0.
Example 8-18 shows the presence of the oc and oc-algo parameters in the Via header, signifying advertisement of support for overload control by using the loss and rate algorithms.
Example 8-18 Advertisement of Overload Control in the SIP Via Header
INVITE sips:user@example.com SIP/2.0 Via: SIP/2.0/TLS p1.example.net;branch=z9hG4bK2d4790.1;oc;oc-algo="loss,rate"
The receiver responds to the overload advertisement by selecting an algorithm and also setting oc and oc-validity both to 0, as shown in Example 8-19, to indicate that it is not currently in an overload condition.
Example 8-19 Acknowledgement of Overload Control Algorithm
SIP/2.0 100 Trying Via: SIP/2.0/TLS p1.example.net;branch=z9hG4bK2d4790.1; received=192.0.2.111;oc=0;oc-algo="loss";oc-validity=0
In contrast, if the receiving party did not support overload control, the original parameters oc;oc-algo="loss,A" would be left unchanged in the Via header to signal that it does not support overload control.
After the overload mechanism is negotiated by the two parties, at some point, one side may experience overload. When this occurs, that side signals the condition by setting the relevant parameters. In Example 8-20, one side is requesting a 20% reduction in message rate (that is, 500ms).
Example 8-20 Indication of an Overload Condition
SIP/2.0 180 Ringing Via: SIP/2.0/TLS p1.example.net; branch=z9hG4bK2d4790.3;received=192.0.2.111; oc=20;oc-algo="loss";oc-validity=500;oc-seq=1282321615.782
Once the overload subsides, the parameters from Example 8-20 are changed to indicate that the overload condition has been resolved, and the reduction rate is set to 0% and for 0ms (indefinitely), as shown in Example 8-21.
Example 8-21 Indication of a Resolved Overload Condition
SIP/2.0 183 Queued Via: SIP/2.0/TLS p1.example.net; branch=z9hG4bK2d4790.4;received=192.0.2.111; oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
Supported Overload Algorithms
With the loss algorithm, the message rate is requested to be reduced by a specified percentage (a value between 0 and 100%), relative to the current rate of messages. The upstream party being instructed to reduce the rate then either rejects or redirects that percentage of the incoming calls for the specific time period, based on the setting in the oc-validity parameter. This algorithm is the default algorithm supported for overload control, and support of it is a requirement for the implementation of this overload approach defined by RFC 7339.
As defined in RFC 7415, a published alternative algorithm is the rate algorithm. With this algorithm, a SIP peer defines a specified value to use as the messages-per-second rate, for a defined period of time. When signaled to the sender, the sender then seeks to throttle messages for an average target of 1/(rate) seconds between message transmissions to achieve the messages-per-second target. For example, oc=150;oc-algo="rate";oc-validity=5000; instructs the other side to transmit at a target of 150 messages per second for a total duration of 5000 ms (5 seconds). This would be accomplished on the transmitting side by targeting a pause of 1/150 seconds between message transmissions across this period of 5 seconds.
Overload Security Considerations
A challenge with defining the ability for peers to message a desire to reduce or stop message transmission opens up potential concern for security. A malicious user could potentially signal to a critical device to reduce message transmission as a way to mount a DoS attack on the device. As a result, it is important for the device processing the overload request to trust the integrity and intent of any peer device that may signal an overload condition. This can be accomplished through standard SIP authentication schemes, such as the SIP Authorization header, or through S/MIME key exchange, as discussed in Section 23 of RFC 3261. Section 3.4 of RFC 7200 also defines the concept of a trust domain, which is a set of entities within an autonomous entity that are permitted to exchange overload filtering mechanisms.
Because it is important for overload conditions to be signaled end-to-end to prevent an overload condition from just passing the condition to a node further upstream, it is still important to be able to signal overload conditions across trust boundaries. In these scenarios, RFC 7200 suggests using a simple 503 response upstream to signal overload across a trust boundary.
It is strongly desired that TLS be employed between SIP peers and to filter processing of inbound messages to only source IP addresses of known trusted entities. This approach helps ensure that malicious users cannot spoof the source destination and trigger an unrequested overload control scenario as a way to deny service.
Additional Overload Challenges
The techniques described in this section for defending against overload conditions all require some reliance on the peer nodes in the SIP network. With explicit overload controls, the adjacent peers must typically both support the same implementation strategies for the overload control outcome to be successful. Even with implicit overload control, the local SIP node needs to have intelligence of the ability to execute the overload control when the downstream peer becomes responsive.
Call Admission Control
At the time of this writing, the SIP overload approaches described in the previous section have not become a widespread implementation and deployment. As a result, some challenges for interoperability and adoption must be overcome before these strategies can be widespread and most effective. In the meantime, other strategies can be applied locally on a device to help protect overload, which do not rely on external signaling to peers to take action. Some of these approaches that are available are discussed in this section.
Because a network has a constrained amount of bandwidth that can be used for call transmission, it is important to have controls that prevent the ability for calls to saturate these network paths. Without any control over the number of calls set up across a network segment, if the concurrent call volume exceeds what the circuit or device is capable of handling, it may result in degradation of call quality across all calls through that path.
Call Admission Control (CAC) has been defined to prevent this condition. This concept allows for a limited number of concurrent calls to be supported across a call path so administrators can control calls to a maximum concurrent volume that will not exceed the known capabilities of the network. If a call is attempted across a call path where CAC has determined that there is no additional availability to support the call, the call will be rejected or redirected along another call path to ensure integrity of call quality for the existing calls.
CAC can be accomplished through either of these two forms:
Local CAC—A call processing node is restricted to allow a specific number of calls across a specific call path (for example, 20 maximum concurrent calls supported across a single SIP trunk to the service provider). This method is not intelligent enough to understand actual bandwidth consumption of the network utilization, and as a result, this is a predictive and best-guess approach to preserving bandwidth.
Resource-based—The decision to permit a call is governed by the amount of available resources, such as the number of channels available for a call, maximum licensed calls, available DSP resources, or actual network utilization.
CAC on CUBE
On CUBE, CAC can be defined either at the interface or dial-peer level, or it can be configured to apply globally across the entire platform.
Interface and Dial Peer–Specific CAC
CAC on CUBE can be accomplished by simply configuring the maximum number of calls to be supported on each dial peer. This is configured by specifying the max-conn parameter under dial-peer, as shown in Example 8-22.
Example 8-22 Configuration for Maximum Concurrent Calls on a dial-peer
dial-peer voice 1 voip max-conn 10
With this approach of setting the maximum calls based on call counts, CUBE is not aware of the underlying bandwidth being consumed by each call leg. As a result, maxconn 10 would support 10 maximum calls on a dial peer. Now consider a scenario in which the dial peer has a voice-class codec with G.729 and G.711 both configured. This configuration could allow for a total bandwidth consumption of 312 kbps for G.729 or 1104 kbps for G.711. This is a wide difference in bandwidth between the two scenarios, and the limitations of this approach should be considered when using this approach and determining the appropriate CAC sizes.
When a call fails due to exceeding the maximum connections defined, CUBE displays the following syslog message and then rejects the call with a 503 Service Unavailable or Q.850 cause value 44 (requested circuit/channel not available):
%CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer <id>
An alternative (or addition) to specifying the maximum call connections is to specify the maximum bandwidth permitted across the dial peer. This is done by specifying the max-bandwidth parameter under the dial peer with the maximum bandwidth, in Kbps, that is to be supported for the peer (see Example 8-23).
Example 8-23 Configuration of Maximum Bandwidth CAC
dial-peer voice 1 voip session protocol sipv2 max-bandwidth 1024 midcall-exceed exempt-local-media
In this example, dial-peer 1 is allowed to set up as many calls as it can until the total bandwidth for calls across the dial peer exceeds 1024 Kbps. The parameter midcall-exceed allows for already established calls to exceed the max-bandwidth statement if the call upgrades the codec in the middle of the call to one that consumes more bandwidth. The default action, when this command is not specified, would drop the call during such scenarios when a mid-call codec change would exceed the defined bandwidth. The exempt-local-media command excludes calls that are both sourced and terminate on the chassis internally to prevent them from decrementing against bandwidth counts intended for application on external interfaces, circuits, or signaling peers.
The max-bandwidth and max-conn parameters can be used individually or together on a dial peer. When combined on the same dial peer, the parameter that is first exceeded causes the call to be rejected.
When the call is rejected due to a lack of available bandwidth, no response is sent to the upstream peer. The call is ignored, and a message similar to the following is output to syslog:
%SIP-3-DIALPEERBWCAC: Calling number 4085551234, called number 9195551234, dial- peer 1, used bandwidth 960, available bandwidth 0, requested bandwidth 80, call state initial-reject
The cause value used during a triggered call failure due to this dial peer CAC can be changed with the following global commands, along with any SIP reason code between 400 and 699:
error-code-override max-conn failure SIP-code error-code-override max-bandwidth failure SIP-code
Although the max-bandwidth command discussed earlier in this chapter is only aware at the dial peer, a call threshold can also be applied at the interface level with the call threshold interface command. In Example 8-24, CAC is defined for a threshold of being triggered when the interface bandwidth reaches the value of 1000 Kbps and then sustains above 800 Kbps.
Example 8-24 Defining a per-Interface Maximum Call Bandwidth
call threshold interface GigabitEthernet 0/0 int-bandwidth low 800 high 1000
Bursts in call setups can also be controlled at the dial-peer level with the command call spike along with the maximum calls desired within a specified window of time. The system takes multiple snapshots over a specified window of time to determine the current volume. The default window of measurement to determine the current incoming call number is an average of five consecutive 200 ms windows, which can be adjusted. Example 8-25 shows how to configure CUBE to reject a rate over 20 CPS by taking 5 sampling windows of 1 second (1000 ms) each.
Example 8-25 Defining a Maximum Number of Calls per Second
call spike 20 steps 5 size 1000
Global CAC
A challenge with the max-conn command discussed in the previous section is that it is only dial peer aware. There is not a capability with that mechanism to be able to restrict calls when the total calls on the platform exceed a defined threshold.
For conditions where impairment from call overload needs to be controlled at an interface or platform-wide level, the global CAC functionality on CUBE can be used. This extensive CAC ability is useful for protecting against exceeding the overall platform guidelines for capacity, especially in conditions where there is a complex overlapping of dial peers distributed across several network interfaces.
In addition to total concurrent call counts on the platform, several other platform conditions can also be defined as thresholds through the call threshold global command. The following parameters can be defined with this CAC feature:
total-calls—The total number of concurrent calls on the platform
cpu-5sec—The 5-second CPU utilization
cpu-avg—The average CPU utilization across 60 seconds
io-mem—The amount of memory utilized for input/output of packet forwarding across the past 5 seconds
proc-mem—The memory utilized for processor tasks that are not I/O related (that is, the utilized amount not used by io-mem) across the past 5 seconds
total-mem—Total memory utilization of the platform across the past 5 seconds
A rejected call from global CAC also prints a message to the syslog; the following is an example of a string for a reject from exceeding the total-calls threshold:
%SIP-3-TOTCALLCAC: Call rejected due to CAC based on Total-calls, sent response 503
SIP calls have an additional configuration for defining the rejection cause value with the command error-code-override that is found under the sip section of voice service voip. Example 8-26 demonstrates overriding the cause value for when CAC bandwidth is exceeded to respond with a 503 Service Unavailable message.
Example 8-26 Overriding SIP Error Codes During CAC Conditions
voice service voip sip error-code-override cac-bandwidth failure 503
The following parameters can be defined to override the SIP error codes with the error-code-override command:
cac-bandwidth — Status code to be sent for max-bandwidth CAC
call spike — Status code to be sent for call spiking
cpu — Status code to be sent for all CPU thresholds
max-conn — Status code to be sent for max-conn thresholds
mem — Status code to be sent for all memory thresholds
total-calls — Status code to be sent for total call thresholds
SIP error codes can also be defined under specific dial peers through the command voice-class sip error-code-override.
RSVP-Based CAC
An alternative that helps overcome some of the constraints with local CAC is Resource Reservation Protocol (RSVP). RSVP, as described in RFC 2205, is a protocol designed to improve admission control through reserving resources in a network for use by specific applications. RFC 2212 further leverages RSVP to allow for reservation of bandwidth resources, ensuring that QoS can be met for a data flow on a per-hop basis across the network path by controlling the maximum packet queuing delay that may be experienced. This approach ensures that the network path has the available bandwidth and resources before setting up the data session (such as a call) and then also dynamically accounts for the utilization of those resources through the life of the data session.
When a host is RSVP enabled and has a data flow that needs QoS guaranteed by RSVP, it sends an RSVP path message across the data path every 30 seconds. Each node that is RSVP aware will consume the message and either ensure the needed resource reservation and forward the packet downstream or respond with a resource reservation rejection. Any hops that are not RSVP aware will simply forward the packet along the path to the next hop, without reserving resources for the flow.
The advantage of RSVP-based CAC over traditional CAC is that the entire path capable of RSVP is reserved for resources rather than just the local resources on a single node. RSVP is path aware, so if the underlying network path changes, RSVP adapts and updates each node with the new resource utilization requirements, ensuring that resource reservations are maintained and the level of expected service for the packet forwarding is upheld.
CUBE can have two layers of RSVP configuration: the general network interface RSVP commands that would be on any RSVP-aware hop in the network and the dial peer–specific RSVP configurations.
The RSVP configurations for the network need to be defined. This needs to be done on any device that is RSVP aware, regardless of whether it is an SBC or even when it isn’t voice aware (that is, doesn’t have dial-peer configurations). To define the RSVP bandwidth to be used at the network interface, the command ip rsvp bandwidth is used under the interface. This command specifies the amount of bandwidth to allow for reservation on RSVP-enabled flows.
If the interface is servicing multiple sensitive data flows, such as both voice and video, then a policy group can be further defined for each application type. Policy groups are created with the ip rsvp policy command. In Example 8-27, there is a T1 with a total reservation of bandwidth for RSVP use set to 1024 Kbps, and video is only allowed to use up 300 Kbps of that pool, but voice traffic can use up to 768 Kbps of the pool.
Example 8-27 Interface Configuration for RSVP
ip rsvp policy identity rsvp-video policy-locator .*VideoStream.* ip rsvp policy identity rsvp-voice policy-locator .*AudioStream.* interface Serial0/0/1:0 ip address 192.0.2.100 255.255.255.0 service-policy output shaper ip rsvp bandwidth 1024 ip rsvp data-packet classification none ip rsvp resource-provider none ip rsvp policy local identity rsvp-voice maximum bandwidth group 768 forward all ip rsvp policy local identity rsvp-video maximum bandwidth group 256 forward all
The following list breaks down the information from Example 8-27:
ip rsvp policy identity — Defines the regular expression to associate these request types to the application-specific rsvp-video and rsvp-voice policies defined under the interface. VideoStream and AudioStream are the application IDs that Cisco Unified Communications Manager uses as default in System> Service Parameters> System – RSVP. Consult vendor documentation to determine these values for other collaboration products.
service-policy output shaper — Attaches the WAN QoS policy shaper to the interface for appropriate queuing. This is configured on interfaces where network congestion is expected to occur. The shaper QoS configuration is further discussed in the next section.
ip rsvp bandwidth 1024 — Defines the amount of bandwidth, in Kbps, to be allocated for all RSVP flows.
ip rsvp data-packet classification none — Disables RSVP processing of every packet, which improves overhead and network performance.
ip rsvp resource-provider none — Ensures that class-based weighted fair queueing (CBWFQ) is used for data processing, which aligns with the CBWFQ policy map that is being applied to the interface.
ip rsvp policy local identity rsvp-voice — Defines a policy group called rsvp-voice. This is associated by RSVP application IDs with the ip rsvp policy identity command from earlier.
maximum bandwidth group 768 — Defines the portion of the overall rsvp bandwidth that can be reserved by applications matched for rsvp-voice. This specific command is reserving 768 Kbps for voice traffic flows, and video is defined as 256 Kbps. The sum of these values for all groups is allowed to exceed the total RSVP bandwidth, but in those conditions, a group may be rejected even if the utilized bandwidth for the group is under the policy limit in situations where the total RSVP bandwidth has been exceeded.
forward all — Accepts and forwards all RSVP messages to the next hop.
In Example 8-27, it is important that the bandwidth defined under the interface matches the defined sizes of the appropriate queues for the QoS policy on the interface. This ensures that when the traffic is reserved for RSVP, the traffic is guaranteed to go into the appropriate queue for the circuit. The priority queue size (generally reserved for voice media) on the interface should also not be higher than the committed rate the service provider of the circuit has given.
In Example 8-27, because voice traffic should be placed in a priority queue as a best practice, the priority queue for the serial interface should match the RSVP bandwidth defined for the voice group, which in this case is 768 Kbps. Though the details of QoS configuration for collaboration media are not further covered in this book, a sample configuration to match the RSVP configuration from Example 8-27 is provided. The configuration for QoS in Example 8-28 assumes that DSCP is being trusted from the access layer through the core to this edge device.
Example 8-28 Sample Configuration for CBWFQ for Voice/Video Traffic
class-map match-any rtp-voice match dscp ef class-map match-any rtp-video match dscp af41 class-map match-any signaling match dscp cs3 af31 match protocol mgcp match protocol h323 match protocol sip match protocol skinny policy-map wan-qos class rtp-voice priority 768 class rtp-video priority 256 class voice-control bandwidth 8 class class-default fair-queue random-detect dscp-based set dscp 0 policy-map shaper class class-default shape average 1544000 service-policy wan-qos interface Serial0/0/1:0 service-policy output shaper
Once the interface-specific configuration for RSVP has been performed, the voice-specific RSVP configuration can be performed on CUBE. Example 8-29 shows an example of RSVP configuration that would be specifically applied for a voice device such as CUBE.
Example 8-29 RSVP Configuration for CUBE
dial-peer voice 150 voip voice-class sip rsvp-fail-policy voice post-alert mandatory disconnect retry 2 interval 30 voice-class sip rsvp-fail-policy video post-alert mandatory disconnect retry 2 interval 30 req-qos controlled-load audio req-qos controlled-load video acc-qos controlled-load audio acc-qos controlled-load video ip qos dscp default media rsvp-fail ip qos dscp default video rsvp-fail ip qos policy-locator voice app AudioStream ip qos policy-locator video app VideoStream ip qos defending-priority 1111
The following list explains the information shown in Example 8-29:
voice-class sip rsvp-fail-policy — This command defines the action to take when RSVP negotiation fails. This command specifies that after the alerting state of the call, if RSVP cannot reserve resources after two attempts—waiting 30 seconds and retrying—the call will be disconnected. The alternative to disconnecting is keep-alive, which does not disconnect the call but specifies a time interval to continue sending RSVP keep-alive messages until resources can be reserved for that call.
req-qos controlled-load — The default behavior in IOS is to accept best-effort QoS, which means that an RSVP reservation is not initiated or requested by default. req-qos and acc-qos set the requested and acceptable QoS behavior, respectively. controlled-load requests low-delay and high-throughput QoS (by using WRED) for matches on this dial peer and is generally preferred for real-time communication. Other options for this command are guaranteed-delay (where RSVP guarantees bandwidth by using Weighted Fair Queuing [WFQ]) and best-effort (where RSVP does not reserve any bandwidth).
ip qos dscp default media rsvp-fail — This command specifies that DSCP should be rewritten if an RSVP reservation has failed. Specifically, this command strips the DSCP when RSVP fails in order to avoid overloading the defined queues. The result is best-effort media transmission for any calls that come in after the defined RSVP bandwidth has been exhausted.
ip qos policy-locator voice app AudioStream — This command tells the router to tag all generated voice traffic with the application ID of AudioStream for use with classification in RSVP policies.
ip qos defending-priority 1111 — This command specifies that an RSVP priority for calls matches across this dial peer. When no bandwidth is available, a call with a higher priority value can preempt an existing call that has a lower priority. This is useful in scenarios where you want to allow emergency calls to go through when a circuit may be saturated by lower-business-priority calls.
If a call is rejected due to RSVP for an SIP call, the call is rejected with a 580 Precondition Failed message. A call rejection due to lack of RSVP bandwidth is demonstrated in Example 8-30, with debug ccsip info and debug ccsip messages enabled.
Example 8-30 Debug Output During SIP Call Failure to Allocate RSVP Bandwidth
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/133120/sipSPIBwCacIsDi-
alPeerBwAvailable: bwcac NOP dial-peer bw available tag 102
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/critical/131072/sipSPIBwCacIsIn-
terfaceBwAvailable: bwcac no interface specified!!!!
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/131072/sipSPIBwCacVerifyB-
wThreshold: bwcac verify bw threshold, bw available allow call total bw 80000 bps
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/notify/133120/sipSPIGetCallQosSup-
ported: precondition tag needed in Require header
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/131073/sipSPIDoQoSNegotia-
tionWithMediaLine: QOS negotiation for mline_index 1
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/critical/131072/sipSPIDoStreamQoS-
Negotiation: Qos negotiation fails
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/critical/4096/ccsip_set_cc_cause_
for_spi_err: Categorized cause:49, category:184
Dec 5 05:15:19.419: //-1/xxxxxxxxxxxx/SIP/Info/verbose/4096/ccsip_set_release_
source_for_peer: ownCallId[2411], src[6]
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/4096/sipSPIContinueNewMsgIn-
vite: ccsip_api_call_setup_ind returned: SIP_PRE_CONDITION_FAIL_ERR
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/verbose/4096/sipSPIUaddCcbToTable:
Added to table. ccb=0x7F230DAB2510 key=1-8088@127.0.1.18FFE6D-38F balance 1
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/verbose/4096/sipSPIUaddccCallId-
ToTable: Adding call id 96B to table
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/verbose/4096/sipSPISendInviteRe-
sponse: Dialog State: [0]
Dec 5 05:15:19.419: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_create: cre-
ated msg=0x7F22BFE4A070 with refCount = 1
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/8192/Session-Timer/sipSTSLMain:
SE: 0;refresher:none peer refresher:none, flags:0, posted event:E_STSL_INVALID_PEER_EVENT, reason:4
Configured SE:1800, Configured Min-SE:1800
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/verbose/8192/sipSPIPresendProcess-
ing: Presend Processing called for 3 event
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/notify/4096/sipSPI_ipip_Get-
PassthruCopyListDataFromTdContainer: Could not get any elements from TD Container
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/notify/4096/sipSPI_ipip_Get-
PassthruCopyListDataFromTdContainer: Could not get any elements from TD Container
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/4096/sipSPISendInviteRe-
sponse: Associated container=0x7F22BF5469C8 to Invite Response 580
Dec 5 05:15:19.419: //-1/xxxxxxxxxxxx/SIP/Info/verbose/8192/sipSPIAppHandleContain-
erBody: sipSPIAppHandleContainerBody len 0
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/2048/sipSPIGetExtensionCfg:
SIP extension config:1, check sys cfg:1
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/info/2048/sipSPIGetExtensionCfg:
SIP extension config:1, check sys cfg:1
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Info/critical/512/sentErrResDisconnect-
ing: Sent an 3456XX Error Response
Dec 5 05:15:19.419: //2411/1F0354C0A5FD/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 580 Precondition Failed
Via: SIP/2.0/UDP 192.0.2.5:5061;branch=z9hG4bK-8088-1-0;received=192.0.2.50
From: Eleanor Rigby <sip:9195555150@192.0.2.5:5061>;tag=8088SIPpTag001
To: Mrs OLeary <sip:9195551234@192.0.2.10:5060>;tag=8FFE6D-38F
Date: Tue, 05 Dec 2017 05:15:19 GMT
Call-ID: 1-8088@192.0.2.5
CSeq: 1 INVITE
Allow-Events: telephone-event
Warning: 399 192.0.2.10 "QOS Negotiation Failure"
Reason: Q.850;cause=49
Server: Cisco-SIPGateway/IOS-15.5.3.S6
Content-Length: 0