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@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----------->|
```
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_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
