[sr-dev] exit vs drop

[Miklos Tirpak]

Hi Andrei,

On 07/01/2009 04:02 PM, Andrei Pelinescu-Onciul wrote:
> On Jul 01, 2009 at 13:11, Juha Heinanen <jh at 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).

we do drop replies for existing transactions therefore the 
t_drop_replies() was implemented...

Miklos

> 
> 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
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev