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",
    "recording"
  ],
  "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.

_images/capabilities.png

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.

recording

Ability to record a call (infrastructure mode).

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.