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

[Daniel Pocock]

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