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

From: "Gerald Yan" <[email-masked]>
Date: Sun, 11 Jun 2006 14:46:28 +0800

I have another question about RFC 4028.
In section 7.2:
	"It is possible that the UAC requested the session timer (and thus included a Session-Expires header field in the request) and that there was no Require or Session-Expires header field in the 2xx response. This will happen when the UAS doesn't support the session timer extension and only the UAC has asked for a session timer (no proxies have requested it).  In this case, if the UAC still wishes to use the session timer (which is purely for its benefit alone), it has to perform them. "
	"If the 2xx response did not contain a Session-Expires header field, there is no session expiration.  In this case, no refreshes need to be sent.  A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests.  This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field."
My question is that how does UAC know the 2xx response without a Session-Expires header is for "turning off" session timer or a just response from a UAS which doesn't support session timer.

Best regards
Gerald

-----邮件原件-----
发件人: Paul Kyzivat [mailto:[email-masked]] 
发送时间: 2006年5月17日 3:00
收件人: Sergey Markovich
抄送: [email-masked]
主题: Re: [Sip] RFC 4028 (Session Timer) related question

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

_______________________________________________
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: Sun, 11 Jun 2006 13:22:34 -0400

> My question is that how does UAC know the 2xx response without a Session-Expires header is for "turning off" session timer or a just response from a UAS which doesn't support session timer.

The presence of a Session-Expires in the 2xx response strikes an
agreement between two parties to have a session timer. It might be
between the UAC and the UAS, or between the UAC and a proxy, or between
the UAS and a proxy.

The absence of the Session-Expires in the 2xx means there is no
agreement to do session timer. This does not prevent the UAC from
periodically doing a reinvite, just as if there *had* been a session
timer with it as the refresher, but technically this is not as a result
of a session timer.

This highlights a point that I keep raising, because many/most people
don't seem to get it: the session timer is for the convenience of
proxies that can't initiate reinvites on their own. There is no reason
for a UA to *request* a session timer, though there is value in
indicating support for it.

	Paul