Re: [reSIProcate] Client OutOfDialog request with OPTIONS method

[Dario Bozzali <Dario.Bozzali@xxxxxxxxxxx>]

Hi Scott,

Thank you very much for your feedback.

I have to admit that implementation using application timers seems quite easier to me, anyway I like your design that relies on ClientOptions and ServerOptions classes as OOD-specific handlers.

I’ll think about your suggestions and, if I decide for DUM changes, I will submit a pull request to dev list.

Best regards,

Dario

 

From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: lunedì 19 dicembre 2016 15.13
To: Dario Bozzali <Dario.Bozzali@xxxxxxxxxxx>
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Client OutOfDialog request with OPTIONS method

 

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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel