ICE Keepalive from Chrome is a bug?

[SteveG]

Hi,

The chrome browser is sending STUN keepalive at 450ms intervals.  All information I can see in the RFCs (5245 and consent-freshness) indicates that the interval between keepalive is 15 seconds.

For a browser to browser implementation I can see this may not be a concern, but if there is a GW that is terminating STUN for webrtc calls then that extra traffic is a burden.

Is there a reason Chrome sends keepalive so frequently?  Should I open a new issue to track this or is there a way to re-open https://code.google.com/p/webrtc/issues/detail?id=1161  ?

Thanks,

Steve   

From 5245:

If there has been no packet sent on the candidate pair ICE is using
   for a media component for Tr seconds (where packets include those
   defined for the component (RTP or RTCP) and previous keepalives), an
   agent MUST generate a keepalive on that pair.  Tr SHOULD be
   configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be
   configured to less than 15 seconds.

From consent-freshness:

 A consent timer, Tc, whose value is determined by the browser.  This value MUST be 15 seconds.

Every Tc seconds, the WebRTC browser sends a STUN Binding Request to the peer.

[SProgrammer]

Please confirm which Turn Server you have used? I are using http://code.google.com/p/rfc5766-turn-server/  latest one, never face those problems. Must be related to your broken trun-server or using old versions with BUGS.

[Steve Gibbard]

Hi, 

Thanks for the reply.  We are using stuntman stun server in our lab http://sourceforge.net/projects/stuntman/files/ 

and are running these calls using chrome  Version 32.0.1700.72 m.

I see the candidates gathered from the stun server.  The webrtc call is made to our gateway which negotiates ice-lite.  The call comes up and we have audio however the STUN Binding Requests for keep alive from the browser come at  480ms intervals. 

This seems like the behaviour discussed in this chrome issue:

 https://code.google.com/p/webrtc/issues/detail?id=1161 

The ICE keep alive is sent between the browser and the terminating point for the call so once the turn/stun server has been used to gather candidates I don't think it would have any influence over the keep alive rate between the browser and endpoint.

I have attached a pcap of the ICE interaction from the originating browser.

.157 is the browser end.

.1 is the terminating gateway using ice-lite

Steve

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/pnRYbD3-r78/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[kapejod]

Hi,

i think that sending STUN binding requests frequently is a good thing.

This way you can handover WebRTC sessions when your client is changing networks,

e.g. a mobile client leaving its home wifi and switching to 3G.

The section of 5245 that you quoted applies to the case where no media is being sent, but you do have an active call with media being sent, right?

best regards,

Klaus

On Thursday, January 9, 2014 1:00:46 PM UTC+1, SteveG wrote:

[Justin Uberti]

The reason we send so often is to perform liveness detection and fast failover, like Klaus mentions. However, we have considered relaxing the send rate.

If this is causing problems for your gateway, could you explain more about the exact problems? Sending 2 STUN responses per second should be pretty cheap compared to the cost of processing 50 media packets per second.

[Steve Gibbard]

Justin / Klaus,

Thanks for your time responding.

For a typical video call leg there would be keep-alive sent on 4 channels if bundle and rtp/rtcp mux is not supported by the peer gateway.  At a 480ms interval for a 3 minute call this extrapolates to 1500 keep alive packets per call leg.  I think each of these packets needs to pass validation/authentication and in our system this is being done by the application layer (rather than at the media transcode/passthrough layer), which adds excessive processing in our architecture, where we could be handling tens of thousand of webrtc call legs plus other types of calls. 

As the browser is not following the RFCs in this regard we would much prefer the behaviour at the browser end to change and have keep-alive sent at 15s intervals, or at least be configurable (RFC 5245 has a recommendation for a configurable keep-alive value).  

The RTP packets (~20ms) should keep the nat binding open anyway.  Although I agree it is simpler to just send keep-alive even when media is flowing and we would be happy to live with that behaviour if the keep-alive rate was less frequent. 

Can I open an issue for this?

Steve

[Justin Uberti]

This issue has not been closed; we just haven't decided exactly what we are going to do about it. Right now it is a medium priority issue, but we plan to handle it once we deal with some higher priority tasks (or it gets more upvotes).

[Steve Gibbard]

Sorry Justin I thought I saw the issue move to wontFix, I see it is in the available state.  I will wait/hope :) for a resolution. Do you know if we dropped the message-integrity param from the keep-alive response if the browser would reject that response?  (I am wondering if chrome authenticates the keep-alive exchanges too).

[Mallinath Bareddy]

Yea, it does authenticates keep-alive messages too.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.