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

From: "Sergey Markovich" <[email-masked]>
Date: Tue, 16 May 2006 10:13:03 -0400

Paul,

A is a proxy in this scenario. Probably I was wrong when I said "A calls
B". A just forwards initial INVITE from somebody else to B. B is an
endpoint.

Sergey

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, May 15, 2006 5:46 PM
To: Sergey Markovich
Cc: [email-masked]
Subject: Re: [Sip] RFC 4028 (Session Timer) related question

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

_______________________________________________
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: Tue, 16 May 2006 12:16:21 -0400

Sergy,

Can you restate your problem, showing both UAs and the proxy, and what 
each does?

	Paul