Re: [rtcweb] Another consideration about signaling

"Kevin P. Fleming" <> Fri, 07 October 2011 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4478621F8C4E for <>; Fri, 7 Oct 2011 12:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.081
X-Spam-Status: No, score=-106.081 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u3k926fk9leo for <>; Fri, 7 Oct 2011 12:46:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 485E221F8BDB for <>; Fri, 7 Oct 2011 12:46:51 -0700 (PDT)
Received: from zimbra.digium.internal ([] by with esmtp (Exim 4.69) (envelope-from <>) id 1RCGQm-00087f-Jz for; Fri, 07 Oct 2011 14:50:04 -0500
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 94BF81A2006 for <>; Fri, 7 Oct 2011 14:50:04 -0500 (CDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KLPB+UpWN0Vx for <>; Fri, 7 Oct 2011 14:50:04 -0500 (CDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id F08941A2001 for <>; Fri, 7 Oct 2011 14:50:03 -0500 (CDT)
Message-ID: <>
Date: Fri, 07 Oct 2011 14:50:03 -0500
From: "Kevin P. Fleming" <>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
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: Fri, 07 Oct 2011 19:46:52 -0000

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.

Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: | SIP: | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at &