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

From: "Sergey Markovich" <[email-masked]>
Date: Tue, 16 May 2006 14:32:49 -0400

Paul,

I checked with our customer. A is a server but it is B2BUA and not a
proxy.
A is interested to know that B is alive. So there is no proxy. So the
scenario is the following:

1.	B and C are endpoints. They do not know anything about Session
Timer mechanism.
2.	A is a B2BUA. It implements Session Timer mechanism. 
3.	C calls A, A calls B, both calls are established.
4.	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.	Probably the same happens between A and C (on the other leg of
B2BUA)
6.	B puts A on hold, i.e. it sends SDP related reINVITE without
"Session-Expires" or "Supported:timer"
7.	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.

Thank you,

Sergey

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

Sergy,

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

	Paul

Sergey Markovich wrote:
> 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
> 

_______________________________________________
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: Venkatesh <[email-masked]>
Date: Tue, 16 May 2006 11:42:20 -0700

At step 7, if A wanted to continue using Session-Timers (which seems to be
your intent), there is nothing preventing it from adding a Supported: timer
and a Session-Expires header with the refresher parameter set to "uas" when
sending the 200 OK response for the Hold request. It can then restart its
timers.

Venkatesh

On 5/16/06, Sergey Markovich <[email-masked]> wrote:
> 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.
>
> 7.      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.
>
> Thank you,
>
> Sergey
>
> From: Paul Kyzivat [mailto:[email-masked] <[email-masked]>]
> > A is a proxy in this scenario. Probably I was wrong when I said "A calls
>
> > From: Paul Kyzivat [mailto:[email-masked] <[email-masked]>]
>
> > 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
>
> >
>
> > timer to be established. If A wants to periodically check the status of
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 May 2006 14:59:55 -0400

Sergey,

In the situation you describe there is no value to using the session 
timer mechanism. Since A is a (B2B)UA, it is free to send a reinvite any 
time it wants to check on its session with B or C. To do this without 
perturbing the call, it can send an offerless reinvite to B, take the 
answer and send it as an offer in a reinvite to C, etc.

Or it could simplify and simply send an OPTIONS periodically  to B and C.

Session-Timer is really only of importance to stateful proxies.

	Paul

Sergey Markovich wrote:
> 
> Paul,
> 
> I checked with our customer. A is a server but it is B2BUA and not a proxy.
>