Subject: RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call

From: Steve Donovan <[email-masked]>
Date: Mon, 14 May 2001 22:43:04 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 7:31 PM
> To: 'SIPWG Mailing List (E-mail)'
> Subject: RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call
> 
> 
> General comment/question: 
> 
> Why can Session-Expires and Require "timer" 
> be in negative re-INVITE responses since it 
> is not guaranteed that re-INVITE has gotten 
> to the far end?  Let me know if I missed the 
> sentence that would ensure that a proxy won't
> generate such a response as means to extend
> the session timer.  Was it added as a means 
> for a proxy to help produce a BYE quicker?

I don't understand the concern.  This does not force a BYE to happen faster.
It might cause a re-INVITE to happen quicker, which is why we are adding
wording about not accepting small session-timer values.

> 
> Section 4 last paragraph:
> The Session-Expires immediate and Require 
> "timer" looks like a kludge for UA's 
> that don't add/use tags.  It seems strange 
> that they are current enough to implement
> timer draft but not current enough to add 
> tags to the To and From.  Note: the proxy 
> should not add the Session-Expires immediate
> and Require "timer" for the UA since the 
> proxy doesn't know the destination UA's 
> reason for the reject.  Please make being 
> able to distinguish a re-INVITE from INVITE 
> a requirement for implementing the draft.

We can't mandate that all UAs support tags.  We have added wording that any
UA implementing the session timer draft must support From and To tags.

> 
> 
> 
> General comment/question:
> 
> Please mention in the draft that 
> the UAS receiving a re-INVITE SHOULD NOT 
> revive a dead call-leg unless it knows that 
> the associated media session is still 
> active/allocated for that call-leg.
> 
> Reasons:
> 1) Helps ensure that the reviver is one 
>    that pays for call if the revived party
>    actually hung up previously.
> 
> 2) Helps ensure that the reviver only pays
>    for call if reviver knows it will be
>    paying for call.
> 
> 3) Only re-alerts the receiver when sender
>    really desires such a thing.
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 15 May 2001 16:47:29 -0400

Thanks for the response.  

More questions/comments are in the following text. 

> wording about not accepting small session-timer values.

[My comment about getting a BYE triggered 
earlier was just an attempt to try and understand 
why proxies can add Session-Expires in negative 
responses.  If the proxy or UAS adds a small 
Session-Expires value that the UAC refuses 
or cannot extend, the UAC would send a BYE prior 
to its expiration.  
]

My main concern is with proxies not being 
explicitly discouraged from adding session 
extending Session-Expires to re-INVITE 
failure responses.

A--P1--P2--B

A call has been set up; P1 and P2 have 
record-routed; and A is required to send 
session extending re-invites to B.  
A sends re-invite.  P1 returns a 503 
because it is too busy.  P1 SHOULD NOT 
return Session-Expires extending the 
session since P2 and B would still be 
timing off the previous Session-Expires.

Same situation however P2 and B do not support 
the timer draft.  P1 previously observed 
that P2 and B do not support the timer draft 
since they didn't return the Session-Expires 
in the 200.  A sends re-INVITE.  P2 returns
503 because it is too busy.  P1 SHOULD NOT
add the Session-Expires to the 503 because
it has no clue if B is still alive.

Same situation however only B does not 
support the timer draft.  A sends a re-INVITE.  
B returns a negative response.  P2 SHOULD NOT 
add the Session-Expires because P2 has no clue 
as to the state of the call-leg's related 
session at B.

> UA implementing the session timer draft must support From and To tags.

What impact does the addition of the 
Session-Expires SHOULD NOT be less than 
30 minutes and the new text about not 
accepting small session-timer values have on
session-expires immediate discussed in above
text?  Is this an exception to the small
Session-Expires rule?

Since the 488 with Session-Expires only works
in one direction, what does the UAC do besides 
send re-INVITE or eventually BYE based upon 
receiving a Require timer with small 
Session-Expires value in a 200 response?