Subject: RE: [Sip] The fate of session timer?

From: "Stevens, Del" <[email-masked]>
Date: Tue, 12 Nov 2002 12:51:29 -0500

All:

For us the implementation of session timers has been a customer-driven
requirement for our B2BUA. I agree that this draft was difficult to
understand, but it satisfies several requirements for us:

1. A simple keep-a-live mechanism (as stated previously). This prevents
tying up resources in our B2BUA if something happens in the network causing
a SIP UA (or proxy) to "disappear" after the receipt of 200 OK. We have a
configurable timer value, but the default of 30 minutes (per the draft)
seems adequate. From a telco perspective, it is important from a billing
perspective to have some record of a session during failure scenarios. Yes,
this record is not exact, but telcos (or the like) can generally deal with
inaccurate cdr records during failures better than no record at all.

2. If our B2BUA receives an INVITE from a SIP UA (or proxy) that support
session timers, the negotiation takes place, allowing a symetrical
keep-a-live mechanism. If the SIP UA doesn't support session timers, then
our B2BUA can still use an asymetrical keep-a-live mechanism so our UA can
ensure the "other" end is still there for each session.

A nice off-shoot from our implementation of session timers occurs during
fail-over situation. In this case, the newly active B2BUA can "re-establish"
updated state information about each in progress session by issuing a
re-INVITE for the session. The responses reinitializes the session timer
lists on the "new" ACTIVE machine.

Even though this is an old draft several sip phone manufacturers support
session timers. Also, since the implementaton of session timers is not
universal, we never issue "Require: timer", but let "Supported: timer" and
"Session-Expires: n" to allow the negotiation to take place.

If anyone is using digest authentication with session timers this creates
the need for each re-INVITE to contain an Authorization header or risk being
challenged (401/407).

Yes, there is some messaging and processing overhead: 1) session timer
negotiation + refreshes, and 2) tracking additional timers per session. But
the safety net provided is a must for some customers. My vote is to keep
this draft and update as necessary!

Del Stevens mailto:[email-masked]
Siemens Network Convergence LLC
7800 Congress Ave
Boca Raton, FL  33487

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, November 11, 2002 6:24 PM
To: [email-masked]
Subject: [Sip] The fate of session timer?

Folks,

As you may have noticed, I submitted an update to the session timer 
specification. This is an old, old spec that has been around for quite 
some time. It receives only minimal attention these days. The general 
comments on the list are generally 'too complex' and 'too hard to 
understand'. Some of that is wording, which I will continue to work. The 
bigger problem, I think, is that its not at all clear what problem this 
draft is REALLY solving.

I assert that session timer is really useful for one thing, which is to 
provide a means to cleanup old session state in UAs and proxies. 
Normally, you'd set a timer (on the order of 5 hours or something) to 
discard any state thats still around. However, since a call may actually 
last that long, you want a way to reliably know when you can flush the 
state.

Session timer is NOT useful for determining call durations for billing 
purposes.

Session timer is NOT useful for quickly determining that a UA has 
failed, in order to recover. It operates too slowly for that.

So, given this somewhat-marginal value, the complexity seems startingly 
high. I have begun to wonder whether that is the reason for the troubles 
this specification is having. So, I see a few options:

1. No one cares about this spec. Discard it entirely.

2. Continue as it is, fix up some wording, and submit. Probably no one 
implements it since it provides little value at high cost.

3. Change the scope. Eliminate or simplify negotiation of the timer by 
defining a suitably long minimum. Eliminate or simplify choosing who 
refreshes by requiring that the UAC support the timer. And so on. The 
result would be a much simpler spec.

4. others?

Please provide comments, particularly if you are actively using this 
specification for some real problem.

-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  https://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
_______________________________________________
Sip mailing list  https://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: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2002 09:52:06 +0200

Hi,

Some comments/thoughts from me about this.

First, since the purpose of the session-timer (as Jonathan said) currently only
is to clean up sessions, and NOT to recover state etc, I would like to get
anything related to the offer/answer mechanism away from it. UAs may need the
send offers for real stream related purposes, so it should not have to do
buffering in case there is an ongoing session-timer offer/answer transaction.
No, due to the long timer value for the session-timer this will probably not
happen very often, but still.

Second (and please don't flame me :), would it be a good idea to have a look at
the INFO method again? The reason we didn't want it in the first place was
because it shall not be used for chaning state. But, since we now don't use the
session-timer for state recover that reason is maybe not valid anymore (it is
NOT the INFO itself which changes the call state).

I think one of the keys to the success of the session-timer is to make it as
light as possible. No idea to include SDPs, and absolutely no idea to use
re-INVITE, which also requires ACK. But, of course it's also a question about if
anyone has any interest in this work.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Nov 2002 07:35:23 -0500

> NOT the INFO itself which changes the call state).

The draft already specifies UPDATE. The UPDATE can be sent without a 
session description. Please explain what benefits there are to 
specifying the usage of INFO in addition.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Nov 2002 16:56:05 +0200

Hi,

UPDATE without SDP is fine too. Just as long as we don't initiate offer/answer
exchanges without any real meaning, and just as long as the timer refresh doesn't
prevent either party to send UPDATE/re-INVITE to initiate a real offer/answer
mechansim during the lifetime of the timer refresh transaction.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 13 Nov 2002 08:46:34 -0800

Christer,

if you don't like reINVITE, you should use an UPDATE instead.  that is 
much better than an INFO!

thanks,
-rohan

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Wed, 13 Nov 2002 10:59:17 -0600

Jonathan
Whenever we overload one request to do disparate functions, we have a source
of confusion, race conditions etc.
For example, although the likelihood of such an intersection is relatively
small, it is possible that an offer/answer exchange is required at the time
a session timer refresh is in progress using UPDATE (or INVITE). This
required extra logic in the implementation to sequence these and is an
overhead for a remote corner case. Further, the rules about crossing
UPDATEs/INVITEs resulting in 491 have to be handled even though it would
seem to make perfect sense to be able to accept an UPDATE without SDP (sent
for session refresh) while an UPDATE with SDP has been sent out by the UA.
It seems silly to have to re-attempt a session refresh when the previous
UPDATE/491 has verified the existence of the session at both ends.

Having a separate request for session timer eliminates unnecessary
overloading of the existing requests. But this seems like a big ado over a
trivial issue.

So, the idea of proxies subscribing to a UserAgent to detect session state
is a good alternative. User agents can always verify session existence using
any request they choose that makes sense in the context of the dialog. Since
the session refreshes are supposed to be infrequent, having refreshes cross
each other is not very likely if the durations are randomly chosen. Further,
it hardly matters that the requests crossed since any (non-BYE/ non-481/408)
request/response exchange verifies the session liveness, anyway, achieving
the purpose.

Regards
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Wednesday, November 13, 2002 6:35 AM
To: Christer Holmberg
Cc: Stevens, Del; [email-masked]'
Subject: Re: [Sip] The fate of session timer?

-Jonathan R.

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 13 Nov 2002 14:45:54 -0500

> if you don't like reINVITE, you should 
> use an UPDATE instead. 

The UPDATE method is basically going to
become the mechanism to "update" most
any header which is valid within an
INVITE.

If this is not the intention of the
header, new methods like RETARGET,
AUDIT, IDENTITY, SUPPORTED, and ALLOW 
should be defined.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2002 10:07:01 +0200

Hi,

> much better than an INFO!

I have nothing against using UPDATE. My question was only if the original
reason not to use INFO isn't valid anymore :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2002 10:06:53 +0200

Hi,

> a session timer refresh is in progress using UPDATE (or INVITE).

I had the same concern, but obviously you don't have that problem if you use
UPDATE -without- SDP for the timer refresh.

Regards,

Christer Holmberg
Ericsson Finland

> This

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Thu, 14 Nov 2002 08:18:40 -0600

Christer
That is not true. Another UPDATE may neither be received nor sent (491/500
with Retry after rules) when an UPDATE has been sent/received.
Cheers,
Venkat

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 2:07 AM
To: Arunachalam Venkatraman
Cc: Jonathan Rosenberg; [email-masked]
Subject: Re: [Sip] The fate of session timer?

Hi,

Regards,

Christer Holmberg
Ericsson Finland

> > session-timer for state recover that reason is maybe not valid anymore
(it
> is

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2002 16:54:40 +0200

Hi,

> with Retry after rules) when an UPDATE has been sent/received.

If that is the case I don't want to use UPDATE :) To my understanding the
current functionality of the session-timer has nothing to do with the
offer/answer mechanism, so I see no reason why it should "block" other possible
offer/answer transactions.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Nov 2002 09:50:56 +0200

Hi,

I have one question about the session-timer. This has probably been discussed
before, but I'd still like to bring it up.

Currently the spec says that a proxy not supporting the proposed refresh timer
value will send a 422 response, and after that the UAC will have to send a new
INVITE, with a higher timer value.

