results of testings today

[GoogleCodeExporter]

I ve tested today with a friend, and we went through several testcases. I would 
prefer to discuss the results somewhere on irc, cause I could describe 
suspicious parts more detailed.
So for now I give you a broad brush description riddled with questions :).

First to the systems: We used
M1) Google Nexus S on Android 2.3.6
M2) Google Nexus S on Android 2.3.6
and one
M3) SGS II on Android 2.3.3.

All using: CSipSimple 0.04-00 r1154.
If the situation gets clearer to me I will include the HTC Wildfires again. 
This time we left them out.

We ve been testing with these two Voip Providers:
P1) Iptel.org (ZRTP, SRTP - 128 AES)
P2) tanstagi (ZRTP, TLS - 256 Twofish)

First round.. on the same Wifi Network:
P1) ZRTP is always invalid. SAS is not available. The rest is fine.
P2) M1 is able to call M2. The call back (M2->M1) is not possible. The call 
shuts down after a sec or two.

Second round.. outside, on UMTS:
The first 10 minutes nothing working at all. Why?
Then:
P1) still no connection possible at all. could it be blocked by the mobile 
service provider? if yes, how can i find out? Other reasons?
We had different versions of not working :).. one phone ringing while the other 
was in the call, calling into silence, just not responding, and quite a long 
delay after pressing "end call" to when the mobile really ends it and closes 
the call window.
P2) Same like above: M1 is able to call M2. The call back (M2->M1) is not 
possible.

I didnt test M3 with P2, the login doesnt work atm, will add the results as fup 
as soon as they are available.

I hope i am able to contribute to your work by testing, I really appreciate it. 
If you need logs, please tell me.

kr

Original issue reported on code.google.com by automate...@gmail.com on 30 Nov 2011 at 9:18

[GoogleCodeExporter]

additional comment:
i ve activated ice on the mobiles.

additional questions..
how are the secure settings interconnected?

for example: if i activate tls, and i set srtp mode to mandatory aswell?
or is this relying on which protocol i set in the account settings? I guess 
something would have to overrule the other..
what about the proxy: srtp mode. if it is set to mandatory, is it used only if 
the srtp is triggered in the first place?

Original comment by automate...@gmail.com on 30 Nov 2011 at 9:25

[GoogleCodeExporter]

What do you mean by ZRTP, SRTP case? Did you try to activate both SRTP and 
ZRTP? If so, that's not supporteed case. I should probably change the 
preference UI to reflect that this is an invalid configuration.
In fact, both ZRTP and SRTP are methods to encrypt media. Both methods are 
exclusive. Actually if both clients supports ZRTP it should include SRTP 
features (at least that's what I understood ;) ). So if you enable SRTP at the 
same time that ZRTP it will not work (I mean encryption will not work). In best 
case SRTP will be tried but I'm not sure.

About case 2, I'd be interested in logs. That's weird that behavior is not 
symetric. All the more so as your two devices are on the same network and 
should have the same configuration. So if you can collect logs from both device 
in the working and the not working case would be great. If you do so, collect 
logs at the end of each call (since android log system has limited buffer, if 
you run all calls in the same log I may not see the begin of the call ;) ).

About P1 on UTMS, that's possible that your mobile service provider block SIP. 
Here in france they detect SIP packets and just block anything about SIP. 
Obviously they are not able to detect SIPS (SIP+TLS) so it works fine with 
encrypted control plan.
This blocking is also sometimes different depending on the antenna you are 
connected to. When it was not yet blocked everywhere here, I was able to 
connect in sip at some location, and if I moved of 100km I was not able.
However regarding what you describe it sounds more like some not totally 
reliable connection or just about the fact sip packets were too big. Indeed 
SRTP add a lot of information in INVITE and it could lead to bigger UDP 
packets. If you have in addition a lot of codecs activated, you could reach the 
limit of what's accepted by the network you are connected too and obsever very 
weird and unresponsive behaviours.

About your last additional comments, for now settings are not interconnected. 
(And as I said, it should maybe be connected for SRTP/ZRTP).
About TLS and SRTP there's no link at all. TLS is about encryption of control 
plan (sip invite, bye, ack messages) and SRTP/ZRTP are bout encryption of the 
media plan (the actual voice).

The SRTP mode mandatory means that if the negociation lead to something that 
will not be encrypted the call will not be established. 
Such an option could also maybe be possible with ZRTP. For now that's not 
supported. But since the way to establish ZRTP is slightly different I'm not 
sure that's a really necessary feature. ZRTP could be supported by other side, 
but not announced during SIP negociation, so the "mandatory" feature is not 
necessarily a good idea for ZRTP.

About a more interactive way for your issues and report, you could join the 
developer group (http://groups.google.com/group/csipsimple-dev/), you'll be 
welcome :D

Original comment by r3gis...@gmail.com on 30 Nov 2011 at 9:49

• Changed state: Need-Details