1 Jul
2009
1 Jul
'09
5:02 p.m.
On Jul 01, 2009 at 13:11, Juha Heinanen <jh(a)tutpro.com> wrote:
What you use already works, and is equivalent to what Miklos proposed
(using a sl_reply_route which contains only a drop; ).
Andrei
Daniel-Constantin Mierla writes:
This works, because you are using it in the main reply route
(onreply_route{} without a name) and you can drop replies in the main
reply route.
What you can't do right now is drop replies in tm onreply_routes,
meaning onreply_routes set with t_on_reply("on reply route name").
The reason why this does not work is that we didn't find it useful to
drop a reply to an existing transaction (you can drop it before in the
main onreply_route like you do it or in the sl_reply route if you really
want to, but it makes little sense to drop it after knowing that a
transaction exists for it).
There's a similar reason for drop not being possible in the branch
route. You can always drop any sent message in the onsend_route() (which
is executed for any forwarded message before sending) if you need to do
it for some security reason.
That being said I'm not opposed to introducing drop in the tm on_reply
and branch routes (since there would be no performance hit, little code
and it might help kamailio users to have an easier migration). I just
not see any use-cases for them :-)
For kamailio, in request and failure route they
are the same, stop
processing of the actions. But in branch route and reply route drop does
a bit more: drop current processed branch respectively reply, so they
are not forwarded.
i'm calling 'drop' in onreply_route if t_check_trans() fails on the
reply. the idea is to discard the reply. Addition of this functionality will affect core
and tm. Any comments
regarding this? i can create the patch for it, if nobody sees issues.
if the above functionality can be achieved in sr by some other means, i
can switch to that. if not, 'drop' should be fixed so that it discards
the reply.