pyj4104 / sipdroid

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

Hangs when using STUN #350

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
When using a STUN Server, Sipdroid does not properly wake from standby. I
have been able to reproduce this using several SIP/STUN services.

What steps will reproduce the problem?

1. Configure Sipdroid using a STUN Server (which one does not matter, I've
tried stun.ekiga.net, stun.voxgratia.org and one I set up myself using stund)

2. Wait until the account is connected (up until here, everything works
perfectly). Put phone to sleep (or wait until it turns itself off).

3. Try to open the sipdroid application again (either from the green status
icon in notification or by dialing a number) - it hangs for a long time,
Android even offers to force close (Sipdroid will eventually start, but it
takes around 30s)

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

Sipdroid to be responsive as usual.

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

Android 1.6 on a G1

Which SIP server are you using? What happens with PBXes?

Asterisk 1.4, 1.6, stund. Don't think I can test STUN with PBXes.

Which type of network are you using?

NAT (no NAT on Asterisk end, the * server is handling this just fine with
any other SIP client).

Please provide any additional information below.
--

Original issue reported on code.google.com by kw%allie...@gtempaccount.com on 1 Mar 2010 at 1:39

GoogleCodeExporter commented 9 years ago
I concur with an HTC Hero Andoid 1.5, asterisk 1.6.1.16. The problem was not 
present
in 1.3.12, which worked perfectly, but is present in 1.3.14.

Original comment by ianjones1957@gmail.com on 1 Mar 2010 at 4:34

GoogleCodeExporter commented 9 years ago
Are either one of you getting any log messages from DiscoveryTest via logcat 
such as 
the following (when you toggle on STUN):

D/DiscoveryTest( 1661): Test 1: Binding Request sent.
D/DiscoveryTest( 1661): Node is natted.
D/DiscoveryTest( 1661): Test 1: Binding Request sent.
D/DiscoveryTest( 1661): Node is natted.

Original comment by carlos.t...@gmail.com on 1 Mar 2010 at 9:24

GoogleCodeExporter commented 9 years ago
This is the logcat from when I turned STUN on, then off again:

03-02 08:50:43.960: INFO/XT9IME(270): [finishInput]
03-02 08:50:44.020: INFO/ActivityManager(59): Displayed activity
org.sipdroid.sipua/.ui.Settings: 463 ms
03-02 08:50:49.170: DEBUG/dalvikvm(114): GC freed 1291 objects / 77888 bytes in 
133ms
03-02 08:50:50.600: INFO/XT9IME(270): [finishInput]
03-02 08:50:57.059: DEBUG/dalvikvm(385): GC freed 4168 objects / 223832 bytes 
in 125ms
03-02 08:50:57.149: INFO/InetAddress(385): gethostbyaddr: getnameinfo: 
192.168.1.79 =
192.168.1.79
03-02 08:50:57.667: DEBUG/InetAddress(385): stun.ekiga.net: 75.101.138.128 
(family 2,
proto 6)
03-02 08:50:57.680: DEBUG/DiscoveryTest(385): Test 1: Binding Request sent.
03-02 08:50:57.880: DEBUG/DiscoveryTest(385): Node is natted.
03-02 08:50:57.910: INFO/InetAddress(385): gethostbyaddr: getnameinfo: 
192.168.1.79 =
192.168.1.79
03-02 08:50:57.920: DEBUG/DiscoveryTest(385): Test 1: Binding Request sent.
03-02 08:50:58.080: DEBUG/DiscoveryTest(385): Node is natted.
03-02 08:50:59.130: DEBUG/LocationManager(385): removeUpdates: intent =
PendingIntent{435b3e98 target android.os.BinderProxy@4359e2f8}
03-02 08:50:59.850: DEBUG/dalvikvm(385): GC freed 10357 objects / 650120 bytes 
in 122ms
03-02 08:51:07.020: DEBUG/LocationManager(385): removeUpdates: intent =
PendingIntent{435b3e98 target android.os.BinderProxy@4359e2f8}
03-02 08:51:07.320: DEBUG/dalvikvm(385): GC freed 8741 objects / 499736 bytes 
in 117ms
03-02 08:51:09.340: WARN/KeyCharacterMap(385): Bad keycharmap - filesize=32
03-02 08:51:09.370: INFO/XT9IME(270): [finishInput]
03-02 08:51:10.300: INFO/XT9IME(270): [finishInput]

Regards
Ian

Original comment by ianjones1957@gmail.com on 2 Mar 2010 at 7:57

GoogleCodeExporter commented 9 years ago
I get this using stun.ekiga.net, which is reachable and working with the other 
phones
in my office (Socket timeout appears when waking up the device):

D/DiscoveryTest(21884): Test 1: Binding Request sent.
D/DiscoveryTest(21884): Node is natted.
D/DiscoveryTest(21884): Test 1: Binding Request sent.
D/DiscoveryTest(21884): Test 1: Socket timeout while receiving the response.
D/DiscoveryTest(21884): Test 1: Binding Request sent.
D/DiscoveryTest(21884): Node is natted.

Sipdroid Version is 1.3.14

Original comment by kw%allie...@gtempaccount.com on 2 Mar 2010 at 10:48

GoogleCodeExporter commented 9 years ago
I don't know if this helps, but I have changed location and here I have no 
problem
with using STUN. The ISP is the same at the two locations (Orange fr) the 
wireless
networks are very similar, it's even the same router in both places (Livebox
Inventel) and I have changed nothing on the phone except activating STUN.

Regards
Ian

Original comment by ianjones1957@gmail.com on 4 Mar 2010 at 7:20

GoogleCodeExporter commented 9 years ago
I have tested this in different networks (Swisscom, Cablecom, Swisscom UMTS) 
without
any improvement. Ian - maybe there is a different NAT type in the other network?

regards,
/ken

Original comment by kw%allie...@gtempaccount.com on 9 Mar 2010 at 2:30

GoogleCodeExporter commented 9 years ago
Ken,

As far as I know, the networks are identical except for SSID and WPA Keys, but 
I will
check next time I go back to the other location (unfortunately that won't be 
for a
couple of weeks.) It's possible that the routers' firmware or software are at
different levels, and I will check that too. I can report that since I have 
returned
here to Paris, everything has been working very well.

Regards
Ian

Original comment by ianjones1957@gmail.com on 9 Mar 2010 at 2:39

GoogleCodeExporter commented 9 years ago
Well, I am now back to where I first noticed the problem, and everything is now
working as expected. I have updated to 1.4, so perhaps that fixed it.

Ian

Original comment by ianjones1957@gmail.com on 21 Mar 2010 at 3:04

GoogleCodeExporter commented 9 years ago
I can confirm that using 1.4.4 with the same setup as before solved this issue 
for me.

/ken

Original comment by kw%allie...@gtempaccount.com on 30 Mar 2010 at 10:13