During some DR testing recently I came across an interesting situation that caused calls to fail in the event 1 of my 2 SIP services went down. I wanted to prove than in the event of a SIP provider/network failure, my 2 Front End pools would continue to route calls via the secondary gateway.
To simulate a SIP provider failure I pulled the network cable from the back of the Sonus gateway. I noticed fairly quickly that the gateway reported that the SIP signalling group was down. I then made a test call from a Lync user who’s primary gateway was the one with the simulated failure. The call did not go through! After running some traces I found that the gateway was sending a “408 Request Timeout” message back to Lync. This is a problem because Lync will treat response codes in the 400 range as final, and will not attempt to route the call via any other configured gateways. This actually makes sense as 400 range response codes are client failure responses.
So how do we get around this? If we where to send a server failure response code from the 500 range, Lync will recognise that the server/service is down and attempt to re-route the call. To achieve this we will need to use an outbound translation rule on the Lync signalling group to change a 408 (Client Request Timeout) to a 504 (Server Timeout).
First create a “Message Rule Table” to add the new rule to:
Create a new “Status Line Rule” rule as follows:
Add the rule properties:
In my case I used a regex replacement to achieve a 408 to 504 re-write:
Once your translation rule has been added, go to the Lync “Signalling Group” and add as an “Outbound Message Manipulation”:
To verify the change has had the desired effect I used the Sonus LX tool. You should now see 2 invites – the first is an attempt to route the call via the primary gateway, the second is the call trying the secondary gateway:
The request to route via the down signalling group results in a 408 being generated:
The translation rule in the Lync signalling group translates the 408 to a 504 and sends it to Lync:
Do you know why the SIP stack of Sonus behaves like this? I wonder how did their software pass Microsofts certification program for Lync, if it fails so miserably on the failover testcase. There is no such configuration guideline in the official Sonus doc, even if that smells a mandatory step for all Lync deployments worldwide where there is more then 1 PSTN gateway.
No I cant say I do. I think that strictly speaking the response codes are correct, because the SBC's incoming signalling group (SG) acts as a client endpoint rather than server. The issue with this is that if the destination SG has an issue, its response code is mapped using the default mapping table back to the incoming SG. This does not always have the desired effect depending on what's connected on the other end. In the case of Lync we know it often handles response codes differently to vanilla SIP.
I will say the Sonus support team are amazing, and when there is an issue they will find the answer for you. The SBC's are very powerful and where needed we can add translations to get the desired result. It would however be nice to see a dedicated "LYNC" SG type added with mappings specific to Lync.
I agree: Sonus should add a template that feeds the Lync routing engine with customized SIP error codes, to ensure proper results.
Great Article Andrew,
I found that running the above configuration worked great until I had issues with incoming calls to lineURI that contained 408 and my SIP Invites was also getting manipulated. The LineURI assigned to Lync was tel:+61222222480;ext=480
INVITE sip:[email protected]:5067 SIP/2.0
From: ;tag=c0a86ef5-4651e;sgid=1
To:
To get around this I restricted the message rule table, Applicable Messages from “All Messages” to “Select Messages”. This allowing the manipulation to the message type that I wanted. E.G 408 Request Timeout etc
Hey Arran, thanks very much for taking the time to post your solution!
Would the same have been achieved if you used Regex rule: “408 Request Timeout” rather than just “408” to “504 Time Out”?
I don’t actually know off the top of my head sorry. Did you try and it didn’t work? Any reason not to just use the status code?