Lync Trunk Configuration

I've been wanting to post this for a while.  A while back I was involved in a support case that took a while to pinpoint and eventually resolve.  It was an intermittent issue, which I hate.  I used the usual method for troubleshooting and asked for specific examples with date and time stamps as well as caller and callee.  Then got stuck in to the Lync Monitoring server logs delving deep into the guts of each call.  The most frustrating thing was that Lync reported no failure, expected or unexpected, for any of the calls.

The issue reported was that calls which were put on hold seemed to disappear and couldn't be retrieved.  The strange thing was that the person having been put on hold was still on hold.

The Lync solution was pretty standard except for the addition of an Asterisk Free PBX which was providing hold music.  

I know this is not a "supported" solution before you say anything.  But what do you do when there is no other solution for providing consistent hold music and the customer really wants music on hold?  And I also know there are better solutions available now with embedded music on hold on the Aries handsets and gateways with dedicated storage for music on hold and even MOH ports.  This was an early project and these solutions didn't exist.

Anyway, the only characteristic similarity I found for any of these calls and, as it turns out, a lot more calls which weren't reported as problematic was 

"Call terminated on mid-call media failure where both endpoints are internal"

Lync insisted that it was always the outside party that ended the call.  But the error said that the call terminated where both endpoints were internal.  The outside party also insisted that they could still hear hold music so assumed they were still on hold.  Now the penny has dropped.  Lync is dropping the calls because as far as it is concerned, it doesn't have control of the call any more.

Why was this happening?  What you should know is that the Asterisk is connected to Lync via a trunk.  There are a couple of configurable attributes on a trunk that were key in resolving the issue.

Figure 1


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 setting: 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 setting: True

Why were these relevant?  Put simply, Lync thought the calls ended because it wasn't receiving RTCP (RTP Control Protocol) Packets.  RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, packet loss, jitter, and round-trip delay time. Lync and other systems use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.  Because Lync wasn't receiving these packets it simply ended the call by severing the trunk.

By setting these parameters to false it stops Lync from checking for these packets.

In an elevated Lync command shell enter the following:

Set-CSTrunkConfiguration -identity “trunk name” -RTCPActiveCalls $False -RTCPCallsOnHold $False

 You'll get the following warning when you set the configuration.

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.

So as well as the above you need to enable the session timer.

Set-CSTrunkConfiguration -identity “trunkname” -enablesessiontimer $True 

The strange thing is that all three settings essentially check to see if a call is active.  The session timer does it by sending periodic probes to the mediation server and waiting for a reply.  And I've explained what the other does already.  The point is that all three settings have the same goal.  And here we have disabled one and enabled the other.  Microsoft say in the description of the parameter disabling these is a bad thing and should be done only if necessary.  But I wouldn't have to use this setting if the gateway didn't stop sending RTCP packets in the first place.  At least there is a setting to change to fix it.

As soon as I changed these parameters the errors stopped and so did the dropped calls.  We have also since had to change it on the trunk to the PSTN gateway for the same reason.

It also turns out that I am not alone in the issue.  You'll probably find more than a few forums mentioning the same thing.  As I said, I have been wanting to post this for a while.  And I really hope it helps you if you encounter the issue, but also to understand the mechanics of why it is happening in the first place.  I also hope that gateway and SBC manufacturers and SIP providers take note and ensure their products consistently send RTCP packets.

Thanks for reading.

How small is your big business?

There is no question that Lync is a great communication tool.  Pop a name into the search bar to find the person you're after.  Or with skills searching enabled and up to date "MySites" for your users, you can ask Lync who to contact about something and it will suggest the answer.  Lync knows if they are available and shows you in the form of the Presence traffic light.  Hover your mouse over their photo and choose how to reach out.

Gone are the days of hiding behind your inbox.
How many times have you sent an email to someone, hoping for an answer straight away?  You pass them in the corridor hours or days later and ask them about it and get the "I haven't seen that yet" response.  What happens if the person you need an answer from is in a different office, or a different country?  You can't very well pop over and chase a response.  Don't get me wrong, email has its place.  After all it's much faster than writing a letter.

Unlike email, Lync is all about instant communication.  With presence, you can see at a glance if the person you need is available before you ask the question.  Even if the person is on a call you can still send an IM and get some kind of response, even if it is just to say that they'll answer when they get off the phone.  But if you ask a question with a simple answer, 9 times out of 10 you'll get that answer there and then.  Which is fantastic!

As businesses get larger, communication doesn't have to be more difficult.
Back in the old days, companies were small and fit in a single room.  You could just as easily shout over the heads of your co-workers as walk over and ask the question.  Fast forward a bit and the companies were on multiple floors of a big building.  A bit more and now you have regional offices in different cities.  Now the likelihood is that you might have territory offices in different countries, regional offices in different cities in each country and a large head office somewhere with a large workforce on multiple floors in multiple buildings.

Lync brings your workforce into one place.  No matter where your workforce is, as long as they have Lync and an internet connection they are part of the company.  It doesn't matter whether they are at the next desk or the other side of the world.  Wherever they are, you can see if they are available and communicate with them in real time.

Here are a few ways to bring your company closer together.  Assuming you have Lync of course.

1. Send an IM instead of an email.  It doesn't matter where they are 9 times out of 10 you'll get an instant answer.
2. Use skills based searches in conjunction with Sharepoint to find who to contact about a given subject.
3. Tag someone for status change alerts.  You'll get a popup when they go online.  Particularly useful if they are far away or in a different timezone.
4. Update the directory with photos of your staff.  Have you ever wanted to put a face to the name?  Now you can.
5. Have an online meeting.  This way you can get participation from people in different locations.

Lync can work whether you are all in one place or spread out across many.  Whether you have a handful of staff to tens of thousands.  The closer together you can make your staff feel, the more they will work together.

So I say install Lync and make your big business feel small again.