[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:
> |  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
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
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
More information about the Standards