search

hanenehrizi / sipdroid

Automatically exported from code.google.com/p/sipdroid
GNU General Public License v3.0
0 stars 0 forks source link

Workaround Android 1.5 UDP receive bug #166

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Try to register to an Asterisk server with qualify=yes over wifi, port
5060, protocol UDP
2. Sipdroid never receives the SIP/200 OK packet from Asterisk after
registration, it only receives the OPTIONS packet.
3. A wifi airdump from a laptop confirms that both packets are sent, 2nd
one is sent very soon after 1st one.
4. Android doesn't see the 2nd packet, so it never sees the registration
success -> Registration times out
5. This is due to a bug in Android and not Sipdroid, see
http://code.google.com/p/android/issues/detail?id=4444
6. However this bug prevents Sipdroid from being used

What is the expected output? What do you see instead?
Registration successful, SIP/200 packet seen

What version of the product are you using? On what operating system?
Tried both version 1.1.3 beta from the Market, and SVN r340.
Running on Android 1.5, HTC Hero. Build number 2.73.405.5

Which SIP server are you using? What happens with PBXes?
asterisk.clamav.net, pp.eurovoice.ro.
Cannot register on PBXes (invalid username/password), and PBXes uses TCP,
so this bug doesn't apply.

I have attached a patch to workaround this issue: whenever an OPTIONS
packet is seen we assume registration was successful (I fake a SIP/200
packet being received via a SipProviderListener).

Original issue reported on code.google.com by edwinto...@gmail.com on 30 Oct 2009 at 4:23

Attachments:

GoogleCodeExporter commented 9 years ago 
It's looking obscure to me that a SIP packet would get lost within the kernel 
or 
framework. The SIP protocol uses retransmissions over UDP if the network looses 
a 
packet. So it should still work even if a packet goes lost.

I think you made two mistakes: First your implementation of OPTIONS seems to 
have the 
bug. And second your testing for the "lost" packet: tcpdump is not a good test. 
Not 
seeing a packet there does not indicate that it is actually lost in the stack.

Original comment by pmerl...@googlemail.com on 30 Oct 2009 at 11:18

GoogleCodeExporter commented 9 years ago 
SipDroid doesn't receive it either, I dumped all packets it receives in the log.
Yes Asterisk does retransmit UDP packets, but it retransmits both (OPTIONS +
SIP/200), since it can't know which one is lost (its not TCP).

But ok, if you don't feel like adding a workaround for a bug that is not 
sipdroid's,
I'm fine with that.

Original comment by edwinto...@gmail.com on 31 Oct 2009 at 7:40