Incomplete ice-candidate
#1065
Replies: 9 comments 30 replies
-
|
How do you retrieve the candidates generated by libdatachannel? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi, after manny hours testing I have meet several issues. I will try to explain here with some logs. I wil set here my configuration and steps I take to perform succesiful datachannel connection. Let see my initial configuration first Configuration set for PeerConnection: rtc::Configuration config;
config.iceServers.emplace_back(std::string("stun.xxxx.io"),3478);
config.iceServers[0].type=rtc::IceServer::Type::Stun;
config.enableIceUdpMux=true;Configuration set for Datachannel rtc::DataChannelInit data_channel_config;
data_channel_config.reliability.unordered=true;
data_channel_config.reliability.maxRetransmits=3;
data_channel_config.negotiated=true;
data_channel_config.protocol="udp";When caller starts to communicate with calee, sends offer taking this steps:
Calee point of view
Caller point of view
Note1- peer1 (caller or calee) use libdatachannel C++ app<----------------> peer2(caller or calee) use webrtc javascript app Note2- Caller and calle are state of peers. As I said earlier i make test with two peers. First peer is called celler or calee in some point depend on test is libdatachannel C++ program. Other peer caller or calle depend on test is webrtc javasript application: I have met several issues using FireFox and Chrome as peer2 (caller/calee) javascript app. Peers are behind NAT not symetrical. First log is success log(extremly rare) between libdatachannel c++ app and Chrome javascript webrtc app. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Thanks for the details.
You don't need to override the type, an ICE server URL without an explicit protocol defaults to STUN.
This doesn't do what you think it does. It allows you to set the sub-protocol used by the application on this datachannel, and it has nothing to do with the underlying UDP protocol (see the WebRTC API doc).
Same, this is used to negotiate the datachannel id out-of-band through application signaling (see the WebRTC API doc), setting it while you don't set the id yourself makes no sense and will typically fail to create the datachannel. You shouldn't set parameters at random otherwise it won't work as you expect, defaults are good for most use cases.
No, you must not call
You shouldn't try to do something smart and filter candidates yourself, the ICE protocol takes care of everything for you. For instance, IPv6 host candidates should not be filtered even if they are not server reflexive.
Why would you set
The failed case looks like the answer was not set properly on the remote peer. You should check your signaling implementation, there could be a race condition or some similar issue. You might also want to look at the client and web examples.
It looks like libdatachannel generates a server reflexive candidate with your router's public address and calls |
Beta Was this translation helpful? Give feedback.
-
|
"It looks like libdatachannel generates a server reflexive candidate with your router's public address and calls onLocalCandidate() with it, so I assume the issue you reported in the top post is actually not present." |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your help. I will correct with suggestions you provide!!! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
So I have set changes your suggest, but the problem with Chrome and FF remains. I mean with FF almost 100% connection is done via my C++ app using libdatachannel and webrtc using javascript app, but with Chrome 99% is oposite- connection creation is verry rare between peers under same conditions for Chrome and FF. Can you help me with something? 10x!! |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Do the client and web examples connect? |
Beta Was this translation helpful? Give feedback.
-
|
Wait, I am not trying this. Ok I will and let you know. 10x. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Ok, my test case is like this: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Ok, I have new information about Chrome and FF connection. When I add 200ms delay in function where process Ice candidates before peerConn->addRemoteCandidate(candidate) conn is done in Chrome. Why is that?10x for your time! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Can you check this fragment of code located in https://github.com/paullouisageneau/libdatachannel/blob/master/src/impl/peerconnection.cpp#L1076 if (auto iceTransport = weakIceTransport.lock()) |
Beta Was this translation helpful? Give feedback.
1 reply
-
Those two lines are equivalent. |
Beta Was this translation helpful? Give feedback.
-
Sorry I wasn't clear, I meant trying the web example with the client example, just to rule out an issue with Chrome.
This very probably means that there is a race condition in your signaling code. |
Beta Was this translation helpful? Give feedback.
26 replies
-
There is no relationship between the
You need to call
It means |
Beta Was this translation helpful? Give feedback.
-
|
Merry Christmas and best wishes to you and your family. 10x for your response. I fixed all above issues and everything works fine. Yes. I made some performance and speed tests which included a very large number of peer and data channel connections. I start from 10, 20, 50, 100, 500 and 1000 and up. Because of natural using of my C++ app with libwebrtc I have clients(peers) using javascript app for peercon. Just to explain my main option/target is to replace old libwebrtc because I already stopped upgrading it to version 101 because in 102 and up they discard usrsctp lib and replacing it with their implementation transport lib. But with respect to this issues starts to happen with high load of CPU only for few datachann connections. You see I just changed lib to version v.102..120 wahever, nothing else and high CPU load rise immediately. So I found your lib and everything starts from here. OK, returning to tests. For a certain point there is nothing special and interestnig- peers starts form 10, 20, 30 threads goes up, queries goes up and more and more. To make it clear- one app using datachannel process many peers. Going to 50/60 peers queries and repsonse from C++ app goes to slow, 100 peers more slowly, 500 and 1000 make it imposiible to comunicate because I use rtt to track request/response situation and made some decisions. My question is do you need some test calculations or test times of queries or something to made your tests to see where is the problem? |
Beta Was this translation helpful? Give feedback.
-
|
Are you testing across a network? If you blindly send over reliable data channels at a total rate higher than what the network path can transfer, data to send will be buffered, increasing the RTT more and more. It's expected behavior and not a performance issue. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I send across a network of course. Channels are not reliable, network path and MTU is diff for all nets. More interesting is that tests are made in same environment and same nets(peers are in diff nets but still same) with libwebrtc and libdatachannel. |
Beta Was this translation helpful? Give feedback.
-
|
Different nets or not, the point is that if a peer sends faster than what can be transmitted across the network, it's going to buffer data that can't be sent immediately and increase RTT as a result (the limitation can be on sender side or receiver side). How many other peers does a peer sends to and receives from? What is the average rate? By "not reliable", do you mean |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have wonder why candidates doesn not include srflx raddr of mine? For example I have ipv4 inner address and ipv6 inner address, but I have ipv4 and ipv6 real address bound to my Router interface for NAT. My configuration is:
rtc::Configuration config;
config.enableIceUdpMux = true;
config.iceServers.emplace_back(std::string("stun:stun.l.google.com:19302"));
config.certificateType=rtc::CertificateType::Default;
config.iceServers[0].type=rtc::IceServer::Type::Stun;
This is ice candidates generated from libdatachannel:
My ice candidate generated by libdatachannel
This is other side peer ice candidates generated by chrome
X.X.X.X is my realIP
And finally I cannot open a datachannel remotly (peer->INternet->peer)? But if I run all this locally the datachannel is open (peer->localNet->peer)
Beta Was this translation helpful? Give feedback.
All reactions