[jdev] voicechat again
us at die-horde.de
Thu Mar 4 07:40:18 CST 2004
first of all, please change the font for this mail to a fixed width font
(due to the ascii sketch below)
I hope i don't miss anything in this mail.
* tcp and udp sessions are already possible through 95/65 combination
* codec independence is given
* rtp is on a higher level than tcp/udp
* jacek asked, should jabber be some sort of control protocol or just an
* i think xmpp should do the controlling and i think, there is no
split between control protocol and application launcher protocol.
* if we launch an application we can still control that application!
an RTP approach seems reasonable - there are many well working
the rtp approach is fairly easy to implement, depending on the used
I hope the ascii art get's through.
*CLIENT* <-----RTP----> *CLIENT*
+RTP LIB +RTP LIB
That's fairly easy and hands most media transmission problems to the RTP
libraries (thanks to matthias wimmer for consequently and always
pointing to RTP). Clients can exchange rtp data between them or rtp data
with a component. what needs to be done is the negotiation whether a
client A should send data directly to another B client or whether it
should send data to the server, who sends (in case of a udp connection)
in return the data to client B. Of course that way we would omit the
problem with UDP/TCP, since the rtp components would "know/test" their
transport mechanism between endpoints. through the relay on the server
it would be possible to even mix UDP connections and TCP connections
inside a session - means a server has session data and stores this data
either for pulling through TCP from a client or for pushing to a client
What we should take care of are rtp session parameters, a client should
be able to find out what sort of data a rtp session holds.
The jabber layer behind this architecture would then stop or start rtp
sessions and carry all those other informations about the session. Since
RTP is based on urls, we would just have to exchange URLs on xmpp layer
[for recieving/accessing and transmitting media]. RTP as well makes
authentication through passwords possible, which we can then exchange on
xmpp layer, for example [to proactively secure private sessions].
*Very important, the use cases are still the same ! *
Another argument for RTP is codec independence - we can transmit almost
everything with rtp, even chat data if it's required, it's just not so
well adapted ;-). RTP takes care of payload identification. Codec
independence means, RTP can handle OGG or speex very well, it's just a
question of the used library.
i hope my points get through. i'd go with rtp.
Jacek Konieczny wrote:
>On Wed, Mar 03, 2004 at 10:57:14PM -0600, Thomas Charron wrote:
>> JEP-65 is specifically geared twards opeing up a TCP socket to
>>communicate data. IMHO, anything that uses it is specifically 'jabber
>>oriented'. Utilizing it could be used, but the end solution is, by
>>nature, something that ends up running as a solution for the jabber
>>network. Using existing systems, such as rtp, etc, allows existing
>>applications alraedy BUILT to handle these things to funciton.
>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.
>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.
>jdev mailing list
>jdev at jabber.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the JDev