PDMS-SP 2.1.1 Feature Set Summary - Polycom...1. On the Poly endpoint (running UCS 6.1 or later),...

1

PDMS-SP 2.1.1 FEATURE SET SUMMARY

__________________________________________________________________________________________________________________________________________________________________________________________________________________

PDMS-SP 2.1.1: Feature Set Summary July 23rd, 2020

This document covers what’s new in PDMS-SP 2.1.1, and what’s supported today in PDMS-SP as a whole. The content will cover both web portal and API features. Details on the previous versions of PDMS-SP can also be found here.

If you have any questions, please contact [email protected].

Release History

Release Version Features

2.1.1 • Activity Logs

• Alert Thresholds: MOS and SIP Registration

• Claim Zero-Touch Devices for UCS

2.1.0 • Syslog Collection Enhancements

• Administration API: Base Profile Patch

• Self-Report Note Field

• Single and Bulk Unclaim Device

• Revoke Access Token API

• Platform Status Monitoring Portal

2.0 • PDMS-SP API Developer Portal (API v2)

• Administration APIs: Organizations and Devices

• Application APIs: UCS and OBi Edition REST API Relay

• Call Quality Statistics

• Single Sign-On at Web Portal

1.0 • Rebrand from OBiTALK Device Management Platform

• Support for Polycom UCS Devices

• OBiTALK Service API (API v1)

mailto:[email protected]

2


What’s New in PDMS-SP 2.1.1

Activity Logs

This feature gives service providers an audit trail view into certain actions in PDMS-SP. Activities are recorded by their timestamp, source, username and message (i.e. the activity). The “Activity” chart shows a history of the number of activities in the particular tenant, where the “Logs” show the activity details. Inside the Logs, you can click on one of them to capture more details about that particular log.

Figure 1. Screenshot from the Web Portal of the Activity Logs feature

The below table lists the activites that is supported and recorded in PDMS-SP 2.1.1. Note that some functions are not supported because PDMS-SP itself has not supported the actual functions of these.

Activity Log Type Web Portal API

User Login Y Y

User Logout Y Y

User Create Y N/A

User Delete Y N/A

User Update Y N/A

Organization Create Y Y

Organization Update Y Y

Organization Role Create Y N/A

Organization Role Delete Y N/A

Organization Role Update Y N/A

Base Profile Update Y Y

Device Claim Y Y

Device Unclaim Y Y

3


Alert Thresholds: SIP Registration and MOS Score

PDMS-SP now supports the ability to alert a user when a device on their deployment does not meet up to certain thresholds set by the new PDMS-SP interface. With that, users will also gain the ability to set thresholds of the SIP Registration and MOS-LQ scores in the given user interface.

Alerts Home Page:

When you select the Alerts page from the main menu, you will be first directed to a page where all the generated alerts are shown.

Figure 2. Screenshot from the Web Portal of the Alerts Home page, showing all the alerts that have been generated from the set

thresholds.

You can then go to the Alert Settings page to create, configure, or terminate the available alert thresholds. Within these threshold items, you can zoom into one of them and just display the alerts generated by the threshold in subject. Over in this page, there is also the Tags column, where it would show all the Tags that device in subject has, not particularly what’s set on the Alert item. Tags:

So how do you organize what devices should get alerts? In PDMS-SP 2.1.1, we introduce the concept of Tags. This is to organize a pool of devices in your PDMS-SP tenant or organization together by a certain label or designation (i.e. the Tag). Then, you can tie the Tags to the Alert item so that the alert is only based on your set pool of devices. Tags can be set through the configuration of the Poly endpoint, which can be either set from your provisioning server, or from the device webpage.

1. On the Poly endpoint (running UCS 6.1 or later), provision the parameter deviceAnalytics.note

from your provisioning server or device webpage with the following syntax:

deviceAnalytics.note = "tag{delimiter}tag{space}{tag1}{delimiter}{tag2}

{delimiter}………{tagN}"

where N = 1, 2, 3, 4, …. and the {delimiter} is any combination of non-space characters (e.g. |)

4


An example configuration file would be as follows :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<CONFIG>

<OBiTALK

deviceAnalytics.note = "tag|tag PolyHQ|San Jose|Server 3|United

States"

/>

</CONFIG>

The delimiter is placed there to indicate to the system the separation between the tags. In the example above, “|” is being used to separate PolyHQ, San Jose, Server 3, and United States tags. The delimiter is also defined by the character between tag and tag, so the system knows what the delimiter to expect and that other characters potentially in the tag string itself is not treated as a delimiter.

Note: Configuration for tags cannot be concatenated together with a self-report note field. In other words, if you want to use tags, no characters before the tag{delimiter}tag character can be placed in the deviceAnalytics.note parameter.

Alerts Settings:

This Alerts Settings page is where you set your Tags and your thresholds (now supports MOS-LQ and SIP Registration).

Figure 3. Screenshot from the Web Portal of the Alerts Settings page, showing all the set alert items that has the threshold

configuration.

Over at the Create New Alert button, a pop-up will show the configuration you can set to create the new alert item.

Creating Alerts:

1. Go to Alert Settings

2. Click the + Create New Alert button

3. Specify the Name of the Alert

4. Over at the Tags field, chose one of the tags displayed in the dropdown, or start typing the tags to

do a smart search of the tags available. Note: Tags would have to be configured on the device

first before it can appear here.

5. Select either of the threshold for this Alert item

a. MOS-LQ (Near-end): To raise an alert if the set minimum threshold MOS score of a

certain calls, and for a minimum number of seconds of that call duration is met.

b. SIP Registration: To raise an alert if the SIP Registration of that device is not registered.

5


6. Click Create.

Figure 4. Screenshot from the Web Portal of the Alerts Settings page, showing the pop-up box to set the configuration of the alert.

Note: Once you create an alert, you cannot edit the thresholds anymore. If you need to fix a certain Alert item, please delete it and create a new one.

Duplicating Alerts:

1. Go to Alert Settings

2. Click the icon to duplicate an existing Alert.

3. Make changes on Name, Tags, or either of the alert thresholds

4. Click Create.

View all generated alerts from a single Alerts item:

A. Go to Alert Settings

B. Click the icon

C. You will then be transported to a page similar to the Alerts Home page, but it will only show

entries generated only by this Alert item.

Requirements:

• Firmware:

o VVX: 6.1.0

▪ For support for Tags, it will require UCS 6.1.0 or later. Note: In the time of writing

of PDMS-SP 2.1.1, groupings for Alerts can only use Tags.

o Trio: Not yet supported

o OBi Edition devices: Not yet supported

• Configuration:

deviceAnalytics.note =

"tag{delimiter}tag{space}{tag1}{delimiter}{tag2}

{delimiter}………{tagN}"

6


Claim Zero-Touch Devices for UCS

This is a feature where UC Software-based devices (UCS) can be onboarded and bootstrapped into a set of UCS configs (e.g. the service provider-maintained provisioning URL) via the PDMS-SP web portal. The result of implementing this feature will give you a cloud-native experience deploying UCS endpoints, which provides benefits to end-users such as:

1. Self-serving themselves to onboard Poly devices to your service.

2. Purchase any Poly UCS-based endpoint from the channel without any pre-provisioning costs,

hence wider availability and less SKU-variant complexities in channel distribution.

As for the service provider themselves, the benefit to using this is the following:

A. One interface for all Poly device onboarding (No need to maintain both ZTP and PDMS-SP).

B. Eliminates the need to manage Ref IDs in Polycom ZTP.

C. New partners would not need to sign-up for ZTP to get onboarding services from Poly.

Note: The service will use Polycom ZTP as a means to redirect the UCS devices to PDMS-SP. Firmware and network requirements would still need to be followed for deployments.

Figure 5. Schematic of the flow of device onboarding using Polycom ZTP at PDMS-SP.

The mechanics of this feature anchors on the fact that UCS natively connects to ZTP at the device’s first bootup. ZTP then basically does a redirect to PDMS-SP, and PDMS-SP would serve the tenant assignment and its ZT Profile. See Figure 5 above for the schematics of how the ZTP fits into the PDMS-SP ecosystem. Keep in mind also that Step 2 will never happen unless the device.prov.ztpEnabled

is set to "1" which usually gets automatically set during a device factory reset.

Note: Before the device would connect to PDMS-SP, the service provider would have already need to setup the ZT Profiles and prepare the MAC addresses to claim into their PDMS-SP tenant.

https://support.polycom.com/content/support/north-america/usa/en/support/voice/zero-touch-provisioning/zero-touch-provisioning-solution.html

7


ZT Profile Setup:

The ZT Profile is a profile served from PDMS-SP during a device’s onboarding to the cloud service. This would contain the UCS configuration file that is to be provisioned. As an administrator or if the user has the appropriate permissions, you are able to create a UCS ZT Profile and then edit them afterwards. You can view the components of what you need to do get started from Figure 6 and 7.

Figure 6. ZT Profiles webpage at PDMS-SP with captions showing all the components inside the page.

Figure 7. Webpage after pressing Create New ZT Profile with XML Editor built-in.

8


Claim Device:

After you’ve set your ZT Profiles in the fashion you like, its time to claim your devices to the PDMS-SP database. Here, you will associate the device’s MAC address, the sub-organization and the ZT Profile. Remember to do this before you turn the device online, or otherwise a factory reset is required.

Figure 8. Claim Device webpage with captions showing the components inside doing a single claim device with the new UCS ZT

Profile.

Figure 8 shows the components needed to be inputted so that the claim device process can go through successfully. The ZT Profile dropdown will show both the OBi and the UCS ZT Profiles at the same time. If the wrong ZT profile is assigned and fed to the device, it will just pass a blank XML file, hence no profile will pass on the device when it gets onboarded.

Note: If the claimed device already has an association to a Polycom ZTP tenant, the claim device feature will not work, and the device will remain in a “Pending” ZT state.

Note: If the claimed device already has the parameter obitalk.accountCode configured on it,

the feature will not work, and the device will stay into that tenant. Also if the device is successfully claimed, then later gets provisioning to a different value in its obitalk.accountCode,the

device will be moved and go to that tenant. Please ensure device is properly secured (e.g. change the admin password from default).

This Claim Device action can be done via a CSV file uploads under “Claim multiple devices.”

Requirements:

• Firmware:

o VVX: 5.8.0

o Trio: 5.9.1

• Configuration:

o device.prov.ztpEnabled = "1"

o obitalk.accountCode to be blank and not configured

• On-site Network:

o Whitelist all PDMS-SP requirements plus Polycom ZTP requirements (ztp.polycom.com):

▪ 3.219.214.168 (Port 80, 443)

▪ 18.235.37.112 (Port 80, 443)

9


Features Supported as of v2.1.1

PDMS-SP Web Portal Feature Matrix

The table below shows the differences in support in different software streams of Poly voice endpoints with respect to the PDMS-SP Web Portal. This data is only relevant as of the launch of PDMS-SP v2.1.1—will be subject to change as software development continues.

OBi Voice Adapters VVX OBi Edition

Software VVX UC Software

Online/Offline Status Y Y Y

SIP Registration Status Y Y

Y

(Without Registration Status Details)

Configuration Read Y Y Y

Configuration Write Y Y Via XML Format

Add Device (non ZT) Y Y N

Delete Device (non ZT) Y Y N

Claim Device (ZT) Y Y Y

Onboarding via Config (Late Binding)

N/A N/A Y

Unclaim Device (ZT) Y Y Y

Remote Provisioning via Cloud-Hosted Profile

Y Y N

Base Profiles – for day-0 bootstrapping

Y Y N

Base Profiles – for day-2 provisioning

Y Y N

Reboot - individual Y Y Y

Reboot - mass Y Y Y

Factory Reset - individual Y Y Y

Factory Reset - mass Y Y Y

Resync Provisioning Y Y Y

Remote PCAP OBi5 Series Only Y Y

Remote Syslog (Start/Stop) Y Y Y

Edit Note Alias Y Y Y

Sub-Organization Support Y Y Y

SIP ALG Test Y Y N

Map Y Y Y

Snapshot Y Y Y

Firmware Update From PDMS-SP

Y Y N

Call Quality Statistics Y Y Y

(With VQMon License)

10


PDMS-SP API Feature Matrix

The table below shows the differences in support in different software streams of Poly voice endpoints with respect to the PDMS-SP API. This data is only relevant as of the launch of PDMS-SP v2.1.1—will be subject to change as software development continues.




