Session Manager call routing 3

[fondog2]

Hello to all,
We have a 7.0 System/Session, 7.0 SBC and 7.0 CM. I am trying to determine how to route calls out specific trunks like I do with CM. We have all the configuration with entity links between CM. Now the biggest portion of this is we have a lot of location codes to get to different PBX's. We have over 50 PBX's so the first 3 digits are the location code and then the last four is the extension number. I have heard of domain based routing and port based routing but no one from Avaya can tell me how to configure my session manager to take an inbound call from my SBC and once it connects to my session manager point that call to trunk 25 of my CM. We have several TCP trunks and TLS but no matter what I do it points it to the first TLS trunk. It always follows the lowest TLS trunk as it is secure. If anyone can assist I would greatly appreciate it.

Thank you,

 

[mattKnight]

This document is a good start...

Yep it is titled best practice recommendations for Network regions

https://downloads.avaya.com/css/P8/...gglMAA&usg=AFQjCNHCZ6HWaBPStBHOyvyRkcMy6S5DAA

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[fondog2]

mattKight,
The link didn't work. I'll see if I can pull it from support.avaya.com.

Thank you,

 

[kyle555]

For starters, port based routing is bad. CM can have a maximum of 16 TLS connections for SIP signaling, and different ports use those up. That's to say 1 of those 16 connections per unique pair of source/dest IP/port
So, 1 CM, 1 SM, 16 TLS SIP signaling groups on ports 6061-6076 would max out your CM and you couldn't add any more SIP signaling groups UNLESS they were to that 1 SM and on the same pair of ports on both sides like 6061-6076. Conversely, 100 sig groups from 1 CM to 1 SM on port 5061 with subdomain tenant1.customer.com, tenant2.customer.com, etc would use 1 of the 16 connections. Also, bear in mind that SM doesn't care about your entity links. Look at a dial pattern and routing policy in there. It says "sip entity as destination" not "SIP entity link as destination" You don't get to tell SM to use TCP or TLS if for the 1 SIP entity you have both as entity links.

Is there any particular reason you'd want certain calls to go to trunk 25 in CM? Thinking out loud, it might sound like you've migrated from PRI to core SIP and are looking to keep that logical separation like you'd had before. Depending on your needs and how you want to subdivide your resources, that might make sense. Say, 25 locations used to have 100 trunks each and your SBC has 2500 now for them all and you want to to keep each location to no more than the 100 they're budgeted for.

The SBC can do that too if you look into URI groups and application rules. Basically, you can have a number map to server flow (go to SM) with an application rule (that defines max 10 or 20 sessions) and make different URIs for location 25 map to it. Maybe you want to go down that road, maybe you don't.

Still, that won't change the domain of incoming calls from the SBC. Your SBC has "server interworking profiles" that let you swap domain on the way out to the carrier or SM. But that won't subvdivide 25 ways either. Maybe having 25 internal subinterfaces on the SBC to SM and having SM use an adaptation for each. An adaptation can do a few things - like digit or domain manipulation like the SBCs interworking profile, but again, it's global to "everything from that SIP link" - so, no granularity to apply tenant1@customer.com if digits are 101xxxx.

As far as I know, CM's the only thing that can send a number to something at the same IP and port AND use a different domain based on what the dialed number was - to say, have 25 SIP sig groups to the same SM but with far-end domain tenant1.customer.com for the 101s, and tenant2.xxx for the 102s. I'm sure Breeze has a sequenced application that'd be trivial enough to write so that your calls would go SBC-->SM-->Breeze-->back to SM with the appropriate domain based on the numbering-->CM. But I don't think you have special Breeze applications.

So, you could (though I'm not sure I'd recommend rejigging your network this way) have all your incoming DIDs go through SM to CM to SM back to CM to work your domain in. CM could have (for our example of 25 locations x 100 trunks) 10 sig/trunk groups of 250 members at customer.com receive those numbers and insert a steering digit.

That steering digit could map to ARS and based on the ranges, send out to SM on each of 25 sig/trunk groups of 100 channels with domain tenant1.customer.com etc.
SM could have those domains set up and 25 dial patterns like this: "x" of min/max whatever your length is, @domain tenant1.customer.com, go to CM.
On CM, you'd have trunk 25 be tenant25.customer.com get the call.

