On Jul 12, 2007 at 11:08, JF <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >[EMAIL PROTECTED] > >http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
