Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

Matthew Kaufman <matthew.kaufman@skype.net> Wed, 07 September 2011 22:29 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 ED7AB21F8E23 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 15:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.592
X-Spam-Level:
X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=1.007, 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 3wXHqrKIRio1 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 15:29:12 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EF22221F8744 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 15:29:11 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 080A1CF; Thu, 8 Sep 2011 00:31:02 +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=ansQYTKyAproi1 MLIvF1ynr9S7o=; b=ifFhH1X8yi2A6nHGaeDf0BfjZrKbgNoSN6XNxhYGX6WQ1P J2xYp9cCqG36WwxucuKhcwqemGbKMya3ELdendy0OJYPcOzZNXkSYogkRwkEtyvx lHOFMyQmgSxoKk4NQpmhTNPliGN4oK1XEf3fNmrP9vC20iBhMGP5eo3EURVUY=
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=UnY8vHryRDR7neHq9oIvwD IyoNre4zL8x7Xn7y9f9+/V5/Ud/bDj9zGHlMS0giRz7VzUnTehxwDAcU2obJ02/m KB8Innk6TB2O96E8fs9mjZfMRMvNqcDEWzQijBiBZ43IwuD29j2n2FVEUfKr1fte jJWGwVeBLHlfL0zDd92Ns=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id F1EDC7FD; Thu, 8 Sep 2011 00:31:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CEB6635081E5; Thu, 8 Sep 2011 00:31:01 +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 ObRcgly53MUW; Thu, 8 Sep 2011 00:31:01 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 575D83507EF9; Thu, 8 Sep 2011 00:31:00 +0200 (CEST)
Message-ID: <4E67F0A2.1070308@skype.net>
Date: Wed, 07 Sep 2011 15:30:58 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Randell Jesup <randell-ietf@jesup.org>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3EE.50707@jesup.org>
In-Reply-To: <4E67C3EE.50707@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]
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, 07 Sep 2011 22:29:13 -0000

On 9/7/11 12:20 PM, Randell Jesup wrote:
>
> I also started from the same point - assume SIP.  SIP gives you all 
> the things that the zillions of hours and emails to define it and 
> define extensions and secure it provides, without having to reinvent 
> all those wheels (or ask app developers to reinvent them).  Why go 
> through the horrible pain of choosing something else, or why throw the 
> app developers to the wolves to fend for themselves?
>
> However...
>
> Two things have swayed me.  The primary one is the suggestion of 
> Offer/Answer in the browser.  This breaks out the important 
> negotiation piece that almost any application would need, and while 
> not perfect, SDP O/A is a zillion times simpler than SIP with all the 
> extensions one could use.

I agree with this. While I am also opposed to SDP O/A, these are two 
unrelated arguments to have... and not baking a SIP phone into the 
browser is *more* important than avoiding a repeat of the offer/answer 
problems.

>
> The other thing that swayed me was thinking about federation and the 
> apps that will be built with this.  A webrtc app talks to its 
> (web)server, other webrtc clients running the app that talk to the 
> server, and to other webrtc applications/networks that federate with 
> it (and their clients).
>
> Federation is in the same hands as the person who provides/wrote the 
> app.  If they have no interest in federation you can't force it, and 
> they may have no use for all the fancy SIP standards.

And for numerous types of apps (think: server-based augmented reality 
systems), "federation" doesn't even make sense.

>
> On the other hand, if they *want* to either provide access to the 
> wider communication net that is the PSTN network, now or in the 
> future, or they want easy federation with other networks, it behooves 
> them to use SIP or something very close to it or 
> equivalent/convertible (at a basic level at least) to it.
>
> So what conclusions do I draw from this?
>
> 1) O/A via SDP in the browser simplifies a lot of things (including 
> handling new codecs, etc).  It doesn't extremely limit an application, 
> though we should think about how an application can interact with the 
> fmtp/etc parameters used.

I agree that it would simplify some interop cases, but at an unfortunate 
cost in lack of flexibility and functionality. Still not nearly as bad 
as if we put a full SIP stack in there though.

>
> 2) SIP as a *separate* item that can be cleanly and easily *added* to 
> a webrtc app to handle the call setup/etc is a good idea.

I would be open to looking at this again, *after* RTC is already in 
browsers and successful, to see if it actually solves a real use case.

Matthew Kaufman