SIP Trunking with Lync Server 2010 (calls end at 51min 30sec)

  • Article

I recently worked on a project for a customer who was interested in working with a local SIP trunk provider (ITSP) who is listed on the Microsoft OIP page for Lync Server 2010. We offered four connectivity methods to the client which consisted of the following:

  1. Full IP NAT connection to ITSP
  2. Public IP connection to ITSP
  3. Site-to-site IPSEC VPN connection to ITSP
  4. Layer 2 PVC using ISP link

The customer decided to go with option 1 which meant we provisioned a new public IP and created a NAT to a private IP which was bound to the Lync server. Appropriate firewall rules were set up to permit SIP and RTP/RTCP packets between the two and for the most part everything worked really quite well.

Incidentally, calls made to, or coming from the PSTN (ITSP) are using G.711 as a codec and if you have a reasonably reliable connection with low delay and jitter, you can expect good results.

 

This particular customer had an interesting issue which resulted in their calls being dropped after being active on the phone for 51 minutes and 30 seconds (typically a conference call). After a series of funny looks asking if anyone else as seen this issue, I decided to dig into the Lync Server 2010 trunk configuration settings to see if we can fine tune something. The theory on why this was happening appeared to be related to the RTCP packets being blocked from the ITSP. Unfortunately I didn't have any evidence of this to share here but it makes sense. Looking at the default options for a Lync trunk connection, the following areas of interest are what I focused on:

 

EnableSessionTimer ($true | $false)
RTCPActiveCalls ($true |
$false)

RTCPCallsOnHold ($true | $false)

 

The default option for a trunk in Lync Server 2010 is:

EnableSessionTimer = False

RTCPActiveCalls = True

RTCPCallsOnHold = True

Session timers will apply to a connection even if the trunk setting is "False" (this can occur when the remote side uses them). RTCPActiveCalls refer to the method of sending RTCP packets to determine if the call is still 'alive' or not. If these packets cease, the call is terminated after 30 seconds. The purpose of determining a valid call this way is because the SIP signaling for the call could traverse another path, such as Media Bypass, and/or become interrupted (brief network/device). The same applies to RTCPCallsOnHold but in a slightly different manner. Historically a call on hold without MOH will cease sending RTP packets and drop the peer (some of you may recall this being an issue on SNOM or Cisco sets).

If my theory of RTCP packets being blocked (inbound) or not sent at all, I would think the call wouldn't last very long at all (i.e. no more than about 30 seconds). I attempted to set "EnableSessionTimer" to True but this didn't seem to make a difference. I had to set RTCPActiveCalls and RTCPCallsOnHold to False as well for the issue to go away. Again, in the end, the configuration I went with looks like this:

 

EnableSessionTimer = True

RTCPActiveCalls = False

RTCPCallsOnHold = False

 

Hope this is helpful to some of you out there.