Customized Internet Radio

Venky Krishnan and S. Grace Chang
Hewlett-Packard Laboratories, 1501 Page Mill Road, Palo Alto, CA 94304, USA

Abstract

Today's Internet Radio breaks down geographic boundaries and lowers the barrier for audio broadcasting. The listener now has access to a huge growing number of radio stations. However, there are very few mechanisms in place that aid the listener in identifying audio broadcasts of his choice. Furthermore, unlike the traditional FM radio, radios on the network should exploit the Internet and provide features based on information about the content, the content providers and the listener. The Customized Internet Radio (CIR) proposes a framework for managing and customizing audio broadcast content on the Internet. The CIR, by managing the metadata of the broadcast content, provides the listener a dynamically selected and personalized radio program. This paper introduces the notion of a CIR Station, an Internet radio station with tools to create and manage program schedules for Internet audio broadcasts. The framework manages broadcast content originating from both local and remote sources. It allows specific radio stations or genre to be scheduled in time slots, and provides alerts and dynamic changes based on the availability of a specified content. CIR, by caching live content, also enables program time-shifting. The CIR uses the Session Announcement Protocol (SAP) to advertise the station information. These announcements contain information used by the client to receive the dynamically changing content. An implementation example of CIR illustrates the enhanced listener and content manager experience.

Keywords: Internet radio, SAP, SDP, media delivery, media management, customization, dynamic content


1. Introduction

With the advent of the explosive growth of the Internet, we see a plethora of media delivery platforms such as the Internet Radio. Broadcasting audio over the Internet is extremely popular. Today, there are approximately 2300 radio stations world-wide broadcasting live content and about 1500 stations broadcasting pre-recorded music. These numbers are growing at a rapid pace. There are several factors that contribute to this growth of Internet-based radio stations:

  1. Internet Radio eliminates the coverage restriction found with FM radio stations. A radio station on the network can be accessed from any computer with Internet access. This wide coverage capability of Internet Radio broadcast is very appealing to broadcasters. This has resulted in many FM radio broadcasters setting up a parallel Internet radio presence.
  2. It has become increasingly easy to set up a radio station server. Cheap hardware (networked PC and CD-ROM) and Internet access along with free/low-cost high-quality audio streaming software tools enable even a naive user to create an audio broadcast presence on the network.

Internet Radio Stations broadcast their content either using unicast or multicast. A station typically gives information describing the attributes (metadata) of (1) the station (e.g. genre, description), (2) the audio content (e.g. the program name and air time, song and artist name), and (3) the data (e.g. the bandwidth, the data encoding format). Client software (such as WinAmp, RealPlayer, and MediaPlayer) use this information to (a) select the appropriate audio decoder and (b) to provide the listener information on the content such as the station name and current playlist. There are several mechanisms by which a station advertises its metadata:

  1. Listeners select well-known IP addresses or Web sites to access the radio station. Typically, this information is obtained by advertisement, word of mouth, or from portal sites, search engines, and content provider sites (e.g. broadcast.com [1]).
  2. A radio station can register itself with a well-known Directory Server. Examples of this model include Nullsoft's Shoutcast system [2] (the server complement of the Nullsoft's Winamp MP3 player), and its open source replica called Icecast [3]. These systems provide a Directory Server that maintains a database keeping track of radio stations and their attributes, as well as a mechanism for a radio station to register itself.
  3. The radio station is hosted on a well-known address. Companies like live365.com [4] host radio stations on their site. They provide benefits such as reliability, high availability, robust servers, and fast connection.
  4. The station can announce its attributes using the Session Announcement Protocol (SAP) [5] on a well-known multicast address. The attributes include information on the broadcast such as the IP address of the data channel, the start and end time, the data encoding format, and the source of the broadcast.

The Internet Radio listener, while benefiting from the abundance of audio content, now has to sieve through many stations to find one that suit their preferences. Traditional AM/FM radio listeners rely on radio personalities like Disc Jockeys to filter the broadcast content for them. Traditional radio also has some powerful features like re-broadcasting content from a central content provider. For example, KQED, a local SF radio station, re-broadcasts the evening news from NPR in Washington. These are features of traditional radio that are lacking in today's Internet Radio.

Moreover, a network-based audio broadcast should exploit the features of the Internet. Some of key features that will enhance the listener experience are:

  1. Event-based content switching: Today, Internet Radio provides static listening. Once tuned to a station, the listener needs to actively change stations. There is no mechanism of changing stations automatically based on attributes such as the time, listener location, alert messages (e.g. for weather and traffic reports), genre, content provider, etc.
  2. Ease in accessing and reusing available content: There is plenty of content on the network. Tools to assist in accessing the content would provide immense added-value. For example, the HP Labs media Communications Department should be able to create an HP Labs Radio Station easily. The DJ of this station should be able to create the station's broadcast program based on content available on the network. The station itself does not need to create its own content. A listener of the HP Labs Radio Station thus will access content from different sources.
  3. Content-caching for playback: A radio station on the Internet should be able to cache content and playback this time-shifted content based on the listeners' needs.
  4. Content/Station/Listener awareness: Unlike a traditional radio, Internet radio should exploit information about the content, the station, and the listener preferences to provide customized content to the listener.

The Customized Internet Radio (CIR) attempts to address the above-mentioned shortcomings of today's Internet Radio. CIR is a framework for customizing and creating a "radio station" with event-based dynamic content access. It allows the station creator to manage the content based on the specified preferences (like genre, time of day, priority), and leverage the content available on the Internet from other providers as well as locally generated content. Once created, this radio station announces its presence and schedule so that its subscribers receive dynamic content as well. The various events that trigger a change in radio stations are (1) the expiration of a scheduled time-slot for a program, (2) an alert for the availability of a radio station or a webcast event, or (3) a location-specific event.


2. Basic Framework

In the Customized Internet Radio framework, there are three entities: the radio station servers (CIRServer), the radio client (CIRClient), and the "virtual" radio station (CIRVirtualStation), which is at the heart of the CIR framework. The CIRServer and the CIRClient are rather like the traditional server and client, with one serving the content and the other receiving the content. The CIRVirtualStation entity can be thought of as an intermediary Radio Station Program Manager, which gathers information (metadata) about the available radio stations and their content. It then compiles a schedule with programs from different sources and advertises this schedule to listening CIRClients or other CIRVirtualStations. Figure 1 shows the relation between these three entities. In the following, we describe the functions of each entity, and their relations with each other. More details about the architecture will be presented later in Section 3.


Figure 1: Relations between CIRServers, CIRClients, and CIRVirtualStations.

2.1 CIRServer

A CIRServer is the radio station server from which the audio content originates. In the CIR Framework, it represents the audio content provider. In today’s Internet Radio, the content providers streams out data using, for example, Real Network's RealServer [6], NullSoft's Shoutcast server [2], multicast conferencing tools (e.g. sdr [7]), or any other streaming audio servers. A server announces its presence typically in two mechanisms. It can register itself with a directory service such as yp.shoutcast.com or yp.icecast.org. It can also announce its attributes via multicast announcement protocols such as using SAP [5] and SDP [8], a mechanism provided by the tool sdr.

The CIRServer comes in two flavors: (1) a radio server that sends metadata information about its broadcast, and (2) a wrapper for existing servers. In both cases, the metadata sent includes time of radio broadcast, URL, genre, priority etc. The wrapper for an existing server gathers information about the server and its content, and transforms it to the CIR compatible format. For example, the Wrapper for the Shoutcast Server parses the list of radio stations on the Web page, http://yp.shoutcast.com, and creates announcements for each of the listed stations. The current incarnation of CIRServer does not announce fine grain metadata like details of songs (writer, singer, name, etc.) for a music radio station but these enhancements can be easily added.

2.2 CIRClient

A CIRClient is the audio player. The listener interacts with the CIRClient to select his choice of radio station (server). This can either be a CIRServer or CIRVirtualStation. Based on the metadata broadcasted by the selected server, the CIRClient tunes to the appropriate audio content stream from the content provider. The CIRClient has two parts: (1) a wrapper that interfaces with the CIR server components and (2) off-the-shelf audio players (e.g. RealNetwork's RealPlayer, NullSoft's Winamp MP3 player, FreeAmp [9]). In order to be a CIRClient in the Customized Internet Radio framework, there needs to be a wrapper which understands directives from the CIRServer and CIRVirtualStation. A CIRClient also contains several audio players for encoding different audio data formats, so that it can be format independent.

2.3 CIRVirtualStation

A CIRVirtualStation is an intermediary entity that acts as a Radio Station Program Manager, scheduling programs from different sources based on the preferences of the Disc Jockey (DJ). The DJ uses a user interface to set his preferences of the CIRVirtualStation. For example, the HP Labs DJ can specify that he wants to "broadcast" BBC from 9AM-5PM, and classical music from 5PM-9PM. He can also specify that if there are traffic or weather report channels available relevant to the listener’s current location, he wants the listener to be notified of these alerts. The CIRVirtualStation interacts with CIRServers to get their program schedules and sends out its own program announcements (metadata) based on the DJ’s settings. A CIRVirtualStation can also receive announcements from other CIRVirtualStations and can advertise its own local audio content.

