13 Jul
2007
13 Jul
'07
3:27 p.m.
On Jul 12, 2007 at 11:08, JF <jfkavaka(a)gmail.com> wrote:
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?
The problem is you block all the processes that handle messages
belonging to the same transaction. For example if you have some
retransmitted replies while you are in the failure route (for the same
transaction the retransmitted replies belong to), the processes
receiving the replies will be blocked untill the failure route ends.
That's why in general is better to spend as little time as possible in
the failure route.
A fix to this would mean trying to execute most of the failure route out
of the reply_lock. I think this would be possible, but requires a
very carefull analysis, lots of testing and more lockless code
(read as: it's not trivial and I'm not 100% sure we can do it
without breaking some sip scenarios). If it makes you feel better,
it's on my "secret" todo list, but with a low priority, so don't
expect any changes in the near future.
Andrei
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
>