Re: [reSIProcate-users] header(h_SessionExpires).param(p_refresher)

[Ruadhri Howman <ruadhri@xxxxxxxxx>]

Hi Scott,

I've been doing some tests and it appears that having the UAC as refresher works for what I want, so I'll leave it at that.

I'd prefer to put the burden of the refreshing on the UAS, but it's not a problem -- I guess that's my only use case for having the DUM set the refresher in the initial INVITE.

I'm still a little confused over the Profile::Prefer.*Refreshes -- it seems to me that without DUM actually sending a refresher in the initial INVITE, they're never used -- one always ends up with the UAS's choice.

Perhaps that's only because in my case I always receive a 'refresher=uac' in the 200 OK response to my INVITE.

Thanks for your help.

Regards,
Ruadhri.

On Tue, Jun 23, 2009 at 5:25 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

In section 7.1 it states

The UAC MAY include the refresher parameter with value 'uac' if it
   wants to perform the refreshes.  However, it is RECOMMENDED that the
   parameter be omitted so that it can be selected by the negotiation
   mechanisms described below.

Even though this paragraph mentions MAY for refresher=uac.  I don't think this is explicitly stating that it is illegal to send a refresher=uas - it is just not recommended. 

If you are sending the INVITE (UAC) the RFC is recommending you let the far end choose who the refresher is.  In your case the far end is choosing you as the refresher, and the DUM code is honoring that request.  In order to request that the far end is the refresher when sending out and INVITE you would need to add a refresher=uas parameter to the INVITE.  There is no current setting to ask DUM to do this for you.  We could add a setting if the use case is compelling enough.  What is your use case for wanting to do this?  You could also do this without modifying resip code, by using the MessageDecorator API's.

Scott

On Tue, Jun 23, 2009 at 11:27 AM, Ruadhri Howman <ruadhri@xxxxxxxxx> wrote:

Hi Scott,

Thanks for all of that.

I'm not sure how to get the system to behave as I want: which is to have the Callee do the refreshing.

I've had another read of RFC 4028, and I don't see how I can negotiate the refresher.

In section 7.1 it states:

   The UAC MAY include the refresher parameter with value 'uac' if it
   wants to perform the refreshes.  However, it is RECOMMENDED that the
   parameter be omitted so that it can be selected by the negotiation
   mechanisms described below.


(First, this implies that the UAC shouldn't set the refresher to 'uas'. So what I was doing last time was illegal anyway.)

In the "negotiation mechanisms described below", I couldn't see anything which said when it was ok to modify the refresher (unless one of the proxies/UAC/UAS didn't support it) -- only the Session-Expires.

Also, having removed the changes I described in my previous email, I've tried all four settings for masterProfile->setDefaultSessionTimerMode:
Profile::PreferRemoteRefreshes
Profile::PreferLocalRefreshes
Profile::PreferUACRefreshes
Profile::PreferUASRefreshes

And all result in the Caller (me) doing the refresh.

The response to my initial INVITE always sets the refresher to 'uac' so that may well be the expected and correct behaviour.

So, in summary, is there any way I can get the Callee to do the refreshing?


Thanks,
Ruadhri.

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/