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

Justin Uberti <juberti@google.com> Tue, 06 September 2011 20:21 UTC

Return-Path: <juberti@google.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 7858B21F8DFD for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 13:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.669
X-Spam-Level:
X-Spam-Status: No, score=-104.669 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, 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 d1ILGFnYWKTI for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 13:21:36 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 21D6821F8E0F for <rtcweb@ietf.org>; Tue, 6 Sep 2011 13:21:35 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p86KNCZd020324 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 13:23:13 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315340593; bh=dBT6KUEk50c7cxTByU866k/aIzo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VkTsdg7nwTCWYTgKFmQhAFETd3F8mvqarq3KSxgJtf4nUaG19QhjSt7tL7acY4cFf BSBR1lGhhJBGtxKHQ98Mg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=RHyOb+BdAq4HUibAfg0myJlHqe5wAxe34TOpm7f1n6IeszJd+Hi6IkGmzXZPl+IrQ rR+/2u1C9wU9wHWvPCJNA==
Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq5.eem.corp.google.com with ESMTP id p86KMYl3016683 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Tue, 6 Sep 2011 13:23:11 -0700
Received: by yib12 with SMTP id 12so3838146yib.10 for <rtcweb@ietf.org>; Tue, 06 Sep 2011 13:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0tQyaPKLcFVJXkz5BQezhZ6jEXcCmzG99NYUNWRt25U=; b=WHHG0+8xXx1O2Gp61gKCcecvu/KWiz8KA8Te+5fPJDIUVZ/Y9YRBMWnZIKR8J33H0i PytqT4qpoKNG7zcg+Ezw==
Received: by 10.231.66.85 with SMTP id m21mr10411859ibi.53.1315340591499; Tue, 06 Sep 2011 13:23:11 -0700 (PDT)
Received: by 10.231.66.85 with SMTP id m21mr10411852ibi.53.1315340591272; Tue, 06 Sep 2011 13:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.10 with HTTP; Tue, 6 Sep 2011 13:22:50 -0700 (PDT)
In-Reply-To: <4E66789C.4020307@alcatel-lucent.com>
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> <4E66789C.4020307@alcatel-lucent.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 6 Sep 2011 16:22:50 -0400
Message-ID: <CAOJ7v-38yzNBpgb8LrZX1CE097ZAWnWh=3JPn95em9wyBUWtSw@mail.gmail.com>
To: igor.faynberg@alcatel-lucent.com
Content-Type: multipart/alternative; boundary=0015176f09d8b392d004ac4b9864
X-System-Of-Record: true
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 20:21:37 -0000

Notifications can be received over WebSockets, or any of the existing
mechanisms web applications use for server->client notifications.

On Tue, Sep 6, 2011 at 3:46 PM, Igor Faynberg <
igor.faynberg@alcatel-lucent.com>; wrote:

> The key question is:  What MUST the browser provide to support a SIP
> implementation in an application? (I asked this question a few thousand
> messages back, but the thread was inconclusive.)
>
> HTTP alone cannot do the job. How will the user agent receive
> notifications, for example?
>
> Igor
>
>
> On 9/6/2011 2:47 PM, Olle E. Johansson wrote:
>
>> 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
>>
>> ______________________________**_________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>