We have a client that has several users that receive a busy tone when calling a number. It is never the same number, or the same user. The user can call the number more than once and get the same result, but another user can call the same number without the fast busy. The user having the issue can call another number with the same area code and it will work fine.
I usually work with commercial systems, so I thought it was an issue with the users Class of Service or dialplan for that user. I have been learning about Asterisk and Trixbox and reviewed the .conf files.
This is what I have checked.
- Dialplans.
The Zap trunk doesn’t have any dialplan assigned. That area is blank. It appears there aren’t Classes of Service in the Trixbox. If other people can dial the number and the same user can call this number on other days it appears to not be a dial plan issue. - Available trunks
I have been told that when this happens if they delete the user and reassign the user the issue is resolved. I thought maybe they just don’t have enough circuits (they have a 24 channel PRI) and they were getting the fast busy because there were enough circuits at the time. From what I have seen it doesn’t appear to be the issue, but it is impossible to monitor at all times using “Show Channels”. It doesn’t have Munin as an option in tools and the call records don’t suggest this is the issue. - NAT
All the phones are behind a NAT firebox (Cisco Pix) and the Trixbox is also behind the same firewall. I have noticed that the extensions have NAT=Yes. - Phone
I am thinking the issue might be the phone itself. They are using Grandstream phones and I am going to have the user switch with a known good phone to see if that helps. It doesn’t appear the phone has a dialplan in it. It might be a DTMF issue.
Is there an easier way to tell what the issue is. On the commercial systems (Audiocodes) I can see the dial stream on the gateway to capture exactly what the phone is dialing to rule out issues. Is there a way to capture this information? Wireshark won’t capture this.