Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Why is this working?

Why is this working?

Why is this working?

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?

RE: Why is this working?

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.

RE: Why is this working?

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

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?
Lop off another subdomain
Analyze as 1234@.net
analyze as 1234@ALL
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.
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 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 :)

RE: Why is this working?

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!!

RE: Why is this working?

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. :P

RE: Why is this working?

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.

RE: Why is this working?

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.

RE: Why is this working?

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.

RE: Why is this working?

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.

RE: Why is this working?


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.

RE: Why is this working?

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

RE: Why is this working?

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!

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close