Subject: [MMUSIC] BUNDLE: Accept m- line, reject bundle

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 13:07:00 +0000

Hi,

Assume the following case:

1.       An SDP offer contains an m- line associated with a BUNDLE group

2.       The answerer wants to accept the m- line, but wants to reject it being in the specific BUNDLE group.

A few alternatives on how this could be achieved have been presented:

Alt 1.      The answerer accepts the m- line, but does not associate it with a BUNDLE group.

Alt 2.      The answerer accepts the m- line, associates it with a BUNDLE group, and then sends a new offer which removes the m- line from the BUNDLE group.

Alt 3.      The answerer rejects the m- line, and then sends a new offer which adds the m- line outside a BUNDLE group.

In my opinion, Alt 1 does not work, at least not if the offer contains identical port values for the m- lines associated with the BUNDLE group. It would mean that the m- line is not added to a BUNDLE group, but still has the same port value (at least at the offerer side) as the m- lines in the BUNDLE group, which is not allowed.

So, my suggestion would be to specify that the answerer must use Alt 2 and/or Alt 3.

Comments?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 May 2013 11:01:21 -0400

On 5/3/13 9:07 AM, Christer Holmberg wrote:
> 1.An SDP offer contains an m- line associated with a BUNDLE group
>
> 2.The answerer wants to accept the m- line, but wants to reject it being
> in the specific BUNDLE group.
>
> Alt 2.      The answerer accepts the m- line, associates it with a
> BUNDLE group, and then sends a new offer which removes the m- line from
> the BUNDLE group.
>
> Alt 3.      The answerer rejects the m- line, and then sends a new offer
> which adds the m- line outside a BUNDLE group.
>
> In my opinion, Alt 1 does not work, at least not if the offer contains
> identical port values for the m- lines associated with the BUNDLE group.
> It would mean that the m- line is not added to a BUNDLE group, but still
> has the same port value (at least at the offerer side) as the m- lines
> in the BUNDLE group, which is not allowed.
>

I don't think we should restrict flexibility here when it works and 
makes sense.

I agree that Alt 1 doesn't work *if* the m-line in question shares 
addr/prot with other m-lines that are also accepted, bundled or not. But 
the normal first offer won't present that situation. If the addr/port in 
the m-line in question is unique among all the accepted m-lines, then 
this should be acceptable.

(Note, this is a degenerate case of bundle splitting. There are real use 
cases for it. If it can be done without a 2nd o/a, then lets allow that.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 20:03:28 +0000

Hi,

> cases for it. If it can be done without a 2nd o/a, then lets allow that.)

I was thinking that, by not allowing it, we could have a general rule saying something like:

"If an m- line in an offer is associated with a BUNDLE group, it MUST be associated with a BUNDLE group in the associated answer, unless the answerer sets the port value to zero."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 May 2013 16:25:48 -0400

> "If an m- line in an offer is associated with a BUNDLE group, it MUST be associated with a BUNDLE group in the associated answer, unless the answerer sets the port value to zero."

Is the goal to minimize the number of words in the draft? :-)

