[asterisk-dev] [patch] ICE failure with Chrome, multi-homed Asterisk

[Daniel Pocock]

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
>
> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: res_rtp_asterisk.patch
Type: text/x-patch
Size: 377 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140922/c0f5d303/attachment-0001.bin>