search

sepfy / libpeer

WebRTC Library for IoT/Embedded Device using C
MIT License
852 stars 126 forks source link

libpeer sample not working with TURN #101

Open cy-jayasankar opened 2 weeks ago

cy-jayasankar commented 2 weeks ago

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 commented 2 weeks ago

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

cy-jayasankar commented 2 weeks 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

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 commented 2 weeks 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 weeks 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 weeks 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"

topworldcoder commented 2 weeks 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"

Does it matchs the sense I mentioned in issue 97? I config STUN/TURN and libpeer to run in the same machine, and have the same result of no response after "send binding..."

topworldcoder commented 2 weeks ago

Besides, you can try add some logic like I tested for delay receive in function 'agent_connectivity_check'( It maybe helpful for some cases ): //////////////////////////////////////////////// int agent_connectivity_check(Agent* agent) { codes ................... int retry = 0; int ret = 0; while (++retry < 60) { ret = agent_recv(agent, buf, sizeof(buf)); if (ret > 0) { break; } } codes .................... } ////////////////////////////////////////////////

and modify function agent_recv: /////////////////////////////////////////////////////////////////////////////// int agent_recv(Agent agent, uint8_t buf, int len) { int ret = -1; StunMessage stun_msg; Address addr; if ((ret = agent_socket_recv(agent, &addr, buf, len)) > 0) { if (stun_probe(buf, len) != 0) { return ret; }

    memcpy(stun_msg.buf, buf, ret);
    stun_msg.size = ret;
    stun_parse_msg_buf(&stun_msg);
    switch (stun_msg.stunclass) {
    case STUN_CLASS_REQUEST:
        LOGD("agent_recv STUN_CLASS_REQUEST");
        agent_process_stun_request(agent, &stun_msg, &addr);
        break;
    case STUN_CLASS_RESPONSE:
        LOGD("agent_recv STUN_CLASS_RESPONSE");
        agent_process_stun_response(agent, &stun_msg);
        break;
    case STUN_CLASS_ERROR:
        LOGD("agent_recv STUN_CLASS_ERROR");
        break;
    default:
        LOGD("agent_recv %d", stun_msg.stunclass);
        break;
    }
}
return ret;

} ///////////////////////////////////////////////////////////////////////////////

topworldcoder commented 2 weeks ago

agent_recv STUN_CLASS_RESPONSE

when you got log 'agent_recv STUN_CLASS_RESPONSE', it means send binding success!

cy-jayasankar commented 2 weeks 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 weeks 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 weeks 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 1 week 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 1 week 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?

topworldcoder commented 1 week 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, may be you can try the repository that I fork from sepfy, I commited some codes which seems to work better for me.

git clone --recursive https://github.com/topworldcoder/libpeer.git