[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