[Kamailio-Devel] drop in onreply_route

[Klaus Darilion]

Daniel-Constantin Mierla schrieb:
> 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...

If tm stores a shortcut (to avoid scanning all the active transaction a 
second time) then the dedicated route is not needed. But when is the tm 
callback executed - before or after default reply route?

klaus