[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call
> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Monday, April 30, 2001 8: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?
This is legacy of an old problem. The problem
was that if a UAC sends a refresh, and the UAS
had since crashed and rebooted, we needed a way
for the UAS to respond to the re-INVITE and say
"sorry, this call is terminated". At the time this
text was inserted, we had not specified that a 481
response to a mid-call request terminates the call.
With that feature added, this legacy text on
Session-Expires in a non-200 response is not needed.
It has been removed.
To avoid a dependency of session timer on bis, I've added
text that says From tags are mandatory when session timer
is implemented. I've also explicitly mentioned that a UAS
should send a 481, and that a UAC MUST consider the call
destroyed when it receives this. This is exactly what bis
says, but since its now also mandated by this extension
when the extension is used, the dependency is broken.
>
> Section 4 last paragraph:
> The Session-Expires immediate and Require
> "timer" looks like a kludge for UA's
> that don't add/use tags.
Excellent observation, and completely correct.
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.
Done.
I've also changed the text in all places so that Session-Expires can only
appear in a 2xx class response.
> 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.
I've added text that says it shouldn't accept a re-INVITE
for a call that it thinks is terminated unless it is
explicitly trying to recover lost calls.
>
> 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.
All good reasons.
-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip