Freeze one ingress model and failed transaction
Record local and UTC time; direct PBX address, application-user registration or saved external registration; account and application; remote source or proxy; transport; registration ID and mode; status code and message; destination; ordered rules; selected rule and scenario version; incoming event; every call identifier; SIP response; and the earliest media event.
Classify the first divergence: source not admitted, registration failed, registration bound to the wrong application or rule, destination matched the wrong direct-ingress rule, scenario did not start, scenario did not create the next leg, remote leg failed, answer did not occur, or signaling advanced without media packets.
Verify registration state without treating it as a call test
For a saved external registration, compare the configured proxy, optional port and transport, outbound proxy, authentication user, persistent mode and redacted username with the current object. Preserve Failed status details or the transition timeline. A newly changed object can remain In progress while provisioning occurs, so do not repeatedly edit it without preserving the first result.
Then prove the application and selected routing-rule binding. A Successful status proves registration only; it does not prove that an incoming request reached the application, that the chosen scenario ran or that callSIP used the intended registration ID.
Trace direct PBX ingress through ordered rule selection
For an allowlisted PBX call, preserve the source address actually seen and the exact destination from the application SIP address. Compare that destination, not the caller identity, with routing-rule patterns in top-to-bottom order. Record the first matching rule and every attached scenario version.
Do not change an allowlist to repair a valid request that reached the wrong rule. Conversely, do not reorder rules to repair traffic that never reached the platform. Registration-bound calls and direct application-address calls have different selection behavior and must remain separate.
Correlate scenario execution and every created call leg
Preserve the application event destination and custom headers needed for correlation, then the first scenario log or action. For each new SIP, user or PSTN call, record its own identifier, request target, response sequence, SDP, answer or failure event and termination reason.
If the incoming event exists but no outbound leg exists, inspect the deployed scenario branch, exception and applicable limit before debugging the remote PBX. If an outbound leg fails, keep that failure distinct from the still-valid incoming leg and from any later bridge operation.
Separate early media, answer, first packet and ongoing RTP
Put AudioStarted, Connected, FirstAudioPacketReceived, MediaStatisticsReceived and RtpStopped on the timeline for the exact leg that emitted them. Because AudioStarted can follow 183 without actual packets, it is not evidence of received audio. Connected establishes answer, not two-way media.
Compare each leg's SDP endpoints, negotiated codec, first-packet event and per-direction statistics. If RtpStopped occurs, preserve the last media and control-packet times before changing NAT, firewall or codec configuration. Correct only the demonstrated signaling, scenario or media boundary.
Make one correction and retain the limits of the retest
Change only the demonstrated proxy, transport, credential, registration mode, application binding, rule order or pattern, deployed scenario, destination, callSIP registration ID, SDP, firewall or PBX route. Repeat one authorized non-emergency transaction and correlate registration state, destination, rule, scenario, every leg, answer, first packet, stream metrics and final event.
Do not represent that result as proof of another direction, PSTN coverage, emergency service, failover, capacity, price, availability, compatibility or support performance. No Voximplant account, registration, rule, scenario, call or media stream was inspected or tested.
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.