[Users] Request for discussion: t_relay() internal error processing

Hi all, there are some topics largely discussed lately on the mailing list; in order to fix them problems first we need to find a solution for logical point of view - and here I think that several opinions are better than one :) In order to have failover based on serial forking, it is mandatory to be able to detect from script if the initial t_relay() fails. The problem is that now t_relay() masks any error by internally generating an error SIP reply. Of course, it can be internal errors (like lack of memory), msg errors (parse errors) or transport errors (DNS failed, send/connect failed, etc). Now, disabling the auto replying in case of error is not a problem. The problem is how to handle the errors from the script; two make distinction between the error classes a listed above will not be the purpose of this email ( I will open another one for this ;) ). What is important here is to be able to properly resume from the point were the error popped up. What I mean is: the t_relay() function builds the transaction and sends the requests. If the error occurred during transaction creation, from script, you will had to use only stateless functions to send err. replies. If the transaction was already created and the error popped up during relaying stage, you will need from the script to take care of the transaction and either destroy it, either reply it. Based on this, here is what I suggest: 1) have a new param for disabling the auto reply in t_relay() 2) t_relay will return several error codes: -1 = no transaction created -> need to use sl_* functions -2 = transaction created, relay failed -> may destroy transaction, reply via TM with error, trigger failover. any comments on this ? regards, bogdan