Return-Path: 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 431ED1F0C76 for ; Tue, 18 Oct 2011 14:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 tVEHPwGSlDNl for ; Tue, 18 Oct 2011 14:53:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0209F1F0C7A for ; Tue, 18 Oct 2011 14:53:04 -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; Tue, 18 Oct 2011 17:53:00 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 17:53:00 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Current state of signaling discussion Thread-Index: AQHMjeBN9USwkyocF0KQH5G/+0/FIA== Date: Tue, 18 Oct 2011 21:52:59 +0000 Message-ID: <48FB392E-A65C-44B8-B526-D7DD10C72D7E@acmepacket.com> References: <4E9D773A.4010705@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5163235E6293C947A9E1D3B14FB7DF74@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Current state of signaling discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:53:06 -0000 On Oct 18, 2011, at 5:18 PM, Eric Rescorla wrote: > One might already have much of this stuff in your application to support > whatever person-to-person communications (E.g., IM) you already > have. When I heard "20 lines of code" I always assumed that it excluded t= hat > sort of routing-type stuff. But that's the point exactly - OF COURSE that type of stuff might already b= e in your application, and could be conveyed in a URL or all be implicit or= whatever. Or it might not at all be in your app and need to added for thi= s in some way. =20 And that's the point many of us have been making: don't define a standard s= ignaling protocol, because it's all application-specific to the web-app, wh= ich only the web-app developer would possibly know. Thus, I'm asking the chairs what they mean when they use the word "signalin= g". If they mean session signaling, then ROAP doesn't do it either. If th= ey only mean media-setup+negotiation signaling, that's a different problem = scope. (I think that too is unnecessary, but if you put full SDP offer/answ= er state in the browser, then it's probably a fait accompli) -hadriel