13 Jul
2010
13 Jul
'10
5:48 a.m.
Hey,
Iñaki Baz Castillo wrote:
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...
...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
2010/7/12 Henning Westerholt
<henning.westerholt(a)1und1.de>de>:
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.
On Monday 12 July 2010, Timo Reimann wrote:
I think so. [..]
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. (2) always decrement the reference counter during BYE
response handling.
But why is this additionally necessary? 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)?