Closed
Bug 881294
Opened 11 years ago
Closed 11 years ago
inform the user when a PeerConnection was closed unexpectedly
Categories
(Core :: WebRTC: Networking, defect)
Core
WebRTC: Networking
Tracking
()
RESOLVED
DUPLICATE
of bug 852665
People
(Reporter: florian, Unassigned)
Details
(Whiteboard: [WebRTC][blocking-webrtc-])
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•11 years ago
|
||
bug 878562 may be requesting the same thing, but I find that bug confusing, so I preferred filing a new one.
Comment 2•11 years ago
|
||
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.
Reporter | ||
Comment 4•11 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)
Comment 5•11 years ago
|
||
(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•11 years ago
|
Whiteboard: [WebRTC][blocking-webrtc-][Works for me?]
Reporter | ||
Comment 6•11 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).
Comment 7•11 years ago
|
||
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•11 years ago
|
Flags: needinfo?(adam)
Whiteboard: [WebRTC][blocking-webrtc-][Works for me?] → [WebRTC][blocking-webrtc-]
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•