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

[Bogdan-Andrei Iancu]

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