11 Jul
2007
11 Jul
'07
6:02 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
11 Jul
11 Jul
6:12 p.m.
New subject: [Serusers] sl module functions in failure route
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
6:16 p.m.
New subject: [Serusers] sl module functions in failure route
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(a)iptel.org> wrote:
At 16:34 11/07/2007, JF wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
6:57 p.m.
New subject: [Serusers] sl module functions in failure route
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(a)iptel.org> wrote:
At 16:34 11/07/2007, JF wrote:
--
Jiri Kuthan http://iptel.org/~jiri/ 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/ 
7:17 p.m.
New subject: [Serusers] sl module functions in failure route
Jiri Kuthan wrote:
At 20:12 11/07/2007, JF wrote:
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
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.
7:48 p.m.
New subject: [Serusers] sl module functions in failure route
At 21:17 11/07/2007, Martin Hoffmann wrote:
Jiri Kuthan wrote:
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.
At 20:12 11/07/2007, JF wrote:
Wait. Does t_reply() skip branch picking? 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. 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
6215
days inactive
6215
days old
5 comments
4 participants
participants (4)
-
JF -
Jiri Kuthan -
Martin Hoffmann -
SIP