11 Aug
2008
11 Aug
'08
10:17 p.m.
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
11 Aug
11 Aug
11:47 p.m.
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).
--
Iñaki Baz Castillo
12 Aug
12 Aug
midnight
On Mon, Aug 11, 2008 at 4:47 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
El Lunes, 11 de Agosto de 2008, Kaeman Chris
escribió:
AFAIK, the 200 OK is relayed in stateless mode, not dropped.
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).
--
Iñaki Baz Castillo
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
12:19 a.m.
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
9:55 a.m.
Iñaki Baz Castillo schrieb:
El Lunes, 11 de Agosto de 2008, Ovidiu Sas escribió:
yes.
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.
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
11:37 a.m.
El Tuesday 12 August 2008 08:55:49 Klaus Darilion escribió:
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")
...
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).
How can occur tha tif transaction has been already deleted?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
11:51 a.m.
Iñaki Baz Castillo schrieb:
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
El Tuesday 12 August 2008 08:55:49 Klaus Darilion
escribió:
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())
...
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")
non-200 ACK I guess will be absorbed by tm
(not sure about this).
How can occur tha tif transaction has been already deleted?
12:15 a.m.
Iñaki Baz Castillo wrote:
El Lunes, 11 de Agosto de 2008, Kaeman Chris
escribió:
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
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).
5949
days inactive
5950
days old
7 comments
5 participants
participants (5)
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Kaeman Chris -
Klaus Darilion -
Ovidiu Sas