[OpenSIPS-Devel] Timeout for INVITE transactions in the tm module should be >= Expires

Maxim Sobolev sobomax at sippysoft.com
Wed Feb 15 17:13:54 EST 2017


Hi,

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.

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.

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).

-Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170215/21587701/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: current.png
Type: image/png
Size: 7361 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170215/21587701/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proper.png
Type: image/png
Size: 5992 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170215/21587701/attachment-0001.png>


More information about the Devel mailing list