SRST template and suggestions
Hi there,
I was just reviewing an existing SRST (Survivable Remote site telephony) template that's currently in use by our iptel team to test redudnacy scenarios. Briefly speaking, the overall design is a CUCM cluster with pubs and subs split across 2 data centres; and then branch sites connect to those clusters. The SRST template is being used to test redundancy scenarios. If any experts out there are able to provide some valuable feedback/input into the template that's currently in use so we can test any scenarios that aren't included in it, that will be great help ! Goal is to improvize this existing SRST template.
1. Disable Local Site E1 to ensure call re-routes via core voice gateway
2. Simulate primary call manager failure so that IP phones register to secondary Call Manager
3. Force local gateway to re-register with secondary CM instead of primary CM.
4. Simulate a true outage to see if SRST (Call-Manager-fall back) works
5. Test AAR by limiting the bandwidth in Location so calls are re-routed via PSTN.
6. Test individual E1's by shutting one down and check if calls can be recieved/sent over the other E1.
7. Check UPS power supply by switching off first one/second one turn by turn.
Thanks !
I was just reviewing an existing SRST (Survivable Remote site telephony) template that's currently in use by our iptel team to test redudnacy scenarios. Briefly speaking, the overall design is a CUCM cluster with pubs and subs split across 2 data centres; and then branch sites connect to those clusters. The SRST template is being used to test redundancy scenarios. If any experts out there are able to provide some valuable feedback/input into the template that's currently in use so we can test any scenarios that aren't included in it, that will be great help ! Goal is to improvize this existing SRST template.
1. Disable Local Site E1 to ensure call re-routes via core voice gateway
2. Simulate primary call manager failure so that IP phones register to secondary Call Manager
3. Force local gateway to re-register with secondary CM instead of primary CM.
4. Simulate a true outage to see if SRST (Call-Manager-fall back) works
5. Test AAR by limiting the bandwidth in Location so calls are re-routed via PSTN.
6. Test individual E1's by shutting one down and check if calls can be recieved/sent over the other E1.
7. Check UPS power supply by switching off first one/second one turn by turn.
Thanks !
Ok so lets review this:
1. I am assuming that outbound calls leave the local gateway, thereby disabling the local E1 you force callmanager to look at the next entry in the route-group that is assocaited with the dial pattern that is in the users CSS in order to reroute the call to another gateway. So that is a good test.
2. This test is based on the concept that you have both ccms in a callmanager group with the primary one being the one that is first listed - should be the sub, and then the second callmanager is the backup which should be the pub. Another valid test that is necessary - this requires data connectivity to the backup location.
3. This is based on the idea of either a backup mgcp definition or a secondary dial peer if this is h.323. Another valid test you need to make sure that your gateway will failover. Again, requires data connectivity to the backup cm.
4. Break the data link to test SRST.
a) make sure inbound calls are routed properly
b) make sure outbound cals can be placed locally.
c) ensure all phones accounted for register to the SRST gateway. If you have more phones than what the SRTS gateway will support the additional phones won't register.
5. Again valid test controlled by location bandwidth as stated.
6. This again is controlled similar to line #1 but instead is used locally.
7. Again good check.
That looks like a good plan to me. The only other thing I might add if this is a new location is to test the 911 functionality in order to make sure the correct address is being sent to the psap for emergencies. Not sure if you have that functionality in New South Wales though ;)
1. I am assuming that outbound calls leave the local gateway, thereby disabling the local E1 you force callmanager to look at the next entry in the route-group that is assocaited with the dial pattern that is in the users CSS in order to reroute the call to another gateway. So that is a good test.
2. This test is based on the concept that you have both ccms in a callmanager group with the primary one being the one that is first listed - should be the sub, and then the second callmanager is the backup which should be the pub. Another valid test that is necessary - this requires data connectivity to the backup location.
3. This is based on the idea of either a backup mgcp definition or a secondary dial peer if this is h.323. Another valid test you need to make sure that your gateway will failover. Again, requires data connectivity to the backup cm.
4. Break the data link to test SRST.
a) make sure inbound calls are routed properly
b) make sure outbound cals can be placed locally.
c) ensure all phones accounted for register to the SRST gateway. If you have more phones than what the SRTS gateway will support the additional phones won't register.
5. Again valid test controlled by location bandwidth as stated.
6. This again is controlled similar to line #1 but instead is used locally.
7. Again good check.
That looks like a good plan to me. The only other thing I might add if this is a new location is to test the 911 functionality in order to make sure the correct address is being sent to the psap for emergencies. Not sure if you have that functionality in New South Wales though ;)
Premium Content
You need an Expert Office subscription to comment.Start Free Trial