[jdev] voicechat again

[Ulrich Staudinger]

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:
>  
>
>>  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.
>
>Greets,
>	Jacek
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>https://jabberstudio.org/mailman/listinfo/jdev
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20040304/a87be6cf/attachment-0002.htm>