ice options

[Rajmohan Banavi]

I am trying to inter-op my webrtc stack with the google chrome (v 37). I have the following questions w.r.t chrome implementation.

1. If trickle ice is implemented in my stack, and it is indicated with ice-options as "trickle" in sdp, does the chrome stack understand and interpret it?
2. SDP generated from Chrome mentions ice-options as "google-ice". Is this same as trickle ice or it implements something more than that?
3. In the trickled ice candidates, there is some additional text in addition to candidate information - "generation 0". For eg: a=candidate:3643540446 1 udp 25108223 X.X.X.X YYY typ relay raddr A.A.A.A rport BBB generation 0. What does this additional parameters signify?

Thanks.

[Iñaki Baz Castillo]

2014-09-01 18:28 GMT+02:00 Rajmohan Banavi <rajmoha...@gmail.com>:
> If trickle ice is implemented in my stack, and it is indicated with
> ice-options as "trickle" in sdp, does the chrome stack understand and
> interpret it?

Trickle-ICE is about signaling, and WebRTC is signaling agnostic. It
is just related to how the ICE candidates are sent. When in SDP O/A
world, they are typically sent all together as RFC 5245 states, but in
WebRTC you can send them one by one (as they are discovered by the
gathering process).

Forget the "trickle" parameter in the SDP. In your WebRTC JS
application just get the ICE candidates (onicecandidate event) and
decide whether you want to send them one by one using whatever
signaling protocol you use, or all together with the final SDP
offer/answer.

> SDP generated from Chrome mentions ice-options as "google-ice". Is this same
> as trickle ice or it implements something more than that?

It just means that Chrome *also* supports a "different" version of
ICE, which Google calls "google-ice" but AFAIK it is based on a
previous ICE draft. Forget it. Just don't announce "google-ice" into
your SDP and Chrome will talk "normal" ICE as defined by RFC 5245.

> In the trickled ice candidates, there is some additional text in addition to
> candidate information - "generation 0". For eg: a=candidate:3643540446 1 udp
> 25108223 X.X.X.X YYY typ relay raddr A.A.A.A rport BBB generation 0. What
> does this additional parameters signify?

I think (but not sure) that it is something related to a previous ICE
draft. Just ignore those fields.



--
Iñaki Baz Castillo
<i...@aliax.net>

[Rajmohan Banavi]

Thanks. ICE is mandatory for WebRTC but how about trickle ice, since it is also being adopted by WG as proposed standard?

--

---
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/d/optout.

--

Life is here and now, not yesterday, not tomorrow...!

[Rajmohan Banavi]

Section 4 of trickle-ice draft (page 7) mentions that

usages of trickle for specific protocols would need to either:

   o  Provide a way for agents to verify support of trickle ICE prior to
      initiating a session.  XMPP's Service discovery [XEP-0030] is an
      example for one such mechanism;

   o  Make support for trickle ICE mandatory so that support could be 

      assumed the agents.

   

Since we do not have any mechanism within webrtc for service discovery, I was assuming the second option(mandatory). Given this, Chrome should be attempting a Half Trickle mechansim rather than assuming that the other party supports trickle ice. 

[Iñaki Baz Castillo]

2014-09-02 11:28 GMT+02:00 Rajmohan Banavi <rajmoha...@gmail.com>:
> Section 4 of trickle-ice draft (page 7) mentions that
>
> usages of trickle for specific protocols would need to either:
>
> o Provide a way for agents to verify support of trickle ICE prior to
> initiating a session. XMPP's Service discovery [XEP-0030] is an
> example for one such mechanism;
>
> o Make support for trickle ICE mandatory so that support could be
>
> assumed the agents.
>
>
> Since we do not have any mechanism within webrtc for service discovery, I
> was assuming the second option(mandatory). Given this, Chrome should be
> attempting a Half Trickle mechansim rather than assuming that the other
> party supports trickle ice.

I don't know if I was clear enough in my previous mail.

You are the "specific protocol" builder, so you decide whether your JS
application uses trickle ICE or not. Chrome provides you (the JS
application) with the discovered ICE candidates one by one during the
ICE gathering process (onicecandidate events). And then you (the JS
application) decide whether to signal them all together to the peer or
one by one by using your *own* signaling protocol (SIP, XMPP, custom
amateur JSON based protocol, or whatever).

> Since we do not have any mechanism within webrtc for service discovery

Why not? If you implement a JavaScript XMPP library (over WebSocket
for example) then you *can* implement whatever the XMPP protocol
provides, including the service discovery mechanism. It's up to you.

> Chrome should be attempting a Half Trickle mechansim rather than assuming that the other party supports trickle ice.

Chrome assumes *nothing*. It is your JS code the responsible of
collecting the ICE candidates information provided by the browser and
signaling them to the peer in the fashion you prefer.

[Justin Uberti]

FYI, we are adding a canTrickle property to PeerConnection that will provide the ability to know from SDP signaling whether you should do trickle or not (assuming you don't know from some out-of-band mechanism). Obviously, the initial default is "unknown", so an application that uses canTrickle will do Half Trickle initially.

--
Iñaki Baz Castillo
<i...@aliax.net>

[Rajmohan Banavi]

Thanks Inaki, things are clearer now.