Subject: [MMUSIC] Existing missmatch between SDP mux and BUNDLE

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Sep 2017 13:20:25 +0200

Hi,

We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which 
references Bundle and SDP-Mux as it defines the mux category for its SDP 
attributes. As we made some last minute changes to MUX catergory for the 
extmap-allowed-mixed attribute we found some text needing changes. This 
anyway resulted in us noticing a missmatch between BUNDLE and sdp-mux.

So Bundle (-39) states:

8.1. Mux Category Considerations

    When an offerer or answerer associates SDP attributes with a bundled
    "m=" line (including any bundle-only "m=" line) associated with a
    shared address, IDENTICAL and TRANSPORT mux category SDP attributes
    [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
    line only if the "m=" line is also associated with the offerer/
    answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
    associate such SDP attributes with the "m=" line.  The rule above
    does not apply to a bundled "m=" line associated with a unique
    address.

However, SDP-mux states:

4.3. Category: IDENTICAL

    The attributes and their associated values (if any) in the IDENTICAL
    category MUST be repeated across all the media descriptions under
    multiplexing.

To my understanding the first is correct, but the change in BUNDLE has not been
reflected into SDP-mux doc. I assume that is in part due to its approved status.
Has the authors tracked the set of changes that are needed due to changes in BUNDLE?

Do there exist a text change for this missmatch?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 22 Sep 2017 09:29:00 -0400

Hi Magnus

Can you elaborate on the mismatch ? I understand they do not say the 
same thing, but it's not clear to me they are actually in conflict with 
each other.

How do you interpret the line ("associate" in particular)
<quote>
Otherwise the offerer/answerer MUST NOT associate such SDP attributes 
with the "m=" line.
<quote>

Is the issue that bundle is relaxing the MUST requirement in bundle ?

Thanks

-- Flemming

On 9/20/17 7:20 AM, Magnus Westerlund wrote:
> references Bundle and SDP-Mux as it defines the mux category for its 
> SDP attributes. As we made some last minute changes to MUX catergory 
> for the extmap-allowed-mixed attribute we found some text needing 
> changes. This anyway resulted in us noticing a missmatch between 
> BUNDLE and sdp-mux.
>
> So Bundle (-39) states:
>
> SE-164 80 Stockholm, Sweden | mailto:[email-masked]
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Sep 2017 16:56:31 +0200

Hi,

SDP Mux says:

This I interpret as you really MUST include it each and every m= section that are bundled.
While BUNDLE with its updated text says, that you only should include the SDP attribute in the m= sections
that are first on any a=group:BUNDLE line, and not in another unless they have unique
transport information for the case of legacy fallback into individual lines.

Thus, I see SDP-mux require inclusion of the SDP attribute on each m= section in all cases and BUNDLE to
forbid such includion with the m= section in some cases. Thus, in those cases there is a conflict between
two different MUST statements.

Cheers

Magnus

Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
> same thing, but it's not clear to me they are actually in conflict 
> with each other.
>

-- 

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 22 Sep 2017 12:20:17 -0400

> This I interpret as you really MUST include it each and every m= section that are bundled.
Agreed.
> transport information for the case of legacy fallback into individual lines.
It depends on how we interpret "associated with" - if it simply means 
"included as part of the media description" then I agree with you.

> two different MUST statements.
I think you are right - maybe Christer can clarify the "associated with" 
term ?

Thanks

-- Flemming

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 22 Sep 2017 19:25:19 +0200

>
> It depends on how we interpret "associated with"

That's why I purged "associated with" from the BUNDLE spec:
https://github.com/taylor-b/draft-sdp-bundle/pull/1

It almost always can be interpreted in multiple ways. Unfortunately this
never got integrated, I assume because I was too late.

Anyway: the intention here, as can be found in the mailing list history,
was that IDENTICAL attributes are only placed in one m= section (the
BUNDLE-tag section) when there's no fallback to becoming un-bundled. This
avoids redundant information in SDP, wasting bytes in signaling messages.
Example:

*Initial offer (supports being received by non-BUNDLE endpoint):*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=identical:baz
a=mid:bar

*Answer:*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=mid:bar

*Subsequent offer:*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=mid:bar

So yes, sdp-mux-attributes needs to be updated.

On Fri, Sep 22, 2017 at 6:20 PM, Flemming Andreasen <[email-masked]>
wrote:

> Can you elaborate on the mismatch ? I understand they do not say the same
> thing, but it's not clear to me they are actually in conflict with each
> other.
>
> Otherwise the offerer/answerer MUST NOT associate such SDP attributes with
> the "m=" line.
> <quote>
>
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> --
>
> Magnus Westerlund
>
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Sep 2017 19:38:21 +0000

Hi,

>> This I interpret as you really MUST include it each and every m= section that are bundled. 

Perhaps the text should say "applies to all media descriptions", and then a sentence saying the individual usages need to define in which m- lines the attribute must be explicitly included..

> It depends on how we interpret "associated with" - if it simply means "included as part of the media description" then I agree with you. 

That's what it means.

> I think you are right - maybe Christer can clarify the "associated with" term ? 

Unless the DRAFT clarifies that to you, we really need to do something...

Regards,

Christer

Can you elaborate on the mismatch ? I understand they do not say the same thing, but it's not clear to me they are actually in conflict with each other. 

How do you interpret the line ("associate" in particular)
<quote>
Otherwise the offerer/answerer MUST NOT associate such SDP attributes with the "m=" line. 
<quote>

Thanks

-- Flemming 
We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which references Bundle and SDP-Mux as it defines the mux category for its SDP attributes. As we made some last minute changes to MUX catergory for the extmap-allowed-mixed attribute we found some text needing changes. This anyway resulted in us noticing a missmatch between BUNDLE and sdp-mux.

However, SDP-mux states:

4.3.  Category: IDENTICAL

Cheers 

Magnus Westerlund 

-- 

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Sep 2017 19:51:36 +0000

Hi,

> That's why I purged "associated with" from the BUNDLE spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1 
>
> It almost always can be interpreted in multiple ways. Unfortunately this never got integrated, I assume because I was too late.

No, you were not :) I have been looking at your CR, and have been considering to integrate it, but I lately I have been so busy with draft-dtls-sdp etc.

Having said that, we have changed the terminology in bundle a number of times already - we really need to stop at some point.

The history of "associated" is when people commented that one cannot add an attribute, address etc to an m- line (because attributes, c- lines and m- lines are separate SDP properties). So, instead of talking about adding those to an m- line talk about associating those with an m- line.

Now, if I remember the changes in your PR correctly, you are talking about "media descriptions", which would be an "envelope" containing the m- line, the address and attributes associated with that m- line. Then you could say "add attribute to the media description", etc. Right?

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 22 Sep 2017 22:08:30 +0200

Right. I can only think of one possible interpretation of "add attribute to
media description". RFC4566 uses the following phrases:

   - "attributes ... may be added"
   - "attribute ... in the media description"
   - "attribute is present"
   - "a media description may have any number of attributes"
   - "attribute fields can ... be added"
   - "specifying the attribute"
   - "session description containing such attributes"
   - "attribute MUST be included"

So, the following would be consistent with the defined terminology:

   - "The offerer MUST add the foo attribute to the media description."
   - "The foo attribute MUST be [present|contained|specified|included] in
   the media description."
   - "The media description MUST have the foo attribute."

But "foo attribute MUST be associated with the m-line"? Not so much.

On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <
[email-masked]> wrote:

> No, you were not :) I have been looking at your CR, and have been
> considering to integrate it, but I lately I have been so busy with
> draft-dtls-sdp etc.
>
> Having said that, we have changed the terminology in bundle a number of
> times already - we really need to stop at some point.
>
> The history of "associated" is when people commented that one cannot add
> an attribute, address etc to an m- line (because attributes, c- lines and
> m- lines are separate SDP properties). So, instead of talking about adding
> those to an m- line talk about associating those with an m- line.
>
> Now, if I remember the changes in your PR correctly, you are talking about
> "media descriptions", which would be an "envelope" containing the m- line,
> the address and attributes associated with that m- line. Then you could say
> "add attribute to the media description", etc. Right?
>
> Regards,
>
> Christer
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Sep 2017 22:38:55 -0400

I much prefer use of the term "media description" as well since this is 
well-defined in 4566.

Having said that, I wholeheartedly agree with Christer's point about 
terminology change - we need people to agree to this before entertaining 
yet another update on this front.

So folks, please speak up and let us know if you are for, against, or 
indifferent in terms of said terminology change.

Thanks

-- Flemming

