On 22/09/14 15:28, Daniel Pocock wrote: > On 22/09/14 13:59, Daniel Pocock wrote: >> This appears to be an Asterisk issue but I'm cc'ing discuss-webrtc >> because similar things have been discussed there too, please reply on >> asterisk-dev >> >> I've observed that calls are failing badly (appears to answer, no audio) >> when calling from Chrome to Asterisk and when my Asterisk server has >> three or more IP addresses. Looking in more detail, I notice that >> Chrome never finishes the ICE checks after the SDP offer/answer exchange. >> >> Caller: Chrome (tried M35, M37) >> Server: Asterisk on Debian, version 1:11.12.0~dfsg-1~bpo70+1
Just some other dependency versions: PJProject v2.1.0.0.ast20130823-1~bpo70+1 OpenSSL 1.0.1e-2+deb7u12 >> >> Simply removing the third IP address from the Asterisk box makes >> everything work. Adding a third IP address again it stops working >> again. Any more than three IP addresses and it is not working. >> >> Firefox can call Asterisk and it works OK even if there are three or >> more IP addresses >> >> I enable Chrome logging like this: >> >> chromium --enable-logging=stderr --v=4 > chrome-test.log 2>&1 >> >> and capture the packets with tcpdump for analysis with Wireshark. >> >> I've tried configuring the client both with and without a TURN server. >> It fails either way but the Chrome logs show slightly different errors. >> >> The Asterisk IP addresses are always public addresses. >> >> Here is what I observe in those scenarios where it fails: >> >> - Chrome sends binding request to the STUN server on port 3478 >> - Chrome receives "Binding Success Response XOR-MAPPED-ADDRESS" >> - Chrome receives SDP answer and starts ICE checking >> - Chrome sends authenticated STUN request to the Asterisk server's RTP >> port (e.g. 10214) >> - Asterisk sends back some media packets (from 10214 to Chrome's media port) >> - Chrome logs one of these messages: >> (if using TURN) "Received TURN data indication with invalid peer >> address, addr=......." >> (it no TURN server configured in client) "Received non-STUN packet >> from an unreadable connection." >> - After a few media packets, I notice Asterisk sends back "Binding >> Success Response" from 10214 in response to Chrome's ICE check >> - However, Chrome continues sending the STUN check packets, it doesn't >> seem to process the response from Asterisk >> - Asterisk never appears to send any ICE check (STUN) packets to Chrome >> >> The ICE engine in Chrome never gets past the "checking" state. >> >> When I look at the tcpdump output from the case where the Asterisk box >> has just two IP addresses, I notice that Asterisk is sending ICE checks >> to Chrome correctly. It doesn't send any of the checks in the scenario >> where there are three or more IP addresses on the Asterisk box. >> >> I came across some related discussions about similar issues in the past: >> >> https://issues.asterisk.org/jira/browse/ASTERISK-21383 >> https://reviewboard.asterisk.org/r/3454/ >> http://code.google.com/p/webrtc/issues/detail?id=2717 >> http://code.google.com/p/webrtc/issues/detail?id=1612 >> https://groups.google.com/d/topic/discuss-webrtc/GKtrfMir2sE/discussion >> >> Some of the related issues from the links above: >> - if peer(Asterisk) sends packets before the JavaScript gives Chrome the >> SDP answer, Chrome does not know whether to use regular ICE or Google ICE >> - timing issues/race conditions causing Asterisk to send media before it >> sends the response to the STUN check >> - does Asterisk give up trying to do ICE too soon and just start >> sending media? >> - does Chrome completely exclude the candidate when it receives the >> media frame before the STUN response packet? >> - Asterisk should be sending ICE checks to Chrome but it never sends any >> of them (this is what I observe in this test scenario) >> >> I had previously opened a Chrome bug about this type of problem but this >> latest analysis makes me feel it is an Asterisk fault. In any case, >> when I originally looked at this it was only a problem for DTLS-SRTP but >> it was fine with SDES (now deprecated though): >> http://code.google.com/p/chromium/issues/detail?id=341844 > > I created a trivial patch against res_rtp_asterisk.c to help get further > insight into this problem. > > After obtaining the list of local host candidate addresses, this sets > the size of the array to 1, thereby dropping all candidates except the > first. > > When I run it like this on a multi-homed box: > > - the SDP only contains the first IP address that was discovered > - the ICE setup completes successfully/problem described above does not > occur > > This is not a suitable patch for release but it is helpful for studying > the problem. As a workaround, maybe it would be possible to do one of > the following: > > - modify the code around this patch so that it only takes the candidate > matching the sip.conf media_address (if defined) and removes all others > from address[] > > - add some new sip.conf or rtp.conf parameter called > ice_candidate_whitelist with a list of permitted ICE candidates and then > use it to filter the contents of the address[] array in > rtp_add_candidates_to_ice > > A more comprehensive solution might be to fix the ICE implementation so > it works for large numbers of candidates but in practice people with > multi-homed boxes may not want to expose all their addresses and using > certain addresses in ICE may slow down the whole setup procedure. > > > > -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
