Child pages
  • sipXcom 15.10.1
Skip to end of metadata
Go to start of metadata

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-3389Auto Attendant prompt "Please hold while I transfer your call" when transferring call after failure cannot be dissabledAuto 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
UC-3799Shortcode for disable/enable live attendant not workingSteps 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.
UC-3837zen 5081 : 15.10 invalid /etc/hosts entryA invalid /etc/hosts entry is generated on 15.10 as shown on line two below .. :

[root@uc ~]# cat /etc/hosts uc
$(ips[$(host_servers)][1]) $(host_servers) $(host_servers) # sipXcom cluster 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.
UC-3838zen 5081 : 15.10 DNS zone incorrect after restoreRestored 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 previously and restored .. :

[root@uc ~]# cat /var/named/
$TTL 1800
@ IN SOA (
105820009 ; serial#
1800 ; refresh, seconds
1800 ; retry, seconds
1800 ; expire, seconds
1800 ) ; minimum TTL, seconds IN NS uc

This configuration.tar.gz backup I used can be found here :

No commit required. Rebuild after revert of some code for UC-3770 fixed issue.
UC-3839zen 5088 : 15.10 System -> Backups never completes listing backupsSteps 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.
UC-3840zen 5087 : 15.10 config backup to 15.10 restore failsSteps taken to reproduce .. :

1. on ( command line, I ran sipx-backup -c to generate configuration.tar.gz, attached
2. on ( webui as superadmin, system -> restore -> backup file upload -> configuration.tar.gz from step 1, restore

result is a failure, 99% snapshot attached from

No commit required. Rebuild after revert of some code for UC-3770 fixed issue.
SIPX-393Add known issue for Auth Codes with LocationsThe 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
  • No labels