Verifying and Troubleshooting SRST
To verify your SRST configuration, you should initiate a failover condition and thoroughly test typical calls and features. To minimize the impact to operations, follow these steps to create a test bed:
|
Step 1. |
Create an SRST reference.
|
|
Step 2. |
Create a new device pool using the SRST reference from Step 1. All other parameters should match your existing device pool that you used at the remote site.
|
|
Step 3. |
Assign the new device pool to IP phones for testing. You should test with at least three IP phones. If you are implementing COR, you need at least one IP phone per incoming COR list.
|
|
Step 4. |
If no IP phones exist, or if you are testing an MGCP gateway, add a null route to CallManager.
ip route 10.1.10.0 255.255.255.0 null0 |
|
Step 5. |
If IP phones do exist, place the test phones in their own VLAN. Create an extended access control list (ACL) to block traffic from this VLAN to the CallManager addresses.
|
Note
To fully test MGCP gateways, you need to invoke MGCP Gateway Fallback. This impacts all IP phones and should be planned accordingly.
The most useful tools to troubleshoot SRST are the show ephone and debug ephone commands. These commands show any registration issues. SRST issues are commonly related to the dial plan. To troubleshoot dial plan issues, use the debug voice dial peer command. For ISDN circuits, use debug isdn q931.
The debug voice ccapi inout command can also be useful, but this debug generates significant output. You should use this as a last resort.