I took some time this week to review the ZRTP integration in almost all its aspects.
This mail was meant to be shorter, but finally it got (again..) longer than I thought it will gonna be, so I'll add a summarry of the main ideas in the start:
I. GUI code restructuring II. Future multistream enhancement issues (and video securing)
III. Patches: ZRTP4J as JAR integration and provisionaly no-registrar IV. Tests summarry
V. Other revision points
--- I ---
About the code itself, even if it isn't very much added in terms of new classes, and besides the GoClear - GoSecure changes, which meant modifications in many parts of ZRTP4J (temporarily disabled), the rest of the code was pretty convoluted at some points. So, I've done another modification regarding to the GUI part, in order to simplify things a bit,
and also provide better means of extension for other possible future security solutions. More exactly, I've refactored the ZRTPGUI plugin under the name of SecurityGUI and I've moved all the button related ZRTP actions inside the SCCallback (ZRTP user callback class - in the media.transform.zrtp package). The movement was pretty logical; that class was already handling the changes on the label. Due to this change, the current architecture leaves the former ZRTPGUI plugin (now SecurityGUI) as a simple container for GUI items. These GUI items (now only for ZRTP) can be obtained and used by future various security solutions' GUI handling classes (like SCCallback now for ZRTP). Actually this was the idea from the first place - because of this, being designed also the general security change event, handled in CallSessionImpl, before ZRTP is selected as the default securing algorithm. In conclusion the effect of this GUI code restructuring (which actually isn't pretty much because the only element affected is the secure button) can be resumed for now as:
- as long the secure button is in initial state (command) of "startSecureMode", it has the role of a "general" toggle on/off security button and it's basic send secure change event action is handled in the SecurityGUI plugin;
- in case there is a call session active, setting the security on makes the button being "caught" in the SCCallback class, and after the ZRTP engine initiliazes, to "become" a ZRTP specific security button; this means that the ActionListener for the button is temporarilly set as being the SCCallback and the button will act by switching between ZRTP specific commands until the call is over; then it will go back to the "startSecureMode" command and the status of a general security button
(All this design is in particular very useful, probably among others, for the GoClear part in case will be re-enabled, because the button needs more commands there). I hope, it's clear enough because it's already too much talk about a single (yet complicated...) button :), so I'll get on to the next subject.
--- II ---
I've temporarily disabled also the security for the video RTP manager, like I actually was thinking at some point in the previous mail. This is based mainly on the fact that ZRTP4J doesn't support yet multistream mode, and the way this integration part was implemented until now could cause some unexpected results in case of simultaneous video securing (may probably work, as it is, with some more flags eventually added to the GUI part, but this doesn't comply with the standard which implies using multistream).
The disabling is done in CallSessionImpl and can be re-enabled by removing the comments which are pointed out at specific places by "Video securing related code" text.
I actually gave some thought about the multistream extension this week, and some basic opinions about the integration would be:
- The ZRTPTransformEngine variable used at ZRTPConnector creation in the TransformManager class should be a static variable, instantiated once and passed to all connectors (audio and video - one multistream engine for all streams)
- The SCCallback (ZRTP user callback class) should follow the same idea as one static variable in the TransformManager class
- The ZRTPTransformEngine should have an addConnector method instead an setConnector one and manage an array of connectors (one connector per stream)
This is the "binding"/integration part, between ZRTP4J and SC. Further, the connector array management should probably start to relate closely to the standard.
I personally intend to continue also after GSoC, when time permits, like I said in the previous mail, to further focus on the ZRTP integration enhancement, and I think multistream is the next part I'll consider in more detail.
--- III ---
One other thing I've done this week was to build SC with ZRTP4J included as a JAR. The ZRTP4J JAR was built from the ZRTP4J sources I've worked on, these containing also the (disabled) modifications for GoClear-GoSecure. In order to reduce the JAR's size I've removed the test package, which isn't used anyway in the integration. I didn't commit yet this build version to the encryption branch. For any further development I think it will be more easy for debugging to keep the current branch source structure (with perriodically commits to the main trunk).
However, for commiting the GSOC changes into the the main trunk, it might be better to use the JAR version. I've added to this mail a patch which applies to the current encryption branch transforming it into the JAR build version.
The other patch added to this mail as attachment is another update of the provisional no-registrar patch for the current encryption branch, which has the same problems as it did until now, but it also includes a minor fix for the account registration wizard part added to the initial Michael Koch's version. (Related to this patch also, I'll try to add an entry about the problems described a few weeks ago on the issue tracker soon)
--- IV ---
I've tried this weekend to redo some of the tests previously done to have a final GSOC situation. I gathered the ( all successfull ) results in a Google spreadsheet at the address: http://spreadsheets.google.com/pub?key=pISWJIBcSpdFFBkkNNKpvCQ
(it's my first Google spreadsheet so please don't be too critic on how it looks). I've added also some previous older tests I didn't do anymore, including also the one done by Werner with Minisip/Zfone (hope I got the basic data accurately). Since Free World Dialup seems to switch on fee-based status soon, I've searched for another free SIP provider service. The first one I've found was Free IP Call ( www.freeipcall.com ... if I remember correctly ) and the secure call test was successfully.
--- V ---
Other things done as a final GSoC revision for ZRTP4J integration:
- added resource support for all (hope I didn't missed any...) hard-coded strings used for tooltips, label, etc; I've translated these in Romanian also (unfortunately my German is pretty bad and the other languages are more or less unknown to me, so somebody else should handle this in case of a merge with the main trunk);
- done some more error handling and other fixes;
- added a few logger entries and some more comments;
Well, this is pretty much all about the final GSoC revision done this week. However, despite the "final GSoC" above, like I said, when I'll find some free time I'll try to continue the development for the multistream enhancement.
If there are any unclear points or other issues to be discussed about anything in this mail, please let me know.
This being said, because is the final GSoC week (but most probably not the final ZRTP4J-integration-related-way-too-long mail I'll send to the SC dev list ), I'd like to add many many thanks to Werner, Romain, Emil, Michael, and all the other SC dev team members, for support, guidance and providing a very useful learning experience in what I'm concerned throughout all the GSoC period.
ZRTP4J-jar-integration.patch (348 KB)
"Life is full of unexpected but nothing happens without a reason..."