Re: [rtcweb] Use of offer / answer semantics

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 06 September 2011 15:19 UTC

Return-Path: <matthew.kaufman@skype.net>
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 5F66D21F8BB5 for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 08:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.02
X-Spam-Level:
X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[AWL=1.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nvKAP73Tu9Fn for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 08:19:20 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 37DFD21F8B4D for <rtcweb@ietf.org>; Tue, 6 Sep 2011 08:19:20 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C2F7716F5; Tue, 6 Sep 2011 17:21:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=Srpg9etEG+F5lh HQcGnrPonjWtU=; b=S1lcBCVO4q4WIgIzSX8N9QnWw6rjqKIlw0W6jaVtLz9B3r wDKDJfIo9k3XjLxvkNsKsyWenpEAkDGmu6R+pvbU2Ve60NUCBbidjKvd6SSdIi18 J4IgnpLoQB0pqjmrnbcaz5sxrp1rSsadZqGSENg336HX6iiHlfej5z4jNnBnA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=cgxnIAQiL2gWNVMQrEqhOF hZHRMcv6V83g3EdC15F1yO7/Xc050kfabi9KWScYsSQkyL4CS1iQQ1Wtr8a/qxI+ ZERp7lMTQDH2flFH/6XzfF9WAhKsMOcZLNM2Gy41IXWVEKW5H99luKaJVDkAbWRH oXzT9HADvOcM4mt435zAw=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C0BE27F6; Tue, 6 Sep 2011 17:21:05 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 9E6C53507021; Tue, 6 Sep 2011 17:21:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqruZJH91YpK; Tue, 6 Sep 2011 17:21:04 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 4E5233507E86; Tue, 6 Sep 2011 17:21:02 +0200 (CEST)
Message-ID: <4E663A35.7000507@skype.net>
Date: Tue, 06 Sep 2011 08:20:21 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com>
In-Reply-To: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Use of offer / answer semantics
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, 06 Sep 2011 15:19:21 -0000

On 9/6/2011 7:46 AM, Cullen Jennings wrote:
> In my roll as an individual contributor, I want to propose some text that I think we can get rough consensus on around that helps specify which parts of the signaling issues we agree on and which we don't.
>
> At the last meeting, my read of the the room was there was a fair amount of agreement in the room that offer / answer semantics  with SDP are what we want to use. I don't think there was was broad agreement on if one should use SIP or not, or for that matter jingle. If we can nail down this decisions as the direction the WG is going, it will really help make progress. What I would like to do is propose some following principles in the text below. If we have agreement on these, then they would go into the overview document and help guide the design of other documents. I want to highlight that none of the principles below imply that we would need to use SIP in the browsers - the principals would all work fine if we there was signaling gateway in the web server that converged SIP to whatever proprietary HTML / JS  / HTTP that the applications wanted to use between the browser and the web server.
>
>
>
> 1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP.

I think this would be unfortunate. We have an opportunity here to not 
repeat this mistake.

And *if* we go down this road, we need additional language around things 
like exposing the capabilities via an API that doesn't start the 
offer/answer process itself. (Use case: determine if a browser has an 
appropriate camera and encoder before suggesting that they call the 
customer service rep for a live chat.)


>
> 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed.

Agree.

>
> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers.

I would be ok with reusing the SDP parameter string as specified as a 
parameter to the API, but I don't think it should be a blob of SDP that 
combines both the codec parameters *and* the connection/ICE parameters, 
*and* I think that offer/answer is the wrong model.

However, see below...

>   Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications.

This is a good idea. But then where do all the parameters that *weren't* 
specified in the MMUSIC WG go? (Like "force Opus codec to music mode", 
or "change your motion estimation algorithm")

>
>
> People  has looked at alternatives to all these in a fair amount of detail. For example, we have considered alternatives to the SDP offer / answer such as the advertisement proposal draft (draft-peterson-sipcore-advprop-01) and discussed that several times in the WG.

This is mixing up the API and the wire protocol. If people want to use 
SDP offer/answer between the browser and the web server, that's fine, 
but that doesn't mean we need to bake SDP offer/answer into the 
Javascript API. (And it certainly doesn't mean we need to mix up the 
layers, with connection properties in the SDP *and* encoder properties 
in the same SDP... done properly, these would go to/from different 
Javascript objects anyway.)

Likewise, advprop should be able to be supported as well... with a 
different set of Javascript talking to the same APIs.

>   The primary issues identified with this was concerns over mapping this to legacy SDP.

This makes the assumption that the primary use case will have things 
that speak only SDP offer/answer on the far side. I think that's a very 
IETF + SIP + legacy point of view, which is an unfortunate way to 
approach the future of communications as enabled by web applications.

I think that as long as the browser *or* the server *can* map it to SDP 
offer/answer when needed, that is sufficient.

> Similarly people have considered a replacement for SDP in the SDPng work which was eventually abandoned due to the difficulty of having a incentive for implementations to migrate from SDP to SDPng.

Obviously can't use something that was abandoned.

>
> We have also considered just sending audio and video directly over something like DTLS and not suing RTP.

That would break point 2 above.

>   The WG has clearly rejected this due to a variety of reasons - the desire not to to have the operating expense of media gateway and reduction in quality of experience is obviously a high priority goal for the designs of the RTP multiplexing draft.

Agree.

>
> The JS API is being developed by W3C but when proposing APIs that should violate the third principal, such as the the API in section 4 of draft-jennings-rtcweb-api-00, it is clear that many people that are more from the browser and web application world do not want such an API.

Too many negatives for me to parse.

Matthew Kaufman