Subject: Re: [sipcore] Session timer fix

From: "Jesske, Roland" <[email-masked]>
Date: Wed, 1 Nov 2017 10:47:10 +0000

Hi Christer,

So I think we should also put something into 7.4 since this section is describing the Refresh mechanism for the subsequent refreshes.
So if documentation is easier in 7.2 we can do this. But then I think in 7.4 we need at least then a reference to 7.2.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg [mailto:[email-masked]]
> Gesendet: Montag, 30. Oktober 2017 15:20
> An: Jesske, Roland <[email-masked]>; Paul Kyzivat
> <[email-masked]>
> Cc: [email-masked]
> Betreff: Re: AW: AW: Session timer fix
> 
> 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
> >