none
Lync PSTN Timeout fixes

    Question

  • Hi to all,

    Previously in OCS R2 days the Mediation Server 'MediationServerSvc.exe.comfig' file required some simple Hotfixes installed to disable the 30 second & 30 minute timers. These were:

    "GatewayIgnoreMediaTimeout" value="True" &
    "GatewaySessionTimer" value="False"

    as discussed in this thread (thank you voipnorm for this way back last year!)

    Now we are on Lync I am wondering whether these settings are still required in the Lync server? Or has something replaced these fields? We have media bypass disabled and are using a standalone Mediation server in our live environment and as a matter of course I added these settings to the new Lync Mediation Server. We have been happily working but an OCS customer called our Response group this week and was cut off a couple of times (the first time we have experienced it)

    I've tracked it down and I believe the Lync Med is at fault:

    Med Server advising:

    "State: StreamStateTimeout, Reason: Endpoint"

    in one message then in the next:

    "Rtcp timer is not disabled and Mediation Server encountered a gateway media stream timeout."

    It feels strange that only this week we have encountered it as we upgraded at least a month ago, and to my knowledge we only observed this from a call originating from an OCS environment calling a number via our SBC Gateway. I'm still investigating to see whether the call was cleared by our SBC's but initial diagnostics shows it wasn't, and since starting ethereal traces I've not had the issue anymore (following the removal of these OCS R2 RTCP settings).

    I have left the RTCP settings off the current settings to ensure in the live environment there are no issues and so far after this evenings testing calls are working well. But for peace of mind and for everyone else out there who may have encountered this I just thought I would ask other admins experiences of this in Lync? Was I being too smart for my own good?! I can't see any other discussions around this so thought I would put it out there!

    Thanks,
    D

    Friday, July 1, 2011 9:45 PM

Answers

  • Cause

    The mediation server is configured to use RTCP. Once the gateway receives a=sendonly or a=inactive in the SDP, it doesn't send any media traffic (no RTCP). The server ends the connection with "Rtcp timer is not disabled and Mediation Server encountered a gateway media stream timeout."

    Resolution

    Set the mediation server setting with following switch to disable RTCPActiveCalls and RTCPCallsOnHold.

    Set-CsTrunkConfiguration -RTCPActiveCalls $false -RTCPCallsOnHold $false

     

    Refer the below article for more information

    RTCPActiveCalls -This parameter determines whether RTCP packets are sent from the PSTN gateway, IP-PBX, or SBC at the service provider for active calls. An active call in this context is a call where media is allowed to flow in at least one direction. If RTCPActiveCalls is set to True, the Mediation Server or Lync Server client can terminate a call if it does not receive RTCP packets for a period exceeding 30 seconds. Note that disabling the checks for received RTCP media for active calls in Lync Server elements removes an important safeguard for detecting a dropped peer and should be done only if necessary.

     

    Default: True

     

    RTCPCallsOnHold - This parameter determines whether RTCP packets continue to be sent across the trunk for calls that have been placed on hold and no media packets are expected to flow in either direction. If Music on Hold is enabled at either the Lync Server client or the trunk, the call will be considered to be active and this property will be ignored. In these circumstances use the RTCPActiveCalls parameter. Note that disabling the checks for received RTCP media for active calls in Lync Server elements removes an important safeguard for detecting a dropped peer and should be done only if necessary.

     

    Default: True

    http://technet.microsoft.com/en-us/library/gg398238.aspx

     


    • Marked as answer by DanTremeer Friday, July 8, 2011 1:10 PM
    Thursday, July 7, 2011 3:09 AM
  • Thanks guys, I found a couple of problems.  One was during a call and the other was Lync to OCS R2 voicemail:  Calls drop after 30 seconds when leaving a voicemail on the OCS R2 system.  Setting RTCPActiveCalls & RTCPCallsOnHold to false resolved this issue.

     

    Drago, makes sense that MS changed how to modify this - This by default is set to false but I expect it will cause issues if it's set to true!

     

    Best Regards,

    Dan


    • Marked as answer by DanTremeer Tuesday, January 10, 2012 12:01 PM
    Friday, July 8, 2011 1:12 PM

All replies

  • I believe this is now controlled by “EnableSessionTimer” parameter i.e. Set-CsTrunkConfiguration -Identity site:Redmond -EnableSessionTimer $False.

    More information can be found here: http://technet.microsoft.com/en-us/library/gg398238.aspx

     

    Drago


    http://www.lynclog.com
    • Marked as answer by DanTremeer Friday, July 8, 2011 1:10 PM
    • Unmarked as answer by DanTremeer Friday, July 8, 2011 1:12 PM
    Saturday, July 2, 2011 11:12 PM
  • Cause

    The mediation server is configured to use RTCP. Once the gateway receives a=sendonly or a=inactive in the SDP, it doesn't send any media traffic (no RTCP). The server ends the connection with "Rtcp timer is not disabled and Mediation Server encountered a gateway media stream timeout."

    Resolution

    Set the mediation server setting with following switch to disable RTCPActiveCalls and RTCPCallsOnHold.

    Set-CsTrunkConfiguration -RTCPActiveCalls $false -RTCPCallsOnHold $false

     

    Refer the below article for more information

    RTCPActiveCalls -This parameter determines whether RTCP packets are sent from the PSTN gateway, IP-PBX, or SBC at the service provider for active calls. An active call in this context is a call where media is allowed to flow in at least one direction. If RTCPActiveCalls is set to True, the Mediation Server or Lync Server client can terminate a call if it does not receive RTCP packets for a period exceeding 30 seconds. Note that disabling the checks for received RTCP media for active calls in Lync Server elements removes an important safeguard for detecting a dropped peer and should be done only if necessary.

     

    Default: True

     

    RTCPCallsOnHold - This parameter determines whether RTCP packets continue to be sent across the trunk for calls that have been placed on hold and no media packets are expected to flow in either direction. If Music on Hold is enabled at either the Lync Server client or the trunk, the call will be considered to be active and this property will be ignored. In these circumstances use the RTCPActiveCalls parameter. Note that disabling the checks for received RTCP media for active calls in Lync Server elements removes an important safeguard for detecting a dropped peer and should be done only if necessary.

     

    Default: True

    http://technet.microsoft.com/en-us/library/gg398238.aspx

     


    • Marked as answer by DanTremeer Friday, July 8, 2011 1:10 PM
    Thursday, July 7, 2011 3:09 AM
  • Thanks guys, I found a couple of problems.  One was during a call and the other was Lync to OCS R2 voicemail:  Calls drop after 30 seconds when leaving a voicemail on the OCS R2 system.  Setting RTCPActiveCalls & RTCPCallsOnHold to false resolved this issue.

     

    Drago, makes sense that MS changed how to modify this - This by default is set to false but I expect it will cause issues if it's set to true!

     

    Best Regards,

    Dan


    • Marked as answer by DanTremeer Tuesday, January 10, 2012 12:01 PM
    Friday, July 8, 2011 1:12 PM
  • Dan,

    I am sorry if I mislead you. I was sure only that this behavior is controlled by CsTrunkConfiguration cmdlet and assumed that the session timer is the control. In any case, Balinder shed light about the issue and this is what counts here... :-)

     

    Drago


    http://www.lynclog.com
    Saturday, July 9, 2011 4:58 AM
  • Cheers Drago, my intention wasn't to say you were wrong, your answer will help a lot of people with similar issues reading this thread.  I just wanted to complete the resolution process so that others who read will hopefully understand all areas around this topic.  Thanks for your additions.

     

    Thanks,

    Dan

    Friday, July 15, 2011 7:12 PM