[jdev] voicechat again

[Thomas Charron]

> RTP is a protocol to send multimedia streams via unreliable
> transport protocol, like UDP. JEP-65 is a protocol to establish reliable
> (TCP) connection between two Jabber clients. There is no conflict here.
> TCP connection may be used for voice and _existing_ Ogg stream format
> may be use for this. Using UDP whould be much better, so we need some
> kind of protocol to establish UDP link between two Jabber entities. RTP
> doesn't provide that. But RTP may be used as soon as those clients can
> communicate via UDP.

  Once again, JEP-95 provides a way to do all of it.  JEP-65 is
specifically to allow a connection of a binary stream over TCP.  Making
another enhancement would now provide 3 solutions, one generic, one for
TCP, one for UDP.

  To open an RTP stream, this provides all the data you need.

  rtp://224.44.45.46:8888

  That's it.

  I'm merely using RTP as an example, do to the fact that people seem
familiar with it here.

> IMHO existings standards like RTP, OGG or speex should be used at low
> level to encode/transmit actual data, but higher-level singnaling has to
> be a new XMPP-based protocol unless we want our Jabber clients to be
> just external voice-communication-application launchers. And XMPP
> infrastructure seems very well suited for voice chat/multimedia
> conference signaling. IMHO even better that H.323 or SIP - which may be
> good for IP telephony, but not for PC-to-PC communication.

  Yep.  What we're talking about it HOW to signal the start of a stream. 
The existing JEP-95 does that.  It ends up telling a client, 'hey, open
up this, and here's the mime type.  If the client can handle the mime
type natively, hey, BY ALL MEANS.  Typical eb browsers don't use an
external application for http or ftp, but WOULD for rtp.  But if they
have a plugin or something that can handle it natively, then, by all
means.

  All the information is there already.  That's the point that has caused
frusteration.

  But hey, it's an open world.  Submit a JEP.