Il 20/10/2010 03:40, Ross Finlayson ha scritto:
(As there's no RFC on RTSP over HTTP, as far as I know, I use this
document as a reference:
http://developer.apple.com/quicktime/icefloe/dispatch028.html
FYI, another document - with a little more detail - is here:
http://images.apple.com/br/quicktime/pdf/QTSS_Modules.pdf (starting on
page 107)
Thank you.
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?
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.)
Yes, the session cookie is included correctly, luckily (the contrary
would have defied the whole RTSP-on-HTTP purpose, I guess).
2) Milestone sends us a base64 encoded POST that contains this SETUP:
SETUP rtsp://192.168.1.83:8554/video/track1 RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=12154-12155
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).
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?
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.
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.
Thank you.
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.
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.
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).
Thank you again,
best regards,
Cristiano Belloni.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
--
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
bell...@imavis.com <mailto://bell...@imavis.com>
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
