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

Martin Thomson <martin.thomson@gmail.com> Thu, 07 November 2013 17:52 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 3157411E81B7 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 09:52:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, 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 JgMVkE4HO+12 for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 09:52:27 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1D21E81EA for <rtcweb@ietf.org>; Thu, 7 Nov 2013 09:52:08 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id f4so1019402wiw.4 for <rtcweb@ietf.org>; Thu, 07 Nov 2013 09:52:03 -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; bh=RTUuruzeMR5SMIEtixvzKmIwwzrMWtNeA/yUX9LX0QM=; b=TUGVJW1/bvPFlwGo1PMKoT9uvgQ9BJ8K6oJoQlFNtMWVvEbDIx51wFssHlm9po1Rw6 5VL/RWgJRiLhtas62Y3oD1eferbDGVqdUyiXBuOSgW9Co6uk1OqMwOmja+ycAv1Lamev HT5cBVtgmgnDDHO/l6PJuRTEwMshlIqtTEmKbFQggS07kuSjGG76GOnZlXFEW4SpOfkl p8IzbcVRyleCvujoRxE2FLiqL80SHrLar7JuX2jpPrMgGl62vQCFNR5NKIZQKbQGvgLw E0IvjS5S0L0Shw1x9PoFdDhKBalVelLwJA9N3k6ZrgfzoQZyzuUcT8Ubnt9UPRqEcI2Q YvkQ==
MIME-Version: 1.0
X-Received: by 10.194.58.104 with SMTP id p8mr8550718wjq.1.1383846723741; Thu, 07 Nov 2013 09:52:03 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Thu, 7 Nov 2013 09:52:03 -0800 (PST)
In-Reply-To: <CAOJ7v-2_cOy0TFHLzx=feYfDKksfAx=nmin7U1C=NVR1tVr=jg@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> <CAOJ7v-0c4F9i2Pkc0kjGkhcVDV227EiCH7PdLY--PKmcUMkG2Q@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17C337D0@MCHP04MSX.global-ad.net> <CABkgnnUtjB3Up50nKpALFoG9i47MCXME-98Cju0XTp5r_7z57Q@mail.gmail.com> <527AFF89.3000408@alvestrand.no> <527B35E0.7010401@alum.mit.edu> <CAOJ7v-2_cOy0TFHLzx=feYfDKksfAx=nmin7U1C=NVR1tVr=jg@mail.gmail.com>
Date: Thu, 7 Nov 2013 09:52:03 -0800
Message-ID: <CABkgnnVOj+A8ZF8VYBnb5v_wgCKnD17Lcoy3=XdnM88GHuidMQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset=UTF-8
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: Thu, 07 Nov 2013 17:52:28 -0000

On 6 November 2013 23:11, Justin Uberti <juberti@google.com> wrote:
>>
>> A more complex case is:
>>   X offers A, B, C
>>   Y answers A, B
>>
>> Then X begins using A, and not using B.
>> When doing next offer,
>> 1) X MUST offer A, B, C
>> 2) X MUST offer A, B
>> 3) X MUST offer A
>> 4..N) X MUST offer one of above by default, but may offer more according
>> to some constraint.
>>
>
> X may be using A in this case, but Y may be using B, so #3 would be bad IMO.
> (Remember, the reason for the new offer is because some other property of
> the session changed.)
>
> #2 would be the default behavior, and #1 would be the optional behavior that
> the application could choose.

Thanks to Paul for the example, and I definitely agree with the
requirement that the negotiated (not just in-use) parameters MUST
remain.  That's a given.

My suggestion is that we *don't* add a constraint, we just require the
inclusion of everything.  If you want to constrain codec use, then you
can use the mechanisms that we provide for doing that.  Currently,
that's editing SDP; though we've talked about specific constraints in
the form of { video: { disableCodec: 'VP8' } } or something like that.

I don't want to create a special new set of constraints that will
effectively never get used.

(We do need to be careful about overconstraining implementations by
using MUST here.  Implementations should be encouraged to offer
everything that they can do, but circumstances might change such that
even negotiated codecs can become unavailable.  Any MUST will need to
be modulated.)