You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ignoredhttps://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:
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!
The text was updated successfully, but these errors were encountered:
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.
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
Your environment.
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 configtoml
(turn server creds). It works awesome for the most part. However I have found that occasionally theRTCPeerConnection.connectionState
(not ICE) for a given client can change todisconnected
orfailed
- hard to specifically track down why (perhaps flaky connection). Renegotiation is needed however the SFU rejects the offer withoffered ignored
https://github.com/pion/ion-sfu/blob/68545cc25230220435ee028d5a0af6e768a0a79a/pkg/sfu/peer.go#L201-L203What 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:
It appears as the the
pion/webrtc
library 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!
The text was updated successfully, but these errors were encountered: