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. 
>
> Absolutely correct. Having proxies use the same consistent rules should be sufficient.
>
> My point is that we cannot define proxy behavior based on having a transaction in progress. This is only non-ambiguous and implementable for a UA.

If the proxy is not aware of transactions, it could always behave in the same way, i.e., always insert/modify the same S-E and Min-SE header field values in INVITEs and UPDATEs.

I really see no reason why a proxy should suddenly change session timer behavior - especially a proxy that is not session aware, or aware of other ongoing transactions.

Regards,

Christer