Closed GoogleCodeExporter closed 9 years ago
I've fixed something today about how csipsimple cleanup connections maybe it
could help.
If you can do tests using the future auto builds (the one that is upper than
750 that will be built tonight), and tell me if can be reproduced even with
this one.
Else it's probably about a deadlock as the one in issue 810.
Original comment by r3gis...@gmail.com
on 26 Mar 2011 at 11:17
Original comment by r3gis...@gmail.com
on 27 Mar 2011 at 9:13
Now I can not ringing from CSIPSimple totally.
But I can ringing to CSIPSimple.
CSipSimple-latest-trunk.apk 28-Mar-2011 03:04 3.5M
15:11:12.279855 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
(17), length 30)
10.0.2.2.5060 > 212.53.40.40.5060: SIP, length: 2
15:11:15.247898 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
(17), length 1309)
10.0.2.2.5060 > 212.53.40.40.5060: SIP, length: 1281
INVITE sip:1111111111@sipnet.ru SIP/2.0
v: SIP/2.0/UDP 195.xxx.xxx.xxx:5060;rport;branch=z9hG4bKPjs6xWhSVRJEFhEzW5ayNJO7qpHBLeepqv
Max-Forwards: 70
f: "\0xd0\0x94\0xd0\0xb8\0xd0\0xbc\0xd0\0xb0" <sip:0000000000@sipnet.ru>;tag=8VQJxsmYU.MjsiTOsRrr2UlQE3JzpEs7
t: <sip:1111111111@sipnet.ru>
m: "\0xd0\0x94\0xd0\0xb8\0xd0\0xbc\0xd0\0xb0" <sip:0000000000@195.xxx.xxx.xxx:5060;ob>;+sip.ice
i: uxDqKg7fUZTIcZ0uHGbZBs0ESjTiHlPh
CSeq: 387 INVITE
k: replaces, 100rel, timer, norefersub
x: 1800
Min-SE: 90
User-Agent: CSipSimple r755 / GT-I5700-8
c: application/sdp
l: 767
v=0
o=- 3510303057 3510303057 IN IP4 195.xxx.xxx.xxx
s=pjmedia
c=IN IP4 195.xxx.xxx.xxx
t=0 0
a=X-nat:6
m=audio 33113 RTP/AVP 8 101
a=rtcp:43483 IN IP4 195.xxx.xxx.xxx
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:jkK7IXUbx4ZcVLxtq1AhmsXnPKvidrj20JWyJoSA
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:vwLHxWuqez3qKW5KZzaZqOO90v6V5fQfzoagiO3L
a=ice-ufrag:7ea47ab9
a=ice-pwd:6db1f0f4
a=candidate:Sa000202 1 UDP 1862270975 195.xxx.xxx.xxx 33113 typ srflx raddr 10.0.2.2 rport 33113
a=candidate:Ha000202 1 UDP 1694498815 10.0.2.2 33113 typ host
a=candidate:Sa000202 2 UDP 1862270974 195.xxx.xxx.xxx 43483 typ srflx raddr 10.0.2.2 rport 43483
a=candidate:Ha000202 2 UDP 1694498814 10.0.2.2 43483 typ host
15:11:15.275936 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP
(17), length 372)
212.53.40.40.5060 > 10.0.2.2.5060: SIP, length: 344
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 195.xxx.xxx.xxx:5060;rport=5060;branch=z9hG4bKPjs6xWhSVRJEFhEzW5ayNJO7qpHBLeepqv
From: "\0xd0\0x94\0xd0\0xb8\0xd0\0xbc\0xd0\0xb0" <sip:0000000000@sipnet.ru>;tag=8VQJxsmYU.MjsiTOsRrr2UlQE3JzpEs7
To: <sip:1111111111@sipnet.ru>
Call-ID: uxDqKg7fUZTIcZ0uHGbZBs0ESjTiHlPh
CSeq: 387 INVITE
Server: CommuniGatePro/5.4c2
Content-Length: 0
15:11:15.275990 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP
(17), length 523)
212.53.40.40.5060 > 10.0.2.2.5060: SIP, length: 495
SIP/2.0 401 Authentication required
Via: SIP/2.0/UDP 195.xxx.xxx.xxx:5060;rport=5060;branch=z9hG4bKPjs6xWhSVRJEFhEzW5ayNJO7qpHBLeepqv
From: "\0xd0\0x94\0xd0\0xb8\0xd0\0xbc\0xd0\0xb0" <sip:0000000000@sipnet.ru>;tag=8VQJxsmYU.MjsiTOsRrr2UlQE3JzpEs7
To: <sip:1111111111@sipnet.ru>;tag=6715D086
Call-ID: uxDqKg7fUZTIcZ0uHGbZBs0ESjTiHlPh
CSeq: 387 INVITE
WWW-Authenticate: Digest realm="etc.tario.ru",nonce="220BCA94BCCAB6970781",opaque="opaqueData",qop="auth",algorithm=MD5
Server: CommuniGatePro/5.4c2
Content-Length: 0
15:11:15.440608 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP
(17), length 359)
10.0.2.2.5060 > 212.53.40.40.5060: SIP, length: 331
ACK sip:1111111111@sipnet.ru SIP/2.0
v: SIP/2.0/UDP 195.xxx.xxx.xxx:5060;rport;branch=z9hG4bKPjs6xWhSVRJEFhEzW5ayNJO7qpHBLeepqv
Max-Forwards: 70
f: "\0xd0\0x94\0xd0\0xb8\0xd0\0xbc\0xd0\0xb0" <sip:0000000000@sipnet.ru>;tag=8VQJxsmYU.MjsiTOsRrr2UlQE3JzpEs7
t: <sip:1111111111@sipnet.ru>;tag=6715D086
i: uxDqKg7fUZTIcZ0uHGbZBs0ESjTiHlPh
CSeq: 387 ACK
l: 0
15:11:15.441673 IP (tos 0x0, ttl 64, id 64669, offset 0, flags [DF], proto TCP
(6), length 1500)
10.0.2.2.48004 > 212.53.40.40.5060: Flags [.], cksum 0x793e (correct), seq 2074447820:2074449268, ack 3164333947, win 2920, options [nop,nop,TS val 18205195 ecr 1716007028], length 1448
15:11:15.441856 IP (tos 0x0, ttl 64, id 64670, offset 0, flags [DF], proto TCP
(6), length 156)
10.0.2.2.48004 > 212.53.40.40.5060: Flags [P.], cksum 0xaa43 (correct), seq 1448:1552, ack 1, win 2920, options [nop,nop,TS val 18205195 ecr 1716007028], length 104
15:11:15.469729 IP (tos 0x0, ttl 59, id 16375, offset 0, flags [DF], proto TCP
(6), length 52)
212.53.40.40.5060 > 10.0.2.2.48004: Flags [.], cksum 0x7541 (correct), ack 1552, win 91, options [nop,nop,TS val 1716011638 ecr 18205195], length 0
Original comment by 304...@gmail.com
on 28 Mar 2011 at 12:19
[deleted comment]
Aga, I understood. That was "compact sip mode" enabled.
You should make it disabled by default I think.
About this topic. With shared NAT and one external IP it works.
Today I will test with different NATs and feedback results here.
Original comment by 304...@gmail.com
on 28 Mar 2011 at 12:32
Ok, thx for the feedback. I mark as a bad point for compact mode in issue 842.
(I have enabled it by default in nightlies to get more feedback ;) ).
The good approach will probably be to enable it only with some providers known
as supporting this mode.
Original comment by r3gis...@gmail.com
on 28 Mar 2011 at 1:48
Tests results.
I have turned off STUN and ICE, because as I se they no influence here (voice
traffic goes via sip proxy).
Problem description:
a. X-Lite 4 (STUN and ICE off, G711 aLaw) = NAT = Internet = NAT = X-Lite 4
(STUN and ICE off, G711 aLaw)
I can ringing in both directions, I hear all, voice trafic goes via sip proxy.
All good.
b. X-Lite 4 (STUN and ICE off, G711 aLaw) = NAT = Internet = NAT = CSipSimple
(STUN and ICE off, G711 aLaw)
I can ringing without problems from X-lite to CSipSimple only, all ok as in
"a".
When I ring from CSipSimple to X-lite, I can not hear anything, but voice
traffic goes into sip proxy from both applications! It seems proxy do not
forward it.
p.s. Now sometimes there is no green icon is taskbar, but connection
established :) But this in no critical.
Original comment by vale...@gmail.com
on 28 Mar 2011 at 8:34
> b. X-Lite 4 (STUN and ICE off, G711 aLaw) = NAT = Internet = NAT = CSipSimple
(STUN and ICE off, G711 aLaw)
I have enabled "DNS automatic configuration" and it began working!
Then I disable this option, but it still works. Rebooted, but it works, no
matter checked or not.
I am little confused now.
Original comment by vale...@gmail.com
on 28 Mar 2011 at 9:54
Weird...
"DNS automatic configuration" -> is it an option of csipsimple (dns srv?) ? or
xlite? (or server?)
As for the green icon in taskbar, I fear there is a deadlock somewhere in the
app. I was not able to reproduce yet, but as soon I'll do, I'll try to fix it :)
Original comment by r3gis...@gmail.com
on 28 Mar 2011 at 10:41
> Weird... "DNS automatic configuration"
My be I named it incorrectly.
CSipSimple => Wireless networks => Auto Lookup DNS server (translation from
russian)
I will test today also to make sure that all ok in this build.
Original comment by vale...@gmail.com
on 29 Mar 2011 at 6:23
ok, russin translation is probably wrong. I guess it's "Allow DNS SRV lookup".
DNS SRV are special DNS entries __udp.__sip.domain.loc that is a nice way to
announce where is SIP server using a root domain. (if you want to review
russian translations : https://translations.launchpad.net/csipsimple/trunk ) ;).
There is something I'm thinking about now. As far as I understood, russian
network is isolated from other networks which implies that default STUN server
will probably fail in resolving your public IP regarding the russian sip server.
It's a little bit if you ask a server on the web to resolve your public IP to
give it as public IP to a server in your LAN.
The public STUN server will resolve one of the russian gateway but this
"public" IP will not be valid for your SIP server that is also in russian
network.
As consequence it could be interesting to find a STUN server on the same area
than your SIP provider. (the default one is stun.counterpath.com). The best
case occurs when the STUN server is exactly on the same machine that the SIP
server.
In this case whatever where you are in the world the resolved public IP given
by STUN server is also the public IP seen by the sip server.
Original comment by r3gis...@gmail.com
on 29 Mar 2011 at 1:42
Can not say about Russia, but from Ukraine stun.counterpath.com is available, I
just checked with STUN client. Also, I use sip provider STUN server. I'll test
deeper, at evening. Problem may caused by sip server configuration. Difficult
determine.
Just checkout csipsimple svn repository. Wow! I did not thought that project so
large!
pjsip is unreal at all. How is possible find bug there...
Intresting, where you finding free time to do this work?
p.s. How nice works voice in windows google talk, without these configs, stuns,
nats and ice. Hope csipsimple someday will work anywhere with default settings,
just server, username and password :)
Original comment by vale...@gmail.com
on 29 Mar 2011 at 3:00
> Can not say about Russia, but from Ukraine stun.counterpath.com is available
Ok from Ukraine should be fine indeed :). For information, the fact that the
stun server is available, does not mean it resolve a relevant public IP
address. But in Ukraine should be fine, as far as I know the public network is
not cut from what counterpath consider as public network ;).
> Intresting, where you finding free time to do this work?
In fact I do not develop pjsip. It's developed mainly by Teluu. Pjsip is a
great opensource sip stack. The only thing I did is
* porting it to android
* do the java application on the top of it.
As consequence every sip feature is not done by me but by pjsip guys. And they
are very very good in SIP stuff. They know really well SIP RFC and their
implementation has a good quality. (their code is clear and portable ;) ).
If you want more infos and docs about pjsip : http://www.pjsip.org/
This stack is widely used by many opensource SIP client. On android 3CX also
use this stack (even if they do not opensource it cause they buy teluu dual
license and release a commercial app).
On iphone there is the siphon project which rely on pjsip and many others.
There is also clients for mac, windows, linux, symbian and so on relying on
this stack.
Most of the time issues I get with this stack was more about how to configure
it for a need than about a bug in their stack.
But SIP is extremely complex to configure, all the more so as you are in a
mobile context. So my goal is to simplify this and try to reach the goal you
expect "someday will work anywhere with default settings, just server, username
and password :)" .... Actually, it is already the case for 80% of the users.
Thanks to the "wizard" approach, I'm able to do pre-configurations for given
sip providers by filling everything needed for a specific provider, considering
bugs and misfunctionement regarding SIP RFC of the sip server.
You have to keep in mind that having an Open client is infinitely more complex
that relying only one ONE SERVICE !
That's the price of openness. Skype has not all these problems. Google talk
neither.
For SIP providers that contacted me directly we did this work to adapt wizard
to their service. And trust me, it works just flawlessly with this providers !
Regardless STUN/ICE and so on. Simply cause they have a clean SIP server config
on their side that workaround Nat traversal and cause they know exactly how to
configure a client to make it works as it should with their service.
Original comment by r3gis...@gmail.com
on 29 Mar 2011 at 3:19
My test totally completed. With different NATs.
All works exellent in dev version. Minor interface bugs, I think you know it.
What you think about enabling STUN and ICE by default? Direct connection as and
via sip proxy works great! In X-Lite it enabled by default and recomended.
Original comment by vale...@gmail.com
on 30 Mar 2011 at 4:51
Yes indeed, I'm aware about regressions of the new UI ;). Big refactoring with
a lot of new feature take time to implement :)
As for STUN and ICE, I thought previously that it was a good idea... However,
after trying to commit something with STUN and ICE enabled by default on an
older revision, I get a lot of very bad feedback from many users. Mainly users
that use the application in russian countries and users that use an enterprise
PBX.
In this case they get very bad experience cause they can't even register.
As consequence I choose to disable it by default and prefer to activate it in
each wizard where it is relevant to do.
Usually SIP providers that provide service somewhere where the STUN is required
provide STUN server. In this case it's by far better to use this STUN server
and wizard approach allow me to easily configure automatically that.
Besides STUN server is something that should be relative to your access point
and should be relative to the service.
Even worse, some SIP providers solve on their side the NAT. In this case trying
to activate STUN and ICE just conflicts and it's a very bad idea to have any
NAT resolution trick on the client side.
As I said in my previous comment, all of this make SIP configuration really
really dependant of the provider/service. That's exactly why there is this
wizard approach.
I assume that either :
* user is a mainstream user. If so he use a well known sip provider. As consequence csipsimple should have a wizard for this and allow to configure it in less than one minute.
* user has some skills in SIP and want to have his own sip server. If so I think that's something really good for this user to learn new things and to understand more about how stun and ice works ;). So not really hurting in this case
* user is the user of a company that deploy company sip ippbx. In this case the work is not yet finished, but it should be possible for the company IT to provide a simple file to put on the android device that will automatically configure the user device.
In case of missing wizard in first case, CSipSimple must add a new wizard.
Project is still young, so there is probably missing wizards but I think that
this approach is better than disappointing 50% of the users by just deciding
unilaterally that one configuration is better than another.
Original comment by r3gis...@gmail.com
on 30 Mar 2011 at 9:03
Original issue reported on code.google.com by
vale...@gmail.com
on 26 Mar 2011 at 11:04