Comments (12)
paullouisageneau
commented on August 31, 2024
Hi,
First, the library is precisely designed to send WebRTC messages between native applications and web browsers, so you should definitely be able to achieve what you want!
You are right about the STUN protocol being used to map external addresses introduced by NAT (in your case, the connection is local, so a STUN server is not necessary), however it's only a part of it. STUN actually handles all the low-level stuff for connecting the two peers, for instance it handles also probing the addresses and checking the presence of the other peer.
The error you get means that the STUN user fragment (aka ufrag) was not validated properly between the peers when probing the connection. This is because you need to paste the entire description between peers, not only the fingerprint. This is the equivalent of calling PeerConnection.setRemoteDescription().
I'm interested if you have more information about the issues you had to build on MacOS.
from libdatachannel.
willm
commented on August 31, 2024
Thank you very much for your reply. I actually did try to paste the whole thing in before, but the program threw an error, maybe this is due to the formatting after pasting it in? should the whole address be on one line for example? See the output when I try this:
./datachannel
*************************************************************************
* 0: Exit / 1: Enter Description / 2: Enter Candidate / 3: Send Message *
[Command]: 1
[SDP]: v=0
o=- 2649305949 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:qqLr
a=ice-pwd:CPWhT3hG+9YDNCULzESSru
a=ice-options:trickle
a=mid:0
a=setup:actpass
a=dtls-id:1
a=fingerprint:sha-256 57:0A:9D:ED:53:15:AF:AB:69:15:76:64:D1:58:8C:B2:7B:BE:53:6D:6B:31:C6:01:C5:73:79:81:32:D8:9D:8B
a=sctp-port:5000
a=max-message-size:262144terminate called after throwing an instance of 'std::logic_error'
what(): Fingerprint must be set to generate an SDP string
Aborted
I created a separate issue for building on macos
from libdatachannel.
paullouisageneau
commented on August 31, 2024
Yes, it's a formatting issue in the console. The printed SDP description is supposed to have '^' instead of endlines for easier copy-pasting but strangely it's not the case here. I'm looking into it.
from libdatachannel.
paullouisageneau
commented on August 31, 2024
SDP reading from console should be fixed by 35d4455
I also took the occasion to clean up the tests a bit and rename datachannel executable to answerer for the sake of consistency, so don't be suprised.
from libdatachannel.
willm
commented on August 31, 2024
I tried this again running in my docker ubuntu version. I now get the following logs. keep alive's are sent regularly after that, but if I try option "3 Send Message", it tells me that ** Channel is not Open **
I guess Unable to set TLS priorities: No or insufficient priorities were set. is the reason for the failure?
[Gathering State: complete]
2
[Candidate]: a=candidate:1 1 UDP 2122317823 172.17.0.2 42634 typ host
***************************************************************************************
* 0: Exit / 1: Enter remote description / 2: Enter remote candidate / 3: Send message *
[Command]: 2020-02-24 18:53:05.634 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:408: STUN entry 0: Sending request
2020-02-24 18:53:05.634 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:771: Sending STUN binding request
2020-02-24 18:53:05.636 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:05.636 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:586: STUN entry 0 matching incoming transaction ID
2020-02-24 18:53:05.636 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:692: Received STUN binding success response from client
2020-02-24 18:53:05.636 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:710: Got a working pair
2020-02-24 18:53:05.636 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:453: New selected pair
2020-02-24 18:53:05.636 INFO [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:381: Changing state to connected
2020-02-24 18:53:05.637 DEBUG [24] [rtc::DtlsTransport::DtlsTransport@65] Initializing DTLS transport (GnuTLS)
2020-02-24 18:53:05.637 ERROR [24] [@48] Unable to set TLS priorities: No or insufficient priorities were set.
2020-02-24 18:53:05.638 WARN [24] [rtc::IceTransport::StateChangeCallback@199] Unable to set TLS priorities: No or insufficient priorities were set.
2020-02-24 18:53:05.638 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:05.638 WARN [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:539: STUN local ufrag check failed, expected="WHXW", actual=""
2020-02-24 18:53:05.638 ERROR [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:355: STUN message verification failed
2020-02-24 18:53:06.137 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:06.137 WARN [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:539: STUN local ufrag check failed, expected="WHXW", actual=""
2020-02-24 18:53:06.137 ERROR [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:355: STUN message verification failed
2020-02-24 18:53:07.140 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:07.140 WARN [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:539: STUN local ufrag check failed, expected="WHXW", actual=""
2020-02-24 18:53:07.140 ERROR [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:355: STUN message verification failed
2020-02-24 18:53:09.143 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:09.143 WARN [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:539: STUN local ufrag check failed, expected="WHXW", actual=""
2020-02-24 18:53:09.143 ERROR [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:355: STUN message verification failed
2020-02-24 18:53:13.147 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:353: Received a STUN message
2020-02-24 18:53:13.147 WARN [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:539: STUN local ufrag check failed, expected="WHXW", actual=""
2020-02-24 18:53:13.147 ERROR [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:355: STUN message verification failed
2020-02-24 18:53:21.126 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:403: STUN entry 0: Sending keepalive
2020-02-24 18:53:21.126 DEBUG [24] [rtc::IceTransport::LogCallback@253] juice: agent.c:771: Sending STUN binding indication
from libdatachannel.
paullouisageneau
commented on August 31, 2024
Yes, that's indeed the issue. It seems no or insufficient priorities were set means that no suitable TLS cipher suite is available, but it's obviously hiding another problem. What Ubuntu version do you run in the container?
It might be that your GnuTLS version requires explicitely NULL compression to be enabled, could you please try with 3c77d71 ?
If it still doesn't work, you might want to switch to OpenSSL with -DUSE_GNUTLS=0 temporarily while I investigate the issue.
from libdatachannel.
paullouisageneau
commented on August 31, 2024
Does 3c77d71 solves the problem for you?
from libdatachannel.
willm
commented on August 31, 2024
I'm using the latest ubuntu as a base container image (18.04).
I'm afraid that commit does not fix it, I get this message which repeats a few times:
2020-03-02 21:27:41.374 DEBUG [18] [rtc::DtlsTransport::DtlsTransport@65] Initializing DTLS transport (GnuTLS)
2020-03-02 21:27:41.375 DEBUG [18] [rtc::IceTransport::LogCallback@253] juice: agent.c:367: Received a STUN message
2020-03-02 21:27:41.375 WARN [18] [rtc::IceTransport::LogCallback@253] juice: agent.c:555: STUN local ufrag check failed, expected="IEoH", actual=""
2020-03-02 21:27:41.375 ERROR [18] [rtc::IceTransport::LogCallback@253] juice: agent.c:369: STUN message verification failed
then:
2020-03-02 21:28:43.384 ERROR [19] [@48] TLS handshake failed: The operation timed out
2020-03-02 21:28:43.388 ERROR [19] [rtc::DtlsTransport::runRecvLoop@167] DTLS handshake: TLS handshake failed: The operation timed out
from libdatachannel.
paullouisageneau
commented on August 31, 2024
That looks good actually, it seems GnuTLS starts as expected now!
The issue you are getting is now a non related signaling issue. It's because one side did not get the entire manifest somehow. It's at least missing the "ufrag" line, hence the error. Maybe a copy-paste mishap?
You can try to run the tests program. If it works, the build went well.
from libdatachannel.
willm
commented on August 31, 2024
Looks like the tests program runs fine. Maybe it's best for me to try and build my own application rather than continue trying to get the example to work in that case?
from libdatachannel.
paullouisageneau
commented on August 31, 2024
Great! Indeed, and you can use the tests program as a basic example of how to do the plumbing to pass the description and candidates.
from libdatachannel.
paullouisageneau
commented on August 31, 2024
I'm closing this since the GnuTLS issue is now fixed. Please open another one if you encounter a connection establishment problem while building your application.
from libdatachannel.
Related Issues (20)
- Websocket::Open crash HOT 3
- Error in build node-datachannel for webtorrent-cli HOT 2
- ABI issue when linking HOT 2
- RtpPacketizationConfig not properly initialized HOT 2
- setLocalDescription's Init parameter may not work. HOT 3
- The push function of the sendQueue in DataChannel will trigger wait and can not be awaked. HOT 3
- Client xxx not found HOT 2
- WebSocket::path() returns nullopt when state is Connecting HOT 2
- Mixed up dynamic and static libjuice dependencies HOT 1
- Source directory requires read/write filesystem during build HOT 3
- C API lacking proper closure support HOT 4
- Lost connectivity after successful connection HOT 7
- WebSocketServer not stopping properly HOT 2
- How to troubleshoot when the onGatheringStateChange function returns very slowly？ HOT 1
- Websocket disconnect HOT 2
- Trouble connecting via TURN server HOT 1
- Does libdatachannel support to compile in pure C Linux system(for some embedded device no support C++17)? HOT 3
- rtc::PeerConnection::close() causes the application to crash when called multiple times HOT 1
- Unable to retrieve negotiated media details HOT 2
- crash HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libdatachannel.