UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36

Steps to reproduce the problem:
1. coturn (Coturn-4.5.0.2 'dan Eider') stun/turn server
2. enable stun auth "secure-stun"
3. use stun username and password credential in PeerConnection iceServers config option that is used with turn

Chrome do not send after the 401 auth challenge any new binding request with the LTC credential.

What is the expected behavior?
Send a new binding request after 401 with credentials (username, nonce, message integrity, etc.)
Work the same way as TURN LTC is implemented.

Work according STUN RFC5389 describes the binding with Long Term Credential(LTC) auth mechanism. 

For quick fix: Add a warning for developer that it is not yet implemented.

What went wrong?
I experience these messages in debug log:

[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1 reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1 reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1 reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1 reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1 reason='Unauthorized'

I have checked in source, but I couldn't find the implementation of handling of this 401 auth challenge messages in stunport.cc.

Did this work before? No 

Chrome version: 50.0.2661.86  Channel: stable
OS Version: 50.0.2661.86
Flash Version: Shockwave Flash 21.0 r0

Why stun auth

Pros:
 *  The STUN RFC gives the possibility to use authenticated STUN. 
 *  In coTURN there is an implementation, so people will try to use it in this way. 
 *  It would be nice to have at least a Warning for devs, that STUN&LTC auth is not yet supported.
 *  I would like to provide STUN service to a closed group. And indicate that I do not provide to everyone. So stun auth is filter.
 *  Avoid crawling bots what look for open stun service, and then advertise it an open stun, and adding extra unpredictable load on the service through this way.
 *  TURN is an extension STUN protocol, so I would like to use uniform way the STUN auth like TURN. And it is confusing that it is not implemented.
 *  coTURN is giving out sw VERSION information by default, if I use a patched coTURN that gives out empty Version information in error e.g. 401 Challenge, then I could defend and not expose the exact STUN/TURN version, and keep this information to only for the users who are authenticated. STUN/TURN version information may could help to find exploit and attack the service.
 *  STUN server with RFC5780 support according NAT behavior discovery STUN gives the possibility for the attacker to detect secondary IP address from the OTHER_ADDRESS attribute. With STUN auth this information could also protected and expose to only for a closed group.