[libnice] ICE re-start issue with libNice

Rajarshi Chaudhuri rajarshi.chaudhuri at genesys.com
Fri May 9 20:00:06 PDT 2014

Hi -

We are using libNice for our WebRTC Gateway. We just added support for ICE restart and running into issue with WebRTC enabled browsers like Chrome.  In the problem case the remote peer (Chrome) is the one initiating the ICE restart.

After we call nice_agent_restart(),  and send the answer SDP to Chrome, we start ICE by setting remote credentials and candidates. And before Chrome has received and processed the SDP, the STUN binding requests are sent by libNice are received by Chrome and gets rejected, as shown in chrome debug log below (due to ufrag/pwd change):
[6948:12472:0509/173558:VERBOSE1:port.cc(1010)] Jingle:Conn[audio:HCmebYA2:1:1:local:udp:>:1:0:local:udp:|C--W|-]: Received STUN request with bad remote username oIYa
[6948:12472:0509/173558:VERBOSE3:port.cc(690)] Jingle:Port[audio:1:1::Net[{64B2D6F7-CCC1-4665-AB07-D9F552B5C4B8}:]]: Sending STUN binding error: reason=Unauthorized to

But this problem goes away after the SDP is processed by Chrome, and there are no more such errors.  However, the STUN binding requests are rejected now by libnice, as reported in Chrome debug log, as shown below.
[6948:12472:0509/173558:VERBOSE1:port.cc(422)] Jingle:Port[audio:1:1::Net[{64B2D6F7-CCC1-4665-AB07-D9F552B5C4B8}:]]: Received STUN binding error: class=4 number=1 reason='Unauthorized' from

This problem, however, does not recover, and we receive the  NICE_COMPONENT_STATE_FAILED error from libNice within 50ms. We tried starting ICE again by setting remote credentials and candidates again, then the nice agent goes to  NICE_COMPONENT_STATE_CONNECTED state, but does not go to ready state.  On the Chrome side, it keeps complaining about receiving STUN binding error.

The version of libNice we are using (on Windows) is 0.1.3.  Do you have any idea what is happening?  For instance, is it possible that the nice agent goes into a bad/failed state due to the binding errors received from Chrome (only for a short time, and definitely less than 1 second)?  Is there anything that we could do something to avoid this issue?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140510/60f9547d/attachment.html>

More information about the nice mailing list