Call redirected to an external number

Greetings,

I’ve got an IVR, with different queues. The thing is that for some customers, when they are in the queues, instead of having some agents of the queues, they are redirected to an external number (04499) which is a real external number. And so customers, instead of having someone from my company, have a call with someone else.

Here below the link where you will be able to download the Call Event log:

www . filedropper . com / cel

As you will see at ligne 56 i’ve got the line

BRIDGE_END
40866061
40866061
40866061

DEFAULT
4499
from-internal-xfer
Dial
Local/614@from-queue-00007727;2

The thing is: i don’t have any 4499 extension configured anywhere, so i’d like to know why some customers in queues are redirected to this extension which i don’t know

Let me know if you need more information.

Regards,

Call Event Logging is too complicated and your link is incomplete, just post the regular log of a failed call, only in exceptional circumstances would 04499 ever be a “real” external number, and if so only in your particular deployment, please explain why you think it is.

Hi Dicko,

0 is the number used to call outside, and 4499 is a real number in my country: it is the number to reach telephone directory information. And i know the customer is redirected to this number, as guys from the telephone information called us, saying that they had some people who composed our number, and instead of having us (4410), they have them (4499), which is confirmed when i see CDR logs like below:

Call Date Recording System CallerID Outbound CallerID DID App Destination Disposition Duration
2015-01-07 09:58:40 1420660710.9746187206555 <87206555> Dial 04499 ANSWERED 00:21
2015-01-07 09:58:30 1420660710.97461 "87206555 "<87206555> Dial 604 ANSWERED 00:10
2015-01-07 09:58:30 1420660710.97471 "87206555 "<87206555> Dial 614 NO ANSWER 00:05
2015-01-07 09:58:30 1420660710.97465 "87206555 "<87206555> Dial 607 NO ANSWER 00:05
2015-01-07 09:58:30 1420660710.97467 "87206555 "<87206555> Dial 611 NO ANSWER 00:05
2015-01-07 09:58:00 1420660680.97459 "87206555 "<87206555> 4410 Queue 692 ANSWERED 01:01
2015-01-07 09:57:23 1420660643.97442 "87206555 "<87206555> Dial 604 ANSWERED 00:24
2015-01-07 09:57:23 1420660643.97452 "87206555 "<87206555> Dial 614 NO ANSWER 00:06
2015-01-07 09:57:23 1420660643.97446 "87206555 "<87206555> Dial 607 NO ANSWER 00:06
2015-01-07 09:57:23 1420660643.97448 "87206555 "<87206555> Dial 611 NO ANSWER 00:06

But the thing is: i don’t see any 04499 in any extensions files, nor queues conf files either.

Between

grep 4499 /etc/asterisk/*

rasterisk -x ‘database show’|grep 4499

will identify any endpoint that recognizes that number or a variation , , ,

Thre is nothing in your posted log that substantiates what you say.

Again, post a log of a failed call and not the derivative cdr/cel records

This one shows that 04499 has been dialed, is that correct ?

Call Date Recording System CallerID Outbound CallerID DID App Destination Disposition Duration
2015-01-07 09:58:40 1420660710.9746187206555 <87206555> Dial 04499 ANSWERED 00:21

For a failed call, how do i do that ? this redirection happened randomly, so if i have to get the trace online, it would be difficult. Can you provide me a wayt to perform a trace of the call log ?

In a standard installation all your stuff will be in /var/log/asterisk/full

Ok i’ve activated full debug and full verbose, i’ll come back with trace as soon as i’ve got it (debug and verbose was set to 0 before).

thanks Dicko !! :slight_smile:

Alright here below the whole call detailed, from what i’ve seen it seems that there is a moment where the server will redirect the call to the extension 04499, and i don’t know where it take this value, as it’s nowhere in files (i’ve performed the grep search you provided to me in your answer before).

Please find below the text file with the detail of the call (as i can’t post links on this message, i’ve put a space between each word and character, please remove all space to get the full link).

www . filedropper . com / call

Sorry, but your mangled URL is incomplete.

edit

perhaps not so I found your log :slight_smile: , but I don’t think anybody will have the patience to go through all that, (I know I don’t) set debug to 0 and verbosity to 3 to start with, the logs would then be easier for us to consume.

( you can set those levels in /etc/asterisk/asterisk.conf if you RTFM, how did you install your system?)

Ok i will set up debug 0 and verbosity to 3 to start.

My system is a freepbx distro i’ve installed through DVD install.

I’ve changed debug and verbosity settings.

As soon as i’ve got a trace, i’ll send it here.

Thanks !!

Ok finally i’ve got it:

www . filedropper . com / call2

So:

Caller 87xxxx is calling 4410
-> He will get an IVR
-> After selection he will be in queue 695, where there are several static agents (606,607,611,614)

-> After no answer from anyone in the queue, at 14:38:54, here starting to appears the 04499

[2015-01-09 14:38:54] VERBOSE[29163] pbx.c: – Executing [04499@from-internal:1] Macro(“SIP/611-000070e6”, “user-callerid,LIMIT”) in new stack

And as i’ve said before, composing 04499 from my platform will send you to the telephone information of another company, as 4499 is a real number (and 0 is the number to compose to call outside).

i really hope you can help me in this case, thanks !!!

probably becuse of :-

[2015-01-09 14:38:54] WARNING[2078] sig_pri.c: PRI Error on span 2: Received MDL/TEI managemement message, but configured for mode other than PTMP!

(Did you notice the ERROR strings later ?)

PTMP means “Point to Multipoint” in ISDN speak, you need to setup dahdi signalling to match your carrier’s abilities.

Ok i’ve re-installed the system, don’t have the warning PTMP error, nor the ERROR strings, however the bug is still there.

I really don’t understand why the system would transfer to this 04499 destination which has never been set up. I think i will go back to my trixbox system where this issue wasn’t there.

Thanks anyway for your support.

It’s not a bug, it’s because you are trying to use improperly configure your channel drivers.

Good luck with trickybox, it is long gone, prone to attack, unsupported and broken.

Good luck though, you are now on your own :slight_smile: