Subject: RE: [Sip] Session Timer - Terminology is no clear

From: "Sarit Galanos" <[email-masked]>
Date: Tue, 11 May 2004 09:45:18 +0300

Hi Paul,
Thanks for you answer.
>From your answer I understand that 7.1 talks about the first time the UAC tries to set a session timer 
(in an initial dialog or an established dialog), and 7.4 defines the behavior of the UAC incase the request 
was rejected with 422.
Further refreshes are identical to the initial refresh.

I'm still not clear about the relationship between the Session Expires and the Min SE.
Lets say a UAC wants to set them both. According to 7.1:
  "If a Min-SE header is included
   in the initial session refresh request, the value of the
   Session-Expires MUST be equal to the value in Min-SE."

Proxies on the way must follow the following rule regarding the Session Expires:

    "Any proxy servicing this request can lower this
     value, but is not allowed to decrease it below the value specified in
     the Min-SE header field."

But then how can a proxy lower the Min-SE if it is always equal to the Session Expires?
And when both Session Expires and Min-SE will be present but will include different values?

Thanks for you help,
Sarit.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Wednesday, May 05, 2004 5:57 PM
To: Sarit Galanos
Cc: [email-masked]; Jonathan Rosenberg
Subject: Re: [Sip] Session Timer - Terminology is no clear

Sarit,

I just went back and reread the text. I agree it is confusing.

Stepping back a moment, lets look at what kind of session refresh 
requests can be either INVITE or UPDATE. INVITE could also be 
establishing a dialog, or it could be within an existing dialog. UPDATE 
can only be within an existing dialog.

(I note that this draft is now behind the times in that it doesn't 
address other dialog establishing requests. It would make perfect sense 
to want to use session timer within a dialog established with a 
SUBSCRIBE. But that is a subject for another time.)

Session timers intimately connected to dialogs. But some of the action 
may happen before a dialog is established. The behavior before and after 
a dialog is established is intertwined in the text. It is probably worth 
looking at separately:

Suppose the UAC is sending a new INVITE that will hopefully establish a 
dialog. And the UAC wants to use session timer, so it inserts a 
Supported: timer. It may also insert Session-Expires and/or Min-SE.

This could fail with a 422, indicating that the Session-Expires inserted 
by the UAC or some proxy on the path was too small for the UAS or some 
proxy on the path.

This clearly doesn't affect dialog state, because there isn't any dialog 
yet. So it can only affect pending call state in the UAC - altering how 
further attempts to establish the call are done.

The invite could have forked, and some other fork could have succeeded. 
In that case this is moot. But if all the forks fail, then the UAC may 
attempt to recover, retrying the invite. To have this try come out 
differently, it follows 7.4 and inserts a Min-SE that is the max of all 
those it received in 422 responses. The UAC may also include a 
Session-Expires in the retry, constrained by the Min-SE value. 
Presumably it would do this iff it had included one in the initial request.

Doing that ensures that proxies along all fork paths will use 
Session-Expires values large enough to be acceptable to all candidate 
forked UASs, so that there should be no 422 responses on the 2nd try. Of 
course there may be other problems, but eventually this will hopefully 
result in one or more responses that establish dialogs. And each dialog 
then may or may not have a session timer in operation according to the 
response. Each dialog is then an independent entity for purposes of 
session timer.

It is possible that a dialog would be established without a session 
timer, and then later, an initial session refresh could be sent within 
the dialog. That isn't a very interesting case, so I will ignore it for now.

Once in a dialog with a session timer, one of the participants might 
send an INVITE or UPDATE. This could be because the time to refresh the 
session timer has come, or it could be for some entirely unrelated 
reason. It doesn't matter, because the rules must be followed if the 
message is sent, regardless of reason.

Parts of 7.4 apply to this case. The key requirement here has to do with 
Min-SE:

    The value of the Min-SE header field present in a session refresh
    request MUST be the largest value amongst all Min-SE header field
    values ... received in session refresh
    requests, on the same dialog, if a dialog has been established.
    ...
    A result of this rule is that the maximum value of the Min-SE is
    effectively 'cleared' once the dialog is established, and from that
    point on, only the values from proxies known to be on the proxy path
    will end up being used.

The point here is that the Min-SE in the initial request might have been 
larger than necessary due to the needs of servers on forks not taken. 
Now that a dialog has been established, the goal is to constrain the 
session-expires value only by the needs of the currently involved parties.

In the simple case where there was no forking, and the initial request 
succeeded in establishing a dialog, the Min-SE value used in the 
"subsequent session refresh request" would normally be the same value 
received in the response to the initial session refresh request.

The rules about the relationship of the Session-Expires to the Min-SE 
are a separate story. The UAC is never required to insert a 
Session-Expires at all. The session timer mechanism is really for the 
benefit of the proxies along the path rather than the UAC and UAS. (The 
UAC and UAS are free to send INVITE or UPDATE any time they want to test 
the liveness of the other end. They don't need session timer for this.) 
So there is no particular benefit in the UAC providing a value other 
than to express a preference as the refresher or not. So in general it 
would be silly for a UAC to insert a Session-Expires into an initial 
session refresh request.

Once a session timer has been established, it will presumably be a 
normal case to want to preserve it for the life of the dialog, even as 
other things change in the dialog.

I really don't know why 7.4 says the UAC SHOULD include Session-Expires. 
If it just included Min-SE the right thing would happen, and other 
options would be preserved for the other participants in the dialog. One 
reason to include it is to specify the uac/uas parameter, but the UAS 
for the request could handle that. If the Session-Expires header is 
included, its syntax requires that delta-time be provided. The 
requirement that this equal Min-SE guarantees that the value can't be 
altered anywhere in the path. This means that once a time value has been 
established it won't ever change.

Possibly the recommentation to include Session-Expires in this case was 
motivated by a desire for the session timer not to be accidentally lost 
from the call. But I think a rule on the UAS is sufficient for that. So 
I think I would be inclined to violate the SHOULD, and omit the 
Session-Expires in this case.

I may have forgotten something about the rationale here. Maybe Jonathan 
will comment on this.

	Paul

Sarit Galanos wrote:
> Hi Paul,
> Thanks for you answer.
> I'm still not clear about the following:
> The draft includes two different sections:
> 7.1  Generating an Initial Session Refresh Request
> 7.4  Generating Subsequent Session Refresh Requests
> Each section includes different rules regarding the session timer.
> When should I apply the behavior of 7.1 and when should I use 7.4?
> 
> Thanks,
> Sarit.
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, May 03, 2004 5:06 PM
> To: Sarit Galanos
> Cc: [email-masked]
> Subject: Re: [Sip] Session Timer - Terminology is no clear
> 
> 
> The language in this is at times obscure. I think in part this results 
> from the age of the document. (It has been in progress for years, I 
> think since before 2543bis. So terminology has changed around it.)
> 
> Part of the problem is that it is written as if a reINVITE or UPDATE is 
> done solely for the purpose of session timer refresh. But in reality 
> things are not that simple.
> 
> A reINVITE or an UPDATE does a bunch of stuff. If session-timer is 
> supported then refreshing, or cancelling, a session timer is one of the 
> things it does. Any time a reINVITE or UPDATE is sent, it will affect 
> the session timer one way or another, whether that was the primary 
> intent in sending the message, or not.
> 
> There also isn't anything special about the "first" refresh. The request 
> that first establishes a dialog also establishes some kind of session 
> timer state - either leaving it disabled, or running. Every subsequent 
> reINVITE, UPDATE (and reSUBSCRIBE too) does the same thing - 
> restablishes a new session timer or else leaves the dialog with none. 
> There is no need to consider what the previous state was - the new state 
> is not affected by that.
> 
> All that the session timer mechanism does is force a reINVITE or UPDATE 
> to happen by a particular time if one hasn't happened for any other reason.
> 
> 	Paul
> 
> Sarit Galanos wrote:
> 
>>Hi,
>>The session timer draft uses the term "Initial Session Refresh Request".
>>
>>The draft defines that 
>>              "Session Refresh Request: An INVITE or UPDATE request within a dialog."
>>
>>>From that I understand that "Initial Session Refresh Request" is the first re-Invite or Update inside that dialog.
>>
>>But, If the dialog was established with session timer parameters and after the first INVITE-200-ACK session time is already active,
>>why is there a difference between the initial refresh and further refreshes.
>>Or is that the  "Initial Session Refresh Request" is the first request that has session timer parameters
>>and it can also be the initial INVITE?
>>
>>Thanks,
>>Sarit
>>
>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments on the application of sip
>>
> 
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2004 12:25:32 -0400

> I'm still not clear about the relationship between the Session Expires and the Min SE.

Is it clear that the point of having both is to support negotiation of 
both an upper bound and a lower bound on the refresh interval?

The upper bound is needed for the session timer to be useful. (An 
infinite bound is like no session timer.) Different servers along the 
path may vary in their needs.

The lower bound is there to bound the load placed on all the nodes 
involved, in generating/processing all the messaging generated.

> Lets say a UAC wants to set them both.

Why would the UAC want to set the Session-Expires value? There is no 
real reason why it should. The value is for the benefit of proxies along 
the path, not the UAC.

But while there is no good reason for the UAC to set it, there is no 
good reason to forbid it either.

 > According to 7.1:

I don't really understand why this restriction is here.

> But then how can a proxy lower the Min-SE if it is always equal to the Session Expires?

Well, obviously if the UAC set the value according to the above rule, 
then there is no negotiation. The value is fully determined by the UAC 
and nobody else along the path has any say in it, other than to refuse 
the request.

> And when both Session Expires and Min-SE will be present but will include different values?

The most reasonable use case is for the UAC to include Supported:timer, 
and optionally (if it wants to avoid being overloaded) a Min-SE value. 
But *don't* include a Session-Expires header. Then, *if* at least one 
proxy along the path needs a session timer, the first one will insert 
the Session-Expires header, and others that care can adjust it (down).

Done this way, the values are negotiated among those who care, and no 
timer is established if nobody needs one.

	Paul