Configure SIP trunks and routing

Use this guide to configure inbound SIP trunks and inspect outbound routing. For an existing call failure, first identify the call leg and responding component with SIP diagnostics.

Separate the configuration questions

Question	Configuration to inspect
Which inbound trunk matches this request?	Enabled trunks, matching order, and identification criteria
Is this identified caller authorized?	The selected trunk's authentication and transport policy
How is a transfer destination reached?	Target form, effective egress selection, and outbound identity
Why is an expected diagnostic header missing?	Termination/header handling, after checking the correct call leg

A trunk-identification event does not prove authentication succeeded. A successful OPTIONS probe does not prove that an actual call can complete identification, authorization, route lookup, and setup.

Configure an inbound SIP trunk

An inbound trunk tells the edge how to identify incoming SIP traffic and which authentication, transport and media policy to apply. It does not itself assign a destination number, application, team or server group. Arrange those routing resources through the existing routing procedure before testing a call. Agree network, transport, NAT and codec requirements through SIP signaling and media; this field reference does not replace that integration checklist.

Open Admin settings → SIP Trunks. Platform readers can inspect the list; create, update and delete require Super Admin authority. Read-only controls are disabled in this list. No feature flag in the inspected form replaces those API role checks.

1. Record the provider's actual source addresses, From-domain/User-Agent behavior, authentication requirement and transport/media agreement. Have the intended credentials and certificate material available through approved handling.
2. Choose Create. Start with a blank form or a Quick Template and review every populated field; templates are presets, not discovery or proof that a carrier's current network matches the stored sample ranges.
3. Enter a unique Name and Trunk ID, then configure identification, authentication, TLS and media as described below. Use a specific identification rule before a broad fallback.
4. Choose Save, reopen the record and verify it. This persists database configuration; it does not automatically activate the change at the SIP edge.
5. Have the responsible administrator perform the platform Sync All to Redis action and verify the effective configuration and any TLS reload. This is a platform-wide operation, described under configuration activation and recovery, not the Teams toolbar's legacy Sync All Apps action.
6. Test the intended inbound path in the approved test environment, then verify identification, authentication, destination routing, media and teardown separately. A saved row or SIP OPTIONS result alone does not establish a usable call.

List, templates and basic fields

The list shows # (priority), Name, Trunk ID, Identification, Type and Enabled, with search/filtering and row edit/history/delete actions. The API defaults to returning 50 records; filtering the displayed list is not proof that no other record exists. A duplicate name or technical ID is rejected by create/update.

Control	Meaning and default
Quick Templates	Create-only buttons Twilio, Janus WebRTC, Internal Trunk replace the draft's identity/name, identification, auth method, internal/X-Call-ID and external-ID fields. They do not reset every TLS/media/limit field and do not save. Review retained fields when switching presets.
Name	Required display name, up to 100 characters; HTML tags rejected.
Trunk ID	Required technical identifier, up to 64 characters: starts with a lower-case letter, followed by lower-case letters, digits, _ or -. It keys runtime trunk configuration and correlation; renaming is not merely cosmetic.
Enabled	New-record default on. Platform sync includes only enabled trunks in the matching order. Saving off without activation does not immediately remove the previously exported configuration. This is not a dedicated maintenance/drain command and provides no “existing calls unaffected / new calls get 503” guarantee.
Description	Optional explanatory text, up to 1000 characters.
Priority	Integer 0–100; default 50. Lower priorities are evaluated first, then names in ascending order. The first matching trunk wins.

Cancel closes the editor without submitting its draft. Save Snapshot appears while editing an existing trunk; treat it as a snapshot of persisted configuration, not Save or live activation. The row history/snapshot recovery workflow is owned by configuration recovery.

Identification: fill every selected condition

In Admin settings → SIP Trunks, open the edit dialog for the trunk you want to inspect. The letters identify controls; they are not a sequence of changes. The example trunk below is disabled and uses synthetic values.

Select the image to view it at full size.

