<div dir="ltr"><div>Thanks!<br></div><div>This issue doesn't bring troulbe (Just a warning on the console).<br><br></div>Seems that libjingle doesn't have the problem. I will try to find out how libjingle deal with server response.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-08 16:05 GMT+08:00 Youness Alaoui <span dir="ltr"><<a href="mailto:kakaroto@kakaroto.homelinux.net" target="_blank">kakaroto@kakaroto.homelinux.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This is a very old bug, and it's caused by the STUN server. I just added a /* FIXME */ in the code about it.<br>
</div><div><a href="https://github.com/tieto/libnice/commit/3727a574960a341e4a472567d3cdcf81d21681a3#diff-3f00c4bd712ae194ed79810bcb41210eR678" target="_blank">https://github.com/tieto/libnice/commit/3727a574960a341e4a472567d3cdcf81d21681a3#diff-3f00c4bd712ae194ed79810bcb41210eR678</a></div>
<div>Basically what happens is that the ICE specification says that we must send keepalives on the UDP sockets to keep the port open. If the connection is established, then we send a binding request on the connection which is fine, on reception, libnice will parse it and ignore it. In the case of a non-established connection (component is CONNECTING or CONNECTED state), then it can't do it, so it will keep the candidate alive by sending a STUN request to the server from which the server-reflexive candidate was discovered.</div>
<div>See section 4.1.1.4 of the ICE specification : <a href="http://tools.ietf.org/html/rfc5245#section-4.1.1.4" target="_blank">http://tools.ietf.org/html/rfc5245#section-4.1.1.4</a></div><div>The problem is that the STUN server only accepts RFC3489 STUN requests, and ICE uses RFC5389, so when the response is received by the STUN server, it cannot be parsed as a valid stun message, so libnice assumes it's application data and forwards it back to the application.</div>
<div>This was never a problem because when using RTP, the application will reject the stun as it validates the data it receives.</div><div>We would need to fix this either by using a binding indication (which does not generate a response from the server) but it would break the ICE RFC which says we must send a binding request, or by using RFC5389 to send the request, which will cause the server to ignore it or response with an error (which will probably still be in RFC3489 format, which won't solve the problem), or on reception, we would have a RFC3489 stun agent that we can use to parse those kinds of messages.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Youness.</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 30, 2014 at 12:41 PM, Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
This doesn't look right, and this packet indeed looks like a STUN<br>
packet. But any UDP based application should be ready to receive garbage<br>
packets and somehow validate its input, so it shouldn't matter.<br>
<br>
Olivier<br>
<div><div><br>
On Sun, 2014-03-30 at 22:40 +0800, Jianbin Kang wrote:<br>
> Hello, All<br>
><br>
><br>
> I used nice examples/simple-example.c to test ice, but found that<br>
> 'cb_nice_recv' was called both before and after<br>
> NICE_COMPONENT_STATE_READY.<br>
><br>
> I changed the function 'cb_nice_recv' to print the length of received<br>
> data, like this:<br>
><br>
> printf("****Recv(%u): %.*s", len, len, buf);<br>
><br>
><br>
> And during candidate allocating, cb_nice_recv was called with 32 bytes<br>
> of data:<br>
> cb_nice_recv(32):<br>
> 01 01 00 0c 7c f4 b8 25 a2 68 67 2a 87 fe 06 8f 59 3c 2f 2b 00 01<br>
> 00 08 00 01 40 04 3c 08 75 49<br>
><br>
><br>
><br>
> After state ready, cb_nice_recv was called with the another 32 bytes.<br>
> The first four bytes was same (01 01 00 0c)<br>
><br>
><br>
> The stun server I used was: <a href="http://stun.l.google.com:19302" target="_blank">stun.l.google.com:19302</a><br>
><br>
> <a href="http://stunserver.org" target="_blank">stunserver.org</a> has the same problem too, but the length of data was 88<br>
> bytes.<br>
><br>
><br>
> Is this a bug or just something I misunderstand?<br>
><br>
> Thanks<br>
><br>
> Jianbin<br>
><br>
</div></div>> _______________________________________________<br>
> nice mailing list<br>
> <a href="mailto:nice@lists.freedesktop.org" target="_blank">nice@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
<span><font color="#888888"><br>
--<br>
Olivier Crête<br>
<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a><br>
<br>
_______________________________________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org" target="_blank">nice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>