IETF Logo Mail Archive

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

"Hutton, Andrew" <andrew.hutton@unify.com> Wed, 06 November 2013 22:02 UTC

Return-Path: <andrew.hutton@unify.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 500D121F9ED1 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 14:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=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 Xh595orMxbZE for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 14:02:00 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3921F9F19 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 14:01:59 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 26BFA1EB86C9; Wed, 6 Nov 2013 23:01:52 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 23:01:51 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Justin Uberti <juberti@google.com>, Michael Procter <michael@voip.co.uk>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
Thread-Index: AQHO2zhhRkimDg8HS1yf9W6X1FrNbJoYwKAg
Date: Wed, 06 Nov 2013 22:01:51 +0000
Message-ID: <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>
In-Reply-To: <CAOJ7v-0c4F9i2Pkc0kjGkhcVDV227EiCH7PdLY--PKmcUMkG2Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17C337D0MCHP04MSXglobal_"
MIME-Version: 1.0
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:02:05 -0000

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<mailto: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<mailto:michael@voip.co.uk>> wrote:
On 3 November 2013 22:55, Justin Uberti <juberti@google.com<mailto: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

v2.23.0 | Report a Bug | By Email