Mark Holloway

In most cases a SIP Redirect Server simply responds to a SIP Invite with a 302 Moved Temp message and provides multiple contacts in the Contact Header.  When this occurs, the device receiving the 302 Moved Temp message (such as an Acme Packet SBC) will attempt to contact (ie. send a SIP Invite) the first address in the Contact Header.  If that fails, it will send a SIP Invite to the next address, and if that fails, the process will continue until there are no more addresses remaining.  Although this provides some form of redundancy it is not necessarily the best approach. Utilizing call flow this way means there is no control over how calls could potentially be load balanced if desired (or required).  Also, if one of the devices in the Contact Header is offline, there is no knowledge of this by the SBC and it will continue to send SIP Invites regardless and wait for the timers to expire. Definitely a less than desirable behavior.  The last item to note is that if you need to send SIP Invites to a potentially large group of servers (20 or more) there is a chance the Contact Header will become so large this is going to cause the SIP message to become fragmented.  All of these pitfalls may be easily avoided.

The Acme Packet SBC has a feature called sag-lookup-on-redirect. Simply put, the Redirect Server provides just one address in the Contact Header and the SBC will match that to a Session Agent Group in its configuration.  The result is calls may be load balanced (Hunt, Round Robin, Least Utilized, Least Busy, Proportional Distribution) and the SBC has the benefit of knowing when a target address (Session Agent) is alive and healthy which means it is in-service, or if the target is offline or unhealthy and therefore the SBC demotes it to an out-of-service state.  When a Session Agent is in an out-of-service state the SBC will not to send SIP Invites to that particular destination.

The feature sag-lookup-on-redirect is enabled through sip-config.

PHOENIX# configure terminal
PHOENIX(configure)# session-router
PHOENIX(session-router)# sip-config
PHOENIX(sip-config)# sag-lookup-on-redirect enabled
PHOENIX(sip-config)# done

In order for the SBC to pro-actively determine if a Session Agent is in-service or out-of-service, configure OPTIONS ping for each Session Agent.

session-agent
…
ping-method                     OPTIONS;hops=0
ping-interval                      60
ping-send-mode                 keep-alive

To view what Session Agents are in-service execute the following command:

PHOENIX# show sipd agents

Now, when the SBC receives a 302 Moved Temp message it will load balance based on the chosen scheme.  If any Session Agents are out of service the SBC will not attempt to send a SIP Invite.  The SBC waits until three successful OPTIONS pings are received before declaring an agent in service again.  This is great as it helps prevent an endpoint from flapping on the network.

Answer to Seizure Ratio (ASR) is a term used in Telecommunications and helps determine when new call setup attempt should be routed to an alternate destination. The definition of ASR is the number of successfully answered calls divided by the total number of calls attempted (seizures) multiplied by 100. The formula is (Answer / Seizure) * 100 = AnswerSeizureRatio.

Normally when an SBC initiates a SIP Invite to a peer and receives a SIP 503 Service Unavailable message in return the SBC will attempt another call setup to a secondary destination (Session Agent) automatically.  However, using an example such as busy signals, they not considered “failures” by a SIP device, yet there could be an upstream outage somewhere causing an unexplained amount of SIP 600 Busy messages being returned that is starving the Telecom network from completing calls. Since the Acme Packet SBC has the ability to route based on a configured ASR threshold, call may easily be routed to another destination if the configured ASR value falls below a specified threshold. Nice!

The place to configure ASR is within a Session Agent.  By defining a minimum (acceptable) ASR value, the SBC computes ASR as it makes routing decisions.  Using the formula first mentioned above, the SBC is calculating the number of successfully answered calls on a Session Agent and dividing by the total number of calls attempted. If the ASR constraints are exceeded, the Session Agent goes out of service for a configurable period of time and all traffic is routed to a secondary Session Agent (via a Local Policy which has the same Next-Hop but with a higher cost).

The two ASR parameters within a Session Agent are minimum seizure and minimum ASR.

Minimum Seizure determines if the Session Agent is within it’s normal constraints. For example, if 5 call attempts (seizures) have been made to a Session Agent and none have been answered, and the min seizures is set to 5, then on the 6th failed attempt the Session Agent will be marked as having exceeded its constraints and will be marked out of service.

Minimum ASR is considered when making routing decisions. If some or all of the calls to the Session Agent have been answered, the min ASR value is considered to make the routing decision. For example, if you set the Minimum ASR to 50% and the Session Agent’s ASR for that window falls below 50%, the Session Agent is marked as having exceeded its constraints and calls will not be routed to it until the time-to-resume has elapsed.

The time-to-resume element tells the SBC how long (in seconds) a Session Agent should be considered out of service once constraints have been exceeded.

