- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Wed, 13 Jun 2012 05:29:28 -0400
- To: public-webrtc@w3.org
On 6/13/2012 3:07 AM, Harald Alvestrand wrote: > On 06/13/2012 01:01 AM, Martin Thomson wrote: >> On 12 June 2012 13:15, Stefan Hakansson LK >> <stefan.lk.hakansson@ericsson.com> wrote: >>> I think we need to make developers close the PeerConnection when it >>> is not >>> needed. A way to promote this would of course be to make >>> PeerConnection set >>> up fast. >> Unfortunately, responsiveness is also a trait that is valued highly. >> Setup for data channels is currently prohibitively long. Applications >> that are not specifically targeting mobile users will have abysmal >> performance on mobile networks initially. Expect the radio to remain >> on constantly. > I'm really looking forward to having an implementation up so that I can > test what the setup time is for various media path RTTs and signalling > path RTTs. > > How far down do you think we have to drive the setup time before you > would not call it "abysmal"? > > (for reference: the responder's time from hitting "allow" in Chromium to > having a video on the screen with apprtc.appspot.com is subjectively > quite short - below 2 seconds - I can't measure it more accurately > without generating logs for it.) Well, I *want* time from "ok" to all media live to be on the order of 200ms or less (I'd like <100ms). I may not get it with ICE, DTLS, etc, but that's what I want. These are the times I typically could get in a dedicated videophone, and that users of hardphones (analog POTS or SIP UAs) are used to. 2 seconds may seem good in webcam chat, but I feel it's already horrid at 2 seconds. -- Randell Jesup randell-ietf@jesup.org
Received on Wednesday, 13 June 2012 09:29:57 UTC