Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt

From: "Robin Escolme" <[email-masked]>
Date: Thu, 2 Nov 2000 15:44:48 +0000

Hi,

Some comments and questions :

   Section 5.2, CASE I - UAC supports session timers. The text states "In this
   case the proxy remembers that it inserted a Session-Expires header into the
   request and that the UAC supported sesion timer". The proxy may not have
   inserted a Session-Expires header - it would only have done so if the there
   wasn't one in the request from the UAC.
   CASE II - UAC Doesn't support, UAS doesn't support. There is, presumably,
   nothing to stop the proxy, if its policy dictates, from running a local
   session timer, the expiration of which would result in it de-allocating any
   resources - and in particular, closing any pin-holes opened across a
   firewall, with no indication at all to the end points. Whilst this isn't very
   nice for the end points, since their RTP packets would suddenly cease, the
   proxy is trying to protect it's network resources from unreliable end-points.
   The session timer used be longer that normal, given there is no opportunity
   to refresh. Alternatively, cannot the proxy issue a re-INVITE to each UA,
   using the same SDP used orginally?
   Section 6, Para 2 states "If the the UAS places a Session-Expires header into
   the response, and the request contained a Supported header with the value
   "timer",.......". This implies that the UAS may place a Session-Espires
   header into the response when the request did not contain a Supported header
   with the value "timer". However,  the table further down says that if the
   request contained neither a Supported header with the value "timer", nor a
   Session-Expires header, there there will be no timers. Surely, if the UAS
   supports session timers it can place a Session-Expires header in the
   response, so that it indicates to proxies that it is running a session timer.
   If this is the case, then the behavoir in the foirst row of this table should
   indicate that the UAS MAY add a session-Expires header to the response. This
   then equates to CASE III in section 5.2.
   Section 6, last para suggests that a 200 OK in response to a re-INVITE may
   not contain a Session-Expire header. How can this be, unless a proxy or the
   UAC has removed it, which I thought was not allowed?
   Section 8.5 - call flow for re-INVITE. The Calling UA send the INVITE to the
   SPS with a Session-Expires header. The note against the next message, INVITE
   from SPS to Called UA says the SPS adds the S-E header, but it was already
   there.
   General - ther terms UAC and UAS I have taken to be synonymous with Calling
   UAC and Called UAC, respectively. The document makes use of both terms at
   varying times. Are these terms interchangeable or is there some implied
   difference.
   Section 9 of RFC2543bis02 lists abbreviated forms for common header fields.
   The session timer feature is valuable and may be insisted upon by many
   networks, bringing the Session Expires header into common use. You should
   consider an abbreviated form.

Hope these make sense.

Robin Escolme

Marconi Communications

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

---

From: "Singh, Manish" <[email-masked]>
Date: Thu, 2 Nov 2000 12:17:08 -0800

Hi,

Sectoin 4, UAC behavior states :

"Note that it is possible that the calling UA is generating
refreshes, and then it receives a re-INVITE. After following
the rules for UAS described below, the calling UA now determines
it is not supposed to generate refreshes..........."

Is their a specific reason for allowing the master switchover
for generating the re-INVITES? After the initial negotation, if
the UAC was responsible for generating re-INVITES, why would UAS
in the middle of a session like to take control? 

Can we add an Example flow for this scenario in section 8 of the
draft. 

-Thanks,
Manish Singh

-----Original Message-----
From: Robin Escolme [mailto:[email-masked]]
Sent: Thursday, November 02, 2000 7:45 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt

Hi,

   Section 5.2, CASE I - UAC supports session timers. The text states "In
this
   case the proxy remembers that it inserted a Session-Expires header into
the
   request and that the UAC supported sesion timer". The proxy may not have
   inserted a Session-Expires header - it would only have done so if the
there
   wasn't one in the request from the UAC.
   CASE II - UAC Doesn't support, UAS doesn't support. There is, presumably,
   nothing to stop the proxy, if its policy dictates, from running a local
   session timer, the expiration of which would result in it de-allocating
any
   resources - and in particular, closing any pin-holes opened across a
   firewall, with no indication at all to the end points. Whilst this isn't
very
   nice for the end points, since their RTP packets would suddenly cease,
the
   proxy is trying to protect it's network resources from unreliable
end-points.
   The session timer used be longer that normal, given there is no
opportunity
   to refresh. Alternatively, cannot the proxy issue a re-INVITE to each UA,
   using the same SDP used orginally?
   Section 6, Para 2 states "If the the UAS places a Session-Expires header
into
   the response, and the request contained a Supported header with the value
   "timer",.......". This implies that the UAS may place a Session-Espires
   header into the response when the request did not contain a Supported
header
   with the value "timer". However,  the table further down says that if the
   request contained neither a Supported header with the value "timer", nor
a
   Session-Expires header, there there will be no timers. Surely, if the UAS
   supports session timers it can place a Session-Expires header in the
   response, so that it indicates to proxies that it is running a session
