Re: [SR-Users] Multiple INVITEs and discarded call_control
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 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 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:
Re: [SR-Users] Multiple INVITEs and discarded call_control
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 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:
Re: [SR-Users] Multiple INVITEs and discarded call_control
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:
Re: [SR-Users] Multiple INVITEs and discarded call_control
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 ___ 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
[SR-Users] Multiple INVITEs and discarded call_control
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
