Lync 2010 hold issue with Cisco Call Manager Express/UC500

Well we went live with Lync 2010 on our customer support desk and as per any go live there were a couple of teething issues so I thought I would blog one of the biggies I got that didn’t show up in testing, but was a nasty on go live.

This seems to apply to CME as well as the UC500 platform but from what I have seen it will most likely apply to Cisco Call Manager as well (I don’t have a CM to play with and test though).

The issue is that when you place somebody on hold after what seemed like a random amount of times the call would get cut off (it normally seemed to cut you off between 30 and 40 seconds or 150-180 seconds from test calls). Investigation showed in the monitoring server that the call failed with a diagnostic code of “32 – Call terminated on mid-call media failure where both endpoints are internal” as shown below.



So after seeing this we can see that the mediation server has sent a “BYE” SIP message back to our CME for some reason.

I did a lot of digging through the Lync traces as well as Cisco debug (Debug CCSIP messages is your friend) and determined that the Lync server seemed to be cutting the call off as it was not receiving RTCP messages from the Cisco CME when the call was placed on hold, this made sense as it would be sensible that Lync cuts a call off if it stops receiving messages from the other end of the trunk to prevent large bills being run up if something has gone wrong!

I did some digging on Google and found that a similar issues happens between OCS 2007R2 and Cisco CM’s Unity voicemail so this confirmed what I was seeing although this was not voicemail the issue was similar so a good jumping off point. The issue then came that the fix for OCS2007 R2 doesn’t work with Lync 2010 and so it was back to the drawing board (for those interested the TechNet article for OCS2007 R2 is here .

So knowing what the problem was I decided to take matters in to my own hands as Google held no results that were close to my issue. Time to dig in PowerShell and have a look at the trunk to see some of the options not being exposed by the GUI.

Under the PowerShell you will find several new options that you can’t define in the GUI, Get-CSTrunkConfiguration is the key to seeing your current configuration. After having a look at the options available I decided to change 2 of them from their defaults there are 3 interesting results worth looking at as shown below:

EnableSessionTimer                  : False
RTCPActiveCalls                     : True
RTCPCallsOnHold                     : True

After having a read on TechNet it looks to me like these were the options previously defined in the XML file in OCS2007 R2 which as Lync depends on a centralised configuration it made sense they were now stored in Lync’s PowerShell instead.

According to TechNet RTCPCallsOnHold is ignored if you are using hold music so there is no point in playing with this if you have enabled Lync’s music on hold like I have (although if your not you might want to set this to false). So according to TechNet if we want to ignore the missing RTCP messages that Cisco have decided not to send back to our mediation server we need to set RTCPActiveCalls to true.

This can be accomplished as follows:

PS C:\>Set-CsTrunkConfiguration –Identity {Name here} -RTCPActiveCalls $False

WARNING: When RTCP active calls or RTCP calls on hold is false, it is recommended that you enable session timer to periodically verify that the call is still active.


As you can see when you type the above command in Lync will tell you this is a bad idea unless you enable the session timer. I tested anyway after doing this to see if the above had any effect on my hold issue and the answer is yes! the problem went away, I now proceeded to make several calls and put myself on hold for 10-15 minutes and received no issues. Time to move on to the last piece, enable the session timer. To do this you need to do the following:

Set-CsTrunkConfiguration –Identity {Name here} -EnableSessionTimer $True

now reading some of the OCS 2007 R2 articles once this is enabled you will start getting your voicemail/hold calls cut off again after 30 minutes, I did a couple of final tests of this issue in Lync 2010 and was unable to reproduce I left calls on hold for well over 30 minutes and they were fine.

Hopefully you will find the above useful if you experience the same issue!! I shall update my connecting Lync 2010 to CME and add a part 3 with this and a couple of other “adjustments” I have found since putting our Lync solution live.



  1. Chris

    Hi James,

    Saw your post on Tehcnet and thought this might be helpful for you as well.

    Something I wrote a few months back. Just be aware that drops after 30 minutes can occur with session timers enabled and that if the problem shows up you may need disable this setting. If you are using Lync audio conferencing I would test this by putting a CME user on mute from the Lync presenter control functions for over 30 minutes and see if the call stays up. Sorry you didnt find this information sooner.

  2. Toby

    I wonder if you have any tip on this:
    I have a SIP Trunk which I use with a Cisco UC540. When external calls from the trunk come in through the AA and are forwarded to VM, I get a busy signal. If the calls go directly to an internal extension and then to VM, there’s no problem. My SP uses g711ulaw and so all my dial peers are hard coded with 711ulaw – no transcoding needed.
    I tested with a UC520 and that worked fine if calls come in through the AA and then go to VM.
    The boxes are configured identical but when I compared ccsip mssg dbgs from both UC520 and UC540, I noticed that right before the reinvite from UC to the external caller, there is an UPDATE message being sent by the 520 (The UC540 just sends an INVITE after a BYE from the AA). It is a requirement from my SP that the session parameters be updated first before the new invite is sent out (since the from, to and via fields will be swapped around or changed).
    Any thoughts what I should be looking for on the UC540 to send out an UPDATE?

    • James Botham


      Yes you can modify your SIP headers, I have a configuration that does this.

      I am not at work this week but can send you over a sample from my config where I am doing this if you still require it.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s