Subject: Re: [sipcore] Session-timer: Non-refresher sending UPDATE/re-INVITE - is it a session refresh request?

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 1 Oct 2018 17:38:42 +0900

Hi Paul,

When b2bua controls a whole SIP system, session timer is not necessary.
If turn-off logic is available, the server can prohibit unnecessary traffic.

Regards,
Shinji

On 2018/09/30 2:33, Paul Kyzivat wrote:
> Hi Shinji,
>
> On 9/29/18 8:35 AM, OKUMURA Shinji wrote:
>> Hi Paul,
>> It's been a while. ;-)
>>
>>  > This is just like an initial request - the proxy MAY insert S-E if it wants a timer, or leave it out if it doesn't.
>>
>> I think that is the primary cause of some problems.
>> A proxy's discretion is too big. UAs can not predict a behavior of a proxy.
>>
>> The following rules may simplify this problem,
>> 1. If a UAC supports timer, proxy must not add SE header to the request.
>> 2. If a UAS supports timer, proxy must neither add nor modify SE header in the response.
>>
>> At least these will make UAs to turn-off successfully.
>
> I think this is backward. The prime motivation for timers is so that proxies have a way to monitor the liveness of a session. The reason for UAs to support timers is to render assistance to proxies that need this to manage state that they hold about sessions. The UA doesn't know in advance if there are any proxies on the path that need this, so it should typically only indicate support, and wait for proxies to express a desire.
>
> Remember that UAs that desire to periodically test the liveness of a session don't need session timer to do so. They can send an in dialog request at any time.
>
> I don't understand why a UA would request a session timer on its own. OTOH, it *might* want to specify Min-S-E initially to avoid being asked to do too much work.
>
> BTW, I think having some discussion like this in the document would be very helpful.
>
>     Thanks,
>     Paul
>
>
>> Regards,
>> Shinji
>>
>> On 2018/09/29 1:28, Paul Kyzivat wrote:
>>> On 9/28/18 5:05 AM, OKUMURA Shinji wrote:
>>>> Hi,
>>>
>>> Hi Shinji! I don't hear from you very often. Glad to see you here!
>>>
>>>> It's about time we check up concrete protocol sequences.
>>>> If you notice any irregular behavior, please comment on the problem,
>>>
>>> These all seem good to me, except comment at end.
>> (snip)
>>>> [scenario 9] turn-off
>>>> 1. Alice sends UPDATE INVITE without SE
>>>> 2. no proxies add SE to the request
>>>> 3. Bob returns 200 without SE
>>>>
>>>> 1: Alice's behavior is consistent with RFC
>>>> 2: Require rules to specify proxy behavior
>>>> 3: Alice's behavior is consistent with RFC
>>>
>>> I don't understand what you mean or are asking about 2 in scenario 9.
>>> This is just like an initial request - the proxy MAY insert S-E if it wants a timer, or leave it out if it doesn't.
>>>
>>>     Thanks,
>>>     Paul 
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Oct 2018 12:08:03 -0400

Hi Shinji,

> If turn-off logic is available, the server can prohibit unnecessary traffic.

If a b2bua is in the path then this document only applies in the path 
between it another ua. There could still be a proxy that requires 
session timer in that path.

There is conflict between allowing a UA to force the timer off and 
allowing a proxy in the path that *needs* the timer. In any case, a UA 
that wants to refuse to do session timer can do so by simply not 
indicating support for it.

When I talk about turning the timer off in the context of this document 
I simply mean on end indicating it prefers not to have it, so that it 
will be negotiated off if nobody else on the path needs it.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 02 Oct 2018 13:12:28 +0800

Am 02.10.2018 00:08 schrieb Paul Kyzivat <[email-masked]>:

Hi Shinji,

This is what I would like to see and I'm supportive for that.

Another Issue:

I would see the B2BUA as a entity that could use the session timer on one leg where it is needed and on the other leg where it is not needed. But with clear rules.

But currently there are no rules with regard to the B2BUA.

I have seen B2BUA which are changing the direction of refresher. This end up in race conditions. When each refresher is sending the refresh at the same time.

Thanks,

Paul

_______________________________________________

sipcore mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked]
Date: Tue, 02 Oct 2018 13:36:02 +0800

Hi,
As already said such scenarios I do not see in reality.

Looking through the discussion, we have more or less discussed how a stateful proxy may work.

Of course it would be, as Roman said,  the easiest way to send an Update afterwards some courious call negotiation. But such behaviour must then implemented into the UAs which is not such as easy.

We are coming a long way along discussing many scenarios and the interpretation of these.

My question now is on what we could agree to have a way forward for a proper description?

My proposal would be:

1. Describe the initial setting of S-E in the initial INVITE

2. A stateless proxy behaviour.

3 A call stateful proxy behaviour. Whatever call stateful means. So we need that definition of it or state that this is not possible.

4 A proper B2BUA behaviour and regarding rules.

5 Possibly a helper function . I.e. sending a UPDATE after cross call scenarios.

6 And a description of backwards compatibility to the existing RFC as there are a coupuple of implementations out.

Thank you and Best Regards

Roland

Am 29.09.2018 07:35 schrieb Roman Shpount <[email-masked]>:

On Fri, Sep 28, 2018 at 6:44 PM, Christer Holmberg <[email-masked]> wrote:

>>>> It may not cause a problem in this case, but my point is that we cannot have a generic rule mandating the

>>>> S-E of the mid-dialog UPDATE and the INVITE response to be identical.

>>> I meant to say consistent not identical, i.e. not to change S-E expiration or refresher on random basis.

>> We just need to make sure we get the wording right: the proxy MUST NOT change the S-E expiration, or

>> the refresher, in the "mid-INVITE" UPDATE request/response, but in some cases it will not indicate the

>> refresher at all.

>> There are some serious implementation issues here. I think some sort of cross-transaction correlation needs

>> to occur for session timer to work consistently. Imagine the situation when proxy needs to refresh at least

>> every 15 min. Imagine your scenario where Alice supports session timer and Bob does not. If there is no

>> cross-transaction state correlation then:

>> Alice          Proxy            Bob

>> |(1) INVITE     |               |

>> | SE: 600       |               |

>> |-------------->|               |

>> |               |(2) INVITE     |

>> |               | SE: 600       |

>> |               |-------------->|

>> |               |               |

>> |               |(3) UPDATE     |

>> |               |<--------------|

>> |(4) UPDATE     |               |

>> | SE: 900       |               |

>> |<--------------|               |

>> |               |               |

>> |(5) 200(UPD)   |               |

>> | SE: 900       |               |

>> | refresher=uas |               |

>> |-------------->|               |

>> |               |(6) 200(UPD)   |

>> |               | SE: 900       |

>> |               | refresher=uas |

>> |               |-------------->|

>> |               |               |

>> |               |(7) 200(INV)   |

>> |               |<--------------|

>> |(8) 200(INV)   |               |

>>| SE: 600       |               |

>> | refresher=uac |               |

>> |<--------------|               |

>> 1. INVITE is sent by Alice with S-E set to 600

>> 2. Proxy needs to refresh every 900, since 600 is less it forwards the S-E header as is to Bob

>> 3. UPDATE is received from Bob with no S-E

>> 4. Proxy adds S-E set to 900, since it does not know about INVITE transaction state and it needs to refresh every 15 min

>> 5. Alice accepts session timer and sets S-E to 900;refresher=uas

>> 6. Bob ignores S-E, since it does not support session timer

>> 7. Bob sends 200 Ok to INVITE without S-E since it does not support session timer

>> 8. Proxy looks up transaction state and adds S-E set to 600;refresher=uac

>> As a result Alice is confused about the S-E refresh interval.

>> Sharing cross transaction state for proxy can be a big deal. Different transactions might no even end up on

>> the same proxy instance, especially since initial INVITE is sent to the pre-configured proxy, but UPDATE is sent

>> based on dialog route set. Furthermore, support for cross transaction dialog state can create a significant additional

>> load on the proxy, since transaction state is usually in memory but dialog state is typically in database where frequent

>> updates are not desirable.

First, the proxy adding session timer must be stateful.

Stateful means storing transaction state, not state across transactions. This is something like OpenSIPS tm module and avp (https://opensips.org/html/docs/modules/2.4.x/tm.html and https://www.opensips.org/Documentation/Script-CoreVar-2-4#varavps). UPDATE transaction normally has no access to INVITE transaction state. Even transaction stateful can be a problem for HA or high scale deployment and can cause calls to fail. Converting anything except initial INVITE transaction to stateful is too high of the price to pay for session timer. In practice, it would be easier to assume that session timer is supported throughout the dialog if it was supported during initial dialog negotiation.

Second, the proxy adding session timer SHOULD add Record-Route. Perhaps we should change that to MUST. Otherwise I really don't see how you intend to solve that cause the confusion...

Record-Route does not help here. There is no way to store changing state for INVITE transaction in Record-Route header. From implementation point of view, dealing with this issue means state for current INVITE transaction needs to go into some sort of shared DB (even if it is in-memory DB) which is accessible from all servers/processes that can handle UPDATE transactions for this dialog. In other words, every time INVITE request is received, session timer information from this request is stored in DB. Once INVITE transaction is completed, record for INVITE is removed from DB. Every time UPDATE is message is processed, DB needs to be looked up if there is a current INVITE transaction for this dialog. Of cause, logic for INVITE collisions and race conditions need to be implemented as well.

Reality is unless this can be resolved on the client, these rules are too complicated to be implemented on the proxy so that nobody will do that. Unless there is a way to implement proposed rules using openSIPS or Kamilio configuration script, these rules are not going to useful.

On the other hand, asking Alice to do one more UPDATE after the INVITE completion if there were any UPDATE transactions during INVITE is much simpler for all involved and unambiguosly resolves all the problems.

Regards,

_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 2 Oct 2018 18:58:01 +0900

Hi Paul,

Of course I thought that all servers that require a session timer are session-stateful.
But RFC4028 does not say clearly that the proxy must be session-stateful.

At the end of the day, in your opinion should SE of (2) and SE of (4) be consistent or not?

Regards,
Shinji

On 2018/09/30 2:37, Paul Kyzivat wrote:
> On 9/29/18 12:03 PM, OKUMURA Shinji wrote:
>> Hi all,
>>
>> First of all I think that it is necessary to check our goal, do you
>> accept inconsistencies for SE-state between INVITE transaction and
>> UPDATE one.
>>
>> If you accept them, the proxy should be only transaction-stateful and
>> record-route is unnecessary.
>> Otherwise the proxy should be dialog-stateful(call-stateful) and
>> record-route is necessary.
>> In other words SE-state must be one of a dialog state.
>> And maybe we need rules that make an UPDATE request not to intersect a
>> success response for INVITE.
>>
>> Paul seems to be the former, Christer seems to be the latter.
>> I am the latter. Which one are you, Roman?
>
> ISTM that the likely reason why a proxy wants a session timer is because it is session-stateful, and needs a way to know when it can release the session state.
>
> If it isn't session stateful then it can ignore all of this.
>
> Can you think of a reason why a proxy that isn't session stateful would want a session timer?
>
>     Thanks,
>     Paul
>
>> Regards,
>> Shinji
>>
>> On 2018/09/29 8:35, Roman Shpount wrote:
>>>>>> 4. Proxy adds S-E set to 900, since it does not know about INVITE
>>>> transaction state and it needs to refresh every 15 min
>>>>>> based on dialog route set. Furthermore, support for cross transaction
>>>> dialog state can create a significant additional
>>>>>> load on the proxy, since transaction state is usually in memory but
>>>> dialog state is typically in database where frequent
>>> Stateful means storing transaction state, not state across transactions.
>>> This is something like OpenSIPS tm module and avp (
>>> https://opensips.org/html/docs/modules/2.4.x/tm.html and
>>> https://www.opensips.org/Documentation/Script-CoreVar-2-4#varavps). UPDATE
>>> transaction normally has no access to INVITE transaction state. Even
>>> transaction stateful can be a problem for HA or high scale deployment and
>>> can cause calls to fail. Converting anything except initial INVITE
>>> transaction to stateful is too high of the price to pay for session timer.
>>> In practice, it would be easier to assume that session timer is supported
>>> throughout the dialog if it was supported during initial dialog negotiation.
>>>
>>> Second, the proxy adding session timer SHOULD add Record-Route. Perhaps we
>>>> should change that to MUST. Otherwise I really don't see how you intend to
>>>> solve that cause the confusion...
>>>>
>>> Record-Route does not help here. There is no way to store changing state
>>> for INVITE transaction in Record-Route header. From implementation point of
>>> view, dealing with this issue means state for current INVITE transaction
>>> needs to go into some sort of shared DB (even if it is in-memory DB) which
>>> is accessible from all servers/processes that can handle UPDATE
>>> transactions for this dialog. In other words, every time INVITE request is
>>> received, session timer information from this request is stored in DB. Once
>>> INVITE transaction is completed, record for INVITE is removed from DB.
>>> Every time UPDATE is message is processed, DB needs to be looked up if
>>> there is a current INVITE transaction for this dialog. Of cause, logic for
>>> INVITE collisions and race conditions need to be implemented as well.
>>>
>>> Reality is unless this can be resolved on the client, these rules are too
>>> complicated to be implemented on the proxy so that nobody will do that.
>>> Unless there is a way to implement proposed rules using openSIPS or Kamilio
>>> configuration script, these rules are not going to useful.
>>>
>>> On the other hand, asking Alice to do one more UPDATE after the INVITE
>>> completion if there were any UPDATE transactions during INVITE is much
>>> simpler for all involved and unambiguosly resolves all the problems.
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>
>>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Oct 2018 11:26:13 +0000

Hi,

The RFC says:

   "Although the user agents
   may be able to determine whether the session has timed out by using
   session specific mechanisms, proxies will not be able to do so.  The
   result is that call stateful proxies will not always be able to
   determine whether a session is still active.  For instance, when a
   user agent fails to send a BYE message at the end of a session, or
   when the BYE message gets lost due to network problems, a call
   stateful proxy will not know when the session has ended."

 At least in my eyes that makes it very clear that it is about session state.

Unless a proxy keeps session state, it has no need to know whether a session has expired - it does not care.

Even with Roman's charging case, in order to send charging information associated with a session, the proxy needs to keep session state.

Regards,

Christer

________________________________
From: OKUMURA Shinji <[email-masked]>
Sent: Tuesday, October 2, 2018 12:58 PM
To: [email-masked]
Cc: Paul Kyzivat; Roman Shpount; Christer Holmberg
Subject: Re: [sipcore] Session-timer: Non-refresher sending UPDATE/re-INVITE - is it a session refresh request?

Hi Paul,

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Oct 2018 11:55:16 -0400

On Tue, Oct 2, 2018 at 7:26 AM Christer Holmberg <
[email-masked]> wrote:

> Even with Roman's charging case, in order to send charging information
> associated with a session, the proxy needs to keep session state.
>
>
I think we are talking in circles. Session timers are about session state,
but they are essentially an optimization to minimize the amount of work
required by proxies to know that there  is an ongoing session (dialog) so
that implementer does not have to use B2BUA for the same purpose. All that
proxy care about is that session is still running. What you are suggesting
is that proxy also need to maintain information about ongoing transactions
in dialog, which is a lot more work then what proxy currently do. There
might be additional complications such as INVITE collisions (i.e. dealing
with storing two INVITE transaction at the same time which would be
eventually rolled back), INVITE sequence numbers, INVITE and ACK collision,
etc. All this logic will also be actively attacked to try to generate calls
which are not correctly accounted for. The whole idea of the proxy is that
it is reasonably simple and most of the state maintenance is at UA, so that
proxy can be scaled and audited easily. By trying to put all the session
logic in the proxy, you essentially go against the SIP design principals
(intelligence at the edge). At this point you might as well make proxy into
B2BUA.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 2 Oct 2018 12:17:46 -0400

On 10/2/18 1:12 AM, [email-masked] wrote:

> Another Issue:
> I would see the B2BUA as a entity that could use the session timer on 
> one leg where it is needed and on the other leg where it is not needed. 
> But with clear rules.
> I have seen B2BUA which are changing the direction of refresher. This 
> end up in race conditions. When each refresher is sending the refresh at 
> the same time.

A b2bua is obligated to follow the UA rules independently on each leg. 
As long as it does that, there need not be any coordination between the 
two legs. Of course it may attempt to emulate a proxy if it wishes.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Oct 2018 17:28:01 +0000

Hi,

…

>I think we are talking in circles. Session timers are about session state, but they are >essentially an optimization to minimize the amount of work required by proxies to know >that there  is an ongoing session (dialog) so that implementer does not have to use >B2BUA for the same purpose.

Not sure why one would have to use a B2BUA.

>All that proxy care about is that session is still running. What you are suggesting is that >proxy also need to maintain information about ongoing transactions in dialog, which is a >lot more work then what proxy currently do.

The only thing the proxy needs to know is if there in an ongoing (re-)INVITE/UPDATE transaction, and if so what S-E values etc have been used within that transaction. The proxy does not need to know anything about the transaction(s) themselves.

Or, have I missed something?

>There might be additional complications such as INVITE collisions (i.e. dealing with >storing two INVITE transaction at the same time which would be eventually rolled back), >INVITE sequence numbers, INVITE and ACK collision, etc. All this logic will also be actively >attacked to try to generate calls which are not correctly accounted for. The whole idea of >the proxy is that it is reasonably simple and most of the state maintenance is at UA, so >that proxy can be scaled and audited easily. By trying to put all the session logic in the >proxy, you essentially go against the SIP design principals (intelligence at the edge). At >this point you might as well make proxy into B2BUA.

What I suggest above does not turn a proxy into a B2BUA.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Oct 2018 13:42:49 -0400

On Tue, Oct 2, 2018 at 1:28 PM Christer Holmberg <
[email-masked]> wrote:

> >I think we are talking in circles. Session timers are about session
> state, but they are >essentially an optimization to minimize the amount of
> work required by proxies to know >that there  is an ongoing session
> (dialog) so that implementer does not have to use >B2BUA for the same
> purpose.
>

If session timer did not exist and proxy could not request one of the UA to
run periodic requests, the only way to monitor the session from the network
element in the middle is using B2BUA. In fact you can do anything done by
proxy using B2BUA. Proxy is just an optimization where only limited logic
is required from the network element and most of the state measurement is
delegated to the client.

> >All that proxy care about is that session is still running. What you are
> suggesting is that >proxy also need to maintain information about ongoing
> transactions in dialog, which is a >lot more work then what proxy currently
> do.
>
> The only thing the proxy needs to know is if there in an ongoing
> (re-)INVITE/UPDATE transaction, and if so what S-E values etc have been
> used within that transaction. The proxy does not need to know anything
> about the transaction(s) themselves.
>

Keeping track of ongoing INVITE transactions would at the best case double
the proxy load (two DB updates per transaction vs one).

>From proxy point of view there can be two or more INVITE transactions going
on at the same time, so this will require more DB entries then one per
call. These INVITE transactions can be INVITE collisions or valid 2XX and
INVITE network re-order. Proxy has no way of knowing which one it is when
INVITE messages are received. If we add malicious clients, proxy need to
validate that current scenario is legitimate (i.e. it did not get large
number of INVITE requests in same direction) before it stores the INVITE
transaction info. All of this complicates things a bit.

> >There might be additional complications such as INVITE collisions (i.e.
> dealing with >storing two INVITE transaction at the same time which would
> be eventually rolled back), >INVITE sequence numbers, INVITE and ACK
> collision, etc. All this logic will also be actively >attacked to try to
> generate calls which are not correctly accounted for. The whole idea of
> >the proxy is that it is reasonably simple and most of the state
> maintenance is at UA, so >that proxy can be scaled and audited easily. By
> trying to put all the session logic in the >proxy, you essentially go
> against the SIP design principals (intelligence at the edge). At >this
> point you might as well make proxy into B2BUA.
>

My suggestion is to try to express whatever rules we propose using
opensips/kamillio configuration script. If this is possible, these rules
are acceptable and implementable by current proxies. If this would require
binary changes to opensips, then these rules are too complex for most of
the deployed scenarios.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Oct 2018 19:06:32 +0000

Hi,

One option is that the proxy simply does not modify the S-E values that it inserts. It uses the same value in every request/response - no matter if there are ongoing INVITE transactions or not. Not sure how often the session timer is modified mid-session to begin with...

Regards,

Christer

________________________________
From: Roman Shpount <[email-masked]>
Sent: Tuesday, October 2, 2018 8:42 PM
To: Christer Holmberg
Cc: OKUMURA Shinji; SIPCORE; Paul Kyzivat
Subject: Re: [sipcore] Session-timer: Non-refresher sending UPDATE/re-INVITE - is it a session refresh request?

If session timer did not exist and proxy could not request one of the UA to run periodic requests, the only way to monitor the session from the network element in the middle is using B2BUA. In fact you can do anything done by proxy using B2BUA. Proxy is just an optimization where only limited logic is required from the network element and most of the state measurement is delegated to the client.

Keeping track of ongoing INVITE transactions would at the best case double the proxy load (two DB updates per transaction vs one).

>From proxy point of view there can be two or more INVITE transactions going on at the same time, so this will require more DB entries then one per call. These INVITE transactions can be INVITE collisions or valid 2XX and INVITE network re-order. Proxy has no way of knowing which one it is when INVITE messages are received. If we add malicious clients, proxy need to validate that current scenario is legitimate (i.e. it did not get large number of INVITE requests in same direction) before it stores the INVITE transaction info. All of this complicates things a bit.

My suggestion is to try to express whatever rules we propose using opensips/kamillio configuration script. If this is possible, these rules are acceptable and implementable by current proxies. If this would require binary changes to opensips, then these rules are too complex for most of the deployed scenarios.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Oct 2018 15:52:04 -0400

On Tue, Oct 2, 2018 at 3:06 PM Christer Holmberg <
[email-masked]> wrote:

> One option is that the proxy simply does not modify the S-E values that it
> inserts. It uses the same value in every request/response - no matter if
> there are ongoing INVITE transactions or not. Not sure how often the
> session timer is modified mid-session to begin with...
>
>
>
I would suggest the following:
1. If proxy receives a SIP Request without S-E, it inserts the S-E header
with expiration value desired by proxy with no refresher
2. If proxy receives s SIP Request with S-E, it can reduce the expires
time, it this expires time is greater then session refresh interval desired
by proxy (as long as it is greater then Min-SE)
3. If proxy receives a SIP Response without S-E, it checks S-E value and
supported timer header which were set in the request associated with this
response when it was sent by the proxy. If session timer was supported by
the origination client, then proxy inserts S-E value in the response with
the same expiration as original request and refresher set to UAC.

These rules do not require any inter-transaction dependencies (rule 3 is
within single transaction) and simply act as a more strict version of rules
specified in the current RFC.

These rules can still result in inconsistent S-E refresh interval (not the
refresher role) in scenario like this:
Alice          Proxy            Bob
 |(1) INVITE     |               |
 | SE: 600       |               |
 |-------------->|               |
 |               |(2) INVITE     |
 |               | SE: 600       |
 |               |-------------->|
 |               |               |
 |               |(3) UPDATE     |
 |               |<--------------|
 |(4) UPDATE     |               |
 | SE: 900       |               |
 |<--------------|               |
 |               |               |
 |(5) 200(UPD)   |               |
 | SE: 900       |               |
 | refresher=uas |               |
 |-------------->|               |
 |               |(6) 200(UPD)   |
 |               | SE: 900       |
 |               | refresher=uas |
 |               |-------------->|
 |               |               |
 |               |(7) 200(INV)   |
 |               |<--------------|
 |(8) 200(INV)   |               |
 | SE: 600       |               |
 | refresher=uac |               |
 |<--------------|               |

1. INVITE is sent by Alice with S-E set to 600
2. Proxy needs to refresh every 900, since 600 is less it forwards the S-E
header as is to Bob
3. UPDATE is received from Bob with no S-E
4. Proxy adds S-E set to 900, since it does not know about INVITE
transaction state and it needs to refresh every 15 min
5. Alice accepts session timer and sets S-E to 900;refresher=uas
6. Bob ignores S-E, since it does not support session timer
7. Bob sends 200 Ok to INVITE without S-E since it does not support session
timer
8. Proxy looks up transaction state and adds S-E set to 600;refresher=uac

For scenarios like this I suggest we add the rule for the client:

If it processes UPDATE transactions during INVITE which result in different
session timer negotiation result with overlaying INVITE transaction or each
other, UA MUST send a new UPDATE outside of any INVITE transaction to
re-negotiate the session timer state.

This way if client runs into old or non-compliant implementations, it will
deal with them correctly.

Furthermore, we should clarify the negotiated SIP session timer value in
the middle of the INVITE transaction. Current RFC specifies that S-E should
be set to currently negotiated value when request is sent, but does not say
what the currently negotiated value is when transaction is still in
progress. I think we should specify that session timer negotiation occurs
when INVITE request is received and UPDATE messages sent within INVITE
transaction should use this value. 2XX response to INVITE transaction
should include S-E value negotiated by UPDATE transactions which occurred
during the INVITE.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Oct 2018 20:43:25 +0000

Hi,

As we have discussed, the session timer mechanism is mostly useful for proxies. Therefore, assuming that the proxy knows best what interval is needed:

Q1: If the S-E in message #1 is too small, the proxy could reject it with 422.

Q2: In message #2, since the proxy wants 900, could we allow the proxy to insert 900?

Q3: In message #8, since the proxy wants 900, could we allow the proxy to insert 900?

Regards,

Christer

Sent: Tuesday, October 2, 2018 10:52 PM

On Tue, Oct 2, 2018 at 3:06 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

I would suggest the following:
1. If proxy receives a SIP Request without S-E, it inserts the S-E header with expiration value desired by proxy with no refresher
2. If proxy receives s SIP Request with S-E, it can reduce the expires time, it this expires time is greater then session refresh interval desired by proxy (as long as it is greater then Min-SE)
3. If proxy receives a SIP Response without S-E, it checks S-E value and supported timer header which were set in the request associated with this response when it was sent by the proxy. If session timer was supported by the origination client, then proxy inserts S-E value in the response with the same expiration as original request and refresher set to UAC.

These rules do not require any inter-transaction dependencies (rule 3 is within single transaction) and simply act as a more strict version of rules specified in the current RFC.

These rules can still result in inconsistent S-E refresh interval (not the refresher role) in scenario like this:
Alice          Proxy            Bob
 |(1) INVITE     |               |
 | SE: 600       |               |
 |-------------->|               |
 |               |(2) INVITE     |
 |               | SE: 600       |
 |               |-------------->|
 |               |               |
 |               |(3) UPDATE     |
 |               |<--------------|
 |(4) UPDATE     |               |
 | SE: 900       |               |
 |<--------------|               |
 |               |               |
 |(5) 200(UPD)   |               |
 | SE: 900       |               |
 | refresher=uas |               |
 |-------------->|               |
 |               |(6) 200(UPD)   |
 |               | SE: 900       |
 |               | refresher=uas |
 |               |-------------->|
 |               |               |
 |               |(7) 200(INV)   |
 |               |<--------------|
 |(8) 200(INV)   |               |
 | SE: 600       |               |
 | refresher=uac |               |
 |<--------------|               |

If it processes UPDATE transactions during INVITE which result in different session timer negotiation result with overlaying INVITE transaction or each other, UA MUST send a new UPDATE outside of any INVITE transaction to re-negotiate the session timer state.

This way if client runs into old or non-compliant implementations, it will deal with them correctly.

Furthermore, we should clarify the negotiated SIP session timer value in the middle of the INVITE transaction. Current RFC specifies that S-E should be set to currently negotiated value when request is sent, but does not say what the currently negotiated value is when transaction is still in progress. I think we should specify that session timer negotiation occurs when INVITE request is received and UPDATE messages sent within INVITE transaction should use this value. 2XX response to INVITE transaction should include S-E value negotiated by UPDATE transactions which occurred during the INVITE.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Oct 2018 19:02:30 -0400

On Tue, Oct 2, 2018 at 4:43 PM Christer Holmberg <
[email-masked]> wrote:

> As we have discussed, the session timer mechanism is mostly useful for
> proxies. Therefore, assuming that the proxy knows best what interval is
> needed:
>
>

This is correct. This is what I meant that old Min-SE procedures should
still be followed.

Q2: In message #2, since the proxy wants 900, could we allow the proxy to
> insert 900?

There can be more then one proxy. One might want 900. Another might want
600. The smallest interval must be chosen by each. If both proxies follow
the procedure I have described then the same interval will always be
selected.

Q3: In message #8, since the proxy wants 900, could we allow the proxy to
> insert 900?

Same issue as Q2 -- there might be multiple proxies. This can possibly be
replaced by applying the rule for requests to responses as well, i.e. proxy
can reduce the refresh interval but not change the refresher if it is
already specified, but this can potentially cause behavior changes to
current RFC when UAC specifies the refresh interval.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Oct 2018 06:37:59 +0000

Hi,

>This is correct. This is what I meant that old Min-SE procedures should still be followed.

So, I think we should specify that:

"If the proxy receives a S-E value that is too small, the proxy SHOULD reject it with a 422 response."

In addition, I think we should say that UAs SHOULD NOT insert S-E to begin with. That gives the proxy more freedom to insert whatever value it wants.

---

>Same issue as Q2 -- there might be multiple proxies. This can possibly be replaced by applying the rule for requests to responses as well, i.e. proxy can reduce the refresh interval but not
>change the refresher if it is already specified, but this can potentially cause behavior changes to current RFC when UAC specifies the refresh interval.

The case where the UAC receives different S-E values in (4) and (8) is causing problems today.

Sure, we can say that the UAC should send a new UPDATE if that happens, but existing deployments won't do that. But, we can minimize the risk of this to occur by specifying the following:

1) As described in Q1, the proxy rejects too small values with 422, rather than forwarding them.
2) By default, a proxy must always insert the same S-E value in each direction. The proxy is only allowed to change the value if it is able to keep track of ongoing transactions etc.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 3 Oct 2018 18:50:03 +0900

