Hi,
I will look into that, thanks for the report.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 28.07.2014 22:11, Jamuel Starkey wrote:
Thanks, Bogdan--great feature in 1.11.x I was originally looking in
the 1.8.x man pages.
I just got 1.11.2 working here in dev and the feature works great.
One question--any reason that if I xlog the $T_fr_timeout or
$T_fr_inv_timeout variables they return 0 whenever they were not
explicitly set in the script instead of returning the default values
that were set in the mod_param section for tm module?
In any case keep up the good work!
On Jul 28, 2014, at 10:49 AM, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> wrote:
Hi,
fr_timeout is the interval between the request and the first
provisional reply - shortly, how long to to wait for the first
provisional reply.
fr_inv_timeout is the interval between the request and the final
reply (2xx or negative) - shortly, how long to wait for completing
the transaction.
So you can use different values for these 2 timers for a transaction
to get the desired behavior.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 19.07.2014 07:53, Jamuel Starkey wrote:
Hi,
From the TM module man page it would see fr_timeout should fire whenever a
final reply is not received for a request but it is only limited to ACK's for
negative INVITE replies? Is this correct? Can someone be so kind as to clarify
when fr_timeout is triggered.
Is there a method to set a timeout between specific provisional replies in an
INVITE? In other words let's say we receive a 100 TRYING but then see a very
long delay until the next provisional reply (specifically 183 Ringing). Is
there a way to timeout the request so that we can route advance to another
gateway?
We have a carrier who is randomly prone to lengthy PDD intervals in completing
calls we send to them. On such a call our initial INVITE almost immediately
sees the 100 Trying but then we might see another 25-30 seconds before we
seeing another provisional response such as 183 Ringing or a final response.
Is there a way to implement an INVITE specific provisional response timer so
that if we get the 100 Trying and then don't see any other provisional response
in a much shorter period of time (for example no more than 6 seconds) we could
then route advance and attempt the call on another gateway. Is this at all
possible? Serial forking to the next gateway would be fine but parallel
forking would be preferred after the provisional timeout occurred. We'd just
not want to route advance if we received the 183 Ringing provisional response.
Any help or insight would be greatly appreciated.
Cheers,
JPS
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
