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

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 10:43:36 +0000

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

---

From: Bo Burman <[email-masked]>
Date: Wed, 5 Oct 2016 17:44:06 +0000

Christer,

You mean this might impact how the IDENTICAL and TRANSPORT categories should be defined in -mux-attributes? That would be a pretty fundamental change.

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?

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.

/Bo
(as individual)

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: den 4 oktober 2016 12:44
To: [email-masked]
Cc: [email-masked]
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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 18:14:25 +0000

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

> This already seems aligned with what you suggest below.

Yes.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: den 4 oktober 2016 12:44
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes: Do we need to mandate identical SDP attribute values?

Hi,

Comments?

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 5 Oct 2016 11:45:10 -0700

On Wed, Oct 5, 2016 at 11:14 AM, Christer Holmberg <
[email-masked]> wrote:

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

> *From:* mmusic [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Christer Holmberg
> *Sent:* den 4 oktober 2016 12:44
> *To:* [email-masked]
> *Cc:* [email-masked]
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 18:58:44 +0000

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

              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.

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

Yes.

Regards,

Christer

Hi,

Comments?

Regards,

Christer

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 5 Oct 2016 12:09:43 -0700

On Wed, Oct 5, 2016 at 11:58 AM, Christer Holmberg <
[email-masked]> wrote:

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

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"

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 19:33:02 +0000

Hi,
Hi,

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?

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

.

Regards,

Christer

Yes.

Regards,

Christer

Hi,

Comments?

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 5 Oct 2016 12:57:12 -0700

Hi ,

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

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Oct 2016 09:35:44 +0000

Hi,

…
[Suhas]

Meta Note:

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

Correct.

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 )

If there is no rtcp-mux attribute, and if the BUNDLE is rejected (or if an m- line is not accepted into the BUNDLE group), normal SDP O/A procedures apply and there would be no RTCP MUX.

Anyway, even if we do mandate identical attribute values in case of IDENTICAL, is draft-mux-categories clear that it applies already before a BUNDLE group has been created? I believe there were some clarification questions about that also earlier.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 6 Oct 2016 04:29:24 -0700

Hi,

On Thu, Oct 6, 2016 at 2:35 AM, Christer Holmberg <
[email-masked]> wrote:

> 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.
>
> Correct.
>
> If there is no rtcp-mux attribute, and if the BUNDLE is rejected (or if an
> m- line is not accepted into the BUNDLE group), normal SDP O/A procedures
> apply and there would be no RTCP MUX.
>
> Anyway, even if we do mandate identical attribute values in case of
> IDENTICAL, is draft-mux-categories clear that it applies already before a
> BUNDLE group has been created? I believe there were some clarification
> questions about that also earlier.
>
>
[Suhas] .. I personally feel that clarification should be in the BUNDLE
spec. BUNDLE spec already has clarification on how IDENTICAL and TRANSPORT
categories are treated once shared address is selected as you pointed out
earlier (also in section 8.1).
Similarly, it needs to to address the case for before shared address
getting selected, if it is not already (I thought section 7.3 implied that
already).

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 7 Oct 2016 11:42:48 -0700

Hi Christer,Bo

   Just to close the loop on this topic, I don't see misalignment between
Bundle and Mux specs. However, adding  clarification on the fact that the
categories apply even during the initial offer(or before bundle gets
negotiated) and their semantics apply , might be needed in the Bundle spec,
if it is not already clear

Section 8.1 already talks about categories interpretation once bundle gets
negotiated. That section might be a right place to add above clarification.
I would leave the decision to Christer on that :)

Thanks
Suhas

On Thursday, October 6, 2016, Suhas Nandakumar <[email-masked]> wrote:

> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hi,
>>
>> …
>>
>>> [Suhas]
>>>
>>>
>>>
>>> Meta Note:
>>>
>>> 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]
>>
>> If there is no rtcp-mux attribute, and if the BUNDLE is rejected (or if
>> an m- line is not accepted into the BUNDLE group), normal SDP O/A
>> procedures apply and there would be no RTCP MUX.
>>
>> IDENTICAL, is draft-mux-categories clear that it applies already before
>> a BUNDLE group has been created? I believe there were some clarification