I notice a change in the latset batch of updates regarding call limits for asterisk 1.4 but it still does not fix the problem with phones going to extenstion state 16 and staying busy.
If the sip.conf is edited and notifyhold is set to NO from the default of yes, then the problem goes away. The thing is that it gets set back to yes every time freepbx makes an update. Is this setting adjustable in freepbx anywhere?
I know this problem has been difficult to track down, but on a system with asterisk 1.4, with phones set with call waiting disabled and notifyhold set to yes, I can constantly set a phone to state 16 (which it seems, should not be possible) by transfering a call. The full procedure is
101 calls 102
102 transfers to 103 and hangs up
103 answers
101 and 103 hang up
101 calls 102
101 calls 102 again, it’s now busy.
the issue of editing sip.conf is that you should never edit sip.conf, that is why there are all the other include files, when you need to make customizations that are not standard.
The issue of notifyhold is more related to the fact that information is scattered all over the place wrt to the 1.4 testing and what is needed to get the state information working properly, compounded by the fact that the Asterisk code continues to be buggy so it is not clear what is a setting issue and what is an asterisk bug.
What we need is someone who has a vested interest in getting 1.4 working properly for this to provide a consolidated set of requirements (either here in the forum or in a new ticket) that indicates what each setting you feel needs to be set for 1.4 and why it needs to be set. Then we will be glad to work on those changes.
(hint hint - feel free for that person to be you if you want)
and while you are at it. I seem to recall that notifyhold was explicitly added for 1.4. So now you are saying it should be changed to no? Can we get some discussion going on this - are you changing it to get around an Asterisk bug or otherwise, what is the right setting and reasoning?
I’ve just had a look at the ‘live’ system that the call_limit problem originally occurred on, and that has had the following settings in sip.conf for the last couple of weeks & no sign of problems:
[code:1]; Reported as required for Asterisk 1.4
notifyringing=yes
notifyhold=no
limitonpeers=yes
;jbenable = yes
;jbforce=yes
[/code:1]
I remember seeing somewhere that notifyhold was part of the problem, with call_limit being the other part…
Also, there was a note saying the jitterbuffer parameters were not a good idea, so I commented them out.
I did see the ‘hold’ problem at 1.4.8 but since upgrading to 1.4.9 I have not seen the problem using the default (freePBX) settings in sip.conf.
I do however have a problem where if power is cut to an extension mid-call then Asterisk never terminates it and the extension is permanently ‘InUse’ – I suspect I am supposed to set a call time limit or something to handle that but you’d have thought Asterisk could handle it better somehow.
[quote=“w5waf”]Wonder how to tell if the setting “took”? From thr asterisk CLI?
Bill[/quote]
Maybe we should take this to the Asterisk forums - but to be honest, I’ve never really had much of a response from them - probably the stupid dumb a**e questions I ask…
As far as I can tell, there is NO difference in performance in the notifyonhold setting. I’ve put in sip.conf and sip_additional.conf. YES or NO has no effect.
I can consistantly cause an extension to go to state 16 by using the transfer button on the GXP-2000. Asterisk transfers “*2” and “##” seem to leave the extension in the proper configuration.
Oh yes…turning call waiting on in the extension mitigates the problem.
well where that leaves us is that I am going to wait until a decision is settled on as to what is needed. When I see agreement followed by a well articulated recommendation that everyone seems to agree with - I will be very happy to put it in. You guys may want to ping the Elastix guys on this also since they are leading with 1.4.
As far as sip.conf being reset, yes every time you press the red bar. The best thing is to try to get these in once of the includes. If that won’t work for you (meaning you should report a bug of the need for another include spot) then you can change sip.conf from a link to a real file. It will not do the symbolic link if the file is there. Just remember to put it back for future updates.
As far as seeing what the settings are, ‘help sip’ at the CLI. ‘sip show settings’ might be useful. Or for a specific extension’s settings 'sip show peer ’ or sip show user helps.
Thanks for working this one out and we’ll be happy to get it in. It just seems to be a bit clouded from Asterisk problems, oh well, so is life.
I don’t have any GrandStreams but I will try tomorrow to recreate the issue - I tend to use ## all the time as I have such a menagerie of phones - I don’t use transfer as designated by the phone because I’m not really sure what it is doing… I suppose I could watch the SIP messages but life is too short (I’m told).
Is that the main difference? Instead of Asterisk handling the transfer via ## it is handling from SIP messages from the phone?
Unless anyone has suggestions here I guess the Asterisk forum/support is a logical option?
I’m still fairly new to all this and it’s still a hobby as opposed to anything I’m forced to do - there are far better guys and gals here I suspect that have a better idea than I…
if you ask on the Asterisk forum, IRC or other medians, don’t mention FreePBX - they tend to shy away because they don’t understand it. (Which usually degrades into “real men use CLI so get lost …”)
[quote=“w5waf”]Wonder how to tell if the setting “took”? From thr asterisk CLI?
Bill[/quote]
I tried this today and made a number test calls using the transfer option on my SPA962 and recreated the problem in about 1 in 8. I could however reproduce it every time by simply calling an extension, placing that extension on hold then hang up the calling extension!
Having the call limit did seem to allow the extension to be called after though, even though it has a Hold status.
I did verify that adding notifyhold=no to sip_custom.conf prevents this behaviour/hold reporting. To check this, enable notifyhold, simply place the extension on hold and you will see the status as Hold in ‘core show hints’.
Change the option to notifyhold=no in sip_custom.conf and the status is not reflected in ‘core show hints’ so we would deduce that the override at least works.
notifyhold=no both times? - can you go back and edit your port to be clear which one is yes (or it’s just too early for me…) to help drive this to a resolution. Thanks.
I 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.
so how about a consolidated summary of what appears to work. And as part of that summary (where you specify all your conf file settings), a digest description of the bug/patch - if it is suppose to hit a real asterisk release or what. As suspected, this whole things sounds like Asterisk is still broken and we need to know this to know when Asteirsk will be fixed
