Audio-only Intercom: signaling accepts `sendrecv` and we do transmit — but nothing comes out of the door station. Traces + open questions

[Pulella]

Hi! Following up from our email exchange, as you suggested — moving it here so it's public and searchable.

TL;DR. I bought the audio model, installed it on a Comelit audio-only building intercom, and traced it.
Three things are now established: (1) Ring's signaling accepts an audio-only live_view for
intercom_handset_audio and answers sendrecv to a sendrecv offer; (2) media really flows in
the receive direction; (3) we really do transmit — thousands of RTP packets with real payload,
measured with pc.getStats(). What does not work: nobody at the door station hears us. Meanwhile
the official Ring app talks two-way on the exact same installation, so the path
Ring → Comelit → outdoor speaker exists and works — the gap is in our client. Below are the logs, the
things I've ruled out, and the one hypothesis I'm left with (Opus frame duration, 20 ms vs 60 ms).

Setup

• Device: Ring Intercom (audio model), kind intercom_handset_audio, on a Comelit Mini 2738W/A
  (Simplebus2, audio-only building intercom). Installed and working in the Ring app (talk + door open).
• Test rig: standalone Python script, python-ring-doorbell 0.9.14 + aiortc 1.9.0 + av 12.3.0.
  Not Home Assistant — deliberately, to isolate the question.
• Physical state during all tests: handset and its plastic shell detached from the wall base (this is
  the state in which the official app works, so I kept it identical for every A/B).

What I changed vs. upstream: exactly one field

I did not rewrite RingWebRtcStream. I wrapped the websocket and rewrote a single field on its
way out, so that the trace proves the existing code path works as-is:

# upstream ring_doorbell/webrtcstream.py hardcodes:
#   "stream_options": {"audio_enabled": True, "video_enabled": True}
if msg.get("method") == "live_view":
    msg["body"]["stream_options"] = {"audio_enabled": True, "video_enabled": False}

The resulting live_view message (redacted):

{
  "method": "live_view",
  "dialog_id": "<DIALOG_ID>",
  "body": {
    "doorbot_id": "<DEVICE_ID>",
    "stream_options": { "audio_enabled": true, "video_enabled": false },
    "sdp": "<offer>",
    "type": "offer"
  }
}

Everything else — ticket endpoint, websocket, message handling — is stock python-ring-doorbell.

Result 1 — recvonly offer → sendonly answer

Ring accepts the session and streams audio. Answer contains no m=video line at all, so
video_enabled: false is honoured:

v=0
o=- 3993650225 3993650225 IN IP4 <IP>
s=-
t=0 0
a=group:BUNDLE 0
m=audio 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 <IP>
a=sendonly
a=mid:0
a=rtcp-mux
a=setup:active
a=fingerprint:sha-256 <FINGERPRINT>
a=ice-ufrag:<UFRAG>
a=ice-pwd:<PWD>
a=candidate:1 1 UDP 2013266431 <IPv6> 40942 typ host
a=candidate:3 1 TCP 1010828799 <IPv6> 443 typ host tcptype passive
a=candidate:4 1 UDP 2013266430 <IPv6> 35516 typ host
a=candidate:7 1 UDP 2013266429 <IP> 49277 typ host
a=candidate:9 1 TCP 1010828031 <IP> 443 typ host tcptype passive
a=rtpmap:96 OPUS/48000/2
a=fmtp:96 useinbandfec=0
a=ssrc:2775838177 msid:<...>
a=ssrc:2775838177 cname:<...>

