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

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2018 07:21:17 +0000

Anyone???

I need this clarification to be able to address IESG comments given on BUNDLE.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 17 April 2018 at 12:42
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] ice-options attribute: session- and media-level?

Hi,

Section 4.6 of draft-ietf-mmusic-ice-sip-sdp-20 defines the ‘ice-options’ attribute as both session- and media-level.

However, there is no description of what it means to use the attribute on media-level. Does it mean that the indicated ICE extension is only used for that particular media stream?

Also, section 5.12 of draft-ietf-mmusic-sdp-mux-attributes-16 indicates the attribute as session only (“S”).

Is there a need to define it as media-level attribute?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 20 Apr 2018 14:37:20 -0400

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.

Regards,

_____________
Roman Shpount

On Fri, Apr 20, 2018 at 3:21 AM, Christer Holmberg <
[email-masked]> wrote:

> From: mmusic <[email-masked]> on behalf of Christer Holmberg <
> [email-masked] <[email-masked]>>
> To: "[email-masked]" <[email-masked]>
> Section 4.6 of draft-ietf-mmusic-ice-sip-sdp-20 defines the ‘ice-options’
> attribute as both session- and media-level.
>
> However, there is no description of what it means to use the attribute on
> media-level. Does it mean that the indicated ICE extension is only used for
> that particular media stream?
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 20 Apr 2018 13:07:44 -0600

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,
> 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.
> 

Agreed.

In the Trickle ICE spec, we also limited the `trickle` option to session
level only.

Peter

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 20 Apr 2018 23:09:16 -0700

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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 23 Apr 2018 09:45:14 -0700

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.

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Apr 2018 13:03:46 -0400

Hi All,

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.

Furthermore, it is possible to define per ICE candidate specific parameters
using ICE candidate extension attributes. I think it would be cleaner to
define things which are specific to only some candidates using this
mechanism vs medial level ice-options.

Regards,

_____________
Roman Shpount

On Mon, Apr 23, 2018 at 12:45 PM, Marc Petit-Huguenin <
[email-masked]> wrote:

> 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 Fri, Apr 20, 2018 at 12:07 PM, Peter Saint-Andre <[email-masked]
> >
> > wrote:
> >

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Apr 2018 06:43:04 +0000

+1

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Monday 23 April 2018 at 20:03
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] ice-options attribute: session- and media-level?

Hi All,

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.

Furthermore, it is possible to define per ICE candidate specific parameters using ICE candidate extension attributes. I think it would be cleaner to define things which are specific to only some candidates using this mechanism vs medial level ice-options.

Regards,

_____________
Roman Shpount

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:

On 04/20/2018 11:09 PM, Suhas Nandakumar wrote:
> On Fri, Apr 20, 2018 at 12:07 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
> wrote:
>

--
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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Apr 2018 07:07:54 +0000

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