[Icecast] Using Icecast relay function with dynamic IP at remote source end
Robert Jeffares
jeffares.robert at gmail.com
Thu Apr 20 23:30:55 UTC 2017
It does not matter what IP BUTT has, it sends to the fixed IP at the
studio on port [ 8000 ] with a mount like /liveBroadcast.mp3
On 21/04/17 11:05, Jack Elliott wrote:
>
> Ha! Terms even a broadcaster can understand! Many many thanks.
>
> If BUTT is considered to be as good a transporter as Icecast, then I
> will stick with what I'm doing, if for no other reason than, "Master
> is the source server (where the source comes from) and Slave is the
> relay. THe connection is initiated by the slave to the master."
>
> Slave may not know where the Master is. Master (on a table in front of
> me at a remote music event) may be at unknown/dynamic IP address. I'd
> have to find my IP address, Teamview into the server computer at the
> station, stop the Icecast service, edit icecast.xml with my current IP
> address, and re-start the Icecast service.
>
> Is there any way to "push" a connection from Master to Slave? Slave is
> at a fixed IP address.
>
> --
> That Jack Elliott
> (541) 848 7021
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
> On 4/19/2017 8:47 PM, David Saunders wrote:
>> ok let see if I can translate it to broadcaster terms for ya :)
>>
>> A icecast server can be set up to accept direct source connection. ie
>> dark ice( which i do agree runs better on the machine where icecast
>> server is. ) I do use it to trans-code the mount to different encoding.
>>
>> THe icecast server can also set up as a relay, where it pulls in from
>> the another server. Primary used to pull the stream from a icecast
>> server. Then make it available to be acceded by clients from it mounts.
>>
>> But, BUTT is designed to stream to an icecast server, and does very
>> well.
>>
>>
>> http://icecast.org/docs/icecast-2.4.1/relaying.html
>>
>> Master is the source server (where the source comes from) ad Slave is
>> the relay. THe connection is initiated by the slave to the master.
>>
>> BUTT ---MASTER ========= SLAVE ===== Clients
>> --- can be local host or lan or wan private or public
>>
>> == is public connections wans/lans/...
>>
>> If you need more bandwidth you can setup/rent other SLAVEs on other
>> networks to augment you bandwidth.
>>
>> It lot easier to have 1 master and bunch of slaves to spreading the
>> bandwidth out, It easier to maintain a single master with many
>> mounts + it easy to trace problems down with sources going to a
>> common Master.
>>
>> I tend to diverge from your question a bit. But, your encoder
>> should work find with broadcaster to the icecast server by itself. I
>> have had it done for the past 10 years. The only real issue s when
>> you encode the stream higher then what he bandwidth can handle.
>> remember the source clients use the UPLOAD speed of you connection
>> and the client use the UPLOAD speeds. In the USA it no uncommon to
>> have uploads speeds to be far slower then you can download. Also I am
>> talking about how fast the connection is not how much data you have
>> in a month. It get really confusing when you talk about bandwidth,
>> since they call both bandwidths.One is how big your pipe is and other
>> how much you get through the pipe in a given time.
>>
>> Lot of the extra above fore those reading this and nee d a little
>> more clarity :)
>> David
>>
>>
>> SLAVE looks a the master waiting for something to do. When it sees
>> the mount it relays it.
>>
>>
>>
>> On Wed, Apr 19, 2017 at 7:33 PM, Jack Elliott
>> <thatjackelliott at kpov.org <mailto:thatjackelliott at kpov.org>> wrote:
>>
>> /I made an error, I swapped two diagrams, it should be this:/
>>
>> Here's how I've been doing it:
>>
>> BUTT ===> WAN ===> Icecast server
>>
>> I thought I might try this instead:
>>
>> BUTT --> localhost Icecast server ===> WAN ===> Icecast server
>>
>> --
>> That Jack Elliott
>> (541) 848 7021 <tel:%28541%29%20848-7021>
>> KPOV 88.9 FM High Desert Community radio
>> Producer, The Wednesday Point
>> Host, The Sunday Classics
>>
>> On 4/19/2017 4:00 PM, Jack Elliott wrote:
>>>
>>> Hi David, I don't think we will necessarily be on wifi, I'm
>>> sorry if I implied that. There are a couple of events each year
>>> when we have to use wifi, but for those I have a dedicated
>>> access point running at close to 1 watt connected directly to
>>> our ISP's network.
>>>
>>> Okay, I was told over on the Darkice listserv that using Darkice
>>> > WAN > Icecast is not very reliable, and my testing supported
>>> that statement. They said that Darkice is an encoder, and
>>> Icecast is a transporter. Icecast, they said, is very reliable,
>>> Darkice is a good encoder but not too great as a transporter.
>>>
>>> I've been using BUTT as the encoder at the remote (audio source)
>>> end, and sending the stream over the WAN to the Icecast server
>>> at the station building. BUTT, I found, is more reliable than
>>> Darkice at the encoding end.
>>>
>>> Here's how I've been doing it:
>>>
>>> BUTT --> localhost Icecast server ===> WAN ===> Icecast server
>>>
>>> I thought I might try this instead:
>>>
>>> BUTT ===> WAN ===> Icecast server
>>>
>>> Now here I want to avoid using incorrect terminology. The way I
>>> am using the word "remote" is how it is used in broadcast: if a
>>> crew leaves the building to broadcast an event occurring outside
>>> the station somewhere, they are doing a remote.
>>>
>>> So in my case, the "remote" is at the music festival - my audio
>>> source.
>>>
>>> So when you write, "The relay easiest to configured in a pull
>>> configuration. Where the setting are setup on the remote
>>> server." -- is it correct for me to interpret that to mean that
>>> I can leave the settings on the station computer's server alone,
>>> just set up the server in my remote kit to "pull" from the
>>> station's server?
>>>
>>> I am puzzled by "pull," since I am wanting to send audio from me
>>> to the station, but that's pulling?
>>>
>>> --
>>> That Jack Elliott
>>> (541) 848 7021 <tel:%28541%29%20848-7021>
>>> KPOV 88.9 FM High Desert Community radio
>>> Producer, The Wednesday Point
>>> Host, The Sunday Classics
>>> On 4/19/2017 10:26 AM, David Saunders wrote:
>>>> Hey,
>>>>
>>>> The relay easiest to configured in a pull configuration.
>>>> Where the setting are setup on the remote server.
>>>>
>>>> Since the client is on WiFi, you will have lots of issues
>>>> streaming due to the ever changing wifi environment. My
>>>> suggestion is source the stream at the lowest settings for
>>>> encoding you can live with, This will keep the bandwidth down
>>>> and less likely burp on you.
>>>>
>>>> We do have clients who use WiFi and set the the encoding to
>>>> smallest size for the content being recorded. Most of the time
>>>> since its voice content we really don't have to go super high
>>>> on the encoding.
>>>>
>>>> I have set up the relay to supplement our bandwidth when we
>>>> think it will be over the limit. Just remember you need to
>>>> give the listeners the remote server connection info not the
>>>> local server.
>>>>
>>>> Why it would be better? not sure why, but if the icecast
>>>> server is set with a larger buffer, it will buffer thru the
>>>> disconnects of the source.
>>>>
>>>> David.
>>>>
>>>> On Wed, Apr 19, 2017 at 11:02 AM, Marvin Scholz
>>>> <epirat07 at gmail.com <mailto:epirat07 at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 19 Apr 2017, at 16:20, Jack Elliott wrote:
>>>>
>>>> For our community radio station's live music festivals
>>>> broadcasts, we set up a small broadcast studio at the
>>>> festival's venue, and use B.U.T.T. to send a stream to
>>>> an Icecast server located at the radio station's building.
>>>>
>>>> REMOTE LOCATION STATION BUILDING
>>>> B.U.T.T. ======= WAN =======>> ICECAST SERVER
>>>>
>>>> It's pretty reliable, though BUTT does sometimes lose
>>>> connection, probably due to network congestion.
>>>>
>>>> The folks on the Darkice listserv claim that using
>>>> Icecast to do the sending provides a more reliable
>>>> connection. So I want to try this idea:
>>>>
>>>> REMOTE LOCATION STATION BUILDING
>>>> B.U.T.T. --> Icecast on localhost ==== WAN ====>>
>>>> ICECAST SERVER
>>>>
>>>>
>>>> I am not sure how this could be more reliable than BUTT alone.
>>>>
>>>>
>>>> I'm finding the terminology for setting up a relay (on
>>>> http://icecast.org/docs/icecast-2.4.0/config-file.html#relay
>>>> <http://icecast.org/docs/icecast-2.4.0/config-file.html#relay>)
>>>> to be a bit confusing and could use some help.
>>>>
>>>> I believe I want to set up a Specific Mountpoint Relay.
>>>> It's where the IP addresses get plugged in that I need
>>>> some clarification. The IP address for the building is
>>>> static, but the IP address for the remote server is
>>>> unknown before every festival, and may be dynamic.
>>>>
>>>> The documentation says that for the <relay> section of
>>>> the xml, we have a <server>127.0.0.1</server> setting.
>>>> And that is described as "This is the IP for the server
>>>> which contains the mountpoint to be relayed."
>>>>
>>>> I can't tell whether the <relay? section is on the
>>>> remote server, in which case we only need to put the
>>>> static IP of the building in the <server> section, or
>>>> whether the <relay> section is on the building's
>>>> server, in which case we need to know ahead of time
>>>> what our remote IP will be, and hope it doesn't change
>>>> during the festival.
>>>>
>>>> I hope this question makes sense. My confusion is
>>>> clearly because I am unclear which server (remote or
>>>> building) the <relay> section applies to.
>>>>
>>>> --
>>>> That Jack Elliott
>>>> (541) 848 7021 <tel:%28541%29%20848%207021>
>>>> KPOV 88.9 FM High Desert Community radio
>>>> Producer, The Wednesday Point
>>>> Host, The Sunday Classics
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>> <http://lists.xiph.org/mailman/listinfo/icecast>
>>>>
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>> <http://lists.xiph.org/mailman/listinfo/icecast>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Icecast mailing list
>>>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>>>> http://lists.xiph.org/mailman/listinfo/icecast
>>>> <http://lists.xiph.org/mailman/listinfo/icecast>
>>>
>>> _______________________________________________
>>> Icecast mailing list
>>> Icecast at xiph.org <mailto:Icecast at xiph.org>
>>> http://lists.xiph.org/mailman/listinfo/icecast
>>> <http://lists.xiph.org/mailman/listinfo/icecast>
>> _______________________________________________ Icecast mailing
>> list Icecast at xiph.org <mailto:Icecast at xiph.org>
>> http://lists.xiph.org/mailman/listinfo/icecast
>> <http://lists.xiph.org/mailman/listinfo/icecast>
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-- *Communication Consultants* 64 Warner Park Avenue Laingholm Auckland
0604 09 8176358 0221693124 06 650 6087
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170421/7f72d9bf/attachment.htm>
More information about the Icecast
mailing list