Fco. J. Montilla wrote: > Mensaje citado por Mayhem & Chaos Coordinator <[EMAIL PROTECTED]>: >>The proper way to solve this is to use icecast as a tunneling mechanism. >>If you have an Obs box at location A, and you want to listen to the same >>stream at location B, but A and B are seperated by the Internet, then >>set up icecast as a tunnel. You'll need an icecast server at both points >>-- just have the icecast server at point B propagate a stream from >>icecast server A. >> >>However, this isn't quite what you want. Icecast does not do multicast, >>so location B cannot use multicast. Also, location B will not be able to >>listen to the same stream as location A -- you will need to set up >>different channels. > > I went this route, and found that. No matter how I hack it, I wasn't able to > stream/multicast the same channel. There's the other problem: I cannot once on B > LAN multicast again the icecast stream.
I would have thought that rather than tunneling the data at the application level (which you say doesn't do what you want), a better solution is to tunnel the multicast traffic, so that you have two isolated multicast "clouds" connected over your VPN by TCP tunnels. How to set this up depends a lot on your network setup, but you should be able to set up a BSD or Linux box as a multicast router using mrouted (you will need to enable multicast routing in the kernel, and set up all the tunnels in the mrouted config file). > Another problem I'm facing is that all my mp3s are encoded at 128Kbps VBR with > lame. The ADSL lines that interconnects some of the other branches are only 128 > upstream, so they can't cope with the variable 128 Kbps stream. mrouted can't help you here... there's already a bandwidth overhead stuffing the datastream into UDP multicast packets. Stuffing those UDP packets into TCP packets to tunnel them only adds to the overhead... Pete. _______________________________________________ Obs-dev mailing list [EMAIL PROTECTED] http://www.freeamp.org/mailman/listinfo/obs-dev
