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

[Roman Shpount <[e-mail]>]

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 <
[e-mail]> wrote:

> Den 2016-12-02 kl. 03:21, skrev Dale R. Worley:
>
>> Roman Shpount <[e-mail]> writes:
>>
>>> 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.
>>>
>>
>> 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).
>>
>>
> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>