<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="monospace">Hi Johan,<br>
<br>
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.<br>
<br>
Regards,<br>
</font>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="https://www.opensips-solutions.com">https://www.opensips-solutions.com</a>
<a class="moz-txt-link-freetext" href="https://www.siphub.com">https://www.siphub.com</a></pre>
<div class="moz-cite-prefix">On 28.03.2024 10:29, Johan De Clercq
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEVWGm_Mbp2JU5hT54iYPCrgs25uMEvAZ2XsGctP_rhR7YDz-w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Question,
<div><br>
</div>
<div>I always believed that fr_inv_timer should trigger when
an invite is not finished in due time. </div>
<div>This seems however to contradict the link in the title </div>
<div><br>
</div>
<div>
<pre class="gmail-newpage"
style="box-sizing:border-box;font-size:16px;margin-bottom:0px;overflow:visible;padding:0px;width:80ch;color:rgb(222,226,230);background-color:rgb(33,37,41)"> 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
of <a
href="https://datatracker.ietf.org/doc/html/rfc3261#section-12.1.1"
style="box-sizing:border-box" moz-do-not-send="true">Section 12.1.1</a> in addition to those of <a
href="https://datatracker.ietf.org/doc/html/rfc3261#section-8.2.6"
style="box-sizing:border-box" moz-do-not-send="true">Section 8.2.6</a>. 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.</pre>
</div>
<div><br>
</div>
<div>Can somebody please comment on this ? </div>
<div><br>
</div>
<div>BR, Johan. </div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>