Now, in a forking environment there is a chance that 422 responses will be received
from proxies in legs which may never be part of the session, and the UAC will have
to send a new INVITE, and rise the value because of proxes which may never be part
of the session... I guess the forking proxy may not even always forward the 422 to
the UAC, while waiting for other final responses, so the UAS on that leg may never
get a chance to participate in the call in the first place, since the end-user may
never receive the INVITE (a proxy will return 422).

So, my question is: if a value is too small for a proxy, what is the reason it
simply can't change the value and forward the INVITE? In that case the INVITE will
receive the UAS, and the final response will indicate the refresh value which will
actually be used.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Surendra Prajapat <[email-masked]>
Date: Fri, 15 Nov 2002 00:13:58 -0800

As I understand it from the extenstion, the expire time is negotiated 
between entities which are already in a dialog. So in case
of forking the timer value will only be negotiated with entities which 
eventually be participating in the call.

-Surendra

that it should not happen till the session is established and so even in 
forking
At 09:50 AM 11/15/2002 +0200, Christer Holmberg wrote:

> > > > > Second (and please don't flame me :), would it be a good idea to 
> have a
> > > > look at
> > > > > the INFO method again? The reason we didn't want it in the first 
> place
> > > was
> > > > > because it shall not be used for chaning state. But, since we now 
> don't
> > > > use the

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Nov 2002 11:43:14 +0200

Hi,

> eventually be participating in the call.

Eeeh... I don't really understand...

The UAC sends an INVITE, which gets forked. ANYONE receiving the INVITE, no matter
if they will be part of the established dialog or not, can reject it with 422.

If one wants to re-negotiate the timer when the session is established we of course
don't have this situation, but that is not what I was talking about.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Fri, 15 Nov 2002 09:07:49 -0600

Christer
The proxy cannot change the value and send it to the same UAS again because
a proxy cannot up the CSEQ and originate a request. The UAS receiving the
request with the changed value of session timer has to recognize it as a new
request, so it has to have a higher CSEQ.
Regards,
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Christer Holmberg
Sent: Friday, November 15, 2002 1:51 AM
To: Jonathan Rosenberg; [email-masked]
Subject: Re: [Sip] The fate of session timer?

Hi,

I have one question about the session-timer. This has probably been
discussed
before, but I'd still like to bring it up.

Currently the spec says that a proxy not supporting the proposed refresh
timer
value will send a 422 response, and after that the UAC will have to send a
new
INVITE, with a higher timer value.

Now, in a forking environment there is a chance that 422 responses will be
received
from proxies in legs which may never be part of the session, and the UAC
will have
to send a new INVITE, and rise the value because of proxes which may never
be part
of the session... I guess the forking proxy may not even always forward the
422 to
the UAC, while waiting for other final responses, so the UAS on that leg may
never
get a chance to participate in the call in the first place, since the
end-user may
never receive the INVITE (a proxy will return 422).

So, my question is: if a value is too small for a proxy, what is the reason
it
simply can't change the value and forward the INVITE? In that case the
INVITE will
receive the UAS, and the final response will indicate the refresh value
which will
actually be used.

Regards,

Christer Holmberg
Ericsson Finland

have a
place
don't

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Nov 2002 19:27:14 +0200

Hi,

I never said the proxy should change the value and send it to the same UAS
again...

What I said was two things:

1. The UAC MAY receive 422 from proxies in early legs which will never be used
in the call, because if the message was forked.

2. A forking proxy may "buffer" a 422 it receives from a proxy in a leg, while
waiting for final responses from other legs. Then, if it receives a 200 OK from
another leg the UAS behind the proxy who sent the 422 never received the INVITE,
so it was never given a chance to participate in the call.

So, because of these reasons (even if the first would never take place, I still
think the second is valid) my proposal was that proxies should NOT have to
return 422. Instead they should be able to update the refresh value to a higher
value and simply forward the INVITE. This way the INVITE would reach every UAS,
and every UAS would be given a chance to participate in the call. Now, if the
refresh value received by the UAS for some reason is too low, it can choose to
either return 422 or return 200 with an updated value. If this value now, for
whatever reason, is too big for the UAC it may either terminate the call or try
to re-negoatiate the refresh value.

Now, I realise a drawback with this proposal is that if the UAS updates the
value, intermediate proxies will not be able to indicate in case they, for
whatever reason, think the value is too high. One reason too solve this would be
to define also a "max value" header, if really needed.

I also earlier said that this has been discussed before, and that there may be
issues I didn't think of now.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 02:39:09 -0500

> offer/answer transactions.

Please read the specifications carefully. RFC 3311 only forbids sending 
an UPDATE with an offer while there is another offer outstanding. Thus, 
if you have sent an UPDATE without an offer, the specification does not 
prohibit you from sending another before it completes.

However, I would generally recommend against such overlapping of 
UPDATES, as it is a recipe for trouble.

Venkat had a specific complaint I want to address:
> overhead for a remote corner case.

This is a bogus issue. You need to have centralized coordination of 
sending/receiving requests in order to do proper cseq maintenance, 
remote target URI maintenance, etc. So, this function is already there.

  Further, the rules about crossing
> for session refresh) while an UPDATE with SDP has been sent out by the UA.

