Forum Replies Created
-
AuthorPosts
-
By default, HAastCR will place users back into the FreePBX dialplan at the point of joining the conference (without password validation). However, the conference bridge will use the FreePBX settings and may force each user to re-record their name – IF that is how you set the conference configuration within FreePBX.
To circumvent the name re-recording only for call recovery, you have to make a separate entry point into the dialplan at the Asterisk level, with different options. First, create a file in the /etc/asterisk directory called ext-meetme-custom.conf containing:
[ext-meetme]
exten => STARTMEETME,1,ExecIf($[“${MEETME_MUSIC}” != “”]?Set(CONFBRIDGE(user,music_on_hold_class)=${MEETME_MUSIC}))
exten => STARTMEETME,n,ExecIf($[“${MEETME_MUSIC}” != “”]?Set(CHANNEL(musicclass)=${MEETME_MUSIC}))
exten => STARTMEETME,n,Set(GROUP(meetme)=${MEETME_ROOMNUM})
exten => STARTMEETME,n,GotoIf($[${MAX_PARTICIPANTS} > 0 && ${GROUP_COUNT(${MEETME_ROOMNUM}@meetme)}>${MAX_PARTICIPANTS}]?MEETMEFULL,1)
exten => STARTMEETME,n,ConfBridge(${MEETME_ROOMNUM},,${USER_PROFILE},${MENU_PROFILE})
exten => STARTMEETME,n,Macro(hangupcall,)Then edit the confbridge.conf file in the /etc/asterisk directory and add the following
[no_name_prompt_user]
type=user
record_conference=no
announce_join_leave=no
announce_user_count=noAnd finally in the haastcr.conf file in the /etc/xdg/telium directory add the following:
conference/variable/user/5=USER_PROFILE=no_name_prompt_user
conference/variable/administrator/5=USER_PROFILE=no_name_prompt_userAnd that’s it. You will have to restart the HAastCR service and FreePBX for the changes to take effect. To build on this, you can treat conference administrators and users differently if you like by creating separate user profiles, but the above example shows how to make the change.
Note: If you are not comfortable working with HAastCR/Asterisk configuration files, then please contact Telium to assist with this configuration.
in reply to: How do I install the Dongle Server #22526First, plug the Dongle Server into your network and it will receive an address via DHCP. Browse to this address to configure a static IP (recommended) in the Dongle Server. There are other optional parameters to configure, but for now this is enough to get started.
Next you must download the SEH UTN Manager installation files which can be found on the SEH Computertechnik GmbH website:
https://www.seh-technology.com/services/downloads.htmlThere are 3 packages you must download (you do not need to install the GUI manager), matching your Linux distro:
1) driver
2) service (SEH UTN service/daemon)
3) clitool (command line interface tool ‘utnm’)We recommend you download these files to the /usr/src/seh directory. Next open a terminal window and install the packages as follows (instructions assume Red Hat family OS):
1. Install the headers for your kernel:
sudo yum install kernel-devel-uname -r
2. Verify, that the version numbers of kernel and headers match exactly:
Kernel: uname -r
Header: sudo yum list | grep kernel-headers
3. Change to the /usr/src/seh directory
cd /usr/src
5. Install the SEH UTN Manager packages (repeat for each package downloaded):
sudo yum install <full package name>
6. Add all users that are to administrate the SEH UTN Manager on the client to the user group ‘utnusers’. To do this, open a Terminal and enter the command:
sudo usermod -aG utnusers <username>
Note that if you plan to operate solely as root, this step is optional
7. Logout and login again so that the group changes take effect.Next plug the Telium USB dongle into the dongle server port 1, and from the linux host issue the following command (using your dongle server’s IP address):
utnm -c “getlist 1.2.3.4”
You should see something like the output below.
Port VID PID Manufacturer Product
—- —— —— —————————– —————————–
1 0x0471 0x485e Senselock Elite4 5.xPort State Owner Class Port name
—- ————— ————————- —– ————————-
1 Not activated server1 0x03 test dongleNext you need to connect the dongle in the Dongle Server to the host (SEH calls this “activation”). The following command will connect the host to the device in the Dongle Server’s port 1 :
utnm -c “activate 1.2.3.4 1”
And finally, confirm that your host sees the dongle server as expected:
lsusb
Bus 006 Device 013: ID 0471:485e Philips (or NXP) Elite4 5.xNext, you should set the dongle to re-connect automatically in case of network outage or other problems:
utnm -c “set autoconnect=true 1.2.3.4 1”At this point you can begin using the dongle as if were plugged into the local host. There are many more options available to configure the dongle server, as well as the host connection. Telium may advise on other settings to suit your environment, but in general if you don’t understand a setting don’t experiment. The defaults work quite well.
Note that Telium may recommend changing other settings in the Dongle Server, but Telium must have detailed information on your network topology, hosts, etc. As well, Telium can only offer such recommendations and offer support to Dongle Servers purchased directly from Telium.
If you wish to review the dongle server documentation (for Linux) please see:
https://www.seh-technology.com/fileadmin/user/downloads/dongleserver/documentation/dongleserver_UM11_Linux_en.pdfin reply to: Encryption of config file passwords #22495Although this question is years old, Telium products do now support keeping encrypted values in a keyring. (No way to reverse or expose the stored value). This was implemented at the request of our customers.
Some USB devices need a power cycle after a deactivation or a loss of the USB connection, to be able enumerate themself again at the host. This is what is happening when you power off or reboot your virtual machines.
We can automate the power cycle of the USB ports on the DongleServer whenever these devices are connected. The following steps will cause the specified USB device to power cycle for 5 seconds after every interruption or deactivation of the USB connection.
1. Download the parameter file from the dongleserver (Maintenance > Backup > Export)
2. Delete every entry in the file except the “utn_poffduraX = 0” entrys, where X is for the USB port number where your Telium Dongle is plugged in.
3. Change the 0 to a 50 in the above line, and save the file.
4. Upload this file to the dongleserver
5. Verify this parameter was accepted via the “view” button on the “maintenance” -> “backup” page.For example, on a 20 port DongleServer ProMax the new config file to upload would look like this:
utn_poffdura_1 = 50
utn_poffdura_10 = 50
utn_poffdura_11 = 50
utn_poffdura_12 = 50
utn_poffdura_13 = 50
utn_poffdura_14 = 50
utn_poffdura_15 = 50
utn_poffdura_16 = 50
utn_poffdura_17 = 50
utn_poffdura_18 = 50
utn_poffdura_19 = 50
utn_poffdura_2 = 50
utn_poffdura_20 = 50
utn_poffdura_3 = 50
utn_poffdura_4 = 50
utn_poffdura_5 = 50
utn_poffdura_6 = 50
utn_poffdura_7 = 50
utn_poffdura_8 = 50
utn_poffdura_9 = 50in reply to: Why does VLS reboot on its own #20761The VLS server may reboot itself following internal housekeeping activities. This is not normally a problem, since the VLS saves all state (activations in progress) and restores them on startup.
If the hardware is causing a reboot (e.g. bad power, hardware interrupt error, overheat, etc) or operating system (Linux crash) this too won’t cause a problem since the VLS will automatically recover it’s last known good state.
If you would like Telium to investigate further, please preserve the core dump file so that we can determine the root cause. But in general you can ignore an occasional reboot.
in reply to: USB dongles with Microsoft Hyper-V #20537Based on user feedback, the USB passthrough support of non-storage devices was removed from the enhanced session capabilities of Hyper-V. At this time (August 2024) Telium recommends a USB over IP solution (either hardware or software based) as described here https://telium.io/en/topic/usb-license-on-hyper-v-guest/
For larger deployments where local activation is required (but hardware fingerprint is not viable), Telium recommends a Volume License Server. For smaller deployments, Telium recommends a hardware based USB over IP solution. Please note that unless you have purchased one of these products from Telium, or you have engaged Telium to install the USB over IP product for you, Telium cannot offer any assistance with these third party solutions.
in reply to: Internal server error #17584There are many causes for a 500 (internal serve) error. The cause will likely not show up in your apache logs because of how PHP is setup. The default PHP configuration is designed to maximize speed (and therefor less logging). If you change your PHP configuration slightly the root cause will show in the apache error log. Please follow these steps:
Locate your php.ini file:
el@apollo:~$ locate php.ini
/etc/php5/apache2/php.iniEdit that file as root:
sudo vi /etc/php5/apache2/php.ini
Find this line in php.ini:
display_errors = Off
Change the above line to this:
display_errors = On
Lower down in the file you’ll see this:
; display_startup_errors
; Default Value: Off
; Development Value: On
; Production Value: Off;error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATEDThe semicolons are comments, that means the lines don’t take effect. Change those lines so they look like this:
display_startup_errors = On
; Default Value: Off
; Development Value: On
; Production Value: Offerror_reporting = E_ALL
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATEDWhat this communicates to PHP is that we want to log all these errors. Warning, there will be a large performance hit, so you don’t want this enabled on production because logging takes work and work takes time, time costs money.
Restarting PHP and Apache should apply the change.Next, do what you did to cause the 500 Internal Server error again, and check the log:
tail -f /var/log/apache2/error.log
You should see the 500 error at the end, something like this:
[Wed Dec 11 01:00:40 2024] [error] [client 192.168.11.11] PHP Fatal error:
Call to undefined function Foobar\\byob\\penguin\\alert() in /yourproject/
your_src/symfony/Controller/MessedUpController.php on line 249The cause should then be obvious – or email us the relevant log excerpts and we’ll help you figure it out. If you run a different Linux OS or different version, then the settings may differ slightly but the same basic instructions apply.
in reply to: OEM edition not recovering calls in one queue #17562You actually did very well setting up your system (without any help from Telium). In fact, if it weren’t for a typo in your NIGHTSERVICE queue recovery parameters everything would have worked.
Look at the NIGHTSERVICE/queue/rebuildmode key. You have “orderofarival”. Notice the missing ‘r’. It should be “orderofarrival”. Fix the typo and that queue will work too.
in reply to: Automatic update to Geofencing database #17542This can be accomplished with a simple bash (or python, perl, etc) script. At a high level the steps are:
- Change to the /usr/local/secast directory
- Use ‘wget’ to pull down the latest GeoIP database from the telium file server
- Restart the SECast service (don’t worry, all state is saved)
We normally make GeoIP database updates available with program updates; however, if you require more frequent updates (or access to a higher accuracy database) please contact your account rep for additional information.
in reply to: USB dongles with Microsoft Hyper-V #17520You’re in luck! Microsoft is slowly catching up with VMware and has experimentally added the ability to pass through USB devices. You will need a recent version of Hyper-V, and be warned that it’s not as polished as VMware’s offering.
You need to enable “Enhanced Session Mode” on your HAast virtual machine. Once you have done so then you can pass through some USB devices. If you would like some step-by-step instruction on how to enable this mode, here is a good post: https://www.nakivo.com/blog/install-ubuntu-20-04-on-hyper-v-with-enhanced-session/
As more that 90% of our customers using virtualization use VMware, we can’t offer technical support for the above yet. But if this becomes more popular then we will include instructions in our installation guide / website.
Note that Telium is not affiliated with the Nakivo website above, and considers this feature experimental. Microsoft may chose to remove this capability at any time (as of August 2023 it worked), so use at your own risk.
HAast has changed considerably since version 2.1. Did you remember to copy over the sync job definitions (probably from /etc/xdf/telium/haast.conf.d ) As for the event handlers (probably post-sync), we recommend that you use nodeprep to ensure data is properly updated and reconciled once it reaches the other node. Most event handlers are a single line of code: e.g. “nodeprep -a 1200”
If you don’t have nodeprep installed (if you pieced together a cluster from old and new software), please email us and we will provide you with the missing software and sample event handlers.
in reply to: Change nodeprep settings after setup #17247If you make changes to any products’ continuity.conf file, you need to tell nodeprep to reconfigure (re-read the continuity.conf file).
So to do this for haast run:
nodeprep -c -haast
nodeprep -c +haastThe first line will remove the haast configuration from nodeprep. The second line will cause nodeprep to re-read all configuration data and update the nodeprep database.
in reply to: Migrating to NodePrep #17245The alignment is only a small part of NodePrep does…but don’t worry, you can still customize the sync event handlers however you want.
i.e. we aren’t deprecating the syntax or event handler files.
NodePrep combines a lot of Call Continuity module functionality that would benefit the non-OEM editions, so we are slowly moving that functionality into the Flex and Unlimited editions.
in reply to: Rebuilding queues after failover on OEM edition #17208The “call continuity” module is responsible for rebuilding the queues on the standby server (as it promotes to primary). The queues are rebuilt in the order of which the calls arrived at the PBX. If a call was first answered by a user (or some other service) and then transferred to the queue, it is possible that the order of arrival at the PBX does not match the order of entry to the queue. Realistically, those few calls might be only slightly out of position.
At this time we do have any workaround for this situation. However, this should affect very few calls (<1%) and the impact should be minimal (minor change in order for those few calls). In a future version of the call continuity module we may use call queue entry times for queue reconstruction. Because of some Asterisk limitations this is not as easy as it sounds.
If this issues is a problem for your customers we recommend announcing estimated wait time instead of queue position.
in reply to: Corrupt AstDB file #17193First of all, make sure that HAast isn’t warning you of a real problem. Does your standby node have latency problems? Sever network/cpu/disk latency could easily cause a sync to fail. And if that’s a rare occurrence then that’s ok. But if it’s happening regularly then first check for hardware (or virtualization) issues.
Next, as you may already be aware, FreePBX is known to destroy the AstDB file for no good reason on rare occasions (i.e. it’s a bug that occurs rarely). See https://community.freepbx.org/t/corrupted-astdb-how-to-rebuild/4809 This problem has existed for many years customers have commented that Sangoma appears unable/unwilling/uninterested to resolve this. The nature of the problem is that Astdb file remains valid and whole (i.e. a valid SQLite 3 file), but critical information is missing or invalid in the database. Since HAast will try to apply changes to the AstDB upon sync, the sync may fail if the contents violate SQL relationship rules or other integrity constraints.
To pinpoint the cause, please enabled debug in the syncjob on the standby computer; for example, the file /etc/xdg/telium/haast.conf.d/asterisk.syncjob.conf might contain a syncjob called asterisk-db. Add the following line to that job:
asterisk-db/debug=on
And then restart HAast on the standby node. This will cause a detailed bug file to be created in the /var/tmp/haast directory. After a few automatic (or manual) starts of the asterisk-db sync job, please send that file to the support team and we will have more insight on what is going wrong.
In summary, the most likely cause is OUTSIDE of HAast. Experience has show that HAast will detect these errors and report them, but it doesn’t mean you have a HAast problem. If you are sure the hardware, Linux, and resources of the nodes are ok then starting debugging in HAast as described above.
-
AuthorPosts
