Server-Side ICE Bug?


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.