SIP SRST is different than SCCP SRST

I’m in the process of migrating about 1000 phones from old 794X and 796X SCCP phones over to newer 88XX SIP phones. I’ve even stood up a few clinics (branch offices) with 88XX phones and 44XX routers with MGCP.

The problem? I didn’t know that the SRST configuration is different for SIP phones than it is for SCCP phones. So here I was still loading SCCP SRST configurations onto my routers that would never see a SCCP phone! Oh no!

Alright, lets back track a little bit.

What is SRST? SRST is the survivable remote site telephony feature. Basically the way it works is that it allows your phones to register direct to your router in case of a WAN failure and process calls locally and even to a PSTN connection if one is available to the router, such as an FXO port, PRI, or SIP trunk.

Here is a visual for you to help you understand. On the left, in grey, is our branch office. We have a SIP phone and a router. It has a WAN connection back to HQ where our CUCM is at, and from HQ we have a centralized SIP ITSP. So all branch offices will connect back to HQ like this, and all calls will route through HQ. We also have a single POTS line at least branch office to route 911 calls in case of a failover.

This is our normal structure. Purple represents phone registration, where the phone registers to CUCM. Red represents signaling for a call, and then orange represents the media of the call.

Now, if in any event our phone cannot reach CUCM, if the WAN link breaks on either end, if the CUCM goes down, or if the router at HQ goes down, I need a backup in case there is an emergency and calls need to be made. This won’t be a full scale “normal call flow” in this case, because I only have a single POTS line, but this will allow emergency calls through, and they will have the right address for emergency responders. The reason we use this model is because, in my case, these facilities are medical facilities.

In this next image, you see that there are outages… Our phone can no longer reach CUCM, so where does it go? With SRST configured, our SIP phone will register to the local router, and then utilize the POTS line to route emergency calls. (You can configure yours to route ALL calls, but I just go with emergency calls)

Note – In the above image, I just realized I put an X over the SIP ITSP, and while it’s true that with the SIP ITSP down, calls won’t process, this won’t force phones into SRST. You want to build additional routes into your route group for that branch if the SIP ITSP goes down, because phones will still be registered to CUCM in that case.

So how do I configure this?

I knew you were going to ask that. Well let’s dig in. Now, one note, I’m going to assume you already have a valid router configuration and have set up MGCP, so I’m not going to get into how to do all of that. I’m just focusing on the SIP SRST stuff right now.

So SIP phones, different from SCCP phones, will use SIP protocol to register with the router. Keeping in mind that there are two parts of a SIP trunk, the user-agent and the server. In this case, the phone will be the user-agent and the router will be the server. So the first thing we need to do is configure the router to be able to accept sip registrations.

voice service voip
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
supplementary-service media-renegotiate
sip
registrar server expires max 120 min 60

You can read about the supplementary-service commands at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html. These commands are best-practice according to Cisco.

Next we are going to configure the voice register. The voice register is what tells the router how to configure devices that want to register to it. We have two parts here, the global configuration and then the pool configurations. You can configure multiple voice register pools, but we are just going to configure a single one today.

First let’s start with our global configurations. We will need to set the mode, how many DN’s (max-dn) we are licensed for, and how many phones (max-pool) we are licensed for.

voice register global
default mode
no allow-hash-in-dn
system message "SRST Mode-Emergency Calls Only"
max-dn 10
max-pool 10

Next lets configure our actual pool.

voice register pool  1
id network 10.80.1.0 mask 255.255.255.0
dtmf-relay rtp-nte sip-kpml sip-notify
codec g711ulaw
no vad

We gave this pool the ID of 1, since it’s the only one we are configuring. Next we had to tell the router how to identify the phones. I told it to identify by the network, so I used ID Network 10.80.1.0 mask 255.255.255.0. This means anything in the 10.80.1.XXX network can register, up to our maximum of 10 phones that I have licensed. You can also ID by specific IP address (id ip [ip address] mask [subnet mask]), with the subnet mask being optional, or you can identify phones by the mac address (id mac xxxx.xxxx.xxxx). The reason I went with network is because I have a specific voice vlan, and I don’t want to have to reconfigure the routers voice register every time I replace a phone. Plus my phones are on DHCP, so they could pull a new IP address next week, and then if I identified by IP address, it wouldn’t work.

Assuming your router is connected to CUCM via MGCP, you will want to include this command to ensure it fails over any controlled ports.

ccm-manager fallback-mgcp

Finally, once our phones are registering to the router, we need to tell our router where to send incoming and outbound calls.

Inbound:

Since our only inbound calls will be over the POTS line, which is an FXO port, we will just include a single command to point incoming calls to one of our SRST SIP phones.

voice-port 0/1/0
timing hookflash-out 50
timing guard-out 1000
connection plar [insert DN]
description *** FXO POTS for 911 calls ***
cable-detect

The important command here is connection plar [insert DN]. We are telling that port to send all incoming calls to a specific DN. I also have a few extra commands on the port, one notable command being cable-detect. I recommend having this so you can verify if your POTS line is connected.

Outbound:

By now we should know that in order to get the router to route calls, we need a dial-peer. One thing to note is that we can build dynamic dial-peers through the voice register pool. Look for the alias and translation commands on this document: https://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_configuration_guide_chapter09186a0080557e81.html

But for now we are just going to configure a static dial peer because I always want my 911 calls to route over this POTS, regardless if we are in SRST or not. I’m not going to go through that full configuration, though, just the relevant part to SRST.

dial-peer voice 911 pots
description *** Dial-Peer for 911 calls ***
destination-pattern 911$
port 0/1/0
forward-digits all

And there you have it. We should have a functional SIP SRST router now.

Let’s do a few commands to check the status.

If your phones are currently in SRST:

show sip-ua status registrar // shows what SIP phones and DN's are registered to SRST.
debug voice register errors // good for troubleshooting the SRST process
debug voice register events // good for troubleshooting the SRST process
debug voice dialpeers inout // good for troubleshooting our call routing while in SRST

I hope this has been informative and helpful, please feel free to comment and let me know if I missed anything or if this has helped you!

Leave a Reply

Your email address will not be published. Required fields are marked *