IETF Logo Mail Archive

Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3)

Cullen Jennings <fluffy@cisco.com> Fri, 04 November 2011 15:43 UTC

Return-Path: <fluffy@cisco.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 2F09C21F8C19 for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 08:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.394
X-Spam-Level:
X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 v4mFwKJaxwPn for <rtcweb@ietfa.amsl.com>; Fri, 4 Nov 2011 08:43:53 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAFC21F8C16 for <rtcweb@ietf.org>; Fri, 4 Nov 2011 08:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1263; q=dns/txt; s=iport; t=1320421433; x=1321631033; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sX91iLZls5JpynCZawjOIaug7G2LH3PHbHSjhvYadmw=; b=YV1E1WpMFyEYWAhGw+T6pdY2Z4uym/IRUGk36+La/VG3aCqzQE0ouq2F X5MimDrVAdSGGohSKSuixl8Yd0fNoUaadgb98vF/Bq7v2E82K5cjtKvjX clhhiubp9X9dOTf/rqj+8OLnqQiToj+kPu4KGqgUTBjH4mRMNz/OtVQX6 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAC0HtE6rRDoG/2dsb2JhbABEqgOBBYFyAQEBAwESAWYQCzsLVwY1h2CWeAGeZIhIYwSICowSkgY
X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12346318"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 04 Nov 2011 15:43:53 +0000
Received: from [IPv6:::1] (ssh-sjc-2.cisco.com [171.68.46.188]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA4FhrUv003575; Fri, 4 Nov 2011 15:43:53 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="windows-1252"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 04 Nov 2011 08:43:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> <E08E5E86-56BE-417D-A5C0-03AAA4A375CB@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3)
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: Fri, 04 Nov 2011 15:43:54 -0000

On Nov 3, 2011, at 12:33 , Christer Holmberg wrote:

> 
> Hi, 
> 
>>> Q2. Are there restrictions when it comes to changing information in a non-final 
>>> answer and a final answer? Or, can the final answer be completely different from 
>>> previously sent non-final ANSWERS? In "legacy" O/A there are restrictions.
>> 
>> Any answer has to be a valid answer for the offer but other than that, no restrictions, 
>> so the final answer can change everything from an earlier one. 
> 
> Is there a reason/use-case/requirement why we need to allow that? As far as I know, the reason behind this is ICE.
> 
> 


There a bunch of use cases but to mention two: In the browser to browser case, imagine that you start sending audio in the first answer but need to wait for user feedback to find out if video can be added or not in the final answer. In a browser to SIP use case, the early media for 1-800-go-fedex.

Cullen

PS - Sorry for slow replies but we had the week before the -00 drafts, then the week before the -01 drafts, now I am at the W3C TPAC meeting for a week, then reading drafts weeks, then IETF so I suspect a bunch of this I won't really get to till after IETF but ….

v2.23.0 | Report a Bug | By Email