A Mozilla-based Universal SIP Client

The goal of the Universal SIP Client project is to produce a cross platform application that can be used to establish interactive media sessions between two or more users.

SIP is an invitation protocol designed by the IETF. Each user is identified by a SIP URI that can be used to initiate an interactive media session. This SIP URI is designed to be similar to an email address and in some cases the scheme specific part of the URI can be identical for an email and a SIP address (e.g. mailto:marc@8x8.com and sip:marc@8x8.com).

As SIP does not defines the kind of media sessions that can be used, the Universal SIP Client will use a plugin mechanism to add new media type. The application will contain a basic set of plugins for voice and perhaps video sessions, but third-party developers can add new plugins for other interactive media types.

One example of a media session plugin would be for text sessions (aka instant messaging). The IETF is working on an instant messaging protocol named MSRP that uses SIP as invitation protocol.

Another example would be for interactive games. A plugin can be written for a chess game. A chess player using the Universal SIP Client with this chess plugin installed will be able to start a new game by simply entering the SIP URI of an opponent in a text field. There is no need to configure a server, or to send an email to exchange the parameters of the software. The opponent simply receives the invitation, accepts it, and starts to play.

Many other kinds of plugins can be written for existing and future interactive protocols.

One of the main feature needed for the success of this project is NAT traversal. The IETF is working on a generic NAT traversal framework named ICE and an implementation of ICE will be part of the Universal SIP Client.

The SIP working groups at the IETF are very active and already produced a lot of extensions for the SIP protocol. Like for Firefox and Thunderbird, it will be possible to write Universal SIP Client add-ons to implement these various extensions.

This application seems the natural continuation of the work done for Firefox and Thunderbird. Thunderbird implements the client side of a store and forward protocol for exchanging documents. Firefox implements the client side of a publication protocol. The Universal SIP Client implements the client side of an invitation protocol for interactive media sessions. Firefox, Thunderbird and the Universal SIP Client are complementary. E.g. audio and video streaming are not interactive media sessions and so are best managed by Firefox plugins rather than by Universal SIP Client plugins.

There are already some existing commercial and F/OSS applications that partially cover what the Universal SIP Client will do. The problem with these applications is that they focus on the media session part, and not on the invitation part. E.g. Windows Messenger uses SIP to establish a voice, video or text interactive session, but it is not possible to add a plugin to support games for example. In the F/OSS world there are already a lot of softphone [1] projects, but nothing close to the Universal SIP Client.

The Mozilla project is the ideal framework for this application. The main problem with all the existing SIP clients is that it is nearly impossible to find one that implements the IETF standards correctly [2], and so interoperability is very difficult. The Mozilla Foundation commitment to standards will be a big plus for this project.

Like for Thunderbird and Firefox, the Universal SIP Client is useless without a server. Thunderbird uses SMTP/IMAP/POP3 servers, Firefox uses HTTP servers. For the Universal SIP Client, a SIP proxy/registrar is needed to accept the registrations coming from the client, and to route the invitations to the right clients. Here also there are commercial and F/OSS applications already available.

[1]

Some examples:

[2]This is so bad that vendors are starting selling Session Border Controllers, a controversial network component that is, among other thing, meant to "repair" the bad behavior of these endpoints. SBC are controversial because they break the end-to-end argument.