Subject: [sipcore] Session timer fix

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Oct 2017 08:37:00 +0000

Hi,

>>…
>> 
>>> I'll propose that the session timer negotiation never be done with an
>>> UPDATE within an INVITE transaction. (Regardless of whether than INVITE
>>> is negotiating a session timer or not.) I think this resolves the
>>> problem that you have encountered. (Or we could require that the UPDATE
>>> and response care consistent session timer signaling with what is
>>> carried in the INVITE and its responses.)
>> 
>> I had a chat with some product people, and they said that there actually
>> ARE cases where the session timer is negotiated using UPDATE when the
>> initial INVITE transaction is still ongoing. There are cases where the
>> INVITE only contains Supported:timer, but the actual negotiation is done
>> using UPDATE.
>
>Interesting! (I wonder why.)

I haven’t been able to figure out exactly why. I was just told the
use-case exists.

>That sequence itself presents some ambiguities. The way I have always
>described how the session timer negotiation works is that *every* INVITE
>and UPDATE transaction affects s-t - it either negotiates it *on* or
>else it negotiates it *off*. (IMO this makes it very easy to understand.)
>
>That presents issues when you have an update nested inside of an invite.
>In the case you describe I might expect that the update would negotiate
>the timer on, and then the completion of the invite would negotiate it
>off again.
>
>How would the case you describe work if a proxy inserted S-E in INVITE?
>In that case, the UAC doesn't know about it until the 2xx from the
>invite. Before then it might try enabling a timer using UPDATE.
>
>I am inclined to keep things simple by saying that the 2xx response to
>every INVITE or UPDATE redefines the state of the session timer, either
>on or off. That will of course break the use case you describe above.

The problem here is that the UAC sends INVITE with S-E, and then receives
an UPDATE with S-E before it has received a 2xx response to the INVITE -
making the UAC think that there is a S-E glare situation (i.e., the UAS
also tries to initiate session timer negotiation).

I think the RFC is pretty clear on how things work once the session timer
has been negotiated (and, if it isn’t, we for sure can clarify that too).

Regards,

Christer

