Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle - ice-options

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Feb 2018 19:38:26 +0000

Hi,

It seems like I missed this conversation (thanks to Ari for reminding me).

5245bis does talk about ice options, but in my opinion the text in Section 13 needs to be modified, to be more generic.

I suggest the following modification:

OLD:

   First, ICE provides the ice-options attribute.  Each extension or
   change to ICE is associated with a token.  When an agent supporting
   such an extension or change triggers candidate exchange, it MUST
   include the token for that extension in this attribute.  This allows
   each side to know what the other side is doing.  This attribute MUST
   NOT be present if the agent doesn't support any ICE extensions or
   changes.

NEW:

   First, ICE provides the ICE option concept.  Each extension or
   change to ICE is associated with an ICE option.  When an agent supports
   such an extension or change, it provides the ICE option to the peer agent
   as part of the candidate exchange.

(Section 10 already says that the encoding of the ICE option is usage-specific, so I don't think we need to repeat that in section 13.)

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 01 February 2018 22:54
To: Ben Campbell <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle

On 2/1/18 1:51 PM, Ben Campbell wrote:
> 
> 
>> On Feb 1, 2018, at 2:07 PM, Peter Saint-Andre <[email-masked]> wrote:
>>
>> On 1/31/18 9:47 PM, Ben Campbell wrote:
>>> Thanks for your quick response, Peter; this discussion was 
>>> helpful—partially by bringing up a separate but related question 
>>> (more for 5245bis than for ice-trickle):
>>>
>>> Section 13 of 5245bis talks about a series of tokens for 
>>> “ice-options”. But since the ice-options  SDP attribute in no longer 
>>> defined in 5245bis, did we lose the text that says that the ICE 
>>> option needs to be able to carry multiple tags, whatever the 
>>> signaling protocol is?
>>
>> I don't want to speak for the 5245bis authors, but it strikes me that 
>> the exact form of "the ICE option" will depend on the signaling 
>> protocol. That is, it's not necessarily the case that syntactically 
>> the signaling protocol will define a single construct for "the ICE option"
>> that itself can include "multiple tags" - that syntax might be true 
>> for SDP but not other signaling protocols.
> 
> Sure, I guess I meant this more conceptually than syntactically. But 
> if an application supports, for example, no ice, 5245bis, or 5425bis 
> with trickle, then you need to be able to distinguish between those. 
> (Not to mention if they support 5245 legacy as a separate mode.)

Indeed.

>> For instance, in XMPP (for which
>> we still need to update the relevant Jingle transport method [1]), 
>> the fact that an entity supports "ice2" and "trickle" will be 
>> signaled by advertising the 'urn:xmpp:jingle:transports:ice:0' XML 
>> namespace (whereas support for pre-ice2 is signaled by advertising 
>> the older 'urn:xmpp:jingle:transports:ice-udp:1' namespace' defined in XEP-0176).
> 
> IIRC, Jingle assumes trickle if you support ICE, correct?

Yes, that's been the primary data transfer method in Jingle since the beginning.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Feb 2018 12:27:39 -0800

>    as part of the candidate exchange.

LGTM.

Peter