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

From: Matthew Kaufman <[email-masked]>
Date: Wed, 17 Oct 2012 20:40:30 +0000

A few questions raised by this thread:

1)      Did the discussion about “trickle ICE” actually turn into an I-D for (I suppose) MMUSIC to look at?

2)      Are we seriously considering defining the allowed SDP for RTCWEB/WEBRTC by referencing an I-D and not an RFC, or are we going to delay defining the allowed SDP until trickle ICE is in an RFC, or are we going to drop trickle ICE from RTCWEB 1.0?

3)      Is IETF or W3C the right venue for defining the specific SDP that is permitted in the JSEP “setLocalDescription” and “setRemoteDescription” calls (and what errors will be reported when disallowed SDP is passed to those APIs)?

4)      How does trickle ICE work without “relaxing” RFC3264 O/A? It seems like you really want to be able to trickle via updated offers that may be generated prior to the corresponding answer or reject?

Sorry if some of these seem like the answer is obvious, but I think we need to get pretty specific before we start asking major browser vendors to bake some of this logic into mission-critical software.

Matthew Kaufman

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 06:30:36 +0000

Hi Matthew,

>1) Did the discussion about “trickle ICE” actually turn into an I-D for (I suppose) MMUSIC to look at?

http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt

There has been some discussion on the list already.

>2) Are we seriously considering defining the allowed SDP for RTCWEB/WEBRTC by referencing an I-D and not an RFC, or are we going to delay defining the allowed SDP until trickle ICE is in an RFC, or…

I guess the same question applies also to BUNDLE, and potentially to a number of other I-Ds.

>4) How does trickle ICE work without “relaxing” RFC3264 O/A? It seems like you really want to be able to trickle via updated offers that may be generated prior to the corresponding answer or reject? 

One of my comments on the trickle draft was about that. The draft says that a new offer can be sent "at any time", but my comment was that it should be according to 3264.

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"...

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Oct 2012 11:54:16 +0200

Hey folks,

On 18.10.12, 08:30, Christer Holmberg wrote:
> On 17.10.12, 22:40, Matthew Kaufman wrote:
>> 
>> 4) How does trickle ICE work without “relaxing” RFC3264 O/A? It
>> seems like you really want to be able to trickle via updated offers
>> that may be generated prior to the corresponding answer or reject?
> 
> One of my comments on the trickle draft was about that. The draft
> says that a new offer can be sent "at any time", but my comment was
> that it should be according to 3264.

That's not exactly what the draft says. What it does say is:

  At any point of ICE processing, a trickle ICE agent may receive new
  candidates from the remote agent.

> 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?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 11:17:30 +0000

Hi,
 
>>> 4) How does trickle ICE work without “relaxing” RFC3264 O/A? It seems 
>>> like you really want to be able to trickle via updated offers that 
>>> may be generated prior to the corresponding answer or reject?
>> 
>> One of my comments on the trickle draft was about that. The draft says 
>> that a new offer can be sent "at any time", but my comment was that it 
>> should be according to 3264.
>

Correct.

And, it is of course true in one sense, because STUN requests creating peer reflexive candidates can of course be received at any time :)

> 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.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Oct 2012 14:21:02 +0200

Hey Christer,

On 18.10.12, 13:17, Christer Holmberg wrote:
>>>> seems like you really want to be able to trickle via updated
>>>> offers that may be generated prior to the corresponding answer
>>>> or reject?
>>> 
>>> says that a new offer can be sent "at any time", but my comment
>>> was that it should be according to 3264.
>> 
>> At any point of ICE processing, a trickle ICE agent may receive
>> new candidates from the remote agent.
> 
> Correct.
> 
> And, it is of course true in one sense, because STUN requests
> creating peer reflexive candidates can of course be received at any
> time :)

True but in the "Trickle ICE" case it would be more common to learn new
candidates through signalling (rather than PR candidates during conn
checks). This is what the text refers to. I agree we should make it
clearer that we do not really mean PR candidates here.

