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 mydomain.com. 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.

Whew

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.

Related Articles:

Avaya Aura® Platform—The Original Pragmatic Hybrid Cloud

In a recent InfoWorld post David Linthicum wrote of “an organic movement driven by rank-and-file enterprise IT people who simply want to solve their issues using the best technology and approach.” Linthicum called this the “pragmatic hybrid cloud.” Reading this from the perspective of someone with decades of experience in the enterprise communications market, my immediate reactions was, “Aha, he’s talking about the Avaya Aura® Platform.” He isn’t, but here I’ll explain why this thought struck me.

Linthicum writes, “What this movement has discovered is that you can combine the public cloud and modernize some of your legacy systems to be more cloudlike.” That is exactly what Avaya customers have been achieving in an evolutionary process spanning almost two decades. Long before the term cloud came into vogue, Avaya customers have been able to gain the benefits of the cloud paradigm while avoiding the need to comprehensively lift workloads to a public cloud provider and the need to wholesale forklift and abandon existing investments.

Today, many Avaya customers—including a large swath of the globe’s most notable organizations in industries ranging from financial services, to healthcare, to government, and many small and medium businesses—process their mission-critical workloads using a combination of premise-based solutions and both public and private cloud-served applications. It is a “pragmatic hybrid” approach that since the mid-2000s has provided these Avaya customers with unparalleled reliability, cost savings, and business agility.

The Avaya Aura Platform is the reason why. Avaya Aura had its genesis in a time tested methodology for allowing geographically distributed organizations to link islands of resources to gain economies of scale. Back in the day, to create either a contact center that followed the sun or a single enterprise communications solution that served the needs of a worldwide workface, expensive dedicated circuits were required. As IP Telephony evolved, companies began to use packet-switched technologies to more cost-effectively link together distant resources into single holistic systems. Rather than centralized in isolated locations, communications applications could now be seamlessly and cost-effectively shared across distances. This made new ways to organize communication assets and the work that depended upon those resources possible.

Avaya’s great insight was to take advantage of the session initiation protocol (SIP). Over time Avaya’s customers have “pragmatically” converted the networking connections of their existing standalone investments to create fabrics of SIP internetworked appliances. The Avaya Aura® Session Manager lets companies treat their owned assets as part of a private cloud and combine those resources with public cloud capabilities both from Avaya and from a growing ecosystem of additional providers. It is a strategy that has resulted in significant cost savings while unleashing new innovation.

Today the Avaya Aura Platform has moved far beyond simply a “pragmatic hybrid” for sharing resources. It has become a strategic tool for many organizations. It gives companies a flexibility and agility to adapt and reconfigure at the speed of business. Avaya Aura has also opened the doors to both internal Avaya inventions and new external development.

Avaya Breeze™ Platform is but the latest application development platform that takes advantage of Avaya Aura. Avaya, Avaya’s customers, and an industry of third-party companies are leveraging Breeze with their own creativity for solving business problems. Breeze allows the creation of unique ways to leverage the inherent capabilities of Avaya products in combination with cloud and third-party capabilities. Whether those assets reside in a private data center, on premises-based servers, or in public clouds, because of the Avaya Aura Platform, the only barriers to progress are the limits of human ingenuity.

Linthicum concluded that, the “pragmatic approach is very sensible. It makes the most of what you have, reducing the need for new resources and letting you transition to the cloud at a pace you can handle, both in terms of cost and time.” Your Path, Your Pace, Your Choice, where have I heard that before? Avaya circa 2004 maybe? Nice to see the industry finally following Avaya’s lead.

 

Zang Serves Up a Special Delivery for Your Mom this Mother’s Day

Mother’s Day is the one day in the U.S. when the most phone calls are made. According to this cool Mother’s Day Facts site, 122 million calls are made to mothers on Mother’s Day in the United States alone. Considering there are only 85 million mothers in the U.S., Mom must be pretty busy taking calls from her multiple children, and Dad must be busy making reservations at the favorite family restaurant (Mother’s Day remains the top holiday for dining out).

