[OpenSIPS-Users] https://datatracker.ietf.org/doc/html/rfc3261#section-13.3.1.1

[Bogdan-Andrei Iancu]

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 
> <bogdan at 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 at lists.opensips.org
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240328/c6e274d8/attachment.html>