Hi:
Ok, I've not managed to find any documentation on the shoutcast
compatibility introduced in icecast 2.2.0, so please humour me if I
missunderstand how it's meant to work.
This is my understanding of it currently:
1. You configure Icecast (as shown in the shoutcast example) so that
shoutcast connections get mapped to the mountpoint you define.
2. You configure a listen socket specifically for use as a shoutcast
source port. People connecting on this port wil have their stream appear
on regular Icecast ports under the mountpoint defined for Shoutcast
streams.
Note that it's not clear whether you can only have one port defined, or
just that you can only have one of such ports active at any one time.
3. So, you end up with a situation where you have a regular Icecast setup
running on your regular Icecast port(s), plus one (or possibly more)
ports set up specifically to receive shoutcast-style connections which
will appear on the regular Icecast port(s) under the mountpoint
specified for such streams.
Assuming I'm correct so far, my observations follow.
The one downside to this setup is that you can only accept one shoutcast
style connection at a time. This means that if you have people who want or
need to use this type of connection, you need to run multiple servers.
This seems kinda silly to me as Icecast is otherwise designed to handle as
many streams as you can manage.
My proposal is this. Move the mountpoint specifier from where it is now
into the section where you configure the shoutcast source port. This way,
you could configure several shoutcast source ports, each with their own
mountpoint and hence served by the one server. Ideally, it would also be
good if you could define separate source passwords for such ports too, but
I don't know how much work that would be.
I do realise that we aren't really in the business of encouraging the use
of shoutcast sources, but at least such a change would encourage the use of
the Icecast server as it would negate the need to run multiple servers.
Currently I work with a project that runs 6 shoutcast-compatible servers as
well as an Icecast server. I'd dearly love to be able to get rid of most
of these. If I can do it without having to bug any of the broadcasters
into changing their software, then it'll go a lot more smoothly.
Geoff.
--
Geoff Shang <geoff@hitsandpieces.net>
Phone: +61-418-96-5590
MSN: geoff@acbradio.org
Make sure your E-mail can be read by everyone!
http://www.betips.net/etc/evilmail.html
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
At 12:32 AM 12/29/2004, you wrote:>Hi: > >Ok, I've not managed to find any documentation on the shoutcast >compatibility introduced in icecast 2.2.0, so please humour me if I >missunderstand how it's meant to work. > >This is my understanding of it currently: > >1. You configure Icecast (as shown in the shoutcast example) so that >shoutcast connections get mapped to the mountpoint you define. > >2. You configure a listen socket specifically for use as a shoutcast >source port. People connecting on this port wil have their stream appear >on regular Icecast ports under the mountpoint defined for Shoutcast streams.The shoutcast-compat options in icecast were introduced so that we could properly handle the Shoutcast DSP style source client connection. Here are the important bits we needed to implement : * The shoutcast DSP connects on 2 different ports (lets call this "port" and "port + 1"). The authentication handshaking (as well as the actual stream data) comes over "port + 1", while "port" is used only for sending in metadata updates. * The shoutcast DSP sends in metadata update requests over "port", but does not specify any kind of mountpoint (obviously since it knows nothing about them). * The shoutcast DSP connection protocol is obscure enough that we were not able to easily flag that type of connection protocol (this caused us to require that all "port + 1" connections must be flagged as "shoutcast-compat" to enable shoutcast DSP style connection behavior on that port. So to setup icecast in shoutcast-compat mode you pretty much just create another listen port (one larger than your original port) and mark that "port + 1" port as "shoutcast-compat". This is what the example config does. Also, since the shoutcast DSP doesn't allow you to specify any kind of mountpoint (or anything close to it), you are able to assign a "virtual mountpoint" via the <shoutcast-mount> option. The default is to map all shoutcast DSP sources to /stream. The main problem (and reason why you cannot attach multiple Shoutcast DSPs reliably to a single icecast instance) is the Shoutcast DSP's ignorance of mountpoints. Metadata updates are sent in over the "port" port, and have no mountpoint designation. So, while technically you could connect 2 (or more) Shoutcast DSPs to icecast, you would have no way to map the metadata updates from those 2 to the correct mountpoints. It may be possible to do this based off the port the request came in on (that would then require you to setup a set of 'port' and 'port + 1' pairs for each possible shoutcast DSP you wanted to connect. This is not a very elegant solution however, and is marginally better than starting up multiple icecast instances. although we may consider implementing it if enough people ask for it. The good news is, once you've connected a shoutcast DSP to icecast (and it is mapped to a mountpoint), then you can use all the normal "mountpoint-specific" settings that any normal mountpoint can. this includes specifying a different source password, all the authentication stuff, and things like fallbacks. Hope this explains it a bit better, and if you have any questions, feel free to followup... oddsock
On Wed, Dec 29, 2004 at 08:49:54AM -0600, oddsock wrote:> So, while technically you could connect 2 (or more) Shoutcast > DSPs to icecast, you would have no way to map the metadata updates from > those 2 to the correct mountpoints. It may be possible to do this based > off the port the request came in on (that would then require you to setup a > set of 'port' and 'port + 1' pairs for each possible shoutcast DSP you > wanted to connect. This is not a very elegant solution however, and is > marginally better than starting up multiple icecast instances. although we > may consider implementing it if enough people ask for it.IMHO, it's much better than having to run multiple instances. Especially since you're already doing magic with the paired ports. -r
oddsock wrote:> The authentication handshaking (as well as the actual stream > data) comes over "port + 1", while "port" is used only for sending in > metadata updates.Oh yuck!> * The shoutcast DSP sends in metadata update requests over "port", but does > not specify any kind of mountpoint (obviously since it knows nothing about > them).Indeed. So much for my idea, at least in the form I presented it. But this does make it essential to have a regular listen socket on shoutcastsourceport-1, which could probably be more strongly worded in the docs (e.g. metadata updates won't work if you don't do this). Of course, I've not really checked the docs for this (it might already be in there), but the config file sample seemed to suggest that it was a good idea rather than strongly recommending against not doing it (if that makes any sense). I do agree that defining port pairs would be a bit clunky, but the whole thing has a ring of clunkiness about it (not Xiph's fault of course), and given that we are treating the base port specially with the metadata then perhaps this would be the best way to do it. And perhaps it would be less confusing to have a <shoutcastcompat> section with all the required values or something. Geoff.