On 6/24/09, Ruadhri Howman <
ruadhri@xxxxxxxxx> wrote:
> 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/
>>>
>>
>>
>