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

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.

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?

	Thanks,
	Paul

> Regards,
>
> Christer
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: 17 February 2017 18:51
> To: Taylor Brandstetter <deadbeef@google.com>
> Cc: Christer Holmberg <christer.holmberg@ericsson.com>; IETF MMUSIC WG <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>> 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>] *On Behalf Of *Christer
>>         Holmberg
>>         *Sent:* 16 February 2017 19:07
>>         *To:* Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>>; mmusic
>>         WG <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/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>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>