Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

The dialer is a complex system of applications, and in order to help you integrate with the dialer we cover a few topics here of what is required and why you need to do things in certain ways.

This however only covers so much, we always recommend that our integrators keep good communication with us, so that we can help and explain as much as possible. Integrations are our highest priority. 

Overview 

The dialer is basically a giant asynchronous state machine with a lot of moving parts under the hood, the API you consume does a lot of orchestrating in backend.
The dialers API has 2 parts, the RESTful section, which you use to issue commands to the dialer and a notification system.  

RESTful API

Use the RESTful API to issue commands to the dialer, do not use this to check state, its an anti-pattern and will result in many hard to debug bugs in your application.

Notifications

We use redis's PubSub and Lists for notifications, because it's the simplest queueing mechanism for integrators to integrate with, and is very low latency. 

Basic Flow

The basic flow is that you will issue a command to the API and wait for a notification to confirm that that state change has happened.

 

which brings us to the most important principle, do not try to manage state in your system, rather respond to the dialers notifications

 

So if you want to add an agent to a running campaign and make him available for calls, wait until the dialer sends you the notification to say that the state change has succeeded, instead of assuming it has after doing the RESTful API call. 

Conclusion

In closing react to the notifications and trust that the dialer will manage the state properly

  • No labels