[Icecast] Using Icecast relay function with dynamic IP at remote source end

Robert Jeffares
Thu, 20 Apr 2017 23:30:55 -0000

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-0001.html>