You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am contacting you in regard with any ideas and advices from your side due to the reason that recently our team has issues with our own developed software and the situation is very critical:
1. We use libwebrtc 101, as we have deliberately compiled the library this way
(fragment from webrtc.gni)
declare_args() {
# Enable the dcsctp backend for DataChannels and related unittests
rtc_build_dcsctp = false
# Enable the usrsctp backend for DataChannels and related unittests
rtc_build_usrsctp = true<--------------------------
We chose this because if it is rtc_build_dcsctp = true, we get a large CPU throtling and load.
# Enable gRPC used for negotiation in multiprocess tests
rtc_enable_grpc = false
}
2. We use only datachannel through which we pass a stream around 2-4Mb / s maybe more.
3. We split / divide the stream into 8K packets and transmit them via data_channel->Send(webrtc::DataBuffer(rtc::CopyOnWriteBuffer(buf.data(),buf.size()),true)) to application stack
The issue does not always become apparent. What I want to say is that if you successfully build a peer-to-peer connection and open the data channel in SOME Wireless environments / networks, data transmission/transfer is very difficult and almost impossible due to this issue we have. However, not all Wireless networks are so, only some do not know how to get there. Just for information - in the test we do we use the same router that gives bad results with WiFi connection, and in LAN NIC 100/1000 Mb the result is successful and do not rush this issue. We have been trying different webrtc fine tunnings for a month now and we have not made any progress. The application simply pushes enough data to its peers to be able to play the stream. And the strangest thing is that it appears ONLY when using WiFi network card in some peers, and in others not. Based on the application logic of our program and ignoring it, respectively, the next level that worries us and we do not have much information about it is sctp protocol- a which webrtc uses implemented by you. There are probably some settings that we can change compile time to meet the needs of these "specific / special" wireless cases.
Any help and advices form yours side will be useful to us.
Thanks and regards,
Peter
The text was updated successfully, but these errors were encountered:
Dear sctplab team,
I am contacting you in regard with any ideas and advices from your side due to the reason that recently our team has issues with our own developed software and the situation is very critical:
(fragment from webrtc.gni)
We chose this because if it is rtc_build_dcsctp = true, we get a large CPU throtling and load.
The issue does not always become apparent. What I want to say is that if you successfully build a peer-to-peer connection and open the data channel in SOME Wireless environments / networks, data transmission/transfer is very difficult and almost impossible due to this issue we have. However, not all Wireless networks are so, only some do not know how to get there. Just for information - in the test we do we use the same router that gives bad results with WiFi connection, and in LAN NIC 100/1000 Mb the result is successful and do not rush this issue. We have been trying different webrtc fine tunnings for a month now and we have not made any progress. The application simply pushes enough data to its peers to be able to play the stream. And the strangest thing is that it appears ONLY when using WiFi network card in some peers, and in others not. Based on the application logic of our program and ignoring it, respectively, the next level that worries us and we do not have much information about it is sctp protocol- a which webrtc uses implemented by you. There are probably some settings that we can change compile time to meet the needs of these "specific / special" wireless cases.
Any help and advices form yours side will be useful to us.
Thanks and regards,
Peter
The text was updated successfully, but these errors were encountered: