Subject: [Sipping] Behaviour of Session-Timer at UAC after receiving 488 response for RefreshRe-Invite Sent

From: [email-masked]
Date: Tue, 9 Oct 2007 16:09:31 +0530

Hi,
  I have query regarding the Session-timer.

We have a scenario where we are rejecting Session Refresh 
request(Re-INVITE or UPDATE) with 488.
After receiving the 488 does the UAC should continue with the same timer 
which is running or it should re-set the timer
with the previous value.

INVITE ->(with session-expires: 90)
180<--
200 <-- (with session-expires: 120)
ACK-->
Re-INVITE ( Session-expires: 150)
488 <-- 

Here does the UAC has to stop and start the timer again with 120 or should 
continue with the running timer.

As per the information provided in the below link, it is suggested to 
re-send the previous INVITE. 
Should the INVITE be sent immediately or should it be sent after the 
Session-Timer expiry.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2002-July/003495.html

Thanks and Regards,
 Preethi..
------------------------------------------------------------------------------
Preethi Sadasivan,
Software Engineer,
ARICENT ,
Bangalore.
tel: +91-80-41069118
------------------------------------------------------------------------------

***********************  Aricent-Restricted   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2007 09:25:14 -0400

> 200 <-- (with session-expires: 120)

The above behavior by the UAS (or some proxy along the path) is 
incorrect. The session-expires value must not be increased - it must be 
<= the value of 90 sent in the invite. The UAS should have sent a 422 
response with a value of 120.

> Re-INVITE ( Session-expires: 150)

Then attempting to further increase it is asking for trouble. You should 
use the value negotiated initially, or at least a value between the 
min-SE and the session-expires of the 200 response.

However the 488 response is not the right way to indicate problems with 
the session timer. It ought to indicate a problem with the SDP offer in 
the reinvite.

> Here does the UAC has to stop and start the timer again with 120 or 
> should continue with the running timer.

As I interpret RFC 4028, the old session timer will remain in effect in 
this case, continuing to count down. If it doesn't get refreshed by some 
subsequent reinvite or update then when it counts down to zero the 
session should be terminated.

> re-send the previous INVITE.

I think that comment is reasonable advice if interpreted loosely, but 
many things should work.

Sending *exactly* the same invite as previously sent will not work. At 
least the CSeq must be changed. And it isn't necessarily the right thing 
to do if there were intervening exchanges of various sorts.

You should try to understand what is provoking the 488. Are you changing 
the media description in the reinvite in a way that might bother the 
UAS? Or is it perhaps misusing the 488 to indicate a complaint about the 
session-expires - perhaps using it when it should be using a 422.

> Should the INVITE be sent immediately or should it be sent after the 

Its really hard to give hard and fast answers here because you are 
dealing with a non-compliant implementation. But if you wait until the 
prior session timer expires the call will end, so that isn't a good answer.

You need to deal with two things:

- fix the non-compliance in your own code. When refreshing, use the 
session-expires value negotiated previously, at least if it was 
*validly* negotiated. Definitely make sure it is <= the session-expires 
value of the previous successful response, and >= the min-SE value, if 
any in that response.

- if you need to make your code work when there is non-compliance by 
others as shown in your example - that increases the session-expires 
value - then you will have to experiment with what works. The only 
obvious thing to do is accept the value as if it was the one you had 
initially proposed. This may or may not be enough. If this is being 
messed up by proxies there is a possibility that nothing will work. All 
you can do is try. Another possibility is to simply try to cancel the 
session timer, by sending a reinvite without session-expires.

I've been saying this for years now, without much effect, but there is 
really NO value in a UAC or UAS requesting the establishment of a 
session timer. The value of session timer is for stateful proxies that 
need periodic evidence that there is still a functional session. The UAs 
can test any time they want by sending an in-dialog request, they don't 
need session timer to tell them to do it.

So you could simply stop trying to establish a session timer, while 
remaining willing to support one if requested to do so. That might solve 
your problem.

	Paul

> _https://lists.cs.columbia.edu/pipermail/sip-implementors/2002-July/003495.html_
> 
> 
> 
> Thanks and Regards,
> Preethi..
> ------------------------------------------------------------------------
>