search

ConnectyCube / connectycube-ios-calls-sdk-releases

Releases packages for ConnectyCube iOS Calls SDK platform
https://connectycube.com
3 stars 1 forks source link

didReceiveNewSession isn't triggered with VOIP Notification. #1

Closed iamimsh closed 4 years ago

iamimsh commented 4 years ago

Hi..

If I receive a call when my app is closed (removed from background), I'm trying to reconnect to ConnectyCube Chat Server, but didReceiveNewSession isn't triggered. How can I handle this?

iamimsh commented 4 years ago

Also, why not creating a session object with session id so that receiver can create the same session and get connected directly....

DaveLomber commented 4 years ago

@iamimsh please let us know where you are trying to reconnect to ConnectyCube Chat Server. Is it happening in background or foreground?

Also, what error do you receive?

iamimsh commented 4 years ago

@iamimsh please let us know where you are trying to reconnect to ConnectyCube Chat Server. Is it happening in background or foreground? Ans: background. Because app is closed.

Also, what error do you receive? Ans: there are no errors. It's connected but didReceiveNewSession isn't called..

Let me explain: Step 1: My app is closed and not in background. Step 2: Someone called me, since I'm not online I receive a VOIP notification. Step 3: Now in background, I try to connect to chat server (which is working fine). But how do I connect to session?

DaveLomber commented 4 years ago

The logic should be like this:

iamimsh commented 4 years ago

@DaveLomber I'm doing exactly the same...

  1. Displayed a Call Kit screen - then a user taps on accept and then will be redirected to the app
  2. once an app is opened - I'm connecting to chat server
  3. once connected, it does nothing... even though is connected to chat

Here's the log

12:32:14 PM Connected to chat server
12:32:33 PM ImSh:ConnectyCubeManager session(_:didChange:forUser:) - 12 - userId: 980381
12:32:33 PM ImSh:ConnectyCubeManager session(_:didChange:) - 4
12:32:33 PM ImSh:ConnectyCubeManager sessionDidClose(_:)

Is there a way to get the current session from SDK? It will be helpful for me to use it as a workaround.

iamimsh commented 4 years ago

@DaveLomber Update: I tested calling from Android device

  1. Displayed Call Kit screen, user accepts
  2. app opened and connected to chat server
  3. now it calls didReceiveNewSession(_ session: CallSession, userInfo: [String : String]? = nil)

But calling from iOS doesn't work.

I found the same issue in Android Project, here's the link: Link: https://github.com/ConnectyCube/android-messenger-app/issues/51

Conclusion: Making an outgoing call from iOS to iOS or Android (When the app is not active) doesn't trigger didReceiveNewSession method.

Please take a look at this issue, it's very critical.

DaveLomber commented 4 years ago

@iamimsh let's do the following:

at the time when app opened and connected to chat server (after Call Kit screen accepted) - please collect all Xcode logs from ConnectyCube SDK and attache here - we will check what's there and it will help to identify where the issue is

iamimsh commented 4 years ago

android-to-ios.txt ios-to-ios.txt

@DaveLomber I've attached the log files. Please take a look. android-to-ios is working fine. ios-to-ios doesn't work fine.

DaveLomber commented 4 years ago

Thanks @iamimsh we have checked the logs at our side

What's interesting in 'ios-to-ios.txt' is that there is a 'hangUp' signal in logs right after the chat is connected:


2020-03-01 12:09:24.025976+0300 timeviewer[1262:426083] [Chat]: RCV: <message xmlns="jabber:client" id="5e5b7bc397658cd906b7acdb" to="976722-1831@chat.connectycube.com" from="980381-1831@chat.connectycube.com/F10AE73F-D7A2-487D-BEBC-1B7554D0EC1D" type="headline">
  <extraParams xmlns="jabber:client">
    <callType>2</callType>
    <callerID>980381</callerID>
    <moduleIdentifier>WebRTCVideoChat</moduleIdentifier>
    <platform>ios</platform>
    <sdkVersion>1.2</sdkVersion>
    <sessionID>13EB07BB-D896-44B6-92F8-1A5875E31EC6</sessionID>
    <signalType>hangUp</signalType>
    <userInfo>
      <callee_name>Imran mohammed</callee_name>
      <caller_name>timeviewer</caller_name>
      <is_video>false</is_video>
      <start_time>2020-03-01 12:08:38</start_time>
      <duration>10</duration>
      <caller_image>https://dev.timeviewer.tv/storage/app/profiles/timev_1575789263.png</caller_image>
      <callee_image>https://dev.timeviewer.tv/storage/app/profiles/imran_1572858789.jpg</callee_image>
      <appointment_id>3949</appointment_id>
      <caller_cc_id>980381</caller_cc_id>
      <callee_cc_id>976722</callee_cc_id>
    </userInfo>
    <opponentsIDs>
      <opponentID>976722</opponentID>
    </opponentsIDs>
  </extraParams>
</message>

which is something that a user with ID=980381 sent to current iOS user.

Can you comment it somehow?

Maybe you send a hungup after call timeout (recipient) does not answer?

What I can recommend is to check iOS app timeout settings (AnswerTimeInterval) https://developers.connectycube.com/ios/videocalling?id=settings-and-configuration

and make sure you have same values for both iOS/Android

Please double check it

iamimsh commented 4 years ago

Helo @DaveLomber

I have same values set for iOS and Android for timeout.

I think you didn't get the problem yet..

If you see 'ios-to-ios.txt' one more time, Chat is connected at 12:08:45 and there's no other method called.... and then after about 45 seconds, there's a hangUp signal at 12:09:24 which is common.

It's supposed to be like... when chat gets connected at 12:08:45, I should receive didReceiveNewSession which never happens.

Refer to these lines from the below code. 2020-03-01 12:08:45.764 rtc::[RTCClient] Signaling channel connected 2020-03-01 12:09:24.025976+0300 timeviewer[1262:426083] [Chat]: RCV:

2020-03-01 12:08:45.763629+0300 timeviewer[1262:426086] [Chat]: Connected
Debug sockets: connected to chat
2020-03-01 12:08:45.764 rtc::[RTCClient] Signaling channel connected
2020-03-01 12:08:45.764387+0300 timeviewer[1262:426083] [Chat]: SNT: <presence/>
2020-03-01 12:08:45.764907+0300 timeviewer[1262:425438] [Chat]: SNT: <iq type="get" id="F48E7D89-2491-4FC0-9CC0-F428F995C104">
  <query xmlns="jabber:iq:roster"/>
</iq>
2020-03-01 12:08:45.765695+0300 timeviewer[1262:426086] [Chat]: SNT: <iq xmlns="jabber:client" type="set" id="9A3F795E-22FA-41AB-BBE3-B2CAD05DC890">
  <enable xmlns="urn:xmpp:carbons:2"/>
</iq>
2020-03-01 12:08:45.993458+0300 timeviewer[1262:425438] [Chat]: RCV: <iq xmlns="jabber:client" id="0A4A6969-2A53-4045-A278-D6619775A5DB" type="result" to="976722-1831@chat.connectycube.com/D24B933F-79F3-401C-B473-E873EC274F49">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
    <jid>976722-1831@chat.connectycube.com/D24B933F-79F3-401C-B473-E873EC274F49</jid>
  </bind>
</iq>
2020-03-01 12:08:46.348245+0300 timeviewer[1262:426083] [Chat]: SMT: <enabled xmlns="urn:xmpp:sm:3"></enabled>
2020-03-01 12:08:46.676008+0300 timeviewer[1262:426086] [Chat]: RCV: <iq xmlns="jabber:client" id="9A3F795E-22FA-41AB-BBE3-B2CAD05DC890" type="result" to="976722-1831@chat.connectycube.com/D24B933F-79F3-401C-B473-E873EC274F49"/>
2020-03-01 12:08:46.677205+0300 timeviewer[1262:426086] [Chat]: RCV: <iq xmlns="jabber:client" id="F48E7D89-2491-4FC0-9CC0-F428F995C104" type="result" to="976722-1831@chat.connectycube.com/D24B933F-79F3-401C-B473-E873EC274F49">
  <query xmlns="jabber:iq:roster"/>
