[sr-dev] exit vs drop

[Klaus Darilion]

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