[rtcweb] Why SDP answer needs and ack … was Re: SDP Offer/Answer draft-jennings-rtcweb-signaling

Cullen Jennings <fluffy@cisco.com> Tue, 18 October 2011 18:41 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 9B43F21F8BDC for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level:
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 9pQm5sUyIyWQ for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:41:17 -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 1829D21F8BDB for <rtcweb@ietf.org>; Tue, 18 Oct 2011 11:41:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2547; q=dns/txt; s=iport; t=1318963277; x=1320172877; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n+v2pMwdCOGgBjKwfNV8cgs0ED1fg12C89r1x3ZcULQ=; b=hbyXlpUzc6FXw0fHPOSRyir04WfMBdNW796ydiHq3qQHtEXDBTyzc8EE A18g9vQFaPX9Vz4p25qlGXfcVCIwwvSGFeqtIhhEvkfxPjlES70xsmjeB cVIqz+XbKa5dgskYrVuASMRBEVzBkgGfLFQ1Ob2EEKQS/AF4dMn/BUKgN o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHHHnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAgEBEgFhBQULOBlXBhMih14Il3kBnmCEf4I7YQSIAot7kXY
X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8641431"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 18:41:16 +0000
Received: from dhcp-171-70-217-213.cisco.com (dhcp-171-70-217-213.cisco.com [171.70.217.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9IIemxb027916; Tue, 18 Oct 2011 18:41:16 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CALiegf=EXfNAfRDGiohz3aSqmZzsDDXbE=DRNX0gZTXz7x4+Yg@mail.gmail.com>
Date: Tue, 18 Oct 2011 11:41:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA064BE5-9C95-4B87-B1D9-CD3FD1E0810D@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CALiegf=EXfNAfRDGiohz3aSqmZzsDDXbE=DRNX0gZTXz7x4+Yg@mail.gmail.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
Subject: [rtcweb] =?windows-1252?q?Why_SDP_answer_needs_and_ack_=85_was_Re?= =?windows-1252?q?=3A__SDP_Offer/Answer_draft-jennings-rtcweb-signaling?=
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: Tue, 18 Oct 2011 18:41:17 -0000

Hi - glad to hear you see this going the right direction. On the topic of why we have an OK, let me provide a bit of the motivation. 

When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send things or user interface that provides feedback about the status of the other side. We are also dealing with a web transaction model where transaction are not guarantee to happen even if they are sent over TCP. So you need to get back a response to request. It also helps with mapping to SIP but even if you were not mapping to another protocol, I suspect you would still need to be able to have an confirmation than and answer was received. 



On Oct 15, 2011, at 2:20 , Iñaki Baz Castillo wrote:

> 2011/10/15 Cullen Jennings <fluffy@cisco.com>;:
>> Jonathan and I submitted a new draft on setting up media based on the SDP Offer/Answer model. The ASCII flows are a bit hard to read so until I update them, I recommend reading the PDF version at
>> 
>> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf
>> 
>> Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.
> 
> 
> Hi, thanks for this work. IMHO this is clearly the way to go, and the
> proposal that could make everyone happy. Let me just a comment:
> 
> 
> -----------------------------
> 5.3.3.  OK
> The OK message is used by the receiver of an ANSWER message to
> indicate that it has received the ANSWER message. It has no contents
> itself and is merely used to stop the retransmissions of the ANSWER
> -----------------------------
> 
> I wonder how much needed is the OK message taking into account that
> the transport will always be reliable. So, instead of retransmiting
> the ANSWER until an OK arrives, why not retransmit the OFFER until an
> ANSWER arrives and drop the OK message from the spec?
> 
> Probably I miss something here as in the case the offered wants to
> signal ringing (a 180 in SIP) it conveys no media so there would be no
> ANSWER message for long time until the offered human user decides to
> accept or reject the incoming call. If so, please forget this comment
> :)
> 
> 
> 
> 
> 
> 
> 2)
> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>;