Re: Expose capabilities / Allow for IP:Post based connections / Better abstraction

ok, thanks
El 11/07/2013 15:27, "Eric Rescorla" <ekr@rtfm.com> escribió:

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