[Standards-JIG] Re: VoIP revisited

Cesar Martinez Izquierdo listas at ono.com
Wed May 4 18:10:59 UTC 2005


El Jueves 14 Abril 2005 07:23, Nolan Eakins escribió:
> Cesar Martinez Izquierdo wrote:
> | [1] http://users.evtek.fi/~k0400388/project/extract-project.pdf
>
> This is an effort that I would like to contribute or even spearhead this
> year. I've been studying SOCKS5 byte streams and the file transfer JEPs
> since I would like to leverage them to an extent. I haven't begun any
> writing, but since you're forcing this on me now I'll try my best.
>
> There are a couple of requirements that I would want addressed. Those
> are offline AV messages and encryption. Offline AV messages kind of go
> with push-to-talk voice messaging. The style is more like a CB or walky
> talky than a phone, and would be more inline with the style of
> communication that is instant-messaging where people handle more than
> one conversation at a time (yeah, this doesn't help our NADD).

(Sorry, I don't understand what NADD means).
Although I will not address encryption in my school project (because of time 
constraints), I find this topic very important, and we should definitively 
address it in the official Jabber specification.

Regarding the offline AV messages, I'm not sure if they are useful in the same 
way as text instant-messaging. In a text conversation, people is used to 
don't get a reply inmediatly. But normally, people interact in a quite 
different way inside a voice conversation. You usually expect to get a reply 
inmediately. (But maybe I'm just a bit blind to see a new way of 
communication).
On the other hand, AV messages seen as voice mail are quite interesting, but 
I'm don't think they fit in the kind of services that Jabber protocol is 
offering currently. It would require a lot of space and traffic on the 
servers, which is quite different to the current situation. Moreover, it is 
said that an XML protocol as Jabber is not suitable to manage big quantities 
of binary data.

> That's why I'm studying up on file transfer since this would in essence
> be done by sending sound or video files between to entities. That
> doesn't rule out real-time  streaming communication though since a user
> may want to do that, but the choice should be there and could possibly
> be done using the same compression schemes and wire format (streaming
> mp3s == mp3 on my HD).
>
> Encryption should also be an option whether now or at some future date.
> If we're going to be paranoid using SSL, e2e, and whatnot, we may as
> well go all the way and get that going on teleconferencing, file
> transfers, and everything else. Doing this may also have bit of a
> deadline too considering the nature of governments. This would depend on
> getting Jabber's e2e hammered down or say screw it and go with OpenPGP
> for everything.
>
> Your last requirement of no modifications to the server may not exactly
> be in the spirit of Jabber. My current thoughts are that a byte stream
> cache component would be needed for offline delivery (would work with
> file xfers too) and a SIP (or another protocol) gateway. Personally I'm
> of the opinion of keeping AV communication within Jabber clients as much
> as possible otherwise we face the possibility of compromising the
> integrity of Jabber by running a SIP client that can do IM too. In that
> case we loose and SIP wins.

I don't think we should think this as a battle of Jabber against SIP. SIP is 
out there working for VoIP phones. And Jabber is working out there for IM.
SIP has become a kind of de-facto standard for VoIP-PSTN gateways, and I think 
making the Jabber videoconference compatible with SIP is a good point to 
Jabber. Ignoring SIP would make us more weak, less succesful, not more 
strong.

If I can phone (using SIP) normal phones using my Jabber client that will be 
great. If I need a TINS/whatever-SIP gateway, and my Jabber server is not 
offering such thing, and my SIP provider is not offering this either, then I 
will need a separate SIP client, which is not making Jabber stronger at 
all...

Best regrads, 

 Cesar



More information about the Standards mailing list