ZRTP plugin for GStreamer
Werner Dittmann
Werner.Dittmann at t-online.de
Tue Feb 14 23:59:26 PST 2012
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
More information about the gstreamer-devel
mailing list