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

Impolite "offered ignored" on renegotiation? #652

Open
brendanmoore opened this issue Mar 24, 2022 · 2 comments
Open

Impolite "offered ignored" on renegotiation? #652

brendanmoore opened this issue Mar 24, 2022 · 2 comments

Comments

@brendanmoore
Copy link

brendanmoore commented Mar 24, 2022

Your environment.

  • Version: v1.11.0-jsonrpc
  • Client: ion-js-sdk
  • Environement: OVH VPS
  • Are you using a TURN server? coturn

What did you do?

I have been running ion-sfu on a small side project for a while now, essentially using the default set-up given in example code. Straight up docker image but with a couple entries in the config toml (turn server creds). It works awesome for the most part. However I have found that occasionally the RTCPeerConnection.connectionState (not ICE) for a given client can change to disconnected or failed- hard to specifically track down why (perhaps flaky connection). Renegotiation is needed however the SFU rejects the offer with offered ignored https://github.com/pion/ion-sfu/blob/68545cc25230220435ee028d5a0af6e768a0a79a/pkg/sfu/peer.go#L201-L203

What did you expect?

The server would be "polite" and "rollback" its local description (like you would with a mesh topology) so it can accept the new incoming offer. Something like:

	if p.publisher.SignalingState() != webrtc.SignalingStateStable {
		p.publisher.pc.SetLocalDescription(webrtc.SessionDescription{Type: webrtc.SDPTypeRollback});
	}

It appears as the the pion/webrtclibrary has support for rollback but the implementation here in ion-sfu doesn't exactly support it. I would love to be able to dive into the code and PR this up but I am a total Go noob.

The only workaround I could find (using the js-sdk) was to completely disconnect the client/signalling and reconnect a fresh.

Notes:
Some people are still reporting this error condition in a closed issue #571

Also I am very grateful for all the work on this project it has really helped me. Great job!

@OrlandoCo
Copy link
Collaborator

OrlandoCo commented Mar 24, 2022

Hello, @brendanmoore ion-sfu does not support perfect negotiation, becuase there were some issues on browser implementation, thats why it uses 2 pc, one to publish and other one to subscribe, that way negotiations would be always one sided.

Not sure what could be the reason the connection is closing, are you connecting from browser or another server?

Also Im not actively mantaining the SFU, so I recommend you to look at livekit, its open source and was based on ion.

@brendanmoore
Copy link
Author

Hey @OrlandoCo Thanks for getting back to me.

I missed a piece of information... It is actually the publish PC that disconnects/fails for some reason. The subscribe PC is normally rock solid, so the affected user no longer sends any media, yet can't still see/hear all the incoming, so trying to un-plublish/re-publish the LocalStream (that triggers a renegotiation) throws this "offered ignored" (if the connection state is "connected" un-publish/republish works fine) so I am fairly sure the pub connection (client -> sfu) just needs a rollback on the sfu side and it should kick back to life. This would probably also handle/fix a user connection type change (i.e. moving from wifi to 4G). I am just thinking out loud here.

I totally understand if you are no longer maintaining this project. Livekit looks awesome: Quite the batteries included approach I'll check it out some more. However this project is perfect for me at the moment, perhaps I need to go learn go 🤓

Great job again, and thanks for the hard work on this

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

No branches or pull requests

2 participants