I keep seeing people posting examples where the UAC specifies the UAS as
the refreher. Why would you ever do this??? This only makes sense if the
UAC requires that a session timer be run, and that the UAC *can't* or
*won't* do it, and would rather have the call fail. This limits the
cases when a call can be successfully established. Why would you want to
do that?
Frankly, I can see no cases where either the UAC or the UAS would
require a session timer. It is proxies in the middle that might need a
session timer. A UAS can do a reINVITE or UPDATE to validate the session
any time it wants, without session timer.
And if for some reason the UAC wants session timer, I don't see why it
would presume to insist that the UAS be the refresher. It doesn't in
general know the capabilities of the UAS. I would think it leave the
refresher unspecified, thus allowing the UAS to choose based on its
capabilities.
Otherwise I agree with Raj.
Paul
Raj Jain wrote:
> On Fri, May 30, 2008 at 9:59 AM, <[EMAIL PROTECTED]> wrote:
>> Hi,
>> Considering that both UAC and UAS support Session Timer.
>> If UAC sends an INVITE request with the refresher parameter set as 'uas'
>> in the Session-Expires header, the UAS has to have Session-Expires
>> header with the refresher parameter set to 'uas'.
>> Now when the UAS sends an UPDATE, what will the refresher parameter be
>> in the Session Expires header?considering the fact that the UAS of the
>> initial transaction is actually acting as the UAC for the current
>> Transaction(sending UPDATE).
>
> The meaning of the refresher parameter applies to the direction of the
> current transaction. It is irrelevant whether the entity generating a
> refresh request was a UAC or a UAS in a previous transaction. In your
> example, if the entity generating UPDATE wants to remain the refresher
> then it should put refresher=uac in the UPDATE.
>
>> Will the refresher parameter mean the 'uas' of initial transaction or
>> will it keep changing with every Transaction?
>
> Putting referesher=uas in the UPDATE means that the current UAC (the
> entity that is sending the UPDATE) wants the recipient of the UPDATE
> to be the refresher.
>
> Here is a quote from section 7.4 of RFC 4028 that describes how this works --
>
> If the session refresh request is not the initial one, it is
> RECOMMENDED that the refresher parameter be set to 'uac' if the
> element sending the request is currently performing refreshes, and to
> 'uas' if its peer is performing the refreshes. This way, the role of
> refresher does not change on each refresh. However, if it wishes to
> explicitly change the roles, it MAY use a value of 'uas' if it knows
> that the other side supports the session timer. It could know this
> by having received a request from its peer with a Supported header
> field containing the value 'timer'. If it seeks to reselect the
> roles, it MAY omit the parameter.
>
> --
> Raj Jain
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
