Richard Dobson wrote:
(1) Server forwards all control + data messages between clients, as it
does with IMs.
(2) Server forwards all control messages (throughput, voice establishment,
codec selection, etc.),
but data is handled in a peer to peer fashion. (Directly from one user to
another, optionally to
many others in emulation of a multicast voice reflector, if we're talking
about voice conferencing.)
(3) All control + data messages are handled in a peer to peer fashion.
All server does is give
each peer the other's IP address, and no more than that.
We should not really even consider (1) because escapsulating the voice data
and sending it via the jabber server just wont really work for voice chat as
that would produce serious latence that would make it virtually unusable,
but instead of that the better solution for server based mechanisms is to
have a third party server for relaying the voice data, like we have a
separate server for MUC. The only problem with this tho of course is that
not every server operator will deploy such servers due to the bandwidth
demands and such, and those that do might well charge for the facility, so
IMO having at least the option of doing voice data p2p is pretty much a
requirement, not just doing it all server based no matter what as has been
suggested by others in the past.
i agree. (1)/inband is not acceptable.
Richard
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
