Subject: [MMUSIC] To duplicate or not duplicate

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Oct 2016 16:41:22 -0700

Section 4.3 of the sdp-mux-attributes document says:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-14#section-4.3

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

Section 8.1 of the BUNDLE document says:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-33#section-8.1

   When an offerer associates SDP attributes with a bundled "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 BUNDLE-tag.  Otherwise the offerer MUST
   NOT associate such SDP attributes with the "m=" line.

I submit that BUNDLE is right here and the mux attributes document is wrong
and
we should not duplicate.

-Ekr

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 7 Oct 2016 21:53:02 -0700

Hello Ekr

  Thoughts inline.

>    NOT associate such SDP attributes with the "m=" line.
[Suhas]

I am not sure if you were able to follow the discussions on the same topic
here :

  https://www.ietf.org/mail-archive/web/mmusic/current/msg16929.html

I will try to summarize some points from the above discussion below :-

a) Section 8.1 of the BUNDLE spec refers to the state of the system when
the shared address is already known (after successful  bundle negotiation,
for example).
I do agree that once the BUNDLE address is know ,  the IDENTICAL and
TRANSPORT category attributes needs to be specified on that m=line alone.

b) Section 8.1 doesn't talk about the case for the initial offer (or when
the BUNDLE address is not yet known). The IDENTICAL category  is required
in this case for the Offerer to specify its intent as the Software is
unable to make the decision otherwise.
The very specific example is a=rtcp-mux attribute. In the initial Offer, if
the Offerer wants to multiplex RTP/RTCP it needs to include it in all the
m=lines (as defined by the IDENTICAL category). This is because, if the
BUNDLE semantics gets rejected the offerer can still do
 RTP/RTCP multiplexing on all the m=lines.
OTOH, if a=rtcp-mux was included only in the m=line whose mid was listed as
the first in the a=group:BUNDLE line and the BUNDLE semantics gets
rejected, there is no way for the Software to auto imply RTCP multiplexing
or not. This is when the current semantics of the IDENTICAL category ( as
defined in section 4.3 of mux-attributes draft) come into play.

Thus i do believe that there needs to be clarification, in the Section 8.1
of BUNDLE spec, on the interpretation of the IDENTICAL category attributes
before and after the BUNDLE address selection process. It already handles
the post shared address selection but it lacks the pre-selection
consideration.

> I submit that BUNDLE is right here and the mux attributes document is
> wrong and
> we should not duplicate.
>
> -Ekr
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>