Closed GoogleCodeExporter closed 9 years ago
Werner will correct me if I mistake, but my understand is the following :
ZRTP is somehow always optional cause it is based on RTP and send on RTP some
hello to see if other part does accept that.
SRTP mechanism is different. There is mandatory SDP infos about the fact the
call will be done using SRTP, while using ZRTP it's not mandatory.
I think that besides, when you use ZRTP process is not the same. You can just
not talk at all if you see that the communication is being encrypted. I'm
adding the little icon to inform that the call is encrypted, but if you don't
get the popup it is a good indication about that already ;).
I think that the ZRTP options would more be something like 'Disabled',
'Optional', 'Only if remote announced in SDP'.
Cause 'mandatory' make not really sense cause there is always the beginning of
the communication where the SAS has to be acknowledged when the call is done
without ZRTP encryption.
The only way to provide mandatory would be to say : "mandatory for incoming
only" and would also mean that remote side has to announce in SDP ZRTP support.
Or we could cut the communication if ZRTP negociation fails... but since the
user should be aware about that (my bad, not yet ;) ), not really hurting to
leave user decide.
Original comment by r3gis...@gmail.com
on 7 May 2011 at 3:29
Hi regis,
i can't see the security settings under network any more. Did you change
something? Are they gone, or is it just on my device (defy) for some reason?
Original comment by nilsjan...@gmail.com
on 7 May 2011 at 7:37
If you sure that you are using a tls version, the other reason for not having
the setting is that the sip stack has never been started.
The setting only appear if pjsip has been loaded once to be able to know
whether it has been built with tls support.
So you should first try to register and then go in settings.
Original comment by r3gis...@gmail.com
on 7 May 2011 at 9:37
ZRTP on r836 nightly works brilliantly for me now! Thanks for fixing whatever
bug there was. I'm running it on LeeDroid Gingerbread Rom V 3.0.6 (HTC Desire).
You guys rock!
Original comment by chhab...@gmail.com
on 8 May 2011 at 11:25
sorry, i used the usual nightlies...
Original comment by nilsjan...@gmail.com
on 8 May 2011 at 11:36
@regis (51):
Regis is right. Othe client that support ZRTP just have an enable check box. If
checked then ZRTP tries to negotiate the security data with the other client. If
the othe client also support ZRTP - bingo, secure connection will be
established. If
the other partner does not support ZRTP then the ZRTP implementation switches to
listening" mode to see if the other partner sends a ZRTP Hello to announce that
it
is willing to negotiate SRTP keys.
You may announce in the SDP that your client supports ZRTP (I need to look if
this
is avaiable for pjsip). However, some operators/ISPs/SIP providers block SIP
INVITE
if they see an unknown SDP header or they block SIP INVITE if the SDP is not
what
they like :-) .
Best regards,
Werner
Original comment by werner...@googlemail.com
on 9 May 2011 at 6:53
Just a remark to Regis and other that like to build CSipSimple from scratch
or like to use pjsip (pjsua infact) together with ZRTP:
Unfortunatly Benny (the mainatiner of Pjsip) did not include an important
feature
in the latest release of pjsip (even it was announce for this release). When you
like to use ZRTP together with PJSUA you must apply a patch (it's a small patch)
that allows an application to enable the ZRTP transport in pjsip/pjsua.
Best regards,
Werner
Original comment by werner...@googlemail.com
on 9 May 2011 at 6:58
Great stuff, just tested on two csipsimple devices attached via freeswitch zrtp
pop ups are working! thanks r3gis and werner for all the hard work!
had to enable proxy media
http://wiki.freeswitch.org/wiki/Proxy_Media
Original comment by wheresau...@lavabit.com
on 9 May 2011 at 11:38
regis, when do you think will this get into the stable version? and what is the
seperate tls version for?
Original comment by nilsjan...@gmail.com
on 12 May 2011 at 3:13
It will be included in stable version as soon as I introduce the way to
download separately a .so lib (or as a third party application). It's not
included in normal version cause TLS build include lib openssl (cause that's
not in android NDK), and it make the size of the app twice bigger.
My goal is to have it as a "module" of the app.
It could be either by downloading directly the .so file, but after thinking a
lot about that I think that a better idea would be another app that bring the
relevant .so files.
I'll have the same problem for the video (that should also be distributed as a
plugin).
The way it's managed for themes apps is not so bad I think (with a link in the
app to find Themes and Plugins).
For now the only thing I'd have to solve conceptually with this approach is the
way to update things (should not be so difficult) and second point the way
several plugins could work together (probably some plugins such as TLS that
requires to rebuild the entire stack may not be considered as plugin but as
"core" and would not be compatible with other "cores".
Then I'll start to make a proof of concept of this "modular" approach and
include it in future versions.
A could thing would have been to have pjsip really modular regarding TLS but
AFAICT it's not currently easy to do.
Original comment by r3gis...@gmail.com
on 12 May 2011 at 4:49
that sounds good. perhaps link to the tls version from
http://code.google.com/p/csipsimple ?
best,
nils
Original comment by nilsjan...@gmail.com
on 13 May 2011 at 7:06
@werner, do you know the min. cpu power needed for zrtp on android?
Original comment by nilsjan...@gmail.com
on 13 May 2011 at 7:11
did anybody try it via gprs/edge/umts?
for me it currently only works via wifi, but that could be the fault of my
mobile provider blocking sip...
Original comment by nilsjan...@gmail.com
on 24 May 2011 at 2:01
yes, the key exchange does not seem to be happening over 3G but works great
over wifi! 3G still connects the call with no SAS(zrtp exchange) message.
r3gis think this could be application somewhere?
Original comment by wheresau...@lavabit.com
on 24 May 2011 at 9:17
Issue 1153 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 15 Jul 2011 at 2:25
Issue 1152 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 15 Jul 2011 at 2:26
@issue 1152:
After ZRTP exchanged keys with both sides it starts the secure connections
(SRTP)
immediately. The SAS confirmations is independent of this - one may chosse never
to verify and confirm SAS with the other side. In such a case I strongly
recommend
to check the SAS with the other side verbally. Once this was done and was ok
you
may click SAS verify and ZRTP implementation remembers this and can perform
additional checks on the next key exhanges and issues warnings if it detects
something is wrong. If SAS was verfied and ZRTP does not reports any warning
during
the next key exchanges then no Man-in-the Middle occured and security is ok.
Original comment by werner...@googlemail.com
on 17 Jul 2011 at 12:35
@comment 62:
Sorry no. What I did to reduce CPU consumption was: enable elliptic curve
Diffie-Helman public key exchange as default. This requires much less CPU power
than finite-fiel DH while more secure (win-win, isn't it :-) )
@comment 63 and 64
Sometimes 3G operators filter RTP packets that are not _real_ RTP. ZRTP uses the
RTP connection to exchange data and use a RTP format, but these are not _real_
RTP packets. To check this someone should use Wireshark to analyse the real
data traffic and check whether or not ZRTP packets make their way thru 3G
connections.
I cannot check 3G because I don't own an Android device.
Just a note here:
in comment 64 I read: ...still connects the call with no SAS message... . As
said,
I can't give a response here how CSipSimple implemented the GUI for ZRTP. Other
clients that support ZRTP usually display a small textfield that contains the
4-char
SAS and a check-box to "verify" the SAS with ZRTP (see comment 67). A client
may also show which crypto algorithms are active in SRTP. The SAS shall be
shown as
soons as secure call was established (ZRTP uses a callback to inform the GUI).
Original comment by werner...@googlemail.com
on 17 Jul 2011 at 12:47
About last point, I did a very recent change to improve this point. It's still
not yet perfect and I'll try to add your advise on issue 1153 to improve how
it's integrated.
For reference, what is expected now is :
when call is secured it show "ZRTP : SAS" with a little icon on the top right
of the call card. If SAS has to be verified, it shows an alert that one can
accept to verify it (previously it was asking each time - now it does only if
it has actually to be verified).
Except from pure UI issues, there is also still something I have to solve on my
side. That's more complicated to manage and should allow multiple calls with
ZRTP. (It's about the way the UI store the reference to the zrtp transport...
that's not so easy to manage with JNI on the middle ;) ).
Original comment by r3gis...@gmail.com
on 17 Jul 2011 at 4:01
can you please list the ZRTP-enabled SIP servers that you were able to use to
establish a ZRTP connection successfully between two CSipSimple clients?
When switched "Create ZRTP" On (and SRTP off, or any other choice), the call is
started and ended immediately on 2 of the servers I checked (Kamailio and
FreeSWITCH).
Thanks!
Original comment by a...@privatemail.lv
on 1 Aug 2011 at 5:21
There are no specific SIP servers that handle ZRTP because this is not
required. ZRTP
is a protocol that negotiates the keys that are required to setup a SRTP
context and
does this via the RTP session (usually the audio connection). Thus no SIP
involved.
ZRTP starts it's negotiation as soon as the first media session is ready.
ZRTP uses it's own underlying SRTP - thus if you like to use ZRTP please switch
off
the other SRTP which uses a specific SIP mechanism to exchange the SRTP keys.
When I test ZRTP I use kamaillio (openSER) as SIP proxy and registrar and it
works
quite well. Which problems do you see? Any logs from kamaillio?
Original comment by werner...@googlemail.com
on 1 Aug 2011 at 9:20
Apologies for the slightly off-topic question....
Does anyone know of a termination provider that offer ZRTP support?
(For the specific threat model, it's enough we encrypt until the service
provider {assuming it's not in a particular country} and make simple
unencrypted PSTN calls onward).
This would be also used for conferencing a number of ZRTP supported clients
within the problematic country.
Naturally, we can setup our own server for that - but there are benefits for
using an existing service provider.
Thanks,
Yahel.
Original comment by ya...@airjaldi.org
on 10 Aug 2011 at 6:59
I'm not aware of any termination provider that connects VoIP to PSTN that also
supports ZRTP. AFAIK this requires a Asterisk server with ZRTP enhancement and
you
need to have a ZRTP implementation that support a specific ZRTP feature: trusted
Man-in-the-Middle. Currentliy the PJSIP implementation (CSipSimple uses this
implementation) does not support this feature because it is considered a
security
risk.
Just send me a PM if you need some more support and/or discuss specific
features.
Regards,
Werner
Original comment by werner...@googlemail.com
on 10 Aug 2011 at 1:21
Hello guys.I am really excited about ZRTP support in CSipSimple. I have a
problem and mostly I think is a GUI one.
I am testing ZRTP in CSipSimple with a HTC Desire HD (Android 2.3.3) and 2 Samsung Galaxy Mini (Android 2.2.1) clients connected to a Freeswitch server (which runs in proxy media mode).
The problem is that I only sometimes see the 4 digit SAS displayed on both phones,sometimes the SAS appears only on one phone but most often it is not displayed at all on any phone, although ZRTP is active (I know that because I registered on the Freeswitch server with a client on the phone and a client on a computer (Jitsi-former SIP Communicator) and in Jitsi it showed me that ZRTP is active, but on the phone it didn't display the 4 digit SAS or that ZRTP was active).
The catch is that if I select "Disconect" from the app menu, and I restart the app again (on both phones) then, on the first call made after that the SAS is displayed on both phones, but on the other calls it is just like I've mentioned before.
So, even if ZRTP is active, the user won't know that because it isn't displayed anywhere and he can't verify the SAS with the other party.
Please check this problem, and I will continue to test the app and post
updates.
Keep up the good work.
Original comment by ursu.adr...@gmail.com
on 24 Oct 2011 at 10:21
Regarding @74
I cannot really test this because I don't have a freeswitch setup. Thus just a
question: do you use anything like the "PBX ZRTP registration" feature in
freeswitch? I know that freeswitch support this sort of trusted
Man-in-the-Middle feature?
If it is really purly "proxy-media" I would be interessted in some network
traces between both clients and the freeswitch.
Best regards,
Werner
Original comment by werner...@googlemail.com
on 6 Nov 2011 at 11:27
I play with r1064 and ZRTP. My experience is:
The ZRTP SAS only show at the first call, because the implementation is not
complete, see that
http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csips
imple/pjsip/UAStateReceiver.java?r=1060#458
"// For now, just get the first one..." is the problem. Another problem that
the transport_zrtp.c is often crash with sigsegv.
********** Crash dump: **********
Build fingerprint:
'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
pid: 1359, tid: 1411 >>> com.csipsimple:sipStack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 07000004
Stack frame #00 pc 0010b260 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine pj_lock_acquire in
apps/pjsip/project/build/..//pjlib/build/..//src/pj/lock.c:178
Stack frame #01 pc 0010c672 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine lock_timer_heap in
apps/pjsip/project/build/..//pjlib/build/..//src/pj/timer.c:104
Stack frame #02 pc 00151ebe /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine timer_add_entry in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/trans
port_zrtp.c:303
Stack frame #03 pc 00152504 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine activateTimer in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpCallbackWrapper.cpp:42
Stack frame #04 pc 00153018 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine activateTimer in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZRtp.cpp:2126
Stack frame #05 pc 00158f9e /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine startTimer in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpStateClass.cpp:1352
Stack frame #06 pc 00159c90 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine evInitial in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/inclu
de/libzrtpcpp/ZrtpStates.h:76
Stack frame #07 pc 00159dd8 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine processEvent in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpStateClass.cpp:129
Stack frame #08 pc 0015352c /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine startZrtpEngine in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZRtp.cpp:199
Stack frame #09 pc 001513aa /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine zrtp_startZrtpEngine in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpCWrapper.cpp:122
Stack frame #10 pc 00151c90 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine pjmedia_transport_zrtp_startZrtp in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/trans
port_zrtp.c:754
Stack frame #11 pc 00152082 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine transport_send_rtp in
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/../..
/../pjlib/include/pj/string.h:634
Stack frame #12 pc 000e49c0 /data/data/com.csipsimple/lib/libpjsipjni.so:
Routine pjmedia_transport_send_rtp in
apps/pjsip/project/build/..//pjmedia/build/..//src/pjmedia/stream.c:1345
S
this is because the timer_pool did not freed at transport_destroy(), but the
pjlib destroys it automatically at end of first call (pool_caching.c:108), so
when the next call started the timer_pool is already destoyed and the sigsegv
occurs. The problem maybe that the timer_stop() function is not used, so the
implementation is not complete also.
Furthermore the timer_android.cpp is unstable, with that the SIP stack always
sent a REGISTER message to the SIP server at every 1-3 seconds. I dont know why
and I don't know that this is related to ZRTP or not. When I build the library
with the original timer.c this problem is gone, but CSipSimple does not accept
incoming calls when device is in idle.
Original comment by gcjo...@gmail.com
on 7 Nov 2011 at 3:41
About timer_android.cpp, you're right for TLS version.
ZRTP and TLS builds are broken til the next stable release (which will come
really soon). If I want to have something stable without regression risk on
trunk with android 1.6 I've to break ZRTP support for a while.
I've something working again but based on pjsip-2.0.
So for now hold for a couple of week if you need ZRTP (or try to build with the
new jni folder ;) ).
About the fact it take only the first SAS, good point, I forgot that I
postponed this implementation :). So to be done :)
Original comment by r3gis...@gmail.com
on 7 Nov 2011 at 3:58
Oh, and I forgot to add that with the pjsip-2.0 builds (after the next stable
release on the android market), ZRTP and TLS will be on of stock features of
csipsimple :).
I finally found a fancy way to use openssl if available on the platform (99.99%
of cases) and to load it dynamically else. (Many other native features will
becomes available through plugins too : codecs, audio and video device
implementations etc).
Original comment by r3gis...@gmail.com
on 7 Nov 2011 at 4:04
Thank you! If the new trunk with ZRTP will be buildable, I will test it! :)
Original comment by gcjo...@gmail.com
on 7 Nov 2011 at 5:44
@r3gis.3R@gmail.com
can u give a hint on how to fix that ZRTP SAS issue so the SAS always shows up?
also, if i build with the new jni folder, will ZRTP work ? :p
keep on up with the great work!
cheers,
Francisco
Original comment by francisc...@gmail.com
on 7 Nov 2011 at 6:16
@fransisco : I just did a commit that should help (even if not yet clean) with
the sas display as pointed out by gcjoe. If you use timer.c implementation
instead of android_timer.cpp implementation it should work. It may also work
depending on device with the timer_android.cpp (depends on the dalvik config).
About the other issue pointed out by gcjoe : timer_stop never called there is
maybe something too. I've to investigate this point too when pjsip-2.0 will be
used on nightlies.
Maybe if Werner can give me some pointers about why timer_stop exists but is
never launched by the rest of the code, it could help me to understand what is
wrong in my timer implementation or if there is something missing somewhere ;).
Original comment by r3gis...@gmail.com
on 7 Nov 2011 at 9:22
First of all, thanks r3gis for the modification to the source code about SAS display . It works great. I have a question. I am getting this error in LogCat:
11-10 11:49:32.827: E/libpjsip(21359): 11:49:32.843 timer_android. Huh, pj is
cancelling something already unknown... : 0.
What does this mean? I understand that there is a problem with the timer. What
can I do to fix this? Does this influence ZRTP in any way? I mean, ZRTP is
active and my call is secure, isn't it?
Also I would like to suggest an enhancement which already exists in Jitsi.
There, in Options->Zrtp (ZRTP Ninja) you can select in Standard and Mandatory
different key lengths for AES encryption (128 and 256) , and during a call it
is displayed on the screen that your call is secured , the encryption method
and key length. For example: (Cipher: AES-256). Do you think this could be
implemented in CSipSimple also under the 4 digit SAS ?
Thanks, and keep up the good work.
I am using CSipSimple r1064 on a Htc Desire HD (Android 2.3.3) and Samsung
S5570 (Galaxy Mini Android 2.2.1) on a Freeswitch Server in proxy media mode.
Original comment by ursu.adr...@gmail.com
on 10 Nov 2011 at 10:09
The error raised by the timer_android implementation should actually be a
warning. It is just to warn me about the fact pjsip is trying to cancel a timer
that it has already previously cancelled or that was already fired. I tried to
track down which was the root cause of this dupplicate cancel. But seems to be
normal, and the timer implementation should (and actually is), robust to
duplicate cancel or cancel after execution of the callback. So this error
should just be ignored ;). That was just for me to debug that.
About the key lenght, it should be possible I think. I put that in my todo list
:).
Original comment by r3gis...@gmail.com
on 10 Nov 2011 at 10:14
New nightly build available here :
http://nightlies.csipsimple.com/trunk/
Now TLS and ZRTP are part of trunk builds. ZRTP support should have been really
improved. The UI should not mix infos from several calls anymore and should
always display the SAS (it asks to confirm only if needed). It will also show
the AES encryption type.
As it's a new build toolchain and it's based on a different pjsip version there
is maybe some possible regression, feel free to open new issues about it :).
Also I'm unsure about how it will go on all android phones since the openssl
library is not included into the app but it tries to rely on the one of the
phone.
For now I never found a phone without openssl on it. However, if someone has a
phone without openssl I can produce a plugin which intent to provide openssl
library to CSipSimple.
Original comment by r3gis...@gmail.com
on 20 Nov 2011 at 9:42
Thank you! My first try with your binary package (r1129) is no luck, beacause
CSipSimple crashes immediately when the peer answer the call (TLS+ZRTP enabled
of course). I'll try build one from source (if I can) in the next week, then I
can send a backtrace.
Original comment by gcjo...@gmail.com
on 20 Nov 2011 at 6:32
Thanks r3gis, my first wave of testing on r1132 did not go so well. The
calling phone would freeze when placing a call to a zrtp enabled peer.
Happened on both my devices. r1136 works great! Tested a few calls between
espresso devices running cyanogen 7.1. ZRTP support has come so far in the
last year, thanks!! I did all my testing on tanstagi.net, its been
around/stable for a year as well, with more and more people using it, any
chance for a wizard with TLS/ZRTP enabled? It requires no special
configuration options just tls/zrtp.
Original comment by wheresau...@lavabit.com
on 21 Nov 2011 at 2:20
In 1136 I did a couple of fixes specially for android 2.2 device (that were
completly broken previously).
Yes we should add a Tanstagi.net wizard now that ZRTP and TLS are features of
the trunk version :D. I've just added an issue about that : issue 1389.
In a first time maybe some simple link to the web page to create an account. If
you think it would be better to do that through a more advanced web api from
within the app you can send me infos by mail or on the issue 1389.
Original comment by r3gis...@gmail.com
on 21 Nov 2011 at 2:46
Sorry but 1136 is still crash for me when the peer answer the call (ZRTP mode).
********** Crash dump: **********
Build fingerprint:
'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
pid: 1895, tid: 2208 >>> com.csipsimple:sipStack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3135327c
Stack frame #00 pc 000e9874 /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so:
Routine pj_lock_acquire in
CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//src/pj/lock.c
:178
Stack frame #01 pc 000ebbea /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so:
Routine lock_timer_heap in
CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//../../android
_sources/pjlib/src/timer_android.c:338
Stack frame #02 pc 0007a5a0 /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so:
Routine Java_org_pjsip_pjsua_pjsuaJNI_pj_1timer_1fire in
CSipSimple/jni//swig-glue/android_toolchain/../nativesrc/pjsua_wrap.cpp:18713
Stack frame #03 pc 000180f4 /system/lib/libdvm.so
Stack frame #04 pc 00046624 /system/lib/libdvm.so
Stack frame #05 pc 0001d304 /system/lib/libdvm.so
Original comment by gcjo...@gmail.com
on 21 Nov 2011 at 11:10
Another problem that r1128 - r1136 versions are never sent REGISTER message to
the SIP server while the account status shown as "Registered" (green).
Original comment by gcjo...@gmail.com
on 21 Nov 2011 at 11:15
a current walk through for using csipsimple w/ tanstagi
http://freeborn.devio.us/doku.php?id=androiddiffemyhellman
gcjo, did you make sure to enable TLS in the transport settings of your account
settings?
Original comment by wheresau...@lavabit.com
on 22 Nov 2011 at 9:01
Thank you for this pointer! Both problems are solved!
No I don't use TLS. I try to use CSipSimple with my own Freeswitch build
(simple bypass mode). This is a working setup, the ZRTP calls are works fine
when I try with an r1064 build.
But my config was wrong, because under Network->Secure transport it was checked
on the TLS checkbox. After I uncheck this box, now the outgoing calls are works
fine with ZRTP (on UDP transport), so in this case no timer crash anymore!
The REGISTER message problem is also solved. I forgot to fill the "Registration
URI" (it was empty) in the account settings and this caused that the account
shown as "Registered" (green) but the REGISTER message was not sent.
Thank you!
Original comment by gcjo...@gmail.com
on 22 Nov 2011 at 11:32
Thanks for the Link!
Is this kinda common description for setting up an account for crypted use?
The reason why I am asking: i am new to this and i dont want to open tickets
because of misconfigured devices on my side:).
It would be great if we have smth like an easy to follow walkthrough for the
common settings.
Why do you guys use TLS if SRTP does the work already?
Btw.. i tried to get some SAS working, but it didnt show up. Therefore ZRTP
tells us: "No verification"
Thanks for you comments
Original comment by automate...@gmail.com
on 25 Nov 2011 at 5:14
Well, first thing to know is that there is to communication plan in SIP. There
is the media plan (the actual audio other side receive) and the control plan
(it's here to invite, hold, cancel, hangup the call).
SRTP and ZRTP apply both to media plan. TLS (SIPS) apply to control plan.
If there is a hacker on your network and that the control plan is not secured
he will be able to see who calls who and to terminate calls (and maybe to
gather some interesting infos about your sip password -- not immediate info,
but could be deduced after many calls).
If the media plan is not secured, he will be able to listen what is said in the
conversation.
So TLS and S/Z RTP are for two distinguished purpose.
There's guys here much more expert about these points than me so do not
hesitate to correct me if I'm wrong ;).
For TLS you need a sip server that supports TLS to be able to talk with it an
encrypted way. So this is a feature of your sip provider.
About SRTP and ZRTP that's different.
First about SRTP. This way has to be announced during the negociation of call
and to be accepted by both parts. If the media does not go directly between you
and your remote party but is modified by your sip provider they also need to
support SRTP on their side. Then on between their server and your remote party
it's another negociation.
So in order to have this feature working, either your sip provider (if media
gatewway) or your remote party must support this, else it will not be activated.
About ZRTP. It is not 'necessary' to announce it during the negociation, and
can be established over an ongoing call. As previously both party *must*
support the feature. If your sip provider filter or does media gateway stuff it
may drop ZRTP feature so that the other side will never receive ZRTP hello
packets.
So also, to have this feature working you may first understand what's done on
your sip server side.
If you just want to directly test the feature without further configuration on
a sip server, there is a simple way to do so if your two devices are on the
same network.
You can simply create a "local account" on each device (there is a specific
wizard for that). Disable all other accounts on each device. And call directly
one device with the other using direct IP address (you can get in android
settings). To do this peer to peer call, use the text dialer (little icon on
the left top corner of the dialer). And type the complete remote address :
user2@xxx.xxx.xxx.xxx where the xxx.xxx.xxx.xxx is the ip address of the second
device.
Original comment by r3gis...@gmail.com
on 25 Nov 2011 at 6:06
The above timer crash (comment c88) is still occurs but very rarely.
Original comment by gcjo...@gmail.com
on 27 Nov 2011 at 10:47
automate...
yes thats a guide to get csipsimple running quickly with TLS and ZRTP on
tanstagi. Its even easier now that r3gis has added the wizard. Good luck, let
me know if you have any issues connecting.
Original comment by wheresau...@lavabit.com
on 30 Nov 2011 at 2:57
I was just passed this pdf (pdf:
http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper001.pdf ) it states
that VBR codecs can be snooped on regardless of encryption. Im trying to find
out which codecs are VBR and which are non-vbr, anyone else have any thoughts
on this?
Original comment by wheresau...@lavabit.com
on 30 Nov 2011 at 3:04
has someone managed to get CSipSimple working with linphone?
srtp works, but with zrtp, sound is garbled (using the same codecs as with
srtp).
OnSIP and IpTel seem to work the best, Nymgo seems to hijack the stream and
disable ZRTP, Ekiga seems not very reliable or is too picky.
message: ZRTP INFO zrtp_InfoInitConf1Received
message: ZRTP secrets on: SAS is abcd previously verified no - algo
AES-CM-128/DH3k
message: sent ZRTP Confirm2 31337
message: ZRTP secrets for receiver are ready
message: Authentication token is abcd (unverified)
message: received ZRTP Confirm1 10
message: ZRTP secrets for sender are ready
message: ZRTP INFO zrtp_InfoSecureStateOn
message: Audio stream is encrypted
message: All streams are encrypted
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
message: bandwidth usage: audio=[d=68.5,u=80.4] video=[d=0.0,u=0.0] kbit/sec
message: Thread processing load: audio=2.180420 video=0.000000
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
message: received ZRTP Conf2ACK 11
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
...a million of these...
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
error: srtp_unprotect failed 7 ; packet discarded (may be plain RTCP)
... BYE ...
message: cb_sndbye (id=17)
message: eXosip: timer sec:0 usec:509995!
message: oRTP-stats:
Audio session's RTP statistics :
message: number of rtp packet sent=1782
message: number of rtp bytes sent=306504 bytes
message: number of rtp packet received=1750
message: number of rtp bytes received=306436 bytes
message: number of incoming rtp bytes successfully delivered to the
application=305216
message: number of rtp packet lost=32
message: number of rtp packets received too late=3
message: number of bad formatted rtp packets=0
message: number of packet discarded because of queue overflow=0
message: ms_filter_unlink: MSAlsaRead:0x2153ac0,0-->MSVolume:0x2171a00,0
message: ms_filter_unlink: MSVolume:0x2171a00,0-->MSG722Enc:0x215f240,0
message: ms_filter_unlink: MSG722Enc:0x215f240,0-->MSRtpSend:0x2102d80,0
message: ms_filter_unlink: MSRtpRecv:0x215de70,0-->MSG722Dec:0x214cc90,0
message: ms_filter_unlink: MSG722Dec:0x214cc90,0-->MSDtmfGen:0x215e060,0
message: ms_filter_unlink: MSDtmfGen:0x215e060,0-->MSVolume:0x20b20f0,0
message: ms_filter_unlink: MSVolume:0x20b20f0,0-->MSEqualizer:0x215f4f0,0
message: ms_filter_unlink: MSEqualizer:0x215f4f0,0-->MSAlsaWrite:0x215f140,0
message: Stopping ZRTP context
message: ZRTP secrets off
message: ZRTP secrets off
message: ZRTP INFO zrtp_InfoSecureStateOff
message: Destroying ZRTP wrapper
message: Destroying ORTP-ZRTP mutex
message: Destroying SRTP contexts
message: ORTP-ZRTP context destroyed
message: Audio MSTicker thread exiting
message: Filter usage statistics:
message: Name Count Time/tick (ms) CPU Usage
message: MSAlsaWrite 1743 0.191468 41.5972
message: MSAlsaRead 3569 0.0834608 37.117
message: MSG722Dec 1743 0.0316154 6.86858
message: MSG722Enc 1673 0.0252301 5.26134
message: MSRtpRecv 3570 0.00999456 4.44606
message: MSRtpSend 3569 0.00943405 4.19555
message: MSVolume 3416 0.00094114 0.40061
message: MSDtmfGen 3570 0.000193293 0.0859863
message: MSEqualizer 1743 0.000127403 0.0276788
message: MSFilePlayer 0 0 0
message: MSSpeexEC 0 0 0
message: Call 0x215e3f0: moving from state LinphoneCallStreamsRunning to
LinphoneCallEnd
message: Resetting the current call
Original comment by hvtaifwk...@gmail.com
on 4 Mar 2013 at 8:06
sflphone kind of works, after fixing a bug in it, but:
A ZRTP error forced the call with asdjweklfkwejrj@getonsip.com to fall under
unencrypted mode.
Exact reason: DH Error: bad pvi or pvr ( == 1, 0, or p-1)
Original comment by hvtaifwk...@gmail.com
on 4 Mar 2013 at 10:02
with latest git libzrtpcpp and ortp:
linphone 3.5.2 works with zrtp without extra patches, ortp needed one patch:
- zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc);
+ zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc,
zrtp_total_packet_length);
Original comment by hvtaifwk...@gmail.com
on 5 Mar 2013 at 10:48
When calling CS→Linphone, ZRTP does not get enabled. It works the other way.
CS→Linphone logs as seen from CS:
08:59:16.802 zrtp_android.c ZRTP info message: Responder: Commit received,
preparing DHPart1
08:59:16.802 zrtp_android.c ZRTP info message: DH1Part: Generated a public DH
key
08:59:17.070 strm0x15a169c RTP decode error: Invalid RTP version
(PJMEDIA_RTP_EINVER) [err:220122]
08:59:17.070 strm0x15a169c RTP status: badpt=0, badssrc=0, dup=0,
outorder=-1, probation=0, restart=0
08:59:17.106 sip_endpoint.c Processing incoming message: Response msg
200/INVITE/cseq=13425 (rdata0x134e42c)
...
08:59:17.151 pjsua_media.c .....Call 0: updating media..
08:59:17.151 pjsua_media.c ......Call 0: stream #0 (audio) unchanged.
08:59:17.151 pjsua_media.c ......Audio updated, stream #0: GSM (sendrecv)
08:59:17.151 timer_android. .....Scheduling timer 1 of 8 in 0 ms @ 0x5bbc1624
08:59:17.183 pjsua_jni_addo .....Get secure for media type 1
08:59:17.183 zrtp_android.c .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:17.183 zrtp_android.c .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:17.184 pjsua_aud.c .....Conf connect: 2 --> 0
08:59:17.184 pjsua_aud.c .....Conf connect: 0 --> 2
08:59:17.224 inv0x130000c ....Received Response msg 200/INVITE/cseq=13425
(rdata0x134e42c), sending ACK
08:59:17.224 tdta0x15a4710 ....Destroying txdata Request msg ACK/cseq=13424
(tdta0x15a4710)
08:59:17.224 endpoint ....Request msg ACK/cseq=13425 (tdta0x15a4710)
created.
...
08:59:31.449 pjsua_jni_addo .....Call 0 is DISCONNECTED [reason=200 (Normal
call clearing)]
08:59:31.451 pjsua_jni_addo .....Get secure for media type 1
08:59:31.451 zrtp_android.c .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:31.452 zrtp_android.c .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:31.503 pjsua_media.c .....Call 0: deinitializing media..
08:59:31.503 timer_android. .......Scheduling timer 1 of 8 in 1000 ms @
0x5bbc90ac
08:59:31.521 strm0x15a169c .......JB summary:
size=0/eff=0 prefetch=0 level=3
delay (min/max/avg/dev)=20/500/45/48 ms
burst (min/max/avg/dev)=1/5/2/0 frames
lost=0 discard=56 empty=101
08:59:31.521 pjsua_media.c .......Media stream call00:0 is destroyed
08:59:31.521 transport_zrtp ......Media stop - encrypted packets: 0, decrypted
packets: 0
08:59:31.521 icetp00 ......Stopping ICE, reason=media stop requested
08:59:31.521 transport_zrtp ......Destroy - encrypted packets: 0, decrypted
packets: 0
08:59:31.521 icetp00 ......ICE stream transport 0x13989f4 destroy
request..
08:59:31.521 stuntp0x144e1e .......STUN sock 0x1574374 request, ref_cnt=8
Logs from Linphone:
message: CALL_ACK
message: sent ZRTP Hello 4258
message: received ZRTP HelloACK 2
message: sent ZRTP Commit 4259
message: Received message:
INVITE sip:x@85.156.y.y SIP/2.0
...
a=zrtp-hash:1.10 cb4d...
...
message: Stopping ZRTP context
message: Destroying ZRTP wrapper
message: Destroying ORTP-ZRTP mutex
message: Destroying SRTP contexts
message: ORTP-ZRTP context destroyed
message: Audio MSTicker thread exiting
(Linphone has no feature "timestamps in logs")
Original comment by hvtaifwk...@gmail.com
on 29 Mar 2013 at 7:22
Original issue reported on code.google.com by
wheresau...@lavabit.com
on 5 Oct 2010 at 10:52