Greetings,
I have some confusion. I've seen it mentioned, somewhere in some docs,
that Icecast2 does not (as yet) support Push relaying. Is this actually
the case? Should I be looking at icecast1 (which does support push
relay, I believe) until such capability is implemented on icecast2? Or
should I be creating a combination of both? Or what?
Here's my situation:
I have a customer with the following requirements:
1. A Mac OS X based Nicecast "live radio" feed from his office/studio
relaying to a Datacenter server running Linux accessible on a URL on
his website. I.E. We need the capability of running multiple streams
from a datacenter server with one IP address.
2. The datacenter server would also need to stream archived content, on
separate streams (each accessible via a URL on his website), in addtion
to the live stream.
The following conditions are in play.
1. My customer is NOT technically capable; he's a musician, an
entrepreneur, and runs a non-profit which needs to stream audio.
Therefore, setting up icecast2, on his G5 Powermac, such that Pull
Relaying could be setup using "Single-Broadcast Relay" would require
my
doing so on my own G5 and subsequently installing my working
implementation on his machine
2. Moreover, in order to set the <server>his server ip</server>
field,
within the <relay></relay> container in the icecast2 config file,
this
"Master Server" at my customer's studio would have to be provided
with
a static IP, or I'd have to acquire his current DHCP provided IP
address (Cox Cable) and programatically adjust the XML config file
running on the "Slave" server at the datacenter. Additionaly, he'd
have
to expose the G5 at his studio on a DMZ, or port forward the required
ports. This is a plumbing and maintenance nightmare.....
What I'm thinking of doing now, is to running an instance of either
icecast1 or shoutcast, on the datacenter server, to receive the
'pushed' broadcast from the Nicecast running on the G5 at my
customer's
office/studio. Additionally running an instance of icecast2, on the
same datacenter server (and on another port(s)) to stream the archived
mp3 content.
Do I have this right? Or am I missing something?
--
Chuck Tellechea
CMTi Technologies, Inc.
Chuck Tellechea wrote:> What I'm thinking of doing now, is to running an instance of either icecast1 > or shoutcast, on the datacenter server, to receive the 'pushed' broadcast > from the Nicecast running on the G5 at my customer's office/studio. > Additionally running an instance of icecast2, on the same datacenter server > (and on another port(s)) to stream the archived mp3 content.It is true that Icecast2 can't do push relaying, but I don't understand why you need it. If Nicecast is going to be pushing the content to you, what's the problem? Maybe *I'm* missing something. Geoff.
On Thu, 24 Mar 2005 01:26:59 +1000, Geoff Shang <geoff@hitsandpieces.net> wrote:> Chuck Tellechea wrote: > > > What I'm thinking of doing now, is to running an instance of either icecast1 > > or shoutcast, on the datacenter server, to receive the 'pushed' broadcast > > from the Nicecast running on the G5 at my customer's office/studio. > > Additionally running an instance of icecast2, on the same datacenter server > > (and on another port(s)) to stream the archived mp3 content. > > It is true that Icecast2 can't do push relaying, but I don't understand why > you need it. If Nicecast is going to be pushing the content to you, what's > the problem? Maybe *I'm* missing something.Nicecast uses Icecast to do its broadcasting, so it can't do anything that Icecast can't do. So I don't really understand either. Could you solve the DHCP problem by getting your customer set up with dynDNS? Wouldn't that immediately solve the problem, meaning that people could listen directly to the stream coming from his box? Dan -- http://www.mcld.co.uk
i don't think anyone has really answered his question yet, so i'll give it a shot. from what you have said i think you are misunderstanding something. the customer that is running nicecast does not need any kind of server on his machine, all he would have to do is tell nicecast to stream to your server as for the archived content, all thet would be required is to run ices on the server machine to do that streming of static content On Wed, 23 Mar 2005 16:28:24 +0000, Dan Stowell <danstowell@gmail.com> wrote:> On Thu, 24 Mar 2005 01:26:59 +1000, Geoff Shang <geoff@hitsandpieces.net> wrote: > > Chuck Tellechea wrote: > > > > > What I'm thinking of doing now, is to running an instance of either icecast1 > > > or shoutcast, on the datacenter server, to receive the 'pushed' broadcast > > > from the Nicecast running on the G5 at my customer's office/studio. > > > Additionally running an instance of icecast2, on the same datacenter server > > > (and on another port(s)) to stream the archived mp3 content. > > > > It is true that Icecast2 can't do push relaying, but I don't understand why > > you need it. If Nicecast is going to be pushing the content to you, what's > > the problem? Maybe *I'm* missing something. > > Nicecast uses Icecast to do its broadcasting, so it can't do anything > that Icecast can't do. So I don't really understand either. > > Could you solve the DHCP problem by getting your customer set up with > dynDNS? Wouldn't that immediately solve the problem, meaning that > people could listen directly to the stream coming from his box? > > Dan > > -- > http://www.mcld.co.uk > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >
Darrel, Thanks for the help. I'm presuming then that I've misunderstood what is meant by "pull" vs. "push". I understood, I guess erroneously, that the context of 'push' relaying was from the perspective of the icecast2 receiving a 'pushed' stream. I believe now that I have this backwards, and that the context is from the part of icecast2 not being set up to 'push' a stream (broadcast as per nicecast or shoutcast client tools) to another icecast2 server (or icecast1, shoutcast, or whatever). If such is the case, then I am still confused by the context of the "Specific Mountpoint Relay" paradigm and how to setup a mountpoint for the 'listening' icecast2 server at the datacenter which would be receiving a 'pushed' stream from the nicecast client/server at my customer's studio. Or do I is the "Specific Mountpoint Relay" paradigm *not* applicable here, and what I need to do is merely to setup a <listen-socket> instance with the <shoutcast-compat> set to true, and setup Nicecast to send as if to a shoutcast server? Nicecast has a icecast2 option in its remote server configuration, however, it requires one to specify an mountpoint; and if such is the case, I'm back to using the "Specific Mountpoint Relay" paradigm, aren't I? In any case, I'm going to try a few different ways while instrumenting the connections with tcpdump and see if I can figure this out. I'll be working on this the rest of the day today. Thanks again :) On Mar 23, 2005, at 1:27 PM, Darrell Dominey wrote:> i don't think anyone has really answered his question yet, so i'll > give it a shot. > > from what you have said i think you are misunderstanding something. > the customer that is running nicecast does not need any kind of server > on his machine, all he would have to do is tell nicecast to stream to > your server > > as for the archived content, all thet would be required is to run ices > on the server machine to do that streming of static content > > > On Wed, 23 Mar 2005 16:28:24 +0000, Dan Stowell <danstowell@gmail.com> > wrote: >> On Thu, 24 Mar 2005 01:26:59 +1000, Geoff Shang >> <geoff@hitsandpieces.net> wrote: >>> Chuck Tellechea wrote: >>> >>>> What I'm thinking of doing now, is to running an instance of either >>>> icecast1 >>>> or shoutcast, on the datacenter server, to receive the 'pushed' >>>> broadcast >>>> from the Nicecast running on the G5 at my customer's office/studio. >>>> Additionally running an instance of icecast2, on the same >>>> datacenter server >>>> (and on another port(s)) to stream the archived mp3 content. >>> >>> It is true that Icecast2 can't do push relaying, but I don't >>> understand why >>> you need it. If Nicecast is going to be pushing the content to you, >>> what's >>> the problem? Maybe *I'm* missing something. >> >> Nicecast uses Icecast to do its broadcasting, so it can't do anything >> that Icecast can't do. So I don't really understand either. >> >> Could you solve the DHCP problem by getting your customer set up with >> dynDNS? Wouldn't that immediately solve the problem, meaning that >> people could listen directly to the stream coming from his box? >> >> Dan >> >> -- >> http://www.mcld.co.uk >> _______________________________________________ >> Icecast mailing list >> Icecast@xiph.org >> http://lists.xiph.org/mailman/listinfo/icecast >> > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-- "Living is easy with eyes closed; misunderstanding all you see...." John Lennon Chuck Tellechea
Dan, Thanks for responding. On Mar 23, 2005, at 11:28 AM, Dan Stowell wrote:> On Thu, 24 Mar 2005 01:26:59 +1000, Geoff Shang > <geoff@hitsandpieces.net> wrote: >> Chuck Tellechea wrote: >> >>> What I'm thinking of doing now, is to running an instance of either >>> icecast1 >>> or shoutcast, on the datacenter server, to receive the 'pushed' >>> broadcast >>> from the Nicecast running on the G5 at my customer's office/studio. >>> Additionally running an instance of icecast2, on the same datacenter >>> server >>> (and on another port(s)) to stream the archived mp3 content. >> >> It is true that Icecast2 can't do push relaying, but I don't >> understand why >> you need it. If Nicecast is going to be pushing the content to you, >> what's >> the problem? Maybe *I'm* missing something. > > Nicecast uses Icecast to do its broadcasting, so it can't do anything > that Icecast can't do. So I don't really understand either. > > Could you solve the DHCP problem by getting your customer set up with > dynDNS? Wouldn't that immediately solve the problem, meaning that > people could listen directly to the stream coming from his box? >Well, the problem here is that bandwidth (hopefully) will become an issue and that is why we need to relay to a server with a FAT pipe at a datacenter. Regardless, he'd have to setup port forwarding, or a DMZ, on his router/NAT device behind his cable modem, and such would be beyond his skills. I'd need to do that and then manage it as well. Much, much, simpler for him just to send a stream to the datacenter server and have that server 'proxy' it to the world. I do that now with shoutcast and nicecast for my Buddhist temple; however, that's only one stream. There's going to be a number of separate streams to different content and bitrates for this customer. And though, I presume, I could run multiple instances of shoutcast on the same box, on different ports, such would be more of a pain to manage than one daemon process handling all of them; therefore my interest in icecast2. Thanks again :)> Dan > > -- > http://www.mcld.co.uk > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-- "Living is easy with eyes closed; misunderstanding all you see...." John Lennon Chuck Tellechea