Subject: Re: [sipcore] session-timer fix

From: Roman Shpount <[email-masked]>
Date: Sun, 1 Apr 2018 21:14:25 -0400

On Sat, Mar 31, 2018 at 6:02 PM, Paul Kyzivat <[email-masked]> wrote:

> On 3/31/18 3:04 PM, Roman Shpount wrote:
>
>> The situation I am describing here is a bit extreme but not nonsensical.
>> There are existing UA that can send the initial INVITE and then send an
>> UPDATE during this transaction to negotiate S-T. The purpose of the UPDATE
>> transactions is to negotiate S-T (refresher and expires) early, before
>> INVITE transaction was completed, similar to early media. Well behaving UA
>> should simply send the current S-T state (refresher and expires), in
>> subsequent transactions embedded in the INVITE transaction or in INVITE
>> transaction final success response. This will initiate a timer re-start
>> but, I would say, this is within the spirit of session timer, since UA and
>> proxies got a recent message indicating that dialog is still active and
>> timer can continue.
>>
>
> Then IIUC you are saying that if a s-t has been negotiated by a UPDATE
> within an INVITE then the UAS for the INVITE SHOULD send the same values in
> the 200 INVITE as were in the last 200 UPDATE.
>

Correct.

(If there had been no Supported:timer in the INVITE then I guess we presume
> that there is to be no s-t negotiation in UPDATEs either.)
>

Correct. Things start breaking in very interesting ways when Supported:
timer starts appearing and disappearing in different transactions.

> I suspect there are cases possible here, where a s-e expiration value that
> is compatible with the INVITE is incompatible with the UPDATE. These would
> be pathological, but ought to be investigated before we are done.
>

There are likely a few pathological cases there. I think at some point when
testing our session timer implementation I wrote a state machine tester
which iterated for all the possible values combination in each message.

While writing this response I realized another flaw in 4028. The rules for
> generating subsequent refreshes seem to assume that once it has been
> determined that both ends support s-t that this will continue to be true.
> For instance this must be so when the refresh request says refresher=uas.
> But in the presence of a B2BUA that passes s-t through rather than managing
> each side separately, after a 3pcc transfer this may not be true.
>

Actually request asking for refresher=uas is not binding. It might still
get a response where refresher=uac. B2BUA that passes s-t through rather
than managing each side needs to do the same thing that is required from
the proxy: If requester specified support for s-t and response specified no
s-t, set refresher in the response to uac, even if original request had
refresher set to uas. This way the side that supports s-t will be forced to
do it. This is similar to https://tools.ietf.org/html/rfc4028#section-8.2

Regards,
_____________
Roman Shpount