Subject: [sipcore] Session-timer: UAS receiving mid-INVITE request with Supported:timer but no Session-Expires

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Oct 2018 09:45:07 +0000

Hi,

Section 8.1 of RFC 4028 says:

   “To request a session timer for a session, a proxy makes sure that a
   Session-Expires header field is present in a session refresh request
   for that session.”

But, the text also says:

   “A proxy MAY insert a Session-Expires header field
   in the request before forwarding it if none was present in the
   request.”

In my reading, this might end up in the UAS receiving a request without Session-Expires. However, if the UAC supports session timer, that request might still contain Supported: timer.

Section 9 contains the following text_

   “If the incoming request contains a Supported header field with a
   value 'timer' but does not contain a Session-Expires header, it means
   that the UAS is indicating support for timers but is not requesting
   one.  The UAS may request a session timer in the 2XX response by
   including a Session-Expires header field.  The value MUST NOT be set
   to a duration lower than the value in the Min-SE header field in the
   request, if it is present.”

First, I think there is a spelling error. It should be “that the UAC is indicating support for timers”.

Second, I think it should be clarified that, in the case of an ongoing session timer INVITE transaction, the UAS should also in this case insert whatever S-E value it intends to insert in the 2XX response to the INVITE.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2018 11:34:31 -0400

>     in the request before forwarding it if none was present in the

The above are consistent - just different ways of saying the same thing.

> In my reading, this might end up in the UAS receiving a request without 
> Session-Expires. However, if the UAC supports session timer, that 
> request might still contain Supported: timer.

Yes. Again, this is fine.

>     one. 

This section is about UAS behavior, and so "incoming request" in this 
context is the *received* by the UAS, and so it indicates what the UAC 
supports.

>     The UAS may request a session timer in the 2XX response by

This part is fine.

> indicating support for timers”.

I agree.

> Second, I think it should be clarified that, in the case of an ongoing 
> session timer INVITE transaction, the UAS should also in this case 
> insert whatever S-E value it intends to insert in the 2XX response to 
> the INVITE.

Your wording here is confusing me. Where is it that you want an S-E 
inserted to match what it intends to insert in a (later) 2xx?

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Oct 2018 15:39:56 +0000

Hi,

...
    
>    context is the *received* by the UAS, and so it indicates what the UAC 
  
Yes.

>    inserted to match what it intends to insert in a (later) 2xx?
  
In the response to the reguest (e.g., an UPDATE) that contains Supported:timer, but no S-E.

Now, based on previous discussions, if we say that proxies should insert the same S-E in all request, this should obviously not happen.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 23 Oct 2018 17:53:46 +0900

Hi,

On 2018/10/22 18:45, Christer Holmberg wrote:
(snipping)
> First, I think there is a spelling error. It should be “that the UAC is indicating support for timers”.

This is already reported.
https://www.rfc-editor.org/errata/eid632

> Second, I think it should be clarified that, in the case of an ongoing session timer INVITE transaction, the UAS should also in this case insert whatever S-E value it intends to insert in the 2XX r…

When an INVITE transaction is going on, obviously there is no need for the UAC to intentionally send an UPDATE for a new negotiation of session timer.
But UAs send an UPDATE for various reasons(offer/answer, precondition, etc.), so we should prescribe a procedure to send an UPDATE request and response regardless of a session-timer.

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Oct 2018 09:17:10 +0000

Hi,

 >   https://www.rfc-editor.org/errata/eid632
   
Ok. Good.

>> Second, I think it should be clarified that, in the case of an ongoing session timer INVITE transaction, the UAS should also in this case
>> insert whatever S-E value it intends to insert in the 2XX response to the INVITE.
>    

Correct. And, my suggestion is that the UAC should include the same values (Supported, S-E etc) in the UDPATE.

But, my issue was the UAS behavior if it, for whatever reason, receives an UPDATE that only contains Supported: timer.

Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 23 Oct 2018 21:10:35 +0900

Hi,

My suggestion is the below,

If all entities(UAC, UAS and proxy) are aware that an INVITE transaction
is going on with a negotiation of session timer, they only have to
ignore SE and Min-SE header.
Therefore UAC does not insert SE and Min-SE in the request, proxy does
not add or modify SE and Min-SE in the request and UAS does not insert
SE in the response. Of course proxy and UAS does not reject the request
by 422 response.

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Oct 2018 12:30:45 +0000

Hi,
    
>    SE in the response. Of course proxy and UAS does not reject the request
  
The UAs and proxies may have different opinion on whether an INVITE transaction is ongoing, as messages may get delayed in the network etc.

I think we should try to have common procedures, no matter whether a request/response is sent/received within an ongoing INVITE transaction or not.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Oct 2018 08:41:01 -0400

Hi Shinji,

> SE in the response. Of course proxy and UAS does not reject the request
Proxy is not going to be aware that there is an INVITE transaction going on
that negotiates session timer without significant changes on how proxies
operates. Furthermore, because of network transmission delays and timing
UAC, UAS, and proxy can be of different opinion if INVITE transaction is
ongoing. Because of this your suggestion is not viable.

Normal behavior should be:

1. If an element (UAC, Proxy, UAS) needs a session refresh, it should
insert this value in S-E header if not present.
2. If element has a constraint on how often it can perform session refresh,
it should insert it into Min-SE value, if not present.
3. If S-E header is present and current value of S-E is higher then desired
session refresh interval, element should reduce S-E value to the desired
value, as long as it is higher then Min-SE.
4. If S-E is lower then minimum supported refresh interval, message should
be refused with 422.
5. If Min-SE in the message is lower then minimum supported refresh, Min-SE
value should be increased to minimum supported refresh interval.

If these rules are followed, as long as desired refresh interval and
minimum supported refresh interval stay the same for each network element,
negotiation always ends up with the same result.

There are a few more complications, such as dealing with only one element
supporting session timer, dealing with situation where network elements do
not follow those rules or being malicious, but these are, essentially edge
cases.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Oct 2018 10:41:26 -0400

On 10/23/18 8:41 AM, Roman Shpount wrote:
> Hi Shinji,
> 
> 
> On Tue, Oct 23, 2018 at 8:10 AM OKUMURA Shinji <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Proxy is not going to be aware that there is an INVITE transaction going 
> on that negotiates session timer without significant changes on how 
> proxies operates.

I don't understand how this can be so hard. Assuming the proxy is 
transaction stateful, it has awareness that there is an INVITE 
transaction in progress. Stateless proxies are a different story, but 
they shouldn't be involved in session timer.

Or are you thinking of cases where there are redundant proxies, and the 
UPDATE goes to a different proxy than the INVITE?

> Furthermore, because of network transmission delays 
> and timing UAC, UAS, and proxy can be of different opinion if INVITE 
> transaction is ongoing.

This does potentially cause trouble. It is a good place to focus attention.

The sender of the UPDATE is the one that potentially initiates the 
confusion here. So I think it is obligated to construct the UPDATE so 
that it will be properly handled regardless of what order the other 
parties receive it.

A good place to start would be to say that a UA MUST NOT send an UPDATE 
containing an S-E within an INVITE that didn't have an S-E.

> Because of this your suggestion is not viable.
> 

Are you suggesting that the below rules apply independently to each 
message (INVITE/UPDATE request/response)? It would certainly be nice to 
have such a simple approach if it can be made to work.

> insert this value in S-E header if not present.

What is "this value"? And insert it in what?

Can the element's "need" for session refresh change over the course of a 
dialog? Are there any constraints on when and how it can change?

> 2. If element has a constraint on how often it can perform session 
> refresh, it should insert it into Min-SE value, if not present.
> 3. If S-E header is present and current value of S-E is higher then 
> desired session refresh interval, element should reduce S-E value to the 
> desired value, as long as it is higher then Min-SE.
> 4. If S-E is lower then minimum supported refresh interval, message 
> should be refused with 422.
> 5. If Min-SE in the message is lower then minimum supported refresh, 
> Min-SE value should be increased to minimum supported refresh interval.

Note that changes in values can only occur in requests. Once a response 
has been sent the values can't change along the path, else there will be 
disagreement on what the values are.

You only state the rules for what is inserted. You aren't saying how 
those need to be acted upon. For instance, what if a UAS has received an 
INVITE with one set of values, and an UPDATE with a different set of 
values? What should go in the responses to each?

And what if a UAC has received a response to a nested UPDATE with one 
set of values, and then an INVITE response with a different set?

We need to cover all the potentially troublesome orderings, including 
the ones that include message reordering. I expect we will need to 
actually enumerate these and verify that whatever we specify works for 
them all.

> minimum supported refresh interval stay the same for each network 
> element, negotiation always ends up with the same result.
> 
> There are a few more complications, such as dealing with only one 
> element supporting session timer, dealing with situation where network 
> elements do not follow those rules or being malicious, but these are, 
> essentially edge cases.

The edge cases must be covered, though perhaps not protocol violations.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 23 Oct 2018 23:47:18 +0900

Hi,

