If you watch closely, when you first issue the "ccm-manager config" command it will download via TFTP I believe the xml config file for the router. There it contains quite a bit of information. But I think you are right, there is no phone information. That's one reason why it's a first-come, first-served service. When you program your router with the max-ephone, max-dn statements it prepares a number of pseudo-dial-peers which are waiting for registration. When the phone contacts the router (via SCCP I believe), I believe it gives it all the information the router needs, mainly the DNs associated to that phone. Sorta like auto-reg on a subscriber. The router then populates the dial-peers accordingly.
Q. Do we need to configure a MAC address for SRST mode?
A. No MAC address configuration is needed, if the IP phones are already configured by Cisco CallManager. When the connection to the Cisco CallManager is down, or after the IP phones miss 3 keepalive packet exchanges with the Cisco CallManager, IP phones will register with the SRST router and will also provide the SRST router with all related configuration that is contained in their memory.
What do you mean by "the use of POTS" ? Do you mean FXS/FXO ports? If so I'm not sure. I know that MGCP controlled PRI gateways will rever to H323 when the router looses connectivity to the CallManager.
From the same FAQ:
Q. Can we run MGCP Gateway fallback feature with SRST on the same router in 12.2(11)T?
A. Yes, it's available in 12.2(11)T where MGCP and SRST can coexist on the same router. Without the MGCP Gateway fallback feature, and if you are running FXO ports under MGCP control from Cisco CallManager, then the MGCP ports will not be available and you would have to provide additional FXO ports for use during failover. With the MGCP gateway fallback and SRST feature running on the same router, IP phones can fall back to the SRST router, and analog phones fall back to the same router running MGCP Gateway fallback feature, when WAN links to the Cisco CallManager is down.
I believe that xml config is used only during regular service, not SRST though.
I've restarted my router with the link down and the phones still register to it fine.
Everything the router needs to run as SRST is in the config.
I still have yet to test different power cycle sequences. I've been told that if the router power cycles and then the phones power cycle, the phones do not register. Haven't had a chance to try that yet.
Personally I've witnessed that after a power loss the phones are able to register with the SRST gateway. This was because the phones saves the CallManager registration information (primary CM, secondary CM,...SRST gateway in its memory even after a reset or power loss. For my experience the power loss was not too long (under 5mins) not sure what the impact would have been if the power loss was longer, meaning would the phones still retained the CM registration information in their memory after say 1 hour power loss. We have CM 4.1(3)SR4 and 7970 with latest FW.
Obviously a new phone or a phone that has not downloaded its configuration file from the CM or TFTP server will not be able to register with the SRST because it does not know the IP address of the SRST gateway.
The last used configuratoin is always stored on the phone and is used as the last resort when trying to register to the callmanager. When the phone boots, it gets the IP Address and tries to download configuration from TFTP Server. Incase it is not able to download the configuration nor register to the TFTP Server which it received from DHCP, it uses the last known config to register the a CM.
How long the power loss is should not make a diff. I've seen this work on phones which were not connected for a long time as well
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...