timer.
   If this is the case, then the behavoir in the foirst row of this table
should
   indicate that the UAS MAY add a session-Expires header to the response.
This
   then equates to CASE III in section 5.2.
   Section 6, last para suggests that a 200 OK in response to a re-INVITE
may
   not contain a Session-Expire header. How can this be, unless a proxy or
the
   UAC has removed it, which I thought was not allowed?
   Section 8.5 - call flow for re-INVITE. The Calling UA send the INVITE to
the
   SPS with a Session-Expires header. The note against the next message,
INVITE
   from SPS to Called UA says the SPS adds the S-E header, but it was
already
   there.
   General - ther terms UAC and UAS I have taken to be synonymous with
Calling
   UAC and Called UAC, respectively. The document makes use of both terms at
   varying times. Are these terms interchangeable or is there some implied
   difference.
   Section 9 of RFC2543bis02 lists abbreviated forms for common header
fields.
   The session timer feature is valuable and may be insisted upon by many
   networks, bringing the Session Expires header into common use. You should
   consider an abbreviated form.

Hope these make sense.

Robin Escolme

Marconi Communications

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Nov 2000 02:51:53 -0500

> From: Singh, Manish [mailto:[email-masked]]
> Sent: Thursday, November 02, 2000 3:17 PM
> To: 'Robin Escolme'; Jonathan Rosenberg
> Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-session-timer-03.txt
> 
> 
> Hi,
> 

The idea was just to make the whole process stateless, so that processing of
a re-INVITE is absolutely the same as processing the initial INVITE. As a
result of this choice, the roles will change over on re-INVITEs depending on
what level of support each side has. If each side both supports session
timer, the user sending the re-INVITE will become the one performing
refreshes if the re-invite completes successfully.

The stateless operation is needed, for example, to recover from crash-reboot
cycles.

I think this actually makes the implementation simpler, not more complex.

> Can we add an Example flow for this scenario in section 8 of the

I will add text explaining the above, and also an example flow.

-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

---

From: "Singh, Manish" <[email-masked]>
Date: Fri, 3 Nov 2000 10:30:02 -0800

Hi :

Thanks for the response.

Another concern, section 5 states -

"Session expiration are mostly of interest to call stateful
proxy servers. However, a stateful proxy server MAY also follow
the rules described here"

Shouldn't it be mandated by the draft that, if a stateful proxy
(transaction stateful case) server is starting a Session Timer, 
it MUST insert a "Record-Route" header in the Invite, prior to 
proxying it.

Since, the procedure is symmetric, i.e. UAS can send a Re-Invite 
and become the master, to avoid such proxies being missed out and
later timing out, it MUST be on the path.

Also, is there any example when a transaction stateful only
proxy would like to start a session timer?

-Regards,
Manish Singh

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 05:20:35 -0500

Finally getting around to this.... sorry for the delay:

> Sent: Thursday, November 02, 2000 10:45 AM
> To: Jonathan Rosenberg

I rewrote the text for CASE I. There are actually two sub-cases. One is when
the proxy is the one closest to the UAS (in which case it inserts
Session-TImer and Require into the response), and the other case is for all
other proxies. For those proxies, this case is indistinguishable from CASE
IV.

>    using the same SDP used orginally?

No, it cannot. Proxies do not initiate requests except for ACK and CANCEL. 

If the proxy wants to run a local timer on its own, well, thats its own
choice. There are no protocol implications of that, and it has nothing to do
with this session timer specification. Thus, I see no need to discuss it
here.

>    then equates to CASE III in section 5.2.

Yes, you are correct. I have updated the table.

>    UAC has removed it, which I thought was not allowed?

No; the case is when the proxies change their mind and decide that they no
longer want session timer. In this case, the re-invite had a supported
header, but no session-expires. No proxies were interested, so none inserted
session-expires. UAS doesn't support, so the response has no
session-expires, no Require. I added a sentence explaining when this
happens.

>    from SPS to Called UA says the SPS adds the S-E header, 

Copy-paste error. Fixed.

>    varying times. Are these terms interchangeable or is there 

THe roles of UAC and UAS are on a transaction by transaction basis. The
initiator of a request is the UAS. Recipient is UAS. Caller and called party
reflect the initial invite request. I believe the terms are used consistent
with this definition. This definition is the one present in rfc2543.

>    consider an abbreviated form.

Good idea. I've taken 'x', for eXpires.

Thanks for your comments,

Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 05:26:58 -0500

> Sent: Friday, November 03, 2000 1:30 PM
> To: 'Jonathan Rosenberg'; Singh, Manish; 'Robin Escolme'

No. Its not useful to the proxy to ask for a session timer and then not
record-route, but nothing breaks if you don't. I'll mention that its silly
not to.

> proxy would like to start a session timer?

Protocol processing has nothing to do with whether you are transaction
stateful or call stateful. This fact is hidden from anyone outside of the
proxy. Any of the flows, as a result, are the same for both cases.

Thanks,
Jonathan R.
---