[Spce-user] mediator stopped
qabane me
qabaneitsolutions at gmail.com
Wed Mar 6 07:17:34 EST 2019
Hi Andrew
Ah that explains why I don't see it in the DB.
I am not sure what to look for in the kamailio.proxy log other than that
caller id? there certainly isn't anything today and we have already purged
older ones.
I also have no idea where that long callid comes from and all seems to be
running fine otherwise. But it would be swell of course if we can actually
find what caused it.
In the meantime - aside from the cause, how do I remove it :-) ?
Regards
On Wed, Mar 6, 2019 at 1:42 PM Andrew Pogrebennyk <apogrebennyk at sipwise.com>
wrote:
> On 3/6/19 10:58 AM, qabane me wrote:
> > Hi
> >
> > Ok I have done a bit of digging as follows:
> >
> > select * from cdr WHERE call_id LIKE
> > '%$116d5af1-b6d4-1237-df83-a6958035e26f%';
> >
> > Under the assumption that I will find the offending call there and once
> > I do, get rid of it. The result is empty though so clearly I am not
> > looking in the right place?
>
> Mediator works with acc records so you don't get a CDR if there is an
> error fetching acc.
> The acc records are stored in the redis DB with index 21 in most recent
> versions. The mediator also tries to correlate the start/stop records
> from redis with those from mysql, in case the user has switched the
> engine or just updated the system. In that case, you might get some
> errors in the cdr.log which aren't actually a problem, but in your case
> my wild guess is that some system misconfiguration is causing such a
> huge call-id suffix that it leads to inaccurate SQL query when trying to
> fetch acc.
>
> Can you check the kamailio-proxy.log and/or acc records and tell us how
> in your setup, you obtained such a long call-id
> 116d5af1-b6d4-1237-df83-a6958035e26f_b2b-1_b2b-1_b2b-1_b2b-1....etc
> because there is probably a loop going on somewhere in the system, e.g.
> circular call forwarding involving several users. I am especially
> interested in the kamailio-proxy.log because in most cases we do manage
> to detect and break the loop in case of misconfiguration.
>
> BR,
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20190306/b53d669a/attachment-0001.html>
More information about the Spce-user
mailing list