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

[Tijl Houtbeckers]

On Fri, 28 Nov 2003 03:42:44 -0000, Richard Dobson <richard at dobson-i.net> 
wrote:

>> No, one server will assume the role as "server". The client will ask
>> permission to participate with the conference on the server, sending an 
>> IQ
>> request etc. Then after permission SI will be used to create a two way
>> stream for the audio between the server and client. Ofcourse the server
>> will only stream it's own audio input to the client (no need to send the
>> client it's own input back) as long as there are only two people 
>> talking.
>> More isn't required, though I can imagine it'd be nice to have when you
>> have the power and bandwith for it.
>
> I still dont see the point of this, you dont need to require a server to
> design a signaling protocol that will work for server based and purely 
> peer
> to peer mode conferences.

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.

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

> and server based (when a
> server is available, which IMO will only normally be available in 
> corporate
> environments, or as a paid for service due to the bandwidth issues with
> hosting one of these servers).

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!

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

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

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

>> The benifit of it is, even if you can't host conferences yourself (for
>> example cause of bandwith etc.) even with the minimum implementation you
>> could still participate in them. Additionally the protocol could define
>> (perhaps just as an extention) a way to manage conferences (for example 
>> on
>> a jabber component) remotely. Then, even if I just have a pocket PC, I 
>> can
>> still set up a conference, decide wich people to let in / invite / 
>> reject,
>> password protect it ect. I can imagine x:data would be used for this (so
>> maybe just field standardization would do it).
>
> Remote management will I expect be a requirement for server based
> conferences, otherwise there is no way to manage it.

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.