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

[Andreas Granig]

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