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

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Tue, 06 September 2011 19:00 UTC

Return-Path: <pravindran@sonusnet.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 22EA121F8D13 for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 12:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level:
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599]
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 D5gdrNiTOv2E for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 12:00:53 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFD621F8D89 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 12:00:46 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p86J2wQR007816; Tue, 6 Sep 2011 15:02:58 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 15:02:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Sep 2011 00:32:24 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F086C@sonusinmail02.sonusnet.com>
In-Reply-To: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
Thread-Index: AcxsxWWfyNnA2J9pQ+iNipdIXlgKZwAAIJVg
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>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Olle E. Johansson" <oej@edvina.net>, "Matthew Kaufman" <matthew.kaufman@skype.net>
X-OriginalArrivalTime: 06 Sep 2011 19:02:28.0315 (UTC) FILETIME=[85A18AB0:01CC6CC7]
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 19:00:56 -0000

Matthew,

<snip>>> 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. </snip>

In case one port opening (80) will not create security issue but how
opening two ports (80 & 5060) will cause security issue? Could you
please explain the security reason between port 80 for HTTP and 5060 for
SIP

Please read inline for further comments.

Thanks
Partha

>-----Original Message-----
>From: Olle E. Johansson [mailto:oej@edvina.net]
>Sent: Wednesday, September 07, 2011 12:17 AM
>To: Matthew Kaufman
>Cc: Ravindran Parthasarathi; 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]
>
>
>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.
[Partha] My understanding is same as olle. Javascript API MUST provide
the mechanism to add proprietary SIP headers or else I agree with you
that solution is useless.

>
>>
>> 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.
[Partha] In case Javascript API supports for adding new headers, there
is no difference right?

>>
>> 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.
[Partha] 
>
>I am not arguing for either side, just correcting some details...
>
>/O