| # |
Problem |
Action |
Prio |
Status |
Open Issue No |
F2F discussion ? |
| 1. |
Invalidation of application session/session lifetime |
New proposal in separate ppt doc. or go back to JSR116 version with exception of adding is valid function. |
H |
RESOLVED |
1001 |
leave invalidate() semantics the same (forced invalidate) as it was in 116 earlier, invalidate(true) also is exactly the same. isReadyToInvalidate() query provides a polling mechanism. set/getInvalidateWhenReady(boolean). how do we register a SessionInvalidation event listener? will be specified. app composition may break if a session for an app in the already formed chain is gone. Send error response if that case arises. route req/resp w/o app involvement (applicable for proxies). stateless proxying of responses to be clarified. if a message arrives for an invalidated session ? reject (only logical choice) |
| 2. |
Deployment AR format |
Add simple config into JAR. Expose new method in the AR interface configChanged(InputStream) |
H |
TBD |
See 1002, 1005 |
To be discussed in F2F |
| 3. |
Many AR's |
Remove leads to confusion and is underspecified |
H |
CLOSED |
NA |
NA |
| 4. |
Path header not clear |
See note from list |
M |
CLOSED |
|
|
| 5. |
Proxy collocated with UAS |
Do not deprecate, add that getProxy() must be called before send e.g. 180 as UAS. |
M |
RESOLVED |
1012 |
Needs to be described by us but got accepted. |
| 6. |
SipFactory create session with a key. |
Add to API |
M |
CLOSED |
|
|
| 7. |
Security DTD changes |
Underspecified |
M |
TBD |
1016 |
Avaya investigates rfc4474 |
| 8. |
Describe the P-Asserted-ID handling |
Security framework should check if trusted |
M |
TBD |
1016 |
Proposal 2 voted with remark to not have passerted indication as an attribute but as an element inside. |
| 9. |
ListIterator in SSAPI |
(See 5.4.1 AddressHeaders). Can we state that the optional methods add(),remove(),set() are not implemented |
M |
TBD |
1026 |
|
| 10. |
Add doBranchResponse call back. |
Improves coding style |
L |
RESOLVED |
1027 |
We need to write up a proposal and consider any multi-threading cases |
| 11. |
Set outbound what should happen and who is responsible for the choice between sip and sips |
Clarification needed |
L |
TBD |
|
|
| 12. |
Proxy acting as a UAS for subsequent request, 10.2.9 last paragraph. |
Clarification needed |
M |
TBD |
|
|
| 13. |
B2BuaHelper.getPendingMessage() |
Huge memory penalty, need to keep reference to all messages |
L |
CLOSED |
|
|
| 14. |
Asynchronous/delayed proxyTo() or send() in a servlet.timout() method |
Should this be supported |
L |
RESOLVED |
1018 |
Accepted |
| 15. |
11.3 should we support merged request |
Clarification needed |
L |
RESOLVED |
|
Discourage in the spec |
| 16. |
Inconsistent 5.4.2 and javadoc: getAddressHeaders throws IllegalStateException and 5.4.2 throws IllegalArgumentException |
Adjust |
L |
TBD |
|
|
| 17. |
Implement same functionality for Parameterable Header Fields as for Address Header Fields (5.4.1) ? |
Shall modification of Parameterable objects modify underlying message? Clarification needed |
L |
RESOLVED |
Accepted, text to spec will be added |
|
| 18. |
Javadoc for getAddressHeaders and getParameterableHeaders missing info about what to do when request not include the requested header. |
Add information to javadoc similar to information in getHeaders. |
L |
TBD |
|
|
| 19. |
if getRouteModifier returns ROUTE, and getRoutes() returns an array of routes (strings), in what order should these routes be pushed on to the request? |
Add order (element 0 pushed first?) |
H |
TBD |
1010,1011 |
Not in the list for F2F discussion |
| 20. |
ROUTE Back should be added to SipRouteModifier |
Follow up |
M |
TBD |
1007 |
Not in the list for F2F discussion; we can ping the SLs to see if they have accepted it. |
| 21. |
B2BuaHelper.createAck()/createCancel() |
Missing method |
M |
CLOSED |
1052 |
Use getPendingMessages() examples in the spec to come... |
| 22. |
SipSessionsUtil.linkSession()/ getLinkedSession() |
Missing methods. use SipFactory createApplicationSessionByKey() pattern. |
H |
CLOSED |
|
|
| 23. |
Should stateInfo be stored as Object or as Serializable? In E/// implementation, SipServletRequestImpl stores stateInfo as Object, whereas JSR states Serializable. |
Use Serializable everywhere |
M |
CLOSED |
implementation detail, only useful with HA and recovery on transaction level or in cases of upgrade/hot swap. |
|
| 24. |
If JSR289 applications need to share state, where should they store it? ApplicationSession is limited to one app only, and possibility to access EJBs from a SipServlet has not been standardized. |
Standardize EJB access from SIP servlets, or introduce the notion of a CompositionSession. |
H |
Not for this release |
|
|
| 25. |
What's the purpose of having a SipApplicationRouter.init() method, when we already have SipApplicationRouter.init(List<String> apps) ? |
remove from spec and allow null-list |
L |
TBD |
|
|
| 26. |
The EDR specifies the SipApplicationRouterInfo.getRegion() method, which should return one of the SipApplicationRoutingRegion enum values. However, there is neither a setRegion method nor a constructor with a region parameter. How should theSipApplicationRouterInfo know what region to return |
Add setRegion() method and add SipApplicationRoutingRegion argument to constructor |
H |
CLOSED |
|
|
| 27. |
15.2.2: what kind of application is CW? B2BUA? Proxy? Same question for 3WC. |
Add more implementation details about the example applications. |
? |
TBD |
|
|
| 28. |
15.9.4: if Alice activates 3WC to call Bob? Explain HOW Alice would typically activate 3WC! Is this a webrequest? It should be clear that the 3WC activation does involve additional SIP signalling that might clutter the chain. |
add info |
? |
TBD |
|
|
| 29. |
15.2.2: The text mentions the deprecated method SipFactory.createRequest(SipServletRequest origRequest, boolean sameCallId). |
Remove |
? |
RESOLVED |
New method without flag is added to B2BUAHelper to replace. |
|
| 30. |
15.9.4: in the example, when 3WC sets up a new call to Bob, which method should it use? we currently don't have one. the one we have ( sf.createReq(orig) ) is deprecated and we don't want to persist the complete original request. |
we may need a SipFactory.createSession(origSession).Discuss |
H |
TBD |
|
|
| 31. |
SipApplicationRouterInfo.getRoute() needs to be replaced by SipApplicationRouterInfo.getRoutes() |
? |
? |
TBD |
Same as 19. |
|
| 32. |
Some of the proposals in the JSR289 open issue list suggest the SipApplicationRouterInfo should return SipURIs, for example the getSubscriberUri method. This will however require that the AR has access to the SipFactory, and that in turn would introduce the need for annotation support in the AR. |
Discuss |
? |
TBD |
1009 ? |
Not in the list for F2F discussion |
|
| 33. |
What should happen with ongoing traffic when a application is undeployed? The assumption is that the behaviour is exactly the same as invalidating all the sessions and dialogs where the application is involved in. This is a reason for implementing a better invalidation strategy as described in point 1. |
Describe undeployment as invalidation of all sessions |
L |
TBD |
|
|
| 34. |
We currently use the DataCentricRouting concept in a cluster environment to ensure that the requests are routed to the correct instance. Therefore, we assume that any access to the SipApplicationSessions can be handled by the local instance (barring after failure cases). This means that current sailfin does not support what we call true out-of-band access, where the SAS is accessed from a non-DCR routed request, e.g., EJB or non-DCR routed JCA. Any attempt to access the SAS from such a scenario will fail most of the time. The alternative is to provide remote access to the SAS or to migrate the SAS data to the instance where it is requested. Both alternatives are expensive. |
Try to avoid a cluster distribution scenario where the DCR scenario does not fit |
L? |
TBD |
|
|
| 35 |
Inconsistent Usage of IllegalStateException |
The problem is that 116 has not been consistent in throwing an IllegalStateException where al it might happen. Should that be remedied in 289? |
L |
RESOLVED |
1059 |
Since 289 shall not introduce incompatibilities we will make sure only new APIs ill throw ISE. Old inconsistencies shall be left alone. |
|
| 36 |
Per Pettersson: createApplicationSessionByAppName(AppName), *ByKey(Key), *ByAppNameAndKey(Name,Key) |
|
