In this post I will cover an integration case between Infinity and a web app. This is only a proposal and there are other ways to achieve a similar behavior.For example, we could use a Local Policy (Enabling local policy | Pexip Infinity Docs), but this has some limitations that are commented in the documentation.
In this use case the user will enter in a website, for example, it could be an insurance company website. And in a corner he will find a button to start a call.
Once the user click on the button, an ephemeral meeting will be created. The meeting will be displayed inside the same website and the user should also be able to invite other participants by sharing a link. After some time, the meeting shouldn’t be accessible any more.
Here is an example of how the interface could look like:
In this project we will have to develop two different components:
- Server: It will be our back-end service. It will validate the user and create the ephemeral meeting. The framework and language used for this element is not relevant for our implementation.
Before starting to get deeper in this use case, we should have in mind a detail of the Infinity architecture.
In a Infinity deployment you will have two kind of nodes:
- Management node: It’s the machine that controls the whole deployment and perform all the configuration sync between the rest of the nodes.
- Conferencing node: These machines are used by the customers and are geographically distributed. The user will join a Conferencing node and this node will send/receive the media (audio & video) and make transcoding if needed.
In you want to know more about this, check this page: Benefits of the Pexip Infinity distributed architecture | Pexip Infinity Docs
One of the first things that could come to your mind is to use the Management node API to create a meeting and delete it after the conference ends:
The main disadvantage of this approach is that the creation of the VMR (Virtual Meeting Room) will be requested to the Management node and then, it will be propagated to all the Conferencing nodes. This process will take some time (~30s), so it’s not valid if the user expects to join the conference immediately.
Another approach that is better for our case is to design an External Policy Server. With this approach, the direction of the request change. Before, it was our back-end service which will perform a POST request to create the VMR to the Management node. Now each Conferencing node will perform a GET request to our back-end service to validate an incoming call.
Here is an example of how the three elements can speaks with each other:
Here is an explanation of the previous sequence diagram:
- The Web App requests the Server to create a meeting. In this example, you will pass a “validUntil” parameter, but you can define also other parameters, such as “validFrom”. This way you define a meeting that has a starting and ending time.
This API endpoint and parameters are defined by you. The result of this request will be a string with the meeting alias (could be a UUID). This value should be saved in the Server database since it will be used in the following step.
You can find more information of the External Policy Server here:
Other thing that we could need is to retrieve conference information in real time. This can be achieve by using an event sink.
If you have any doubt about this example, don’t hesitate to leave a comment. And don’t forget to check our documentation and developer tutorials.