Download OpenAPI specification:Download
This is the Maintenance API definition for the Avaya Session Border Controller for Enterprise.
Each supported endpoint is defined in this file along with a description of the endpoint, any required parameters, permissions, and the expected responses with examples. Detailed information on how to fully configure a system from start to finish can be found in the Administering Avaya Session Border Controller for Enterprise document available on the Avaya Support site (see https://support.avaya.com/products/P0997/avaya-session-border-controller-for-enterprise/).
Note that each endpoint definition also includes an embedded x-required-capability
property which contains the
required permissions for the endpoint (this is also included in the description).
Copy Files:
Copy the upgrade package file and the signature file (.asc) to the folder located at /archive/urpackages
.
Start Upgrade: Once the files are copied, start the upgrade process using the API.
Device upgrades are managed through an API that tracks the status of the upgrade process. The process transitions through several states based on API calls and events triggered during the upgrade:
INITIATED: This is the initial state when the upgrade process is started via the API.
STARTING: After initiation, the upgrade moves to the starting phase, where initial setup and checks are performed.
IN_PROGRESS: Once the starting phase is complete, the upgrade progresses to the in-progress state. During this phase, actual updates and changes to the device or system are made. This state includes activities such as down the services, installing updates and start the services.
REBOOTING: The upgrade process requires a reboot to apply the changes, thus transitioning the process to the reboot state.
COMPLETED: In a successful scenario, the upgrade process reaches the completed state, indicating that all phases of the upgrade, including any necessary reboots, have been successfully executed.
FAILED: If an error occurs at any stage of the upgrade process, the upgrade can transition to the failed state. This could happen due to various reasons during update execution.
The status of the upgrade process can be monitored and tracked using the upgrade status API. This API allows consumers to retrieve the current state of the upgrade, providing insights into whether the process is in progress, completed successfully, or has encountered any issues.
During the IN_PROGRESS state, which involves actively updating and modifying services,
both the Upgrade status API and authentication API may return various HTTP status codes such as 500
, 502
, 504
, or 401
.
These codes represent different scenarios, such as server errors (500
), bad gateway errors (502
), gateway timeouts (504
),
or unauthorized access (401
). To handle these situations effectively, API consumers should implement robust error handling mechanisms.
This includes implementing retry strategies for transient errors (500
, 502
, 504
) and ensuring proper management of authentication and authorization issues (401
).
In contrast, while in the REBOOTING state, the upgrade status API service will be unavailable. The upgrade process will transition to COMPLETED once the device successfully completes the reboot process.
Note: The upgrade process can take upto 40 minutes, depending on the system specifications.
Start an upgrade on this device.
This API endpoint will return immediately upon successfully starting the upgrade process. Further inquiries must be made to the API via the status and logs endpoints to check the status of the upgrade after it has started.
User must have the upgrade:update
capability to perform this action.
{- "status": "INITIATED",
- "code": "INITIATED",
- "message": "Upgrade process initiated successfully.",
- "details": {
- "transaction-id": "edae64c9-8257-44bc-955a-fda1bfc20a25"
}
}
Get the current upgrade status.
This API endpoint will return the current upgrade status associated with the provided transaction-id
. This
value will be returned after an upgrade has been started and must be used get the correct upgrade status.
Note: The recommended interval between Upgrade status API calls is 5 to 10 seconds.
User must have the upgrade:read
capability to perform this action.
transaction-id required | string
|
{- "status": "FAILED"
}
Get the logs generated while upgrading the system.
This API endpoint returns the current upgrade logs associated with the provided transaction-id
.
This value is generated once an upgrade has started and must be used to fetch the correct upgrade logs.
User must have the upgrade:read
capability to perform this action.
{- "status": "LOGS_FOUND",
- "message": "Logs found",
- "details": {
- "logs": "2024-02-01 19:22:44,810 [MainThread ] [INFO ] [edae64c9-8257-44bc-955a-fda1bfc20a25] \n[__prep] - Error : [__prep]: Current SBCE Version b'10.2.0.0-85-23901\\\\n' is not in \nUpgrade/Update Supported Version List\\n2024-02-01 19:22:44,844 \n[MainThread ] [INFO ] [edae64c9-8257-44bc-955a-fda1bfc20a25] Clearing Lock file\\n\n"
}
}
Copy Files:
Copy the hotfix package file and the signature file (.md5) to the folder located at /home/ipcs
.
Start Hotfix installation: Once the files are copied, start the hotfix installation using the API.
The hotfix installation is involved with various states as described below:
The status of the hotfix install process can be monitored and tracked using the hotfix install status API. This API allows consumers to retrieve the current state of the hotfix install, providing insights into whether the process is in progress, completed successfully, or has encountered any issues.
During the INSTALLING state, which involves actively updating and modifying services,
both the Hotfix install status API and Authentication API may return various HTTP status codes such as 500
, 502
, 504
, or 401
.
These codes represent different scenarios, such as server errors (500
), bad gateway errors (502
), gateway timeouts (504
),
or unauthorized access (401
). To handle these situations effectively, API consumers should implement robust error handling mechanisms.
This includes implementing retry strategies for transient errors (500
, 502
, 504
) and ensuring proper management of authentication and authorization issues (401
).
In contrast, while in the REBOOTING state, the hotfix install status API service will be unavailable. The hotfix install status will transition to COMPLETED once the device successfully completes the reboot process.
Note: The hotfix installation can take upto 30 minutes, depending on the system specifications.
Start a hotfix installation on this device.
This API endpoint will return immediately upon successfully starting the hotfix installation process. Further inquiries must be made to the API via the status and logs endpoints to check the status of the hotfix installation after it has started.
User must have the hotfix:install
capability to perform this action.
Hotfix information that need to be installed.
hotfix-file-name | string |
{- "hotfix-file-name": "asbc-10.2.0.1-Hotfix-001-24395.tgz"
}
{- "status": "STARTING",
- "code": "STARTING",
- "message": "Hotfix install process initiated successfully.",
- "details": {
- "transaction-id": "edae64c9-8257-44bc-955a-fda1bfc20a25"
}
}
Get the current hotfix installation status.
This API endpoint will return the current hotfix installation status associated with the provided
transaction-id
. This value will be returned after a hotfix installation has been started and must be used get
the correct hotfix installation status.
User must have the hotfix:read
capability to perform this action.
Note: The recommended interval between Hotfix status API calls is 5 to 10 seconds.
transaction-id required | string
|
{- "status": "STARTING"
}
Get the current hotfix installation status.
This API endpoint will return the current hotfix installation status associated with the provided
transaction-id
. This value will be returned after a hotfix installation has been started and must be used get
the correct hotfix installation status.
User must have the hotfix:read
capability to perform this action.
{- "status": "LOGS_FOUND",
- "message": "Logs found",
- "details": {
- "logs": "Thu, 01 Feb 2024 12:04:39: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 \n- filename - /home/ipcs/sbce-10.1.2.1-87-23978-hotfix1-01182024.tgz, force - False, \ntransaction_file - /archive/log/icu/c6a9fbaa-a133-4ffc-bd17-a47d6eb46785.log\\nThu, 01 Feb 2024\n12:04:39: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - translation file \ncreated - /archive/log/icu/c6a9fbaa-a133-4ffc-bd17-a47d6eb46785.log\\nThu, 01 Feb 2024 \n12:04:39: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - Extracting \n/home/ipcs/sbce-10.1.2.1-87-23978-hotfix1-01182024.tgz to /usr/local/ipcs/temp/hotfix\\nThu, \n01 Feb 2024 12:04:46: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - \nStopping the application.\\nThu, 01 Feb 2024 12:04:47: hotfix-installer: INFO \n: c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - Application stopped successfully.\\nThu, \n01 Feb 2024 12:04:47: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - \ninstall_hotfix.sh found. Running the script at \n/usr/local/ipcs/temp/hotfix/sbce-10.1.2.1-87-23978-hotfix1-01182024/install_hotfix.sh\\nThu, \n01 Feb 2024 12:04:47: hotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - This \npatch is not valid to be installed on this version.\\nThu, 01 Feb 2024 12:04:47: \nhotfix-installer: INFO : c6a9fbaa-a133-4ffc-bd17-a47d6eb46785 - \nApplication started successfully.\\n\n"
}
}