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

Justin Uberti <juberti@google.com> Thu, 07 November 2013 07:11 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 437C611E81D3 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 23:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.97
X-Spam-Level:
X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 lJCcffak1uRi for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 23:11:22 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 373B211E810B for <rtcweb@ietf.org>; Wed, 6 Nov 2013 23:11:21 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id tp5so211633ieb.17 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 23:11:21 -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=1v82mrF2pvxYdbcmPshISJ7I8MxuFJ90QcnTwDMRHvs=; b=lzydKnEpDwT1wBBC7lSWbMZkwRqoh5+Xu3gNNZSb+6jwWHuhLkpIp+hWD92byTzixy 5Ms5Jom5jJNSUOgoYliChFUlQwsU4JBBO5Ea09g0PhzYnBrrS5A9SahjUh7PR/6s53G9 FC2RMQTFO9farKedVbKLt6GHwQzvmRZpJ91iKEetQkfZUbmRdjOA8bTwQho9LCcJmmev 6k+7GuQzzIj//2jKTG+nFm1a6uR2qcB02X60k3oAZKEH/z1Fh+otqdXFy7oP9EQ4UJnu sqFaMZqA97pRDohAeM8+F98CafljQ/nKUpt7HHx+Pb1oNNDunehHU5yRFGnl8PtOAkfR 6ZsQ==
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=1v82mrF2pvxYdbcmPshISJ7I8MxuFJ90QcnTwDMRHvs=; b=WNTx6v6/+2xRp6uPOkVs3qfhUDJwHzGzJsJdvT9+rZNovQ2n5FZNYqgf/zs40ycGO2 DW9NdyxhW0PiZ0YJ0G1ZYXlZwtjIGF6WoKbfeZp+KydrUcoBIeR9ir6C6TgmZ4g1YjUB 3zEKSU5RXHknzgg0JHzf50Aep6NkAYnLRw1x/0IuZ6t4QqvJ1NBBIzky3b/UAT//Zh7v jycS/gEAp1AH7A4sP3hrGmXyeInl3AWZ475pF86nbGN5CIDOIoAifeI2Dqzhkif+G7qN Dul4VM5aSvRWHq9ktVvcaiq272efBlJMQkneKv5hthqyJbAgBLygip06NkMdnGBxvGDu GCOA==
X-Gm-Message-State: ALoCoQmn/chspSqhFsOTSOwEUQot1qcQlptNCC0lwsql2VPLqJ986O0JdUy5xC6kete1W1a9MiSmoIzlE2StWlKv4v71pVLXsFqLjHB7P7Po9vemW9z/Ndh8AGN/GdxImsoRf2d+Rgc5y65ubwtAbz+pQxjXxQZdbFFV5bB8JcDYKHD0sFArfBtDHBMDRgWhqQHOum1VJqId
X-Received: by 10.42.40.83 with SMTP id k19mr4320737ice.3.1383808281450; Wed, 06 Nov 2013 23:11:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.246.106 with HTTP; Wed, 6 Nov 2013 23:11:01 -0800 (PST)
In-Reply-To: <527B35E0.7010401@alum.mit.edu>
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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 6 Nov 2013 23:11:01 -0800
Message-ID: <CAOJ7v-2_cOy0TFHLzx=feYfDKksfAx=nmin7U1C=NVR1tVr=jg@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=90e6ba1efbf40e4aa004ea90f964
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 07:11:23 -0000

On Wed, Nov 6, 2013 at 10:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 11/6/13 6:48 PM, Harald Alvestrand wrote:
>
>> 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.
>>
>
> This is a subset of the possible cases. But lets stick with it for the
> moment.
>
>
>  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).
>>
>
> SDP O/A recommends an offer that contains A, but allows offering B and C
> (or D) without A. Of course that could cause a great deal of pain, but
> maybe X has no choice due to some change of situation.
>
> If JSEP wants to restrict to (2) then I don't see that as a problem. (But
> be prepared for the possibility of *receiving* an offer that doesn't
> contain A.) But I think it also ought to be possible for the non-default
> offer to contain A plus anything else.
>
> 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.


> (Note that audio easily can result in negotiating two codecs, where one of
> them is telephone-events.)
>
>         Thanks,
>         Paul
>
>
>  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
>>>
>>
>>
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>