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

[Tijl Houtbeckers]

I had a larger reply to this, but somewhere it got lost.

Using a client/server model has no heavyer requirments than a p2p based 
mode. Nor is it any complexer, but it will allow much easyer to 
participate in client/server based conferencing.

If you're argueing that, in the case of more than 2 persons talking, 
rather than client/server based conferences we should have this all done 
in p2p mode, I disagree. There's definatly cases where that is intresting, 
but the need is really for client/server, just like the real need for 2 
people talking is a direct connection (wether this is client/server or p2p 
based doesn't matter).

I also think building p2p based conferincing into the protocol from day 
one is unnecisarly complex, that should belong in an extention in any case 
then.

It's odd though, that you completly put aside the arguments you tried to 
make about 1 on 1 chat, when you talk about conferencing. Namely, limited 
bandwith (in the case of 20 people talking this would be almost 10 times 
as much as as c/s based) and lack of mixing capabilities (even if your 
pocketpc does have that much bandwith it'll have to mix 20 channels!).

On Fri, 28 Nov 2003 10:21:29 -0000, Richard Dobson <richard at dobson-i.net> 
wrote:

>> 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
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>