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
Add support for FQDN ICE candidates in addition to the already supported IP candidates.
Motivation
FQDN candidates are a valid option as per the RFC, and they are supported in other major WebRTC implementations (such as browser ones).
This feature will allow the users to use Pion to connect to peers that only expose FQDN candidates, which is somewhat tricky to achieve without direct library support.
Describe alternatives you've considered
A hypothetical alternative would be to post-process incoming ICE candidates, resolving any FQDNs to concrete IP addresses on the client side before passing them to the library. That adds implementation overhead to the user, and requires them to know the implementation details of the WebRTC stack instead of just using the library as a black box.
Summary
Add support for FQDN ICE candidates in addition to the already supported IP candidates.
Motivation
FQDN candidates are a valid option as per the RFC, and they are supported in other major WebRTC implementations (such as browser ones).
This feature will allow the users to use Pion to connect to peers that only expose FQDN candidates, which is somewhat tricky to achieve without direct library support.
Describe alternatives you've considered
A hypothetical alternative would be to post-process incoming ICE candidates, resolving any FQDNs to concrete IP addresses on the client side before passing them to the library. That adds implementation overhead to the user, and requires them to know the implementation details of the WebRTC stack instead of just using the library as a black box.
Additional context
@Sean-Der mentioned in the Slack channel that this feature has potential privacy implications.
The text was updated successfully, but these errors were encountered: