Session Manager Adaptations Best Practices

3 Steps to help you understand how SM Adaptations work.

Session Manager Adaptations by Wellington Paez

Session Manager Adaptations Best Practices

3 Steps to help you understand how SM Adaptations work.

By the end of this post “Session Manager Adaptations Best Practices” learn how these modules help the System Administrator configure digit manipulation and update any SIP Messages allowing connected Servers understand the SIP traffic, or to match any Server’s Provider requested information from our Avaya Core Servers in order to allow the completion of the call.

Recently I was helping one of our clients integrate their IVR System to the Avaya Core (Session Manager and Communications Manager). The challenge was getting both servers syncing and understand each dialing properties information. the following are the three steps that helped me accomplish this task:

  • 1.- Understand Existing Conditions
  • 2.- Update and configure
  • 3.- Test and go live

1.- Understand Existing Conditions

This particular customer had already created the basic modules and elements in Session Manager. His problem was routing the calls to a specific Route Pattern through its Routing Policy to the Entity Link created for the IVR.

Calls were getting a “404 Not Found – Route Not available” whenever calls were placed from the IVR. This is a common mistake when integrating multiple servers and routing calls with different conditions. As you know Session Manager it is a Proxy Server which makes route decisions based on Routing Policies, and load balances, and prioritize similar Route Parents based on weight.

By running TraceSM with “Call Processing” enabled, you can see every step of the call, to help you understand if there is anything missing along the way. In my case, the call was choosing the wrong dialing Dial Pattern.

2.- Update and configure

Once the Route Pattern was created to route from its Originating Location (IVR) using its designed Routing Policy through CM’s trunks, calls were almost placed. The Problem was related to the digits sent from the IVR to CM. There is when an Adaptation was added to the SIP Entity.

Session Manager Adaptations – A Digit Conversion Adaptation was created to modify digits sent from the IVR to CM by applying the Route Pattern, Routing Policy and Entity Links to allow these calls by matching the following variables=

Module Parameter Type – This should be set to “Name-Value Parameter” to let you type the words “fromto”, “iodstd”, and “iosrcd”.

The “fromto=true” Module Parameter it is use to modify the SIP Headers “From and To”.

The Adaptation is also using the Ingress Override Destination Domain (iodst) to be replaced with “localdomain.com” in the REQUEST URI as well as the NOTIFY on Ingress.

Ingress Override Source Domain (iosrcd) is applied here to replace the FROM SIP Headers with “localdomain.com” if the PAI is requested from the IVR.

After you have altered how the SIP Messages are being exchanged, it is time to work on your Session Manager Adaptation Digit Manipulation by configuring the “Digit Conversion for Incoming Calls to SM” with Matching Pattern= x, minimum and maximum digits= 10 (this is the total number presented to SM), Delete Digits= 0, Insert Digit= +1 ( E.164 Dialing Plan), and for this example “both” direction was used.

The last portion of the Session Manager Adaptation is configuring the Outbound Calls from SM by matching “+1”, with Minimum and Maximum digits= 12, Deleting= 2, and finally Address to Modify= both.

For some SIP Integration you may want to use the Verizon Adaptation to do any PAI modifications needed for outgoing calls from SM. This Adapter lets send information needed to allow EC-500 Calls and RFCs.

“Some providers won’t recognized the Calling Number and will reject the call”

3.- Test and go live

While troubleshooting I made the mistake of removing the SIP Entity associated with this particular IVR causing a 407 Proxy Authentication Required “Host Not Trusted”. I then quickly restored Both SIP Entities 1= Local SM and 2= IVR’s Entity Link. Both using trusted UDP ports 5060. Calls were successful once the Route Pattern was updated with the correct locations, Entity Links and Routing Policies.

I suggest that you align anyone responsible, including different vendors to test at once. This helps you change any parameters, and find out if something won’t sync well with the other servers.

How about you? – How do you use System Manager Adaptations?

Please note: I reserve the right to delete comments that are offensive or off-topic.