GNOME Bugzilla – Bug 794813
RECORD: improve SRTP handling
Last modified: 2018-03-30 15:58:36 UTC
When using secure profiles with rtspclientsink, only the media stream sent by the client, and its associated RTCP, were correctly decrypted. The RTCP backchannel from the server to the client was not, and neither was the retransmission stream. These patches address that.
Created attachment 370298 [details] [review] rtsp-stream: extract handle_keymgmt from rtsp-client rtspclientsink will also need to parse KeyMgmt headers sent by the server to decrypt the RTCP backchannel stream
Created attachment 370299 [details] [review] rtsp-client: Send KeyMgmt header in ANNOUNCE response When sending back an encrypted RTCP back channel, it is useful for the client to know the encryption key.
Created attachment 370300 [details] [review] rtspclientsink: Handle the KeyMgmt header in ANNOUNCE response This in order to be able to decrypt the RTCP backchannel
Created attachment 370301 [details] [review] rtspclientsink: add rtx ssrc to mikey's crypto sessions
Comment on attachment 370301 [details] [review] rtspclientsink: add rtx ssrc to mikey's crypto sessions Is this done all correctly for PLAY sessions already and was only broken for RECORD?
Created attachment 370347 [details] [review] rtsp-client: Send KeyMgmt header in ANNOUNCE response When sending back an encrypted RTCP back channel, it is useful for the client to know the encryption key.
PLAY is probably also affected by this, should be fixed as part of this bug or at least get a new bug opened :)
Attachment 370298 [details] pushed as a093f44 - rtsp-stream: extract handle_keymgmt from rtsp-client Attachment 370300 [details] pushed as c683cad - rtspclientsink: Handle the KeyMgmt header in ANNOUNCE response Attachment 370301 [details] pushed as 7894328 - rtspclientsink: add rtx ssrc to mikey's crypto sessions Attachment 370347 [details] pushed as ae0e08d - rtsp-client: Send KeyMgmt header in ANNOUNCE response