Hi,

Are you discussing on the presumption that UAS does not support a session-timer?

> In addition, I think we should say that UAs SHOULD NOT insert S-E to begin with. That gives the proxy more freedom to insert whatever value it wants.

IIUC, you say that "UAC" SHOULD NOT insert S-E to a request, don't you?.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Oct 2018 07:01:48 -0400

On Wed, Oct 3, 2018 at 2:38 AM Christer Holmberg <
[email-masked]> wrote:

> In addition, I think we should say that UAs SHOULD NOT insert S-E to begin
> with. That gives the proxy more freedom to insert whatever value it wants.
>

This is not going to implementable if we try to provide any sort of
backwards compatibility with existing implementations. In current
implementations UAC are required to insert S-E header with currently
negotiated session timer role an refresh. As i have mentioned before UA
specify S-E to initiate session timer and to avoid both sides of the dialog
being refreshers and causing INVITE collisions.

More importantly your proposal is not going to help us in any way if
multiple proxies are present. Consider this scenario:

Alice          Proxy A          Proxy B         Bob
 |(1) INVITE     |               |               |
 |-------------->|               |               |
 |               |(2) INVITE     |               |
 |               | SE: 600       |               |
 |               |-------------->|               |
 |               |               |(3) INVITE     |
 |               |               | SE: 600       |
 |               |               |-------------->|
 |               |               |(4) UPDATE     |
 |               |               |<--------------|
 |               |(5) UPDATE     |               |
 |               | SE: 900       |               |
 |               |<--------------|               |
 |(6) UPDATE     |               |               |
 | SE: 600       |               |               |
 |<--------------|               |               |
 |(7) 200(UPD)   |               |               |
 | SE: 600       |               |               |
 | refresher=uas |               |               |
 |-------------->|               |               |
 |               |(8) 200(UPD)   |               |
 |               | SE: 600       |               |
 |               | refresher=uas |               |
 |               |-------------->|               |
 |               |               |(9) 200(UPD)   |
 |               |               | SE: 600       |
 |               |               | refresher=uas |
 |               |               |-------------->|
 |               |               |(10) 200(INV)  |
 |               |               |<--------------|
 |               |(11) 200(INV)  |               |
 |               | SE: 600       |               |
 |               | refresher=uac |               |
 |               |<--------------|               |
 |(12) 200(INV)  |               |               |
 | SE: 600       |               |               |
 | refresher=uac |               |               |
 |<--------------|               |               |
 |               |               |               |

