Subject: [MMUSIC] BUNDLE Weekly Summary: Assumptions

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

Hi,

In order to try to close issues on BUNDLE, based on the discussions we've had, I intend to update the BUNDLE draft based on the following assumptions:

1.       We mandate usage of rtcp-mux when BUNDLE is used.

2.       SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, due to this, the number of m- lines associated with a BUNDLE group may differ between the offer and the associated answer. There will also be a note indicating that this is due to RFC 5888, in case people later start to wonder where the "MUST NOT" comes from.

Please indicate if you OBJECT to any of these assumptions.

Regards,

Christer

---

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

On 5/3/13 8:53 AM, Christer Holmberg wrote:
> Hi,
>
> In order to try to close issues on BUNDLE, based on the discussions
> we’ve had, I intend to update the BUNDLE draft based on the following
> assumptions:
>
> 1.We mandate usage of rtcp-mux when BUNDLE is used.

Are you going to include the possibility of bundling non-RTP m-lines?
(Needed if we are to include DTLS/SCTP.)

If so, then of course the use of rtcp-mux only applies to RTP m-lines.

(Of course, if only one DTLS/SCTP line can be included, a bundle without 
RTP is not very interesting. But it doesn't hurt to make this ready for 
future bundling of other things.)

> 2.SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE
> group (not in an offer, nor in an answer). There will be a note
> indicating that, due to this, the number of m- lines associated with a
> BUNDLE group may differ between the offer and the associated answer.
> There will also be a note indicating that this is due to RFC 5888, in
> case people later start to wonder where the “MUST NOT” comes from.
>

Aside from the above comment I have no objections.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 17:41:08 +0000

Hi,

> (Needed if we are to include DTLS/SCTP.)

Yes.

I guess I should have listed that as a third assumption.

> If so, then of course the use of rtcp-mux only applies to RTP m-lines.

Correct.

> future bundling of other things.)

Agree. My intention is not to mandate a BUNDLE group to contain RTP media.

> Aside from the above comment I have no objections.

And, the zero port value restriction would of course apply to any media type (not only RTP).

Regards,

Christer

---

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

On May 3, 2013, at 6:53 AM, Christer Holmberg <[email-masked]> wrote:

> Hi,
>  
> In order to try to close issues on BUNDLE, based on the discussions we’ve had, I intend to update the BUNDLE draft based on the following assumptions:
>  

agree with this

>  
> 2.       SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, due to this, the number of m- lines associated with a BUNDLE group may differ between the offer and the associated answer. There will also be a note indicating that this is due to RFC 5888, in case people later start to wonder where the “MUST NOT” comes from.

object to this. I think EKR's idea of doing this explicitly in an offer to indicate that the line is only being offered in a bundle is a good one. 

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

---

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

> object to this. I think EKR's idea of doing this explicitly in an offer to indicate that the line is only being offered in a bundle is a good one.

Then we must revise 5888.

Its hard to say whether we could get away with making that change 
without dealing with backward compatibility issues.

Maybe we should ask the authors (Gonzalo and Henning) why that 
limitation was put in. It does seem pretty arbitrary.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2013 15:05:46 -0700

On Fri, May 10, 2013 at 2:21 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> > 2.       SDP m- lines with a zero port value MUST NOT be put inside a
> BUNDLE group (not in an offer, nor in an answer). There will be a note
> BUNDLE group may differ between the offer and the associated answer. There
> will also be a note indicating that this is due to RFC 5888, in case people
> later start to wonder where the “MUST NOT” comes from.
>
> object to this. I think EKR's idea of doing this explicitly in an offer to
> indicate that the line is only being offered in a bundle is a good one.
>
>
I'm sorry to be slow today, but can you point me to the specific MUST NOT
in RFC 5888.

-Ekr

---

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

> object to this. I think EKR's idea of doing this explicitly in an offer to indicate that the line is only being offered in a bundle is a good one.

+1

I'd prefer to keep the concepts of bundling (in-out) and negotiated
(on-off) as two orthogonal switches.

