Module 13 · BYOC trunks

Lee en español: Módulo 13 · Troncales BYOC.

Objective: register and provision your BYOC SIP trunk, limit its destinations, share it with all your offices, tell it apart from platform lines, and understand its health states and event history. Time: ~8 minutes · Prerequisites: a user with trunk management permissions and your SIP provider's details (the proxy and the IPs it sends calls from).

1. Register your BYOC trunk

In the menu open Trunks & Carriers; the screen is titled SIP trunks (carriers). Press + Add trunk and fill in:

• Name: anything that helps you recognise it.
• Kind: BYOC (client trunk), for your own provider. You can only register BYOC trunks here; platform lines are not something you add (section 5).
• Scope: Sede (that office uses it) or Empresa (shared) (section 3).
• SIP proxy: your provider's address, in the format of the placeholder sip:proxy.example:5060. Your outbound calls go there.
• Source IPs (BYOC inbound ACL): the IP addresses from which your provider sends you inbound calls.

Press Save. Your trunk authenticates by IP: the platform recognises your provider by the source IPs you declare. There is no registration mode with a username and password. Each IP belongs to one trunk across the whole platform; if it is already assigned to another, the registration is rejected. An empty list is valid, but that trunk then carries outbound calls only.

Saving only records the trunk. To make it work, you have to provision it.

Encrypt the media (SRTP)

By default the audio between the platform and your provider travels as plain RTP. If your provider supports SRTP, the trunk can encrypt it: the srtp field takes off (default), offer (the platform offers SRTP and accepts plain RTP if your provider answers without it) or require (it refuses an answer that is not SRTP). offer and require need a TLS SIP proxy (sips: or ;transport=tls); with a plain proxy the platform answers 400. The console does not show this field yet, and it cannot be edited afterwards: set it through the API when you create the trunk, as described in BYOC trunks: SRTP.

2. Provision and revoke

On your BYOC trunk's row, under Actions, press Provision: the platform writes the trunk to the SIP edge and turns on its inbound ACL. The screen confirms with «Provisioned to the SIP edge.». If your environment has no live SIP edge, it says «Saved — no live SIP edge is configured, so it was not pushed.» and nothing reached the edge.

After registration, the SIP proxy, the source IPs and the scope are not edited in place. To change them, Revoke the trunk and register another. Revoking is permanent: it removes the inbound ACL, the trunk can no longer be provisioned, and its IPs are freed for another trunk.

Through the API

This is the same as POST /v1/carriers, POST /v1/carriers/{id}/provision and POST /v1/carriers/{id}/revoke. See the API reference.

3. The company-wide trunk your offices inherit

With scope Empresa (shared), the trunk is shared by every office of the account. Use it to have a single provider for the whole company:

• Outbound: every office without an active BYOC trunk of its own goes out through the company's. If an office has its own, the office's wins.
• Inbound: the source IPs of a company-wide trunk deliver calls to the numbers of any office in the company. The IP identifies your account, not the office; the dialed number decides which office takes the call, and that number must have an active inbound route. A number of another account, or an IP we do not recognise, is rejected at the SIP edge.

Creating, changing or revoking a company-wide trunk affects every office, so it takes an account administrator user; a user without that role gets a permission error. An office trunk, and provision and revoke on it, also refuse a plain member (403 role_forbidden over the API); an account administrator or an integration key can do them.

4. The destination allowlist

A BYOC trunk can declare a list of numbers it may call, for accounts that must never reach anyone else: a test account, or a prospect's trial that may only call the numbers the prospect confirmed as its own. Without a list, nothing changes.

• They are exact E.164 numbers (+ and digits), up to 100, no duplicates.
• It is declared when registering the trunk or later, and each change replaces the whole list; an empty list lifts it. Today it is managed through the API (allowed_destinations on POST /v1/carriers and PATCH /v1/carriers/{id}): the trunks screen has no control for it.
• It binds the whole office, not one trunk: campaign dials (retries and callbacks included), manual and preview dials, and the outbound leg of a transfer to an external number all count. If several BYOC trunks of the office declare a list, the number has to be on each of them.
• If the list cannot be read, the call is refused as if the number were outside it.