As I mention above, this is technically allowed although it makes me 
nervous. UPDATE can, in the future, affect other pieces of state, and 
thus we may run into other problems.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 02:48:00 -0500

inline.

Christer Holmberg wrote:
 > discussed before, but I'd still like to bring it up.
 >
 > Currently the spec says that a proxy not supporting the proposed
 > refresh timer value will send a 422 response, and after that the UAC
 > will have to send a new INVITE, with a higher timer value.
 >
 > Now, in a forking environment there is a chance that 422 responses
 > will be received from proxies in legs which may never be part of the
 > session, and the UAC will have to send a new INVITE, and rise the
 > value because of proxes which may never be part of the session...

This is why the session timer spec has the UA "clear" the min-expires 
value when the dialog is established.

I
 > guess the forking proxy may not even always forward the 422 to the
 > UAC, while waiting for other final responses, so the UAS on that leg
 > may never get a chance to participate in the call in the first place,
 > since the end-user may never receive the INVITE (a proxy will return
 > 422).

This may happen, yes.

 >
 > So, my question is: if a value is too small for a proxy, what is the
 > reason it simply can't change the value and forward the INVITE? In
 > that case the INVITE will receive the UAS, and the final response
 > will indicate the refresh value which will actually be used.

There are two reasons.

The first is documented in the security considerations section:

> Next, consider the case of a rogue UAS that wishes to force a UAC to
>    generate refreshes at a rapid rate. In that case, the UAC has to
>    support session timer. The initial INVITE arrives at the rogue UAS,
>    which returns a 2xx with a very small session interval. The UAC uses
>    this timer, and quickly sends a refresh. Section 7.1 requires the UAC
>    to copy the current session interval into the Session-Expires header
>    field in the request. This enables the proxies to see the current
>    value. The proxies will reject this request, and provide a Min-SE
>    with a higher minimum. The UAC will then use this higher minimum.
>    Note, that if the proxies did not reject the request, but rather
>    proxied the request with a Min-SE header field, an attack would still
>    be possible. The UAS could discard this header field in a 2xx
>    response, and force the UAC to continue to generate rapid requests.

So, the change you suggest would introduce a dos attack that a rogue UAS 
could launch on a UAC.

The second reason was that one property we wanted to maintain was that 
the session refresh interval was at least as small as the smallest 
requested value, so long as that wasn't below someones configured 
minimum. Your suggested change would allow a single proxy to increase 
the timer to an arbitrary value, breaking this requirement.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Nov 2002 14:34:29 +0200

Hi,

>  >since the end-user may never receive the INVITE (a proxy will return

And that is not good.

> So, the change you suggest would introduce a dos attack that a rogue UAS

The UAC would include a minimum value in the request, which proxies are only
allowed to INCREASE, if needed. If the UAC then receives 200 OK with a SMALLER
value it knows something went wrong, so it would probably choose to release
the call. Every proxy, when receiving the 200 response, would also see that
something has gone wrong, since the value is smaller than the value set in the
INVITE request.

> the timer to an arbitrary value, breaking this requirement.

That is true, but again the UAC (or UAS) would still be able to terminate the
call if this happens. But, at least the UAS would get a chance to participate
in the call.

I also think I mentioned a max value header earlier, which could be used by
the UAC to make sure the value won't get too big. Of course, that value would
have to be big enough to make sure any "reasonably" configured proxy would
accept it. Or, a proxy would be allow to update this value also - in either
direction - and if the value gets too big the UAC can choose to release the
call.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 16:42:38 -0500

inline.

> something has gone wrong, since the value is smaller than the value set in the

That doesn't work. It relies on behavior at the UAS. That is the place 
where the rogue element is. Once you assume you cannot trust the UAS, 
you must rely on the proxy before it to generate an error response. I 
believe there is no way around that.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Nov 2002 13:45:00 +0200

Hi,

> believe there is no way around that.

[CHH] Assuming that the proxies DO accept the value proposed by the UAC, and the
INVITE reaches the UAS, the UAS can
still insert a SMALLER value, and the situation will be the same, won't it?

Regards,

Christer Holmberg
Ericsson Finland