|
List Info
Thread: SRTP design thoughts and some general implementation
|
|
| SRTP design thoughts and some general
implementation |

|
2007-05-07 16:44:49 |
|
Hi, all
Recently I did some design and implementation of the SRTP project9;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. 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. :-D
Thank you, Su
|
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-10 08:02:39 |
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.g
mail.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.
>
> 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. :-D
>
> 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
|
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-10 10:06:28 |
|
Thank you, Romain. Will look at it.
On 5/10/07, Romain KUNTZ < kuntz clarinet.u-strasbg.fr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
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 project9;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. > 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. :-D > > Thank you, > Su > <srtp4jmf.zip> > ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">kuntz clarinet.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dev-unsubscribe sip-communicator.dev.java.net For additional commands, e-mail:
dev-help sip-communicator.dev.java.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
dev-help sip-communicator.dev.java.net
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-15 02:54:38 |
|
Hi all,
I9;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.
Of course it is not the final one, it will be updated as this project goes on.
Best regards, Su
|
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-15 05:21:38 |
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.
> 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
|
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-15 07:01:44 |
|
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">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
you39;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.  > 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">
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">
kuntz clarinet.u-strasbg.fr Louis Pasteur University - Networks and Protocols Team
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe sip-communicator.dev.java.net">
dev-unsubscribe sip-communicator.dev.java.net For additional commands, e-mail: dev-help sip-communicator.dev.java.net">dev-help sip-communicator.dev.java.net
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-16 08:25:06 |
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/SipComm
unicator .
>
> 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.
> > 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
|
|
| Re: SRTP design thoughts and some
general implementation |

|
2007-05-16 21:06:19 |
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.
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/SipComm
unicator .
> >
> > 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.
> > > 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
|
|
[1-8]
|
|