hi, I??ve never used enum in this way, but, ive rather often done failure_route -> route to do other stuff.. Like, It??s happend I need to send a 181.. or other call-forwarding related stuff :) so, even while it??s ugly,, it works ;)
- Atle * Andreas Granig <[EMAIL PROTECTED]> [070712 12:52]: > 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) > > 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