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
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@voice-system.ro To: devel devel@openser.org, users openser.org users@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
On Tuesday 05 September 2006 14:47, Mahesh Paolini-Subramanya wrote:
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)
If I understood this right, both would be present at the same time: if not disabled, it will send autoreplies and return no error codes (i.e. behave like now), but if disabled, it will return the error codes specified at point 2 and send no autoreplies.
So I think there is nothing to vote about.
On Monday 04 September 2006 10:26, Bogdan-Andrei Iancu wrote:
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 ?
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 wrote:
On Monday 04 September 2006 10:26, Bogdan-Andrei Iancu wrote:
Based on this, here is what I suggest:
- have a new param for disabling the auto reply in t_relay()
- 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 ?
This all sounds good for the following reasons:
- 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.
actually the "may" was for the script writer - he can explicitly destroy the transaction via t_release() or indirectly via t_reply() / t_relay().
If he does not handle properly the transaction in the script, the TM module will take care of it and destroy the transaction but it will generate some logs about it... You can test this by doing only a "t_newtran()" for a request without forwarding or replying it....:)
regards, bogdan
-
Bogdan-Andrei Iancu -
Dan Pascu -
Mahesh Paolini-Subramanya -
Ron Winacott