Re: [sipcore] 4028bis: memory refresh - proxy assumptions

[Christer Holmberg <[e-mail]>]

Hi,

>>>1. Defining proxy behavior based on having a transaction in progress: This is hard to implement in practice since initial INVITE and UPDATE
>>>might not even go over the same path and the same proxies.
>> 
>> Section 8 of RFC 4028 says:
>> 
>>   “Proxies that ask for session timers SHOULD record-route, as they
>>   won't receive refreshes if they don't.”
>> 
>> In my opinion it should be possible to mandate that a proxy that asks for session timers, or modifies a session timer value (S-E or Min-SE), also record-route.
>>
> I have mentioned before that even requiring record-route would be insufficient. First of all, having a transaction in progress for a proxy is something
> that can be ambiguous due to network delays or message re-ordering even if it is always on the dialog path. Second, the amount of state maintained
> by proxy, if it needs to track transactions vs dialogs increases significantly. Third, even if the proxy can be the same "logical proxy", it can actually be
> multiple physical servers sharing an address behind a load balancer, so UPDATE and INVITE transactions can end up on the different servers.

You could still configure those proxies to behave in the same way (insert/modify the S-E and Min-SE header field values in the same way) when it comes to the session-timer. 

Regards,

Christer