Re: [rtcweb] Filling in details on "trickle ICE"

[Emil Ivov <[e-mail]>]

Hey Christer,

On 18.10.12, 13:17, Christer Holmberg wrote:
> Hi,
> 
>>>> 4) How does trickle ICE work without “relaxing” RFC3264 O/A? It
>>>> seems like you really want to be able to trickle via updated
>>>> offers that may be generated prior to the corresponding answer
>>>> or reject?
>>> 
>>> One of my comments on the trickle draft was about that. The draft
>>> says that a new offer can be sent "at any time", but my comment
>>> was that it should be according to 3264.
>> 
>> That's not exactly what the draft says. What it does say is:
>> 
>> At any point of ICE processing, a trickle ICE agent may receive
>> new candidates from the remote agent.
> 
> Correct.
> 
> And, it is of course true in one sense, because STUN requests
> creating peer reflexive candidates can of course be received at any
> time :)

True but in the "Trickle ICE" case it would be more common to learn new
candidates through signalling (rather than PR candidates during conn
checks). This is what the text refers to. I agree we should make it
clearer that we do not really mean PR candidates here.

>>> IF we are going to relax 3264 (I really hope we are NOT), it
>>> needs to be clearly described somewhere. We cannot have a number
>>> of I-Ds doing it "on the run"...
>> 
>> I don't see how trickle ICE would require any changes to the O/A
>> model. Candidate trickling semantics are completely separate from
>> those in 3264.
>> 
>> Yes, the 3264 offer may, in some cases, contain a first batch of
>> candidates and the the 3264 may have to be delayed until ICE
>> processing yields valid pairs for every component but that's about
>> it.
>> 
>> Am I missing something?
> 
> I guess the question was whether one, after the first batch of
> candidates have been sent in an offer, should be allowed to send the
> second batch in a new offer - before an answer to the previous offer
> has been received. That would be against 3264.

It would indeed but I am not sure why we would think of additional
candidate drops as offers at all. They are just independent signalling
and are only loosely related to the 3264 semantics.

Of course with SIP we would have a problem caused by the fact that
additional in-dialog signalling is blocked by the 3264 answer. However,
that's specific to SIP and will probably be best served with a SIP
specific solution (e.g. UPDATEs or forcing early answers, or something
else).

Does this make sense?
Emil

> Regards,
> 
> Christer
> 

-- 
https://jitsi.org