aiortc
aiortc copied to clipboard
Ice trickle support
Hi again,
I would to open again the discussion about ice tickle support. So, is it so difficult to implement in aiortc codebase? Could explain how can we implement this in aiortc
(better way to implement)? I could help you in this issue.
I would like to join this discussion. I would need ICE trickle support to get compatibility to my WebRTC counterpart that seems to only support offering with ICE trickle. When searching for ICE trickle support in this code base I found some hints that it should be possible to get it working but I didn't found out how. For example I found this discussion here very interesting https://github.com/aiortc/aiortc/issues/651 but it looks like the issue was not resolved for the one that raised the question.
I would like to join this discussion. I would need ICE trickle support to get compatibility to my WebRTC counterpart that seems to only support offering with ICE trickle. When searching for ICE trickle support in this code base I found some hints that it should be possible to get it working but I didn't found out how. For example I found this discussion here very interesting #651 but it looks like the issue was not resolved for the one that raised the question.
This is off topic, we support receiving trickled ICE candidates, so there should be no interop issue.
@rprata this is where it needs to happen: https://github.com/aiortc/aioice/issues/4
@rprata this is where it needs to happen: aiortc/aioice#4
I'll check this issue and update it.
Thanks.
Hi @rprata I'm happy to keep this issue open as there will be some integration work in aiortc itself too.
I would like to join this discussion. I would need ICE trickle support to get compatibility to my WebRTC counterpart that seems to only support offering with ICE trickle. When searching for ICE trickle support in this code base I found some hints that it should be possible to get it working but I didn't found out how. For example I found this discussion here very interesting #651 but it looks like the issue was not resolved for the one that raised the question.
This is off topic, we support receiving trickled ICE candidates, so there should be no interop issue.
I think there still may occur interop issues: That is if the counterpart of aiortc can't handle it when the ICE candidates are sent directly in the answer. But this could be more of an issue of the other library than an issue of aiortc... If I understand you correctly aiortc supports receiving ICE trickle candidates out of the box (no special handling needed in the application)? Is there any particular library that works particularly well as a counterpart of aiortc? I think the one from google https://webrtc.googlesource.com/src is particularly widespread. Was it tested with aiortc?
Sorry if this post is off topic but I didn't find a better place to post it.
@mglettig we explicitly support both candidates passed into setRemoteDescription
or subsequenty with addIceCandidate
. If you have a reproducible scenario where this does not work, please open a separate issue.
@mglettig we explicitly support both candidates passed into
setRemoteDescription
or subsequenty withaddIceCandidate
. If you have a reproducible scenario where this does not work, please open a separate issue.
Just confirming that it works as you mentioned. 👍 The problem was on my side (my signalling adapter blocked a thread where aiortc was running it leading to no response during ICE exchange).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Let's keep this issue alive
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is off topic, we support receiving trickled ICE candidates, so there should be no interop issue.
In order to get around Firefox's bug with resolving mDNS addresses only after setRemoteCandidate
is called. I tried and seemingly succeeded to implement trickle candidate support. I updated the webcam.py example with another endpoint for receiving trickled candidates. ICE connections in Firefox are now successful.
However, despite iceConnectionState
equaling connected
I still cannot view webcam video in my application. Checking about:webrtc
shows a successful connection but no data being transmitted. (However, I do see the feed if I turn on STUN locally to generate a srflx candidate and don't use trickling)
@jlaine Is it expected that I should be able to see the video feed after an ICE connection is made via trickling? Is there anything special I need to do when sending the video feed in this case?
Same problem here! I am very new to webrtc and want to receive video stream after sending sdp answer. Ice connection is complete (successfully to connect to server via webrtc) but no data transmit.
I've asked for help here and he said library is not sending or receiving Stun Binding Requests to server.
Please tell me what should I do next?
This is off topic, we support receiving trickled ICE candidates, so there should be no interop issue.
In order to get around Firefox's bug with resolving mDNS addresses only after
setRemoteCandidate
is called. I tried and seemingly succeeded to implement trickle candidate support. I updated the webcam.py example with another endpoint for receiving trickled candidates. ICE connections in Firefox are now successful.However, despite
iceConnectionState
equalingconnected
I still cannot view webcam video in my application. Checkingabout:webrtc
shows a successful connection but no data being transmitted. (However, I do see the feed if I turn on STUN locally to generate a srflx candidate and don't use trickling)@jlaine Is it expected that I should be able to see the video feed after an ICE connection is made via trickling? Is there anything special I need to do when sending the video feed in this case?
Can you share your solution or @jlaine can a working Firefox example be supplied?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.