On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
> Right. I can only think of one possible interpretation of "add 
> attribute to media description". RFC4566 uses the following phrases:
>
>   * "attributes ... may be added"
>   * "attribute ... in the media description"
>   * "attribute is present"
>   * "a media description may have any number of attributes"
>   * "attribute fields can ... be added"
>   * "specifying the attribute"
>   * "session description containing such attributes"
>   * "attribute MUST be included"
>
>   * "The offerer MUST add the foo attribute to the media description."
>   * "The foo attribute MUST be [present|contained|specified|included]
>     in the media description."
>   * "The media description MUST have the foo attribute."
>
> On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     <https://github.com/taylor-b/draft-sdp-bundle/pull/1>
>     >
>     > It almost always can be interpreted in multiple ways.
>     Unfortunately this never got integrated, I assume because I was
>     too late.
>
>     Having said that, we have changed the terminology in bundle a
>     number of times already - we really need to stop at some point.
>
>     The history of "associated" is when people commented that one
>     cannot add an attribute, address etc to an m- line (because
>     attributes, c- lines and m- lines are separate SDP properties).
>     So, instead of talking about adding those to an m- line talk about
>     associating those with an m- line.
>
>     Now, if I remember the changes in your PR correctly, you are
>     talking about "media descriptions", which would be an "envelope"
>     containing the m- line, the address and attributes associated with
>     that m- line. Then you could say "add attribute to the media
>     description", etc. Right?
>
>     Regards,
>
>     Christer
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 Sep 2017 19:52:33 -0700

I am in favor of the changes that Taylor proposes.

-Ekr

On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen <[email-masked]>
wrote:

> Right. I can only think of one possible interpretation of "add attribute
> to media description". RFC4566 uses the following phrases:
>
>> > It almost always can be interpreted in multiple ways. Unfortunately
>> this never got integrated, I assume because I was too late.
>>
>> Now, if I remember the changes in your PR correctly, you are talking
>> about "media descriptions", which would be an "envelope" containing the m-
>> line, the address and attributes associated with that m- line. Then you
>> could say "add attribute to the media description", etc. Right?
>>
>> Regards,
>>
>> Christer
>>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 13:24:06 +0000

Hi,

>I much prefer use of the term "media description" as well since this is well-defined in 4566.

Actually, the PR suggests “m= section”. That is used in JSEP, but in 4566 there is “media description” and “media-level section”. I am not really sure that the difference is, because I find both:

        "Each media description starts with an "m=" field and is terminated by either the next "m=“ field”

…and:

        "Each media-level section starts with an "m=" line and continues to the next media-level section"

So, it seems the RFC uses inconsistent terminology.

Now, I had a look at draft-4566bis, and it seems like “m=“ field has been removed. But, both “media description” and “media-level section” are still used.

Regards,

Christer

On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
Right. I can only think of one possible interpretation of "add attribute to media description". RFC4566 uses the following phrases:

  *   "The offerer MUST add the foo attribute to the media description."
  *   "The foo attribute MUST be [present|contained|specified|included] in the media description."
  *   "The media description MUST have the foo attribute."

On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Sep 2017 16:44:39 +0000

I have one question, which actually makes a practical difference to the on-the-wire SDP of BUNDLE.

For a session- and media-level attribute which has the common pattern that the session-level value provides a default for the media level, a non-overridden session-level attribute is arguably “associated” with a media description, but it clearly isn’t “included” in it.

Should this be permitted?

On Sep 25, 2017, at 10:52 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
I much prefer use of the term "media description" as well since this is well-defined in 4566.

Having said that, I wholeheartedly agree with Christer's point about terminology change - we need people to agree to this before entertaining yet another update on this front.

So folks, please speak up and let us know if you are for, against, or indifferent in terms of said terminology change.

Thanks

-- Flemming

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 17:13:01 +0000

Hi,

>I have one question, which actually makes a practical difference to the on-the->wire SDP of BUNDLE.
>
>For a session- and media-level attribute which has the common pattern that the >session-level value provides a default for the media level, a non-overridden >session-level attribute is arguably “associated” with a media description, but it >clearly isn’t “included” in it.
>

Not sure I understand. Should what be permitted? :)

Regards,

Christer

-Ekr

Thanks

-- Flemming

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Sep 2017 17:49:49 +0000

On Sep 26, 2017, at 1:13 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

>For a session- and media-level attribute which has the common pattern that the >session-level value provides a default for the media level, a non-overridden>session-level attribute is arguably “associated” with a media description, but it >clearly isn’t “included” in it.
>

If BUNDLE says that an attribute of this type “MUST be associated with a media description”, is it sufficient to have the attribute specified at the session level?

Regards,

Christer

-Ekr

Thanks

-- Flemming

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 26 Sep 2017 11:00:11 -0700

>
> Actually, the PR suggests “m= section”. That is used in JSEP, but in 4566
> there is “media description” and “media-level section”. I am not really
> sure that the difference is.

"Media description" and "media-level section" are the same thing, by
definition. My PR defines "m=" section as another shorthand, mainly since
this is a phrase JSEP uses heavily. But I'd gladly just use "media
description", "media-level section" or "media section".

On Tue, Sep 26, 2017 at 10:49 AM, Jonathan Lennox <[email-masked]>
wrote:

