Re: [rtcweb] draft-ietf-rtcweb-jsep-05

The question in the room was:

Given a negotiated session with "A, B, and C", is an endpoint
permitted to create an offer that includes "D"?

A great many people said yes, because that is how SDP is most commonly used.

I agree that not offering A, B or C would be bad.

On 6 November 2013 14:01, Hutton, Andrew <andrew.hutton@unify.com> wrote:
> I vote for option 2 – Application controls renegotiation through constraint.
>
>
>
> Option 1 would be bad.
>
>
>
> Option 3 would be very bad.
>
>
>
> Andy
>
>
>
>
>
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Justin Uberti
> Sent: 06 November 2013 13:37
> To: Michael Procter
>
>
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
>
>
>
> From the room discussion, I sensed 3 possible options to move forward.
>
> 1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to
> renegotiate)
>
> 2) MUST NOT renegotiate codecs etc. by default, but MUST support option to
> renegotiate (application controls renegotiation through constraint)
>
> 3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if
> desired (no application logic needed, but non-deterministic API behavior)
>
>
>
> "etc" here would not include anything that would result in the offer
> changing from the previously agreed-upon local description, including
> codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings,
> or use of FEC/RTX.
>
>
>
> I proposed #1 in the room, but see #2 as a reasonable solution. That
> provides the application with full control over what it wants, as well as
> deterministic behavior.
>
>
>
> On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti <juberti@google.com> wrote:
>
> Yes, it would. But I think the problem still exists for applications that
> don't use partial offer/answers.
>
>
>
> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter <michael@voip.co.uk> wrote:
>
> On 3 November 2013 22:55, Justin Uberti <juberti@google.com> wrote:
>> According to section 5.2.5, it seems that this is only the cases for
>> offers
>> triggered by offerless reINVITEs. I don't think we want to be
>> re-allocating
>> and negotiating codecs every time we want to make a change to the session
>> descriptions in use.
>
> Would the partial offer/answer work address at least part of this?
> m-lines that you don't want to change wouldn't need to be advertised
> at all, rather than being advertised with a restricted codec set.
>
> Michael
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>