Subject: RE: [SIP] First cut review of Session Timer draft.

From: Steve Donovan <[email-masked]>
Date: Wed, 9 May 2001 10:37:53 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 7:06 PM
> To: [email-masked]
> Subject: RE: [SIP] First cut review of Session Timer draft.
> 
> 
> > Comments referring to specific parts of the document are 
> prefixed with
> > (page:paragraph)
> > 
> 
> <snip>
> 
> > 3:4 - (Minor) I am not sure I see the value in pushing 
> > responsibility back
> > to a supporting UAC, if the UAC did not request the timer 
> in the first
> > place. Why not just let the UAS deal with it, if the UAS is 
> > the element that
> > wishes to use a timer? 
> 
> I agree.  However the text is mainly to deal 
> with proxies adding the "Session-Expires and 
> Require timer" for functionality that it 
> knows is supported by the UAC.  Hopefully 
> a UAS isn't requiring it of the UAC when UAS 
> is the one that wants it and could have done 
> it.

See my response to Ben's note.

> 
> > At least it might make sense to say 
> > that the UAS must
> > insert the Required header IF it wishes the UAC to handle the 
> > re-invites.
> 
> It does elsewhere in the document: 
> section 5.2 Case 1 and section 6 paragraph 2.
> 
> > 
> > 4:5  What happens if the UAC does _NOT_ include a 
> > Session-Expires header on
> > the re-invite? I assume everyone resets their timers with 
> the original
> > values? Or does timer processing cease?
> 
> Timer processing ceases unless re-added 
> by proxy or UAS.

No, the timer is not effected.  I have added wording to make this clear.

> 
> > 
> > 5:2 - Doesn't option of absolute time imply an assumption 
> > that all elements
> > have their clocks reasonably synchronized?
> 
> The Date header should be included to avoid 
> the date/time synchronization problem.
> 
> > 
> > 5:3 - Again, we need to allow elements to reject expirations below a
> > configured threshold.
> 
> I agree.  And if possible, lets allow the minimum 
> value to be returned with a standard format so that 
> the request could be sent again hopefully without 
> having to get the users and proxy admins involved 
> for success.
> 
> > 10:2 - How can a proxy know that it is the closes proxy to 
> > the UAC that
> > cares about the timer? Except in the trivial case where the 
> > proxy is the
> > closest to the UAC period, this seems problematic.
> 
> I agree.  The text should reflect that the first 
> proxy that receives the final response and wants 
> the Session-Expires to be honored should add 
> (if not present) the remembered Session-Expires 
> and Require header containing "timer".
> 

This is already there.  See my response to Adam's note.

> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 9 May 2001 23:46:08 -0400

> No, the timer is not effected.  I have added wording to make 

Last paragraph page 12 draft-ietf-sip-session-timer-04:
"Note that if the 200 OK to the re-INVITE has 
no Session-Expires, no expiration time exists for the 
session.  This can happen if the proxies and/or UAS 
change their mind about session timers, and decide 
they no longer wish to use them."

Please continue to require this renegotiation of
Session-Expires stuff in all re-INVITE combinations
for the following reasons.
1) A revived proxy can be aware of Session-Expires value.
2) A revived UAS that was required to perform session 
   extensions will know it needs to do so.
3) It allows the session timing to be 
   discontinued and the call still remain.
4) It requires the smurf that required small timer 
   values to stay in the picture if they want to 
   continue to require small values.