I am using Linphone Coe 3.10.2 SDK. Server supports TCP and UDP. When TCP is enabled, I cannot call or receive calls at all, it does nothing. When I switch my phone to UDP, every time it says that User is busy, my screen goes to IncomingCallView for one second before connection is broken and it says "User is busy". On Android, it is working normally. And yes, I am not talking about background modes, we have implemented VOIP push services for iOS 10.
I recently have the same problem. All you need to do is set the corret codec. Ask your sip provider what codecs you should
Related
I am using Apprtc library for the real-time connection.
this is my server host URL #"https://appr.tc". Connection successfully established to any network, but in the audio/video sense
audio/video only works on same/private network iOS to iOS or iOS to Android
in public network audio/video only work in iOS to Android , Not working iOS
device to iOS device .
do you have any idea ?
TL;DR You need to bring up a TURN server, and configure the client with the addresses of your TURN server.
WebRTC attempts to connect two peers directly, but that's not always possible in all network configurations (e.g. when both sides are behind a NAT or a Firewall). In these cases, WebRTC will fallback to using a TURN server. It's basically a server that both peers can connect to, and it forwards packets from one to the other.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
I have a navigation application that works with both CoreLocation (Backgrounding mode Location updates) as well as GPS data provided over a UDP connection from an external sensor.
I've noticed that when I background the app the socket goes down (which likely makes sense).
What is the procedure to keep the socket open in backgorunding?
Idea
I thought perhaps to register as a VoIP app - would keep the socket open but it looks like that works differently now.
The documentation suggest implementing setKeepAliveTimeout:handler: but this appears to be deprecated.
I'm not sure exactly how to proceed. Any ideas? The best I can come up with is a hack to have my location-update handler run a check on the socket so see if there is new data - but I'm assume there is a legitimate way to do this.
When the phone goes in stand-by all the UDP socket are closed and only TCP connection can be used. Yes probably with VOIP app you can use the UDP but in that case your app will be reject because your don't use a real VOIP service. I had the same problem ... In my case, even if the phone is in background, I want to send UDP message to a domotic system but is not possible.
I want to send UDP packages in a local network using GCDAsyncUdpSocket.
My fear is that at some point UDP packages will be sent via LTE because of the newly introduced "WiFi assist" from iOS 9.
Is there some way I can pretend iOS 9 from passing my traffic to cellular network, and instead require it to always use WiFi?
Thanks a lot for any ideas!
I think you can use "Reachability" to detect if the phone is connected to a wi-fi or to cellular data and then avoid to send message or manage the that particular condition. You can also ask to the user to disable the wi-fi assistant with a popup just to be sure to avoi the problem.
I'm trying to build a hack so that I can echo incoming TCP packets to local UDP (to connect to 3rd party control surfaces that don't support TCP).
I don't care if Apple won't approve it, I only need to do this on my own iPads. I tried pretending that my app supported audio but that didn't work.
Is this posible (without jail breaking?)
I haven't actually tried this but you might be able to do it by setting the app up as a VoIP app.
From the developer documentation:
Rather than keep VoIP apps awake all the time, the system allows them to be suspended and provides facilities for monitoring their sockets for them. When incoming traffic is detected, the system wakes up the VoIP app and returns control of its sockets to it.