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

[Matthias Wimmer]

Hi Carsten!

Carsten Breuer schrieb am 2003-11-27 23:59:54:
> OK, but what is the situation if both clients are connected via a ISP.
> The dont have nothing tu do with NAT etc. What's the situation then.
> What is if one has a DSL-Router with a VPN behind (192.168) and the 
> other partner have a direct conection (ISP)?

I am not sure what you want or what the situation is that you try to
solve. I just wanted to say:
In case of using UDP, I don't see why an external reflector helps
crossing NATs. It's not as with TCP where you establish a connection and
the reflector can send back it's packets on this connection. UDP is
connection-less and an external reflector has still be able to send
messages to the client behind the NAT (doesn't matter if there are one
or both clients behind the NAT).

The only situations where I can see a benefit from using a reflector
instead of a peer to peer connection:
- The bandwidth of a client is not enough to send out all streams and
  the client is not connected to a multicast network.
- A client is not connected to a mulitcast network and wants to join a
  multicast conference.
- Two multicast networks should share a common conference.

I think it should be always the default to use peer to peer, as this
WILL help to introduce a mutlimedia protocol to Jabber. I don't expect
that there can be free public relays for Jabber, as multimedia would
cause many traffic that has to be paied by the reflector owner.
Where I can imagine that reflectors could be used is in company
networks, but there I can also imagine that it is better to setup
multicasting. It is maybe a bit more work to configure this, but it will
result in much better network performance afterwards. - And even Windows
95 is multicast ready.

If you try to solve the NAT problem it gets harder, I tried to explain
this in an other post. Best solution in this case is to use a proxy that
is capable of handling UDP packets, e.g. a special proxy for your
transportation protocol like RTP. But you don't have this on every NAT
router and you are not able to install it on all of them. The next
solution would be to use a protocol like SOCKS5, which can handle UDP
partly (externally using UDP, but TCP for the connection to the SOCKS
proxy). You can get the latency and timing problems of TCP in this case,
but as you only use TCP on the local network, you have a good chance,
that these problems are not as big as with a internet wide TCP
connection. The last fallback can be to use TCP connections, but you
have to add some additional logic than and can't just stream your audio
data over this TCP connection. This logic has to care for messurement of
the jitters in the stream and to report it to the sender. You also have
to detect stalled connections and have to try to replace such a
connection as fast as possible.
(One additional comment: TCP works for streaming of internet radio, as
the clients can buffer up some data before they start playing the stream
and therefore are able to use data from the buffer if a new frame from
the sender doesn't arrive in time. For voice conferencing and internet
telephonie only delays in the order of tens of ms are acceptable,
therefore you can't buffer much of the data, as already the encoding of
the frames can't be faster as the framesize (typically 20 ms), as the
frame can't be compressed before it is completly recorded.)



Tot kijk
    Matthias

-- 
Fon: +49-(0)70 0770 07770       http://matthias.wimmer.name/
HAM: DB1MW                      xmpp:mawis at charente.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.jabber.org/jdev/attachments/20031128/b1bb4a00/attachment-0002.pgp>