Subject: RE: [Sip] URGENT: session timer: new issues

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 17:10:16 -0400

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 5:04 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] URGENT: session timer: new issues
> 
> 
> 
> Suggestions:
> 
> 1) Deprecate forking -- solves the whole problem. Failing that, your
> proposal seems adequate.

Dean, we did take a consensus at IETF 51 to put this to rest once and for
all. As I recall, the consensus was to NOT deprecate forking, and therefore
we can avoid continuing needless debates on this subject. Since forking will
stay, I will integrate my proposal into the draft.

> 
> 2) Allowing a proxy to insert Session-Expires only in the 
> presence of a UA
> Supported header would solve the problem, but begs the 
> question of how to
> deal with clients that don't support or indicate support.

Right, thats exactly the problem. In this case, the proposal is to insert
Min-SE, so that the UAS effectively does what the UAC cannot - make sure
that the resulting session-expires is not less than Min-SE.

 Rather than
> allowing low-timer setups (as your idea of not returning 
> 422), this would
> preclude use of sessin timer if at least one UA doesn't 
> support it. 

Well, specifically, there would be no session timer unless the client
supports it. That is how session timer worked way, way, way back when, and
there was such a pushback against this, that I caved (I was a proponent of
not worrying about this case) and now we have this complex morass of
negotiation. 

> On the
> other hand, I'm not all that convinced we have this nut 
> cracked anyhow.

Can you be more specific?

> 
> It strikes me that we could have made this whole mess 
> irrelevant by making
> keepalives mandatory from the start and just using fixed (or 
> algorithmic
> with a standard algorithm) timers rather than negotiated timers.
> 

Debating what we should have originally done is pointless, and I'm not even
sure I would have put this in bis. I also think that the negotiated timers
will find quite some use, perhaps for things we've been arguing not to use
it for. Caveat emptor...

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2001 11:33:03 -0400

> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 8:53 PM
> To: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [Sip] URGENT: session timer: new issues
> 
> 
> > Issue #1
> > --------
> > My fix for this is that the client uses the max of the Min-SE 
> > amongst all
> > 422 in all responses for a particular CALL before any call legs are
> > established. Once a call leg is established, it uses the max 
> > of the min-SE
> > returned in all 422 responses for that call leg (i.e, with 
> > the same tag as
> > the 2xx that created the leg). As a result, when the call is 
> > accepted, the
> > max of the Min-SE is effectively "cleared", and then can be 
> > reset to the max
> > of the Min-SE on the path of the call leg. This seems to work fine.
> 
> Sounds good.

OK, seems like consensus on this one.

> 
> > 
> > ISSUE #2
> > --------
> > Another option (soln 2) is this. A proxy can insert both a 
> > Session-Expires
> > and Min-SE into the request. If a proxy sees a request 
> > without a Supported
> > header, but with a Session-Expires header below its minimum, 
> > it can insert a
> > Min-SE header into the request before proxying it (although it can't
> > increase the session timer). When this hits the UAS, if it sees a
> > session-expires with a value lower than min-se, it uses the 
> value from
> > min-se instead of the value in session-expires. 
> 
> Solution 2 sounds fine.  The same solution works 
> for when the UAS thinks Session-Expires was too 
> small.  The UAS would use its own Min-SE for the 
> Session-Expires instead of rejecting with a 422.
> 

Yes, that is true. 

I will take this to mean consensus on this issue as well. I'll update the
draft today and get it resubmitted with these changes. I think we are
finally done!

-Jonathan R.
---

---

From: "Padhye, Chinmay" <[email-masked]>
Date: Wed, 29 Aug 2001 13:25:32 -0700

Hello,

	I have a question w.r.t Issue 2 mentioned in the email below. 

	Consider the following case -

	UAC ---- P-A ---- P-B ---- P-C ---- UAS

	UAC - Does not support session timer.
	P-A, P-B, P-C and UAS supports session timers.

	P-A has a preferred session timeout of 15 minutes, 
	P-B has a preferred session timeout of 20 minutes and 
	P-C with a preferred session timeout of 25 minutes. 

1.	UA sends an INVITE to P-A. This does not contain any session-expires
header.
2.	P-A inserts a session-expires header - Session-Expires: 900 and
forwards it to P-B.
3.	P-B finds the value too small. But instead of sending a 422 it
inserts a MinSE with a value of 1200. (This is as per the proposed solution
to Issue #2)
4. The INVITE reaches P-C. P-C finds that the MAX(Session-Expires, MinSE) is
less than 1500. 

	My question is what should P-C do? 

a)	Send a 422 - Wont solve the problem.
b)	Add another MinSE. Is this allowed? 

Regards,

Chinmay

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, August 24, 2001 8:33 AM
To: [email-masked]'; Jonathan Rosenberg; [email-masked]
Subject: RE: [Sip] URGENT: session timer: new issues

Yes, that is true. 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Aug 2001 17:08:36 -0400

Responses inline.

> From: Padhye, Chinmay [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 4:26 PM
> To: 'Jonathan Rosenberg'; [email-masked]'; [email-masked]

It has to also increase the session-expires to 1200.

> 	My question is what should P-C do? 

Same as P-B. Increase Min-SE to 1500 (assuming that you are saying that
P-C's minimum is 1500) and also increase S-E to 1500.

> b)	Add another MinSE. Is this allowed? 

No, but it can increase the existing one. 

I have just submitted an updated version of session timer which incorporates
this new algorithm. It should appear shortly, but in the mean time, you can
pick it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-06.txt

Thanks,
Jonathan R.
---