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

[Taylor Brandstetter <[e-mail]>]

>
> 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 <[e-mail]>
wrote:

>
>
> On 9/22/17 10:56 AM, Magnus Westerlund wrote:
>
> Hi,
>
> SDP Mux says:
>
> The attributes and their associated values (if any) in the IDENTICAL
>    category MUST be repeated across all the media descriptions under
>    multiplexing.
>
> This I interpret as you really MUST include it each and every m= section that are bundled.
>
> Agreed.
>
> 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.
>
> It depends on how we interpret "associated with" - if it simply means
> "included as part of the media description" then I agree with you.
>
>
> 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.
>
> I think you are right - maybe Christer can clarify the "associated with"
> term ?
>
> Thanks
>
> -- Flemming
>
>
> Cheers
>
> Magnus
>
>
>
> Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
>
> 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:
>
> 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  [phone] <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile [phone] <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>
> _______________________________________________
> mmusic mailing [e-mail]://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone] <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile [phone] <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>