WeSIP

From Wesip

Session management in a converged container is a little bit more complicated than in a typical HTTP application server. To begin, SIP applications are far more complicated than HTTP since incoming request can be proxied forked and stablish several one-to-one communication links. On the other hand, converged applications can make use of several protocols in the execution of a service thus mixing different protocol sessions at a time.

Imagine a click-to-dial service. A user opens a browser from her laptop, goes to a web page and introduces the caller and callee address. The click-to-dial service calls to both parties and puts them together using 3rd party call control (3pcc) techniques while reporting the status of each connection through the web page.

Looking at the picture we can see two SIP dialogs backed by two SipSessions and one HTTP connection with its corresponding HttpSession. The three of them with their own data. Despite those three sessions are independent from a mere protocol point of view they are related to each other from an application perspective.

The application session (SipApplicationSession for naming reasons but don't let the 'Sip' prefix confuse you) comes to represent such a concept. It represents an application instance and aside from storing references to all the protocol sessions (HTTP and SIP) it can store application data itself. SipSessions can retrieve the SipApplicationSession by calling to their getApplicationSession method. HTTP sessions do not have such methods (hope they will in a future where SIP Servlet and HTTP Servlet specifications are merged) so nowadays the best thing you can do is place a reference to the SipApplicationSession as another HttpSession attribute with the name of your choice.

<< SIP Servlet LifeCycle and methods | SipSessions and dialogs >>