I think this would be eliminating a scenario with practical utility.
And allowing it doesn't make the implementation significantly harder.
(The offerer must be prepared for the whole bundle to be rejected. This 
is a variant of that. For the m-lines that are removed from the bundle 
it is as if the bundle had been rejected. For the other m-lines it is as 
if the bundle had been accepted.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 4 May 2013 04:40:02 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Christer Holmberg
> Sent: Friday, May 03, 2013 6:07 AM
> To: [email-masked]
> Subject: [MMUSIC] BUNDLE: Accept m- line, reject bundle
> 
> Hi,
> 
> 
> 
> BUNDLE group, and then sends a new offer which removes the m-
> line from the BUNDLE group.
> 
> 
> 
> identical port values for the m- lines associated with the BUNDLE
> group. It would mean that the m- line is not added to a BUNDLE
> group, but still has the same port value (at least at the offerer side)
> as the m- lines in the BUNDLE group, which is not allowed.

True, but isn't that precisely what will happen if the answerer does not understand/support BUNDLE?
So at this point the offerer could choose to send a re-INVITE to use different receive ports for the non-bundled m-lines.
I would not put that burden on the answerer.

Cheers,
Charles

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 4 May 2013 06:15:55 +0000

Hi Charles,

Just to clarify, I am talking about a case where the answerer DOES support BUNDLE, but for some reason it does not want to accept the m- line within a BUNDLE group.

Regards,

Christer
________________________________________
From: Charles Eckel (eckelcu) [[email-masked]]
Sent: Saturday, 04 May 2013 7:40 AM
To: Christer Holmberg; [email-masked]
Subject: RE: BUNDLE: Accept m- line, reject bundle

Cheers,
Charles

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 6 May 2013 14:00:27 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

Strictly speaking, it's not like other cases of bundle splitting,
because the separated m= line is not put into another bundle, but
remains unbundled.  Because of that, the design considerations are
likely to be somewhat different.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 14:33:18 -0400

> likely to be somewhat different.

In my view it is a degenerate form that admits to special optimizations.

It *could* be handled by establishing new bundles containing only the 
single m-line. But there is no value in doing that. And by *not* doing 
it, it is possible to handle everything in a single O/A rather than 
requiring a 2nd one.

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 10 May 2013 20:47:19 +0000

> So, my suggestion would be to specify that the answerer must use Alt 2 and/or Alt 3.

I think you want to to Alt 1. 

Say Alice sends offer with with three m lines in a bundle. Note they will have different ports. 

Then Bob sends answer with two of these in the bundle and the one of them not in the bundle. The two in the bundle will have the same port and be in the bundle group but the third will not be in a bundle and will have a different port. 

And like all bundle & ice usage, when everything is done negotiating there can be the final O/A to clean up all the SBCs.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 13:54:24 -0700

> I think you want to to Alt 1.

I'm on Alt 1 as well.  There are two signals that this is unbundled:
  a. The port is different.
  b. The BUNDLE group doesn't include the mid.
The former wouldn't be sufficient, but the latter is always enough.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2013 18:01:44 -0400

It sounds like we are approaching violent agreement on this.

But what about "bundle splitting" that I introduced even before this 
discussion began? It is more complex. Because of the rule that a bundle 
can't include an m-line with zero port, it is forced to use Alt-3.

IMO Alt 1-3 are all "valid", if the answerer finds them acceptable to 
it. But for certain common cases its pretty clear that one is clearly 
better than another.

Alt 1 is better in cases when you can use it. Alt 3 should work when Alt 
1 won't. I envision no cases when Alt 2 is useful, but I see no reason 
to ban it.

	Thanks,
	Paul

On 5/10/13 4:54 PM, Martin Thomson wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 May 2013 15:14:11 -0700

On 10 May 2013 15:01, Paul Kyzivat <[email-masked]> wrote:
> Alt 1 is better in cases when you can use it. Alt 3 should work when Alt 1
> won't. I envision no cases when Alt 2 is useful, but I see no reason to ban
> it.

I agree.  A good summary.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2013 07:44:41 +0000

Hi,

Ok, so the outcome seems to be that we allow Alt 1 as long as the rejected m- lines in the offer contains unique port numbers.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 11. toukokuuta 2013 1:14
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle

On 10 May 2013 15:01, Paul Kyzivat <[email-masked]> wrote:
> Alt 1 is better in cases when you can use it. Alt 3 should work when 
> Alt 1 won't. I envision no cases when Alt 2 is useful, but I see no 
> reason to ban it.

I agree.  A good summary.

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 02:20:42 -0700

Hello Christer
  Sorry for the delayed response.

   I do support Alt-1 in the cases when the Offerer doesnot know of
Answerer;s BUNDLE support.
  and
 Alt-3 in the case, when Both the parties can support BUNDLE but Answerer
wants to change the offered configuration for a reason specific to it. In
which case, the Answerer should take the lead on setting up the new offer
to let its intention known.

Thanks
Suhas

On Mon, May 13, 2013 at 12:44 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Ok, so the outcome seems to be that we allow Alt 1 as long as the rejected
> m- lines in the offer contains unique port numbers.
>
> Regards,
>
> Christer
>