Re: Keeping up data channel

On Wed, Jun 13, 2012 at 5:09 AM, <Markus.Isomaki@nokia.com> wrote:

>
>
> Stefan Hakansson wrote:
> >On 06/12/2012 07:36 AM, Harald Alvestrand wrote:
> >> On 06/11/2012 03:58 PM, Markus.Isomaki@nokia.com wrote:
> >>>
> >>> 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.
> >
>
> Fair enough. It would be useful to write this down somewhere in our
> documents. People would probably expect that leaving audio/video sessions
> on has an ill effect on power consumption, but might not understand that
> the same would apply to idle peer-to-peer data channels. Apps should close
> them e.g. when they are on "background", and just leave the "signaling"
> connection open so that they can be quickly re-established.
>
> Markus
>
+1
leaving audio/video session on without using it not only will impact on
power consumption, but also will have some privacy issue and they also will
consume the processing power of the device.

But for closing them by app when they are in background, I suggest it will
prompt a dialogue to user for choose to close it or leave it open, if no
response for some time, it will automatically close the peerconnection and
stop mediastream from the camera.

I think the closing function and detect user away function is out of scope
of this specification, but we may have an implementation recommendation for
this issue.

-- 
Yang
Huawei