<div dir="ltr">Hi,<div><br></div><div>Today I've noticed the following failure scenario in the tm module, that I think could be handled better (current.png). Basically what happens there is that UA2 due to some software bug has failed to emit proper provisional replies, but got INVITE transaction properly setup and then eventually that INVITE timeouts on expire with the proper 487 Request Expired. By that time OpenSIPS properly stops retransmits and generates 408 Request Timeout to UA1 and supposedly clears up transaction from the shared memory. So that subsequent 487 gets handled statelessly and forwarded back to the UA1, which is also at this point has no clue about that transaction anymore causing UA2 to spin its wheels trying to retransmit and wasting resources of all agents in chain.</div><div><br></div><div>In this case failure is on the UA2 side, however the same scenario can occur if there is a temporary network disruption on the UA2 side as well, so that INVITE gets through, but none of the provisional replies within 32 seconds.<br><br></div><div>What should have been happening in my view is that wherever transaction on the UA1 side timeouts without generating CANCEL on the outbound side, the tm module should  increase lifetime of the outbound transaction to at least the value of the Expires in the original outbound INVITE sent to the UA2 from the default value. So that any late responses would be properly intercepted and ACK generated by the OpenSIPS (proper.png).</div><div><br></div><div><div>-Max</div><div><br></div><div><br></div><div><br></div>
</div></div>