9 Jul
2010
9 Jul
'10
10:42 a.m.
2010/7/9 Timo Reimann <timo.reimann(a)1und1.de>de>:
Hey Iñaki,
Iñaki Baz Castillo wrote:
Hi Timo, thanks for your response. Unfortunatelly that is not what I
get in my tests. If now I repeat the step 5 of my first mail I sitll
see such dialog (state 5) with timeout 0 and timestart 0, but it still
appears when retrieving the dialog list via MI. So IMHO such
information is obviously leaking (note that dialog module expiration
value is 60 seconds in case).
Could you please perform the same experiment I've done in my first
mail? I can reproduce it 100% of times.
2010/7/9 Iñaki Baz Castillo
<ibc(a)aliax.net>et>:
I don't think that it leaks. Please have a look at the
get_expired_dlgs(unsigned int time) function in dlg_timer.c: The loop
condition to get all expired dialogs is
while( tl!=end && tl->timeout <= time) {
^^^^^^^^^^^^^^^^^^^
[...]
}
The unit of "time" is ticks, so the while-loop picks those dialogs for
cleanup whose timeout value is lower or equal the current number of
ticks. Certainly, this is true for a timeout of zero. However the current code could leak.
And IMHO it leaks!. The reason is that after the CANCEL the dialog
information remains as follows:
dialog:: hash=3132:647756461
state:: 5
timestart:: 0
timeout:: 0
callid:: knfmgpcorrteiia@ibc-torre
from_uri:: sip:test_ibc@somedomain.org
from_tag:: vicxp
caller_contact:: sip:test_ibc@X.X.X.X
caller_cseq:: 326
caller_route_set::
caller_bind_addr:: udp:X.X.X.X:5060
to_uri:: sip:XXXXXX@somedomain.org
to_tag::
callee_contact::
callee_cseq::
callee_route_set::
callee_bind_addr::
This is, there is no timestart neither timeout values, so even if the
expiration time for dialgo module is set to 60 seconds, the dialog
remains in memory forever! Nevertheless, I think the current dialog module should
be hotfixed such
that dlg_end_dlg doesn't end dialogs in the "early" state simply because
it's not capable of doing so. The upcoming, refurbished dialog module
should do better though.
Great :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>