I am working to build the PJsip project for iOS 16(i.e Xcode 14) where I am using the “c” based library PJsua. I am able to make calls using free SIP accounts created on Antisip.com.
Problem: Not able to hear any sound on my iOS device after the call gets connected to my VoIP server(which is modified to play only the recorded message).
I have analyzed the server & mobile app logs but have not observed any errors. Also haven’t noticed any difference in server logs for calls done via old and newly built PJSip project.
I did a lot of research on it but am still stuck on this sound issue. I am not sure if I am missing anything related to audio configuration or if anything is specifically required for iOS 16.
Other details:
TransportType: TLS
OpenSSL: 1_1_1r
Server: kamailio (5.2.0 (x86_64/linux))
Kindly help if someone has any idea on this.
NOTE: Although, not facing any issues and able to hear the voice if the call is made using previously built(using iOS 11 SDK i.e Xcode 9) PJsip project.
Related
I have been searching for the past few days for a solution but havent been able to find any.
I am developing app to pair and connect to bluetooth device using a mac address.
I found one private framework API, but even that one i cant make it work, since for some reason i can not include the headers from the private API.
Anyone knows any information? How to achieve this on iOS, or is it 100% impossible to do this at the moment, until Apple decides to open up the bluetooth libraries to the developers?
EDIT:
I was looking into the BeeTee app, and using the private API BluetoothManager.framework, but for some reason it doesnt work on IOS 10 & Xcode 8.1
Has anyone managed to make it work?
I know it is private API and most probably wont pass on App Store, but that doesnt matter at this moment, since i am looking just to test the concept, wont need to publish app at this moment.
Thanks
For past few weeks I am trying to get the Kurento group calls to work with IPv6. However no success so far.
It seems that till M52 release of WebRTC (https://bugs.chromium.org/p/webrtc/issues/detail?id=5871), the WebRTC framework didn't support IPv6 for iOS. This was fixed in the M53 release of the iOS framework in August 2016.
However, it seems that with the latest M54 release of the framework group calls don't work with Kurento. First I tried to make it work with the official Kurento Group Call Java sample. In the end the video and audio from iOS goes to Chrome. But video and audio from Chrome doesn't come to iOS.
Then I found the Nubomedia Kurento iOS project. (https://github.com/nubomediaTI/Kurento-iOS). They have a sample for Kurento Room Project (Java Based) with iOS client. I managed to get it to run with Kurento 6.5 and 6.6 tagged commits. (For some reason the HEAD checkout doesn't run, even after adding 6.6.1-SNAPSHOT dependencies. It crashes with an exception during startup citing port conflict. Though I ensured that no other process was running on the same port.).
With IPv4 network, the Kurento Room Demo iOS project from Nubomedia runs properly and I am able to conference with one participant on Chrome and one participant on iOS.
However, on IPv6 network this demo fails. When I looked closely "WebRTC.framework" in the Nubomedia Kurento iOS project was checked in on Jul 29. Since M53 release of WebRTC.framework happened in August, it is understandable that this framework doesn't work with IPv6.
So I downloaded the M54 release of the framework from here: https://github.com/Anakros/WebRTC-iOS/releases/tag/13869.6.0
I replaced the older version of the framework in Nubomedia Kurento iOS project with this latest one. However, when I tried the Kurento Room Demo with this new build, the results were the same like I had obtained with the official Kurento Group Call Java sample. The video and audio from iOS goes to Chrome. But video and audio from Chrome doesn't come to iOS.
At this point, I don't have any clue on how to move forward to get Kurento Group Calls to work on iOS with IPv6. Hence the question:
Has anyone managed to get group calls working with Kurento on iOS with IPv6 only networks as required by Apple?
If yes, a few pointers on how to get it to work will be very helpful.
--
Note: I had asked this 4-5 days ago on Kurento Google Groups. But didn't get any answers. So trying here.
My app uses BLE (Bluetooth 4) to connect to a physical peripheral.
My users and I have repeatedly encountered a bug where, at some point, the app stops connecting to the peripheral - you can see an indication that the BLE peripheral is discovered and the connection was established, but then few seconds after, the connection is dropped.
Things go back to normal only after restarting the iDevice.
I’ve done a very long work on checking it and researched this issue thoroughly, until I got to the conclusion that this must be a bug in iOS (tested with 7.1, but probably occurs on 8.0 as well).
My tests and findings:
Occurs with every BLE supporting iDevice.
Occurs with both my own BLE peripheral and with other 3rd party BLE products, both known to work perfectly in normal cases.
It can sometimes work well for even 50 launches, but then eventually it’ll fail.
Network & factory settings reset did not help.
Tested and occurred with various applications: ##
My own app.
Clean new Xcode project that’s only scanning for peripherals and trying to connect to the first and only discovered peripheral.
Apple’s BLE example app: Health Thermometer (with relevant modifications since I don’t have this particular peripheral).
3rd party apps, including the generic LightBlue.
Important note: Every one of the options above worked perfectly for a while (multiple launches), at some point suddenly stopped and then worked again after a restart of the device.
The connection procedure seems to fail when trying to discover the peripheral’s services - i.e. it gets discovered and connected normally, but when initiating discovery of services, it stops responding (didDiscoverServices isn't called).
I have of course tried many approaches found online with no luck.
Can anyone shed some light on this problem?
Is it a known issue?
Was it fixed in a recent iOS update?
Is it going to be fixed?
You can imagine the negative affect such an issue has on my users’ experience, as BLE connection is essential to the product.
I'll appreciate your advice and suggestions on how to solve it.
Thanks!
Update:
Apple responded to my tech support request:
Bottom line(s):
They said they had fixed some BLE related bugs in iOS 8 and urging us to test if it still happens in iOS 8.
They said to start with that and if not, try to diagnose the problem with a utility app they provide.
So far for me it didn't happen with iOS 8, but on the other hand I can see posts about other Bluetooth issues, that are not necessarily related but who knows.
Full answer:
I’m responding to your finding that you and your customers find that
after some point of use, iOS BLE fails to maintain a connection. You
indicate that the problem was identified with iOS 7.1. There have been
issue regarding iOS BLE which have been reported and have been fixed
with iOS 8.0. To best determine whether your issue has been addressed,
of course the simplest means would be to install iOS 8 and to see if
the issue can be replicated. However, as you report that you can
replicate the problem on your deivce with iOS 7.1 the first thing
would be to obtain the Bluetooth Server profile, install it to your
deivce, replicate the problem, then obtain a BLE Server log when the
problem occurs. The profile will have the BLE server report additional
logging details which can help to report issues that the server
encounters. We can see if the issue is one which has been reported
previously. Something to consider is that for all new bug report
issues, Core Bluetooth engineering is requesting that all issues be
regressed with the currently shipping version of iOS - that is 8.0.
For customers with iOS 7.x, there will be no more iOS 7 updates - all
software fixes and bug fixes will be with iOS 8. For this reason, only
issues which are reported with iOS 8 will be investigated. You can
obtain the BLE server profile from the Apple Developer bug report web
page https://developer.apple.com/bug-reporting/ios/bluetooth/. The
instructions for installing the profile and capturing the log, are
presented on the web page. If you capture a log with iOS 7.x, you can
send it to me for review. However, this will be somewhat of an
academic exercise - to know if iOS solves the issue, or whether it
persists, we will need to see if the issue occurs under iOS 8.
Something to keep in mind, once you update a device to iOS 8, you will
not be able to restore it to a previous version. I’m happy to
review your results. If however, the problem persists under iOS 8,
it’s best to submit a bug report to get Core Bluetooth engineering’s
attention on this matter. You can submit a bug report using the Apple
Developer bug report web page. - http://bugreport.apple.com
So it looks like the problem is solved with recent iOS update (either 8.0 or 8.1).
We have an application that's using a Socket Mobile scanner (a CHS 7Xi, in particular) to scan bar codes from a variety of sources. We're using the latest SDK. It appears that sometimes—not always—when the app resigns and then regains active status, the SDK is unable to reconnect to the device. We get a few error notifications through the delegate protocol (specifically, ESKT_UNABLEINITIALIZE), and then nothing. Fixing this usually involves quitting the app, restarting the scanner, and starting over.
Does anyone have any idea why that might be, or how we can prevent this?
EDIT: hrm. The problem described in this Socket Talk blog post sounds familiar. Though it claims that the issue was long-since fixed in the SDK we're using (10.0.9.10686).
It seems like all large downloads timeout on iOS6 using ASIHTTPRequest.
Does anybody know of any forks that have updated this library for iOS6. I love this library and really do not want to have to switch.
EDIT:
This issue is not specific to ASIHTTPRequest. Upon testing FSNetwork, MKNetwork, AFNetwork, and NSURLConnection they all fail.
A sample project can be downloaded from here:
https://github.com/BLamy/NetworkTest
It must be built to an actual device running iOS6 (I used an iPad2 unsure if that makes a difference).
I was having the issue with uploading. The solution I found was to set the cachePolicy of the urlRequest to NSURLRequestReloadIgnoringLocalAndRemoteCacheData. (There were a few other networking bugs I encountered too which only occurred on iPhone 5.)
Are you getting the timeouts on apps that are build against iOS SDK 5.x running on iOS 6 (ie your old builds. If you don't have access to an old build, how about the one you have existing on the App Store?).
Or are your symptoms ONLY occurring for new builds with Xcode 4.5 against iOS SDK 6.0? If the latter, and you really don't want to give ASI up, (and you don't want to implement any of the new iOS functionality), then you could consider building against iOS SDK 5.x instead of 6.0. See my answer here for instructions.
If you need to implement new iOS 6 features, or iOS 6 actually broke your implementation of ASIHTTP (built against iOS SDK 5.x), then you should consider other networking options. It's been over a year since Ben advised developers to seek other options, with good reason.
iOS6 has serious problem related to Wi-Fi. We use ASIHTTPREQUEST. We find small file downloads work fine, in some case large file(10MB above) downloads too, but after the download, we keep the device idle for a minute, again you try to add operation to the queue. The app crashes.
Initially, we got many Network unavailable alerts, though the internet was available. Later, we changed the Wi-Fi setting security mode WAP to NONE. Then for sometime we did not find the network unavailable error, as well downloads were ok..
However, when the server itself becomes loaded, the connectivity and download becomes to halt at mid of the progress. I have noticed this behavior, even in native SDK facebook app.
The simulators work very fine, even the devices like iPad1, iO5.0, iPhone 4 with iOS5.0, the never crash.
I sum up..Apple half baked the iOS6.0, may be the iOS6.0 is suitable only for iPhone 5,the new antenna structure. Unless Apple fix the iOS6.0 issue may not be solved.