Identification Methods (AND logic when multiple selected) offers IP Whitelist, From Domain, and User-Agent. The form keeps at least one selected; new records start with IP Whitelist.

Conditional field	How to configure it
Allowed IPs / CIDRs	Visible with IP Whitelist selected. Enter an IPv4 address or CIDR and choose Add (or Enter); delete a chip to remove it. Multiple populated entries are alternatives within the IP check; runtime tests exact addresses and CIDR membership. The matching loop examines at most 100 entries. The validator checks a textual IPv4/CIDR pattern, not complete network correctness—verify the actual address/prefix.
From Domain Pattern (regex)	Visible with From Domain selected. Matches the SIP From-header domain, not automatically the Request-URI or authentication realm. Use an appropriately anchored pattern when an exact domain is intended.
User-Agent Pattern (regex)	Visible with User-Agent selected. Matches the received User-Agent value. A recognizable User-Agent alone is not an IP authorization check.

Important implementation limit: the runtime combines the checks that have usable values. A selected method with an empty list/pattern is skipped rather than forced to fail. An IP-only trunk with no usable IP entry has no participating check and does not match; an empty IP list combined with a populated User-Agent pattern can match that User-Agent alone. The UI's empty-IP hint must not be interpreted as a safe complete rule. Populate every selected condition and verify the resulting matched trunk.

For example, a trunk with a populated IP list and a populated User-Agent pattern matches only when the source is in the list and the User-Agent matches. An unrelated source that presents the same User-Agent must fail that combined rule. Verify both positive and negative cases after activation; JavaScript regex validation in the editor does not prove identical deployed SIP-engine behavior.

Authentication

Authentication is evaluated after identification. The selector defaults to IP Whitelist Only (recommended); that label does not add an IP check if identification uses another method.

Authentication Method	Runtime consequence
IP Whitelist Only (ip_only)	Accepts the already identified trunk without a separate digest challenge. Configure populated IP identification if IP authorization is the intended protection.
SIP Digest Auth (digest)	Requires a configured username and password, challenges/validates the SIP credentials and checks the returned username. Identification must still select a trunk first.
IP + Digest (both required) (ip_and_digest)	Requires digest plus a separate authorized-source-IP check, even if the selected identification methods do not include IP. Configure the allowed source list as well as credentials.

Auth Realm, Auth Username, and Auth Password appear for the two digest choices. Blank realm falls back to the SIP From domain. Missing username/password causes an inbound-auth configuration failure instead of a successful challenge flow.

Editing credential limitation: the editor opens Auth Password empty and its helper says to leave it empty to retain the existing password. The inspected update handler instead persists the submitted empty string. When saving a digest trunk, supply the intended password again through the approved secure procedure; do not assume a blank edit preserves it. Changing unrelated fields can otherwise clear the credential before the next sync. The source does not implement the legacy guide's claim that this field is encrypted by the trunk handler; treat the record, exports, snapshots and diagnostic data as sensitive. Do not paste the password into support examples.

TLS and media

TLS controls are rendered independently of the selected authentication method. These settings require the edge's TLS service/certificates to be configured; the switches do not create certificates or enable a missing TLS listener.

Control	Default and effective behavior
Require TLS Transport	Off by default. When active at runtime, non-TLS traffic for the identified trunk is rejected.
Verify Peer Certificate	Off. Requires selected CA material and a peer verified by the TLS layer. A saved UUID is not evidence that the actual CA bytes were loaded.
Require Client Certificate (mTLS)	Off. Also requires CA material. The global TLS watcher collects CA material while per-trunk SIP checks enforce the requirement; do not assume a wholly isolated trust store per trunk.
Peer Name Verification	Disabled / Enabled; default Disabled. The inspected SIP route compares the peer certificate common name with TLS Remote Subject Name when Enabled and that name is populated. This is not a general SAN/hostname-validation guarantee.
TLS Remote Subject Name	Optional text, up to 255 characters. Populate the intended name when enabling peer-name checking; a blank name does not perform the CN comparison in the TLS-enabled route.
TLS CA Certificate (Platform Material)	Select an existing TLS_CA_CERT platform material; the picker loads up to 100. Required by validation when either certificate-verification or client-certificate switch is on, even if a helper only says optional. Arrange the material through platform administration; selecting it does not upload the certificate. Use platform secret controls to create the material record and populate its value.
SRTP Mode	Disabled (plain RTP), Prefer (offer SDES, accept plain), Require (RTP/SAVP only); default Disabled. These modes build RTPEngine SDES/media flags. SRTP terminates at RTPEngine; the inspected backend leg uses plain RTP. Do not interpret this as end-to-end encryption.
Symmetric RTP	Off. Adds the symmetric-media behavior to RTPEngine's offer/answer flags for NAT/media-address handling. Verify actual two-way audio, not only signaling.

Without TLS support at the edge, enabled certificate or peer-name requirements lead to rejection; saved settings alone cannot supply that support. For listener certificates, renewal and internal service trust, use the operator TLS verification procedure. The TLS watcher normally checks the exported material version every five seconds and attempts tls.reload; failure can leave the previous runtime state. Verify its result rather than promise a fixed activation time or zero downtime.

Routing and technical fields

Control	Consequence
Unique ID Header	Optional header name, up to 64 characters, used to extract an external call identifier for correlation. It does not by itself authorize the caller or route a destination.
Internal Trunk	Default off. Changes internal/external routing/media treatment; internal calls can enter special outbound-transfer paths and use different media directions. It also excludes the trunk from the inspected external health-monitor selection. Do not turn it on solely to silence an alarm.
Requires X-Call-ID	Default off. Rejects the call unless its X-Call-ID passes the runtime's validation. Used for the gateway/WebRTC call path; a header's mere presence is not sufficient.
Max Concurrent Calls	Integer 0–10000, default 0; the form labels 0 unlimited. The value is stored/exported, but no consumer enforcing this inbound-trunk field was found in the inspected edge route. Number/server-group limits are distinct; do not rely on this field alone for capacity protection.

codecPreferences is retained in the stored/exported record (new default PCMA, PCMU), but this editor renders no codec selector. No enforcement of this exported trunk codec list was found in the inspected inbound edge route. Use the actual channel/media configuration and negotiated SDP as evidence; do not invent a control from the schema.

Save, activate, disable or delete safely

Saving and deleting use database mutations followed by audit logging; the web hooks only refresh query data. They do not automatically run platform Redis sync. If a request fails after a write, reopen the record before repeating it; an error is not a guaranteed rollback of the database change.

The platform-wide sync clears the managed configuration namespaces and rebuilds them, including inbound trunk order, authentication data and TLS materials. Runtime call/heartbeat keys are outside that targeted delete, but the rebuild is not one atomic transaction: a failure can leave partial configuration. Plan activation with Operations and inspect its result. Saving a disabled trunk or deleting a record requires this activation step to remove its prior runtime matching configuration.

The delete action confirms the selected record and removes it from the database; it is not soft deletion or a maintenance interval. Keep an approved recovery snapshot/export before destructive changes. Do not assume restore includes usable credentials or that restoring a row activates it—use the existing recovery guide.

Understand the health controls actually available

The inspected SIP Trunks list/editor has no dedicated per-trunk health enable switch, probe-target editor or monitor-endpoint field. Enabled controls trunk eligibility, not monitoring independently. The database contains a monitor endpoint name, but it is not exposed by this form or its create/update schema. A requested dedicated control must not be documented as already implemented.

The edge's global HEALTH_PROBE_ENABLED setting controls outgoing OPTIONS probes. The deployment bundle defaults it off, while the image entrypoint fallback is on: the effective deployed value matters. Eligible probes use enabled, external trunks and the first allowed-IP entry. For a CIDR, the inspected helper replaces the last octet with 1; it is not a general subnet-first-host calculation or provider target discovery. Have Operations verify a valid intended target before enabling probes; do not weaken inbound IP identification just to make a probe target convenient.

A final 2xx response is success; a failure can carry status_N (including status_408) or no_reply. These are distinct from the TelPhi monitor's no probe result from edge outcome for missing/invalid/stale data. Health thresholds count monitor evaluations; they are not proof of that many distinct network probes. A trunk may be identified correctly yet fail OPTIONS, or answer OPTIONS while real-call routing/media is broken. Use the operator health/logging owner for deployed probe settings and correlated evidence.

Verify and recover an inbound configuration

Symptom	First checks
Save rejected	Duplicate Name/Trunk ID, required identity fields, IPv4/CIDR syntax, regex syntax, selected CA requirement and numeric bounds. Reopen before retry if the outcome is unclear.
Call matches the wrong trunk	Effective sync result, priority order and each populated IP/domain/User-Agent condition; check broad earlier rules and blank selected conditions.
Digest fails after an edit	Verify whether the blank Auth Password was saved; restore the intended credential securely, activate and retest.
TLS rejected after Save	Actual transport, TLS-enabled deployment, effective CA material/reload result and exact expected CN.
Disabled/deleted trunk still matches	Database state and completion of platform-wide activation; this editor does not push automatically.
Health unavailable but calls work	Effective global probe setting, first allowed-IP target, result freshness and carrier OPTIONS behavior; do not toggle Internal or weaken identification as a workaround.

Check outbound selection

Record the original transfer target, effective route selection, and outbound/base-number context. Do not infer the original request solely from the final wire URI: a configured trunk can construct a SIP URI from a number.

Original target	What to check
Number-like destination	Effective route/base identity, selected trunk or pool, and the trunk's routing method
Literal sip: or sips: destination	URI host, applicable restrictions, actual transport, and reachability; literal URI resolution bypasses number-pool selection

Bypassing pool selection does not bypass transfer restrictions or establish transport support. Number-handling helpers also do not provide a universal E.164 normalization guarantee. Use the formatting required by the configured route and carrier, and verify the actual outbound request.

Manage outbound trunks and pools

A trunk describes one outbound gateway configuration. A pool (API: egress route) groups one or more trunks and associates an outbound base-number identity. Direct base-number/trunk links also create a legacy pool; they are not the same object as a named route. Neither object allocates a carrier number or publishes an application's phone entry point.

Open Admin Settings → Egress (/admin-settings/egress) for platform management. Trunks and Pools share one manager; older /admin-settings/egress-trunks and /admin-settings/egress-routes links select the corresponding tab. Settings → Team embeds the same manager with the selected team's scope. Its CRUD actions save independently of the surrounding team-settings Save button.

Authority: team-owned trunk/route creation and mutation require Team Admin; global objects require platform SUPERUSER. Changing an object's owner also requires SUPERUSER. Team-list API access requires at least Member and includes available global objects; platform readers can inspect across teams. A team view disables editing/deleting global rows. Super Viewer cannot perform these protected mutations. An enabled-looking button is not permission: the list UI's read-only flag does not substitute for API guards. See access and teams. These egress handlers do not themselves establish the team's TEL entitlement or carrier availability.

1. Identify the intended team/global scope, destination gateway, outbound identity and transfer method. Review outbound selection and team transfer restrictions.
2. In Trunks, choose New or edit an existing row. Complete the applicable fields below; a preview only constructs an example URI, not a connectivity test.
3. Save, reload and confirm the persisted fields. Check the activation/result boundaries below before interpreting a closed dialog as runtime success.
4. If you need an explicit multi-trunk route, create it under Pools after the trunks exist. Otherwise associate the intended base number directly with the trunk.
5. Configure the application's entry point and egress base number, then verify a controlled outbound scenario using SIP diagnostics. A route selection or REFER dispatch does not prove the remote peer accepted or completed the transfer.

Trunk fields

Controls	Values and consequences
Name; Trunk ID; Enabled	Name 1–100 characters; technical ID 1–64, starting with a lowercase letter, then lowercase letters/digits/underscore/hyphen. Names and IDs are checked for uniqueness across trunks, not just the team. Enabled defaults on; disabled trunks are omitted from synchronized runtime pools. Changing the ID does not rewrite flow references automatically.
SIP URI; Transport	SIP URI is required (up to 256 characters); Transport is UDP/TCP/TLS, default UDP. The legacy Kamailio number-pool path constructs sip:<destination>@<configured value>: use the gateway host/port format expected by that path, not an arbitrary full URI inferred from the field label. URI-building paths have different semantics below.
Routing Method	Static URI, Number @ host, Genesys FQDN or Genesys TGRP. Static templates containing {number} use destination substitution; static values without that placeholder remain on the legacy pool path in TelPhi.
Proxy hosts (round-robin); Proxy Port	Shown for Number @ host and TGRP. Hosts split on newlines/commas, trim and drop empty entries; maximum 16. Optional port must be 1–65535. Placeholders are not saved defaults. Proxy selection in TelPhi uses a process-local counter, not active health probes.
Customer Prefix; Region; BYOC Domain; Trunk Context (override)	Prefix and region are required for the two Genesys modes; TGRP additionally requires at least one proxy host and exposes trunk-context override. Domain/context are optional form fields. These source templates have deployment-specific assumptions: have the operator verify the constructed URI against the actual carrier contract rather than assuming the named mode supports every installation.
Authentication Method	IP Only, SIP Digest, Registration, IP + Digest or TLS Mutual Auth; default IP Only. Digest/registration/IP+digest show Auth Realm, Auth Username and Auth Password. Registration material is synchronized separately from successful carrier registration; saving does not prove a REGISTER succeeded.
Verify Carrier Certificate; Require Mutual TLS	Both default off. Verification requires a CA material reference; supplying a client certificate requires its paired client key and vice versa. Use TLS transport and verify deployment TLS support; selecting these switches does not enable TLS in the running deployment.
Peer Name Verification; TLS Remote Subject Name	Peer verification defaults Disabled; subject-name text is optional (up to 255 characters). Confirm certificate identity and the generated/loaded TLS profile with the operator.
TLS CA Certificate / Client Cert / Client Key (Platform Material)	Select existing platform materials or None. Empty selections normalize to null references. Selectors are disabled in team mode; ask a platform admin to attach or change material. A stored material reference is not proof its content was resolved or loaded.
Caller ID Mode; Caller ID Override	Passthrough default, Base Number, or Override; fixed-number input appears for Override (up to 32 characters). On the inspected legacy outbound path, the per-request caller-ID override takes precedence over trunk settings. Inspect the actual outbound From identity, not only the stored mode.
Priority	Integer 0–100, default 50; lower numbers sort first in pool aggregation. This is not a universal promise that the first trunk handles every call: pool strategy still applies.
Max Concurrent Calls	Integer 0–10,000, default 0; UI labels 0 unlimited. The value is persisted/exported, but the inspected egress consumer does not demonstrate enforcement of this per-trunk cap. Do not use it as a verified admission-control limit.
Codec Preferences	PCMA, PCMU, G722, OPUS; defaults PCMA/PCMU. Selection can be empty and is persisted/exported. The inspected egress routing consumer does not establish that these values filter negotiated media; verify the actual SDP/media path.
Base Numbers	Multi-select, empty by default; team form offers that team's numbers. Saving replaces that trunk's selected links; clearing removes them. Named-pool membership is configured separately.

Password-edit limitation: the form says leaving Auth Password empty keeps the existing password, but the inspected edit form initializes it to an empty string and the API persists the submitted value without preserving the old password. Do not save a credential-backed trunk with a blank password assuming it is unchanged. Coordinate the intended credential with its owner before editing; do not paste credentials into support tickets or screenshots.

URI-building limitation: Number @ host validation allows an empty proxy list when SIP URI is present, but the inspected TelPhi builder does not derive the missing host from that URI. Supply the intended proxy host and confirm the preview instead of relying on that fallback. Optional empty domain/context strings can also differ from omitted values in URI construction; the preview and controlled carrier verification remain necessary.

Pool fields and selection

