gomac / sipdroid

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

Sipdroid appears not to respond to Asterisk qualify messages (OPTIONS) and is marked UNREACHABLE #109

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Configure Asterisk PBX to qualify clients (qualify=yes or
qualify=numeric_value)
2. Register to Asterisk PBX on the same network (no NAT, no firewall)
3. Connect to asterisk server (run "asterisk -r")
4. At the CLI, run "sip show peers"
5. Sipdroid is consistently marked unreachable by Asterisk

The example below shows a softphone and then a sipdroid peer registered to
the Asterisk PBX. They are NATed the same way, but the softphone is
qualified properly.

SOFTPHONEUSER 192.168.2.1      D   N      5061     OK (3 ms)            
SIPDROIDUSER  192.168.2.1      D   N      5060     UNREACHABLE           

What is the expected output? What do you see instead?

I expect Sipdroid to respond to OPTIONS messages sent by Asterisk PBX and
to be qualified.

What version of the product are you using? On what operating system?

Sipdroid 1.0.4
Asterisk 1.4.23.1

Please provide any additional information below.

Original issue reported on code.google.com by iiordanov@gmail.com on 8 Aug 2009 at 2:10

GoogleCodeExporter commented 9 years ago
If one sets qualify=no in the SIP extension config on the server, then things 
start 
working, obviously this is only a workaround. It would be better if OPTIONS 
were 
supported.

Original comment by schlac...@gmail.com on 9 Aug 2009 at 11:24

GoogleCodeExporter commented 9 years ago
The major problem with qualify=no is that there is nothing to keep the UDP NAT 
state
alive. If you leave Sipdroid set up with qualify=no registered through NAT long
enough, it does not receive calls anymore because the Asterisk server is unable 
to
contact it.

Naturally, the only way for us to use Sipdroid trough NAT is to configure it 
with
qualify=no, and to re-register to the server often. 

This is inconvenient and hence, this bug significantly reduces the ability of
Sipdroid to successfully receive incoming calls.

Original comment by iiordanov@gmail.com on 10 Aug 2009 at 5:24

GoogleCodeExporter commented 9 years ago
Issue 147 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 2 Oct 2009 at 8:29

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I have the same problem here !
How can I change the expiry time (I can't find any option in configuration) ?

Original comment by federico...@gmail.com on 21 Oct 2009 at 7:55

GoogleCodeExporter commented 9 years ago
I downgraded to Sipdroid 1.1.0 instead of 1.1.3 and the issue disappared.
Unfortunately I haven't backed up the versions among these and I can't find 
them any
more in the download section to try them....

Original comment by federico...@gmail.com on 22 Oct 2009 at 8:39

GoogleCodeExporter commented 9 years ago
Odd, I had the problem on 1.1.0

Original comment by sebastien.wains on 22 Oct 2009 at 8:41

GoogleCodeExporter commented 9 years ago
I'm using it into the same LAN subnet in which asterisk server is, with nat=yes 
and
qualify=no. Since yesterday when I downgraded the issue hasn't happened any 
more,
it's been always reachable. With 1.1.3, after a while it became unreachable 
(Asterisk
in sip show peers still showing its address but checking with nmap the port of 
the
device was closed, and wasn't possible to receive calls).

Original comment by federico...@gmail.com on 22 Oct 2009 at 10:31

GoogleCodeExporter commented 9 years ago
I'm not sure I understand what "issue" you're talking about.
With qualify=no, the device is not monitored.
Usually, incoming calls work with that option turned off but you can get a 
timeout at
the NAT level, which closes the ports to the device.

If you're on a LAN, no NAT is involved (as I guess incoming calls go through the
Asterisk PBX).

Original comment by sebastien.wains on 22 Oct 2009 at 10:40

GoogleCodeExporter commented 9 years ago
Yes, clearly federico.ghigo is not talking about the same problem as we're 
having. We
have a specific problem that arises with qualify=yes or qualify=N, where 
N=)number of
miliseconds Asterisk waits for reply to OPTIONS). The problem persists still, 
and has
not disappeared in v1.1.0.

Original comment by iiordanov@gmail.com on 22 Oct 2009 at 3:16

GoogleCodeExporter commented 9 years ago
I can also confirm that the issue existed in 1.1.0 . Presumably replies to 
OPTIONS are 
not implemented at all yet...

Original comment by schlac...@gmail.com on 22 Oct 2009 at 3:21

GoogleCodeExporter commented 9 years ago
The problem I had with 1.1.3 was that it was registering correctly but after a 
while
the phone was unreachable and the port on which the phone should have been
communicating with the asterisk server was closed (I used sip 'show peer XXX' 
to know
the port and 'nmap -p portnumber -sU -P0 ipaddress' to check the port state).
Obviously pinging the phone is ok. The only way I had to have the phone answer 
the
calls again was to close Sipdroid and repoen it. Concerning NAT actually I had 
doubt
on it by myself and that's why I specified that the phone is on the same subnet 
as
the server, but I believe that something concerning NAT happens because with 
nat=no
it doesn't register. Qualify=yes doesn't allow the phone to register in any 
case with
any version.

Original comment by federico...@gmail.com on 22 Oct 2009 at 3:26

GoogleCodeExporter commented 9 years ago
Ok, nevertheless this is a different issue. This bug is about the phone not 
responding 
to OPTIONS requests, after a successful registration (in fact I have no 
problems with 
registrations whatsoever). Asterisk only sends those requests with qualify=yes 
enabled.

Original comment by schlac...@gmail.com on 22 Oct 2009 at 3:30

GoogleCodeExporter commented 9 years ago
Hi Federico, don't confusing things any further, please. The bug here is that 
when
you put qualify=yes in the Asterisk configuration, the Android phone running 
Sipdroid
is marked UNREACHABLE by Asterisk almost immediately, because it simply does not
respond to qualify queries by the Asterisk server. This is the bug here. This 
also
has the side effect of preventing Sipdroid from functioning properly through 
NAT,
because the OPTIONS messages keep the NAT state alive, and when not present
eventually, the NAT state disappears.

So, you mean Sipdroid is "unreachable" in a vague way, whereas the rest of us 
assign
a very specific meaning to it, i.e. marked as UNREACHABLE, as can be seen by 
calling
"sip show peers" in the asterisk CLI.

Original comment by iiordanov@gmail.com on 22 Oct 2009 at 3:39

GoogleCodeExporter commented 9 years ago
Sorry for the misunderstandment i caused.

Original comment by federico...@gmail.com on 22 Oct 2009 at 4:18

GoogleCodeExporter commented 9 years ago
Attached is a patch that implements support for OPTIONS in SipDroid, its really
simple: it always replies with SIP/200.

With this patch (and another one to workaround an Android 1.5 UDP bug) I can
successfully register on Asterisk with qualify=yes set!

Please integrate this patch into official sipdroid!

Original comment by edwinto...@gmail.com on 30 Oct 2009 at 4:17

Attachments:

GoogleCodeExporter commented 9 years ago
Please integrate this patch into official sipdroid!

I do not want to patch+recompile every new release!

Original comment by jirkapra...@gmail.com on 11 Nov 2009 at 8:00

GoogleCodeExporter commented 9 years ago
I agree. Is there any reason not to integrate it, if it's already done? It's a 
very 
simple implementation, but also a very useful one.

Original comment by schlac...@gmail.com on 17 Nov 2009 at 11:58

GoogleCodeExporter commented 9 years ago
@ 17 jiraprachar or 16 edwin : 

can you make your patched apk available to the world ?

Original comment by sebastien.wains on 17 Nov 2009 at 12:02

GoogleCodeExporter commented 9 years ago
Attached, note that you'll have to uninstall Sipdroid before installing this one
(which will loose your settings).

Original comment by edwinto...@gmail.com on 17 Nov 2009 at 12:39

Attachments:

GoogleCodeExporter commented 9 years ago
This is perfect. This patch totally does the trick and should be integrated 
into the
next release. I have no more issues using sipdroid on my asterisk server. Not 
within
the LAN, or via NAT. Both work perfectly, sending and receiving calls.

THANKS!

Original comment by cdol...@gmail.com on 17 Nov 2009 at 11:08

GoogleCodeExporter commented 9 years ago
Same here, works perfectly with Asterisk 1.2

Original comment by sebastien.wains on 18 Nov 2009 at 8:23

GoogleCodeExporter commented 9 years ago
This is great! Thanks very much "edwinto...", works perfectly for me as well.

Please include this patch into the official sipdroid distro.

Original comment by schlac...@gmail.com on 18 Nov 2009 at 12:22

GoogleCodeExporter commented 9 years ago
Acording to my phone, that .apk is not an valid application.

Original comment by conex...@gmail.com on 23 Nov 2009 at 8:48

GoogleCodeExporter commented 9 years ago
Conexcol: Have you enabled installing from "untrusted sources" in the settings?

Original comment by iiordanov@gmail.com on 23 Nov 2009 at 4:26

GoogleCodeExporter commented 9 years ago
iiordanov: yes, "untrusted sources" is enabled.
As soon as I click on
http://sipdroid.googlecode.com/issues/attachment?aid=-340608570418647178&name=Si
pUA-1.1.8%2Bbugfix_109_166.apk
I get a message saying: "The content is not supported: The content is not 
supported
on the phone. No application can be found to open this file. Do you still want 
to
doenload it?". I choose to ignore the warning and go ahead, it download the 
file and
when I try to open it, I get: "Open file error: No application can be found to 
open
this file."

Original comment by conex...@gmail.com on 23 Nov 2009 at 4:37

GoogleCodeExporter commented 9 years ago

Original comment by pmerl...@googlemail.com on 1 Dec 2009 at 12:27

GoogleCodeExporter commented 9 years ago

Original comment by pmerl...@googlemail.com on 3 Dec 2009 at 4:42

GoogleCodeExporter commented 9 years ago
is this fix included in 1.3.1 beta? my sipdroid is listed as UNREACHABLE on 
asterisk 
when the sipdroid is configured with qualify=yes

Original comment by jneriks...@gmail.com on 19 Jan 2010 at 8:32

GoogleCodeExporter commented 9 years ago
Latest sipdroid works fine without any additional patches, and registers on 
Asterisk.

Original comment by edwinto...@gmail.com on 19 Jan 2010 at 8:36

GoogleCodeExporter commented 9 years ago
The SIPDROID is successfully registered and I am able to make calls to an 
SJPhone running on PC. But i am not able to make calls from SJPhone to 
SIPDROID, 404 error occurs.

What could be the reason for that?
I am using Asterisk server, the output of 'sip show peers' is :
*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
pc/pc                      (Unspecified)    D   N      0        UNKNOWN
mydroid/mydroid            10.1.50.103      D   N      46694    OK (178 ms)
6001/6001                  10.1.12.133      D   N      5060     Unmonitored
6000/6000                  10.1.11.37       D   N      5060     Unmonitored
4 sip peers [Monitored: 1 online, 1 offline Unmonitored: 2 online, 0 offline]

See the PORT of 'mydroid', its not 5060..! Its 46694..!! may b that is the 
reason for the error..!

So, how can i set the port to 5060..? Kindly help me on this..!

Original comment by register...@gmail.com on 30 Sep 2010 at 11:29

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I see they have fixed the IP issue but still haven't fixxed the Port. I've been 
following this issue since iiordanov Created it. Hoping that these issues would 
be fixed.

Original comment by brons...@gmail.com on 30 Sep 2010 at 1:26

GoogleCodeExporter commented 9 years ago
So, that means that SIPDROID cant receive SIP calls, till now..?
Is there any means by which I can make between a SIP phone on PC and a 
SIPDROID..?

Thanks.

Original comment by register...@gmail.com on 1 Oct 2010 at 3:17