[SR-Users] dialog module: in-early-dialog requests / race conditions

[Ovidiu Sas]

On Wed, Jun 23, 2010 at 9:25 AM, Timo Reimann <timo.reimann at 1und1.de> wrote:
> Hi,
>
>
> Ovidiu Sas wrote:
>> On Tue, Jun 22, 2010 at 12:27 PM, Timo Reimann <timo.reimann at 1und1.de> wrote:
>>> 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.
>
> 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.

Yes, the latter approach seems to be the right one.


Regards,
Ovidiu Sas