Configure SRST Fallback support on CME

Unanswered Question
Dec 2nd, 2007


Don't quit understand this,


srst mode auto-provision none

srst dn line-mode dual

max-ephone 10

max-dn 10

ip source-address <IP of CME>


Does it mean:

I do not need to configure ephone and ephone-dn, as the config will be download from the CCM in time of working condition.

When the connection broke, it will fallback to the config that it download from CCM previously.

What is the difference between this and call-manager-fallback ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
allan.thomas Sun, 12/02/2007 - 10:51

Essentially CME SRST provides you with more scabilitity or features which you may require in fallback without additional licensing costs.

For example Huntgroups is a key feature, you may have several huntgroups with DIDs which you require fallback for. With CME you can provision the configuration using ephone-phones, and ephone-hunt.

Take a look at the following information taken from this link:-

This feature enables routers to provide call-handling support for Cisco Unified IP phones if they lose connection to remote primary, secondary, or tertiary Cisco Unified Communications Manager installations or if the WAN connection is down.

When Cisco Unified SRST functionality is provided by Cisco Unified CME, provisioning of phones is automatic and most Cisco Unified CME features are available to the phones during periods of fallback, including hunt-groups, call park and access to Cisco Unity voice messaging services using SCCP protocol. The benefit is that Cisco Unified Communications Manager users will gain access to more features during fallback without any additional licensing costs.

A limited number of phone features are automatically detected at the time that call processing falls back to the Cisco Unified CME router in SRST mode, and an advantage of SRST fallback support using Cisco Unified CME is that you can choose to prebuild a Cisco Unified CME configuration that contains a number of extensions (ephone-dns) with additional features that you want them to have for some or all of your extensions. The configurations will contain ephone-dn configurations but will not identify which phones (which MAC addresses) will be associated with which ephone-dns (extension numbers).

Hope this helps



yenlung Mon, 12/03/2007 - 01:24

Still don't really understand.

does it mean, that my ephone-dn and ephone will be mess up when there is a loss in connectivity?

How can I prevent this?


Yen Lung

allan.thomas Mon, 12/03/2007 - 08:07

From your example you have configured auto-provision to none, which essentially means that the DN numbers associated with the phone when fail-over occurs will not be added into the running configuration.

Therefore if you provision your ephone-dn and ephone then you will not have a problem when phones re-register as the ephones will already be tied to an ephone-dn. This unlike provisioning only DNs, as you may find in this instance that when the phone register they will be tied to the wrong number.

I specificially use CME SRST specifically for the huntgroup feature when operating in fallback. I provision all the ephone-dn and ephone information in order create the huntgroup members and appropriate distribution algorithm.



yenlung Tue, 12/04/2007 - 15:46

if i put it to auto-provision to all, then, what is the point of connecting it to the callmanager?

DO i get all the features from the cisco callmanager?

allan.thomas Tue, 12/04/2007 - 16:06

If you require only straight forward fallback, where phones simply require the ability to receive calls and make external calls, then CME SRST is not the option.

In this particular instance configure SRST 'call-manager-fallback'.

With auto-provision all, the ephone-dn's and ephones are created in the running configuration when they re-register. IP Phones will not fallback if you have not configured the SRST reference with CallManager and enabled SRST on the voice-gateway.

If you enable only CME/SRST without registering the gateway within CCM and without specifying a SRST reference for the device pool then you will have to configure the gateway for H323 and full CME, ensuring that you provision TFTP, ringtones, firmware, and both ephone(mac-addresses) and ephone-dn's.

As I have mentioned, SRST Auto-provision all ensure that the mac-addresses are created, and the ephone-dn associate with the mac is inserted into the running configuration.

Prior to this the phones are dependant on CCM for obtaining their firmware and configuration. In the event of SRST, the phones have already loaded their configuration and firmware from CCM, and therefore simply re-register with their existing configuration.




This Discussion