[asterisk-bugs] [JIRA] (ASTERISK-21383) STUN Binding Requests Not Being Sent Back from Asterisk to Chrome

[Shaun Clark (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205089#comment-205089 ] 

Shaun Clark commented on ASTERISK-21383:
----------------------------------------

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.
                
> STUN Binding Requests Not Being Sent Back from Asterisk to Chrome
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-21383
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21383
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_http_websocket
>    Affects Versions: 11.3.0, 11.4.0
>            Reporter: Shaun Clark
>         Attachments: capture.pcap, onewaycapture.pcap, Screen Shot 2013-04-05 at 8.10.27 AM.png, stuncap.pcap
>
>
> 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)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira