On Jul 12, 2007 at 12:51, Andreas Granig <[EMAIL PROTECTED]> wrote: > Hi, > > Well, I do this for years now (jumping right back into routes for > processing call-forward-busy etc.) without any problems. Should I care? :o)
For enum no. However working arround ser's failoure route checks using route() might burn you if you use some command which really is not failure route safe. You could get a deadlock if you use a tm non failure route safe command. So, if you use it make sure everything you call from that route is failure route safe. Andrei > > Andreas > > > JF wrote: > >Thanks. > >The issue here is what kind of "Dragons" will be awaked in TM if I do > >that... > > > >JF > > > >On 7/12/07, Atle Samuelsen <[EMAIL PROTECTED]> wrote: > >> > >>Hi Jf, > >> > >>There is one hack you can do.. wich would allow you do to a enumquery.. > >>but, it?s not nice.. > >> > >>in failure_route, call a regular route. and in the reuglar route do a > >>enum_query. It works I think (not tried it) but it?s not nice. > >> > >>this way, you will "skip" the extra record_rotue etc.. > >>- Atle > >> > >>* JF <[EMAIL PROTECTED]> [070712 12:09]: > >>> 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 > >>> > > >>> _______________________________________________ > >>> 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 _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users