[SR-Users] Multiple INVITEs and discarded call_control

[Mino Haluz]

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 at 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 at 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 at 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 at 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111007/dfd653f8/attachment-0001.htm>