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? 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
