Flash is slated to die at the end of 2020 (and hopefully that date is kept IMO) — is the flash operator panel a holdover name that a new HTML/JS version uses? I haven’t used said operator panel so I’m not familiar with it. If it does indeed refer to an Adobe Flash version it may not be wise to put more development effort into it.
Yes, it’s html5
1 Like
I would like to have an option to create inbound routes per dahdi channel and not only per DID.
This is for the actual recordings of the calls, not the system recordings. For call recordings difference between wav and mp3 is gigabytes.
What bitrate are your .wav files? Your .mp3 files? And why .mp3 instead of OPUS or another modern codec that provides less degradation for a given bitrate?
another +1 for improved IPv6 support. Unless I’m badly mistaken I cannot even configure an IPv6 transport using the GUI. Just tried to do this for PJSIP and failed miserably.
Users / Groups:
-
Don’t delete users/groups from external directories if they’re deleted in the external directory - just flag them for cleanup. We continue to have issues with user and group settings occasionally disappearing, presumably due to sync issues (perhaps rebooting or otherwise losing connectivity to an AD server during sync or something?). Even beyond sync issues, there is also the possibility of admin error and we don’t have granular backup/restore capabilities for these settings like we do with AD itself. This has been a pain point for us.
-
Related to (1) above, support multiple AD servers for syncing. Or preferably just let us specify the domain and pull the server list from DNS (_ldap.tcp.dc._msdcs.mydomain.com).
-
Move all of the user / group data into an extended AD / LDAP schema - this would eliminate (1) completely and make it very easy to backup and restore, and might lead into some very interesting scalability / failover capabilities for large organizations.
High availability:
- Support multiple Ethernet interfaces for failover (we have a situation where we have to use RFC-1918 addresses for internal clients and a publicly routable IPv4 for the provider over MPLS, and we will probably run into this again).
- Support cross-site failover (I think this is already planned for 15, but including anyway).
- Active/Active support - many phones will allow a secondary (or more) SIP PBX connection, and with cross-site failover this would provide better support for datacenter site failover.
1 Like
Extension / endpoint management:
- Extension Groups, please, please, please. Managing them individually is a huge time-waster.
- As mentioned by some others, more aggressive support in Endpoint Manager. If you had to triple the price to accomplish this I’d be perfectly happy to pay it. I can see where this is just a massive, hideous, soul-draining pile of suck from a development and maintenance standpoint, but as customers we really do need this.
- Don’t default to PJSIP for installations. It would be nice if it was ready for prime time, but in our experience it is not. First thing we do with new FreePBX installs is switch the ports around so that SIP is the main protocol.
UCP / Phone Apps:
- A system for placing local extensions, system-wide contact lists, site-wide contact lists (by user / extension group), and end-user contact lists on the phone BLF keys / expansion modules. We have a hacked system internally for this (site extensions first, system-wide contact lists, site-wide contact lists, then personal contact lists ordered by list name), but it would be nice to have a formal solution for this.
- Flesh out XMPP support some more in UCP - show other users, preferably with the ability to filter out those who are not members of the same group(s).
- Access to various contact lists for SMS. We have a customer who dispatches drivers via texting and an internal web app, and they would LOVE to have access to their various driver lists by User Group (not just for SMS - for calling, etc.).
If that’s your experience please help everyone by telling us why you think PJSIP isn’t working for you and the details of your problems.
If those things aren’t put into a bug report either with Sangoma or Digium, unfortunately nothing will be done to improve it and in five years we’ll still be saying “PJSIP isn’t ready for prime time”.
In fact Digium receives hardly any bug reports on it, so PJSIP won’t be different a year from now if we don’t provide them any.
In fact there is a lengthy thread about PJSIP, the perception of it, and its problems:
@avayax Interestingly the very last post on that thread you linked to had you saying
“You can use pjsip on internal extensions, but use chansip for your Sip trunk providers”
Have you changed your mind?
There are many VSP’s that will ONLY register against 5060
It is relatively trivial to arrange for all you internal (and external) extensions to use your pjsip port (5060 would be my last choice for any number of reasons) , I’m not saying chan_pjsip is bad it has great enhancements for extensions , not so much needed for trunks and chan_sip is pretty well rock solid , the VSP’s accept that fact and provide howto’s for provisioning it.
In what way?
I haven’t changed my mind.
Right.
I have some of my systems still on chansip, some on pjsip internal, but would like to move all over to pjsip next year, also the trunks. I haven’t tried pjsip on trunks yet.
The duality of having to keep both channel drivers is confusing and inefficient, also makes setup and troubleshooting more complicated.
To keep both forever is an undesirable prospect.
It’s just that the more people deal with pjsip and also report on it’s problems, the better for everyone.
Then I agree with you, I edited my post to reflect my own feelings. Providers on 5060 and chan_sip for ease, compatabilty and legacy, extenstions on chan_pjsip somewhere not so visible to the knuckle-draggers for the advantages of chan_pjsip for extensions. Firewall rules are simpler and largely effective if your extensions don’t use 5060
Just remember Digim EOL chan_sip and it has no more bug fixes being applied and only pjsip gets any features and bug fixes.
For example we found a nasty bug in chan_sip just recently where it will randomly send qualifies and invites from the wrong IP and ignore the IP that it is bound to. Guess what that bug will now exist forever as Digium won’t fix it nor should they since it’s EOL.
Interesting, can you post a reference to that nasty bug please?
No bug report public since it won’t get fixed with Digium. It only affects users who bind Chan sip to a specific IP like a floating IP in HA
That’s what I do. I am using HA on a number of systems.
Is there any info on when this happens?
HA doesn’t work with pjsip.
1 Like
Is that your HA implementation or all generic HAs ?
Has nothing to do with our HA. It’s chan_sip randomly not honoring the IP Bind. Not sure why we are focusing on a single bug. Their are plenty in Chan sip was just using that as a example as it was the most recent and something we just dug into last week as a example.