Re: Meeting Notes (and the DAR)
- From: Keith Lewis <
- To: jsr359-experts <
- Subject: Re: Meeting Notes (and the DAR)
- Date: Thu, 20 Mar 2014 10:01:54 +0000
A correction regarding the DAR discussion. The note on the second school of
thought is incorrect.
I was advocating for the DAR to treat as a NOOP any request which is
"locally generated but addressed externally".
An "externally addressed" request satisfies BOTH of the following criteria.
1. The topmost route or (if there are no routes) the request URI is a
2. Either (a) there are no routes and the Request-URI is an external SIP
address or (b) there are routes but none was popped by the container
(poppedRoute == null).
A "locally generated" request is one with a NEW routing directive
originated by a local application.
This is found as point (1) of my DAR proposal.
The rationale behind needing the invoke the DAR for everything other than
those which are "locally generated but addressed externally" is :-
1. If the request has come from outside the container we must do
something with it.
2. If the request is to a TEL URI the SIP stack will not know how to
route it - we need the DAR to find an app to handle this.
3. If the request is addressed to an internal SIP URI then we need to
route the request to an app.
I was advocating for this behaviour since it allows very simple criteria in
the configured file - there is no need to confirm that it is an internally
addressed URI using a function in every chain.
As an alternative to hard-coding this logic we also mentioned the
possibility of adding a flag to detect whether a request is externally
addressed e.g. "support_externally_addressed". This flag could be either be
global and placed at the top of the file or could be local to a chain, the
flag would default to false since this is what is needed to protect the
The reason for removing the "support-locally-generated" flag is that when
it is set to false it expresses the rule that application can never process
requests that come from any local app irrespective of explicit routes
headers in the request.
This seems to be a strange thing to declaratively associate with an app, it
could easily need changing if a new app was added that DOES need to send
requests to the original app.
By contrast a "support_externally_addressed" flag is set true to express a
rule that a local application has a role in processing requests that have
no explicit route header naming this app as the "outgoing proxy".
From what Eric was saying this was a scenario envisaged by the JSR289 group.
It can be asserted irrespective of which other apps are present.
The email with the subject "Poll: DAR handling of locally generated
requests" does not reflect the decision I thought we are trying to make - I
doubt that anyone would vote for model (2) as currently written. Here is a
possible alternative wording
Questions for the EG:
In appendix C the current draft spec has the flag
1. Should we make available notion of "externally addressed" requests
and remove the "support-locally-generated" flag.
2. If you answer YES to (1) should this notion be used via (A) a flag
"support_externally_addressed" placed at the chain level (and defaulting to
false) or (B) via a boolean property "request.externallyAddressed" that can
be used in criteria or (C) hard-coded into the DAR so that requests which
are both locally generated and externally addressed will unconditionally
skip the rules and return a NOOP.
3. If you answer NO to (1) should (A) we keep the
"support_locally_generated" flag as documented or (B) replace the existing
flag with a property "request.locallyGenerated" that can be used in
If Option (C) in question 2 is used then apps must explicitly push a route
if they require the use of an "outgoing proxy" that is not already in the
routes of the request, this is recommended in SIP (RFC3261 section 8.1.1)
but not required in JSR289. Some JSR289 applications would need to be
modified to work with the new DAR.
Following yesterdays discussion and the arguments put forward by Eric and
others I am happy to withdraw Option (C) from this poll.
My vote is for 2 (A).
On 20 March 2014 04:24, binod pg
> Attendees : Tom, Eric, Jonas, Keith, Binod.
> - There was no further feedback from EG on sip/websocket discussion. In
> case of authentication, we
> will ask for a poll of EG.
> - We discussed supporting a flag in DAR configuration for skipping
> "locally generated requests". There were
> two school of thoughts. One is to let DAR and its configuration decide
> when the locally generated requests
> are handled or not. This can be achieved by adding a configuration flag
> in the chain level. The second is to let
> DAR never handle locally generated requests and application will need to
> push the routes if a new outgoing
> request need to be handled by the DAR. We will deciede on this based on
> a poll.
> - Next, we discussed Non SIP protocols. There is a general concern that
> this area is not discussed enough and
> hence should be left out of the specification. Binod will ask wider EG
> whether they are okay with leaving it out.
> - Tom has brought up the issue of multiple threads accessing the
> SipServletMessage (and even other objects) at
> the same time, if the submitted task contains a message from another SAS
> context. We decided that an appropriate
> guideline will be provided (eg: cloning the message) so that concurrency
> issues can be avoided.
> - Public review draft will be finalized by mid next week and then onwards
> no more changes will be incorporated in the
> draft. The draft will then go to internal oracle approval and will be
> submitted to JCP. Any bug fixes or small tweaks
> will be taken up after the public review.
Note: The information contained in this message may be privileged and
confidential and protected from disclosure. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and deleting it
from your computer. Thank you. CafeX Communications.