Freeze one path and one observed failure
Record timestamp, exact 6940w label, installed software, call manager, programmed Mobile/PC Line control, paired device and operating-system version. Name the path as PCLink, MobileLink or SIP and the symptom as absent connection, wrong device, silent microphone, silent output, unsynchronized mute, unexpected line priority or failed return after an IP call.
Do not troubleshoot all three paths as one call. A Bluetooth pairing record proves only retained trust information; it does not prove a current connection, selected application devices, a SIP registration or two-way audio.
Prove control enablement before changing radio settings
The Mitel guide requires the Mobile/PC Line feature for PCLink and says administrator involvement may be required. Confirm the visible control, its server or Web UI provisioning path and effective state before deleting pairings or changing Bluetooth policy.
For PCLink, the guide says pairing begins from the computer, not the phone. For MobileLink, retain the exact connected mobile identity. If a different PC or mobile device is already connected, classify that ownership conflict before treating it as RF failure.
Trace the computer audio path end to end
For PCLink, record Bluetooth connection, operating-system input and output, collaboration-application microphone and speaker, application mute, phone mute, handset or speaker selection and one bounded local media test. Mitel documents phone mute as local to the phone rather than synchronized with the PC application.
The guide also warns against leaving the phone as the computer's default audio device in the described workflow and says only one mobile-or-PC device type can be connected at a time. Capture the actual selected devices rather than assuming the last pairing owns audio.
Separate mobile audio and history from the SIP line
For MobileLink, verify the connected mobile, permission to share contacts or history, the Mobile Line state and which device answered the mobile call. A contact-sync or history error does not prove that Bluetooth call audio failed, and retained history does not prove the phone is still connected.
An incoming SIP call and an incoming mobile call remain different sessions. The user guide gives an IP call priority when both arrive and the handset is lifted; record the actual line and resulting audio path rather than calling the behavior a dropped mobile or SIP call without evidence.
Repair the earliest divergence and retest transitions
Change one confirmed mismatch: feature enablement, programmed line control, connection owner, operating-system device, application device, permission, local mute or selected phone transducer. Re-pair only when the retained identity or trust state is the first failed gate.
Repeat idle PC audio, a PC collaboration session, an incoming SIP call during that session, return to PC audio after hangup, one paired-mobile call and one SIP call only where authorized. Keep connection, control, audible input, audible output and return-to-prior-session as separate results. No 6940w, computer, mobile device, call manager, account, packet, media stream or live 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.
- Mitel 6900 SIP Phones document center ↗
- Mitel 6900 IP Phone Series product page ↗
- Mitel 6940 and 6940w SIP phone user guide, release 6.4 SP3 ↗
- Mitel 6800, 6900 and 6900w SIP phones administrator guide, release 6.4 ↗
- Mitel 6900 accessories document center ↗
- Mitel 6940w SIP phone learning center for MX-ONE ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.