SJVN Claims that SIP doesn't Peer and that XMPP doesn't Federate -- WTF?

Image via Wikipedia

"For example, Iptel, Ekiga.net, and ippi are all fine SIP networks, but if youre only on one of them you cant talk to other SIP VoIP users on the other two and vice-versa. The same is true of XMPP/Jingle networks, and, for that matter all the other VoIP networks." -- http://www.zdnet.com/blog/networking/beyond-skype-voip-alternatives/1061

Huh? SIP supports peering and XMPP supports federation. That means that different networks can talk to one another.

"No Extensions NecessaryBut what does SIP peering mean? Is there some new special protocol required for SIP peering? What problems does peering introduce that arent already covered by the existing specifications and products? Those are good questions. First and foremost, SIP peering does not require any new extensions to SIP. The ability to interconnect provider networks is built into the SIP protocol itself. There is a common misconception that SIP peering requires some kind of special profiling of SIP in order to provide interoperability. That is simply not true. SIP was designed to interoperate, even among implementations that support different extensions and capabilities. SIP networks are interconnecting today without additional extensions. SIP has built-in negotiation capabilities that allow fallback to a common baseline set of capabilities when there is mismatch between sides. As an example, SIP has an extension for preconditions (RFC 3312), which makes sure that a call proceeds only if a quality of service (QoS) reservation exists between the endpoints. What happens if only one side supports the extension? If implementations follow the specifications, they will correctly fall back to baseline operation without this feature. Now, some will argue that this is a problem. We need this feature to always be used between our networks! theyll say. The interesting thing is, the extension is implemented at the endpoints, not in the network servers. Thus, a SIP profile that mandates usage of the extension could not be applied to the SIP servers doing the interconnection. Fortunately, the SPEERMINT working group has recognized that SIP peering is not about SIP profiling. Its charter explicitly rules profiling as out of scope, in fact. So, if SIP peering is not about a SIP profile, what is it about?" --http://www.tmcnet.com/sip/0306/sip-columns-speaking-sip-0306.htm

Also:

"1. Introduction

XMPP Core [1] describes the client-server architecture upon which Jabber/XMPP communication is based. One aspect of such communication is "federation", i.e., the ability for two XMPP servers in different domains to exchange XML stanzas. There are at least four levels of federation:

Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed. Permissive federation was effectively outlawed on the Jabber network in October 2000 with the release of the jabberd 1.2 server, which included support for the newly-developed Server Dialback [2] protocol.

Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via Server Dialback, based on information obtained via the Domain Name System (DNS) and verification keys exchanged in-band over XMPP. However, the connection is not encrypted. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks. Verified federation has been the default service policy followed by servers on the open XMPP network from October 2000 until now.

Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in RFC 3920 [3] and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.

Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain.

The remainder of this document describes in more detail the protocol flows that make it possible to deploy verified federation, encrypted federation, and trusted federation. Protocol flows are shown for federation attempts between various combinations to illustrate the interaction between different federation policies." -- http://xmpp.org/extensions/xep-0238.html

Sure, they have to be turned on, meaning that Facebpook's XMPP doesn't federate, for instance, but most XMPP networks do, and it's the same for most SIP neworks. In fact, this is from Ekiga:

"Using the Ekiga.net SIP addressThe Ekiga.net service accept calls to its registered users without being registered to Ekiga.net. Just call the sip:user@ekiga.net address directly. " --http://wiki.ekiga.org/index.php/Peering

Peering and federation are the strongest selling points of SIP and XMPP. How could you miss them?

Am I misunderstanding you, SJVN? I hope so.




Personally, I'm waiting for a bunch of providers to step up and provide webmail / SIP / XMPP + social extensions all under one address.

Related articles
Beyond Skype: VoIP Alternatives (zdnet.com)