Hello,
What are the problems in production that can be encountered if the fr_inv_timer is increased from 30-45 secs to 120 secs for a sip-sip call? Anyone have found any issues?
Thanks! KC
--------------------------------- Unlimited freedom, unlimited storage. Get it now
El Lunes, 11 de Agosto de 2008, Kaeman Chris escribió:
Hello,
What are the problems in production that can be encountered if the fr_inv_timer is increased from 30-45 secs to 120 secs for a sip-sip call? Anyone have found any issues?
In fact, I recommend you to use a value greater then 100 seconds (at last). fr_inv_timer is the time OpenSer keeps the transaction until it receives a final response, but note A can call B and B rings for more than fr_inv_timer before send a 200 OK. What will occur then? OpenSer will receive the 200 OK and will drop it since transaction was already deleted.
So set always fr_inv_timer greater than 100 seconds. In fact, there is not any issue if you set a value os 300 seconds (usually 99% of calls are not ringing for more than 60 seconds).
On Mon, Aug 11, 2008 at 4:47 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Lunes, 11 de Agosto de 2008, Kaeman Chris escribió:
Hello,
What are the problems in production that can be encountered if the fr_inv_timer is increased from 30-45 secs to 120 secs for a sip-sip call? Anyone have found any issues?
In fact, I recommend you to use a value greater then 100 seconds (at last). fr_inv_timer is the time OpenSer keeps the transaction until it receives a final response, but note A can call B and B rings for more than fr_inv_timer before send a 200 OK. What will occur then? OpenSer will receive the 200 OK and will drop it since transaction was already deleted.
AFAIK, the 200 OK is relayed in stateless mode, not dropped.
So set always fr_inv_timer greater than 100 seconds. In fact, there is not any issue if you set a value os 300 seconds (usually 99% of calls are not ringing for more than 60 seconds).
-- Iñaki Baz Castillo
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Lunes, 11 de Agosto de 2008, Ovidiu Sas escribió:
AFAIK, the 200 OK is relayed in stateless mode, not dropped.
You are rigth, this is what RFC3261 says, but not sure if OpenSer implements it, does it? but will OpenSer also relay a non 2XX final response in stateless mode if transaction expired?
Anyway other problem will occur with the following ACK. If 2XX the ACK is a new transaction but AFAIK OpenSer matches it (in some way) to the INVITE transaction (now expired). If non 2XX then the ACK is part of the INVITE transaction so it will not delivered to the UAS because the transaction expired.
Iñaki Baz Castillo schrieb:
El Lunes, 11 de Agosto de 2008, Ovidiu Sas escribió:
AFAIK, the 200 OK is relayed in stateless mode, not dropped.
You are rigth, this is what RFC3261 says, but not sure if OpenSer implements it, does it? but will OpenSer also relay a non 2XX final response in stateless mode if transaction expired?
yes.
Anyway other problem will occur with the following ACK. If 2XX the ACK is a new transaction but AFAIK OpenSer matches it (in some way) to the INVITE transaction (now expired). If non 2XX then the ACK is part of the INVITE transaction so it will not delivered to the UAS because the transaction expired.
Indeed, ACK routing will be more difficult. 200-OK ACK should be loose routed - thus no problem. non-200 ACK I guess will be absorbed by tm (not sure about this). I think problem makes non-200 OK ACK with a pre-louded route set.
regards klaus
El Tuesday 12 August 2008 08:55:49 Klaus Darilion escribió:
Anyway other problem will occur with the following ACK. If 2XX the ACK is a new transaction but AFAIK OpenSer matches it (in some way) to the INVITE transaction (now expired). If non 2XX then the ACK is part of the INVITE transaction so it will not delivered to the UAS because the transaction expired.
Indeed, ACK routing will be more difficult. 200-OK ACK should be loose routed - thus no problem.
Well, "no problem"? I thing it must be handled doing something as:
if method == "ACK" { if ! t_checktran <-- Because transaction is deleted now lookup("location") ...
non-200 ACK I guess will be absorbed by tm (not sure about this).
How can occur tha tif transaction has been already deleted?
Iñaki Baz Castillo schrieb:
El Tuesday 12 August 2008 08:55:49 Klaus Darilion escribió:
Anyway other problem will occur with the following ACK. If 2XX the ACK is a new transaction but AFAIK OpenSer matches it (in some way) to the INVITE transaction (now expired). If non 2XX then the ACK is part of the INVITE transaction so it will not delivered to the UAS because the transaction expired.
Indeed, ACK routing will be more difficult. 200-OK ACK should be loose routed - thus no problem.
Well, "no problem"? I thing it must be handled doing something as:
if method == "ACK" { if ! t_checktran <-- Because transaction is deleted now lookup("location") ...
Basically yes, but not for in-dialog modules. Usually you first have if (loose_route()) ...
if method == "ACK" { if ! t_checktran <-- Because transaction is deleted now lookup("location")
non-200 ACK I guess will be absorbed by tm (not sure about this).
How can occur tha tif transaction has been already deleted?
proxy ---INVITE--->| |---INVITE------> | fr_timeout fires wt_timer fires (now the transaction is remove from tm) |<----180-------- <-180--------| |<---500--------- <--500-------| | ---ACK------>| | ACK (if using the logic from above)
regards klaus
Iñaki Baz Castillo wrote:
El Lunes, 11 de Agosto de 2008, Kaeman Chris escribió:
Hello,
What are the problems in production that can be encountered if the fr_inv_timer is increased from 30-45 secs to 120 secs for a sip-sip call? Anyone have found any issues?
In fact, I recommend you to use a value greater then 100 seconds (at last). fr_inv_timer is the time OpenSer keeps the transaction until it receives a final response, but note A can call B and B rings for more than fr_inv_timer before send a 200 OK. What will occur then? OpenSer will receive the 200 OK and will drop it since transaction was already deleted.
Kamailio never drops final responses (even if you call "drop" in the reply route) - they will get forwarded stateless if no corresponding transcation is not found (timed out).
Further, if there was at least one provisional response (e.g 100) then Kamailio will send a CANCEL, thus in this case there should be no 200 OK after transaction timeout.
regards klaus
So set always fr_inv_timer greater than 100 seconds. In fact, there is not any issue if you set a value os 300 seconds (usually 99% of calls are not ringing for more than 60 seconds).
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Kaeman Chris -
Klaus Darilion -
Ovidiu Sas