[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Mon Feb 13 23:25:14 UTC 2006

Pedro Melo wrote:

> Hi,
> On Feb 10, 2006, at 8:35 PM, Akito Nozaki wrote:
>> XMPP protocol was not implemented based on AIM/ICQ, MSN, Yahoo  
>> protocol,
>> but got ideas from it. Why is Jingle<->SIP gateway so important but
>> gateway to these IM network wasn't as important?
> In terms of instant messaging, I think the future is XMPP. I consider  
> those networks legacy. And the only reason we keep a boat-load of  
> servers running pyMSNt here is a business decision, not a technical one.
> In terms of PC2PC, we prefer using XMPP only + ICE for NAT traversal  
> + RTP and Codecs. Our SAPO Messenger client is a dual-stack right  
> now, SIP and XMPP, using a commercial SIP stack, and I can tell you  
> that from our experience, it creates more problems than the time it  
> saves on implementation.
> In terms of PC2PSTN, we consider SIP to be the future *for now*.  
> Telcos (we are part of the portuguese telco, btw) use SIP, period.  
> They don't accept nothing else right now. So you need SIP, but not on  
> the client, just on a special gateway that translates what ever you  
> want to use on the IM network to signal voice and video to SIP. The  
> important part as we see it is to make sure the voice data is  
> interoperable directly, without transcoding.
> Why we prefer the server-side gateway? Simple (bad pun...): SIP is  
> complex, and not all SIP proxys we intereact with are exactly the  
> same. Some of them send some events, others don't. The problem with  
> that is the complexity the client has to have to deal with all those  
> SIP variations. Believe me, we have some of those here. So when ever  
> we need to tweak some code to deal with another SIP diference, we  
> have to deploy hundreds of thousand copies of our client. And then  
> some of our client, for whatever reason don't update all at the same  
> time (right now, our online users stats shows 10 different SAPO  
> messenger's versions....).
This is a viable argument, since we experienced some of this too ... 
However, isn't this where 'autoupdate' was invented for?

> If we push the SIP complexity to the server-side, upgrades to deal  
> with SIP stuff are very very simple, and with immediate benefits to  
> all of our clients.
> Our hope with Jingle is that it will cover some % of what SIP is  
> capable of, but that part is probably 100% of what we want to offer  
> on our client. And we get a XML schema to validate what we get from  
> the other clients/gateways. And I can dump the SIP stack and keep  
> only the RTP, ICE and Codecs.

> Our hope with libjingle is the ICE stuff, and probably the media- 
> control stuff. We are not going to use the XMPP parts most likely.

What do you do for signalling then? Or state? Or is this the 
'media-control' stuff? So if took a dim view (allow me :) you will trade 
something you have and works for an unkown of which you will not use 
most ... ?

> Please note: I'm not a technical writer or a protocol writer, and my  
> knowledge of SIP is still limited. I wrote this mail as someone who  
> has to keep a comercial XMPP service, with a VoIP client using dual- 
> stack SIP/XMPP, *and* has already a connection with PSTN working.
> Best regards,
> -- 
> HIId: Pedro Melo
> SMTP: melo at co.sapo.pt
> XMPP: pedro.melo at sapo.pt

More information about the Standards mailing list