As you can see Proxy B receives (2) INVITE with S-E. If the rules I have
proposed are applied, then Alice will get the same refresh interval and the
will be the refresher as a result of both UPDATE and INVITE transactions.

How is this going to work with your rules?

> can reduce the refresh interval but not
> >change the refresher if it is already specified, but this can potentially
> cause behavior changes to current RFC when UAC specifies the refresh
> interval.
>
> Sure, we can say that the UAC should send a new UPDATE if that happens,
> but existing deployments won't do that. But, we can minimize the risk of
> this to occur by specifying the following:
>
> 2) By default, a proxy must always insert the same S-E value in each
> direction. The proxy is only allowed to change the value if it is able to
> keep track of ongoing transactions etc.
>

Again, I am not sure what you are saying here and how this is going to
work. I have a feeling though that this is going to break existing
implementations.

Finally, in current session timer RFC we have unspecified behavior, which
is handling and generation of S-E header in intersecting transactions. This
is primarily UA specific behavior and has little to do with proxies.
Currently UA implement something random when generating UPDATE message or
processing mismatching S-E headers in UPDATE and INVITE. Whatever we
specify, UA implementations MUST be updated to support this. So let's try
to fix things there. Proxies contribute to the problem by being
inconsistent, i.e. inserting different S-E headers for no specific reason
and we can fix this as well, but I do not think the problem is fixable by
changing proxies alone.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Oct 2018 11:39:36 +0000

