Juha Heinanen wrote:
> If I recall correctly, theis problem was debated several times ago. It is
> more a logical issues than a bug and was labeled as "delayed CANCEL" - as
> the trace shows, it is about a transaction with a non-responsive branch,
> transaction wthat gets completed. After that a reply from the
> non-responsive branch arrives. The questions is what should you do?? If the
> transaction is still in memory, you can generate a delayed
> CANCEL.....otherwise the reply will not match any transaction and it will
> be stateless fwd....Any thoughts???
yes, if transaction state still exists, it makes sense to generate a
delayed cancel.
but if transaction does not exist anymore, i don't think it makes sense
by a atateful proxy to statelessly forward any replies. in other
worlds, if in my proxy i always t_relay requests, i would like to be
able to tell the proxy not to never statelessly forward any replies.
Me too. That's why I asked to check for transactions in reply route and
drop final responses too:
http://openser.org/pipermail/devel/2006-December/005001.html
regards
klaus
--
Klaus Darilion
nic.at
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
