Choose the exact Voximplant connection model
Voximplant documents several SIP relationships that must not be collapsed. A PBX can send allowlisted traffic to the platform and an application rule can start a VoxEngine scenario; a Voximplant application user can register as a SIP endpoint; and a scenario can originate a separate SIP leg with optional authentication and outbound proxy parameters. Name the selected path and direction before configuring it.
Record the account, application, rule, scenario, PBX or SBC, source addresses, destination, credential owner, numbers and commercial products in scope. Keep SIP transport, platform processing, PSTN calling, phone numbers, SIP registration, Voice AI and messaging as separate entitlements unless the order explicitly joins them.
Documented service facts
Reviewed 2026-10-15. Compare SIP trunk services →
SIP authentication
DocumentedVoximplant documents an IP or network allowlist for PBX-to-platform trunk calls without SIP authorization. Its outbound callSIP interface separately supports an authentication username and password, while application users can register as SIP endpoints. These are different trust paths; retain the selected source addresses, credential owner, destination and application rule without publishing secrets.
Registrar, proxy and DNS
DocumentedThe SIP-user FAQ constructs an application-and-account domain and documents username/password registration. The trunk FAQ instead starts with an IP allowlist and application rule, so it does not establish REGISTER as a universal trunk requirement. Confirm the ordered design, current domain, outbound proxy, DNS answers, transport and timer behavior for the selected account.
Numbers and inbound delivery
DocumentedVoximplant documents forwarding allowed PBX traffic into an application rule and handling the resulting CallAlerting event in a VoxEngine scenario. It also sells phone numbers separately. Selected number inventory, portability, delivered Request-URI and identities, rule order, scenario behavior and alternate targets remain account and application specific.
Routing and failover
Not verifiedThe reviewed sources describe a global platform and application-controlled routing but do not define one universal customer-side DNS target order, failover trigger, retry policy, established-dialog behavior or recovery sequence. Obtain the current ingress and egress design and observe only authorized failure tests before relying on an alternate path.
Service and number coverage
DocumentedThe SIP-trunking solution page states calling to more than 190 countries and numbers from 60 countries, while the newer Voice AI FAQ describes broader platform PSTN figures. Treat these as page-scoped statements, not a reconciled entitlement. Qualify every source, destination and number type against current rate sheets, regulation and the selected account.
Codecs, DTMF and RTP
DocumentedVoximplant lists G.711 mu-law and A-law, G.722, Opus and iLBC for audio and describes in-band, RFC 2833 and SIP INFO DTMF. The selected path can contain PBX, Voximplant scenario, media server and PSTN or external-SIP legs; preserve each offer and answer, transcoding boundary, RTP tuple, packetization and decoded result.
Fax and analogue dependencies
Not verifiedNo current T.38, audio pass-through, fax-machine or analogue-adapter acceptance statement was verified in the reviewed sources. Inventory fax, alarms, lifts, door entry, payment and monitoring systems separately and retain the approved replacement or test result for every dependency.
Signaling and media protection
DocumentedVoximplant documents SIP over TLS plus media protection using SDES or DTLS and says IPsec VPN is available on request. Those capabilities do not prove activation, certificate identity, trust, cipher, keying, downgrade behavior or end-to-end protection. Verify every PBX, platform, scenario, carrier and destination leg against the ordered policy.
Channels and call starts
Not verifiedThe solution page says customers can use multiple trunks, but the reviewed sources do not establish the selected account concurrency, direction sharing, calls-per-second limit, scenario or media limits, queueing, burst behavior or overload response. Obtain current limits and test only approved traffic within authorization.
Emergency calling
Not verifiedNo selected-account emergency-calling eligibility, registered-location workflow, callback identity, propagation time, failure behavior or approved test process was verified. Do not infer emergency service from ordinary PSTN coverage or rented numbers; obtain written scope and retain an accessible independent emergency method until acceptance.
Pricing, SLA and contract
DocumentedVoximplant publishes separate SIP-calling, registration, PSTN, number, application and optional-feature charges, and warns that regional functionality can vary. The public schedule does not establish the selected destination rates, taxes, surcharges, volume terms, SLA remedy, support entitlement, suspension or cancellation conditions; preserve the dated quote and contract.
Monitoring, support and demarcation
DocumentedVoximplant publishes call events, scenario failure codes, support channels and a service-status page. Map account, allowlist, DNS, PBX, firewall, application rule, scenario, media, carrier and destination ownership separately. A platform status indicator or scenario event is one observation, not proof of end-to-end service restoration.
SMS and MMS
Not verifiedVoximplant offers messaging as a separate platform capability and pricing area, but the reviewed SIP-trunk material does not establish SMS or MMS on selected voice numbers. Treat messaging as separate until number eligibility, registration, consent, throughput, API behavior, retention, filtering and price are documented.
Trace ingress through the application rule and scenario
For PBX-to-platform traffic, the current trunk FAQ starts with an account allowlist and then forwards the call through an application rule to a scenario that handles CallAlerting. Preserve the received source address, Request-URI and identities, selected rule, rule order, scenario version, event timeline and first scenario action. A permitted IP proves neither that the intended rule matched nor that the scenario answered or routed the call.
Define whether the scenario rejects, answers, creates early media, calls another SIP URI, calls PSTN or joins legs. Every new leg has its own request, response, SDP, media and final outcome. Avoid interpreting a successful first leg as proof that the destination leg started or answered.
Keep registration and outbound SIP authentication separate
The registration FAQ builds a domain from application and account names and assigns a user and password. That endpoint-style registration is not the same as the IP-allowlisted trunk ingress. In the other direction, callSIP can use an authentication username, password, outbound proxy or saved registration identifier when the external SIP server requires them.
Preserve the chosen trust model and the owner of each secret or allowlist. Inspect DNS answers, transport, TLS name, challenge exchange, From and asserted identity, Contact, expiry and observed registration state only where that model uses them. Do not add a REGISTER flow merely because another Voximplant SIP feature documents one.
Verify media, protection and destination scope per leg
Voximplant lists UDP, TCP and TLS signaling, SDES or DTLS media protection, several audio and video codecs and multiple DTMF methods. Those are platform capabilities, not proof of the negotiated result. Retain each leg's signaling transport, certificate and trust result, SDP offer and answer, media keying, RTP endpoints, codec, packetization, DTMF result and decoded media.
Keep codec interworking and media encryption distinct from end-to-end protection. A scenario or carrier boundary can terminate, transcode or re-originate media. Fax and analogue dependencies need separate acceptance because the reviewed sources do not establish T.38 or pass-through behavior for the selected path.
Accept routing, operations and commercial scope together
Build an acceptance matrix for inbound PBX-to-platform, platform-to-PBX, any PSTN route and each number. Record normalization, caller identity, permitted destinations, expected rule and scenario, answer outcome, media, capacity, alerts, support owner and rollback. Use scenario failure events, call records, platform status and PBX evidence as separate observations.
Reconcile the selected coverage and current rate sheet instead of turning page-level country counts into an entitlement. Confirm concurrency and call-start limits, failover targets and triggers, emergency scope, number portability, regulatory documents, pricing, SLA and support terms in writing. Public platform capability does not replace a dated order or an authorized end-to-end test.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voximplant SIP trunking solution ↗
- Voximplant SIP trunk connection FAQ ↗
- Voximplant SIP phone registration FAQ ↗
- Voximplant processing calls in scenarios ↗
- Voximplant CallSIP parameters ↗
- Voximplant telephony and SIP capabilities FAQ ↗
- Voximplant pricing ↗
- Voximplant service status ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.