[OpenSIPS-Devel] [opensips] fr_inv_timer restarted when restart_fr_on_each_reply = 0 and replies sequence is 100, 183, 180, 183 (#342)

[miko95]

Hi,

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.

The SIP flow was:

```
10:56:37.203070      |-----------INVITE sip:+27137445208 at 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 at 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 at 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 at 196.25.241.86:5060;transport=udp SIP/2.0-->|
10:57:38.247836      |<-------------------------------200 OK------------------------------|
10:58:28.132556      |-----------CANCEL sip:+27137445208 at 196.25.241.86 SIP/2.0----------->|
```

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.

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

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 
```
(last_uac_status < msg_status) && ((msg_status >= 180) || (last_uac_status == 0))
```
will match for:
 - the 100 reply (since it is the first reply - last_uac_status = 0)
 - the first 183 reply (since 100 < 183 and 183 >= 180)
 - 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.

Therefore, it seems the fr_inv_timer may be restarted "indefinitely" is the sequence 180,183,180,183... is returned by the UAS.

Is this behavior expected?

Regards,
Mickael

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/342
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20140930/9b4abab0/attachment.htm>