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 <mino.haluz@gmail.com> wrote:
Any updates on this? I updated callcontrol which has some bug fixed:

callcontrol (2.0.14) unstable; urgency=low

 * Avoid handling requests with a duplicated CallID

But it still does not work. The callcontrol is executed 3 times and in
the config, I have only once the mark "xxx" printed in syslog (see the
config below).
t_newtran before calling callcontrol does not work as well - it is
executed 3 times.

On Mon, Jun 13, 2011 at 4:29 PM, Mino Haluz <mino.haluz@gmail.com> wrote:
> 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
> <miconda@gmail.com> wrote:
>> Hello,
>>
>> if it is a retransmission, then just do t_newtran() in your config file
>> before handling it to call control to be sure the retransmitted requests are
>> absorbed.
>> http://kamailio.org/docs/modules/stable/modules/tm.html#t_newtran
>>
>> Cheers,
>> Daniel
>>
>> On 6/6/11 4:29 PM, Mino Haluz wrote:
>>
>> Hi,
>> my kamailio server is receiving from some customers 3 identical INVITEs when
>> call is initiated (separated by 200ms). Those 3 INVITEs are making a big
>> problem with call_control:
>> WARNING: call_control [call_control.c:1156]: dialog to trace controlled call
>> was not created. discarding callcontrol.
>> That is why, the prepaid limit is not working at all in this case. This way
>> the user can hack the prepaid protection of the account. Otherwise the
>> call_control is fuilly functional.
>> Anybody experienced the similar problem? If so, how to resolve it?
>> Thanks,
>> Mino Haluz
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- http://www.asipto.com
>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>