Subject: [sipcore] 4028bis re-start

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Aug 2021 19:16:33 +0000

Hi session-timer lovers,

The work on 4028bis has been postponed for a long time.

I will now try to reboot the work, and hopefully we will be able to finalize the work soon.

SCOPE:
======

I think it is important to keep in mind that the purpose of the work is to fix the issues associated with RFC 4028 - not to add new functionality, or change existing functionality just because someone thinks the functionality would be "better" that way.

Of course, if people identity other errors in RFC 4028, those can also be fixed.

A number of issues have been opened on GitHub, so we need to take a look at those: https://github.com/cdh4u/draft-sessiontimer-race/issues

BACKGROUND MATERIAL:
=====================

IETF #101 SIPCORE session-timer presentation:

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

IETF #101 SIPCORE minutes:

https://datatracker.ietf.org/meeting/101/materials/minutes-101-sipcore-00

IETF #101 SIPCORE YouTube recording:

https://www.youtube.com/watch?v=kZdtpZe0-9E

GitHub issues:

https://github.com/cdh4u/draft-sessiontimer-race/issues

PROBLEM:
=========

The problem is explained in the background material above, and also in the draft, but in a nutshell:

When an UPDATE transaction is triggered during an ongoing (re-)INVITE transaction, and if both transactions contain session-timer information, it can lead to a glare situation where it is unclear who is the refresher.

SOLUTION:
=========

The proposed solution has been to say that, if a UAC ends up in a situation where the session-timer property values are unclear, the UA MUST trigger a "session-timer clean up" UPDATE transaction.

This is also aligned with the UAC procedures defined in RFC 6141 (Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP): https://datatracker.ietf.org/doc/html/rfc6141#section-3.4

There have also been some proposals on how to avoid the glare situation to begin with:

  *   Do not include session-timer information in UPDATE transactions that are sent while there is an ongoing (re-)INVITE transaction.
  *   Do now allow session-timer negotiation in UPDATE transactions to begin with - no matter whether there is an ongoing (re-)INVITE transaction or not.
  *   Once the refresher has been determined, don't change it during the session (in case of 3PCC etc it can be re-negotiated)
  *   ...

Regards,

Christer