Building a Resilient SIP Solution

I am the father of three boys. More accurately, I am the father of three men, since the oldest is 29 and the youngest is 22.

However, for most of their existence, they were boys and to me that meant years of worrying about broken bones, cuts, bruises, and much worse. They all came through adolescence and the teenage years in relatively good shape, but I spent more hours in emergency rooms and urgent care clinics than I care to think about.

I want to think that a lot of the reason why they survived into their twenties is that I was always insistent on doing things safely. They wore helmets when they snowboarded or rode their bikes.

Driving without seat belts was punishable by a denial of car privileges. While I wasn’t overbearing, I did my best to ensure that they understood the risks of their activities and took the proper precautions.

All of this leads me to what I want to write about today—risk management for SIP.

There are a number of places in a SIP infrastructure where things can go wrong. There are network elements that move SIP sessions in, out, and around your enterprise.

This article originally appeared on Andrew Prokop’s blog, SIP Adventures, and is reprinted with permission.

There are users who connect their SIP endpoints to that network. There are SIP servers that route sessions from place to place. There are trunks to and from your SIP carrier. Clearly, there are lots of places where things can wrong. Fortunately, there are just as many ways to ensure that things either don’t go wrong in the first place, or heal themselves as quickly as possible.

Network First

The quality of your SIP traffic is directly related to the quality of your network. Before I have anyone move to SIP, I insist on an assessment to ensure that all routers and switches are of a vintage that can handle real-time media and all are correctly configured. Don’t just trust that your network is ready to support quality-of-service. Go through the proper tests to make sure that all the I’s are dotted and the T’s are crossed. Believe me, it will be money well spent.

In terms of SIP and trunks, I highly recommend that you have multiple ingress and egress points. This may mean multiple MPLS drops to a single location. It may also mean having a primary circuit in your main data center and a backup circuit in a disaster recovery site. The important thing is to guarantee that if one connection drops there is another one ready to take over.

You may even want to consider multiple providers. For instance, you might want to use AT&T for your prime circuits and Verizon for your backup. This will complicate your dial plan, but the price of losing all call services might be worth the effort.

On the Border

The first line of SIP defense is your Session Border Controller (SBC). Every enterprise-grade SBC on the market today offers a high availability (HA) option. In an HA-SBC pair, one box runs in active mode, processing all incoming and outgoing SIP sessions. The second box is in standby mode, waiting to be told to take over that SIP traffic. There is a link between the two that keeps the standby box synchronized with the active box. This allows the standby box to hit the ground running whenever the main SBC dies. It knows everything that was occurring at the time of failure and all active sessions continue on as if nothing happened.

An important aspect of HA-SBCs today is that the active and standby modes must be connected by a Layer-2 network. This means that they must be on the same subnet. Since many primary and backup data centers only support Layer-3 between them, HA-SBC pairs cannot be geographically split. This doesn’t negate the need for HA, it simply means that HA can only be campus-based and the two boxes must be local to one another.

Session Management

Session management is what turns “SIP the protocol” into “SIP the architecture.” I’ve written extensively about session management (please see my articles, Session Management and Avaya Session Manager vs. Session Border Controller), but the main thing to understand here is that it loosely connects disparate SIP services, servers, and endpoints together to form a cohesive whole.

Unlike SBCs, Avaya Aura Session Manager supports HA in an active-active manner. This means that all Session Managers are active at all times and nothing runs in standby mode. Session Managers are grouped into communities where each member understands what the others in the community are doing. This facilitates a seamless failover if one of the members dies or is taken offline.

Another difference between the Aura Session Manager and a SBC is that Session Managers do not require a Layer-2 network between them. This allows an enterprise to spread Session Managers across the world and still maintain a single logical SIP solution.

The Endpoints

The last layer of resiliency resides with the endpoints. As I wrote about in “In the Beginning: SIP Registration,” SIP allows a single user to simultaneously register multiple devices. I always have at least two devices registered. When sitting at my desk, I take calls on my Avaya 9641 telephone, but those same calls will also ring One-X Mobile for iOS on my iPhone. It doesn’t matter if I am stationary or mobile. I never miss a call.

Lastly, Avaya telephones support something called SIP Outbound. This allows a single device to simultaneously register to multiple SIP servers. My 9641 can register to three different Session Managers at the same time (two in the core and one at the branch). If one goes down, I am already registered to a backup. This provides for a seamless failover with no dropped calls.

No Single Points of Failure

If you follow these guidelines, you will create a resilient SIP architecture with no single points of failure. I haven’t done the math, but I can easily envision five or six nines of availability. Remember, downtime is lost money, and who can afford that these days? So, like I always told my kids, wear your helmets and buckle up your seatbelts. No one wants to take their business to the emergency room.

Related Articles:

Learning to Work With Avaya Aura Session Manager Adaptations

The problem with standards is that they rarely are. Despite the fact that SIP has been around since the 1990s, is fairly well documented, and exists inside solutions from a variety of providers, there are still far too many situations where one vendor’s SIP has trouble speaking with another vendor’s SIP. Solution X might use the History-Info header while Solution Y is looking for the data in the Diversion header. Company A might love to use multipart MIME in their SIP message bodies—causing Company B’s softphone to go belly up.

In addition to these protocol mismatches, there are times when you need to reach into a SIP message and change the data. For instance, there may be instances where you need to change the domain in the FROM to something other than what the SIP client set it to.

This is where SIP adaptation comes in. Adaptation is the process of altering SIP packets to make the recipient see messages as they want (or need) to see them. Perhaps it’s as simple as the aforementioned domain name change, but it might be as complicated as adding new headers or removing existing ones.

If your Session Manager programming is a little rusty, you may want to start here: An Avaya Aura Session Manager Cookbook.

Adaptation is typically done by a SIP proxy that sits between two or more SIP endpoints. One such proxy is the Avaya Aura Session Manager (SM). As part of the process of creating routing rules for SIP messages, administrators define adaptations that are applied on the ingress and egress sides of SIP entities. SIP entities can be Avaya Communication Managers, Session Border Controllers, other SIP communications servers (CS1000, Cisco Call Manager, etc.) or a myriad of other forms of SIP servers.

Creating SM adaptations can range from very simple to extremely complex. The easiest adaptations are the ones that use the built-in modules that Avaya supplies and basic digit conversions. The most challenging adaptations require sophisticated SIP header manipulations and complex digit conversions. Thankfully, the tools that the Avaya Aura System Manager (SMGR) provides greatly simplifies the creation of both types.

To create an adaptation, log into SMGR and navigate to Home > Elements > Routing > Adaptations.

Avaya Aura 1

From this screen, press New to bring up a template to create your adaptation.

Name the adaptation and choose a Module Name. The Module Name dropdown list contains all the built-in Avaya adaptations. These include:

  • DigitConversionAdapter
  • AMSAdapter
  • AttAdapter
  • CS1000Adapter
  • CiscoAdapter
  • DiversionTypeAdapter
  • ModularMessagingAdapter
  • NortelAdapter
  • OrangeAdapter
  • VerizonAdapter

Several of these are fairly obvious. For example, if you are sending to and receiving from a Modular Messaging server, chose ModularMessagingAdapter. Others are less obvious and should only be used when instructed to by DevConnect implementation notes.

Avaya Aura 2

The most common adapter is DigitConversionAdapter, and unless instructed otherwise, it is the one you will typically use. This adapter allows you to manipulate digits (i.e. telephone numbers) that are sent to (ingress) SM and from (egress) SM. For example, if you are routing calls to an Avaya Communication Manager, you would choose DigitConversionAdapter.

Note that no matter what adapter module type you choose, you still have the ability to perform digit manipulation. In other words, an adapter such as CS1000Adapter allows you to perform CS1000-specific adaptations, as well as those provided by DigitConversionAdapter.

Next, you have the option of performing header manipulation on incoming and outgoing SIP messages. There are two ways of doing this, but one of those ways is a subset of the other and essentially unnecessary.

If SIP header manipulation is required, my preference is to always choose Name-Value Parameter from the Module Parameter Type dropdown. This allows you to create parameter/value tuples that direct SM to perform specific SIP header manipulation operations.

The choices for parameter types differ greatly between Aura version 7.0 and pre-7.0. Pre 7.0 gives you a few basic choices, while 7.0 greatly enhances your options.

I’ll start with Pre 7.0, but rather than trying to reproduce the list of choices, I will simply cut and paste from the Avaya documentation and help files.

Pre Aura 7.0

Supported adaptation module parameters are:

  • fromto: if set to true, the adaptation modifies the FROM and TO headers of the message. If omitted or set to any other value, FROM and TO headers will not be modified.
  • multipartMIMEsupported (can be abbreviated to MIME): (Optional): This adaptation applies to the egress processing only. If the parameter is present and set to no, then multipart MIME message bodies will be stripped on egress from Session Manager. If the multipart MIME message contains an SDP message body, it will be inserted as the only message body in the outgoing message. If omitted or set to any other value, message bodies will not be modified.

EGRESS Domain Modification Parameters:

  • overrideDestinationDomain (can be abbreviated to odstd): replaces the domain in REQUEST-URI, TO header (if administered), REFER-TO header, and NOTIFY/message-summary body with the given value for egress only.
  • overrideSourceDomain ( can be abbreviated to osrcd): replaces the domain in the FROM header (if administered), P-ASSERTED-IDENTITY header and calling part of the HISTORY-INFO header with the given value for egress only.

INGRESS Domain Modification Parameters:

  • ingressOverrideDestinationDomain (can be abbreviated to iodstd): replaces the domain in REQUEST-URI, TO header (if administered), and NOTIFY/message-summary body with the given value for ingress only.
  • ingressOverrideSourceDomain (can be abbreviated to iosrcd): replaces the domain in the FROM header (if administered), P-ASSERTED-IDENTITY header and calling part of the HISTORY-INFO header with the given value for ingress only.

