[sip-comm-dev] SRTP design thoughts and some general implementation


#1

Hi, all

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

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.
4. Because currently project repository is not set up, so the project is
packed into a zip, attached with this email.
If this is not suitable for mailing list, will somebody tell me? Thank you.
5. Wish this piece of code can make you understand my thoughts a little
easier. :smiley:

Thank you,
Su

srtp4jmf.zip (15.4 KB)


#2

Hi Su,

Regarding the discussion on the IRC channel, here is a link from Kensan that might be of your interest: http://sourceforge.net/mailarchive/message.php?msg_id=444a31a20610130953o5d9d016cxabbe9e2813f3ca41%40mail.gmail.com

Cheers,
romain

路路路

On 2007/05/07, at 23:44, Bing Su wrote:

Hi, all

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

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.
4. Because currently project repository is not set up, so the project is packed into a zip, attached with this email.
If this is not suitable for mailing list, will somebody tell me? Thank you.
5. Wish this piece of code can make you understand my thoughts a little easier. :smiley:

Thank you,
Su
<srtp4jmf.zip>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Thank you, Romain. Will look at it.

路路路

On 5/10/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

Hi Su,

Regarding the discussion on the IRC channel, here is a link from
Kensan that might be of your interest: http://sourceforge.net/
mailarchive/message.php?
msg_id=444a31a20610130953o5d9d016cxabbe9e2813f3ca41%40mail.gmail.com

Cheers,
romain

On 2007/05/07, at 23:44, Bing Su wrote:

> Hi, all
>
> Recently I did some design and implementation of the SRTP project's
> architecture. I'd like to share my thoughts with you. :slight_smile:
>
> 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.
> 4. Because currently project repository is not set up, so the
> project is packed into a zip, attached with this email.
> If this is not suitable for mailing list, will somebody tell me?
> Thank you.
> 5. Wish this piece of code can make you understand my thoughts a
> little easier. :smiley:
>
> Thank you,
> Su
> <srtp4jmf.zip>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi all,

I've updated my roadmap according to previous discussion.
Because I find plain text roadmap hard to maintain, I switched to word, and
thus converted it to a pdf.
It is attached with this email, take a look if you are interested. :slight_smile:
Of course it is not the final one, it will be updated as this project goes
on.

Best regards,
Su

roadmap.pdf (113 KB)


#5

Hi Su,

Thank you for the roadmap. This reflects what we discussed on IRC last time.
BTW, would you like an account on the SIP Communicator's Wiki? The wiki may be a more efficient tool to maintain your roadmap, and would avoid the word->pdf->ML procedure.

This comments also applies to other GSoC students. Raise your hand if you're interested!

Thanks,
romain

路路路

On 2007/05/15, at 9:54, Bing Su wrote:

Hi all,

I've updated my roadmap according to previous discussion.
Because I find plain text roadmap hard to maintain, I switched to word, and thus converted it to a pdf.
It is attached with this email, take a look if you are interested. :slight_smile:
Of course it is not the final one, it will be updated as this project goes on.

Best regards,
Su
<roadmap.pdf>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Sure! It will be definitely great to maintain the roadmap through wiki.
So, where is it? I searched for it, but only found an empty one at:
http://wiki.java.net/bin/view/Communications/SipCommunicator.

Thank you,
Su

路路路

On 5/15/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

Hi Su,

Thank you for the roadmap. This reflects what we discussed on IRC
last time.
BTW, would you like an account on the SIP Communicator's Wiki? The
wiki may be a more efficient tool to maintain your roadmap, and would
avoid the word->pdf->ML procedure.

This comments also applies to other GSoC students. Raise your hand if
you're interested!

Thanks,
romain

On 2007/05/15, at 9:54, Bing Su wrote:

> Hi all,
>
> I've updated my roadmap according to previous discussion.
> Because I find plain text roadmap hard to maintain, I switched to
> word, and thus converted it to a pdf.
> It is attached with this email, take a look if you are interested. :slight_smile:
> Of course it is not the final one, it will be updated as this
> project goes on.
>
> Best regards,
> Su
> <roadmap.pdf>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Su,

Emil has created an account for you on the Wiki.
You can access the Wiki from this page (click on the "Roadmap" link beside your name):
http://www.sip-communicator.org/index.php/Development/TeamAndContributors

I'll send you a private mail about your login details.

Thanks,
romain

路路路

On 2007/05/15, at 14:01, Bing Su wrote:

Sure! It will be definitely great to maintain the roadmap through wiki.
So, where is it? I searched for it, but only found an empty one at: http://wiki.java.net/bin/view/Communications/SipCommunicator .

Thank you,
Su

On 5/15/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote: Hi Su,

Thank you for the roadmap. This reflects what we discussed on IRC
last time.
BTW, would you like an account on the SIP Communicator's Wiki? The
wiki may be a more efficient tool to maintain your roadmap, and would
avoid the word->pdf->ML procedure.

This comments also applies to other GSoC students. Raise your hand if
you're interested!

Thanks,
romain

On 2007/05/15, at 9:54, Bing Su wrote:

> Hi all,
>
> I've updated my roadmap according to previous discussion.
> Because I find plain text roadmap hard to maintain, I switched to
> word, and thus converted it to a pdf.
> It is attached with this email, take a look if you are interested. :slight_smile:
> Of course it is not the final one, it will be updated as this
> project goes on.
>
> Best regards,
> Su
> <roadmap.pdf>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Romain,

I've logged in, changed my password and upload the roadmap with no problem.
Thank you. This wiki approach is really much more convenient. :slight_smile:

Cheers,
Su

路路路

On 5/16/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote:

Hi Su,

Emil has created an account for you on the Wiki.
You can access the Wiki from this page (click on the "Roadmap" link
beside your name):
http://www.sip-communicator.org/index.php/Development/
TeamAndContributors

I'll send you a private mail about your login details.

Thanks,
romain

On 2007/05/15, at 14:01, Bing Su wrote:

> Sure! It will be definitely great to maintain the roadmap through
> wiki.
> So, where is it? I searched for it, but only found an empty one at:
> http://wiki.java.net/bin/view/Communications/SipCommunicator .
>
> Thank you,
> Su
>
> On 5/15/07, Romain KUNTZ <kuntz@clarinet.u-strasbg.fr> wrote: Hi Su,
>
> Thank you for the roadmap. This reflects what we discussed on IRC
> last time.
> BTW, would you like an account on the SIP Communicator's Wiki? The
> wiki may be a more efficient tool to maintain your roadmap, and would
> avoid the word->pdf->ML procedure.
>
> This comments also applies to other GSoC students. Raise your hand if
> you're interested!
>
> Thanks,
> romain
>
> On 2007/05/15, at 9:54, Bing Su wrote:
>
> > Hi all,
> >
> > I've updated my roadmap according to previous discussion.
> > Because I find plain text roadmap hard to maintain, I switched to
> > word, and thus converted it to a pdf.
> > It is attached with this email, take a look if you are
> interested. :slight_smile:
> > Of course it is not the final one, it will be updated as this
> > project goes on.
> >
> > Best regards,
> > Su
> > <roadmap.pdf>
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@sip-
> communicator.dev.java.net
> > For additional commands, e-mail: dev-help@sip-
> > communicator.dev.java.net
>
> --
> Romain KUNTZ
> kuntz@clarinet.u-strasbg.fr
> Louis Pasteur University - Networks and Protocols Team
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-
> communicator.dev.java.net
>

--
Romain KUNTZ
kuntz@clarinet.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net