When planning a radio remote (also known as an Outside Broadcast), it's important to consider what would happen if the connection were to drop. Is there a co-host at the station who can carry on, or a board op who can play in some filler content until the line is re-established?

Just as you should have a back-up running when a show is recorded, you should have a back-up circuit for your live show. The board-op can then quickly swap from the 'main' to the 'reserve', in the event of a disconnection. How seriously you take this will be largely determined by the size of your audience, and of course any advertising revenue.

You might of course ask why any of this should be necessary, if sip.audio and ipDTL were free of faults. Whilst we do our best to maintain a reliable service, it's important to appreciate that no technology is 100% reliable, and that our services rely largely on public networks and ISPs (Internet Service Providers).

We do pride ourselves on the following:
• Network of over 10 SIP servers around the world
• Diverse power, UPS and generators at each site
• Diverse connectivity from many different providers
• Ability to switch and divert traffic around rare network faults
• Backup SIP proxys at proxy2.sip.audio
• Backup ipDTL website and servers at ipdtl2.com

When planning your remote, try your best to eliminate any potential single point of failure. Whilst you could send or receive both the main AND reserve feed from ONE multi-channel device, consider that if that device should fail, then you have no plan B.

Here is an example of truly diverse main and reserve paths...

Remote Mixer Aux1 > ipDTL PC > AT&T Router > Internet (Direct) > Corporate Network > ipDTL PC > Studio Board MM1

Remote Mixer Aux2 > IP Codec > Comcast Router > Internet (Relayed) > Backup Network > IP Codec > Studio Board MM2

Note in this example that...
• Each path has its own aux or mix-minus at each end, so that switching faders doesn't cause any audio to loop back around.
• The ipDTL stream takes a direct path across the internet. This can be forced to relay via a server, in ipDTL's settings.
• The sip.audio stream between hardware codecs is relayed via a server. This can be can be changed in sip.audio's account settings.

Of course, such diversity isn't always achievable, and compromises may be necessary while acknowledging the risk. Other options for achieving a diverse path include using ipDTL and ipDTL2 respectively, or perhaps using 4G LTE for the reserve path.