[Live-devel] RTSP-over-HTTP and inconsistent SETUP requests.

Cristiano Belloni belloni at imavis.com
Wed Oct 20 01:05:53 PDT 2010


  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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101020/061472ba/attachment.html>


More information about the live-devel mailing list