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

[John Hearty <[e-mail]>]

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