< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Re: handling recoverable failures in dum


How about:

Have DUM decide if a retry is reasonable and call:
 int onRequestRetry only when it makes sense.

The return value -1, 0, N would be used as described below.

david


Quoting Fischl jason <jason.fischl@xxxxxxxxx>:

> After some IM discussion with Derek, I have some changes. Scratch
> previous proposal...
> 
> Add the following handler method to each UAC handler which would be
> called by the UAC in dum
> 
> // return 0 to retry immediately, return -1 to not retry. return > 0
> to retry in specified secs
> // if the app returns -1, the usage will go away. 
> virtual int onRequestRetry(InviteSessionHandle h, const SipMessage&
> response, int retryAfter);
> 
> The usage will call Helper::determineFailureMessageEffect(const
> SipMessage&) to determine if a retry is possible and will call
> onRequestRetry if it is.
> 
> There would be a version of onRequestRetry for InviteSessionHandler,
> ClientPublicationHandler, ClientSubscriptionHandler, 
> ClientRegistrationHandler, ClientPagerMessageHandler,
> OutOfDialogHandler
> 
> Jason
> 
> On Thu, 17 Mar 2005 18:31:27 -0800, Fischl jason <jason.fischl@xxxxxxxxx>
> wrote:
> > There are a number of failure cases that occur as a UAC that are
> > recoverable. e.g.
> > 
> > - send REGISTER, receive 503 with Retry-After: 30
> > - send INVITE, receive time out (possibly due to temporary network error)
> > 
> > I propose that when an onFailure Handler is called on the application
> > that the application have the ability to make a call on the BaseUsage
> > to retry with an optional future time.
> > 
> > // It is only valid to call this method from within an onFailure
> > Handler. If the app doesn't call
> > // retry, the Usage will be destroyed.
> > // This method should only be implemented on Client or Dialog
> > subclasses of BaseUsage
> > void
> > BaseUsage::retry(int ms=0);
> > 
> > It would be up to the application to look at the type of failure to
> > determine whether or not to retry.
> > 
> > Jason
> >
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>