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

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

On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat <[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]] *On Behalf Of *Christer
>> Holmberg
>> *Sent:* 16 February 2017 19:07
>> *To:* Eric Rescorla <[email protected]>; mmusic WG <[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/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]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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