[reSIProcate] Client OutOfDialog request with OPTIONS method

[Scott Godin]

Hi Dario,

Out-of-dialog requests by definition do not form dialogs, so there is no
real need to have increasing C-Seq numbers, since no far end should be
looking for that.  However perhaps you want to do this to be like other OOD
requests (ie: Publish or Register).

I've always just implemented timed OPTION pings using an application timer
and not worrying about sequential CSeq's.

As for implementing with DUM itself.  I'm not keen on the idea of assuming
that OOD requests have a concept that requires refreshing.  ie: Having a
refreshTime parameter on an makeOutOfDialogRequest API, is a little odd.
Since using OPTIONs for keepalive pings seems to be a pretty common
practice, I'm not opposed to adding a specific ClientOptions class (like
ClientPublication or ClientRegistration), and potentially a similar
ServerOptions handler.  In this case OPTION messages would no longer to be
handled by OutOfDialog handlers, they would go to the specific handler.
For backwards compat, we could have it fallback to the OOD handler if the
app doesn't specify a specific OPTIONs handler.  Then we could expose on
DialogUsageManager to makeOptionsRequest with a refresh parameter (an all
the other parameters).

Cheers,
Scott

On Mon, Dec 19, 2016 at 5:12 AM, Dario Bozzali <Dario.Bozzali at ifmgroup.it>
wrote:

> Hello,
>
> I was thinking about adding support in my application for timer-based
> refresh of client out-of-dialog request sessions created using OPTIONS
> method (for example to keep active a NAT binding or check status of a
> trunk SIP).
>
> At the moment it is possible to create a single out-of-dialog request using makeOutOfDialogRequest() method, but it not possible to ask DUM to refresh session.
>
> I think that there are two possible solutions to implement this scenario.
>
>
>
> First solution expects to store in application layer the message returned by makeOutOfDialogRequest() and in onSuccess() and onFailure() callbacks start an application timer (in onFailure method I could rely on Retry-After header if present in status message): on application timer expiration I need to increment CSeq header value of out-of-dialog request message and send updated message.
>
> Note that in ClientOutOfDialogReq::dispatch() method ClientOutOfDialogReq is deleted after onSuccess() and onFailure() invocation, so a new ClientOutOfDialogReq object  is created when status message is received for each request.
>
> The advantage of this solution is that I can implement it without changing DUM.
>
>
>
> Second solution relies on changes in DUM. I will explain some thoughts
> about it. I took inspiration from ClientPublication class, but I’m not sure
> that it could work.
>
> In my opinion I could change OutOfDialogHandler class adding the following
> two methods:
>
>  virtual int onRequestRetry(ClientOutOfDialogReqHandle, int retrySeconds, const SipMessage& status);
>
>                    virtual void onFlowTerminated(ClientOutOfDialogReqHandle);
>
>
>
> In ClientOutOfDialogReq class I could change dispatch(DumTimeout) method to handle request refresh:
>
>                    virtual void dispatch(const DumTimeout& timer);
>
> In dispatch() method I could invoke a new method:
>
>                    void requestRefresh();
>
> that increments CSeq and sends new OPTIONS request.
>
> To accomplish this I suppose that I could add OutOfDialogRefresh in
> DumTimeout::Type enum.
>
> requestRefresh() method can be invoked also in onFlowTerminated() to open
> new flow in case of error.
>
>
>
> makeOutOfDialogRequest() could be overloaded with an additional parameter refreshTime:
>
>  SharedPtr<SipMessage> makeOutOfDialogRequest(const NameAddr& target, const SharedPtr<UserProfile>& userProfile, const MethodTypes meth, AppDialogSet* = 0, UInt32 refreshTime = 0);
>
>
>
> In ClientOutOfDialogReq::dispatch() method, if refreshTime is not 0 I could start DumTimeout::OutOfDialogRefresh timer instead of deleting ClientOutOfDialogReq object (if sipMessage is a final response).
>
> ClientOutOfDialogReq is not deleted in dispatch() method if refreshTime is not 0 either on success or on failure.
>
> ClientOutOfDialogReq::end() method stops timer (if it exists) and delete object if we are not waiting for a status message: if there is a pending status message we have to wait it before deleting ClientOutOfDialogReq object (as it is done in ClientPublication class).
>
>
>
> In your opinions which is the best way to accomplish my target?
>
> Do you have better ideas or do you have implemented that in your applications?
>
> Is first solution (the simplest in my opinion) acceptable?
>
> Any suggestion or comment would be appreciated.
>
> Thank you in advance and best regards,
>
> Dario
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20161219/7736ea43/attachment.htm>