Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)
- From: Nitzan Nissim <
- Subject: Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)
- Date: Wed, 19 Feb 2014 16:28:09 +0200
Yes, that would solve it.
I think though that this needs to be explained a bit more in the doc, not
sure if its clear what this boolean does.
I understand that "locally generated" means generated by that app (not in
this server), and so the default would be to send the message it generated
back to it. So that is probably the default for backwards comparability
What happens when its false? Would the chain continue from the next
application? I think this needs to be stated.
I find it also unclear what is the order of app selection. Is that the
order of writing it in JSON up to down, or does the value of state-info
affects it? The state-info in the DAR was something that always seemed
redundant to me, since it doesn't guarantee anything really....
From: binod pg
Date: 18/02/2014 11:32 AM
Subject: Avoiding DAR invocation for app initiated requests (Re:
In the current draft with EG, there is flag "support-locally-generated"
in the DAR configuration file.
Do you think that would work for this usecase?
On 2/13/2014 10:26 PM, Nitzan Nissim wrote:
> The issue I was rasing was the case of an application running as on a
> container that uses a DAR, which acts in some cases as a UAC.
> Even if this application needs to run in a chain of 1 app, it will always
> get the message it is sending out routed back to itself, which will be
> counter intuitive for most developers.
> An example could be an app defined in the DAR property file as the only
> to handle an INVITE, but it can also act sometimes as an INVITE call
> initiating UAC.
> Custom application routers can handle cases like this better, but they
> need to do the extra step of verifying if the INVITE came from outside or
> inside the container (as the directive will be NEW both cases)
> One possible solution is to default the directive in such cases to
> rather then NEW.
> The DAR and CAR will then recognize this case since the stateInfo will be
> null. This can be an indication that the chain needs to start from the
> request generating app onwards. For a DAR this will be easy to implement,
> in a CAR it depends on its logic and whether it can identify what is the
> originating application of this message.
> If a change of interface was possible, then I would suggest adding the
> information of the last application visited to the getNextApplication
> method, or pass it some other way to the AR, e.g. have a default
> that holds this information.
> Another option is an API method like
> SipServletRequest.getOriginatingApplicationName() returning the name of
> application that sent it (or null if it came in from the outside). This
> might be useful regardless for creating CARs, simplifying some of the
> they need to do.
> The other solution is to change only the DAR behavior in the spec to
> recognize the situation (differentiating external from internal generated
> messages) and make it resume the chain from that app, even though the
> directive is NEW. This is easy to do but then it might be confusing and
> doesn't let the application the flexibility of explicitly setting the NEW
> directive if they actually do want to start the AR sequence from the
> A small comment about the JSR draft:
> 19.1.6 Routing Directives mentions 15.2 through 15.4. It should be
> to 19....
> - Nitzan
> From: binod pg
> Date: 13/02/2014 09:18 AM
> Subject: Meeting Notes
> Attendees: Nitzan, Tom, Eric, Keith, Wei, Binod, Jonas.
> - We discussed Keiths suggested changes on AR. Decided that we need to
> keep the compatibility
> and hence the interface changes to SipApplicationRouter need to be
> avoided. EG is also of the view
> that the proposal should not introduce a concept of different
> application router versions.
> - Keith will make changes to the proposal such that the information
> returned from the getNextApplication
> cover the usecases presented. The update will make sure that the
> backward compatibility is maintained.
> - There was a discussion on whether it is appropriate for isInternalURI
> to be part of SipFactory. Keith
> will move the method to another appropriate place.
> - Nitzan brought up the need for not having to invoke DAR for requests
> created by applications in the
> container. We could not complete the discussion due to lack of time.
> Nitzan will send an email to the EG on this.
> - EG is fine with supporting SipInvocationScoped proposed in the public
> draft. We also decided to expand the
> support to SIP listeners, unless anyone have specific issues about
> - Thrupoint raised a concern about the complexity in implementation of
> SipApplicationChainScoped for the
> containers, which EG agrees with. We decided to drop
> SipApplicationChainScoped from the public draft.
> - Most of the EG members are fine with an extra meeting on Tuesday 9am
> for three weeks. We will start
> the extra meeting next week.