On Fri, 2009-11-13 at 23:24 +0100, Daniel Stenberg wrote:
> RTSP is very similar to HTTP. We need to figure out exactly how similar, and
> quite likely we should add RTSP as a some kind of extension to HTTP so that
> they can share as much code as possible. Of course we should make
> RTSP-specific stuff in a separate file/functions and the same goes for the
> non-RTSP parts of HTTP.

Indeed, their similarity is the major driving reason why I think cURL is
a good target for this code.

Here's an overview of the key high level differences as I see them, most
of which you probably already know:

-Commands are different: Rather than the HTTP verbs, there are RTSP
verbs like PLAY, PAUSE, SETUP, TEARDOWN, etc.. The logic for all of this
would be RTSP specific.

-RTSP is 'stateful': This mainly affects server implementations. On the
client side, a session identifier must be maintained.

-Commands use a monotonically increasing sequence number CSeq

-Server can send commands: When a persistent connection is used, the
server can request that the client do something (REDIRECT/ANNOUNCE).
This is not applicable if the client does not support persistent
connections, however.

-Different Headers: Though RTSP shares some of the HTTP headers like
Accept-Encoding, it also has its own set of headers for various media
functions. We'll need a different set of header logic for RTSP.

-Different Status Codes: Likewise with headers, though RTSP shares some,
it has its own set of status codes.

-RTP can be interleaved: We'll need to either not support this or detect
and hand off the RTP packets to the application.

-Chunked coding is not permitted

>
> The best way to proceed with adding a new protocol, is to implement a test
> server for it so that you can write up test cases for the curl test suite that
> runs tests against the server and you can see that it behaves correctly.
> Again, possibly the existing HTTP test server can be expanded to also support
> RTSP.
> Code-wise, a protocol is written in a new source file with a struct
> Curl_handler instance (or several like if there's a SSL version etc) and you
> add protocol bit(s) in the CURLPROTO_* style in include/curl/curl.h, default
> ports (PROT_* defines) in lib/urldata.h and some version_info() magic into
> lib/version.c.
Thanks. I'll definitely be familiarizing myself with these pieces
shortly.

>
> For more, just ask!

Will do. I won't be working much (if at all) on this over the weekend,
but I should have more questions/comments early next week.

--Chris
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-11-14