Users capabilities

Introduction

The list of available features or behaviors of a Quobis SDK application is determined by the resulting capabilities of the user session. Right after the user makes its first successful login, a set of capabilities are established. There are three types of capabilities:

Service capabilities: defined by the sippo-server configuration and enabled services.
Stack capabilities: defined by the vendor of the signaling stack.
Session capabilities: defined by the wac-user or wac-domain configuration, where:
- Pruned capabilities: defined by configuration to remove specific features per user or domain.
- Forced capabilities: defined by configuration to add specific features per user or domain.

The applications will receive a set of capabilities following these conditions:

All capabilities are provided by active services (system functionalities).

All capabilities are limited by the stack (client browser or app limitations).

Administrators can add capabilities for extra features on the client side.

Administrators can limit any present capability.

Every user is able to retrieve their platform capabilities. The applications must adapt the user interface to the resulting status of the abilities granted. So, as a result, removing a capability, results on limit access to a feature.

GET https://wac:8001/sapi/capabilities/ HTTP/1.1
Authorization: Bearer ec3fe973ea047b6fd38228eb9f9b9661cbb5b0fdeac01ff13af1eef8

{
  "domain": [
    "stats",
    "alarms",
    "callcontrol",
    "chat",
    "contacts",
    "datapipe",
    "filetransfer",
    "login",
    "meetings",
    "login-token",
    "presence",
    "log",
    "settings"
  ],
  "user": [
    "[+c2cagent, +caller-extra-info]"
  ]
}

Service and stack capabilities

These capabilities define the available features for a user on an application:

Service capabilities: defined by the sippo-server configuration and enabled services.
Stack capabilities: defined by the vendor of the signaling stack.

Depending on the configuration of the sippo-server and the stack used in each deployment, the set of available features in a Sippo environment will be different. The running services at the sippo-server determinate the functionalities available in the server side and provided by the REST API.

In the same way, some vendor stacks provide functionalities that are not available in others (like data channel or call transfer), maybe due to what the manufacturer uses as Media Server or due to platform limitations.

In the end, the set of available features is exposed to the applications on top of SippoSDK. The final application can use this to adapt the user interface (for example, do not show a call transfer button is the underlying stack does not support it), or for any other purpose (configuration or monitoring).

Some functionalities can be provided by the Sippo AS, others by the stack and others are provided by both elements. In the latter case the Sippo AS has a higher priority. The next picture represents how is the routing process. Whenever an application invokes a method on the SippoSDK, it is routed to the vendor stack or to the sippo-server. This decision is made in the wac-proxy, one of the internals modules of SippoSDK.

For configuration purposes. To generate the session capabilities the AS needs to know what services are running and create an array with the corresponding capability of each one. This is accomplished by the service Capabilities:

(wac.ini)
...
[capabilities]
...

Configurable session capabilities

In addition to the Service capabilities and the Stack capabilities, there are capabilities defined by configuration:

Pruned capabilities: defined by configuration to remove specific features per user or domain.
Forced capabilities: defined by configuration to add specific features per user or domain.

These are very useful to customize the behavior of some users or domains without affecting the other ones.

Forced capabilities are just strings for the sippo-server, that will be exposed to the applications without changes. An administrator is free to add extra configuration capabilities needed by the application. This way, any application can define new capabilities.

These capabilities are configured during the user provisioning process, by adding an array of capabilities to the user.

Include a + as prefix to force (add) a capability to a user.
Include a - as prefix to prune (remove) a capability to a user.

The following example will edit a user to include an extra capability (caller-extra-info) and to remove another one (chat).

PUT https://wac:8001/sapi/users/5788b1a8e8f15d3472817350 HTTP/1.1
Authorization: Bearer ec3fe973ea047b6fd38228eb9f9b9661cbb5b0fdeac01ff13af1eef
Content-Type: application/json

