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

Justin Uberti <juberti@google.com> Wed, 06 November 2013 21:38 UTC

Return-Path: <juberti@google.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 C8C1F11E812B for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KKET4p1tZkGF for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:38:11 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8091F21E81A7 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 13:37:47 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id x16so74261vbf.37 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 13:37:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A3lwPQw5tb8IrFEUYtSN1SHXHjf4DQKN+gHlQhQsFhY=; b=kDZjAP/LkidwENONnsMDLv4ON6u85pUWOR38UlYuPxnUVxkFFQWCylH7Srqa8RyIuJ ZmIFXnE7bV+rwdLZT3KSRAmCnYFqIe5NwhKlknPIz5euk7fZhmuxJAAx059PBx94MuRu +MA+PnT04MnphhxIHmXn7XQB1ikGcS/vi1g7VpHpE3Q1dIk1qtFZPQ19W3xarwaE1P1+ H6c+jXMvIbIO8oVf/uhVty7EmfOD3nbMCuOMYbMVp36wSOlNR3EFKVXOsj/PjTgN+8gj cvv4kP3QhSkWyEGSpUpuiz7ozAhr2SP0Wj/nEvqjeIucAMJbcFTkaCgtaTQtXolLHap2 GowA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A3lwPQw5tb8IrFEUYtSN1SHXHjf4DQKN+gHlQhQsFhY=; b=gv/3+B7VngIeO6XeYnEVCJvc7bed9rY6eBwTS4nB4KKgrY2pJ6JOhyI9Iy4wLJjzsK 4r9MZT6GDThtsoTUh6aILOeOvN50sNNwYGy8YOpDtRnPt5M8XMImipU6QyuLlMtkGaNT nEybzqY/e7QskGF9o/ZA42zZW7de1mGkd231jd8l2HEE6ozeEYirhRLRLm1+yAd3O2hI vlIe0peniv90ckVzQbMKVeVNng/dgz/GjFVqbvyE47jD6hBimo+0CW2HMYmEWTJ4EOCO usAYDD4cv5TwPl5OWBT9LT/OIOVM9ftBAnG+1H7DnWhEMH7X+S7SoyTMpPe9gfVs9D23 N8xA==
X-Gm-Message-State: ALoCoQn39weK42qAT783GR9pSqzx2xAxKLPEhBqdasqfsGEGS4gK2AtroZ0Dg7Rm4qphduDkB2lJFP/GxdSpUCw4iajaiOxrsH1QIDQpQvTovhMBbAe/jtrEE6Q4R1CO9wU35jEh3Kt3AsmVlTdSoKIoVdbEdTzfd6XWYc2d6oK56VVUmtcNqD6dl9qCYjB3KF6hyh83ZDUu
X-Received: by 10.220.174.200 with SMTP id u8mr4130319vcz.6.1383773865089; Wed, 06 Nov 2013 13:37:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.110.101 with HTTP; Wed, 6 Nov 2013 13:37:24 -0800 (PST)
In-Reply-To: <CAOJ7v-0UmZcuYbEzY5Z5WhFw7x_qP2pgntWEY_3byhNWTJqbnA@mail.gmail.com>
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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 6 Nov 2013 13:37:24 -0800
Message-ID: <CAOJ7v-0c4F9i2Pkc0kjGkhcVDV227EiCH7PdLY--PKmcUMkG2Q@mail.gmail.com>
To: Michael Procter <michael@voip.co.uk>
Content-Type: multipart/alternative; boundary=089e0149ca3aadaf8704ea88f55c
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 21:38:14 -0000

>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;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
>>
>
>