[asterisk-biz] Implementation of Video Conferencing using Asterisk

[Trixter aka Bret McDanel]

On Mon, 2008-05-19 at 12:13 +0400, Sergey Tamkovich wrote:
> Trixter aka Bret McDanel wrote:
> > On Mon, 2008-05-19 at 11:11 +0400, Sergey Tamkovich wrote:
> >   
> >> Usually, video conferencing hardware (Sony, Tandberg) doesn't use 
> >> multicast for conferencing itself. Unicast only.
> >>     
> >
> >
> > to a point that is required if you have a central server that muxes the
> > video since it takes everyone but you and combines them somehow.  This
> > results in a custom stream for each participant.
> >   
> Exactly.

This was more for general education, given that you said basically this
originally just in what I felt was less clear terms, I figured you would
agree :)  People have spoken in the past about video conferencing and
often comments make me think that people are viewing it from the audio
conference perspective where you can just mux the audio together and
easily make one stream.  

They sometimes forget with video you either have to have multicast
(basically localnet only), mux them by resizing everyone to fit into a
"square" like the brady bunch into one video stream (not light on the
cpu if you are using high compression codecs and many streams) or have
multiple streams, basically N*(N-1) where N is the conference
participant count (so with 5 (N) people, each needs a stream to the
other 4 (N-1), or 5*4=20 streams.  This is probably the least desirable
as it consumes N-2 times more bandwidth for each participant than it
would if there was a central server.  It is however the easiest way to
do it since the server itself doesnt have to know anything about
resizing, muxing, etc.

You also have to figure out how the end points are doing video, some use
multiple rtp streams, one for audio, one for video, some do it in the
same (although the SSRC is supposed to be different for each samplerate,
since the video isnt likely to be at 8000 fps, the RFC requires a new
SSRC (even if the same "conection" is used, and its valid and legit to
use the same "connection" (yeah yeah udp) for multiple streams with
unique SSRCs).

My guess is that for all of these there are at least 2 variants, or if
not there will be.  Some will lie about the sample rate (some vendors
already do when they do 16kHz wideband codecs, makes rfc2833 easier as
well because you have to have a matching sample rate for that or um well
new ssrc which will break most everything out there if you do multiple
2833s with different sample rates and different payload numbers (which
are not by the spec hard coded they just are supposed to use the "free"
range which is quite large).

Sometimes it is actually easier to buy it and let someone else deal with
integration with everything else :)

> > multicast would be ideal if each client is broadcasting to other clients
> > on the local network, and those clients are rendering the participants
> > itself into one display.
> >
> >
> >   
> I didn't meet that kind of terminals, also customers prefer to use 
> conferencing on the WAN instead of LAN.


right, again that wasnt so much for you, just as a general explanation,
often times people get caught up with buzzwords on business lists and
forget about what the technology really does, or the fact that multicast
is almost impossible to get working across the internet in a sane
fashion (vpn is about as close as it gets, depending on what you are
doing, and the vpn in question that can be a performance problem, in
this instance many VPN solutions would not be suitable because they rely
on tcp which doesnt work as well with any packet loss, there are some
popular ones that use a stateless (ipip, udp, etc) method which may work
well for voip apps, but it does not work as well when you are selling a
hosted platform, thus for this list, not very sane for most people
here).  


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
Belfast +44 28 9099 6461        US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!