Default Ice Servers Configuration #1095
-
SummaryA Python implementation of WebRTC, aiortc, includes "stun:stun.l.google.com:19302" as part of its default ice servers list. libdatachannel doesn't, and this caused some issues on my end. I was wondering if this was an issue on my end (i.e. the TURN server configuration), or a detail that could be clarified through examples or documentation. DetailsI wrote a Python WebRTC application using aiortc and attempted to port it to C++ using libdatachannel. I believe I got everything setup as similarly as I could, but the C++ application would fail to connect when the client was on a separate network. I was using a TURN server that was working with the Python API. I figured out that the Python library was appending Google's stun server by default if no ice servers were defined, which allowed my application to work. In libdatachannel, this would look like rtc::Configuration config;
configuration.iceServers.push_back(rtc::IceServer("stun:stun.l.google.com:19302"));
rtc::PeerConnection pc{config};I'm not sure what additional information would be most hopeful, so I attached debug logs of both instances. P.S.When running this same app on a different device, I suddenly encountered "Send failed, datagram is too large" errors, usually when sending packets of size 1410. But when I switched from libjuice to libnice, it seemed to go away? Could there be any explanation for this? Let me know if I should move this message to the libjuice discussion board respectively. LogsBad result: candidate pair check fails. good result: default Google STUN server was added |
Beta Was this translation helpful? Give feedback.
Answered by
paullouisageneau
Jan 19, 2024
Replies: 1 comment 1 reply
-
|
This is expected, you need a STUN server on both sides to ensure NAT traversal works as expected if both peers are behind a NAT. Irrelevant of the aiortc decision, I think hardcoding the Google STUN server by default is actually a bad idea:
For anything other than tests, you should deploy your own STUN server.
The maximum packet size you can send depends on the Maximum Transmission Unit of the network path. To be sure it works everywhere, you should reduce the MTU on the RTP packetizer to something like 1200 (look at the media sender gst-launch command for instance). |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Your explanations make sense, thank you for clarifying! 🙏 |
Beta Was this translation helpful? Give feedback.
Answer selected by
ap0nia
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is expected, you need a STUN server on both sides to ensure NAT traversal works as expected if both peers are behind a NAT.
Irrelevant of the aiortc decision, I think hardcoding the Google STUN server by default is actually a bad idea:
For anything other than tests, you should d…