</iq>
2020-03-01 12:08:46.678104+0300 timeviewer[1262:425996] [Chat]: RCV: <presence xmlns="jabber:client" from="976722-1831@chat.connectycube.com/D24B933F-79F3-401C-B473-E873EC274F49" to="976722-1831@chat.connectycube.com"/>
2020-03-01 12:09:24.025976+0300 timeviewer[1262:426083] [Chat]: RCV: <message xmlns="jabber:client" id="5e5b7bc397658cd906b7acdb" to="976722-1831@chat.connectycube.com" from="980381-1831@chat.connectycube.com/F10AE73F-D7A2-487D-BEBC-1B7554D0EC1D" type="headline">
  <extraParams xmlns="jabber:client">
    <callType>2</callType>
    <callerID>980381</callerID>
    <moduleIdentifier>WebRTCVideoChat</moduleIdentifier>
    <platform>ios</platform>
    <sdkVersion>1.2</sdkVersion>
    <sessionID>13EB07BB-D896-44B6-92F8-1A5875E31EC6</sessionID>
    <signalType>hangUp</signalType>
    <userInfo>
      <callee_name>Imran mohammed</callee_name>
      <caller_name>timeviewer</caller_name>
      <is_video>false</is_video>
      <start_time>2020-03-01 12:08:38</start_time>
      <duration>10</duration>
      <caller_image>https://dev.timeviewer.tv/storage/app/profiles/timev_1575789263.png</caller_image>
      <callee_image>https://dev.timeviewer.tv/storage/app/profiles/imran_1572858789.jpg</callee_image>
      <appointment_id>3949</appointment_id>
      <caller_cc_id>980381</caller_cc_id>
      <callee_cc_id>976722</callee_cc_id>
    </userInfo>
    <opponentsIDs>
      <opponentID>976722</opponentID>
    </opponentsIDs>
  </extraParams>
</message>
2020-03-01 12:09:24.027 rtc::[Signaling Processor] - Did receive signal: hangUp from: 980381
iamimsh commented 4 years ago

@DaveLomber, Is there any update on the above?

marab2 commented 4 years ago

Hi Dave, I hope all are well. We are an enterprise application who is facing the same issue in our R&S department, can anyone please try to investigate further to find where is the issue is? Thank you

DaveLomber commented 4 years ago

@iamimsh thanks for pointing me here https://github.com/ConnectyCube/connectycube-ios-calls-sdk-releases/issues/1#issuecomment-593441026

Then, what I think is the problems seem on a sender's side, not a recipient's.

In general, let me explain how it works under the hood.

When a UserA calls UserB - then UserA starts sending a call signal each 5 seconds (this is dialing time interval here https://developers.connectycube.com/ios/videocalling?id=dialing-time-interval ) And we do it until either a UserB answer, to until a answer timeout happened (this is an answer time interval here https://developers.connectycube.com/ios/videocalling?id=answer-time-interval)

In your case, by some reason, an iOS user does not receive periodic call requests when another iOS user calls.

Here is what I propose as the next steps:

  1. make sure you set a dialing time interval at iOS side to 5
  2. need to check what's happening at caller's side (iOS) logs - dies the user sends periodic call signals or not. Seems not. But this is something to check as the first things, to at least understand at which side the issue is

@iamimsh could you please check these 1 2

iamimsh commented 4 years ago

@DaveLomber , Thanks a lot. It worked. dialing time interval was set to 45 seconds, equal to answer time interval.

Now I changed it to 5, it works.

Can you also help with other issue? https://github.com/ConnectyCube/connectycube-ios-calls-sdk-releases/issues/3

DaveLomber commented 4 years ago

@iamimsh great to hear it!