Name the SIP relationship before reading its status
Voximplant documents three distinct relationships: allowlisted PBX traffic entering an application address; a third-party SIP client registering as an application user; and a saved SIP registration through which Voximplant registers to an external provider or PBX. A successful state in one model does not prove the other two are configured.
Record direction, account and application, remote domain or address, transport, credential owner, saved registration identifier, destination, selected rule and deployed scenario version. Keep platform SIP, PSTN, phone numbers, SDK users and Voice AI as separate products or legs unless the selected design explicitly joins them.
Documented service facts
Reviewed 2026-10-23. Compare SIP trunk services →
SIP authentication
DocumentedDirect PBX ingress uses a source-IP allowlist, third-party SIP clients can authenticate as application users, and saved external SIP registrations use provider credentials. These are separate trust paths; preserve the selected model and secret owner.
Registrar, proxy and DNS
DocumentedSaved registrations specify proxy, username and password, with optional authentication user and outbound proxy. Status can be Successful, In progress or Failed; persistent and user-login-dependent non-persistent modes have different lifecycle behavior.
Numbers and inbound delivery
DocumentedDirect PBX calls use an application address and destination-matching routing rules. Calls received through a saved registration require an application and rule binding; the registration-bound rule handles those calls without a pattern.
Routing and failover
Not verifiedStatus changes and callback evidence are documented, but no universal selected-account retry order, alternate proxy, established-call behavior or recovery objective is stated. Preserve registration transition and each call outcome separately.
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
DocumentedAudioStarted can follow 183 without received packets. Connected marks answer, FirstAudioPacketReceived is explicit packet evidence, MediaStatisticsReceived reports stream metrics and RtpStopped can follow an RTP or RTCP interruption.
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
DocumentedThe SIP guide documents UDP and TCP plus TLS for supported SIP relationships. Actual certificate identity, trust, signaling leg, SDP protection and media keying remain path specific and must be verified per leg.
Channels and call starts
Not verifiedVoxEngine limits are published, but the selected account, scenario, call-start, concurrency, registration and media limits were not inspected. Obtain current account evidence and test only authorized loads.
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
Not verifiedThe registration guides disclose a recurring registration charge but no selected-account amount, taxes, PSTN rate, number charge, SLA remedy or support entitlement was verified. Retain the dated order and billing evidence.
Monitoring, support and demarcation
DocumentedRegistration status details, callbacks, call events, media statistics and account call history are documented observations. Correlate them by registration, application, scenario and call identifier; none alone proves an end-to-end call.
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.
Prove the registration object and its application binding
A saved SIP registration has a proxy, username and password, with optional authentication user and outbound proxy. The current guide documents Successful, In progress and Failed states, with status details for failures; the Management API additionally distinguishes persistent registration from a user-login-dependent non-persistent mode. Preserve the registration ID, mode, proxy, transport, redacted identity, timestamps, status code and message.
Incoming calls through that registration require attachment to an application and a selected routing rule. The guide says that rule handles all calls to the registration without needing a pattern. Registration success therefore proves neither the intended application binding nor the running scenario outcome.
Evaluate routing rules in documented order
For direct PBX-to-platform calls, the allowlisted source sends a destination in one of the documented application address formats. Routing-rule patterns evaluate the destination rather than caller identity, rules execute top to bottom, and only the first matching rule runs. Preserve the received source, Request-URI or destination, ordered rules, matching result and attached scenario versions.
A source allowlist admits traffic but does not select the intended rule. Likewise, an attached registration rule bypassing pattern matching does not prove that a direct application-address call follows the same path. Correct the specific ingress model, binding or rule order instead of widening every pattern.
Keep the incoming and created call legs independent
The scenario receives an incoming call event and can answer, reject or create another SIP, user or PSTN call. The resulting calls are separate legs with their own request, responses, SDP, answer time and termination. Preserve the incoming application event, destination and selected scenario, then assign a distinct call identifier and timeline to every created leg.
Do not turn a successful inbound event into proof that the scenario created the intended outbound leg, or turn an answered outbound leg into proof that the incoming leg was bridged. A scenario exception, limit or explicit branch can stop processing between those checkpoints.
Use explicit media events instead of inferring audio from signaling
Voximplant documents that AudioStarted can follow a 183 Session Progress response regardless of whether media packets are actually arriving. Connected marks answer, while FirstAudioPacketReceived is the explicit first-packet observation. MediaStatisticsReceived carries stream metrics, and RtpStopped can follow an RTP or RTCP interruption. Preserve which leg emitted which event, its timestamp and the corresponding SIP and SDP evidence.
An early-media event, 200 response or bridge request is not a two-way-audio result. Compare negotiated transport and codec, RTP endpoints, first packet, per-direction statistics and stop events for each leg before moving to firewall, NAT or codec changes.
Reconcile limits, operations and commercial scope separately
The platform publishes account and scenario limits, registration management operations and downloadable call history, but the selected account state and commercial terms are not established by those reference pages. Correlate account, application, rule, scenario, registration, call identifiers, event timestamps and remote PBX evidence without treating an API success or history row as an end-to-end call result.
Before production acceptance, obtain current limits, registration charges, PSTN and number scope, support entitlement, availability terms, emergency-calling scope and approved failure procedures. No live account, call or media path was tested for this review.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voximplant SIP calls and registrations ↗
- Voximplant routing rules ↗
- Voximplant applications ↗
- Voximplant processing calls in scenarios ↗
- Voximplant CallEvents reference ↗
- Voximplant AppEvents reference ↗
- Voximplant SIPRegistration Management API ↗
- Voximplant VoxEngine limits ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.