[icecast] a new directory service
rillian at telus.net
Mon Sep 17 20:59:03 UTC 2001
Forgive the lack of antecendents. I just now joined the list, but will
respond generally to what I saw in the list archives.
I think jack's suggestion of distinguishing between static and
time-depended data is a smart one. I would also suggest that many of the
ranking issues people are concerned about can be addressed through the
description field. Punting things like 'now playing' to a metadata
stream seems like a good idea. Directory servers can watch this directly
and add it to their displays if they think that's worthwhile.
The ttl field does provides some time-dependence capabilities, and it
can be abused by setting it too short as well as too long. The latter
case can be solved though a no-ping expiry policy on the directory
server as jack suggested. Probably we should just design so '0' is also
an acceptable setting, and let individual maintainers decide on a
The ttl field in dns is mostly there to control propagation through a
distributed cache. Are we planning something like that for the icecast
> authorization string. this is a md5sum of of some
> random data.
> ex.: echo 'jack at xiph.org|Jack Moffitt|password' | md5sum
As written, this adds little security over sending the password in
plaintext. Some folks at mit recently wrote a nice summary of how to do
secure auth over the web:
Unfortunately, anything more secure requires a shared secret, and thus
and ssl-connection over which to send it. For example, running the
contents of the update through the hash in addition to the password
would let the server verify each update directly and block replay
attacks. Of course, this assumes the connection in between is more
vulnerable than the server and/or the client's machine, so perhaps in
practice it's so much better. Still, I think it's worth trying to do
> We could add a second tag 'rate', which could be in kHz for audio, and
> in fps for video based streams. We could also add a 'channels' to
> describe the number of audio channels (it's not unlikely we will see
> surround sound Ogg streams) and maybe a 'size' for picture size (ex.:
I think a separate table is needed with stream urls and this specific
metadata, all of which sits under the more general data like stream
name, homepage and description. That easily takes care of both mirrors
and alternate bitrate versions of the same content.
All the extra bits get complicated fast, but bitrate, samplerate, number
of channels, and size seem like a good starting point. Maybe 'size'
should be replaced by 'format' which can be the resolution/aspect ratio
for video and the surround format for audio.
You might also want some sort of sub-description that could say things
like 'Pacific Mirror'.
Otherwise, the general layout looks good. Program 'guides' for a
particular station with scheduled programming is another nice feature,
but it's somewhat orthogonal to what jack has suggested. I do think it's
perfectly reasonable for the same software to support it, but we should
think about it as a separate piece of information. Anybody know if
here's an xml working group for program listings? :)
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast