Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes: Do we need to mandate identical SDP attribute values?

[Suhas Nandakumar <[e-mail]>]

Hi ,


On Wed, Oct 5, 2016 at 12:33 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> Hi,
>
> >You mean this might impact how the IDENTICAL and TRANSPORT categories
> should be >defined in -mux-attributes? That would be a pretty fundamental
> change.
>
>
>
> It’s not related to the definition of IDENTICAL and TRANSPORT as such. It
> is more related to mandating the same attribute values in all m- lines, as
> at the end of the day only the attribute values in the BUNDLE m- line
> matters.
>
> >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.
>
> >
>
> >This text could in principle be changed say that the attribute of the
> “m=” line whose >information is used to define the multiplexed group (for
> BUNDLE that is the “m=” line >carrying the mid listed first on the
> “a=BUNDLE” line). Would you allow “m=” lines in the >multiplexed group to
> have other values of an IDENTICAL category attribute, even if the >value
> to use when multiplexed is given by the BUNDLE “m=” line? In what way would
> >that be useful or an improvement compared to (as now) require that
> values are actually >identical when multiplexed?
>
>
>
> In fact, based on a rather recent change, BUNDLE actually says (see below)
> that IDENTICAL and TRANSPORT attribute are ONLY inserted in the BUNDLE m-
> line to begin with. So, we are already misaligned, as we don’t repeat them
> across all m- lines…
>
>
>
> “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*.”
>
>
>
>
>
> [suhas] - So what happens if BUNDLE-tag m=line in the offer gets rejected
> and say rtcp-mux was just included only on  that m=line as per above text
> form BUNDLE text.  If i understand right, there is no rtcp mux for any of
> the m=lines which is not the Offerer might want
>
>
>
> Note that the text only applies to the case when the m- line contains a
> shared address, i.e., it has already been accepted into the BUNDLE group.
>
>
>
> When you send the initial offer (before the BUNDLE group has been
> created), or when you want to add a new m- line to a BUNDLE group, you have
> to include all attributes in all m- lines, using normal 3264 procedures.
> But, in that case I don’t think draft-mux-attributes applies to begin with,
> i.e., you can include whatever attribute values, and they will be used if
> the m- line is not accepted into the BUNDLE group. draft-mux-attributes
> only applies once the BUNDLE group has been created. At least that is my
> understanding
>
>
>
> [Suhas]
>
>
>
> Meta Note:
>
> The mux draft has stayed away from offer/answer procedures to avoid
> ambiguities with offers/re-offers and its focus has been defining generic
> framework categorizing SDP attributes while performing Media multiplexing
>
>
>
> Thus, the case of initial offer applies as well. In that context, on
> Initial Offer, the offerer will repeat the SDP attributes that fall under
> IDENTICAL category on all the m=lines that it plans to multiplex.
>
>
>
> What is the reason for having different rules for IDENTICAL and TRANPORT?
> With TRANSPORT you can use different attribute values, because the
> “software will pick the correct value”. Why not use the software-must-pick
> rule also for IDENTICAL?
>
>
>

[Suhas]

 Let's try to explain this with example attributes. a=rtcp-mux which is
categorized as IDENTICAL and ice-candidates which falls under TRANSPORT
category.

For ice-candidates ,the offerer in the initial offer will include different
ice-pwd, candidates lines per m=line since it's not sure of the BUNDLE
negotiation. Thus once BUNDLE gets successfully negotiated , the software
picks the ones from the m=line that is selected for BUNDling. OTOH, if the
BUNDLE get's rejected each m=line's individual ice info will be used.

For a=rtcp-mux,  in the initial Offer, the offerer must include it in all
the m=lines (repeated) since there is no way for the software to decide the
intent of the Offerer in scenarios where the BUNDLE gets rejected ( If the
offerer didn't repeat the attribute, the software cannot assume the
offerer's intention of whether to imply a=rtcp-mux for  the m=lines or the
Offerer itself didn't want to perform rtcp muxing )

In summary, the categories IDENTICAL and TRANSPORT serve different semantic
categories and apply to different SDP attributes.

However, when BUNDLE is successfully negotated, the semantics from the
BUNDLE spec defines how these categories and attributes are treated and as
we discussed earlier it makes sense to include those only on the BUNDLEd
m=line






>
>
> As far as what happens in the subsequent Offer/Answers once BUNDLE address
> gets selected is very BUNDLE semantic specific and its totally fine to say
> that "the attributes under IDENTICAL & TRANSPORT categories needs to be
> included only in the m-line  that selected for BUNDLing once BUNDLE is
> successfully negotiated"
>
>
>
> Good.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> .
>
>
>
> My point is that what is important is that draft-mux-attributes defines
> which categories apply to all m- lines in the BUNDLE group – NOT whether
> the attribute values in the SDP need to identical, as the values are taken
> from the BUNDLE m- line.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> >4.5.  Category: TRANSPORT
>
> >
>
> >   The attributes in the TRANSPORT category can be set normally for
>
> >   multiple items in a multiplexed group but the software MUST pick the
>
> >   one that's associated with the "m=" line whose information is used
>
> >   for setting up the underlying transport.
>
> >
>
> > This already seems aligned with what you suggest below.
>
>
>
> Yes.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* mmusic [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Christer Holmberg
> *Sent:* den 4 oktober 2016 12:44
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes: Do we need to
> mandate identical SDP attribute values?
>
>
>
> Hi,
>
>
>
> Based on Ekr’s review of BUNDLE, it has been suggested that the text
> should not focus so much on whether the bundled m- line addresses are
> “shared” or “unique”. The important thing is that the BUNDLE m- line
> specifies the address for the bundle group.
>
>
>
> I wonder if the same thing applies also to SDP attributes
> (read: draft-ietf-mmusic-sdp-mux-attributes): E.g., what is important is
> whether an attribute property is applied to all bundled m- lines or not
> (based on the mux category) – not whether the SDP attribute values must be
> identical in different m- lines.
>
>
>
> Comments?
>
>
>
> Regards,
>
>
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>