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

Cullen Jennings <fluffy@cisco.com> Wed, 09 November 2011 14:37 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 16E3E21F8A57 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:37:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.453
X-Spam-Level:
X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 oCClgmfoYuqd for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 06:37:47 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBEF21F8AAA for <rtcweb@ietf.org>; Wed, 9 Nov 2011 06:37:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1813; q=dns/txt; s=iport; t=1320849467; x=1322059067; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VDShaCPF03/ahOkfe3LOBnQmJOBWhG+qGzLAMXIEf+0=; b=DVqtZWgVpgZK7xkld68XHYLQ6IczRUcxgB+ZLkEVdMS5C6iYp0ne7NiQ qSEtVBfcDtSgxnBr4H+JaboedHmMT11AeLhQDTDNT1CpbjQ8NuiQ+2Xkw ic8hf+jVzsAb75ZBZcs3q3k22XzViyZh5OKvuSWfHUTCp7JfzgOGhL0Uy I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJSPuk6rRDoI/2dsb2JhbABCqh6BBYFyAQEBAwESASc/EAs7C1cGNYdgmSgBnyGJHGMEiAyMGYU1jF0
X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="13200305"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Nov 2011 14:37:42 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA9Ebgel000354; Wed, 9 Nov 2011 14:37:42 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235A07262@ESESSCMS0356.eemea.ericsson.se>
Date: Wed, 09 Nov 2011 07:37:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7869E63-9814-4BF5-B251-45AD4C8930FE@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> <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235A07262@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1084)
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: Wed, 09 Nov 2011 14:37:48 -0000

On Nov 9, 2011, at 2:14 AM, Christer Holmberg wrote:

> 
> Hi Cullen, 
> 
>>>>> 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.
> 
> I think that could cause interoperability issues.
> 
> For example, assume that a gateway would map a more-to-come answer to a SIP 18x response.
> 
> Then, if the no-more-to-come answer is different, the gateway can't map it to SIP 200 response - at least not without chaning the SIP dialog identifier.

Seems like it should be able to do this. Lets talk about this in Taipei - I suspect we are just talking past each other and both mean about the same thing. I'm not proposing any change to 3264. 

> 
> Also, if you map a more-to-come answer to a SIP 18x answer, and then receives a new SIP offer, the gateway *cannot* map it to a ROAP offer, as it is still wating waiting for the no-more-to-come answer.
> 
> Regards,
> 
> Christer