How Tandem SIP Calls be Routed to Different E1 Trunk Groups(TG)

[dianvaguar]

Avaya CM Extensions 5xxx and 6xxx were setup in collaboration with MsTeams App Extensions ranges 15xxx and 16xxx, respectively.

Currently, outbound calls from MsTeams extension range 15xxx, provides correct CLID 23005xxx via TG-1. But for MsTeams extension range 16xxx, CLID sent by public carrier is the default main DID number of TG-1 23005000. We need outbound calls to be routed to TG-2 to be able to send out correct CLID 24006xxx using tandem cpn table.

I am looking for a way for MsTean extentions 16xxx to utilize TG-2 to instead. Since all calls from MsTeans Cloud are through a SIP trunk with COR 1, Partition routing provides TG-1 only. I can change the COR number but this does not solve the problem. To further illustrate the calling scenario, see the flow of calls below:

CALL FLOW-1 (for 5xxx- This is OK):
MsTeams(15xxx) --> Session Manager --> SIPtrunk(COR1) --> ACM(Tandem CPN table) --> TG-1(E1-ISDN) --> PublicPhones(CLID displayed:23005xxx)

CALL FLOW-2 (for 6xxx- PSTN provided the Main DID number 23005000 as CLID):
MsTeams(16xxx) --> Session Manager --> SIPtrunk(COR1 --> ACM(Tandem CPN table) --> TG-1(E1-ISDN) --> PublicPhones(CLID displayed:23005000)
Note: The public career sends out the defaul main DID number 23005000 because the received CLI of 16xxx are not within valid DID range of TG-1. Calls from 6xxx should go throu TG-2.

Can anyone suggest a way to route tandem calls to specific trunk group based on the callers' CLID received on CM?
I am contemplating ANI based routing but couldn't find the right vector entries to do this goal. Hoping for your experts opinions. Thanks.

 

[bignose21]

I would imagine it is possible with regular expression adaptation in the SM if you collect the originating CLID into a variable and then in the action Modify the Request URI to add the originating CLID to the from of number, then based on that route the call

so incoming from teams

16000 calling +441234567890 after adaptation 16000441234567890
15000 calling +441234567890 after adaptation 15000441234567890

On the outbound adaptation to CM you could adapt this again to something more helpful for routing once it gets to the CM (recognise 16 delete 5 insert xxx)

I am no expert on Regular expression adaptation but there is a whitepaper here

https://support.avaya.com/css/public/documents/101060318

and videos on youtube etc.

 

[bignose21]

So did a bit of testing and managed to take a call in my lab coming into SM on sip The Originating is 11206 and destination +441234567890

Incoming Invite +441234567890@abc.com
To +441234567890@abc.com
From/Contact/PAI 11206@abc.com

Outgoing Invite 11206441234567890@abc.com
To +441234567890@abc.com
From/Contact/PAI 11206@abc.com

Regular Expression rule to do this would be on the Teams Endpoint

If its not clear

Variable name

ocli​

match expression

sips?.*)@.*​

Rule Action
Match

(sips?):\+(.*)@​

Replace

${1}:${ocli}${2}@​

You can now route base on the leading 15xxx/16xxx

 

[dianvaguar]

Hi @bignose21, Thank you for the insight. I've created the expression rule, but it seems that I am missing something. No change on dialed pattern. I added to Msteams SIP Entity the newly created Adaptive expression.

 

[bignose21]

It certainly worked for me, in the lab it was a call from IP Office sending +441234567890 from 11206 so my test route just to look at the Invites was

IP Office---SM---CM

In Elements\Session Manager\Global Settings I enabled "Enable Regular Expression Adaptations"
I created new Regular expression Adaptation called "IP Office"
I added an Incoming Adaptation Rule called "OCLI_add_TO_Header"
I added the Adaptation to the IP Office endpoint and as its just a lab it was the only adaptation against that endpoint

In the rule add a variable
Name ocli
service type Header
Source from
Instance top
match expression sips?.*)@.*

This should take the value from inside the brackets and add it to the variable "ocli" way it works is
sips? this will look for sip or sips
:
the brackets .* takes everything before the @

For the Rule
Source Type Request-Line
Source Request-URI
Instance blank
Operation modify
Match (sips?):\+(.*)@
Replace ${1}:${ocli}${2}@

So the above should match sip/sips and put it in variable 1 then because the :\+ is outside the bracket it is dropped the .* takes all the destination number into variable 2 and the @ is dropped
in the replace the format is <variable 1> :<variable ocli><variable 2>@

so if it was originally sip then the output should be sip:11206441234567890@domain.com

 

[bignose21]

Only other question is the invite coming in with a + on it, as that is what the regex is looking for.

 

[dianvaguar]

Thanks for the details. I really appreciate it. I still not able to focus on trying this out but the soon I get to it, I will update you. Regarding the +, I think we are not getting the + on the CLI as well as the dialed number.

 

[bignose21]

If there was no + on the dialled number then the match would change to

Source Type Request-Line
Source Request-URI
Instance blank
Operation modify
Match (sips?).*)@
Replace ${1}:${ocli}${2}@