[standards-jig] Voice and Video over Jabber Networks

Joe Hildebrand JHildebrand at jabber.com
Thu Apr 3 18:29:58 UTC 2003


For 1), you can use TINS:
http://ietf.org/internet-drafts/draft-hildebrand-xmpp-sdpng-00.txt

For 2), you *could* use bytestreams, but voice and video really need to be
isochronous (packets get dropped if they can't be delivered with constant
latency), so TCP is usually not a great fit.  There are existing media
protocols that would work, like RTP (http://www.ietf.org/rfc/rfc1889.txt).
For most Jabber servers, you wouldn't want to do this sort of thing in-band,
because of karma restrictions, XML overhead, and added latency.

The general approach I'm seeing is:
- Use TINS to negotiate a media protcol, like RTP
- Use media protocol to pass data out of band to XMPP
- Use something like STUN (http://www.ietf.org/rfc/rfc3489.txt) for firewall
traversal


> -----Original Message-----
> From: evan at prodromou.san-francisco.ca.us
> [mailto:evan at prodromou.san-francisco.ca.us]
> Sent: Wednesday, April 02, 2003 1:36 PM
> To: standards-jig at jabber.org
> Subject: [standards-jig] Voice and Video over Jabber Networks
> 
> 
> Howdy. So, I'm pretty much dumb as a bag of carpet lint when 
> it comes to
> issues concerning transmission of voice packets over the 
> Innurnet, and I
> should probably just shut my trap right now. BUT, I think 
> voice is a great
> application for Jabber, and I think it'd be great to get 
> something working.
> So, I'm gonna stick my nose and my two cents where it doesn't belong.
> 
> It seems to me that there are two approaches to doing voice 
> (and video)
> transfer over Jabber networks.
> 
>        1) Use the Jabber network to exchange metadata and 
> pre-connect data
>        between two clients, and then use existing protocols 
> to do the actual
>        connection and data transfer.
> 	  
>        2) Use the Jabber network to exchange both metadata 
> _and_ the actual
>        voice data.
>        
> To my ignorant eye, these bear a lot of similarity to the 
> difference between
> out-of-band file transfer and in-band file transfer. But 
> that's just cause
> I'm dumb.
> 
> My suggestions for this problem are this:
> 
>        * People with interest in applying an existing 
> protocol to Jabber,
>          as in 1), publish JEPs for that application.
> 	 
>        * Some one or ones interested in doing something along 
> the lines of
>          2) publish a strawman JEP that can be a starting point for
> 	 discussion.
> 
> (If it were me, BTW, doing this second part, I'd probably suggest
> something like sending <message type="audio"> with an x 
> element containing
> a mime type and base64-encoded data, e.g.,
> 
>        <message type='audio'
>        		to='romeo at montague.net'
> 		from='juliet at capulet.com'>
> 	   <body>This packet contains audio data.</body>
> 	   <thread>balcony_scene</thread>
> 	   <x xmlns='jabber:x:audio' mime-type='audio/mpeg'>
> 	     adfaadfasdfasdfasdfkjglk==
> 	   </x>
>        </message>
>        
> Disco could be used to ensure that the receiver can handle 
> audio messages
> before sending. Of course, this is terribly simplistic, doesn't handle
> streams of voice data, or ordering series of related packets, 
> would require
> some way to negotiate appropriate mime type, etc. But, hey, 
> that's why *I*
> am not writing the JEP.)
> 
> Personally, I think the _worst_ thing that can happen is that 
> incompatible
> implementations hit the market. Bad for independent 
> implementors, bad for
> the Jabber community.
> 
> -ESP
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list