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.
Have you seen this, should answer a lot of your questions:
First of all you need UMG module to manage E-SRST.
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.
Sorrym just remove the partner from the link:
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.
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....
Sorry about that, it works fine without the partner and you should be able to view it:
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)?
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.
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.
Please rate helpful posts...
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.
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..!
Please rate helpful posts...
Noteworthy Thread regarding UMG roadmap and SRSV announced by Cisco.
Keep in mind that only SRSV and VPIM features of UMG are being EOS/EOL, E-SRST will still remain on UMG.
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?
It is Hardware, Cisco is being tricky :-)
Either NME or SM-SRE module is available:
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.
Just to be clear:
Correct on first 3 points.
For last point the hardware for CME-SRST is the local gateway and no different from traditional SRST, licenses for CME-SRST are inter-changable with traditional SRST. They are not enforced today but you need to purchase them to be entitled to use the feature.
How is the branch office user experience different? (I had thought E-SRST was actually a rebranded Marketing term for CME-as-SRST. Reading through this thread indicates that is not the case. It sounds like CME-as-SRST is yet-another-option.
So, in a centralized delployment with a CUCM cluster at the main campus, (co-located with a Unity Connection cluster) as well as all of the PSTN gateways and a small ISR router at the branch office (with a couple of POTS) my options are:
Or more specifically, if the IP WAN to the branch office fails, and the client is good with routing inbound calls from the PSTN campus GW to Unity Connection until the IP WAN to the branch office comes back up... what should I do?
Correct, E-SRST is different from CME as SRST as explained in previous posts.
E-SRST requires centralized management via UMG module, CME as SRST is basic standalone configuration on the router where you define telephony-service instead of call-manager-fallback and which give you additional options/features you do not get with basic SRST, basically you are running CME as SRST failover.
>>Or more specifically, if the IP WAN to the branch office fails, and the client is good with routing inbound calls from the PSTN campus GW to Unity Connection until the IP WAN to the branch office comes back up... what should I do?
Are your trunks centralized and inboud calls arrive via central site? If so any feature is feasible as it does not make a difference here, if you want them to go to VM they will by default, if you want to re-route the calls through PSTN to the remote site you will need to use forward on unregistered setting on the DNs, either solution has nothing to do with what you do as SRST.
Thanks Chris. Can you please clarify...
Do they both offer the same telephony features? I have heard that you can configure CME-as-SRST to allow phones to dynamically register (and bring their current phone configuration in the event of an IP WAN failure at the branch site). Does it mean that each phone/line need to be preconfigured? From what I had heard, the answer was no. I understood the dynamic piece was that the phone 'brought it's lines/speed dials, etc. with it, when it reregistered with the CME-as-SRST device. If that feature exists, and works, as described here, why would I ever run E-SRST and pay for an additional UMG device?
Sorry for late reply as I was out on vacation, the big advantage of Enhanced SRST is that it brings a lot more information from CUCM/UMG when phone registers with CME/SRST as normal SRST or CME as SRST, for example it defines cor-list based on CSS/PT configuration in CUCM, etc. The idea is that now SRST is fully synchronized with CUCM and you do not have to maintain it separately.