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

Harald Alvestrand <harald@alvestrand.no> Thu, 07 November 2013 02:48 UTC

Return-Path: <harald@alvestrand.no>
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 E9E9311E8227 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 18:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level:
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 CpsVLoSyqWg1 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 18:48:54 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 55F8E11E822B for <rtcweb@ietf.org>; Wed, 6 Nov 2013 18:48:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FFE139E05D for <rtcweb@ietf.org>; Thu, 7 Nov 2013 03:48:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3dJ-efEMFYR for <rtcweb@ietf.org>; Thu, 7 Nov 2013 03:48:51 +0100 (CET)
Received: from [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19] (unknown [IPv6:2001:67c:370:160:6056:eeee:f72d:1d19]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4A8AE39E029 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 03:48:47 +0100 (CET)
Message-ID: <527AFF89.3000408@alvestrand.no>
Date: Thu, 07 Nov 2013 03:48:41 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: rtcweb@ietf.org
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> <CABkgnnUtjB3Up50nKpALFoG9i47MCXME-98Cju0XTp5r_7z57Q@mail.gmail.com>
In-Reply-To: <CABkgnnUtjB3Up50nKpALFoG9i47MCXME-98Cju0XTp5r_7z57Q@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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: Thu, 07 Nov 2013 02:48:59 -0000

On 11/06/2013 11:06 PM, Martin Thomson wrote:
> 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"?

That's not what I heard.

What I heard was:

X offers A, B and C (codecs being the canonical example).
Y answers A (only). That means we have agreement to use A only.
X wants to send a new offer.

Three alternatives:

1) X MUST offer A, B and C
2) X MUST offer A (only) if no particular constraint is set, but MUST
offer A, B and C if some (to-be-defined) constraint is set.
3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour)

I like option 2, for the reasons stated (deterministic, seems to do the
job).


>
> 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
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.