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

Christer Holmberg <[email protected]> Fri, 17 Feb 2017 08:27:42 +0000

Newsgroups	gmane.ietf.mmusic
Message-ID	<[email protected]>

Hi,

>> 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 am sure it could be done. The question is what (if any) specifications that would have to be updated.

Regards,

Christer

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