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


-- 
Daniel-Constantin Mierla
http://www.asipto.com