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

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 12:47:46 +0000

Hi,

Assume Alice and Bob negotiates usage of the session-timer, and Alice becomes the refresher.

Now, if Bob for whatever reasons needs to send an UPDATE/re-INVITE request, is that a session refresh request? I.e., that the rules about adding S-E etc apply to it? My initial reading is that it does NOT apply – but again, the text is not that clear.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Sep 2018 13:30:56 -0400

On Thu, Sep 27, 2018 at 8:47 AM, Christer Holmberg <
[email-masked]> wrote:

> Now, if Bob for whatever reasons needs to send an UPDATE/re-INVITE
> request, is that a session refresh request? I.e., that the rules about
> adding S-E etc apply to it? My initial reading is that it does NOT apply –
> but again, the text is not that clear.
>
>
>

Yes, it is a session refresh request. Any INVITE/UPDATE request in the
dialog where session timer is negotiated is a session refresh request. S-E
rules do apply to it. The alternative would be stopping the session timer.

Another clue that both parties generate session refreshes is in RFC 4028
section 7.4 (https://tools.ietf.org/html/rfc4028#section-7.4) where it says:

If the session refresh request is not the initial one, it is RECOMMENDED
that the refresher parameter be set to 'uac' if the element sending the
request is currently performing refreshes, and *to 'uas' if its peer is
performing the refreshes.*

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 18:58:34 +0000

Hi,

>> Now, if Bob for whatever reasons needs to send an UPDATE/re-INVITE request, is that a session 
>> refresh request? I.e., that the rules about adding S-E etc apply to it? My initial reading is that it does 
>> NOT apply – but again, the text is not that clear.
>
> Yes, it is a session refresh request. Any INVITE/UPDATE request in the dialog where session timer is 
> negotiated is a session refresh request. S-E rules do apply to it. The alternative would be stopping the session timer.
>
> Another clue that both parties generate session refreshes is in RFC 4028 section 7.4 (https://tools.ietf.org/html/rfc4028#section-7.4) where it says:
>
> If the session refresh request is not the initial one, it is RECOMMENDED that the refresher parameter be set to 'uac' if the element 
> sending the request is currently performing refreshes, and to 'uas' if its peer is performing the refreshes.

True. However, section 7.4 seems to assume (it is not very clear, though) that the UAC (Bob in the example) supports the session timer extension. What if Bob doesn't support it to begin with (which would be the reason Alice was selected as the refresher)?

The session timer supporting proxies need to remember that Bob didn't support the session timer, so they don't think he is trying to disable it (by not including S-E in the request). And, at least one of the proxies must add a S-E to the request, so that the UAS (Alice) doesn't think that Bob is trying to disable it.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Sep 2018 15:47:31 -0400

On Thu, Sep 27, 2018 at 2:58 PM, Christer Holmberg <
[email-masked]> wrote:

> request, is that a session
> dialog where session timer is
> > negotiated is a session refresh request. S-E rules do apply to it. The
> alternative would be stopping the session timer.
> >
> that the refresher parameter be set to 'uac' if the element
> True. However, section 7.4 seems to assume (it is not very clear, though)
> that the UAC (Bob in the example) supports the session timer extension.
> What if Bob doesn't support it to begin with (which would be the reason
> Alice was selected as the refresher)?
>
> The session timer supporting proxies need to remember that Bob didn't
> support the session timer, so they don't think he is trying to disable it
> (by not including S-E in the request). And, at least one of the proxies
> must add a S-E to the request, so that the UAS (Alice) doesn't think that
> Bob is trying to disable it.
>

In my experience proxy will always add S-E to INVITE/UPDATE requests if it
was not present there and session timer was required by that proxy. Proxy
will only assume that session timer was cancelled if S-E was not present in
the success response. Keep in mind, UA do not need session timer with
exception of some B2BUA cases. Session timer is mostly needed for proxies
and the only way to turn off session timer is if UA and all the proxies on
path decide that they no longer need it, which also mostly happens with
B2BUA scenarios.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 20:53:16 +0000

Hi,

>> True. However, section 7.4 seems to assume (it is not very clear, though) that the UAC (Bob in the example) supports the 
>> session timer extension. What if Bob doesn't support it to begin with (which would be the reason Alice was selected as the refresher)?
>>
>> The session timer supporting proxies need to remember that Bob didn't support the session timer, so they don't think 
>> he is trying to disable it (by not including S-E in the request). And, at least one of the proxies must add a S-E to the request, so 
>> that the UAS (Alice) doesn't think that Bob is trying to disable it.
>
> In my experience proxy will always add S-E to INVITE/UPDATE requests if it was not present there and session timer was 
> required by that proxy. 

Let's assume Bob sends the UPDATE while the initial INVITE is still ongoing. As we have discussed, the S-E added by the proxies should be identical to the information used in the INVITE transaction. However, according to Table 2 a proxy is not allowed to add the refresher parameter if the UPDATE does not contain Supported:timer.

>Proxy will only assume that session timer was cancelled if S-E was not present in the success response. 

Yes. But, again, when Alice sends session refresh requests, proxies will have to remember that Bob doesn't support session timer, and will not include anything in the response to the session refresh requests.

Regards,

Christer

> Keep in mind, UA do not need session timer with exception of some B2BUA cases. Session timer is mostly needed for 
> proxies and the only way to turn off session timer is if UA and all the proxies on path decide that they no longer need it, 
> which also mostly happens with B2BUA scenarios.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Sep 2018 17:26:41 -0400

On Thu, Sep 27, 2018 at 4:53 PM, Christer Holmberg <
[email-masked]> wrote:

> >>> Another clue that both parties generate session refreshes is in RFC
> 4028 section 7.4 (https://tools.ietf.org/html/rfc4028#section-7.4) where
> it says:
> >>>
> >>> If the session refresh request is not the initial one, it
> is RECOMMENDED that the refresher parameter be set to 'uac' if the element
> >> True. However, section 7.4 seems to assume (it is not very clear,
> though) that the UAC (Bob in the example) supports the
> >> session timer extension. What if Bob doesn't support it to begin with
> (which would be the reason Alice was selected as the refresher)?
> >>
> support the session timer, so they don't think
> >> he is trying to disable it (by not including S-E in the request). And,
> at least one of the proxies must add a S-E to the request, so
> > In my experience proxy will always add S-E to INVITE/UPDATE requests if
> it was not present there and session timer was
> > required by that proxy.
>
> Let's assume Bob sends the UPDATE while the initial INVITE is still
> ongoing. As we have discussed, the S-E added by the proxies should be
> identical to the information used in the INVITE transaction. However,
> according to Table 2 a proxy is not allowed to add the refresher parameter
> if the UPDATE does not contain Supported:timer.
>

What does RFC 4208 Table 2 have to do with proxy? It controls the UAS
behavior. Proxy can insert S-E to requests regardless of presence of
"Supported: timer" header (see
https://tools.ietf.org/html/rfc4028#section-8.1).

> Yes. But, again, when Alice sends session refresh requests, proxies will
> have to remember that Bob doesn't support session timer, and will not
> include anything in the response to the session refresh requests.
>

Yes, proxy will cancel session timer if S-E was not present or added to he
request and S-E is not present in the response, or no S-E header in
response and neither UAC nor UAS include "Supported: timer". Please see
https://tools.ietf.org/html/rfc4028#section-8.2 for more details.

It is really hard to cancel session-timer. Everybody (both UA and all the
proxies) must agree that they no longer need it or both UA would need to
stop supporting it.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 21:42:18 +0000

Hi,

>> Let's assume Bob sends the UPDATE while the initial INVITE is still ongoing. As we have discussed, the S-E added by the proxies 
>> should be identical to the information used in the INVITE transaction. However, according to Table 2 a proxy is not allowed to add 
>> the refresher parameter if the UPDATE does not contain Supported:timer.
>
> What does RFC 4208 Table 2 have to do with proxy? It controls the UAS behavior. Proxy can insert S-E to requests regardless of 
> presence of "Supported: timer" header (see https://tools.ietf.org/html/rfc4028#section-8.1).
 
The proxy can insert S-E, but it MUST NOT insert the refresher parameter.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Sep 2018 17:57:09 -0400

On Thu, Sep 27, 2018 at 5:42 PM, Christer Holmberg <
[email-masked]> wrote:

> ongoing. As we have discussed, the S-E added by the proxies
> >> should be identical to the information used in the INVITE transaction.
> However, according to Table 2 a proxy is not allowed to add
> behavior. Proxy can insert S-E to requests regardless of

This is correct. In practice proxy should never insert refresher parameter,
just S-E without one. Why is this important?
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 22:12:02 +0000

Hi,

It is important if the UPDATE is sent within an ongoing INVITE transaction, as we have been talking about mandating the session timer parameters being identical.

Regards,

Christer

Sent from my iPhone

On 28 Sep 2018, at 0.57, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

This is correct. In practice proxy should never insert refresher parameter, just S-E without one. Why is this important?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 27 Sep 2018 18:18:50 -0400

On Thu, Sep 27, 2018 at 6:12 PM, Christer Holmberg <
[email-masked]> wrote:

> It is important if the UPDATE is sent within an ongoing INVITE
> transaction, as we have been talking about mandating the session timer
> parameters being identical.
>
>
If proxy added S-E header to INVITE it should add the same header to
UPDATE. In both cases S-E header should not include refresher.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 03:07:55 +0000

Hi,

The UA (Alice) might have added the the S-E.

Regards,

Christer

Sent from my iPhone

On 28 Sep 2018, at 1.18, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Sep 27, 2018 at 6:12 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
It is important if the UPDATE is sent within an ongoing INVITE transaction, as we have been talking about mandating the session timer parameters being identical.

If proxy added S-E header to INVITE it should add the same header to UPDATE. In both cases S-E header should not include refresher.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 00:13:20 -0400

Can you please provide the full example?

Roman Shpount

On Thu, Sep 27, 2018, 11:07 PM Christer Holmberg <
[email-masked]> wrote:

> On 28 Sep 2018, at 1.18, Roman Shpount <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 07:00:19 +0000

Alice                            Proxy                       Bob (does not support session timer)

1. ------ INVITE ------------→
             S-E: 100;refresher=uac

2.                                            ------- INVITE ------------->
                                                       S-E: 100;refresher=uac

3.                                            <------ 18x -------------------

4.  <------ 18x ----------------

5.                                            <------ UPDATE -------------

6.  <------ UPDATE ----------
                 S-E: 100
7.                                            <------ 200 -------------------

8.  <------ 200 ----------------
                 S-E: 100;refresher=uac

The UPDATE in message 5 is sent while the INVITE transaction is still active.

In message 6, the proxy is not allowed (section 8.1) to include the refresher parameter. However, in message 8, the proxy MUST (section 8.2) include the refresher parameter.

This means that the S-E in the UPDATE sent while the INVITE transaction is still ongoing is not aligned with the 200 response to the INVITE.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Friday 28 September 2018 at 07:13
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Session-timer: Non-refresher sending UPDATE/re-INVITE - is it a session refresh request?

On Thu, Sep 27, 2018, 11:07 PM Christer Holmberg <mailto:[email-masked]> wrote:
Hi, 

Regards,

Christer
Sent from my iPhone

On 28 Sep 2018, at 1.18, Roman Shpount <mailto:[email-masked]> wrote:
On Thu, Sep 27, 2018 at 6:12 PM, Christer Holmberg <mailto:[email-masked]> wrote:
It is important if the UPDATE is sent within an ongoing INVITE transaction, as we have been talking about mandating the session timer parameters being identical.

Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 Sep 2018 18:05:06 +0900

Hi,

It's about time we check up concrete protocol sequences.
If you notice any irregular behavior, please comment on the problem,

Assuming that Alice's UA and proxies support timer, Bob's UA does not support timer,

[scenario 1]
1. Alice sends 1st INVITE with SE
2. Bob returns 200 without SE
3. proxies add SE refresher=uacto the response

[scenario 2]
1. Alice sends 1st INVITE with SE
2. Bob sends UPDATE without SE
3. proxies may add SE to the UPDATE request
4. Alice returns 200(UPDATE) with SE refresher=uas (Table 2)
5. Bob returns 200(INVITE) without SE
6. proxy add SE refresher=uacto the response

[scenario 3] no session timer
1. Bob sends 1st INVITE without SE
2. no proxies add SE to the request
3. Alice returns 200 without SE

3: ISTM the behavior of UAS(section 9) is unclear when UAC does not support timer.

[scenario 4]
1. Bob sends 1st INVITE without SE
2. proxies may add SE to the request
3. Alice returns 200 with SE refresher=uas (Table 2)

[scenario 5]
1. Bob sends 1st INVITE without SE
2. no proxies add SE to the request
3. Bob sends UPDATE without SE
4. Alice returns 200(UPDATE) without SE
5. Alice returns 200(INVITE) without SE

[scenario 6]
1. Bob sends 1st INVITE without SE
2. proxies adds SE to the INVITE request
3. Bob sends UPDATE without SE
4. proxies add SE to the UPDATE request
5. Alice returns 200(UPDATE) with SE refresher=uas (Table 2)
6. Alice returns 200(INVITE) with SE refresher=uas (Table 2)

[scenario 7] refresh
1. Alice sends UPDATE with SE refresher=uac
2. Bob returns 200 without SE
3. proxies add SE refresher=uac to the response

[scenario 8] unintended refresh
1. Bob sends UPDATE without SE
2. proxies add SEto the UPDATE request
3. Alice returns 200 with SE(refresher=uas)

[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

Regards,
Shinji

On 2018/09/28 5:53, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 09:21:43 +0000

Hi,
    
    [scenario 2]

What I wanted to point out is that proxies are not allowed to add the refresher parameter to the UPDATE request (message 3).

So, the SE header in messages 3 and 6 will not be identical, as the refresher parameter will be missing from message 3.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 Sep 2018 18:58:44 +0900

Hi,

Alice          Proxy            Bob
 |(1) INVITE     |               |
 | SE: 3600      |               |
 |-------------->|               |
 |               |(a) INVITE     |
 |               | SE: 2400      |
 |               |-------------->|
 |               |               |
 |               |(2) UPDATE     |
 |               |<--------------|
 |(3) UPDATE     |               |
 | SE: 2400      |               |
 |<--------------|               |
 |               |               |
 |(4) 200(UPD)   |               |
 | SE: 2400      |               |
 | refresher=uas |               |
 |-------------->|               |
 |               |(b) 200(UPD)   |
 |               | SE: 2400      |
 |               | refresher=uas |
 |               |-------------->|
 |               |               |
 |               |(5) 200(INV)   |
 |               |<--------------|
 |(6) 200(INV)   |               |
 | SE: 2400      |               |
 | refresher=uac |               |
 |<--------------|               |

The success response for the UPDATE is message 4.
The success response for the INVITE is message 6.

The SE header in messages 4 and 6 will be identical.
Is that a problem?

Regards,
Shinji

On 2018/09/28 18:21, Christer Holmberg wrote:
>     6. proxy add SE refresher=uac to the response
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 06:00:13 -0400

On Fri, Sep 28, 2018 at 3:00 AM, Christer Holmberg <
[email-masked]> wrote:

>                                                        S-E:
> 100;refresher=uac
> In message 6, the proxy is not allowed (section 8.1) to include the
> refresher parameter. However, in message 8, the proxy MUST (section 8.2)
> include the refresher parameter.
>
> This means that the S-E in the UPDATE sent while the INVITE transaction is
> still ongoing is not aligned with the 200 response to the INVITE.
>
>
You are correct. This should not be a problem though since UDPATE will not
include Supported: timer, so nothing except Alice being a refresher can be
negotiated.

Also, in your example if INVITE in 1 does not include refresher, proxy will
still add refresher=uac in 8, since 200 OK in 7 does not include S-E or
Supported: timer.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 06:04:54 -0400

>  | SE: 3600      |               |

This should not be a problem since there is no ambiguity about what is
negotiated.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 12:32:27 +0000

Hi,

> You are correct. This should not be a problem though since UDPATE will not include Supported: timer, so nothing except Alice being a refresher can be negotiated.

My point is that we cannot have a generic rule mandating the proxy to insert the same S-E in the mid-INVITE update as it will insert in the 200 OK response.

We can probably solve it by saying something like: "Must insert the same timer value, and must not change the refresher", or something like that.

> Also, in your example if INVITE in 1 does not include refresher, proxy will still add refresher=uac in 8, since 200 OK in 7 does not include S-E or Supported: timer.

Correct. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 12:34:55 +0000

Hi,

Alice          Proxy            Bob
 |(1) INVITE     |               |
 | SE: 3600      |               |
 |-------------->|               |
 |               |(a) INVITE     |
 |               | SE: 2400      |
 |               |-------------->|
 |               |               |
 |               |(2) UPDATE     |
 |               |<--------------|
 |(3) UPDATE     |               |
 | SE: 2400      |               |
 |<--------------|               |
 |               |               |
 |(4) 200(UPD)   |               |
 | SE: 2400      |               |
 | refresher=uas |               |
 |-------------->|               |
 |               |(b) 200(UPD)   |
 |               | SE: 2400      |
 |               | refresher=uas |
 |               |-------------->|
 |               |               |
 |               |(5) 200(INV)   |
 |               |<--------------|
 |(6) 200(INV)   |               |
 | SE: 2400      |               |
 | refresher=uac |               |
 |<--------------|               |

> This should not be a problem since there is no ambiguity about what is negotiated.

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.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 12:11:07 -0400

On 9/27/18 1:30 PM, Roman Shpount wrote:
> On Thu, Sep 27, 2018 at 8:47 AM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     __ __
>     request, is that a session refresh request? I.e., that the rules
>     about adding S-E etc apply to it? My initial reading is that it does
>     NOT apply – but again, the text is not that clear.____
> 
> dialog where session timer is negotiated is a session refresh request. 
> S-E rules do apply to it. The alternative would be stopping the session 
> timer.

Agree. I will reiterate that the concepts and terminology are all messed 
up and not very consistent with the actual mechanism.

Think of it this way: every new INVITE/UPDATE within the dialog is a new 
and distinct negotiation of session timer, independent of what was 
previously negotiated. If the transaction successfully completes, then 
the new timer (or non-timer) negotiated *replaces* whatever was 
previously in effect.

The timer expiring is one mechanism for triggering an INVITE/UPDATE 
transaction that provides a keep-alive. Other reasons for sending 
INVITE/UPDATE will preempt that.

This discussion is further convincing me we should simply begin working 
on a bis. It should be a major rewrite of the expository text, while the 
actual mechanism can remain the same except for clearing up the race we 
have been discussing.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 12:28:01 -0400

> Hi,

Hi Shinji! I don't hear from you very often. Glad to see you here!

> If you notice any irregular behavior, please comment on the problem,

These all seem good to me, except comment at end.

> 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: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 12:48:12 -0400

On Fri, Sep 28, 2018 at 8:34 AM, 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.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 20:34:47 +0000

Hi,

>> 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.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 17:13:44 -0400

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

> have a generic rule mandating the
> 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.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 22:44:36 +0000

Hi,

>> 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 |               |
>> |<--------------|               |
>>
>> 2. Proxy needs to refresh every 900, since 600 is less it forwards the S-E header as is to Bob
>> 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
>> 7. Bob sends 200 Ok to INVITE without S-E since it does not support session timer
>> 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.

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...

Regards,

Christer

---

From: [email-masked]
Date: Sat, 29 Sep 2018 07:16:37 +0800

Hi
Since in (5) the refresher was already set. It is not allowed to change it in (8).  See table 2 and the following text. And as Christer wrote the proxy must be staateful when doing such stuff.

Regards

Roland

Am 29.09.2018 05:13 schrieb Roman Shpount <[email-masked]>:

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

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.

Regards,

_____________

Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 19:23:27 -0400

On Fri, Sep 28, 2018 at 7:16 PM, <[email-masked]> wrote:

> Since in (5) the refresher was already set. It is not allowed to change it
> in (8).  See table 2 and the following text. And as Christer wrote the
> proxy must be staateful when doing such stuff.
>
>
I do not think you are correct here.

Since INVITE and UPDATE transactions are in opposite directions, this is
the same refresher. Also, what does Table 2 has to do with proxy response
processing? Proxy behavior is defined in Section 8.2. Table 2 is for UAS.

Finally, stateful proxy means quite a specific thing, i.e. stateful
transaction processing, not dialog stateful, so this does not help.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Sep 2018 19:35:16 -0400

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

> change the S-E expiration, or
> cross-transaction correlation needs
> transactions might no even end up on
> >> 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: OKUMURA Shinji <[email-masked]>
Date: Sat, 29 Sep 2018 21:35:26 +0900

Hi Paul,
It's been a while. ;-)

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.

Regards,
Shinji

> These all seem good to me, except comment at end.
(snip)

---

From: OKUMURA Shinji <[email-masked]>
Date: Sun, 30 Sep 2018 00:10:18 +0900

Hi,

A proxy must insert the same timer value, and must not change the
refresher "as much as possible"

I like this rule. But when Bob supports timer, Bob may insert SE: 1200.
That is to say that the se-value may be updated.

Alice          Proxy            Bob
 |(1) INVITE     |               |
 | SE: 3600      |               |
 |-------------->|               |
 |               |(a) INVITE     |
 |               | SE: 2400      |
 |               |-------------->|
 |               |               |
 |               |(2) UPDATE     |
 |               | SE: 1200      |
 |               |<--------------|
 |(3) UPDATE     |               |
 | SE: 1200      |               |
 |<--------------|               |
 |               |               |
 |(4) 200(UPD)   |               |
 | SE: 1200      |               |
 | refresher=uas |               |
 |-------------->|               |
 |               |(b) 200(UPD)   |
 |               | SE: 1200      |
 |               | refresher=uas |
 |               |-------------->|
 |               |               |
 |               |(5) 200(INV)   |
 |               | SE: 1200      |
 |               |<--------------|
 |(6) 200(INV)   |               |
 | SE: 1200      |               |
 | refresher=uac |               |
 |<--------------|               |

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Sun, 30 Sep 2018 01:03:58 +0900

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?

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Sep 2018 13:33:40 -0400

Hi Shinji,

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Sep 2018 13:37:33 -0400

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Sep 2018 18:27:35 +0000

Hi,

> 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.
>
> Can you think of a reason why a proxy that isn't session stateful would want a session timer?

Section 8 of RFC 4028 says:

"Stateless proxies MUST NOT attempt to request session timers."

Also, if you read the Introduction etc, it only talks about stateful proxies.

Regards,

Christer

>>>>> the refresher, in the "mid-INVITE" UPDATE request/response, but in 
>>>>> some
>>> cases it will not indicate the
>>>>> refresher at all.
>>>>>
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> the same proxy instance, especially since initial INVITE is sent 
>>>>> to the
>>> pre-configured proxy, but UPDATE is sent
>> 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.
>>
>>> 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: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Sep 2018 15:12:58 -0400

> Also, if you read the Introduction etc, it only talks about stateful proxies.

IIUC, when used without qualification, "stateful proxy" means 
*transaction stateful*. And indeed it isn't possible to do the proxy 
role for RFC4028 without being transaction stateful.

That is still true to handle the nested UPDATE-within-INVITE cases in 
the ways we have been discussing. The necessary state is part of the 
INVITE transaction, but then the UPDATE transaction needs access to it. 
It doesn't require longer lived session-state.

But I'm suggesting that unless a proxy is session-stateful then there 
probably is no reason for it to want to mess with session timers.

I'm interested in hearing of well motivated use cases for UAs and 
non-session-stateful proxies to want a session timer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Sep 2018 19:22:22 +0000

Hi,

> IIUC, when used without qualification, "stateful proxy" means *transaction stateful*. And indeed it 
> isn't possible to do the proxy role for RFC4028 without being transaction stateful.
>
> That is still true to handle the nested UPDATE-within-INVITE cases in the ways we have been discussing. The 
> necessary state is part of the INVITE transaction, but then the UPDATE transaction needs access to it. 

Correct.

> But I'm suggesting that unless a proxy is session-stateful then there probably is no reason for it to want to mess with session timers.

Agree.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 29 Sep 2018 18:22:12 -0400

> non-session-stateful proxies to want a session timer.
This is about session state. But most importantly it is about how much work
proxy needs to do to maintain session state. The main use case for proxy
session timer is billing. Whenever new dialog is established an entry is
created in the DB (and by this I mean traditional database used for storage
of call records). When dialog is ended, call record is closed and balance
for account is updated. The problem with this case is some percentage of
the calls die without sending a disconnect message. These calls are cleaned
up using SIP session timer. In this implementation proxy updates a DB call
record for each INVITE/UPDATE message it receives for the dialog with
current time. Some sort of timer based process scans the call records table
and closes the call records that has not been updated since the last scan.
Most of the time all of this logic is implemented in proxy config script.
The problem with all if this is that it puts a limit on how complex the
proxy request handling rules can be.

As far as use case for UA initiating session timer is concerned it is about
negotiating refresh interval and refresher.  UA use periodic signaling
exchanges to make sure remote is fully operational and did not crash (some
crashes kill the signaling but keep the media. Some dialogs do not have
media to monitor the session). Without session timer negotiation both sides
of the call become refreshers with the same refresh interval which results
in INVITE collisions.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Sep 2018 10:38:04 +0000

Hi,

I don’t disagree with your charging use-case, but in my experience such proxies do insert Record-Route (in order to receive the BYE etc), and they are session stateful.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 30 September 2018 01:22
To: Paul Kyzivat <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; OKUMURA Shinji <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Session-timer: Non-refresher sending UPDATE/re-INVITE - is it a session refresh request?

On Sat, Sep 29, 2018 at 3:13 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
I'm interested in hearing of well motivated use cases for UAs and
non-session-stateful proxies to want a session timer.

This is about session state. But most importantly it is about how much work proxy needs to do to maintain session state. The main use case for proxy session timer is billing. Whenever new dialog is established an entry is created in the DB (and by this I mean traditional database used for storage of call records). When dialog is ended, call record is closed and balance for account is updated. The problem with this case is some percentage of the calls die without sending a disconnect message. These calls are cleaned up using SIP session timer. In this implementation proxy updates a DB call record for each INVITE/UPDATE message it receives for the dialog with current time. Some sort of timer based process scans the call records table and closes the call records that has not been updated since the last scan. Most of the time all of this logic is implemented in proxy config script. The problem with all if this is that it puts a limit on how complex the proxy request handling rules can be.

As far as use case for UA initiating session timer is concerned it is about negotiating refresh interval and refresher.  UA use periodic signaling exchanges to make sure remote is fully operational and did not crash (some crashes kill the signaling but keep the media. Some dialogs do not have media to monitor the session). Without session timer negotiation both sides of the call become refreshers with the same refresh interval which results in INVITE collisions.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Sep 2018 15:38:22 -0400

On Sun, Sep 30, 2018 at 6:38 AM Christer Holmberg <
[email-masked]> wrote:

> I don’t disagree with your charging use-case, but in my experience such
> proxies do insert Record-Route (in order to receive the BYE etc), and they
> are session stateful.
>

Yes, these proxies do insert Record-Route and they are station stateful.
Please note that storing information for each received INVITE request and
response, which would be required to detect UPDATE during INVITE, would
require at least twice as many DB updates then storing information only for
each successful INVITE, which is done now. Correctly handling INVITE
collisions of failed INVITE requests and correlating them to UPDATE
transactions would complicate the proxy logic. All of this is doable but
would create a new additional burden on the proxies. As I have said
earlier, this is not just about the session state but also about the amount
of updates done to the session state and logic required to manage it.
Currently both are fairly rudimentary which allows proxies to scale better.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Sep 2018 19:52:07 +0000

> Yes, these proxies do insert Record-Route and they are station stateful. Please note that storing information 
> for each received INVITE request and response, which would be required to detect UPDATE during INVITE, 
> would require at least twice as many DB updates then storing information only for each successful INVITE, 
> which is done now. Correctly handling INVITE collisions of failed INVITE requests and correlating them to 
> UPDATE transactions would complicate the proxy logic. All of this is doable but would create a new additional 
> burden on the proxies. As I have said earlier, this is not just about the session state but also about the amount 
> of updates done to the session state and logic required to manage it. Currently both are fairly rudimentary which
> allows proxies to scale better.

If we want to say that a proxy must not change the S-E value in a "mid-INVITE" UPDATE, the proxy needs to know that the INVITE transaction is still ongoing (and it of course needs to know what S-E value it has used for the INVITE).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Sep 2018 16:12:30 -0400

On Sun, Sep 30, 2018 at 3:52 PM Christer Holmberg <
[email-masked]> wrote:

> Please note that storing information
> > burden on the proxies. As I have said earlier, this is not just about
> the session state but also about the amount
> If we want to say that a proxy must not change the S-E value in a
> "mid-INVITE" UPDATE, the proxy needs to know that the INVITE transaction is
> still ongoing (and it of course needs to know what S-E value it has used
> for the INVITE).
>
>
This is exactly what I was saying: If you impose this rule on the proxy,
you will double the number of DB updates done by the proxy comparing to
what it is doing now. This can create a major barrier to adoption. If you
implement the ambiguity resolution rule on the client, then proxy load will
remain the same. Furthermore, you will need to have this rule for the
client anyway since legacy proxies will not follow the new rule.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Sep 2018 20:23:08 +0000

>> If we want to say that a proxy must not change the S-E value in a "mid-INVITE" UPDATE, the proxy needs to know that 
>> the INVITE transaction is still ongoing (and it of course needs to know what S-E value it has used for the INVITE).
>
> This is exactly what I was saying: If you impose this rule on the proxy, you will double the number of DB updates done by 
> the proxy comparing to what it is doing now. This can create a major barrier to adoption. If you implement the ambiguity 
> resolution rule on the client, then proxy load will remain the same. Furthermore, you will need to have this rule for the 

In my experience it is always easier to fix a "few" proxies than tons of clients, but please explain the "resolution rule on the client" you have in mind.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 Sep 2018 17:22:36 -0400

On 9/29/18 6:22 PM, Roman Shpount wrote:
> This is about session state.

Based on your description below, I would consider such a proxy to be 
session stateful, and so it fits into my notion of why to request a 
session timer.

> But most importantly it is about how much 
> work proxy needs to do to maintain session state. The main use case for 
> proxy session timer is billing. Whenever new dialog is established an 
> entry is created in the DB (and by this I mean traditional database used 
> for storage of call records). When dialog is ended, call record is 
> closed and balance for account is updated. The problem with this case is 
> some percentage of the calls die without sending a disconnect message. 
> These calls are cleaned up using SIP session timer. In this 
> implementation proxy updates a DB call record for each INVITE/UPDATE 
> message it receives for the dialog with current time. Some sort of timer 
> based process scans the call records table and closes the call records 
> that has not been updated since the last scan. Most of the time all of 
> this logic is implemented in proxy config script. The problem with all 
> if this is that it puts a limit on how complex the proxy request 
> handling rules can be.

This issue of how to structure the session timer rules so as to minimize 
the work required of a particular set of session stateful proxies should 
probably be a separate discussion. ISTM that there are many ways to skin 
this cat.

> As far as use case for UA initiating session timer is concerned it is 
> about negotiating refresh interval and refresher.  UA use periodic 
> signaling exchanges to make sure remote is fully operational and did not 
> crash (some crashes kill the signaling but keep the media. Some dialogs 
> do not have media to monitor the session). Without session timer 
> negotiation both sides of the call become refreshers with the same 
> refresh interval which results in INVITE collisions.

OK, that makes some sense.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 Sep 2018 17:25:06 -0400

On 9/30/18 3:38 PM, Roman Shpount wrote:
> On Sun, Sep 30, 2018 at 6:38 AM Christer Holmberg 
>     I don’t disagree with your charging use-case, but in my experience
>     such proxies do insert Record-Route (in order to receive the BYE
>     etc), and they are session stateful.
> 
> 
> Please note that storing information for each received INVITE request 
> and response, which would be required to detect UPDATE during INVITE, 
> would require at least twice as many DB updates then storing information 
> only for each successful INVITE, which is done now. Correctly handling 
> INVITE collisions of failed INVITE requests and correlating them to 
> UPDATE transactions would complicate the proxy logic. All of this is 
> doable but would create a new additional burden on the proxies. As I 
> have said earlier, this is not just about the session state but also 
> about the amount of updates done to the session state and logic required 
> to manage it. Currently both are fairly rudimentary which allows proxies 
> to scale better.

Are you saying that the only session state these proxies have is in the 
DB, with none in memory? In-memory state would be sufficient to resolve 
all these issues.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Sep 2018 23:29:13 -0400

> DB, with none in memory? In-memory state would be sufficient to resolve
What I am saying  is that proxy has in-memory transaction state but only
session state is a call detail record in the persistent database. Only
state available across transactions is call record in the DB.

What I am trying to get here is to keep session timer simple, so it is the
standard which is actually used instead of turning it into sip-outbound,
which no one understands or implements. As it stands right now I am not
aware of anybody implementing the rule about re-inserting refresher by
proxy if one of the end points does not support session timer. This use
case is simply ignored since it provides little additional benefit (only a
small additional percentage of calls have only one UA supporting session
timer vs calls where both support session timer), but requires a lot of
additional resources for stateful processing of INVITE transactions.
Furthermore, where session timer is critical for call handling, UA which do
not support session timer are placed behind B2BUA (SBC) which injects SBC
support.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Sep 2018 23:35:24 -0400

On Sun, Sep 30, 2018 at 4:23 PM Christer Holmberg <
[email-masked]> wrote:

> In my experience it is always easier to fix a "few" proxies than tons of
> clients, but please explain the "resolution rule on the client" you have in
> mind.
>
>
The clients will need to be fixed anyway, since only some proxies would be
updated and ambiguous scenarios would continue to be present.

My rule for the client  is very simple: 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.

We can then put SHOULD strength rules on proxies/UA to avoid mismatches,
but the rule above would act as a catch all for all cases when this fails.

Regards,
_____________
Roman Shpount