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

[Emil Ivov <[e-mail]>]

Hey Christer,

On 18.10.12, 15:03, Christer Holmberg wrote:
> 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...

Yes, but I already agreed that the term was somewhat abused and we need
to review that. We may probably just switch to calling them ICE
initiation request/response ... or something along those lines.

We will do this in the 01 version which should be coming later this week.

Cheers,
Emil

-- 
https://jitsi.org