Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ice trickle support #691

Closed
rprata opened this issue Apr 14, 2022 · 15 comments
Closed

Ice trickle support #691

rprata opened this issue Apr 14, 2022 · 15 comments
Labels
stale There has been no recent activity

Comments

@rprata
Copy link
Contributor

rprata commented Apr 14, 2022

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.

@mglettig
Copy link

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.

@jlaine
Copy link
Collaborator

jlaine commented Apr 17, 2022

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.

@jlaine
Copy link
Collaborator

jlaine commented Apr 17, 2022

@rprata this is where it needs to happen: aiortc/aioice#4

@rprata
Copy link
Contributor Author

rprata commented Apr 18, 2022

@rprata this is where it needs to happen: aiortc/aioice#4

I'll check this issue and update it.

Thanks.

@rprata rprata closed this as completed Apr 18, 2022
@jlaine jlaine reopened this Apr 18, 2022
@jlaine
Copy link
Collaborator

jlaine commented Apr 18, 2022

Hi @rprata I'm happy to keep this issue open as there will be some integration work in aiortc itself too.

@mglettig
Copy link

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.

@jlaine
Copy link
Collaborator

jlaine commented Apr 19, 2022

@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
Copy link

@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.

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).

@github-actions
Copy link

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.

@github-actions github-actions bot added the stale There has been no recent activity label Aug 24, 2022
@jlaine jlaine removed the stale There has been no recent activity label Sep 6, 2022
@jlaine
Copy link
Collaborator

jlaine commented Sep 6, 2022

Let's keep this issue alive

@github-actions
Copy link

github-actions bot commented Jan 5, 2023

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.

@github-actions github-actions bot added the stale There has been no recent activity label Jan 5, 2023
@jlaine jlaine reopened this Jan 23, 2023
@github-actions github-actions bot removed the stale There has been no recent activity label Jan 24, 2023
@yedi
Copy link

yedi commented Mar 31, 2023

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?

@toon4003
Copy link

toon4003 commented Jun 1, 2023

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?

@guidocalvano
Copy link

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?

Can you share your solution or @jlaine can a working Firefox example be supplied?

Copy link

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.

@github-actions github-actions bot added the stale There has been no recent activity label Feb 14, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale There has been no recent activity
Projects
None yet
Development

No branches or pull requests

6 participants