Apologies for the second email but I've thought of a more concrete example other than "this is how we do it".
You have a remote transmitter site. You obviously need to get the station output to the transmitter somehow. Despite the security risks involved, a lot of people are going the Internet route. Being a little security conscious you should be firewalling the hell out of the transmitter which leaves you with 3 obvious routes: 1. Set up a site to site VPN (doable but introduces latency and processing cost) 2. Open the ports on the transmitter firewall (which to my mind is an obvious way of getting your transmitter hijacked, you can mitigate with passwords etc) 3. Have the transmitter pull from the station. I prefer the pull method as worst case scenario someone ends up taking your feed in addition to your transmitter (by getting through the open port on the station firewall) but importantly they can't disrupt the transmitter which you're probably paying hundreds of thousands a year for. I appreciate I've over simplified this example and glossed over/ignored a lot of the ways you can work around security problems. -----Original Message----- From: [email protected] on behalf of Wayne Merricks Sent: Wed 24/10/2012 01:55 To: User discussion about the Rivendell Radio Automation System Subject: RE: [RDD] OpenOB 2.3 release Use case wise, we farm out our transmission to WRN in London (they take care of the satellite uplink and the transmission management in Uzbekistan). I've got full control of the transmission firewall (its my firewall) but the WRN end is off limits, they generally connect to our codec (or an icecast server) and pull the feed from us. The Icecast server is weirdly our most reliable box these days but WRN are obsessed with hardware codecs. -----Original Message----- From: [email protected] on behalf of James Harrison Sent: Tue 23/10/2012 09:10 To: [email protected] Subject: Re: [RDD] OpenOB 2.3 release Since most outside broadcasts want talkback functionality anyway, I want to implement firewall/NAT tunneling to get around the same problem on the transmitter end (because you need an audio link from RX to TX for talkback), which essentially involves the transmitter punching a tunnel to the receiver that the receiver then passes audio over. As for quite how that gets achieved without messing with RTP, that's a challenge, but it's doable I believe. I believe that would then solve your issue. What's the use-case where you've got an unavoidable firewall on the receiver, out of interest? The cost of stuff like the STL-IP was what made me develop OpenOB in the first place - the station I worked for at the time simply couldn't afford a £3000 STL, let alone the £6500 one we'd been recommended as an entry level IP codec. I'm now working at BBC R&D and maintaining OpenOB in my spare time at home, so it's a bit less structured around necessity and maturing a bit now, which is nice. I'm currently working on improving the software's design for packaging so it can be installed with a simple apt-get install openob and can be configured with nice simple configuration files for daemonized operation in addition to the current command-line mode. After that it's a bit more refactoring work to get it plugged into a PyGTK GUI for really simple operation, and to add a web interface daemon. Once those parts are all in place, it'll be more than equivalent in terms of usability to commercial codec software and will have all the parts needed to be trivially packaged up by broadcasters on their own hardware in a package equivalent to a commercial box. Except of course that 'box' can now be a Raspberry Pi running off a LiPo battery with 3G wireless connectivity! Cheers, James Harrison On 23/10/12 02:59, Wayne Merricks wrote: > Very interesting piece of software, I didn't get chance to play with the BETA > but it was on my todo list. One question probably outside of the scope of > the software, what if I wanted to run it as a broadcast codec, effectively > swap the endpoints around so that the receiver connected to the transmitter > (to get around firewalls on the receiver end)? > > I assume the transmitter is connecting to the receiver at the moment? > > I'm currently looking at various traditional IP codecs and it pains me to > look at mini itx, 8mb of compact flash all wrapped up in a 1U box running > linux yet it sets you back £1500 (I had to fix a fan on an MDO Audio TX > STL-IP, I couldn't believe there was a normal PC motherboard in there). > > Feel free to message me off list to save spamming RD (if necessary). > > Regards, > > Wayne > > > -----Original Message----- > From: [email protected] on behalf of James > Harrison > Sent: Mon 22/10/2012 22:27 > To: User discussion about the Rivendell Radio Automation System > Subject: [RDD] OpenOB 2.3 release > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I know a few Rivendellers have used the earlier (beta) versions of > OpenOB in the past so here's a quick notice to all that OpenOB 2.3 is > out, with stable support for the Opus codec recently standarized by the > IETF, which supports bitrates as low as 16kbps or up to 384kbps with a > variety of audio bandwidths. > > OpenOB is the open outside broadcast tool, an audio over IP link tool > which makes moving audio over a network in realtime with very low > latencies (<10ms in PCM mode,<50ms in Opus mode) fairly trivial. > > Other improvements include proper Python packaging for easy > installation, reliability improvements, visual feedback changes and an > improved command line interface. > > Support for the Raspberry Pi single-board computer has now been tested, > confirmed and verified. It works out of the box with no issues using USB > sound cards. This means you can put a link together (both ends) for > under £200. > > You can nab yourself a copy here: > http://jamesharrison.github.com/openob/ - all you need is two computers > running Linux. > > </list-hijack - sorry!> > - -- > Cheers, > James Harrison > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCFujwACgkQ22kkGnnJQAz4cACgkHnoB2JHSBcCNnyVvx+cclb9 > mwIAn2N4PdieHesX1H/WoBuft0j5vLEP > =3NB7 > -----END PGP SIGNATURE----- > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > > ####################### > Scanned by MailMarshal > ####################### > > ############ > > Attention: > > The information contained in this message is confidential and intended > for the addressee(s) only. If you have received this message in error > or there are any problems, please notify the originator immediately. > The unauthorised use, disclosure, copying or alteration of this message > is strictly forbidden. Christian Vision or any of its subsidiaries will > not be liable for direct, special, indirect or consequential damages > arising from alteration of the contents of this message by a third party > or as a result of any virus being passed on. Please note that we reserve > the right to monitor and read any e-mails sent or received by the > company under the Telecommunications (Lawful Business Practice) > (Interception of Communications) Regulation 2000. Christian Vision is > registered in England as a limited company 2842414 and as a charity > 1031031 > > ############ > > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev Scanned by MailMarshal Attention: The information contained in this message is confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Christian Vision or any of its subsidiaries will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. Please note that we reserve the right to monitor and read any e-mails sent or received by the company under the Telecommunications (Lawful Business Practice) (Interception of Communications) Regulation 2000. Christian Vision is registered in England as a limited company 2842414 and as a charity 1031031 to ####################### Scanned by MailMarshal ####################### ############ Attention: The information contained in this message is confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Christian Vision or any of its subsidiaries will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. Please note that we reserve the right to monitor and read any e-mails sent or received by the company under the Telecommunications (Lawful Business Practice) (Interception of Communications) Regulation 2000. Christian Vision is registered in England as a limited company 2842414 and as a charity 1031031 ############
<<winmail.dat>>
_______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
