Softphone uses the wrong speaker, headset or microphone

Name the wrong path before resetting devices

Preserve one affected call and record what is wrong: ringtone on an unexpected speaker, remote speech on the wrong output, microphone from the wrong input, or a route that changes only after docking, reconnecting USB, joining Bluetooth, sleep or resume. Record time, operating system, softphone and browser builds, connected devices, saved selections, active selections and the transition immediately before the symptom.

A device can be paired or connected without being the active call route. System sounds, a local recording, softphone ringtone, received call audio and transmitted microphone media can also use different controls. Do not treat sound from one of those paths as proof of another, and do not reinstall or clear the client until the route evidence and provisioned account are preserved.

Separate operating-system defaults from per-app routing

Microsoft's current Windows guidance exposes output and input devices in Sound settings and identifies the Volume mixer when one application is silent while system audio works. Record the default output, default input, any communications-role device and the softphone's per-app assignment. A working browser video or Windows alert can still use a different route from a desktop softphone.

Apple's macOS guidance similarly provides separate Sound output and input selections. Check the actual device name and input level rather than assuming the most recently connected headset became the default. If the operating system cannot play an approved test sound or show input level on the intended device, stop at that layer; SIP, RTP and codec changes cannot select a missing local route.

Read the softphone's active route, not only its preference

After the operating-system path works, inspect the softphone's current speaker, microphone and ringtone selections. Some clients offer explicit devices while others follow the operating-system default. A saved label can point to a device that was removed and recreated with a new identifier after a dock, USB or driver transition.

Change only one selection and confirm whether it applies immediately or on the next call. Keep hardware mute, application mute, input gain and output level separate. If the intended microphone works in the operating system but the softphone captures a different input, follow the silent-microphone diagnosis before altering media addresses or PBX policy.

Treat Bluetooth, USB and dock changes as route events

Apple documents audio-route changes when an input or output is added or removed, including wired headphones, Bluetooth headsets and USB audio interfaces, and exposes both the current and previous route to applications. Android likewise distinguishes available communication devices from the device selected for a communication use case. These are application-platform capabilities, not proof that one softphone handles every transition correctly.

Reproduce the problem with a bounded sequence: start with built-in audio, connect the approved device, place a call, disconnect it during an authorized test, reconnect it and place another call. Record the route at each stage and whether media became private or moved to a loudspeaker. Avoid repeated pairing resets or driver replacement until the first route change that diverges is known.

Preserve browser permission and output-selection boundaries

For a browser softphone, Media Capture and Streams makes the available input list permission and policy sensitive. The Audio Output Devices specification adds user-mediated selection of a non-default output and binding that approved device to a media element. The default output has a different permission boundary, and support remains dependent on the exact browser and application implementation.

Record the page origin, browser build, permission state, enumerated device labels, selected input, selected output, remote media element and playback result. A device missing from a webphone menu does not alone prove hardware failure, and a successful SIP session does not prove the remote track was bound to the intended output. Do not grant broad microphone access to unrelated origins or claim universal browser output selection from the existence of the specification.

Keep ringtone, conversation and privacy behavior separate

A receptionist may deliberately send ringtone to a desk speaker while keeping conversation audio on a headset. That can be useful, but it also means a ringtone test cannot accept the call-media route. Confirm inbound alert, answer, remote speech, local speech, hold, resume, transfer and hangup on the intended devices. Repeat with another application briefly using the microphone only when policy permits.

Test privacy explicitly after a headset or Bluetooth device is removed. The expected result may be pause, a visible prompt or a controlled fallback; automatic movement to a loudspeaker can expose call audio. Record the approved fallback for the organization and client rather than assuming one operating system's media-player convention defines VoIP-call behavior.

Correct one owner and verify recovery

Correct only the demonstrated boundary: disabled operating-system device, wrong default or per-app assignment, softphone device preference, stale device identifier, browser permission or output selection, unsupported client build, driver or firmware owned by the endpoint team, or an application route-change defect. Preserve the previous setting and rollback. Do not change NAT, codecs, SIP credentials or PBX routing when local route evidence already explains the symptom.

Repeat the affected call and a known-good control with the intended input, output and ringtone paths. Verify connect and disconnect, dock or undock, sleep and resume, application restart, mute and unmute, hold and resume, transfer where required, both speech directions and privacy after device removal. No computer, mobile device, dock, USB interface, Bluetooth device, browser, softphone, operating-system policy, PBX, media path or live call was inspected or tested for this guide.

Do not use conversation output selection to explain a missing browser ringtone

The browser no-ring diagnostic first proves INVITE arrival, visible alert state and ringtone playback policy. After answer, return here to prove the selected remote-audio output and actual listener result.

Continue from device selection into headset call control

After the intended microphone and speaker are proven, use the wireless-headset control diagnostic when answer, end, hold or mute state still differs between the physical headset and softphone.

Check all three VoIPstudio audio destinations

The VoIPstudio desktop client documents separate microphone, call-audio and ringer controls. The service-specific guide and diagnostic keep ringing, capture and rendered call audio from standing in for one another.

Check Webex ringer, speaker and microphone independently

Webex App exposes separate desktop choices and can receive operating-system processing before the app. The calling guide keeps local tests separate from observed call media.

Use the MicroSIP audio-device note as a bounded clue

The 3.22.19 notes add detection of memory corruption associated with problematic audio devices or drivers. The MicroSIP guide keeps that publisher statement separate from evidence that one device is incompatible, selected or repaired.

Separate PhonerLite global audio state from its SIP profile

PhonerLite stores selected sound devices in global configuration, not the SIP profile. The local-state diagnostic proves which PhonerLite.ini and device selection are active.