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 and the 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.

(screenshot needed)

Egress adaptation options

overrideDestinationDomain (abbreviated odstd): changes the domain shown in the Request-URI and 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, and 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 and 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 and calling part of the History-Info header with the value you input.

Example

Screenshot 2019-03-21 13.38.39

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.

Screenshot 2019-03-21 13.49.26

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.

Screenshot 2019-03-21 13.55.58

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.

Screenshot 2019-03-21 13.56.59