Subject: Re: [MMUSIC] ice-options attribute: session- and media-level?

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 16 Jun 2018 00:20:19 -0700

Hello All

  Circling back on this topic in making ice-options to be solely Session
Level and given the majority of responses favored Session level, I can make
changes in ice-sip-sdp to reflect the same, unless i hear arguments
otherwise.

Please let me know

Thanks
Suhas

On Tue, Apr 24, 2018 at 12:08 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> > I would prefer disaggregated media to be handled separately and keep
> ice-options a session level attribute.. Dealing with disaggregated media is
> a much bigger issue then just adjusting ice-options.
> > For instance, why ice-options are handled there and ice-lite is
> excluded? I think ice-lite is potentially as big of the problem when
> aggregating media from several sources. Also, I we sure that making singe
> ICE agent
> > dealing with two independent ICE agents does not have any issues? I do
> not think this was examined in sufficient detail.
>
> If you are going to use disaggregated media with ICE, I think there are
> more issues than signalling.
>
> For example, keep in mind that the check lists impact each other (e.g., a
> state change of a pair in list X might impact the state of a pair in list
> Y). How would that work if check lists X and Y are handled by different ICE
> agents?
>
> With ICE trickle, one agent would need to know that candidates the other
> agent(s) is trickling.
>
> Etc.
>
> There would either need to be some "inter-agent communication” mechanism,
> or we would need to "de-couple” how media streams (check lists) depend on
> each other.
>
> So, if people want to specify disaggregated-media-with-ICE, I think it
> should be done as a separate deliverable (possibly in a separate WG).
>
> Regards,
>
> Christer
>
>
>
>
>
> On Mon, Apr 23, 2018 at 12:45 PM, Marc Petit-Huguenin <
> [email-masked]> wrote:
>
>> This was done as a consequence of merging this draft in ice-bis:
>>
>>
>> https://www.ietf.org/archive/id/draft-petithuguenin-mmusic-ice-attributes-level-04.txt
>>
>> There is probably discussions that can be found in the minutes of IETF
>> meetings around that time when the WG agreed to that modification.
>>
>> On 04/20/2018 11:09 PM, Suhas Nandakumar wrote:
>> > I am fine with considering ice-options has session level too. I wonder
>> if
>> > Marc can chime in on considering it as  media level in the ice-sip-sdp.
>> >
>> > On Fri, Apr 20, 2018 at 12:07 PM, Peter Saint-Andre <
>> [email-masked]>
>> > wrote:
>> >
>> >> On 4/20/18 12:37 PM, Roman Shpount wrote:
>> >>> Hi All,
>> >>>
>> >>> I do not think ice-options was ever used as a media level attribute.
>> >>> Only two ice-options defined in IANA registry
>> >>> (https://www.iana.org/assignments/ice/ice.xhtml) are ice2 and
>> rtp+ecn,
>> >>> which are both session level.
>> >>>
>> >>> Furthermore, RFC 5245 section 15.5
>> >>> (https://tools.ietf.org/html/rfc5245#section-15.5,) defined that
>> >>> ice-options attribute is session level only. Thus, ice-options should
>> be
>> >>> kept session level for backwards compatibility.
>> >>>
>> >>> If something more granular then session is needed, I think it should
>> go
>> >>> into candidate extension attribute, not into media level ice-options.
>> >>>
>> >>> Bottom line, I think ice-options should be a a session level only
>> >> attribute.
>> >>
>> >> Agreed.
>> >>
>> >> In the Trickle ICE spec, we also limited the `trickle` option to
>> session
>> >> level only.
>> >>
>> >> Peter
>> >>
>> >>
>>
>>
>> --
>> Marc Petit-Huguenin
>> Email: [email-masked]
>> Blog: https://marc.petit-huguenin.org
>> Profile: https://www.linkedin.com/in/petithug
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Jun 2018 07:58:59 +0000

I hereby let you know: session only
:)

Regards,

Christer

Sent from my iPhone

On 16 Jun 2018, at 9.20, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:

Hello All

  Circling back on this topic in making ice-options to be solely Session Level and given the majority of responses favored Session level, I can make changes in ice-sip-sdp to reflect the same, unless i hear arguments otherwise.

Please let me know

Thanks
Suhas

On Tue, Apr 24, 2018 at 12:08 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

> I would prefer disaggregated media to be handled separately and keep ice-options a session level attribute.. Dealing with disaggregated media is a much bigger issue then just adjusting ice-options.
> For instance, why ice-options are handled there and ice-lite is excluded? I think ice-lite is potentially as big of the problem when aggregating media from several sources. Also, I we sure that making singe ICE agent
> dealing with two independent ICE agents does not have any issues? I do not think this was examined in sufficient detail.

If you are going to use disaggregated media with ICE, I think there are more issues than signalling.

For example, keep in mind that the check lists impact each other (e.g., a state change of a pair in list X might impact the state of a pair in list Y). How would that work if check lists X and Y are handled by different ICE agents?

With ICE trickle, one agent would need to know that candidates the other agent(s) is trickling.

Etc.

There would either need to be some "inter-agent communication” mechanism, or we would need to "de-couple” how media streams (check lists) depend on each other.

So, if people want to specify disaggregated-media-with-ICE, I think it should be done as a separate deliverable (possibly in a separate WG).

Regards,

Christer

On Mon, Apr 23, 2018 at 12:45 PM, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>> wrote:
This was done as a consequence of merging this draft in ice-bis:

There is probably discussions that can be found in the minutes of IETF meetings around that time when the WG agreed to that modification.

On 04/20/2018 11:09 PM, Suhas Nandakumar wrote:
> I am fine with considering ice-options has session level too. I wonder if
> On Fri, Apr 20, 2018 at 12:07 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>>> (https://www.iana.org/assignments/ice/ice..xhtml<https://www.iana.org/assignments/ice/ice.xhtml>) are ice2 and  rtp+ecn,
>>> ice-options attribute is session level only. Thus, ice-options should be
>>> If something more granular then session is needed, I think it should go
>> In the Trickle ICE spec, we also limited the `trickle` option to session
>> level only.
>>
>> Peter
>>
>>

--
Marc Petit-Huguenin
Email: [email-masked]<mailto:[email-masked]>
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

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

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

---

From: Roman Shpount <[email-masked]>
Date: Sat, 16 Jun 2018 07:10:00 -0400

+1

_____________
Roman Shpount

On Sat, Jun 16, 2018 at 3:58 AM, Christer Holmberg <
[email-masked]> wrote:

> On 16 Jun 2018, at 9.20, Suhas Nandakumar <[email-masked]> wrote:
>
> Hello All
>
>>> >>> (https://www.iana.org/assignments/ice/ice..xhtml
>>> <https://www.iana.org/assignments/ice/ice.xhtml>) are ice2 and  rtp+ecn,
>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jun 2018 12:31:47 -0600

On 6/16/18 1:20 AM, Suhas Nandakumar wrote:
> Level and given the majority of responses favored Session level, I can
> make changes in ice-sip-sdp to reflect the same, unless i hear arguments
> otherwise.

I agree with the direction, but is draft-mmusic-ice-sip-sdp the right
place for this, given that ICE options can be used outside of SIP/SDP?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jun 2018 18:38:48 +0000

Hi,

The draft defines the ice-options SDP attribute, so the draft needs to define what type (media and/or session) of SDP attribute it is.

Regards,

Christer

Sent from my iPhone

> On 19 Jun 2018, at 21.31, Peter Saint-Andre <[email-masked]> wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jun 2018 13:40:05 -0600

> The draft defines the ice-options SDP attribute, so the draft needs to define what type (media and/or session) of SDP attribute it is.

At the syntax level, yes. Sematically, however, is it perhaps the job of
the ICE specification to define whether ICE extensions (however encoded
in a using protocol) are session-level or media-level?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jun 2018 22:13:21 +0000

Hi,

To further complicate, it seems like RFC 5245 defines ice-options as a session-level attribute only...

draft-5245bis says:

"Extensions:  New media-stream or session-level attributes (ice-options)."

In addition, draft-5245bis defines new "ice2" ice option. It doesn't say whether it's media or session, but I assume is something that some could consider a session-level.

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 19 June 2018 21:40
To: Christer Holmberg <[email-masked]>
Cc: Suhas Nandakumar <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] ice-options attribute: session- and media-level?

> The draft defines the ice-options SDP attribute, so the draft needs to define what type (media and/or session) of SDP attribute it is.

At the syntax level, yes. Sematically, however, is it perhaps the job of the ICE specification to define whether ICE extensions (however encoded in a using protocol) are session-level or media-level?

Peter

>>>   Circling back on this topic in making ice-options to be solely 
>>> Session Level and given the majority of responses favored Session 
>>> level, I can make changes in ice-sip-sdp to reflect the same, unless 
>>> i hear arguments otherwise.
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jun 2018 16:14:11 -0600

Good catch. So, yes, we need to define this consistently and in the
right places...

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jun 2018 19:37:09 -0400

Peter,

> in a using protocol) are session-level or media-level?

whether session level, media level, or both is required as part of the 
registration of the attribute. It is considered part of the syntax even 
though it isn't part of the ABNF.

Of course the semantics of its use is also tied up in whether it is 
session or media level, and so needs to be described as part of the 
semantics as well.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jun 2018 17:50:06 -0600

On 6/19/18 5:37 PM, Paul Kyzivat wrote:
>>> The draft defines the ice-options SDP attribute, so the draft needs
>>> to define what type (media and/or session) of SDP attribute it is.
>>

Hi Paul,

I guess my concern is this: now that we've decoupled ICE from SDP, we
might lose synchronization between SDP bindings and non-SDP bindings,
which wouldn't be good for interoperability. As I understand it, the
ice-options attribute can include a variety of tokens (e.g., 'ice2' or
'rtp+ecn'). Should it be the responsibility of a token spec to specify
whether a token is session level or media level, or is that best handled
at the attribute layer? I am not an SDP expert so I might be missing
something fundamental...

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jun 2018 07:21:56 +0000

Hi,

>>> At the syntax level, yes. Sematically, however, is it perhaps the job 
>>> of the ICE specification to define whether ICE extensions (however 
>>> encoded in a using protocol) are session-level or media-level?
>> 
>> registration of the attribute. It is considered part of the syntax 
>> even though it isn't part of the ABNF.
>> 
> I guess my concern is this: now that we've decoupled ICE from SDP, we might lose synchronization between SDP bindings 
> and non-SDP bindings, which wouldn't be good for interoperability. As I understand it, the ice-options attribute can include 
> a variety of tokens (e.g., 'ice2' or 'rtp+ecn'). Should it be the responsibility of a token spec to specify whether a token is session 
> level or media level, or is that best handled at the attribute layer? I am not an SDP expert so I might be missing something fundamental...

Assuming that ICE options can be both media and session, I think each individual token spec needs to define which it is applicable to. However, RFC 6336 does not currently require to explicitly indicate whether an option is media and/or session - eventhough a description of the token is required.

But, never the less, the ice-sip-sdp draft still needs to define whether the ice-options SDP attribute is media, session or both :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jun 2018 09:15:19 +0000

Hi,

In the middle of my BUNDLE euphoria, it seems like I mixed up some things.

RFC 5245 defines ice-options as session-level only, and that is what we
also agreed for ice-sip-sdp, so all good :)

Regards,

Christer

On 20/06/18 10:21, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>>might lose synchronization between SDP bindings
>> and non-SDP bindings, which wouldn't be good for interoperability. As I
>>understand it, the ice-options attribute can include
>> a variety of tokens (e.g., 'ice2' or 'rtp+ecn'). Should it be the
>>responsibility of a token spec to specify whether a token is session
>> level or media level, or is that best handled at the attribute layer? I
>>am not an SDP expert so I might be missing something fundamental...
>
>Assuming that ICE options can be both media and session, I think each
>individual token spec needs to define which it is applicable to. However,
>RFC 6336 does not currently require to explicitly indicate whether an
>option is media and/or session - eventhough a description of the token is
>required.
>
>But, never the less, the ice-sip-sdp draft still needs to define whether
>the ice-options SDP attribute is media, session or both :)
>
>Regards,
>
>Christer
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 20 Jun 2018 05:17:32 -0400

Hi,

I just wanted to remind that current ICE SDP allows to define custom
attributes either per session (ice-options on the session level) or per ICE
candidate (extension-att-name and extension-att-value). Do you need to
define customer attributes at the media level as well?

Also, RFC 5245 defines ice-options as session level only, so for backwards
compatibility it makes sense to keep them at the same place.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jun 2018 09:19:28 +0000

+1

I mixed things up. Sorry for that.

IF there is a need for "media-level ICE options", I think that should be a separate work.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 20 June 2018 at 12:17
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] ice-options attribute: session- and media-level?

Hi,

I just wanted to remind that current ICE SDP allows to define custom attributes either per session (ice-options on the session level) or per ICE candidate (extension-att-name and extension-att-value). Do you need to define customer attributes at the media level as well?

Also, RFC 5245 defines ice-options as session level only, so for backwards compatibility it makes sense to keep them at the same place.

Regards,
_____________
Roman Shpount

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jun 2018 09:52:34 -0600

> IF there is a need for "media-level ICE options", I think that should be

Seems reasonable. Thanks for the reminder about 5245bis, too. Carry on! :)

Peter