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

[Richard Dobson]

> I would suggest still using the c/s model as a basis for the spec, since
> you can use as the basis for person to person over a direct link, person
> to person via a server, conferencing over direct links (with each "peer"
> acting as server, as described in an additional spec) and of course,
> conferencing on a server.
>
> However, it should also allow for an additional spec where there is more
> than one server hosting the conference.

This is what the base spec needs to be IMO, a hybrid server and p2p
mechanism to solve both sets of requirements/problems, IMO there is no point
in creating this if we are not going to solve both sets of problems with a
single spec, there is no point in having things in additional specs.

> There's different approaches you can take for this, you could create a
> persistant network of "public" "supernodes", but this ofcourse brings it's
> security issues (since you can't encrypt if there has to be mixing on the
> supernodes) or you could create a network of "supernodes" for each
> conversation.

All you need is for the people who have the bandwidth, processing power, and
firewall/NAT traversal to act as the servers (p2p between the servers), and
the rest as clients of those servers.

> Unless you use client side echo removal (which ofcourse will put some
> extra burden on the client, what I'm indeed trying to avoid all along, but
> it's still a compromise). But agreed, this is one of the main advantages
> of using a direct link based conference. Again, you'll benifit the most
> (and the disadvantages will be the least obvious) if all clients have
> somewhat equal specs, while in most cases I doubt this is true for Joe
> Consumer.

Of course not all machines will have equal specs, but if they were bought
within the last 3-5 years they will likely be plenty powerful enough for our
requirements as far as CPU power goes.

> >> Ofcourse you still have to mix when you use DirectX ;)
> >
> > Playing two (or more) streams simultaneously is not mixing as far as I
am
> > concerned, so no you dont necessarly have to even mix.
>
> Ofcourse the streams are mixed, just by DirectX/ALSA/whatever instead of
> you. If your soundcard has some Direct X compatible hardware for this the
> soundcard can do the mixing. (Which is still true in many cases if you use
> a server that uses DirectX for mixing too)

But the point is that you do not have to manually code it and in so doing do
it in the processor, using such things as directx means it is far more
optimised and will take advantage of any sound hardware (or processor
extensions such as SSE) you have to accellerate this. This is in contrast to
server mixing that will have to be manually done in the processor as it
needs to be re-encoded and retransmitted.

> Then we both don't know ;) But most implementations probably won't be so
> advanced, if this is even possible (and you made a good point about
> re-encoding, which I more seriously doubt you can optimize much)

Yes the real problem is the re-encoding, not the mixing.

> > Because you will hear yourself echo from the other end, that is I
thought
> > what you meant, but overall I doubt syncing is something we really need
> > to
> > concentrate on or worry about too much.
>
> Out of sync mixing is *the* biggest annoyance about direct-link based
> conferencing if you ask me. Escp. when participants have severly different
> connections. I find this unbareable to work with.

Fine but not all people find it as much of a problem as you do.

> > its a
> > modified version of your model where instead of having a single server
> > you
> > could have as many as possible which communicate with each other via
p2p,
> > but anyone who is incapable due to platform issues, bandwidth, CPU,
> > firewall
> > etc to act as a server itself connects to one of these servers, this
> > provides the benefit of more evenly load balancing the CPU/bandwidth use
> > of
> > the chat over several nodes rather than concentrating on one, provides
> > instant fall back to another server if one has problems or leaves, and
> > provides your primary benefit of being able to support dialup users or
> > simple clients like pocket pc's or people who cant go p2p because of
> > firewalls.
>
> I think my idea as decribed more at the beginning of this email and here
> are pretty much alike. Are you suggesting a persistant network or these
> servers (which is p2p I suppose) or a per-conference network? (which I'd
> rather just call clustering of the servers)

It would just be a per chat network automatically setup from the chat
participants.

> Do you feel such a system should be part of the "base" spec for (audio)
> conferncing or an extention? And what do you feel should be done for NAT
> traversel in person to person? In case you suggest a peristant network of
> these nodes is that what should be used for that?

I feel this must be part of the base spec, and I dont feel a persistent
network is needed, as far as NAT traversal goes the servers will need to be
able to full traverse the NAT or firewall they have, which can be done with
UPnP (Zeroconf ?), or manual setup by a knowledgable person, but we must try
to minimize that requirement.

Richard