[sr-dev] [dialog MI dlg_end_dlg] error when terminating a dialog in state 2 (never removed from memory)

[Timo Reimann]

Hey,


Iñaki Baz Castillo wrote:
> 2010/7/12 Henning Westerholt <henning.westerholt at 1und1.de>:
>> On Monday 12 July 2010, Timo Reimann wrote:
>>> [..]
>>> However, the latter is something to be done in future dialog module. To
>>> prevent any kind of leakage in the current implementation, my proposed
>>> fix would be to
>>>
>>> (1) Deny proxy-initiated dialog termination unless the call is in the
>>>     "confirmed" state and
>>
>> so if understand correctly this should fix the leak that was reported, as the
>> refcnt should be then not increased prior it comes to this invalid internal
>> state.
> 
> I think so.

Right -- this part of the fix makes sure that BYE requests are not even
sent in the first place for calls that have not reached the confirmed
state yet. Otherwise, it would inevitably lead to 481 responses and UAs
not terminating because of missing tags.


>>> (2) always decrement the reference counter during BYE response handling.
>> But why is this additionally necessary?
> 
> AFAIU ("U" = understand X-D) he means that after the proxy generates
> the BYE it should inmediately decrease the reference counter without
> waiting for the response.

That's what I had in mind. It should guarantee that dialogs are not
dangling and leaking no matter how the UAs reply and how that affects
dialog state.

However...


>> Does this apply to the handling of all BYEs?
> 
> Good question. Let me ask another question (the same in other words):
> 
> When a BYE is received in Kamailio, is the dialog terminated when the
> BYE is processed? or when the BYE receives a 2XX? what about if the
> BYE receives a [3456]XX response (or no response at all)?

...your question made me take a look at the code again. For UA-initiated
BYE requests the dialog is terminated (as in state) and destroyed (as in
cleanup) once the BYE has been sent. For proxy-initiated BYE requests
the dialog is terminated and destroyed once the final response to the
BYE request is received, or when no response at all is received (because
bye_reply_cb() is a callback to TMCB_LOCAL_COMPLETED which triggers for
both UA and timeout-generated 408 final responses). Analogously,
callbacks to DLGCB_TERMINATED are executed at respective times depending
on the use case.

That means that destroying dialogs terminated by proxy-initiated BYE
requests right after such requests have been sent cannot work that
easily. One would have to move dialog destruction and callback execution
into that part of the code where the BYE request is sent. The
alternative is to keep the code where it is right now (bye_reply_cb()).

I'm not sure why dialog termination points in time differ for
UA-/proxy-initiated BYE requests. Is there a rationale that proxies
triggering dialog termination need to ensure that UAs respond or
time-out before they can destroy the dialog? How does it differ from
UA-initiated dialog terminations?

Maybe you have an idea on this; I will continue thinking about it. In
any case, the "always decrement counter during BYE processing" isn't
strictly required for the designated fix if the "deny proxy-initiated
call termination for non-confirmed calls" rule is in effect. That's
because confirmed dialogs should always transition to the terminated
state on processing of the BYE request and thereby decrement the counter.

Too much thinking about dialog today. I need a break. :)


Cheers,

--Timo