I actually also only got it from the guide/discussion here: Complete NC installation on Debian with Spreed.me and TURN step by step
Also only understood half at that time and still do 
. Maybe later I will use some time to check out these settings.
Also I am not sure if maybe the one or the other could be left out, didn’t try so far.
€: https://github.com/coturn/coturn/wiki/turnserver
There they explain the options, but my knowledge is too low to understand all of them:
-
fingerprint Use fingerprints in the TURN messages. If an incoming request contains fingerprint, then TURN server will always add fingerprints to the messages in this session, regardless of the per-server setting.
What is meant by “TURN messages”, all WebRTC traffic passing the TURN server, or just the initial one? And who/what checks the fingerprint and what would be the consequence if there is no match? €: After going forward through the options I guess it’s all about the authentication on the TURN server. -
lt-cred-mech Use long-term credentials mechanism (this one you need for WebRTC usage).
http://stackoverflow.com/questions/26110412/is-long-term-credentials-authentication-mechanism-required-for-webrtc-to-wor here some more information about this. Seems to be necessary to stay authenticated on the TURN server during WebRTC session. -
total-quota Total allocations quota: global limit on concurrent allocations.
Seems to be the maximum number of connections and therefore parallel WebRTC users on your server. Sadly they don’t say something about the default value of this. -
bps-capacity Maximum server capacity. Total bytes-per-second bandwidth the TURN server is allowed to allocate for the sessions, combined (input and output network streams are treated separately).
Bandwidth for the TURN server and therefore WebTRC sessions. I guesss “0” means that there is no limitation. - In subsequent communications, the client may go with exactly the same sequence, but for optimization usually the client, having already information about realm and nonce, pre-calculates the integrity string for each request, so that the 401 error response becomes unnecessary. The TURN server may use “–stale-nonce” option for extra security: in some time, the nonce expires and the client will obtain 438 error response with the new nonce, and the client will have to start using the new nonce.
I needed to read some more about what a nonce is: https://en.wikipedia.org/wiki/Cryptographic_nonce
So it’s some security feature against reply attacks. -
no-loopback-peers Disallow peers on the loopback addresses (127.x.x.x and ::1).
no-multicast-peers Disallow peers on well-known broadcast addresses (224.0.0.0 and above, and FFXX:*).
Seems to be reasonable to block there adresses, how ever a successful TURN request through these could happen: https://en.wikipedia.org/wiki/Multicast
At least I got an idea about what all this is about. I am missing default values there, especially as some of the options seem necessary or at least very reasonable I would expect them to be default.