Hello there, My name is Bryan. We’ve been having an issue dialing out internationally. Our system is set up to use the number 8- then a TN number to properly dial out for long distance calls [IE, to call a US number in New York, it would be 81(for U.S.)-845-XXX-XXXX.] Whenever this is done for any international number [IE 8-011-971-2-550-8607 (UAE McDonalds TN number)] it goes busy, or states ‘the number is not answering’ stopping at the 6th digit of the outbound number.
I found the CDR records here, but no proper IDs. Looking at the live feed [ tail-f /var/log/asterisk/full] Shows the call out right not fully dialing out. It gets stuck at the 6th digit or (when dialing with 81 instead of just 8) goes up to the 10th digit. It appears to fail when hitting the Adtran 908 and says busy when going to the outbound line. I’ll attach an image of the 2 trunks with my next responce
As the wiki states, please grab a full trace from the full logfile, so we can see whats wrong. A picture from the CDR doesn’t really provide helpful information.
That screenshot doesn’t expand for me at least so is unreadable. Assuming your outbound route is correctly configured to be sending out all the digits and removing the dialing prefix you use, I would look at the Adtran logs.
The system gets to 01197, then just stops dialing with the error ‘your call can’t be completed as dialed’. I’m looking into where to find the full logs. This system wasn’t set up by me and I’m not the most experienced with it.
[my apologies for the odd formatting, this is the best I could do in a short time]
If you need to read this more clearly, I suggest opening it in a new tab.
Listed here is the trunk, I feel that it’s not reaching the trunk proper due to some issue with the dialing path. I’m aware that 8 is our normal prefix to dial out.
I suspect that your IP phone has a dialplan that is interfering with sending the complete number. With some phones, you can work around this by keying the number while still on hook, then lifting the handset. Please post details about make/model/version.
The phone is a Cisco IP 7941 IP phone. The thing is ancient, as is most of the equipment in the building. [Due to the pandemic and the system’s odd nature, an upgrade just isn’t in our budget currently, as we’d have to replace literally everything in the building to upgrade the equipment to something more current]. I tried to dial out with the line active, same issue, goes out to 6 digits (801197) and stops and refuses to go past it.
The 79xx series get their dialplan from an XML file that you could easily edit.
However, the existing dialplan may well accept the number starting with 011. Try that; the call will fail but see whether the phone shows the complete number.
If it does, add a line to your Outbound Route with
prepend: (blank)
prefix: (blank)
match pattern: 011XXXXXX.
and test. If the call fails, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.
This does look like a phone dialplan issue - I haven’t worked with cisco phones in a long time - but there probably is a way to get the current phone dialplan - do you know if it is downloading config files from your PBX? Look for dialplan.xml as googling around indicates that is the likely name of the config file for that.
To be quite blunt, I don’t think the previous person set that up. If any phone loses it’s config for any reason (factory reset, memory fail, etc). The phone flat out can’t pull firmware or data from anything, it’s odd…
Line 623: Executing [801197@ILT_Staff:1] Goto("SIP/3178-00000c8c", "ILT_Staff_rulematch,801197,1") in new stack
The phone sent a partial number. You need to fix that before FreePBX can do anything with it.
Did you find an XML file containing the phone’s dialplan? If so, post it here.
I know very little about Cisco phones so this is just general information:
IP phones require a considerable amount of configuration data, for example their extension number, password, IP address of the PBX and so on. This includes a “dial plan”, which defines what strings of digits are accepted and when a number is complete and sent to the PBX.
In some devices, configuration can be done with a built-in server, but with complex phones such as Cisco this is limited or nonexistent. You could try to connect to a phone from a browser and see whether what you are trying to change is there. Even if it is, changes may not ‘stick’ because the data is being overridden by the PBX.
Normally, the phone ‘pulls’ configuration files from a server, usually the same machine as the PBX, each time the phone boots and when the server requests it. These files can be created manually (with a text editor) or with an Endpoint Manager. If your Elastix has an endpoint manager module installed, you can see whether it is provisioning your phones. If so, you should be able to view and change the dial plan there.
If not, you can see whether your phones are getting config files from the PBX. If using TFTP, you’ll see entries in /var/log/messages when a phone reboots. If not, tcpdump should show some other traffic (FTP, HTTP, HTTPS) when a phone reboots. Once you see what files are being read, you can look at them and see what needs to be changed.
It’s possible that these phones were provisioned a long time ago and the means used is now defunct. If a phone is unable to pull config info, most will come up with whatever config they last had.
Let us know what you find and we’ll take it from there.
