ZRTP actually operates as if it were a "plugin" in Twinkle; the associated libraries are dloaded rather than directly linked, and this happens only when Twinkle has ZRTP activated. This happens in the "User Profile" settings under security tab. There is additional ui elements that exists in Twinkle itself as well. However, if you never activate and use ZRTP you will not encounter ZRTP related issues or any crashes related to it.
My issues with the current versions of Twinkle/ZRTP related packages is actually drawn from my experience with Lenny, Hardy and Intrepid, which also used the same upstream versions, and these versions used together (zrtp 1.3, and twinkle 1.1 in particular prior to Jaunty which uses 1.2) are known to be bad by respective upstream maintainers (myself, Werner Ditterman, Michael De Boer). Specific issues I recall, from my Lenny and Intrepid testing, varied from constant pulsing (loud) noise during active ZRTP call sessions to the ui crashing during ZRTP call establishment to an inability for the application to terminate normally (one had to use kill -9...). While I had not used Twinkle 1.2 with Zrtp 1.3 myself (I had skipped to Twinkle 1.3, and now that is out,1.4, for my testing, based on recommendations of Werner), ZRTP 1.3 also is not interoperabile with later zfone releases or with any of the IETF drafts for ZRTP and is unable to detect this fact. Upgrading to ZRTP 1.4 requires some matching ui and api support changes that are only found in more recent Twinkle releases. Hence, 1.4(.3) libzrtpcpp also requires Twinkle 1.3.x or 1.4.x. Also, changes were made in ccrtp (1.7 releases) that are reflected in libzrtpcpp. So the entire library set and Twinkle need to be updated and synchronized on more current upstream versions for ZRTP to be both usable and interoperable. The three tests I would suggest would be to establish a ZRTP call with Jaunty to another Jaunty ZRTP twinkle instance, establish a call between Jaunty ZRTP and the new packages I have, and do so directly between my two packages. I recall ZRTP 1.4 now detects that the 1.3 instance is protocol obsolete, will no longer establish a broken ZRTP session (hence at least no pulsing noise) and will give a message in the Twinkle call log indicating that ZRTP could not be negotiated; you will have an insecure session established. I think twinkle 1.2 had missed some gui elements when in active ZRTP calls for confirming the SaS. Somewhere in this testing you may also get a Jaunty Twinkle instance that also fails to exit. In a successfully negotiated ZRTP call session, you will see a lock icon and a SaS string displayed as part of the call status screen. You will also be able to click on the SaS lock icon to confirm the keys. You will also need to look at the Twinkle call log to see what has happened during any testing. ZRTP cannot normally be tested through Asterisk because Asterisk forms media connections as a B2BUA and maintains it's own codec processing, hence the endpoints cannot directly exchange end- to-end keys over RTP media and refuse to establish a ZRTP session. You can either test by having each Twinkle client call the IP address of the remote client directly, or by using a non-B2BUA based pure SIP call server, such as SIP Witch or sipxpbx, to mediate the call. I hope this clarifies the issue. I was thinking of just submitting updates of current packages (based on current upstream versions), so it would get updated in time for 9.10. If you think this should be updated in Jaunty (I presume post-release ;), this I imagine could be considered as well, although again the zrtp specific issues have no effect or have any relevant issues for non-zrtp users. -- Obsolete version with broken zrtp support https://bugs.launchpad.net/bugs/361827 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
