SIP Trunking

[mightyking]

Hello Everyone,

We have a mega CUCM cluster with 21 servers for our multi sites Clustering Over WAN deployment.  

Number of site: 20 with different area codes

Number of users: 50000

CUCM Version: 10.5

CUBE (HA): ISR 43xx

Current situation:

Every site has it's own CUCM server(s) and at least 2 or more gateways with dedicated PRI connection to PSTN.

We are planing to replace all our PRIs with SIP Trunks over a centralized deployment. The trunk will contain 1000+ SIP channels. Please note that we will continue with Clustering Over WAN design after migrating to SIP but all local gateways wil be decommissioned.

 Would that be acceptable to put all eggs in one basket meaning one trunk containing 1000 SIP channels terminated to HQ CUBE?

Wouldn't it be more logical to have multiple trunks with fewer channels? Please note that in our negotiation there're no charges for additional trunks. They are FREE.

Design questions:

1) Inbound

Could we have 20 inbound SIP Trunks (carfully sized) from the provider to the HQ CUBE each handling different site (area code) and a dial peer from the CUBE to the repective onsite CUCMs? 

2) Outbound

Could we have 20 trunks from CUCM to the CUBEs each carring the traffic of a different site which will be mapped to the same trunks terminated in the CUBE from the provider? 

I would greately appreciate if your could share your thoughts.

Thanks,

MK

[shleets]

We are doing this now and going with a cetralized HA cube design in our DC's clustered across the WAN.  Call preservation is available in each DC if a cube were to fail.  With a 1000 CC I would change your cubes to 4431's.  Doing this approach reduces hardware and circuits costs, also reducing entry points into the network..  With this said the WAN needs to be able support the traffic.

[Jinto Alakkal]

Design questions:

1) Inbound

Could we have 20 inbound SIP Trunks (carfully sized) from the provider to the HQ CUBE each handling different site (area code) and a dial peer from the CUBE to the repective onsite CUCMs? 

I assume all the CUCM servers sharing same database here when you say clustering over WAN and the phone registration is controlled by respective CUCM groups, unlike the PRI circuits a SIP trunk to the CUBE is an internet kind of connection

from ITSP and they will be terminating all calls through it you can have like 4 or 6 CUBE routers  here first pair with an active and standby and another second pair with active and standby connections so that you will have complete redundancy
that will be something I would consider, you should be using Fiber connections instead of RJ45 because you need a lot of bandwidth to terminate calls for 20 sites)

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability.html this is a Documentation about how you can enable high availability/options

Another point of failure What if your WAN connection goes down to a branch site and it isolates couple of servers at a site how the calls to that branch will get routed and how the calls from that branch is going to get routed to ITSP do you have highly redundant internal pipes to cover it ?

When I design I will normally consider all the call legs and the DID blocks for each sites and will prefix the incoming DID numbers with a code and the outbound dialpeers are matched with that Code,

so that you can route it the appropriate CUCM group) you need to be really good at writing translation rules in CUBE for this

if you have an SME call manager and each sites are having independant or shared clusters you can use the SME to route those calls in your case i think you don't have an SME CUCM

2) Outbound

Could we have 20 trunks from CUCM to the CUBEs each carring the traffic of a different site which will be mapped to the same trunks terminated in the CUBE from the provider? 
 
I would greately appreciate if your could share your thoughts.

you can have same number of trunks as the number of routers and you can create your route lists accordingly, one per each CUBE router i would say but not 20 of them because when you have 20 SIP trunks you might want to create 20 different
SIP profiles because you cannot use same ports multiple times to the same terminating address you want to keep the design as simple as possible but highly redundant, We will only have like 4 or 6 routers serves as the central point to routing to the ITSP

When it comes to design not only these are the considerations, as it is a brown field you might want to reach out a Partner architect to help you out a bit more to understand your environment deeper and help you with a good solution that suits you hope this helps a bit

Thanks!
Jinto.

[mightyking]

Thanks Jinto & Shleets for taking the time and replying.

I understand that having 20 trunks for outbound calls will make the design look complexe and I agree with you that the number of trunks should go with the number of available CUBEs. but what about multiple trunk from ITSP to the CUBE for inbound calls? What could go wrong with this design? I just don't feel comfortable to put 1000 CC in one single trunk. We have more than 2000 partitions to which the CSS of the trunk needs to have access. In another word, the CSS of the trunk will contain more than 2000 partitions. Do you thing this will make sens? Knowing that a CSS cannot contain more than 1024 characters, 

         - We are going to use ISR 4351 for CUBEs.

         - The WAN links are 10G Wavelength fully redundant

Thanks,

MK

[Dennis Mink]

ONe thing that you will need to consider is bandwith, if you have say 100 channels, then this could mean 100x80kpbs of traffic if using G711. so make sure you understand how RTP is going to flow, so you have enough bandwidth and QoS in place.

CUBES can operate in two modes when it comes to RTP: flow througfh and flow around. flow through is where RTP terminates both the inbound and outbound RTP leg on the CUBE. this can be particularly usefull if you place your CUBE in the DMZ. with flow around the CUBE will NOT terminate the RTP but will just provide the signalling. this means your SIP provider will need full routability to all your voice subnets. something to think about

[mightyking]

Thank you Dennis for the usefull informations and yes all these calculations have been done with care. 

I guess my question remains unanswered. The question is; having one trunk containing 1000 channels vs lets say 4 trunks with 250 channels from ITSP to the CUBE for inbound calls? Do you see any disadvantages with having multiple trunks instead of one?

Thanks,

MK

[mightyking]

Anybody with any idea?

Thanks,

MK

[TONY SMITH]

I'm pretty sure you can't have 2000 partitions in one CSS.  There will be an alternative solution, but we'd need to know more about your dial plan design to be specific.   What are these 2000 partitions for, and how do you manage internal calling?

One possible solution might be for the CUBE CSS to reach one or more partitions containing translation patterns for each country or number prefix or whatever suited.  Each translation pattern would then have a CSS containing only the relevant final partitions.

[mightyking]

Thanks Tony,

Il looks like you prefer one incoming trunk from ITSP to the CUBE containing 1000 channels instead of having 4 trunks with 250 channels, is that right? Do you see any disadvantage of having multiple incoming trunks vs one?

MK

[jonathan.salter]

I would contact the carrier for suggestions as well.

[TONY SMITH]

---

@mightyking wrote:

Il looks like you prefer one incoming trunk from ITSP to the CUBE containing 1000 channels instead of having 4 trunks with 250 channels, is that right? Do you see any disadvantage of having multiple incoming trunks vs one?

---

The CSS issue will be the same whether the CUBE has one trunk or many trunks as in either case the CUBE will appear to CUCM as a single SIP trunk (assuming you're using SIP for CUBE<->CUCM of course).

Personally I prefer to have two or more completely independent CUBEs, seen by CUCM as separate trunks but with overflow and failover by Route List/Route Group configuration for outbound calls.   Failover and overflow for inbound is reliant on the ITSP, and in turn that requires each CUBE to be configured so it can handle any of your incoming calls (coming back to your CSS question).

[Jinto Alakkal]

If you know your DID blocks you can actually route the calls as below, we don't have to add all partitions to same trunk when it's big deployment like this you might not be able to do it as there are limitations for number of partitions

Main trunk with lets say 250 channels and you know the DID numbers which will be landing through it, you can create a common partition for all these numbers  (One per location) and add them as a translation pattern, for example you receives an incoming call for an internal 4 or 5 digit number on a DID externally through the SIP trunk, the SIP trunk CSS will not have direct access to the internal partitions instead it will have access to that common partition for that DID block

lets say this as an example

The E164 number +1408915XXXX belongs to the location San Jose what you will be doing is you will create a partition for it lets call it PartDID_SanJose and the SIP trunk CSS will only have access to this partition specifically and now you will create a translation pattern +1408915XXXX to translate it to however the way you want 4 or 5 digits in the local cluster or all the numbers as it is if you have a Global dial plan (this Translation pattern will have a CSS and this is going to be the master CSS for each site), you can also use e164 patterns now for internal numbers depending on your dial plan.

Similarly if you have like 20 different site locations you can create partitions for them and you will be able to route similarly and if all of the phones are currently registered to the same cluster the internal dialing is just going to work however the way it was working before as we are not doing any changes to the local phone configuration/CSS or Partitions, the SIP trunk is for external DID numbers only, you can actually create wild card DID patterns so that you can get all numbers for 20 different sites with minimum number of DID blocks in CUCM.

Hope this helps a bit, In addition reach out to your provider and they have same kind of trunks in multiple locations, ask them example deployment models how they will be delivering it and get a clear picture about that as well.

[mightyking]

Thanks Jinto,

We have 3 major sites which carry 80% of our traffic. Let's say Boston is the HQ, San Jose and New York are two other major sites. Each major site has it's own UCCX call center and at least 2 CUCM servers (Clustering Over WAN).

Here's what I had in mind as the design for our SIP project.

4 trunks of 250 channels each terminated to our core CUBE(HA) located in HQ. The trunks are dedicated as follow:

- First trunk would contain the main number of HQ call center as well as all DID blocks.

- Second trunk would contain the main number of San Jose call center and all DID blocks.

- Third trunk would contain the main number of Net York call center and all DID blocks,.

- The fourth trunk would contain the DIDs of all other smaller sites.

An incoming call destined to San Jose comes into the CUBE in HQ. A Dial peer matches the incoming call and forwards the call to San Jose CUCM server group and the CUCM routes the call to the endpoint.

I was planing to do the same for outbound calls. Creating 4 Route Lists --> Route Groups --> Trunks to send the call to the CUBE and from CUBE to the ITSP trunk.

This design allows me to separate the traffic of each major site for inbound and outbound calls. It would be easier, should there be any maintenance for one site without affecting the other sites.

Do you see anything unusual with this design?

Please note that we have another pair of CUBE in San Jose (Standby) which is for the redundancy purpose.

Thanks,

MK

[Jinto Alakkal]

Hi MK,

I don't see a problem with this design however you may want to check with your service provider also about this and ask them for a similar solution that they have deployed for another customer, Once when they give you a HLD you can figure out if there are any single point of failure and if there is one you may further ask them how to mitigate it.

Thanks!

Jinto.