Automatic path selection in CUCME

[khanfawaz]

Hi All,

I have a special requirement. There is a big central core voice network where I have SME and CUCM clusters. On other side I have hundreds of CUCMEs installed in trucks which are mobile units located far away in remote places. When they are remotely located, mobile/truck CUCMEs get connected to the central voice network over various wireless network. Occasionally this trucks/mobile units come closer to central network and they get connected via a Ethernet connection. At this point the call routing from CUCME should not happen over radio/wireless devices. It should travers through the Ethernet connection. Manual tweaking in CUCME is not possible. How can I achieve this? There are hundreds of trucks/mobile units and there would be hundreds of POPs where these trucks can possibly get physically connected.

One idea which came to my mind instantly is to create as many dial-peers in every CUCMEs and give the highest preference values to the dial-peer pointing the Ethernet connection, so that the call will hunt for the available paths. Would like to understand how feasible is this solution also the cons of it. As I have hundreds of dial-peers how can I reduce the hunt time of the available path efficiently.

I am looking for an intelligent call routing technique which can adapt by itself. Is there another solid solution for this?

Thank you.

Fawaz

[Jaime Valencia]

Not really, neither CUCM nor CME work based on the underlying network conditions on choosing the best path, all that config is static.

They don't know, or care, which communication method is used between the boxes.

EDIT you can try options ping on the dialpeers depending on your config to turn them on/off based on that.

[khanfawaz]

Hi Jaime, I agree with you. On the other hand we can make the call hunt its path in CME writing in so many dial-peers with the help of preference. I just wanted to make utilise this capability. I am looking for a clear justification which says hunting 1000's of dial-peer is not possible. I'm looking for the limitation.

I didn't understand your statement -'EDIT you can try options ping on the dialpeers depending on your config to turn them on/off based on that.'

Thank you.

[Jaime Valencia]

http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/vb_book/vb_book/vb_9321.html

[Jaime Valencia]

It goes without saying that having 1000's of dial peers is far from a best design, but there is no hard limit that is defined in any platform, the amount of dial peers depends on how they look like, your flash and memory. There is no easy way to tell how many you can configure in a certain ISR, with the current config, without you actually testing it.

[khanfawaz]

Many Thanks Jaime. I was looking for this answer. Yes, of course the design may not be a recommended one, it is always good to have a solution at least. Special requirement = special solution. Yes, this will be tested thoroughly.

Thanks a lot.

[Dennis Mink]

You would need to do these sorts routing decisions ,based on a routing protocol not CUCM or CUCME

CUCM doesnt care how it gets to the far end, it lets your .routing make that descision.

so whatever device has the wireless connection/ethernet connection in the trucks, you would need to configure that so that as soon as ethernet plugs in, that should be your preferred path.

Please rate if useful

[khanfawaz]

Yes, I am exactly looking at a similar solution. I want some experts to say me this is not possible because of so and so reason. There would be 1000s of dial-peers.

Thank you.

[Mohammed al Baqari]

+5 Dennis and Jaime.

As mentioned, you are looking for layer 2/3 function to reroute traffic based on your preferred metrics. CME/CUCM perform application layer functions and they are independent on layer 3 protocol (very rare instances where they depend like rsvp cac).

The only thing I can think about here (thinking loudly) is using SAF/CCD as this is dependent on EIGRP which needs L3 network to establish reachability. Here is whats in my mind.

- Establish SAF/CCD using EIGRP over Wireless network to exchange patterns

- Establish GDPR (this will establish independent of layer 2/3 network)

- Within CSS put SAF-PTs higher than GDPR-PTs which makes SAF patterns searched 1st 

- Now once Ethernet is connected and Wireless disconnected, SAF patterns will die and GDPR PTs will be used as 2nd path in the CSS which will go over ethernet.

Another option is to use H323 over wireless and SIP over Ethernet using different set of loopback on CMEs (but this might not work since you are already using SME and SIP). You can combine this with IWAN/Policy routing where H323 is carried over one network and SIP over another network. 

These are loud ideas but you need to evaluate to make sure that they will work as you want. 

*** FYI cisco is phasing out SAF/CCD and replacing it with GDPR