As well known, VideoLAN (VLC) can operate as an encoder for a Apple Darwin Streaming Server (DSS) by creating an SDP file, copying it to /usr/local/movies, and starting to send media flows with the same options used for the SDP creation. DSS will happily reflect the flows to every requesting client.
Troubles arose when we tried to use VLC as an Origin in the framework of the OpenCDN project. In that case, DSS is configured as a Relay and, according to a "pull" paradigm, it acts as an RTSP client with respect to VLC, making the remote stream also available to its own clients. In that way, the SDP metadata is transferred to DSS during the RTSP negotiation phase, and no manual copy of the SDP file is needed...
... the only problem, is that DSS seems to be unable to complete an RTSP request toward a VLC which is configured as an RTSP server !!!
By sniffing the traffic which occur during the RTSP session between 2 DSS (one used as Source, and the other configured as Relay), and then by sniffing of another RTSP session between VLC (used as Source) and DSS (configured as Relay), a difference has been found in the "a=control:" attribute of the sdp.
DSS expects the attribute to have the following format:
VLC generates the same attribute using an absolute URL:
By using VLC as a source and the DSS as a pull relay, the latter don't parse the "a=control:" field correctly, and interpreters the first integer that it encounters (192) as the trackID.
Section C.1.1 of RFC 2326 (Real Time Streaming Protocol), says: "This attribute (the a=control:) may contain either relative and absolute URLs, following the rules and conventions set out in RFC 1808". So, the need to dig into the code, to make DSS able to parse "a=control:" attribute containing absolute URLs also.
By starting from the stable release (5.5.4) of the Apple Darwin Streaming Server, the APICommonCode/SDPSourceInfo.cpp file has been modified as described in the diff below. After recompilation, the same tests described above have been repeated, showing that now both the RTSP sessions (DSS to DSS and VLC to DSS) work correctly.
The second problem depends on the first one, and concerns how DSS rewrites the SDP fields. As commented above, DSS simply don't think as possible the presence of an absolute URI in the SDP's control line. So, when a client makes an RTSP request to the server side of the DSS relay, the SDP received from the client side of the relay is served again, with the "a:control" line unchanged. The result is that the requesting side become confused, about how to get a content which is controlled by the relay source.Again, after digging into the code, we have found how to patch it, in order to cancel the address part of the SDP's control line, and the result is also given in the following diff.
The tests have been carried out on a Fedora Core 5 linux. Building from sources failed due to the default version of C/C++ compiler used by this distro (gcc-4.1.0). After the installation of the packages:
and their dependencies, the Buildit script has been changed as follows, indicating the correct C/C++ compiler to use:
@@ -56,3 +56,3 @@
This way, everything works fine and the sources can be compiled.
--- SDPSourceInfo.cpp.start 2005-07-31 11:00:30.000000000 +0200
+++ SDPSourceInfo.cpp 2007-01-12 19:01:58.000000000 +0100
@@ -137,3 +136,0 @@
@@ -145 +142,13 @@
- hasControlLine = true;
+ aParser.ConsumeUntil(NULL, '=');
+ aParser.ConsumeUntil(NULL, StringParser::sDigitMask);
+ localSDPFormatter.Put("a=control:trackID=", 18);
+ localSDPFormatter.Put(aParser.GetCurrentPosition(), aParser.GetDataRemaining());
+ hasControlLine = true;
@@ -342,0 +352 @@
+ aParser.ConsumeUntil(NULL, '=');