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

Martin Thomson <martin.thomson@gmail.com> Wed, 06 November 2013 22:06 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ECA21E809E for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 14:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcPSxjy-e-Rf for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 14:06:40 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id D244F21E80FC for <rtcweb@ietf.org>; Wed, 6 Nov 2013 14:06:20 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id n12so133201wgh.17 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 14:06:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gjmetUmA/kMHOY9VfMdPN0aGfqTcykBylzgn+PUWSw8=; b=UyiflyjH2YFJfgo2RlA3Bjuk5kj94HXJEKbTLySsLl9yOPNKJwimgKazeybx5b9RCy ItZ887U99p7CrXClV6Y/mk3KSh2FAQMKmlVF60b1PeVYTbJqX5EnuL8aW/V5CDekQ1yE C+CQIXDF4sBwzGDatJZe2+mME2BV3dQuNphjrgYgceEIsSFIUe/ZYw7LIaDMyU6eogXX nl/SMhj1yVo2OfDKCRgxplUXF6AsFNN7kGnhpt1I7JOsAA8LAAg0fE7r3EaUUpwTRBfu vNXnPEg5J7J3k3b9i7D7L1QKNpNrgu+1Q2NdkmJfdQZMs7Pj9fnnjbqD8LUa7siJfHRc FJGw==
MIME-Version: 1.0
X-Received: by 10.194.250.6 with SMTP id yy6mr4478875wjc.13.1383775579480; Wed, 06 Nov 2013 14:06:19 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Wed, 6 Nov 2013 14:06:19 -0800 (PST)
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net>
References: <527420FC.3070805@alum.mit.edu> <CAOJ7v-3tMLV0Zs5po_1daWuVaMPtrZK0g+L=kzPnLd0jGtfRXQ@mail.gmail.com> <CAPms+wQMN9+=wy5EJX0LUwZQRrJk2HebbJOADhhGeQpm2jzO8g@mail.gmail.com> <CAOJ7v-0UmZcuYbEzY5Z5WhFw7x_qP2pgntWEY_3byhNWTJqbnA@mail.gmail.com> <CAOJ7v-0c4F9i2Pkc0kjGkhcVDV227EiCH7PdLY--PKmcUMkG2Q@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net>
Date: Wed, 6 Nov 2013 14:06:19 -0800
Message-ID: <CABkgnnUtjB3Up50nKpALFoG9i47MCXME-98Cju0XTp5r_7z57Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 22:06:42 -0000

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
>