It gets a bit frustrating trying to match gateways to Lync for good functionality. It is even more frustrating when its not a certified gateway.

With this introduction I fire into a new post about gateways, resilience and fail-over options.

Usually when an alternative route exists for fail over one assumes that the trusty SIP options will take care of failing over in the event that a positive response isn’t received from the gateway.

But what if the SIP Options responses are positive and yet there is another issue? Possibly routing beyond the gateway in question…

SIP Options aside, there is another influencing factor that triggers fail over – SIP Error messages!

Lync will not fail over on 4xx SIP Response codes, an error code reporting a 5xx SIP Response is required for Lync to attempt an alternate route.

For example, if a gateway was responding positively to SIP Option requests from the Lync Mediation Server but was unable to route to the ITSP a 408 SIP Response code may be received (Request Timeout).

As this is a 4xx SIP message no fail over will be attempted!!!

All certified gateways usually send the correct response codes as described by Microsoft for fail over. But we are in a world where all things are not perfect and so…we may need to tell Lync to respond differently to a the 408 SIP Response code.

How to do this?
As with all things truly powerful…Lync Powershell of course.
You can set a SIP Response Code Translation Rule per Gateway and below is an example:

New-CsSipResponseCodeTranslationRule -Identity “PstnGateway:” -ReceivedResponseCode 406 -TranslatedResponseCode 503

The Identity MUST be in the format PstnGateway:/
You can check the naming convention in Lync Control Panel Voice Routing – Route – Associated Trunks.

TechNet reference: