high level questions about using srtpenc/srtpdec

[Andres Gonzalez]

Hi,

First of all, I want to thank you guys for all of your help and for answering my many (stupid?) questions here. Your answers/comments have really helped me better understand GStreamer and has enabled me to get some cool streaming features working in my app.

I currently have a functional traditional RTP/RTCP stream working well. The pipeline is built using 2 bins, one for all the video elements feed by an appsrc, and one for all of the audio elements also feed by an appsrc, with both bins linked to an single rtpbin, then linked to 2 udpsink elements (outgoing RTP and RTCP) and 1 udpsrc element (incoming RTCP).

I am now trying to add to this basic RTP/RTCP pipeline support for SRTP. I have finished all of the crypto and key part using openssl so I have the negotiated key. But I am still confused about the architecture of the SRTP-enabled RTP pipeline.  

rtpbin has callbacks for encoders/decoder for RTP and RTCP:  e.g.: request-rtp-encoder. These callbacks return a pointer to a GstElement.

Question: I am assuming the return pointer is the pointer to the srtpenc.  Is this correct?  The reason I ask what must be a newbie question, is that when I create the srtpenc element using  gst_element_factory_make() and then return that reference in the rtpbin request-rtp-encoder callback, I get a segfault deep within GStreamer code. So I am not sure if I am using the API correctly (I cannot find any example code for srtpenc/srtpdec and the current documentation does not expand on its usage nor how to interface them to the regular rtpbin).

I have looked at the dtlssrtpenc source but it appears to use srtpenc different from how I thought these should be used. In the dtlssrtpenc source, it appears they use a funnel element and link both the data feed (which would be the clear text RTP data in my case??) and the srtpenc element to the input of the funnel. However, my current understanding is that the  srtpenc/srtpdec elements are not linked as usual in the pipeline, but instead these elements are "connected" to the regular rtpbin using the rtpbin request-xxx callbacks.  So this appears to conflict with how I have interpreted some of the comments here about srtpenc/srtpdec usage.

Thanks,
-Andres

[Andres Gonzalez]

Hi,
Just wanted to add a related question to this original question.

Question: What is the intended processing that should be done in the 4 callbacks (request-rtp-encoder, request-rtcp-encoder, request-rtp-decoder, and request-rtcp-decoder) in rtpbin for using srtpenc and srtpdec?  

Reviewing the source for srtpenc/srtpdec seems to imply that the linking is done internal to rtpbin, and that these callbacks are not used to link pads as can usually be done when linking "Sometimes" pads. This seems to imply that the ONLY purpose for these callbacks is to return the reference to the srtpenc/srtpdec elements and NOT link pads for rtpbin.

Thanks,
-Andres