Just wondering if there is any update to when we can expect delivery of 14HA? I will shortly be going live with my project so ideally I’d like to do the conversion from standalone to cluster process before putting this box into production in case there are any issues and I can roll back.
Thanks,
Fraser
dial=SIP/215
SIP only supports single registration. You should use PJSIP for multiple endpoints to a single extension number.
It’s OK but I have a 5 extensions (215,216,217,218,219) on same phone.
Firstly, I know the log messages are warnings and if they’re not causing call issues can safely be ignored… however…
I have one 6 SIP trunks, 5 have negligible traffic, 1 is used for most inbound and all outbound calls.
FreePBX 14.0.3.13 running on Asterisk 15.5.0. The system is hosted on a VMware ESXi installation - the VM guest is configured with high latency sensitivity, a dedicated 4GB RAM and 2 CPU cores dedicated (3.06Ghz each). All resources reserved. The VM is hosted on a PCIe SSD storage device (although using VMDKs) with high share percentage configured.
There are 9 queues configured - although they don’t all receive callers at the same time. Six of the queues are used as a day/night endpoint for three parts of the company. Each of these 6 queues has one static agent configured for it - this static agent is another queue set to not answer which “fixes” the MoH from the first queue. These 3 queues then have, at most, 8 extensions as static agents.
When I make an external call into the system, I am receiving log messages like these:-
[2018-08-13 11:14:11] WARNING[13147][C-00000046] taskprocessor.c: The ‘subm:ast_channel_topic_all-cached-0000007b’ task processor queue reached 500 scheduled tasks again.
[2018-08-13 11:14:11] WARNING[13147][C-00000046] taskprocessor.c: The ‘subm:ast_channel_topic_all-00000084’ task processor queue reached 500 scheduled tasks again.
[2018-08-13 11:14:11] WARNING[13147][C-00000046] taskprocessor.c: The ‘subm:ast_channel_topic_all-0000007e’ task processor queue reached 500 scheduled tasks again.
[2018-08-13 11:18:33] WARNING[14229][C-00000047] taskprocessor.c: The ‘subm:ast_channel_topic_all-cached-0000007b’ task processor queue reached 500 scheduled tasks again.
The taskprocessor reports:-
subm:ast_channel_topic_all-0000007e 120935 0 586 450 500
subm:ast_channel_topic_all-00000084 120934 0 610 450 500
subm:ast_channel_topic_all-cached-0000007b 159626 0 764 450 500
subm:ast_channel_topic_all-cached-0000007c 159625 0 1058 450 500
subm:ast_channel_topic_all-cached-0000007d 159624 0 789 450 500
subm:manager_topic-00000007 233451 0 5162 2700 3000
I think I’d be less concerned if I could figure-out what the ast_channel_topic taskprocessor is being utilised for. The system only has 19 devices attached to it (using PJSIP) and 6 trunks (using CHANSIP). We hit a maximum of four simultaneous calls via the queues - and yet these stats seem to suggest the system is overloaded.
I tried building a new FreePBX install on an i7 NUC with 8GB RAM and an SSD at the weekend, restoring the config here and pointing DNS to it. After a couple of test calls, it too was showing these warnings.
I am concerned with some of the things I have read regarding taskprocessors which seem to indicate that PJSIP can “pause” responding if a queue size reaches the high water level - although the documentation doesn’t seem clear on whether this is true of ALL taskprocessor queues or only those specific to the PJSIP components.
Sorry for the brain dump - but to be honest, this is causing me sleepless nights. Just a FYI… last week we were having severe issues with the system. The VM was shutdown one evening to allow a copy to be made of it’s VMDK/VMX files etc as a kind of “super backup”. However, when the VM was powered-on, the system was not working properly. At random points in the day, when a call came in, the target handsets would start to ring but would never stop. When the system got into this state, I was unable to register new extensions and incoming calls on the existing trunks gave the busy tone to the external caller - the FreePBX logs showed no activity when these incoming calls were attempted. I assumed that something which had been configured in the week since the last system reboot was responsible and started “backing-out” changes (call recording enabling etc) but was unable to get the system operational for more than a week. In desperation this weekend, I created a new VM, re-installed FreePBX and restored the configuration. Since this time, no more weird “ghost” calls or busy incoming trunks… but these warning are freaking me out a little as I have never seen them on previous systems.
In short HELP - technical or psychiatric…
This is a little confusing… do you mean you have multiple devices on the same extension (needs PJSIP) or multiple extensions on the same device (doesn’t need PJSIP). When you say you’re using Gigaset handsets A510, C610 etc - what are you using as the base? Gigaset N510, N720 etc?
With Zulu mobile still unavailable, I was forced to take a look at 3cx recently. Indeed, we trialled it “live” for a month. There are strengths and weaknesses on both sides. 3cx seem a lot more “corporate” than Sangoma/FreePBX and very “stuck in their ways”. Suggestions people were making for functionality changes were, at best, met with indifference by both 3cx and their users alike. For example, setting DND on a handset on 3cx does not notify subscribers that the handset is busy… compared to Asterisk this just seems crazy to me - but 3cx insist that users would prefer to see this status on the Windows softphone client instead… 
I have come back to FreePBX with my tail between my legs, taken Andrew Nagy’s advice and opened support calls on a couple of issues I had with Zulu 3 - and hope that the Zulu Mobile client answers all my prayers.
You really can’t compare the team at FreePBX/Sangoma with 3cx - completely different culture
I use only SIP PJSIP is disabled
YES I use multiple extensions on the same device for example C530-IP.
But my problem is now solved.
Gigaset release new FW last month and this fix my latency problem. 
The issue with this isn’t a 3CX or Asterisk issue. The DND button that is on many phones by default is a local DND function. That means it sets the phone (the entire thing) to DND and it in no way tells the PBX (3CX, Asterisk, etc) what the status of the phone is. The PBX will only see that the phone is BUSY when it sends a call to it. In order for Asterisk/FreePBX to tell all the subscribers that device is BUSY the user must dial the DND Feature Code or use the UCP or other function that will update the status at the PBX level which will then trigger the NOTIFY messages to all the subscribers.
This is a common issue I’ve seen over the years, even with FreePBX. Users submit feature requests or improvements that are related to non-PBX level items or with a lack of understanding how certain features/functions work in general. The “indifference” is because nothing can actually be done about it and they just let it sit.
Also, the one thing I haven’t seen anyone touch on with the 3CX trend that is going on. Over a year ago 3CX was 100% Windows based, so even their “free” license require the user to shell out a Windows license fee. Now with the buyouts that 3CX performed they now have a full Linux based offering with their free level license. Part of their buyouts of these other companies was to compete with FreePBX in this space.
Just another little FYI, Nicholas Galea (CEO of 3CX) acquired shares in Sangoma back in 2016 and has been selling those shares since 2017 as part of his “investment” strategy. Nicholas announced sales of shares in July of 2017 and even back in May of this year he announced the sale of more shares of Sangoma stock. Even more fun information, Nicholas still has control of roughly 6.9% of the common shares for Sangoma on the market after these two announcements.
Tom - with a reply like this you could actually WORK for 3cx - or at least be a reseller. This is EXACTLY the kind of response you get!
Actually the DND function in 3cx is actually quite good. It switches on the local DND on the 'phone but the 3cx soft clients update their status to “away”. This is not reflected by the BLF of monitoring subscribers though. Contrast this with dialling the feature code on an Asterisk device.
The feedback received by myself and other on the 3cx forum was close to derision - “why would you want to show the phone in-use when it’s actually DND”, “its the fault of the phone manufacturer that DND doesn’t show on BLF”, “there is no DND status that can be used in a NOTIFY”… all semi-true, semi b/s
For installations that don’t want to use a softclient and believe that a phone system is just a phone system, it’s nuts not to at least allow the installer to make DND indicate busy on subscribed extensions. Would it be nice if the phones supported a DND notify? Sure… but apart from Yealink handsets with their ridiculous “TALKING” label on an active BLF, a red light is a red light is a red light.
Most if not all phones allow their hardware DND button to be reprogrammed to send a DTMF sequence in which case pressing the DND button can easily send *76 or whatever and then ALL devices know the phone is busy/DND.
I have no comments to make about Nick Galea - he seemed quite reasonable when I “chatted” with him via the forums - although there is much evidence across the internet that he can be more than a little difficult to deal with.
preupgrade-assistant-2.6.0-2.el6.sangoma.x86_64
preupgrade-assistant-contents-0.7.5-1.el6.sangoma.noarch
As in the server the recording does not present the problem, I thought that I would not see delayed packets when running “rtp set debug ip”. And I understood that the ordering problem was happening exclusively on the user’s side.
Anyways, I am going to check sngrep and RTFM! 
Thanks for the tip, very well appreciated!
I see where you’re going with this. I just checked the upgrade instructions and the first line is different from the one in my notes. I’ve been using this line:
yum -y install http://package1.sangoma.net/distro-upgrade-1802-2.sng7.noarch.rpm
But on the upgrade page it says to use this line:
yum -y install http://package1.sangoma.net/distro-upgrade-1807-2.sng7.noarch.rpm
I don’t know how I got the wrong package listed in my notes. I’m going to start over and try again. Thanks for all your help!
I neither work for or resell 3CX.
As for the DND feature in the 3CX softphone doing things, of course it can. It’s a softphone designed to function with their PBX so the DND key on their softphone is going to do what it was designed to do. I was referring to non-3CX phones/softphones. You buy a Yealink, Polycom, Cisco SPA, Aastra, etc and hit the DND button on those phones they do what I described in my previous post.
There are PBX makers that have their own phones. These phones are designed to work specifically with the PBX in question. These will always provide more features and functions than a straight SIP device and yes, the PBX maker will push their phones over the use of other phones.
You wouldn’t. When you use the DND feature in FreePBX it sets the device state to BUSY not INUSE. INUSE pretty much means the device/extension is on an active call. At the phone level if they are in DND the phone will send back either a 480 or a 486 SIP reply to show that it is “BUSY”.
That’s BS. BLF is a two-factor feature. 1) The phone must be able to support BLF and 2) The PBX/Phone system needs to support Subscriptions. Each PBX/Phone system can have different ways in which they handle said subscriptions and how to subscribe and what to subscribe to.
Additionally, phones generally have a Subscription server option in them and a user/pass option for said server. If that is not set, it defaults to the SIP account/server for subscriptions. So really the subscription service could be a completely different server than the PBX. It’s actually done that way in a few different platforms.
At the device level? It’s just BUSY. There aren’t a lot of device statuses that need to be sent via a NOTIFY.
The other thing that people commonly get mixed up on is the fact that Presence and Device statuses are two separate things. Presence is for the user. The user’s Presence status can be multiple things from “Out to Lunch”, “On Vacation”, “In Meeting”, “Do No Disturb”, “Away”, etc, etc… Depending on the phone system and how it is set up, setting your status to one of those can in turn update the status of your device as well.
Some PBX/voice systems that have a chat element included can also offer statuses such as “Chat Only” which updates the user’s Presence status to show that while setting the device to BUSY but allow people to send IMs to them. However, when they set their Presence to Do Not Disturb not only does it change the device status it also changes their chat status and people can no longer send IMs along with calls getting the bust destination.
Again, a lot of this has to do with what the PBX/phone system can provide and support along with what the endpoint/devices (softphone or hardware) can also support in conjunction with the system it is communicating with.
;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. ;
;--------------------------------------------------------------------------------;
; For information on adding additional paramaters to this file, please visit the ;
; FreePBX.org wiki page, or ask on IRC. This file was created by the new FreePBX ;
; BMO - Big Module Object. Any similarity in naming with BMO from Adventure Time ;
; is totally deliberate. ;
;--------------------------------------------------------------------------------;
[general]
enabled=yes
enablestatic=no
bindaddr=::
bindport=8088
prefix=
sessionlimit=100
session_inactivity=30000
session_keep_alive=15000
tlsenable=yes
tlsbindaddr=[::]:8089
tlscertfile=/etc/asterisk/keys/integration/certificate.pem
tlsprivatekey=/etc/asterisk/keys/integration/webserver.key
But in fact i got in WEB
FreePBX 14.0.3.12
FFS. I give up. The quotes you have used from my earlier post are responses 3cx gave me when I queried why a subscriber wasn’t notified the remote device was in DND - either by a specific notify or a general in_use/busy.
You completely missed the point of what I said 3cx softphone did - what I said was that when you put a 3cx-provisioned device in DND, the 3cx server notes the change and adjusts the user’s presence to match so the softphones show the DND status. This is kinda pointless though when they don’t notify subscribing extensions of the fact.
Whatever the mechanism I, as others did, would have liked the BLF to be on for devices in DND - LIKE THEY ARE WHEN YOU DIAL DND IN ASTERISK. Which was the only damn point of what I put.
I’m not a moron, I do understand the difference between presence and device status - which is why I said that for environments who believe a phone system is a phone system and if a phone sets DND this should be reflected by the BLF on monitoring phones.
Anyway, I’m done with this conversation… you definitely know far more than me - so how about helping with my thread where I have an actual, technical issue with FreePBX
Instead of using “Directed Call Pickup”, have you tried the group pickup option (IIRC, it’s “*8” - check your Feature Summary)?
That is incorrect. Nick sold all his holding 100% a couple months ago. Once he is below 10% he no longer has to report his holdings.
I do not know if this is helpful but looking in linphone’s log, I see a bunch of these messages during the call were we had the problem.
2018-08-10 10:39:04:497 WARNING Not enough ref samples, using zeroes 2018-08-10 10:39:04:507 WARNING Too many samples to drop, dropping entire frame. 2018-08-10 10:39:04:528 MESSAGE Samples are back.
And at end of the call the stats show…
2018-08-10 10:43:06:781 MESSAGE MSQualityIndicator[0CC22050][audio], remote statistics available:
Loss rate : 0.0%
Inter-arrival jitter: 1.0ms
RT propagation : 5.0ms
and final stats.
2018-08-10 10:43:10:057 MESSAGE ===========================================================
2018-08-10 10:43:10:057 MESSAGE AUDIO SESSION’S RTP STATISTICS
2018-08-10 10:43:10:057 MESSAGE -----------------------------------------------------------
2018-08-10 10:43:10:057 MESSAGE sent 50907 packets
2018-08-10 10:43:10:057 MESSAGE 0 duplicated packets
2018-08-10 10:43:10:057 MESSAGE 8756004 bytes
2018-08-10 10:43:10:057 MESSAGE received 50914 packets
2018-08-10 10:43:10:057 MESSAGE 0 duplicated packets
2018-08-10 10:43:10:057 MESSAGE 8757208 bytes
2018-08-10 10:43:10:057 MESSAGE incoming delivered to the app 8754972 bytes
2018-08-10 10:43:10:058 MESSAGE incoming cumulative lost 1 packets
2018-08-10 10:43:10:058 MESSAGE incoming received too late 1 packets
2018-08-10 10:43:10:058 MESSAGE incoming bad formatted 0 packets
2018-08-10 10:43:10:058 MESSAGE incoming discarded (queue overflow) 0 packets
2018-08-10 10:43:10:058 MESSAGE sent rtcp 193 packets
2018-08-10 10:43:10:058 MESSAGE received rtcp 203 packets
2018-08-10 10:43:10:058 MESSAGE ===========================================================
2018-08-10 10:43:10:058 MESSAGE ===========================================================
2018-08-10 10:43:10:058 MESSAGE FILTER USAGE STATISTICS
2018-08-10 10:43:10:058 MESSAGE Name Count Time/tick (ms) CPU Usage
2018-08-10 10:43:10:059 MESSAGE -----------------------------------------------------------
2018-08-10 10:43:10:059 MESSAGE MSWebRTCAEC 101690 0.128861 33.2918
2018-08-10 10:43:10:059 MESSAGE MSRtpSend 101816 0.105994 27.418
2018-08-10 10:43:10:059 MESSAGE MSResample 203384 0.0319738 16.5214
2018-08-10 10:43:10:059 MESSAGE MSAudioFlowControl 50908 0.0431358 5.57913
2018-08-10 10:43:10:059 MESSAGE MSRtpRecv 102795 0.0188042 4.91095
2018-08-10 10:43:10:059 MESSAGE MSAudioMixer 305448 0.00371584 2.88356
2018-08-10 10:43:10:059 MESSAGE MSWASAPIWrite 101645 0.00673907 1.7403
2018-08-10 10:43:10:059 MESSAGE MSDtmfGen 203637 0.0029906 1.54722
2018-08-10 10:43:10:059 MESSAGE MSAlawEnc 101640 0.00484057 1.24997
2018-08-10 10:43:10:059 MESSAGE MSWASAPIRead 101816 0.00467505 1.20932
2018-08-10 10:43:10:059 MESSAGE MSVolume 137586 0.00309622 1.08229
2018-08-10 10:43:10:059 MESSAGE MSItcSource 101816 0.00338843 0.876502
2018-08-10 10:43:10:059 MESSAGE MSGenericPLC 101816 0.00211163 0.546226
2018-08-10 10:43:10:059 MESSAGE MSFilePlayer 101821 0.00172851 0.447143
2018-08-10 10:43:10:059 MESSAGE MSAlawDec 50901 0.00326117 0.421737
2018-08-10 10:43:10:059 MESSAGE MSTee 35946 0.00169694 0.154976
2018-08-10 10:43:10:059 MESSAGE MSEqualizer 137586 0.000218044 0.0762176
2018-08-10 10:43:10:059 MESSAGE MSOpusEnc 99 0.17 0.04319
2018-08-10 10:43:10:059 MESSAGE MSMKVRecorder 49 0 0
2018-08-10 10:43:10:059 MESSAGE MSFileRec 99 0 0
2018-08-10 10:43:10:059 MESSAGE MSVoidSink 0 0 0
2018-08-10 10:43:10:059 MESSAGE MSItcSink 0 0 0
2018-08-10 10:43:10:059 MESSAGE ===========================================================
2018-08-10 10:43:10:061 MESSAGE MKVRecorder: destroyed
2018-08-10 10:43:10:061 MESSAGE ===========================================================
2018-08-10 10:43:10:061 MESSAGE FILTER USAGE STATISTICS
2018-08-10 10:43:10:061 MESSAGE Name Count Time/tick (ms) CPU Usage
2018-08-10 10:43:10:061 MESSAGE -----------------------------------------------------------
2018-08-10 10:43:10:061 MESSAGE MSWebRTCAEC 101690 0.128861 33.2918
2018-08-10 10:43:10:062 MESSAGE MSRtpSend 101816 0.105994 27.418
2018-08-10 10:43:10:062 MESSAGE MSResample 203384 0.0319738 16.5214
2018-08-10 10:43:10:062 MESSAGE MSAudioFlowControl 50908 0.0431358 5.57913
2018-08-10 10:43:10:062 MESSAGE MSRtpRecv 102795 0.0188042 4.91095
2018-08-10 10:43:10:062 MESSAGE MSAudioMixer 305448 0.00371584 2.88356
2018-08-10 10:43:10:062 MESSAGE MSWASAPIWrite 101645 0.00673907 1.7403
2018-08-10 10:43:10:062 MESSAGE MSDtmfGen 203637 0.0029906 1.54722
2018-08-10 10:43:10:062 MESSAGE MSAlawEnc 101640 0.00484057 1.24997
2018-08-10 10:43:10:062 MESSAGE MSWASAPIRead 101816 0.00467505 1.20932
2018-08-10 10:43:10:062 MESSAGE MSVolume 137586 0.00309622 1.08229
2018-08-10 10:43:10:062 MESSAGE MSItcSource 101816 0.00338843 0.876502
2018-08-10 10:43:10:062 MESSAGE MSGenericPLC 101816 0.00211163 0.546226
2018-08-10 10:43:10:062 MESSAGE MSFilePlayer 101821 0.00172851 0.447143
2018-08-10 10:43:10:062 MESSAGE MSAlawDec 50901 0.00326117 0.421737
2018-08-10 10:43:10:062 MESSAGE MSTee 35946 0.00169694 0.154976
2018-08-10 10:43:10:062 MESSAGE MSEqualizer 137586 0.000218044 0.0762176
2018-08-10 10:43:10:062 MESSAGE MSOpusEnc 99 0.17 0.04319
2018-08-10 10:43:10:062 MESSAGE MSMKVRecorder 49 0 0
2018-08-10 10:43:10:062 MESSAGE MSFileRec 99 0 0
2018-08-10 10:43:10:062 MESSAGE MSVoidSink 0 0 0
2018-08-10 10:43:10:062 MESSAGE MSItcSink 0 0 0
2018-08-10 10:43:10:062 MESSAGE ===========================================================
Ahh, interesting. I didn’t know about the under 10% rule for the reporting. Thanks.
