Subject: [MMUSIC] ICE SDP extension-att-name in ICE candidate

From: Roman Shpount <[email-masked]>
Date: Thu, 1 Dec 2016 18:03:25 -0500

Hi All,

The grammar for candidate-attribute in ICE SDP says:

   candidate-attribute   = "candidate" ":" foundation SP component-id SP
                           transport SP
                           priority SP
                           connection-address SP     ;from RFC 4566
<https://tools.ietf.org/html/rfc4566>
                           port         ;port from RFC 4566
<https://tools.ietf.org/html/rfc4566>
                           SP cand-type
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

Is there a registry for ICE extension-att-name? How does one looks up
where extension-att-name
is defined, what it means, and how it is used? Are there any rules
associated with ICE candidate extensions?

As far as I know there are two extension attributes that are commonly used:
"generation" and "network" but I am not sure where these values and their
usage are defined.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 01 Dec 2016 21:21:15 -0500

> "generation" and "network" but I am not sure where these values and their

There is no registry for this extension, as there is none listed under
"Interactive Connectivity Establishment (ICE)" in the IANA protocol
registry.

"extension-att-name" itself is mentioned only in RFC 5245 (ICE) and RFC
6544 (ICE over TCP).

Dale

---

From: Roman Shpount <[email-masked]>
Date: Thu, 1 Dec 2016 23:44:01 -0500

Should we add the registry for these values? Also, should some language be
added on how unsupported ice candidate attributes are handled?

Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 Dec 2016 11:03:15 +0100

> "extension-att-name" itself is mentioned only in RFC 5245 (ICE) and RFC

I would note that any extensions in the ICE space can be negotiated 
using the ICE options. And those have a registry established by:
https://datatracker.ietf.org/doc/rfc6336/

The ICE options registry is here:
http://www.iana.org/assignments/ice/ice.xhtml#options

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roman Shpount <[email-masked]>
Date: Fri, 2 Dec 2016 09:57:14 -0500

Hi All,

First of all, from what I know, candidate extension attributes are being
used without ICE options right now and no requirement to use them only with
ICE options is present in any of the documents.

Second, when offer is generated, it is unknown if remote supports a
particular ICE option, which can result in including both unsupported ICE
options tag and candidate extensions attributes in the offer.

What I really like to see in ice-sip-sdp regarding the ICE candidate
extension attributes is the following:

1. It should be required to publish an RFC defining the ICE candidate
extensions before these extensions are used

2. IANA registry should be established for the ICE candidate extensions.
Otherwise there is no guarantee that the same extended attribute is used
for two unrelated purposes and there is no easy way to see where particular
attribute is defined and what is it suppose to mean.

3. An RFC needs to define the policy on how to handle unknown candidate
extension attributes, which, I assume, should be to ignore them.

4. If necessary a relationship with ICE options should be established.
Alternatively it can be stated that no such relationship is required. I
actually think that candidate extension attributes and ICE options should
be used independently, since including unsupported candidate extension
attribute should not force changes in ICE nomination process the way
unsupported ICE option does.

What I am trying to accomplish here is to make sure that no unknown
undocumented candidate attributes are simply used by some implementations
with no attempt to document them. For instance "generation" and "network"
attributes are used but not defined in any SDP related document, which I
think is wrong.

Regards,
_____________
Roman Shpount

On Fri, Dec 2, 2016 at 5:03 AM, Magnus Westerlund <
[email-masked]> wrote:

> I would note that any extensions in the ICE space can be negotiated using
> the ICE options. And those have a registry established by:

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 2 Dec 2016 16:19:35 +0000

On Dec 1, 2016, at 11:44 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Should we add the registry for these values? Also, should some language be added on how unsupported ice candidate attributes are handled?

5245, and ice-sip-sdp, already says

   The candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs to be added at the end of the attribute.  An
   implementation MUST ignore any name/value pairs it doesn't
   understand.

which I think is fine.

But I agree that an IANA registry for these is probably a good idea.

Note that in addition to the attributes you listed, I also see Chrome sending “network-cost” in its JSEP.  This is presumably draft-thatcher-ice-network-cost.

Roman Shpount

On Dec 1, 2016 9:21 PM, "Dale R. Worley" <[email-masked]<mailto:[email-masked]>> wrote:

Dale
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic