Because right now both situations leading to code #64.
so there is no code #130. code #130 for situation when disconnect initiator = switch.
also on cdr side the system is able read that legb reason is “Timeout”, DC reason is “Sip transaction timeout” and the lega reason is “request timeout”.
it is recognized on this cdr, no?
ok. We will discuss internally if we want to violate RFC there.
it’s not a violation I think, it’s just a bug that for some reason doesn’t make some checks if the #63 is set to stop hunting=true. I think everything is ok with rfc, you just need to see why rules on #130 are bypassed by rules on #63.
Thanks a lot, that would solve a lot of issues if a carrier goes down, right now all the traffic is stopped when a carrier is down, even if I have a lot on cascade.
it is not clear what use case there. Why you want to not reroute call when remote gw respond 408? Because this response indicates issues on carrier side in same way as transaction timeout.
yes, that’s true, both codes would be 408 but reasons are different, and you are already managing different reasons.
408 “Request timeout” is a termination that tried to contact customer and it doesn’t reply, even if his phone is ringing, after some time the switch return 408, the request has timed out.
408 “timeout” or “sip transaction timeout” is a termination not online, so no request are sent to any phone, and I want to reroute on another termination.
on this example i set stop hunting= no and it’s routing perfectly, if I set to yes on #63 it just seems that #63 has more priority over #130.
I just made a test setting stop hunting=no on #63 and yes on #130 and basically it seems you are not reading that flag because it will reroute even if I set to no
and no rewrite code and reasons are written
408 request timeout shouldn’t be generated when customer alerted but doesn’t accepting call.
basically it’s working in that way instead, if a customer will not reply in a time range, the termination replies with 408 “request timeout”
so that’s why we need to differentiate at least the reasons
I think the main problem is that rule #130 is not managed properly, his flags and rewrites are not checked in some way when it’s loaded, just the code and the reason, so it is overridden from the rule #63 …that’s just my guess
the same reason why it’s passing reason to originator even if it’s set to no