Subject: [Ice] negotiating trickle: always session-level?

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Apr 2017 14:30:34 -0600

Over at GitHub, Taylor posted a note about a comment that Philipp Hancke
made regarding the fact that (in SDP) "a=ice-option:trickle" is allowed
to exist at the media level as opposed to the session level...

https://github.com/ice-wg/trickle/issues/11

Taylor suggested that we probably don't want to negotiate trickle for
some media streams and not others, and proposed the following text:

   An ICE agent compliant to this specification MUST inform the
   peer about the compliance using the 'trickle' ICE option, either
   at the session level or for every media stream at the media stream
   level.

The best place I can find for the relevant text is in Section 3...

OLD

   Even if a signaling protocol does not include a capabilities
   discovery method, a user agent can provide an indication within the
   ICE description that it supports Trickle ICE (e.g., in SDP this would
   be a token of "trickle" in the ice-options attribute).

NEW

   Even if a signaling protocol does not include a capabilities
   discovery method, a user agent can provide an indication within the
   candidate information that it supports Trickle ICE, either at the
   session level or for every media stream at the media stream level
   (e.g., in SDP this would be a token of "trickle" in the ice-options
   attribute).

Note that Taylor adapted his proposed text from the latest version
5245bis, which says:

   An ICE agent compliant to this specification MUST inform the peer
   about the compliance using the 'ice2' ICE option.

The fact that 5245bis defines an ICE option for registration by IANA at
https://www.iana.org/assignments/ice/ice.xhtml#options makes me think
that we need to register an ICE option for trickle, too. Somehow we've
overlooked this so far, but I can add the registration template to the
next version of draft-ietf-ice-trickle.

Peter

---

From: Nils Ohlmeier <[email-masked]>
Date: Sun, 23 Apr 2017 13:42:07 -0700

> On Apr 23, 2017, at 13:30, Peter Saint-Andre <[email-masked]> wrote:
> NEW
> 

Sounds good to me.

Although this makes me wonder how to handle the situation where all m-sections have the ice-options, but one indicates support for trickle and another does not. While technically I could maybe handle this by trickling only for the sections for which the support is announced. I guess webrtc needs to define how to translate this into the "can trickle” flag.

> next version of draft-ietf-ice-trickle.

Yes please.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Apr 2017 14:56:20 -0600

On 4/23/17 2:42 PM, Nils Ohlmeier wrote:
> 
>> On Apr 23, 2017, at 13:30, Peter Saint-Andre <[email-masked]>
>> wrote: NEW
>> 
>> discovery method, a user agent can provide an indication within
>> the candidate information that it supports Trickle ICE, either at
>> the session level or for every media stream at the media stream
>> level (e.g., in SDP this would be a token of "trickle" in the
>> ice-options attribute).
> 
> Sounds good to me.
> 
> Although this makes me wonder how to handle the situation where all
> m-sections have the ice-options, but one indicates support for
> trickle and another does not. 

If I understand Taylor and Philipp correctly, they're saying "don't do
that"; perhaps we need to say MUST NOT?

> While technically I could maybe handle
> this by trickling only for the sections for which the support is
> announced. I guess webrtc needs to define how to translate this into
> the "can trickle” flag.
> 

Good point.

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 24 Apr 2017 11:06:34 -0700

> m-sections have the ice-options, but one indicates support for trickle and
> another does not.

I believe this is exactly what brought up the issue. My suggestion is to
just make this illegal and interpret it as invalid SDP.

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 24 Apr 2017 11:20:06 -0700

> On Apr 24, 2017, at 11:06, Taylor Brandstetter <[email-masked]> wrote:
> 
> Although this makes me wonder how to handle the situation where all m-sections have the ice-options, but one indicates support for trickle and another does not.
> 
> I believe this is exactly what brought up the issue. My suggestion is to just make this illegal and interpret it as invalid SDP.

I’m fine with that. But then I would think it should say MUST NOT like Peter suggested to make it explicit.

Probably I’m missing a point here, but if the trickle ice-options need to be identical across all m-sections what is the difference to a session level attribute then (except that a receiver would need to check for consistency of all attributes and reject)?
Is the reason only that ice-options in general are allowed in m-sections and we can’t mandate the trickle option only to be used at the session level ice-options?

Best
  Nils Ohlmeier

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 24 Apr 2017 18:39:48 +0000

On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 24, 2017, at 11:06, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:

The general reason ice-options are allowed at the media level is to handle distributed media cases — some variety of 3PCC might be aggregating several different end systems’ ICE sessions.

It seems possible this use case can’t be made to work for trickle, in which case we need to have the option aligned across all media sessions.  (So a 3PCC would have to force all its controlled systems back to non-trickle if they don’t all support trickle, but that’d be reasonably straightforward to do.)

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 24 Apr 2017 11:47:29 -0700

> On Apr 24, 2017, at 11:39, Jonathan Lennox <[email-masked]> wrote:
> 
>> 
>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Okay. I guess the other option would be to allow different values in the trickle RFC itself. And then WebRTC for example would have to forbid it to avoid confusion with the PeerConnection canTrickle property.

Best
  Nils

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Apr 2017 21:03:47 -0600

On 4/24/17 12:39 PM, Jonathan Lennox wrote:
>>>     Although this makes me wonder how to handle the situation where
>>>     all m-sections have the ice-options, but one indicates support
>>>     for trickle and another does not.
>>>
>>>
>>> I believe this is exactly what brought up the issue. My suggestion is
>>> to just make this illegal and interpret it as invalid SDP.
>>
>> Probably I’m missing a point here, but if the trickle ice-options need
>> to be identical across all m-sections what is the difference to a
>> session level attribute then (except that a receiver would need to
>> check for consistency of all attributes and reject)?
>> Is the reason only that ice-options in general are allowed in
>> m-sections and we can’t mandate the trickle option only to be used at
>> the session level ice-options?
> 
> The general reason ice-options are allowed at the media level is to
> handle distributed media cases — some variety of 3PCC might be
> aggregating several different end systems’ ICE sessions.
> 
> It seems possible this use case can’t be made to work for trickle, in
> which case we need to have the option aligned across all media sessions.
>  (So a 3PCC would have to force all its controlled systems back to
> non-trickle if they don’t all support trickle, but that’d be reasonably
> straightforward to do.)

Yes, that seems like a possibility (although perhaps unattractive - we
wouldn't get the benefits of Trickle until all the controlled systems
support it).

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Apr 2017 11:35:34 -0600

> wouldn't get the benefits of Trickle until all the controlled systems

How about this change?

OLD

NEW
   Even if a signaling protocol does not include a capabilities
   discovery method, a user agent can provide an indication within the
   candidate information that it supports Trickle ICE using a token of
   "trickle" in the ice-options attribute.  This token MUST be provided
   either at the session level or, if at the media stream level, for
   every media stream (an agent MUST NOT specify Trickle ICE support for
   some media streams but not others).

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 25 Apr 2017 15:22:09 -0700

Sounds good to me.

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 25 Apr 2017 15:33:38 -0700

+1

> On Apr 25, 2017, at 15:22, Taylor Brandstetter <[email-masked]> wrote:
> 
> Sounds good to me.
> 
> On Tue, Apr 25, 2017 at 10:35 AM, Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:
> >>> On Apr 24, 2017, at 2:20 PM, Nils Ohlmeier <[email-masked] <mailto:[email-masked]>
> >>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>>
> >>>
> >>>> On Apr 24, 2017, at 11:06, Taylor Brandstetter <[email-masked] <mailto:[email-masked]>
> >>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>>>