|<< Back to previous view|
[SIPSERVLET_SPEC-34] Requirement: abiltity to discover (also terminate) SipSessions that are related by forking (aka derived sessions) Created: 29/Apr/13 Updated: 05/Feb/14 Resolved: 15/Jan/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||binod and tomrstrickland|
Forking can lead to 'derived' SipSessions. The label 'derived' only really matters for the act of copying the parent session, as after that, all sessions should be considered to be equivalent: it does not really matter which session was the first, as what really matters is the final response to each session. If session 5 receives a 200 ok and the application wants to terminate the remaining sessions, then it which session is the original session and which are derived does not matter. So, a better label: sibling sessions.
The requirement: the means to discover sibling SipSessions for a given SipSession. Perhaps a method call SipSession.getSiblingSessions(): Set<SipSession>, returning empty set if there are none.
A secondary requirement: the means to terminate other SipSessions by calling SipSession.terminateOtherSipSessions(). This is a more complicated requirement: it is relatively straightforward in non-proxy scenarios, but in proxy scenarios all that we can do is to terminate such branches.
I will have more to add on this topic shortly: this is just an initial bug-report.
|Comment by binod [ 15/Jan/14 06:34 AM ]|
Current ForkingContext API in the draft currently distributed fixes this issue. Please see section 8.2.6 of the specification.
|Comment by tomrstrickland [ 05/Feb/14 02:53 PM ]|
I have been reviewing the Javadocs on ForkingContext and see a new method that seems to go against the originally agreed discussion:
The group had originally decided to have this set as NOT cloned by default for JSR-359 apps. I see also that section 188.8.131.52 Derived SipSessions also says that SipSession contents are cloned by default.
We had originally talked about whether or not this should be switchable at the application-level and/or the SipSession level. I think that we had originally agreed that this would be switchable at the application level, and would default to not cloning attributes if the application is explicitly at least a SipServlet 2.0 app.
|Comment by binod [ 05/Feb/14 04:37 PM ]|
Agree that, it is important to be able to switch it the application level. That is missing and we should
The method in ForkingContext is a nicety. Its a just a flexibility we can provide to the developer.
The default behavior: It might break the backward compatibility for applications ported from 289. But I see
|Comment by tomrstrickland [ 05/Feb/14 05:01 PM ]|
In this way: