Failing over to 2nd SIP trunk when 1st's channels all in use (503 Service Unavailable)

[Wayne Ficklin]

CUCM 11.5.1

CUCM =>SIP TRUNK1=>CUBE#1=>SIP Trunk to Service Provider

CUCM =>SIP TRUNK2=>CUBE#2=>SIP Trunk to Service Provider

SLRG:

-SP-RouteGroup:

--Trunk1

--Trunk2

We have a private circuit to SP connecting to CUBE#1.  The SP sends calls to us on this trunk first.

We route to SP connecting to CUBE#2 over the internet.  The SP sends calls to us on this trunk after the first one fills.

We use Circular Distribution outbound, mostly so I can see that both trunks are up.  There's about a 2:1 distribution of calls, because the SP is trying to fill up the first trunk before using the 2nd, ...and we're distributing calls outbound on both, ...relatively evenly.

Yesterday we started receiving 503 Service Unavailable on outbound calls because the first trunk was full.  I'd be happy to have assistance in configuring some sort of limit where it would fail over to the second trunk when the first one's full.

I know there's a "max-conn" statement that can be given on dial-peers on CUBE, but as I've got two dial-peers (inbound and outbound), I don't think that would take into consideration the two directions of calls on each trunk.

[Anthony Holloway]

I agree that setting the max connections on your dial-peer would not be good for the reason you gave.

I'm curious though, because by default, CUCM should see the called failed on the first path, and attempt the second path.

"When the system initially presents a call to a member of a route list, Cisco Unified Communications Manager reroutes for all cause codes other than Out of Bandwidth, User Busy, and Unallocated Number."
Source: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010000.html#CUCM_RF_RD813422_00

Can you show us the ladder diagram between CUCM > CUBE > ITSP?

[TONY SMITH]

Out of interest, what's your reason for separate inbound and outbound dial peers in this particular case?

[Wayne Ficklin]

I couldn't delete my comment.

[Anthony Holloway]

This is typically going to be the best approach, but not always. If for nothing else, for ease of operations (administration and troubleshooting). Do you typically combine your dial-peers (incoming/outgoing) into a single dial-peer?

[TONY SMITH]

"Do you typically combine your dial-peers (incoming/outgoing) into a single dial-peer?"

I've not yet come across a reason to separate them.  Obviously there are some settings that are only needed on an outbound DP and some only needed inbound, however they can be set in the same DP.   In general the settings needed for both directions would be the same values (codec choices, DTMF handling off the top of my head) so it makes sense to have them set in only one place.  So typically in a CUCM/CUBE configuration I'll have one DP for CUBE<->CUCM and one for CUBE<->ITSP.

Turning the question around, in what circumstances have you found a setting that needs to be different for inbound vs outbound, meaning you couldn't use the same DP?

[Anthony Holloway]

That's fair Tony. I think it's more along the lines of: Should you put a single Gateway in a Route Group and then in a Route List, or just put the Gateway on the Route Pattern. Both work just fine, but one is simpler to configure, at the expense of growth, while the other provides opportunity for growth, at the expense of extra configuration. To each, his own.

[TONY SMITH]

Cheers.  I think that's slightly different though as if you point a Route Pattern direct to a gateway you can't also have the GW in a Route Group, so seriously limit options further down the line.   What function or scale is lost by using the same dial peer for inbound and outbound call legs?  I still can't see any unless there's a setting that needs to be different.

[Anthony Holloway]

I cannot think of any hard requirements at the moment which would force you into separating your dial-peers. I could play the what-if game, but that's not productive. It's case by case, and to some degree personal preference. Like I said, to each his own.