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

Jack Elliott thatjackelliott at kpov.org
Wed Apr 19 23:00:23 UTC 2017


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
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
> http://lists.xiph.org/mailman/listinfo/icecast

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170419/cd435f18/attachment-0001.html>


More information about the Icecast mailing list