Call initiation is slow

[udayakiran]

It has been observed that once call (audio/video) is accepted and hardware permission is provided, the initializing message shows up for a few seconds before the audio/video data gets transmitted. This introduces some void in between the callers once the call has been accepted. This has been observed in the stand alone demo and on jappix as well.

Is there a way to reduce this delay ?

[valeriansaliou]

The delay is normal. It is the network propagation time which allows the client (Chrome/FF) to contact a specified STUN server (default is stun.jappix.com) to discover the client's external IP and an UDP port that the session can be attached to for p2p media flow.

I noticed a severe decrease of resolution performance since latest versions of both Chrome and Firefox, probably because of more checks being done about NAT discovery and all the likes (to increase the odds of stream establishment success in restricted networks). These are only my own speculations.

[udayakiran]

Hi, Thanks for the response.

Just curious, are there any ways to reduce this delay?

• Can anything be done in the code to reduce these checks ?
  OR anything on the server ..
• Like changing the stun server ? or choose stun server based on location ? OR hosting own ? I think stun.jappix.com should be fast enough, But also saw a list of stun servers as mentioned in the code comments of examples - https://gist.github.com/zziuni/3741933

Because, a delay of 7-10 secs is huge and the UX is getting affected. So, thinking aloud if any possibility to reduce this.

Thanks.

[valeriansaliou]

I'm afraid there's not, you can try setting up a STUN server that's nearer to your clients (but still outside their LAN, since it needs to be reached over the Internet to retrieve global IP params).

[udayakiran]

Hi, thanks for the pointer.

We tried switching some STUN servers and things improved. We are able to reduce the delay to about 3 secs. Closing the issue here.

[valeriansaliou]

Great! :)

Just curious, what were the STUN/network conditions that improved things?

[udayakiran]

We had stun choices as below in the ARGS we pass to Giggle. stun.l.google.com seem to be slow and its fallback too.
'stun.l.google.com',
'stun.ekiga.net',
'stunserver.org',

We changed this choices to below. We have users in the US and India mainly. The below STUN order seem to work well.

stun.services.mozilla.com
< our local stun based on ejabberd >
stun.ekiga.net

We will continue tweaking these servers but the important problem for us was to identify the cause. With your help, we could.

Thanks.

[valeriansaliou]

Great, thanks for the insights! :)

[udayakiran]

Thank you. :)

Another observation today - When we give only one stun server in the ARGS it is working faster. Event with 'stun.l.google.com'. Things are faster if we give the STUN servers in the above mentioned order. When we give 'stun.l.google.com' as the first server and another as a fallback, it seems to slow down things. Doubting if anything to fix in the code ?

So, the solution that worked for us is either have only one STUN server configured or use the above mentioned order.

Thanks.

[valeriansaliou]

Well, Giggle delegates the whole list to the browser API. The use of the list is of the responsibility of the browser - not Giggle.

It looks like browsers try to query every STUN before returning a reply in that case - I may be wrong but this is possible.

[valeriansaliou]

I simplified the demo file STUN list in a43a746

[valeriansaliou]

Let me know if things are faster in the demo for you now ;)

[udayakiran]

Hi, yes. Things are very much faster with the simplified STUN list :) . Thanks!