Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 18:28:29 +0000

Hi,

I scanned through 3264, in order to find the sections that need to be updated.

Below are the sections/sentences that I found, together with suggestions on how to modify the text.

Section 5.1 (Unicast Streams):
-------------------------------------

OLD TEXT:

	"A port number of zero in the offer indicates that the
   	stream is offered but MUST NOT be used.  This has no useful semantics
   	in an initial offer, but is allowed for reasons of completeness,
   	since the answer can contain a zero port indicating a rejected stream
   	(Section 6)."

SUGGESTED NEW TEXT:

	"By default, a port number of zero in the offer indicates that the
   	stream is offered but MUST NOT be used.  This has no useful semantics
   	in an initial offer, but is allowed for reasons of completeness,
   	since the answer can contain a zero port indicating a rejected stream
   	(Section 6). Extensions can define a different semantics for the usage
	of a port number of zero in the offer."

Section 8.2 (Removing a Media Stream):
-------------------------------------------------
 
OLD TEXT:

	"A stream that is offered with a port of zero MUST be marked with port
   	zero in the answer."

SUGGESTED NEW TEXT:

	"A stream that is offered with a port of zero, in order to be removed, MUST be marked with port
   	zero in the answer."

Section 8.4 (Putting a Unicast Media Stream on Hold):
-----------------------------------------------------------------

OLD TEXT:

	"Of course, when used, the port
   	number MUST NOT be zero, which would specify that the stream has been
   	disabled."

SUGGESTED NEW TEXT:

	"Of course, when used, the port
   	number MUST NOT be zero, which could specify that the stream has been
   	disabled."

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]] 
Lähetetty: 14. marraskuuta 2013 19:35
Vastaanottaja: Christer Holmberg; [email-masked]
Aihe: Re: VS: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute

On 11/14/13 9:26 AM, Christer Holmberg wrote:
> Hi,
>
>>> Based on the decision in Vancouver to define the usage of port zero in 'bundle-only' m- lines, I've updated the new text I proposed some time ago.
>>>
>>> One question that was raised in Vancouver is whether we will have to update RFC 3264, so I've added a new OPEN ISSUE (13) for that.
>>> ...
>>>      OPEN ISSUE (13): RFC 3264 mandates a zero port value in an SDP Answer
>>>      to a zero port value in an SDP Offer.  As we now allow a non-zero
>>>      value in the SDP Answer, do we need to update 3264 procedures?
>>
>> Why is this a question. Section 8.2 of 3264 clearly states this, and we propose to do otherwise. So that means a revision is required.
>
> It is a question because we decided in Vancouver that we need to figure out what/how to do.
>
> However, I guess the question is not IF, but HOW, we will update 3264. Will BUNDLE update the affected 3264 sections? Will we produce a 3264bis? Etc etc etc.

Right.

I doubt we want to do a 3264bis at this time.
The most straightforward thing is to simply put an explicit statement in this draft that it is updating 3264 in this way as a narrow exception, and mark the draft as "updates 3264".

And then you can ask the chairs of sipcore to review this. :-)

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Nov 2013 10:35:21 -0800

> I scanned through 3264, in order to find the sections that need to be updated.

A direct replacement doesn't seem necessary.  We aren't issuing a new
3264.  A more direct explanation of what 3264 permits or prohibits and
why this is being changed is probably more important.

Maybe it's as simple as saying something like:

RFC 3264 states that m-lines with zero ports are negotiated off.  This
document updates RFC 3264 to permit the use of a zero port on m-lines
in combination with the a=bundle-only attribute.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 19:05:11 +0000

Hi Martin,

> A direct replacement doesn't seem necessary.  We aren't issuing a new 3264.  A more direct explanation of what 3264 permits or prohibits and why this is being changed is probably more important.
>
> RFC 3264 states that m-lines with zero ports are negotiated off.  This document updates RFC 3264 to permit the use of a zero port on m-lines in combination with the a=bundle-only attribute.

That is not how we have updated RFCs in the past. At least in my experience we have explicitly updated specification text.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Nov 2013 12:03:47 -0800

> That is not how we have updated RFCs in the past. At least in my experience we have explicitly updated specification text.

I must have been doing it wrong then.  I didn't notice anyone caring.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 20:14:50 +0000

