Experience(s) with Enhanced SRST vs. Traditional SRST?

[crescentwire]

Hi everyone,

We are looking to gain more insight into the advantages/differences of using Enhanced SRST for remote site survivability in the event of a WAN outage, vs. the more traditional SRST that many of us know and have worked with for quite some time. I know the end-user experience is supposed to be a little more robust and tailored, but beyond that, what are the real benefits?

Also, if anyone can explain their setup, hardware-wise and deployment specifics, as to how their Enhanced SRST setup is configured, I'd appreciate it. I've received a lot of conflicting information about what exactly is needed for an Enhanced SRST deployment, so any information you can provide me here is greatly appreciated.

Thanks very much for your time.

[Chris Deren]

Michael,

Have you seen this, should answer a lot of your questions:

http://www.cisco.com/en/US/partner/prod/collateral/voicesw/ps6788/vcallcon/ps2169/prod_qas0900aecd8028d113.html

First of all you need UMG module to manage E-SRST.

HTH,

Chris

[crescentwire]

Hi Chris,

Looks like I don't have access to view that file. Any way you can provide me the content here (copy/paste)? Or a PDF?

If that's not kosher, don't sweat it. But I'd like to have a look at it all the same.

Thank you.

[Chris Deren]

Sorrym just remove the partner from the link:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/prod_qas0900aecd8028d113.html

Also, remember that "CME as SRST" which has been available for quite some time is not the same as E-SRST, E-SRST requires UMG and does automatic synchronization from CUCM among other things.

HTH,

Chris

[crescentwire]

Chris,

Sorry, but I'm still not able to reach that page via the link you gave me. Removing the partner portion doesn't make a difference. Maybe I can try to have one of my vendors pull the content... humm....

[Chris Deren]

Sorry about that, it works fine without the partner and you should be able to view it:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/data_sheet_c78-678873.html

Otherwise simply search for "Cisco Unified Survivable Remote Site Telephony (SRST) and Cisco Unified Enhanced SRST" on CCO.

Here is the most important part of it:

Q. What is Cisco^® Unified Survivable Remote Site Telephony (SRST) and Cisco Unified Enhanced SRST (E-SRST)?

A. In a centralized Cisco Unified Communications Manager environment, when  IP phones lose connectivity to Cisco Unified Communications Manager  because the WAN is down or the application is unreachable, IP phones in  remote branch offices or teleworker homes lose call-processing  capabilities. The SRST feature provides basic IP telephony backup  services so that IP phones can fall back to the local router at the  remote site when connectivity is lost. SRST takes advantage of existing  Cisco IOS^® Software features to provide basic telephony services such as off-net  calls to 911, calls within a remote site, or calls between sites through  the public switched telephone network (PSTN). The application is ideal  for enterprises for cost-effective deployment of IP telephony in their  remote locations.

E-SRST combines all the benefits of SRST, but also includes the following:

• Enhanced user experience in failover mode by maintaining phone displays and providing full call-control features

• Easy to use GUI interface to provision, monitor, report, and troubleshoot remote sites

•  Automatic synchronization with Cisco Unified Communications Manager for  additions, deletions, and modifications of users and phones

• Calling-rule restrictions continued in failover mode

Q. Is special hardware required?

A. For Cisco Unified SRST, no additional hardware is required. Cisco Unified E-SRST is enabled through Cisco Unified SRST and the Cisco Unified Messaging Gateway.

Chris

[Aaron Harrison]

Hi

I've found that few of my customers really care one way or the other what I configure for them. I've done a few of both types but generally just go traditional by default.

The advantages of the CME-style SRST config is that you can assign more detailed configs, hunt groups, pickups, etc etc, but the trade off is that unless you are blessed with a very static configuration and usage pattern it means you (or in my case my customer who may only be familiar with CUCM rather than CME admin) have to keep the config up to date.

Basic SRST is pretty simplistic, but requires little config and maintenance and performs the intended function of basic telephony as a fallback reasonably well.

Most customers have reliable WANs which means that SRST is rarely invoked, and rarely for any great length of time. If they have less than reliable LANs, they'd typically go for a distributed CME network anyway.

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

[crescentwire]

Thanks, Aaron -- this is really good information.

Our main interest in E-SRST is the rumored ease of setup, relative stability, and rock-solid nature when compared to traditional SRST (historically, we've set up SRST in a remote office, validated it, and then years later when we really do lose our WAN connection, it fails to work properly ... bizarre, but true). As we are building out some new sites at the moment, it's an attractive prospect -- having SRST behave as it's supposed to, and under a different method of setup than we've done it in the past. But, it sounds like it's more or less an improvement for end-users in their experience, and from an overall CallManager-ish experience, given that it really is running an instance of CME on the router. Sounds also like the reliability of your WAN circuit would generally be a good determining factor for choosing one option over the other, so that's good to keep in mind too.

As far as the configuration goes, my understanding is that there needs to be not only the CME-SRST gateway router at the remote office, but also a special module that is installed in a gateway router at the HQ office (where the main CallManager cluster is housed), and it's through that module that communication occurs, configs are pushed down, etc. Is that the way you've deployed it in the past? If not, how?

Thanks again for all your help.

[Aaron Harrison]

Hi Michael

I was referring to the two standard type of SRST config in my post - i.e. 'call-manager-fallback' (standard) and 'telephony-mode' (CME) styles. Probably best to pay more attention to Chris at this point :-)

Chris - It makes me sad to admit that before I read your post I had never even heard or E-SRST. Though it looks like it does what I imagined CME-as-SRST might be capable of when it was first trumpeted by Cisco..!

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

[Steven DiStefano]

Noteworthy Thread regarding UMG roadmap and SRSV announced by Cisco.

https://communities.cisco.com/message/80442#80442

[crescentwire]

Hi Steven,

This is good info. Thank you for posting...

[Chris Deren]

Keep in mind that only SRSV and VPIM features of UMG are being EOS/EOL, E-SRST will still remain on UMG.

Chris

[Steven DiStefano]

Yep,  Good point Chris. 

At a point of confusion I have with Cisco Docs is saying no additional HW is required, but it requires UMG which is a SRE on a new ISRG2, no?   Is that not HW?

[Chris Deren]

It is Hardware, Cisco is being tricky :-)

Either NME or SM-SRE module is available:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps2169/data_sheet_c78-678873.html

Chris

[Chris Deren]

Aaron,

Don't feel bad :-) This is relaitvely new feature and I have yet seen it implemented.  We have done few SRSV implementations with the UMG (which is EOS now) but never E-SRST.  I see the benefit of it and some cases where it would benefit customers, but most customers do not want to invest in SRST capabilities and basic SRST is sufficient for 90% of customers. 

Chris