13 Oct
2008
13 Oct
'08
2:58 p.m.
It would be really nice to have a feature in TM for even faster failover
that is turned off when any reply is received at all, provisional or
otherwise.
The problem with fr_timer and fr_inv_timer is that they throw on lack of
final reply. But sometimes gateways have very lengthy, complicated
asynchronous operations that must complete before they can return a
final OK. If you are doing failover, the most important thing to know
is that the gateway is there at all, which the provisional 1xx message
accomplishes.
What would be really nice is to have a timer that can be diffused as
soon as a provisional reply arrives.
I don't see how this can be accomplished with any of the existing timers.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
13 Oct
13 Oct
3:10 p.m.
Also, it doesn't seem to me that this can be accomplished with the
RFC-defined T-timers.
Alex Balashov wrote:
It would be really nice to have a feature in TM for
even faster failover
that is turned off when any reply is received at all, provisional or
otherwise.
The problem with fr_timer and fr_inv_timer is that they throw on lack of
final reply. But sometimes gateways have very lengthy, complicated
asynchronous operations that must complete before they can return a
final OK. If you are doing failover, the most important thing to know
is that the gateway is there at all, which the provisional 1xx message
accomplishes.
What would be really nice is to have a timer that can be diffused as
soon as a provisional reply arrives.
I don't see how this can be accomplished with any of the existing timers.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
4:14 p.m.
Hi Alex!
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to 2
seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then tm
module changes to fr_inv_timer which I have set to 120 seconds.
regards
klaus
Alex Balashov schrieb:
It would be really nice to have a feature in TM for
even faster failover
that is turned off when any reply is received at all, provisional or
otherwise.
The problem with fr_timer and fr_inv_timer is that they throw on lack of
final reply. But sometimes gateways have very lengthy, complicated
asynchronous operations that must complete before they can return a
final OK. If you are doing failover, the most important thing to know
is that the gateway is there at all, which the provisional 1xx message
accomplishes.
What would be really nice is to have a timer that can be diffused as
soon as a provisional reply arrives.
I don't see how this can be accomplished with any of the existing timers.
4:23 p.m.
Hello,
On 10/13/08 16:14, Klaus Darilion wrote:
Hi Alex!
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to 2
seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then tm
module changes to fr_inv_timer which I have set to 120 seconds.
if I get it right, might be similar to something I encountered quite
recently. There are some PSTN termination providers that frontend their
GW farm with a proxy. That proxy sends quickly 100 trying but then it
takes too long to get ringing or 200ok.
So I would have needed to change to fr_inv_timer if != 100 is received
in fr_timer.
Cheers,
Daniel
regards
klaus
Alex Balashov schrieb:
--
Daniel-Constantin Mierla
http://www.asipto.com
It would be really nice to have a feature in TM
for even faster failover
that is turned off when any reply is received at all, provisional or
otherwise.
The problem with fr_timer and fr_inv_timer is that they throw on lack of
final reply. But sometimes gateways have very lengthy, complicated
asynchronous operations that must complete before they can return a
final OK. If you are doing failover, the most important thing to know
is that the gateway is there at all, which the provisional 1xx message
accomplishes.
What would be really nice is to have a timer that can be diffused as
soon as a provisional reply arrives.
I don't see how this can be accomplished with any of the existing timers.
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
4:57 p.m.
New subject: [Kamailio-Users] OT: European DID providers
I realize this is not the purpose of this list, so please forgive me... but
I have had a very difficult time finding DID\DDI providers in Western
Europe. I believe the companies I am looking for are most likely Kamailio
users... so if anyone on this is provides SIP-based DID\DDI services in
Italy, France, Germany, and Spain (or smaller countries), please contact me
OFF LIST.
Sorry for the noise.
Michael Young
6:24 p.m.
Daniel-Constantin Mierla schrieb:
Hello,
On 10/13/08 16:14, Klaus Darilion wrote:
should we fix the PSTN? :-)
Hi Alex!
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to
2 seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then
tm module changes to fr_inv_timer which I have set to 120 seconds.
if I get it right, might be similar to something I encountered quite
recently. There are some PSTN termination providers that frontend their
GW farm with a proxy. That proxy sends quickly 100 trying but then it
takes too long to get ringing or 200ok. So I would have needed to change to fr_inv_timer if !=
100 is received
in fr_timer.
Not changing - maybe adding a new one. The fr_timer is needed for fast
detection of GW failures.
Cheers,
Daniel
regards
klaus
Alex Balashov schrieb:
It would be really nice to have a feature in TM
for even faster
failover that is turned off when any reply is received at all,
provisional or otherwise.
The problem with fr_timer and fr_inv_timer is that they throw on lack
of final reply. But sometimes gateways have very lengthy,
complicated asynchronous operations that must complete before they
can return a final OK. If you are doing failover, the most important
thing to know is that the gateway is there at all, which the
provisional 1xx message accomplishes.
What would be really nice is to have a timer that can be diffused as
soon as a provisional reply arrives.
I don't see how this can be accomplished with any of the existing
timers.
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
8:36 p.m.
Hello,
On 10/13/08 18:24, Klaus Darilion wrote:
I meant to change the timeout to fr_inv_timer value, not to change the
behavior of existing parameters. So, you are right, a new parameter
could be the solution in this case.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Daniel-Constantin Mierla schrieb:
:-) he he ... do you mean: fix == replace?!?!
Hello,
On 10/13/08 16:14, Klaus Darilion wrote:
should we fix the PSTN? :-)
Hi Alex!
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to
2 seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then
tm module changes to fr_inv_timer which I have set to 120 seconds.
if I get it right, might be similar to something I encountered quite
recently. There are some PSTN termination providers that frontend their
GW farm with a proxy. That proxy sends quickly 100 trying but then it
takes too long to get ringing or 200ok.
So I would have needed to change to fr_inv_timer
if != 100 is received
in fr_timer.
Not changing - maybe adding a new one. The fr_timer is needed for fast
detection of GW failures.
Cheers,
Daniel
> regards
> klaus
>
> Alex Balashov schrieb:
>
>
>> It would be really nice to have a feature in TM for even faster
>> failover that is turned off when any reply is received at all,
>> provisional or otherwise.
>>
>> The problem with fr_timer and fr_inv_timer is that they throw on lack
>> of final reply. But sometimes gateways have very lengthy,
>> complicated asynchronous operations that must complete before they
>> can return a final OK. If you are doing failover, the most important
>> thing to know is that the gateway is there at all, which the
>> provisional 1xx message accomplishes.
>>
>> What would be really nice is to have a timer that can be diffused as
>> soon as a provisional reply arrives.
>>
>> I don't see how this can be accomplished with any of the existing
>> timers.
>>
>>
>>
> _______________________________________________
> Users mailing list
> Users(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
4:54 p.m.
Hi Klaus,
Klaus Darilion wrote:
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to 2
seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then tm
module changes to fr_inv_timer which I have set to 120 seconds.
I must have misunderstood the module documentation, then. The
documentation for the fr_timer section specifically says:
"Timer which hits if no final reply for a request or ACK for a
negative INVITE reply arrives (in seconds)."
I understood this literally; it applies to *final* responses, not
provisional ones.
But after reading your reply I looked at the "timer-based failover"
section above it and it says:
"fr_timer - this timer is used when no response was received yet. If
there is no response after fr_timer seconds the timer triggers (and
failure route will be executed if t_on_failure() was called). If a
provisional response was received, the timer is set to fr_inv_timer
for INVITE transactions, and RT_T2 for all other transactions. If a
final reponse is received, the transaction has finished. "
So which one is it? Do provisional responses affect fr_timer expiration
or not?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
6:22 p.m.
Alex Balashov schrieb:
Hi Klaus,
Klaus Darilion wrote:
Yes, they do. fr_timer fires only if no response was received within
fr_timer intervall. If a provisonal response is received, the fr_timer
will be deleted and fr_inv_timer will be used.
klaus
Not sure what you mean:
For detection if the gateway responds at all use fr_timer. I set it to
2 seconds. If there is no reply from the gateway within 2 seconds, the
failure route will be executed. If there is a reply (e.g. 100), then
tm module changes to fr_inv_timer which I have set to 120 seconds.
I must have misunderstood the module documentation, then. The
documentation for the fr_timer section specifically says:
"Timer which hits if no final reply for a request or ACK for a
negative INVITE reply arrives (in seconds)."
I understood this literally; it applies to *final* responses, not
provisional ones.
But after reading your reply I looked at the "timer-based failover"
section above it and it says:
"fr_timer - this timer is used when no response was received yet. If
there is no response after fr_timer seconds the timer triggers (and
failure route will be executed if t_on_failure() was called). If a
provisional response was received, the timer is set to fr_inv_timer
for INVITE transactions, and RT_T2 for all other transactions. If a
final reponse is received, the transaction has finished. "
So which one is it? Do provisional responses affect fr_timer expiration
or not?
5887
days inactive
5887
days old
8 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Klaus Darilion -
Michael Young