Activity Log : GSoC Week #06 (26.V - 1.VI)

Finally got over with my exams last week, so I started writing my first lines of code in the weekend. You can find these here:

• .patch format : http://students.info.uaic.ro/~eonica/sc/zrtp01.patch


• zip archive : http://students.info.uaic.ro/~eonica/sc/patch01.zip


• actual created/modified sources : http://students.info.uaic.ro/~eonica/sc/patch01/

I've also received Werner's code (which I might say again is much more advanced than I am into the matter). After I've looked into it, though I didn't finish yet, my opinion is that it will possibly be a solution not very hard to do, to follow his integration approach, which differs a bit from mine, and find a way to bind it to SIP Communicator; or may also be a solution to combine the approaches, like I'll describe in the end.

Until then, a few words about what I have done until receiving Werner's code:

The sources posted consist mostly of a simple skeleton solution for binding the ZRTP services into the current SRTP implementation. I've tried to make detailed comments inside them so I'll be more short here describing only the general idea:

(I'm not sure how clear I'll be, so I'll recommend for everybody who reads forward to look at the same time on the sources also to get the idea)

I have added two packages : keyshare and keyshare.zrtp.

The connection "starts" in this case also, as for SRTP, in the CallSessionImpl class, in the initializeRTPManager method. The keyshare package contains a very small interface KeyProvider which is intended to define the current supported key management/provider types (for now only ZRTP and a DummyProvider) and has a method for retrieving the provider type. The interface is implemented by two classes, ZRTPProvider and DummyProvider as mentioned, which act more like some constants. The createSRTPConnector in the TransportManager class takes as last parameter an object which implements KeyProvider. Based on the provider type retrieved through the method I've mentioned above it acts accordingly to start the associated implementation for key management (takes a branch on an if to be more clear :) ). In case of ZRTP provider type it instantiates a ZRTPConnector (about which I'll talk below). In case of a DummyProvider procedes as it did before instantiating a SRTPConnector with the hardcoded keys. I made all this selection process (which actually should be developed a bit more) with the purpose to offer a possible entry point for other key management solutions.

(Actually, the KeyProvider interface defined also methods for getting and setting the crypto parameters needed to provide for the SRTP transformation, but I removed them yesterday because I found it to be a bit redundant - the SRTPTransformEngine has already the getters for these; so in conclusion the Provider type classe might look a bit strange and probably could be reduced only to the constants - or could be let this way in case of possible additional methods to be added)

This was the description of the "choosing" of the ZRTP key management solution or any other one (which process isn't final, as I said). Now, focusing on the actual ZRTP part. I've left the description at instantiating the ZRTPConnector in the TransformManager. The ZRTP related classes are contained in the keyshare.zrtp package, and of course the ZRTPConnector is also there. Before going forward, I'll insert a scheme which presents the most important points of interconnection in this package, regarding the integration problem.

I know it's not really UML but I hope it's understandable :). I've described also inside the source comments how it works, so I won't get into deep details here. Shortly speaking, it's like I said a skeleton implementation which runs in the next way:

• ZRTPConnector extends TransformConnector and overrides all the methods concerned with the input and output stream creation
• ZRTPConnector makes use of two specific ZRTP input and output stream classes, which extend TransformInputStream and TransformOutputStream, overriding the read and write methods.
• These methodes are the ones directly responsible with receiving and sending the packets. This is the point of actually binding ZRTP to SC by using in these methods the specific ZRTP services provided by the ZRTP4J library which should be accessed through a ZRTPPacketManager class instance (which is empty at this moment).
• A sole instance of this class is passed both to the input and the output stream by the ZRTPConnector, which fact provides the possibility to "communicate" between the read and write methods if needed or any other type of interaction between the input and output stream.
• In the read and write methods, based on the information provided by the ZRTPManager about the ZRTP state, the streams may send RTP, SRTP or ZRTP packets (for SRTP is called the base class implementation - which I've tested).
• The read and write methods have access to the SRTPTransformEngine to set and get the necessary info they need in the ZRTP communication. This is done by accessing the base class SRTPPacketTransformer member which may expose the SRTPTransformEngine through a getter.

This would be in rough lines my idea of integration. It's explained a bit more in detail in the comments inside the sources.

I don't know if it's ok or not. It might bring some limitations at some points, but I'm not so experienced to ZRTP to see exactly where now. I've tried to keep the SRTP-ZRTP coupling as low as possible. As it can be seen, all the idea is like practicaly adding a ZRTP separate layer, the only modifications I've done in the SRTP implementations being adding some getters and some setters for the derived classes.

Werner's approach after a basic look I've taken into the sources, is based on defining a ZRTPTransformEngine for the main part of the integration. This engine, as far as I can tell after a quick analysis, has pretty much the role I've imagined for my ZRTPPacketManager, so one option would be to adapt Werner's ZRTPEngine interaction to fit my approach related to ZRTPPacketManager (if it's a good approach, about which I have some doubts...) and "connect" the way I described, to the ZRTP library.

This is only an idea which might be taken into consideration :), but as said at start it may be also even better to try finding an integration way for ZRTP4J, based directly on Werner's current transform.zrtp package design (which doesn't seem to hard, but I still need to get some more things clear). Like I said, I still have a bit more to look on the sources to understand them better, and I'll try to think on the integration part also while doing that (maybe I'll get some ideas until the chat).

PS:

Sorry for not posting last evening, as I said I'll try in my mail. Have the bad habit of commenting the code after I finish a work phase, and this time the code comments took longer than I thought : ...