CUBE and SIP question

[Bekzod Fakhriddinov]

Hi, we have one cube and sip to service provider(SP) , management is considering another redundant SIP trunk to be established via another l3mpls network we use for data traffic only . The thing is CUBE is not directly connected to that l3mpls network but connected via LAN . 

Is it possible to setup 2nd  SIP trunk to be established via another l3mpls network over LAN ? 

I don't know how to deal with IPs at this case, cause we are connecting to PUblic ip of the SP...

and also I don't have PVDM modules and CUBE license on the router connected to that l3mpls network...

Any idea, recommendations?  

Thank you 

[R0g22]

You would need SIP multi-tenant support to have multiple tenants/sip trunks off the same CUBE. PVDM's/DSP's are NOT required in an IP to IP flow taken the fact that you would not use this CUBE to host any media resources.
No additional licenses are required apart from the CUBE licenses which are RTU and based on the sessions. You would need to take into account if adding another trunk will increase the total number of sessions through the CUBE or not against your existing licenses. If it does, you would need to purchase additional licenses.

[Bekzod Fakhriddinov]

that second SIP over l3mpls  is as backup in case 1st will down.

so you mean I can use IP-to-IP flow here: Service provider-existingSIP--cube---switch---CUCM--routerB--l3mpls  with no pvdm and send traffic from router B to CUCM ? And CUCM will use software resources for transcoding. Correct?

Do I need CUBE licenses on router B to make it backup CUBE with backup SIP trunk (logically if 1st down then # of session is the same on the second then no need extra licenses) ?

Thank you

[Dennis Mink]

on the outbound, you can build in redundancy by sticking both SIP trunks to the CUBES in a RG, make sure you use OOB options ping on the CUCM ,to make fail over quicker.  This is on the outbound. so calls from cucm to PSTN.

inbound calls you will need to talk to your provider.

If and when you use a single codec end to end like g711 or 722 then you would not need to transcode and this your cubes will not need PVDMs.

[Mohammed al Baqari]

What the Dennis suggested will work. My opinion that its not best practice
to connect trunks from provider directly to cucm (at least not cisco best
practice).

You can connect both to CUBE and let CUBE failover between then using OOB
Options-Ping. On CUCM you need to set service parameter Stop Routing on
Unallocated Number Flag to False.

Your CUCM should be protected behind the CUBE to avoid any kind of attacks
such as DDoS or exploitation.

[R0g22]

Yeah so with the call flow that you have, your CUCM will need to do the hunting. So your CUBE and Router B will be part of a route list/route group with CUBE being preferred as the primary destination. CUCM service parameters to "Stop Routing on User busy/Unallocated Number" will need to be set to False.

CUCM cannot do transcoding natively. You need to have IOS based resources. So if you plan your codecs correctly, you might not need a transcoder at all. But, if you know for sure that transcoder will be required, then yes you would need PVDM's on the router.

For the licensing query, if the router B will act as a CUBE then yes, you would need licenses on it even if it will act just as a backup.

[Bekzod Fakhriddinov]

it's getting much clear now. Thank you guys. Right now I am connecting to SIP provider via public ip and CUBE then does ip mapping public-to-internal. Is it possible to change this and  connect SIP provider to my Loopback ip of that CUBE?

(If yes then that L0 ip I'd advetrise to both sides (via my LAN) so l3mpls side aslo will advertise it and SIP provider will have second backup path via l3mpls  . like      SIP-----[cube]---[lan]---[routerB]---l3mpls)

[R0g22]

I would not want to do that. It defeats the purpose of having an SBC to provide topology hiding. Why do you need to provide a backup path to your ITSP ? They should be able to do that on their own in case there is a lack of response from the primary CUBE and/or if it sends a 500,503 response for an inbound request.

Remember, your OUTBOUND hunting/failover is governed by you. This is transparent to your ITSP. INBOUND failover is governed by ITSP. This will be transparent to you. When I say transparent, I mean neither of you are concerned about how the other is achieving redundancy.

[Bekzod Fakhriddinov]

U r right, I should care only if I loose primary link to be able to reach their public ip via my backup path. 

At this case routerB (connected to l3mpls)  become just a router not a CUBE , correct? 

[R0g22]

I believe routerB will be a CUBE as well. If you confirm the following call flow, then my answer would be relevant.

CUCM >> SIP >> RouterB (while failover is active) >> SIP over MPLS >> ISP

[Bekzod Fakhriddinov]

In my previous post I thought in fail-over case: CUCM ---sip--existingCUBE--LAN---routerB--L3mpls . 

I thought incoming/outgoing sip traffic routerB will process as regular ip flow and CUBE then will do his job.  Is it wrong ?  

[R0g22]

That's achievable as well IMO. You would redundant dial-peers now on the existing CUBE with a higher preference so that the CUBE does a hunt when call fail through the primary SIP trunk.
From what I see, you are complicating things. Can't you have a second SIP trunk terminate on your existing CUBE router and have multi-tenants ? Why a need to have another router ?

[Bekzod Fakhriddinov]

this I wanted to ask you about, Can I terminate second sip on existing CUBE if that sip ip flow will go trough routerB to l3mpls,  this path   CUBE ----LAN---routerB---l3mpls ? 

at this point as I think routerB will not be CUBE just router routing ip packets. 

I am not sure about security because we learned always when connect to SIP provider always use CUBE

what do u think? 

[R0g22]

My initial response to this thread specified just that. Use of Multi-Tenants.
Ok let's clear out a couple of things -

CUBE >> SIP >> ITSP
CUBE >> SIP > L3MPLS

The above would be the setup for multiple SIP trunk termination.

CUBE ----LAN---routerB---l3mpls

With this topo, you don't really need to worry about the second trunk because all you are doing is routing the call to your routerB over LAN. A simple dial-peer pointing to routerB can accomplish this. RouterB will further terminate a SIP trunk over MPLS.
In this same scenario, the routerB will have an IP to IP call flow which makes it a CUBE.

[Bekzod Fakhriddinov]

ok, sound good.  At this case I just need to enable CUBE feature on router B, get uck9 licenses, activate uc feature,   and don't need dial-peers, voice translation rules, correct?