Why are my calls disconnecting after a few seconds?

[Stuart Bentley]

Hi, I'm working on setting up my own WebRTC app, and I'm having some problems with my current implementation. When I test my app (at http://chatphrase.com/test/ ) with a friend of mine who lives less than a mile away, we're connected for a few seconds, then the call is disconnected (each of us sees the other side's streams freeze, and chrome://webrtc-internals reports that the ICE connection has disconnected).

At first I thought it was just the TURN server I was using (turn:homeo:ho...@turn.bistri.com:80), but now I'm trying it with numb.viagenie.ca and I'm getting the same result, so I'm thinking this isn't an issue with the TURN server I'm using. (Also, why would a connection between two ordinary residential NAT routers need to go through TURN?)

Since we've tested over https://apprtc.appspot.com and our systems can connect just fine, I'm led to believe this is an issue with my implementation. Can anybody see what's wrong? (To test, go to http://chatphrase.com/test/, enter an alphanumeric phrase on one end, then enter the same phrase on the other end to be connected - I'm available as one end for testing, you can contact me via email or Google Hangouts at stu...@testtrack4.com.)

[Philipp Hancke]

It seems like the peerconnection is closed due to garbage collection. Try keeping an explicit reference somewhere.

[Stuart Bentley]

If this is in fact the root cause, would I be correct in saying that this is a bug in Chrome?

[Stuart Bentley]

https://code.google.com/p/chromium/issues/detail?id=292887

[Dennis E. Dowhy]

IMO this is not a bug. This is expected behavior. If an object goes out of scope it gets garbage collected. You can't just make an exception in JavaScript and stop garbage collecting objects with no more references.  If a disconnect is expected, how would you trigger an ice restart then?  what if you wanted to stop it? what if you then wanted it to go out of scope and eventually get garbage collected?  unless you have references to it none of that is going to happen. I believe this is correct behavior to have peer connections garbage collected once they have no more references to them regardless of their state. 

Sent from my iPhone

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[bryand...@gmail.com]

It is a bug per the spec which requires that the window object holds a strong reference to the pc.

It was previously reported and fixed...

https://code.google.com/p/webrtc/issues/detail?id=2047

[Stuart P. Bentley]

Does that mean the fix will land when 30 goes stable?

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/BbQRh2CIXEw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Vikas]

Hi,

I think you should be able to test with Chrome beta the fix for issue 2047 should be in there.

/Vikas

[Dennis E. Dowhy]

Alrighty then I stand corrected apparently. If you no longer have a reference to the peer connection then how would you do any of the things I mentioned previously?  I think this puts you into some sort of weird state with a "partially hanging around object that you no longer have any control over that's partially sort of on its way to being garbage collected if the media somehow disconnects of which I have no way of stopping without closing windows down meanwhile its chewing up my bandwidth and its owning control of my webcam that I can't release to be used by other applications."  Sound confusing? yep thats what i think of this behavior too.  I don't exactly agree with that type of behavior. I'd rather have it properly garbage collected when there are no more references to it. Leaving these hanging around like that sounds like the type of behavior i'd expect from a memory leak. But that just my opinion. That is of course unless you have some method of re-obtaining a reference to it (therefore not truely reaching a reference count of 0) as well the ability to detach that reference from a video element. Without those, it sounds like an incomplete API.

Sent from my iPhone