The following is a call progress on a 1.4.6 system. Please note that it shows the handset as state 16 (busy) when it is not. Rebooting the server or restarting asterisk [restart now] solves the problem. I have seen similar posts where others are having the same problem, but no solutions. I apologize for reposting, but no solutions were offered to the other members, and our business is crippled until this problem is fixed. I am hoping that reposting might reach some members who may have missed this support request previously.
The easy way to create this error is to simulate an incoming call by dialing 7777, answering at an extension (in this example 406), transferring the call to another extension (in this case 310), then terminating the call. Any succeeding calls from internal or external will find extension 406 as busy, when it is not.
dialparties.agi: priority is 1
dialparties.agi: Caller ID name is 'Kyle PC' number is '407'
dialparties.agi: Methodology of ring is 'ringall'
-- dialparties.agi: Added extension 310 to extension map
-- dialparties.agi: Added extension 406 to extension map
-- dialparties.agi: Extension 310 cf is disabled
-- dialparties.agi: Extension 406 cf is disabled
-- dialparties.agi: Extension 310 do not disturb is disabled
-- dialparties.agi: Extension 406 do not disturb is disabled
dialparties.agi: Extension 310 has ExtensionState: 0
-- dialparties.agi: Checking CW and CFB status for extension 310
-- dialparties.agi: dbset CALLTRACE/310 to 407
dialparties.agi: Extension 406 has ExtensionState: 16
-- dialparties.agi: Checking CW and CFB status for extension 406
dialparties.agi: Extension 406 is not available to be called
dialparties.agi: Extension 406 has call waiting disabled
All of our handsets are Grandstream GXP-2000 with the latest firmware. Please also note that the ExtensionState: 16 is not valid from what I have read.
Have a look at dialparties.agi you will see a section that looks to check its not 4 you may be able to duplicate this bit to also check if its 16 and ignore it.
I’ve had a look at that file to resolve this as I’m also experiencing the same problem.
The more I looked at the code, the more I couldnt help feeling that a change to ignore state16 would be a bad thing. It has to be more effective to find why the phones are being left in an invalid state and fix that, as until that happens how can the real state of the phone be discovered?
It’s set up as the all in one method, which is default I think. Can you elaborate on the changed you made to get a resolution on this so I can try your steps and see if they work for me?
Please forgive my ignorance, but I don’t know the difference as I am new to Asterisk. I am using an Elastix/freePBX/Asterisk package if that answers your question. Alternatively, if you could tell me how to figure out the answer to your question, I’d be happy to check.
Hmm OK I gather you haven’t found that bit yet. I did the same also. In /etc/amportal.conf you can change the mode that Freepbx runs in and choose deviceandusers about half way down in the file. In this mode devices ( the handsets themselves ) are configured independently to users ( the extensions ) which allows you to have handsets you can walk up to and login to using *11 and the phone becomes you’re extension.
The reason I asked which mode, was when I first used this mode and users were not logged in at all, the system would not send calls to Voicemail, and would just be denied.
For the peer call-limit part, in sip_additional.conf in /etc/asterisk you will find all of your configured extensions, and I have had to add call-limit=x. Digium support say that this has been fixed, but seeing as my system is live I can’t be playing with it too much to check this has been resolved.
I have a test box with Elastix, and will upgrade to * 1.4.9, and try it out as sooon as I can.
This is a known issue in Elastix. We just faced this. This happens if the call waiting is deactivated. If we activate call waiting for that particular extension, you will be able to receive the calls.This is happening cos when the extension is being deactivated, the DBDel command is not working for some reason.
This is a real issue and its a major problem, I know it’s not affecting everyone but it is affecting many, can we please have some escallation on this?
If this is an issue, then users need to decide where the problem lies, IE is it with the freepbx code or is it with asterisk. then raise a bug report with the relevent project.
Asking for “escallation” here will not serve any real purpose, You need to document the problem in full and then raise it as a bug with whoever.
That’s a very fair point. It raises an interesting issue too, while I think the source of the problem lies in the Asterisk code, I dont know this for a fact and I also dont know how to go about proving it.
If someone is running Asterisk with a handcoded dialplan or using Asterisk Now and has this issue, then I guess that rules out the freepbx codebase. Until someone comes forward with that setup though, I’ll try to find a way to isolate the issue. Cheers
A tip found on a different forum for a related issue suggested setting notifyhold=no in the /etc/asterisk/sip.conf
I’ve done this and the problem goes away, handsets show as extension state 0 after the transfer instead of 16.
I’m pretty sure that freepbx was responsible for setting that value to yes in the first place, but it’s likely asterisk that’s handling the setting wrong?
That’s interesting, Dirk. It leads me to two questions.
First, is there a way to set that in freePBX? I have found that if I modify the .conf files manually, freePBX will overwrite them the next time I do practically anything to the system.
Second, have you found any drawbacks or loss of other functions by setting notifyhold=no? In other words, what functionality does notifyhold=yes turn on, that we lose by changing it to no?
I’ve not done much testing but below is a link to the forum post I got the answer from, that’s the best way as I didnt exactly work this out on my own.
am running a 1.4.9 box and had exactly the same problems described. from my extension I dialled 401 earlier then transferred to 403 then transferred to 406. The hints were all showing normal at this time but as soon as 406 was hung up, both 401 and 403 went to ‘hold’ and trying to call them resulted in an extension state 16.
The notifywaiting=no did cure this problem but this then created another one. Even though call waiting was disabled, when a call came in the caller received a ringing tone and the called party received a tone in their ear and their line two would start to flash.
Anyway, I earlier applied the patch below to my chan_sip.c file, recompiled asterisk did a make install, followed by an amportal restart.
My notifyonhold is now back to yes, the hints are working perfectly and our extensions are now ringing as busy when they are. Everything is working just the way we want it and my nightmare ends!
The file is available for download from here http://bugs.digium.com/file_download.php?file_id=14972&type=bug but for some reason, at least in my browser it insists on downloading the file as a php file. It is actually the diff file though. Hope this helps.
