search

monorailcat / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

Bug when calling from CSIPSimple. #840

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Enable STUN and ICE in CSIPSimple
2. From other side X-Lite 4 with STUN and ICE
3. Call from CSIPSimple to X-Lite (all ok).
4. Call from X-Lite to CSIPSimple (all ok).
5. Call from CSIPSimple to X-Lite - no sound and voice trafic, connection 
drops, but I still see green icon (green hadndet) in task bar. Can be removed 
by stopping CSIPSimple from task manager.
6. After kill app, I can call few times from CSIPSimple to X-Lite, but after 
several cross calls, I can not.

What version of the product are you using? On what operating system?
CSipSimple-0.01-01.apk
Android Froyo

Please provide any additional information below.
Both clients under different NATs. Voice traffic goes via SIP proxy. One or 2 
times I can connect without problems, but after this problem appearing.
I can call from X-Lite to CSIPSimple many times, all works without problems.

Original issue reported on code.google.com by vale...@gmail.com on 26 Mar 2011 at 11:04

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago

Original comment by r3gis...@gmail.com on 27 Mar 2011 at 9:13

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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