Why is this working? 3

[RedTech443]

So I recently had a Sip integration from an Audio codes system with a MS Teams behind it going to Avaya Session Manager then to Avaya CM, also using a Avaya SBCE for outside telco calling.

I was able to get everything working but I am looking for a better understanding of why it is working and can it be more efficient.

In Communication Manager I have a Signaling and ip-network-region of #100 with authoritative domain name of sipiscool.net
All of existing phones on the network are in a domain of nonsipisboring.net

The AudioCodes SBC is sending its FQDN of iamaudiocodes.sbc.net
Without Adaptations I was unable to get anything to work, until I played with them to the point of just trial and error until it all worked not fully understanding what I did.

I added the following to the adaptations for the routing patterns and dial patterns coming in and out of Audiocodes.

I think I converted everything here from customer real domain names to my fake names, so this should be accurate.
Iodstd = nonsipisboring.net
Iosrcd = sipiscool.net
Odstd = nonsipisboring.net
Osrcd = nonsipisboring.net

The dial pattern is 9 min 1 max 36 goes out Avaya SBCE trunk, and any 4 digit in specified ranges go to Avaya CM over SM SIP trunk.
I feel like I am not doing something correct with the adaptations?

 

[RedTech443]

Forgot to mention, I am moving stations off the Avaya system and then adding them to the Teams side. Then pushing all calls to that extension over UDP / AAR routing patterns in Avaya for off system calling, will eventually be moving 500+ phones off Avaya to Teams.

 

[kyle555]

https://downloads.avaya.com/css/P8/documents/101038507

Start around p375

Your adaptations override source/dest domain for incoming messages - iosrcd iodstd and outgoing messages - osrcd odstd

Session Manager's routing algorithm is complicated.

Pretend you have:
dial pattern x for domain @nonsipisboring.net
dial pattern 1234 for domain ALL

If SM gets a request 1234@nonsipisboring.net, you matched x@nonsipisboring.net before you matched 1234@ALL- it tries to match the most explicit subdomain. It does domain matching before number matching.

Now, your SM entity REQUIRES a location. No other entities require a location, but can have one.

So, pretend you have location AvayaCore and Audiocodes and a 3rd location Teams and in that location for Teams you included IP pattern 10.10.10.0/24

Now go look in your dial pattern x@nonsipisboring.net. You'll see you can specify originating locations and routing policies.
So, pretend you had 100 Audiocodes MP112s with a copper trunk and this was your 911 dial pattern.
If it came from originating location with IP in Site 1, send to routing policy to audiocodes with copper trunk at site 1. From location Site 2, routing policy to site 2. You get the idea.

You'll see that when you select an originating location you can select the big check box to apply to ALL, or you can select the check box just below that selects each item in the originating locations. There is a big difference.

So, back to our original example.

Pretend you have:
dial pattern x for domain @nonsipisboring.net
dial pattern 1234 for domain ALL
AND pretend the audiocodes sip entity is defined as in 'location' audiocodes

In dial pattern x@nonsipisboring.net you have 1 entry for originating location ALL to use routing policy 1
In dial pattern 1234@ALL you have originating location audiocodes for policy 2.

1234@blablabla.nonsipisboring.net would now pick policy 2.

The rationale behind that is this:
SM will match on domain first. If it finds a match, it will look and see if there is a routing policy specified for your specific originating location. It will not look at originating location ALL yet. If it has a match for your location, it will use it. If it does not...

The next step is to lop off the most specific subdomain or your request and try again.

So, 1234@blablabla.nonsipisboring.net matches nothing. It analyzes as 1234@nonsipisboring.net. x@nonsipisboring.net is a better match than 1234@ALL
Is there a specific match in x@nonsipisboring.net for location Audiocodes?
No.
Lop off another subdomain
Analyze as 1234@.net
nothing
analyze as 1234@ALL
match!
Does that match include a defined routing policy from originating location Audiocodes. Yes. Use that.

If 1234@ALL only had an entry for location ALL and not each specific location selected, then SM would go back to step 1 and analyze 1234@blablabla.nonsipisboring.net.
Nothing
1234@nonsipisboring.net - match x@nonsipisboring.net
Now, the second time around after SM exhausted all options that tried finding a match with your location, it will now use the originating location ALL choice in x@nonsipisboring.net and use the policy defined there.
If on the second time around x@nonsipisboring.net only had originating location "potato" and nothing for ALL, then it would go up to 1234@.net again and to 1234@ALL and use the routing policy for location ALL as the last choice.

Every incoming call to SM must have a location.
If the location Teams with IP pattern 10.10.10.0/24 were defined, and a call came thru Audiocodes to SM, it would be assigned to location Teams. SM determines originating location in this order:

1. The Session Manager tries to match the IP address of the bottom-most VIA header of the received INVITE against the IP patterns on the Locations.
2. If no IP address match is found, the Session Manager uses the assigned location on the sending SIP Entity.
3. If no assigned Location is found, the Session Manager uses the assigned location of the Session Manager SIP Entity.


And that's how SM routing works

 

[RedTech443]

Wow nice write up Kyle, I am going to have to give this a good read later tonight and get back to you Thanks for this!!

 

[RedTech443]

Finally got around to reading this post Kyle, thanks again. Got everything working now the customer wants to get rid of all the Avaya stuff and go to the cloud.

 

[wpetilli]

For that actual design, is the audiocodes a requirement in between MS Teams and ASM? I want to dabble in something similar and have everything except that Audiocodes piece.

 

[RedTech443]

I do not think it is required, although I am not sure. It is needed to create the SIP trunk between teams and the Avaya Session Manager. I do not know much about the teams side so I am not completely sure on that either.

 

[kyle555]

I want to say yes. MS certifies only certain SBCs to put in front of their stuff. I'm sure you could find another SBC vendor that says they'll support you, but may or may not be on the MS official list.

 

[RedTech443]

Yeah I did read that now that I think of it, it needs to be an MS certified SBC in front of teams. I have only ever had to configure with a AudioCodes SBC on the other end so I know no other way to do it.

 

[kyle555]

https://docs.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers

I'd be interested how far you guys go with this and how your architecture is built.

Supposing you have 10 sites with a mix of Avaya and Teams, you could do some cool stuff to keep media local between users on a site or otherwise make the media flow the same whether you were on an Avaya softphone on a PC or a Teams one.

I'm thinking in a perfect world the Audiocodes, being considered private and not PSTN facing, wouldn't need to topology hide or do NAT, and could probably do media release/media unanchoring/shuffling/whatever you want to call it. You could probably do it with a single interface on the SBC - CCNA style 'router on a stick' exercise and just use the Audiocodes for the SIP manipulations and not the NAT/topology hiding.

 

[wpetilli]

That was my other question.. in our case Teams is part of O365 in the cloud and nothing on prem.

 

[kyle555]

Audiocodes has a lot of material on it. They seem to have this thing called OneVoice that must live in a cloud near MS that you can peer up with for your own carrier SIP trunks or possibly to your own SBC with an interface facing it on the internet.

That'd be a fun call flow...

Teams-->Avaya DN-->Audiocodes-->Internet-->Avaya SBC-->SM/CM

All the while exposing the network topology of contact and via headers and SDP. It might be possible in theory to keep a speech path local between a prem phone and Teams Online client, but that sounds like a discussion with an Audiocodes architect!