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

[Christer Holmberg <[e-mail]>]

Hi, 

>Oh, I agree wholeheartedly here... in order to support things like trickle ICE it would be enormously helpful to separate the ICE negotiation 
>from the SDP O/A state machine, so that candidates may be added without making them part of an "Offer".
>
>The "Microsoft API proposal" neatly handles the ICE negotiation in a way that is separated from the media negotiation... I suggest we use that 
>method instead of trying to bend SDP O/A all out of shape in order to do trickle ICE.

Sure, between the browser and the JS App we might choose to separate ICE from SDP and O/A completely.

However, the way the trickle-ICE draft is written, I assume it focuses on the interactions between two entities, and what is sent on the wire.

Regards,

Christer




________________________________________
From: Emil Ivov [[e-mail]]
Sent: Thursday, October 18, 2012 5:53 AM
To: Christer Holmberg
Cc: Matthew Kaufman; Justin Uberti; [e-mail]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

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