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

Re: Keeping up data channel

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 13 Jun 2012 15:44:14 +0200
Message-ID: <4FD8992E.5000700@ericsson.com>
To: SUN Yang <sun.yang.nj@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 06/13/2012 03:36 PM, 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?

The idea was that if PeerConnection setup is fast (and always works!), 
the app developer would be less resistant to close it when it is 
temporarily not needed.

> But I agree with you on it is more like a PeerConnection Issue than
> dataChannel issue.
>
> --
> Yang
> Huawei
>
Received on Wednesday, 13 June 2012 13:44:48 UTC

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