PRI to SIP migration

[KhanalZ]

I wanted to run it by the experts so that I have good idea well in time. Apologies for the lengthy background.

Following is my current scenario:

- 2 sites (Hq and Branch) connected by MPLS

- Single CUCM 12.5 cluster with nodes spread in both sites

- Hq site has 44xx router with multiple PRIs

- Branch site has 44xx with a single PRI for failover but failover rarely happens

- Routers have cube licenses

- CUCM has both gateways as route group members so we have control over which gateway to use for oubound calls

- Bunch of VG310 and VG320 gateways in both locations for fax and analog devices

- Uptime is very critical in our environment

- We have CUCM lab environment for testing

Plan in the working

Replace PRIs with SIP trunk. Expected cutover end of Summer 2024

 - Single CUBE router in both sites. Re-purposing existing 44xx for this purpose

 - dual sip trunks terminated at each sites (2 at HQ and 2 at Branch) for redundancy

 - No spare cube router for testing the SIP trunk

 - BGP is preferred routing protocol per ITSP

 - Configure a loopback interface for inbound SIP invites

 - We can take the branch router out of production for testing but it needs to be put in prod when SIP goes live

Given the above scenarios:

 - How do we configure, test and do the cutover with minimum downtime?

- We need to be able to do site failover testing as well, preferrably prior to number porting

- Is there any way to keep the routers at both sites online with PRIs still connected and servicing calls and at the same time, connect the SIP trunks, do the BGP config, make necessary CUBE configs? 

- Probably use the new SIP trunks for outbound calls as well as inbound (we will get a few test DIDs)

I am sure it is not uncommon scenario so if someone could provide any tips or resources that would be very helpful.

Thanks,

Khanal

[Maren Mahoney]

First, it is *always* appreciated when posters provide as much information as you did. Thank you!

You don't mention if your PRIs are MGCP controlled or if you have SIP Trunks to the routers and PRIs on the other side.

If your PRIs are MGCP controlled, you can acquire the same routers via SIP using what will end up being your final config for the SIP communications. The router can run MGCP and SIP in parallel while you are testing. If this is the case, you can build inbound and outbound dial peers as desired for SIP, along with SIP parameters and such. In CUCM, come up with a route pattern that uses a prefix (like "77") that points to the new SIP Trunk (via its route list!) where the Route Pattern strips off the prefix before egressing CUCM. You'll have the test DIDs to test inbound call routing.

If you connect to your routers by SIP already with inbound and outbound dialpeers already pathing traffic, your CUCM-Trunk-to-Router configuration should not need to change much. If you absolutely have to have a different trunk and different CUCM-facing dial-peers you can have CUCM acquire the router a second time using SIP using a loopback address and/or set up a SIP Trunk Security Profile to use specific ports (which would have to be reflected on the router) for the second trunk. You can build outbound dialpeer(s) on the router that sends specific outbound calls over the new SIP connection to your service provider. As with the MGCP scenario the test DIDs can help test inbound traffic.

Failover testing can be simulated by shutting down the dialpeers outbound to your new service provider to make them unavailable. This will help test the failover timers as well. Other folks here may have additional ideas on how to do that.

This is where I start in a situation like this. You'll have to refine this based on your environment. And I'm sure other folks here will have input.

Maren

[KhanalZ]

Thanks a lot Maren for responding so quick. Sorry I forgot to mention, we have SIP trunk between CUCM and the gateway. The MGCP section of your response might help those with MGCP integration.

So, as you mentioned, there should not be much changes required in CUCM or even the dial peers towards the CUCM. There is absolutely no need to create another trunk either. 

Anyway, I look forward to hearing from more folks on this and see they have anything new to add on this.

Thanks again