If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

inform the user when a PeerConnection was closed unexpectedly

RESOLVED DUPLICATE of bug 852665

Status

()

Core
WebRTC: Networking
RESOLVED DUPLICATE of bug 852665
4 years ago
4 years ago

People

(Reporter: florian, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC][blocking-webrtc-])

(Reporter)

Description

4 years ago
I don't know any way for a web application to be informed if the other end of a PeerConnection disappears (browser killed, crashed, whatever...) and no longer sends any data.

This would be useful to update the UI to reflect that the call has actually ended.

Reading http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtciceconnectionstate-enum makes me think that maybe this is what the "disconnected" state of RTCIceConnectionState is for, but I'm not completely sure.
(Reporter)

Comment 1

4 years ago
bug 878562 may be requesting the same thing, but I find that bug confusing, so I preferred filing a new one.
Have you tried doing the following?

1. Listen for the onsignalingstatechange event
2. Check for when the signalingState changes to closed

That should work I think.
needinfo to confirm if comment 2 works for you
Flags: needinfo?(florian)
(Reporter)

Comment 4

4 years ago
(In reply to Jason Smith [:jsmith] from comment #2)
> Have you tried doing the following?
> 
> 1. Listen for the onsignalingstatechange event
> 2. Check for when the signalingState changes to closed

The initial value of signalingState is "stable". It never changes (or at least my onsignalingstatechange handler is never called).

I can't find anything in the code generating "signalingstatechang" events (http://mxr.mozilla.org/mozilla-central/search?string=signalingstatechange) so maybe this isn't implemented yet?
Flags: needinfo?(florian)
(In reply to Florian Quèze [:florian] [:flo] from comment #4)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > Have you tried doing the following?
> > 
> > 1. Listen for the onsignalingstatechange event
> > 2. Check for when the signalingState changes to closed
> 
> The initial value of signalingState is "stable". It never changes (or at
> least my onsignalingstatechange handler is never called).

Are you running the latest build? Cause I'm seeing onsignalingstatechange implemented. I know Adam landed this recently on trunk.

Updated

4 years ago
Whiteboard: [WebRTC][blocking-webrtc-][Works for me?]
(Reporter)

Comment 6

4 years ago
comment 4 was with the "24.0a1 (2013-06-07)" build. I've just tested with a current nightly (24.0a1 (2013-06-10)) and there's a difference, signalingState starts at "stable", is changed to "have-local-offer", and then returns to "stable". Still no event when the other end disappears (even after waiting a few minutes).
Okay, i confirmed that actually. Looks like the patch on bug 784519 isn't handling the closed case.

Adam - Any thoughts?
Flags: needinfo?(adam)

Updated

4 years ago
Flags: needinfo?(adam)
Whiteboard: [WebRTC][blocking-webrtc-][Works for me?] → [WebRTC][blocking-webrtc-]

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 852665
Moving the talkilla tracking bug to bug 852665.
No longer blocks: 859886
You need to log in before you can comment on or make changes to this bug.