Skip to main content

Re: Meeting Notes (and the DAR)

  • From: Nitzan Nissim < >
  • To:
  • Cc:
  • Subject: Re: Meeting Notes (and the DAR)
  • Date: Tue, 25 Mar 2014 12:34:45 +0200

I believe that the spec intention is that the applications composer should
not be aware of the location of other applications his app might get
composed with, or of the AR logic. The application should never have to be
rewritten for a change of composition to happen. The only thing the
application should do is to send the request to whatever destination it
think it should go, and use the directive NEW to hint  the AR it is playing
the rule of a UAC now, or CONTINUE to hint it is being a b2b/proxy. The AR
should still be able to do whatever it wants with the message routing.
Therefore a good DAR would be one that can do any kind of internal
composition or external routing, based on incoming/outgoing requests
headers values, by configuration alone.

A way yo achieve that is to let the DAR be configured to evaluate each
request coming or going out in a uniformed way. Something like:

If originating is [ application_name or null for externally incoming ] and
request meets [ criteria ] and
directive is [ NEW/CONTINUE ] then
proceed to [ application_name(s) / [route_set] / request_destination ]

The [criteria] could be composed the way the spec suggests today. In
addition we could add to the syntax "locallyRouted" as a property of
"request" or a property of a URI.
Looking at the directive set by the application gives the DAR further
freedom to decide how it would like to treat this hint from the app without
being forced by the spec.

If this is done this way, I don't see why we would need the flags
external_routing or support_locally_generated. The DAR could be configured
to do anything (including determine if a URI is local or a request is
targeted locally), and the app will never need to change or be aware of the
next application location.

We could still have chains style of composition in case the DAR cares only
about the first incoming request criteria, and then messages of next apps
in the path will follow the chain defined by multiple app_names in 'proceed
to' no matter what their routing is.

I think that this logic is both easier to implement and easier to explain.
It is also backwards compatible with existing 289 applications, since the
DAR could be configured to treat the directives (NEW vs CONTINUE) as the
legacy one did.


From:   Keith Lewis 
< >
To:     jsr359-experts 
< >,
Date:   20/03/2014 12:02 PM
Subject:        Re: Meeting Notes (and the DAR)
Sent by:        

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
naive user.

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
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 criteria.

     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).

Keith Lewis

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.

Re: Meeting Notes (and the DAR)

Keith Lewis 03/20/2014

Re: Meeting Notes (and the DAR)

Nitzan Nissim 03/25/2014

Re: Meeting Notes (and the DAR)

Binod 03/25/2014

Re: Meeting Notes (and the DAR)

Nitzan Nissim 03/25/2014

Re: Meeting Notes (and the DAR)

Eric Cheung 03/26/2014
Please Confirm