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

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 06:11:50 -0800

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.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 17:07:19 +0000

Hi,

>The basic issue is that it's possible to have a situation where you have both
>conclusion that it should go with the BUNDLE tag (i.e., in the data m= section)

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Feb 2017 09:58:53 -0800

On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg <
[email-masked]> wrote:

> *>*See:
> 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.
>

Yes/

> This has been discussed in the past, and the outcome has been to now allow
> RTP-specific parameters in non-RTP m= sections.
>

Do you mean "not" rather than now?

-Ekr

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 18:07:40 +0000

Yes, I meant "not" :)

Sent from my iPhone

On 16 Feb 2017, at 18.59, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yes/

-Ekr

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 16 Feb 2017 11:11:40 -0800

> Yes, I meant "not" :)

I can't find this restriction in the current draft of BUNDLE. Also, this
restriction would make BUNDLE even more complex and non-future-proof
(suppose some future protocol that can be bundled with RTP also has its own
TRANSPORT attributes). What are the reasons for this restriction? Shouldn't
endpoints ignore attributes they don't expect? "If an attribute is received
that is not understood, it MUST be ignored by the receiver."

> OR, we change the mux category for the RTP-specific parameters. But, that

That wouldn't make sense in my opinion. If rtcp-rsize wasn't a
transport-level attribute, then multiple bundled m= sections would be
allowed to use different values for it. It's fundamentally a
transport-level attribute.

On Thu, Feb 16, 2017 at 10:07 AM, Christer Holmberg <
[email-masked]> wrote:

> Yes, I meant "not" :)
>
> Sent from my iPhone
>
> On 16 Feb 2017, at 18.59, Eric Rescorla <[email-masked]> wrote:
>
>
>
>> This has been discussed in the past, and the outcome has been to now
>> allow RTP-specific parameters in non-RTP m= sections.
>>
>
>> …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-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Feb 2017 19:49:35 +0000

Hi,

>> Yes, I meant "not" :)
>
> I can't find this restriction in the current draft of BUNDLE. Also, this restriction would make BUNDLE even more complex and 
> non-future-proof (suppose some future protocol that can be bundled with RTP also has its own TRANSPORT attributes). What 
> are the reasons for this restriction? Shouldn't endpoints ignore attributes they don't expect? "If an attribute is received that is 
> not understood, it MUST be ignored by the receiver."
 
It's not a BUNDLE restriction. The question is whether it's a restriction in the specs defining the parameters.

If there is no restriction, then there should be no issue to begin with. 

If there is a restriction, then the question is whether we would need to update the specs defining the parameters.

>> 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.
>
> That wouldn't make sense in my opinion. If rtcp-rsize wasn't a transport-level attribute, then multiple bundled m= sections would 
> be allowed to use different values for it. It's fundamentally a transport-level attribute.

I agree. The question is whether it's allowed to place the attribute in a non-RTP m= section.

Regards,

Christer

On Thu, Feb 16, 2017 at 10:07 AM, Christer Holmberg <[email-masked]> wrote:
Yes, I meant "not" :)

Sent from my iPhone

On Thu, Feb 16, 2017 at 9:07 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

 

Yes/

-Ekr

 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Feb 2017 18:50:53 -0500

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-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 16 February 2017 19:07
> *To:* Eric Rescorla <[email-masked]>; mmusic WG <[email-masked]>
> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m=
> sections
>
>
>
> Hi,
>
> * *
>
> *>*See:
>

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 16 Feb 2017 18:27:56 -0800

> 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-masked]> wrote:

> 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.
>
> 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
>
>> The basic issue is that it's possible to have a situation where you
>>>
>> have both
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2017 08:27:42 +0000

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

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

Hi,

* *

*>*See:

A solution would be to simply change the bundle tag when the RTP m=
sections are added.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Feb 2017 11:51:25 -0500

On 2/16/17 9:27 PM, Taylor Brandstetter wrote:
>     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
> 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-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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.
>
>     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-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Christer
>         Holmberg
>         *To:* Eric Rescorla <[email-masked] <mailto:[email-masked]>>; mmusic
>         WG <[email-masked] <mailto:[email-masked]>>
>             <https://github.com/cdh4u/draft-sdp-bundle/issues/27>
>
>
>             <https://github.com/rtcweb-wg/jsep/issues/528>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Feb 2017 09:35:40 +0000

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

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 17 February 2017 18:51
To: Taylor Brandstetter <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; IETF MMUSIC WG <[email-masked]>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections

On 2/16/17 9:27 PM, Taylor Brandstetter wrote:
> 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.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Feb 2017 11:09:51 -0500

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Feb 2017 10:45:13 -0800

On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <[email-masked]> wrote:

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Feb 2017 16:38:31 -0500

On 2/18/17 1:45 PM, Eric Rescorla wrote:
>
>
> On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <[email-masked]
>         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.
>
>

They are supposed to span all the m-lines in the bundle that it is 
meaningful for them to be used with.

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.

>     attribute that identifies an m-line of an appropriate type to carry
>     the attribute?
>
> 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

>         From: Paul Kyzivat [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         To: Taylor Brandstetter <[email-masked]
>         <mailto:[email-masked]>>
>         Cc: Christer Holmberg <[email-masked]
>         <mailto:[email-masked]>>; IETF MMUSIC WG
>         <[email-masked] <mailto:[email-masked]>>
>             On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>             <mailto:[email-masked]>
>                     <mailto:[email-masked]
>             <mailto:[email-masked]>>] *On Behalf Of *Christer
>                     Holmberg
>                     *To:* Eric Rescorla <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>>; mmusic
>                     WG <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>                     *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
>
>
>                         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.
>
>
>
>
>                     Based on your GitHub discussion, my understanding is
>             that you
>                     want to
>                     …OR, we change the mux category for the RTP-specific
>             parameters.
>                     But,
>             <mailto:[email-masked] <mailto:[email-masked]>>
>                 <https://www.ietf.org/mailman/listinfo/mmusic
>             <https://www.ietf.org/mailman/listinfo/mmusic>>
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Feb 2017 14:28:20 -0800

> meaningful for them to be used with.

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

> 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

> 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.
>
>>                         m= section and now you need to put the TRANSPORT
>> and
>>             IDENTICAL
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Feb 2017 13:10:28 +0000

Hi,

Do people think we need to discuss this face-to-face in Chicago? Note that I have currently NOT requested agenda time for BUNDLE.

As far as document changes are concerned, we would AT LEAST need some clarification text in BUNDLE and/or draft-mux-attributes.

Regards,

Christer

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Sunday 19 February 2017 at 00:28
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections

On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 2/18/17 1:45 PM, Eric Rescorla wrote:

On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        Hi,

They are supposed to span all the m-lines in the bundle that it is meaningful for them to be used with.

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

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.

        Thanks,
        Paul

-Ekr

            Thanks,
            Paul

        Regards,

        Christer

        -----Original Message-----
        From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>]
        Sent: 17 February 2017 18:51
        To: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
        Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>; IETF MMUSIC WG
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
        Subject: Re: [MMUSIC] 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.

                Thanks,
                Paul

            On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat
            <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
            <mailto:[email-masked]<mailto:[email-masked]>

            <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:

                    Hi Paul,

                    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-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>>
                    <mailto:[email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>>>] *On Behalf Of *Christer
                    Holmberg
                    *Sent:* 16 February 2017 19:07
                    *To:* Eric Rescorla <[email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>>>>; mmusic
                    WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
            <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>

                    Hi,

                    * *

                    *>*See:

                    have both

                        m= section and now you need to put the TRANSPORT and
            IDENTICAL

                    section)

                    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.

                    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-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
            <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
                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
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
    https://www.ietf.org/mailman/listinfo/mmusic
    <https://www.ietf.org/mailman/listinfo/mmusic>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Feb 2017 06:32:54 -0800

Yes, I think we do

On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Do people think we need to discuss this face-to-face in Chicago? Note that
> I have currently NOT requested agenda time for BUNDLE.
>
> As far as document changes are concerned, we would AT LEAST need some
> clarification text in BUNDLE and/or draft-mux-attributes.
>
> Regards,
>
> Christer
>
> From: Eric Rescorla <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, Taylor
> Brandstetter <[email-masked]>, "[email-masked]" <[email-masked]>
>
>> 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
>> be identical in bundles. But that means making all the changes to do that,
>> and maintain it in the future.
>
>
>> 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.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2017 12:21:55 -0500

I give up!!! If everybody else is happy with this then I will simply 
hold my nose and my tongue.

The fundamental problem here is that SDP syntax is vastly inadequate for 
how it has been pushed. This was already true when O/A was first 
introduced, and it has gotten progressively more apparent as more things 
have been added.

Unfortunately there seems to be zero chance that another crack at SDPng 
will ever be taken.

	Grumble,
	Paul

On 2/18/17 5:28 PM, Eric Rescorla wrote:
>         On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>
>     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.
>
>
> is to be handled
> (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16) 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.
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked]
>         <mailto:[email-masked]>>>; IETF MMUSIC WG
>                 <[email-masked] <mailto:[email-masked]>
>                     <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>>>> wrote:
>
>                             *From:*mmusic
>         [mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>] *On Behalf Of *Christer
>                             Holmberg
>         <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>>>>; mmusic
>                     <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>
>         <https://github.com/cdh4u/draft-sdp-bundle/issues/27>>>
>
>
>
>         <https://github.com/rtcweb-wg/jsep/issues/528>>>
>
>
>
>
>                     <mailto:[email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>>>
>
>
>
>