EGRESS Display Name Modification:

  • egressDisplayName: In Session Manager 6.3.4 and later, the adaptation module modifies the display name of the CONTACT, P-ASSERTED-IDENTITY, and FROM/TO headers (if fromto = true).

For outgoing calls, adaptation is applied to the P-ASSERTED-IDENTITY, CONTACT, and FROM headers in both the initial dialog-creating request sent from the Session Manager and in all subsequent in-dialog requests.

For incoming calls, adaptation is applied to the P-ASSERTED-IDENTITY, CONTACT, and TO headers. If the value of the parameter contains spaces, the value must be enclosed in double quotes. Additionally, any double quotes that are part of the parameter value must be preceded by a backslash character.

Example values for the egressDisplayName parameter are:

  • egressDisplayName=SomeCallingName
  • egressDisplayName=”My Business”
  • egressDisplayName=”The \”Best\” Business”

The following screenshot demonstrates a set of parameters and values that instructs SM to change the domain name within outgoing calls to Since fromto is set to true, this includes the REQUEST-URI, TO header, REFER-TO header, and any NOTIFY/message-summary body.

Avaya Aura 3

Aura 7.0

Aura 7.0 allows you to use all of the previous options, plus quite a few new ones. As you will immediately see, 7.0 adaptations are much more flexible than those possible in previous releases. Again, this is almost a straight copy from the Avaya documentation.

  • adaptForeignURI: If the value is set to true, the ingress adaptation is applied to the Request-URI and the TO header (if fromto is set to true), even if the host part is an IP address that is different from the IP address of the Session Manager.
  • noidtmf: If the value is set to true, no DTMF message body conversion is performed on ingress.
  • dtmf: The value of this parameter determines the DTMF message body format that is desired on egress from the Session Manager. If omitted, no conversion is done. Supported values are nortel, relay, and dtmf.
  • keepPortTransport: If this parameter is present and set to any value, Session Manager does not strip the port and transport when the domain of the Request-URI is modified on egress.
  • noar: This parameter requires a comma-separated list of SIP response codes. This parameter is applicable to the egress adaptation only. You can use this parameter to override the default alternate routing behavior of Session Manager. Session Manager does not alternate route a request to the next SIP Entity if it receives one of the responses listed in the parameter value.

An example of a comma-separated list is noar = 404,486.

  • sessionTimeout: Use this parameter for SIP entities that do not support the session timer, as per RFC 4028, or to send periodic SIP messages to keep the session active for more than one hour. If both entities use the session timer in a call, Session Manager keeps the session active for the negotiated interval. If the entities do not use the session timer in a call, then Session Manager keeps the session active for one hour after the last SIP transaction. In such cases, you can set this parameter (in seconds) to extend the one hour interval. For example, if the session timer is not used, the parameter value of sessionTimeout=7200 makes the session stay in memory for 7200 seconds (120 minutes) after the last SIP message exchange.
  • noallow: This parameter requires a comma-separated list of SIP methods. The system strips the methods from the Allow header on egress. Method names are case-insensitive. For example, noallow=UPDATE and noallow=UPDATE, OPTIONS.
  • iRhdrs: Removes the specified header or headers during adaptation process from messages in the ingress direction. Separate multiple headers with a comma. For example, P-Charging-Vector, P-Location. Header names are case-insensitive. The administrator can remove the headers that Session Manager may add during post adaptation module invocation, for example, P-Location.
  • eRhdrs: Removes the specified header or headers during adaptation process from messages in the egress direction. Separate multiple headers with a comma. For example, P-Charging-Vector, P-Location. The administrator can remove the headers that Session Manager may add during post adaptation module invocation, for example, P-Location.
  • reduceRtHdrs: Intermediate Aura elements add routing headers when SIP messages move from one element to another. To reduce the number of routing headers values from the SIP message, use the reduceRtHdrs parameter.

If reduceRtHdrs is set to true, the system reduces the number of routing headers values, such as Via and Record-Route from SIP messages. However, all the outgoing messages from Session Manager will have the Via and Record-Route header with values of Session Manager IP and transport. This ensures that all the subsequent responses and requests for that call will be delivered back to Session Manager.

Digit Manipulation

Digit manipulation allows you to define rules that change telephone numbers as they enter and leave SM. This requires you to understand the specific requirements of the SIP entity the adaptation is applied to.

In general, I like to ensure that all numbers entering SM are converted to an E.164 format. This includes the +1 prefix.

For calls to Communication Manager, I convert numbers to E.164 without the + sign.

The following graphic shows a simplified view of that conversion:

Avaya Aura 4

When you’ve finished with an adaptation, apply it to the appropriate SIP Entity in Home > Routing > SIP Entities.


That was a lot of information, but I hope you found it useful. As a purist, I wish that the need for adaptation went away, but as a realist, I know that that’s probably never going to happen. Until then, the tools that System Manager provides allow you to seamlessly connect all kinds of SIP servers and be reasonably assured that they will happily coexist.

For more information, visit Andrew Prokop’s blog, SIP Adventures.