Subject: [sipcore] Session-timer issue

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Sep 2017 11:06:52 +0000

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 :)

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Sep 2017 11:27:56 -0400

> 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.)

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 09:33:51 +0000

Hi,

>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

---

From: <[email-masked]>
Date: Thu, 7 Sep 2017 11:30:44 +0000

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. 

Best Regards

Roland

> -----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
> >> People seem to have different opinions on which node is acting
> >>wrongly, so  I hope we can sort it out :)
> >
> >ought to happen in this case. (But I don't understand why someone
> >thinks a 480 is a good way to resolve it.)
> 
> 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
> >
> >>                session-timer-aware proxy to receive the response.
> >>This  proxy
> >>                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
> >> above) the UPDATE request (#5) should not contain any session timer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 7 Sep 2017 12:10:56 -0400

> 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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 16:38:27 +0000

Hi,

> 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

>> Von: sipcore [mailto:[email-masked]] Im Auftrag von 
>> Christer Holmberg
>>> 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.)
>>
>> 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
>>>
>>>>                 add the 'timer' option tag to any Require header 
>>>> field in  the