Subject: RE: [Sip] Session Timer - Timeout on Refresh

From: "Padhye, Chinmay" <[email-masked]>
Date: Thu, 25 Oct 2001 17:18:53 -0700

Hello,

	Please see my questions inline starting with [Chinmay].

Regards,

Chinmay

-----Original Message-----
From: Brett Tate [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 4:45 PM
To: 'Wray Ferrell'; [email-masked]
Subject: RE: [Sip] Session Timer - Timeout on Refresh

> Version 0.8 of the draft states:
> "If no response is received to a refreshing re_INVITE
> is received before the session expiration, the UA
> SHOULD send a BYE request to terminate the call.
> It SHOULD send this BYE slightly before session
> expiration"

I think it should be "If no 2xx response ...".

> 
> The bis-03 draft of SIP states under Reliability
> for INVITE Requests:
> "If no response is received after sending seven packet
> requests, processing continues as if a 481 response was
> received for that request."

Would a 408 be more appropriate than a 481?
This would allow the UAC to decide the 
importance of the re-invite.
 
> So does the SIP Session Timer override the section on
> reliability for INVITE requests? More specifically if
> a UA responsible for refreshing does not receive a
> response to its' re-INVITE what should its' behavior
> be? Disconnect the session as if receiving a 481 or
> keep the session alive since the session expiration
> has not yet been reached?

I think that the session should stay alive 
if the re-invite didn't have a new sdp.

---
[Chinmay]
Consider the above case where an intermediate proxy has also started a
session timer for this call.

What should the proxies behavior be?

a) Should it release the resources for the call because it does not get a
2xx for the re-INVITE? OR
b) Should it wait for a BYE from the UAC?

Also what happens when the session timer at the proxy expires? 
---

Allowing the possibility for multiple 
failures during session refreshing was
one of the reasons why the timer draft
starts trying to refresh at 1/2 
session-expires.

---
[Chinmay]
I didn't follow your statement. 

Can you please clarify what you mean by 'Allowing the possibility for
multiple failures'?

Do we want to let the refresh fail and still keep the call alive?!
---

If it was a new sdp in the re-invite, 
releasing the call might be desired to 
avoid potential sdp fallback confusion.

_______________________________________________
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

_______________________________________________
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: Wray Ferrell <[email-masked]>
Date: Fri, 26 Oct 2001 12:54:30 -0400

> if the re-invite didn't have a new sdp.

Brett, can you clarify why the difference in behavior
if the sdp is updated? Are you saying that the code
should treat a change in the sdp as a new session?
i.e. a re-INVITE without a sdp change is
still the old session in which both sides agreed to
keep up for x seconds, but a sdp change is a new
session and the agreement reached about the old
session no longer matters?

> Can you please clarify what you mean by 'Allowing the possibility for

Not to speak for Brett, but I think what he means is that
sending the refresh at 1/2 session-expires allows all the
re-tries (unless the SE value is really small) to occur before
the session expires. If the refresh was sent near the end of the
interval then a temporary network glitch could cause the call to
be terminated since the non refreshing UA timer would expire
before the refreshing UA had exhausted its' retries.

Wray

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 26 Oct 2001 14:43:10 -0400

> b) Should it wait for a BYE from the UAC?

It should release resources when the session 
expires.  There is no need to wait for the BYE.
 
> Also what happens when the session timer 

It can cleanup call state and send CANCELs 
and 4xx's when appropriate.
 
> 'Allowing the possibility for

First refresh failed with 407 from proxy 1.
Second failed with a 503 because proxy 2 
too busy to process the request.
Third failure because proxy 2 was down
and proxy 1 returns a 408.
Fourth try fails because UAS returns 401.
Fifth try is successful.
 
> still keep the call alive?!

Some refresh request can fail (assuming no 481).  
A subsequent refresh request can still be 
successful when sent within the session-expires 
interval.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 26 Oct 2001 15:23:34 -0400

> Brett, can you clarify why the difference in 
> behavior if the sdp is updated?

If a re-invite was only to extend the session,
a proxy being down for a minute ultimately
shouldn't have a negative impact on the
call or call-leg.  The UAC can retry again
later if time is still available within the
session-expires window.

However if the re-invite was attempting to
change the session by supplying a new SDP,
a non-acknowledged re-invite may or may not
have been received and/or accepted by the
UAS.  Thus it can lead to media/SDP confusion.