Subject: [sipcore] IETF#101: Session-timer slides

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Mar 2018 09:50:36 +0000

Hi,

As some people are going to participate remotely, before I upload the slides I have put the current version on GitHub.

https://github.com/cdh4u/draft-sessiontimer-race/blob/master/IETF101_SIPCORE_SESSION-RACE.pdf

We will discuss the technical stuff during the meeting, but if there is something you think could be clarified then please let me know.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2018 10:57:56 -0400

Christer,

On 3/19/18 5:50 AM, Christer Holmberg wrote:
> Hi,
> 
> As some people are going to participate remotely, before I upload the 
> slides I have put the current version on GitHub.
> 
> We will discuss the technical stuff during the meeting, but if there is 
> something you think could be clarified then please let me know.

I went and reviewed the draft and rfc again, and I still think the fix 
in your 3.1 (to section 7.2 of 4028) is over broad.

Consider a case where a session timer has already been established 
between Alice and Bob. We are mid-dialog and there are no transactions 
in progress. Now Alice decides she wants to disable the session timer.

How can she do that? Following 4028, she does that by sending an INVITE 
or UPDATE with no Session-Expires. The response to that also has no 
Session-Expires, and then session timer is cancelled.

But with your revision, because the request did not contain 
Session-Expires, the response does not cancel the session timer.

To avoid the problem, the behavior of leaving a s-t running after 
receiving a response without Session-Expires must be limited to UPDATE 
transactions embedded within INVITE transactions.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Mar 2018 15:35:10 +0000

Hi Paul,

>> We will discuss the technical stuff during the meeting, but if there 
>> is something you think could be clarified then please let me know.
>
> I went and reviewed the draft and rfc again, and I still think the fix in your 3.1 (to section 7.2 of 4028) is over broad.
>
> Consider a case where a session timer has already been established between Alice and Bob. 
> We are mid-dialog and there are no transactions in progress. Now Alice decides she wants to disable the session timer.
>
> How can she do that? Following 4028, she does that by sending an INVITE or UPDATE with no Session-Expires. 
> The response to that also has no Session-Expires, and then session timer is cancelled.
>
> But with your revision, because the request did not contain Session-Expires, the response does not cancel the session timer.

If that's what the text is saying, we need to fix it. My intention is not to remove the generic ability to remove the session-timer.

Note, though, that I am not going to discuss the text at the meeting. The focus will be on the overall principle. Once we can agree on that, we'll sort out the text.

> To avoid the problem, the behavior of leaving a s-t running after receiving a response without Session-Expires must be 
> limited to UPDATE transactions embedded within INVITE transactions.

Correct. I think the focus shall be on UPDATE transactions that take place within INVITE transactions (or, during session-timer negotiations).

Regards,

Christer