cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4737
Views
20
Helpful
7
Replies

failover mechanism for extension mobility ???

hy all

       is there any failover mechanism for extension mobility ??  if so what is the concept and how do we implement this failover mechanism ??

Thanks in advance

Regards

P.Vishvak

2 Accepted Solutions

Accepted Solutions

James Hawkins
Level 8
Level 8

Assuming that you are talking about CUCM Cisco recommend enabling EM on multiple servers and then using a server load balancing device to distribute requests across servers. More detail at the link below:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cmapps.html#wp1189079

In my experience customers are not willing to deploy SLB devices just for this so I normally use round robin DNS to distribute connections to multiple CUCM servers. This has the downside that if one of the servers is down it can take a while to get a response from another but it does offer an acceptable level of redundancy for most customers.

View solution in original post

Hi

Firstly, a second for James post - that's what I do on most installs... a slow response from the round robin DNS is better than a failure. Hopefully at some point Cisco will improve the phone firmware so they fail over quicker; you'll notice if you browse to the round-robin hostname using IE that it always comes back near-instantly even when most of your servers are down.

Secondly - there's a couple of things to understand about EM.

There are two services - 'Extension Mobility' is the actual API that runs on each server. This is what you can start/stop from feature services in serviceablity. If you stop this on a server, the actual EM webpage/web service (which is found on the 'network' services page in CUCM serviceability) knows which servers are running the EM API, and can fail over automatically. So if you stop EM API on the publisher, the EM web service will just use the subcriber EM API. This is what has happened when you have 'stopped' EM.

This is all well and good, but in the case where your publisher is truly down, both the EM web service/web page and the EM API are gone. The key one here is that the EM webpage is gone, and this is the only service that the phones directly connect to - i.e. the target of the phone service URL, specified typically by hostname or IP.

To get around this limitation, you need to use James' solution of round robin DNS, or some other form of load balancer.

Regards

Aaron Harrison

Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

7 Replies 7

Jaime Valencia
Cisco Employee
Cisco Employee

When asking for help you ALWAYS need to provide what you're using and not just the question.

CUCM???? CME???? version????

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

HTH

java

if this helps, please rate

richard.steve
Level 1
Level 1

What do you use? UCCE/UCCX

Which version do you use?

How many clusters do you have?

Give your setup details, such as no. of publishers & subscribers?

Waiting to help you....!

James Hawkins
Level 8
Level 8

Assuming that you are talking about CUCM Cisco recommend enabling EM on multiple servers and then using a server load balancing device to distribute requests across servers. More detail at the link below:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cmapps.html#wp1189079

In my experience customers are not willing to deploy SLB devices just for this so I normally use round robin DNS to distribute connections to multiple CUCM servers. This has the downside that if one of the servers is down it can take a while to get a response from another but it does offer an acceptable level of redundancy for most customers.

hy all

I am using a CUCM 8.5 in a cluster configuration one publisher one subscriber and a unity connection. I am not using any load balancer or any such stuff the phone gets registered properly when using extension mobility.  I am running the services for extension mobility in both publisher and subscriber when i just switch off the services in publisher the extension mobility works fine but when i switch off the publisher as a whole it stops functioning when i am logged in using extension mobility i am not able to log out when publisher is not switched on is there any solutions for this other than using load balancer and what is the normal failover mechanism being used i heard that CUCM 8.5 has a failover solution for extension mobility so what is that please do help.

Thanks in advance

P.Vishvak

Have you tried the solution in the link posted by James?

Try adding the subscriber IP in the Enterprise Parameter section, which by default contains the Publisher IP... Also verify whether the changes gets reflected in subscriber too...

-Steeve.

Hi

Firstly, a second for James post - that's what I do on most installs... a slow response from the round robin DNS is better than a failure. Hopefully at some point Cisco will improve the phone firmware so they fail over quicker; you'll notice if you browse to the round-robin hostname using IE that it always comes back near-instantly even when most of your servers are down.

Secondly - there's a couple of things to understand about EM.

There are two services - 'Extension Mobility' is the actual API that runs on each server. This is what you can start/stop from feature services in serviceablity. If you stop this on a server, the actual EM webpage/web service (which is found on the 'network' services page in CUCM serviceability) knows which servers are running the EM API, and can fail over automatically. So if you stop EM API on the publisher, the EM web service will just use the subcriber EM API. This is what has happened when you have 'stopped' EM.

This is all well and good, but in the case where your publisher is truly down, both the EM web service/web page and the EM API are gone. The key one here is that the EM webpage is gone, and this is the only service that the phones directly connect to - i.e. the target of the phone service URL, specified typically by hostname or IP.

To get around this limitation, you need to use James' solution of round robin DNS, or some other form of load balancer.

Regards

Aaron Harrison

Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

hy guys

thanks a lot for your time hope i would learn a lot more in the comming days and belated wishes for a very prosperous and a happy new year!!!!  take care.

Special thanks to James Hawkins and Aaron Harrison

Regards

P.Vishvak

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: