Client trunks

A client trunk connects a client’s own phone system (its PBX) to FireTone. The PBX sends its outgoing calls through your carriers, and the client’s numbers ring the PBX. Each call is rated and billed to the client’s organisation like any other outbound call. It follows the organisation’s outbound rules and rates, is held against its balance when it is prepaid, and appears in its call history with the trunk named. Client trunks are the optional Client trunks module (Modules). With the module off, a client’s PBX is refused like a stranger, a number pointed at a PBX cannot complete, and the screens and API are gone. The licence must include the module too. Organisations see the screen as SIP trunks.

​

How a PBX signs in

Each trunk signs in one of two ways:

• A username an extension already holds is refused, in both directions.
• Addresses may be no wider than a /24 (IPv4) or /48 (IPv6), and never one of your carriers’.
• A client’s address is allowed through the firewall on 5080 but is not added to the never-ban list. A client that floods you is banned like anyone else.

​

What a trunk may do

Emergency numbers are always refused. A client trunk carries no location, so the PBX must send emergency calls over its own local line.

​

Numbers that ring the PBX

Point a number at the trunk: Numbers → edit → Destination → Client trunk (the client’s PBX).

• A password trunk is rung at the address it registered from. If it is not registered, the call fails as not registered.
• An IP trunk is rung at its first single address (a /32 or /128) on port 5060.
• The number is sent as the called user, in +E.164 form.
• Inbound calls count against the trunk’s concurrent calls and are not rated, like every inbound call.

​

Organisations creating their own

An organisation’s admin can create, edit and delete their own trunks, within an allowance you set. With no allowance, they see their trunks and can reset passwords, but cannot create any. Client trunks → Allowances lists every organisation. For each it shows:

• trunks used and allowed;
• concurrent calls and calls per second: the totals their trunks’ limits use, out of the totals allowed;
• whether fixed-IP sign-in is allowed;
• the room left.

Edit a row to change it, or select several and use Allow 1 trunk (1 trunk, 10 concurrent calls, 2 per second, password only) or Revoke. An organisation’s own trunks:

• present only its own numbers as caller ID. The other policies stay yours;
• must each set a concurrent-calls limit and a calls-per-second limit, with the totals inside the allowance;
• sign in by fixed IP only where the allowance says so.

Settings you made on one of their trunks are kept when they edit it, and two creates at once cannot both take the last place. You are not held to any allowance.

​

A trunk’s own page

Click a trunk’s name. The page answers “the client’s PBX can’t call out” without a support ticket:

• Now: whether the PBX is registered (or that the switch did not answer), calls up now, calls started this second, the last sign-in, and sign-ins refused today. It refreshes every few seconds.
• Limits: concurrent calls and calls per second against the trunk’s limits, with countries, caller ID and codecs.
• Sessions: registrations now, with the address, the device and when each expires; then those that ended in the last 7 days, and whether the device signed out or stopped refreshing.
• Sign-ins: attempts the switch refused, with the reason, the address and the device. Repeats from one address are counted once a minute.
• Calls: the trunk’s calls.
• Changes: who changed the trunk, and when.

​

Why a PBX can’t call out

​

Through the API

The same operations are in the API reference under Provisioning: They belong to the panel’s interface rather than the versioned public API, so they may change between releases. On a server without the module they are absent.