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

From: Rakesh Shah <[email-masked]>
Date: Wed, 25 Apr 2001 16:00:01 -0400

Please note that we are now doing a Last Call review for
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-session-timer-04.txt>
draft-ietf-sip-session-timer-04.txt. The schedule of the review is broken
into two parts. The first cut was to have dedicated reviewers do a review
and post them to the list. This begins the second part which opens up the
review to everyone.
 
    The standard review time is for one week unless the debates require more
time. The review is open until 1-May-01. Please post your issues to the SIP
WG mailing list so that everyone can debate the issue. This also allows the
authors to collect the information.
 
Regards,

Rakesh
_______________________________
Mr. Rakesh C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
1st Floor
East Hanover, N.J. 07936 
(973) 952-5066 direct 
(201) 214-6084 cell
(973) 952-5000 main
(973) 952-5050 fax
[email-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 30 Apr 2001 20:30:50 -0400

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?

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.

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.