|
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. Scenario A: * tcp and udp sessions are already possible through 95/65 combination * codec independence is given Scenario B: * rtp is on a higher level than tcp/udp * jacek asked, should jabber be some sort of control protocol or just an application launcher? * 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 implementations around. the rtp approach is fairly easy to implement, depending on the used library. I hope the ascii art get's through. *JABBER SERVER* | | *RTP RELAY/COMPONENT* / \ [RTP] [RTP] / \ / \ *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 through UDP. 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. u Jacek Konieczny wrote: On Wed, Mar 03, 2004 at 10:57:14PM -0600, Thomas Charron wrote: |
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
