GNOME Bugzilla – Bug 701129
ipv6 support in rtsp-stream
Last modified: 2014-02-25 22:28:46 UTC
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?
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.
Created attachment 245612 [details] [review] 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.
commit 3e119be8291556b91c8150837004ed4f2c6848af Author: Alexander Schrab <alexas@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
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?
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 " )");
The original issue is fixed, new bug in #702002