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

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 09:42:10 +0000

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: Suhas Nandakumar <[email-masked]>
Date: Sun, 22 Apr 2018 22:28:15 -0700

Hi Christer,

 Please see response inline

Cheers
Suhas

On Tue, Apr 17, 2018 at 2:42 AM, Christer Holmberg <
[email-masked]> wrote:

> 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?
>
>
[Suhas] Section 10.2 defines explanation of each ice-options attributes for
media-level and session level considerations.
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-10.2

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Apr 2018 07:12:54 +0000

Hi Suhas,

> [Suhas] Section 10.2 defines explanation of each ice-options attributes for media-level and session level considerations.

That text is VERY confusing  - especially the stuff about “media-level attributes being MUST be aggregated on session-level”.

Also, the text seems to define such “aggregation rules" for the “rtp+ecn” option. If so, shouldn’t the draft update RFC 6679?

Related to that, the text says that the the “rtp+ecn” option can only be used on session-level if it applies to all media, otherwise it has to be on the media-level. How does that fulfil the “MUST aggregate to session-level” requirement?

Regards,

Christer

Regards,

Christer

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Apr 2018 13:09:27 +0200

Hi,

I have to say, that I don't quite understand the reasons for changing 
the ice-options attribute. ECN for RTP's ICE ECN capable path check 
procedure is not a good argument for the need for media level. The 
rtp+ecn option is a session level capability attribute, where the 
a=ecn-capable-rtp attribute indicates which media levels where the path 
shall be checked.

However, if the consensus is to prepare for any potential future option 
that would use media level ICE options, then okay, but it is difficult 
to evaluate the changes without any clear requirements.

However, the draft do need to be updated. I have to agree with Christer, 
the normative 2119 language affecting the rtp+ecn option thus results in 
an updates: RFC 6679. And in addition section 10.2 also seem to update 
or replace the registration rules in RFC 6336. Which of it is needs to 
be made explicit.

And if one is to allow to use rtp+ecn option on media level then I think 
you need to define that better. As ecn+rtp option indicates an endpoint 
capability it is not clear what media level version of that means. You 
will clearly also need to tackle the meaning of the different option in 
an bundle group.

Cheers

Magnus

Den 2018-04-23 kl. 09:12, skrev Christer Holmberg:
> >>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?
> >
> That text is VERY confusing  - especially the stuff about “media-level 
> attributes being MUST be aggregated on session-level”.
>
> Also, the text seems to define such “aggregation rules" for the 
> “rtp+ecn” option. If so, shouldn’t the draft update RFC 6679?
>
> Related to that, the text says that the the “rtp+ecn” option can only 
> be used on session-level if it applies to all media, otherwise it has 
> to be on the media-level. How does that fulfil the “MUST aggregate to 
> session-level” requirement?
>
> Regards,
>
> Christer
>
>
>
>
>     Also, section 5.12 of draft-ietf-mmusic-sdp-mux-attributes-16
>     indicates the attribute as session only (“S”).
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
>
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 23 Apr 2018 14:59:18 +0000

Thanks for the responses Magnus and Christer.
The more I think about it, the more I am confused on having a media level
option.

Unfortunately, this section predatesme joining as a co-author and hence
Marc/Ari might have a better reasoning.

We can wait on them to respond or can go with session level only
ice-options and write a new spec if we decide a media level version is
needed in the future

Cheers
Suhas

On Mon, Apr 23, 2018 at 4:09 AM Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> I have to say, that I don't quite understand the reasons for changing the
> ice-options attribute. ECN for RTP's ICE ECN capable path check procedure
> is not a good argument for the need for media level. The rtp+ecn option is
> a session level capability attribute, where the a=ecn-capable-rtp attribute
> indicates which media levels where the path shall be checked.
>
> that would use media level ICE options, then okay, but it is difficult to
> evaluate the changes without any clear requirements.
>
> the normative 2119 language affecting the rtp+ecn option thus results in an
> updates: RFC 6679. And in addition section 10.2 also seem to update or
> replace the registration rules in RFC 6336. Which of it is needs to be made
> explicit.
>
> capability it is not clear what media level version of that means. You will
> clearly also need to tackle the meaning of the different option in an
> bundle group.
>
> Cheers
>
> Magnus
>
> >> 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?
> >
> > [Suhas] Section 10.2 defines explanation of each ice-options attributes
> for media-level and session level considerations.
> >
> Also, the text seems to define such “aggregation rules" for the “rtp+ecn”
> option. If so, shouldn’t the draft update RFC 6679?
>
> Related to that, the text says that the the “rtp+ecn” option can only be
> used on session-level if it applies to all media, otherwise it has to be on
> the media-level. How does that fulfil the “MUST aggregate to session-level”
> requirement?
>
> Regards,
>
> Christer
>
>
>
>
>
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
> --
>
> Magnus Westerlund
>
> Ericsson AB                 | Phone  +46 10 7148287Torshamnsgatan 23 <https://maps.google.com/?q=Torshamnsgatan+23&entry=gmail&source=g>           | Mobile +46 73 0949079