What steps will reproduce the problem?
Startup application with PJSIP at iPhone 3G with iOS 4.
Make outgoing call. Start conversation.
Wait 20 seconds.
What is the expected output? What do you see instead?
Actual result: Outgoing call cut off at 20 sec. The call breaks on the phone on which I have called. And the call ends normally according to the log-file.
What version of the product are you using? On what operating system?
I use iPhone 3g with iOS 4, iPhone 2g with iOS 3, iPhone 3gs with iOS 4, iPhone 4 with iOS 4
I tried to use PJSIP 1.0.3, PJSIP 1.6, PJSIP 1.7
I have tried another sip clients at this Wi-Fi network:
Fring - the problem reproduce
Nimbuzz - the problem NOT reproduce
Please help me to solve this problem.
Sounds like you need a keepalive mechanism on the SIP connection. PJSIP supports this. Maybe you will have to enable it.
Use a packet sniffer to see what is actually going on.
You'll probably have more luck at SuperUser. Having said that, if one SIP client doesn't have this problem, while the other does, your first step should be to look at what's different between working and non-working clients.
When you say the call cuts off do you mean that media just stops flowing? Does something send you a BYE? (If the media stops flowing, and you terminate your end of the call, does the BYE go out and do you get a 200 OK back?)
Is it possible to use something like Wireshark on the far side of your wireless access point? In other words, can you see media traffic on the first hop past the Wifi network? When the call's cut off, what do you see?
Related
I am trying to reverse engineer the API of an IoT device using mitmproxy. My setup is an iphone, computer running on MacOS 10.14, and an IoT device (watering pump) that can only access the wireless network after being plugged into the computer via USB connection, i.e. a not genuinely WiFi device. My phone is configured to point to the computer, which is running mitmproxy on a standard configuration.
When I send instructions from the app controlling the device on my phone to the device itself, presumably these instructions are sent to the computer, to the device cloud server, and then to the device. With these assumptions, one would think that they would see the flow of POST requests in mitmproxy before observing the results of those instructions. That is, if you send an instruction to turn on the pump, you'd think you'd see POST request containing that instruction show up in the mitmproxy flows before you see the pump turn on.
However that is not the case here. What happens is that, when I send instructions from the app, I observe the expected behavior from the IoT device, and then the flow of requests appear on the mitmproxy console seemingly at random. There seems to be no determinate relationship between the instructions I send and the requests that appear; they show up 5 seconds later, 5 minutes later, or 30 minutes later. Is this an intentional security feature? To somehow jam MITMproxies so that hackers cannot easily isolate the knowledge of which packet is performing which instruction? Or is it just something that I am doing wrong? Does anyone have any ideas as to what could be happening hear and potential solutions for making the flow of requests appear in real time? Ty
It's on Android. I have a chat tool that sends/receives packets. On the client side I parse the packets and display the message to users. A traditional chatting tool.
The problem is the tool works quite well on other devices on wifi, Edge and 3G, except the HTC One. On HSDPA (3G) we notice that the client cannot receive the packets as usual. It's stuck there until we reset the socket.
I debug and found that the DataInputStream.read() method (in the while loop to listen to the incoming data) is stuck there. I attached Android source to go deeper but not until the java.libcore package of Oracle.
I guess the issue is because of the Sleep mode of the HTC One. But on foreground, the app cannot receive the message too, until we open a new socket (with a long timeout, about 4 minutes, which is too long for a chatting tool).
As I researched, I try to install the SmartSync Disabler for HTC and the situation seems to be better. When I decompile the tool, it only sets 2 parameters: sleep_mode_mode to off and data_on_wifi to off, which means on the sleep mode, SmartSync does not disconnect wifi.
My question is has anyone encountered this situation before on HTC One in particular? What could be the reason?
Many thanks!
We have just got the same problem.
Try to play with this methods
void setReceiveBufferSize(int size)
void setSendBufferSize(int size)
I.e. make it much smaller.
Despite working earlier, my socket chat app now refuses to write to socket on the iPhone!
It works fine on the simulator and again, used to run fine on my phone. I don't really know where to start troubleshooting this issue --- just seems weird. My server doesn't detect anything trying to connect.
Any ideas on how to start troubleshooting this?
Thanks tons.
I did run into a problem where using sockets on the iPhone would not open up the cell phone network unless something else opened it first. I had to run an http call to a generic web site first, and then the sockets would communicate normally. Try putting a call, like sendSynchronousRequest, to a generic web site, like www.apple.com, before opening your socket, and see if it works in that case.
I need to stop wasting all you nice peoples' time.
Long story, my friend updated to iOS 5.1. Now the 3G network reads 4G on iOS 5.1. So I turned off my (5.0) wifi to see if mine cell network was "4G" (which, of course, it wasn't).
But yeah, having turned off wifi my app could no longer join my locally hosted server...
I grabbed Charles though, and it looks handy, so thanks for that anyways. Also Owen's comment about the cell network originally made me think about checking my wifi, as my app shouldn't even be using the cell network yet. But I'll keep in mind what you said for the future.
Thanks everybody!
I am trying to get a simple sockets program working on the Ipad.
To do this I am using the CFStreamCreatePairWithSocketToHost command.
It works fine on the simulator.
The problem is that it does not work on the iPad (I checked connectivity issues using the iPad's safari, and everything seems fine).
What I want to do is have the iPad open a connection to a PC. The reason I used CFStreamCreatePairWithSocketToHost was that I found a simple 10 line sample program which does this.
My questions:
1 - Does CFStreamCreatePairWithSocketToHost work on the iPad
2 - Can anyone direct me to a simple sample for ipad socket communications (I tried apple dev, and google. No sample that I found could be considered simple (less than 50 lines of code...))
Update:
Also tried sockets and NSHost, both withAddress and withName.
The results were the same: works perfectly inside the simulator, but does not work on the iPad.
I would suggest to use the socket-wrapper AsyncSocket. The download comes with a sample project.
edit
the most recent version can be found here
The low level APIs don't turn on the cellular radios. Use a very high level API to connect, then after the radios are turned on, disconnect if necessary, and (re)connect via BSD sockets.
An HTTP request to a server near the same destination IP would probably be sufficient.
Found the problem...
There was a "rouge" proxy problem in my organization, which was forwarding the saffari, but not my program (even thoughthe safati was not on an http port).
Solved, and thanks for your help.
There is a sample code of apple named "reachability" which tells us the network status of the device, wifi or edge/gprs, but I couldn't see any documentation or sample code regarding gathering if the device is on 3g or not while accessing to internet. I also googled, but no hope. Is it possible to do that, if so how?
According to Apple representatives, this is not currently possible. See this message on the Apple forums (registration as an iPhone developer required).
Maybe there is a server side solution to your problem? I assume that your app requires a fast internet connection to operate - maybe you could measure latency, packet loss etc on the server side and take appropriate action if the connection is too slow?