← Alle berichten

Waarom je softphone "microfoon geweigerd" zegt terwijl je niets hebt geweigerd

29 september 2026 · door Rodney Carrilho · 675 woorden

“Ik kan niet bellen, er staat iets over de microfoon.”

Zo komt het binnen. En draait je softphone in de browser, dan weet je meteen waar je gaat kijken: het slotje in de adresbalk. Staat de toestemming voor de microfoon aan?

Bij ons stond hij aan. Laatst gebruikt: 1 minuut geleden.

Wat de app zei, en wat er waar was

De regel in het gesprekslog was ondubbelzinnig: User Denied Media Access. Toestemming geweigerd door de gebruiker.

De browser zei iets anders. Microfoon: toestaan. Geen uitzondering, geen blokkade, en volgens de browser zelf een minuut eerder nog in gebruik.

Het echte antwoord kwam pas toen we het met de hand navroegen in de console. Daar stond geen toestemmingsfout, maar NotReadableError — met de toelichting dat de audiobron niet kon worden gestart.

Dat betekent iets heel anders. Het apparaat kón niet starten. Op Windows is dat bijna altijd een ander programma dat de microfoon vasthoudt, of een apparaat dat in exclusieve modus staat. In dit geval bleek het een Chrome die niet helemaal was afgesloten en in het systeemvak was blijven hangen.

Waarom de app iets anders zei dan de browser

Dit is geen fout van de browser, en eerlijk gezegd ook niet van onze app. Het zit in de SIP-bibliotheek ertussen.

Die vraagt de microfoon op, en als dat mislukt vertaalt hij elke fout naar dezelfde oorzaak: USER_DENIED_MEDIA_ACCESS. Toestemming geweigerd, apparaat bezet, microfoon losgetrokken, geen beveiligde verbinding — het komt er allemaal hetzelfde uit.

De naam klinkt als een diagnose. Dat is hij niet.

En dat is erger dan een vage foutmelding. Vaag laat je zelf zoeken. Deze melding stuurt je stellig naar het slotje, waar niets aan de hand is. Je gebruiker klikt drie keer op toestaan, het blijft niet werken, en dan begint het echte gedoe.

De echte fout wordt niet weggegooid

Het goede nieuws staat één regel verderop in diezelfde bibliotheek: de oorspronkelijke fout van de browser verdwijnt niet. Hij komt mee als een apart event, getusermediafailed, met de echte uitzondering erin.

Luister daarop, en vertaal op de naam van díe fout in plaats van op de oorzaak die de bibliotheek ervan maakte. Er zijn er zes, en ze vragen zes verschillende dingen van je gebruiker:

  • NotAllowedError — toestemming is echt geweigerd. Hier hoort het slotje thuis, en op Windows ook de privacy-instelling voor de microfoon.
  • NotReadableError (en het oudere TrackStartError) — het apparaat kan niet starten. Meestal houdt een ander programma de microfoon vast: Teams, Zoom, een desktop-softphone. Helemaal afsluiten, ook in het systeemvak.
  • NotFoundError — er is geen microfoon. Headset niet aangesloten, of het standaardapparaat klopt niet.
  • OverconstrainedError — het eerder gekozen apparaat bestaat niet meer. Opnieuw kiezen.
  • SecurityError — geen beveiligde verbinding. Zonder https geen microfoon.
  • AbortError — de hardware viel weg tijdens het opvragen.

Eén van de zes gaat over toestemming. In de andere vijf gevallen is het slotje het verkeerde antwoord.

Eén valkuil bij het tonen

Toen we dit inbouwden liepen we nog ergens tegenaan: op het moment dat je de melding laat zien, kan de bewaarde fout al verouderd zijn.

De gebruiker sluit Teams af en probeert het opnieuw. Toon je dan de onthouden fout van daarnet, dan meld je een probleem dat net is opgelost — en ben je opnieuw stellig en opnieuw mis.

Doe daarom een verse controle op het moment dat je de melding toont: vraag de microfoon even op en stop hem meteen weer. Is hij inmiddels vrij, dan zeg je dát, in plaats van de vorige klacht te herhalen.

Wat ik eraan heb overgehouden

De foutnaam was niet onduidelijk. Hij was specifiek en onjuist, en dat is duurder dan vaag.

Bij een vage melding gaat iemand zoeken. Bij een stellige verkeerde melding gaat iemand doen wat er staat. Dat kost een kwartier, een ticket, en een stukje van het vertrouwen dat de app weet waar hij het over heeft.

Sindsdien stel ik bij elke foutvertaling twee vragen in plaats van één. Niet alleen: snapt de lezer dit. Maar ook: weet de laag onder mij dit eigenlijk wel zeker?

RC
Rodney Carrilho
Directeur AR ICT & Telecom
Bouwt Lijnrecht en gebruikt het zelf, elke dag, bij AR ICT & Telecom in Rotterdam. Schrijft hier op over wat er in de praktijk stukgaat tussen telefooncentrales, Microsoft 365 en de balie.

Meedenken over jullie situatie?

We kijken in twintig minuten mee met hoe jullie receptie nu werkt, en zeggen eerlijk wat er wel en niet te winnen valt — ook als dat betekent dat je bij je huidige centrale blijft.

Plan een demo