W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Keeping up data channel

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 13 Jun 2012 15:45:04 +0200
Message-ID: <4FD89960.4000502@ericsson.com>
To: SUN Yang <sun.yang.nj@gmail.com>
CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2012-06-13 15:36, SUN Yang wrote:
> On Wed, Jun 13, 2012 at 4:15 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>     On 06/12/2012 07:36 AM, Harald Alvestrand wrote:
>         On 06/11/2012 03:58 PM, Markus.Isomaki@nokia.com
>         <mailto:Markus.Isomaki@nokia.com> wrote:
>             Hi,
>             In today's WebRTC meeting a discussion came up on how costly
>             it is
>             to keep an unused data channel connected.
>             As long as we are using UDP, it is extremely costly for cellular
>             connected mobile devices. In many networks keep-alives at least
>             every 30 seconds are neeed to keep the UDP flow alive.
>         We also have to send something every 30 seconds to keep the
>         consent-to-receive alive in the case of media (and to maintain NAT
>         mappings). So as long as a PeerConnection remains unclosed, I think
>         we should assume that a packet will be sent every 30 seconds.
>     I agree, and I also think this is more of a PeerConnection than a
>     data channel issue.
>     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.
> Why set up PeerConnection fast means closing PeerConnection when not needed?

It just a guess of how developers will behave. If it takes long to setup 
a PeerConnection it's likely that developers won't close it unless 
they're sure that it won't be used again. If it's quick and easy to 
setup again, they might consider closing it.

Received on Wednesday, 13 June 2012 13:45:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC