Freeze one failed attempt and classify the earliest divergence
Record the timestamp and timezone, desktop package and build, operating system, user, green application indicator, endpoint row and address, direction, destination class, call identifier, alert, answer, microphone, call output and final treatment. Redact credentials, authorization data, personal numbers and customer audio before sharing evidence.
Classify the first divergence as login failure, no endpoint binding, call not generated, provider rejection, remote not alerted, no answer, no received audio, no transmitted audio, or later degradation. These states do not share one repair.
Prove the application session and endpoint record independently
Verify the same email identity can use the intended account and that the desktop client shows its documented running state. Then inspect the service’s registered-endpoint view for the same user and time window. Keep the application session, SIP binding, device address and call permission separate.
If the endpoint is absent, use the documented SIP Test and MTR Test before changing audio. If it is present but the call is rejected, preserve the exact signaling result and account or dial-plan decision. Do not reset the SIP password as a substitute for proving which credential path failed.
Trace the three desktop audio selections and operating-system owner
Confirm the selected microphone, call-output device and ringer separately. Check operating-system permissions, physical mute, headset profile, sample rate or exclusive ownership only where those controls exist. Reproduce with one known local recording and playback, then one authorized call.
If local capture fails, correct that workstation boundary first. If local capture works but no outbound RTP is observed, continue at the application or network boundary. If RTP leaves and the far end remains silent, correlate the remote leg instead of repeatedly changing the microphone.
Use the WebRTC and network tests without treating them as a call
Run the built-in WebRTC Test and retain its per-port result. Compare the current network guide with DNS, firewall, VPN and SIP ALG state for the failing workstation. The client’s VPN-bypass control changes which route carries the session; use it only as an authorized comparison and record both paths.
A passed connectivity test is not provider acceptance or RTP proof. A failed test identifies a reachability boundary but not automatically the firewall owner. Capture the rule, destination, protocol and time window before changing policy, and keep signaling reachability separate from the wider UDP media path.
Correlate signaling, SDP and both RTP directions
After the provider accepts the call, preserve the offer and answer, selected codec, media addresses, encryption mode, first packet in each direction, packet counts and the client’s selected devices. No RTP in either direction differs from one-way RTP, packets arriving at the host but not the application, and packets decoded by the application but sent to the wrong device.
Change only the earliest proven owner: application session, endpoint registration, account policy, device choice, operating-system permission, firewall route, VPN policy, SIP ALG or remote media path. Repeat the same authorized destination and one negative control, remove temporary captures and restore normal logging. No workstation, network, account, media stream or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- VoIPstudio desktop and mobile downloads ↗
- VoIPstudio Desktop Softphone manual ↗
- VoIPstudio user-manual introduction and platform requirements ↗
- VoIPstudio user, endpoint, SIP Test and MTR administration ↗
- VoIPstudio network, media, encryption and SIP ALG guidance ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.