Recently I was caught out with CME-SRST. This issue was ‘awoken’ by an actual failover event for one of the remote sites. When the CUCM solution was initially deployed SRST was tested in full among other services without issues. Phones registered to the SRST Router, tested inbound/outbound calls, voicemail routing to CUC (Head Office), also tested CME features and Media Resources, all these passed with flying colours.

I’m referring to the command “srst mode auto-provision [all , dn, none]” This is what effectively brought undone SRST. Using SRST CME mode is completely fine and I would recommend you configure any SRST Router in this mode, due to the additional features that can be accessed by remote users when in SRST mode. One big gotcha, if you configure the auto-provision mode to be anything other than ‘none’ then this saves the ephone-dn and ephone to the running configuration of the SRST Router.

What does this mean? Exactly what you think it means, the ephone and ephone-dn is now a part of your configuration, and if an ephone-dn is in the running configuration of the router, then the Virtual POTS dial-peer is in an UP state with a host specific dial-pattern [$] beating all others.
So when the remote Site is brought online again, the phones deregister correctly from SRST and register back to CUCM. BUT because the ephone-dn remains in the running configuration…. Yep you guessed it the Virtual POTS dial-peer remains UP. The biggiest issue is when this SRST router is also a local ISDN gateway for the remote site, the inbound calls will match….. the Virtual POTS dial-peer! No calls will ever route to CUCM.

This isn’t so much of an issue if the SRST Router does not terminate calls locally ie ISDN, as the inbound calls will never pass through the SRST router.
You will have to manually delete the ephone-dn’s effectively shutting down the related Virtual POTS dial-peer.

So my recommendation is too always configure SRST with auto-provision none. This ensure the ephone-dns and ephones do not write to the running configuration.

Like I’m mentioned in the beginning of this article, my initial failover tests worked like a charm, but was bitten by this little command.