On Thu, Jul 11, 2013 at 12:56 AM, piranna@gmail.com <piranna@gmail.com>wrote: > >>>> What about creating by default an internal DataChannel to support this > >>>> things transparently to the user? Or it would be better to be done on > >>>> an upper API as I'm currently doing? Cound candidates being send all > >>>> in one message instead of several ones? > >>>> > >>> > >>> The problem with sending candidates over an internal DataChannel is > that > >>> you > >>> can't set up the channel (assuming it's p2p) until you have exchanged > >>> candidates since the peers can't reach each other yet. It becomes a > >>> chicken > >>> and the egg thing. > >>> > >> Also including them on the offer/answer messages? > > > > > > Nothing prevents that. It all comes down to what available transports you > > have at the moment. If you have done the initial connection setup, you > can > > send sequent offer/answer messages and candidates on a DataChannel. But > > until then, you need some other transport to talk to your peer. > > > I know I can be able to use a DataChannel to send offer/answer and > candidate messages, in fact I'm doing it :-) I was asking about > sending the candidates on the initial offer SDP so a DataChannel could > be used on the first shoot. Seems some time ago it was talked about > support this on the spec, isn't it? This is supported by the spec. In fact, it's how Firefox behaves already, though there's some ambiguity about exactly what triggers ICE candidate gathering in the trickle ICE case which we hope to resolve shortly. -Ekr
Received on Thursday, 11 July 2013 13:27:48 UTC