---

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

On 10 May 2013 15:05, Eric Rescorla <[email-masked]> wrote:
> I'm sorry to be slow today, but can you point me to the specific MUST NOT in
> RFC 5888.

I struggled to find it too.  It's in 9.2:

   SIP entities refuse media streams by setting the port to zero in the
   corresponding "m" line. "a=group" lines MUST NOT contain
   identification-tags that correspond to "m" lines with the port set to
   zero.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2013 15:17:54 -0700

>    identification-tags that correspond to "m" lines with the port set to

This feels like something we could relax for the offer.

---

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

On 5/10/13 6:05 PM, Eric Rescorla wrote:

>      > 2.       SDP m- lines with a zero port value MUST NOT be put
>     inside a BUNDLE group (not in an offer, nor in an answer). There
>     will be a note indicating that, due to this, the number of m- lines
>     associated with a BUNDLE group may differ between the offer and the
>     associated answer. There will also be a note indicating that this is
>     due to RFC 5888, in case people later start to wonder where the
>     “MUST NOT” comes from.
>
>     object to this. I think EKR's idea of doing this explicitly in an
>     offer to indicate that the line is only being offered in a bundle is
>     a good one.
>
>
> I'm sorry to be slow today, but can you point me to the specific MUST
> NOT in RFC 5888.

Section 9.2:

While this is stated in the context of answers, the statement itself 
seems unqualified. And it would be pretty silly if you could do it in 
the offer and not in the answer.

	Thanks,
	Paul

---

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

On 10 May 2013 15:17, Eric Rescorla <[email-masked]> wrote:
>> > NOT in

Absolutely.  It seems a little arbitrary.  That said, I'd like to
understand why the MUST NOT exists.  Of the groupings I understand, I
can't think of a reason not to allow negotiated-off lines, but I'm
prepared to be surprised.

---

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

On 5/10/13 6:17 PM, Eric Rescorla wrote:
>
>
> On Fri, May 10, 2013 at 3:16 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 10 May 2013 15:05, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:

We could relax it. The question is if the change will break any existing 
use. That is a hard question to answer.

If we do relax it, then we should do for both offer and answer. Doing 
just for offer is stupid and bound to introduce further complications.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2013 15:26:28 -0700

On Fri, May 10, 2013 at 3:23 PM, Martin Thomson <[email-masked]>wrote:

> > On Fri, May 10, 2013 at 3:16 PM, Martin Thomson <
> [email-masked]>
> > wrote:
> >>

Indeed.

Of course, if it is a problem we can invent:
a=group-without-5888-restrictions:....

-Ekr

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 10 May 2013 22:34:55 +0000

On May 10, 2013, at 4:26 PM, Eric Rescorla <[email-masked]> wrote:

> On Fri, May 10, 2013 at 3:23 PM, Martin Thomson <[email-masked]> wrote:
> a=group-without-5888-restrictions:….

+1

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 10 May 2013 18:44:50 -0400

> use. That is a hard question to answer.

We could say that whether it's valid must be defined by the group semantic, and for all existing group semantics it's not.

--
Jonathan Lennox
[email-masked]

---

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

> We could say that whether it's valid must be defined by the group semantic, and for all existing group semantics it's not.

WFM

---

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

Hi,

So, assuming we are going to update RFC 5888 (whatever the exact wording would be), would we do that within draft-bundle, or within a separate document?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 11. toukokuuta 2013 3:40
To: Jonathan Lennox
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions

On 5/10/13 6:44 PM, Jonathan Lennox wrote:

>> We could relax it. The question is if the change will break any 
>> existing use. That is a hard question to answer.
>

WFM

---

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

Hi,

A few questions, assuming we allow port zero m- lines within a bundle.

Q1:

Is the decision tied to whether we move forward with Plan A or Plan B?

Q2:

Do we allow port zero only for "bundle-only" m- lines, or for m- lines in general?

Q3:

If we allow port zero only for "bundle-only" m- lines, is there a technical need to allow it in SDP answers?