Although it may be best to be able to decide the response regardless an
INVITE transaction, is this possible?

If a UAS receives an UPDATE while an INVITE transaction was going on,
the UAS has to respond immediately. But if the UAS can not decide SE
until the precondition is met, what should the UAS set for SE?

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Oct 2018 14:51:58 +0000

Hi,

>    until the precondition is met, what should the UAS set for SE?
  
Not sure why preconditions would have any impact, but perhaps we could say that the UAS only inserts Supported/Require:timer, which basically means that it wants the mechanisms but no parameters associated with the mechanisms are negotiated as part of this transaction.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Oct 2018 10:59:19 -0400

> until the precondition is met, what should the UAS set for SE?

That is a tricky case. Like Christer, I wonder if preconditions would 
ever affect this. If they do, perhaps the answer has to be to use a 
separate transaction after the INVITE is complete, to reset the timer to 
be consistent with the preconditions.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Oct 2018 11:11:06 -0400

Hi Paul,

> UPDATE goes to a different proxy than the INVITE?

Having redundant proxies with different proxies processing different
transactions is a good example of what can cause difficulty for
inter-transaction ruls. The other reason for this difficulty is that proxy
will need to update dialog state a lot more often to deal with the special
rules for Update transactions during INVITE. I have addressed this problem
before on the list. The best way to think about this problem is to look at
OpenSIPS/Kamilio configuration and see how easy it is to express proposed
rules using configuration scripts for these proxies.

> This does potentially cause trouble. It is a good place to focus attention.

It actually does not cause trouble unless network elements (UA or proxies)
are doing something random.

> containing an S-E within an INVITE that didn't have an S-E.

This is not necessary.

> have such a simple approach if it can be made to work.

Yes, these messages should apply independently to each request. Only time
responses need to be mentioned are in cases of UAS, when response is being
generated or proxy, when UAS does not support session timer and S-E is
inserted in the response by the proxy.

> What is "this value"? And insert it in what?

Each network element should to know that it needs dialog refreshed at least
every X seconds (can be infinite, if no refresh is needed) but not more
often then Yseconds (can be zero). This element should insert S-E with
value X (if X is not infinite) if S-E is not present in the request. It
should reduce S-E to X if S-E is present in the request and greater then X.
It should insert Min-SE with value Y if Min-SE is not present in the
request and Y is not 0. It should reduce Min-SE to Y if Min-SE is present
in the request and its value is higher then Y.

> dialog? Are there any constraints on when and how it can change?

Yes, this can change but only at the point when there are no transactions
in progress. In practice this change almost never happens except due to
3pcc scenarios when one of the UA end s up being connected to a new element.

> disagreement on what the values are.

This is correct.

> values? What should go in the responses to each?

Responses from UAS should be generated based on the described rules. I did
not cover the refresher role.

> set of values, and then an INVITE response with a different set?

With the rules that I have proposed this will never happen.

> actually enumerate these and verify that whatever we specify works for

I actually did. At some point in the past I wrote a state machine generator
and validated all possible scenarios.

>  Yes, once we update the document we should cover all edge cases and
recovery behavior (send a new UPDATE/INVITE transaction when in doubt).

Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 24 Oct 2018 15:53:20 +0900

Hi,

> Not sure why preconditions would have any impact, but perhaps we could say that the UAS only inserts Supported/Require:timer, which basically means that it wants the mechanisms but no parameters as…

That is exactly what I wanted to suggest.

1. UAS MAY send the response without Session-Expire and Min-SE headers but with Supported: timer.
2. This response means that the UAS supports this mechanism but this transaction is irrelevant to this mechanism.

I think that above rules may resolve the crossing problem.
However, there is a risk of being mistaken for turn-off.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 24 Oct 2018 16:19:06 +0900

Hi,

I do not point out that preconditions affect a session timer.
I point out that the UAS may not be able to make a decision on session timer when receiving an UPDATE within an INVITE transaction,

A precondition is just one example.
#It seems that it was not a very good example.

In actual precondition case, such UPDATE will be sent.
In such a case, what kind of response should the UAS return?
I would like to discuss it.

Regards,
Shinji

On 2018/10/23 23:59, Paul Kyzivat wrote:
> That is a tricky case. Like Christer, I wonder if preconditions would ever affect this. If they do, perhaps the answer has to be to use a separate transaction after the INVITE is complete, to reset the timer to be consistent with the preconditions.
>
>     Thanks,
>     Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Oct 2018 08:38:43 +0000

Hi,

