Dialing rules and Call Routing for CUPC/Softphone 8.x Multi Site Deployment

[lancesmith]

I am hoping someone out here has come across theis senerio and has been able to find a solution.

The Problem:

     I have a couple of customers now that have purchased CUPS 8.5 +, and we have deployed CUPC 8.5 clients as well as configured the CSF ( Cisco Services Frameworks) Devices in CUCM ( 8.51), so the client can use either their IP Phone or Softphone with their CUPC.

The challange I am having is getting the Click to call to work properly due to the fact these customers have multiple geoghrapically seperated locations.

When a users looks up a Phone number of a contact from their Corporate AD ALL numbers are in the form of a 10 Digit Number: The problem I am having is how to configure CUCM to know when the outbound call requires a 9 ( For Local Call), or a 91 ( for Long Distance), and send the call out eth appropiate Voice Gateway.

To add to the challange I have same Area Codes that are BOTH Local and Long Distance to the different Sites. For example 778-XXX-XXXX and 250-XXX-XXXX. I currently have TEHO configured for the IP Phones, so in my existign route patterens I have broken patterns dowm to the NXX level and all of this works. The key thing there is that the End User knows when to dial a 9 or a 91.

For a Site to Site 4 digit call everything is fine, but I don't know if it will still work if AAR Kicks in due to Low Bandwidth, thast for a later test

For Softphones to work I can set up SIP Dialing Rules, but they will only work for one or the other site. ( See My Example below)

Any Help woudl be greatly Appreciated.

Lance

[Jonathan Schulenberg]

Well you could configure CUP/CUPC to use the ipPhone attribute instead of telephoneNumber. This would be under Application > CUPC > Settings in the CUPC LDAP Attribute Mapping section.

If you're set on using telephoneNumber: The way I have been avoiding this problem the past few years is by using the E.164 (aka plus-dialing) dial plan. It handles this easily because whatever format the number is input with is always translated into a global form before making the route decision. This global format (e.g. +18005532447) is then localized as appropriate for each off-net path. Moving to E.164 requires some serious thought to wrap your head around the details as well as a total overhaul of the CUCM dial plan though.

An alternative may be a partition in each site's device-level CSS that matches the local calling area patterns and strips the NPA off. This is a lot of work to maintain though. It probably also means that you use Device Mobility to change the device-level CSS dynamically as the CSF device registeres from various offices.

PS- SIP Dial Rules cannot manipulate the dialed pattern. You mean to say Application Dial Rules.

[lancesmith]

Jonathan, thank you for responding.

     So a couple of things, you are correct and I have set the CUPC LDAP Attribute to the IPPhone field, thats the only reason that the dialing the internal 4 digit phone numbers work out of the Contacts in CUPC.Also correct it is the Application Dialing Rule.. :-), if I hover over a contacts work number it is just the number out of the IP Phone Field in AD that is displayed and dialed

     Regarding using E164, it is something we have to start to seriuosly look in future deployments but I need to find some good material on proper deplyment design and senerios in the UC / CUCM, anyways I digress.

     We were looking into having to use Device Mobility to accomplish proper Call Routing, however my thought was to create some basic Route Patterns that would accomodate the Local and Long Distance for each of the sites, and not worry about making sure I preserve TEHO as with the IP Phones.

For Example ( Nope I am not using Route Filters only for Toll Free..)

9.604XXXXXXX                 Vanc_Local_CUPC_Par        Use the Local RL for Vanc

9.1[2-9]XX[2-9]XXXXXXX     Vanc_LD_CUPC_Par          Use the Local RL for Vanc

9.011!                              Vanc_INTL_CUPC_Par          Use the Local RL for Vanc

etc...etc

then for the other site say Toronto, same idea

9.416XXXXXXX                    Toro_Local_CUPC_Par          Use the RL for Toro

9.647XXXXXXX                    Toro_Local_CUPC_Par          Use the RL for Toro

9.1[2-9]XX[2-9]XXXXXXX       Toro_LD_CUPC_Par               Use the RL for Toro

etc

I could even Prepend all of the 10 digit numbers being dialed out of the CSF / CUPC with someother number say 88, and build my patterns to match on 88 + 10 digits etc...

put each of these Partitions in a Site Specific CSS to the CSF Softphone Device.

But here is the catch we see with this, currently on the we define the the Information Elements on the Voice Gateways as Unknown / National / Unknown / ISDN , therefore we are basically telling the CO  what the Call Type is at the Gateway ( MGCP).

If I understand the New options where we can define the Call Type at the Route Pattern OR Route Groups, then first I would have to CHANGE all of my Voice Gateway IE to CUCM / CUCM / CUCM / CUCM, so what ever is defined as a call type prior to the gateway is carried thru unchanged correct?

Then for each of the Local Route Patterns Defined I would set the National / ISDN / National / ISDN

and the Long Distance patterens as Unknown / National / Unknown / ISDN, thereby defining the Call Type on Each of the Route Patterns and carrying this information all the way thru to the CO.

I haven't tried this method before and I would like to know if other out there do define the Call Type at the Route Pattern and if there are any caveats, or if this would even work ! ?

If this doesn't work then I will have to seriously look at Device Mobility, I would assume since these are Clients running on PC's then the Networks I would have to define wouldn't be the IP Phone networks for Device Mobility, but would be the customers PC Subnets? Doing this method adds a layer of complexity for the customer to have to support once I am done as well.

I just wish Cisco had developed the SIP to be configurable in the same way SCCP is with the ability to add a Partition in a SIP CSS that could be applied at a Device of LIne level, this would make life so much easier.

sincerely

[Frank den Haan]

Hi Lance,

Unfortunately it's not much help to your issue, but it's interesting to read your post. We deployed CUPS/CUPC in our company, which is Canada-wide, and experienced the EXACT same issues you were facing with the click-to-call functionality. Internal site-to-site dialing with the LDAP Attribute Mapping of BusinessPhoneNumber to the ipPhone field, everything works great. But when it comes to calling people's mobile numbers listed in AD with area codes in Nova Scotia, for example, where 902 can be a local or long distance call depending on your location, it just cannot be easily accomplished. We tried multiple configurations with Application Dial Rules, etc but as you saw, it works great in one location but it's not scalable to multiple sites.

When I talked to Cisco TAC and some consultants, it seems the best solution is to layer in a E.164 dial plan. Hopefully, that will be the next step for us.