[Bug 701129] New: ipv6 support in rtsp-stream

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

Summary: ipv6 support in rtsp-stream
Classification: Platform
Product: GStreamer
Version: 1.x
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-rtsp-server
AssignedTo: gstreamer-***@lists.freedesktop.org
ReportedBy: ***@axis.com
QAContact: gstreamer-***@lists.freedesktop.org
GNOME version: ---


When binding to an ipv6 socket we create rtsp-streams that have multiudp-sinks
that are not compatible with ipv6. There is a private flag in rtsp-stream:
is_ipv6. This flag works, if I set it to true the system is capable of serving
over ipv6. But noone sets this flag and it is non-trivial to do it correctly.
The reason is that when creating the stream it's hard to get the information
(since media and thus stream is created in the construct media factory call
which we have little control over, and we do not necassarily have the clients
yet (thus being able to look at the client address to figure it out).

My ideas are ranging from something simple just trying to communicate the
is_ipv6 through the construct call to refactorying the media and extracting the
stream construction to a seperate factory system enabling this case and other
future cases.

What do upstream guys think?

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

--- Comment #1 from Alexander Schrab <***@axis.com> 2013-05-29 05:35:56 UTC ---
I talked to wim on irc yesterday and one idea we had was configuring the media
with is_ipv6 after construct. Problem is that this is too late, because
default_construct in media-factory will do collect_streams on the media which
in turn creates the multiudpsinks.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

--- Comment #2 from Alexander Schrab <***@axis.com> 2013-05-30 06:12:46 UTC ---
Created an attachment (id=245612)
View: https://bugzilla.gnome.org/attachment.cgi?id=245612
Review: https://bugzilla.gnome.org/review?bug=701129&attachment=245612

Patch

Approach taken: rtsp-stream now handles both ipv6 and ipv4, even if ipv6 is not
dual stack. I have tested this on linux binding to 0.0.0.0 and ::0 with and
without dual stack with expected result (0.0.0.0 is always only ipv4, ::0 is
both in dual stack and ipv6 only in single stack).

I had to add another udpsrc for the v6. And there is also two sets of server
ports due to this (we cannot guarantee v6 and v4 binds to the same ports). The
family of the client is deduced from the client transport destination string,
this is the same way multiudpsink does it.

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

Sebastian Dröge <slomo> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@circular-chaos.org

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

Wim Taymans <wim.taymans> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |***@gmail.com
Resolution| |FIXED
Target Milestone|HEAD |1.1.1

--- Comment #3 from Wim Taymans <***@gmail.com> 2013-06-03 09:33:00 UTC ---
commit 3e119be8291556b91c8150837004ed4f2c6848af
Author: Alexander Schrab <***@axis.com>
Date: Thu May 30 08:07:48 2013 +0200

rtspstream: handle both ipv4 and ipv6 clients

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701129

["GStreamer" (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

--- Comment #4 from Alexander Schrab <***@axis.com> 2013-06-10 12:17:39 UTC ---
I found an additional problem:

this code doesn't handle the situation where we have an address pool without
only ipv4 or only ipv6 addresses. I guess we didn't support the latter before
either, but at least we need to support only ipv4? :)

Any idea on how to tackle this?

["GStreamer" (bugzilla.gnome.org)]

http://bugzilla.gnome.org/show_bug.cgi?id=701129
GStreamer | gst-rtsp-server | 1.x

Patricia Muscalu <patricia> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@axis.com

--- Comment #5 from Patricia Muscalu <***@axis.com> 2013-06-25 11:19:03 UTC ---
The unit test test_play_specific_server_port fails with this fix. The problem
has been already described by Alexander. An easy fix/workaround in the test is
the following patch:

diff --git a/tests/check/gst/rtspserver.c b/tests/check/gst/rtspserver.c
index 5edeffd..b6a9c8d 100644
--- a/tests/check/gst/rtspserver.c
+++ b/tests/check/gst/rtspserver.c
@@ -1255,6 +1255,8 @@ GST_START_TEST (test_play_specific_server_port)
pool = gst_rtsp_address_pool_new ();
gst_rtsp_address_pool_add_range_unicast (pool,
GST_RTSP_ADDRESS_POOL_ANY_IPV4,
GST_RTSP_ADDRESS_POOL_ANY_IPV4, 7770, 7780);
+ gst_rtsp_address_pool_add_range_unicast (pool,
GST_RTSP_ADDRESS_POOL_ANY_IPV6,
+ GST_RTSP_ADDRESS_POOL_ANY_IPV6, 7770, 7780);
gst_rtsp_media_factory_set_address_pool (factory, pool);
g_object_unref (pool);
gst_rtsp_media_factory_set_launch (factory, "( " VIDEO_PIPELINE " )");