For any reply, see here the condition:
https://github.com/OpenSIPS/opensips/blob/4b23a80bd14dcf509ebe8de22f26906d34e0b079/modules/tm/t_reply.c#L1697
Keep in mind that the restart_fr_on_each_reply is by default on (set to 1).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 28.03.2024 12:37, Johan De Clercq wrote:
Thanks for the swift reply Bogdan.
but shouldn't this timer be reset when receiving f.e. 180 or 183 ?
Op do 28 mrt 2024 om 11:35 schreef Bogdan-Andrei Iancu
<bog...@opensips.org>:
Hi Johan,
In OpenSIPS, the fr_inv_timer kicks in (for INVITEs) when a first
reply (typically a 100) is received from UAS. And it will wait for
the final reply. So, it is how long to wait from the first reply
up to the final one.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 28.03.2024 10:29, Johan De Clercq wrote:
Question,
I always believed that fr_inv_timer should trigger when an invite
is not finished in due time.
This seems however to contradict the link in the title
If the UAS is not able to answer the invitation immediately, it can
choose to indicate some kind of progress to the UAC (for example, an
indication that a phone is ringing). This is accomplished with a
provisional response between 101 and 199. These provisional
responses establish early dialogs and therefore follow the procedures
ofSection 12.1.1
<https://datatracker.ietf.org/doc/html/rfc3261#section-12.1.1> in addition to those
ofSection 8.2.6 <https://datatracker.ietf.org/doc/html/rfc3261#section-8.2.6>. A
UAS MAY
send as many provisional responses as it likes. Each of these MUST
indicate the same dialog ID. However, these will not be delivered
reliably.
If the UAS desires an extended period of time to answer the INVITE,
it will need to ask for an "extension" in order to prevent proxies
from canceling the transaction. A proxy has the option of canceling
a transaction when there is a gap of 3 minutes between responses in a
transaction. To prevent cancellation, the UAS MUST send a non-100
provisional response at every minute, to handle the possibility of
lost provisional responses.
An INVITE transaction can go on for extended durations when the
user is placed on hold, or when interworking with PSTN systems
which allow communications to take place without answering the
call. The latter is common in Interactive Voice Response (IVR)
systems.
Can somebody please comment on this ?
BR, Johan.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