Hi,

>This is not going to implementable if we try to provide any sort of >backwards compatibility with existing implementations.
>In current implementations UAC are required to insert S-E header >with currently negotiated session timer role an refresh. As i have >mentioned before UA specify S-E to initiate session timer and to >avoid both sides of the dialog being refreshers and causing INVITE >collisions.

That's why it is a SHOUD - we wouldn't make existing deployments non-compliant, but we would discourage future implementations from doing it.

>More importantly your proposal is not going to help us in any way if >multiple proxies are present. Consider this scenario:

>As you can see Proxy B receives (2) INVITE with S-E. If the rules I >have proposed are applied, then Alice will get the same refresh >interval and the will be the refresher as a result of both UPDATE and >INVITE transactions.
>

In the same way: if 600 is too small for Proxy B then it sends 422.

>Again, I am not sure what you are saying here and how this is going to work. I have a feeling though that this is going to break existing implementations.

There is no fix we can do that won't break some existing implementations (UAs and/or proxies).

But, we can fix the problems for future implementations - and existing implementations that can be fixed. I am aware of proxies that CAN be updated, but before that is done we need to know how to update them.

>Finally, in current session timer RFC we have unspecified behavior, which is handling and generation of S-E header in intersecting transactions. This is primarily UA specific behavior and has little to do with
>proxies. Currently UA implement something random when generating UPDATE message or processing mismatching S-E headers in UPDATE and INVITE. Whatever we specify, UA implementations MUST be
>updated to support this. So let's try to fix things there. Proxies contribute to the problem by being inconsistent, i.e. inserting different S-E headers for no specific reason and we can fix this as well,

