libpeer sample not working with TURN

[cy-jayasankar]

hi,
I am trying to run libpeer sample examples/generic on Ubuntu. I could get the sample working when both the peers are connected to same network/router. But when two peers are connected to two different networks, sample is not working.

I have tried configuring turn server credentials in main.c file. Also downloaded https://sepfy.github.io/webrtc/?deviceId=12345 code locally and configured turn credentials in iceServers in the downloaded html file. But sample did not work.

Observation from wireshark logs on both the sides is as below

1. On machine where libpeer sample is running, I could see allocate success response with XOR-RELAYED-ADDRESS from TURN server.
2. On machine where the html file is running ** I don't see any STUN messages** going out to TURN server.
3. Finally sample fails before changing the state to connected from checking.

Can you please provide details on how to run the sample with turn server configurations?

[sepfy]

Hi, could you try this branch first? thanks
https://github.com/sepfy/libpeer/tree/turn

[cy-jayasankar]

Hi, thanks for your reply. I have tried with branch https://github.com/sepfy/libpeer/tree/turn but still I observe the same issue.

Following is the log

==================================================================================================
open https://sepfy.github.io/webrtc?deviceId=12345
INFO /home/test/njsa/libpeer-turn/libpeer/src/agent.c 37 create IPv4 UDP socket: 3
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/dtls_srtp.c 208 local fingerprint: 49:12:42:33:1A:22:E3:1A:3C:3B:3F:F4:7A:D3:CC:91:F8:F1:C0:7F:AA:1E:79:1A:D5:60:5E:02:91:24:E6:55
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_connection.c 191 Datachannel allocates heap size: 153600
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_connection.c 196 Audio allocates heap size: 332800
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_connection.c 207 Video allocates heap size: 332800
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 535 MQTT Host: broker.emqx.io, Port: 8883
INFO /home/test/njsa/libpeer-turn/libpeer/src/ports.c 164 Resolved broker.emqx.io -> 44.232.241.40
INFO /home/test/njsa/libpeer-turn/libpeer/src/socket.c 246 Connecting to server: 44.232.241.40:8883
INFO /home/test/njsa/libpeer-turn/libpeer/src/socket.c 252 Server is connected
INFO /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 85 start to handshake
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
ERROR /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 89 ssl handshake error: -0x7280
INFO /home/test/njsa/libpeer-turn/libpeer/src/ssl_transport.c 93 handshake success
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 368 MQTT_Connect succeeded.
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 401 MQTT Subscribe/Unsubscribe succeeded.
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 314 MQTT_PACKET_TYPE_SUBACK
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 309 MQTT_PACKET_TYPE_PUBLISH
state is changed: new
INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_connection.c 292 ice server: turn:global.relay.metered.ca:80?transport=tcp
INFO /home/test/njsa/libpeer-turn/libpeer/src/ports.c 164 Resolved global.relay.metered.ca -> 139.59.19.18
INFO /home/test/njsa/libpeer-turn/libpeer/src/agent.c 272 Resolved stun/turn server 139.59.19.18:80
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 278 Create turn addr
ERROR /home/test/njsa/libpeer-turn/libpeer/src/stun.c 197 Unknown Attribute Type: 0x0009
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 169 Nonce 2e13d18b3a0ffcef
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 164 Realm metered.ca
ERROR /home/test/njsa/libpeer-turn/libpeer/src/stun.c 197 Unknown Attribute Type: 0x8022
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 329 key: e407559a66e019aeda07b5be:metered.ca:dAdTiyXHd84DwEg1
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 174 XOR Relayed Address
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 100 XOR Mapped Address Family: 0x02
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 101 XOR Mapped Address Port: 35936
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 102 XOR Mapped Address Address: 139.59.19.18
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 100 XOR Mapped Address Family: 0x02
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 101 XOR Mapped Address Port: 56035
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/stun.c 102 XOR Mapped Address Address: 106.78.9.195
ERROR /home/test/njsa/libpeer-turn/libpeer/src/stun.c 197 Unknown Attribute Type: 0x8022
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 307 local description:
a=ice-ufrag:sbuQ
a=ice-pwd:sbuQcW0g1hKxj84O4vZJYyFs
a=candidate:1 1 UDP 2122554111 172.20.10.3 33690 typ host
a=candidate:2 1 UDP 9199871 139.59.19.18 35936 typ relay raddr 0.0.0.0 rport 0

DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 93 MQTT_Publish succeeded.

INFO /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 309 MQTT_PACKET_TYPE_PUBLISH
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_connection.c 499 SSRC: 1956909170
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 415 Set remote description:
v=0
o=- 9025134376447453311 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video audio datachannel
a=msid-semantic: WMS b12a3e42-b74b-4c78-abd4-628942f45788
m=video 64240 UDP/TLS/RTP/SAVPF 96 102
c=IN IP4 139.59.19.18
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3212732462 1 udp 2113937151 1104db0c-025b-4790-8f28-8d3e7ea38990.local 49666 typ host generation 0 network-cost 999
a=candidate:745507680 1 udp 2113939711 c34a73c6-235b-4949-b517-c3db984538f1.local 49667 typ host generation 0 network-cost 999
a=candidate:871938564 1 udp 16785407 139.59.19.18 64240 typ relay raddr 122.171.23.156 rport 11101 generation 0 network-cost 999
a=candidate:871938564 1 udp 16785407 139.59.19.18 41167 typ relay raddr 122.171.23.156 rport 5362 generation 0 network-cost 999
a=ice-ufrag:SQK7
a=ice-pwd:JMi0IHgFBv0tnmCuWFaz1AAQ
a=ice-options:trickle
a=fingerprint:sha-256 C8:FE:93:D7:DE:76:57:A8:FF:ED:EE:AB:A3:66:BE:10:AF:90:5A:D6:D7:24:F2:55:2D:D0:F4:B6:56:F0:C1:3A
a=setup:active
a=mid:video
a=recvonly
a=rtcp-mux
a=rtpmap:96 H264/90000
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:102 H264/90000
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
m=audio 9 UDP/TLS/RTP/SAVP 8
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:SQK7
a=ice-pwd:JMi0IHgFBv0tnmCuWFaz1AAQ
a=ice-options:trickle
a=fingerprint:sha-256 C8:FE:93:D7:DE:76:57:A8:FF:ED:EE:AB:A3:66:BE:10:AF:90:5A:D6:D7:24:F2:55:2D:D0:F4:B6:56:F0:C1:3A
a=setup:active
a=mid:audio
a=sendrecv
a=msid:b12a3e42-b74b-4c78-abd4-628942f45788 a6b95f50-f7ae-493d-97be-b61c50ae365e
a=rtcp-mux
a=rtpmap:8 PCMA/8000
a=ssrc:1956909170 cname:73VKAm5frzAV37d7
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:SQK7
a=ice-pwd:JMi0IHgFBv0tnmCuWFaz1AAQ
a=ice-options:trickle
a=fingerprint:sha-256 C8:FE:93:D7:DE:76:57:A8:FF:ED:EE:AB:A3:66:BE:10:AF:90:5A:D6:D7:24:F2:55:2D:D0:F4:B6:56:F0:C1:3A
a=setup:active
a=mid:datachannel
a=sctp-port:5000
a=max-message-size:262144

DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
INFO /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 167 Failed to resolve hostname
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 54 flag is not a DNS response
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 161 timeout
INFO /home/test/njsa/libpeer-turn/libpeer/src/mdns.c 167 Failed to resolve hostname
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 440 remote ufrag: SQK7
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 441 remote upwd: JMi0IHgFBv0tnmCuWFaz1AAQ
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 455 candidate pairs num: 4
state is changed: checking
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/peer_signaling.c 93 MQTT_Publish succeeded.
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 64240
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
DEBUG /home/test/njsa/libpeer-turn/libpeer/src/agent.c 475 send binding request to remote ip: 139.59.19.18, port: 41167
state is changed: failed

[cy-jayasankar]

hi,
From the debug logs and wireshark logs, observed that relayed transport address is being allocated to both the peers by TURN server. And both are sharing the candidate list( that includes relayed address) with each other. After this libpeer sample app is sending bind request but there is no response to the bind request.

Until now I have tried with two turn servers turn:turn.freeturn.net:3497 and turn:global.relay.metered.ca:80?transport=tcp. With both of these turn server I see the same behavior that relayed transport address is being allocated for both the peers but no response to the BIND request. Could you please suggest if this issues can be because of TURN server? also it would be great if you can share TURN server details with which libpeer sample app tested.

[topworldcoder]

hi, From the debug logs and wireshark logs, observed that relayed transport address is being allocated to both the peers by TURN server. And both are sharing the candidate list( that includes relayed address) with each other. After this libpeer sample app is sending bind request but there is no response to the bind request.

Until now I have tried with two turn servers turn:turn.freeturn.net:3497 and turn:global.relay.metered.ca:80?transport=tcp. With both of these turn server I see the same behavior that relayed transport address is being allocated for both the peers but no response to the BIND request. Could you please suggest if this issues can be because of TURN server? also it would be great if you can share TURN server details with which libpeer sample app tested.

Hi, what's the browser you used? I found firefox would occour the familiar error like 'ssl_handshake returned -0x7280'. You can try using google chrome. And there are some other scenes you may check out from issue #97

[cy-jayasankar]

hi, From the debug logs and wireshark logs, observed that relayed transport address is being allocated to both the peers by TURN server. And both are sharing the candidate list( that includes relayed address) with each other. After this libpeer sample app is sending bind request but there is no response to the bind request.
Until now I have tried with two turn servers turn:turn.freeturn.net:3497 and turn:global.relay.metered.ca:80?transport=tcp. With both of these turn server I see the same behavior that relayed transport address is being allocated for both the peers but no response to the BIND request. Could you please suggest if this issues can be because of TURN server? also it would be great if you can share TURN server details with which libpeer sample app tested.

Hi, what's the browser you used? I found firefox would occour the familiar error like 'ssl_handshake returned -0x7280'. You can try using google chrome. And there are some other scenes you may check out from issue #97

hi, I have used chrome. I don't see 'ssl_handshake returned -0x7280' error. Actual issue I see is no response after "send binding request to remote ip: 139.59.19.18, port: 64240"

[cy-jayasankar]

hi @topworldcoder,

I am trying the environment similar to the 2nd one that you have mentioned in
"libpeer is built and run on a linux machine independent of the STUN/TURN service, and web demo is on another Win PC:" and libpeer and WinPC are connected to different networks, and used a free TURN server from metered. Can you please provide us details of the TURN configurations that you have used. This would help us to rule out any issues related to the turn server that we are using.

Also, we have tried increasing the AGENT_POLL_TIMEOUT to wait for enough time to receive the binding response, But we see that BINDING response is not at all arriving, even we confirm this in wireshark log.

[topworldcoder]

hi @topworldcoder,

I am trying the environment similar to the 2nd one that you have mentioned in "libpeer is built and run on a linux machine independent of the STUN/TURN service, and web demo is on another Win PC:" and libpeer and WinPC are connected to different networks, and used a free TURN server from metered. Can you please provide us details of the TURN configurations that you have used. This would help us to rule out any issues related to the turn server that we are using.

Also, we have tried increasing the AGENT_POLL_TIMEOUT to wait for enough time to receive the binding response, But we see that BINDING response is not at all arriving, even we confirm this in wireshark log.

you can reply your email here, and I will send to you by [email protected]

[sepfy]

hello, In fact, I also tested TURN using metered, just like you, but I was able to connect successfully. I'm not sure if it could be a limitation of the router?

[zelzmz]

hi @topworldcoder,

I am trying the environment similar to the 2nd one that you have mentioned in "libpeer is built and run on a linux machine independent of the STUN/TURN service, and web demo is on another Win PC:" and libpeer and WinPC are connected to different networks, and used a free TURN server from metered. Can you please provide us details of the TURN configurations that you have used. This would help us to rule out any issues related to the turn server that we are using.

