About this document
This document describes the new features (new APIs, modified APIs, internal features) and specific upgrade instructions for the Broadworks Gateway (that includes also Phones Vendors, Transcribe and Call Recording Gateways).
The most recent version is listed upper.
It must be noted that this public document at been created at the time of the release 1.11.0 and will not include older version.
Release 1.11.2
New and Modified APIs
Please refer to the APIs documentation changes log
New and Modified features
Files access hardening
There has been modifications on the access rights of the files delivered by the RPM packages.
It is mainly to:
- remove the "others" rights
- be sure the users in the group django can access them.
Lib phone number upgrade
The 3rd party library used to validate phone numbers has been upgraded to the version 8.13.52. You can check their release note to see the changes
Release 1.11.1
New and Modified APIs
Please refer to the APIs documentation changes log
New and Modified features
Audit records for other Network Adaptors than BW
We have added the support of generation of South Data in the audit records for the following type of network element interactions: • Phone Vendors • Call Recording
• Email Transcoding
Theses audit record south data items indicate the type of record, the data format (JSON or XML) and the vendor (for now only relevant for Phone Vendor), while the BW records only indicate BW as the format is always XML (so far). It is possible to disable this generation in the Backend settings (it is enabled by default if the audit feature is enabled).
Note: The APIO Core GUI (Requests) will progressively be adapted to support these new types of items. Until it is the case, in the graphical representation of the message exchanges, the “other party” will be reported as unknown
AS System Default Domain by AS Backend connection data
Up to now the multi-AS prerequisites made that all the “system low level configuration” is the same. For example the list of available Call Types, NCOS, … and also the AS System Default Domain.
But some customers came with the need to regroup in one platform several AS initially configured with different AS System Default Domain (and this is quite complicated to change at BW side itself). It means that with its previous capabilities the APIO could add the wrong domain to users in these AS. Note: the need to add the default domain in the APIO to users without domain is coming from an undocumented behavior of BW: in some APIs (but not all of them) if a userId has the AS System Default Domain as domain, the OCI answer will contain only the user part, while in others OCI answers the full userId is returned making comparisons of userIds between APIs complicated. Also some OCI requests need the full userId not the partial one.
With the 1.11.1, it is possible to define in the BW AS Backend settings the AS System Default Domain. When it is the case: • the Network Adaptor library (PROQ) will use these settings (attached to the OCI session) to adapt userIds in OCI answers • when at login time the username does not contain a domain, the APIO will add the AS System Default Domain in the lust of domains to be tried (in addition of the domains defined the global settings that will be tried first) It must be noted that as Cisco BW does not document the OCI answers impacted by this “domain removal” logic, it is therefore possible that we have missed some of them. If some are discovered we will of course adapt them in the next releases.
Bug fixes (not impacting API signature)
In case of VM transcoding the mediaType is incorrect
When reading a voicemail, it is possible to ask to transcode the content into mp3. This waw working fine, but the mediaType field in the answer body was not updated from WAV to MP3. It I snow the case.
Specific Upgrade Instructions
If you upgrade from 1.11.0, nothing specific to be done. If you upgrade from a release older than 1.11.0 then the upgrade instructions of the 1.11.0 must be followed.
Release 1.11.0
New and Modified APIs
Please refer to the APIs documentation changes log
New and Modified features
Encryption of some fields of the Backend object
The Backend object has now its 2 fields with sensitive data such as password (connection_data and service_data) encrypted in the DB.
Bug fixes (not impacting API signature)
Service Users: active status returned with incorrect value or when not relevant.
Due to a bad initialization in a lib, the “active status” was always returned as False in GET CC Instance and GET HG Instance while it should not be present at all. It is now fixed.
Specific Upgrade Instructions
This upgrade introduces the encryption of some fields of the Backend object in the DataBase. This is a breaking change, backward incompatible.
What is the impact: when the RPM package is installed, it launches the DB migration process. It means that the end of the installation the old code of the GW is no more able to read these objects and therefore will stop working.
The following steps are therefore needed:
- The BW GW must be stopped (using supervisorctl), on all servers in case of redundant setup
- The new RPMs are installed on all servers
- The BW GW is restarted on all servers.
Note that the steps 2 and 3 can be done server by server. But the step 1 MUST be done on all servers before any step 2 is performed.
In case a rollback would be needed, the instructions are also specific:
- The BW GW must be stopped (using supervisorctl), on all servers in case of redundant setup
- The migration (Django terminology) must be rollbacked (see below)
- The old RPMs are installed on all servers (do not forget the ‘force” option as the version is decreasing)
- The BW GW is restarted on all servers.
Note that the steps 3 and 4 can be done server by server. But the step 1 MUST be done on all servers before the step 2 is performed and only after step 2 is performed can 3 and 4 be started.
How to rollback the migration:
- To be done on one of the servers only
- Go in folder /opt/apio-gw-core/ops/scripts
- You will have 1 or several sh scripts (several if same server is shared between instances) named update_django_db…
- What is important is the last element of the file that is the reference of the settings file: apio_gateway_frontend.settings…., note all of them. Let’s says it is “apio_gateway_frontend.settings.apio-gateway-my_example.ini”
- Go in folder /opt/apio-gateway_frontend/apio-gateway
- Execute “source /opt/apio-gw-core/ bin/activate”
- And then execute for each instance of the GW “python manage.py migrate authentication 0020_alter_backenduserprofiletypelink_unique_together --settings= apio_gateway_frontend.settings.apio-gateway-my_example.ini” where you replace the last element by the value copied in stage 4.