[BC] introduction and RE: multiple ISDN's

[Johannes G. Rietschel]

Hello, 

my name is Johannes Rietschel, I am CEO of Barix, and thanks to Jim Peck's 
pointer I subscribed to this list.
I will be happy to answer questions regarding IP in general and specific 
techniques or protocols in particular.
I have done IP based "streaming" implementations since about 20 years now 
(sold my first company doing serial-
to-ethernet to Lantronix and served as their CTO a couple of years ago, if 
you have a Lantronix device it's a high
chance Johannes' designed technology is in there).
So - enough of the personal and introductory stuff - this is "onetime" 
only. I would like to explain a bit further about UDP/TCP,RTP, BRTP etc:

Most internet radio stations and many STL applications use TCP - the 
"reliable" part of the IP protocol suite, for streaming.
This makes sense where receivers can buffer - you need to buffer because 
eventually lost data needs to be retransmitted.
Typical shoutcast/icecast servers (software solutions running on a variety 
of operating systems, free) use TCP/IP to receive a stream
from a source (such as the Barix Instreamer, $395 device, or a software 
solution such as the winamp plugin). The server then
buffers and "replicates" the stream to a large number of "listeners" - 
these can be hardware devices (like the Barix Exstreamer, 
$195) or PC's with a media player software (winamp, windows media player 
etc).
Service providers like streamguys (www.streamguys.com) offer such servers 
"for rent" very cheap, they charge typically per stream
per month and operate the server. A big advantage is that for a typical 
"STL" or one-to-many link, no static IP address is required on
either side - you can stream from the studio directly to the service and 
the listeners can "pull" the stream from the service.
Disadvantage is the relatively high latency (typically more than 10 
seconds) due to server buffering AND player buffering.

A direct link can be much faster - but with TCP ("reliable" transmission) 
there will be still some latency - it is necessary that the receiver 
buffers, 
otherwise the retransmission function cannot work.

RTP - in contrast, is a "UDP" (nonreliable packet delivery) protocol. Each 
block sent by the server either makes it to the destination or is lost.
Only UDP based protocols can be "multicast/broadcast" (addressed to 
many/all devices) on a network. And as Tom Hartnett already pointed out, 
the public internet typically does not support multicast. Local networks 
and VPN's however often do.
Barix products are, for example, used by Clear Channel to do exactly that 
- take an audio feed, convert it to IP/Multicast, then distribute to a 
large
number of sites (equipped with the Exstreamer) via a satellite based IP 
network. For satellite applications, IP/Multicast or broadcast is ideal, 
because
every receiver gets the same signal. One feed then can address a very 
large number of devices/sites/receivers.
Disadvantage is that if a block is lost, the receiver has to deal with 
this fact (and typically cannot ask for retransmission), different vendors 
have different
tricks/schemes on how to react on block loss.

RTP packets can of course also be sent to a particular IP address. For 
example, if you have 5 destinations you want the stream to go to, you can 
enter
multiple destinations into the encoder (this works on Barix as well as on 
Comrex). But, again, as Tom pointed out, this means n times uplink 
capacity need.

You can get around this problem (as you can with TCP/IP) by using a 
rebroadcasting service provider or a "hosting" center where you put a 
rebroadcasting
server. Barix offers a control device which can duplicate a stream from 
one source to up to 100 destinations (at 64kbps), it's inexpensive ($295) 
and non-PC 
based. The device rebroadcasts standard RTP with less than 20ms (!) 
latency. Streamguys is currently testing a software implementation and 
likely will offer
RTP rebroadcasting with Barix for low-latency applications - because that 
is a big benefit of an RTP based implementation - it is - compared to 
TCP/IP - very
low latency because no buffering for retransmissions is needed.

RTP has still one disadvantage. It is a "push" protocol. Which means that 
targets need to be "well known" (public IP address) and with typical NAT 
servers, routers
etc, "forwarding" configuration is needed so the router knows to which 
device on the local network to send the feed.
BRTP (B stands for Barix) overcomes this problem/limitation. This protocol 
is plain RTP with a simple extension. The stream is "pulled" from a 
server, which solves
the "pass-through" issue on most NAT/firewalls and also allows the 
destinations to be on dynamic IP addresses.
With BRTP you have the advantage of low latency, and all the advantages of 
the "shoutcast/icecast" solution - no need for a static IP address on 
either sender or
receiver sites. Of course supported by the streamguys hosted replicator ;)


I hope this was not a too long post and can help to shed some light on 
these things. Please forgive if too verbous - if so, let me know and I 
will be quiet or terse in the future. If too commercial, please let me 
know too - I am new to the list here. I hope my presence is welcome.

Greetings !

Johannes Rietschel
CEO, Barix AG