At 12:08 12/07/2007, JF 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.
Well sometimes a big-hammer approach features design simplicity which is good (simple to understand, audit, maintain, ....) and can be used to solve problems on serial basis. I personally find this quite a good solution. > One more Record-Route, bigger >message... parsing the whole thing again. parsing yes, you don't have to record-route each pass. -jiri >Andrei, what exactly is the problem regarding long processing in >failure route, and what could be done to fix it? > >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 > > > >-- >Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
