search

meetecho / simple-whip-server

Simple WHIP Server (based on the Janus WebRTC Server)
GNU General Public License v3.0
93 stars 24 forks source link

WHIP sessions not removed on ConnectionState==Closed, HTTP - DELETE required #6

Closed cameronelliott closed 6 months ago

cameronelliott commented 2 years ago

I would just like to confirm if something is possible.

It is possible to somehow have simple-whip-server teardown the WHIP session when the Janus RTCPeerConnection ConncectionState goes to closed. (or Disconnected or Failed)

It seems this doesn't happen by default, and the HTTP 'DELETE' indication is required to stop/end a WHIP session?

Thanks, Cameron

p8952 commented 2 years ago

I'm curious how this is supposed to work too.

After creating a WHIP Endpoint which maps to a Janus Room, I can use a WHIP Client to send an audio/video stream into the Janus Room. Brilliant 🎉

However if I stop the WHIP Client the WHIP Endpoint remains in an active state and I get an HTTP 403 Forbidden error when restarting the WHIP Client.

Should the WHIP Server be putting the WHIP Endpoint back into an idle state when the WHIP Client disconnects? Or is it the job of the WHIP Client to manage the WHIP Endpoint by sending an HTTP DELETE before restarting?

lminiero commented 2 years ago

@cameronelliott apologies for this late response, I must have missed the notification. The WHIP server is already configured to automatically tear down the WHIP resource when it detects the PeerConnection going away: notice this only means getting rid of the resource, not the endpoint, which should then be available for another round from a different WHIP client in case. That said, the WHIP server relies on Janus notifiying this via a hangup event, so if that doesn't happen it's not aware the PC may have gone away; due to the way Janus works, this can happen in response to a DTLS alert, but it will not detect ICE timeouts.

@p8952 I think this addresses your question as well. In theory we have ways to intercept info on a PC going away, but it's always best to explicitly send a DELETE as well to make sure the session doesn't remain busy. I guess we can add an internal REST request to forcibly tear down a session as well in case the original client went away, so that from an application server perspective you can do some cleanup when that happens.

p8952 commented 2 years ago

@lminiero Thanks for the prompt reply, yes that clears it up for me!

lminiero commented 6 months ago

Closing.