Strategies to speed up candidate discovery

[Anthony Minessale]

HI,

Are there any discussions in the works to deal with slow setup times.  I see the spec on trickle-ice and I am thinking about ways to use it but, in addition, could there be some more ways to do this and possibly some exposure to JS to control it.  For instance, could Chrome do some pre-determining of which interfaces are ideal to use as candidates so they could put the best foot forward when offering SDP.  I know its not always easy to determine that but in many case it probably is.  I notice a lot of downed and dead-end interfaces added to the candidate search over and over and it seems like there could be a way to figure that out eventually and start to favor paths that are more likely to work such as doing a stun req periodically and pre-determining that you are behind nat and you know the server reflexive data and when the destination is out on the internet that its likely which interfaces lead there.  This is all application specific and falls into the realm of implementation so I am wondering if browsers can learn to do some of this and speed up the call setup time.  Coming from the telephony arena, I know that people are very impatient about call setups and I am pretty sure many webrtc developers are going to use it for phone calls.

I have been playing with Jssip a bit and I have proposed some ideas to them on using existing specs to do trickle-ice over sip but in addition to that I think the browser could probably do more to speed it up and even allow preferences to the JS api similar to how dtls is enabled so you can prefer different models on how to get the candidates.

For reference:

https://groups.google.com/forum/?fromgroups=#!topic/jssip/7gcykkmH8RI

[Anthony Minessale]

*shrug* I guess not? 

[Justin Uberti]

Trickle ICE is the current plan to deal with slow setup times. If you think Trickle ICE is insufficient, please point out the shortcomings so that they can be dealt with in Trickle ICE.

Down and dead interfaces should be ignored by Chrome, but even if not, they are dealt with by Trickle ICE.

*shrug* I guess not? 

--
 
---
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.
 
 

[Anthony Minessale]

That's what I thought I was already doing on Feb 9th by raising the question with a few examples but I can elaborate more.  (I think really this goes beyond the speed concern.) 

Basically I think its important to be proactive about things I know will become an issue with users of VoIP systems like FreeSWITCH/Asterisk/Kamailio while things are still fluid.  I have people complain to me about 500ms call setup times in FreeSWITCH with SIP and we already know early adopters are hoping to use webrtc for phone call type situations.  (I assume that's a given since there is support for DTMF). Considering google voice is already doing this which jingle which is clearly the ancestor for this entire architecture  it seems likely that its on the roadmap for google as well.

So the point of this post was to see if there is any consideration going on for this kind of thing.

I see a lot of postings on various lists from webrtc spec discussions where people trying to raise concerns about compatibility with other SDP based media communication are shut down pretty quickly with (this is not XYZ, this is webrtc).  I understand the excitement about making everything new and trying to eliminate legacy but I really think some consideration needs to made to interact with an existing decade of technology.    

One big shortcoming to point out is that the current behavior completely reveals your entire network topology to anyone you try to call.

There is no way to configure which interfaces you want to advertise to the callee so you end up sending them all.

That may be enough to outlaw the use of webrtc in a cooperate environment where it may have been ok to advertise the public mapped port etc but will not tolerate offering all the ip of every interface. 

Additionally, there is a high likelihood that a large percentage of PC will have a bunch of interfaces that will never work or will all reach the remote host by virtue of the same NAT router even though they really can't reach it normally and every call will repeat the pointless attempts to send ice candidates over these interfaces. 

 Trickle ICE helps but its more challenging for situations where you convert the webrtc sdp to something like SIP where most stuff is not designed around getting the network ip and port later on in the call setup.

If someone is designing an application where the page/js code is loaded from a server on the internet, the dest ip where calls will go would already be known and it would be possible to do some of the preferences in advance when the page loads to come up with a working ip strategy.  We already have tons of ways to do this so it seems logical to save the harder strategy for the ones that cannot be solved with traditional practices.

This is just a discussion really, I am not requesting any particular feature etc.

I've already opened a bug in chrome because it sends candidates with 0.0.0.0 ip or that are down.  This just adds to the time it takes to generate candidates.  Its been acknowledged that its not right to offer downed interfaces.

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_...@hotmail.com
GTALK/JABBER/PAYPAL:anthony....@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org
googletalk:conf...@conference.freeswitch.org
pstn:+19193869900

[kapejod]

Hi,

to ease the pain for calls going from WebRTC to SIP you could just skip the ICE candidate gathering completely.

That is what we do on our WebRTC-SIP-interworking gateway.

Most likely the SIP destination will require some sort of RTP/SRTP/DTLS translation anyway and will not support STUN/ICE, 

so you will be in the middle anyway and you can just play the good old symetrical RTP game with the WebRTC endpoint.

best regards

Klaus

[Anthony Minessale]

Except in my case when I am actually implementing the webrtc enabled sip endpoint that will probably end being used by everyone else for said translations. 

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/Dtl3sKeu7_Q/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[parul singhal]

Hello Anthony,

I want to disble ICe implemetation in webRTC code, becoz for our netwrok we dont need IP to be translated. Can u pls suggest code changes so that i can disable ICE and hardcode IP address for communication.

Thanks.

MSN:anthon...@hotmail.com
GTALK/JABBER/PAYPAL:anthony.mine...@gmail.com

IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference

sip...@conference.freeswitch.org
googletal...@conference.freeswitch.org
pstn:+19193869900

[Anthony Minessale]

code changes in what?

To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/Dtl3sKeu7_Q/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm

MSN:anthony_...@hotmail.com
GTALK/JABBER/PAYPAL:anthony....@gmail.com

IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference