Icecast (http://www.icecast.org/) is one of the greatest open source multimedia projects done by Xiph.Org Foundation (http://www.xiph.org/), also known as Xiphophorus. Their other remarkable projects include Ogg stream format, Vorbis audio compression algorithm and software, Speex low-bitrate speech compression algorithm and software, and Theora video codec. Icecast 2's primary engineers include Jack Moffitt, Michael Smith and the folks from oddsock.
Icecast is a streaming audio server - in other words, it's all you need to set up an "Internet Radio" server.
Icecast's primary strengths at the moment include the fact that it's client-compatible with Shoutcast, meaning everyone with Winamp is a potential listener. All other clients that support HTTP will also work (iTunes, XMMS, mpg123 or ogg123, curl|ogg123|aplay, etc...). It is also open source, and reportedly far easier to work with than shoutcast itself, at least for your average *NIX geek. Music is streamed in MP3 format (1.x) or Ogg Vorbis (2.0beta), and any bitrates supported by these formats are supported in the software.
Icecast at the moment is in kind of an annoying state. Basically, the preferred version is 2.0, but it is only at the beta state, and many of the tools (such as Liveice) for 1.x (or even earlier incarnations of 2.0) won't work with it. Also, 2.0 only supports Ogg Vorbis and not MP3 - the developers were forced to make the unsupported, obsolete 1.x version available because the demand for MP3 support was so high. Further, there's no generic "feed these media files to the thing and it plays" support in ices2 (the bundled source client), it only accepts PCM and Vorbis - luckily, PCM input can be given "live", so I could do some shell hackery with mpg321 to feed MP3s through ices2...
Icecast's architecture is very clean client-server based thing, and most of the things happen over HTTP protocol. Streams are requested via normal HTTP GET request. The server only opens one port that is used for all transactions (listener, source and admin connections), and it can also be used to serve normal documents. As usual, it's probably not up to task as a generic http server, so you may want to try something more reliable.
Basically, there are three kinds of processes. There is the streaming server, which streams the music to clients, that is, listeners. The server gets its music pre-encoded from a source client. The source client and server don't necessarily need to be on the same server.
The source connects to the server and "mounts" the stream to some URI. The client connects to the server and requests the URI, and thus is the streaming started. The source can mount the same stream to multiple servers (load balancing reasons, for example), or even provide same stream in multiple bitrates. Well, that's how the theory goes, it's all up to the client implementer... at the moment, the most reliable icecast2 source client available is the one that comes with icecast (ices2).
From user point of view, the streams appear as ordinary URIs (as in http://server:8006/radio.ogg). However, it's customary to use a "metafile" that is merely a text file containing the URL of the server, placed on the web server and linked from a web page (http://server/radio/radio.m3u) - when user clicks on the link, web browser will note it's a playlist rather than a file, and will then launch a music player to handle the stream, rather than trying to save the stream to disk.
Icecast also supports (or rather, supported, I have no idea how this is handled in Icecast2) YP servers, that is, realtime web directories of radio channels.