<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] RTSP-over-HTTP and inconsistent
SETUP req</title></head><body>
<blockquote type="cite" cite>(As there's no RFC on RTSP over HTTP, as
far as I know, I use this document as a reference: <a
href="http://developer.apple.com/quicktime/icefloe/dispatch028.html"
>http://developer.apple.com/quicktime/icefloe/dispatch028.html</a></blockquote
>
<div><br></div>
<div>FYI, another document - with a little more detail - is here:
http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf (starting on
page 107)</div>
<div><br>
<br>
</div>
<blockquote type="cite" cite>1) Milestone doesn't send us
"Accept:" or "Content-Type:" string of
"application/x-rtsp-tunnelled" in the HTTP GET. I
deactivated the check in the RTSPServer.cpp code and everything works.
Will you incorporate this in the future code?</blockquote>
<div><br></div>
<div>Note that the document that I referred to above explicitly states
that the "application/x-rtsp-tunnelled" header must be
present. However - in the spirit of "Be liberal in what you
accept" - I will deactivate this check in the next release of the
code. (Note, though, that the "x-sessioncookie:"
header absolutely has to be present in the request, both to
distinguish RTSP-tunneling requests from regular HTTP "GET"
commands (which should be rejected because we're not a real HTTP
server), and to enable us to tie together the "GET" and
"POST" requests. I presume, though, that the
'Milestone' client is including this header OK, otherwise the code
wouldn't be working.)</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite>2) Milestone sends us a base64 encoded
POST that contains this SETUP:<br>
<br>
SETUP <a
href="rtsp://192.168.1.83:8554/video/track1"
>rtsp://192.168.1.83:8554/video/track1</a> RTSP/1.0<br>
CSeq: 2<br>
Transport: RTP/AVP;unicast;client_port=12154-12155<br>
<br>
This makes RtspServer send its packets in UDP, while Milestone seems
to want them tunneled in the TCP connection (openRTSP gets it right,
sending a more reasonable Transport:
RTP/AVP/TCP;unicast;interleaved=0-1).<br>
<br>
My question is: does not the GET imply that the stream data must be
tunneled, regardless the (incorrect) Transport:RTP/AVT request from
the Milestone? What could be the point on requesting UDP/RTP data over
an RTSP/HTTP negotiation?</blockquote>
<div><br></div>
<div>I can imagine that this *might* be useful for tunneling across a
firewall that passes UDP packets, but blocks TCP connections to
anything other than port 80. I agree, though, that this is
unlikely to be what you want to do.</div>
<div><br></div>
<div>So, with some reluctance, I will modify the server code (in the
next release) so that - when HTTP tunneling is being done - it assumes
that it will stream over the TCP (HTTP) connection, regardless of what
the "SETUP" command says. I say "with some
reluctance", though, because I'm getting tired of the assumption
that - just because we're Open Source - we should inevitably modify
our code in order to be compatible with other people's broken,
non-standard software (or hardware). I'm willing to bet that the
installed base of our software is larger than that of 'Milestone'.
So, even though I'll modify our server code to work around these two
bugs, I'd like you to also please contact 'Milestone', informing them
of these bugs, and asking them to fix them in their software.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>