<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Il 20/10/2010 03:40, Ross Finlayson ha scritto:
<blockquote cite="mid:f06240800c8e3f405ce1b@%5B66.80.62.44%5D"
type="cite">
<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>
<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
moz-do-not-send="true"
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:
<a class="moz-txt-link-freetext" href="http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf">http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf</a>
(starting on
page 107)</div>
<div><br>
<br>
</div>
</blockquote>
<br>
Thank you.<br>
<br>
<blockquote cite="mid:f06240800c8e3f405ce1b@%5B66.80.62.44%5D"
type="cite">
<div>
</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>
</blockquote>
<br>
Yes, the session cookie is included correctly, luckily (the contrary
would have defied the whole RTSP-on-HTTP purpose, I guess).<br>
<br>
<blockquote cite="mid:f06240800c8e3f405ce1b@%5B66.80.62.44%5D"
type="cite">
<div><br>
</div>
<blockquote type="cite" cite="">2) Milestone sends us a base64
encoded
POST that contains this SETUP:<br>
<br>
SETUP <a moz-do-not-send="true"
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.</div>
</blockquote>
<br>
Thank you.<br>
<br>
<blockquote cite="mid:f06240800c8e3f405ce1b@%5B66.80.62.44%5D"
type="cite">
<div> 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>
</blockquote>
<br>
I'm getting very tired of this, too, and I can assure you I share
your feelings. I'm sincerely astonished that big manufacturers as
Milestone just can't stick to these simple standards.<br>
I've already contacted Milestone developers and informed them on
these bugs (and on other ones, such as making the first GET in HTTP
1.1, while all GETs *must* be done in HTTP 1.0. Luckily liveMedia
seems to works fine with this).<br>
<br>
Thank you again,<br>
best regards,<br>
<br>
Cristiano Belloni.<br>
<br>
<blockquote cite="mid:f06240800c8e3f405ce1b@%5B66.80.62.44%5D"
type="cite">
<x-sigsep>
<pre>--
</pre>
</x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a class="moz-txt-link-freetext" href="http://www.live555.com/">http://www.live555.com/</a></div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Belloni Cristiano<br>
Imavis Srl.<br>
<a href="http://www.imavis.com">www.imavis.com</a><br>
<a href="mailto://belloni@imavis.com">belloni@imavis.com</a><br>
</div>
</body>
</html>