SRTP design thoughts and some general implementation

Recently I did some design and implementation of the SRTP project's architecture. I'd like to share my thoughts with you. :-)

OK, here's my design:
1. The srtp support will be based on JMF's RTP support. We will translate each RTP packets into SRTP packets before they are sent out.
And translate received SRTP packets into normal RTP packets before they are forwarded to JMF.
This means we only perform the translation between RTP and SRTP. Normal RTP's work is still done by JMF, such as jitter buffer control.

2. JMF allow developer to specify the transport of RTP packets. The RTPConnector interface is design for this purpose.
JMF will write outgoing packets through RTPConnector and read incoming packets from RTPConnector.
So, by implementing the RTPConnector interface, we could intercept the outgoing/incoming RTP/RTCP packets and then do our encryption/decryption work.

3.The encryption/decryption is actually a transformation of RTP packets. So, we can first define a general class "TransformConnector".
And then specify the transforming logic through interface "PacketTransformer". Each implementation of "PacketTransformer" contains
the concrete logic of how the packets will be manipulated. In our case, we will encapsulate our encryption/decryption logic in "SRTPTransformer".

4. TransformConnector and related support class such as TransformInputStream / TransformOutputStream deals with abstract PacketTransformer interface.
When a packet is ready to be sent, it will be handed to PacketTransformer, after transformation, the returned packet (maybe complete new one) will then be sent out.
When a packet is received, it will fist handed to PacketTransformer for reverse transformation, and then the returned packet will be handed to JMF for later processing.

Here's the implementation status:

1. I finished a minimal implementation of the above design. And created a dummy transformer (does nothing, returns the packet to be transformed directly)
2. I modified JMF's example code and make a small test program, to test the dummy transformer (and the TransformConnector). In my environment, it works fine.
The core modification is instead of initialize RTPManager using local address and add remote address as target, we pass our TransformerConnector object to
the initialize() method of RTPManager.
3. I use eclipse 3.2.2 as my IDE. JMF's version is 2.1.1e.
Coding styles and project related regulations are not considered so much, will be refactored later.

Roadmap updated

As the project moves on, the road map I made in GSoC application is not up-to-date and has not enough details for further work. So, I updated it:

1. Getting started. (05/01/2007 - 05/07/2007)
1. Set up working environment. Things includes:
1. Create a dev blog. (DONE, http://sipcomm-srtp.blogspot.com)
2. Set up the project repository for my own purpose.
   After Emil has set up the project on java.net, all the code and document will be moved there.
3. Have meeting with my mentors, discuss this roadmap with them. Make this roadmap more clear.
   
2. Read RTP/SRTP related RFC. Study opensource SRTP implementation (e.g. libsrtp). Learn how SRTP is defined and normally how it would be implemented.
   After this step, I will write a simple description of my understanding. It will contain the main problems of the implementation and my brief design.
3. Write a test RTPConnector implementation. It will do nothing except sending the RTP/RTCP packets out directly. The main purpose is to prove that we are able to intercept RTP/RTCP packets before they are sent out. And later this piece of code will be our base for further development.
   After this step, there will be a RTPConnector implementation, together with a simple JMF RTP test program. This RTPConnector is not used immediately in SIP Communicator, since test using SIP Communicator will be more complex. The integration work should be done after we have a runnable SRTP implementation.
   
   
2. Design and implementation. (05/08/2007 - 06/19/2007)
   
   In this step, I would like to mix the design and coding work together.
   The process will mostly like this:
   a. Write some code (make some design decisions)
   b. Describe the main design thoughts / choices.
   c. Post it on the dev list (and dev blog) and discuss with all the dev team.
   d. Fix the unproper choices.
   e. Go back to "a" to continue coding until the main implementation work is done.
   
   After this step, there should be a minimal working SRTP implementation based on JMF.
   And we shall have a simple test program to verify its behavior.
   
   There will certainly be more details about this design and implementation step. They shall be pointed out gradually when we are working on this step.
   
   
3. Add SRTP support for SIP Communicator. (06/20/2007 - 07/03/2007)
1. Study SIP Communicator in detail.
   Find out what should be modified in order to use the new SRTP plug-in.
2. Make necessary changes to SIP Communicator, make it able to use the SRTP implementation.
   
   
4. Test and bug fix. (07/04/2007 - ?)
   Find out as many SIP and SRTP enabled applications as I can. Test SIP Communicator with them. Find bugs, and fix them.
   
   
5. Implementation Report (07/04/2007 - ?)
   Organize previous design documents, discussion emails, and then write the final Implementation report.
   

Getting Started

Hello, everybody!
This blog is dedicated for my GSoC 2007 project: RTP Encryption for SIP-Communicator. I will post project plans, designs, implementation thoughts, progress information and anything related to the development process here. Your comments and suggestions are highly appreciated.