Based on the phone discussion yesterday, the current suggestion is that a UAS must include S-E in the UPDATE response, even if there are preconditions etc ongoing. If the UAS later needs to change the value, it will do so. As people typically seem to be using a S-E value of 1800, there aren't going to be any refreshes sent while the precondition procedures are ongoing, and there will be more than enough time for the UAS to re-negotiate the value later if needed.

While one could argue that it would be nice to be able to send an UPDATE response without S-E etc, it is NOT essential in order to fix the race condition issue, and as discussed in the meeting THAT is what we should put our focus on - or we will never be done.

Any nice-to-haves can be documented in the GitHub, and we may look at them in the future.

Regards,

Christer

On 24/10/2018, 10.19, "OKUMURA Shinji" <[email-masked]> wrote:

    Hi,

    
    
    Regards,
    Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 25 Oct 2018 18:50:44 +0900

Hi Roman,

> negotiation always ends up with the same result.

This might be an edge case.

Assume that the acceptable refresh-interval for both UAs is between 1800 and 3600.
And for the sake of simplicity, here is no proxy.

Within an initial INVITE transaction, both UAs send an UPDATE at the same time.

UA-A sends UPDATE with S-E:2000 and Min-SE:1800.
UA-B sends UPDATE with S-E:1800 and Min-SE:1800.

and,

UA-B sends response for UPDATE with S-E:2000.
UA-A sends response for UPDATE with S-E:1800.

These results are different.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Oct 2018 12:12:02 -0400

Shinji,

I am not sure I quite understand your example.

If acceptable refresh-interval for both UAs is between 1800 and 3600, both
should send UPDATE with Min-SE: 1800 and S-E: 3600. UA should not just set
S-E to a random value in their acceptable range. It should be set to the
max.

Second, if both UA send UPDATE, this should be treated as collision and
UPDATE should fail with 491 (Request Pending).

Regards,
_____________
Roman Shpount

On Thu, Oct 25, 2018 at 5:50 AM OKUMURA Shinji <[email-masked]>
wrote:

> refresh,
> desired
> Min-SE
> element,

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 26 Oct 2018 10:55:41 +0900

Hi,

<1st>
There is no rule for UAs to set the maximum value.
UAs may set any value within the acceptable range.

<2nd>
If either UPDATE has SDP in this case there is no rule that makes the UA to send a 491 response.
And even if both values are equal, should it be treated as collision?

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 26 Oct 2018 13:41:36 +0900

(It is correct as follows)

If either UPDATE has "no" SDP in this case, there is no rule that makes the UA to send a 491 response.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Oct 2018 07:22:34 -0400

Shinji,

1. The rules I was proposing was to set S-E to max and Min-SE to minimum
range values for all entities, including UA. Since currently those rules do
not exist, and your sequence is legal. But, like a lot of random sequences
with current specification it produces random results. We need additional
constraints to avoid ambiguous situations.

2. You are correct. I thought that collision rules apply to all Update
messages, but it does only apply to Update messages with SDP. It needs to
be analyzed further, but I think glare rule should apply to Update or it
would make it impossible to change any session timer parameters
non-ambiguously.

Regards,
_____________
Roman Shpount

---

From: [email-masked]
Date: Fri, 26 Oct 2018 14:36:01 +0200

Hi
But it will sent an 491 since there are open transactions on both sides.

I have seen this race condition within our network many times. But not within the initiation state but within the refresh state. Even if there is no SDP within the UPDATE.

The same apply for this case. Which I assume is very rare. I have never seen such case.

Best Regards

Roland

---

From: [email-masked]
Date: Fri, 26 Oct 2018 14:43:19 +0200

Hi Roman,
Regarding 2.

Yes we need to identify such race conditions.

There will be a further more if B2BUA will come into the game. I have pointed out such race condition earlier.

I would propose, if possible, to have such implementation guideline to avoid such race conditions. Or we can agree on some procedures to avoid this.

But this will not help with running systems.

Best Regards

Roland

Am 26.10.2018 13:22 schrieb Roman Shpount <[email-masked]>:

Shinji,

1. The rules I was proposing was to set S-E to max and Min-SE to minimum range values for all entities, including UA. Since currently those rules do not exist, and your sequence is legal. But, like a lot of random sequences with current specification it produces random results. We need additional constraints to avoid ambiguous situations.

2. You are correct. I thought that collision rules apply to all Update messages, but it does only apply to Update messages with SDP. It needs to be analyzed further, but I think glare rule should apply to Update or it would make it impossible to change any session timer parameters non-ambiguously.

Regards,

_____________
Roman Shpount

On Fri, Oct 26, 2018 at 12:41 AM OKUMURA Shinji <[email-masked]> wrote:

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 26 Oct 2018 23:52:30 +0900

Hi,

UAS behavior is not random. Generally UAs do not care about the maximum 
value. They care only about the minimum value. Therefore UAS just copies 
S-E value in the response from the request.
In addition, it is not certain that an UA will attach a S-E header.

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 27 Oct 2018 00:44:50 +0900

Hi Roland,

Since negotiating for a session-timer is pointless within early dialog, 
it is unreasonable that the UPDATE for a different purpose is rejected.

So my suggestion is that UA responds the UPDATE by 200 OK, and ignores 
S-E header.
Of course UA may reject it for other reason.

Regards,
Shinji

On 2018/10/26 21:36, [email-masked] wrote:
> I have seen this race condition within our network many times. But not within
> the initiation state but within the refresh state. Even if there is no SDP
> within the UPDATE.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Oct 2018 21:59:27 -0400

Shinji,

UAC behavior is random, since if the maximum allowed refresh interval is  3600,
both UA should put S-E with value 3600 when sending the UPDATE request.
Both should respond with 3600 since it is within their acceptable limits.
Why UAC need to refresh every 3600 seconds but sends an UPDATE with S-E set
to 2000 or 1800 makes no sense.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 26 Oct 2018 22:02:14 -0400

Shinji,

No, it is not pointless to negotiate S-E within early dialog. Ignoring S-E
header in UPDATE is not possible since proxy will not be able to reliably
determine that this is an UPDATE within early dialog, which will result in
different state for proxy and UA.

Regards,
_____________
Roman Shpount

On Fri, Oct 26, 2018 at 11:44 AM OKUMURA Shinji <[email-masked]>
wrote:

> > The same apply for this case. Which I assume is very rare. I have never
> seen
> > such case.
> > Best Regards
> > Roland
>
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 27 Oct 2018 15:24:24 +0900

Hi,

This is a matter of an implementation and configuration of UA.
If I implement UA, the required settings are the minimum and initial 
values for SE. The initial value is used for the SE of the UPDATE/INVITE 
request, but it does not mean the maximum value.
If I must say, the maximum value is infinite.

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Sat, 27 Oct 2018 02:59:43 -0400

Shinji,

This still makes no sense to me. If UA does not need session timer (maximum
allowed request is infinite), it should not insert S-E. If UA, for some
reason need to do periodic session requests, it should add S-E with the
maximum desired interval. Inserting random values for no reason is exactly
what we are trying to fix with the new specification

Regards,
_____________
Roman Shpount

---

From: OKUMURA Shinji <[email-masked]>
Date: Sun, 28 Oct 2018 00:35:16 +0900

Hi,

Regardless of a session-timer, UPDATE potentially has problem with 
transaction order.
UA-B can not recognize that a glare situation is occurring in the 
following two sequences.
And only UA-A can recognize that there is a possibility that the glare 
situation may have occurred.

    A                        B    A                        B
    |                        |    |                        |
    |init-INVITE             |    |init-INVITE             |
    |=======================>|    |=======================>|
    |UPDATE                  |    |UPDATE                  |
    |----------------------->|    |---------\              |
    |                 200-UPD|    |          \      200-INV|
    |               /--------|    |<=======================|
    |              /  200-INV|    |            \           |
    |<=======================|    |             \--------->|
    |            /           |    |                 200-UPD|
    |<----------/            |    |<-----------------------|

Is your pointing related to this problem?

The solution to this problem is so difficult.
In order to avoid this problem I also wanted to define an UPDATE not 
related to session-timer.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Oct 2018 21:06:57 -0400

On 10/26/18 7:22 AM, Roman Shpount wrote:

> messages, but it does only apply to Update messages with SDP. It needs 
> to be analyzed further, but I think glare rule should apply to Update or 
> it would make it impossible to change any session timer parameters 
> non-ambiguously.

The glare rules currently don't apply in these cases. I think it would 
be overreaching and cause trouble to call for glare to be reported in 
all cases of crossing UPDATE. If necessary, perhaps we could call for 
glare to be used in the presence of S-E in either of the crossing 
UPDATEs, either in all cases, or in the cases where the S-E values don't 
match.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 29 Oct 2018 19:03:50 +0900

Hi,

If UAS does not need session timer, what do you think it should set in S-E header of the response?

Regards,
Shinji

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Oct 2018 15:33:42 -0400

> If UAS does not need session timer, what do you think it should set in S-E
In the response UAS, should include S-E value from the request if it is
present and higher then minimum refresh time for UAS.

Regards,
_____________
Roman Shpount