RE: [reSIProcate] FW: [Sip] RFC4028 - Session Timer Clarification
I committed a fix for the Session Timer implementation revolving around the
discussion in these emails. I also added the setting of the MinSE header.
-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Monday, May 16, 2005 2:24 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] FW: [Sip] RFC4028 - Session Timer Clarification
FYI - resip does not currently function this way for session timers. It
treats the terms UAS and UAC as if referring to the Invite Session. I plan
to fix this soon.
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx]
Sent: Monday, May 16, 2005 11:54 AM
To: Scott Godin
Cc: 'Jonathan Rosenberg'; sip@xxxxxxxx
Subject: Re: [Sip] RFC4028 - Session Timer Clarification
Scott Godin wrote:
> The refresher parameter is used to indicate if the UAS or UAC is to
> perform the session refreshes.
>
> Do the terms UAS and UAC refer to the Invite Session or to the
> particular transaction?
The terminogy is indeed confusing here.
> Consider the following scenario
>
> 1. Alice Invites Bob
> 2. Bob's 200 contains a refresher parameter specifying UAS (himself)
> as the refresher.
> 3. When Bob sends his session refresh message should it contain a
> refresher parameter of UAS or UAC - assuming he wishes to continue
> being the refresher?
>
> The RFC seems to indicate he should send UAC (2^nd last paragraph in
> section 7.4).
I agree that Bob should specify UAC to remain the refresher.
IMO the right way to think about session-timer is that every request
that could be a session-refresh-request terminates the old session
timer. Then it may or may not set up a new session timer. When doing so,
the refreshed is determined relative to the current request.
Paul
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel