Transitioning DID’s from CUCM to OCS

What is a DID?

Direct-inward-dialing (DID) is when a carrier provides a range of PSTN numbers for a customer’s PBX that is sent over a T1, analog or other service provided by the carrier.

The solution…

This is a complex subject at the best of times and I am sure that there are plenty of ways to get this done. Over the last few weeks I have been looking at effective ways to achieve this that doesn’t involve routing calls through a Cisco Unified Communications Manager (CUCM) first and still only use one Mediation server. Seems like it could be difficult but I think I have the answer. First step here is assuming you have a CUCM environment you are also using the ISR platform as your gateway (other gateways such as NET or audio codes may also perform the same function). Unfortunately my plan doesn’t work with MGCP as the gateway protocol on the CUCM sude but certainly H323 and SIP will work for talking to CUCM and OCS respectively. This way of transitioning is really aimed at smaller customers although a much larger Enterprise could utilize this idea to either share or transition DID’s from one system to another using multiple mediations servers.

One part of this solution is relying on the mediation server to receive inbound calls from a gateway not defined in its configuration. Inbound, a mediation server will accept SIP invites from any gateway. Outbound is where the limitations begin. Only one gateway can be configured for outbound calls, in this case it would be a direct SIP trunk to a CUCM server and not the gateway. So all outbound calls would still route through a CUCM before either calling a Cisco IP Phone or the PSTN. Once your cutover is complete you can swing the configuration in the mediation server to point to the gateway and not CUCM server if you have removed all the Cisco IP phones and no longer require outbound calls to CUCM or if the balance of OCS users compared to Cisco IP phones becomes weight more towards one over the other.

Diagram



The solution I have really relies on OCS’s behavior of call rejection when you send a call to it that uses a DID that is not associated to an OCS user or application. What does OCS do in this case? SIP/2.0 404 Not Found.

I have also used this behave to route calls to an announcement server for unallocated DID’s when you have a dedicated range but in this case we are sharing with a CUCM system. What’s important here is that the call is rejected by OCS to the gateway which gives the gateway a chance to route the call elsewhere. In CUCM this behavior is a little different in that CUCM would try to route the call out another trunk rather than reject the call back to the gateway. Once the call is rejected by OCS the gateway sends the call to CUCM where CUCM will first lookup to see if the call is destined to any of its own endpoints. It may be a case where it may then try to send the call to OCS again and this is where having an a announcement setup in CUCM will play a critical part in avoiding any looping behavior when OCS rejects the call back to CUCM.

Below is ISR configuration (OCS/SIP and CUCM/H323) to make this work.

voice translation-rule 103
rule 1 /^\(120655555..\)/ /+\1/
!
voice translation-profile AddPlusOne
translate called 103
!
dial-peer voice 555 voip
description to OCS mediation server
preference 1
translation-profile outgoing AddPlusOne
destination-pattern 120655555..
session protocol sipv2
session target ipv4:X.X.X.X
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 5552 voip
description to CUCM XX
preference 2
destination-pattern 120655555..
session target ipv4:X.X.X.X
dtmf-relay h245-alphanumeric
codec g711ulaw
!

Why using OCS Sim Ring to ring the Cisco IP phone is better than using Cisco Unified Mobility to ring OC.

One word. Licensing. It limits the requirement for a Cisco Device License Unit to turn on Mobility for a user if you haven’t subscribed to the CUWL (Cisco Unified Workspace License). One word of caution though if using simultanoues ringing on OCS to perform this. The numbers cannot be the same. So either a different DID ranges for each system or they somehow need to be different, otherwise OCS will not route the call out to CUCM. Maybe the full E164 for OCS and abbreviate 5 digit line number on CUCM would most likely work but would take a little thought to avoid routing loops.

Why this is better than other solutions that require a customer to forward calls from CUCM.

Forwarding calls from a Cisco phone to OCS is in my opinion a pain in the you know what. The results can be unpredictable and if there is an issue in CUCM system your OC client no longer receives the call. Sharing DID’s at the gateway makes a whole lot more sense than just forwarding or relying on CUCM for call control of an OCS inbound call just because we can make OCS take full control of the call and utilize Sim ring to help with ringing multiple devices.

Routing from CUCM to OCS for internal calls

This has two options but using the gateway to route between the two systems means turning on the IP-IP GW feature which Cisco has a license for. Best solution here is to route directly over a SIP trunk between the two systems.

I know some people may see this as complex and yes I guess it is but migration strategies are never simple when you want to ring multiple devices and share DID ranges. If you had a clean range for each system I would recommend more of a flash cut scenario but limiting CUCM extra licensing requirements and making the system more effective is my whole idea here. After spending three years using call forwarding techniques to achieve some of what I have written here I can tell you in all honesty which I would much prefer to do.

If you have tried other successful methods please feel free to share.