Logs show username parameter not specified (realm <ring> user <>) and fail authentication

Support in English
1

I have noticed the below entries in my log file, I wonder why my Jami clients are not including the User (realm <ring> user <>) in messages causing an “error 401: Unauthorized” ?

Mar 02 13:10:09 files turnserver[662]: 530: : IPv4. tcp or tls connected to: 49.195.46.231:51156
Mar 02 13:10:09 files turnserver[662]: 530: : session 000000000000000001: realm <ring> user <>: incoming packet message processed, error 401: Unauthorized
Mar 02 13:10:09 files turnserver[662]: 530: : IPv4. tcp or tls connected to: 49.195.46.231:51157
Mar 02 13:10:09 files turnserver[662]: 530: : session 005000000000000003: realm <ring> user <>: incoming packet message processed, error 401: Unauthorized
Mar 02 13:10:09 files turnserver[662]: 530: : IPv4. Local relay addr: <IP of TURN server>:15941
Mar 02 13:10:09 files turnserver[662]: 530: : session 005000000000000003: new, realm=<ring>, username=<ring>, lifetime=600
Mar 02 13:10:09 files turnserver[662]: 530: : session 005000000000000003: realm <ring> user <ring>: incoming packet ALLOCATE processed,

I have also noticed this behaviour also from Trickle ICE, why at times do they send messages with the user missing while in other messages, they include both the realm and the username?

Mar 02 18:49:32 files turnserver[691]: 15820: : session 007000000000000001: delete: realm=<ring>, username=<ring>
Mar 02 18:49:32 files turnserver[691]: 17762: : session 005000000000000002: realm <ring> user <>: incoming packet message processed, error 401: Unauthorized

Mar 02 19:03:33 files turnserver[808]: 13: : session 005000000000000001: realm <ring> user <ring>: incoming packet ALLOCATE processed, success
Mar 02 19:03:33 files turnserver[808]: 13: : session 001000000000000001: realm <ring> user <>: incoming packet message processed, error 401: Unauthorized

Maybe this inconsistency is just how ICE protocol works things out?

2

Well it really does seem to just be how the “clear text UDP, send TURN Allocate requests” work !

With a bit more research this is the answer to my question:

https://www.rfc-editor.org/rfc/rfc8656
For clear text UDP, send TURN Allocate requests to both IP address families as discussed in
 [RFC8305] without authentication information. If the TURN server requires authentication, 
it will send back a 401 unauthenticated response; the TURN client will use the first UDP
 connection on which a 401 error response is received. If a 401 error response is received from
 both IP address families, then the TURN client can silently abandon the UDP connection on the IP
 address family with lower precedence. If the TURN server does not require authentication (as
 described in Section 9 of [RFC8155]), it is possible for both Allocate requests to succeed.

Using the above information I decided to test using a TLS encrypted Trickle ICE test:
turn:turn.mydomain.com.au:5349 [ring,ring]

I still noticed: “error 401: Unauthorized”

Mar 02 19:39:31 files turnserver[956]: 67: : session 000000000000000001: new, realm=<ring>, username=<ring>, lifetime=3600
Mar 02 19:39:31 files turnserver[956]: 67: : session 000000000000000001: realm <ring> user <ring>: incoming packet ALLOCATE processed, success
Mar 02 19:39:31 files turnserver[956]: 67: : session 006000000000000001: realm <ring> user <>: incoming packet message processed, error 401: Unauthorized