The SIP protocol uses a mechanism called a Session Refresh Timer. This is used to ensure the far end is still responding, to identify dropped calls and when far end network is lost. This enabled ‘dead’ calls to be cleared out, rather than hanging around forever in the event of an unclean disconnection.

 

When in a call, the two devices negotiate a timer, and device is nominated as the ‘refresher’, which is responsible for initiating the session refresh, using either an UPDATE or INVITE sip message.

 

If the timer expires without the refresh having been sent and a response received, the call is to be considered as dead and it will be dropped.

 

If the Meeting Server drops the call at this point, it will log a message in the event log with reason “timeout - no refresh received”, or “timeout - no refresh response” depending on wether it was the refresher or not in the call. However, it is possible that the far end might drop the call for the same reason, and if the Meeting Server just receives a BYE message this would show up as a normal disconnect/remote teardown.

 

In order to investigate this further, a good place to start would be to take a SIP trace from both ends of the call - this may show some issues with the session refresh, such as a misconfigured SIP proxy rejecting the refresh for authentication reasons, for example.

 

For Lync calls especially it is important to check that the local contact domain is set in the outbound dial plan rule on the Meeting Server, otherwise the Lync client may not be able to send the refresh. This should be set to the FQDN of the Meeting Server.

 

Last update:

21-May-2019

FAQ ID:

1189