After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 720696 - gst-rtsp-server: allow client to accept different transports
gst-rtsp-server: allow client to accept different transports
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal enhancement
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-12-18 20:29 UTC by Aleix Conchillo Flaqué
Modified: 2014-02-25 22:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
client: allow different transports (7.90 KB, patch)
2013-12-18 20:32 UTC, Aleix Conchillo Flaqué
none Details | Review

Description Aleix Conchillo Flaqué 2013-12-18 20:29:31 UTC
Currently, in the SETUP request only the RTP/AVP transport is allowed. This is hardcoded in the parse_transport function in rtsp-client.c. It would be good if a user could allow different transports (e.g. RTP/SAVP).
Comment 1 Aleix Conchillo Flaqué 2013-12-18 20:32:32 UTC
Created attachment 264499 [details] [review]
client: allow different transports

This adds a new callback (GstRTSPClientAllowTransportFunc) that will the user to select which transports are accepted by the server. It defaults to RTP/AVP as before.
Comment 2 Sebastian Dröge (slomo) 2014-01-03 09:32:13 UTC
Or maybe there should be a deeper integration of RTP/SAVP inside gst-rtsp-server that takes care of inserting the srtp elements too?
Comment 3 Aleix Conchillo Flaqué 2014-01-03 17:06:09 UTC
(In reply to comment #2)
> Or maybe there should be a deeper integration of RTP/SAVP inside
> gst-rtsp-server that takes care of inserting the srtp elements too?

Right now, I do that (inserting srtp elements) by subclassing rtsp-media and implementing setup_rtpbin. There, I just connect to the new rtp-request-* signals. The current gst-rtsp-server API is pretty flexible.

But it's true that, probably, everyone that wants srtp support will have to do something similar, so it might be good to already add it to gst-rtsp-server.

In any case this allow transport callback is also flexible enough to let the user choose anything whether gst-rtsp-server integrates srtp or not. I think it might be useful for testing purposes or if you want to allow a certain transport only in specific cases (e.g. config file, only certain URLs, IPs).
Comment 4 Wim Taymans 2014-01-07 10:31:00 UTC
I want to add SAVP support into rtsp server at some point
Comment 5 Wim Taymans 2014-01-07 13:01:07 UTC
Added some commits to make it possible to configure the accepted transports in a stream.

commit ae1fe21436cf77da079beb4580f5027ec71e2238
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Tue Jan 7 12:21:09 2014 +0100

    stream: add property to configure profiles

commit 78c6648c967c9f758f8c8da7fc1e9bd7e59b703c
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Tue Jan 7 12:28:47 2014 +0100

    client: let stream check supported transport
    
    Delegate the check if a transport is allowed to the stream.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=720696

commit a1202effdaf180ec4bfb49683a1685e7451ab827
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Tue Jan 7 12:14:15 2014 +0100

    stream: add method to check supported transport
    
    Add a method to check if a transport is supported
Comment 6 Aleix Conchillo Flaqué 2014-01-07 19:35:53 UTC
This looks great. Thanks!