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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 21 September 2011 11:22 UTC

Return-Path: <HKaplan@acmepacket.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 1823C21F8A58 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 04:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 YNQerMMKa4hT for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 04:22:19 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F139721F8876 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 04:22:18 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Sep 2011 07:24:46 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 07:24:46 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
Thread-Index: AQHMeFEQ7TNY7RqJnUiNIyKjjxBJyw==
Date: Wed, 21 Sep 2011 11:24:46 +0000
Message-ID: <1AF68A74-EF46-4F78-999C-C37BFAA9FC31@acmepacket.com>
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> <CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com> <4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <DB86C19C-781C-4FD2-ADE2-D6E1C0EE1D61@ag-projects.com> <4E79A964.2050007@alvestrand.no>
In-Reply-To: <4E79A964.2050007@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FDCF340312D5DE47A0A485A0CDDE376C@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] "20 lines" (Re: 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
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, 21 Sep 2011 11:22:20 -0000

On Sep 21, 2011, at 5:07 AM, Harald Alvestrand wrote:

> The developers of applications that need audio and video capabilities are not RTC developers. Their main focus and main skill set will lie elsewhere.

I agree.  That's why JS libraries exist, though, isn't it?


> In a little more than 20 lines of code, it is possible to set up a call using a variant form of the existing W3C API. I know, I have seen the code. Other examples (in a slightly different variant) are part of the Ericsson demo.

Well, to be fair, the Ericsson code has this at the top of the main HTML page's script:
<script type="text/javascript" src="signaling.js"></script>

And that separate JS is another ~100 lines of code.  
And that "signaling" code doesn't appear to actually handle the rendezvous function of signaling - you have to email the other party a cookified URL to reach you at for the particular session. (I think)
And it doesn't appear to handle terminating a session (other than by closing the browser window).

But then, it's just a demo.
[note: I'm not disparaging the demo - it's a cool demo]


> What's perhaps more important is that none of those 20+ lines mention anything about codecs, bit rates, congestion control or any of the numerous other issues we've been hashing out.

Right, nor should they - the browsers should do that stuff internally, and only if the JS actually wants/needs to get involved somehow should it need to (through callbacks/whatever).
No one's been saying the JS needs to be responsible for codecs, bit rates, congestion control, or anything much media related.

We've only been arguing about:
1) Using SDP and the SDP offer/answer as the media API
2) Whether there should be a "default" signaling component built in as well, or let JS libraries handle it


> With the API we support, simple things MUST be simple. Complex things must be possible.

Yes, it should be "as simple as it can be, but no simpler".  The tricky part's always figuring out what that means. :)

Why isn't this simple enough:
<script src="http://ajax.googleapis.com/ajax/libs/sigpipe/1.0/sigpipe.min.js"></script>

-hadriel