I was thinking of doing something similar to section 5 in draft-ietf-ecrit-country-emg-urn-01, where the old and new text is shown.

http://tools.ietf.org/id/draft-ietf-ecrit-country-emg-urn-01.txt

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 22:56:21 +0000

Hi,

Below is an example of how the 3264 update could be implemented in BUNDLE.

Note that I only include the paragraphs that are modified.

Regards,

Christer

-----------------------------------------

8.  Update to RFC 3264

8.1.  General

   This section replaces the text of the following sections of RFC 3264:

   o  Section 5.1 (Unicast Streams).

   o  Section 8.2 (Removing a Media Stream).

   o  Section 8.4 (Putting a Unicast Media Stream on Hold).

8.2.  Original text of section 5.1 (2nd paragraph) of RFC 3264

   For recvonly and sendrecv streams, the port number and address in the
   offer indicate where the offerer would like to receive the media
   stream.  For sendonly RTP streams, the address and port number
   indirectly indicate where the offerer wants to receive RTCP reports.
   Unless there is an explicit indication otherwise, reports are sent to
   the port number one higher than the number indicated.  The IP address
   and port present in the offer indicate nothing about the source IP
   address and source port of RTP and RTCP packets that will be sent by
   the offerer.  A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness,
   since the answer can contain a zero port indicating a rejected stream
   (Section 6).  Furthermore, existing streams can be terminated by
   setting the port to zero (Section 8).  In general, a port number of
   zero indicates that the media stream is not wanted.

8.3.  New text replacing section 5.1 of RFC 3264

   For recvonly and sendrecv streams, the port number and address in the
   offer indicate where the offerer would like to receive the media
   stream.  For sendonly RTP streams, the address and port number
   indirectly indicate where the offerer wants to receive RTCP reports.
   Unless there is an explicit indication otherwise, reports are sent to
   the port number one higher than the number indicated.  The IP address
   and port present in the offer indicate nothing about the source IP
   address and source port of RTP and RTCP packets that will be sent by
   the offerer.  A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.  This has no useful semantics
   in an initial offer, but is allowed for reasons of completeness,
   since the answer can contain a zero port indicating a rejected stream
   (Section 6).  Furthermore, existing streams can be terminated by
   setting the port to zero (Section 8).  In general, a port number of
   zero indicates that the media stream is not wanted.

8.4.  Original text of section 8.2 (2nd paragraph) of RFC 3264

   A stream that is offered with a port of zero MUST be marked with port
   zero in the answer.  Like the offer, the answer MAY omit all
   attributes present previously, and MAY list just a single media
   format from amongst those in the offer.

8.5.  New text replacing section 8.2 (2nd paragraph) of RFC 3264

   A stream that is offered with a port of zero, in order to be removed,
   MUST be marked with port zero in the answer.  Like the offer, the
   answer MAY omit all attributes present previously, and MAY list just
   a single media format from amongst those in the offer.

8.6.  Original text of section 8.4 (6th paragraph) of RFC 3264

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.

8.7.  New text replacing section 8.4 (6th paragraph) of RFC 3264

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which could specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.

-----------------------------------------

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 14. marraskuuta 2013 22:15
Vastaanottaja: Martin Thomson
Kopio: [email-masked]; Paul Kyzivat
Aihe: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Martin Thomson [mailto:[email-masked]] 
Lähetetty: 14. marraskuuta 2013 22:04
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; [email-masked]
Aihe: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

I must have been doing it wrong then.  I didn't notice anyone caring.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 18 Nov 2013 11:23:36 +0000

Inline 

