Ok,
I updated the code in the server. I'm testing the changes on Tuesday and I'll send feedback to the list.
We found dialog module very useful because of the information and functionality it provides. For example, we are using its exported function dlg_end_dlg to cleanly end all the active calls when stopping Kamailio is required for maintenance reasons. We are also using the dlg_bridge function to implement click-to-dial applications and it works fine.
On the other hand, in the logs of the server we detected the unreference problem, we got the logs showed below quite often. I don 't know if it can be related to the unreference problem. Since it has
a CRITICAL log level I'm not sure if this is so because it can mean a real problem or Kamailio can safety deal with it:
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: CRITICAL: dialog [dlg_hash.c:615]: bogus event 5 in state 4 for dlg 0x7f2d0a3d30e0 [306:1818049706] with clid '92515995-3508071667-342415@usmiap1etx02.mydomain.com' and tags '3508071667-342428' '7A242CC-0'
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:770]: dialog 0x7f2d0a3d30e0 changed from state 4 to state 4, due event 5
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=4077 , global msg id=4076 , T on entrance=(nil)
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=356, isACK=0
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:470]: DEBUG: RFC3261 transaction matched, tid=3178c7ec929daf0e4ade2b303de82a20
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_lookup.c:728]: DEBUG: t_lookup_request: transaction found (T=0x7f2d0a82bca0)
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: tm [t_reply.c:1430]: DEBUG: reply retransmitted. buf=0x7f2d2eff4160: SIP/2.0 5..., shmem=0x7f2d0a72cb90: SIP/2.0 5
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: dialog [dlg_hash.c:599]: unref dlg 0x7f2d0a3d30e0 with 1 -> 3
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil)
Mar 2 17:21:30 kamailio2 /usr/local/sbin/kamailio[32153]: DEBUG: <core> [usr_avp.c:646]:
From dlg_hash.h
...
DLG_STATE_CONFIRMED 4 /*!< confirmed dialog */
...
DLG_EVENT_REQPRACK 5 /*!< PRACK request */
...
I understand it means we are receiving a PRACK
in a confirmed dialog (ACK received), doesn't it? I guess it can be due either to an error of the SIP stack of the caller side or this PRACK is a rtx due to networking issues (not probable, I think).
Thanks a lot,
regards
Antón
2011/3/4 Daniel-Constantin Mierla
<miconda@gmail.com>
Hello,
On 3/3/11 10:19 AM, Anton Roman wrote:
Hello,
thanks for your quick reply, my answer is inline.
2011/3/2 Daniel-Constantin Mierla
<miconda@gmail.com>
Hello,
looks like related to the callbacks for dialog module. Are
you loading other modules that require dialog module?
we are using some features of dialog module such as
ending dialogs after a timeout period, and we are using
engage_mediaproxy() function, as well. It's an old
configuration we had to put in production with no time
enough to test. Do you recommend not to use dialog module if
not strictly required?
usage of dialog module was always safe and working great for me. But
I use it mostly alone, never with mediaproxy module, just with
pua_dialoginfo module in some cases. From the logs, the crash was
related to the callback system exported by dialog module for the
other modules willing to hook into dialog, it is why I asked about
the other modules to be sure there is at list one binding to dialog.
So, like with other modules, if there is a problem discovered there,
it is important that we fix it - this is a module used a lot by
many. Therefore usage is encouraged when needed :-)
Cheers,
Daniel