Nils Ohlmeier wrote:
On Friday 13 July 2007 11:16:24 Klaus Darilion wrote:
Nils Ohlmeier wrote:
On Thursday 12 July 2007 15:24:59 Klaus Darilion wrote:
Is it really necessary to differ this cases in ser.cfg? I usually just t_relay() the ACKs as tm module should know if this is a 2xx ACK or a non-2xx ACK.
If you need this information in ser.cfg, then having a function t_is_ack_local() would be useful.
I did not claimed that I want this information to be available in the config. You suggested to export it via the return code.
But as I pointed out to Martin in the other mail, the point is that non-2xx and 2xx ACKs should also be routed correctly in case of stateless forwarding. So telling everybody just call t_relay() for all ACKs, it will take care of it, is IMHO no acceptable option.
Is telling "If you do statefull forwarding just t_relay() the ACKs - both, in loose_route block and after loose_route block" an acceptable option?
Sure, for transaction statefull relaying there is no problem with this. The problem is, that I'm also looking for a solution which works stateless (if you run a SER without tm - e.g. a stateless load balancer).
I think now I also realized the problem that you describe. In stateless mode the dispatcher can't distinguish between in-dialog ACK (which is just forwarded after loose_route) and out-of-dialog+preloadedroute (which requires dispatcher activity before forward).
What about adding a cookie to RR header to distinguish between pre-loaded routes and learned routes?
regards klaus