I use Twilio API to create video between two users. It works good if one of the users clicks on "Disconnect". But when user terminates his app, the picture "freezes". How can I disconnect user if he terminates his app (turns off internet connection, ...) ?
Twilio developer evangelist here.
I would implement the TVIRoomDelegate methods didDisconnectWithError and participantDidDisconnect so that you can clear up video connections when a disconnection is detected.
Related
First of all, this is not about VoIP.
Requirement: The user taps on a wearable device to receive an incoming call, just like FitBit.
I have tried CallKit's CXProvider and its delegate but it seems only work with VoIP related apps.
How we can answer the call using an app? I saw in FitBit wearable it is allowed to receive an incoming system call.
Spend a whole day to search an answer not able to figure it out. Please don't suggest private APIs.
We've been able to establish a VoIP call using CallKit. However, Hold and Resume operation on this established VoIP call causes one-way speech path issue. I'm able to hear far-end after I hold and resume. Far-end is not able to hear me.
I've already taken Wireshark traces and confirmed that after the resume, there is only one-way audio. Audio is not sent from my device to far-end.
Since Wireshark already showed the problem, I checked WebRTC code for media session errors. I see no errors in startSend or startPlayout (audio unit processing for send and receive)
I re-checked by CallKit integration code to confirm correct sequences
HOLD OPERATION
Press HOLD button on App UI or long-press MUTE button on CallKit UI.
App requests CXSetHeldCallAction transaction to CallKit with onHold as YES.
App receives provider delegate call back performSetHeldCallAction.
App puts the call on hold and then fulfils performSetHeldCallAction.
App receives provider delegate call back didDeactivateAudioSession.
RESUME OPERATION
Press RESUME button on App UI or HELD button on CallKit UI.
App requests CXSetHeldCallAction transaction to CallKit with onHold as NO.
App receives provider delegate call back performSetHeldCallAction.
App configures audio session (AVAudioSessionCategoryPlayAndRecord, AVAudioSessionModeVoiceChat, preferredSampleRate:44100) and then fulfils performSetHeldCallAction but remembers the call to be taken off-hold.
App receives provider delegate call back didActivateAudioSession. Using this App takes the call off-hold (resumes the call). The call is the one that was stored in the above step.
We've already raised an Apple Ticket using bugreport (with no update) and are pursuing raising an Apple Technical Support Incident (Apple TSI).
Hoping for some valuable inputs.
I am trying to record incoming and outgoing calls in iPhone... Is it possible to record calls in iOS ?
Please let me know. Thanks in advance.
Yes you can.
With the use of AudioToolbox and libkern/OSAtomic.h
First of all you need to trigger when an incoming call coming.
Fire an event when ever there is Incoming and Outgoing call in iphone?
Recording the call this is what you exactly looking for.
SO post
Note:
Apple allows these hooks only when your application in foreground.
Conditions that allow your app runs in background:
For tasks that require more execution time to implement, you must request specific permissions to run them in the background without their being suspended.
In iOS, only specific app types are allowed to run in the background:
Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
Reference link
You can go through this link below:
Record the conversation of phone - ios
There is no public API for recording the calls made (or received) by the built-in Phone app.
You will have to implement your own phone calling mechanism. You'll probably want to use VoIP. (That is what Google Voice uses, for example.) You'll need to run your own server on the Internet, or contract with an existing VoIP service. You'll want to use in-app purchase to let the user buy minutes, because it costs money to run your own server or use a third-party service.
We are experimenting with the Twilio video call SDK for iOS and we are able to establish a call between two users but now we would like to send events from one user to another. For example, one user would tap a button on his device and the event would be sent to the other device to display a sound or animation. Basically we are looking for a way to establish a data channel between both callers that we can use to send events, much like a websocket.
Thanks for your input! Regards,
Enrique
Twilio recently announced a State Syncronisation API which you can use to solve your problem , have a look : https://www.twilio.com/sync
For your case, you could setup up a "Map" item ( a map of event to device identity ) on Twilio sync which could be used by a device to push their events to Cloud to which any subscribed devices can get the info pushed to .
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.