To help make sure Mom gets that special call on Mother’s Day, Zang today announced a Zang-built service for those who 1) are multiple time zones away from mom (ie: military, working or studying abroad), 2) just want to send another thoughtful gift to Mom to let her know she’s loved, or 3) frankly, for those who have a track record for forgetting (you know who you are). With the Zang Forget Me Not service, anyone can record a voicemail for their mom before Mother’s Day, designate the date & time the voicemail should be sent, then receive a text confirming the voicemail was delivered. The new service was created using  cloud-based Zang Comms platform as a service, which allows anyone to create communication applications and services just like Forget Me Not.

How does it work, you ask? Simple. First go to www.zang.io/callmom and complete four short steps:

1)  Enter your telephone phone number
2)  Enter recipient’s telephone number
3)  Pick the time you would like the recording to be delivered
4)  Zang Forget Me Not service will then call your phone number for you to record, review and approve your message for delivery.

 

Go ahead—give it a try! It’s just one more surprise you can give Mom this Mother’s Day.

Next time you visit Dubai, take a public transport

With happiness being a key focus in Dubai, government agencies are looking towards contributing to the goal of raising the quality of life of customers and ensuring public happiness. These agencies are quickly realizing that the key to delivering a better and more personalized experience is technology. Using the latest services and solutions paves the way to guaranteed customer retention and loyalty.

One of the leading organizations in the area of customer care, winning multiple awards for its contact centre operations including a Hamdan bin Mohammed Smart Government Award, is the Roads & Transport Authority (RTA).

The RTA has a wide remit including Dubai’s Metro, public buses, private road vehicle registration, traffic management and more, so it has a diverse customer base negotiating Dubai’s busy transport system, with a volume of customer enquiries to match. It therefore comes as no surprise that the RTA is investing in multiple channels of communications with its customers, to improve standards of service, increase efficiency and gain valuable feedback from its user. It is also looking to technology to help improve the quality of interactions with clients and to improve overall levels of customer satisfaction and engagement. It has utilized a number of different solutions to increase its outreach to customers, and over time the focus of these efforts has evolved, to include voice communications, smart apps and multi-channel engagement.

From projects and operational perspective, RTA has a big focus on alternative smart channels. It offers 173 smart services under nine apps, that can help customers complete their transactions with a click of the finger through the automation of the main services the authority provides. It is dedicated to opening up more channels of communication, with an omni-channel strategy, that includes delivering services through channels such as self-service kiosks. At present the RTA has deployed around 16 kiosks, which offer smart services to users in RTA service centres, and in future it plans to have around 100 kiosks all over the city. The Authority has a well-established customer care line, which handles enquiries across the range of its activities, running on Avaya contact centre solutions. In 2015, the centre handled over 2.5 million calls, with over 80% of calls responded to in 20 seconds, and 90% of issues resolved in one call.

To make this possible, last year the contact centre underwent a major technology refresh, to put in place the latest generation of solutions. With Avaya Aura, RTA is now using the most recent software to increase the efficiency of the contact centre. With the aim to deliver the best possible interaction experience to transport customers, Avaya aligned with RTA’s Customer Resource Management strategy to consolidate channels and mediums into RTA’s first, best-in-class contact center to host multi-channel interactions. Among the capabilities that the new technology has enabled is an advanced Interactive Voice Response (IVR) system, which has helped to improve operations by automatically handling some of the more common customer enquiries. On New Year’s Eve the centre received some 12,000 calls, with the IVR handling one third of all enquiries.

The RTA is a pioneering example of how technology can make the difference in delivering quality to customers through the creation of a seamless and hassle free experience. As we share the RTA’s vision in excelling in customer experiences to achieve happiness, my advice to you is that, next time you visit Dubai, remember to take a  public transport.