Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Starting SIPCC in Firefox for multiple tabs

Received: by 10.68.129.169 with SMTP id nx9mr712239pbb.2.1334709187253;
        Tue, 17 Apr 2012 17:33:07 -0700 (PDT)
Path: r9ni68463pbh.0!nntp.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 17 Apr 2012 19:33:06 -0500
Return-Path: <rje...@mozilla.com>
X-Original-To: dev-me...@lists.mozilla.org
Delivered-To: dev-me...@lists.mozilla.org
X-Virus-Scanned: amavisd-new at mozilla.org
Received-SPF: none (mozilla.com: No applicable sender policy available)
	receiver=notorious.mozilla.org; identity=mailfrom;
	envelope-from="rje...@mozilla.com"; helo=dm-mail03.mozilla.org;
	client-ip=10.2.74.48
Date: Tue, 17 Apr 2012 20:32:39 -0400
From: Randell Jesup <rje...@mozilla.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Eric Rescorla <e...@rtfm.com>
Subject: Re: Starting SIPCC in Firefox for multiple tabs
References: <CBB25752.532C%emannion@cisco.com> <4F8CE3AF.4080702@mozilla.com>
	<CABR-dWri-iR3FvTWsUTJOsQqQ4ViV2i3bfijnwGLpXwcA_FH9g@mail.gmail.com>
	<CABcZeBN6CVXU5Kxz=TYNsdBmvcUUeMDUycxPvBXquTrr=NGq5w@mail.gmail.com>
In-Reply-To: <CABcZeBN6CVXU5Kxz=TYNsdBmvcUUeMDUycxPvBXquTrr=NGq5w@mail.gmail.com>
Cc: dev-me...@lists.mozilla.org, Enda Mannion <emann...@gmail.com>
X-BeenThere: dev-me...@lists.mozilla.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "For discussion around media in browsers \(Video, Audio, WebRTC,
	etc.\)" <dev-media.lists.mozilla.org>
List-Unsubscribe: <https://lists.mozilla.org/options/dev-media>,
	<mailto:dev-media-requ...@lists.mozilla.org?subject=unsubscribe>
List-Post: <mailto:dev-me...@lists.mozilla.org>
List-Help: <mailto:dev-media-requ...@lists.mozilla.org?subject=help>
List-Subscribe: <https://lists.mozilla.org/listinfo/dev-media>,
	<mailto:dev-media-requ...@lists.mozilla.org?subject=subscribe>
Approved: dev-me...@lists.mozilla.org
Newsgroups: mozilla.dev.media
Message-ID: <mailman.22013.1334709186.31724.dev-me...@lists.mozilla.org>
Lines: 37
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 63.245.208.166
X-AuthenticatedUsername: NoAuthUser
X-Trace: sv3-v9CquStLm0oLw0oQWM0A0dlNxGa7ClpeSwHr0Nw/JFeWFP91pzstRBY/SpzVMWsuUqmMRGIgq/wcLEV!2D9KYQoXRSVv9giAxOdkrUut+NLTcC56zpvgciRYMVUXNNwAYfGh4poyuOg8nfy6K7MTHQ1v1G27!lc6d0LTAARHPTltnoopDpvpe2OOsWh7K
X-Complaints-To: ab...@mozilla.org
X-DMCA-Complaints-To: ab...@mozilla.org
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4592
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 4/17/2012 6:41 PM, Eric Rescorla wrote:
> On Tue, Apr 17, 2012 at 2:58 PM, Enda Mannion<emann...@gmail.com>  wrote:
>> Thanks for you feedback.  I think running one instance of SIPCC as the
>> SDP engine for multiple PeerConnections is the best way to go, main
>> reasons being performance and resources. SIPCC is currently very
>> stable at handling multiple calls but we know less about its stability
>> if it is run as multiple instances to handle multiple PConnections.
>> Also running multiple SIPCCs will unnecessarily use more message
>> queues and threads than needed.  There is also a lot more SIPCC
>> startup and shutdown CPU usage when running N instances.
> I'm extremely concerned about this proposal. The security model clearly
> indicates that PCs from different origins need to be isolated, and I'm
> not convinced that that happens properly when you have one shared
> SIPCC. What security analysis have you done to indicate that this is
> OK?

Security is a concern; I forget if I raised it in my last message, but 
it was on my mind (if for no other reason than one PC could access the 
shared Signaling instance, and if that PC can lock up or otherwise mung 
the instance it would take all current calls and probably require a 
restart of FF to fix).

I'm a bit less worried about state from one call escaping to another 
call, though it's certainly possible,  Obviously sipcc needs to be 
secure whether or not it's a singleton; singleton just means that the 
thread/object has more data from other calls easily available to it.

One interesting idea would be to run the signaling singleton in a 
separate process, much as we do for plugins. This would provide far 
better firewalling, at the cost of some performance when doing call 
signaling.  Hmmm.  And there still would be cross-call vulnerabilities 
to worry about, but overall it might be a safer design.

Please excuse the off-the-top-of-my head consideration here...

    Randell Jesup