Control	Meaning
Name; Route ID; Enabled	Name 1–100; Route ID follows the same 1–64 technical-ID pattern as a trunk. Names/IDs are unique across routes. Enabled defaults on. Route ID is the runtime selector, not the database UUID.
Base Number	Required outbound identity/fallback context. For a team-owned route, the API checks that this number is assigned to the team.
Strategy	Round robin (default) or Priority / failover. This controls the route pool, not the server group's inbound load-balancing strategy.
Priority	0–100, default 50; lower preferred when choosing among matching routes. It is separate from member-trunk order.
Egress trunks	Select 1–16 distinct trunks. The chooser lists enabled available trunks; the API rejects nonexistent or another team's owned trunks for a team route. Global trunks can be members. Changing the selection assigns member priorities 1, 2, … from the selected list; there is no separate per-member numeric-priority editor here.

For number-like targets, TelPhi first respects an explicit routing selector. Without one it checks the application egress base number, otherwise the called number, for an enabled matching route or legacy number pool, then considers the enabled global platform-default route. Literal SIP/SIPS targets use their URI path rather than number-pool selection. Default selection does not establish peer REFER support or override transfer restrictions.

The two runtime paths are important: URI-building in TelPhi selects an enabled member using process-local round robin, or the first ordered member for Priority / failover. That selection itself has no health-probe or retry loop. On the legacy Kamailio pool path, round robin uses a Redis counter; Priority / failover starts at member zero. Its failover handler advances on 408/5xx while members remain, and stops for a cancelled transaction. Do not generalize this into retries on every rejection, health-aware scheduling, or end-to-end failover for every direct-URI transfer. Direct base-number pools carry no explicit strategy and use the legacy round-robin branch when multiple members are present.

Save, disable, delete and verify

Trunk/route writes commit database state before attempting granular Redis synchronization. Trunk changes reaggregate linked base-number/route pools, rebuild registration material and bump TLS-material version; route changes rewrite their route pool. Removed links and renamed trunk/route keys have explicit cleanup paths. A platformSynced: false result means stored configuration and runtime state may differ; the inspected UI success hooks close/invalidate after a successful API response without turning that flag into a failure.

Reload after any error before retrying. Association replacement and later updates are not one atomic transaction in these handlers; an error can follow removal of existing links. For diagnosis, record scope, object IDs, operation/time and sync result without credentials. Ask the operator to inspect/reconcile the specific runtime keys and material before repeating a call; use service health and configuration recovery. Do not use a platform-wide force re-sync casually: it affects more than the row you edited.

Disabling a trunk removes it from synchronized pools but is not a drain of active calls. Deleting a trunk also removes its associations and rebuilds dependent pools; a route can then have no usable member. Deleting a route removes its named runtime key but does not rewrite application selectors. On the legacy path a missing named pool may fall back to the base-number pool, so deletion is not a reliable way to force all matching traffic to stop. Review references before either action. Trunks provide History/Save snapshot; treat any restore as a separate live configuration change under the recovery guide, not an automatic recovery of carrier state.

Manage base numbers

Use Admin Settings → Base Numbers to manage the platform's number resource. Registering this row is separate from acquiring a number from a carrier, assigning it to a team and publishing a phone entry point. Team Settings shows assigned number/description information and header assignment controls; it is not the full number editor.

Authority: creation requires platform SUPERUSER. Updating or deleting an existing number requires SUPERUSER or Admin membership in at least one assigned team; this is broader than a platform-only edit rule, and a shared resource change can affect other assigned teams. Add/remove-team operations require Admin access for the specified team. Super Viewer mutations are blocked. Adding a team also checks TEL entitlement and its base-number allowance; ordinary resource creation alone does not grant either.

1. Choose New, enter Name and Number, and review the optional configuration below. Save creates the resource; team assignment controls appear when editing an existing record.
2. Reopen the record and use Add Team to associate the intended team. Check the resulting assignment before configuring that team's entry points. Without extensions, only one team can be assigned.
3. For a direct-number entry point, keep Extensions off. For shared extension entry points, review the migration consequences before enabling it and then assign the intended extension through the application's entry-point workflow.
4. Verify the number, team, server group, header configuration and outbound links after saving. Verify runtime routing separately using the same controlled scenario as before the change.

Field/action	Meaning and boundary
Name; Number; Description	Name required, maximum 20 characters; description optional. Number input permits formatted phone-number characters with 6–15 digits and the UI normalizes it before submission. Use the intended international carrier number; this does not reserve/provision it. Do not renumber an active resource as a routine label edit.
Extensions	Default off. Changing mode affects whether endpoints use the bare number or extensions; it is not simply a visual option. Multiple team assignments require extensions enabled.
Server Group	Optional selector for routing placement. Blank/undefined input is not an explicit null-clear contract: update uses serverGroupId ?? undefined. Verify the saved assignment rather than assuming clearing the control detached the group.
Header Manipulation Configs	Multi-select replaces associations. See header-rule assignment and activation: selecting a base number is not itself proof that exported rules are isolated to that number's calls.
Outbound Trunk (Egress)	Multi-select for direct legacy outbound-pool membership; empty removes these links. Named route pools remain separate.
Assigned teams → Add Team / remove chip	These are immediate separate mutations, not staged until Save. Add checks entitlement, allowance and same-name collision within the team. Removal is rejected while that team's endpoint has an assigned flow on the number. Cancelling the surrounding edit dialog does not undo completed assignment changes.
History; Save snapshot; Delete	History/snapshot are separate configuration actions. Delete is destructive resource deletion, not deactivation or carrier cancellation; review all endpoints, routes, assignments and dependent configuration first.

Provider, external ID, country, provisioning status and suspension date may exist in stored/displayed number data; they are not editable fields in this number dialog. Do not rely on the older field list as a supported provisioning form or copy its server-group algorithm/capacity claims into this resource editor.

Change extension mode without assuming an atomic migration

On Save after a mode change, the UI queries assigned-flow endpoints and may ask to deactivate them. Confirming starts endpoint deactivation and the number update separately, without awaiting the first before the second. The API rejects enabling extensions while a bare-number endpoint still has a flow, and rejects disabling them while extension endpoints still have flows. A failure can therefore leave endpoints deactivated while the mode remains unchanged. Stop and reload both the number and application endpoints; do not repeatedly confirm or assume rollback occurred.

Endpoint deactivation clears flow assignments and attempts Redis cleanup; cleanup errors can be logged while database deactivation continues. Number mode update also attempts to remove invalid bare-number or extension keys. None of this republishes the replacement entry points. Reconcile the intended assignments and publish through the application workflow only after the new mode and routing are verified.

Removal, renumbering and recovery boundaries

Adding a team sets the stored number status to ASSIGNED and invokes number synchronization. The inspected remove-team handler removes the relationship but does not reset status or perform that synchronization. The delete handler likewise does not establish complete runtime key cleanup or carrier cancellation. Do not infer that a successful removal makes the carrier number available for reuse or that traffic stopped.

Number updates can change links before the final number-row update; egress-pool synchronization occurs before that final update. Renumbering is therefore not a verified migration of all old/new Redis keys or named-route identities. Escalate an active-number rename/delete to the operator with the intended old/new mapping and dependent entry points. Use the recovery guide to distinguish resource snapshots from runtime cache, carrier state and backups.

Verify the applied change

After an authorized change, confirm the relevant running state through the deployment's supported administration/operations workflow, then repeat the same controlled scenario.

• For inbound identification, confirm the intended trunk matched and authentication/call setup progressed as expected.
• For outbound routing, confirm the selected identity and destination on the correct outbound leg, then confirm the destination actually received the transfer.
• If the observed behavior still differs from configuration, return to SIP diagnostics with the exact response and originating component.

Do not treat a saved form, an OPTIONS response, or a transfer-dispatched event as proof of the end-to-end result. Keep SIP and call handling as the shared entry point for capability, configuration, and incident questions.