Using external and local policy to control Pexip Infinity behavior
You can extend Pexip Infinity's built-in functionality by using external and/or local policy to apply bespoke call policy and routing decisions based on your own specific requirements.
For example, you might want to apply different PIN rules depending upon whether a conference participant is an on-site employee or a remote visitor, or use a specific location for media handling for certain types of calls.
Pexip Infinity's external policy API allows a vast range of call policy decisions to be taken by an external system, based on the data sources that are available to that external system.
When external policy is enabled, rather than using its own database and systems to retrieve service and participant data, Pexip Infinity Conferencing Nodes send the external policy server a service request over a RESTful API and the server should respond by returning the requested data to the Conferencing Node.
For more information about using the external policy API, see Using the external policy server API with Pexip Infinity.
Local policy allows you to manipulate service configuration and media location data (that has been provided either via the external policy API, or has been retrieved from Pexip Infinity's own database) by running a jinja2 script against that data.
For more information about using local policy, see Enabling local policy.
Whether to use external policy, local policy or both?
External policy provides the ultimate flexibility in implementing your own bespoke decision-making logic. However it requires more system development effort to implement and adds a dependency on a third-party system that must provide real-time responses to requests made by Pexip Infinity over the external policy API. Developing a high availability / redundant external policy server that works well in the face of network partitions can be complicated, especially if your Pexip Infinity deployment is geographically distributed.
Local policy has a more limited scope than external policy in what it can control, but it is easier to implement and runs locally on each Conferencing Node.
External policy can be more powerful than local policy: local policy is stateless and therefore, for example, does not have access to information about any running conferences or their participants, whereas external policy can query any databases or APIs it wants, including the Pexip Infinity APIs.
You can configure Pexip Infinity to use both external and local policy depending on your requirements. When both external and local policy are enabled, external policy is applied first to retrieve the configuration data from the external system, and then local policy is applied to that retrieved data (which can then conditionally modify that data). The flow chart shows Pexip Infinity's processing logic when policy profiles are used.
Configuration data request types
The following table shows the types of configuration data that can be controlled, and by which types of policy:
|Type of data (policy requests)||Description||Controllable via external policy||Controllable via local policy|
Obtains the image to display to represent a conference participant or directory contact.
Obtains directory information — a list of device or VMR aliases and their associated names. This is used to provide phonebook information to Connect apps that are registered to a Pexip Infinity Conferencing Node.
Used to determine whether a device alias is allowed to register to a Conferencing Node.
Policy profiles specify how Pexip Infinity uses external policy and/or local policy to control its call policy and routing decisions.
They give you individual control over which types of policy to apply to each type of configuration data. For example, you could use both external and local policy to manipulate service configuration data, only local policy to manipulate media location data, external policy to provide participant avatars, and no policy at all (i.e. just use the data from Pexip Infinity's own database) for directory information and registration aliases.
Each system location is configured with a policy profile and that profile is then used by all of the Conferencing Nodes in that location whenever they need to retrieve configuration data. This means that you could use the same policy profile in all locations (and thus all Conferencing Nodes), or if required you can configure many different profiles with, for example, different local policy scripts or different external policy server URIs, and then assign different policy profiles to different system locations.
You must assign policy profiles to locations otherwise they will never be used. If you want to configure just one policy profile to be used globally you need to assign it to all of your locations.
See Configuring policy profiles for more information about how to set up your policy profiles.