> in combination with the a=bundle-only attribute.
[TS]  I agree with Martin.
An answerer compliant with 3264 and not supporting bundle would ignore a=bundle-only and would set the port=0 in its answer.
I don't see an issue with an offerer compliant with 3264 and not supporting bundle, since it wouldn't have included a=bundle-only (and wouldn't include a larger number of m-lines with port=0). The answerer supporting bundle would have to set port=0 in the answer to such an offer in order to comply with 3264. 
In my opinion there isn't any change to the procedures in 3264 for an older implementation, so this isn't an update to 3264. 
However, explicit text in bundle that describes this behavior would be justified.

Regards
Thomas

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Mon, 18 Nov 2013 16:23:34 +0000

Hi Thomas,

<snip> An answerer compliant with 3264 and not supporting bundle would ignore a=bundle-only and would set the port=0 in its answer. </snip>

The above statement clearly shows how RFC 3264 implementation will break with "bundle-only" attribute proposal. RFC 3264 would have properly negotiated in case the port is allocated in the initial offer instead of port 0.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Stach, Thomas
Sent: Monday, November 18, 2013 4:54 PM
To: Martin Thomson; Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Inline 

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 18 Nov 2013 16:45:29 +0000

> 
> Hi Thomas,
> 
> <snip> An answerer compliant with 3264 and not supporting bundle would
> ignore a=bundle-only and would set the port=0 in its answer. </snip>
> 
> The above statement clearly shows how RFC 3264 implementation will
> break with "bundle-only" attribute proposal. 
[TS] I'm not sure what 'break' should mean here. If it means "reject the m-line by setting port= in the answer", that is the intended behavior. 
My statement was based on http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1 
Here, the a=bundle-only attribute is combined with port=0 in the offer. 
The port=0 in the offer should guarantee that an answerer does not use the m-line.
> RFC 3264 would have
> properly negotiated in case the port is allocated in the initial offer
> instead of port 0.
[TS] That is not what a=bundle-only wants to achieve.
The semantics of using a valid port in the offer together with a=bundle-only are not clear to me. 
I would regard that as an invalid combination. 

Regards
Thomas
> > > I scanned through 3264, in order to find the sections that need to
> be
> > updated.
> >
> >
> An answerer compliant with 3264 and not supporting bundle would ignore
> a=bundle-only and would set the port=0 in its answer.
> I don't see an issue with an offerer compliant with 3264 and not
> supporting bundle, since it wouldn't have included a=bundle-only (and
> wouldn't include a larger number of m-lines with port=0). The answerer
> supporting bundle would have to set port=0 in the answer to such an
> offer in order to comply with 3264.
> In my opinion there isn't any change to the procedures in 3264 for an
> older implementation, so this isn't an update to 3264.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Nov 2013 17:19:49 +0000

Hi,

The issue is not whether a 3264 implementation will break or not.

The issue is more administrative, and how we are allowed to write standards in IETF.

Currently, 3264 says:

1) Port zero in an Offer means that the stream must not be used; and

2) An Offer with port zero must be answered with port zero

As far as I know, we can not simply override that by defining an SDP attribute ('bundle-only'). Unless we can move inside the boundaries set by 3264, we need to update 3264.

Please correct me if I'm wrong, though. I guess some chair/AD input would be useful here.

IN ANY CASE, I really hope we are not going to spend too much time on this issue - we have more important things to do.

Regards,

Christer

________________________________
From: Stach, Thomas [[email-masked]]
Sent: Monday, 18 November 2013 6:45 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards
Thomas

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Mon, 18 Nov 2013 17:22:58 +0000

Hi Thomas,

AFAIK, it was agreed that the offer will not have bundle port until otherwise, it is known that the remote peer supports BUNDLE. In that scenario, I prefer to send some actual port with "bundle-only" during the initial offer. This ensures that the backward compatibility with the existing system as well as provides the bundle negotiation if required.

Also, Could you please confirm as per your understanding of offer m line with port 0 & a=bundle-only whether any ICE candidates exists within "m" line or not.

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:[email-masked]] 
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Nov 2013 17:34:22 +0000

Hi Partha,

Please note that the WG agreed in Vancouver to send bundle-only with port zero.

The question now is whether/how/if we need to update 3264 based on that agreement.

Regards,

Christer

________________________________
From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [[email-masked]]
Sent: Monday, 18 November 2013 7:22 PM
To: ext Stach, Thomas; Martin Thomson; Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Hi Thomas,

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:[email-masked]]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards
Thomas

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Mon, 18 Nov 2013 17:34:29 +0000

Hi Christer,

I agree. We discussed the same earlier in length.

In fact, I vaguely remember that there is a proposal from Adam to introduce new RTP profile name to achieve this functionality without impacting RFC 3264.

Thanks
Partha

From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Monday, November 18, 2013 10:50 PM
To: Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Hi,

Currently, 3264 says:

Regards,

Christer

Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat

Regards
Thomas
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
> Behalf Of ext Stach, Thomas
> Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat
> > <[email-masked]<mailto:[email-masked]>> wrote:
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Mon, 18 Nov 2013 17:39:11 +0000

Hi Christer,

Thanks for the update. The new RTP profile (like BSAVPF) proposal looks much cleaner solution.

Thanks
Partha

From: ext Christer Holmberg [mailto:[email-masked]]
Sent: Monday, November 18, 2013 11:04 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); ext Stach, Thomas; Martin Thomson
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Hi Partha,

Regards,

Christer

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:[email-masked]]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Nov 2013 17:45:43 +0000

And how would that work with non-RTP media?

Regards,

Christer

________________________________
From: Ravindran, Parthasarathi (NSN - IN/Bangalore) [[email-masked]]
Sent: Monday, 18 November 2013 7:39 PM
To: Christer Holmberg; ext Stach, Thomas; Martin Thomson
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Hi Christer,

Thanks
Partha

Hi Partha,

Regards,

Christer

Thanks
Partha

-----Original Message-----
From: ext Stach, Thomas [mailto:[email-masked]]
Sent: Monday, November 18, 2013 10:15 PM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; Paul Kyzivat
Subject: RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

Regards
Thomas

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Nov 2013 10:07:46 -0800

On 11/18/13 9:19 AM, Christer Holmberg wrote:
> As far as I know, we can not simply override that by defining an SDP
> attribute ('bundle-only'). Unless we can move inside the boundaries set
> by 3264, we need to update 3264.
>

I queried Adam for his opinion so we could have unanimity among chairs, 
but I haven't heard back from him.

I agree with Martin, that we need to formally declare that we are 
updating 3264, but that we don't have to provide an explicit delta to 
3264 to do so.

> IN ANY CASE, I really hope we are not going to spend too much time on
> this issue - we have more important things to do.

Agree.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
> *From:* Stach, Thomas [[email-masked]]
> *Sent:* Monday, 18 November 2013 6:45 PM
> *To:* Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson;
> Christer Holmberg
> *Cc:* [email-masked]; Paul Kyzivat
> *Subject:* RE: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute
> - Suggested 3264 update
>
>>
>> Hi Thomas,
>>
> [TS] I'm not sure what 'break' should mean here. If it means "reject the
> m-line by setting port= in the answer", that is the intended behavior.
> My statement was based on
> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.1

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Nov 2013 10:43:25 +0000

Hi,

So, let's do things in steps:

First, does anyone object that we need to, SOMEHOW (we'll discuss the actual text etc later), update RFC 3264?

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 18. marraskuuta 2013 20:08
To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Adam Roach
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

On 11/18/13 9:19 AM, Christer Holmberg wrote:
> attribute ('bundle-only'). Unless we can move inside the boundaries 
> set by 3264, we need to update 3264.
>

I queried Adam for his opinion so we could have unanimity among chairs, but I haven't heard back from him.

I agree with Martin, that we need to formally declare that we are updating 3264, but that we don't have to provide an explicit delta to
3264 to do so.

Agree.

	Thanks,
	Paul

>> <snip> An answerer compliant with 3264 and not supporting bundle 
>> would ignore a=bundle-only and would set the port=0 in its answer. 
>> </snip>
>>
> [TS] I'm not sure what 'break' should mean here. If it means "reject 
> the m-line by setting port= in the answer", that is the intended behavior.
> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-
> 3.1 Here, the a=bundle-only attribute is combined with port=0 in the 
> offer.
>> properly negotiated in case the port is allocated in the initial 
>> offer instead of port 0.
>> > A direct replacement doesn't seem necessary.  We aren't issuing a 
>> > new 3264.  A more direct explanation of what 3264 permits or 
>> > prohibits
>> and
>> > document updates RFC 3264 to permit the use of a zero port on 
>> > m-lines in combination with the a=bundle-only attribute.
>> An answerer compliant with 3264 and not supporting bundle would 
>> ignore a=bundle-only and would set the port=0 in its answer.
>> wouldn't include a larger number of m-lines with port=0). The 
>> answerer supporting bundle would have to set port=0 in the answer to 
>> such an offer in order to comply with 3264.

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 19 Nov 2013 11:56:00 +0000

Christer,

may I ask what you mean by "NEED to update 3264"? 

- If you mean to revise 3264 and create a 3264bis, I would object.  

- If you mean to include "Updates: RFC3264" in the header of the BUNDLE RFC-to-be, I'm inclined to say "Not necessary", but I don't care enough and would not object. 
Disclaimer: I quickly scanned RFC2026 and its successors for criteria when "Updates: RFCxxxx" is used, but couldn't find any.

- If you mean that we need to precisely describe how a bundle-implementation acts on receipt of an offer with port=0 and an a=bundle-only attribute, I would say "Yes, absolutely" and I also would want to clarify that this goes beyond what is specified in 3264.

I hope this helps, but I can also give a justification in a next step.

Regards
Thomas

> To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN -
> IN/Bangalore); Martin Thomson; Adam Roach
> Cc: [email-masked]
> > ---------------------------------------------------------------------
> -
> > --
> > The port=0 in the offer should guarantee that an answerer does not
> use
> > the m-line.
> >> RFC 3264 would have
> >> Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only'
> attribute
> >> - Suggested 3264 update
> >>
> >> Inline
> >>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Nov 2013 12:04:09 +0000