Well, that is what I have been suggesting...

>but I do not think the problem is fixable by changing proxies alone.

I am not saying that. We for sure can define that a UA should send a new UPDATE if it receives inconsistent information. If we distribute the "burdon" among proxies and UAs we can hope that at least some update their implementations :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Oct 2018 08:01:24 -0400

> In the same way: if 600 is too small for Proxy B then it sends 422.

In my example Proxy A needs a signalling request at most every 600 seconds.
Proxy B needs a signaling request at most every 900 seconds. The low
boundary for both proxies (Min-SE) is something different and can be 60
seconds for both. So, when session setup traverses both proxies, it should
negotiate the refresh interval of 600 seconds. Either Proxy A or B should
refuse the INVITE or UPDATE if refresh interval in S-E is greater then 60.

> But, we can fix the problems for future implementations - and existing
> implementations that can be fixed. I am aware of proxies that CAN be
> updated, but before that is done we need to know how to update them.
>
> is primarily UA specific behavior and has little to do with
> >proxies. Currently UA implement something random when generating UPDATE
> message or processing mismatching S-E headers in UPDATE and INVITE.
> Whatever we specify, UA implementations MUST be
> >updated to support this. So let's try to fix things there. Proxies
> contribute to the problem by being inconsistent, i.e. inserting different
> S-E headers for no specific reason and we can fix this as well,
>
> I am not saying that. We for sure can define that a UA should send a new
> UPDATE if it receives inconsistent information. If we distribute the
> "burdon" among proxies and UAs we can hope that at least some update their
> implementations :)
>