Also, we have tried increasing the AGENT_POLL_TIMEOUT to wait for enough time to receive the binding response, But we see that BINDING response is not at all arriving, even we confirm this in wireshark log.

hi @cy-jayasankar ,
I have also encountered the same problem. Have you solved it?
I ran the demo of ESP32, with the default configuration of stun: stun.l.google.com:19302, as seen by Wireshark

16172 48.050379 192.168.10.245 223.160.231.49 STUN 134 Binding Request user: EEGK: w7jA,

But the other end did not receive it.

[zelzmz]

hi @topworldcoder,
I am trying the environment similar to the 2nd one that you have mentioned in "libpeer is built and run on a linux machine independent of the STUN/TURN service, and web demo is on another Win PC:" and libpeer and WinPC are connected to different networks, and used a free TURN server from metered. Can you please provide us details of the TURN configurations that you have used. This would help us to rule out any issues related to the turn server that we are using.
Also, we have tried increasing the AGENT_POLL_TIMEOUT to wait for enough time to receive the binding response, But we see that BINDING response is not at all arriving, even we confirm this in wireshark log.

hi @cy-jayasankar , I have also encountered the same problem. Have you solved it? I ran the demo of ESP32, with the default configuration of stun: stun.l.google.com:19302, as seen by Wireshark

16172 48.050379 192.168.10.245 223.160.231.49 STUN 134 Binding Request user: EEGK: w7jA,

But the other end did not receive it.

Hi，@sepfy
I found that this is because the other end is connected to the 5G hotspot on my phone, and when I switched it to a router connection, there was no problem with binding.
But why is the video so laggy?
ESP32 printing: Failed to sendto: Not enough space
But the print I saw before was: webrtc: [APP] Free memory: 7922808 bytes
Why isn't such a large space enough? Can any configuration be changed?

[zelzmz]

@cy-jayasankar @sepfy @topworldcoder
Hi，Has the problem you encountered been resolved？
The coturn server I built also encountered the same problem as you.

I also have similar printing, but it doesn't seem to affect the generation of candidates.
Unknown Attribute Type: 0x8022

The final send binding request to remote IP did not respond.

[topworldcoder]

@zelzmz

Did you pull the latest code from libpeer? I have a good experence of it.
libpeer ignores handling some attributes type from turn as below:

1. Unknown Attribute Type: 0x8022
2. Unknown Attribute Type: 0x0009
   But that would not occour any problems.

You can also check function 'agent_connectivity_check' from agent.c and add some debug logs.
Mostly I want to advise you to do is add some logic or logs around 'agent_recv(agent, buf, sizeof(buf));' in function 'agent_connectivity_check'.

PS. you can refer to agent.c at my repository:
https://github.com/topworldcoder/libpeer

[zelzmz]

@zelzmz

Did you pull the latest code from libpeer? I have a good experence of it. libpeer ignores handling some attributes type from turn as below:

1. Unknown Attribute Type: 0x8022
2. Unknown Attribute Type: 0x0009
   But that would not occour any problems.

You can also check function 'agent_connectivity_check' from agent.c and add some debug logs. Mostly I want to advise you to do is add some logic or logs around 'agent_recv(agent, buf, sizeof(buf));' in function 'agent_connectivity_check'.

PS. you can refer to agent.c at my repository: https://github.com/topworldcoder/libpeer

Thank you very much for your suggestion. I will try debugging libpeer.
In fact, I have tried the code in your repository and it has the same effect. Perhaps there is a problem with my coturn configuration? I set up the server on Alibaba Cloud's ECS and tried using Trickle ICE. The results are as follows:

I'm not sure if there's something wrong with my coturn.

[topworldcoder]

@zelzmz You can visit Coturn's log to find the exact reason, which may be found in '/var/log'.
The code=701 displayed by the Trickle ICE web page is not a fatal error. relay result is done.

[zelzmz]

@zelzmz You can visit Coturn's log to find the exact reason, which may be found in '/var/log'. The code=701 displayed by the Trickle ICE web page is not a fatal error. relay result is done.

Thank you very much. After listening to your feedback, I tried to debug Coturn and it can now relay traffic normally.