putting this into a compliance test is a very good idea. But I'd not go native streaming with one fixed codec, going compliant to RTP seems simply better - it's not reinventing like substituting a round wheel with an eightsided one ...Therefore, IMHO, we must require a Jabber AV client to support at least one specified codec to ensure this interoperability.
Once again, codec has nothing to do with jabber. We can suggest options, and in the end, chances are, no client developers are going to write thier OWN software to do things like RTP.
There is no _technical_ need to require a certain codec, but if you want Jabber to also succeed as a main stream platform, a common denominator is indeed necessary. For a non-geek user, the beauty of, e.g., Apple's iChat AV is that it just works: there is no need for the user to configure any behind-the-scenes technical details.
To allow Jabber as a platform to provide a similarly user-friendly approach, the client should be able to create a video-chat connection without requiring user intervention (beyond initiating the call, of course...). Which is hard to implement if it is not ensured that all Jabber clients support a common standard of AV signal. Of course, there is no reason why clients should not _additionally_ provide further codecs, as long as they _also_ support a common standard.
Actually, there may be no need to modify the protocol as outlined in JEP-0095 at all. Still, a specification of one common standard codec for use in Jabber-based AV sessions should be required. Why not simply put this into a compliance test, similar to the XMPP ones?
u
<http://www.jabber.org/compliance/TestDevelopmentOverview/overview.html>
GreetinX,
Jochen.
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
