Acme Packet 4500
 
Net-Net 3810
 
Acme Packet 3820
 

PLA-Support>Sun Systems>CommsGBU>Session Delivery Network>SN-SND: Acme Service Provider
 

In this Document

Goal

Solution

Applies to:

Goal

How to interpret SIP (session initiation protocol) response codes generated by the Session Director (SD).

Solution

Here are the most common response codes generated by the SD and various reasons for sending these responses. Please note that these are the responses generated by the SD and not by a next-hop server (where SD is acting as a back to back user agent). Most of these response codes are briefly described in RFC 3261, but this article provides a detailed explanation specific to the SD. These are some of the most common reasons and in many cases debug logs might be required to troubleshoot further and find the exact reason.


Request Failure 4xx
================

400 Bad Request:
The request could not be understood due to malformed syntax. For example; a missing call-id header in the request will generate this error.
SIP/2.0 400 Missing Call-ID


403 Forbidden:
The most common reason for this response from SD is due to the “allow-anonymous” value in the corresponding sip-interface where the request came from. Following are the configurable allow-anonymous parameters.

agents-only: Connections only allowed from configured session agents.

realm-prefix: Connections only allowed from addresses with the realm’s address prefix and
configured session agents.

registered: Connections allowed only from session agents and registered
endpoints. (For SIP only, a REGISTER is allowed for any endpoint.)

register-prefix: Connections allowed only from session agent and registered endpoints. (For SIP only,
a REGISTER is allowed for session agents and a matching realm prefix.)

all: All requests allowed.

For example, with allow-anonymous set to registered, when an un-registered endpoint tries to make a call, SD replies directly with a 403 Forbidden.


405 Method Not Allowed:
SD being a B2BUA will not generate this message unless the following configuration options are configured. These options restrict the SD to allow only certain methods and reject the method not configured under this option with a 405.

1.Under sip-config:

methods=INVITE,REGISTER,ACK,PRACK,INFO,UPDATE,REFER,CANCEL,BYE,NOTIFY

or

2.
sip-config using enforcement-profile.

SD(enforcement-profile)# name Reject-Options
SD(enforcement-profile)# allowed-methods INVITE,REGISTER,ACK,PRACK,INFO,UPDATE,REFER,CANCEL,BYE,NOTIFY

An OPTIONS request will be rejected by SD with 405 when either of the above is configured.

408 Request Timeout:
This message is generated by the SD on a request timeout. In most cases the request was forwarded to the next-hop server but there was no response and thus SD sends a 408 to the originator.

480 No Routes found:
Here are the most common reason for this response:

1. For registered endpoints, if the registration expired for the called-party and SD did not receive a new registration from the endpoint, 480 is sent when there is no local-policy or sip-nat to forward the request.

2. Even for peering traffic, 480 is sent when SD does not know how to route the request i.e., when there is no matching-local-policy or sip-nat.

481 Call/Transaction Does not Exist:
This status indicates that the UAS received a request that does not match any existing dialog or transaction on the SD.

482 Loop Detected:
This response is sent when a request gets looped inside the SD (most commonly due to a configuration problem). Debug sip logs are required in most cases to troubleshoot further.

483 Too Many hops:
The server received a request that contains a Max-Forwards header field with the value zero.

488 Invalid Session Description:
This message is generated when there is a problem with the SDP of the request. For example, incorrect content length.


Server Failure 5xx:
===============

500 Internal Server Error:
Most probably this is due to a configuration issue. Sometimes a corrupt configuration (even just one corrupt element) can cause this error. Debug logs will give exact info.


503 Service Unavailable:
There could be several reasons for this particular response. Here are the most common ones:

1.Not enough steering pool ports available for a call.

2.If the required bandwidth exceeds what is available for either endpoint. This is configured under max-bandwidth for the realm or through the call admission control feature.

3.High CPU utilization. When CPU utilization is above 90%, 503s are sent. “show proc cpu” command will give further information on current CPU utilization.

4.The next-hop server which is configured as a session-agent is out of service or unreachable. When ping-method is configured as OPTIONS/INFO under the session-agent and the session-agent is unable to respond to the OPTIONS/INFO message ge sent by the SD, SD retries several times before the transaction times out and the session-agent is marked OOS. In this re-try mechanism SD sends OPTIONS at 0 sec, .5 sec, 1 sec, 2 sec, 4 sec, 4 sec, 4 sec etc. until it reaches the “trans-expire” timer defined in the sip-configuration. In this above example 4 is equal to the max-timer in the sip-configuration. When the SA is marked OOS, any further INVITEs intended for this SA are responded with a 503 Service Unavailable message. The command “show sipd agents” will show this agent marked as “O” next to the ip-address

5.503 is generated when a session-agent exceeds the constraints configured. The session-agent is temporarily marked as OOS. The command “show sipd agents” will show this agent marked as “O” next to the ip-address.

6. If the session agent state is set to disabled the SBC will respond to all signaling messages directed to it with a 503.

session-agent
hostname 192.168.10.10
ip-address 192.168.10.10
port 5060
state disabled<---------------------


7.If SD reached the number of licensed sessions on the box. “show features” will show the number of licensed sessions on the SD along with licensed features. Compare this output with output of “show sessions” to verify if session limit is reached.

8.QOS is configured but not licensed.


513 Message Too large:
SD is unable to process the request because the message length exceeded its capabilities. If a request is larger than 1300 bytes SD will send this response. Per RFC 3261, if a message exceeds 1300 bytes it should be either sent using TCP or it should be fragmented. If the sip-config option +max-udp-length=0, instead of generating 513 message, SD will fragment messages >1300 bytes.

This solution has no attachment