Subject: Re: [sipcore] Session-timer issue

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 12:08:07 +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.

In the example below, it seems like the UAC DOES ignore it, since it
doesn’t included anything in the response. However, the Proxy adds the
information. To prevent that, the UA would have to reject the UPDATE.
Perhaps with a 491 response?

I think one reason for the confusion is that RFC 4028 *DOES* say that the
SE header field should be included in session refresh requests. I think we
need to clarify that it shall not happen 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.

I wonder whether we’d find the people and energy for working on a bis :) I
HOPE we are able to make any needed corrections (once we agree what those
would be) 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

---

From: <[email-masked]>
Date: Wed, 13 Sep 2017 12:52:22 +0000

Hi Christer,
I fully support your draft and I'm also willing to work on it.
Due to the fact that we have also problems with the Session Timer which will be solved with your proposals.

Best Regards

Roland

> Von: Christer Holmberg [mailto:[email-masked]]
> Gesendet: Donnerstag, 7. September 2017 14:08
> An: Jesske, Roland <[email-masked]>; [email-masked];
> [email-masked]
> Betreff: Re: AW: [sipcore] Session-timer issue
> 
> Hi,
> 
> In the example below, it seems like the UAC DOES ignore it, since it doesn't
> included anything in the response. However, the Proxy adds the information.
> To prevent that, the UA would have to reject the UPDATE.
> I think one reason for the confusion is that RFC 4028 *DOES* say that the SE
> header field should be included in session refresh requests. I think we need
> to clarify that it shall not happen as long as the negotiation is ongoing.
> 
> >Nevertheless we have also observed this curious session timer behavior
> >in our network.
> >
> I wonder whether we'd find the people and energy for working on a bis :) I
> HOPE we are able to make any needed corrections (once we agree what
> those would be) 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.)
> >>
> >>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
> >> >>               "Because there is no Session-Expires or Require
> >> >>header field
> >> >>                add the 'timer' option tag to any Require header
> >> >>field in  the
> >> >> 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
> >> >>
> >> >>