<p>Hi,</p>
<p>We just set the restart_fr_on_each_reply parameter to 0 so that fr_inv_timer is not restarted when provisional replies are received but we got the following issue.</p>
<p>The SIP flow was:</p>
<pre><code>10:56:37.203070 |-----------INVITE sip:+27137445208@196.25.241.86 SIP/2.0----------->|
10:56:37.438361 |<------------------------100 Giving a try...------------------------|
10:56:38.184987 |<------------------------183 Session Progress-----------------------|
10:56:38.275681 |---PRACK sip:27137445208@196.25.241.86:5060;transport=udp SIP/2.0-->|
10:56:38.516773 |<-------------------------------200 OK------------------------------|
10:56:38.517898 |<----------------------------180 Ringing----------------------------|
10:56:38.601496 |---PRACK sip:27137445208@196.25.241.86:5060;transport=udp SIP/2.0-->|
10:56:38.843527 |<-------------------------------200 OK------------------------------|
10:57:37.925117 |<------------------------183 Session Progress-----------------------|
10:57:38.005561 |---PRACK sip:27137445208@196.25.241.86:5060;transport=udp SIP/2.0-->|
10:57:38.247836 |<-------------------------------200 OK------------------------------|
10:58:28.132556 |-----------CANCEL sip:+27137445208@196.25.241.86 SIP/2.0----------->|
</code></pre>
<p>As you can see, the replies received by OpenSIPS for the initial INVITE transaction are 100, 183, 180, 183. The transaction is cancelled by the UAC (the CANCEL is not generated by OpenSIPS) around 10:58:28.</p>
<p>The fr_inv_timer was set to 60 seconds, therefore I expected the call to be cancelled around 10:57:37 (i.e. 10:56:37 + 60 sec).</p>
<p>I looked at the t_should_relay_response function (see source file t_reply.c at line 1073), the UAC last_received field is overridden by the received status for each received provisional reply. Also, in the reply_received function (see source file t_reply.c at lines 1640-1642), the condition </p>
<pre><code>(last_uac_status < msg_status) && ((msg_status >= 180) || (last_uac_status == 0))
</code></pre>
<p>will match for:</p>
<ul class="task-list">
<li>the 100 reply (since it is the first reply - last_uac_status = 0)</li>
<li>the first 183 reply (since 100 < 183 and 183 >= 180)</li>
<li>the second 183 reply (since 180 < 183 and 183 >= 180). Note when the second 183 reply is processed, last_uac_status is 180 because of the last received 180 reply.</li>
</ul><p>Therefore, it seems the fr_inv_timer may be restarted "indefinitely" is the sequence 180,183,180,183... is returned by the UAS.</p>
<p>Is this behavior expected?</p>
<p>Regards,<br>
Mickael</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href="https://github.com/OpenSIPS/opensips/issues/342">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/5479561__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNzY4NzQyOCwiZGF0YSI6eyJpZCI6NDQyNjczMjh9fQ==--c472a0dba2d6d24f315c00f9f2ac8c6d729b6911.gif" width="1" /></p>
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","description":"View this Issue on GitHub","action":{"@type":"ViewAction","url":"https://github.com/OpenSIPS/opensips/issues/342","name":"View Issue"}}</script>