Subject: Re: [sipcore] Session timer fix

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Oct 2017 13:38:21 +0000

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: "Jesske, Roland" <[email-masked]>
Date: Mon, 30 Oct 2017 14:13:26 +0000

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.

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

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

Thank you and Best Regards

Roland

> 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,
> 
> >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.
> 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
> 
> 
> 
> 
> 
> >> Von: sipcore [mailto:[email-masked]] Im Auftrag von
> >> Christer Holmberg
> >> >>>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
> >> >>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.)
> >>
> >>      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:
> >>
> >>       there is no session expiration.  In this case, no refreshes
> >>need to
> >> 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
> >> >>>
> >> >>>>>>>>>> Yes, I understand that is the case you are thinking of.
> >> >>>>>>>>>> But I was raising a different case:
> >> >>>>>>>>>>
> >> >>>>>>>>> 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.
> >> >>>>>>>> The problem is that the rfc only talks about the *final*
> >> >>>>>>>>(2xx) response.
> >> >>>>>>>>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.
> >> >>>>>> 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?
> >> >>>>> 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
> >> >>
> >> >
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Oct 2017 17:11:43 -0400

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

No. In the case where it isn't in either the request or the response it 
needs to be switched off. This covers the case I outlined where neither 
the UAC nor UAS want it, and the proxy that once wanted it no longer does.

And this means that the UPDATE within an INVITE transaction is a special 
case. And in this case I'm concerned about what happens when this change 
is introduced and some proxies don't get updated to support it. To be 
sure of that it might be better to say that S-E received in an 
UPDATE/200 ought to be ignored when embedded within an INVITE 
transaction. Then proxies that don't support the update won't screw 
things up.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 Oct 2017 08:35:51 +0000

Hi Paul,

>the UAC nor UAS want it, and the proxy that once wanted it no longer does.

My suggestion is that no-SE-in-response would switch off if SE was in the
request.

So, if there is no SE in the request, there is no switch off.

Regards,

Christer

---

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

> So, if there is no SE in the request, there is no switch off.

This will break pretty much every SE implementation. There are number of
implementations where UA does not insert SE in the request. It is inserted
either by proxies (actually this is the most common use case) or by the
answering agent.

I think it would be much better to have a new header which will specify "do
not update Session-Timer" in the offer.
This way if proxies insert Session-Timer, new header will overwrite.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 Oct 2017 18:43:49 +0000

Hi,

I may reply to Roman’s comments later.

But, at the end of the day I think what Paul said is what matters most: the procedures for turning session timer etc applies AFTER the session timer has been fully negotiated.

So, if the session timer is negotiated during the initial INVITE transaction, whatever UPDATEs are sent during that transaction will not contain session timer information, and they will have no impact on the session timer.

But, once the session timer has been negotiated (once the UAC has received the 200 OK, the rules regarding turning the session timer off etc applies.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 31 October 2017 20:21
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; Jesske, Roland <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Session timer fix

On Tue, Oct 31, 2017 at 4:35 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
My suggestion is that no-SE-in-response would switch off if SE was in the
request.

This will break pretty much every SE implementation. There are number of implementations where UA does not insert SE in the request. It is inserted either by proxies (actually this is the most common use case) or by the answering agent.

I think it would be much better to have a new header which will specify "do not update Session-Timer" in the offer.
This way if proxies insert Session-Timer, new header will overwrite.

Regards,
_____________
Roman Shpount