cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1796
Views
16
Helpful
5
Replies

CUBE - Provider SIP Trunk Termination

mbrandon32
Level 1
Level 1

We are currently in the process of integrating a new SIP provider onto an existing pair of HA CUBEs that is already hosting our current SIP provider. I have the overall configuration worked on in terms of dial-peers - with each provider having their own inbound/outbound legs.

 

My issue is more along the lines of the interface configurations. We have a single /24 network dedicated to our voice services. With a current IP assigned from that /24 to the current interface, I planned to choose another IP from that /24 space for the second provider to terminate on a different interface - while also configuring a new SIP trunk from CUCM to the CUBE. I understand these IPs will overlap each other but wouldn't the CUCM SIP trunk destination and dial-peer bindings not handle the isolation of the incoming/outgoing traffic, ignoring the fact that the interfaces lie in the same subnet?

5 Replies 5

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

I dont see why you want to configure another SIP trunk on CUCM to CUBE. CUCM is not aware of your new ITSP. It is aware of CUBE. So there is no need to add another SIP trunk. On your CUBE you. can use voice class tenants to create a logical separation between your ITSPs and then bind all the necessary configurations to each ITSP. You can then use dial-peers to route calls to each of them as it fit your needs.

 

For outbound calls, CUCM just sends the call to the CUBE and CUBE routes the call based on your dial-peers. Again no need to add any additional sip trunk on CUCM.

Fro inbound calls, New ITSP delivers the call to CUBE and CUBE will route the call based on your outbound dial-peer to CUCM. You can re use your existing dial-peers to CUCM or add new ones if you need to do specific digit manipulations using SIP profiles or voice translation rules..

 

Please rate all useful posts

My theory was more around terminating the trunk from the ITSP on two different interfaces on the CUBE in order to segregate them physically. If I'm understanding correctly - In theory, it looks like from the tenant, bindings, and destination patterns, this can be accomplished logically via the same terminating interface. That way, in the future, when we remove the old provider, we would just need to remove the tenant configurations and shut down their dial peers. Correct?

 

This should also be possible without tenants, it seems, as we aren't currently authenticating our ITSP trunks and on my inbound dial-peers I am identifying an incoming uri.

No, the tenant configurations provides a very clean and logical way of having multiple ITSP on your CUBE. You still need separate physical interface to apply your bind statements. Yes you can do this without tenant configurations. its just not as clean.
Please rate all useful posts

Going back to my initial question regarding the IPs on the interfaces - will the tenant configuration allow two different IPs from the same subnet to be applied? I did some research on multi-tenant prior to all of this but our ITSP doesnt require registration or proxy authentication so I'm just not certain what the tenant would do for us. Can you provide any examples?

Hi,

 

Here is a sample configuration of a multi tenant deployment on the CUBE..

There are two ITSPS on this deployment and as you can see I am using voice class tenants to group the attributes for each ITSP and then applying it to the relevant dial-peer. In this deployment SIP registration is required but my tenant configuration has more than just authentication. With this it is easy for me to migrate between ITSPs, take one down with ease of mind. Just a very elegant way to deploy a solution in my opinion.

 

voice class tenant 101
retry invite 2
retry bye 2
retry cancel 2
timers trying 150
reason-header override
audio forced
bind control source-interface GigabitEthernet0/0/0
bind media source-interface GigabitEthernet0/0/0
no pass-thru content custom-sdp
!
voice class tenant 501
registrar dns:us-west-or.sip.flowroute.com expires 3600
credentials username xxxxx password 7 xxxxx realm sip.flowroute.com
authentication username xxxxx password 7 xxxxx realm sip.flowroute.com
no remote-party-id
retry invite 2
retry bye 2
retry cancel 2
retry register 2
timers trying 150
reason-header override
audio forced
localhost dns:sip.flowroute.com:5060
bind control source-interface GigabitEthernet0/0/1
bind media source-interface GigabitEthernet0/0/1
no pass-thru content custom-sdp
!
voice class tenant 503
registrar ipv4:216.206.64.83:5100 expires 3600
credentials number xxxxx username xxxxx password 7 xxxxx realm voip.centurylink.com
authentication username xxxxx password 7 xxxxx realm voip.centurylink.com
retry invite 2
retry bye 2
retry cancel 2
retry register 2
timers trying 150
timers connect 100
reason-header override
audio forced
localhost dns:voip.centurylink.com
bind control source-interface GigabitEthernet0/0/1
bind media source-interface GigabitEthernet0/0/1
no pass-thru content custom-sdp
sip-profiles 200
early-offer forced

 

dial-peer voice 101 voip
description /* Incoming CUCM dial-peer anchor */
session protocol sipv2
session transport tcp
destination provision-policy 501
incoming uri via cucm
voice-class codec 711
voice-class sip profiles 100
voice-class sip tenant 101
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 103 voip
description /* Incoming Flowroute dial-peer anchor */
translation-profile incoming PSTN-to-CUCM
session protocol sipv2
destination provision-policy 101
incoming uri to flowroute
voice-class codec 711
voice-class sip tenant 501
dtmf-relay rtp-nte
no vad
!
dial-peer voice 301 voip
description /* Flowroute to CUCM cluster */
session protocol sipv2
session server-group 301
destination e164-pattern-map 300
voice-class codec 711
voice-class sip tenant 101
voice-class sip options-keepalive profile 101
dtmf-relay rtp-nte
no vad
!
dial-peer voice 501 voip
description /* From CUCM cluster to Flowroute */
translation-profile outgoing PSTN_FLOWROUTE
preference 1
session protocol sipv2
session target dns:us-west-or.sip.flowroute.com
destination uri-via cucm
voice-class codec 711
voice-class sip tenant 501
voice-class sip options-keepalive profile 501
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
no vad

 

dial-peer voice 503 voip
description /* From CUCM cluster to CenturyLink */
translation-profile outgoing PSTN_CenturyLink
preference 2
session protocol sipv2
session target ipv4:216.206.64.83:5100
destination uri-via cucm
voice-class codec 711
voice-class sip tenant 503
dtmf-relay rtp-nte
no vad

Please rate all useful posts