Closed GoogleCodeExporter closed 9 years ago
Issue 1696 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 21 Apr 2012 at 3:52
Hi,
Can you try to collect some logs.
See http://code.google.com/p/csipsimple/wiki/HowToCollectLogs?wl=en wiki page
to know how.
Also, make sure that your wifi access point does not simply block SIP traffic.
Many open public hotspot blocs SIP traffic and so it's impossible to do SIP on
this using regular ports.
Original comment by r3gis...@gmail.com
on 21 Apr 2012 at 3:53
This issue has been happening to me as well. I just sent in a log of it
following the linked instructions and referencing this issue#.
I'm running CSipSimple version 0.03-01r1108 with PBXes.org as my SIP provider
(trunking to Google Voice).
Possibly relevant settings:
Wifi keep alive - 40
Resolve DNS SRV - Off
Use compact SIP - Off
SRTP mode - Optional
ICE - Off
STUN - Off
Availability Profile - Always Available
System "Keep Wi-Fi on during sleep": Always
I'm running stock Android 4.1.1 on a GSM Galaxy Nexus. I have made calls using
CSipSimple on this Wi-Fi network multiple times so my work isn't blocking SIP.
I have had this happen at home on my own wireless as well. Thus far, I have
not seen it happen on 3g.
Please let me know if there's any other information I can get to help diagnose
this.
Original comment by AltairD...@gmail.com
on 6 Aug 2012 at 3:38
Just sent in an additional log running nightly version 0.04-00r1762. One
notable difference: I didn't see the error while registering message this time,
it just showed as inactive. As before deactivating and activating the account
let it register right away.
Original comment by AltairD...@gmail.com
on 7 Aug 2012 at 5:07
Thanks a lot for the logs !
After a deep analyze the root cause seems a bug on pbxes.org SIP server that
break registration process when the packets are re-transmitted.
In CSipSimple/pjsip timeout values by default before retransmit are the one
defined as default per SIP RFC.
So when it tries to register, if it doesn't have any reply after 500ms it will
retransmit registration.
Apparently in your case, sometimes this retransmit is needed because remote sip
server / network doesn't reply in time (in 500ms).
Normally it's not a problem because the SIP server should ignore the
retransmition in such a case.... but it's not the case for pbxes.org... they
take into account the retransmition to break the reply the application is doing
to the first registration...
When it goes this situation csipsimple/pjsip will stop registration after retry
because it appears that remote server is not able to authenticate.
So, the root cause is on pbxes.org side. However, there is probably a possible
workaround against that :
Since the problem is the retransmation that occurs to quickly and that it's not
supported correctly by pbxes.org, it's possible in csipsimple to change the
value of the retransmition timeout.
To do so :
Go in settings, and switch to expert mode (press menu key when in csipsimple
settings and you'll see in the menu the option to enable expert mode).
Then go in network section and in SIP protocol subsection.
Here you'll see an option about T1 transaction timeout value. It's set by
default to -1 which leads in fact to the default 500 value. Try to set it to
1000 or 2000 (1 or 2seconds). Normally 1000 should be enough. From logs it
appears that the network latency make it reply in 700ms.
I think that your wifi network has higher latency which leads to have this
problem more frequent than on 3G.
Can you confirm this workaround help?
If so, I can automatically change the T1 value when user configure an account
with pbxes.org.
Original comment by r3gis...@gmail.com
on 15 Aug 2012 at 9:50
Issue 873 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 15 Aug 2012 at 10:34
Thanks! The latency on wireless at my work is pretty awful sometimes. I set it
to 1000ms last night and so far I haven't seen it drop today. I will keep an
eye on it today and tomorrow and update this.
Original comment by AltairD...@gmail.com
on 16 Aug 2012 at 3:21
It stayed registered with no issues all day today, so far so good. I'll update
again at the end of tomorrow just to be sure.
Original comment by AltairD...@gmail.com
on 16 Aug 2012 at 9:41
Ok very good news.
I'll update pbxes.org wizard so that it changes the T1 value automatically.
Thanks a lot for the tests.
Original comment by r3gis...@gmail.com
on 17 Aug 2012 at 7:49
This issue was closed by revision r1782.
Original comment by r3gis...@gmail.com
on 17 Aug 2012 at 8:01
Just reporting back for the promised update, the workaround of setting the T1
value to 1000ms is still working beautifully.
Original comment by AltairD...@gmail.com
on 17 Aug 2012 at 9:04
Original issue reported on code.google.com by
yuri...@gmail.com
on 21 Apr 2012 at 3:35