Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Mon, 19 September 2011 16:36 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 186B021F8BE4 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2H6LZngQ3+Hq for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:36:13 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 10C1921F8BDC for <rtcweb@ietf.org>; Mon, 19 Sep 2011 09:36:12 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8JGcXYH022756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Mon, 19 Sep 2011 11:38:33 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8JGcWH1023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Mon, 19 Sep 2011 11:38:33 -0500
Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8JGcWQ0028944; Mon, 19 Sep 2011 11:38:32 -0500 (CDT)
Message-ID: <4E777008.6090100@alcatel-lucent.com>
Date: Mon, 19 Sep 2011 12:38:32 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org>
In-Reply-To: <4E77495E.4000409@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: Mon, 19 Sep 2011 16:36:14 -0000

I am 100% with Randell.  (Incidentally, my idea of "minimal SIP" has 
been that the browser keeps the SIP state machine while receiving and 
sending SIP messages, with parsing left to application: the outbound 
parameters are supplied--and the inbound ones interpreted--by the JS 
application. In this way, pretty much all versions of SIP can be 
accomodated, while none of them has to be supported by the browser.)

On a different topic, I am confused by the very name of this thread, as 
well as the "was" thread that it replaced. I thought that RTCWeb was 
about "packaging" the existing protocols, not inventing new ones...

Igor

On 9/19/2011 9:53 AM, Randell Jesup wrote:
> ...
> I lean towards a proposal I made a week or two ago; to allow full 
> access (which allows
> user-written JS signalling libraries) but provide minimal SIP+O/A as 
> an option within
> the browser.  This could be a JS library, but the primary users of 
> this would be the
> "little guys" who just want simple setup of media streams, and they're 
> most likely to
> never update, while browsers are updated frequently.
>
> ...
> That's entirely available to the application; they can use their own 
> if they wish.
> And while I suggest a simple SIP set be included, if we were certain a 
> "standard" JS
> lib were freely available and solid enough, that would make the 
> argument stronger for
> a JS lib.
>
> ....