17 Jul
2007
17 Jul
'07
5:52 a.m.
Jiri Kuthan wrote:
At 16:18 16/07/2007, Klaus Darilion wrote:
That's indeed what Martin suggested. The spec is vague in this, the idea in it
is that retransmissions don't get 'forked' if usrloc entry changes. That
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me.
I tend to disagree. This bullet effectively limits stateless proxies to
load balancers and other rather static cases. IMHO it's the authors' way
of saying "Don't do stateless proxying." Many have tryied nonetheless
and, oh wonder, many have failed. Statless proxying is broken. There is
too many tripfalls.
|
| o A stateless proxy MUST choose one and only one target from the
| target set. This choice MUST only rely on fields in the
| message and time-invariant properties of the server. In
| particular, a retransmitted request MUST be forwarded to the
| same destination each time it is processed. Furthermore,
| CANCEL and non-Routed ACK requests MUST generate the same
| choice as their associated INVITE.
That would mean that doing lookup() in a stateless proxy is practically
not allowed. (I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)
Well, it is not obviously broken at this point, so it shall be followed.
If one had a well articulated case for stateless proxy
with userloc (does anyone
have such?), I would not hesitate to do it. We have done such things in the
past, note for example that in default configuration SER's registrat is
stateless. This is tremendously important because of performance implications.
Nevertheless, if you look at the RFC3261, it actually says that the UAS
should be stateful in such case.
Haven't searched too thoroughly, but does it actually say somewhere
"registrar MUST be statefull".
Here we traded a minor consistency issue
against a significant performance gain.
Did you now? We've been through this, but the statelessness actually
killed my registrars quite regularly when coming under heavy load. That
got fixed (for a while, anyways) by making the registrar stateful.
The heavy part of processing a REGISTER is _not_ the transaction
handling.
Regards,
Martin