Conferencing Delay

Probably the 2 most useful features UCMA offers are conferencing and back-to-back (B2B) call. Their popularity mainly comes from the wide range of services which can be implemented based on them.

B2B is useful as it is. It allows applications to remain in the signalling path. Thus you can use B2B to monitor call progress, report different call stages or perform call control. But one might ask why should I use conferencing? Do I need it? What are the pros and cons of using that? Obviously, pros mean the additional opportunities conferencing adds to B2B and cons primarily mean the delay required by conferencing.

Let us take a look at 2 scenarios most widely implemented in contact center solutions to connect callers to agents and let us see some explicit data extracted from a production environment with a single site Lync deployment, a Lync Server 2010 Standard Edition, 20 local agents in a single pool and an AudioCodes Mediant 2000 gateway through which callers can dial in from PSTN. Originated from the simplicity of this Lync environment, delay values measured might be considered as the minimal delays which can be achieved in any Lync environment.

Scenario A: Simple B2B

The first scenario connects caller to agent through a simple B2B call. As mentioned above, this allows monitoring, reporting and performing call control.


Without going into the details the average audio B2B call setup delay measured in the above mentioned environment is 0.7 seconds.

Scenario B: Conferencing + B2B

The second scenario is a little bit more complicated. It uses the combination of B2B and conferencing to connect callers to agents. This allows much more than simple monitoring, reporting and call control. It also allows implementing features like custom hold music, call recording, couching or silent listening to any party.


Scenario B requires setting up a conference, joining and dialing to the conference and connecting caller and agent to the conference through B2B.

The following histogram shows the time required to setup an audio conference, join the conference and dial to the conference.


The next histogram shows the time required to connect caller/agent to the audio conference through B2B.


Thus the overall average delay of Scenario B is 1.08 + 2 * 1.07 = 3.2 seconds. This might be a little bit surprising for those ones who come from the world of traditional TDM based PBX where the overall delay of such a scenario is fairly below one second.

You can decrease this overall delay a little bit by delivering caller and agent to conference parallel or by creating conferences in advance. However, this latter one is not recommended since you might mess up Monitoring Server reports.


The difference between the delay of Scenario A and B is 2.5 seconds. Since each call faces this additional delay service level is generally decreased accordingly.

Turning back to our original question: Should I use conferencing? Well, the answer depends on whether you need to have any of the above listed features which currently requires conferencing and whether you can tolerate the additional setup delay.

Finally, please keep in mind that these values are from a very simple environment with agents using Lync client. Federated environments or agents working through Edge might result in much higher delay values. Delay also increases if agents use IP phones instead of Lync client.