Q4:

We need to keep in mind that there is always a chance that the "top-most" m- line within a bundle group is a port zero one. 

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 13. toukokuuta 2013 10:27
To: Paul Kyzivat; Jonathan Lennox
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions

Hi,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 11. toukokuuta 2013 3:40
To: Jonathan Lennox
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions

WFM

---

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

> So, assuming we are going to update RFC 5888 (whatever the exact wording would be), would we do that within draft-bundle, or within a separate document?

That question always comes up, doesn't it?

IMO this could probably be handled in the bundle draft, since it is a 
small change and by the same wg. But it isn't my call. This question 
should be addressed by the chairs and the ADs.

	Thanks,
	Paul

---

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

> A few questions, assuming we allow port zero m- lines within a bundle.

IMO we should try to keep mechanisms as flexible and independent of one 
another as possible. Answers below are based on that.

> Is the decision tied to whether we move forward with Plan A or Plan B?

No. Why should it be?

> Do we allow port zero only for "bundle-only" m- lines, or for m- lines in general?

Any m-lines. I can't see any reason to be restrictive.

> If we allow port zero only for "bundle-only" m- lines, is there a technical need to allow it in SDP answers?

Again, keep things separate and clear. If I'm offered a bundled m-line 
with non-zero port, and want to reject it, I should be able to do so by 
setting the port to zero, just as if it was not bundled. Independently, 
if I'm offered a bundled m-line I may need to exclude it from the 
bundle, and I should be able to make that decision while either 
accepting or rejecting the m-line.

> We need to keep in mind that there is always a chance that the "top-most" m- line within a bundle group is a port zero one.

What is the question?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2013 18:26:40 +0000

Hi,

>> IMO we should try to keep mechanisms as flexible and independent of one another as possible. Answers below are based on that.
>>
>> Q1:
>>
> Again, keep things separate and clear. If I'm offered a bundled m-line with non-zero port, and want to reject it, I should be able to do
> so by setting the port to zero, just as if it was not bundled. Independently, if I'm offered a bundled m-line I may need to exclude it from 
> the bundle, and I should be able to make that decision while either accepting or rejecting the m-line.
>
>> Q4:
>>

Well, there are basically two "warm-up" questions:

Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the receiver accepts bundle, is the receiver expected to be able to send media/data according to that?

Q4_2: IF Q4_1 THEN which m- line does the receiver use to send media/data (when the second offer comes, with identical port numbers, it is no longer an issue).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 14:46:23 -0400

> Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the receiver accepts bundle, is the receiver expected to be able to send media/data according to that?

I hope so.

> Q4_2: IF Q4_1 THEN which m- line does the receiver use to send media/data (when the second offer comes, with identical port numbers, it is no longer an issue).

Surely the bundle draft must specify this.

My first thought is that the address/port of the *first* m-line in the 
bundle with a non-zero port will be used for the entire bundle.

(This means that when you initially offer a bundle with a bunch of 
separate ports, you not only must be prepared to use each of those for 
an unbundled m-line, you must be prepared to use any of them for the 
complete bundle.)

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 May 2013 15:24:48 -0400

> an unbundled m-line, you must be prepared to use any of them for the 

An offerer sends an initial offer with a bundle of two m-lines: one with port 20000, one with 30000.

The answerer answers, rejecting the first m-line (with port zero) but accepting the bundle.

Should the answerer send traffic to port 20000 or port 30000?

--
Jonathan Lennox
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2013 19:31:19 +0000

Hi,

>> Q4_1: When the first offer, with DIFFERENT port numbers is sent, and the receiver accepts bundle, is the receiver expected to be able to send media/data according to that?

Ok, so let's stick to that assumption for now.

> My first thought is that the address/port of the *first* m-line in the bundle with a non-zero port will be used for the entire bundle.
>
> (This means that when you initially offer a bundle with a bunch of separate ports, you not only must be prepared to use each of those for an unbundled m-line, you must be prepared to use any of them for the complete bundle.)

