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

Cullen Jennings <fluffy@cisco.com> Thu, 20 October 2011 00: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 4148B11E80C2 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.78
X-Spam-Level:
X-Spam-Status: No, score=-105.78 tagged_above=-999 required=5 tests=[AWL=0.519, 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 rvhJjaEFjd3B for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:43:52 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1C11E80BF for <rtcweb@ietf.org>; Wed, 19 Oct 2011 17:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2319; q=dns/txt; s=iport; t=1319071432; x=1320281032; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4jd75WBc2FENUSIDZPBz4M+5lCF+mW6wbuelhRK+gWI=; b=H0SATDv5GbjEQvjRwYOY1jPr0fY2mondb8u5MRiCcbFXn21j9NYhSwTz 1VC3nrcdsqWUEhJQdBZexKSkpgWlSaSfwLy+MiO5UMxZ5bA4TCdIdSZkf 7wvLMdM+kOwmwgsIZMSKPgyalAddNK8Xs9JdhYrYa2iXC3oU1yyoXz4wR k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJxtn06rRDoH/2dsb2JhbABEqQKBBYFuAQEBAQIBEgFmBQsLOwtXBhMih16XewGeT4c6YQSIAot8hSqMTA
X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="9004606"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Oct 2011 00:43:52 +0000
Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0heKQ007374; Thu, 20 Oct 2011 00:43:52 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: <CALiegfn_DDxKwbq1gTeyDo+t=+oEyAy6eUS3sJ36Tbyo_Ffnww@mail.gmail.com>
Date: Wed, 19 Oct 2011 18:43:52 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <05C007AF-7462-4A08-894D-9D4DD0569105@cisco.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CALiegf=EXfNAfRDGiohz3aSqmZzsDDXbE=DRNX0gZTXz7x4+Yg@mail.gmail.com> <DA064BE5-9C95-4B87-B1D9-CD3FD1E0810D@cisco.com> <CALiegfn_DDxKwbq1gTeyDo+t=+oEyAy6eUS3sJ36Tbyo_Ffnww@mail.gmail.com>
To: Iñaki 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: Re: [rtcweb] Why SDP answer needs and ack … was Re: 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: Thu, 20 Oct 2011 00:43:53 -0000

I guess the question I am thinking about is how important is this use case. I'm a bit of the fence on the topic.  The primary use of INVITE with no offer is when doing a gateway to some forms of  H.323. It seem the odds of a gateway from RTCWeb to SIP to H323 is pretty low so I have not been thinking about how to deal with INVITE with no offer much.  I should think about it more but too few hours in the day :-) 



On Oct 18, 2011, at 13:44 , Iñaki Baz Castillo wrote:

> 2011/10/18 Cullen Jennings <fluffy@cisco.com>:
>> 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.
> 
> Hi Cullen. Let me put an example:
> 
> - alice: JS client implementing pure SIP over WebSocket.
> - A proxy implementing SIP over UDP and WebSocket.
> - bob: SIP UDP client.
> 
> The flows:
> 
> - alice sends INVITE to bob with an empty body (no SDP).
> - bob replies a 200 with the SDP offer.
> - alice receives the 200. Its JS code internally generates a ROAP Offer.
> - alice generates a ROAP Answer and inserts its SDP into an ACK to be
> sent to bob.
> - In SIP we have ended. So how is supposed alice will receive the ROAP
> OK message?
> 
> I don't understand yet if such ROAP OK message is mandatory to be sent
> to the RTCweb stack. If so, the JS code in alice could auto-generate
> it after sending the ACK, so the RTCweb stack becomes happy. But
> obviously the advantage of such auto-generated ROAP OK is null.
> 
> 
> Regards.
> 
> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>