Hi,

> - If you mean to revise 3264 and create a 3264bis, I would object.  

That is not what I meant.

> - If you mean to include "Updates: RFC3264" in the header of the BUNDLE RFC-to-be, I'm inclined to say "Not necessary", but I don't care enough and would not object. 

That is what I meant.

> - If you mean that we need to precisely describe how a bundle-implementation acts on receipt of an offer with port=0 and an a=bundle-only 
> attribute, I would say "Yes, absolutely" and I also would want to clarify that this goes beyond what is specified in 3264.

That is not what I meant. 

In the BUNDLE spec we naturally need to describe how bundle-only is used, but this question is only related to the possible update of 3264 :)

Regards,

Christer

> I queried Adam for his opinion so we could have unanimity among 
> chairs, but I haven't heard back from him.
> 
> > IN ANY CASE, I really hope we are not going to spend too much time 
> > on this issue - we have more important things to do.
> 
> Agree.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> >
> > Christer
> >
> >> answerer supporting bundle would have to set port=0 in the answer 
> >> to such an offer in order to comply with 3264.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Nov 2013 07:47:43 -0800

> First, does anyone object that we need to, SOMEHOW (we'll discuss the actual text etc later), update RFC 3264?

I *don't* object - I *do* think we need to indicate formally that 3264 
is being updated.

My logic is that is we don't do that, then it will be impossible to 
claim simultaneous conformance to bundle-only and 3264 - using 
bundle-only will of necessity require violating 3264.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2013 10:47:41 +0000

So, maybe something like:

"This specification updates the procedures in RFC 3264. It defines the usage of a zero port
value in an SDP Offer even if the stream is not removed. In addition, it allows the Answerer
to assign a non-zero port value to a stream in an SDP Answer also in cases where the
stream contained a zero port value in the associated SDP Offer. The updates above only
apply to streams for which an SDP 'bundle-only' attribute has been assigned in the SDP
Offer."

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 19. marraskuuta 2013 17:48
To: Christer Holmberg; Stach, Thomas; Ravindran, Parthasarathi (NSN - IN/Bangalore); Martin Thomson; Adam Roach
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DECISION Q8: SDP 'bundle-only' attribute - Suggested 3264 update

> First, does anyone object that we need to, SOMEHOW (we'll discuss the actual text etc later), update RFC 3264?

I *don't* object - I *do* think we need to indicate formally that 3264 is being updated.

My logic is that is we don't do that, then it will be impossible to claim simultaneous conformance to bundle-only and 3264 - using bundle-only will of necessity require violating 3264.

	Thanks,
	Paul

>> use the m-line.
>>> supporting bundle, since it wouldn't have included a=bundle-only 
>>> (and wouldn't include a larger number of m-lines with port=0). The 
>>> In my opinion there isn't any change to the procedures in 3264 for 
>>> an older implementation, so this isn't an update to 3264.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Nov 2013 09:27:51 -0800

> apply to streams for which an SDP 'bundle-only' attribute has been assigned in the SDP

Looks good to me.

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 20 Nov 2013 17:30:07 +0000

Works for me

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Mittwoch, 20. November 2013 18:28
> To: Christer Holmberg
> Cc: Paul Kyzivat; Stach, Thomas; Ravindran, Parthasarathi (NSN -
> IN/Bangalore); Adam Roach; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Nov 2013 16:19:21 -0800

WFM