Subject: Re: [sipcore] Session timer fix

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Oct 2017 14:20:18 +0000

Hi,

>So for the second case:
>If I send an session refresh without S-E and receive a response with S-E
>--> still session timer switched on.

Yes (at least that is my understanding of the text).

>And only in the case S-E in request and response absent then --> Session
>timer switched off.
>
>Yes?

Yes (at least that is my understanding of the text).

>If yes can we document that?
>Like an addition to Section 7.4 like NEW TEXT:
>
>    If the request did not contain a Session-Expires header field, and the
>    associated 2xx response did not contain a Session-Expires header
>    field, there is no session expiration. In this case, no refreshes
>    need to be sent. This means that
>    the session timer can be 'turned-off' in mid dialog by sending a
>request 
>without a Session-Expires header field but only when the UAS responds
>with a 2xx without a Session-Expires.
>
>I think Section 7.4 is not very clear on this.

I assume you mean Section 7.2?

We can for sure make the text more clear.

Regards,

Christer

>> -----Ursprüngliche Nachricht-----
>> Von: Christer Holmberg [mailto:[email-masked]]
>> Gesendet: Montag, 30. Oktober 2017 14:38
>> An: Jesske, Roland <[email-masked]>; Paul Kyzivat
>> <[email-masked]>
>> Cc: [email-masked]
>> Betreff: Re: AW: Session timer fix
>> 
>> Hi,
>> 
>> >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?
>> 
>> Yes :)
>> 
>> I actually disagreed with Paul's statement, and pointed to section 7.4
>>which
>> says that the session timer can only be turned off in a response.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>> >> -----Ursprüngliche Nachricht-----
>> >> 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]
>> >> Betreff: Re: [sipcore] Session timer fix
>> >>
>> >> 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.
>> >> >
>> >> >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.)
>> >>
>> >> 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
>> >>
>> >>
>> >>
>> >>
>> >> >>> Sent from my iPhone
>> >> >>>
>> >> >>> On 27 Oct 2017, at 17.51, Paul Kyzivat <[email-masked]
>> >> >>> <mailto:[email-masked]>> wrote:
>> >> >>>
>> >> >>>> On 10/27/17 8:31 AM, Christer Holmberg wrote:
>> >> >>>>> Hi,
>> >> >>>>>>>>>> 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.
>> >> >>>>>>>>>
>> >> >>>>>>>>> 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.
>> >> >>>>>>>>
>> >> >>>>>>>> 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.
>> >> >>>>>>>
>> >> >>>>>>> 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).
>> >> >>>>
>> >> >>>> I have now gotten lost in the propossals and counter proposals.
>> >> >>>> Can you explicitly state what you are proposing?
>> >> >>>>
>> >> >>>>     Thanks,
>> >> >>>>     Paul
>> >> >>
>> >> >
>> >>
>> >> _______________________________________________
>> >> sipcore mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 31 Oct 2017 14:16:04 -0400

> Yes (at least that is my understanding of the text).

This is incorrect. Session timer is switched off.

> Yes (at least that is my understanding of the text).

Also not entirely correct. It does not matter if Session-Timer was present
in the offer. If there is no Session-Timer in the answer, Session-Timer is
switched off.
Session-Timer is added the answer based on the Supported or Required
headers. Session-Timer in the offer only proposes the Session-Timer
interval. It is optional.

Regards,
______________
Roman Shpount