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

Mahesh Paolini-Subramanya mahesh at corp.aptela.com
Tue Sep 5 13:47:10 CEST 2006


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 at voice-system.ro>
To: devel <devel at openser.org>, users openser.org <users at 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 at openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel



-- 
*******************************************
Mahesh Paolini-Subramanya      (703) 386-1500 x9100
CTO                                         mahesh at aptela.com
Aptela, Inc.                               http://www.aptela.com
"Aptela: How Business Answers The Call"
*******************************************





More information about the Users mailing list