HTTP based Stream Control

The HTTP based stream control makes use of the HTTP searchpart mechanism (see section 2.4.1.1). It enables HTTP requests to be extended by a list of parameters. The mechanism allows the encoding of control commands, here called methods, and their corresponding parameters within standard HTTP-URLs.

The syntax of the HTTP-URL format used within WebAudio can be described as follows: http://<host>[:<port>]/<resource>[?<method>{&<parameter>]}

The individual variables have the following meaning:

<host> specifies the Internet domain name (or IP address) of the WebAudio application. <port> determines the port number of the application listening for incoming requests. This port is usually well-known or must be carried towards the client or user interface by some other means.

<resource> references a specific resource, usually a specific audio stream, to which the <method> should be applied. It may consist of a path and/or a file name (for example, /liveaudio/gsm).

<method> specifies the method which is applied to the <resource>. Three methods are currently supported: GET, PLAY and STOP.

<parameters> or the list of parameters determine method specific arguments of the control request. The supported parameters depend on the individual methods.

A brief description of the supported methods and their parameters is provided below: GET: The WebAudio server simply replies the content of the specified <resource> as

HTML page. If no method is specified in the HTTP request, GET is used as the default method. This allows WebAudio to be used as a Web server. If the <resource> string is empty, a default Web page which starts up the standard user interface and the WebAudio client application at the receiver is sent. The GET method does not support parameters.

PLAY: Additional parameters of the PLAY method determine either the WebAudio server (parameter: SERVER) to which the client should forward the control request or the RTP receiver port (parameter: PORT) where the client expects to receive the audio stream.

The following examples are presented for clarification: The first example presents a user interface requests from the WebAudio client (usually on the same machine, but it can be any Internet host) to set up and start streaming the audio resource liveaudio/pcm from the WebAudio server webaudio listening at port 4445:

http://localhost:4444/liveaudio/pcm?PLAY&SERVER=webaudio:4445 Upon receipt of this stream control request, the client transforms the control request in an RTSP SETUP and PLAY control request forwards them to the server webaudio. The second example shows a HTTP PLAY control request directly send to the We- bAudio server webaudio.lancs.ac.uk:

http://webaudio.lancs.ac.uk:4445/liveaudio/pcm?PLAY&PORT=8312 The server will then setup a new stream and start streaming the audio data to the source IP address of the HTTP request and the transport port 8312 of the HTTP URL.

STOP: This method causes the WebAudio client and server to teardown the specified stream and to release all the resources associated with that stream. STOP does not support any additional parameters.

In the case of unsuccessful request processing, WebAudio returns an error message with an error response code indicating the reason. Table 4.1lists the HTTP response codes used within WebAudio along with their meaning in this context. The general meaning of the response code classes of HTTP is presented in Table 2.7.

Code Description

200 HTTP control request was successfully processed

403 No permission to access the audio resource identified in

HTTP-URL

404 HTTP-URL or audio resource is not valid or not available

500 WebAudio application error

501 WebAudio command unknown

505 HTTP protocol or version not supported

Table 4.1: HTTP Response Codes used within WebAudio

From this description on how HTTP based stream control is achieved within WebAudio, one might conclude that the simple HTTP based approach is sufficient for the purpose of stream control. However, HTTP based stream control has two serious flaws.

First, standard HTTP does not provide a way for the WebAudio server to respond with an appropriate error message or error code in the case of a server error. WebAudio specific errors or errors related to stream control cannot be expressed by the default HTTP error codes and messages. This problem could be solved by extending the HTTP protocol. However, modifying the stream control protocol so that it is no longer compliant with HTTP removes the main advantage of HTTP based streaming control, and thus, standard Web browsers could not be used as simple user interfaces anymore.

4.1. APPLICATION ARCHITECTURE 115 Second, HTTP has no provision to exchange server generated session or stream identi- fiers to uniquely address individual media sessions or streams. The stateless information retrieval protocol HTTP does not provide semantics for media sessions or streams, and hence, the HTTP standard does not define a protocol header field to express such iden- tifiers. As a solution the WebAudio server could transmit the session id as part of the HTTP payload. This solution, however, requires special HTTP clients that interpret the payload correspondingly. As a result, the solution was not considered. Another approach to address individual streams within HTTP stream control requests is to use the request source IP address in conjunction with the media resource specified in the HTTP-URL. It is to be noted that the source port information is not useful if stream control is carried out by means of Web browsers, because subsequent control requests of the same session might have different source ports. This technique limits the service to address one stream per destination address and resource within WebAudio. This of course is not a strong restriction, since common end systems usually have only one sound device. Receiving the same audio stream multiple times would not be of interest. To resolve this limitation, a simple solution could be to add the RTP port of of the WebAudio client as PORT parameter to the control request. It could then be used in concatenation with the source IP address to uniquely identify the client application.