Skip to main content

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

  • From: Nitzan Nissim < >
  • To:
  • 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
with 289.
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....

Thanks,
Nitzan





From:   binod pg 
< >
To:     
,
Date:   18/02/2014 11:32 AM
Subject:        Avoiding DAR invocation for app initiated requests (Re: 
Meeting
            Notes)



Hi Nitzan,

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?

thanks,
Binod.

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
one
> 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
will
> 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
CONTINUE
> 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
stateInfo
> that holds this information.
> Another option is an API method like
> SipServletRequest.getOriginatingApplicationName() returning the name of
the
> 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
work
> 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
> beginning.
>
>
>
> A small comment about the JSR draft:
> 19.1.6 Routing Directives mentions 15.2 through 15.4. It should be
changed
> to 19....
>
> - Nitzan
>
>
>
>
>
> From:          binod pg 
> < >
> To:            
>  ,
> 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
that.
>
> - 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.
>
> thanks,
> Binod.
>
>
>





Meeting Notes

binod pg 02/06/2014

Re: Meeting Notes

Eric Cheung 02/11/2014

Re: Meeting Notes

Wei Chen 02/12/2014

<Possible follow-up(s)>

Meeting Notes

binod pg 02/13/2014

Re: Meeting Notes

Nitzan Nissim 02/13/2014

Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

binod pg 02/18/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

Nitzan Nissim 02/19/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

binod pg 02/21/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

Nitzan Nissim 02/22/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

binod pg 02/24/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

Keith Lewis 02/24/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

Eric Cheung 02/25/2014

Re: Avoiding DAR invocation for app initiated requests (Re: Meeting Notes)

Keith Lewis 02/25/2014

Re: Meeting Notes

binod pg 02/19/2014
 
 
Close
loading
Please Confirm
Close