[Serusers] [Serdev] loose_route behaviour, detecting single Route with myself
hn at nvnc.de
Tue Jul 17 20:27:13 CEST 2007
Jiri Kuthan wrote:
> At 11:52 17/07/2007, Martin Hoffmann wrote:
> >> >> |
> >> >> | 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.
> >> >
> > This bullet effectively limits stateless proxies to
> >load balancers and other rather static cases.
> Yes. (Or if you read it rigirously, it limites the use case to load-balancers
> that never change the list of load-balanced servers :-)))
Indeed. Although forevers are tricky beasts in the best of cases. But
even if you stick to the rest of it, the use is still limited to rather
simple proxies. Using lookup() in a stateless manner will not guarantee
that the retransmit ends up somewhere else or even gets 404ed. And that
part of the rule (don't you dare forking requests on a stateless proxy)
does make sense. I think Postel's Law is lurking in there somewhere.
> >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.
> I agree authors said that, but I'm not sure they realized completely what
> they have said and I think they went too far with it. Despite all possible
> corner-cases, stateless-forwarding has been deployed and worked, paritcularly
> for sake of load-balancing. I'm personally opposed against generally banning
> stateless forwarding (even though it is not the mainstream case).
Well, they didn't do that. But they very effectively limited it. On a
side note (as in SCNR): You can do load balancing without actually
having a proxy.
> >> (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.
> My point is it actually is, because it effectively mandates state usage, wherease
> there are valid scenarios which rely on the stateless mode. (not sure actually
> what is the sense of defining and banning a stateless proxy in the same document :-))
Again, they didn't actually bann anything. It's more that statefull
proxies a SHOULD. If you know what you are doing, you may violate it.
> >> 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".
> Exactly my point -- overstandardized.
Er, that was a question. But even so, I wouldn't call SIP
overstandardized considering the number of interoperability problems.
Maybe overengineered here and there. And in the case of INVITE
More information about the Serusers