ICE completes and media really flows — not just signaling. I recorded 15.1 s to WAV:
RMS 57, peak 1879 (i.e. not digital silence — ambient noise from the outdoor unit's mic).
During a real call the downlink is loud and unmistakable (RMS up to ~3974 with clipping: the call tone
and the visitor's voice). The receive direction is a solved problem.

Result 2 — sendrecv offer → sendrecv answer

Offer (aiortc, abridged):

m=audio 59458 UDP/TLS/RTP/SAVPF 96 0 8
a=sendrecv
a=mid:0
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

Answer:

m=audio 9 UDP/TLS/RTP/SAVPF 96
a=sendrecv
a=mid:0
a=rtcp-mux
a=rtpmap:96 OPUS/48000/2
a=fmtp:96 useinbandfec=0

Ring did not downgrade it to sendonly — which it demonstrably does when the offer is recvonly
(Result 1). So at the SDP level the backend is willing to receive an upstream audio track from us.

Side observation: in the sendrecv session the received audio was ~10x hotter than in the recvonly
one (RMS 547 / peak 26104 vs 57 / 1879), consistent with the device switching into an actual talk mode.

Note that neither side ever negotiates ptime / maxptime. This turns out to matter — see below.

Result 3 — we really do transmit (getStats)

This is the part that changed my mind about where the problem is. In the first physical test I concluded
"it doesn't work" purely from not hearing anything, without ever measuring the sender. I added
pc.getStats() at the end of the session (outbound-rtp: packetsSent / bytesSent):

session	encoder frame	frames produced	RTP packets sent	bytes sent	≈ bytes/packet
2026-07-24 17:16	20 ms	848	848	162 534	~192
2026-07-24 17:29	20 ms	8819	8819	1 698 376	~192
2026-07-24 18:02	60 ms	3879	1292	751 051	~581
2026-07-26 12:21	60 ms	6399	2133	1 229 974	~577

For reference, aiortc encoding digital silence produces ~3-byte payloads. ~192 bytes at 20 ms
is a normal Opus voice payload, so there is genuine audio inside the packets and they leave the machine.
"It's a bug on our side, nothing is being sent" is ruled out.

Result 4 — the physical test at the door station: nothing is heard

Test method: send a loud, unmistakable signal upstream during a real call (someone rings from the
outdoor panel, the Comelit bridges the audio path, ~1 min before it times out) and have a human stand at
the outdoor panel and listen.

• 8 sessions with a 1 kHz beep (0.4 s on / 0.8 s off), listener at the outdoor panel → nothing heard.
• Repeated with number.*volume_della_voce and *volume_del_microfono (Ring's own volume entities)
  raised from 7/11 and 5/11 to 11/11 → no change. "Volume too low" is ruled out.
• Same physical state, official Ring app: two-way talk works, low latency, clearly audible at the
  outdoor panel. So the device, the bus and the outdoor speaker are all fine.
• Still pending: the same listening test with the 60 ms encoder patch and a spoken-voice clip
  (a 1 kHz tone is easy to confuse with the intercom's own tones). That's the next thing I'll run.

A methodological warning for anyone trying this remotely

Before doing the physical test I tried to detect my own tone in the downlink (Goertzel /
autocorrelation on the received WAV), hoping acoustic re-entry would prove the uplink was live.
That method is blind by construction: the Ring's AEC is specifically designed to remove our signal
from the return path. Control: in the same recording the analysis happily locks onto a periodic source at
4.90 s (the intercom's own call tone) but finds zero at my clip's 4.13 s period. That is equally
consistent with "it doesn't come out" and "it comes out but AEC suppresses it" — it decides nothing.
Only a human ear at the door station is a valid judge.

The message sequence

  us   -->  live_view
       <--  session_created
       <--  sdp
  us   -->  activate_session
       <--  notification
  us   -->  camera_options
       <--  camera_started      <-- on a device with no camera
  us   -->  ping
       <--  pong

Note camera_started coming back from a camera-less device: further evidence the signaling path is
generic and not video-specific, which matches what you said over email.

⚠️ Gotcha for anyone reproducing this: 60 ms Opus frames (both directions)

Decoder side. The audio Intercom sends 2880-sample (60 ms) Opus frames. aiortc hardcodes 20 ms:

# aiortc/codecs/opus.py
SAMPLES_PER_FRAME = 960
...
length = lib.opus_decode(..., SAMPLES_PER_FRAME, 0)
assert length == SAMPLES_PER_FRAME   # <-- fires on every frame

The assertion kills the audio-decoder thread, so the session looks established but nothing is ever
decoded and no audio is recorded — with no obvious error unless you're watching stderr. I work around
it by decoding into a 120 ms buffer and trimming to the returned length.

Encoder side — my current hypothesis for the silent uplink. Since Ring sends 60 ms frames, its
embedded decoder plausibly expects 60 ms too, and since no ptime is negotiated in either SDP,
nothing aligns us: we fire 20 ms frames and they may simply be dropped. So I wrote the symmetric patch
(nobody seems to have touched the encoder side before) — an AudioResampler with frame_size = 2880
feeding opus_encode:

samples = 2880  # 60 ms @ 48 kHz, a valid Opus frame duration
self.resampler = AudioResampler(format="s16", layout="stereo", rate=48000, frame_size=samples)

Verified in the wild: packets go from ~192 B to ~577-581 B with a 3:1 frames-to-packets ratio, and
Ring accepts them without tearing down the session (see the table above). Whether that's the cure is
exactly what the pending listening test will tell.

What is ruled out, what is left

Ruled out: nothing is transmitted · volume too low · SDP-level refusal · a broken device/bus/outdoor
speaker (the official app works on the same install, same physical state).

Left standing, in order of how much I believe them:

1. Opus frame duration mismatch (20 ms vs 60 ms), untested by ear so far;
2. the backend accepts an upstream track for intercom_handset_audio but doesn't route it to the
   bus — i.e. the app uses a different mechanism for this kind;
3. some extra signaling step the app performs that we don't (an explicit "talk"/mic-enable message?).

If it turns out to be (2) or (3), my next move is to intercept the official app's signaling and diff it
against ours — but before spending that effort I'd rather ask you, since you already have a working
two-way client on the other kind.

Questions for you

1. On intercom_handset_video, when push-to-talk works in your card, what Opus frame size / ptime does
   the browser end up using upstream? If plain 20 ms browser Opus is audible on the video model, my
   60 ms theory is probably wrong and the difference lives in the backend for the audio kind. This single
   answer would save me a lot of guessing.
2. Did you ever need any extra websocket message to make the uplink actually audible (something like
   a talk / mic-enable / camera_options variant), or is live_view + activate_session enough?
3. Have you ever captured the official app's signaling? Any known asymmetry between the two intercom
   kinds in what the backend does with the upstream track?
4. Does anything in the answers you get (e.g. rms_version, session fields) differ between kinds in a way
   you've had to special-case?
5. Your offer from our email — developing the audio-only two-way mode with me testing on real hardware —
   still stands from my side. I'm happy to run dev builds, capture traces, and test anything you need on
   the audio model. HTTPS on my HA instance is on my list as a prerequisite for browser mic access.

Full redacted traces (SDP + websocket transcripts + the TX: stats lines) are attached; raw captures stay
on my machine since they contain my public IP and session identifiers. Happy to trace anything else while
the rig is set up.

[Pulella]

trace-recvonly-20260721-211703.log
trace-recvonly-20260721-211849.log
trace-sendrecv-20260721-211946.log
trace-sendrecv-20260722-191013.log
trace-sendrecv-20260722-191535.log
trace-sendrecv-20260722-191659.log
trace-sendrecv-20260722-191738.log
trace-sendrecv-20260722-191815.log
trace-sendrecv-20260722-191850.log
trace-sendrecv-20260722-191926.log
trace-sendrecv-20260722-192001.log
trace-sendrecv-20260724-171625.log
trace-sendrecv-20260724-172954.log
trace-sendrecv-20260724-180252.log
trace-sendrecv-20260726-122122.log

[cmos486]

First: thank you for this. This is the most complete trace anyone has sent me for this device, and the
getStats() table in particular is exactly the kind of evidence that stops a debugging session from going
in circles. Answers below, in your order, and then the two experiments I'd run before you go anywhere near
MITM'ing the official app.

1. Opus frame size upstream on intercom_handset_video — 20 ms, and it's audible

The card does nothing to the audio. It's getUserMedia → addTransceiver(track, {direction:'sendrecv'})
→ createOffer(), with no SDP munging anywhere in the path, and the integration is a pure signaling
bridge (it hands the browser's SDP to python-ring-doorbell verbatim and hands Ring's answer back).
Push-to-talk is just track.enabled = true/false on the live track — the transceiver is never
renegotiated.

So upstream is stock browser Opus:

• 20 ms frames, a=fmtp:111 minptime=10;useinbandfec=1
• no a=ptime / a=maxptime in either direction, same as your traces

And it is loud and clear at the door station on the video model. So: plain 20 ms browser Opus is audible on
intercom_handset_video, with no ptime negotiated. That's the single answer you asked for.

Two more data points pushing the same way:

• dgreif/ring-client-api, which has working two-way audio, transcodes return audio with
  ffmpeg -c:a libopus -ac 2 -ar 48k. ffmpeg's libopus default frame duration is 20 ms. A second
  independent client, also 20 ms, also audible.
• A priori, Opus packets are self-describing: the TOC byte carries the frame duration, and any compliant
  decoder handles 2.5–60 ms on a per-packet basis. A device that emits 60 ms frames has no reason to
  choke on 20 ms ones. The aiortc assert length == SAMPLES_PER_FRAME you hit is a client-side bug in
  aiortc's decoder (it hardcodes 960 samples), not evidence that anything on the wire expects 60 ms.

I'd demote your hypothesis 1 hard. The 60 ms encoder patch is still worth the listening test you have
queued since it's already built and costs you nothing — but I would not spend another day on it.

By the way, your decoder finding is genuinely useful independently of this bug and deserves an upstream
aiortc issue/PR; I'll link it from the README either way.

2. Extra websocket message?

Not on my side — but there is one message upstream doesn't send, and it's now my favourite cheap test.

The chain in the working path is live_view → session_created → sdp → activate_session →
camera_options {stealth_mode: false} → ping. That camera_options is the exact equivalent of
ring-client-api's activateCameraSpeaker(), and python-ring-doorbell already sends it, so you have it —
your trace shows camera_started coming back.

What neither of us sends is the session-level stream_options message, which is a different thing from
the stream_options field inside the live_view body. ring-client-api has it:

this.sendSessionMessage('stream_options', { audio_enabled: true, video_enabled: true })

i.e. {method: 'stream_options', dialog_id, body: {doorbot_id, session_id, audio_enabled: true, video_enabled: true}}
sent after the session exists. Given that the one field you changed is exactly this pair, that's the
cheapest untested lever you have.

So two A/Bs, in this order, both one-liners:

• B1 — remove your only variable. Run fully stock live_view (audio_enabled: true, video_enabled: true)
  with a sendrecv audio + recvonly video offer, on the audio unit. Your camera_started on a
  camera-less device suggests the backend is generic, but "the backend answers" and "the backend wires the
  uplink to the bus" are different claims, and video_enabled: false is precisely the kind of flag that
  could put the session on a downlink-only path.
• B2 — send the session-level stream_options {audio_enabled: true} after activate_session, and see
  whether anything changes.

3. Have I captured the official app's signaling?

No. Never done it, and with cert pinning it's a chore. Before you spend that effort, there are two
experiments that are decisive and much cheaper:

Test the browser uplink against your audio unit. This is the one I'd do first. The integration
currently filters on device.kind == "intercom_handset_video"; allowing intercom_handset_audio through
is a one-line change, and I'm happy to push a test branch for you today. Then your uplink is stock Chrome
Opus over the exact code path that demonstrably works on the video model, and the result splits your
hypothesis tree cleanly:

• audible → the backend routes an upstream track fine on intercom_handset_audio, and the bug is in
  our aiortc sender. Your hypotheses 2 and 3 die.
• silent → hypothesis 2, and now it's proven rather than suspected, with no app interception needed.

You'll need HTTPS on HA for mic access, which you already have on your list. The camera entity will be a
black rectangle on a camera-less device; that's fine, we only care about the audio.

Or a second independent stack: ring-client-api's transcodeReturnAudio. Completely different WebRTC
implementation (werift) and a completely different encoder (ffmpeg). If that's also silent on your unit,
that's hypothesis 2 with two independent clients agreeing.

4. Anything I special-case between kinds?

Only two things, both structural, neither audio-related:

• RingOther doesn't inherit from RingDoorBell, so it has no WebRTC methods at all — I monkey-patch
  generate_async_webrtc_stream / on_webrtc_candidate / close_webrtc_stream onto it.
• The kind filter mentioned above.

I never inspect rms_version or any session field, and I've never had to branch on anything in Ring's
answer. The only difference I see between kinds in the answer is the presence of the m=video line.

5. Offer stands

Absolutely. Tell me which branch you want and I'll cut it — starting with the intercom_handset_audio one
above, since it's the experiment with the highest information-per-hour.

One methodological note on your listening test

Your instinct to drop the 1 kHz beep is right, and for a stronger reason than confusability with the
intercom's own tones: if anything in the Ring → Comelit → Simplebus path is voice-switched or gated
(which is normal for audio-only building intercoms, and the AEC behaviour you already observed hints at
active duplex management), a 0.4 s on / 0.8 s off beep is close to the worst possible probe — it's exactly
what a level/VAD-driven gate discards. Use continuous loud speech, or at least a continuous tone, for
10 s+ rather than a pulsed one.

Related question, and it may matter: on the audio model, is the official app full-duplex, or is it
hold-to-talk? If the app has a PTT button, whatever it does at button-down is a strong candidate for
your hypothesis 3, and it would be the first thing to look for if you do end up intercepting it.

Minor diff item while you're comparing SDPs: Ring's answer to your aiortc offer carries no a=extmap
lines at all, so no RTP header extensions are in use — including ssrc-audio-level, which aiortc does
populate when negotiated. Probably irrelevant, but if the device gates the bus on signalled audio level it
wouldn't be. Worth a glance at whether Ring echoes extmaps in the browser case.

[Pulella]

Thank you — this is the most useful reply I could have hoped for, because it kills my main
hypothesis, and it does it with an argument I should have found myself.

1. Opus frame size: conceded

Your two empirical data points would already be enough (your card at stock 20 ms browser Opus,
audible on the video model; ring-client-api at ffmpeg's 20 ms default, also audible). But the
argument that actually settles it is the a priori one: the TOC byte carries the frame duration
and decoding is per-packet, so a device that emits 60 ms has no reason whatsoever to choke on
20 ms. I read a client-side assertion in aiortc's decoder as if it were a property of the wire.
It isn't. Hypothesis 1 demoted.

I'll still run the 60 ms session once tomorrow, purely because it's already built and costs me one
ring — not because I expect anything from it.

And yes, I'll open the aiortc decoder issue upstream; I'll link it here when it's up.

2. Your methodological note is the most valuable part of your reply — it invalidates my Result 4

You wrote that a 0.4 s on / 0.8 s off beep is close to the worst possible probe against a
voice-switched or VAD-gated path. That doesn't just apply to my next test — it applies to the
one I already reported as negative. All 8 sessions behind Result 4 used exactly that pulsed beep.

So "nothing is heard at the door station" is not an established fact. It is fully consistent
with a gate discarding a pulsed probe. I'm downgrading Result 4 from a result to an inconclusive
test, and I'd ask anyone reading this thread later to do the same.

It got worse when I looked at the clip I had queued for the next attempt — spoken voice, so I
thought I'd already fixed the problem. Level profile, one character per 100 ms
(# loud, . quiet, silence), looped end to end:

old clip (4.13 s):  ###   #######.###  ####  ####  ###
                       ^^^                             ^^^^^^^  ← 0.7 s of silence per loop
                    5 silence gaps, longest 700 ms

Still a pulsed signal. I'd have run the same flawed experiment a second time and drawn the same
wrong conclusion. Rebuilt it as continuous speech (counting from one to twenty), internal pauses
compressed to ≤60 ms, head and tail trimmed, normalised:

new clip (11.74 s): ######.######.#####.##########.###############.###############################.######.#####.###.###.################.
                    0 silence gaps

Looped, that's a voice that never stops talking — no gate gets a chance to close. Generator script
is in my repo if it's useful to anyone.

3. B1 and B2: both implemented, both running tomorrow morning

B1 — stock live_view. You're right that "the backend answers" and "the backend wires the
uplink to the bus" are different claims, and video_enabled: false is precisely the kind of flag
that could separate them. My tap now has a --stock-live-view mode: stream_options byte-identical
to upstream (audio_enabled: true, video_enabled: true), plus m=video recvonly in the offer
(audio stays sendrecv), with any incoming video track routed to a MediaBlackhole so the WAV
recorder doesn't choke. Zero deviation from upstream left.

B2 — session-level stream_options. Implemented, sent immediately after activate_session is
forwarded. Everything it needs is already in that message, so there's no state to track:

  us   -->  live_view            {audio_enabled: true, video_enabled: true}
       <--  session_created
       <--  sdp
  us   -->  activate_session
  us   -->  stream_options       {doorbot_id, session_id, audio_enabled: true, video_enabled: true}   <-- new
       <--  notification         {is_ok: true, text: "camera_connected"}
  us   -->  camera_options       {stealth_mode: false}
       <--  camera_started
  us   -->  ping

Question on placement: does ring-client-api send it there, or later — after camera_connected
/ alongside activateCameraSpeaker()? I put it right after activate_session because that's the
earliest point where the session exists, but if their ordering is different I'd rather match it
exactly than guess twice.

Tomorrow morning, one trip to the door station, one ring per session, all four created during an
active call (see §4):

1. B1 stock
2. B1 + B2
3. neither (my old config) but with the continuous clip — this isolates the probe as a variable
   and tells me whether Result 4 was a false negative
4. --tx-ms 60, for closure
5. control: the official Ring app, same trip, same physical state — without this the other four
   prove nothing

Each trace also carries the redacted payload of the ding that opened it. Long shot, but Ring's
two-way talk was historically SIP (sip_server_ip, sip_token, sip_ding_id,
audio_jitter_buffer_ms) and only the newer Ring Edge devices moved to WebRTC. If this 2022 audio
unit still uses SIP for the actual call, that would explain the whole picture at once — app works,
we don't, signaling reports no error, packets genuinely leave the machine — because the real path
would be somewhere else entirely. I'll report either way; a clean "no sip_* fields" is worth
having on the record too.

4. Full-duplex or push-to-talk on the audio model — checked, and it raised something else

Full-duplex. No button to hold, nothing to press at all once the call is answered, and voices
genuinely overlap — I can talk while the other side is talking. So there's no button-down moment for
your hypothesis 3 to hide in, at least not in the obvious place.

But checking it turned up something I think matters more, and I'm slightly embarrassed I hadn't
noticed it before:

In the app I cannot talk unless someone rings me first. There's no "open a session and speak" on
this device — the talk path exists only as the answer to an incoming call. Every working session on
this unit, ever, has been created while a ding was active.

Every one of my sessions was created cold: live_view on demand, no call in progress, and in
some of my tests the ring came afterwards (or not at all). If the backend only wires the upstream
track to the bus for a session created in "answering a call" context, then I have been varying
stream_options, frame durations and volumes while the one variable that actually mattered was
pinned to the wrong value the whole time. That would fit every observation I have: signaling reports
no error, packets genuinely leave the machine, notification says camera_connected, the app works,
and nothing comes out.

I've therefore added a --wait-ding mode to my rig: it authenticates, builds the offer, gathers ICE,
then polls /clients_api/dings/active and fires live_view the moment a ding appears. So tomorrow's
four sessions are all created during an active call, exactly like the app, instead of racing a
one-minute call window by hand. Side benefit: each session's trace now carries the redacted ding
payload, so I get the sip_* question answered per session for free.

Does your integration create the session cold, or in response to a ding? If push-to-talk works on
the video model from a cold live_view with no active call, this idea dies immediately and I'd like
to know before I read too much into tomorrow's results. If your working sessions are also always
call-associated, then this is a variable neither of us has ever controlled for.

5. extmap — I checked my traces, here's the data

Across all 13 recorded sessions, our aiortc offer always carries:

a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level

and Ring's answer carries no a=extmap line at all — every session, recvonly and sendrecv
alike. So it isn't an omission on our side: Ring drops them. Which turns your observation into a
question for you, and it's a cheap one:

In the browser case, does Ring echo any extmap back? If it drops them there too, it's a
non-difference and we can close the line. If it echoes them only on the video kind — and the device
does gate the bus on signalled audio level — it stops being a footnote.

6. The branch: yes, please

Cut the intercom_handset_audio one. It's the experiment with the highest information per hour, it
splits my hypothesis tree cleanly in both directions, and — as you say — it replaces the MITM work
entirely rather than preceding it. If tomorrow's four sessions are all silent while the app is
audible in the same trip, I'll take that as hypothesis 2 promoted and go straight to your branch
rather than spending a week on cert pinning.

I'm setting up HTTPS on my HA instance via the Tailscale add-on — valid certificate, no port
forwarding, no reverse proxy, nothing to install on the wall tablet — so mic access shouldn't be the
thing that holds this up. I'm happy to run dev builds, capture and redact traces, and test anything
you want on the audio model. And whatever the outcome, this unit is a decent rig for you: it has one
independently confirmed working baseline (the official app), which makes every negative result
interpretable.

I'll report back tomorrow with the four results, the app control, the full-duplex/PTT answer, and
the ding payload.

[Pulella]

It works. Two-way audio is confirmed on intercom_handset_audio — and it was your VAD note

I went down to the door station this morning. My voice came out of the outdoor speaker, twice in a
row. Uplink on the audio model works over plain WebRTC. Thank you — the fix came directly out of
your reply, and not from the part I expected.

The runs

#	variant	m=video in offer	TX	RX (60 ms Opus frames)	heard at the door
1	stock live_view (your B1)	yes	0 packets	none	❌ invalid, see below
2	B1 + session stream_options (B2)	yes	0 packets	none	❌ invalid
3	video_enabled: false, continuous clip	no	3672 pkts / 912,268 B	1476	✅ YES
4	same as 3, repeat	no	3658 pkts / 908,901 B	1472	✅ YES

Runs 3 and 4: ~248 bytes/packet at 20 ms, a=sendrecv, no early teardown, ~88 s of audio
received out of 90 — both directions alive for the entire session. Redacted traces attached.

What it actually was: the probe

Your methodological note was the answer. Not the placement of stream_options, not the flags —
the test signal itself.

The crucial detail I hadn't weighted properly: on 22 July, some of those 8 failed sessions were
already made during a real call. So "session created during an active call" is not the variable
that changed today. The variable that changed is the clip: a 0.4 s on / 0.8 s off beep versus
11.7 s of continuous speech with no silence gap longer than 60 ms, looped.

You called it exactly: on an audio-only building intercom there is something voice-switched or
VAD-gated in the Ring → Comelit → Simplebus2 chain, and a pulsed probe is what it discards. Feed it
continuous speech and everything goes through, first try.

So my Result 4 was a false negative produced by the probe, and my hypothesis 1 (60 ms) was
chasing a ghost. Anyone landing on this thread later: if you test uplink audio on one of these,
the test signal must be continuous. A tone burst or a phrase with pauses decides nothing.

Everything else is dead, and that's good news

• 60 ms Opus — works fine at aiortc's stock 20 ms, as your TOC-byte argument predicted.
• video_enabled: false — it works with false. My one deviation from upstream was harmless
  all along, so B1 was unnecessary. Which also means python-ring-doorbell needs no change for
  audio-only intercoms beyond the stream_options field, and arguably not even that.
• Session-level stream_options — not needed.
• SIP — worth recording, because it looked decisive and isn't. The active ding payload for this
  device reports protocol: "sip" and carries eight sip_* fields (sip_ding_id, sip_from,
  sip_server_ip, sip_server_port, sip_server_tls, sip_session_id, sip_to, sip_token). So
  the official app's call path really is SIP on this model. And it doesn't matter: the WebRTC
  uplink reaches the outdoor speaker anyway. Both channels work.
• Buying the video model — I was one week away from spending ~€250 on a video monitor plus a
  Ring Intercom Video to get to a supported two-way path. Not needed.

One real bug, and it's in aiortc

Runs 1 and 2 produced zero media in both directions — TX 0, zero decoded frames — while the
session itself was accepted and ICE completed. The cause:

RTCPeerConnection.__connect → InvalidStateError: RTCIceTransport is closed

Adding a second m-line (m=video recvonly, alongside m=audio sendrecv) makes __connect fail, and
since __connect is what starts senders and receivers, nothing ever flows — silently, unless you
are watching getStats. Both m-lines end up on a single Connection(0) in the aioice log.

That's two aiortc issues from this exercise, then — this one and the hardcoded
SAMPLES_PER_FRAME = 960 in the Opus decoder. I'll file both and link them here.

Where I go from here

Building it in Home Assistant, with the architecture we discussed: HA relays the SDP signaling only,
the tablet's browser does WebRTC directly with Ring, so no transcoding, no fighting the camera
platform, and the Ring token stays server-side. HTTPS via a Tailscale add-on is the last prerequisite.

Two things I'd still value from you:

1. The intercom_handset_audio branch — still worth cutting, and now for a better reason than
   before. It's no longer a diagnostic: it's a shortcut to a working integration for a whole device
   class that currently has none. Browser Opus is continuous speech by construction, so the gate that
   burned me is a non-issue there. I'm happy to be the test rig on real hardware.
2. The extmap question from my previous comment still stands, though it's now just curiosity:
   Ring never echoed a single a=extmap back to my aiortc offers, including ssrc-audio-level. Does
   it echo them in the browser case?

Happy to run any further trace you want while the rig is set up. And thanks again — I'd have spent
another week on frame durations if you hadn't looked at the shape of my test signal.

trace-sendrecv-stock-20260807-091652.log

trace-sendrecv-stock-sessopt-20260807-092136.log

[cmos486]

This is excellent, and congratulations — you got a device class that had no path at all to a working
uplink. Two corrections and then both of your asks.

One variable is still open: your runs don't clear video_enabled

Runs 3 and 4 changed two things relative to 1 and 2: video_enabled: false and the absence of
m=video in the offer. And runs 1/2 aborted locally before a single packet left the host, so they
carry no information about stream_options at all — they only tell us that a second m-line breaks
your aiortc harness.

So what you've established is: audio-only offer + video_enabled: false works. Not
"video_enabled: false works and true was always fine". One run closes it:

Test A — exactly run 3 (no m=video, continuous clip, 20 ms), but with the stock
stream_options: {"audio_enabled": true, "video_enabled": true}.

If it works, python-ring-doorbell needs no stream_options change for this device class and the
field is a non-issue. If it fails, stream_options has to become per-kind and that's an upstream PR
with a real justification. Right now nobody can say which.

While you're there: the m=video ... a=sendonly H264 section in Ring's answer to runs 1/2 is just
SDP mirroring — an answer must have one m-line per offered m-line. It is not evidence of a video path
on a device with no camera, so don't read anything into it.

Your traces do confirm the failure is entirely local

Both runs: session_created → camera_started → camera_connected, pings answered throughout, then
close with code 4 "ICE connection failed" at 22.0 s (run 1) and 22.1 s (run 2) after
session_created. Identical to a tenth of a second — that's a fixed server-side timeout, i.e. Ring
never received a single STUN binding request. Signaling was healthy the whole time. Consistent with
__connect dying before it ever started connectivity checks.

The aiortc report needs more than you have, or it gets closed as unreproducible

Here's the path, against main today (line numbers will drift):

• rtcpeerconnection.py ~L1003–1043 — the BUNDLE block in setRemoteDescription. primaryMid = bundle.items[0], slaves are the rest. For each transceiver where transceiver.mid in slaveMids and not transceiver._bundled, receiver+sender are repointed at the primary transport; the orphaned ones
  then get await dtlsTransport.stop(); await dtlsTransport.transport.stop().
• rtcicetransport.py L350–359 — stop() sets state closed, irreversibly.
• rtcpeerconnection.py L1072–1089 — __connect() calls await iceTransport.start(...), which raises
  InvalidStateError("RTCIceTransport is closed") at rtcicetransport.py L321–329.

So your exception means __connect reached a transceiver still holding a stopped transport — the
reassignment above skipped it. That guard is mid-based and _bundled-based, which is why the report
has to show both.

The catch: with the default bundlePolicy (BALANCED), __createTransceiver only shares a transport
with a transceiver of the same kind, so audio and video get separate transports with
_bundled = False, and the remote-BUNDLE block should reassign the video one cleanly. In other words
your crash is not reproducible from the source as described, which means one of the inputs isn't
what we assume. Capture these or the issue will bounce:

# before setRemoteDescription
print(pc._RTCPeerConnection__configuration.bundlePolicy)
def dump(tag):
    for t in pc.getTransceivers():
        it = t.receiver.transport.transport
        print(tag, t.kind, t.mid, t._bundled, id(t.receiver.transport), id(it), it.state)
dump("pre")
await pc.setRemoteDescription(answer)   # wrap in try/except and dump in the except too
dump("post")

plus the full aiortc DEBUG log — it prints setRemoteDescription(answer) with the SDP and
RTCIceTransport(...) - new -> closed for whichever transport got stopped. Which one closes splits
the diagnosis:

• mid:1 (video) closed, and the audio transceiver still holds it → plain "slave transceiver not
  reassigned" bug, and the mid/_bundled dump names the reason.
• mid:0 (audio) closed → aiortc chose the video transport as primary, meaning the parsed bundle group's
  first item isn't 0. Check sdp.SessionDescription.parse(answer_sdp).group and paste it.

And the thing that will actually get it merged: a Ring-free reproducer. Two local aiortc peers,
offer = audio sendrecv + video recvonly, answer carrying a=group:BUNDLE 0 1 with per-m-line
ice-ufrag/ice-pwd as Ring sends them. If that reproduces, you have a clean bug report. If it
doesn't, the trigger is something specific in Ring's answer, and my first suspect is exactly those
per-section ICE credentials: aiortc validates that each m-line has ufrag+pwd but never checks that
bundled sections agree, and Ring emits a separate ice-ufrag/ice-pwd/fingerprint block per m-line.
Your traces redact both to <UFRAG>/<PWD>, so please diff the two sections' real values before
filing — if they differ, that's a Ring quirk to route around (don't offer the second m-line), not an
aiortc bug, and it's worth knowing which of the two you're looking at.

The SAMPLES_PER_FRAME = 960 one is unambiguous, file that separately.

extmap

In your own traces Ring echoes no a=extmap whatsoever — not ssrc-audio-level, not
abs-send-time. That's compliant and harmless: an extension the answerer doesn't acknowledge is simply
not used (RFC 8285), find_common_header_extensions yields an empty set, and nothing downstream depends
on it.

For the browser case I won't guess from memory — my integration relays the answer opaquely and logs only
timings, not SDP. Two ways to get the real answer: chrome://webrtc-internals on your tablet (the
setRemoteDescription entry shows the answer SDP verbatim), and I'll pull the same from my video-model
rig so you get both models. My expectation is identical output, because that answer is generated by
Ring's RMS (note rms_version and the gml-* cnames in your session_info) and the generator doesn't
appear to vary by offerer.

One consequence worth noting either way: no transport-cc / abs-send-time echo means no
receiver-side bandwidth-estimation feedback loop, so Ring runs a fixed bitrate. Irrelevant for audio,
mildly interesting for the video model.

The intercom_handset_audio branch — yes

I'll cut it. For the record, the interesting part is how little there is to do, and where the actual
upstream gap is:

• python-ring-doorbell does not gate on kind. INTERCOM_KINDS already contains
  intercom_handset_audio (const.py), so nothing in the library treats your device differently. The
  real gap is different and it affects both intercom kinds: generate_async_webrtc_stream,
  on_webrtc_candidate, close_webrtc_stream and sync_close_webrtc_stream live on RingDoorBell
  only. RingOther has none of them. That's why my integration monkey-patches them onto RingOther at
  setup. The upstream PR worth filing is moving those onto RingGeneric (or a small mixin RingOther
  also uses) — not stream_options, unless Test A says otherwise.
• My side, on the branch: widen the discovery gate from intercom_handset_video to both kinds;
  hard-disable the server-side snapshot for the audio kind (async_camera_image must return None
  immediately — otherwise every entity-picture refresh opens a Ring session and blocks ~20 s waiting for
  a video track that will never arrive); expose audio_only: true in the entity attributes so the card
  can adapt.
• The carrier stays a camera entity, because HA's WebRTC relay is a camera-platform feature and
  there's no audio-only entity type. It's a camera that never produces a picture; the companion card
  owns the UI anyway, so that's cosmetic.
• Card side: for this kind the offer must be audio-only — no recvonly video transceiver. Partly
  because a dead second m-line is what burned your harness, mostly because Ring's mirrored H264 section
  would otherwise leave a permanently black <video>. Chrome bundles correctly so it would probably
  survive, but there's no reason to ask for it.

What I need from your rig, in this order: Test A above, and then the first end-to-end browser run
(HA relaying, Chrome doing the WebRTC, audio-only offer). Browser Opus is continuous by construction,
so the gate that cost you three weeks is a non-issue there — but I want to see whether HA's camera
stack objects anywhere to a stream with no video track before I tell anyone else to install this.

Thanks for going down to the door station and for the redacted traces — the 22-second symmetry in those
two logs is what turned "aiortc threw something" into a specific claim.

[cmos486]

Measured the extmap question on the video model, and it forces me to retract two things from my last
comment — one of which would have cost you an afternoon. Also: the branch is up.

extmap: the answer is "yes, exactly one"

Firefox about:webrtc on my rig, remote SDP (= Ring's answer to the browser's offer). Ring echoes a
single header extension, and it echoes it in both m-lines:

a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=rtcp-fb:109 transport-cc     ← audio
a=rtcp-fb:105 transport-cc     ← video

Everything else my browser offered came back dropped: ssrc-audio-level, csrc-audio-level,
sdes:mid, abs-send-time, toffset, playout-delay. The id survives verbatim — offered 7, echoed 7.

Which explains your zero completely, and it has nothing to do with audio-only devices. aiortc's entire
header-extension vocabulary is four entries (aiortc/codecs/__init__.py): sdes:mid and
ssrc-audio-level for audio, sdes:mid and abs-send-time for video. transport-wide-cc isn't in it.
The two sets are disjoint: aiortc never offered the one extension Ring negotiates, so Ring had nothing
to echo. Your ssrc-audio-level was never going to come back — mine didn't either.

Retraction 1: Ring is not running a fixed bitrate

I wrote that the absence of a transport-cc echo meant no bandwidth-estimation feedback loop. Wrong in
the browser case, and wrong for the same reason the above is interesting: transport-cc is negotiated,
so the loop exists. Firefox reports a live send-bandwidth estimate (~22.5 kbps on that session).

It stays true for your aiortc sessions, but as a property of aiortc, not of Ring.

Retraction 2: drop the ICE-credentials lead, it's disproved

I asked you to diff the per-m-line ice-ufrag/ice-pwd in Ring's answer, on the theory that bundled
sections might disagree and that aiortc never checks. In my capture they are identical — same ufrag,
same pwd, verbatim in both sections. Ring repeats the credentials per section, which is what BUNDLE
requires. Please don't spend time there.

What replaces it: bundlePolicy

HA's frontend creates its peer connection with bundlePolicy: "max-bundle" — I read it straight out of
my session config — and Firefox additionally emits the video m-line as a=bundle-only with port 0.
aiortc defaults to BALANCED. That difference lines up exactly with your crash, and it's one line to
test:

from aiortc import RTCBundlePolicy, RTCConfiguration, RTCPeerConnection
pc = RTCPeerConnection(RTCConfiguration(bundlePolicy=RTCBundlePolicy.MAX_BUNDLE))

Why it should matter: under BALANCED, __createTransceiver only shares a transport between
transceivers of the same kind, so your audio and video transceivers got separate ICE transports, and
the code then relies on the remote-BUNDLE block in setRemoteDescription to repoint one and stop() the
other — that stop is what leaves a closed transport for __connect to trip over. Under MAX_BUNDLE, the
second transceiver is handed the first one's transport at creation and marked _bundled = True, so the
remote-BUNDLE block skips it and nothing is ever stopped.

Either outcome is worth having. If B1 now works, you've isolated the bug to the BALANCED reassignment
path and the report writes itself. If it still fails, that's a much stronger claim than we had, because
it rules out the one policy difference between your harness and every browser that talks to this device.

One more thing about Ring's answers, since it changes what generalises

Ring's answer is derived from the offer, not a fixed template. It mirrored my payload types (Opus as
109, H264 as 105) where yours got 96, and it mirrored useinbandfec — my offer said 1 and the answer
said 1; yours said nothing and the answer said 0. So useinbandfec=0 in your traces is a property of
your offer, not of the device. Worth keeping in mind before reading anything else out of the answer's
shape.

The branch is up

intercom-handset-audio —
add the repo to HACS as a custom repository and select that branch. It reports itself as 0.6.0b1 so you
can confirm in the logs what you're running.

Contents, unchanged from what I described: discovery takes both intercom kinds; the server-side aiortc
snapshot is hard-disabled for the audio kind (async_camera_image returns None before touching Ring —
otherwise every entity-picture refresh would open a session and block for the full frame timeout waiting
for a video track that never arrives); the entity exposes audio_only: true in its attributes. The
signaling relay itself is untouched, because it never looked at the device kind in the first place.

The card doesn't read audio_only yet — that's next. Until it does you'll get the audio path with a
black video element sitting on top of it. Don't read anything into the black rectangle.

Still the two things I'd like from your rig, in order: Test A from my last comment (audio-only offer,
stock stream_options with video_enabled: true) to settle whether python-ring-doorbell needs the
field at all, and then the first end-to-end browser run through the branch. If HA's camera stack objects
anywhere to a stream with no video track, tell me exactly where — that decides whether the camera entity
stays the carrier.

[Pulella]

Test A: positive. stream_options is a non-issue.

Audio-only offer, stock stream_options — {"audio_enabled": true, "video_enabled": true} —
continuous clip, aiortc's default 20 ms frames, session opened on the active ding. Audible at the
outdoor panel.

run	video_enabled	TX packets	bytes	bytes/pkt	RX (60 ms Opus frames)	heard
3 (this morning)	false	3672	912,268	248	1476	✅
4 (this morning)	false	3658	908,901	248	1472	✅
Test A	true	3629	901,552	248	1480	✅

Statistically indistinguishable from the two runs that worked with false. a=sendrecv, no early
teardown, media alive in both directions for the full 90 s, one kind=audio track and nothing else.
No control run — a positive can't be a false positive.

So: python-ring-doorbell needs no stream_options change for intercom_handset_audio. The
field simply doesn't matter on this device class, in either value. That closes the question you
raised, and it means the only genuine upstream gap is the one you identified: generate_async_webrtc_stream,
on_webrtc_candidate, close_webrtc_stream and sync_close_webrtc_stream living on RingDoorBell
while RingOther has none of them. Moving those onto RingGeneric or a shared mixin is the PR worth
filing, and I'm happy to test it.

It also means your branch should work on my device unmodified, since it sends true and I've now
shown true is fine.

Where that leaves the picture

Every open question about the device is now closed:

• uplink over WebRTC works on intercom_handset_audio — ✅ demonstrated, three times
• the probe must be continuous, not pulsed — ✅ that was the whole three-week mystery
• 20 ms Opus is fine — ✅
• video_enabled either way — ✅ irrelevant
• SIP fields in the ding are real but not needed — ✅ the WebRTC uplink reaches the bus regardless
• never offer a second m-line from aiortc — ✅ and now enforced in my harness, where the video
  m-line is opt-in behind an explicit flag with a warning, because forgetting it costs a trip to the
  door station

Everything remaining is construction, not discovery.

Next from my side, in your order

1. HTTPS — Tailscale add-on in Serve mode. In progress.
2. Install the branch via HACS as a custom repository, confirm 0.6.0b1 in the logs.
3. First end-to-end browser run. If HA's camera stack objects anywhere to a stream with no video
   track, you'll get the exact traceback and code path, not a summary. And I won't report the black
   rectangle.

Thanks — between the VAD note that unblocked the whole thing and the bundlePolicy capture that
explained the crash, this went from stuck to finished in three days.

trace-sendrecv-stock-20260807-132421.log

[cmos486]

Test A closes it, and a positive with no plausible false-positive mechanism is the right kind of result to
stop on. Agreed on all of it: python-ring-doorbell needs no stream_options change for this device class,
the branch works on your hardware unmodified because it sends true, and the only genuine upstream gap left
is the four WebRTC methods sitting on RingDoorBell while RingOther has none. I'll file that PR and take
you up on testing it.

Two things before you start installing, one of which will save you a wasted evening.

HACS can't install a branch — use the pre-releases

"Install the branch via HACS as a custom repository" doesn't work, and it fails in a confusing way: the
version dropdown only ever lists releases plus the repo's default branch, so intercom-handset-audio
simply never appears and it looks like the custom repository didn't take. I hit this myself.

Both pieces are published as pre-releases instead:

	repo	version
Integration	ring-intercom-video	v0.6.0b1
Card	ring-intercom-video-card	v1.3.0b1

Add both as custom repositories, then in each one: ⋮ → Redownload → enable Show beta versions → pick
the b1. Restart HA after the integration; hard-reload the dashboard after the card. Latest stays on
v0.5.0 / v1.2.0, so nobody else is affected.

The card handles audio-only now, so ignore what I said about the black rectangle

That advice is obsolete — v1.3.0b1 reads audio_only and adapts:

• The offer carries a single m=audio sendrecv and no video m-line. Which is also your finding about
  never offering a second m-line from a client, arrived at from the other direction.
• No video surface at all — an audio-only UI replaces it. Open-door and hang-up are unchanged.
• Remote Opus plays through a hidden <audio> element rather than a hidden <video>, because a
  non-rendered video element can have playback suspended on iOS Safari.
• If the browser's autoplay policy blocks playback, a tap target appears; tapping it retries under the
  fresh user activation. So a blocked autoplay is a visible one-tap fix rather than silence you have to
  diagnose.

The one thing nobody has ever verified

Before the end-to-end run, please confirm the entity exists at all. Nothing in this integration's history
has ever run its discovery against intercom_handset_audio — you'd be the first. Developer Tools →
Template:

{{ state_attr('camera.YOUR_ENTITY','audio_only') }}

True means discovery worked and the branch is live. None means the attribute isn't there — either the
b1 isn't loaded or discovery didn't pick up your device, and those two need different fixes. If no
camera.* entity appears for the intercom at all, the integration logs the kind it discovered at INFO:

logger:
  logs:
    custom_components.ring_intercom_camera: debug

Verification status, so you know what you're walking into

• Card, video path: verified on my rig against both the stable integration and this branch.
• Card, audio-only path: never executed in a browser. Static checks only.
• Integration, audio kind: never run against the hardware. You're the first.

The failure mode is designed to be safe — a missing or unreadable audio_only falls back to the video UI
rather than throwing — but "safe" here means the card still renders, not that the audio path works.

And yes: exact traceback and code path if HA's camera stack objects anywhere to a stream with no video
track. That decides whether the camera entity stays the carrier or whether this needs a different entity
type, and a summary wouldn't settle it.