SP Registration Status Y Y Y

Fetch Firmware Version Y Y Y

Claim Device Y Y Y

Un-claim Device Y Y Y

Fetch Parameters Y Y use UCS REST API

Write Parameters Y Y use UCS REST API

Reboot Y Y Y

Factory Reset (All) Y Y Y

Factory Reset (Granular) Y Y N


Last Update / Contact Y Y Y

Service Activation Code Y Y N

Onboarding Service Tag N/A N/A Y

Applications REST API Set Y Y Y

Manage Organizations Y Y Y

Remote PCAP N N N

Remote Syslog Y Y Y


11


Previous Releases

12


PDMS-SP 2.1.0: Feature Set Summary February 18, 2020

This document covers what’s new in PDMS-SP 2.1.0, and what’s supported today in PDMS-SP as a whole. The content will cover both web portal and API features. Details on the previous versions of PDMS-SP can also be found here.

If you have any questions, please contact [email protected].

Release History


2.1.0 (new) • Syslog Collection Enhancements

• Administration API: Base Profile Patch

• Self-Report Note Field

• Single and Bulk Unclaim Device

• Revoke Access Token API

• Platform Status Monitoring Portal






1.0 • Rebrand from OBiTALK Device Management Platform

• Support for Polycom UCS Devices

• OBiTALK Service API (API v1)

What’s New in PDMS-SP 2.1.0

Syslog Collection Enhancements

For Poly endpoints running UC Software, fetching logs from the local phone storage via the web portal is already supported. However, this feature set is limited on the phone’s storage, limiting a service provider’s ability to troubleshoot. This feature-set to initiate a start and a stop for a syslog capture that is streamed to PDMS-SP. The feature also comes in both forms—the web portal and the API.

The legacy feature Fetch Device Log is still supported in this menu. Just press the button to initiate the fetch, and then the download link will appear. This feature, however, is not available via a REST API call.


13


Figure 1. Screenshot from the Web Portal when there is (left) an inactive session with download link from previous session and

(right) an active session with download link of the current session

Feature Specifications (applicable on both Web Portal and API):

• The maximum size for a Syslog file is 16MB. When the capture hits the size limit, it will

automatically stop the session.

• While the Syslog capture is running, it can be downloaded in the middle of the session. However,

it will only capture at intervals of 200KB at this mode. When the capture is stopped, however, the

whole log will still be recorded.

• The Logging Configuration and Timeout entries are optional. If nothing is configured upon the

Start Syslog execution, Timeout will be set to 7 days (i.e. 10080 minutes).

• The Syslog render level is always set to DEBUG (0) in the Web Portal. In the REST API, you can

change this to other render levels, but DEBUG (0) for syslog captures are highly recommended

for any session.

• The Start Syslog button cannot be executed if a session is already running. If you are seeing this

disabled, a session is either already started from the web portal or from the REST API.

• If the phone reboots, the syslog session will still remain active, but the logs will stop populating.

Please make sure to Stop, then Start a new session for each phone boot cycle.

• Should you require logs of phones during reboot, you can still use the Fetch Device Log from the

local phone.

As it relates to Poly endpoints running OBi Edition, what’s new here is just the APIs to initiate the Start and the Stop. Keep note, however, that the same REST API in PDMS-SP is used for UC Software and OBi Edition. The function on the web portal, on the other hand, is already supported before this PDMS-SP v2.1.0 release.

14


REST API Commands:

Visit the links of each API below learn more about each respective functions and required formats.

• POST /devices/{deviceid}/syslogs: to start the syslog session of a single device and

procure the syslogid. The syslogid is the key or string that labels the syslog session capture in

which is used to fetch its status or stop the capturing session.

• GET /devices/{deviceid}/syslogs: to get the status and syslogid of a syslog session of a

single device.

• GET /devices/{deviceid}/syslogs/{syslogid}: similar to the GET request without the

{syslogid} but can now specify the syslogid in the request URL itself.

• PATCH /devices/{deviceid}/syslogs/{syslogid}: to stop the syslog session of a

given syslogid.

Example PATCH /syslogs/{syslogid} Request:

PATCH https://pcs-api-na.obitalk.com/api/v2/domain/77123456/devices/856

7890/syslogs/94nag46fy622nxg

{

"status": "stop"

}

Response:

{

"data": [

{

"id": "94nag46fy622nxg",

"start_time": "2020-02-11T19:26:36+00:00",

"stop_time": "2020-02-18T19:26:36+00:00",

"status": "stop",

"size": 16000000,

"download_url": "https://service.obitalk.com/obinet/services/api/

ssl/downloadslog?id=94nag46fy622nxg"

}

]

}

Note: A typical operation would be to start the syslog using POST, then procure the information with GET with the provided download link during the currently running session (optional), then PATCH to stop the syslog capture with another GET to grab the final results after it is stopped.

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/syslogs/post

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/syslogs/get

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/syslogs/%7Bsyslogid%7D/get

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/syslogs/%7Bsyslogid%7D/patch

15


Administation API: Base Profile Patch

Poly endpoints with OBi Edition support the concept of Base Profiles, where devices can subscribe to a single XML profile in PDMS-SP and treats it as an auto-provisioned configuration. Each device subcribes to a single Base Profile in PDMS-SP, which can be changed at any time. This new enhancement adds another entity to the JSON Body Request on the existing PATCH /devices/{deviceid} API. This feature is only supported in OBi Edition at the time of writing.

Example Request:

PATCH https://pcs-api-na.obitalk.com/api/v2/domain/77123457/devices/8

567890

}

"org": "7712345",

"baseProfile": "21"

}

Note: both JSON objects are optional. The example above sets the device to an organization inside your PDMS-SP tenant by organization ID and the Base Profile to Base Profile 21. The following action from the REST API will be similar to this function in the web portal below:

Figure 2. Screenshot from the Web Portal on a VVX350 running OBi Edition that is about it have its Base Profile assignment changed.

16


Self-Report Note Field

When your list of devices managed in PDMS-SP grows large, searching for a particular device becomes a more difficult task. Searching these devices by MAC Address or Serial Number is also not quite the preferred input to a support person of a service provider hotline.

Under the Manage Devices page in the web portal, the Notes field is now more dynamic with the use of this feature. A service provider can simply provision a parameter in the UCS-running Poly endpoint using their provisioning server, and then the parameter value string gets passed to PDMS-SP’s Notes Field (see Figure 3 for reference). Once the UCS parameter gets provisioned on the phone and passed through the Note field in PDMS-SP, the Manage Devices search bar can be used to filter out the devices that contain the characters of the search query.

A couple of use cases that the Notes field can help a service provider:

1. A support staff gets a call, and would only has information about their phone number, not their

MAC address.

2. A support staff tries to filter all phones labelled by their Customer name in the Notes field any

custom tags provided by their call control’s provisioning server and check their Registration status

in the Manage Devices page

3. An engineering staff wants to do an inventory count of phones on all phones that are labelled in

the Note field based on geographical region.

Requirements:

• Firmware:

o VVX: 6.0.0

o Trio: Not yet supported

o OBi Edition devices: Only applicable using Cloud Configuration

• Configuration:

o deviceAnalytics.note="any string here"

Figure 3. Screenshot from the Web Portal showing the Notes field and its search bar in (left) the Manage Devices page and (right) the Device Configuration page

17


Setup Instructions:

1. Go to the Edit Note Alias menu, enable UCS Alias and click Update to save the changes.

(Note: The Obi Alias menu is only applicable to OBi Edition and only on units that use the Cloud

Configuration parameters.)

2. On the UCS-running Poly endpoints, config the parameter deviceAnalytics.note to whatever string

value you want the Notes field to display. An example config file is provided below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<CONFIG>

<NOTE

deviceAnalytics.note = "+14088906000"

/>

</CONFIG>

3. Then under the Device Configuration page, the Device Note field should populate whatever

parameter value the deviceAnalytics.note has on that particular device.

Note: The Self-Report Note Alias also follows a precedence hierarchy—that is, if there is already a value entered in the Device Note field from an user in the web portal, the UCS Alias would not take over that particular device. In other words, only empty Device Note fields can take the self-reported Note alias.

Single and Bulk Unclaim Devices

PDMS-SP now supports an Unclaim Device feature at the web portal. PDMS-SP users can their remove UCS or OBi Edition-running Poly endpoint in its Device Configuration page (single) or at the Tools page where a CSV file full of MAC addresses or Serial Numbers can be uploaded and processed (bulk).

