Re: [rtcweb] Another consideration about signaling
"Kevin P. Fleming" <kpfleming@digium.com> Sat, 08 October 2011 14:14 UTC
Return-Path: <kpfleming@digium.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 AB0B721F8BF8 for <rtcweb@ietfa.amsl.com>; Sat, 8 Oct 2011 07:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.314
X-Spam-Level:
X-Spam-Status: No, score=-105.314 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, J_BACKHAIR_43=1, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 AKUlJLOS175y for <rtcweb@ietfa.amsl.com>; Sat, 8 Oct 2011 07:14:21 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id BD51521F8BF4 for <rtcweb@ietf.org>; Sat, 8 Oct 2011 07:14:21 -0700 (PDT)
Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1RCXib-0004ty-RA for rtcweb@ietf.org; Sat, 08 Oct 2011 09:17:37 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C59F1D82A3 for <rtcweb@ietf.org>; Sat, 8 Oct 2011 09:17:37 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCZ4lDMoVV4D for <rtcweb@ietf.org>; Sat, 8 Oct 2011 09:17:37 -0500 (CDT)
Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D829CD8024 for <rtcweb@ietf.org>; Sat, 8 Oct 2011 09:17:36 -0500 (CDT)
Message-ID: <4E905B7F.7010505@digium.com>
Date: Sat, 08 Oct 2011 09:17:35 -0500
From: "Kevin P. Fleming" <kpfleming@digium.com>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
CC: rtcweb@ietf.org
References: <CALiegfmoPWfhtBRiOfgLHG1uhJK_kK2t11xMoop-fT6qW4DUJQ@mail.gmail.com> <4E8F57EB.8030504@digium.com> <CABw3bnOD5APidfbqNscXdPURyY-AMQZqoyYPm6v2xWo5VWKOLA@mail.gmail.com>
In-Reply-To: <CABw3bnOD5APidfbqNscXdPURyY-AMQZqoyYPm6v2xWo5VWKOLA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
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: Sat, 08 Oct 2011 14:14:22 -0000
On 10/08/2011 04:02 AM, José Luis Millán wrote: > Kevin, > > 2011/10/7 Kevin P. Fleming<kpfleming@digium.com>: >> On 09/16/2011 10:42 AM, Iñaki Baz Castillo wrote: >>> >>> Hi all, >>> >>> Let's imagine that rtcweb defines a specific signaling protocol (i.e. >>> SIP) so browsers MUST use it natively for signaling the media streams. >>> Of course this would require a SIP proxy/server in server side (think >>> about NAT) which IMHO seems a showstopper (how to deploy such a SIP >>> proxy in shared web hostings? a "mod_sip" for Apache? should I make a >>> XMPP<->SIP protocol gateway in order to intercommunicate web-browsers >>> with pure XMPP clients?) >>> >>> But there is another important drawback with this assumption: >>> >>> A web site could be interested in drawing in the web the status of the >>> different audio/video streams between users connected to the web. This >>> could mean displaying in the web the active streams (audio/video), >>> when a session is on hold, when it's resumed again, when a new stream >>> is added to a multimedia session (i.e. offering video within an >>> already established audio session). >>> >>> If the signaling uses a separate channel (i.e. SIP) then there is no >>> way for the web server to know what happens during multimedia sessions >>> (or it would be really difficult to achieve). So multimedia sessions >>> would be completely separated from the web page itself. Is that what >>> we want? >> >> (resurrecting this old thread) >> >> Regardless of the signaling protocol in use, it seems unlikely to me that a >> web application developer is going to want to be *involved* in the call >> signaling itself; they are going to pass that responsibility over to some >> existing code/library/server/system (which could mean just shuttling SIP >> messages back and forth between WebSocket connections and UDP connections). >> >> If this assumption is true, then the web application developer who wants to >> achieve the result you describe above is going to choose a SIP >> library/server that allows them access to the call states and other pieces >> of information that they need, in preference to those who don't make that >> information available. I can't imagine that a practical solution would be to >> choose a SIP library/server that handles the calls in an 'opaque' fashion >> but then build a web application that is required to snoop on all the >> signaling to be able to monitor activity. >> > > Web developers have to use well defined APIs so they don't need to > know how the underlaying protocol works. Instead, they rely on the API > methods and information to achieve what Iñaki is stating. I don't disagree with your statements here, but I'm not sure that those statements change anything :-) This group is not defining APIs to be used on the *server* side, only on the browser side. On the server side, if a web application wants to be able to keep track of multimedia sessions and use that information for various purposes, then yes... it will require APIs to do so. Those APIs will be into whichever signaling library/server/component the web application developer has chosen to handle the signaling of those multimedia sessions. This was exactly my point, that the web application would not be actively monitoring the signaling *itself* in order to keep track of sessions... so if the signaling is just being routed by the web application over to another component/server, that's perfectly acceptable and doesn't interfere with the application's ability to keep track of the sessions. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org
- Re: [rtcweb] Another consideration about signaling Kevin P. Fleming
- [rtcweb] Another consideration about signaling Iñaki Baz Castillo
- Re: [rtcweb] Another consideration about signaling Henry Sinnreich
- Re: [rtcweb] Another consideration about signaling Dzonatas Sol
- Re: [rtcweb] Another consideration about signaling José Luis Millán
- Re: [rtcweb] Another consideration about signaling Kevin P. Fleming
- Re: [rtcweb] Another consideration about signaling José Luis Millán
- Re: [rtcweb] Another consideration about signaling Kevin P. Fleming
- Re: [rtcweb] Another consideration about signaling Iñaki Baz Castillo
- Re: [rtcweb] Another consideration about signaling Kevin P. Fleming
- Re: [rtcweb] Another consideration about signaling Iñaki Baz Castillo
- Re: [rtcweb] Another consideration about signaling Ted Hardie
- Re: [rtcweb] Another consideration about signaling Iñaki Baz Castillo
- Re: [rtcweb] Another consideration about signaling Ted Hardie
- Re: [rtcweb] Another consideration about signaling Randell Jesup
- Re: [rtcweb] Another consideration about signaling Iñaki Baz Castillo
- Re: [rtcweb] Another consideration about signaling Saúl Ibarra Corretgé
- Re: [rtcweb] Another consideration about signaling Neil Stratford