At 16:34 11/07/2007, JF wrote:
Hi all,
Is there any particular reason why sl module functions cannot be used in failure routes?
Yes. Failure_route is only invoked from within stateful processing. If a request was processed statelessly, SER does not really know if it failed.
-jiri
I want to send a stateless reply in failure route.
JF _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
So, the following snippet doesn't make sense in a failure route? I may try to call t_relay inside a failure route, and, if it fails, send a stateless reply back...
if (!t_relay()) { sl_send_reply("500","Error relaying"); exit; };
JF
On 7/11/07, Jiri Kuthan jiri@iptel.org wrote:
At 16:34 11/07/2007, JF wrote:
Hi all,
Is there any particular reason why sl module functions cannot be used in failure routes?
Yes. Failure_route is only invoked from within stateful processing. If a request was processed statelessly, SER does not really know if it failed.
-jiri
I want to send a stateless reply in failure route.
JF _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
You CAN call a non-failure route from within a failure route if you want to do some tricks.
But why call t_relay directly from a failure route? Wouldn't the fact that it's in a failure route imply that t_relay failed to complete?
N.
JF wrote:
So, the following snippet doesn't make sense in a failure route? I may try to call t_relay inside a failure route, and, if it fails, send a stateless reply back...
if (!t_relay()) { sl_send_reply("500","Error relaying"); exit; };
JF
On 7/11/07, Jiri Kuthan jiri@iptel.org wrote:
At 16:34 11/07/2007, JF wrote:
Hi all,
Is there any particular reason why sl module functions cannot be used in failure routes?
Yes. Failure_route is only invoked from within stateful processing. If a request was processed statelessly, SER does not really know if it failed.
-jiri
I want to send a stateless reply in failure route.
JF _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
This piece of config makes sense, but it does not include failure_route as you had asked before. From within failure_route, call t_reply to complete transactino processing, don't call sl_send_reply.
-jiri
At 20:12 11/07/2007, JF wrote:
So, the following snippet doesn't make sense in a failure route? I may try to call t_relay inside a failure route, and, if it fails, send a stateless reply back...
if (!t_relay()) { sl_send_reply("500","Error relaying"); exit; };
JF
On 7/11/07, Jiri Kuthan jiri@iptel.org wrote:
At 16:34 11/07/2007, JF wrote:
Hi all,
Is there any particular reason why sl module functions cannot be used in failure routes?
Yes. Failure_route is only invoked from within stateful processing. If a request was processed statelessly, SER does not really know if it failed.
-jiri
I want to send a stateless reply in failure route.
JF _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
At 20:12 11/07/2007, JF wrote:
So, the following snippet doesn't make sense in a failure route? I may try to call t_relay inside a failure route, and, if it fails, send a stateless reply back...
if (!t_relay()) { sl_send_reply("500","Error relaying"); exit; };
This piece of config makes sense, but it does not include failure_route as you had asked before. From within failure_route, call t_reply to complete transactino processing, don't call sl_send_reply.
Wait. Does t_reply() skip branch picking? If not, your t_reply("500", "Whatever") will most likely not get picked.
What you need to remember in a failure route is that you already have a reply from older branches. If nothing came from downstream, SER fakes a 408. This means that you actually don't need to do the sl_send_reply() anyways. Just break out of the failure route and whatever reply lead to the call of the failure route will be send back upstream just fine. Which most likely is what you want anyways, if you think about it.
Regards, Martin
At 21:17 11/07/2007, Martin Hoffmann wrote:
Jiri Kuthan wrote:
At 20:12 11/07/2007, JF wrote:
So, the following snippet doesn't make sense in a failure route? I may try to call t_relay inside a failure route, and, if it fails, send a stateless reply back...
if (!t_relay()) { sl_send_reply("500","Error relaying"); exit; };
This piece of config makes sense, but it does not include failure_route as you had asked before. From within failure_route, call t_reply to complete transactino processing, don't call sl_send_reply.
Wait. Does t_reply() skip branch picking?
frankly, I'm not sure without looking in today's code. Anyway, it is the safe way to generate a reply, otherwise transaction module will send what it considers a good choice, which may be different from the code generated by sl_send_reply, resulting on client confusion.
If not, your t_reply("500", "Whatever") will most likely not get picked.
What you need to remember in a failure route is that you already have a reply from older branches. If nothing came from downstream, SER fakes a 408. This means that you actually don't need to do the sl_send_reply() anyways.
It is not that you don't need to, it is that you must not. Otherwise there can be two replies, the SL-one and another one produced by TM unaware of what SL has done.
Just break out of the failure route and whatever reply lead to the call of the failure route will be send back upstream just fine. Which most likely is what you want anyways, if you think about it.
yes.
-jiri