Disabling ICE to speed up call setup, is this a bug?

[Nathan Stratton]

I have been testing with several version of chrome skipping ICE step and sending the SDP without candidates. The IP in SDP is sent as 0.0.0.0, but for us that is not a big deal since our gateway is always on a public IP. Since it deals with legacy, its common for the IP in the SDP to not match source, so media works just fine.

This approach greatly speeds up call setup to under 1 sec and so far has worked with all the NAT setups I have tested. Some have suggested to me that this only works because of a "bug" in Chrome. I know WebRTC mandates ICE, but this "bug" has made users life very happy removing a delay that does not make sense for them.

Are their plans to plug this hole to break media without ICE in cases where it works fine without it? 

-- 

><>
Nathan Stratton                                               Founder, CTO Exario Networks, Inc.
nathan at robotics.net                                     nathan at exarionetworks.com

http://www.robotics.net                                   http://www.exarionetworks.com/

[Mallinath Bareddy]

Nathan,

Can you provide more information how you will able establish the media, even though you disabled ICE in Chrome? Did you provide ICE candidates of your public gateway to Chrome?

FYI we removed delay in ICE candidates gathering in M29.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Nathan Stratton]

On Mon, Jul 22, 2013 at 2:05 PM, Mallinath Bareddy <mall...@google.com> wrote:

Nathan,

Can you provide more information how you will able establish the media, even though you disabled ICE in Chrome? Did you provide ICE candidates of your public gateway to Chrome?

Sure, I modified JsSIP to check for a disableICE flag, if set it basically fires onIceCompleted and uses the local SDP without any candidates. The incoming SDP from our gateway has candidates and of course also uses a public IP. We have another modifications to support different Firefox version and one that modifies incoming SDP to limit the upstream bandwidth used from the client depending on resolution, but nothing else involving ICE is required on the client with the chrome version I have tested with.

 

FYI we removed delay in ICE candidates gathering in M29.

Great! So how does that work? Does it use the SDP without candidates first and then expect a update later after ICE is finished?

[Iwan Budi Kusnanto]

On Tue, Jul 23, 2013 at 2:05 AM, Mallinath Bareddy <mall...@google.com> wrote:
> Nathan,
>
> Can you provide more information how you will able establish the media, even
> though you disabled ICE in Chrome? Did you provide ICE candidates of your
> public gateway to Chrome?
>
> FYI we removed delay in ICE candidates gathering in M29.

Hi Malinath, is it already in chrome 29 beta?

--
Iwan Budi Kusnanto

[kevinde...@googlemail.com]

So you are just sending the SDP without the candidates, you are NOT disabling ICE. Chrome will still gather the candidates and perform the connectivity checks. When your public endpoint receives these checks it can respond, and if a full ICE endpoint will send its own connectivity checks to the learned peer address.

All that is happening is the INVITE is sent earlier. The RTP will still not flow until the ICE connectivity checks have determined at least one candidate pair that can be used.

[Mallinath Bareddy]

Agree, that's what indeed happening. ICE is still being used and it's the only way you can establish p2p connection in Chrome.

So your public server learns Chrome ICE candidates through Peer Reflexive Candidates procedure.

--

[Mallinath Bareddy]

On Tue, Jul 23, 2013 at 10:13 PM, Iwan Budi Kusnanto <i...@labhijau.net> wrote:

On Tue, Jul 23, 2013 at 2:05 AM, Mallinath Bareddy <mall...@google.com> wrote:
> Nathan,
>
> Can you provide more information how you will able establish the media, even
> though you disabled ICE in Chrome? Did you provide ICE candidates of your
> public gateway to Chrome?
>
> FYI we removed delay in ICE candidates gathering in M29.

Hi Malinath, is it already in chrome 29 beta?

 Yes, its in Chrome M29 beta. 

[Nathan Stratton]

On Wednesday, July 24, 2013 4:35:48 AM UTC-5, kevinde...@googlemail.com wrote:

So you are just sending the SDP without the candidates, you are NOT disabling ICE. Chrome will still gather the candidates and perform the connectivity checks. When your public endpoint receives these checks it can respond, and if a full ICE endpoint will send its own connectivity checks to the learned peer address.

All that is happening is the INVITE is sent earlier. The RTP will still not flow until the ICE connectivity checks have determined at least one candidate pair that can be used.

Correct, only one set is needed, so if your talking to a public gateway, just disable looking for them on the client. Sounds like this hack is not going to be needed for much longer, happy to know.

[Ranjit Avasarala]

which file did u make this modification?