Session Manager Digit Conversion Adapter
Quick article showing some uses for the Avaya Session Manager digit conversion adapter
If you have the opportunity to work with Avaya Session Manager (SM) then you've probably come across the adaptations menu within System Manager. The most commonly used adaptation is the digit conversion adapter.

The DigitConversionAdapter will modify SIP requests and SIP response messages as they flow in and out of SM. The adapter works on the following portions of a SIP message to adapt the

Request-URI
P-Asserted-Identity header
History-Info Header
SIP Notify message-summary body

The adaptation is done from SM's perspective and in 2 directions.
Ingress (on the way into SM before we make a routing decision)
Egress (on the way out of SM after we have made a routing decision)
In both directions we can manipulate digit patterns and matching digits to delete or add digits into the called or calling party numbers.

We can also modify the domain headers in our messages on the way into SM or out of SM depending on how our adaptation is configured.

Egress adaptation options

overrideDestinationDomain (abbreviated odstd): changes the domain shown in the
Request-URI
Notify/message-summary body with the value you type in for Egress (from SM) messages and responses only.

overrideSourceDomain (abbreviated osrcd): changes the domain in the
P-Asserted-Identity header
calling part of the History-Info header with the given value for egress only.

Ingress adaptation options

ingressOverrideDestinationDomain (abbreviated iodstd): changes the domain in
Request-URI
Notify/message-summary body with the value you type in for Ingress (to SM) messages and responses only.

ingressOverrideSourceDomain (abbreviated iodstd): changes the domain in the
P-Asserted-Identity header
calling part of the History-Info header with the value you input.

Example

Example

Here we have a Session Manager adaptation that we are going to use for an IP Office. We are going to take messages coming from the IP Office and change the domain in the Request URI (iodstd) and the P-Asserted-Identity (iodstd) and replace it with location1.company.com This means that our Session Manager will have to have this listed as one of its SIP domains in order to route the message. Our ingress adaptations modify the SIP headers BEFORE a routing decision is made.

We also have odstd set to an IP address, this is the IP address of the Avaya IP Office. So messages going to the IP Office will have the Request-URI overwritten with the IP address of the IP Office.

Digit Conversion
We can also strip digits coming into Session Manager and on the way out of Session Manager with the digit conversion adapter. Below is an example of stripping digits on the way out of Session Manager. This adaptation example is applied to our Communication Manager SIP entity.

Adaptation-Example

Here we are essentially saying any calls for the range +1555123 we want to take away the first 8 digits of the destination (called party number) before we send the call to Communication Manager. This is an egress adaptation because we are on the part of the page that says "Digit Conversion for Outgoing Calls from SM". Our Communication Manager system would be left with the last 4 digits of the called party number. This is a similar action that is normally performed on the incoming call handling table in Communication Manager. In Session Manager we are able to accomplish the same thing in a much cleaner fashion for the entire phone system without having to modify multiple incoming call handling tables.

Viewing adaptation action in traceSM
When using traceSM from Linux on our Session Manager servers we want to make sure we enable the Call Processing flag. Please remember that doing so is much more resource intensive so use this flag at your own risk.

traceSM

One we start our trace any Call Processing Messages will show up in a green background. This is essentially what Session Manager is thinking when it makes a decision. The green background messages are not actually representing any packets sent over the network but rather the routing logic of Session Manager in action.
Was this article helpful?
Cancel
Thank you!