search

ConnectyCube / connectycube-js-sdk-releases

Releases materials for ConnectyCube JS SDK platform https://connectycube.com
9 stars 2 forks source link

onSessionCloseListener not invoked in HangUp from iOS SDK #10

Open stepic-reply opened 4 years ago

stepic-reply commented 4 years ago

We are experiencing a problem with the Connectycube library, we are using it on a web app and also on a native iOS app.

When two web browser are video calling each other, ending a call on one of them is well handled and the other client receive an event on the event listener ‘onSessionCloseListener’, instead when a video call is established between a web browser and a the iOS app, we are facing some problems.

On iOS we execute the following code:

self.session?.hangUp(self.myUserInfo) f self.videoCapture != nil{ self.videoCapture?.stopSession(nil) }

But on the web, the event listener ‘onSessionCloseListener’ isn’t fired, causing a problem with end call handling. In order to workaround this problem we are using on the web the event listener ‘onSessionConnectionStateChangedListener’, that is called back with the state ‘DISCONNECTED’. This workaround, unfortunately, has some flaws, cause it’s fired on the web only after 5-8 seconds after the execution of the hangUp function by the iOS code.

Is this behavior a problem of the library? Or are we using it in the wrong way?

DaveLomber commented 4 years ago

Hi @stepic-reply

Basically both Web and iOS are compatible platforms and should work w/o any issues

Let's try to debug and get more info re issue

Please do the following: 1) On Web side, to collect browser console logs at the time when iOS app ends the call. It will help us to understand whether a Web users receives this signal or not. 2) Same to do on iOS side - toileting collect Xcode logs at the time when iOS app ends the call . It will help us to understand whether an iOS users sends a proper signal about call end or not.

Having this information will help us to find a root cause

stepic-reply commented 4 years ago

Attached logs during the call close event. Archive.zip

DaveLomber commented 4 years ago

Thanks @stepic-reply

I have checked the logs and looks like my assumption was correct - I do not see any ''hangup" signals received on Web and sent from iOS.

What's more interesting is iOS logs - I see there the following:

2020-03-10 14:26:08.422369+0100 [7646:6499736] [Chat]: Doing Chat disconnect...
2020-03-10 14:26:08.426487+0100 [7646:6499095] [Chat]: SNT: <presence type="unavailable"/>
2020-03-10 14:26:08.426650+0100 [7646:6499095] [Chat]: Disconnected

It seems you just close the chat connection at iOS side when ends a call, w/o sending a 'hangup' signal.

What can be better to do on call end is to call a hangUp method, and that's all, but to keep a chat connection - just follow this guide https://developers.connectycube.com/ios/videocalling?id=end-a-call

Cause it seems you either do not call a hangUp method OR call it but does not wait the signal to be sent, instead you close a chat connection immediately, so the hangup signal can't be sent .

Please check it and let us know if you need more assistance

stepic-reply commented 4 years ago

Sorry, I just cut a piece of the ios logs. Attached the complete version log_ios.txt

stepic-reply commented 4 years ago

if it can be useful an extract of the code that hangUp the call iOS-side:

self.session?.hangUp(self.myUserInfo) if self.videoCapture != nil{ self.videoCapture?.stopSession(nil) }

DaveLomber commented 4 years ago

@stepic-reply thanks for providing the complete log

anyway it's the same - there is no hangup signal sent from iOS side, instead of it I see a chat disconnect log

Could you provide the complete code snippet what your are doing when hangup, need to check it

stepic-reply commented 4 years ago

The hang up in the log should be this line:

2020-03-10 14:26:08.416 rtc::[SESS]<2206FB76-87CA-4A21-AC60-CD9A1E77F8C5, I:398335, O:[395045], T:V> Hang Up call 2020-03-10 14:26:08.416 rtc::[SESS]<2206FB76-87CA-4A21-AC60-CD9A1E77F8C5, I:398335, O:[395045], T:V> Begin hangup, userinfo: { ...user infos.... }.

And then:

2020-03-10 14:26:08.422369+0100 Dev App[7646:6499736] [Chat]: Doing Chat disconnect... 2020-03-10 14:26:08.423 rtc::[SESS]<2206FB76-87CA-4A21-AC60-CD9A1E77F8C5, I:398335, O:[395045], T:V> Hang Up call (webrtcvideoengine.cc:2424): VideoReceiveStream not connected to a VideoSink. 2020-03-10 14:26:08.426487+0100 Dev App[7646:6499095] [Chat]: SNT: 2020-03-10 14:26:08.426650+0100 Dev App[7646:6499095] [Chat]: Disconnected

