ZRTP plugin for GStreamer

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ZRTP plugin for GStreamer

Werner Dittmann
All,

after some hacking I have a first working version of the proposed ZRTP/SRTP
plugin for GStreamer.

I'm not familiar with GStreamer and its preferred ways to do things, thus I
need some advise here :-) , for example how to implement asynchronous communication
with the application to inform it about security status, etc.

For asynchronuos communication: use signal or messages, or a combination of both?
The data that zrtpfilter sends to the application is small, 2 integers usually
or a string or two. No complex structures.

I also like to ask for advise which technique to use to handover properties. Most
properties are simple, just integers, booleans - that does not pose a problem. In
one case, however, I would like to have a set of parameters at once, a combination
of integers, boolean, string. This could be done step-by-step, but in this case
a structure would be more covenient. Is this possible? Any pointers/links to an
example if it is possible?

I'll do some cleanup of the code and then create a git repository on github.
This will happen later today and I keep you informed.
NOTE: this is a very first pre-alpha version :-) not ready for real stuff, only
for testing the principal implementation etc.

The current layout of zrtpfilter:


           +-------------------------------------+
           |              zrtpfilter             |
           +---------------+      +--------------+
           |recv_rtp_sink  |      |recv_rtp_src  |
  from     |               |      |              |  to RTP
  network  +---------------+      +--------------+  plugin,
  plugin,  |                                     |  e.g.
  e.g.     +---------------+      +--------------+  rtpbin
  udpsrc   |recv_rtcp_sink |      |recv_rtcp_src |
           |               |      |              |
           +---------------+      +--------------+
           |                                     |
           +---------------+      +--------------+
           |send_rtp_sink  |      |send_rtp_src  |
           |               |      |              |  to
  from RTP +---------------+      +--------------+  network
  plugin,  |                                     |  plugin,
  e.g.     +---------------+      +--------------+  e.g.
  rtpbin   |send_rtcp_sink |      |send_rtcp_src |  udpsink
           |               |      |              |
           +---------------+      +--------------+
           |                                     |
           +-------------------------------------+

The plugin is a full-duplex plugin that handles up- and downstream traffic for
RTP and RTCP. If connected with another ZRTP enabled client it automatically
negotiates the SRTP keys and enables SRTP and SRTCP. This is fully transparent
to the connected up- or downstream plugins. During my tests I use this setup:

gst-launch --gst-plugin-path=$HOME/devhome/gstZrtp/build/src -m \
    zrtpfilter name=zrtp \
    udpsrc port=5004 ! zrtp.recv_rtp_sink zrtp.recv_rtp_src ! \
        fakesink dump=true sync=false async=false \
    udpsrc port=5005 ! zrtp.recv_rtcp_sink zrtp.recv_rtcp_src ! \
        fakesink dump=true sync=false async=false \
    zrtptester name=testsrc \
    testsrc.src ! zrtp.send_rtp_sink zrtp.send_rtp_src ! \
        udpsink clients="127.0.0.1:5002" sync=false async=false \
    testsrc.rtcp_src ! zrtp.send_rtcp_sink zrtp.send_rtcp_src ! \
        udpsink clients="127.0.0.1:5003" sync=false async=false

The first two pipes listen on 5004/5005 and my external ZRTP reference client
sends on these two ports its RTP/RTCP data. The next two pipes connect to
a zrtptester plugin (a quick hacked plugin that produces well defined data) and
sends it to my external ZRTP reference client which listens on ports
5002/5003. The ZRTP protocol handshake uses the two RTP ports (5002 and 5004).

All tests so far work, the ZRTP handshake works, the SRTP/SRTCP setup works
and the data is encrypted and decrypted appropriately.

The design would also support a SRTP/SRTCP standalone filter. In that case the
application needs to set the SRTP keys, for example if it implements some sort
of password/external key negotiation. That would be just a matter how to setup
and control the zrtpfilter (plugin properties mainly).

Regards,
Werner
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: ZRTP plugin for GStreamer

Mathias Gyllengahm

Great news!
Den 15 feb 2012 09:01 skrev "Werner Dittmann" <[hidden email]>:
>
> All,
>
> after some hacking I have a first working version of the proposed ZRTP/SRTP
> plugin for GStreamer.
>
> I'm not familiar with GStreamer and its preferred ways to do things, thus I
> need some advise here :-) , for example how to implement asynchronous communication
> with the application to inform it about security status, etc.
>
> For asynchronuos communication: use signal or messages, or a combination of both?
> The data that zrtpfilter sends to the application is small, 2 integers usually
> or a string or two. No complex structures.
>
> I also like to ask for advise which technique to use to handover properties. Most
> properties are simple, just integers, booleans - that does not pose a problem. In
> one case, however, I would like to have a set of parameters at once, a combination
> of integers, boolean, string. This could be done step-by-step, but in this case
> a structure would be more covenient. Is this possible? Any pointers/links to an
> example if it is possible?
>
> I'll do some cleanup of the code and then create a git repository on github.
> This will happen later today and I keep you informed.
> NOTE: this is a very first pre-alpha version :-) not ready for real stuff, only
> for testing the principal implementation etc.
>
> The current layout of zrtpfilter:
>
>
>           +-------------------------------------+
>           |              zrtpfilter             |
>           +---------------+      +--------------+
>           |recv_rtp_sink  |      |recv_rtp_src  |
>  from     |               |      |              |  to RTP
>  network  +---------------+      +--------------+  plugin,
>  plugin,  |                                     |  e.g.
>  e.g.     +---------------+      +--------------+  rtpbin
>  udpsrc   |recv_rtcp_sink |      |recv_rtcp_src |
>           |               |      |              |
>           +---------------+      +--------------+
>           |                                     |
>           +---------------+      +--------------+
>           |send_rtp_sink  |      |send_rtp_src  |
>           |               |      |              |  to
>  from RTP +---------------+      +--------------+  network
>  plugin,  |                                     |  plugin,
>  e.g.     +---------------+      +--------------+  e.g.
>  rtpbin   |send_rtcp_sink |      |send_rtcp_src |  udpsink
>           |               |      |              |
>           +---------------+      +--------------+
>           |                                     |
>           +-------------------------------------+
>
> The plugin is a full-duplex plugin that handles up- and downstream traffic for
> RTP and RTCP. If connected with another ZRTP enabled client it automatically
> negotiates the SRTP keys and enables SRTP and SRTCP. This is fully transparent
> to the connected up- or downstream plugins. During my tests I use this setup:
>
> gst-launch --gst-plugin-path=$HOME/devhome/gstZrtp/build/src -m \
>    zrtpfilter name=zrtp \
>    udpsrc port=5004 ! zrtp.recv_rtp_sink zrtp.recv_rtp_src ! \
>        fakesink dump=true sync=false async=false \
>    udpsrc port=5005 ! zrtp.recv_rtcp_sink zrtp.recv_rtcp_src ! \
>        fakesink dump=true sync=false async=false \
>    zrtptester name=testsrc \
>    testsrc.src ! zrtp.send_rtp_sink zrtp.send_rtp_src ! \
>        udpsink clients="127.0.0.1:5002" sync=false async=false \
>    testsrc.rtcp_src ! zrtp.send_rtcp_sink zrtp.send_rtcp_src ! \
>        udpsink clients="127.0.0.1:5003" sync=false async=false
>
> The first two pipes listen on 5004/5005 and my external ZRTP reference client
> sends on these two ports its RTP/RTCP data. The next two pipes connect to
> a zrtptester plugin (a quick hacked plugin that produces well defined data) and
> sends it to my external ZRTP reference client which listens on ports
> 5002/5003. The ZRTP protocol handshake uses the two RTP ports (5002 and 5004).
>
> All tests so far work, the ZRTP handshake works, the SRTP/SRTCP setup works
> and the data is encrypted and decrypted appropriately.
>
> The design would also support a SRTP/SRTCP standalone filter. In that case the
> application needs to set the SRTP keys, for example if it implements some sort
> of password/external key negotiation. That would be just a matter how to setup
> and control the zrtpfilter (plugin properties mainly).
>
> Regards,
> Werner
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: ZRTP plugin for GStreamer

Werner Dittmann
In reply to this post by Werner Dittmann
All,

as promised in my earlier mail today here the link to the github repository:

http://github.com/wernerd/gstzrtp

Please keep in mind that this is a very early version and need a lot of tuning
and enhancements before really usable in GStreamer.

Best regards
Werner


Am 15.02.2012 08:59, schrieb Werner Dittmann:
> All,
>
> after some hacking I have a first working version of the proposed ZRTP/SRTP
> plugin for GStreamer.
>
<SNIP --- SNAP>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel