☎️Integration between OMniLeads and PBXs

Integration between OMniLeads and PBXs

We will tackle this example using Issabel-PBX (a well-known free software project). However, everything explained here can be extrapolated as a configuration for any PBX with SIP support:

Note

The steps described in this section are applicable both to the scheme where OMniLeads is located on an exclusive host and the PBX on another, as well as to the case where OMniLeads runs on Docker coexisting within the same host as the PBX.

SIP Trunk Configuration on PBX

We select the creation of a new SIP trunk and complete the configuration with the following parameters:

If you have OMniLeads on one host and the IP-PBX on another host within the LAN network:

type=friend
host=XXX.XXX.XXX.OML
port=5161
disallow=all
allow=alaw
qualify=yes
secret=omnileads
fromuser=issabel
defaultuser=issabel
context=from-internal

• In case you have OMniLeads in the cloud and the IP-PBX in another host within the LAN network:

type=friend
host=XXX.XXX.XXX.OML
port=5162
disallow=all
allow=alaw
qualify=yes
secret=omnileads
fromuser=issabel
defaultuser=issabel
context=from-internal

• In case of running OMniLeads with Docker inside the IP-PBX base operating system:

type=friend
host=XXX.XXX.XXX.PBX
port=5163
disallow=all
allow=alaw
qualify=yes
secret=issabelOML
fromuser=issabel
defaultuser=issabel
context=from-internal

Note that the only thing that changes between the different possibilities is the port parameter. This is related to the fact that in OML a SIP port is used for each type of scenario: LAN, NAT cloud or Docker.

Once our SIP trunk is available, we proceed to check accessibility using the Asterisk CLI of the IP-PBX. We establish a bash session within the host where Issabel-PBX is running and launch the following command:

asterisk -rx 'sip show peers'

If all goes well, we should see OK on the output line for the new SIP trunk, either with port 5161, 5162 or 5163:

SIP Trunk Configuration in OMniLeads

Once the SIP trunk has been generated on the IP-PBX side, the counterpart corresponding to OMniLeads is generated.

If you have OMniLeads on one host and the IP-PBX on another host, we use the following configuration block (LAN PBX template):

type=wizard
transport=trunk-transport
accepts_registrations=no
sends_auth=yes
sends_registrations=no
accepts_auth=yes
endpoint/rtp_symmetric=no
endpoint/force_rport=no
endpoint/rewrite_contact=no
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pbx
remote_hosts=XXX.XXX.XXX.PBX:5060
inbound_auth/username=issabel
inbound_auth/password=issabelOML
outbound_auth/username=omnileads
outbound_auth/password=issabelOML

• In case you have OMniLeads on a cloud host and the IP-PBX on another host, we use the following configuration block (PBX NAT template):

type=wizard
transport=trunk-nat-transport
accepts_registrations=no
sends_auth=yes
sends_registrations=no
accepts_auth=yes
endpoint/rtp_symmetric=yes
endpoint/force_rport=yes
endpoint/rewrite_contact=no
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pbx
remote_hosts=XXX.XXX.XXX.PBX:5060
inbound_auth/username=issabel
inbound_auth/password=issabelOML
outbound_auth/username=omnileads
outbound_auth/password=issabelOML

• In case of running OMniLeads with Docker inside the IP-PBX base operating system, we use the following configuration block (Docker template):

type=wizard
transport=trunk-nat-docker-transport
accepts_registrations=no
sends_auth=yes
sends_registrations=no
accepts_auth=yes
endpoint/rtp_symmetric=yes
endpoint/force_rport=yes
endpoint/rewrite_contact=yes
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pbx
endpoint/rtp_symmetric=yes
remote_hosts=XXX.XXX.XXX.PBX:5060
inbound_auth/username=issabel
inbound_auth/password=issabelOML
outbound_auth/username=omnileads
outbound_auth/password=issabelOML

Once our trunk is effective, we proceed to check if Issabel is accessible from OMniLeads, using the OMniLeads Asterisk CLI.

asterisk -rx 'pjsip show endpoints'

Note

If we are running OMniLeads on Docker, to access the container that runs the Asterisk component of OMniLeads, we must run the command: docker exec -it oml-asterisk-prodenv , and from there the CLI is invoked. The output of the command should be similar to the following figure:

At this point, there is a SIP trunk between both telephone systems, leaving the configuration of call routing between both systems pending. Finally, we put emphasis on relating parameters between the SIP trunk configuration in Issabel with that of OMniLeads. A picture is worth a thousand words:

How to send calls from IP-PBX to OMniLeads

The following is a way to connect the IP-PBX resources (incoming routes, IVRs, ads, extensions, etc.) with OMniLeads. That is, for example, from an option of the company's main IVR, a call can be forwarded to an incoming OMniLeads campaign, or an extension can contact or transfer a call to an incoming OMniLeads campaign or agent.

This is completely feasible using the IP-PBX's custom extensions, in our exemplary case, Issabel-PBX:

Calls to OMniLeads inbound routes

The example then arises where you want to create a custom extension that, when dialed from another extension or invoked from some object in the PBX (IVR, inbound route, announcement, etc.), establishes a channel with OMniLeads, specifically targeting an inbound route, which can in turn send the call to an inbound campaign. On the one hand, then, we will have an inbound route in OMniLeads, targeting, for example, an inbound campaign:

Considering that the chosen DID was 098098, in the IP-PBX you have to generate a custom extension, where the Dial chain points to the SIP trunk against OMniLeads and the number sent is precisely 098098:

In the figure we highlight 3 elements: The extension number does not necessarily have to be identical to the number sent to OMniLeads (3). It can be any number, as long as the Dial string of the custom extension matches the DID of the OML incoming route (098098 for our example).

The trunk to point the custom extension to. This value must match the Trunk Name field in the SIP trunk against OMniLeads generated in the IP-PBX.

The number to be sent by the trunk has to match the DID of the OMniLeads incoming route. In this way, any extension of the IP-PBX will be able to dial or transfer a call to this custom extension and it will be sent to the corresponding incoming route in OMniLeads, to finally connect to an incoming campaign or the element assigned as the destination of the incoming route in OMniLeads.

As a final mention, it is clear that we can have as many custom extensions in the IP-PBX pointing to different OMniLeads incoming routes as we want.

Calls to OMniLeads agents

Starting from the following figure of the list of agents, let's take the agent Enzo Leandro. Note that his ID is equal to "300" and his SIP number is "1300". Therefore, when making a call to the webphone of said agent, a number consisting of the SIP number and his agent ID must be dialed. In our example, it would be 1300300:

Now, when generating the configuration in the PBX to be able to send calls to the agents, we have 2 alternatives:

1 Use an outgoing route from the PBX to OMniLeads, as indicated in the following figure:

In this case, any extension of the PBX can generate a call to an agent by dialing the combination mentioned in the previous paragraph.

Generate a custom extension for each OML agent, that is, the Dial chain of the custom extension will no longer be made up of an OMniLeads incoming route DID as was the case of linking with incoming routes, but will be a combination of the agent ID and their SIP number.

This is indicated in the following figure, where the extension 9001 associated with the IPPBX refers to the agent Adrian Belew, whose ID is 1 and his SIP Extension is 1006:

In the figure we highlight 3 elements:

The extension number does not necessarily have to be identical to the number sent to OMniLeads (3). It can be any number, as long as the Dial string of the custom extension matches the concatenation of the agent ID and its SIP number (10061 for our example).

The trunk to which the custom extension is to be pointed. This value must match the Trunk Name field in the SIP trunk against OMniLeads generated in the IP-PBX.

The number to be sent by the trunk has to match the concatenation of the agent ID and its SIP number (10061 for our example).

The procedure must be repeated for each agent to be linked within the IP-PBX. In this way, the PBX integrator can use flexible numbering for the extensions. Either of the 2 alternatives are viable and will obtain the desired result.

Calls from OMniLeads to PSTN and IP-PBX resources

Finally, we are going to generate outbound routing within OMniLeads, which allows agents and dialers to launch calls to the PSTN on the one hand, while allowing agents to dial or transfer calls to IP-PBX resources such as extensions, ring groups, call queues, etc., on the other hand.

Simply add a new outgoing route pointing the trunk to the IP-PBX:

In this way, the integration is fully functional, and both systems can make all types of calls and interactions.