At first, choosing between SIP and Jabber seems to be something of a dilemma.
Both protocols offer a rich set of features, are supported by a wide range of software and are publicly documented in open specifications advanced through the Internet Engineering Task Force (IETF)
Jabber has slightly more features for IM, e.g. chat rooms, and it is based on XML, which some people see as a benefit. Jabber is the standard for the world's largest federated IM platform, Google Talk, and it is also supported by Facebook.
In contrast, SIP is based on sets of header/value pairs that are very similar to those used in SMTP email and HTTP, making it easy to understand and troubleshoot. It has been implemented in a vast number of hardware phones, including the market leaders from Polycom, Cisco and Linksys. MSN is based on a variation of SIP (like all Microsoft solutions, MSN doesn't strictly adhere to the public standard).
The user perspective
Any software engineering problem should surely start with an analysis of the user requirements:
- The user probably already has an email address and would like to use this as a single identifier for any new protocol: both SIP and Jabber tick this box
- For 90% of users, when they see the email address of a friend or business contact, they will have no idea whether it is a SIP or Jabber address. They will be frustrated if 50% of their attempts to make a call require them to try a second phone (e.g. a SIP phone first, and then they try calling from a Jabber phone). The user will be even more frustrated if they only have one type of phone and they simply can't call the other type of addresses at all.
Three options are apparent:
- Just use SIP, and hope Jabber goes away
- Just use Jabber, and hope SIP goes away
- Support Jabber and SIP
In fact, the third option, embracing both technologies, is the solution that is recommended.
What does it mean in practice?
The fact that both protocols use the same identifier - often the same as the email address - is extremely convenient. Users don't need to print business cards cluttered with multiple addresses, for example.
Much of the infrastructure for the two protocols can also be shared:
- Both use RTP for voice and video, so it is easy to route a phone call from a Google Talk (Jabber) customer to a SIP phone in a call centre, via a SIP-Jabber gateway. The gateway needs to make no extra work to translate the audio/video streams.
- The common use of RTP often means that similar firewall settings are used to support both protocols.
- Both protocols use the same type of X.509 certificates for security, so after the certificate has been purchased for a SIP server, there is no need to go and buy another certificate for a Jabber server, the same one can be used for both.
- Both protocols can be advertised in an ENUM service, and if a caller only supports one or the other, the call will get through.
- The DNS SRV records (used like MX records for email) can be created for multiple protocols (both SIP and Jabber) without any conflict between the two.
- The convenient im: URI prefix can be used to specify a protocol-independent chat address on web sites, e.g. instead of creating two web links, sip:email@example.com and xmpp:firstname.lastname@example.org, you can create a single convenient link im:email@example.com
In fact, it is not a choice between SIP or Jabber: both can be used. What we have revealed is that there are compelling reasons to support both protocols (for user friendliness and to have the widest possible reach), and that there is virtually no conflict between the two protocols if operated concurrently.
Consequently, the OpenTelecoms.org community doesn't make any bias in favour of either protocol and anyone aiming for full Federated VoIP is encouraged to support both.