Subject: [SIP] RE: draft-ietf-sip-session-timer-02.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Oct 2000 22:26:58 -0500

I know this email is ancient, but I am finally getting around to updating
this. So, here are some comments:

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, July 31, 2000 4:01 PM
> To: [email-masked]; Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-sip-session-timer-02.txt
> 
> 
> In section 3, the draft specifies that the
> exiration for delta times are defined as
> "[the] delta time plus the time at which the
> header is observed in a response." Presumably,
> you mean "final response," right? It should
> probably be more explict; further, some note
> should be made about "Session-Expires" in
> 1xx messages (if only to say that they are
> disallowed).

Updated to forbid Session-Expires in 1xx messages.

> 
> In section 4, you specify that the lack of
> require and session-timer headers in an
> INVITE response imply that the UAC has no
> further actions to take. This is somewhat
> misleading. If, for example, the UAC sends
> a "Supported: timer" header and a "Session-Expires"
> header, but receives no timer indication in the
> response, he still should be responsible for
> initiating the periodic re-INVITEs for his
> own use.

I disagree. In this case, neither proxies nor the UAS are interested in the
timer. Why send periodic re-INVITES if no one cares?

> 
> The combination of the recommendation that BYE
> is sent ten seconds before the end of the session
> expires and the recommendation that sessions
> be refreshed at halfway through the expiration
> period leads to the conlusion that refresh periods
> must be larger than 20 seconds. If this is an
> acceptable consequence (and I think it is), it
> should probably be stated that these refresh
> periods should be large enough to accomodate these
> plus some slop. I suggest that the draft
> recommend that timeouts are no smaller than
> 30 seconds.

Hmm. I suspect some of the more telco-ish folks might think 30s is too long
to detect failure of a call. I'll recommend 30s, but adjust the algorithm to
make sure it still works for any arbitrarily small interval.

> 
> The callflow that spans pages 11 and 12 shows
> a circumstance where the calling UA requests
> a timed session, and the SPS agrees to it.
> You say that, after 120 seconds, the calling
> UA decides not to refresh. However, since the
> called UA understands the timer and agreed to
> it (Require: timer), wouldn't he generally have
> sent a BYE after 110 seconds? Am I missing
> something?

No, you're right. I changed it to 110 seconds.

> 
> Section 8.6 shows a callflow that has no basis
> in any description of the draft.

I think you mean 8.7.

> How, for
> example, does the calling UA handle the
> 420 response? Yes, this is fairly straightforward,
> but I really think it should be outlined in
> the text of the draft.

Good point. This scenario is likely to be confusing for the
UAC. Thats because it doesn't know session timer, didn't put
a Require in the request, yet gets back a 420 Bad Extension.
I recall we discussed this on the list and several people felt
strongly about having the ability of proxies to put in Require
despite this problem.

> 
> Editorial comments:
> 
> - The first paragraph on page 4 includes the phrase
>   "UAC and UAC" -- one of these should be "UAS."

Fixed.

> - Table 1 and Table 4 should be labeled. (What
>   happend to tables 2 and 3?)

Fixed.

> - On page 8, the paragraph starting "If the final
>   response..." contans the phrase "...and the proxy
>   remembers that the proxy did not support session
>   timer..." I imagine that the second "proxy" should
>   be "client."

Fixed.

> - Section 8.4, the first message from the SPS
>   to the called UA should have a "Require" header
>   in it (I think).

No. Proxy insertion of Require is not recommended.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 30 Oct 2000 10:22:46 -0600 (CST)

> this. So, here are some comments:
...
> timer. Why send periodic re-INVITES if no one cares?

Because the *UAC* is interested in knowing if
the far side goes down. Perhaps a subtle point
that isn't even necessarily related to the draft.
 
> > in any description of the draft.

Whoops! Yes, 8.7.

> strongly about having the ability of proxies to put

Yes. If you dig back in the archives to find the
thread that started the whole session-refresh
bit, you'll find that the entire initial motivation
was to allow call-stateful proxies to have a sure-fire
way to tell whether a call is up. Remember the
proposal for the "PING" method? This is what came of
those discussions. If the final result is that
proxies cannot insist on some mechnanism to
determine liveness of a call (not just a UA -- a
*call* in particular), then this has been an
academic exercise, as far as I'm concerned.

The point I was attempting to make by this
comment is that you should probably explicitly
point out that the UAC will treat this 420 as
any other 4xx class failure, and the call will
not be set up.

> No. Proxy insertion of Require is not recommended.

"Since the proxy requires session timer..." would
seem to imply that the proxy requires (not desires)
a session timer. If the called party doesn't support
the session timer, we need to have appropriate 
handling.

I guess that this could be done by having the proxy
note whether the response from the UAS contains
the "Session-Expires" header, and adding it back
in if not present. This situation (UAS doesn't
support timer, UAC does, and proxy requires it)
probably warrants its own call flow.

In any case, shouldn't the called UA to SPS
message contain a "Required" header to indicate
that the timer is being used for this session?
I thought this was the way that feature negotiation
worked.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA