Two SIP trunks from the same ITSP terminated on the same CUBE ENT HA

[umutyasar]

Hi All,

We have a Cube HA deployment with 1 sip trunk. I have configured one inbound and one outbound dial-peer to the same sip trunk and it's working fine.

We want to add 2nd sip trunk from the same ITSP. I plan to add second inbound and outbound dial peers for the second sip trunk.

Can we achieve this without changing the cucm config only change cube config?

Are below design scenarios achievable and what is the best one for it? Or do you recommend another design?

1-Using both sip trunks for different Internal number range?

For example 02xxx, 03xxx use sip trunk 1 and 04xxx, 05xxx use sip trunk 2?

2-Using one sip trunk at a time like active/standby. I can use preference for choosing active sip trunk and the outbound dial-peer for the outbound calls. But how can i choose same sip trunk be active for the inbound calls as well for the inbound dial peer?

[TONY SMITH]

I think I'd prefer to have one as first preference for inbound calls, and one first preference for outbound.  Inbound call preference will be dictated by the ITSP, you would have to tell them which calls to route to which trunk, and what to do in a failure or overflow situation. 

[umutyasar]

Thanks for your reply Tony.

Do you mean to choose Trunk1 for incoming calls and Trunk2 for outgoing calls?

Also can you please explain what options they have to do in a failure or overflow situation?

Is it like this: route inbound calls to Trunk1, in failure or overflow route them to Trunk2.

[TONY SMITH · Accepted solution]

---

@umutyasar wrote:

Thanks for your reply Tony.

Do you mean to choose Trunk1 for incoming calls and Trunk2 for outgoing calls?

Also can you please explain what options they have to do in a failure or overflow situation?

Is it like this: route inbound calls to Trunk1, in failure or overflow route them to Trunk2.

---

That's correct on both points.  I prefer to have one trunk as first preference for incoming, and one for outgoing.  That means bother are in use but it's easier for troubleshooting.

How inbound is handled will depend on the carrier.  For example one that I have used will overflow on failure or if the call volume exceeds their provisioned trunk capacity.  That particular ITSP doesn't overflow on Busy or on error.