16 Apr
2014
16 Apr
'14
7:33 p.m.
On 16/04/14 18:29, Juha Heinanen wrote:
Hugh Waite writes:
Some of
these attributes are lost, not stored in the branch at all. Next
hop (which can be from $du) is resolved in some dns structure.
See my previous email for a possible way of accessing existing
attributes stored in the branch.
Why would you need all attributes of the branch that just failed, do you
want to send the request to the same destination again?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
As you and Daniel saw from the code, I replicated
the behaviour of the
'failure-route' but with the current branch index. I didn't deliberately
choose the behaviour of $ru etc. so I'm happy with it being classed as a bug
if that's what's expected in this situation.
Does $T_req($ru) give something different in this situation?
hugh,
i tried with
event_route [tm:branch-failure:contact] {
if (t_check_status("488")) {
xlog("L_INFO", "Got 488 response to
<$T_req($ru)>\n");
and got:
Apr 16 19:22:52 siika /usr/sbin/sip-proxy[16206]: INFO: Got 488 response to
<<null>>
but even if i could get access to branch route $ru, it would not be
enough, since i would also need the branch flags, send socket, $du,
etc., so that after append_branch(); t_relay() would do the right thing.