Subject: [MMUSIC] ICE TCP ice-options?

From: Ari Keranen <[email-masked]>
Date: Mon, 4 Jul 2011 19:24:18 +0300

Hi all,

I have now updated the ICE TCP draft [1] according to the WGLC comments, but noticed one more issue worth considering:

Should we have ice-options tag for ICE TCP?

The ICE RFC says [2]:

   Each extension
   or change to ICE is associated with a token.  When an agent
   supporting such an extension or change generates an offer or an
   answer, it MUST include the token for that extension in this
   attribute.  This allows each side to know what the other side is
   doing. 

However, at least my impression is that TCP candidates are not an extension in the sense described in the RFC. TCP candidates were even originally part of the basic ICE. Also the RFC says [3]:

   If its peer is using ICE options (present in
   an ice-options attribute from the peer) that the agent does not
   understand, the agent MUST use a regular nomination algorithm.  

So, having "tcp" ice-option would unnecessarily result in forcing regular nomination even if not supporting the TCP candidates (or some other transport protocol) would simply result in not pairing them with any local candidate.

Hence, I think we do not need "tcp" options tag (and can keep the draft as it is). Opinions?

Cheers,
Ari

[1] http://users.piuha.net/akeranen/drafts/draft-ietf-mmusic-ice-tcp-14.txt
[2] http://tools.ietf.org/html/rfc5245#section-14
[3] http://tools.ietf.org/html/rfc5245#section-8.1.1

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Jul 2011 15:04:24 -0400

> Hence, I think we do not need "tcp" options tag (and can keep the draft as it is). Opinions?

Makes sense. Seems in line with the spirit of ICE extensibility. +1

Go ahead and publish this RFC! :)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca