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.
-jiri
At 16:41 11/07/2007, JF wrote:
Hi,
Is there any particular reason why enum_query cannot be called from FAILURE_ROUTE?
Thanks,
JF _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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).
Regards, Martin
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/
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 agranig@sipwise.com [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 clona@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Andreas,
as time the functions you are using are safe to be used in failure route, there is no problem doing that...:)
JF, regarding the "enum" functions in failure_route: the reason for not being officially allowed in failure route is because of how the newly added branches are processed, so you might have problems when the enum query returns more than one result. Otherwise is perfectly safe. Just to give you an example of the branch issue: the enum_query() function stores the first URI (from result) in RURI and the rest of them as branches; so, if the query returns A, B and C (ordered by q), you will have A in RURI and B + C in branches. As failure route does not use RURI anymore, you need to do a append_branch() to move A also as a branch -> you have B,C,A order now which conflicts with q.
if you do not have multiple results, you can safely do from failure_route the enum_query() and append_branch().
regards, bogdan
Andreas Granig 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)
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@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
On Jul 12, 2007 at 12:51, Andreas Granig agranig@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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Jul 12, 2007 at 11:08, JF jfkavaka@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Jiri Kuthan wrote:
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.
LOL, when did you last see a non-trivial ser.cfg that conformed to KISS ;-) g-)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 20:38 12/07/2007, Greger V. Teigre wrote:
Jiri Kuthan wrote:
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.
LOL, when did you last see a non-trivial ser.cfg that conformed to KISS ;-)
I think current ser.cfg is actually both quite well structured (even though there is a couple of things I would do even simpler) and still quite powerful.
-jiri
g-)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/http://iptel.org/~jiri/
Serusers mailing list mailto:Serusers@lists.iptel.orgSerusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-
Andreas Granig -
Andrei Pelinescu-Onciul -
Atle Samuelsen -
Bogdan-Andrei Iancu -
Greger V. Teigre -
JF -
Jiri Kuthan -
Martin Hoffmann