So I have seen this asked a few times here only to be put down and essentially not really given any assistance. It would appear none of those people solved their issues.
There does not appear to be any guides that really go through the whole process of making this work on the entire internet, which is probably why there really isn't any apps taking advantage of these possibly powerful features.
I followed every guide I could, I am at about 30 hours of reading and trying to make a signaling server work here. I created my username nad password and I confirmed it is in the sqlite database... but it does not work
101: handle_udp_packet: New UDP endpoint: local addr 172.31.9.100:3478, remote addr 75.84.148.45:52208
101: session 001000000000000001: realm <dashos.net> user <>: incoming packet BINDING processed, success
101: handle_udp_packet: New UDP endpoint: local addr 172.31.9.100:3478, remote addr 75.84.148.45:52913
101: session 000000000000000001: realm <dashos.net> user <>: incoming packet BINDING processed, success
101: session 001000000000000001: realm <dashos.net> user <>: incoming packet message processed, error 401: Unauthorized
101: session 000000000000000001: realm <dashos.net> user <>: incoming packet message processed, error 401: Unauthorized
102: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
102: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
102: session 000000000000000001: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
102: session 001000000000000001: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
ubuntu:~/turnserver/examples$ turnadmin -l
dash-p2p[dashos.net]
I confirmed 100 times literally that the password I entered and use is what I am using when contacting the server.
The common response is "this is not about webrtc" but every test I have tried (including by using the included client) returns unauthorized for this user.
Is there some formatting that needs to be done ? Do i not actually use the username/password that i created but instead some other form of username / password?
This library is awesome - i love how it is so complete and matches the RFC's out there. Truly do appreciate the collaborators work on this!
Would be really really nice to have a guide that goes through how it all actually works / comes together. The examples are nice but something higher level would be hugely beneficial (a "getting started" guide).
I do plan to bring this all together into a nice guide / article once I can figure out how these things come together.
On that note, I do recognize that this is user error and I am missing some piece which also may be documented somewhere. I guess I just can't find it or keep missing a critical piece to make this all come together!
I really can't believe there is almost zero documentation for getting this all working across the web after years though! Everything seems to be "ok well here is how you do it once you are connected" and essentially make the real obstacles mysterious.
Note: I have noticed some references about the REST API and how the username needs to be reformatted to be a mix of the key and username with timestamp and other various formatting. I can not, however, find any reference as-to when and how that actually is used.
Here is the response if I use the turnutils_uclient with the given username and password (which again I confirmed is correct on both ends)
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
5218: session 000000000000000015: realm <dashos.net> user <dash-p2p>: incoming packet message processed, error 401: Unauthorized
5218: ERROR: check_stun_auth: Cannot find credentials of user <dash-p2p>
Update: Ok finally got this working. I think having all these auth processes without any information as-to what they are for is causing a lot of confusion out there. I have found about 6 different places people have asked about it without replies.
Finally I found a cached website (tried to find the url but had already closed it, sorry) which had a comment that solved the issue.
My understanding of this whole thing was that the REST API is on top of and in parallel to the standard mechanism. Now it appears that you can use the REST >OR< others? May be wrong there. I had just thought the REST would be there with a "shared secret" to authenticate when eneded.
Anyway - the solution was to remove shared secrets from the config and turnadmin. Once I did this things worked.
It would be a very good idea to document this and to throw errors if the configuration produces a system that breaks all functionality of the server.
It is still not working completely but I am at least making progress.
I do hope this helps others as they run through the steps here!
thank you, that's helpful to me
So...
RFC terminology = coTURN terminology
You can't use both in the same time, because collision in username space.
Read RFC-s a and drafts.
Or see in nutshell the differences:
I have added already a warning alert about it in the latest source.
See commit: https://github.com/coturn/coturn/commit/44c448e8e93539305be34e7e1ae597360c4ebf53
Anyhow any help regarding improving the documentation will be highly appreciated!
Please open other issue or reopen it if I could help you more.. & Sorry for the delayed answer..
Thanks..
Misi
For anyone having similar problem
In my case coturn config was correct and even after many restarts, it could not auth any user. It turned out that client apps (riot) needed to be restarted.
Most helpful comment
Update: Ok finally got this working. I think having all these auth processes without any information as-to what they are for is causing a lot of confusion out there. I have found about 6 different places people have asked about it without replies.
Finally I found a cached website (tried to find the url but had already closed it, sorry) which had a comment that solved the issue.
My understanding of this whole thing was that the REST API is on top of and in parallel to the standard mechanism. Now it appears that you can use the REST >OR< others? May be wrong there. I had just thought the REST would be there with a "shared secret" to authenticate when eneded.
Anyway - the solution was to remove shared secrets from the config and turnadmin. Once I did this things worked.
It would be a very good idea to document this and to throw errors if the configuration produces a system that breaks all functionality of the server.
It is still not working completely but I am at least making progress.
I do hope this helps others as they run through the steps here!