A CIRClient listening to a CIRVirtualStation will get automatically tuned to the content provider identified by the metadata sent by the CIRVirtualStation. In the example above, if the listener "tunes" his CIRClient to the HP Labs CIRVirtualStation, then between 9AM-5PM, his Internet radio will be tuned to the BBC radio station. At 5PM, the CIRClient will switch to the classical station chosen by the HP Labs CIRVirtualStation. Throughout the day, he will receive alert broadcasts of the traffic and weather updates for his location.

In the descriptions thus far, the DJ and the listener are two distinct persons. Our model also supports the notion of the listener being his own DJ. In such a scenario, the CIRClient and the CIRVirtualStation components run on the same system. The listener can personalize his radio station to suit his needs. For example, Venky (an HP Labs employee) can configure his Personal Station (CIRVirtualStation) to tune to the audio broadcast as selected by the HP Labs radio station when he is in his office and switch to the top rock station listed on the Shoutcast directory when he is at home. Venky’s current location can be gotten either by manually indicating to the CIRClient or by integrating with a location-aware device like GPS.

To summarize, the CIRVirtualStation is at the core of the Customized Internet Radio framework. It enables a flexible and customized programming of the radio stations. To achieve this, the CIRVirtualStation needs to have mechanisms for the discovery of radio stations and their attributes (address, genre, bit rate, location, data format, etc), and information about their content (descriptions of the songs and programs). It also has mechanisms for a DJ to create a radio station program schedule based on time, genre, location, and alerts. Lastly, it needs to communicate its schedule, or playlist, to listening CIRClients, so that the listener gets dynamically selected radio stations. The audio content can come from either the original CIRServers or it can be collected by the CIRVirtualStation and then re-transmitted to the CIRClients. In the latter case, the CIRVirtualStation provides the additional functionality of content caching, to allow time-shifting of radio programs. For example, Venky wants to listen to the NPR 6 o'Clock news at 9PM when he is at home. In this case, Venky’s personal radio (CIRVirtualStation) will cache the 6PM content and re-broadcast the news at 9PM.

The fundamental idea behind the CIR is the notion of a passive broadcast. The metadata describing a radio station is broadcasted to whoever is interested. The client programs (listeners or other stations) that access this information can utilize this data as best as they see fit. The notion of a Radio Station Program Manager (CIRVirtualStation) facilitates an environment that enhances listener experience and content management.


3. Architecture

3.1 CIRVirtualStation

The architecture of the CIRVirtualStation is illustrated in Figure 2. It consists of four parts: a DJ Profiler module, a Discovery module, a Scheduler module, and an Announcement module. The DJ Profiler module provides the DJ a graphical user interface to enter his preferences. The DJ can select a radio station, program the preferred time-slot for it, and set its priority. If a station is set with a high priority, its broadcast becomes an alert that overrides other stations of normal priority. The DJ can set a default genre which will cause a station of that genre to randomly selected. A station can also be set to default, and will be played when no other stations have been selected for that given time. The DJ Profiler module saves this profile upon exiting and loads it upon start up.


Figure 2: Architecture of a CIRVirtualStation

The Discovery module is responsible for discovering what radio stations are available. There are several mechanisms for discovery. One way is to fetch the lists of radio stations from directory servers such as yp.shoutcast.com [2] and yp.icecast.org [3], content hosts such as broadcast.com, or radio station search engines. These listings are often in the form of HTML pages, and can be parsed for the station's content URL, name, genre, description, data format, bitrate, and other attributes. Another way of discovery is to listen to well-known multicast addresses used for announcing multicast sessions. For example, the popular multicast conferencing tool, sdr, announces and listens to the address 224.2.127.254 and port 9875 for SAP session announcements. Each SAP packet contains a SDP payload that describes session attributes such as the session originator, the data channel and format, the session name and description, the contact information of the session creator, and the time duration of the session. Lastly, the user can add a new station to the Discovery module by providing the necessary information (the name and the data channel, at least). This module also contains some pre-specified well-known channels such as the BBC (http://www.broadcast.com/bbc) news channel, and the weather channels. The Discovery module presents to the DJ Profiler module the discovered list, and lets the DJ select from the list in a convenient manner. The DJ can also specify different views based on genre, time, alphabetical, etc.

After the profile has been specified, the Scheduler parses this profile and decides what station should be played at what time, then generates a TV-guide-like playlist for the given profile. When the profile contains alerts (i.e. high priority items), the Scheduler module queries the Discovery module to see whether these stations have become available. If so, and the alert conditions have been satisfied, then the Scheduler selects the alert station and interrupts the normal programming. When there are no alerts, then the scheduling is straightforward, as it only needs be concerned with the selected program times and the default genre and station.

A CIRVirtualStation needs to communicate its playlist to a CIRClient in order for the latter to receive the dynamic content. It achieves this by sending out its playlist via multicast announcements using SAP, with the payload being the playlist. This choice of playlist announcement has the advantage in that it provides scalability over the traditional client-server negotiation. A design issue is to decide how much information to announce and how often, in order to provide the CIRClients with a timely view of the schedule for the near future, without flooding the network with the playlist metadata. Currently we are investigating into using three types of announcements: long-term, medium-term and short-term. Medium-term announcements are on the order of minutes and convey programs in the proximity of several hours. Long-term announcements can contain, say, the schedule of the day, and it can be an HTML page at an announced URL or can be an infrequent multicast announcement. Short-term announcements are for alert messages that notify listener of an event that has just occurred or will occur in a matter of seconds (such as the availability of a traffic report that has just come on-line).

Once the CIRClient receives the playlist, it needs to parse and understand this playlist. The actual audio content can reach the client in two mechanisms. First, it can come from the CIRServer that serves out the original content, thus the CIRClient understands from the playlist when and where to receive a particular station, and tunes to it. In this model, the audio content does not go through the CIRVirtualStation, and the CIRVirtualStation manages the metadata about the audio content rather than the content itself. The CIRClient instructs its player to tune in to the current station, knows when to switch to the next scheduled program, and provides buffering in between for an uninterrupted transition. In the second case, the audio content from a CIRServer is cached in the CIRVirtualStation, who then re-transmits the audio content either immediately or at a later time. This mechanism is akin to the VCR recording, and allows the content to be broadcasted at a later time. It also allows transformation of the content at the CIRVirtualStation, such as re-coding the content to a lower bit-rate for low bandwidth clients, or transcoding it to a different audio format for which the client has a player.

3.2 CIRClient

The architecture for a CIRClient is shown in Figure 3, and it consists two parts: a player and a wrapper. The player part includes many audio decoding tools (including those that can decode MP3, Real Audio format, and RTP), so that it can be as format-independent as possible. The wrapper includes a user interface that lets the listener set the radio station and other settings. This radio station can be a CIRServer or it can be a CIRVirtualStation. The wrapper also includes a parser that parses the playlist announcement from the CIRVirtualStation it subscribes to. Based on the announcement, it invokes the appropriate audio decoder and instructs it to tune to the selected station. Because it has the knowledge of the next program from the playlist, it can prepare for the next program by (possibly) invoking a different player, and buffer the content for a smooth transition.

As discussed earlier, our architecture allows a straightforward integration of the CIRVirtualStation and the CIRClient. This integration results in a customized radio client that achieves all the functions of the CIRVirtualStation personalized to the listener.


Figure 3: Architecture of a CIRClient

3.3 CIRServer

A CIRServer can be any currently available radio station (content provider) on the Internet without any modification. In our framework, we only need to be able to discover this station, and know its data channel. The CIRServer then creates an announcement for this content provider. Thus, any currently available server using, say, NullSoft's Shoutcast server, the multicast conferencing tool sdr, or the RealServer, can become CIRServers with a simple front-end wrapper that parses their listings and SAP announcements and changes to the CIR compatible format.

In the current state of Internet radio, the server simply transmits the audio content, without sending information about what is playing and what will be played. At best, some MP3 stations provide what is currently playing and what is coming up next (see, for example, yp.icecast.org and yp.shoutcast.com), but they do not provide the precise timing information about the content like the switch point between songs and advertisement. Sometimes audio events are advertised on Web pages, but they are not in a standard format, thus making it difficult to automatically parse this information. If the next generation audio servers transmit in-band information on the data being currently broadcast, the CIRVirtualStation can exploit this fine granularity to do a more precise scheduling and enable features like advertisement insertion.


4. Implementation

4.1 CIRVirtualStation

The components in CIR have been implemented in Java to achieve platform independence. Figure 4 shows a screen dump of the various pieces of the CIRVirtualStation that the DJ interacts with to manage the radio station’s program schedule. The main window shows the current radio station playing, along with detailed information on the station when the "Properties" button is pressed. From this window, one can also edit the profile by activating the "Edit Profile" button. In the Profiler, the DJ enters the name of this CIRVirtualStation and the DJ's name. A new program can be added by selecting a station, specifying its start and end time and its priority. A high priority entry means that if it is available, it will interrupt the normal programming. The DJ can set a default genre and a default station. When no station has been programmed for a time slot, the Scheduler selects a radio station of the default genre if this property has been set. Otherwise, it plays the default station. The Profiler allows the DJ to browse a list of stations provided by the Discovery module or manually add a new one. After the profile has been edited, one can view a TV-guide-like schedule of today, tomorrow, or another specified date.


Figure 4: The GUI of the CIRVirtualStation.

Recall that the CIRVirtualStation consists of a Discovery module, a Profiler module, a Scheduler module, and an Announcer module. The Profiler is the part most visible to a user. The other modules are background daemons. The Discovery module (DM) discovers radio stations on the network and passes the radio listings to the other modules in the CIRVirtualStations. The DM currently has three mechanisms to discover a radio stations.

  1. SAP Announcement Listings: Conferencing tools like sdr sends SAP packets with SDP payload on well-known multicast addresses. An SDP description of a session is a string of key-value pair attributes. The attributes include the scheduled air-time, content source, media type (audio vs. video), data encoding, additional information web site location, etc. CIRVirtualStations use a description similar to SDP in their announcements, but include additional information like the genre and priority, and allow the concatenation of descriptions of several radio stations (see more details later in this section). These announcements are from varied types of content providers - live interactive classes and seminars, audio news, music radio stations, video clips, CIRVirtualStations etc. The DM parses only the audio broadcast announcements - this includes the CIRVirtualStation announcements. Other announcements are ignored. The filtered announcements are sent to the other modules of the CIRVirtualStation.
  2. Web-based Directory Listings: An alternate model used in advertising a radio station is by registering it with a well-known directory server. yp.icecast.org and yp.shoutcast.com are examples of such directory servers that list registered radio stations on a Web site. These sites typically contains a list of radio stations, each entry including the name of the radio station, a short description, the genre, the URL of the data channel, the URL of the radio station, and perhaps the bit-rate, the uptime, and the number of listeners. The DM parses these Web sites and sends the radio lists to the rest of the CIRVirtualStation. There are several other directory list servers on the web but due to lack of any format standardization, the listing content is ad hoc. This necessitates writing a separate parser specific to each list server. Our current implementation handles only the two aforementioned directory servers.
  3. Hard-coded Radio Station listing: The DM also provides the ability to add audio broadcasts from hard-coded sources. This is especially useful for adding audio broadcast locally: live feed from the CIRVirtualStation, playback of cached content, etc. The DM, based on input from either the user interface or configuration information creates listings for the broadcasts and passes them to the rest of the CIRVirtualStation.

The Scheduler module parses the profile and decides when and what gets played at a given time. It also gets notified by the Discovery module when the discovered list of stations has changed. The order of precedence for a station to be chosen at a given time is as follows: (1) a station of high priority, (2) a station of normal priority, (3) a station of genre equal to the default genre, and (4) the default station. If a station is not available, then the Scheduler goes to the next highest precedence to find an available station.

Once a schedule (or playlist) is formed, the CIRVirtualStation needs to announce it via its Announcer module. The announcements are sent out as multicast SAP packets, at the CIR-specified multicast address and port number. The payload is a modified form of SDP, which is an ASCII string of attributes each described in the "<key>=<value>" format. The CIR announcement contains a header describing the origin CIRVirtualStation. This header includes the station name, DJ username, message id, description, announcement session name, informational URL, etc. This header is followed by the program listing scheduled for this hour and the following four hours. The program listing is a concatenation of radio station descriptions, each including information such as the program name, program description, data address, start and end time, genre, informationl URL, data format, bandwidth, referrer, and other extensible attributes. As mentioned earlier, the announcements from a CIRVirtualStation are not only received by CIRClients, but can also be parsed by other CIRVirtualStations.

4.2 CIRClient

The CIRClient is the CIR component that the listener uses to access the audio broadcasts. Our implementation of the CIRClient consists of an audio player (including the FreeAmp MP3 player and the GUI-less version of RealPlayer), a wrapper that listens to CIRVirtualStation announcements and controls the audio player, and a User Interface to control the CIRClient.

The wrapper listens to the multicasted CIR announcements, and extracts from the announcement the data format, the address of the data channel, and the start and end time of the current session. It then instructs the audio player to play.

The User Interface includes a Web interface for user control. This control is used to (1) set the CIRClient to the desired CIRVirtualStation or CIRServer, (2) configure the personal information (in the personalized radio case), and (3) configure the audio controls of the radio (like volume, balance, etc.).

As one of the sub-goals of the CIR, we built a Radio Appliance. The Radio appliance is a Linux-based single board computer with wireless connectivity (using either a modem or Wireless LAN like WaveLAN) and audio interface (speakers and microphone). This appliance runs the CIRClient part of the CIR framework. The CIRClient code is implemented on top of Hewlett-Packard's ChaiServer[10], a Web-based software infrastructure for controlling and managing appliances. The ChaiServer library includes access to the infrared port, thus we have also implemented an user interface via IrDA, where the user can "e-squirt" the stations and the volume control to the appliance. The appliance also has a "beacon" that emits its current status via IrDA. Note that the CIRClient software componentcan be installed on any computer as well, not just on our customized Radio Appliance.

4.3 CIRServer

Currently, the CIRServers are the existing radio servers on the Web. We have also created a few radio stations in our network using the Shoutcast server and the sdr multicast conferencing tool. In our next generation implementation, the CIRServer will provide fine grain audio broadcast information, giving details like the start and stop time of songs, and details of the song name and singer, etc. An instance of this has been implemented by [11], which inserts the start and stop signals of a song in the RTP packet level. This allows the precise detection of a song or program, and facilitates a more precise scheduling of songs or programs, as well as enabling advertisement insertion.


5. Related Work

There are wide and varied projects on different aspects of the Internet Radio. The sdp related projects [5], [7] and [8] form the basic building blocks for the CIR architecture. The CIR framework uses SAP and descriptions similar to SDP to build program announcements. The MarconiNet project [12] deals with Internet based audio broadcast but with a focus on creating ad based channel broadcast where the content is always re-directed through the channel servers. The Information Discovery Graph [13] work discusses a scalable hierarchical resource directory through announcement and query. For example, the top level directory contains information of categories like sports, news and music. Then one queries the music directory to find more specific classes like classical music, rock, jazz, and so on. The CIR framework currently uses a simplistic single address multicasting scheme. Future work will research the scalability issues regarding program announcements and description. [2],[3],[6],[9], and [14] provide information on MP3 and RealAudio media formats and players.


6. Conclusion and Future Work

The CIR framework is a scalable Internet audio broadcast environment for managing, customizing, and communicating audio content. It enables features like dynamic content access, ease in creation and management of audio content, and program time-shifting. This research provides valuable insight into various aspects of audio broadcast on the network: exploiting the Web for multimedia information access, building of Web-based appliances and providing a consumer-centric view of the network.

Some of our next steps include:


Acknowledgements

The authors would like to thank Scott Yam, who helped us develop a prototype during the summer of 1999.


References

[1] Broadcast.com, http://www.broadcast.com.

[2] Shoutcast, http://www.shoutcast.com.

[3] Icecast, http://www.icecast.org.

[4] live365, http://www.live365.com.

[5]    M. Handley, C. Perkins, and E. Whelan, "SAP: Session Announcement Protocol," IETF draft, draft-ietf-mmusic-sap-v2-05.txt, Feb. 2000.

[6] Real Networks, http://www.real.com.

[7]    M. Handley, "The sdr Session Directory: an Mbone conferencing scheduling and booking system," http://mice.ed.ac.uk/mice/archive/sdr.html.

[8]    M. Handley and V. Jacobson, "SDP: Session Description Protocol," IETF RFC 2327, Apr. 1998.

[9] FreeAmp Audio Player, http://www.freeamp.org.

[10]    Chai: a Web-based software infrastructure, http://www.chai.hp.com.

[11]    J. Brassil, "The Media Siphon Project," Hewlett-Packard Laboratories, Palo Alto, CA, USA.

[12]    MarconiNet: Next-Generation Internet Radio Network, http://www.cs.columbia.edu/dcc/marconinet.

[13]    The Information Discovery Graph: towards a scalable multimedia resource directory. N.R. Sturtevant, N. Tang, L. Zhang, Proc. WIA'99 IEEE Workshop on Internet Applications, July 1999, pp. 72-79.

[14]    mp3.com, http://www.mp3.com.