sepfy
commented
2 months ago Hi, could you try this branch first? thanks https://github.com/sepfy/libpeer/tree/turn
Open cy-jayasankar opened 2 months ago
sepfy
commented
2 months ago Hi, could you try this branch first? thanks https://github.com/sepfy/libpeer/tree/turn
cy-jayasankar
commented
2 months ago 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
cy-jayasankar
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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 timeturnal@outlook.com
sepfy
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
1 month ago @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
commented
1 month ago @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:
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
commented
3 weeks ago @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:
- Unknown Attribute Type: 0x8022
- 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
commented
3 weeks ago @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
commented
3 weeks ago @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.
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
Can you please provide details on how to run the sample with turn server configurations?