Icecast - Jun 2005 - How to reach listeners behind corporate firewall

Hi,

I know two solutions for that.
1. You set up icecast to broadcast on the 80 port (there's a <port>
tag
in the xml). If you run a webserver on the same machine, then you can't 
do this.
2. If you run a webserver on the 80 port, you can set up the webserver 
to relay the stream through it. If you use apache, you need something 
like this in your httpd.conf:

<VirtualHost IP_ADDRESS>
    ServerName stream.company.com
    ErrorLog /var/log/apache/stream_error.log
    CustomLog /var/log/apache/stream_access.log combined
    ProxyPass / http://127.0.0.1:8000/
    ProxyPassReverse / http://127.0.0.1:8000/
</VirtualHost>

After this the users can connect to 
http://stream.company.com:80/[stream_path].
This case in the stream's log all connections come from 127.0.0.1, but 
the original IP addresses are recorded in the apache's log.

Yours,
Jacint


Ron Blok wrote:
>Hi fellow icecast users,
>
>I get more an d more complaints from listeners who are trying to listen to
>our stream behind a firewall.
>It seams that more and more companies block port 8000 in their firewalls.
>
>Is there a solution for these cases ? I have somewhere read something about
>streaming on port 80 instead of 8000.
>Is this the solution ? Or ???
>
>Thanks in advance,
>
>Ron
>

Unfortunately, this won't really help with some corporate HTTP  
proxies, because the proxy never finishes loading the stream (it's a  
stream) and therefore never sends anything on to the client.

Interestingly, I've seen windows media streams work in such places.  
Does anybody know that happens? Are windows media streams really a  
bunch of small files that the clients reassemble?

On Jun 5, 2005, at 12:45 PM, Balint Jacint wrote:
> Hi,
>
> I know two solutions for that.
> 1. You set up icecast to broadcast on the 80 port (there's a
<port>
> tag in the xml). If you run a webserver on the same machine, then  
> you can't do this.
> 2. If you run a webserver on the 80 port, you can set up the  
> webserver to relay the stream through it. If you use apache, you  
> need something like this in your httpd.conf:
>
> <VirtualHost IP_ADDRESS>
>    ServerName stream.company.com
>    ErrorLog /var/log/apache/stream_error.log
>    CustomLog /var/log/apache/stream_access.log combined
>    ProxyPass / http://127.0.0.1:8000/
>    ProxyPassReverse / http://127.0.0.1:8000/
> </VirtualHost>
>
> After this the users can connect to http://stream.company.com:80/ 
> [stream_path].
> This case in the stream's log all connections come from 127.0.0.1,  
> but the original IP addresses are recorded in the apache's log.
>
> Yours,
> Jacint
>
>
> Ron Blok wrote:
>
>
>> Hi fellow icecast users,
>>
>> I get more an d more complaints from listeners who are trying to  
>> listen to
>> our stream behind a firewall.
>> It seams that more and more companies block port 8000 in their  
>> firewalls.
>>
>> Is there a solution for these cases ? I have somewhere read  
>> something about
>> streaming on port 80 instead of 8000.
>> Is this the solution ? Or ???
>>
>> Thanks in advance,
>>
>> Ron
>>
>>
>
> _______________________________________________
> Icecast mailing list
> Icecast@xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>

Ben wrote:
> Unfortunately, this won't really help with some corporate HTTP 
proxies,
> because the proxy never finishes loading the stream (it's a  stream)
and
> therefore never sends anything on to the client.
I've never come across a proxy that you couldn't listen to a stream
across.

--
Chris Jones, SUCS Admin
http://sucs.org

> 2. If you run a webserver on the 80 port, you can set up the webserver
> to relay the stream through it. If you use apache, you need something
> like this in your httpd.conf:
> 
> <VirtualHost IP_ADDRESS>
>     ServerName stream.company.com
>     ErrorLog /var/log/apache/stream_error.log
>     CustomLog /var/log/apache/stream_access.log combined
>     ProxyPass / http://127.0.0.1:8000/
>     ProxyPassReverse / http://127.0.0.1:8000/
> </VirtualHost>
> 
> After this the users can connect to
> http://stream.company.com:80/[stream_path].
> This case in the stream's log all connections come from 127.0.0.1, but
> the original IP addresses are recorded in the apache's log.
This solution works well, but I wanted to note one thing I discovered
when testing it.  You need to open the URL in the media player for
this to work.  If you hyperlink to, say:

http://stream.company.com:80/[stream_path].m3u

then the client will be redirected to http://icecast-host.company.com:8000/

-Dave Pascoe
 LiveATC.net

Dave Pascoe wrote:
> This solution works well, but I wanted to note one thing I discovered
> when testing it.  You need to open the URL in the media player for
> this to work.  If you hyperlink to, say:
>
> http://stream.company.com:80/[stream_path].m3u
>
> then the client will be redirected to http://icecast-host.company.com:8000/
You could fix the host part by changing the hostname in Icecast, but that 
wouldn't solve the port issue.  Probably the best way would be to make your 
own .M3U file which points to the right place.

Geoff.