2 SIP Trunks on 1 cube IOS version 17.12.05a

[markverwey]

I am currently running 1 sip trunk and are using voice class e164-pattern-map XXX to route calls based on the inbound DID; all works great.  I now have to add a second sip provider with a bunch of different DID's and point those calls to and from this sip provider.  Can I do the call routing with a total of 2 interfaces or should I use 3 interfaces.  1 for SIP trunk A, 1 for SIP trunk B, and another connected to the local network which sends and receives all the calls to and from each location regardless which sip trunk it comes in from or goes to.  To muddy the waters even more only 1 of the 2 sip trunk providers requires sip registration, existing SIP Trunk is a private VPN that connects directly to the Cube interface, the 2nd will come in via a different internet path with its traffic being directed by the FW to the cube.

Example call flow:

Call A <-->SIP TRUNK A<-->PBX A

Call B<-->SIP Trunk A<-->PBX B

Call C<-->SIP Trunk B<-->PBX C

Call D<-->SIP Trunk B<-->PBX D

My question is, do I need to use Voice Class Tenants to keep the 2 sip trunks separate?  Or can just add the second SIP trunk coming in via its own IP Interface on my cube router and continue using the voice class e164-pattern-map XXX for all my call routing and dial-peers for each of the PBX's and bind them to the appropriate interface.

[Roger Kallberg · Accepted solution]

There is no right or wrong in this. It’s really up to you to decide what works for you. Me personally prefer to use different interfaces to split SIP trunks from each other. Also using different tenants is best practices to divide the service providers from each other.

[markverwey]

Thanks for the reply,  With regards to 1 sip trunk requiring authentication with the SIP_UA info and the other not requiring any authentication, how do I make sure that the sip trunk with no registration requirements doesn't try and use the other providers credentials or the other way around

[Roger Kallberg]

That would be set by the inbound and outbound dial peers. For the inbound I would recommend that you use information in the VIA header to match. I would also suggest that you put these in different tenants to keep them apart. For detailed information on how call routing operates in IOS please see this document. Explain Cisco IOS and IOS XE Call Routing 

[Roger Kallberg · Accepted solution]

To add to this I would suggest that you put the authentication configuration on the tenant level instead of on the global sip-ua.

[markverwey]

Ok using tenants and different interface for each sip trunk appears to work just fine.  I do have something strange going on though.  If I stand up a call on the new sip trunk then on the cube router, I type the following "show cube call all"

If goes through and shows all the call and details for inbound/outbound calls for the other sip trunk but not the new one.  My call inbound over the new trunk connects and I have them on the phone, I have run just about every command to try and find that call and it never shows up, even is I run a debug command and search for the number I'm calling from in the past I could always find my calls but not on this new tenant config.  What is the best or better way of seeing all calls on all tenants, or is there a way to view them seperately.

[sjdamme]

I ended up opening a TAC case regarding setting up authentication using tenants, TLS, and sip-ua because the Cisco documentation is lacking. What finally ended up working was putting the authentication string under the voice class tenant and then under sip-ua -> transport tcp tls v1.2 adding "crypto signaling remote-add <carrier SBC IP range> trustpoint <name of trustpoint used for TLS>.

Here's my de-identified config. I didn't include the srtp-crypto or tls-profile configs referenced here; those are going to be carrier dependent:

voice class tenant 2000
tls-profile 2000
authentication username <snip> password 6 <snip> realm sip.realm.carrier.com
sip-server dns:sip.realm.carrier.com:5061
srtp-crypto 2000
session transport tcp tls
url sip
bind control source-interface GigabitEthernet0/0/0
bind media source-interface GigabitEthernet0/0/0
!
sip-ua
transport tcp tls v1.2
crypto signaling remote-addr <snip>.<snip>.60.0 255.255.255.252 trustpoint cube1
crypto signaling remote-addr <snip>.<snip>.51.0 255.255.255.252 trustpoint cube1

[Ciscollab_Amit]

Those crypto signalling commands under sip-ua can also be configured under the tls-profile. That's especially useful when you have different CA requirements for multiple providers. 

[sjdamme]

The connection did not work until the crypto signaling commands were put under sip-ua. That was what led to the TAC case in the first place as the documentation did not indicate this. It may be different for different provider connections, but this was the only way to make this one work. I had the same concern you did regarding multiple carriers when defining this at the global sip-ua level, but the TAC engineer pointed out you can still use a different trust point for different providers because you are defining which trust point to use based on the IP range of the provider's SBCs. 

[Ciscollab_Amit]

Suggested is to use Multiple tenants incase of multiple providers. So that incase you need to modify any specific settings for different providers you can set that up under Tenant. The Authentication, profiles, tls requirements, etc can then be setup per Tenant.