onSessionCloseListener not invoked in HangUp from iOS SDK

[stepic-reply]

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]

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]

Attached logs during the call close event.
Archive.zip

[DaveLomber]

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]

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

[stepic-reply]

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]

@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]

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]

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="[email protected]">
  <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]

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]

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]

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

[stepic-reply]

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

[stepic-reply]

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]

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]

@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]

@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]

@CMLCNL

We just added this commit ConnectyCube/connectycube-web-samples@e94970e

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

are you getting anything different?

[CMLCNL]

@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]

@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]

@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]

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