>>>>
>>>> On 07/09/17 19:38, "sipcore on behalf of Christer Holmberg"
>>>> <[email-masked] on behalf of [email-masked]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>> seen from my point of view the UAC should ignore the Session timer
>>>>>>> proposal within the UPDATE.
>>>>>>> As long as the negotiation is  ongoing.
>>>>>>>
>>>>>>> Nevertheless we have also observed this curious session timer
>>>>>>> behavior
>>>>>>> in our network.
>>>>>>>
>>>>>>> I think we need some clarifications to the RFC. Perhaps also to
>>>>>>>other
>>>>>>> sections to make it more readable.
>>>>>>> My experience is that people have problems in following how the
>>>>>>> session timer should work within a complex SIP networks (e.g. IMS).
>>>>>>>
>>>>>>> What is about updating the RFC4028.
>>>>>>
>>>>>> Like most of the older SIP RFCs, it probably deserves an update. The
>>>>>> problem is whether going to the trouble will have any effect on
>>>>>> implementations. I think the most we > should hope to do is
>>>>>>*clarify*
>>>>>> in
>>>>>> cases where there is ambiguity, so that when interoperability
>>>>>>problems
>>>>>> arise it is clear who needs to change.
>>>>>
>>>>> Yes. In my case, implementation(s) WILL be changed. The question is
>>>>> WHICH
>>>>> implementation(s) :)
>>>>>
>>>>> So, my suggestion would be:
>>>>>
>>>>> 1)	Specify/clarify that SE must not be sent during session-timer
>>>>> negotiation
>>>>> 2)	Specify that one must send a 491 (or some other more appropriate
>>>>> code)
>>>>> response if receiving SE during session-timer negotiation
>>>>>
>>>>> For the above, I think we can do it using an errata.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: sipcore [mailto:[email-masked]] Im Auftrag von
>>>>>>> Christer Holmberg
>>>>>>> Gesendet: Donnerstag, 7. September 2017 11:34
>>>>>>> An: Paul Kyzivat <[email-masked]>; [email-masked]
>>>>>>> Betreff: Re: [sipcore] Session-timer issue
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>> The following issue has been around for some time already (there
>>>>>>>>>is
>>>>>>>>> also  an errata #4744), and as it causes problems (the INVITE is
>>>>>>>>> rejected with a
>>>>>>>>> 480 response) in deployed networks, so I think it needs to be
>>>>>>>>> fixed.
>>>>>>>>> People seem to have different opinions on which node is acting
>>>>>>>>> wrongly, so  I hope we can sort it out :)
>>>>>>>>
>>>>>>>> This is an interesting problem. I agree that it is unclear exactly
>>>>>>>> what ought to happen in this case. (But I don't understand why
>>>>>>>> someone thinks a 480 is a good way to resolve it.)
>>>>>>>
>>>>>>> Whether 480 is the best solution or not is not the issue, in my
>>>>>>> opinion.
>>>>>>> One could also claim that the UPDATE should be rejected. Etc.
>>>>>>>
>>>>>>> The issue is that there is a session-timer negotiation "race
>>>>>>> condition", and we should forbid that (rejecting the UPDATE could
>>>>>>>be
>>>>>>> part of such solution).
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 	Thanks,
>>>>>>>> 	Paul
>>>>>>>>
>>>>>>>>> Below is a call flow showing the problem:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> UA                Proxy                AS
>>>>>>>>>
>>>>>>>>> ------------------->
>>>>>>>>> INVITE (#1)
>>>>>>>>> Supported:timer
>>>>>>>>> SE:refresher=uac
>>>>>>>>>
>>>>>>>>>                         ------------------->
>>>>>>>>>                         INVITE (#2)
>>>>>>>>>                         Supported:timer
>>>>>>>>>                         SE:refresher=uac
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                         <-------------------
>>>>>>>>>                         18x (#3)
>>>>>>>>>
>>>>>>>>> <-------------------
>>>>>>>>> 18x (#4)
>>>>>>>>>
>>>>>>>>> ++++++ early dialog established +++++++
>>>>>>>>>
>>>>>>>>>                         <-------------------
>>>>>>>>>                         UPDATE (#5)
>>>>>>>>>                         Supported:timer
>>>>>>>>>                         SE:refresher=uas
>>>>>>>>>
>>>>>>>>> <-------------------
>>>>>>>>> UPDATE (#6)
>>>>>>>>> Supported:timer
>>>>>>>>> SE:refresher=uas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------->
>>>>>>>>> 200 (UPDATE) (#7)
>>>>>>>>>
>>>>>>>>>                         ------------------->
>>>>>>>>>                         200 (UPDATE) (#8)
>>>>>>>>>                         Require:timer
>>>>>>>>>                         SE:refresher=uac
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                         <-------------------
>>>>>>>>>                         480 (INVITE) (#9)
>>>>>>>>>
>>>>>>>>> <-------------------
>>>>>>>>> 480 (INVITE (#10)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A few things to note:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> N1:	The 18x does not contain the SE (Session-Expires) header
>>>>>>>>>field,
>>>>>>>>>             because according to section 4 of RFC 4028 the header
>>>>>>>>> field is only
>>>>>>>>>             allowed in INVITE, UPDATE and 2xx. So, when the
>>>>>>>>>UPDATE
>>>>>>>>> request
>>>>>>>>>             (#5) is sent, the initial session timer negotiation
>>>>>>>>>is
>>>>>>>>> still
>>>>>>>>>             ongoing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> N2:	The UPDATE request (#5) contains a Session-Expires header
>>>>>>>>> field.
>>>>>>>>>             Section 7.4 of RFC 4028 says:
>>>>>>>>>
>>>>>>>>> 	     "In a session refresh request sent within a dialog with an
>>>>>>>>> active
>>>>>>>>> 	      session timer, the Session-Expires header field SHOULD be
>>>>>>>>> present."
>>>>>>>>>
>>>>>>>>> 	Now, a dialog (early) HAS been established when the UPDATE
>>>>>>> request is
>>>>>>>>>             sent, but as the initial session timer negotiation is
>>>>>>>>> still
>>>>>>>>>             ongoing, I assume the session timer isn¹t yet
>>>>>>>>>"active"?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> N3:	The UPDATE 200 response (#7) does not contain the
>>>>>>>>> Session-Expires
>>>>>>>>>             header field. It is added by the proxy, based on the
>>>>>>>>> procedures in
>>>>>>>>>             Section 8.2 of RFC 4028:
>>>>>>>>>
>>>>>>>>>                  "Because there is no Session-Expires or Require
>>>>>>>>> header field
>>>>>>>>>                   in the response, the proxy knows that it is the
>>>>>>>>> first
>>>>>>>>>                   session-timer-aware proxy to receive the
>>>>>>>>>response.
>>>>>>>>> This  proxy
>>>>>>>>>                   MUST insert a Session-Expires header field into
>>>>>>>>> the
>>>>>>>>> response
>>>>>>>>>                   with the value it remembered from the forwarded
>>>>>>>>> request.
>>>>>>>>> It
>>>>>>>>> MUST
>>>>>>>>>                   set the value of The 'refresher' parameter to
>>>>>>>>> 'uac'.
>>>>>>>>> The  proxy MUST
>>>>>>>>>                   add the 'timer' option tag to any Require
>>>>>>>>>header
>>>>>>>>> field in  the
>>>>>>>>>                   response, and if none was present, add the
>>>>>>>>>Require
>>>>>>>>> header  field with
>>>>>>>>>                   that value before forwarding it upstream."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now, one could argue that the UA should include something in the
>>>>>>>>> UPDATE response (#7), but I think that is not a solution as the
>>>>>>>>>UA
>>>>>>>>> may be confused.
>>>>>>>>> Instead, based on my understanding of the text in section 7.4
>>>>>>>>>(see
>>>>>>>>> above) the UPDATE request (#5) should not contain any session
>>>>>>>>>timer
>>>>>>>>> information. This is also more or less what the errata suggests.
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Christer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sipcore mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sipcore mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sipcore mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 8 Oct 2017 18:11:49 -0400

> also tries to initiate session timer negotiation).

Yes, I understand that is the case you are thinking of. But I was 
raising a different case:

- the UAC sends an invite without a S-E.
- a proxy along the path includes an S-E. (The UAC is unaware.)
- later, the UAC sends an UPDATE with S-E.

That violates the rule in your draft, but the UAC doesn't know it has 
violated it. So your rule for avoiding the problem in this case doesn't 
work.

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 9 Oct 2017 09:34:13 +0000

Hi,
sorry but I have an further issue where we have problems with session timer.
It is the procedures of stateful Proxy Servers where we can cause a race condition.

We have made the observation that due to the rules we have race conditions with using the session timer.

The case is where we have transfer of SIP messages through an network that is not supporting session timer.

Originating network and UAC does support session timer.
Intermediate network does not support session timer
And the terminating network does support session timer.

This may result with the following call flow.

UAC           Proxy           Proxy          UAS_2
   |                           |                |
   |-- INVITE -->|             |                |
   |    SE; supp |-- INVITE -->|-- INVITE (2) ->|
   |             |    none     |    SE; supp
   |             |             |                |
   |             |             |<-- 200 (2) ----|
   |<- 18x (2) --|<- 18x (2) --|    SE 1800;
   |   SE 1800;  |             |      UAS       |
   |     UAC     |             |                |
   |-- UPDATE -->|             |                |
   |             |-- UPDATE -->| <-- UPDATE ----|
   |             |             |                |
   |             |<- UPDATE ---| --- UPDATE --->|
   |<- UPDATE ---|             |                |
   |-- 491   --->|             |<-- 491     ----|
   |             |-- 491   --->|                |
   |             |<-- 491  ----|--- 491     --->|
   |<-- 491  ----|             |                |

This will happen when the session timer has the same length.
How do we can solve such race conditions. I see the main problem within the proxy behavior and the
Forwarding of the UPDATE (or re-INVITE) for session refresh.

Of course also the choice when the refresher shall sent the refresh may solve the problem.
But if the originating and terminating network is using the same software vendor the refresh time will be the same.
So seen from that kind of algorithm is needed to generate different session refresh times.

Do you see the same problems?

Thank you and Best Regards

Roland

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Montag, 9. Oktober 2017 00:12
> An: Christer Holmberg <[email-masked]>; [email-masked]
> Betreff: Re: [sipcore] Session timer fix
>
> >>> ...
> >>>> I'll propose that the session timer negotiation never be done with
> >>>> an UPDATE within an INVITE transaction. (Regardless of whether than
> >>>> INVITE is negotiating a session timer or not.) I think this
> >>>> resolves the problem that you have encountered. (Or we could
> >>>> require that the UPDATE and response care consistent session timer
> >>>> signaling with what is carried in the INVITE and its responses.)
> >>>
> >>> I had a chat with some product people, and they said that there
> >>> actually ARE cases where the session timer is negotiated using
> >>> UPDATE when the initial INVITE transaction is still ongoing. There
> >>> are cases where the INVITE only contains Supported:timer, but the
> >>> actual negotiation is done using UPDATE.
> >>
> > I haven't been able to figure out exactly why. I was just told the
> > use-case exists.
> >
> >
> >> described how the session timer negotiation works is that *every*
> >> INVITE and UPDATE transaction affects s-t - it either negotiates it
> >> *on* or else it negotiates it *off*. (IMO this makes it very easy to
> >> understand.)
> >>
> >> In the case you describe I might expect that the update would
> >> negotiate the timer on, and then the completion of the invite would
> >> negotiate it off again.
> >>
> >> I am inclined to keep things simple by saying that the 2xx response
> >> to every INVITE or UPDATE redefines the state of the session timer,
> >> either on or off. That will of course break the use case you describe
> above.
> >
> > The problem here is that the UAC sends INVITE with S-E, and then
> > receives an UPDATE with S-E before it has received a 2xx response to
> > the INVITE - making the UAC think that there is a S-E glare situation
> > (i.e., the UAS also tries to initiate session timer negotiation).
>
> Yes, I understand that is the case you are thinking of. But I was raising a
> different case:
>
> That violates the rule in your draft, but the UAC doesn't know it has violated
> it. So your rule for avoiding the problem in this case doesn't work.
>
>       Thanks,
>       Paul
>
> > I think the RFC is pretty clear on how things work once the session
> > timer has been negotiated (and, if it isn't, we for sure can clarify that too).
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >>>>>
> >>>>> <[email-masked] on behalf of
> >>>>> mailto:[email-masked]>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>>> seen from my point of view the UAC should ignore the Session
> >>>>>>>> timer proposal within the UPDATE.
> >>>>>>>> behavior in our network.
> >>>>>>>> other sections to make it more readable.
> >>>>>>> Like most of the older SIP RFCs, it probably deserves an update.
> >>>>>>> The problem is whether going to the trouble will have any effect
> >>>>>>> on implementations. I think the most we > should hope to do is
> >>>>>>> *clarify*
> >>>>>>> in
> >>>>>>> problems arise it is clear who needs to change.
> >>>>>>
> >>>>>> Yes. In my case, implementation(s) WILL be changed. The question
> >>>>>> is WHICH
> >>>>>> implementation(s) :)
> >>>>>>
> >>>>>>>> An: Paul Kyzivat <mailto:[email-masked]>; mailto:[email-masked]
> >>>>>>>>>> The following issue has been around for some time already
> >>>>>>>>>> (there is also  an errata #4744), and as it causes problems
> >>>>>>>>>> (the INVITE is rejected with a
> >>>>>>>>>> People seem to have different opinions on which node is
> >>>>>>>>>> acting wrongly, so  I hope we can sort it out :)
> >>>>>>>>>
> >>>>>>>>> This is an interesting problem. I agree that it is unclear
> >>>>>>>>> exactly what ought to happen in this case. (But I don't
> >>>>>>>>> understand why someone thinks a 480 is a good way to resolve
> >>>>>>>>> it.)
> >>>>>>>>
> >>>>>>>> condition", and we should forbid that (rejecting the UPDATE
> >>>>>>>> could be part of such solution).
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Christer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>     Thanks,
> >>>>>>>>>     Paul
> >>>>>>>>>
> >>>>>>>>>>              because according to section 4 of RFC 4028 the
> >>>>>>>>>> header field is only
> >>>>>>>>>> UPDATE request
> >>>>>>>>>>              (#5) is sent, the initial session timer
> >>>>>>>>>> negotiation is still
> >>>>>>>>>>              ongoing.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>         "In a session refresh request sent within a dialog with
> >>>>>>>>>> an active
> >>>>>>>>>>          session timer, the Session-Expires header field SHOULD
> >>>>>>>>>> be present."
> >>>>>>>>>>
> >>>>>>>>>>              sent, but as the initial session timer
> >>>>>>>>>> negotiation is still
> >>>>>>>>>>              header field. It is added by the proxy, based on
> >>>>>>>>>> the procedures in
> >>>>>>>>>>              Section 8.2 of RFC 4028:
> >>>>>>>>>>
> >>>>>>>>>>                   "Because there is no Session-Expires or
> >>>>>>>>>> Require header field
> >>>>>>>>>>                    in the response, the proxy knows that it
> >>>>>>>>>> is the first
> >>>>>>>>>>                    MUST insert a Session-Expires header field
> >>>>>>>>>> into the response
> >>>>>>>>>>                    with the value it remembered from the
> >>>>>>>>>> forwarded request.
> >>>>>>>>>> It
> >>>>>>>>>> MUST
> >>>>>>>>>>                    set the value of The 'refresher' parameter
> >>>>>>>>>> to 'uac'.
> >>>>>>>>>> The  proxy MUST
> >>>>>>>>>> header field in  the
> >>>>>>>>>> Require header  field with
> >>>>>>>>>> Now, one could argue that the UA should include something in
> >>>>>>>>>> the UPDATE response (#7), but I think that is not a solution
> >>>>>>>>>> as the UA may be confused.
> >>>>>>>>>> timer information. This is also more or less what the errata
> >>>>>>>>>> suggests.
> >>>>>>>>>>
> >>>>>>>>>> Comments?
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Christer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> mailto:[email-masked]
> >>>>>>>>> mailto:[email-masked]
> >>>>>>>> mailto:[email-masked]
> >>>>>> mailto:[email-masked]
> >>>>> mailto:[email-masked]
> >>>> mailto:[email-masked]
> mailto:[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 10:54:45 +0000

Hi Paul,

>>>>actually
>>>INVITE
>>receives

Section 8.2 in the RFC is (in my opinon) quite messy, but as far as I
understand the proxy will never remove S-E from a response. So, we could
say that the UAC must not send UPDATE with S-E until it has received a
response to the INVITE.

Regards,

Christer

>>>>>>[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>The
>>>>>>>>>>>(there
>>>>>>>>>>exactly
>>>>>>>>>>>an
>>>>>>>>>>>negotiation is
>>>>>>>>>>>into
>>>>>>>>>>>forwarded
>>>>>>>>>>>to

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 Oct 2017 10:18:43 -0400

>     |    SE; supp |-- INVITE -->|-- INVITE (2) ->|

IIUC you are saying that Proxy1 *removes* the SE and the timer option 
from the request before forwarding it. Do I have that right?

That is more that "not supporting" session timer - that is actively 
interfering with the feature. This is non-compliant behavior for a proxy.

A correctly functioning proxy will, if it doesn't understand the option 
and the header, just pass them along as received. The procedures 
specified for session timer will work properly in that case.

	Thanks,
	Paul

> But if the originating and terminating network is using the same 
> software vendor the refresh time will be the same.
>> > timer has been negotiated (and, if it isn’t, we for sure can clarify that too).
>> >
>> > Regards,
>> >
>> > Christer
>> >
>> >
>> >
>> >
>> >
>> >>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 Oct 2017 10:26:57 -0400

Hi Christer,

> say that the UAC must not send UPDATE with S-E until it has received a

The problem is that the rfc only talks about the *final* (2xx) response. 
It has no provision for including the S-E in provisional responses. (It 
doesn't mention provisional responses, and the Table 1 update in section 
4 shows the intent is to exclude it. Hence, if the S-E is inserted into 
the INVITE by a proxy, the UAC won't know that a session timer has been 
requested until it receives the final response to the invite. Meanwhile 
it might decide send an UPDATE with S-E.

	Thanks,
	Paul

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 9 Oct 2017 14:41:09 +0000

Hi Paul,
Of course I follow your argumentation. i.E. either act properly or forward the Session timer as received.
For the described scenario
sorry that I confused everybody with an incomplete picture.
I missed to state that the transit network which is passing through the call is deleting the session timer since it does not support it.

     Originating                     transit                      terminating
UAC           Proxy1 netA   Proxy2 netB    Proxy3 netB    Proxy4 netC         UAS
   |                           |                |             |                |
   |-- INVITE -->|             |                |             |                |
   |    SE; supp |-- INVITE -->|-- INVITE ----->|-- INVITE -->|-- INVITE (2) ->|
   |             |    SE; supp |    none        |  none       |    SE; supp    |
   |             |             |                |             |                |
   |             |             |<-- 200 (2) ----|<-- 200 (2) -|<--- 200 (2) ---|
   |<- 18x (2) --|<- 18x (2) --|                |  SE 1800;   |   SE 1800;     |
   |   SE 1800;  |             |                |   UAS       |      UAS       |
   |     UAC     |             |                |             |                |
   |-- UPDATE -->|             |                |             |                |
   |             |-- UPDATE -->| <-- UPDATE ----|<-- UPDATE --|<-- UPDATE -----|
   |             |             |                |
   |             |<- UPDATE ---| --- UPDATE --->|--- UPDATE ->|--- UPDATE ---->|
   |<- UPDATE ---|             |                |             |                |
   |-- 491   --->|             |<-- 491     ----|<-- 491  ----|<-- 491  -------|
   |             |-- 491   --->|                |             |                |
   |             |<-- 491  ----|--- 491     --->|<-- 491  --->|--- 491  ------>|
   |<-- 491  ----|             |                |             |                |

NetA and NetC does support session timer.
NetB does not.
So Proxy 2 netB will delete the session timer while Proxy 4 netC will include it again since this is allowed by RFC4028.
On the other way back Proxy3 NetB will delete the information and Proxy1 NetA will include it again.

This will happen when the statefull Proxy rule with session timer support will be implemented.

I hope now it is clear about what scenario I'm talking

Best Regards

Roland

> Gesendet: Montag, 9. Oktober 2017 16:19
> An: Jesske, Roland <[email-masked]>; Christer Holmberg
> <[email-masked]>; [email-masked]
> > Intermediate network does not support session timer And the
> > terminating network does support session timer.
> IIUC you are saying that Proxy1 *removes* the SE and the timer option from
> the request before forwarding it. Do I have that right?
>
> That is more that "not supporting" session timer - that is actively interfering
> with the feature. This is non-compliant behavior for a proxy.
>
> A correctly functioning proxy will, if it doesn't understand the option and the
> header, just pass them along as received. The procedures specified for
> session timer will work properly in that case.
>
>       Thanks,
>       Paul
>
>
> >     |             |             |                |
> >     |             |             |<-- 200 (2) ----|
> >     |<-- 491 ----|             |                | This will happen
> > when the session timer has the same length.
> > How do we can solve such race conditions. I see the main problem
> > within the proxy behavior and the Forwarding of the UPDATE (or
> > re-INVITE) for session refresh.
> >> An: Christer Holmberg <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>
> >> >>>> I'll propose that the session timer negotiation never be done
> >> >>>> with an UPDATE within an INVITE transaction. (Regardless of
> >> >>>> whether than INVITE is negotiating a session timer or not.) I
> >> >>>> think this resolves the problem that you have encountered. (Or
> >> >>>> we could require that the UPDATE and response care consistent
> >> >>>> session timer signaling with what is carried in the INVITE and
> >> >>>> its responses.)
> >> >>>
> >> >>> UPDATE when the initial INVITE transaction is still ongoing.
> >> >>> There are cases where the INVITE only contains Supported:timer,
> >> >>> but the actual negotiation is done using UPDATE.
> >> >>
> >> >> That sequence itself presents some ambiguities. The way I have
> >> >> always described how the session timer negotiation works is that
> >> >> *every* INVITE and UPDATE transaction affects s-t - it either
> >> >> negotiates it
> >> >> negotiate the timer on, and then the completion of the invite
> >> >> would negotiate it off again.
> >> >>
> >> >> I am inclined to keep things simple by saying that the 2xx
> >> >> response to every INVITE or UPDATE redefines the state of the
> >> >> session timer, either on or off. That will of course break the use
> >> >> case you describe
> >> above.
> >> >
> >> > receives an UPDATE with S-E before it has received a 2xx response
> >> > to the INVITE - making the UAC think that there is a S-E glare
> >> > situation (i.e., the UAS also tries to initiate session timer negotiation).
> >>
> >> violated it. So your rule for avoiding the problem in this case doesn't work.
> >>
> >>        Thanks,
> >>        Paul
> >>
> >> >>>>>>>> Nevertheless we have also observed this curious session
> >> >>>>>>>> timer behavior in our network.
> >> >>>>>>>>
> >> >>>>>>>> I think we need some clarifications to the RFC. Perhaps also
> >> >>>>>>>> to other sections to make it more readable.
> >> >>>>>>>> My experience is that people have problems in following how
> >> >>>>>>>> the session timer should work within a complex SIP networks
> (e.g.
> >> IMS).
> >> >>>>>>>>
> >> >>>>>>> The problem is whether going to the trouble will have any
> >> >>>>>>> effect on implementations. I think the most we > should hope
> >> >>>>>>> to do is
> >> >>>>>>> *clarify*
> >> >>>>>>> in
> >> >>>>>> Yes. In my case, implementation(s) WILL be changed. The
> >> >>>>>> question is WHICH
> >> >>>>>> implementation(s) :)
> >> >>>>>>
> >> >>>>>> 1)     Specify/clarify that SE must not be sent during
> >> >>>>>> session-timer negotiation
> >> >>>>>>>> Von: sipcore [mailto:[email-masked]] Im Auftrag
> >> >>>>>>>> von Christer Holmberg
> >> >>>>>>>>>> (there is also  an errata #4744), and as it causes
> >> >>>>>>>>>> problems (the INVITE is rejected with a
> >> >>>>>>>>>> 480 response) in deployed networks, so I think it needs to
> >> >>>>>>>>>> be fixed.
> >> >>>>>>>> Whether 480 is the best solution or not is not the issue, in
> >> >>>>>>>> my opinion.
> >> >>>>>>>>>> N1:        The 18x does not contain the SE
> >> >>>>>>>>>> (Session-Expires)
> >> header
> >> >>>>>>>>>> field,
> >> >>>>>>>>>>              because according to section 4 of RFC 4028
> >> >>>>>>>>>>the  header field is only
> >> >>>>>>>>>>              allowed in INVITE, UPDATE and 2xx. So, when
> >> >>>>>>>>>>the  UPDATE request
> >> >>>>>>>>>> N2:        The UPDATE request (#5) contains a
> >> >>>>>>>>>> Session-Expires
> >> header
> >> >>>>>>>>>> field.
> >> >>>>>>>>>>          "In a session refresh request sent within a
> >> >>>>>>>>>>dialog with  an active
> >> >>>>>>>>>>           session timer, the Session-Expires header field
> >> >>>>>>>>>>SHOULD  be present."
> >> >>>>>>>>>>
> >> >>>>>>>>>> N3:        The UPDATE 200 response (#7) does not contain
> >> >>>>>>>>>>the  Session-Expires
> >> >>>>>>>>>>              header field. It is added by the proxy, based
> >> >>>>>>>>>>on  the procedures in
> >> >>>>>>>>>>              Section 8.2 of RFC 4028:
> >> >>>>>>>>>>
> >> >>>>>>>>>>                    in the response, the proxy knows that
> >> >>>>>>>>>>it  is the first
> >> >>>>>>>>>>                    session-timer-aware proxy to receive
> >> >>>>>>>>>>the  response.
> >> >>>>>>>>>> This  proxy
> >> >>>>>>>>>>                    MUST insert a Session-Expires header
> >> >>>>>>>>>>field  into the response
> >> >>>>>>>>>>                    set the value of The 'refresher'
> >> >>>>>>>>>>parameter  to 'uac'.
> >> >>>>>>>>>> The  proxy MUST
> >> >>>>>>>>>>                    add the 'timer' option tag to any
> >> >>>>>>>>>>Require  header field in  the
> >> >>>>>>>>>>                    response, and if none was present, add
> >> >>>>>>>>>>the  Require header  field with
> >> >>>>>>>>>> Now, one could argue that the UA should include something
> >> >>>>>>>>>> in the UPDATE response (#7), but I think that is not a
> >> >>>>>>>>>> solution as the UA may be confused.
> >> >>>>>>>>>> Instead, based on my understanding of the text in section
> >> >>>>>>>>>> 7.4 (see
> >> >>>>>>>>>> timer information. This is also more or less what the
> >> >>>>>>>>>> errata suggests.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Comments?
> >> >>>>>>>>>>
> >> >>>>>>>>>> Regards,
> >> >>>>>>>>>>
> >> >>>>>>>>>> Christer
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 16:01:21 +0000

Hi Roland,

I don't think it was unclear that S-E is removed by the transit network - at least it was not unclear to me :)

However, your latest call flow is confusing. First, there is a 18x with S-E, which is not allowed.

Second, the UPDATEs and 491 seem messed up, so it's really difficult to parse what is going on, and in what order.

Regards,

Christer

From: Jesske, Roland [mailto:[email-masked]]
Sent: 09 October 2017 16:41
To: Paul Kyzivat <[email-masked]>; Christer Holmberg <[email-masked]>; [email-masked]
Subject: AW: [sipcore] Session timer fix

Hi Paul,

Best Regards

Roland

> An: Jesske, Roland <[email-masked]<mailto:[email-masked]>>; Christer Holmberg
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 16:05:15 +0000

Hi,

>> understand the proxy will never remove S-E from a response. So, we 
>> could say that the UAC must not send UPDATE with S-E until it has 
>> received a response to the INVITE.
>
> It has no provision for including the S-E in provisional responses. (It doesn't mention provisional responses, and the Table 1 update in section
> 4 shows the intent is to exclude it. Hence, if the S-E is inserted into the INVITE by a proxy, the UAC won't know that a session timer has been requested until it receives the > final response to the invite. Meanwhile it might decide send an UPDATE with S-E.

My suggestion is that the UAC would not be allowed to send UPDATE with S-E until it has received the final response for the INVITE. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 16:06:10 +0000

Ok, when looking at your flow, I assume that the UPDATEs pass each other, hence creating the race condition.

But, still, are you sending S-E in 18x, or is that a mistake in the flow?

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 09 October 2017 18:01
To: Jesske, Roland <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Session timer fix

Hi Roland,

Regards,

Christer

From: Jesske, Roland [mailto:[email-masked]]
Sent: 09 October 2017 16:41
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: AW: [sipcore] Session timer fix

Hi Paul,

Best Regards

Roland

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 Oct 2017 12:17:53 -0400

Hi Roland,

On 10/9/17 10:41 AM, Jesske, Roland wrote:

> So Proxy 2 netB will delete the session timer

Let me repeat: this is not valid behavior for a proxy.
The proper fix is for Proxy 2 to do what it is required to do by the specs.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 9 Oct 2017 14:04:10 -0400

Christer,

> My suggestion is that the UAC would not be allowed to send UPDATE with S-E until it has received the final response for the INVITE.

This is more or less the original proposal that was shot down. Or do you 
mean that the *UAC* is restricted that way, but the *UAS* is permitted 
to use S-E to negotiate session timer in the midst of the INVITE, at 
least in some cases?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 18:36:19 +0000

Hi,

>>>>> That violates the rule in your draft, but the UAC doesn't know it 
>>>>> has violated it. So your rule for avoiding the problem in this case 
>>>>> doesn't work.
>>>>
>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far as 
>>>> I understand the proxy will never remove S-E from a response. So, we 
>>> It has no provision for including the S-E in provisional responses. 
>>> (It doesn't mention provisional responses, and the Table 1 update in 
>>> section
>>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted into the INVITE by a proxy, the UAC won't 
>>> know that a session timer has been requested until it receives the final response to the invite. Meanwhile 
> This is more or less the original proposal that was shot down. 

DOH! You're right :)

> Or do you mean that the *UAC* is restricted that way, but the *UAS* is permitted to use S-E to negotiate 
> session timer in the midst of the INVITE, at least in some cases?

I was mostly thinking about the UAC, but I think it could apply to the UAS too.

One option would be to allow S-E in 18x.

Need to think a little more.

Regards,

Christer

---

From: Keith Drage <[email-masked]>
Date: Thu, 12 Oct 2017 16:51:53 +0100

On this specific point I agree with Paul.

If you want to describe a problem for a B2BUA then do so, but the proper 
behaviour for a proxy is to pass the information on, whether it supports 
the feature, or does not and therefore does not recognise the information.

In regard to the Supported header, this is meant to be a statement about 
what the original generator of the header supports, not some 
intermediate along the path (although I know Supported header fields can 
be generated along the path). Therefore I do not believe there is a case 
for a proxy deleting information from such a header field.

regards

Keith

---

From: "Jesske, Roland" <[email-masked]>
Date: Thu, 19 Oct 2017 02:41:06 +0000

Thank you for your discussion.
Yes this is true, looking into the scenario again it is passed through an B2BUA.
And not via a proxy.

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Keith Drage
> Gesendet: Donnerstag, 12. Oktober 2017 17:52
> An: [email-masked]
> behaviour for a proxy is to pass the information on, whether it supports the
> feature, or does not and therefore does not recognise the information.
> 
> In regard to the Supported header, this is meant to be a statement about what
> the original generator of the header supports, not some intermediate along the
> path (although I know Supported header fields can be generated along the
> path). Therefore I do not believe there is a case for a proxy deleting
> information from such a header field.
> 
> regards
> 
> Keith
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Oct 2017 12:31:52 +0000

Hi,

>>> 4 shows the intent is to exclude it. Hence, if the S-E is inserted
>>>into the INVITE by a proxy, the UAC won't know that a session timer has
>>>been requested until it receives the > final response to the invite.
>>>Meanwhile it might decide send an UPDATE with S-E.
>> 
>> My suggestion is that the UAC would not be allowed to send UPDATE with
>>S-E until it has received the final response for the INVITE.
>

I have been thinking about this, talked to some people etc, and perhaps
the easiest solution would be to now allow UPDATE with S-E during an
active INVITE transaction (as suggested above).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2017 10:51:52 -0400

> active INVITE transaction (as suggested above).

I have now gotten lost in the propossals and counter proposals. Can you 
explicitly state what you are proposing?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Oct 2017 16:06:35 +0000

Hi,

I am proposing that it is not allowed to include S-E in an UPDATE while there is an ongoing INVITE transaction.

Regards,

Christer 

Sent from my iPhone

> On 27 Oct 2017, at 17.51, Paul Kyzivat <[email-masked]> wrote:
> 
> I have now gotten lost in the propossals and counter proposals. Can you explicitly state what you are proposing?
> 
>    Thanks,
>    Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Oct 2017 15:41:22 -0400

> there is an ongoing INVITE transaction.

I think that is a good solution as long as we can resolve any backward 
compatibility issues with existing deployments. I gather we have one, 
but it is what identified the problem and so it needs to change anyway.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> Sent from my iPhone
> 
> On 27 Oct 2017, at 17.51, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> I have now gotten lost in the propossals and counter proposals. Can 
>> you explicitly state what you are proposing?
>>
>>    Thanks,
>>    Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 19:47:33 +0000

Hi,

>> I am proposing that it is not allowed to include S-E in an UPDATE 
>> while there is an ongoing INVITE transaction.
>
> I think that is a good solution as long as we can resolve any backward compatibility issues 
> with existing deployments. I gather we have one, but it is what identified the problem and 
> so it needs to change anyway.

Well, the reason we do this exercise is because some of the existing deployments are broken (or, the spec they are based on is broken/unclear), so we can only hope they will be fixed.

But, at least based on the original problem case I solved, the fix would have to be done in a network device (the one sending UPDATE with S-E while the INVITE transaction is still ongoing) - which is much easier than having to fix a large bunch of SIP UAs.

Regards,

Christer

>>>>>>>> Yes, I understand that is the case you are thinking of. But I 
>>>>>>>> was raising a different case:
>>>>>>>>
>>>>>>>> That violates the rule in your draft, but the UAC doesn't know 
>>>>>>>> it has violated it. So your rule for avoiding the problem in 
>>>>>>>> this case doesn't work.
>>>>>>>
>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as far 
>>>>>>> as I understand the proxy will never remove S-E from a response. 
>>>>>>> So, we could say that the UAC must not send UPDATE with S-E 
>>>>>>> until it has received a response to the INVITE.
>>>>>>
>>>>>> (It doesn't mention provisional responses, and the Table 1 update 
>>>>>> in section
>>>>>> 4 shows the intent is to exclude it. Hence, if the S-E is 
>>>>>> inserted into the INVITE by a proxy, the UAC won't know that a 
>>>>>> session timer has been requested until it receives the > final 
>>>>>> response to the invite.
>>>>> My suggestion is that the UAC would not be allowed to send UPDATE 
>>>>> with S-E until it has received the final response for the INVITE.
>>>>
>>>> This is more or less the original proposal that was shot down. Or 
>>>> do you mean that the *UAC* is restricted that way, but the *UAS* is 
>>>> permitted to use S-E to negotiate session timer in the midst of the 
>>>> INVITE, at least in some cases?
>>> I have been thinking about this, talked to some people etc, and 
>>> perhaps the easiest solution would be to now allow UPDATE with S-E 
>>> during an active INVITE transaction (as suggested above).
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Oct 2017 17:03:26 -0400

> But, at least based on the original problem case I solved, the fix would have to be done in a network device (the one sending UPDATE with S-E while the INVITE transaction is still ongoing) - which…

OK. If you go with this approach, it is important for the update to the 
spec to be clear that an UPDATE (without S-E) in the midst of a INVITE 
transaction *does not* impact the status of the the timer being 
negotiated by the INVITE or one that was in effect prior to the INVITE.

(Because normally an UPDATE or re-INVITE without S-E removes any timer 
that is in effect.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 21:18:52 +0000

Hi,

>>> I think that is a good solution as long as we can resolve any 
>>> backward compatibility issues with existing deployments. I gather we 
>>> have one, but it is what identified the problem and so it needs to change anyway.
>> 
>> Well, the reason we do this exercise is because some of the existing deployments are broken 
>> (or, the spec they are based on is broken/unclear), so we can only hope they will be fixed.
>> 
>> But, at least based on the original problem case I solved, the fix would have to be done in a 
>> network device (the one sending UPDATE with S-E while the INVITE transaction is still ongoing) - 
>> which is much easier than having to fix a large bunch of SIP UAs.
>
> OK. If you go with this approach, it is important for the update to the spec to be clear that an UPDATE (without S-E) 
> in the midst of a INVITE transaction *does not* impact the status of the the timer being negotiated by the INVITE or 
> one that was in effect prior to the INVITE.
>
> (Because normally an UPDATE or re-INVITE without S-E removes any timer that is in effect.)

Correct.

Regards,

Christer

>>>>>>>> Section 8.2 in the RFC is (in my opinon) quite messy, but as 
>>>>>>>> far as I understand the proxy will never remove S-E from a response.
>>>>>>> (It doesn't mention provisional responses, and the Table 1 
>>>>>>> update in section
>>>>> do you mean that the *UAC* is restricted that way, but the *UAS* 
>>>>> is permitted to use S-E to negotiate session timer in the midst of 
>>>>> the INVITE, at least in some cases?

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Oct 2017 12:24:02 +0000

Hi,

>>>compatibility issues
>> Well, the reason we do this exercise is because some of the existing
>>deployments are broken (or, the spec they are based on is
>>broken/unclear), so we can only hope they will be fixed.
>> 
>> But, at least based on the original problem case I solved, the fix
>>would have to be done in a network device (the one sending UPDATE with
>>S-E while the INVITE transaction is still ongoing) - which is much
>>easier than having to fix a large bunch of SIP UAs.
>

I am not sure that is correct.

Section 4 says:

    "The default value of the Session-Expires header field is undefined.
     This means that the absence of the Session-Expires header field
     implies no expiration of the session, using the mechanism defined in
     this specification."

My understanding is that the timer can only be removed by not including
S-E in a response, as said in section 7.2:

     "If the 2xx response did not contain a Session-Expires header field,
      there is no session expiration.  In this case, no refreshes need to
      be sent.  A 2xx without a Session-Expires can come for both initial
      and subsequent session refresh requests.  This means that the session
      timer can be 'turned-off' in mid dialog by receiving a response
      without a Session-Expires header field.²

The draft DOES update that paragraph, by saying that it only applies if
the associated request did contain S-E.

Regards,

Christer

---

From: "Jesske, Roland" <[email-masked]>
Date: Mon, 30 Oct 2017 13:32:21 +0000

Hi Christer,

You state with regard to turning off the session timer that:
The draft DOES update that paragraph, by saying that it only applies if the associated request did contain S-E.

For this I fully agree. And this issue is clarified.

Then I see the statement from Paul: "Because normally an UPDATE or re-INVITE without S-E removes any timer that is in effect." Where you also agree.
 
I do not think that this is correct. I think it depends on the SIP field "supported timer". As long as there is an "supported: timer" within an UPDATE or Re-INVITE it is the task of the UAS to agree on a Session refresh or not.
Only the case where the UAS does not sent the S-E then I would say the session timer is turned off.

I do not find any statement in Section 7.4 stating that.

Or did I missed something or have I overread something in you discussion? 

Best Regards

Roland

> Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer
> Holmberg
> Gesendet: Montag, 30. Oktober 2017 13:24
> An: Paul Kyzivat <[email-masked]>
> Cc: [email-masked]
> My understanding is that the timer can only be removed by not including S-E in
> a response, as said in section 7.2:
> 
> The draft DOES update that paragraph, by saying that it only applies if the
> associated request did contain S-E.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> >>> Sent from my iPhone
> >>>
> >>>>>>>>>> That violates the rule in your draft, but the UAC doesn't
> >>>>>>>>>> know it has violated it. So your rule for avoiding the
> >>>>>>>>>> problem in this case doesn't work.
> >>>>>>>>>
> >>>>>>> My suggestion is that the UAC would not be allowed to send
> >>>>>>> UPDATE with S-E until it has received the final response for the
> INVITE.
> >>>>>>
> >>>>>> is permitted to use S-E to negotiate session timer in the midst
> >>>>>> of the INVITE, at least in some cases?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Oct 2017 10:37:41 -0400

>        without a Session-Expires header field.²

Yes, my comment was a bit imprecise. The the potential impact is the same.

Consider the case where the UAC and UAS both *support* session timer, 
but neither of them have any particular desire to enable one. (The 
purpose of announcing support is so proxies can enable it.) In the 
absence of proxy requests, there will be no S-E in either the request or 
the response and so no timer.

Then consider where there is a proxy that inserts the S-E. That starts a 
timer. Later, on a reINVITE, I would expect the UAC to again insert no 
S-E. If the proxy has lost the interest in the timer and doesn't insert 
S-E, then it will arrive at the UAS without.The UAS will presumably 
respond with no S-E and the timer will be cancelled. The same is true if 
you replace the reINVITE with UPDATE.

The above is assuming the UPDATE is outside of an INVITE transaction. So 
now consider the same behaviors applied to an UPDATE within an INVITE 
transaction. Assume again that the UAC and UAS have no self interest in 
having a timer, but are willing to support a proxy who does. If no proxy 
adds S-E, then I think we need clarification that this doesn't cancel 
the timer being negotiated in the INVITE. (This might be obvious, but is 
still worth saying.)

And, then I think the update needs to spell out the updated behavior for 
proxies - that they too can't put an S-E into the UPDATE in this case. 
But then we have to worry about situations where some proxy on the path 
doesn't implement the update, and automatically inserts S-E into every 
INVITE and UPDATE it sees.

	Thanks,
	Paul