[OpenSER-Users] Re: [Serusers] enum_query from failure route

[Andrei Pelinescu-Onciul]

On Jul 12, 2007 at 12:51, Andreas Granig <agranig at sipwise.com> 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 <clona at cyberhouse.no> 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 <jfkavaka at gmail.com> [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 <jiri at iptel.org> 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
> >>> > Serusers at lists.iptel.org
> >>> > http://lists.iptel.org/mailman/listinfo/serusers
> >>> >
> >>> _______________________________________________
> >>> Serusers mailing list
> >>> Serusers at lists.iptel.org
> >>> http://lists.iptel.org/mailman/listinfo/serusers
> >>
> >
> >_______________________________________________
> >Users mailing list
> >Users at openser.org
> >http://openser.org/cgi-bin/mailman/listinfo/users