This is an update release to 15.10. It contains various fixes that were deemed important to be backported to 15.10.
Enhancements, Fixes and Known Issues
| UC-3389 | Auto Attendant prompt "Please hold while I transfer your call" when transferring call after failure cannot be dissabled | Auto Attendants prompt "Please hold while I transfer your call" when transferring calls AFTER FAILURE cannot be disabled. It can be done for any other call transfer through Auto Attendants. More info https://ezuce.zendesk.com/agent/tickets/3640 | Fix |
| UC-3799 | Shortcode for disable/enable live attendant not working | Steps to reproduce : 1. Configure a Live Attendant under System> Dial Plans > AutoAttendant page: Enable live attendant : Checked Live attendant extension : 201 Enable / disable code : 123 Extension will ring for : 10 seconds Follow user call forwarding : Unchecked Live answer attendant : Always 2. Live Attedant can be enabled/disabled using the shortcode feature: - enabling/disabling it with *67/*68 + AA extension + code. 3. After Live Attendant is set up, user 202 calls AA ext 100, user 201 being alerted by the incoming call. 4. Disable Live Attendant using the shortcode by dialing: - shortcode + AA ext + code = *68100123 Expected result: - Live Attendant should now be disabled and the default Operator AutoAttendant should be reached Reported problem: - repeating step 3, user 201 will be alerted by the incoming call. | Fix |
| UC-3837 | zen 5081 : 15.10 invalid /etc/hosts entry | A invalid /etc/hosts entry is generated on 15.10 as shown on line two below .. : [root@uc ~]# cat /etc/hosts 192.168.10.15 uc.ezuce.mattkeys.net uc $(ips[$(host_servers).ezuce.mattkeys.net][1]) $(host_servers).ezuce.mattkeys.net $(host_servers) # sipXcom cluster 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Steps taken to reproduce 1. Install 15.08 from ISO. 2. Install 15.10 from ISO. 3. cat /etc/hosts on each Results attached, 15.08 on the left and 15.10 on the right. It is also there if the server was upgraded via yum from 15.08. No commit required. Rebuild after revert of some code for UC-3770 fixed issue. | Fix |
| UC-3838 | zen 5081 : 15.10 DNS zone incorrect after restore | Restored customer sipxcom 14.10 configuration.tar.gz to 15.10 within the webui restore from backup upload (no options checked on the restore). Resulting /var/named/default.view.<sipdomain>.zone was found to be incorrect and using the pre-existing sip domain. For example I was using ezuce.mattkeys.net previously and restored cha.vox.genesyslabs.com .. : [root@uc ~]# cat /var/named/default.view.cha.vox.genesyslab.com.zone $TTL 1800 @ IN SOA ns1.ezuce.mattkeys.net. root.ezuce.mattkeys.net. ( 105820009 ; serial# 1800 ; refresh, seconds 1800 ; retry, seconds 1800 ; expire, seconds 1800 ) ; minimum TTL, seconds ezuce.mattkeys.net. IN NS uc This configuration.tar.gz backup I used can be found here : sftp://ftp.ezuce.com/support/upload/mkeys/genesys/sa_restore/configuration(28).tar.gz No commit required. Rebuild after revert of some code for UC-3770 fixed issue. | Fix |
| UC-3839 | zen 5088 : 15.10 System -> Backups never completes listing backups | Steps to reproduce .. 1. log into 15.10 webui as superadmin using any browser 2. navigate to system -> backups At the bottom of the page "operation in progress" spins forever, preventing the user from running "backup now" or making any schedule changes. No commit required. Rebuild after revert of some code for UC-3770 fixed issue. | Fix |
| UC-3840 | zen 5087 : 15.10 config backup to 15.10 restore fails | Steps taken to reproduce .. : 1. on uc.ezuce.mattkeys.net (192.168.10.15) command line, I ran sipx-backup -c to generate configuration.tar.gz, attached 2. on test1510.home.mattkeys.net (192.168.1.183) webui as superadmin, system -> restore -> backup file upload -> configuration.tar.gz from step 1, restore result is a failure, 99% snapshot attached from test1510.home.mattkeys.net. No commit required. Rebuild after revert of some code for UC-3770 fixed issue. | Fix |
| SIPX-393 | Add known issue for Auth Codes with Locations | The authorization code is a user itself. The problem is that this special user is not a member of any location/branch. For example if a call is placed from user X (which is in the same location as the gateway he is trying to use) to the auth shortcode : *82. The user is allowed to call *82 then is allowed to enter the auth code, and is approved to call by proxy. But on the next step when user X goes on and tries to enter the external number, the user is blocked because the "auth code" special user needs to transfer user X outside via the gateway. The special user cannot transfer the call externally via the gateway, because the gateway is placed in a location, and can only be used by users from that location, of which our "auth code" special user is not part of. | Known Issue |