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

[Daniel Pocock]

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