Category Archives: SIP Options

Lync Dial Plan Redundancy

18 Monday Mar 2013

Posted by in Fail over, SIP Options, SIP Response Code Translation

≈ Leave a comment

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:192.168.99.47/Rule_for_SIP_406” -ReceivedResponseCode 406 -TranslatedResponseCode 503

NOTE
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: http://technet.microsoft.com/en-us/library/gg413041.aspx

Event ID 1400 – UM Server

22 Friday Feb 2013

Posted by in event id, Event ID 1400, Exchange UM 2010, SIP Options, UM

≈ Leave a comment

I recently set up Lync 2010 at our offices and ran into a snag with Exchange 2010 SP2 UM voice mail integration. The symptom was the following error in Exchange 2010 UM:

The following UM IP gateways did not respond as expected to a SIP OPTIONS request.


Additional symptoms were that Lync client are unable to call voice mail and users are unable to leave a message for Lync users.

The Culprit

There are 2 possibilities here…
#1
The UM IP gateway in Exchange 2010 which is set up by running the ExchUCUtil.ps1 script doesn’t have a port listed in the configuration. This can be viewed by running:

Get-UMIPGateway | fl


Resolution

Run Set-UMIPGateway -Port 5061


#2
The certificate assigned to the Exchange UM Server Role was not using its own FQDN as the Subject Name (SN), instead the SN was mail.domain.com. Interestingly this was working perfectly well before when we were on SP1…


Resolution
Re-issued a cert with the FQDN of the UM server as the subject name.

SIP Options

20 Wednesday Feb 2013

Posted by in SIP, SIP Options

≈ Leave a comment

For some time now I have seen my Wireshark traces and the event log on the Mediation Server report an issue with regard to SIP Options. I finally was forced to pay attention to this item during a recent deployment.


In the image above the Source IP 10.2.85.31 is the Lync FE and 10.2.85.20 & 10.2.85.21 are both gateways. Lync here sends the SIP Options Request and both gateways reply with OK.

What do SIP Options do?
They are used by Lync to determine if the gateway\SBC is good and ready to accept calls from Lync (no that’s not a typo, this is in relation to outbound calls).

Lync sends a SIP Options request to the Gateway and expects an answer (apparently any answer will do) usually a 200 OK. These messages are sent every 4 seconds. If no response is received for a period of up to 30 seconds the route using this particular gateway is marked as down. 

If its the only gateway Lync will continue to attempt to route calls across it. If there is an alternate gateway available then this will receive the outbound calls instead.

Sometimes you may come across a gateway that sends SIP Option messages to Lync, in this case Lync will stop sending Options messages and instead reply to the options messages it receives with an OK. Lync will also send a SIP Option messages every 20 seconds to be sure all is good.

If Lync stops seeing the SIP messages from the gateway it will revert to taking over the role of sending messages in 5 minutes from the last Options message received.