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

[Richard Dobson]

> The "server" is just one of the users, it's all on the same JID, etc. This
> is ust to keep the protocol uniform and means that if you support 1 on 1,
> you also support 1 to many automatically. The only differences is that
> rather than having two "peers" with an equal role one is server and one is
> client.

It is still isnt really needed to "keep the protocol uniform", you still
havent explained why we cant design a protocol that works in both
client/server and full p2p with minimum overlap, just keeping on stating
that it will keep it uniform doesnt explain it.

> >> This allows 2 people to have a conversation through a direct
connection.
> >> One is clearly the server, and the other the client. Wether this still
> >> matches your definiton of peer to peer I don't know, but it allows to
do
> >> what you want doesn't it?
> >
> > No not really, it is still placing an unnecessary requirement on one of
> > the
> > clients, its far better to have two separate modes fully p2p when
> > appropriate (when there is bandwidth available)
>
> Bandwith requirments will be *exactly* the same for both solutions.

I wasnt talking about bandwidth requirements, I was talking about the
general requirement for potensially more code (i.e. the client has to have
code for acting as a full server as well as a client) there are also the
processor requirements of mixing the audio in the server client to send out
to the other clients among other things. I was arguing that if the bandwidth
is available on all the clients there is no reason not for going fully p2p.

> Any JID can assume the role of server, including your own. So any client
> can implement this (that's the point). As explained before, you will not
> need any components whatsoever. Indeed you're right, in corperations they
> might want that, and as a paid service too maybe. The beauty when you
> stick to this mode is that any client designed primarly for 1 on 1
> conversations can take part of this!

Yea and any JID can go fully p2p as well, any client can implement it too,
im not sure why you are trying to argue this fact other than the fact that
you can do it, I already know you "could" do it that way im not arguing
that, im arguing that it is not the best way to do it.

> Though below I see you're now entering the realm of using P2P modes for
> conferences, wich is another story..

Thats the whole point I am arguing for fully p2p, havent you realised that
by now?!?!

> > Now just because we have two separate modes
> > it doesnt mean we cant design a protocol which supports both modes of
> > operation, I dont know why you seem to think to have a common protocol
we
> > need it to only work in a client/server mode (wether there is an actual
> > server or a client is acting as a server). The main benefit I see if
> > fully
> > p2p mode will be that if someone gets disconnected from the net the rest
> > of
> > the people in the conference will still be able to communicate without
> > interuption, but with your method of the client acting as the server for
> > the
> > conference if that goes offline no one will be able to chat. The Xbox
> > live
> > voice chat seems to work p2p with silence detection and works fine with
> > as
> > many as 20 people in the conference. Also the method of going direct p2p
> > will help to reduce latency which could also become a problem in server
> > hosted chats, SIP seems to work by establishing a p2p connection between
> > the
> > two endpoints too and the reason apparently for this is to minimize
> > latency
> > which in voice chats can be very noticable.
>
> And I think we all agree that most needed modes are 1 on 1 without the
> need for any intermidiate server and as little trouble as possible with
> NATs/Firewalls, and conferencing with a single stream to a central server
> that mixes the audio.

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.

> Not that conferencing with multiple connections isn't intresting, but that
> could be done as an extention on top of this.

My point is it doesnt need to be an extension and can and should be built
into our signalling protocol from day one, you still also havent provided
any credible benefits that outway p2p's benefits.

> Not when, like in all the examples I gave for 1 to 1 so far!, your own
> client is the server. However, using a client / server model will make it
> easier to integrate remote management into the protocol.

It will make it slightly easier but it is not really all that much harder
IMO at the protocol level to be able to administrate a p2p setup, it also
gives more power to the members of the group to control the conference as
well.

Richard