KB article 981218: RTCP Timer Confusion

Sometimes you think your right only to be proven wrong. It’s annoying but I would rather be wrong and correct the information at hand than to let it hang about. After spending some time working through an issue with someone here in VoIPNorm I have had to correct an error in a previous post and in this post I will also expand more on what we found and what you can do to correct it.

I was working with a customer recently and we came across some interesting wording in KB article 981218 that led to some confusion around the setting required to disable RTCP timers on the Gateway side of the Mediation Server. The article shows the setting as “true” in the example, later in the article it states that setting it to true will enable session timers which when reading the article isn't very clear and provides no example of this other setting. The misleading statement:

“If the file does not exist, the default setting for GatewayIgnoreMediaTimeout is set to False. If the Mediation Server is set to ignore media timeouts for its gateway side, the Mediation Server will automatically enable session timers for its interactions with its gateway side peer. If the session timers expire, the call will automatically be cleared. If the Mediation Server has to ignore media timeouts for the gateway side interactions of the Mediation Server but the session timers does not been enabled, a configuration file setting is used. This configuration file setting is called GatewaySessionTimer. This setting contains one of two values: True or False. A False value disables session timers for gateway side interactions.”


This statement should read:

"If the file does not exist, the default setting for GatewayIgnoreMediaTimeout is set to False.

If the Mediation Server GatewayIgnoreMediaTimeout (RTCP) is set to True the Mediation Server will automatically enable session timers (SIP) for its interactions with its gateway side peer. If the session timers expire, the call will automatically be cleared as per the default behavior. The session timer will expire after 1800 seconds (30 minutes) by default. This configuration file setting to change the default behavior is called GatewaySessionTimer. This setting contains one of two values: True or False. A False value disables session timers for gateway side interactions."


Confused yet. Just to recap why this setting is used. The issue we were trying to solve was with Cisco Unity when you are recording a voicemail message, Unity does not send RTCP packets and therefore the recording stops at 30 seconds when the Mediation server RTCP timers time out. Now that this is disabled a session timer which was previously disabled is now enabled by default. This means that calls between a Cisco IP Phone and Communicator will drop after 30 minutes if the session timer is not disabled. Also see my previous post on the topic for more information.

The error for the RTCP issue from the Mediation server looks something like this:

BYE
sip:chris.norman@rtctest.contoso.com;opaque=user:epid:U_CefZQFsVm9gVJSmY_DWgAA;gruu SIP/2.0
FROM: ;epid=B9723D714F;tag=f823396c4d
TO: ;epid=9277a8242a;tag=6e417bfd42
CSEQ: 1 BYE
CALL-ID: 8110143875c0465ea6add6729c04f800
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 130.42.108.237:1620;branch=z9hG4bK8941dab2
ROUTE:
CONTENT-LENGTH: 0
USER-AGENT: RTCC/3.5.0.0 MediationServer
Ms-diagnostics: 10011;source="Server.RTCTEST.TL.CONTOSO.COM";reason="Media Gateway side stream timeout";component="MediationServer"

To fix this issue the following steps need to be taken:

Step 1: Patch Mediation Server according to http://support.microsoft.com/kb/977937/

Step 2: Alter MediationServerSvc.exe.config file to include the new settings:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="forwardDisplayName" value="True" />
<add key="GatewayIgnoreMediaTimeout" value="True" />
<add key="GatewaySessionTimer" value="False" />
</appSettings>
</configuration>

I have left in the “forwarddisplayname” setting as an example to show how to apply the change when other settings already exist in the file. If the file does not exists you will need to create it as the default setting is false.

Step 3: Reboot mediation server to have setting take effect.

Thanks to Mike D (you know who you are),Nemo and Anon for testing and validating the configuration.

Apologies to all those that read this article and were lost or confused. Hopefully these corrections have cleared the air.

Comments welcomed.

VoIPNorm

