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

How Pion WebRTC handle ICE role conflict #359

Open
xianchuhan opened this issue Apr 21, 2021 · 8 comments
Open

How Pion WebRTC handle ICE role conflict #359

xianchuhan opened this issue Apr 21, 2021 · 8 comments

Comments

@xianchuhan
Copy link

pion webrtc environment.
Version: [email protected]

What did you do?
we use pion webrtc as client,ice role is contrlolling,remote webrtc as server,ice role is controlling,in this case,an end-to-end not solve the problem of conflict of ice, pion webrtc no solution to the conflict, causing the ice connection to fail.

What did you expect?
Hope that the pion webrtc can solve the problem of ice role conflict.

@Sean-Der Sean-Der transferred this issue from pion/webrtc Apr 21, 2021
@Sean-Der
Copy link
Member

Hey @xianchuhan

This would be a great change! I don't think it would be that challenging either.

In selection.go we have dedicated logic for controlling/controlled. We could add some heuristics to detect if the other side is controlling as well, and then we could switch to controlled. I believe the ICE RFC has explicit instructions on how to do this.

@xianchuhan
Copy link
Author

xianchuhan commented Apr 22, 2021

Hi @Sean-Der

In peerconnection. go SetRemoteDescription function,through the simple judgment to set the end of the ICE role,In pion webrtc code do not see the logic of conflict resolution.

As you say, we need According to the ice rfc specification to solve the problem of ice role conflict.

@Sean-Der
Copy link
Member

I don't believe the ICE Role goes in the SessionDescription. If you make the Offer you are the controlling ICE Agent. The only thing that can influence that would be ice-lite. So I don't believe there is any more logic we need to put in SetRemoteDescription

What could happen is that a ICE Agent could incorrectly being in controlling (or controlled mode) and it wouldn't be communicated via the Session Description. This needs to be handled in this package like this

@xianchuhan
Copy link
Author

xianchuhan commented Apr 23, 2021

Thank you very much for your answer.

Just as you say,when the browser as webrtc client, its ice role is controlling,pion webrtc as server,its ice role is controlled.in some cases,there will be another scenario,browser and pion webrtc turn channel established, then stun channel building,audio and video data is sent from the browser turn switch to stun channels, but pion webrtc remains from the turn and receives data,that led to not receive each other over the data.

Whether pion webrtc can support ice Channel switch? For example, you can switch from turn to stun.

@Sean-Der
Copy link
Member

Yes Pion supports switching between srflx and relay candidates. After a use_candidate is emitted it stays with TURN or STUN.

If you want to switch after the Selected pair has been chosen you can do a ice-restart

@xianchuhan
Copy link
Author

Thank you very much.

I try this approach.

@stv0g stv0g changed the title How pion webrtc handle ice role conflict How Pion WebRTC handle ICE role conflict Jan 12, 2023
@achingbrain
Copy link

achingbrain commented Jan 23, 2025

I'm trying to integrate pion/ice with libdatachannel/libjuice and have come across a similar problem.

When libjuice is in controlling mode and sees an incoming binding request that's also in controlling mode, depending on the tiebreaker value it can send a 487 and expects the remote to switch to controlled mode as per RFC 8445.

In response I think pion/ice just drops the message so the ICE connection fails.

Should pion/ice do the same thing - check for a ClassErrorResponse with the conflict error code in agent.go and switch mode?

achingbrain added a commit to achingbrain/libjuice that referenced this issue Jan 24, 2025
RFC 8445 6.1.1 says:

> The initiating agent that started the ICE processing MUST take the controlling role, and the other MUST take the controlled role.

The spec also shows how to resolve conflicts when both agents are
in the controlling role.

From what I can see here, libjuice will always start in controlling
mode and try to resolve the conflict before contining but it appears
some implementations [don't support that](pion/ice#359 (comment))
so one agent has to start in controlled role.

The change here is to allow passing the role to `juice_set_local_ice_attributes`
in order to start the receiving agent off in the controlled role.
achingbrain added a commit to achingbrain/libjuice that referenced this issue Jan 24, 2025
RFC 8445 6.1.1 says:

> The initiating agent that started the ICE processing MUST take the controlling role, and the other MUST take the controlled role.

The spec also shows how to resolve conflicts when both agents are
in the controlling role.

From what I can see here, libjuice will always start in controlling
mode and try to resolve the conflict before contining but it appears
some implementations [don't support that](pion/ice#359 (comment))
so one agent has to start in controlled role.

The change here is to allow passing the role to `juice_set_local_ice_attributes`
in order to start the receiving agent off in the controlled role.
achingbrain added a commit to achingbrain/libjuice that referenced this issue Jan 24, 2025
RFC 8445 6.1.1 says:

> The initiating agent that started the ICE processing MUST take the controlling role, and the other MUST take the controlled role.

The spec also shows how to resolve conflicts when both agents are
in the controlling role.

From what I can see here, libjuice will always start in controlling
mode and try to resolve the conflict before contining but it appears
some implementations [don't support that](pion/ice#359 (comment))
so one agent has to start in controlled role.

The change here is to allow passing the role to `juice_set_local_ice_attributes`
in order to start the receiving agent off in the controlled role.
@Sean-Der
Copy link
Member

@achingbrain yes we should do that! Are you interested in taking that on? I can help!

You can also control the role via the SettingEngine if you want to force it in Pion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants