[SIPSERVLET_SPEC-27] Put the SAR notion in the Prune List Created: 16/Jan/13  Updated: 26/Mar/14

Status: Open
Project: sipservlet-spec
Component/s: None
Affects Version/s: next
Fix Version/s: next

Type: Task Priority: Major
Reporter: deruelle_jean Assignee: binod
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For Vendors integrating with Servlet Containers on which they don't have control and extending them to provide Converged Containers, it's not always possible to have the ability to define a new SAR extension or the container might already use the SAR Extension (Service Archive by example).
Also the WAR Tooling can be completely reused and there is no addtional value in defining a SAR Extension



 Comments   
Comment by binod [ 26/Feb/14 ]

We discussed this in the EG meeting and there is no strong opinion on pruning SAR support from the spec. So, we decided to leave it in there in this version.

Note that pruning does not actually mean removing the support, it just mean that we are going to remove it in a future specification. So, this decision does not have serious impact on this version of the JSR. I will schedule this for a future revision of the specification.





[SIPSERVLET_SPEC-3] Overload Protection/Filtering Support Created: 27/Sep/12  Updated: 26/Mar/14

Status: Open
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: next

Type: New Feature Priority: Major
Reporter: jonbo372 Assignee: jonbo372
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Introduction

This is a proposal to add overload policies and a filter mechanism for JSR 359.

  • An overload policy based on resources managed by the SIP container such as number of active sip sessions, general memory usage etc
  • A low-level hook (filters) that provides a way to programmatically affect the decision making whether a SIP message should be further processed by the stack or not
    .

The purpose of introducing these mechanisms is to protect SIP Servlet applications from e.g. denial of service attacks and other spikes that typically can either bring down or seriously affect the performance of a SIP Servlet application.

Overload Policy

This feature is more for the system administrator than the application developer. Through performance testing and knowing the typical user scenario for a particular deployment, the sys admin can e.g. set the maximum number of sessions allowed before traffic is actively rejected. The overload policy could be configurable both per SIP Servlet container instance and for each individual application.

Support for Filters

The low-level hook (filters) would allow an organization to implement their own custom rules for how and when traffic is dropped at a more granular level. E.g., during a DDOS attack it may be hard to just block traffic based on IP (which may be more appropriate to do elsewhere anyway) but there may be traffic pattern that you can trigger on and block traffic based on that. In addition, filters must be chainable to allow for multiple policies to be in effect at the same time. These filters should be configurable per SIP Servlet container instance.

The idea of having chains of filters for requests is quite popular in many web stacks. E.g., the Python WSGI interface specification (http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface) allows for middleware commonly used to implement "filters" such as CSRF, cookie management etc. Similarly, Ruby has the rack specification (http://rack.github.com/), which provides hooks for implementing filters as middleware. Both of these technologies allows you to decide whether to forward the request up the stack, terminate it or simply log and silently drop it. Looking to the Java world, Tomcat has a concept of filters (http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html) and all their examples are about preventing various types of attacks. Most of their filters are direct ports for the Apache HTTP Server, which is another great example where filters are used to allow or block traffic based on some particular criteria.

Overall, filters are a well-known concept within the web world and it seems like it would be a good fit for a SIP Servlet Container as well.

Btw, the JAIN SIP reference implementation has a basic concept of this (essentially a single filter). See http://hudson.jboss.org/hudson/job/jain-sip/lastSuccessfulBuild/artifact/javadoc/gov/nist/javax/sip/SipStackImpl.html and the property gov.nist.javax.sip.SIP_MESSAGE_VALVE. The interface for the message valve is here: http://hudson.jboss.org/hudson/job/jain-sip/lastSuccessfulBuild/artifact/javadoc/gov/nist/javax/sip/stack/SIPMessageValve.html



 Comments   
Comment by binod [ 07/Jun/13 ]

Comment from Face2Face (Please see the overload section): http://java.net/projects/sipservlet-spec/downloads/download/f2fjan13/JSR359F2FSanFranciscoNotes.pdf

Comment by jonbo372 [ 03/Feb/14 ]

I believe the overall conclusion is that no overload policy per say will be introduced but rather a mechanism for implementing one according to the needs of a particular deployment could be useful. Today, there is no way to intercept a message before it hits the transaction layer. As pointed out in the description, the jain sip reference implementation has a mechanism allowing to intercept a message before any transaction/dialog mapping occurs, making it a more efficient way to process the message without consuming too many resources. This would allow an application developer to build their own overload policy, which simply could drop the request or whatever it wants to do.

Comment by binod [ 26/Mar/14 ]

As per the EG meeting, EG opinion was divided on whether it is possible to implement a portable Filter/Interceptor that work for all containers. We decided to postpone this to a future release taking into consideration the relative priorities of the tasks.





[SIPSERVLET_SPEC-15] SIP TImers Configuration Created: 25/Oct/12  Updated: 26/Mar/14

Status: Open
Project: sipservlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: next

Type: New Feature Priority: Major
Reporter: deruelle_jean Assignee: binod
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Allows for applications to set a timeout on 1xx responses as JSR 289 defines a timeout only for final responses : By example If a user decide trying should be received in 1 sec, he can configure this so failover to another agent won't wait 10 sec for final response

Discussion prompted in adding more than just 1xx timeout for proxy and allowing for applications to configure SIP Timers



 Comments   
Comment by binod [ 26/Mar/14 ]

EG discussed whether this is important to be handled on a per application basis. EG members did not observe specific usecases for this. Considering the relative priority of the tasks, we decided to postpone this to a future release.





Generated at Wed Apr 01 00:07:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.