>>> 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.
>> 
>> 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).

Does this make sense?
Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 12:26:54 +0000

Hi,

>> And, it is of course true in one sense, because STUN requests creating 
>> peer reflexive candidates can of course be received at any time :)
>
> True but in the "Trickle ICE" case it would be more common to learn new candidates through signalling (rather than PR candidates during conn checks). This 
> is what the text refers to. I agree we should make it clearer that we do not really mean PR candidates here.

Sure.

(Remember our previous discussion, though, about PR candidates being enough if the remote peer is ICE lite ;)

>>>> 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"...
>>> 
> 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.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Oct 2012 14:31:04 +0200

On 18.10.12, 14:26, Christer Holmberg wrote:
> Hi,
> 
>>>>>> 4) How does trickle ICE work without “relaxing” RFC3264
>>>>>> O/A? It seems like you really want to be able to trickle
>>>>>> via updated offers that may be generated prior to the
>>>>>> corresponding answer or reject?
>>>>> 
>>>>> One of my comments on the trickle draft was about that. The
>>>>> draft says that a new offer can be sent "at any time", but my
>>>>> comment was that it should be according to 3264.
>>>> 
>>> creating peer reflexive candidates can of course be received at
>>> any time :)
>> 
>> True but in the "Trickle ICE" case it would be more common to learn
>> new candidates through signalling (rather than PR candidates during
>> conn checks). This is what the text refers to. I agree we should
>> make it clearer that we do not really mean PR candidates here.
> 
> Sure.
> 

I do :).

>>>>> 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?
>>> 
>>> 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.
>> 
>> candidate drops as offers at all. They are just independent
>> signalling and are only loosely related to the 3264 semantics.
>> 
>> 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).
> 

Sure, and we agree that the general O/A need not be used for trickle
ICE, right?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 12:34:11 +0000

Hi,

>>> 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).
>> 
> 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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Oct 2012 14:53:09 +0200

Hey Christer,

On 18.10.12, 14:34, Christer Holmberg wrote:
> 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 :)

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 13:03:19 +0000

Hi,

>>>>>> the second batch in a new offer - before an answer to the previous 
>>>>>> offer has been received. That would be against 3264.
>>>>>
> But why? What do we get from trickling via offers and answers other than problems?
>
> Or did you mean that
>
>> but also for JSEP :)
>> 
> 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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 18 Oct 2012 15:58:04 +0200

Hey Christer,

> 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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 18 Oct 2012 07:52:06 -0700

On Wed, Oct 17, 2012 at 1:40 PM, Matthew Kaufman
<[email-masked]> wrote:

> 2)      Are we seriously considering defining the allowed SDP for
> RTCWEB/WEBRTC by referencing an I-D and not an RFC, or are we going to delay
> defining the allowed SDP until trickle ICE is in an RFC, or are we going to
> drop trickle ICE from RTCWEB 1.0?
>

It's fairly normal for an I-D to reference other I-Ds spawned by the
work.  There's an obvious race condition, and a common set of
responses to that.  Typically, if the I-D making the reference is
ready to advance before the one it refers to is published, there's
discussion at that point just prior to IETF Last Call of whether the
reference is stable enough for a down reference.  If it is not,
there's a reference hold at the RFC publication stage (Bill Fenner has
produced some lovely/scary graphs of what can occur with these holds).

Basically, we don't need to decide which path to take now, but it's
clear that paying attention to the drafts in other working groups  is
a good thing for the advancement of our work.

regards,

Ted

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Oct 2012 20:10:31 +0000

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 [[email-masked]]
Sent: Thursday, October 18, 2012 5:53 AM
To: Christer Holmberg
Cc: Matthew Kaufman; Justin Uberti; [email-masked]
Subject: Re: [rtcweb] Filling in details on "trickle ICE"

Hey Christer,

Or did you mean that

Emil

--
https://jitsi.org