Subject: Re: draft-ietf-mmusic-sip-session-timer-00.txt

From: John Hearty <[email-masked]>
Date: Wed, 17 Feb 1999 11:27 -0600 (CST)

>Patrice Calhoun wrote:
>> 
>> >Thats pretty much whats specified in the Donovan draft. THe difference
>> >is that the timeout doesn't get reflected in the ACK. THis is not
>> >needed, though. The timeout should be echoed in the response, which will
>> >be seen by both servers. I think this works just fine. The only issue
>> >has to do with backwards compatibility - knowing that SC1 will
>> >understand the timer in the response.
>> 
>> ok, but what is a client sends a timeout of infinity, and the server's policy
>> does not allow it to maintain soft state that long for a single session?
>
>I'm not sure what it says in the draft; in a prior email I suggested
>that each proxy along the chain can decrease (but not increase) the
>value of the timer. The result is that the timer in the response
>represents the minimal refresh interval needed by all servers. By
>definition, this means that every server will receive a refresh in time
>(not true if servers are allowed to increase the interval).
>

 We need to be careful about minimums too.  One proxy in a network
could change the value to 1 second for all it's calls and greatly increase
the workload of many other proxys.  For this reason I feel the draft
should indicate some reasonable minimum, maybey 6 seconds, a common
billing increment in the telephony world, or maybey 1 minute to reduce
potential load on proxies.

 This idea of potentially decreasing the timer along the way and echoing
the final (smallest) value back to the originating client might be
a good idea, as it can eliminate the need for rejected invites and
negotiating acceptable values between clients and proxies.  Will we
run into problems with multicasted calls and/or forking proxies if
this is done?  Or just have the originating client use the smallest
value from all the responses?

John H.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Feb 1999 16:30:10 -0500

> potential load on proxies.

A good idea. A reasonable minimum depends on the planned usage, I'm
afraid. If you are trying to bill for a SIP phone call, a few seconds is
probably needed. If the point is just to clean away old state, something
even larger than a minute is OK. 

> value from all the responses?

It cannot use the smallest value across all responses.

There are two cases with forking proxy. In case 1, a single user is
contacted, but through different paths. In this case, the caller will
get multiple 200's, each from the same user, but with different paths.
This raises an interesting issue. Lets say every server put itself in
the Record Route header. Now, when the caller goes to send a BYE, it
will do so using only one of the paths it learned from one of the 200
responses (call this the main branch). Thus, servers on another path
won't ever see the BYE. The keepalives get sent only along one path,
using the keepalive from the 200 response on that path, and the other
paths (and their keepalive intervals) are ignored. This would allow
those non-main branch servers to time out the session state, a neccesary
thing here.

In case 2, multiple users are contacted, so multiple 200 responses come
back (each with a different tag). In this case, if the client sends an
ACK to all of them, it will need to refresh each independently, using
the interval for that particular branch, read from the response on that
path.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen