Introduction

If you are shipping a browser-based AI receptionist, the failure mode is usually not “the model stopped responding.” It is more mundane: the microphone stream goes silent, the video freezes, or audio and lip sync drift far enough apart that the whole experience feels broken. With WebRTC, those symptoms often come from transport issues, track lifecycle bugs, autoplay restrictions, or a bad assumption about who owns the media graph.

This post is a practical debugging guide for Angular apps that embed a realtime voice+video agent. By the end, you should be able to isolate whether the problem is in the browser, signaling, media negotiation, or your application code; instrument the right points; and fix the common causes of audio/video drops without guesswork.

Start by separating media transport from app logic

In a setup like this, there are usually three moving parts:

• The browser client, which captures microphone input, plays remote audio, and renders remote video.

• The realtime agent backend, which consumes audio, produces speech, and may attach a synchronized avatar track.

• The signaling and transport layer, typically WebRTC, which handles ICE, DTLS, SRTP, track negotiation, and packet delivery.

When audio or video drops, don’t start by inspecting your prompt or transcription pipeline. First answer: did the browser lose track publication/subscription, or did the media itself stop flowing?

Useful browser-side signals:

• RTCPeerConnection.connectionState moving to disconnected or failed

• iceConnectionState flapping between connected and disconnected

• Remote audio element present but silent, often due to autoplay policy or a paused element

• Video track exists but the element is frozen, usually due to track replacement, subscription loss, or render thread issues

In Angular, it helps to log these events in one place instead of scattering them across components. If you are using a WebRTC SDK, bind the peer connection events as soon as the room/session connects and keep the logs around for the full call lifecycle.

const pc = room.engine.peerConnection;

});

const pc = room.engine.peerConnection;

});

const pc = room.engine.peerConnection;

});

Audio drops: the common causes are boring, but real

Most “audio dropped” bugs are not packet loss. They are one of four things: autoplay blocking, device changes, track replacement, or upstream silence.

Autoplay and the muted-start trap

Browsers still require a user gesture before unmuted audio can play reliably. If your UI creates the session and immediately attaches a remote audio track, the element may remain silent until the user clicks somewhere. The bug looks like a transport issue, but the fix is usually to resume playback after a gesture.

In Angular, make sure the audio element is actually attached to the document and call play() after the user starts the interaction. If the promise rejects, log it.

<button (click)="startCall()">Start</button>
<audio #remoteAudio autoplay playsinline><

<button (click)="startCall()">Start</button>
<audio #remoteAudio autoplay playsinline><

<button (click)="startCall()">Start</button>
<audio #remoteAudio autoplay playsinline><

async startCall() {
}

async startCall() {
}

async startCall() {
}

Device changes and track restarts

Microphones can disappear when the user switches devices, permissions change, or the browser renegotiates after sleep/wake. If you see the agent still “listening” but receiving no transcript, inspect the local audio track source and the sender stats. If the track ended, replace it explicitly instead of assuming the SDK or browser will heal it for you.

Also check that your app isn’t calling getUserMedia() twice and accidentally publishing a stale track. That is a common Angular lifecycle bug: a component re-renders, reconnects, and the old sender keeps pointing at an inactive track.

Upstream silence can look like a network issue

If the user’s microphone is quiet or muted, the agent may still be connected and the video may still animate, but the conversation stalls. Verify that audio levels are non-zero before blaming WebRTC. The quickest check is to log local track activity or inspect audio stats.

A practical pattern is to show a local “microphone active” indicator tied to actual audio energy, not just permission state. If the indicator is flatlined, the problem is in capture or device selection, not transport.

Video drops: usually subscription, rendering, or lifecycle

Video in an AI receptionist is often a remote avatar track, not a local camera. That matters because the failure modes are different. You are not debugging a flaky webcam; you are debugging track subscription and render continuity.

Track subscription loss

If the remote video freezes or disappears, first confirm the subscriber is still attached to the track. In many SDKs, a remote track object can remain valid while the HTML element was detached, replaced, or hidden during a component update. Angular templates make this easier to break than plain DOM because elements can be recreated when inputs change.

Be careful with conditional rendering such as *ngIf around the video element. Tearing down the element can silently detach the media stream. Prefer keeping the element mounted and toggling visibility with CSS when possible.

Rendering and compositor issues

Even when the track is fine, the browser may stop painting frames if the tab is backgrounded, the element is offscreen, or the app is repeatedly destroying and recreating the video element. A frozen frame with a live track often points here.

For debugging, compare three things:

1. track.readyState and muted

2. Receiver stats such as framesDecoded and bytesReceived

3. Whether the DOM element is still the same node you originally attached

If bytes and frames continue to increase but the UI is frozen, the bug is in rendering or element lifecycle. If they stop increasing, the issue is transport or subscription.

Use WebRTC stats before you guess

Stats are the fastest way to turn a vague “it dropped” report into a concrete diagnosis. Sample sender and receiver stats at intervals and compare deltas.

const stats = await pc.getStats();

});

const stats = await pc.getStats();

});

const stats = await pc.getStats();

});

A few patterns to recognize:

• Bytes increasing, playback silent: autoplay, muted element, or output device issue.

• Bytes flat, connection still “connected”: upstream publisher stopped sending, sender track ended, or SFU/subscription problem.

• Video frames flat, audio active: avatar track stalled while speech continues, often due to a bad element swap or render bug.

• Both audio and video stop at once: connection loss, ICE failure, or application teardown.

Angular-specific gotchas that cause media drops

Angular itself is not the problem, but its component model makes a few mistakes easy:

• Recreating DOM nodes: if your audio/video element is behind *ngIf, it may be destroyed mid-call.

• Subscription churn: reconnecting on every input change or route transition can duplicate peer connections.

• Zone-related timing: async callbacks can fire after the component is destroyed unless you explicitly clean them up.

• Lifecycle leaks: stale peer connections continue running and the new one never gets a clean media path.

For a receptionist UI, keep the call session in a service rather than in the component tree. The component should render the current session state, not own the connection itself. That one change eliminates a surprising number of “random drop” bugs.

When the component unmounts, explicitly stop tracks, close the peer connection, and remove event listeners. WebRTC objects are not magical; they outlive your UI unless you shut them down.

Where Protoface fits without changing your debugging model

Protoface does not replace the WebRTC debugging process; it gives you a cleaner avatar/video source so you can focus on the client-side transport and lifecycle issues. If you are embedding a voice agent with a synchronized talking face, the relevant surface is the developer docs and the integration you are using, not a custom browser-side media stack.

For a backend-managed agent, the LiveKit plugin and its examples are the right place to start: https://github.com/protoface-ai/protoface-plugin-pipecat. If you are creating or managing avatars and sessions directly from a service, use the REST API or Python SDK; exact request and object fields are documented in https://docs.protoface.com.

A minimal backend call pattern looks like this:

import requests

session = resp.json()

import requests

session = resp.json()

import requests

session = resp.json()

The key debugging benefit is architectural: if the avatar/session is created server-side, your Angular app only has to consume a media session and keep the DOM stable. That shrinks the surface area when audio or video drops.

Conclusion

When WebRTC audio or video drops in an Angular receptionist, the fastest path to a fix is to separate browser media issues from application bugs. Check autoplay, track lifecycles, DOM churn, and stats before you chase network ghosts. Keep your peer connection and media elements stable across component updates, and use logging to confirm whether packets stop, tracks end, or rendering simply stalls.

If you want a reference implementation or need to confirm the exact session fields, start with the documentation at docs.protoface.com and the related examples in the plugin repository. From there, reproduce the failure with stats enabled, fix the lifecycle bug, and then re-test on a cold reload, background tab, and device switch. Those are the cases that usually expose the real issue.