23 Jun
2010
23 Jun
'10
9:37 a.m.
On Wed, Jun 23, 2010 at 9:25 AM, Timo Reimann <timo.reimann(a)1und1.de> wrote:
Hi,
Ovidiu Sas wrote:
Yes, the latter approach seems to be the right one.
Regards,
Ovidiu Sas
On Tue, Jun 22, 2010 at 12:27 PM, Timo Reimann
<timo.reimann(a)1und1.de> wrote:
I've been wondering how to achieve this.
AFAICS, the current implementation removes dialog entries right after
the moment the final request/response pair was seen. In order to prolong
a dying dialog's lifetime, I see two possibilities: Use some
time-triggered function that delays dialog deletion for a short period
of time; or, couple dialog deletion to the deletion of the final
transaction, i.e., the one were dialog state transitions to
DLG_STATE_DELETED. Personally, I prefer the latter approach since it
would quite elegantly re-use the transaction layer's timer. 2.) Various race conditions may generate log
messages such as following
when DID mode is enabled:
WARNING:dialog:dlg_onroute: unable to find dialog for <REQUEST TYPE>
with route param 'faf.f69e7b4' [4015:79161711]
Observed REQUEST TYPEs at our site were "BYE" when BYE requests were
transmitted by both caller and callee at roughly the same time due to
user behavior; and "PRACK" when a PRACK was received by the UAS after a
486 (Busy Here)/ACK pair of messages was already exchanged between the
UAS and the proxy. In both cases, the associated dialog had already been
destroyed when another request was received.
My suggestion is to lower the log level for this kind of message because
it can simply happen too often but doesn't affect proper dialog handling.
The proper fix here would be to extend the lifetime of a dialog in
deleted state and absorb any late in-dialog requests.
If we just lower the log level, we don't know if it's a valid warning
log or a bogus one.