Home > Java, SIP, Telecom > SIP in Java: API wars

SIP in Java: API wars

Update: this article is obsolete. For a discussion of JAVA APIs for SIP look here

SIP is useful protocol, and it is open. So, lots of implementations are available for different programming languages. But in Java there is a principle “write once, run anywhere”, which means that “single API for them all”. Sometimes APIs are commite-developed, sometimes the first available API becomes the standard. Right now there are two public APIs for Java: JAIN SIP API and SIP Servlet API. This article will not focus on political questions around these APIs, but rather on techical things.

JAIN SIP API was historically the first. It specifies that application must manually control how message is passing through all SIP layers. Then incoming message is received, then application is notified, then if nesessary it must create a server transaction for this message, then if nesessary it must create a dialog based on that transaction. Of course, they later added option for “automatic dialogs”, which specifies that all these steps are executed by stack itself, but this is just for convenience. This manual control is gives applications great flexibility, because applications can implement their own transactions and dialogs. The only non-replaceable parts are transport and parsing layer. Another feature of this API is that access to all headers is specified through dedicated interfaces.

As I already said, the best thing about this API is that it doesn’t force its dialog and transaction facilities on you. However, it is still a framework, not a pure library, because all parsing and transport layers are hidden from you. You can’t control threading model of stack, so, for example, you can’t remove listening point without stopping whole stack. You can’t use your own network facilities, for example for non-blocking IO. You can’t have your own implementations for messages. And you can’t parse a message in application. Stack hides too much here.

Are those mistakes possibe to fix ? Sure:
1. Add method like processIncomingRaw() to stack, which will accept raw network data (I prefer ByteBuffer, but could be also byte[]), remote address and local address. This will allow you to use your own network layer and threads.
2. Extend message factory with methods for parsing a message. As source I think it should take CharSequence and ByteBuffer
3. Support for CANCEL is very bad. You should have your own storage for INVITE server transactions, so you can find which transaction is being cancelled. Access to transaction storage should be available, and stack also should itself search for INVITE transactions in its storage. Interfaces for client transactions and server transactions should have special child interfaces for CANCEL transactions.
4. Method getValue() should be present in Header interface. Now it is only in ExtensionHeader interface. This makes it very hard to write a general header copying procedure.

Now let’s take a look at SIP Servlet API. It is just a part of SIP Servlet spec, which introduces much more restrictive framework. Servlets are just a components to handle business logic, and everything is driven by container. This API tries to make illegal things (from SIP point of view) impossible, but it means that this API must provide all possible legal functionality itself. Access to transaction layer is hidden, but there is a default UA facility and special proxy facility. So, the approach is “everything nesessary is here, and you must use only that”.

Restrictive nature of SIP Servlet API means that it is impossibe to build JAIN SIP API wrapper on top of SIP Servlet API. But it is possible to implement SIP Servlet API implementation on top of JAIN SIP API.

So, what do we have ? One enterprize-level middleware model with easy but restrictive API, and another library-like framework which allows almost everything. Both APIs have implementations, and these implementations aim server market, because Java is not popular in desktops. JAIN SIP API allows you to take existing implementation and adopt it to your server product. SIP Servlet API shows you which API should your server product expose to make components simple and restricted from most “dangerous” actions. If your customers are vendors of application servers, and they build on top of your code, then you should provide JAIN SIP API. If you are yourself a vendor of application server, use SIP Servlet API, or, at least, design something similar.

But oth APIs are far from being perfect. There are some other APIs, but they are based on those two. OpenCloud recently announced EasySIP API, which is complete rip-off from SIP Servlet API. However, both APIs have good ideas, and a better API could be designed based on these ideas. However, I think that this is unlikely, because even two APIs are too much for Java.

Categories: Java, SIP, Telecom
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: