Subject: [MMUSIC] BUNDLE: Splitting a BUNDLE

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2013 11:58:28 +0000

Hi,

We seem to have an agreement that, when an SDP offer contains an m- line associated with a bundle group, it is ok to leave that m- line outside the bundle group in the SDP Answer.

Now, there has been some discussions about "splitting" a BUNDLE, meaning that an m- line in an SDP Answer is added to a DIFFERENT bundle group than in the SDP Offer.

Based on the discussions, it seems like people would be ok to NOT allow that. If the SDP Answerer wants to put an m- line in another bundle group, it needs to first reply to the SDP Offer, and then send a new SDP Offer itself, putting the m- line in the bundle group it wants.

In short, is basically means: in an SDP Answer, an m- line must only be bundle grouped with the same m- lines (or, a subset of those) as in the associated SDP Offer.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 11:16:49 -0400

On 5/13/13 7:58 AM, Christer Holmberg wrote:
> Hi,
>
> We seem to have an agreement that, when an SDP offer contains an m- line
> associated with a bundle group, it is ok to leave that m- line outside
> the bundle group in the SDP Answer.
>
> Now, there has been some discussions about “splitting” a BUNDLE, meaning
> that an m- line in an SDP Answer is added to a DIFFERENT bundle group
> than in the SDP Offer.
>
> Based on the discussions, it seems like people would be ok to NOT allow
> that. If the SDP Answerer wants to put an m- line in another bundle
> group, it needs to first reply to the SDP Offer, and then send a new SDP
> Offer itself, putting the m- line in the bundle group it wants.
>
> In short, is basically means: in an SDP Answer, an m- line must only be
> bundle grouped with the same m- lines (or, a subset of those) as in the
> associated SDP Offer.

Yes, this is the conclusion I reached. I wish it weren't true. But I 
think there must be a mechanism for the new bundle to be rejected, and 
if it is first proposed in the answer then that isn't possible.

IMO this is a rare enough case that suffering another O/A is acceptable.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 May 2013 19:53:29 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 
> > Now, there has been some discussions about b> 

I agree with Paul here.  Allowing a new group (bundle) to be created
in an answer is a much larger deviation from RFC 5888 than allowing an
m= line with a zero port to be in a group, and the accept/reject
problem can't be solved.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 May 2013 12:01:04 +0000

Hi,

>>> We seem to have an agreement that, when an SDP offer contains an m- 
>>> line associated with a bundle group, it is ok to leave that m- line 
>>> outside the bundle group in the SDP Answer.
>>>
> I agree with Paul here.

Me too :)

> Allowing a new group (bundle) to be created in an answer is a much larger deviation from RFC 5888 than allowing an m= line with a zero port to be in a group, and the accept/reject problem can't be solved.

Note that there are two cases:

1) A new bundle is created in the answer

2) An m- line is moved from bundle_x in the offer to bundle_y in the answer. bundle_y was also present in the offer, so it is not created by the answerer.

In my opinion 2) should not be allowed either, as the m- line was not present in bundle_y in the offer.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 May 2013 16:36:50 -0400 (EDT)

> From: Christer Holmberg <[email-masked]>
> 
> 2) An m- line is moved from bundle_x in the offer to bundle_y in the
> answer. bundle_y was also present in the offer, so it is not created
> by the answerer.
> 

Ugh, yes.  Especially since the offerer probably does not want, and
cannot support, the presence of that m= line in bundle_y.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 May 2013 11:50:33 -0400

> cannot support, the presence of that m= line in bundle_y.

+1

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 21 May 2013 14:52:54 +0000

> In my opinion 2) should not be allowed either, as the m- line was not present in bundle_y in the offer.

Agree with you and to say more …

I think that both 1 and 2 should *not* be allowed. There is no use case to drive needing them and it is complicated. That can be done with a new offer if needed. 

> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 May 2013 15:41:14 -0700

Agree completely. Otherwise media may show up at an unexpected port for the
offerer.

On Tue, May 21, 2013 at 7:52 AM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> >> Allowing a new group (bundle) to be created in an answer is a much
> larger deviation from RFC 5888 than allowing an m= line with a zero port to
> be in a group, and the accept/reject problem can't be solved.
> >
> answer. bundle_y was also present in the offer, so it is not created by the
> answerer.
> >
> I think that both 1 and 2 should *not* be allowed. There is no use case to
> drive needing them and it is complicated. That can be done with a new offer
> if needed.
>
>
> > Regards,
> >
> > Christer
> >
> >

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 01:17:50 -0700

+ 1
If the Answerer decides to move the m=line to a different BUNDLE group, i
support rejecting and re-offering than doing 1 or 2 above,

Thanks
Suhas

On Tue, May 21, 2013 at 3:41 PM, Justin Uberti <[email-masked]> wrote:

> Agree completely. Otherwise media may show up at an unexpected port for
> the offerer.
>
>
> On Tue, May 21, 2013 at 7:52 AM, Cullen Jennings (fluffy) <
> [email-masked]> wrote:
>
>>
>> I think that both 1 and 2 should *not* be allowed. There is no use case
>> to drive needing them and it is complicated. That can be done with a new
>> offer if needed.
>>
>>
>> > Regards,
>> >
>> > Christer
>> >
>> >