Acme Packet 4500
 

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

In this Document

Goal

Solution

Created from <SR 3-9223553211>

Applies to:

Goal

List of the RELAY and GENERATE supported responses by Acme Net Net 4500.
 

Solution

A "list of methods" is the appropriated answer. Although the SD is considered a B2BUA, it behaves much like a 'stateful proxy' as defined in section 16. of RFC 3261. For example:

-The SD will reply locally with a 100 Trying to a new dialog (Initial INVITE) but will not reply by default with 100 Trying to a ReINVITE unless configured to do so (sip-config -> options +reinvite-trying=yes ).

-The SD is also able to manipulate messages and responses via HMRs or response maps ) i.e change a 404 to a 503 response; if desired). It all depends on the state of the dialog and specific configuration choices.

The most common "response codes" generated by the Net-Net System and a possible reason why it has sent this response. Please note that these are the responses generated by the system and not by a next-hop server (where system is acting as a back-to-back user agent) If the output of show sip invite or show sip reg has the same number of 4xx or 5xx counted as received by the client as sent by the server, then this document doesn't apply. The Net-Net system is simply proxying these through the SBC (IE: the error is generated by another SIP server).

Most of these response codes are briefly described in RFC 3261 but this article gives a detailed explanation specific to the Acme Packet Net-Net family of products. 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 system 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, system replies directly with a 403 Forbidden.


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

01. Under sip-config:
methods=INVITE,REGISTER,ACK,PRACK,INFO,UPDATE,REFER,CANCEL,BYE,NOTIFY

or

02. sip-config using enforcement-profile.
system(enforcement-profile)# name Reject-Options
system(enforcement-profile)# allowed-methods INVITE,REGISTER,ACK,PRACK,INFO,UPDATE,REFER,CANCEL,BYE,NOTIFY

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

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

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

01. For registered endpoints, if the registration expired for the called-party and system 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.
02. Even for peering traffic, 480 is sent when system 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 system.

482 Loop Detected:
This response is sent when a request gets looped inside the system (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:

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

02. 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.

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

04. 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 system, system retries several times before the transaction times out and the session-agent is marked OOS. In this re-try mechanism system 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 sip agents” will show this agent marked as “O” next to the ip-address

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

06. 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<---------------------

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

08. QoS is configured but not licensed.

513 Message Too large:
system is unable to process the request because the message length exceeded its capabilities. If a request is larger than 1300 bytes system 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, system will fragment messages >1300 bytes.

 

This solution has no attachment