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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Aug 2001 11:09:25 -0400

Folks,

I was in the process of updating the session timer draft, getting it ready
for IESG, when I happened across several additional issues. For one, there
is a reasonable solution, but the other is more serious and requires some
discussion. Sigh...

Issue #1
--------

The 422 response code allows a proxy to reject a request with a
session-expires which is too low. It includes a Min-SE header with the
minimum value that it is willing to accept. According to the current draft,
the client is supposed to insert the Min-Se header into an INVITE, and the
value is:

   the value MUST be the largest
   value amongst all Session-Expires values returned in 422 responses on
   that leg. 

This wording is imprecise, since a leg won't have been established when you
get a 422 to the initial INVITE. As I was rewording this, I realized that
you might get a bunch of 422's before the call is setup, from proxies that
aren't eventually in the path of the final call leg (because of forking,
primarily). 

Consider the case where A calls B, and there is a Session-Expires in the
INVIITE A sends, with value 50. THis hits proxy X, which forks to Y and Z. Y
returns a 422 with a Min-SE of 10000, and Z returns a 422 with a Min-SE of
75. The proxy forwards one of them arbitrarily, say the one from Y. The
client should retry the request with a Min-SE header in the INVITE, with
value 10000, and a Session-Expires of 10000. This once again forks to Y and
Z. Its OK by Y, but not by Z, so Z returns 422 with value 75. The fork from
Y returns a 486, so the proxy forwards the 422 upstream (there is another
issue here, which is that if Z returns a 408, the proxy will forward the
408, and then thats it - call failure. Ideally, the proxy should have
forwarded the 422 so that the client can retry the request. This is a
generic problem, not specific to session timer, regarding which messages a
proxy chooses to forward upstream). Anyway, the UAC gets that 422 with a
Min-SE of 75, and then retries the request with a value of Min-SE of 10000,
and Session-Expires of 10000. Once again, it forks through Y and Z. THe
branch through Z returns a 200 OK. Now, in refreshes to the session, the
Min-SE will always be present with a value of 10000. THis is veyr large, and
way above the minimum required by the proxies on the path of the call leg
established through Z.

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.

ISSUE #2
--------

The big problem occurs when the 422 is used when the client doesn't support
session timer.

So, the client sends an INVITE, and it knows nothing of session-timer. A
proxy inserts a Session-Expires into the request (which it is allowed to
do). It uses a Session-Expires of value 100. A downstream proxy thinks that
this is too small, so it rejects the request with a 422, and a Min-SE of
200. This hits the client. But, since the client doesn't know the session
timer, the result is a call failure, since it won't know to retry the
request with the Min-SE header present. Oops.

Now, we can mandate that 422 is returned only when the Supported header was
present in the INVITE. But, this means that sessions can be setup with
really low session timers. That seems bad.

A better solution (soln 1) is to mandate that when there is no Supported
header, a proxy cannot insert a session timer value lower than a specific
minimum (namely, 30 minutes), and that no proxy server can reject a request
with a 422 if the session timer is larger than 30m (i.e., there be a maximum
minimum session expiration). 

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. 

Soln 1 is simpler, but can result in sessions being established with large
session timers even though smaller ones are possible and desired. Solution 2
sets up the session with the right timer value, but requires further special
case processing.

I would probably recommend solution 2, but I don't feel strongly and am not
sure the complexity is worth it.

Comments?

-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: "Brett Tate" <[email-masked]>
Date: Tue, 21 Aug 2001 20:52:36 -0400

> of the Min-SE on the path of the call leg. This seems to work fine.

Sounds good.

> 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.

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 22 Aug 2001 16:03:54 -0500

Suggestions:

1) Deprecate forking -- solves the whole problem. Failing that, your
proposal seems adequate.

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. 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. On the
other hand, I'm not all that convinced we have this nut cracked anyhow.

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.

--
Dean