For UCS-running devices, especially note that the configuration that enables the PDMS-SP connection must be disabled. If an Unclaim Device request is pushed to the UCS-running device and the requirements are not met, the device will come back to PDMS-SP as if nothing happened.

For OBi Edition-running devices, do not forget to recustomize afterwards so that the Zero-Touch customization profile is also reset at the firmware level.

18


Figure 4. Screenshot from the Web Portal showing the (top) single Unclaim Device and (bottom) bulk Remove Devices

Requirements for UC Software

• Minimum Firmware Version:

• VVX: 5.8.0

• Trio: 5.9.1

• Parameters:

• feature.obitalk.enabled="0"

• obitalk.accountCode="" (leave empty)

Requirements for OBi Edition

• Minimum Firmware Version:

• VVX x50: 6.3.1.0

• VVX D Series: 7.0.0

• OBi3 Series: 3.0.1.5379

• OBi5 Series: 4.0.2.5429

• Parameters: None

• Recustomization Steps:

• (Option 1) Dial out the digits, separated by comma: ***, 0, 8888#, 1, 1#, 1.

• (Option 2) Keep the device online and open a support ticket by emailing to

[email protected], providing the MAC or Serial of the device.

Note: Keep in mind that there might be terminologies like “Delete” or “Remove” might exist around the web portal. “Delete” is for OBi Edition-running devices where it is onboarded using Add Device where Unclaim is for bootstrapped devices. “Remove” is applicable for both “Unclaim” and “Delete.”


19


Revoke Access Token API

This is an enhancement of allowing a way to ‘logout’ after you authenticate into PDMS-SP APIs using OAuth 2.0 tokens. Once requested, there are two cases that this can happen. Example shown below.

Method and URL:

GET https://pcs-api-na.obitalk.com/api/v2/domain/[orgid]/revoke-token

• Case 1: Response when revoke a valid token (HTTP Status 204 No Content)

• Case 2: Response when trying to revoke a token already revoked or calling other APIs using

revoked token.

}

"fault": {

"faultstring": "Access Token not approved",

"detail": {

"errorcode": "keymanagement.service.access_token_not_approv

ed"

}

}

}

Platform Status Monitoring Portal

PDMS-SP users can view a page that displays uptimes of all servers for the past three months. Also in the portal, users can sign up for alerts when there would be a planned or unplanned outage. Visit https://status.obitalk.com after you login to get to this portal.

Figure 5. A portion of the PDMS-SP Platform Status Monitoring Portal Screenshot, showing uptime and link to subscribe updates

https://status.obitalk.com/

20


Features Supported as of v2.1.0


The table below shows the differences in support in different software streams of Poly voice endpoints with respect to the PDMS-SP Web Portal. This data is only relevant as of the launch of PDMS-SP v2.1.0—will be subject to change as software development continues.





Y





Delete Device (non ZT) Y Y N

Claim Device (ZT) Y Y N

(Use Polycom ZTP)

Onboarding via Config (ZT) N/A N/A Y

Unclaim Device (ZT) Y Y Y


Y Y N

Base Profiles – for day-0 bootstrapping

Y Y N


Y Y N


Reboot - mass Y Y Y





Remote Syslog (Start/Stop) Y Y Y



SIP ALG Test Y Y N

Map Y Y Y

Snapshot Y Y Y


Y Y N



21



The table below shows the differences in support in different software streams of Poly voice endpoints with respect to the PDMS-SP API. This data is only relevant as of the launch of PDMS-SP v2.1.0—will be subject to change as software development continues.






Claim Device Y Y N

Un-claim Device Y Y N

Fetch Parameters Y Y use UCS REST API

Write Parameters Y Y use UCS REST API

Reboot Y Y Y









Remote PCAP N N N

Remote Syslog Y Y Y


22


PDMS-SP 2.0: Feature Set Summary October 9, 2019

This document covers what’s new in PDMS-SP 2.0. The content will cover both web portal and API features.







PDMS-SP API Developer Portal (API v2)

Poly’s newest developer portal for PDMS-SP APIs. Visit https://api-developers.obitalk.com/ to access.

This new portal is the hub for all supported PDMS-SP cloud management APIs available today and the guides on how to use each of them. To know how to authenticate and start using the APIs, please start on the “Get Started” menu in the API Developer Portal webpage.

Administration APIs

These are sets of APIs that allow a PDMS-SP user to manage device and organizations in an API form. For Organizations

• New Actions: Create, Delete, Modify

• Manage organizations in an API form so service providers and enterprises can use their own

front-end to manage multiple tenants in PDMS-SP.

• Enhanced the GET /domain/{orgid}/orgs/{org} API to include the Onboarding Service

Tag for onboarding devices running UC Software

For Devices

• Resync to Provisioning Server URL

• Factory Reset Devices

https://api-developers.obitalk.com/

23


Application APIs

Both VVX phones with UC Software and OBi Edition Software have their own set of HTTP commands to launch actions or applications to the device in a programmatic fashion. These APIs allow these particular sets of HTTP commands to be remotely executed from the PDMS-SP cloud, giving the added benefit of cloud-manageability, and eliminating the user’s need to host their own servers.

Newly added support:

• UCS REST API through PDMS-SP APIs (only compatible with UCS v6.1.0 or later)

• OBiXML Application Commands through PDMS-SP APIs By using PDMS-SP APIs, users can now wrap the HTTP application commands around the PDMS-SP REST APIs via POST /domain/{orgid}/devices/{device}/ucsapi (for UC Software) or POST

/domain/{orgid}/devices/{device}/obiapi (for OBi Edition Software).

• For more information on UC Software REST APIs, please visit:

https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-

documents/en/2018/ucsoftware-restapi.pdf

• For more information on OBi Edition OBiXML Applications, please visit:

https://support.polycom.com/content/dam/polycom-support/products/voice/business-ip-phones-

obi/user/en/obi640-api-developer-guide.pdf

Call Quality Statistics

Polycom endpoints (with UC Software or OBi Edition Software) can now report daily call quality status and call data to the PDMS-SP portal. Check the status report from the Statistics page or in the Device Configuration page when troubleshooting at a per-device basis. The call quality statistics are presented in two segments: Voice Quality (Upload Time, MOS Score, Duration, Delay, Packet Loss, Call ID) and the Call Data Record (Upload Time, Direction, Duration, Disposition, Call ID). As for the feature set today, these statistics are collected at every end of the call. Newly added support:

• Fetch Call Quality Statistics of Single Devices in your Organization via Web Portal

• Fetch Call Quality Statistics of All Devices in your Organization via Web Portal

• Fetch Call Quality Statistics of Single Devices in your Organization via API

For the Polycom endpoints to report these statistics, it must meet firmware and license requirements. Requirements for UC Software

• Minimum firmware requirement:

o VVX: 5.8.0

o Trio: 5.9.1

Note: iLBC, OPUS, G.719, L16.16, Siren22, G.726, SILK, and G.722.3 codecs are not supported

for MOS Score collection on current latest firmware (UCS v6.1)

• Set the following parameters and values from the phone (all non-default values):

• voice.qualityMonitoring.rtcpxr.enable="1"

• voice.qualityMonitoring.collector.enable.session="1"

• VQMon licenses (for phones manufactured before July 2017 only). See below table for part

numbers for the licenses.

https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-documents/en/2018/ucsoftware-restapi.pdf

https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-documents/en/2018/ucsoftware-restapi.pdf

https://support.polycom.com/content/dam/polycom-support/products/voice/business-ip-phones-obi/user/en/obi640-api-developer-guide.pdf

https://support.polycom.com/content/dam/polycom-support/products/voice/business-ip-phones-obi/user/en/obi640-api-developer-guide.pdf

24


License Poly Part Number

VQMon Software Certificate Site License (5000 units) 5150-48378-001




Requirements for OBi Edition Software

• Minimum firmware requirement:

• VVX x50 Series: 6.3.1.0

• VVX D Series: To be supported

• OBi Voice Adapters: To be supported

• Set the following parameters and values from the phone (all non-default values):

• X_DeviceManagement.Monitoring.SyncCQM = true

To access the cloud APIs, please refer to page go to https://api-developers.obitalk.com/. Once you have all the authentication pieces for your PDMS-SP tenant ready, refer to the PDMS-SP API Developer Portal under these links

