Inbound routing and callflows

An incoming call always follows the same path: your provider sends it in, Voiplix looks up the dialled number in the DID list, and hands the call to whatever that DID points to — a device, or a callflow.

The inbound call path

Provider → DID → device or callflow. Concretely:

  1. Your carrier (the DID's Provider) sends the call to Voiplix's Asterisk with the dialled number.
  2. Voiplix looks that number up in the DID list.
  3. If the DID has a device assigned (see Assigning a DID), that device rings.
  4. Otherwise, if the DID has a callflow assigned — see below — the call goes there instead.
  5. If neither is set, there is nothing to route the call to.

A device assignment always wins over a callflow if a DID somehow has both.

Assign PBX callflow

On a DID's detail page, the Assign PBX callflow (IVR / queue / ring group / quickforward) panel points the DID at a callflow instead of (or in addition to — with the device taking precedence) a single device. Pick one from the dropdown and click Assign callflow; Unassign clears it again.

An IVR, a queue and a ring group are call-handling building blocks — a menu of options, a hold-and-distribute queue, and a group of phones that ring together — each managed under PBX in the sidebar. This wiki does not cover building those yet; once you have one, assigning it to a DID uses this same panel.

Quickforward DIDs

A quickforward is the fourth kind of callflow: instead of ringing a device or an IVR, Voiplix recognises who is calling by their caller ID and forwards them to a number that person has set up for this DID. It answers no menu, plays no prompt — it either forwards immediately or rejects the call outright.

The rule: known caller forwarded, unknown caller rejected

Voiplix identifies the caller by matching their number against the caller IDs registered on your devices (or, if the dial plan uses "Use Diversion instead of CallerID", the number in the call's Diversion header instead). If the number is recognised and that person has a forwarding number saved for this DID, the call is forwarded there immediately, no questions asked. If the number is not recognised, or is recognised but has no usable forwarding number for this DID, the call is rejected without ever being answered — never with a prompt to type a PIN or a number, because a caller ID on a public number can be faked.

Setting one up

  1. Create a quickforward dial plan under PBX > Quickforward rules > Quickforward dial plans: a Name, the User it belongs to (and optionally one of their devices), and whether to Use Diversion instead of CallerID.
  2. Assign that dial plan to a DID in the Assign PBX callflow panel, same as an IVR or ring group.
  3. Make sure a Quickforward rule (PBX > Quickforward rules) covers this DID for the customer — without one, any forwarding number they save never becomes effective (see below).
  4. The customer enters their own forwarding number: end customers under Quickforwards in the portal menu, every other role under PBX > Quickforward rules > My quickforwards.
A DID with a quickforward dial plan assigned ("Demo Quickforward").

Staff (not end customers) can see every DID that has a quickforward dial plan, its assigned users and their saved numbers — read only — on the Quickforwards per DID overview, reached from the Quickforwards button on the DIDs list. The Status column tells you whether each saved number is actually effective right now:

Quickforwards overview — this number is effective (green "Active").
Warning

A saved forwarding number that shows anything other than "Active" here is not used on a real call, even though it is saved. The two reasons: "Not used: DID outside the user's Quickforward rule" — no Quickforward rule for that user covers this DID — or "Not used: dial plan of another area" — the dial plan belongs to a different reseller/area than the caller. Fix the rule or the dial plan's owner, not the saved number.

On a real call, a rejected quickforward call shows up in the call log with one of two causes: "Quickforward DID: caller not recognized" (no device has this caller's number as a CLI, and no usable Diversion header either), or "Quickforward DID: no usable forward number" (the caller was recognised, but nothing usable was found for them — the same three reasons as the status column above: no number saved, the rule doesn't cover this DID, or the dial plan belongs to another area).

External DIDs (PBX functions)

Under PBX > External-DIDs, PBX functions (feature codes — the kind of thing dialled as a short internal code rather than called as a phone number) get their own extension and PBX pool. This is a distinct, self-contained feature from the DID list covered elsewhere in this section.

External DIDs — PBX functions as their own dial-plan entries.

Web callback

Separately from DIDs, Settings > Callback (admin only) configures the system-wide web callback feature: a customer requests a call from your web page, and Voiplix calls them ("Leg A"), then calls the destination ("Leg B") and connects the two. It is not something you assign per DID — it is one set of retry/wait timers and caller-ID settings for the whole system.

Callback settings — system-wide, under Settings.

Check

Open a DID that has a callflow assigned and confirm the Assign PBX callflow panel names it under "Currently assigned". For a quickforward DID, check its row on the Quickforwards overview and confirm the Status column reads Active, not one of the "Not used" states.