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

[Christer Holmberg <[e-mail]>]

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.

Sure.

(Remember our previous discussion, though, about PR candidates being enough if the remote peer is ICE lite ;)

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

It is sure that SIP may add its own limitations, but the general O/A is generic.

Regards,

Christer