the UC Guys

New Lync 2013 CHM file

Microsoft has released an update to the Lync 2013 .CHM file. 

You can get the new version of the help file here: http://www.microsoft.com/en-us/download/details.aspx?id=35405

 

This update include various feedback to incorrect info in the documentation.

Lync Calls Drop after 30 seconds using ITSP SIP Trunking Providers

I have worked on many Lync Enterprise Voice Implementations that utilize Internet Trunking Service Providers or ITSP for short.  When working with any Microsoft Lync voice integrated product or service it is important to work with vendors that have gone through the certification process via the Open Interoperability Program.  You can find a list of certified providers here.

A common issue I have run into is calls dropping when placed on hold or in call park orbits.  The reason is linked to the the default Lync Trunk Configuration that the SIP Trunk you configure uses.  

Issue

It appears that when a call is on hold or in a call park situation the default trunk settings don’t allow for Real Time Control Protocol (RTCP) Packets to be processed correctly by the ITSP provider.  When RTCP packets are not handled correctly, you generally get undesirable results and dropped calls after a specific lengths of time is no exception.

Lync Default Settings

When you setup a new Trunk or use the Global trunk the default settings the default settings for a Lync Trunk are as follows:

EnableSessionTimer = False

RTCPActiveCalls = True

RTCPCallsOnHold = True

You can look at your Trunk Configuration Settings by opening a Lync Server Management Shell and typing Get-CSTrunkConfiguration. 

PS C:\Users\admin1.ENABLEUC> Get-CsTrunkConfiguration

Identity                                  : Global
OutboundTranslationRulesList              : {}
SipResponseCodeTranslationRulesList       : {}
OutboundCallingNumberTranslationRulesList : {}
PstnUsages                                : {}
Description                               :
ConcentratedTopology                      : True
EnableBypass                              : False
EnableMobileTrunkSupport                  : False
EnableReferSupport                        : True
EnableSessionTimer                        : True
EnableSignalBoost                         : False
MaxEarlyDialogs                           : 20
RemovePlusFromUri                         : False
RTCPActiveCalls                           : False
RTCPCallsOnHold                           : False
SRTPMode                                  : Required
EnablePIDFLOSupport                       : False
EnableRTPLatching                         : False
EnableOnlineVoice                         : False
ForwardCallHistory                        : False
Enable3pccRefer                           : False
ForwardPAI                                : False
EnableFastFailoverTimer                   : True
EnableLocationRestriction                 : False
NetworkSiteID                             :

 

Corrective Measure

In the testing I have done I found I needed to set the following options in order to allow calls to be placed on hold without being dropped.

EnableSessionTimer = True

RTCPActiveCalls = False

RTCPCallsOnHold = False

You can do this by using the Set-CsTrunkConfiguration cmdlet

Set-CsTrunkConfiguration -EnableSessionTimer $True   -RTCPActiveCalls $false -RTCPCallsOnHold $false

From the technet definition of the above parameters it appears the enabling of the SessionTimer parameter is required likely because the ITSP is not providing this during the call.  The RTCPActiveCalls and RTCPCallsOnHold setting to false disables the Mediation Server from being able to terminate a call if it does not receive RTCP packets for a period exceeding 30 seconds.  These settings needed to be disabled or calls would drop after 30 seconds in my testing.

If anyone else has any other experiences or behaviors with dropped calls after a certain amount of time using an ITSP I would love to hear about them. 

 

 

 

Technorati Tags: SIP Trunking,Dropped calls,ITSP,Lync Enterprise Voice

Lync Mobile 2013 on Windows Phone fails to sign on using Wi-Fi

I have come across this scenario in two customer deployments now whereby a user attempts to sign onto Lync Mobile 2013 using a Wi-Fi only connection on their Windows Phone the first time they connect to Lync on their mobile device.  It simply does not work.  Once the user signs on from a cellular data connection either by disabling Wi-Fi or when out of range, the user can then come and go from their office as they please and sign in and out of Lync without any issues. 

This behavior does not occur on IOS devices in the testing I have done.  I cannot comment on Android devices as of yet.

In all customer deployed scenarios the Microsoft guidance was strictly followed using a proper reverse proxy and defining the DNS records properly.  See Technical Requirements for Lync 2013 Mobility on TechNet for more details.  As well the use of the Lync Connectivity analyzer showed successful testing of the Lync Mobile requirements in these environments.

If anyone else has seen this experience please feel free to comment.   I will provide more info as I get it.  Perhaps someone from the Microsoft Lync Product Group can comment on this behavior.

To try this in your environment (assuming the Mobility guidance was followed) clear your Lync 2013 Mobile on WPE sign in info, disable your cellular data connection and attempt to sign on. 

Reviewing the logs shows the correct attempts but fails with the following errors: 

I have highlighted the interesting info to look at:

2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/77:Starting CUrlRedirectAndTrustResolver with url = https://lyncdiscoverinternal.domain.com/?sipuri=sip:[email protected], maxHops = 10
2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/201:CUrlRedirectAndTrustResolver::processUrl called with url = https://lyncdiscoverinternal.domain.com/, hopCount = 0, maxHops = 10
2013-11-05 18:07:53.899 Lync[2196:2200] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/610:UrlRedirectAndTrustResolver complete with url = https://lyncdiscoverinternal.domain.com/, Hops = 0, status = S0-0-0
2013-11-05 18:07:53.899 Lync[2196:2200] INFO TRANSPORT CCredentialManager.cpp/176:getSpecificCredential for serviceId(4) returning: credType (1) signInName () domain () username () password.empty() (1) certificate.isValid() (0) privateKey.empty() (1) compatibleServiceIds(4)

 

On an IOS device with WiFi only the following successful logon is logged.  This is also logged on a WPE when its working properly:

 

https://lyncdiscover.domain.com/?sipuri=sip:[email protected], maxHops = 10
2013-11-05 19:20:44.332 Lync[106:3ba6b18c] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/201:CUrlRedirectAndTrustResolver::processUrl called with url = https://lyncdiscover.domain.com/, hopCount = 0, maxHops = 10
2013-11-05 19:20:44.332 Lync[106:3ba6b18c] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/610:UrlRedirectAndTrustResolver complete with url = https://lyncdiscover.domain.com/, Hops = 0, status = S_OK (S0-0-0)
2013-11-05 19:20:44.333 Lync[106:3ba6b18c] INFO TRANSPORT CTransportThread.cpp/131:Added Request(UcwaAutoDiscoveryRequest) to Request Processor queue
2013-11-05 19:20:44.333 Lync[106:4d3e000] INFO TRANSPORT CTransportThread.cpp/343:Sent Request(UcwaAutoDiscoveryRequest) to Request Processor
2013-11-05 19:20:44.334 Lync[106:4d3e000] WARNING TRANSPORT CCredentialManager.cpp/317:CCredentialManager::getSpecificCredential returning NULL credential for serviceId (4) type (1)!
2013-11-05 19:20:44.335 Lync[106:4d3e000] INFO TRANSPORT TransportUtilityFunctions.cpp/631:<SentRequest>
GET https://lyncdiscover.domain.com/?sipuri=sip:[email protected]
Request Id: 0x1183fc8
HttpHeader:Accept application/vnd.microsoft.rtc.autodiscover+xml;v=1