srtpdec pushes encrypted buffers out when crypto is not set yet
I noticed a problematic behavior with sipe-pidgin, its farstream backend, and the way the srtp audio stream is passed from libnice to the siren decoder.
When the element starts to receive encrypted buffers, and the keys are not setup yet, the buffers are pushed out undecoded in gst_srtp_dec_chain()
. the problem here is that the size of the rtp buffer is not the same when data are decoded (52 bytes) and undecoded (62 bytes), and the siren decoder in my case expects fixed-size (40 bytes + 12 bytes rtp header) buffers.
The first problem is that the siren decoder is not hardened enough to handle a random content (overflow in the huffman tables) but this can be worked around.
The second problem is more annoying, because the siren decoder has no mechanism to detect and resync on the beginning of "valid" data, when the crypto is finally installed and the buffers pushed out now have their correct size. The visible consequence is that siren decoder fails, and takes down the pipeline partially:
(23:05:10) mediamanager: gst pipeline error: Internal data stream error.
(23:05:10) mediamanager: Debug details: ../libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstBin:conf_0x6160000cf9d0/FsRtpConference:fsrtpconference1/GstBin:bin8/GstNiceSrc:nicesrc4:
streaming stopped, reason error (-5)
(23:05:10) backend-fs2: gst error Internal data stream error.
debugging: ../libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop (): /GstPipeline:pipeline0/GstBin:conf_0x6160000cf9d0/FsRtpConference:fsrtpconference1/GstBin:bin8/GstNiceSrc:nicesrc4:
streaming stopped, reason error (-5)
This is not systematic, since introducing several times a 10 bytes offsets in the 40-bytes chucked stream will resync successfully 1 time out of 4 on average :)
Would it make sense to just goto drop_buffer
instead of push_out when crypto is not setup yet?