I have problem with socket communication - > SIP server and android devices.
I can’t send SIP packet over TCP bigger than 800 bytes.If the packet is < 800 bytes everything is OK. There is a successful TCP handshake established before try to send SIP packet and still nothing.
I send the data like this way;
Socket socket = new Socket(ip,port);
OutputStream out =new OutputStream(socket.getOutputStream());
out.flush();
out.write(msg);
There is no problem with send function. Strange thing is that some packets are delivered to server minutes after being send from devices for SIP packets > 800 bytes.
If we try to send other data not SIP with size of packet > 800 bytes everything is OK and server receives it. The problem is only with SIP packets > 800 bytes. This problem happens not for all android devices. For example:
Galaxy s plus – problem.
Nexus 4 – problem.
Nexus s – no problem. and etc.
The issue is resolved if I split the SIP packet at two parts, however I would like to find out why SIP data isn’t flushed and other data is sent immediately. There shouldn’t be any difference.
You didn't provide information about versions, but I bet you have the problem in Android's 4.0.*.
I also bet the problem only happens when you use the port 5060 over TCP.
That is a known problem in those Android versions, and the current workaround is either to update to Android 4.1(and you can't ask users to do that!) or to avoid those settings.
Any other port or UDP will work.
You can find here one bug report.
Related
I'm making an Android application getting data from a USB device (mode USB host). I read the document at https://developer.android.com/index.html and also some posts in stackoverflow and I found that they use sometimes bulkTransfer(), sometimes controlTransfer() but I can't find out the difference between two method and when do we use each one? Could anyone please give me some suggestion?
Control Transfer is mainly used for sending commands or receiving a device descriptor. It is normally used when setting up a device. The typical packet length is 8 bytes for low speed devices and 8, 16, 32 or 64 bytes for high speed devices. Data which is transferred via this method is formatted into three packets:
Packet 1 – Setup: The packet which contains the address and endpoint number
Packet 2 – Data: The data being sent
Packet 3 – Status: Where the device acknowledges whether the setup packet has been received and read correctly without errors.
Bulk Transfer is used for sending large packets of data to your target device. Printers and Scanners generally follow this transfer protocol. Bulk transfer has built in error correction to ensure that data is transferred and received without error. The process is considered complete when the amount of data obtained is equal to the amount of data requested. This transfer method is not ideal for time sensitive applications since there is no latency guarantee.
I am facing weird problem in receiving udp packets on Sony Xperia Z tablet. My application didn't receive many udp packets. So I have rooted the tablet to install the shark app and captured the network traffic using shark app after rooting the device. When I analyzed the report, the device has received all the packets but my application did not receive many of them. If the application didn't receive any packets, issue could be the packet filter which blocks broadcast packets. Here, my application receives few packets but misses packets received by device. I have not observed this issue with samsung tab 2 and motorola xoom tablet where it receives all the packets. It sounds like there is no code issue. Have anybody faced similar problem? Let me know if you have any suggestions or inputs that I can try.
UPDATE:
I have added my comments below.
I'd tell you a UDP joke, but you might not get it.
Packet loss is a documented feature of the UDP protocol.
UDP protocol does not guarantee that the package will be delivered to the addressee.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
I have found why my app missed some packets received by device. I have set datagram socket receiver buffer size to small value. I removed this code setting buffer size and then it strated receving all the packets. By default, android sets buffer size as 163840B but I set the size to 64 bytes. It is working fine with default buffer size set by android.
I have a problem with receiving UDP packets. My environment is running Android 2.1 on ARMv7. With C socket programming, I use recvmsg to receive packets from kernel but occasionally there are some packet loss events. The sender and receiver are in the same LAN so it's no doubt that packets shouldn't lose. And I proved it via Wireshark.
However, after I replaced recvmsg with recvfrom to receive packets, packet loss event didn't occur anymore.
I'm sure the return value of recvmsg is always more than 0, meaning no error happens.
Is it possible that some packets are dropped in kernel-space only when using recvmsg ?
Yes, it's possible. UDP is unreliable. If dropping of UDP datagrams is creating a problem, then something is very wrong with your design.
Check your socket for drops via cat /proc/net/udp.
This recv man page seems to indicate that recvmsg does not block, while recvfrom does block, at least by default. It's possible that you are calling recvmsg and there are no packets available at that moment. If you called it repeatedly I suppose you might see all your packets eventually just like you did in wireshark.
I'm running some code on the nexus one - and I am having a very strange issue. The "server" sends UDP packets out on the multicast socket that the phone is joined to. The phone receives and sends stuff to the multicast group fine, but it appears that the phone chokes when it receives a large number of packets at one time.
For example, the server will occasionally send out 80 or so 512 byte packets in one go around. The phone starts receiving the packets, but then at the 31st packet (~16KB of data) the receive hangs (indicating that there is nothing on the socket anymore.) I've done wireshark testing and stuff so I know for sure that the packets are not being lost. Even if some are being lost, it is very strange that EVERY test produces the same result --- a large amount of data gets jammed onto the socket at one time, but the socket only allows me to socket.receive() for 16KB worth of data.
I have tried socket.setReceiveBufferSize() with a variety of values (up to 1MB) -- but that doesn't seem to work. Interestingly, a call to getReceiveBufferSize() tells me that the socket should hold roughly 100KB worth of data.
If I tell the server to slow down its send method (which I cannot deploy, I can only do that for testing purposes) - everything works fine, presumably because the packets aren't jammed onto the phone's socket all at one time (ie. I tell the server to wait 1/2 a second between packets.)
Has anyone else experienced this - if so - how did you get around it? I cannot switch the application to TCP.
Thanks!
Dan
PS. The Java code works fine if I run it on a regular machine...
Nevermind - I fixed it by moving onto a closed network where there is 0 possibility for loss and weird things -- not sure what was up with the network I was on (which was supposed to be goo) - but at least it works!
Dan
I am working on making RTSP url to work on Android.
I have used MediaPlayer and VideoView to play the RTSP url but both of them fail to play in G1 Device and emulator. Error is PVMFFailureiin PLAYER_INIT.
So I thought of implementing a RTSP client from scratch. I have developed a small application, it exchanges all the messages (DESCRIBE, SETUP, PLAY, TEARDOWN). But the problem is after PLAY, I should receive the RTP packets at client_port as mentioned in Transport header but TCP dump shows the following messages. I think UDP packets are coming but not received at the application.
11:38:50.213394 IP ew-in-f177.google.com.6970 > 192.168.1.2.6970: UDP, length 444
11:38:50.213451 IP 192.168.1.2 > ew-in-f177.google.com: ICMP 192.168.1.2 udp port 6970 unreachable, length 36
Please let me know how to solve this issue.
OpenCORE, the multimedia engine in Android, is rather stringent about sticking to various standards. Some things that may work in the wild (e.g., MP3 over RTSP) are not supported because they are not in the respective spec. Leastways, that's what we have been told.
Hence, it may be that the media you are trying to stream is slightly out of spec, or the server is slightly out of spec. You may wish to try to find some RTSP stream known to work on Android, get your player working right using it, then focus on getting it to consume your own streams.
Some handsets (I don't know whether Android falls in this category or not) include a firewall on the device. In order to receive packets you may have to perform a hole punch (i.e. send a dummy packet to the server. This will create an allow rule on a firewall running on the local device. It will also create the appropriate NAT mapping if necessary as well.)
Is the device on WIFI or on the carrier's network (which carrier)?