Transfer Delay in Lync Environment

This post covers transfer delay we measured in Lync 2010 environment. Measurement is conducted in a dedicated, unloaded Lync environment we set up to perform this measurement. The Lync environment is constructed from

  • single Lync Standard Edition Front End Server
  • single Lync Mediation Server separated from Front End
  • single Lync Edge Server
  • Lync certified IP gateway: AudioCodes Mediant 1000 (6.20A.043.001) 
  • Lync 2010 x86 client (4.0.7577.4356) 
  • Lync certified IP phones: Aastra 6725ip, Polycom CX600 (both 4.0.7577.4100) 
  • Windows 2008 R2 x64 application server for UCMA application

Transfer delay is measured in the following way: a trusted UCMA application endpoint is dialed which picks up the call and performs UCMA attended transfer to another application endpoint. Meanwhile it measures the time elapsed between the transfer request is issued and the call goes to Established state on the 2nd endpoint the call is transferred to. Transfer delays are calculated as average values over a reasonable large number of test calls.

The following table shows transfer delays measured for Lync users registered from LAN.

Endpoint call is initiated from Average transfer delay [seconds]
Lync 2010 2.27
Aastra 6725ip 2.83
Polycom CX600 2.66

As can be seen transfer delay is above 2 seconds regardless call is originated from Lync or IP phones. Dialing from Lync client results in somewhat smaller delay.

If user registers from Lync client through the Edge Server (remote user) then average transfer delays increases from 2.27 seconds to 4.34 seconds.

Calls originated from PSTN though AudioCodes gateway experience 0.87 second average transfer delay if “Enable Refer Support” is set to “no” on Lync Server trunk. If Refer Support is set to “yes” then average transfer delay becomes above 2 seconds in the same range we measured for IP phones registered on LAN.

Summary

The > 2 seconds average transfer delay for users registered and calling from internal network seems to be significant especially for those ones who spent some time in the traditional, digital PBX aera where sub-second transfer delays were common in this case.

Users with Lync clients registered through Lync Edge Server face a huge average transfer delay (> 4 seconds).

Regarding PSTN calls, transfer delay can be significantly decreased by simply disabling Refer support on Lync trunks. This basically stops propagating the transfer request (SIP REFER) back to the gateway and lets Mediation Server to perform the transfer. Actually, PSTN calls with disabled Refer support on the trunk resulted in the smallest average transfer delay (> 1 second) we experienced during our measurements.

Finally, one more comment for those ones who develop custom middle tier UCMA applications: you need to minimize the number of transfers your application introduces in the call flow. The best idea is to eliminate transfers completely. Sometimes you can use B2B and early media instead. UCMA applications which transfer multiple parties multiple times (e.g. to conferences) might result in terrible user experience: ringback tones for seconds, complaints, decreased service level ….