I'd probably vote for (ii) for a couple of basic reasons (not really related to what is happening...) a) too much information is almost never a bad thing b) it pretty much subsumes (i), i.e., given the info you extract from this, you can essentially replicate (i) cheers ----- Original Message ----- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: devel <devel(a)openser.org>rg>, users openser.org <users(a)openser.org> Sent: Monday, September 4, 2006 9:26:11 AM GMT-0600 Subject: [Devel] 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 _______________________________________________ Devel mailing list Devel(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/devel -- ******************************************* Mahesh Paolini-Subramanya (703) 386-1500 x9100 CTO mahesh(a)aptela.com Aptela, Inc. http://www.aptela.com "Aptela: How Business Answers The Call" *******************************************

On Monday 04 September 2006 10:26, Bogdan-Andrei Iancu wrote: This all sounds good for the following reasons: 1) - The new parameter covers the backward compatibility case where the script wants the old way of doing things. 2) - I assume there will be new script calls to deal with deleting the failed transaction, and the transaction could be freed once the script exits to avoid memory leaks. If not freed by the script call. My only concern is, do you think the two result/error codes are sufficient to cover all of the cases? The idea of "may destroy" leaves me with an uneasy feeling. ronw -- Ron Winacott - SOMA Networks, Inc.