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

[Jonathan Rosenberg <[e-mail]>]

John Hearty wrote:
> 
> >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.

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. 

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

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:   [phone]                       Rm. 4C-526
EMAIL: [e-mail]
URL: http://www.cs.columbia.edu/~jdrosen