Hi,

as I know only t_drop_replies() function exists in tm module that does something similar, but it drops all the replies received so far, and it is usable only from failure_route.

Anyway, I think your particular problem can be solved with the on_sl_reply modparam:

modparam(tm, on_sl_reply, "stateless_reply");

onreply_route["stateless_reply"] { # This route is executes if tm module does not find # the transaction for the reply. # If 0 is returned then the reply is not forwarded. return 0; }

Miklos

On 07/01/2009 12:11 PM, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

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.

-- juha

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

On 07/01/2009 02:25 PM, Juha Heinanen wrote:

Miklos Tirpak writes:

...

Anyway, I think your particular problem can be solved with the on_sl_reply modparam:

modparam(tm, on_sl_reply, "stateless_reply");

onreply_route["stateless_reply"] { # This route is executes if tm module does not find # the transaction for the reply. # If 0 is returned then the reply is not forwarded. return 0; }

mikos,

do i need to call t_on_reply("stateless_reply") in order to activate this onreply route?

No, you do not need to. tm module checks every incoming reply. If the transaction is not found for a reply and the above modparam is set then the route block, "stateless_reply" in my example, is executed. Depending on the return value of this route the processing continues or stops. t_on_reply() has an effect only if tm module finds the associated transaction of the reply, so it is another case.

if so, it is not very practical, because i currently call 'drop' in default onreply_route, which is executed automatically for each reply.

I see, so you did it before tm module saw the reply. In fact both solutions wrap to the same function, t_check(), so you should get the same result.

Miklos

-- juha

On Mittwoch, 1. Juli 2009, Juha Heinanen wrote:

...

I see, so you did it before tm module saw the reply. In fact both solutions wrap to the same function, t_check(), so you should get the same result.

fine. so in my config, i don't anymore have a need for 'drop' command.

So that means we could drop the "drop" command? Fine, one statement less. :)

Henning

On Wednesday 01 July 2009 15:02:32 Juha Heinanen wrote:

Henning Westerholt writes:

...

So that means we could drop the "drop" command? Fine, one statement less. :)

i just commented on it from my own point of view. perhaps there are other needs for 'drop' than dropping transactionless replies (for which purpose it is not needed).

Yes, I have some config on witch I need to drop some branches generated after a lookup() call and I do it on on_branch routes, how could that be done if drop() is removed ?

On Jul 01, 2009 at 16:56, Juha Heinanen jh@tutpro.com wrote:

Miklos Tirpak writes:

...

I see, so you did it before tm module saw the reply. In fact both solutions wrap to the same function, t_check(), so you should get the same result.

fine. so in my config, i don't anymore have a need for 'drop' command.

You still need one in the sl_reply_route. It should contain only drop if you want to be equivalent to your if (!t_check_trans()) drop; in the onreply_route. If it doesn't contain a drop or a return 0, it won't drop the reply :-)

Note that in this case (top-level-route) drop is equivalent with return 0 (but not in other cases, return exists only from the current route, while drop or exit immediately stop all script processing even if the route is not top-level).

Andrei

On Jul 01, 2009 at 13:11, Juha Heinanen jh@tutpro.com wrote:

Daniel-Constantin Mierla writes:

...

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.

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 :-)

...

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.

What you use already works, and is equivalent to what Miklos proposed (using a sl_reply_route which contains only a drop; ).

Andrei

Andrei Pelinescu-Onciul wrote:

On Jul 01, 2009 at 13:11, Juha Heinanen jh@tutpro.com wrote:

...

Daniel-Constantin Mierla writes:

...

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.

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 :-)

In some case it might be needed to drop provisional responses (e.g. caller can not handle 183 early media response correct, or whatever).

regards klaus