13 Jul
2007
13 Jul
'07
3:32 p.m.
On Jul 12, 2007 at 12:51, Andreas Granig <agranig(a)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(a)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(a)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(a)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(a)lists.iptel.org
>>> > http://lists.iptel.org/mailman/listinfo/serusers
>>> >
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users