It does not work, t_newtran always returns success, so it will never absorb the retransmission. So what I did was: if ($sht(a=>$ci::retrans) == 0) { $sht(a=>$ci::retrans) = 1; } else { exit(); } xlog("L_INFO","XLOG: xxx"); call_control(); I prepared sipp scenario which generates 3 INVITEs separated by 200ms. It will gives me this: Jun 13 16:07:04 no-testing /sbin/kamailio[5274]: INFO: <script>: XLOG: xxx Jun 13 16:07:04 no-testing /sbin/kamailio[5273]: WARNING: call_control [call_control.c:1156]: dialog to trace controlled call was not created. discarding callcontrol. Jun 13 16:07:04 no-testing /sbin/kamailio[5275]: WARNING: call_control [call_control.c:1156]: dialog to trace controlled call was not created. discarding callcontrol. So, the first INVITE was processed by call_control, another 2 were not. But WHAT executed those two call_control is some kind of miracle for me ... Callcontrol module is somehow executed at the beginning of the config file where the values are set or why? This is what I always set at the beginning: modparam("dialog", "dlg_flag", 4) modparam("call_control", "diverter_avp_id", 256) #used to set billing party. default is From uri modparam("call_control", "canonical_uri_avp", "$avp(s:can_uri)") On Mon, Jun 6, 2011 at 10:16 PM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote:

Hi, I finally resolved this issue. The problem is in the callcontrol module. The original code: static int postprocess_request(struct sip_msg *msg, unsigned int flags, void *_param) { CallInfo *call; if ((msg->msg_flags & FL_USE_CALL_CONTROL) == 0) return 1; // the FL_USE_CALL_CONTROL flag is still set => the dialog was not created LOG(L_WARN, "dialog to trace controlled call was not created. discarding callcontrol."); call = get_call_info(msg, CAStop); if (!call) { LOG(L_ERR, "can't retrieve call info\n"); return -1; } call_control_stop(msg, call->callid); return 1; } When I was debugging the whole thing, I found out, that this postprocess routine of the callcontrol module is called EVERYTIME the processing of the main route block of kamailio is being ended. Why? I do not understand, this must be considered as a bug. When those 3 INVITEs come, the first is processed, but it still has FL_USE_CALL_CONTROL flag. Another 2 INVITEs are absorbed by kamailio. As I said, the postprocess_request block is executed each time the main route block ends. So, it will enter this function, check the FL_USE_CALL_CONTROL flag. And here comes a strange thing, why the flag FL_USE_CALL_CONTROL is shared accross the same INVITEs? I thought every instance of the module which processes every message should have independent variables. But it seems that this flag is shared, that's why it executes call_control_stop and sends to the callcontrol socket the command of discarding the callcontrol feature (the call is not charged) I patched the module by adding extra parameter - actually name of the AVP variable. This variable is set in the main route block when the first INVITE is processed and the call is initiated. Then it is checked in the routing - if the call has initiated bit set, do not discard the callcontrol. If someone is experiencing the similar problem, I can send the patch. Second simpler approach is to removing this line call_control_stop(msg, call->callid); The question is, will the dialog expire in the callcontrol daemon? Is there any timeout? If so, it can be clearly fixed by this way ;) Hope this helps to somebody, Cheers On Mon, Aug 15, 2011 at 9:59 AM, Mino Haluz &lt;mino.haluz(a)gmail.com&gt; wrote: