tm readme on t_relay flag "0x02" says:
0x02 - do not internally send a negative reply in case of forward failure (due internal error, bad RURI, bad message, etc). When a forward failure occurs, no SIP request is relayed and therefore no negative reply or timeout will show up on the failure_route (if one is set). It applies only when the transaction is created. By default one negative reply is sent. Useful if you want to implement a serial forking in case of failure.
i don't quite understand the statement:
It applies only when the transaction is created.
what does "It" refer to?
i did some experiments with new lcr implementation and if, for example, tcp connection to a gw cannot be established, then t_relay without "0x02" flag generates 477 reply to caller and, indeed, failure route is not executed.
so i need test if t_relay("0x02") failed due to "send failed" and handle selection of next gw in the same route block where t_relay("0x02") was called. this is inconvenient, because there already exists a failure route block that does all that and now its code needs to be at least partially duplicated.
or am i missing something and it is somehow possible to get a failure route block executed also on this kind of internally generated negative reply?
-- juha
Hello,
On 10/18/08 19:27, Juha Heinanen wrote:
tm readme on t_relay flag "0x02" says:
0x02 - do not internally send a negative reply in case of forward failure (due internal error, bad RURI, bad message, etc). When a forward failure occurs, no SIP request is relayed and therefore no negative reply or timeout will show up on the failure_route (if one is set). It applies only when the transaction is created. By default one negative reply is sent. Useful if you want to implement a serial forking in case of failure.
i don't quite understand the statement:
It applies only when the transaction is created.
what does "It" refer to?
i did some experiments with new lcr implementation and if, for example, tcp connection to a gw cannot be established, then t_relay without "0x02" flag generates 477 reply to caller and, indeed, failure route is not executed.
so i need test if t_relay("0x02") failed due to "send failed" and handle selection of next gw in the same route block where t_relay("0x02") was called. this is inconvenient, because there already exists a failure route block that does all that and now its code needs to be at least partially duplicated.
or am i missing something and it is somehow possible to get a failure route block executed also on this kind of internally generated negative reply
Not now, but we can have it as feature request and see what can be done by next release. It will look indeed more coherent.
Now, an workaround could be to move content of failure_route in a route, call that route from failure route and after the relay fails. I think there should be introduced a new PV that can tell what is the type of root route block (request route, failure route, reply route), so one can take decisions based on that in script.
Cheers, Daniel
Daniel-Constantin Mierla writes:
or am i missing something and it is somehow possible to get a failure route block executed also on this kind of internally generated negative reply
Not now, but we can have it as feature request and see what can be done by next release. It will look indeed more coherent.
i created a feature request about it.
Now, an workaround could be to move content of failure_route in a route, call that route from failure route and after the relay fails. I think there should be introduced a new PV that can tell what is the type of root route block (request route, failure route, reply route), so one can take decisions based on that in script.
this workaround does not work if failure route block needs to call functions that can not be called in request route block. so i would say that there is a bug in current setup, because all things simply cannot be made to work correctly no matter what.
-- juha
-
Daniel-Constantin Mierla -
jh＠tutpro.com