Platform roles

IvozProvider is a multilevel role provider solution.

The following images shows the different available levels and the relation between them:

This section will explain each of the available roles, describing their responsibilities and more important tasks.

Global administrator role

The global administrator role (operator in the image) is usually done by the installation responsible.

All options and platform features are visible to this role and usually is in charge of its maintenance.

Their most important task is to create Brands and configure them so they have the enough autonomy to properly use the platform:

• Configure their web access.
• Configure their brand portal look and feel: themes, colors, etc.

Apart from their main task, their global visibility and total access makes them responsible of:

• Monitor the platform so it keeps always UP & RUNNING

• Analyze platform logs to track possible errors.

• Polish the security mechanisms to avoid external attacks.

• Obtain global statistics of calls audio quality.

• Increase the available resources of the platform as long as is needed:

  • Increasing resources available in a standalone installation
  • Migrating, whenever required, to a distributed installation with multiple AS, media relays, etc.

To sum up, this role is the only one that has no limits within the platform, that’s why God is a term used in multiple places along this documentation.

Important

This role is responsible of maintaining the platform*, configuring it for the correct behaviour. This role doesn’t have any kind of limit and grants access to the brand operators.

Brand administrator role

Brand operator can access a portal with less sections available compared to the previous role. The general (God) administrator is in charge of providing an URL with credentials for its brand portal.

The most important task for brand operator is to create and configure clients so they can work properly.

Due to brand operators are also responsible of billing their clients and make sure the external calls are properly setup, it must also manage:

• Peering contracts with other IP providers for PSTN interconnection.
• Include all required client information for the billing process.
• Pricing plans that will offer to their clients, that will determine how match they pay for each call.
• Setup the routes for each outgoing call types based on their final destination
• Create the invoices for each billing period and send them to their clients.

As you can see, the task of brand operator has little in common with the global operator, but their importance is vital so the final users can use all the features includes in IvozProvider

Important

To sum up, brand operators grant access to their clients administrators and configure the platform to route and rate their calls.

Client administrator role

The client administrator has access to the portal supplied by the brand operator.

From its point of view, it has a virtual pbx in the cloud that must configure for its users.

To accomplish that, it’s required:

• Configure terminals, extensions and users.

• Configure the DDI incoming process with the proper logic:

  • Directly to an user
  • IVRs
  • Hunt groups
  • Faxes

• Give access to the final users to their web portal, so they can configure their profile options:

  • Call forward
  • Do not disturb
  • Call waiting

Important

To sum up, the client administrators are responsible for configuring the telephony system and make use of all the features available in IvozProvider.

Final user role

The final user has two different kinds of credentials, both supplied by its client administrator:

• User portal access credentials
• SIP credentials used to register terminals to IvozProvider

Through the user portal, it can browse their call registry and configure:

• Call forward
• Do not disturb
• Call waiting
• Displayed data when calling
• Geographical configuration

On the other hand, the SIP credentials allow users to configure their terminals to place and receive calls.

Note

The same SIP credentials can be used in multiple devices at the same time,generating what is known as parallel-forking: whenever a call is placed to an user, all the active devices will ring so the user can answer the call from any of them.