Softphone microphone is silent: prove capture before RTP

Name the silent direction and preserve one call

Start with one authorized test call and say which party cannot hear which source. Record the time and timezone, caller and destination, softphone build, operating system, selected microphone, headset or Bluetooth state, mute indicators, network and PBX or provider. Keep local microphone capture, client encoding, packet transmission, network delivery, PBX relay and remote decode as separate stages.

Registration, alerting, answer and received audio do not prove that the client captured or sent microphone media. A remote caller saying 'no audio' also does not identify the failed direction. Retain the Call-ID or platform call identifier and use a known-good comparison endpoint where policy permits.

Prove operating-system permission and the physical input

Check the operating system before changing SIP or codec settings. Windows separates device microphone access, app access and desktop-app access. macOS and iPhone expose per-app microphone permission, while Android allows permission to be changed per app and may limit it to use-time or each request. Record the exact state and any organization-managed restriction rather than repeatedly toggling every privacy control.

Select the intended input at the operating-system level, set a conservative level and prove movement with the system input meter or an approved local recording. Repeat once with the built-in microphone if a removable headset is involved. If the operating system cannot capture the source, stop there: SIP signaling, NAT and PBX codec changes cannot restore missing local samples.

Prove the softphone's selected device and capture state

After the operating system captures correctly, inspect the softphone's active input rather than its saved preference alone. USB reconnects, docks, Bluetooth profile changes and sleep or resume can create a new device identifier or move the default. Check both the application mute state and any hardware mute switch or boom position, then use the client's input meter, loopback or echo test only if the vendor documents it.

Record which input was active when the call began and whether a mid-call device change took effect. A moving operating-system meter with a flat application meter localizes the break before RTP. Avoid raising gain until noise or clipping substitutes for silence, and do not grant microphone access to unrelated apps as a diagnostic shortcut.

Read SDP direction before interpreting packets

Preserve the initial and any updated SDP for the affected audio stream. RFC 3264 distinguishes sendrecv, sendonly, recvonly and inactive; it also binds offered or answered media to explicit addresses, ports and codec payload mappings. Confirm the direction from each participant's perspective and whether a hold, transfer or re-INVITE changed it.

A completed SIP answer or an audio m= line is not evidence that microphone samples exist or RTP reached the peer. A zero port rejects the stream, and an accepted codec name does not prove the client encoded it, the network carried it or the remote side decoded it. Keep signaling direction, packet direction and audible result as three separate facts.

Locate the first missing outbound RTP boundary

With authorization and a bounded privacy scope, compare RTP metadata at the client-side interface, trusted network boundary and PBX or media relay. RFC 3550 gives RTP sequence numbers, timestamps, synchronization source identifiers and payload types that can establish a continuing packet stream without listening to content. For SRTP, retain only the permitted metadata and negotiated protection state; inability to decode protected payload is not evidence of silence.

No packets leaving the client points back to capture, mute, client media state or local policy. Packets leaving but not reaching the PBX point to address, port, firewall, VPN, NAT or routing ownership. Packets reaching the PBX but not leaving the expected leg require bridge, direct-media, transcoding or policy evidence. Packets reaching the remote side with no audible speech move the investigation to payload mapping, decode, output routing or the actual sample level. Do not enable broad permanent packet capture or expose call content in tickets.

Keep mobile and Bluetooth lifecycle changes visible

On mobile devices, repeat foreground, background, locked-screen, network-change and incoming-interruption cases separately where those states are in scope. A permission set to use-time, an operating-system privacy reset, a Bluetooth handoff or a call-audio route change can affect capture without changing SIP registration. Record the selected route at call start and after the transition.

Treat handset microphone, wired headset, Bluetooth headset and speakerphone as different input and output pairs. A Bluetooth device being connected does not prove that the call uses its microphone profile. Do not remove mobile-device management, privacy or security controls merely to make one call work; reproduce on an approved control device and correct the demonstrated policy or routing owner.

Correct one owner and accept both directions

Correct only the demonstrated boundary: operating-system permission or input, application device selection or mute, supported client version, SDP direction, advertised media address, firewall or VPN rule, PBX bridge or media policy, codec mapping or remote output. Preserve the prior setting, approval, rollback and the exact call evidence. Avoid reinstalling the client or resetting the profile until credentials, provisioning and diagnostic state are safely preserved.

Repeat the original call and a known-good control. Confirm local capture, active client input, expected SDP direction, outbound and inbound RTP metadata, remote and local audible speech, mute and unmute, hold and resume, the intended headset path and recovery after one approved restart or network transition. No workstation, mobile device, microphone, headset, softphone, operating-system policy, SIP account, PBX, packet capture, protected-media path or call was inspected or tested for this guide.

Trace VoIPstudio microphone capture into outbound RTP

For VoIPstudio Desktop, a working local recording establishes only the operating-system capture path. The paired diagnostic then compares the selected microphone, application permission, SDP and outbound RTP.

Preserve the MicroSIP build before assigning a mute defect

MicroSIP 3.22.19 documents a microphone-muted fix, but the client diagnostic still proves operating-system capture, selected input, client mute state, SDP direction and outbound RTP on the affected host.