Yes, that is what I have been thinking also: until the second offer has been sent and accepted, the offerer has to be able to receive media on any of the offered ports.

Because, the offerer cannot assume that media will come on the *first* non-zero m-line in the offer, because the answerer could  reject it. 

OR, the answerer could accept the m- line but exclude it from a bundle, in which case it will only send media associated to that m- line to the offered port - and the bundled media will be sent to some other port of the offered bundle group.

These are issues that I've had from the beginning with offering different ports in a bundle group, so I would really like the people (Cullen, Richard E etc) that pushed for this to explain me how they intended to solve it  :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 May 2013 19:33:39 +0000

Hi,

> The answerer answers, rejecting the first m-line (with port zero) but accepting the bundle.

Or, the answerer accepts the first m- line, but excludes it from the bundle. Maybe we need to re-think whether it should be allowed to exclude an m- line from a bundle in the answer...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 May 2013 15:34:08 -0400

> Should the answerer send traffic to port 20000 or port 30000?

Well, I hadn't considered that possibility, but it is one.

It seems a little weird, but it might have have some benefits for 
implementation.

I guess I don't have a strong opinion, other than the spec must clearly 
say which way it will be.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 23 May 2013 01:11:07 -0400

On 5/13/13 11:01 AM, Paul Kyzivat wrote:
>> So, assuming we are going to update RFC 5888 (whatever the exact 
>> wording would be), would we do that within draft-bundle, or within a 
>> separate document?
>
I'd like to hear from the RFC 5888 authors about the motivation for this 
restriction in RFC 5888 before we decide to get rid of it (certainly in 
general, but also more specifically for bundle). Following that, if 
there is still a desire to remove the restriction in general, and not 
just for bundle, then my preference would be do it in a separate document

Thanks

-- Flemming

>>>>>          identification-tags that correspond to "m" lines with the 
>>>>> port
>>>>>      set to
>>>>>          zero.
>>>>>
>>>>>
>>> We could say that whether it's valid must be defined by the group 
>>> semantic, and for all existing group semantics it's not.
>>
>> WFM
>>
> .

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 May 2013 08:27:03 +0300

Hi,

as far as I can tell, I do not think relaxing that rule would break
implementations. When we wrote RFC 3388 (RFC 5888's predecessor), there
were some concerns about the size of SDP offers and answers. That is why
it was considered good practice to keep implementations from adding
information that was believed not to be useful.

Cheers,

Gonzalo

---

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

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

>  Hi,****
>
> ** **
>
> In order to try to close issues on BUNDLE, based on the discussions we’ve
> had, I intend to update the BUNDLE draft based on the following assumptions:
> ****
>
> ** **
>
> **1.       **We mandate usage of rtcp-mux when BUNDLE is used.****
> Suhas: Agreed.
>
> **2.       **SDP m- lines with a zero port value MUST NOT be put inside a
> later start to wonder where the “MUST NOT” comes from.****
>
> **Suhas: Disagree. One should be able to set port to zero within or out
> of the BUNDLE group.
>

>  **
>
> Please indicate if you OBJECT to any of these assumptions.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 May 2013 13:01:37 -0700

> On Fri, May 3, 2013 at 5:53 AM, Christer Holmberg <[email-masked]> wrote:
>> Hi,
>> 
>>  
>> 

[BA] Agreed.
>> 2.       SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, due to this, the number of m- lines as…
[BA] Disagree.

---

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

Hi,

>2.       SDP m- lines with a zero port value MUST NOT be put inside a BUNDLE group (not in an offer, nor in an answer). There will be a note indicating that, 
>due to this, the number of m- lines associated with a BUNDLE group may differ between the offer and the associated answer. There will also be a note 
>indicating that this is due to RFC 5888, in case people later start to wonder where the “MUST NOT” comes from.
>
>[BA] Disagree. 

In case you give the information in another e-mail, you don't have to reply to this e-mail, but otherwise: do you disagree to forbidding port zero in bundle offers, bundle answers, or both? :)

Regards,

Christer