[Kamailio-Devel] drop in onreply_route
Daniel-Constantin Mierla
miconda at gmail.com
Mon Nov 3 18:39:28 CET 2008
Hi Klaus,
On 11/03/08 19:16, Klaus Darilion wrote:
>
>
> Daniel-Constantin Mierla schrieb:
>> Hello,
>>
>> I just committed to trunk an update that drop() will stop the
>> execution of any reply processing if called in default onreply_route.
>>
>> Do you think should be extended for the onreply_routes executed by tm
>> upon t_on_reply()?
>>
>> The goal was to use drop() together with t_check_trans() to prevent
>> against being open relay for SIP replies. It solves also some other
>> potential issues, I will detail in another emails, just want to see
>> if worth to be extended.
>
>
> Hi Daniel. Would it make sense for a new reply_route-type? AFAIK the
> non-default reply routes will be called if tm module finds a
> transaction - e.g. if I activate t_on_reply(), and the response is so
> late that the transaction is already terminated, the corresponding
> reply route will not be executed.
>
> Thus, there must already be some mechanism which checks if the reply
> matches an ongoing transaction. Thus, if we extend this code to
> execute the reply_route_notm{}, then we could handle replies without
> matching transaction in this route type. Then, an explicit call to
> t_check_trans can be avoided.
there won't be much gain, just yet another route. t_chec_trans() uses
the code from tm to detect if it is in/out of a transaction and keeps a
shortcut
I could say that i like the aproach with t_check_trans because i can use
other filters before calling it -- e.g., only if the reply is not
comming from my gateways/media servers. With a separate reply route,
that has to be called all the time...
Cheers,
Daniel
>
> Then there should not be any need to have a "drop_all" in non-default
> reply routes.
>
> regards
> klaus
>
--
Daniel-Constantin Mierla
http://www.asipto.com
More information about the Devel
mailing list