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

"Olle E. Johansson" <oej@edvina.net> Tue, 06 September 2011 18:45 UTC

Return-Path: <oej@edvina.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 3A54A21F8D48 for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 11:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 9uTmZi5f7L-g for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 11:45:26 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A507021F8D47 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 11:45:26 -0700 (PDT)
Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 60D5C754BCE4; Tue, 6 Sep 2011 18:47:10 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=iso-8859-1
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <4E666926.8050705@skype.net>
Date: Tue, 6 Sep 2011 20:47:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net>
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>
To: Matthew Kaufman <matthew.kaufman@skype.net>
X-Mailer: Apple Mail (2.1244.3)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
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 18:45:27 -0000

6 sep 2011 kl. 20:40 skrev Matthew Kaufman:

> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
>> Matthew,
>>  
>> Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality.
> 
> Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser.
That's an implementation detail. One can easily add an API call to add headers on the outbound INVITE.

> 
> If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*.
> 
>> There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported.
> See above.
>>  
>>  In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail.
> 
> See above. I want you to be free to use SIP, but not *required* to use SIP.
> 
> And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060.
SIP runs on TCP and TLS ports too.

I am not arguing for either side, just correcting some details...

/O