>
> On Sep 26, 2017, at 1:13 PM, Christer Holmberg <
> >For a session- and media-level attribute which has the common pattern
> that the >session-level value provides a default for the media level, a
> non-overridden>session-level attribute is arguably “associated” with a
> media description, but it >clearly isn’t “included” in it.
> >
> If BUNDLE says that an attribute of this type “MUST be associated with a
> media description”, is it sufficient to have the attribute specified at the
> session level?
>
>
> Regards,
>
> Christer
>
>
>
>
> On Sep 25, 2017, at 10:52 PM, Eric Rescorla <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 18:04:51 +0000

>>Actually, the PR suggests “m= section”. That is used in JSEP, but in 4566 there is “media description” and “media-level section”. I am 
>>not really sure that the difference is.
>
>"Media description" and "media-level section" are the same thing, by definition. My PR defines "m=" section as another shorthand, 
>mainly since this is a phrase JSEP uses heavily. But I'd gladly just use "media description", "media-level section" or "media section".

I'd like 4566bis to use ONE definition, and then we use the same elsewhere.

Regards,

Christer

On Sep 26, 2017, at 1:13 PM, Christer Holmberg <[email-masked]> wrote:

Hi,

 
Regards,
 
Christer

 
 
-Ekr

On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen <[email-masked]> wrote:
I much prefer use of the term "media description" as well since this is well-defined in 4566. 

Thanks 

-- Flemming 
 
On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
Right. I can only think of one possible interpretation of "add attribute to media description". RFC4566 uses the following phrases:
• "attributes ... may be added" 
• "attribute ... in the media description" 
• "attribute is present" 
• "a media description may have any number of attributes" 
• "attribute fields can ... be added" 
• "specifying the attribute" 
• "session description containing such attributes" 
• "attribute MUST be included" 
So, the following would be consistent with the defined terminology:
• "The offerer MUST add the foo attribute to the media description." 
• "The foo attribute MUST be [present|contained|specified|included] in the media description."
• "The media description MUST have the foo attribute."
But "foo attribute MUST be associated with the m-line"? Not so much.
 
On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 26 Sep 2017 14:16:33 -0400

On 9/26/17 1:49 PM, Jonathan Lennox wrote:
>
>> On Sep 26, 2017, at 1:13 PM, Christer Holmberg 
>> that the>session-level value provides a default for the media level, 
>> a non-overridden>session-level attribute is arguably “associated” 
>> with a media description, but it>clearly isn’t “included” in it.
>> >
> If BUNDLE says that an attribute of this type “MUST be associated with 
> a media description”, is it sufficient to have the attribute specified 
> at the session level?
>
Yes - this is how SDP normally works and we shouldn't change that.

Thanks

-- Flemming (as individual)

>>     On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Having said that, I wholeheartedly agree with Christer's
>>         point about terminology change - we need people to agree to
>>         this before entertaining yet another update on this front.
>>
>>         So folks, please speak up and let us know if you are for,
>>         against, or indifferent in terms of said terminology change.
>>
>>         Thanks
>>
>>         -- Flemming
>>             Right. I can only think of one possible interpretation of
>>             "add attribute to media description". RFC4566 uses the
>>             following phrases:
>>
>>               * "The foo attribute MUST be
>>                 [present|contained|specified|included] in the media
>>                 description."
>>                 > That's why I purged "associated with" from the
>>                 BUNDLE
>>                 spec:https://github.com/taylor-b/draft-sdp-bundle/pull/1
>>                 >
>>                 > It almost always can be interpreted in multiple
>>                 ways. Unfortunately this never got integrated, I
>>                 assume because I was too late.
>>
>>                 No, you were not :) I have been looking at your CR,
>>                 and have been considering to integrate it, but I
>>                 lately I have been so busy with draft-dtls-sdp etc.
>>
>>                 Having said that, we have changed the terminology in
>>                 bundle a number of times already - we really need to
>>                 stop at some point.
>>
>>                 The history of "associated" is when people commented
>>                 that one cannot add an attribute, address etc to an
>>                 m- line (because attributes, c- lines and m- lines
>>                 are separate SDP properties). So, instead of talking
>>                 about adding those to an m- line talk about
>>                 Now, if I remember the changes in your PR correctly,
>>                 you are talking about "media descriptions", which
>>                 would be an "envelope" containing the m- line, the
>>                 address and attributes associated with that m- line.
>>                 Then you could say "add attribute to the media
>>         [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 26 Sep 2017 14:18:21 -0400

> I'd like 4566bis to use ONE definition, and then we use the same elsewhere.

4566bis is currently in WGLC - can you provide that feedback to the WGLC 
thread (as well as any other comments you may have on 4566bis) ?

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Sep 2017 10:34:44 -0400

> Yes - this is how SDP normally works and we shouldn't change that.

+1

	Thanks,
	Paul