[JDEV] Videoconferencing with jabber /Re:[speex-dev]Videoconferencing with speex and jabber

[Richard Dobson]

> > You seem to have conveniently skirted the issue here of latency which I
> > think is a major one, and the issue that other already deployed systems
> > (SIP, Xbox) use the p2p approach for very good reason and perfectly
> > sucessfully. You also seem to have skirted the issue that the client
acting
> > as the server is also a major point of failure, if they loose connection
> > then the whole conference will stop and no one will be able to chat,
whereas
> > p2p will just continue on fine for the rest of the people. There are
several
> > ways the client could loose its connection either internet problems (as
ADSL
> > and Cable broadband are not always that reliable over here in the UK),
if
> > the person is on dialup they might have hit their connection time limit
and
> > been disconnected and have to redial (over here in the UK dialup users
on
> > most unmeatered packages have set limits for the length of time each
> > connection can be, usually 1-2 hours, at which time they will need to
> > redial), or someone might not like the person hosting the conference
(maybe
> > they were excluded from the chat) and DDOS's them, in light of these it
> > shows that your server solution has some serious problems that it cant
> > really solve very easily.
>
> If I were initiating a conference (ie I was the server) and I lost my
> connection d*mn if the rest of the meeting can rattle on without my
hearing
> it. It might be OK for Xbox but in a business environment it is very
> important to have all members around all the time and especially the
> Chairman!

Then in business you use a server or use a reliable connection, for a group
of friends chatting away between themselves it is bad if everyone gets
disconnected, also if its not a meeting and people are going in and out of
the chat what if the person acting as the server goes ?? Everyone will get
disconnected. As already noted anyway this p2p mode is primarly for normal
people anyway, business's will most likely host a server, whereas home users
 will generally not have access to one, also as already shown the client
acting as a server approach as some major downsides on unreliable/home
connections. If I was chatting away with my mates from home I would be
mighty annoyed if the whole chat ended when one of my mates (the one acting
as the server) started experiencing network problems, especially if I could
have used p2p and still continued chatting with my other mates while the one
with problems got it sorted and rejoined later.

> As to bandwidth, unless I am missing something each peer needs to send out
> their audio to each member - 7 people means 6*7=42 streams out. With a
sever
> you have 12 streams to the 6 clients - one out and a mixed one back (sans
> your own data). Even if the output stream is broadcast, with p2p each
client
> will have to mix those 6 streams so it is almost the server anyway! With a
> server based solution the client only has a single stream in and out to
> handle and the server is the only one doing the donkey work and
technically
> not much more than a client would do in a p2p environment, which is
logical
> as in p2p each p has to be a server in anything but name.

Yes you are missing something 6 people will mean 6 streams in and 6 streams
out on each client, meaning 12 streams on each client, which is only 48kbps
each way assuming an 8kbps voice codec is used, which a broadband connection
will easily handle, also remember using silence detection it means that only
connections with people currently talking need even have traffic flowing so
that bandwidth use will likely go down to 8kbps normally inwards when
someone else was talking and only sometimes jumping up to 48kbps if everyone
starts talking at once, also the outgoing bandwidth of my connection will
only be used when I myself am talking. Also on the subject of mixing those
streams on the client, yes those streams will be mixed but that task
certainly on windows systems can be passed into directx which will pass most
of the donkey work of that onto your soundcard, whereas in a server where
the mixed stream needs to be rebroadcast that needs to be all handled by the
processor, and as well as the stage of actually mixing the streams the
server also needs to reencode the mixed stream to send out, so the p2p mode
does infact put less demand on the system as far as mixing goes.

Richard