On Jul 12, 2007 at 11:08, JF jfkavaka@gmail.com wrote:
So, if I want to perform some less simple (e.g. enum_query) processing on failed requests, I should loop the request through SER again and do it in request route?
Not a very nice way to solve it. One more Record-Route, bigger message... parsing the whole thing again.
Andrei, what exactly is the problem regarding long processing in failure route, and what could be done to fix it?
The problem is you block all the processes that handle messages belonging to the same transaction. For example if you have some retransmitted replies while you are in the failure route (for the same transaction the retransmitted replies belong to), the processes receiving the replies will be blocked untill the failure route ends. That's why in general is better to spend as little time as possible in the failure route.
A fix to this would mean trying to execute most of the failure route out of the reply_lock. I think this would be possible, but requires a very carefull analysis, lots of testing and more lockless code (read as: it's not trivial and I'm not 100% sure we can do it without breaking some sip scenarios). If it makes you feel better, it's on my "secret" todo list, but with a low priority, so don't expect any changes in the near future.
Andrei
Thanks, JF
On 7/11/07, Jiri Kuthan jiri@iptel.org wrote:
At 21:22 11/07/2007, Martin Hoffmann wrote:
Jiri Kuthan wrote:
At 16:41 11/07/2007, JF wrote:
Is there any particular reason why enum_query cannot be called from FAILURE_ROUTE?
Not sure. I think it is possible to turn it on but possibly ENUM's
processing
latency may conflict with the failure_route located in the middle of transaction processing and lead to some blocknig conditions, current TM maintainer, Andrei, will certainly know better.
In short: There may be dragons there.
Anyways, I am not sure what you want to do, but you can usually skip the problem by fixing the Request-URI and sprialing the call to yourself.
For instance, if call forwarding is what you're after, instead of re-setting the target and just running processing again, you can just stuff the URI you want to forward to in the Request-URI and call t_relay() (don't forget the append_branch() if in a failure_route).
As a rule, keep failure and onreply routes simple. Actually, as a rule, keep your config simple (Though simple does not necessarly mean short).
Indeed: KISS applies to ser.cfg very well.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers