(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>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)


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.)


2) Milestone sends us a base64 encoded POST that contains this SETUP:

SETUP <rtsp://192.168.1.83:8554/video/track1>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. 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.
--

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

Reply via email to