Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections

On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 2/18/17 1:45 PM, Eric Rescorla wrote:
>
>>
>>
>> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>     On 2/18/17 4:35 AM, Christer Holmberg wrote:
>>
>>         Hi,
>>
>>         I invite anyone who has a suggestion on text that needs to be
>>         modified/added/removed to provide a pull request (or send text
>>         to the list) to do so; in draft-bundle, draft-mux-attributes,
>>         and/or any other specification...
>>
>>
>>     IMO it doesn't make sense to put attributes on one bundled m-line
>>     that only apply to some other bundled m-line - current or future.
>>
>>
>> Why? The whole principle is that they are supposed to span all the m=
>> lines.
>>
>
> They are supposed to span all the m-lines in the bundle that it is
> meaningful for them to be used with.
>

Yes, and so it doesn't matter which one they are attached to.

The closest thing we currently have to this situation is session-level
> attributes. Some of those are defined as valid at both session and media
> level, and that the value at session level is a default for media level.
> These in some sense need to be evaluated in the context of every m-line,
> even the ones where they aren't defined.
>
> But we have no standard rule for these. Every attribute needs to say if it
> is defined at session level and if that should be treated as a default for
> a value at media level. And in the process it is specifying (at least
> implicitly) which m-lines it applies to.
>
> In principle this could also be done for all the attributes that are to be
> identical in bundles. But that means making all the changes to do that, and
> maintain it in the future.

Huh? We already have a document that analyzes every single attribute and
tells you how it
is to be handled (
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16) and
tells you how to hoist stuff from one m= line to all of them. And we're
already handling
it that way if the m= line associated with the bundle tag is a media
section. The only
difference is how it's handled if it's a data section.

-Ekr

    As an alternative, how about picking the first tag in the bundle
>>     attribute that identifies an m-line of an appropriate type to carry
>>     the attribute?
>>
>> Seems much more complicated to implement and specify.
>>
>> To conserve e-mails, responding to Christer as well here: I don't think
>> we need to update any of the relevant RFCs (other than potentially
>> putting them in some
>> useless Updates: line at the top of the doc). The idea here is that
>> BUNDLE overrides them for cases where it applies.
>>
>
> Again, maybe it is possible to craft some words that clearly and precisely
> state how this is to work, in a general way without taking it one attribute
> at a time. But I want to see them.
>
> Then we can discuss whether that is simpler than what I suggested above.
>
>         Thanks,
>         Paul
>
> -Ekr
>>
>>
>>             Thanks,
>>             Paul
>>
>>
>>         Regards,
>>
>>         Christer
>>
>>         -----Original Message-----
>>         From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
>>         <mailto:pkyzivat@alum.mit.edu>]
>>         Sent: 17 February 2017 18:51
>>         To: Taylor Brandstetter <deadbeef@google.com
>>         <mailto:deadbeef@google.com>>
>>         Cc: Christer Holmberg <christer.holmberg@ericsson.com
>>         <mailto:christer.holmberg@ericsson.com>>; IETF MMUSIC WG
>>         <mmusic@ietf.org <mailto:mmusic@ietf.org>>
>>         Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in
>>         non-media m= sections
>>
>>         On 2/16/17 9:27 PM, Taylor Brandstetter wrote:
>>
>>                 So, to make this work I think it will be necessary to
>>             ammend the
>>                 definitions of the particular attributes to specify this
>>             usage. And
>>                 then future new attributes that pertain to RTP would
>>             also need to
>>                 address this.
>>
>>
>>             sdp-mux-attributes already amends the definitions of these
>>             attributes,
>>             such that a TRANSPORT attribute in m= section "A" can be
>>             used for
>>             media described by m= section "B". So, I don't see why it
>>             couldn't go
>>             a step further, and explicitly allow TRANSPORT and IDENTICAL
>>             category
>>             attributes to appear in m= sections with proto values not
>>             normally
>>             used with those attributes.
>>
>>
>>         I will reserve judgement until I see specific text.
>>
>>                 Thanks,
>>                 Paul
>>
>>             On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat
>>             <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>>             <mailto:pkyzivat@alum.mit.edu
>>
>>             <mailto:pkyzivat@alum.mit.edu>>> wrote:
>>
>>                 On 2/16/17 12:10 PM, Christer Holmberg wrote:
>>
>>                     Hi Paul,
>>
>>                     I assume you have an opinion on this :)
>>
>>                     The suggestion is to allow RTP-specific parameters
>>             (SDP rtcp-mux
>>                     attributes etc) in non-RTP m= lines (e.g., data
>>             channel).
>>
>>
>>                 This is a nasty issue.
>>
>>                 The problem with allowing this is: what do these
>>             parameters *mean*
>>                 when so attached? And where do I look to find out?
>>
>>                 I'm not certain if they are currently permitted or not.
>>             AFAIK there
>>                 is no *general* mechanism for specifying with which
>>             proto values a
>>                 particular attribute may be used. I haven't studied the
>>             definitions
>>                 of the "RTP-related" attributes to see if they make a
>>             specific
>>                 statement about this. My guess is that they don't, but
>>             that they
>>                 only define the meaning in the context of an RTP session.
>>
>>                 If that is so, perhaps the rule that unknown attributes
>>             are to be
>>                 ignored should apply to those attributes when used with
>>             a non-RTP
>>                 media section. But if that rule were to apply, then we
>>             would expect
>>                 that with O/A the rules for how these attributes in an
>>             offer affect
>>                 what goes in the answer would not apply. I guess that
>>             won't be
>>                 sufficient here.
>>
>>                 So, to make this work I think it will be necessary to
>>             ammend the
>>                 definitions of the particular attributes to specify this
>>             usage. And
>>                 then future new attributes that pertain to RTP would
>>             also need to
>>                 address this.
>>
>>                 IMO this is a can of worms. So my opinion is that these
>>             should *not*
>>                 be used with non-RTP m-lines, with or without bundle.
>>
>>                 Note that data channel is a special case. While we have
>>             agreed not
>>                 to consider it for now, it is possible, in principle, to
>>             run RTP
>>                 over a data channel. If that were defined then these
>>             attributes
>>                 would also be needed. But then they would not be used as
>>             media-level
>>                 attributes. Instead, they would be dcsa attributes.
>>
>>                         Thanks,
>>                         Paul
>>
>>                     *From:*mmusic [mailto:mmusic-bounces@ietf.org
>>             <mailto:mmusic-bounces@ietf.org>
>>                     <mailto:mmusic-bounces@ietf.org
>>             <mailto:mmusic-bounces@ietf.org>>] *On Behalf Of *Christer
>>                     Holmberg
>>                     *Sent:* 16 February 2017 19:07
>>                     *To:* Eric Rescorla <ekr@rtfm.com
>>             <mailto:ekr@rtfm.com> <mailto:ekr@rtfm.com
>>             <mailto:ekr@rtfm.com>>>; mmusic
>>                     WG <mmusic@ietf.org <mailto:mmusic@ietf.org>
>>             <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>>
>>
>>                     *Subject:* Re: [MMUSIC] Issue #27: Allow RTP
>>             attributes in
>>                     non-media m=
>>                     sections
>>
>>
>>
>>                     Hi,
>>
>>                     * *
>>
>>                     *>*See:
>>
>>
>>             https://github.com/cdh4u/draft-sdp-bundle/issues/27
>>             <https://github.com/cdh4u/draft-sdp-bundle/issues/27>
>>
>>             <https://github.com/cdh4u/draft-sdp-bundle/issues/27
>>             <https://github.com/cdh4u/draft-sdp-bundle/issues/27>>
>>
>>
>>                         https://github.com/rtcweb-wg/jsep/issues/528
>>             <https://github.com/rtcweb-wg/jsep/issues/528>
>>                         <https://github.com/rtcweb-wg/jsep/issues/528
>>             <https://github.com/rtcweb-wg/jsep/issues/528>>
>>
>>
>>
>>
>>                         The basic issue is that it's possible to have a
>>             situation
>>                         where you
>>
>>                     have both
>>
>>                         media and data m= sections but the BUNDLE tag is
>>             associated
>>                         with the data
>>
>>
>>                         m= section and now you need to put the TRANSPORT
>> and
>>             IDENTICAL
>>
>>
>>                         attributes somewhere. The JSEP editors discussed
>>             this and
>>                         came to the
>>
>>
>>                         conclusion that it should go with the BUNDLE tag
>>             (i.e., in
>>                         the data m=
>>
>>                     section)
>>
>>                         and that BUNDLE should forbid this, but it
>>             requires a change
>>                         to BUNDLE.
>>
>>
>>
>>
>>                     Did you mean to say that BUNDLE should NOT forbid
>> this?
>>
>>
>>
>>                     Based on your GitHub discussion, my understanding is
>>             that you
>>                     want to
>>                     allow to include RTP-specific parameters
>>             (‘rtcp-mux’, ‘rtcp’,
>>                     ‘rtcp-mux-only’ attributes etc) in the data m=
>> section.
>>
>>
>>
>>                     To repeat what I said on GitHub:
>>
>>
>>
>>                     This has been discussed in the past, and the outcome
>>             has been to now
>>                     allow RTP-specific parameters in non-RTP m= sections.
>>
>>
>>
>>                     A solution would be to simply change the bundle tag
>>             when the RTP m=
>>                     sections are added.
>>
>>
>>
>>                     …OR, we change the mux category for the RTP-specific
>>             parameters.
>>                     But,
>>                     that of course means they have to be added to every
>>             RTP m= section.
>>
>>
>>
>>                     Regards,
>>
>>
>>
>>                     Christer
>>
>>
>>                 _______________________________________________
>>                 mmusic mailing list
>>                 mmusic@ietf.org <mailto:mmusic@ietf.org>
>>             <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
>>                 https://www.ietf.org/mailman/listinfo/mmusic
>>             <https://www.ietf.org/mailman/listinfo/mmusic>
>>                 <https://www.ietf.org/mailman/listinfo/mmusic
>>             <https://www.ietf.org/mailman/listinfo/mmusic>>
>>
>>
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>>
>