We have an app that calls two parties, and when they accept the call we dial them into the same conference call. One issue we have observed is that sometimes both parties will be connected, but one side isn't able to hear the other side. In these cases I usually verify that two calls were indeed created by Sinch (via the Sinch call logs/callbacks) and that they are using the same conference ID (via our own logs.)
I have seen two different types of problems related to this -
1. The "callDidEstablish" delegate method was hit, but a Sinch call was never actually created according to the Sinch logs.
2. Both calls were created, but there is just no audio.
I am not sure if (2) could potentially be an issue with the AudioSession? Any guidance in helping debug this type of issue would be much appreciated. Again, this doesn't happen every time, but we do see it quite often.
Related
I'M Trying to implement a feature with an app include a call inside it. I already implemented the call kit with a lot of socket events and everything is works fine but there's an issue in that:
once the app is locked and get new incoming call, and answer the call, the socket is open and event reach to the other side, but joining the conference is not working till I unlock the device!, have any one any idea about this issue or can help ?
Dear Connectycube Team,
I hope this email finds you well.
Our company has integrated Connectycube into our application, which primarily relies on video calling for communication between users and service providers. To ensure a seamless user experience, it's imperative that the video calling system is robust and reliable.
Unfortunately, our development team is facing challenges in making the system highly robust and 100% reliable. The issue lies in the connection dropping when the application is killed or the phone is locked.
issue: We are trying to integrate connecticube onto cordova app. We are using callkit to implement native incoming screen. The issue is that whenever the app is killed or the phone's screen is locked, accepting the call on callkit leads to failure since the accept call function gets called before the connecticube oncall event listener is called.
I would like to request a call with your technical team to discuss this matter and receive any insights or recommendations that could improve the video calling system.
Thank you for your assistance.
Best regards,
Kanhu
Once we receive incoming call using callkit and the user accepts the call, we try to send the accept call command to connectycube. But since the oncall event is not fired immediately, we create a callback loop to wait for the oncall event to get fired. This works sometimes but fails most of the time. Is there any other way ro achieve the accept call functionalities using callkit and connectycube on cordova.
Firstly I am new to iOS development and I have extensively gone over the little documentation and tutorials there are of Apples CallKit framework, but I cannot figure out if this framework can actually block cellular calls or just VoIP calls?
The question is as simple as that, I need to know if CallKit can be used to block cellular calls, when I have predefined a list of telemarketers that use their mobile phones to call people in my country. I am just wondering if someone can give me a clear cut answer and then I could move on with my life, without having to waste more time, trying to get the CallKit to recognize incoming cellular calls.
Thanks!
Yes, you can block incoming calls using a CallKit extension
I'm running into a problem with an app that I'm building that I'm a little stuck on.
I have an iOS app (handles initiating the call via Twilio SDK) that communicates with a Ruby on Rails back-end (handles the Twilio server side implementation) to enable communication between the iDevice and the phone number being called.
The issue I'm having is that when a call is initiated accidentally (user error or misunderstanding how the app works) and the user goes to terminate the call Twilio has already received the request to create the call and it still goes through.
I've tried disabling the TCConnection and the TCDevice using their respective disconnect methods ("disconnect" and "disconnectAll"), but I'm still seeing the call go through (phone number being called still receives the call from the Twilio side of things). I haven't tried anything on the server side of things because I'd like to avoid building a set of "oh &$^$%" protocols if I can avoid it.
Has anyone experienced this before? Does anyone have any suggestions? Is there anyway to terminate calls made accidentally?
Thanks in advance!
Checking back in to share what I've discovered after reaching out to Twilio support in the event anyone finds this in the future.
From Twilio support:
For canceling a call, you can use the REST API to modify the live call and set the Status to "completed", which will cancel a ringing call and end an established call:
https://www.twilio.com/docs/api/rest/change-call-state
So, in short, build some "oh #^%$*" protocols that you can ping as necessary to actively terminate any call that you need to. Not ideal, but the options are limited.
What exactly I need is that when an incoming call come and my app is in foreground than the call must be automatically received and loudspeaker must be activated.
I have seen many post in SO saying that to intercept the calls is not possible in iOS.
But what if I use any VoIP API and make calls from it to my app[app to app call] ?
can I receive the call automatically in that case or that time also the SDK won't allow me to do so as its the core part of iOS I am too much confused.
This is not possible with UIKit, and furthermore if you did use private Apis your app would not be approved.