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

[Emil Ivov <[e-mail]>]

Hey Christer,

On 18.10.12, 14:34, 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.


Emil

-- 
https://jitsi.org