23 comments:

  1. Hi,

    send feedback via the form at the bottom of the KB article. Maybe somebody is reading those feedbacks, and will update the article sometime.

    ReplyDelete
  2. Recently we moved all users to High Availability platform for EV. We have 2 Mediation servers OCS 2007 R2 going to Cisco call manager 7.1.
    Servers are patched with that 30 second drop out patch and we have that file in place. However it looks like randomly and most of the time OCS PSTN call drop at 29:28 minutes (my believe is extra 32 seconds is for sip signaling)
    We are repeatedly seeing this drop of PSTN at approximate 30 minutes.

    We do have MTP’s check and access to MRGL

    Looks like something related to SIP sessions-expires timer which I think is of 30 minutes and its getting expired and not refreshing invite. But don’t know for sure. Have you experience or seen this type of issue with random PSTN calls dropping at 30 minutes?

    I do have logs where calls was drop at 29:28 and call continue w/o dropping after 30 minutes.

    Any lead/tips will be useful for this troubleshooting.

    ReplyDelete
  3. This does sound kind of familar. Th issue I encountered was a SIP session refresh timer issue but I am not sure this is what your issue is. It wasn't an OCS problem it was a CUCM problem. The exact setting that was changed I can not remember but that may be a start.

    ReplyDelete
  4. in order to troubleshoot 30 minutes issue discussed above I switched my account to use another mediation server where I don't have latest update of Mediation and don't have this MediationServerSvc.exe.config file in place on this server.And I don't see any issue.

    Where as if I switch my account to use this updated mediation server I see 30 minutes drop out. Both the SIP trunks are configured same going to same subscriber CUCM 7.1 and have access to MTP and MRGL.

    In the MS where I don't have patches
    Session-Expires: 1800;refresher=uas is not included in initial invite and ACK

    whereas in the MS where patches is applied
    Session-Expires: 1800;refresher=uas is included and then drops excatly at 30 minutes. In between 2 updates at 10 minutes are send and then BYE

    For consitency I called same PSTN number from both environment.

    So don't know if it is related to RTCP timer setting and config file or not.

    ReplyDelete
  5. RFC4028 Session Timers
    This SIP standard allows periodic refresh of the SIP sessions through re-INVITE and allows Cisco Unified Communications Manager to determine whether the signalling connection to the remote is still active.

    I am still doing some research into this but I had a similar things with reinvites coming from CUCM being triggered by the session expires as you indicated above. If you can find a away to disable reinvites on the CUCM I would try that.

    ReplyDelete
  6. So if you go to Service paramter configuration in CUCM, there is a setting called SIP session expires timer, change that from 1800 to 86400 or some other number. 1800 is exactly 30 minutes. This will stop the reinvite occuring and just may be fix your issue, fingers crossed.

    ReplyDelete
  7. Thanks Chris for your comment. However if you extend SIP expiry to 24 hrs then if for any reason call is hung/lost then Bye will not be send for 24 hrs keeping that call active.

    With my old mediation server where there are no patches but still integrated to same CUCM the sequence is getting followed properly

    For Ex Call starts at time 0 (T0), then next update is sent at time (T10). At T15 I get reinvite from CUCM so again the timer starts thinking it is T0 and thats how call progress.

    But in new MS server where patches are applied, call starts at T0, update is sent at T10 but I don't see any invite coming at T15 and next update is sent at T20 and then BYE at T30 as there is no re-invite coming.

    So i am still debaing myself how can it be CUCM issue.

    ReplyDelete
  8. The patches are designed to ignore RTCP session timers which was a problem with certain Cisco devices and systems like Unity and Phones but I have no idea whether this affects SIP timers also. In saying that the session timers for RTCP may have been overriding the SIP timers keeping your session up. Now that the RTCP timers are turned off it is having an issue with SIP reinvites. This is just a guess. I have no insight into what your seeing on the mediaiton server logs. I would at minimum double the timer to 3600 and see what effect it has if any.86400 was an arbitry figure. You can change it to a couple of hours which most calls are ussually no longer than but really you should test to see if this changes your behaviour.

    ReplyDelete
  9. The 30 minutes issue is by design - we clear sessions by default in that situation. That's for the obvious reason that if there is no RTCP keep alive and no session timer, we could end up with sessions hanging and hogging physical resources wrongly.
    The way to disable the session timer is to set GatewaySessionTimer = false
    Please confirm this solves the issue.
    Note that (without any negatives to my friend Chris) you would get better/faster support via PSS or via the Microsoft forums on Technet.
    Cheers

    ReplyDelete
  10. This comment has been removed by the author.

    ReplyDelete
  11. Good points Nemo and thanks for suggesting an alternate solution.

    ReplyDelete
  12. So after rereading your last comment anon, the fact your not recieving reinvites could mean the oppisite of what I said also, and that is to lower the refresh on the CUCM rather than turn off another timer on OCS as Nemo suggests. Just a thought but well worth trying. I would rather see a timer adjusted rather than turned off if possible.

    ReplyDelete
  13. I opened up case with PSS and we discuss and excatly what we decided to do. We turned off GatewayIgnoreMediaTimeout" value="False. Restart Mediation service and 30 minutes PSTN drop is gone. However what does that mean is "30 second" issue appears. But that's less visible for now as compare to drop out at 30 minutes

    ReplyDelete
  14. Please keep working with PSS as this really isnt a good solution to walk away with. I think you have a couple of options to try that we have mentioned here in the comments. Feel free to ask PSS if they think these could be workable solutions.

    ReplyDelete
  15. so to your point I should try lowering sessions-expires timer on CUCM to 15 minutes or less OR is there any other timer that i should look for in CUCM?

    ReplyDelete
  16. I would look at this timer first as it dictates the reinvite for the SIP session refresh which should in theory refresh the timers on OCS. I am not aware of any other timers on CUCM that may help, not to say there isnt any just that I dont know about them.

    ReplyDelete
  17. First of all thanks to Chris and Captain Nemo for your help. I re-read the technet article 981218.
    As per the article, since I have gatewayignoremediatimeout set to true, it enabled gatewaysessiontimer and set to true and I was having 30 min pstn drop out. in order to disable that I have to add "gatewaysessiontimer" and set to false in the same config file.










    and its been working fine.

    Chris: On your comment at very top of this article "If the Mediation Server GatewayIgnoreMediaTimeout is set to false the Mediation Server will automatically enable session timers for its interactions with its gateway side peer. If the session timers expire, the call will automatically be cleared."

    I think when gatewayignoremediatimeout should be "True".

    Atleast for now one troubleshooting is done.

    ReplyDelete
  18. Thanks for the feedback. I will review the article again. The wording in regards to how they talk about timers is not very clear and now that we have covered your issue I believe it may infact need to read differently. I will adujst this post after a through review. Thanks.

    ReplyDelete
  19. This post has been corrected to show the new information here in the comments. Thanks to Nemo and Anon (who ever you are) for helping with corrections.

    ReplyDelete
  20. Thanks Chris, as always very thorough and generous with your time and considerable skills. Much appreciated.

    ReplyDelete
  21. dear friends,
    i work on a project of ministry of defense in afghanistan so i want to deploy the lync server 2010 bt most all steps are pass successfully bt one setup is fail with web componenets common files error code is 1620,
    any can provide me solution for it.
    reply me in my emil address
    aliakber.sakhi@hotmail.com.
    Thanks alot.

    ReplyDelete
  22. Great Post Chris. I wanted to add/warn users that the current Configuration Guide that Microsoft provides called "Integrating Microsoft Lync Server 2010 and Cisco Unified Communications Manager" http://bit.ly/r7lbYs recommends setting the enabling the 'EnableSessionTimer' setting to True which will cause the 30 minute disconnect issue you discussed in this post when making calls from Lync to CUCM. After changing this setting to false calls are no longer disconnected after 30 minutes. Lync will warn you once you disable the option suggesting that because RTCPActiveCalls and RTCPCallsonHold options are disabled that the EnableSessionTimer should be enabled so that the proper tear down of calls will occur.
    While I would agree with this we can't have calls disconnect after 30 minutes. I am curious is this is an error in the design guide and should be corrected or if the option should really be disabled and the issue addressed another way?
    Regards,
    Dino

    ReplyDelete

Note: Only a member of this blog may post a comment.