Chapter 2: Protocol

A protocol is the “layer 5″ network/transport technology that governs communication between client and server. For radio, the most common protocols are HTTP, ICY, MMS, and RTSP. There is also the small but growing RTMP protocol for streaming Adobe Flash audio and video (FLV files). There are two basic ways to send audio data from a server to a client. One is to stream it; that is, the server sends the audio in real-time to the client, and the client merely plays whatever it gets. If the protocol uses UDP, then any audio that doesn’t make it to the client simply gets dropped. If using TCP, then any lost packets are sent again. The client controls the playback by sending commands to the server to adjust the stream that it is sending (for example, to move to the next track, or pause output). ICY, MMS, and RTSP are all streaming protocols.

The other way to send the audio is called progressive download. This is generally what is used with HTTP connections. With progressive download, an audio file on the server is simply downloaded by the client, as fast as possible. The client will buffer a certain amount of the audio before starting playback to protect against connection troubles or slow connections. Fast-forwarding and other commands sent by the client generally results in the client having to refill its buffer before playback can continue. Progressive download is generally easier to implement on the client and the server because the technology to download a file is simple and well-established. Streaming audio requires a streaming server and a client that can interact with it.

One difficulty with protocols is that sometimes playlists specify the incorrect one. For example, sometimes URLs listed as http:// or rtsp:// are actually MMS streams. Additionally, when you are using open-source programs such as mplayer to stream the audio, sometimes a URL listed as mms:// is actually an rtspt (RTSP over TCP) stream, which mplayer does not support. In those cases you may have to use a different program (gst-launch in this case). Commercial software such as Windows Media Player should handle these cases correctly.

HTTP

HTTP is most often used to serve raw audio data. That is, MP3, AAC, or WMA, none of which have a container (see Chapter 3). HTTP is the simplest to deal with, as it is the protocol that the internet runs on, and is therefore well-established. There are a couple things to remember when dealing with the HTTP protocol, however. First is redirects, using HTTP code 301, 302, or 303. Radio streams will often have multiple levels of redirects before you hit the actual stream. To determine the destination of the redirect, simply read the Location header in the response. The other thing to keep in mind is that you can not always trust the content-type and content-length listed in the HTTP response headers, so don’t rely on them. The only definite way of determining the type of file you have received is by inspecting its contents.

ICY

ICY is the protocol used by SHOUTCast and Icecast servers. It is actually an extension of HTTP. You can tell you are dealing with an ICY stream because the status line of the header of the response will contain ICY 200 OK. Because ICY is an extension of HTTP, it is easy to interact with. ICY streams will generally return metadata about the stream in the response headers (for example, icy-genre and ice-bitrate). If you pass icy-metadata: 1 in the request headers, then a chunk of metadata about the currently playing audio (track-name and length, for instance) is embedded in the audio stream every second or so. See this URL on how to extract the metadata: http://www.smackfu.com/stuff/programming/shoutcast.html.

MMS

MMS stands for Microsoft Media Server and is a proprietary streaming protocol created by Microsoft that has been obsolete since 2003. MMS defaults to port 1755 and can run on either TCP or UDP. Although obsolete, some stations are still using MMS. Note that mms:// is also used as a “protocol rollover”. That is, it is also used for RTSP, described below. When encountering a URL that starts with mms://, a client, such as Wndows Media Player, will first try RTSP over UDP, then RTSP over TCP, then MMS over TCP, and then MMS over UDP. If all previous attempts have failed in the protocol rollover, then the client will try MS-WMSP (Windows Media HTTP Streaming Protocol), which is often referred to as MMSH.

MS-WMSP is RTSP or MMS tunneled over HTTP. You can find the specification in Appendix A. It uses standard HTTP 1.0 (with some optional HTTP 1.1 features), but includes new HTTP headers and types of requests.

RTSP

Microsoft has replaced MMS with RTSP, which stands for Real-Time Streaming Protocol. RTSP specifies only how streams are set up and controlled between a client and server. The actual data is sent using a transport protocol, generally RTP (Real-Time Transport Protocol). RTSP defaults to port 554 and can also be sent over TCP or UDP. RTSP allows a client to send commands such as DESCRIBE, SETUP, PLAY, PAUSE, RECORD, and TEARDOWN, in order to control the stream that it is receiving. RTSP responses contain metadata about the stream that can be parsed.

RTMP

This protocol was developed by Adobe for streaming audio and video from a server to a Flash player. Although it is relatively rare for internet radio, Flash streams are increasing in popularity. It streams on port 1935, though there is the RTMPT variation that tunnels the stream over port 80 (HTTP), and RTMPS that tunnels it over 443 (HTTPS). There are a couple options for playing RTMP streams. The easiest is to just use Flash player. However, if you are unable to, you could try to use one of the open-source implementations, such as mplayer or vlc.