Possible values for min-seizures range from 1 to 999999999. The default value is 5.

Possible percentage values for min-asr range from 0 to 100. The default is set to 0.

Networks where two or more egress paths exist on the VoIP network should consider using ASR based routing to provide the greatest level of network availability during a potential network congestion-outage related issue.

The packet-trace command allows the Acme Packet SBC (Session Director) to capture SIP signaling communication between two endpoints and send the capture to external server such as Wireshark.The SBC uses the network interfaces (ie. media interfaces) to send the capture.  The wancom management interface is not supported in this case.

The first step is to configure a capture receiver.  This tells the SBC what interface is used for the mirrored packets and the target IP of the Wireshark server. The network-interface is the SBC’s network-interface and sub-port ID.

The next step is to identify what IP and ports the SBC should listen to in order to send the packets to Wireshark. If no ports are identified then the SBC listens on all ports.

Even though it is not required to specify the local and remote TCP/UDP ports  it’s always a good idea to be as specific as possible when defining captures so only the required data is captured. At this point any calls coming into the SBC that involve the IP 217.154.63.10 on TCP or UDP port 5060 are going to trigger the capture and packets will be sent to Wireshark. Sixteen concurrent traces can be running at once.

One thing to note is the capture is sent to Wireshark using RFC 2003 (IP to IP encapsulation) as opposed to relaying SIP on port 5060. This means Wireshark needs to be configured to listen for RFC 2003 packets and then it will decode them. Use the ip.src filter to display only the encapsulated SIP packets.

The alarm-threshold command gives the Acme Packet SBC the ability to send minor, major, or critical alarms when CPU, Memory, Rfactor, Space (/ramdrv), and Session count reach a specific threshold based on % usage. Each element is monitored individually so the alarm is sent only for the violating element. Setting these values is a great step towards monitoring your network for health and capacity.

In the following example the SBC is being configured through the ACLI to monitor the number of simultaneous Sessions and will send a major alarm when the SBC is using 75% of its session capacity.  For example, if this SBC supports 16,000 sessions and 12,000 sessions are currently in use, the SBC will send a major alarm to the configured SNMP trap-receiver.

Adding the alarm-threshold settings to your configuration is essential to following Acme Packet’s Best Current Practice for the platform.

QoS based Routing is a feature of the Acme Packet SBC (Session Director) that pro-actively observes and measures RTP quality on a given network path (realm) by using R-Factor (QoS measurement) to determine if quality is acceptable. If the R-Factor falls below a certain threshold then new calls are re-routed on another network path using a different realm. This works for both inbound and outbound calls.

The example diagrams show calls being received inbound from an ITSP. It is common for customers to deploy multiple SBC’s in different physical locations for geographic redundancy. Most people think of redundancy and failover occurring when the network is completely down or unreachable, but another factor to consider is a network condition where route flapping, DoS attacks on a router, or bad cabling play a role in an outage and there is intermittent network connectivity. In many cases having intermittent connectivity is actually worse than the network being completely unreachable. For example, if a SIP Invite is successfully setup, yet within seconds the network experiences flapping, the RTP traffic will be lost momentarily. This is where QoS based Routing can save the day.

This first diagram displays a primary and secondary SBC with two SIP paths from an ITSP to the customer’s network. In this case there is no service disruption occurring.

The next diagram shows the primary site being physically unreachable (down hard). The SIP Invite from the ITSP to the primary site will time-out which then causes the ITSP to send a SIP Invite to the second site.

The third diagram provides an example of SIP signaling when the SBC at the primary location is detecting an R-Factor score below the configured threshold. The SBC pro-actively knows the link is experiencing poor quality and returns a SIP 503 Service Unavailable to the ITSP which forces the ITSP to send a SIP Invite to the secondary site.

In order to utilize QoS based Routing on the SBC it requires the qos-enable value to be set to enabled under media-manager/realm-config. QoS based Routing uses R-Factor to measure quality on a per-realm basis to either cut back the traffic allowed through a realm or alternatively shut down all traffic on that realm.

When configuring QoS constraints per realm there are two categories: major and critical. The constraints set in the major category rejects a certain percentage of calls with a SIP 503 Service Unavailable message. The percentage value is configurable by the user using the call-load-reduction context entry with a value between 0 and 100 (0 represents no call reduction and 100 represents all calls rejected). Calls originating on the customer’s network towards the ITSP will automatically use another realm if there are other routes configured on the customer’s SBC, otherwise calls will be rejected if there are no alternative routes. The critical behavior functions very similar to major, however the user may specify when calls should resume on the realm based on a time-to-resume value which tells the SBC to wait until the R-Factor has achieved acceptable performance for a specific period of time.