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

[Timothy Carpenter]

On 28/11/03 11:37 am, "Richard Dobson" <richard at dobson-i.net> wrote:

>>> 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.

Well, I think it is better to solve the hard problems up front. We are
talking conferencing, not audio chat. It gets a big deal when you include
video. If we get the framework right for audio then an audio-video
environment is just a bigger datastream but the bandwidth gets lumpy...so
better to ensure the bandwidth is properly considered. I am a bit of a
tartar when it comes to what name we give. If this is audio chat protocol
then I will shut up as it is a different problem domain.


> 
>> 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

No, you are really missing something - all the other people in the
conference! For 7 members it is 42 audio OUT channels buzzing around with
each client dealing with the mixing of the 6 they are listening to/being
sent - and do no assume that we have a windows system, and one that is
likely to have that ever-changing conveyorbelt of proprietary protocols from
'Dandruff Bill'.

[ I have combined replies as we seem to be having a similar problem here as
a p2p conf!] ;-)

Tim