search

open-webrtc-toolkit / owt-client-native

Open WebRTC Toolkit client SDK for native Windows/Linux/iOS applications.
https://01.org/open-webrtc-toolkit
Apache License 2.0
392 stars 181 forks source link

Attempt to perform PeerConnection operation when it is closed. #122

Open JamesTerm opened 5 years ago

JamesTerm commented 5 years ago

This issue is very similar and created from issue #121

Ideally, we want to leave the desktop application (Callee / client native) acting as a server for callers, and to keep it logged in to signaling server, which callers are able to come and go as needed.

In our testing environment to reproduce issue, we use the sample application, and the sample web page (as the caller). Then do the following steps:

  1. Setup a p2p session stream video (everything successful)
  2. Click 'Stop Camera Sharing' from calling browser (Note: I can share camera again... in this state)
  3. Click "Logoff" button
  4. Click "Logon" button
  5. Click "Share Camera" button

This time I get the following: (peerconnectionchannel.cc:106): Attempt to perform PeerConnection operation when it is closed.

I would hope this can work, Chunbo has said the following about this: For the use scenario you mentioned, you want functionality like stop-share/share-again is about reconnection or new connection, which takes times for SDK to run detection in order to decide the next step. Similar things to the case like logging off/back on if you're talking about the signaling connection to signaling server, the streaming peer connection is different from signaling connections: The logging off of signaling will not affect the ongoing streaming.

Ok... so one other step that makes this more interesting:

  1. Click the disconnect button from the application
  2. Click the connect button from the application

This has no effect... when sharing the camera it will yield the same result.

What does work, is if I disconnect, and alter the code to reset signalingchannel where io_ (sio::client) is reset. When this happens if will successfully stream again, so I am not sure if this is the fix or if this is a work-around. As a starting point it would be nice to know if the owt-client_native should be able to handle stresses like this.

JamesTerm commented 5 years ago

There is another way to reproduce this issue...

On the client native sample app:

  1. Connect to 11
  2. Set Remote to 12
  3. Click the text button

Note: the stress here is that the caller is not connected, so I expect the message to return message failed.

  1. Observe the message failed to send

On the caller side:

  1. Login to 12
  2. Set Remote ID to 11
  3. Share Camera

I'd expect this to succeed, but instead it gives the same error message as before.

RiuHDuo commented 5 years ago

I met same problem when run windows p2p sample. How to fix this problem?

JamesTerm commented 5 years ago

I hope to hear some response on this... at the very least it should be flagged as p2p and bug. The key is peerconnectionchannel.cc: line 106 as a starting point. I have some other tasks that are on the front burner, but if this case is still open by then... I may take a look at how to solve it.

JamesTerm commented 4 years ago

Ok with today's epic merge of branch 76. (pr #216 ).. I will eventually come back to this issue as time allows and see if it is still present.

For now... I've worked around this problem by monitoring when the caller logs off. I found that OnServerDisconnected() is currently not used for p2p, so I'm using this as a gateway signal to the client code in order to keep changes in the sdk to a minimum. When the caller logs off, I then issue a reset to the app client code which spawns a DPC that disconnects, waits a second, and reconnects. (see initial entry about resetting the signalingchannel for that to work). I do not plan to submit these changes for pr as I feel it is a work-around solution, while mentioning this now to help others in the short term.

This solution is not perfect in that a caller may drop the call without logging off, in which case I can monitor the stream or provide a manual reset work-around, both of which do the same solution, but have their own triggering methods to get there.

JamesTerm commented 4 years ago

As an addendum to the last entry I've handled the stress of a caller dropping the call by use of GetConnectionStats()... loose polling this when the video feed is lost. This will let me know the moment the connection is lost.