Route Outbound calls 50/50 via SMGR - can it be done?

[learningSkype]

All, we currently use AT&T for all of our outbound calling. we have a CM that sends calls to SMGR and then SMGR routes those calls to an SBC that has AT&T SIP trunks to the outside world (PSTN).

we want to disconnect AT&T and route outbound calls over 2 new SIP circuits, specifically with Lumen and Verizon. I know that I can take a Dial Pattern and send calls out over a specific carrier via a Routing Policy or I can change an Adaptation to send all outbound calls, etc., but I don't know if you can split calls out to 2 different carriers using SMGR dial patterns or Adaptations.

is there a way to split traffic 50/50 so that every outbound call hits Lumen first, then the next uses Verizon? is that even possible to do in SMGR?

Last question, does an Adaptation or a Dial pattern have precedence for outbound calling? I always thought that Dial Patterns were for inbound calls while Adaptations were for outbound calling, but I know you can use them interchangeably. which one takes precedence or is of higher importance?

 

[bignose21]

SMGR doesn't do traffic routing etc. so guess you are sending it to a Session Manager (SM). If you assign two Routing policies with the same rank to the dial pattern it would share the traffic.

Adaptations are manipulations on the way in/out of the Session manager, the dial pattern is the digits to recognise in the SM so a really simplified view would be:

endpoint A --- inbound adaptation for module assigned to endpoint A --- Dial Pattern --- Routing Policy --- Outbound Adaptation for module assigned to endpoint B --- endpoint B

 

[learningSkype]

correct, all the traffic is going to a Session Manager. can you add more detail to the Outbound Adaptation outline that you made above?

 

[kyle555]

I wouldn't do 2 routing policies.

I'd use Local Host Name Resolution.

In Session Manager-->Network Config-->LHNR, you make a bogus fqdn list carrier.pstn with one IP to Verizon and the other to Lumen. They have priorities and weights. If they're both priority 100 and weight 50, then that's the result you'll get.

You'd then need just a single sip entity to carrier.pstn and entity links from each SM to carrier.pstn which SM would actually make to both carrier IPs.

Cleaner routing and you can do 3 carriers 33% each or whatever else you want.

It's probably doable on the SBC too but I can't/don't want to think about it right now.

Why do you want to do that anyway?

I'm thinking you might have some fun if it's like "the DID comes in Verizon, went to voicemail, and the guy 0d out to the cell and there's no ringback when it goes out Lumen"

Or "when a call comes in Lumen to Experience Portal to 0 to an agent who transfers externally to Timbuktu there's dead air sometimes. Never on Verizon and sometimes on Lumen"

Out of curiosity, is there some cost consideration where it's cheaper to, for example, stay under 100 trunks on each of Verizon and Lumen vs staying under 200 trunks on Verizon and Lumen as a backup or whatever?

Could there be a better segmentation along lines of business to poitn half your DIDs at Verizon and have those users - sales for example - always dial out verizon and have support DIDs come in Lumen and dial out of Lumen? You could probably gain efficiencies on transfer scenarios and release 2 trunks if you've transferred a Lumen inbound to the PSTN via Lumen rather than tying up a Lumen inbound and Verizon outbound.
You could still have outbound for sales failover to Lumen if Verizon's down and vice versa

 

[bignose21]

For the adaptation question it depends what you are using it for, could be and internal dial plan getting changed to full e164 before being sent over to the SBC, we still have some CS1000 so it can be used to maintain the SRI URI mapping for CS1000.

example
inbound Adaptation with CS1000 adaptor recognises udp.cdp and prefixes 555 to both numbers (Session manager routing doesn't see SIP URI), dial pattern recognises 555xxxx and routes to another CS1000, the outbound adaptation deletes the 555 and adds the cdp.udp SIP URI back.

or if you had some sort of internal dialplan 3 digit location and 4 digit DN, when the call routes to the SBC the outbound Adaptation might be used to remove the location and make the number up to a full e164