{
   "domain": "quobis",
   "username": "alice",
   "email": "imalice@demo.quobis.com",
   "role": "user",
   "capabilities": [+caller-extra-info, -chat],
   "mobilePhone": ['1111111'],
   "alias": "masterOfTheUniverse"
}

Note

The update command must include all the fields that you require to add to the user, not just the ones to update, so username, domain, etc. must be included on each update operation.
Every application defines a set of specific capabilities that could be used by the application. Check the specific application documentation for a complete list of available forced capabilities.
A “+” or “-” sign needs to be added to the capability in order to take effect. Otherwise, adding just the capability name without the sign will have no effect at all.

Session capabilities

Complete list of Quobis wac capabilities. Each application will use them in order to provide more or less actions to their users.

Configuration options

call-from-chat: Ability to call directly from the chat section.
call-rehydration: Ability to recover an existing call when refreshing page.
caller-extra-info: Ability to access to extra context information about an incoming call.
change-camera: Ability to change the camera during call.
create-contacts: Ability to create contacts.
hide-incoming-domain: Ability to display or hide the domain of the caller substituting it for the configured one.
make-calls: Ability to make calls.
settings: Ability to show a form in the client applications with some configurable parameters of the WAC or the core network.
view-call-history: Ability to display call history.
view-contacts: Ability to display contacts.
view-meetings: Ability to display meetings.
whiteboard: Ability to create a whiteboard session.

Service capabilities

Capabilities implemented based on services running on the ``sippo-server``. These will be active if the service is correctly configured and running in the back-end system.

call-alarms: Ability to process received WebRTC stats data from the stack (stats-reporting) check defined alarms and trigger it if they match.
call-history: Ability to access to the call history endpoint.
callcontrol: Call routing and creation of one DB entry per call.
chat: Ability to create a chat (proprietary protocol) - If service present at sippo-server it prevails.
contacts: Ability to access to contacts endpoint.
credentials: The WAC acts as a storage service for credentials.
datapipe: Ability to create RAW data channels (based on Websocket, not WebRTC DataChannels) using Quobis AS as proxy.
filetransfer: Ability to send files using WAC as proxy. Chat capability is required.
forms: Ability to create user/agent forms to be filled by both.
log: The SDs sends local logs to the WAC for debugging purposes. Disabled by default.
login: Ability to login in the WAC with basic authentication (username, password).
login-token: Ability to login into the WAC by using a token-based mechanism, like OAuth2, which allows to use a third party authentication server.
meetings: Ability to view / create / remove meetings.
presence: Ability to receive presence updates about my contacts.
sessions: Sippo wac-session service is active on the Sippo AS.
stats: Ability to process received WebRTC stats data from the stack (stats-reporting) and send it to the Sippo AS for processing.

Stack relying capabilities

Capabilities implemented at SippoSDK level on the specific media integration. We can face limitations on this section based on the vendor running on your environment.

attended-transfer: Ability to transfer a call to a third user from the on-hold panel.
audio-call: Ability to create an audio only call.
audio-video-call: Ability to create a combined audio & video channel.
blind-transfer: Ability to transfer a call directly to a third party user.
collaboration-call: Ability to create a call without audio or video.
conference-hold: Ability to hold a call when using a conference.
conferences: Ability to create multi-endpoint calls.
datachannel: Ability to create ciphered RAW data channels end to end.
geturi: Ability to obtain a URI assigned by the gateway (ims credentials).
hold: Ability to put a call on-hold.
im: Ability to create a chat using the IM caps of the stack.
local-recording: Ability to record a call directly on the user’s browser.
media-update: Ability to manipulate and change the current audio / video streams.
multicall: Ability to have multiple 1-to-1 simultaneous calls.
network-reporting: Ability to receive periodic network reports checking the call quality on real-time.
screen-sharing: Ability to share screen and use it as video stream.
stats-reporting: The underlying stacks reports statistics about the current call.
video-call: Ability to create a video channel.