Subject: [MMUSIC] BUNDLE ALMOST DECISSION: BUNDLE PORT

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2013 12:39:23 +0000

Hi,

At the interim yesterday, we agreed to use the SDP BUNDLE group attribute to indicate on which port bundled media will be sent. In an SDP offer, the order of the attribute mid values can be used by the offerer to indicate a "wish", but the first attribute mid value in the answer indicates where the answerer will eventually send bundled media.

The main usage of this is the "initial offer", when each m- line within a bundle group has a different port value.

So far so good.

The reason I say "almost decision" is because we have started a new discussion regarding updated offers, adding new m- lines etc. We need to make sure that the order-to-mid-values semantics also apply to those, and what restrictions there are when adding m- lines.

But, for now, if you OBJECT to the general principle of using the SDP group attribute mid value order for indicating the port where media will be sent, please indicate so.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 May 2013 10:49:15 -0400

On 5/24/13 8:39 AM, Christer Holmberg wrote:
> Hi,
>
> At the interim yesterday, we agreed to use the SDP BUNDLE group
> attribute to indicate on which port bundled media will be sent. In an
> SDP offer, the order of the attribute mid values can be used by the
> offerer to indicate a “wish”, but the first attribute mid value in the
> answer indicates where the answerer will eventually send bundled media.

This could be interpreted to mean the first a=mid value in the SDP.
I'm sure you mean "the first mid value in the a=group:bundle" line.
Or perhaps "the first mid value in the bundle group" - assuming there is 
a definition that "bundle group" means an a=group:bundle line.

This can be "future proofed" by saying that the first mid value in the 
bundle group in the answer that references an m-line with non-zero port 
value. I realize this adds nothing unless 5888 is revised to permit 
m-lines with zero port in a bundle group. But at least it will be ready 
for that, and harms nothing.

	Thanks,
	Paul

> The main usage of this is the “initial offer”, when each m- line within
> a bundle group has a different port value.
>
> So far so good.
>
> The reason I say “almost decision” is because we have started a new
> discussion regarding updated offers, adding new m- lines etc. We need to
> make sure that the order-to-mid-values semantics also apply to those,
> and what restrictions there are when adding m- lines.
>
> But, for now, if you OBJECT to the general principle of using the SDP
> group attribute mid value order for indicating the port where media will
> be sent, please indicate so.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 24 May 2013 16:00:44 -0700

Hey Christer

   This looks good to me. I personally feel this approach is agnostic of
inclusions and exclusions of m=lines in  the subsequent session
modifications "Eventually".
Also this aligns with the current framework for categorizing
SDP attributes with multiplexing.

Cheers
Suhas

On Fri, May 24, 2013 at 5:39 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> At the interim yesterday, we agreed to use the SDP BUNDLE group attribute
> to indicate on which port bundled media will be sent. In an SDP offer, the
> order of the attribute mid values can be used by the offerer to indicate a
> “wish”, but the first attribute mid value in the answer indicates where the
> answerer will eventually send bundled media.****
>
> ** **
>
> The main usage of this is the “initial offer”, when each m- line within a
> bundle group has a different port value.****
>
> ** **
>
> So far so good.****
>
> ** **
>
> make sure that the order-to-mid-values semantics also apply to those, and
> what restrictions there are when adding m- lines.****
>
> ** **
>
> group attribute mid value order for indicating the port where media will be
> sent, please indicate so.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 09:27:23 +0000

Hi,

>> offerer to indicate a "wish", but the first attribute mid value in the 

Yes.

>Or perhaps "the first mid value in the bundle group" - assuming there is a definition that "bundle group" means an a=group:bundle line.

In the draft "bundle group" means (or, at least is supposed to mean :) the bundle grouped m- lines, and in general I think it is better to explicitly mention the line/attribute.

> This can be "future proofed" by saying that the first mid value in the bundle group in the answer that references an m-line with non-zero 
> port value. I realize this adds nothing unless 5888 is revised to permit m-lines with zero port in a bundle group. But at least it will be ready for that, and harms nothing.

I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line.

Regards,

Christer

> The main usage of this is the "initial offer", when each m- line 
> within a bundle group has a different port value.
>
> So far so good.
>
> The reason I say "almost decision" is because we have started a new 
> discussion regarding updated offers, adding new m- lines etc. We need 
> to make sure that the order-to-mid-values semantics also apply to 
> those, and what restrictions there are when adding m- lines.
>
> group attribute mid value order for indicating the port where media 
> will be sent, please indicate so.
>
> Regards,
>
> Christer
>
>
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 27 May 2013 13:41:49 +0000

sounds good to me along with the port zero fix

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 May 2013 12:32:36 -0400

> I agree, but suggest a little different wording: by saying the first mid value in the group attribute MUST NOT represent a port zero m- line.

I just want to be sure we're clear here.

Are you saying that even if we relax 5888 so that we may have m-lines 
with port zero in a bundle group, that the *first* mid in the bundle 
group can't designate a zero port???

I guess that should always be possible as long as there is at least one 
with a non-zero port.

Do we have a possibility, with ICE, that all the m-lines in the bundle 
will have zero port? (Because we are waiting for ICE to figure out the 
actual port.) Or are we going to use something else for that purpose?

As long as there is no possibility of having a bundle where all the 
ports are zero then I'm ok with what you propose.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 17:16:24 +0000

Hi,

> group can't designate a zero port???

Yes, for BUNDLE. It doesn't have to be a generic 5888 rule.

> ports are zero then I'm ok with what you propose.

I hear what you're saying.

But, in that case saying "first non-zero mid" does not work either, does it? :)

Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 May 2013 13:42:25 -0400

> But, in that case saying "first non-zero mid" does not work either, does it? :)

Yep, you're right!

> Another option is to also allow mids for zero-port m- lines to be first. A first mid for a port zero m- line would mean that there is no port for bundled media. Maybe there could be a use-case for…

That sounds like a bad choice if one of the other m-lines in the bundle 
has a non-zero port.

So maybe your rule is best, if it works: first mid in bundle must 
identify an m-line in the bundle with non-zero port if there is one. If 
there are non with non-zero port then it can refer to one that is zero.

But we can't take this too far without deciding if we want to allow 
rejected m-lines in bundles, and if so, what that means.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 17:51:26 +0000

Hi,

> That sounds like a bad choice if one of the other m-lines in the bundle has a non-zero port.

I agree, but it would allow us to have a generic rule, which would be applicable also in the case where all m- lines have zero port values (assuming we'll allow such m- lines in a bundle group to begin with, that is).

> rejected m-lines in bundles, and if so, what that means.

I don't think it means anything else than that the media associated with the m- line is disabled. As you have said earlier, having a port-zero-m-line in a bundle could be used as a "hint that it may be used within a bundle later", but I can't think of any new technical semantics. Plan A uses port-zero-m-lines, but the plan doesn't define new semantics for the port value itself.

Regards,

Christer