实施SIP即时消息框架

Question

I want to implement an instant messaging framework working on SIP. I have SIP clients and an element that will get all the messages from the clients, and will handle them and forward them to other sip clients.

The clients and the managing element will have their own private protocol ("talking" with each other) that will be delivered inside the SIP messages (in the payload for example).

What I don't know is what I need the "managing element" to be. Should it be a SIP client, or a SIP server? What I was thinking is that I will have a SIP client that will receive all the SIP messages, parse them using the private protocol, and forward it to other clients. So it will be a kind of "server" in the terms on managing the system but a client in the terms of SIP.

I'm implementing this "element" in Java, but it doesn't really matter now. I will be happy to get some direction to help me.

Answer 1

With your problem, I would start by choosing between 2 models:

1- Your IM clients establish a session (SIP dialog) with the IM server (or dispatcher or "element" or whatever it is called) and keep it alive for as long as they are running, or signed in. In this case, the SIP dialog is always established from the IM client to the IM server, so the former can be called a SIP client, and the later a SIP server. IM messages are then delivered in both direction on that dialog, using mid-dialog requests. This is probably a good idea, if you know the IM server is routable from anywhere, but the clients are likely to be in private networks.

2- A more symmetric approach is that there is no ongoing dialog. Whenever either entity, IM client or IM server, wants to send a message to the other, then it just uses a one-off out-of-dialog SIP message. In this case, both ends need to implement SIP UA client and UA server functionalities. This could be a preferred solution in any case, when maintaining dialogs between IM clients and servers seems like a bad idea, but routing is not an issue.

Of course, there is a half way solution too, which looks like the second one, but instead of every message being sent on its own, out of a dialog context, a temporary dialog can be established to send messages (and avoid re-authenticating every single message for example) until some inactivity timer takes the dialog down.