CM SM SBCE Location & Domain Routing

[AuraPS]

Hi

I am hoping there are some System/Session Manager experts who can recommend the best best way to set up trunks and routes out of our international Avaya platform. Our SIP trunk Provider is BT (GSIP) and we have 30+ locations around the globe routing in/out of our EMEA hub. This is a 50/50 load balanced delivery to our DCs in London and Frankfurt

At each DC we have a SBC-HA pair (2 total) and 2 x SMs (4 total)...(plus all the other Avaya stuff, lets just look at the SIP trunks)

From each site Location/network Region (NR) we need to send BT a PA-ID or Diversion Header with the identity number the originating location for billing and correct in country call routing (Automatic Number Identification - ANI). Any outbound presented CLI/CPN is taken from the FROM header.

Question - What's the easiest way to always present a fixed 'site ID number' (ANI) so that it appears in the PA-ID or Diversion header but at the same time have the ability to apply any CLI (CPN) presentation(or withold) as per the PUB-UNK table (shown in the FROM header)

We have been told by our business partner that we can put the 'site ID number' in the sig group domain name, i.e. london.442031234500.company.com and this can be extracted on the SBC and added to the diversion header via a script.
This is all well and good but each site will need 4 x O/B trunk (sig) groups so that there is SM redundancy... 4 x 30 sites is a lot of trunk groups for outbound calls.

I wanted to know if there was an easier way to do this. For example can the PA-ID header be manipulated based on the location the call has come from, (assume I have set up the SM Locations and IP ranges to match the CM NR map). I am sure this is doable in SM adaptations but not sure how it would look, were can I get a guide on adaptations and the values/syntax that can be applied

i.e. Can the contact header 'Contact: Test-123400 sip<123400@192.168.10.55:5061;transport=tls>' be looked at and based on an IP subnet, then amend the PA-ID header

so if contact = xxxxx@192.168.10.* make the PA-ID header 442031234500@company.com


Any pointers greatly appreciated

 

[kyle555]

OK, so Adaptations in SM can change some headers, but that's based on an 'entity' on ingress or egress - so unless you have 30 SIP entities on 30 ports from SM to SBC, you can't have 30 different adaptations outward.

Out of CM, you'll send your Public Unknown Numbering table match out as FROM and PAI. Does your carrier require PAI to be a single billing number per location? Or do they allow ANY number/DID from site 1 outward as a PAI? If the latter, and if you're happy to have everyone send a DID - either their own direct number or the main number of their office, then just use the public unknown table and you don't have to care.

Otherwise, if you have access to support.avaya.com, read this 5 times over and commit it to memory:

https://support.avaya.com/ext/index?page=content&id=ADMN112557

If you have root domain customer.com and subdomains site1.customer.com, site2.customer.com, etc.

A SIP URI of 1234@site1.customer.com is analyzed against all dial patterns "@site1.customer.com" first.
If a match is found FOR THE SPECIFIC LOCATION, then use it. It will not yet match for "ALL" locations. That's the difference in SM when building a dial pattern if you click the box ALL vs click the box that ticks each box for each location.
If there is no match @site1.customer.com in the specific location, try again @customer.com - if there is a match in the specific location, then use it. Don't use a match in ALL yet.
If no match was found @customer.com, go back to the start @site1.customer.com, but accept and use a match for ALL locations.
If no match was found @site1.customer.com for location ALL, go up a level to @customer.com and check for location ALL

That being said, if you had all 30 subdomains spelled out, and if you only had matches @customer.com, SM would still pass thru 1234@site1.customer.com to the SBC as a match
You could then have your sigma script trigger on 'site1.customer.com' and insert the required number for PAI and let CM's pub table set your CLID in the FROM header.

 

[AuraPS]

Hi Kyle,

This makes sense and is in line with what is being recommended by our BP. We either have to have a lot of entities (for adaptations) or lots of Sig groups with sub-domains that can be manipulated on the SBCE script.

I still need to set up 4 x sig groups for each site to handle SM redundancy...... It would be a handy feature on CM if on a SIP signalling group we could just list the order or SM's we want to connect to

Thanks again for taking the time

 

[kyle555]

That's in CM8

If you're otherwise going to be pitching PSTN numbers out of CM all the time for ARS calls anyway, you could probably just have a clever sigma script - if URI.User +44*, then buddy is from UK, so PAI=+44ENGLAND-BILLING-NUMBER

All these SM routing constructs are fun and interesting. And yes, it can absolutely accomplish what you're looking for.

Now, if the endgame is "CM trunk to PSTN goes to SM goes to SBC goes to same carrier anyway" and all you're looking for is using one of 30 known PAIs depending on calling party number, you can put that all in at the SBC headend in 1 script. As long as you understand the limitations that you *didn't* program all those layers in, you know what you're up against.

Actually, I think the sigma script might be the only way depending on what use cases you might want to support.

So, curveball!
Mobile users. I go from London (site1) to Paris (site2). I'll have my London number dialing from an IP in the network map in Paris. I'll pick a trunk/sig group going out @site2.customer.com.
Does the public table say "when kyle's +44 extension goes out a public numbering call on ALL trunks, then..." or "when Kyle's +44 extension goes out trunk 1 with sig 1 @site1.customer.com"
Do you want the user from London visiting Paris to get PAI assigned based on their IP/network region/location/far end domain so that all my calls from my London number get the Paris PAI because @site2.customer.com? Wouldn't that make any visiting user's calls to their normal local calling area be international if you put the Paris PAI in a call FROM +44....?

Then, what about remote workers? Would you ever have a use case for them? Perhaps a dedicated public IP for registering SIP server remoteworkerSite1.customer.com, etc, would let you map an internal IP to each site for remote workers to be able to follow along and peel their outgoing calls out their home location's PAI for billing purposes?

Heck, why not go balls to the wall on toll avoidance and set PAI based on DIALED number. Who cares if I'm in London or Paris - if I'm calling France +33 from +44 and you have a BTN in +33, why not call TO +33 FROM +44 with PAI +33 and keep the long distance down?

 

[redphone]

The BT requirement sounds a lot like Verizon's unscreened ANI feature.


An SM Adaptation toward the SBC with a "VerizonAdaptor" module assigned can use the digit conversion table to add Diversion headers with values entered in the Adaptation Data fields. This would require unique CPN's based on location, as the digit conversion mapping is done based on the PAI sent from CM. This App Note shows an example adaptation with a Diversion header created using the Adaptation Data field, pg. 34.

I am not sure if this would work for your situation, but something to keep in mind.