[Kamailio-Users] fr_inv_timer increased to 120 secs

[Kaeman Chris]

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

[Iñaki Baz Castillo]

Post by Kaeman Chris
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).

[Ovidiu Sas]

Post by Iñaki Baz Castillo

Post by Kaeman Chris
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.

Post by Iñaki Baz Castillo
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
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

[Iñaki Baz Castillo]

Post by Ovidiu Sas
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.

[Klaus Darilion]

Post by Iñaki Baz Castillo

Post by Ovidiu Sas
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.

Post by Iñaki Baz Castillo
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

[Klaus Darilion]

Post by Iñaki Baz Castillo

Post by Kaeman Chris
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

Post by Iñaki Baz Castillo
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]

Post by Klaus Darilion

Post by Iñaki Baz Castillo
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")
...

Post by Klaus Darilion
non-200 ACK I guess will be absorbed by tm
(not sure about this).

How can occur tha tif transaction has been already deleted?

[Klaus Darilion]

Post by Iñaki Baz Castillo

Post by Klaus Darilion

Post by Iñaki Baz Castillo
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.

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())
...

Post by Iñaki Baz Castillo
if method == "ACK" {
if ! t_checktran <-- Because transaction is deleted now
lookup("location")

Post by Klaus Darilion
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