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

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>> 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.
>
> Sure, and we agree that the general O/A need not be used for trickle ICE, right?

Well, I think general O/A SHALL be used - not only for trickle ICE, but also for JSEP :)

(Vanilla ICE is also using general O/A)

Regards,

Christer