The Use Cases and Requirements document states that: "The main protocol we are concerned with are HTTP and RTSP".
- Which protocols should we consider primarily?
- What are the rationale for excluding some protocols?
- The charter says to cover at least the HTTP protocol: Making a best practices recommendation beyond that at this stage may make it too complicated and impossible to get agreement and adoption.
- Dave Singer raises the question of whether the work will be HTTP-specific, or whether other delivery protocols will be considered (e.g. RTSP/RTP, shoutcast, ultravox, and so on).
- Silvia argues that the mms protocol is deprecated since 2003 and no longer supported by Microsoft (Raphael: reference to enforce this claim?). Furthermore, p2p protocols are generally proprietary and the notion of fragments make less sense.
- Raphael shows that the videolectures.net portal use both rtmp and mms protocols, for example:
- Davy nicely demonstrated that we should not blindly trust the protocol written in the URI. Hence the 'mms' URI above turns out to be served over RTSPT (i.e., RTSP using TCP). Consequently, the following URI works as well in the videolectures.net portal:
It is hard to have accurate evaluations of how much each protocols is practically used. We provide below some references:
- The Sandvine Global Internet Traffic Trends Report, October 2008, states that Web (43%) and Web Media (16%) dominate the downstream network with 60% of downstream bandwidth consumption. This traffic is actually composed of many different types, from typical web browsing, to social sites where large amounts of content (typically digital photos) are fetched, to buffered real-time video (YouTube, for example), to real-time streaming (RTSP).
- Olivier Aubert states that IPTV offered by ADSL Internet Providers widely uses the RTSP/RTP protocol.
The media type is the MIME type of the resource that is returned. In RTSP we don't actually have real "video" resources. We only have codec streams. So, the meaning of "fragment" in RTSP is not the same as that for ftp or http for example. However, RTSP already has mechanisms from doing fragment addressing since it was a main part of the standardisation of RTSP.
Essentially: the play request has a range parameter as part of the protocol parameters of RTSP (see http://www.ietf.org/rfc/rfc2326.txt and search for range). It is the equivalent of what Dave and Silvia have been discussing: the use of byte ranges to deliver the data.
However, in HTTP we need to have a mechanism to communicate the temporal segment (or more generally: the media fragment) between a user, a user agent, and a server, such that the server can help convert the fragment to a byte range, which in turn the UA can then request from the server and can be proxied by intermediates.