RFC 4028, "Session Timers in the Session Initiation Protocol (SIP)", April 2005

Errata ID: 4744
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Wang
Date Reported: 2016-07-19

Section 3 says:

   A UAC starts by sending an INVITE.  This includes a Supported header
   field with the option tag 'timer', indicating support for this
   extension.

It should say:

   A UAC starts by sending an INVITE.  This includes a Supported header
   field with the option tag 'timer', indicating support for this
   extension.If UAC or UAS knows one negotiation of session timer is 
   ongoing, it SHALL not start a new one.

Notes:

Add one more sentence here "If UAC knows one negotiation of session timer is ongoing, it SHALL not start a new one."
Actually in the scenarios of session set-up or session modification, it is easy to see the message exchange of UPDATE and (re-)INVITE, according to this RFC, both of them are allowed for the negotiation of session timer, the decision shall be taken on their own 200 OK. Normally the negotiation of session time of (re-)INVITE is started at first and the UPDATE's will be taken place, from UAS perspective, it needs to treat two negotiations of session timer in-parallel, since there is no kind of mechanism to protect the parameters carried in (re-)INVITE and UPDATE being inconsistent, it brings a problem on UAS that the result of two negotiations might be different specially for the parameter of refresher and also the inconsistency will cause UAS to meet a conflict while it is deciding the parameters especially for refresher on 200 OK of (re-)INVITE. In order to avoid this problem, it is better to disallow a net negotiation of session timer until the ongoing one is finished.

Report New Errata