Help with a coexistence design

[John Huthmaker]

Hi Everyone,

I want to see if someone can fill in the blanks on this for me.  I havent finished CIPT2 and I know this stuff is covered in it.

I work for a company that has a single call manager cluster.  We have 15 remote sites that tie back to that Call manager.  Those remote sites have PRI's for off net calling.

We just aquired another company who uses a PBX and SIP Trunks for their phones.  We will be phasing them in to our call manager, but we have a couple of things we need to achieve.  First we have 18 more months on the contract from their sip provider, so we have to continue to use that for their phones.  We need to one office at a time, replace their phones and tie them in to our Call Manager.  We need to have this done well before their contract expires with sip provider.

So, I need to develop a coexistence.  Forgive me for my lack of understanding, but I believe to tie things together today, we would use a CUBE in our main office.  What I need to know though is how we can allow their offices to move over to call manager, yet still use their sip trunks for off net dialing.  Is that also achievable with a CUBE?  Is it possible for more than one PBX to utilize a single sip trunk?  If so, we can allow both our call manager, and their PBX to use the same sip trunk.  Then I think would just be a matter of programming the voice gateways.

Thank you all in advance.       

[Chris Deren]

Deploy CUBE at each location there is SIP trunk PSTN connection and add that CUBE to CUCM as SIP trunk.  The configure your dial plan to use the SIP trunk for those phones at that location by configuring CUCM building blocks properly, such as Route Patterns/Route Lists/Route Groups/Partitions and CSSes.

Basically treat the SIP connection as any other GW connection.

HTH,

Chris

[John Huthmaker]

There are two PBX's at this company, each with a sip trunk connection.  However, they have around 10-15 locations all connected over MPLS.  So would I need 2 cubes, or one for each physical location?

[John Huthmaker]

I should also mention that we have an MPLS network at our current locations as well, and those two MPLS networks are tied together by a single DS3 connection between our two main locations.

[Chris Deren]

John,

OK, that does not change or affect anything, my response is irrelevant of WAN topology, it was assumed that there is WAN connection otherwise it would not be possible.  Let me know what else is unclear.

Chris

[John Huthmaker]

Okay, it sounds like the short answer is we would need a cube at each location.  Is there any other options I could pursue?  My understanding is CUBE's are pretty pricey.

[Chris Deren]

You can build SIP trunks directly from CUCM to provider if authentication is not required on the SIP trunk and routing can be accommodated. It is not recommended as CUBE provides a lot more than that, i.e. demarc point, Early media negotiation natively, header profile modification, etc, etc.

HTH,

Chris

[John Huthmaker]

Thats the option I'll likely pursue then.  Cost is definitley a factor as well as the fact that this a very temporary solution.  In 18 months we will be doing away with the SIP trunks entirely.

[Chris Deren]

Great.

Just out of interest why are you moving away from SIP to PRIs?  That's kind of reverse of where the industry is going.  Have you considered centrelized SIP trunks? Great ROI in long term.

HTH, please rate all useful posts!

Chris

[John Huthmaker]

We bid out all new voice circuits recently, and SIP just wasnt competetive.  We are a very phone heavy company.  With SIP the local calls werent free, so the pricing just wasnt attractive.  Also, it does put all of your eggs in one basket.  If your internet connection goes down, so do all of your phones.

[Chris Deren]

Understood, I would never recommend putting one SIP trunk, the beauty of the solution is you can build redundant SIP trunks in separate data centers.  But traditional PRIs are sure reliable.

HTH,

Chris