A destination outside the list is not dialed: it is filed as a block by account policy (tenant_policy). The list guards against dialing by mistake, not against your own administrator: whoever can manage the trunk can lift it. Details are in the REST API guide.

5. Platform lines

Platform lines are the house trunks (in the list, the Kind column reads house): you call through our trunks instead of your provider's. You do not register them: they are operated by DialerDigital, and the form does not offer them. If your account already has one, it still appears in the list. They have no IPs to declare and are not provisioned; the health column reads «Not a BYOC trunk» and Actions reads «LCR-dispatched»: we pick the least-cost route.

They are billed differently from BYOC. With BYOC, your provider bills you for its minutes and we do not resell them. With platform lines we meter the outbound minutes and charge them at the published rate: first from your plan's Voice minutes allowance and, when it runs out, from your balance. Module 7 has the detail.

6. Trunk health

In the BYOC (Bring Your Own Carrier) model, calls are routed through your own SIP provider. For this to work reliably, the platform can watch the health state of each connected BYOC trunk; if the chip shows no data, ask support to turn the monitoring on for your account.

In the sidebar and trunk list, you will see an indicator ("chip") showing the real-time health of your BYOC trunk. The possible states are:

• Up: the trunk is successfully responding to traffic probes or SIP options messages. Calls can be routed normally.
• Down: the trunk stopped responding or is returning errors to probes. Today the state is informational: the platform tells you, but it does not stop routing calls to that trunk on its own.
• Unknown: this occurs if the health reading is no longer "fresh" because the provider stopped sending signals or the probe loop went quiet.

7. Trunk health history

Every health change in a trunk is recorded. You can view this log to diagnose exactly when your carrier experienced an outage and how long it took to recover.

In the BYOC trunk view, the Health History table displays recent events, from newest to oldest. Each row indicates:

• Observed: the exact moment the platform observed the change (in your local timezone).
• Change: the transition that occurred, for example, Up → Down or Unknown → Up.
• Reason: the technical explanation for the change, such as latency timeouts, SIP response failures, or other reasons reported by the telecom core.

This history is a valuable evidence tool: if you notice failed calls in your dialing operation, the table will help you confirm whether your SIP provider experienced an outage at that exact time.

8. Capacity and balance: what limits a BYOC call

Your carrier bills its own minutes, but the call still runs through our media servers, so a BYOC call is not unmetered.

• The ceiling when you have none. If your account has no capacity ceiling of its own, your BYOC dialing is measured as if it had 100 simultaneous calls and 20 calls per second. Each figure applies only where your account declares none, and a ceiling your account does have always wins, even a higher one (with 500 simultaneous calls declared, 500 go through). Dialer Digital sets the ceiling for your account; the console has no control for it.
• A lane of its own. While the ceiling is that assumed one, your BYOC calls are counted apart from your platform-line calls: calls on platform lines never take BYOC places, and the other way round.
• What you see when it is reached. The 101st simultaneous call is not dialed, and neither is the 21st started in the same second. A campaign shows the reason tenant_channels or tenant_cps (see the brakes table), stays running and dials again as soon as there is room.
• Voice AI over your own trunk. Your carrier's minutes are not ours, but the AI of the call (speech-to-text, language model, text-to-speech) is, so a voice-AI call over a BYOC trunk reserves balance for the AI only, never for the carrier. With prepaid, the reserve is the AI rate times the call window: with no balance the call is not dialed (wallet_insufficient). With a subscription, only your Voice AI allowance counts, not the voice-minutes one; once it is spent, the excess comes out of your balance, as in Module 7. With postpaid, the credit you already have is the ceiling (plan_exhausted when it is used up). Such a call is also judged against the plan's ceiling, 20 simultaneous calls for a subscription or postpaid account, instead of the 100 / 20 above; prepaid has no other limit than its reserve.
• A BYOC call without AI reserves nothing. It only meets the ceiling above.

The figures and the code that backs each one are in the REST API guide.