amazon-kinesis-video-streams-webrtc-sdk-c
amazon-kinesis-video-streams-webrtc-sdk-c copied to clipboard
[FEATURE] Add mDNS support for host candidates
Is your feature request related to a problem? Please describe.
Web browsers routinely use ephemeral mDNS host candidates (e.g. 0f612a90-ee2e-4785-b9b7-72f8434cba27.local
) so as to not expose the local peer's IP address on its local area network. However, the SDK is not currently able to use these candidates:
ERROR iceAgentAddRemoteCandidate(): operation returned status code: 0x5a000003
Peer-reflexive candidate currently serve as a stop-gap in these cases. However, mDNS host candidates should really be supported, both for local and remote host candidates.
@thinkski ,
As long as these candidates are UDP and are of IPv4 format, it should work. What are you noticing in terms of behaviour of the application?
@disa6302 When you say "as long as these candidates are UDP and are of IPv4 format", I take it you mean the address the mDNS hostname resolves to, correct?
I'm not seeing a remote host candidate logged -- the remote peer sends an mDNS host candidate, the C SDK prints the error above. From reading the code, I only see inet_pton()
used, but don't see any code for mDNS domain name resolution (i.e. no getaddrinfo()
or gethostbyname()
), unless I'm missing something?
The remote is supposed to send us the candidates as part of SDP. Do we know if the SDP contains the IP addresses?
The remote is supposed to send us the candidates as part of SDP. Do we know if the SDP contains the IP addresses?
The candidates are trickled. The host candidate is an mDNS hostname (e.g. 0f612a90-ee2e-4785-b9b7-72f8434cba27.local
, not an IP address).
Ok. Now I get it. We will look into this and update the thread with information if any. Adding the ticket as a suggested enhancement.
Adding for our reference: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates
Thank you! I believe the fix is relatively straightforward -- if the candidate is of type host, use getaddrinfo()
to resolve it to an IP address (which is a no-op if its already an IP address). Happy to provide a PR.
Thank you @thinkski . We do welcome contributions! If you have some changes for this, please feel free to open a PR, and the team can review it.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
+1. This would be a nice inclusion.