Summary:	ASTERISK-21383: STUN Binding Requests Not Being Sent Back from Asterisk to Chrome
Reporter:	Shaun Clark (shaunc869)	Labels:
Date Opened:	2013-04-05 10:06:36	Date Closed:	2013-11-01 07:38:05
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_http_websocket
Versions:	11.3.0 11.4.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ASTERISK-21383.diff ( 1) capture.pcap ( 2) chansip_11-4-rc1_21383_2013_4_12.patch ( 3) chansip_11-4-rc1_21383_2013_4_14.patch ( 4) chrome_debug_good_call-21383.log ( 5) onewaycapture.pcap ( 6) Screen_Shot_2013-04-05_at_8.10.27_AM.png ( 7) stuncap.pcap
Description:	When placing an outbound call from jssip/webrtc we get a one way audio situation that produces an error in Chrome that states: [1794:9495:0403/134116:VERBOSE1:port.cc(289)] Jingle:Port[audio:1:0::Net[en0:10.0.1.3/32]]: Received non-STUN packet from unknown address (198.61.XX.XX:11036) Asking the WebRTC group they say the error relates to RFC Spec 5245 section 17, where it talks about sending back stun bind requests from in this case Asterisk to the client. They believe that the bind request is not being properly returned. (https://groups.google.com/forum/?fromgroups=#!topic/discuss-webrtc/GKtrfMir2sE)
Comments:	By: Shaun Clark (shaunc869) 2013-04-05 10:07:15.649-0500 Wireshark capture on the local client during the one way audio call. By: Shaun Clark (shaunc869) 2013-04-05 10:11:39.673-0500 Chrome Error Log By: Shaun Clark (shaunc869) 2013-04-05 11:10:16.023-0500 Server capture with STUN messages By: Shaun Clark (shaunc869) 2013-04-05 11:31:40.347-0500 Got a two way call and captured the packets on the server, you can see two way STUN packets, this is with 0 changes to the server so this problems seems to happen randomly. By: Shaun Clark (shaunc869) 2013-04-05 11:48:05.293-0500 Additional feedback from WebRTC is: I looked at the trace and a binding request is sent from B to Chrome, but not until 7 seconds into the call 1949 6.971568 198.61.170.55 50.43.101.90 STUN 186 Binding Request user: KHi2c1n7iBcTukWC:7cafd4523fc0f40912fdb7196e39c60a Regarding why Chrome sends audio, if you look at the example I sent previously, the offering endpoint starts sending audio once its checks complete, this is shown in step 13. The remote side should not start sending audio until its check completes, in step 17, so Chrome discards it silently. By: Shaun Clark (shaunc869) 2013-04-09 10:31:57.533-0500 The WebRTC team in this issue (https://code.google.com/p/webrtc/issues/detail?id=1593) concludes: I looked at the 708 logs from #31 and I noticed that the STUN binding requests from GW to Chrome all happen before Chrome is ready to get them (i.e., has received the 200 from the GW). In the 708 call, the GW gives up on the binding requests before the 200 and never sends one again later (for the RTP channel). In the 777 call, the GW does send a binding request after the 200, although some media is lost since the request trails the 200 by some amount of time. The fact the gateway gives up so quickly seems like a problem on the GW side, as well as the fact that the GW is not properly responding to ICE Triggered Checks. I think there is also a problem here where Chrome is not ready to receive binding requests in ICE mode before it receives the 183/200, since it doesn't make the ICE versus GICE decision until then. This is unlikely to matter in real-life cases where the client is behind NAT since Chrome won't be able to receive binding requests ahead of the 183/200 anyway. I will file a new issue on this latter problem. Which I can see also in the pcaps attached to that issue. Why would Asterisk respond in sync during one scenario and out of sync in another? So I would say this comes down to when the STUN binding requests are being sent relative to when they should be. By: James Mortensen (jmort253) 2013-04-12 21:28:01.076-0500 We went ahead and modified chan_sip.c so that Asterisk sends only it's public IP in the ICE candidates that it sends to Chrome.  By replacing the local IP in host candidates in the 183/200's from Asterisk to Chrome with the public IP, all of the dropped STUN requests/responses have been eliminated, and we're able to consistently get two-way audio from calls made from Chrome Stable to Asterisk 11.4.0-rc1. I've attached the patch for review and testing, and I've also included my Chrome Stable debug log in case someone wants to review what Asterisk is sending to Chrome and vice-versa. By: James Mortensen (jmort253) 2013-04-14 15:06:37.354-0500 It turns out that our first patch wasn't following RFC-5245 section 3. So we modified chan_sip so that instead of replacing the host candidates with the public IP, we fix the problem with the rtcp port on the second srflx candidate. According to the spec, it's supposed to be 1 plus the value of the port in the media description (m= record). Can someone take a look at this and let us know if there are any issues with this? Since it fixes the one way audio issues we were facing due to the STUN errors, we'd like to see this added to the trunk. More details and the discussion surrounding these issues can be found in this discussion thread:  https://groups.google.com/d/msg/discuss-webrtc/GKtrfMir2sE/u6GOSZUIUrIJ By: Rusty Newton (rnewton) 2013-04-18 19:33:22.337-0500 Thanks for all the info and the patch. It's in our queue now and I'll ping someone to see if they can take a look. By: James Mortensen (jmort253) 2013-10-12 18:39:46.976-0500 I just verified that this same bug exists in Asterisk 12.0.0-beta1.   If I try to call out, or in, without the patch, the RTCP port is incorrect and Asterisk is unable to process the audio. So audio flows from the carrier to Chrome and from Chrome back to Asterisk, but since Asterisk gave Chrome a bad RTCP port, the audio isn't processed correctly. I applied the https://issues.asterisk.org/jira/secure/attachment/46983/chansip_11-4-rc1_21383_2013_4_14.patch patch and rebuilt Asterisk and have verified the patch still works. With the patch in place, I can hear audio on both ends. Hope this helps! By: Kinsey Moore (kmoore) 2013-10-28 09:44:46.498-0500 I've done a bit of rework on the provided patch to make it more consistent with the rest of Asterisk. Functionality should be the same as with chansip_11-4-rc1_21383_2013_4_14.patch. Please check out ASTERISK-21383.diff when you get a chance.