spreed icon indicating copy to clipboard operation
spreed copied to clipboard

Failed call 5th Feb

Open nickvergessen opened this issue 11 months ago • 2 comments

  • [ ] Check readyState on video and reconnect (with increasing delay) if state is 0 check of speakers
  • [ ] Check how janus behaves if publisher connection is closed, what happens with the receiver connections
  • [ ] Allow to access chrome://webrtc in desktop client
  • [ ] show avatar with loading spinner instead of empty/black space

  • @ShGKme resumed his websocket connection
  • 30s later he created a new publisher connection
  • there were no force reconnects
  • the timing strangely aligned with daniel joining the room (talk php word)
  • Selecting the video element in DOM and afterwards cehck various HTML attributes on $0
  • Re-requesting the offer with OCA.Talk.SimpleWebRTC.connection.requestOffer("PUT_SESSIONID_HERE", "video") made audio and video work

nickvergessen avatar Feb 05 '25 15:02 nickvergessen

Check readyState on video and reconnect (with increasing delay) if state is 0 check of speakers

After further research checking readyState in a video element does not seem like a good approach. If a receiver connection is stalled in Chromium readyState will be 0 only for new video elements, but existing video elements will stay at 4 even if no more data is received. In Firefox readyState will be 4 even for new video elements, as it seems to cache the last received frame or something like that. I do not know how Safari behaves.

Similarly, muted can not be checked in the MediaStreamTrack either. In Chromium it only changes to false for the video track, but not for the audio track. In Firefox it does not change to false even for the video track.

A better approach would be checking the bytesReceived or lastPacketReceivedTimestamp in the inbound-rtp stat of the receiver connection, as those values no longer increase once the publisher connection is closed (although they do in the candidate-pair or transport stat). remote-outbound-rtp values do not increase either, but strangely enough Chromium does not seem to provide that stat for video, only for audio, while inbound-rtp is provided for both.

The time without an update of inbound-rtp that should trigger a reconnection still needs to be verified, though, as it seems that the stats of receiver connections sometimes are not updated for several seconds even on working connections.

danxuliu avatar Feb 11 '25 07:02 danxuliu

  • [ ] show avatar with loading spinner instead of empty/black space

@Antreesy could you have a look at that?

nickvergessen avatar Feb 12 '25 14:02 nickvergessen