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

On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <[email protected]> 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.



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

-Ekr


>         Thanks,
>         Paul
>
>
> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email protected]]
>> Sent: 17 February 2017 18:51
>> To: Taylor Brandstetter <[email protected]>
>> Cc: Christer Holmberg <[email protected]>; IETF MMUSIC WG <
>> [email protected]>
>> 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 <[email protected]
>>> <mailto:[email protected]>> 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:[email protected]
>>>         <mailto:[email protected]>] *On Behalf Of *Christer
>>>         Holmberg
>>>         *Sent:* 16 February 2017 19:07
>>>         *To:* Eric Rescorla <[email protected] <mailto:[email protected]>>; mmusic
>>>         WG <[email protected] <mailto:[email protected]>>
>>>         *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
>>>     [email protected] <mailto:[email protected]>
>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>>
>>>
>>>
>>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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