I do not mind updating multiple components, but what I am looking for is:

1. Proposed solution does not break existing use cases. Currently session
timer is initiated by both proxies and UA, but your proposal breaks that.
Some B2BUA are a little more then proxies and cannot initiate session timer
on their own. Some UA do not have the media so they need session timer to
negotiate a signaling keep alive.

2. Proposed solution does not change the currently specified behavior
unless this behavior is inconsistent. We should try to fix things by
putting restrictions around things which are currently not specified or
contradict each other. Your proposal prevents UA from inserting S-E in
INVITE. Current RFC requires UA to insert S-E for currently negotiated
session timer, so this is clearly not satisfied as well.

3. Proposed solution is implementable and does not impose undue burden on
an implementer. Sending an extra UPDATE from the UA should be trivial,
since it sends such transactions for every refresh anyway. In this case
refresh is sent with 0 second delay instead of half the expiration
interval. Changing how proxy handles session state is not trivial and
requires major logic changes. Forcing proxy to be consistent (only increase
Min-SE, only decrease S-E expiration, etc) should be acceptable, since this
is what proxies were supposed to be doing anyway and is currently
under-specified.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Oct 2018 12:10:51 +0000

Hi,

...

> 1. Proposed solution does not break existing use cases. Currently session timer is initiated by both proxies and UA, but your proposal breaks that. Some B2BUA are a little more then proxies and cannot
> initiate session timer on their own. Some UA do not have the media so they need session timer to negotiate a signaling keep alive.
>
> 2. Proposed solution does not change the currently specified behavior unless this behavior is inconsistent. We should try to fix things by putting restrictions around things which are currently not specified
> or contradict each other. Your proposal prevents UA from inserting S-E in INVITE. Current RFC requires UA to insert S-E for currently negotiated session timer, so this is clearly not satisfied as well.

With my proposals UAs would still be allowed to initiate session timer. The idea of recommending against UA including S-E is that the chance of 422 is smaller, but UAs would for sure still be allowed to do it.

And, to clarify, UA inserting S-E for negotiated session timer is ok, because the proxy should be fine with that value.

> 3. Proposed solution is implementable and does not impose undue burden on an implementer. Sending an extra UPDATE from the UA should be trivial, since it sends such transactions for every refresh anyway.
> In this case refresh is sent with 0 second delay instead of half the expiration interval. Changing how proxy handles session state is not trivial and requires major logic changes. Forcing proxy to be consistent
> (only increase Min-SE, only decrease S-E expiration, etc) should be acceptable, since this is what proxies were supposed to be doing anyway and is currently under-specified.

We are not "forcing" anything - we are giving recommendations on how to make things work.

And, regarding session state, if the uses a consistent S-E value there is no need to session state.

Regards,

Christer