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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 07 November 2013 06:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 66B1A11E8189 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 22:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 TtQKqfAicw82 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 22:42:41 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9687211E810B for <rtcweb@ietf.org>; Wed, 6 Nov 2013 22:42:41 -0800 (PST)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id mWih1m0021vXlb855Wihtj; Thu, 07 Nov 2013 06:42:41 +0000
Received: from dhcp-9448.meeting.ietf.org ([31.133.148.72]) by omta17.westchester.pa.mail.comcast.net with comcast id mWgY1m00K1ZxU2f3dWgapZ; Thu, 07 Nov 2013 06:40:39 +0000
Message-ID: <527B35E0.7010401@alum.mit.edu>
Date: Wed, 06 Nov 2013 22:40:32 -0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.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> <527AFF89.3000408@alvestrand.no>
In-Reply-To: <527AFF89.3000408@alvestrand.no>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383806561; bh=0roGbWJbtaaFrb7clfj9pqFvmmffyk25iYP74MvwNnA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rmIsO0ChWBqQi60EBe7Wn+LVLnHik849Dxf68exxsxlEu01fXT+joQc6Hn0Edffec RkE8sj373/mKYHn8wXDzA7KIMGjwnVUvoSrKJ8ALhxne6HymBfTTlKi+s6k7KQbivh Ef9SYAVe8mBp59GTpPTBbxZK6dpmSABKcojm/aH7u3WLyLZORleamR2ePVD4KwPhOL aRUlSNxLkH1z7AWCngd6bdOHlCaEJaGJXE7e213sm7jHJCIyUtpMLTi+aI5tBUfNjM sXGjReddRz3FiSgyAFZgmrFXTcHhVkLGSLRbZ8RTn/cYvzmVOSlwm0i/SWM+8Vs1Lr aTrTRovZGnwcw==
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 06:42:46 -0000

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.

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