Subject: [Sip] RFC 4028 (Session Timer) related question

From: "Sergey Markovich" <[email-masked]>
Date: Mon, 15 May 2006 16:55:58 -0400

We have the following scenario:

1.       A  has Session Timer mechanism enabled.

2.       A calls B,  the call is established

3.       A is sending reINVITEs with "Session-Expires" header to B
periodically. B is replying  with OK without "Session-Expires" or
"Supported:timer", i.e. B does not support the Session Timer mechanism,
A is a refresher.

4.       B puts A on hold, i.e. it sends SDP related reINVITE without
"Session-Expires" or "Supported:timer"

5.       A  replies with OK without "Session-Expires" and it stops
(disables) the mechanism, i.e. no session timer related callbacks
anymore, the application does not do refresh (does not send reINVITEs)
anymore.

I am not sure that step 5 is RFC 4028 compliant.

I know that the default value of "Session-Expires" is infinity, but I
think it makes sense only when the sending party (B) DOES support the
mechanism (i.e. does include "Supported:timer", but does not include
"Session-Expires" in the reINVITE). In that case the reINVITE can be
used for the negotiation of the mechanism parameters. But in our case
the reINVITE from step 4 has to be treated as "refresh" only (because
after step 4 A knows that B is alive). So A has to restart the timer but
not to disable the mechanism.

It would be appreciated if you comment what should we do in step 5. 

Thanks a lot,

Sergey

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 15 May 2006 17:46:08 -0400

Sergey,

For this scenario to make sense there should be a proxy involved that is 
interested in having a session timer. If there was, then it would insert 
a Session-Expires into reinvite of step 4, and A would respond, 
reestablishing the timer.

If there is no proxy doing this, then there is no need for a session 
timer to be established. If A wants to periodically check the status of 
the session, it may do so an any time by sending a reinvite.

	Paul

Sergey Markovich wrote:
> 3.       A is sending reINVITEs with “Session-Expires” header to B 
> periodically. B is replying  with OK without “Session-Expires” or 
> “Supported:timer”, i.e. B does not support the Session Timer mechanism, 
> A is a refresher.
> 
> “Session-Expires” or “Supported:timer”
> 
> 5.       A  replies with OK without “Session-Expires” and it stops 
> I know that the default value of “Session-Expires” is infinity, but I 
> mechanism (i.e. does include “Supported:timer”, but does not include 
> “Session-Expires” in the reINVITE). In that case the reINVITE can be 
> the reINVITE from step 4 has to be treated as “refresh” only (because 
> ------------------------------------------------------------------------
>

---

From: Chen Shuping <[email-masked]>
Date: Tue, 16 May 2006 11:55:43 +0800

I met this problem also.
I think the spirit of RFC4028 is to keep session alive by signal exchange,
So, when i received re-Invite(on hold request) from B,firstly, sipua accept
hold request,
 
secondly,sipua in A  restart refresh-timer.
 
I am not sure it is the right process. 

  _____  

发件人: Sergey Markovich [mailto:[email-masked]] 
发送时间: 2006年5月16日 4:56
收件人: [email-masked]
主题: [Sip] RFC 4028 (Session Timer) related question

3.       A is sending reINVITEs with “Session-Expires” header to B
periodically. B is replying  with OK without “Session-Expires” or
“Supported:timer”, i.e. B does not support the Session Timer mechanism, A
is a refresher.

5.       A  replies with OK without “Session-Expires” and it stops
(disables) the mechanism, i.e. no session timer related callbacks anymore,
the application does not do refresh (does not send reINVITEs) anymore.

I know that the default value of “Session-Expires” is infinity, but I
think it makes sense only when the sending party (B) DOES support the
mechanism (i.e. does include “Supported:timer”, but does not include
“Session-Expires” in the reINVITE). In that case the reINVITE can be used
for the negotiation of the mechanism parameters. But in our case the
reINVITE from step 4 has to be treated as “refresh” only (because after
step 4 A knows that B is alive). So A has to restart the timer but not to
disable the mechanism.

Thanks a lot,

Sergey