# Server-Side ICE Bug?

**URL:** <https://discourse.lynckia.com/t/server-side-ice-bug/128>\
**Category:** Uncategorized\
**Created:** [February 25, 2014, 4:32pm UTC](https://discourse.lynckia.com/t/server-side-ice-bug/128 "2014-02-25T16:32:58Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jonathan\_Warden](https://avatars.discourse-cdn.com/v4/letter/j/ac8455/32.png) [@Jonathan\_Warden](https://discourse.lynckia.com/u/Jonathan_Warden)\
**Post date:** [February 25, 2014, 4:32pm UTC](https://discourse.lynckia.com/t/server-side-ice-bug/128/1 "2014-02-25T16:32:58Z")

</div>

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.