1. Voice Quality: https://api-developers.obitalk.com/docs/pdmssp-

product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/vq/get

2. Call Data Record: Voice Quality: https://api-developers.obitalk.com/docs/pdmssp-

product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/cdr/get

You can request the data to be filtered based on a given time (in UTC time zone). If nothing is specified, then it will respond the GET call with data with the last seven days.

https://api-developers.obitalk.com/

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/vq/get

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/vq/get

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/cdr/get

https://api-developers.obitalk.com/docs/pdmssp-product/1/routes/domain/%7Borgid%7D/devices/%7Bdevice%7D/cdr/get

25


Single Sign-On at Web Portal

PDMS-SP now supports 3rd Party Single Sign-On (SSO) via OAuth2 for your organization. Your PDMS-SP account will be need to get enabled with the new SSO by our SP Support team. Please contact them at [email protected] to request access. While requesting, you can also ask to reserve one or more Email Domains so that users can sign-on at the regular PDMS-SP login page (https://www1.obitalk.com) with an email address with the configured email domain instead of the logging in from the designated SSO Landing Page URL.

Once you have access, you will see a new menu in PDMS-SP called “Single Sign-On” with an exclamation point icon beside it. Once you have filled in the appropriate blank fields, the exclamation point icon will disappear, indicating that you have successfully configured it to your SSO domain.

Below here are the parameters in PDMS-SP to setup the SSO feature:

Parameter Description Type

Client ID Client ID of ITSP’s SSO provider. Required

Client Secret Client Secret of ITSP’s SSO provider. Required

PDMS-SP Landing Page URL

Originally configured by PDMS-SP admin. Read-only

Authorization Endpoint

Authorization endpoint used to authenticate resource owners and obtain authorization grant.

Required

Authorization Callback URL

Originally configured by PDMS-SP admin. Read-only

Token Endpoint Token Request endpoint used to exchange authorization grants for Access Tokens.

Required

User Info Endpoint User info endpoint used to retrieve authorizing user information - i.e. username, email.

Required

Once configured, users can start utilizing SSO to PDMS-SP by either two methods:

1. Go to the Landing Page URL per the Read-only parameter. After a successful login at your

landing page, the user should be redirected to the PDMS-SP web portal.

2. If given Email Domain(s) are set by your PDMS-SP administrator, go to

https://www1.obitalk.com/obinet/, enter the email address with your designated Email Domain

and leave the password field blank. Then click “Sign In” and it should redirect to the Landing

Page URL for the SSO.


https://www1.obitalk.com/

https://www1.obitalk.com/obinet/

26


Features Supported as of v2.0


The table below shows the differences in support in different software streams of Polycom voice endpoints with respect to the PDMS-SP Web Portal. This data is only relevant as of the launch of PDMS-SP v2.0—will be subject to change as software development continues.





Y





Claim Device (ZT) Y Y N

(Use Polycom ZTP)

Onboarding via Config N/A N/A Y


Y Y N

Base Profiles – for bootstrapping

Y Y N


Y Y N


Reboot - mass Y Y Y





Remote Syslog Y

(Start/Stop)

Y

(Start/Stop)

Y

(Fetch)



SIP ALG Test Y Y N

Map Y Y N

Snapshot Y Y Y


Y Y N



27



The table below shows the differences in support in different software streams of Polycom voice endpoints with respect to the PDMS-SP API. This data is only relevant as of the launch of PDMS-SP v2.0—will be subject to change as software development continues.






Claim Device Y Y N

Un-claim Device Y Y N

Fetch Parameters Y Y N

Write Parameters Y Y N

Reboot Y Y Y









Remote PCAP N N N

Remote Syslog N N N


© 2020 Plantronics, Inc. All rights reserved. Poly and the propeller design are trademarks of Plantronics, Inc. The

Bluetooth trademark is owned by Bluetooth SIG, Inc. and any use of the mark by Plantronics, Inc. is under license. All

other trademarks are the property of their respective owners.

Date post:	18-Mar-2021
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

PDMS-SP 2.1.1 Feature Set Summary - Polycom...1. On the Poly endpoint (running UCS 6.1 or later),...

Documents