Everyone,
I’ve been investigating what looks like a problem with ICE negotiation
between the browser and server. I’m running Chrome and Licode on EC2.
Here’s what I’m seeing:
- Browser on laptop successfully gathers candidates and sends offer which
includes a public IP+port (whether using either our STUN server running on
same machine as Licode or Google’s public STUN server). - Licode server
sees offer and finds one valid ICE candidate - Browser receives answer with
good public IP from Licode server. - All other signaling happens as usual -
Browser shows black box for any remote streams - tcpdump on laptop shoes
UDP packets coming in, but on a different local port than the one sent in
the ICE candidate in the offer - tcpdump on licode server shoes UDP packets
going out to the correct public IP, but also on a different port. - So the
server is using a different endpoint for some reason. Possibly it’s just
using the origin ip/port in the packets it receives from the browser (where
else would it come up with those ports if not in the ice candidates list?). - The endpoint supplied in the offer from the client works – I can send
test packets to that public IP/port and my laptop sees them. But I can’t
send from just any origin port – only the same port that was established
in the STUN request (which you can find in /var/logs/turn*), or one of the
ports the licode server is sending to (which must be an origin port from
packets it received if this is port-restricted cone or symmetric NAT). - I
think Chrome is ignoring packets that don’t come in on one of the endpoints
sent in the offer.