Now, for this example, a rough trunk design would look like: sig/trunk 801-810 - the 255 member groups @customer.com.
Sig/trunk 701-725 each with 100 members to tenant1.customer.com all the way up. These trunks would never be in route patterns to send users calls out on, they'd just be for bouncing calls back to SM. That's why a steering digit would lead to them and why people wouldn't be dialing them normally.
Sig/trunk 601-625 would look exactly like 701-725 and those are the trunks the calls would come in on.

Now, it's important to know how CM picks which sig group to answer an incoming call on when it has many sig groups to the same SM. CM will use the lowest numbered signaling group that matches source/dest IP/port AND where the entirety of far-end domain fits in the invite it received. That means if all your subdomains end with customer.com and sig 1 is customer.com that CM would have sig group 1 steal everything because "customer.com" in sig 1's far end domain would match voicemail.tenant14.customer.com. That's why your most specific subdomains need the lowest numbered sig groups and your least specific the highest numbered.

So, my idea would satisfy your requirements until a site uses their 100 trunks. Once that happened, SM would still offer the call to CM, but 601 would be full, so the next available candidate is 701 which is the trunk you'd send out on to do the whole idea in the first place and you've mave a routing loop.
I suppose having 701-725 be outgoing only and not accept traffic would get around that, but 801-810 would still accept them afterwards.

You'd still need some high level steering digits to not break things. Say, on 10 digit DIDs SM pitches to CM the first time, have an adaptation that matches x min/max10 and insert 222 and send to CM. Trunk 801-810 have incoming call handling treatment match 222 min/max 13 and insert the AAR code. AAR 222 min/max 13 goes to your routes to 701-725 and those routes swap 222 for 333.

SM sends back to CM now. If 601-625 match 333 min/max13 and drop the 333 and 701-725 are outgoing only and 801-810 match 333 min/max 13 but replace to an announcement of a busy signal.

But, in the end, all of that is really gross to do and something I'd never recommend. I was just a little bored and figured I'd think the idea through to wherever it wound up. There are no shortage of poor design decisions out there based on people using CM because they know it best to make a solution do things that are handled more nicely at other layers. You've got call admission control in CM and SM and you've got the URI groups and application rules where you can easily manage "no more than X calls to this list of numbers". So, DON'T DO THIS but I hope you got something out of it as far as an understanding of what domain based routing can do.

So, what type of granular control are you looking to achieve across which applications? If you manage that many PBXs, careful with whatever you do because you will live with it forever!

 

[fondog2]

kyle555,
You answered my question. You can but it isn't worth the effort and Session Manager really isn't the "So called SIP PBX" they say it is. I was looking at this for back billing purposes. Outbound is not an issue but also wanted to be able to look at total calls to each site. When you have over 70,000 employees it makes it really challenging. I am really concerned with port based routing and why Avaya is recommending this as our solution. I think it will cause some issues down the road. On a separate issue considering you know the SBC as well and I'm new to it. How would I strip the end of a header off to pass to my service provider? They are seeing some additional info and it breaks the call down back to them. I was reading about server interworking and header manipulation but never added one so I'm very cautious. Sending you some stars on the previous response. Thanks again.

 

[Wanebo]

Session Manager isn't really meant to be a PBX. It's mainly a routing engine with various proxy functions also built in. It's actually quite powerful and versatile.

You can do some header manipulations in the Session Manager using the Routing Adaptations. There is actually a pretty good help file available if you surf to the Routing -> Adaptations page, you will see a Help link in the upper right corner. Select that and then select Administering Adaptations for an overview of what can be done.

Beyond that, you can also usually do what are known as Sigma scripts on an SBC. Sigma stands for Signal Manipulation and can allow you to change almost virtually any part of a SIP header.

The overall preference is to try to manipulate headers before or after they get to the SBC (using Session Manager) since while Sigma is quite powerful it can have unintended consequences to call flows that you might not intend to manipulate. Using Session Manager Adaptations allows control over individual entity links.

 

[kyle555]

All good, happy to help.

For billing, I'd say use a CDR solution and not count on trunk group reports. There's a new CDR service in the latest SBC release so it can at least push to a destination. If you're adventurous, pop it to a database.

Which headers are bugging your carrier? SM7 has more header stripping options for calls "out to a SBC" for that reason. The SBC's sigma scripts can do it as well. It's more flexible and complicated.

Lookup eRHdrs here

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