Am I wrong?

The code is basically a copy&paste from sample-videochat-swift from your samples.

DaveLomber commented 4 years ago

There should be a Chat hangup signal here, e.g. like this one 

Dev App[7646:6499736] [Chat]: SNT: <message id="5e6795684d067ade1d0041ac" type="headline" to="395045-1546@chat.connectycube.com">
  <extraParams xmlns="jabber:client">
    <callType>1</callType>
    <callerID>398335</callerID>
    <moduleIdentifier>WebRTCVideoChat</moduleIdentifier>
    <platform>ios</platform>
    <signalType>hangup</signalType>
   ....

with <signalType>hangup</signalType>

but there is nothing on this matter in logs

Please do 2 things: 1) check that self.session is not nil 2) provide the complete snipped what you do when press a end call button

stepic-reply commented 4 years ago

Attached the code snippet for the management of all the call actions. CallViewController.swift.zip

We also found out another problem with the hangUp. Below a quick description:

  1. User A on iOS call user B
  2. User B on Web-side receives the signal for the incoming call
  3. If User A drop the call before User B answer, User B doesn't receive any kind of signal to inform him that the call has been closed by the other side
krisbaum74 commented 4 years ago

i can also confirm -->

"3.If User A drop the call before User B answer, User B doesn't receive any kind of signal to inform him that the call has been closed by the other side"

is happening for me as well.

DaveLomber commented 4 years ago

@krisbaum74 @stepic-reply thanks we will double check this at our end

stepic-reply commented 3 years ago

Hello @DaveLomber any update on this? We are reworking the app and we need to fix this specific case.

stepic-reply commented 3 years ago

Hello @DaveLomber any update on this? We are reworking the app and we need to fix this specific case.

Hey, we found that the same issue is affecting Android SDK. Do you have any feedback? @DaveLomber

CMLCNL commented 3 years ago

We used to use connectycube 1 version before, but now we are using 3.7.5. If a user exits the application without sending a close call. The call does not hang up. OnSessionConnectionStateChangedListener used to work but now it doesn't work. @DaveLomber

DaveLomber commented 3 years ago

@CMLCNL once a user is disconnected unexpectedly a ConnectyCube.videochat.onSessionConnectionStateChangedListener should fire after some time https://developers.connectycube.com/js/videocalling?id=monitor-session-connections-state

Do you mean it's not happening anymore after switched 1->3 SDK?

CMLCNL commented 3 years ago

@CMLCNL once a user is disconnected unexpectedly

a ConnectyCube.videochat.onSessionConnectionStateChangedListener should fire after some time https://developers.connectycube.com/js/videocalling?id=monitor-session-connections-state

Do you mean it's not happening anymore after switched 1->3 SDK?

Exactly. When i return the sdk 1. Everything its work.

DaveLomber commented 3 years ago

@CMLCNL

We just added this commit https://github.com/ConnectyCube/connectycube-web-samples/commit/e94970e2d5f3b1b80ff9e6bba5a0ac0a8527a840

and then tested using public p2p list https://connectycube.github.io/connectycube-web-samples/videochat/dist/

the following case:

  1. 2 users are on a call
  2. 2nd user just switched the wifi off
  3. after a bit of time, a User1 received the 'onSessionConnectionStateChangedListener' callback
Screenshot 2021-04-18 at 15 12 07

are you getting anything different?

CMLCNL commented 3 years ago

@DaveLomber My problem in React-Native Sdk. This listener never working on 3.7.5 or 3.7.8. Just working on first sdk. SDK 1

DaveLomber commented 3 years ago

@CMLCNL thanks, noted

we are using https://github.com/react-native-webrtc/react-native-webrtc/releases internally and periodically do upgrades of the lib to be up to date with WebRTC stack itself and use new features

I'm not sure if it's possible or not, but you can potentially try to connect an older ver of react-native-webrtc via package.json and see what will happen

Meanwhile, we will double check the listener in latest RN SDDK

CMLCNL commented 3 years ago

@DaveLomber Make sure I have reviewed both sdk. It works in version 1. But it definitely doesn't work in version 3. It also doesn't work in OnRejectListener in version 3. Believe me, I have been using connectycube for 1 year.

DaveLomber commented 3 years ago

@CMLCNL I trust your feedback , if you say it does not work then it means it does not work