[SIPSERVLET_SPEC-4] Clarify specific API in distributed environment Created: 04/Oct/12  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0-pr

Type: New Feature Priority: Major
Reporter: echeung Assignee: binod
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


It would be useful to mandate certain behavior if an implementation chooses to support clustering. For example,
SipSessionsUtil.getApplicationSessionById() should work across the cluster. Key based session targeting should work across the cluster. In case of
migration or failover of session from one container to another, how the attributes are restored should be standardized.

Comment by keith-lewis [ 05/Mar/14 ]

We agree that it should be mandatory for key based session targeting to work across the cluster.

We should however allow for topologies where the SAS is located on particular nodes in the cluster.

It would be good to have the following methods of the SAS always available.

  • encodeURI
  • encodeURL
  • getApplicationName

The first 2 methods only need access to the SASid.
The app name can be retrieved by the SipSessionUtil object.

To achieve this we could require that even when the full object is not available the container should supply a "skeleton" object which implements these methods.
All other methods could return a IllegalStateException.

To allow the developer to know whther it has the "real" object we can provide a new method on the SAS called isLocalSession() (or isAvailableLocally?)

SipSessionsUtil.getApplicationSessionById() should never return null - it either returns the skeleton object or a real one.

Comment by binod [ 26/Mar/14 ]

We had a discussion on this in the EG meeting.

In general, it is hard to get consensus on issues related to distributed environment. This is partly due to
the fact that the distributed environment is not well defined in generally in java space and sip servlets
in particular because of its asynchronous nature.

The conclusion was containers should have more flexibility in their topologies and implementation choices and is
best left for them to innovate.

Generated at Sun Jul 05 23:47:01 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.