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 why? What do we get from trickling via offers and answers other than problems?
>
> Or did you mean that
>
>> but also for JSEP :)
>> 
>> (Vanilla ICE is also using general O/A)
>
> Not really. At least not always. ICE is quite nicely separated from the media O/A in XMPP.
>
> Both are indeed stuffed together for SIP by 5245 but that's just a design choice that we don't need to stick with. At least I don't see why we would.

I was thinking about 5245, and JSEP, both with use 3264.

You are right that other protocols (e.g. XMPP) also can use ICE. However, you do use "Offer" and "Answer" terminology in your draft, and at least I associate that with 3264...

Regards,

Christer