Dahua VTO2111D-P-S2: registration flapping (digest nonce/nc reuse) and call teardown after answer

[teuchezh]

Dahua VTO2111D-P-S2: registration flapping (nonce/nc reuse) + call media negotiation fails (PCM/16000)

Environment

• VoIP Stack version: 2026.8.0
• Home Assistant Core: 2026.7.3 (HAOS 18.1, running as a Proxmox VM, --network=host)
• Device: Dahua VTO2111D-P-S2, firmware V4.700.0.3, User-Agent: Dahua UAC/3.0 VTO2111D-P-S2
• SIP transport: UDP, port 5060
• Auth: local SIP account created in VoIP Stack (username 100, digest auth, realm="voip_stack")
• VTO configured as Third-party SIP server client (its own "SIP Server" toggle OFF), registering to HA.

Summary

A Dahua VTO can register to the VoIP Stack local registrar and signaling reaches HA, but I run into three separate Dahua-specific interop problems. All three are reproducible and I have full tcpdump traces for each.

---

1. Registration flapping (digest nonce / nc reuse)

The VTO reuses the same cnonce="0a4f113b" on every request and always sends nc=00000001. On the periodic re-REGISTER (Expires: 60) it also reuses the previous nonce. The result: one REGISTER succeeds with 200 OK, but subsequent refreshes with the same nonce/nc get 401, so the contact flaps online/offline roughly every 60 seconds.

Username in Authorization matches From/Contact (both 100), and response is recomputed correctly — it still gets 401 on refresh:

REGISTER sip:192.168.1.112 SIP/2.0
From:    <sip:100@192.168.1.112:5060>;tag=...
To:      <sip:100@192.168.1.112:5060>
Contact: <sip:100@192.168.1.108:5060>
Authorization: Digest username="100", realm="voip_stack",
  nonce="3fc65932afe543221c87b7786c11246d", uri="sip:192.168.1.112",
  response="5c298e37bcfba35afe8c7b4a3de856e4", algorithm=MD5,
  cnonce="0a4f113b", qop=auth, nc=00000001
Expires: 60
User-Agent: Dahua UAC/3.0 VTO2111D-P-S2 V4.700.0.3

-> SIP/2.0 200 OK          (first REGISTER)
-> SIP/2.0 401 Unauthorized (subsequent refreshes, same nonce + nc=00000001)

Question: can the registrar tolerate Dahua's non-incrementing nc / nonce reuse (or issue a fresh nonce) without dropping the binding, so the endpoint stays stable? Similar Dahua deployments report the device also expects OPTIONS/keepalive after registration.

tcpdump — registration flap (successful 200 OK surrounded by 401 refreshes)

# initial REGISTER (no auth) -> 401 challenge
18:20:38 In  192.168.1.108.5060 > 192.168.1.112.5060: REGISTER sip:192.168.1.112 SIP/2.0
  Call-ID: 9ec5b5b1152be0e4341c0876f2f3fef4
  From:    <sip:100@192.168.1.112:5060>;tag=09dd7576ce183adb2a78115eb529b00c
  Contact: <sip:100@192.168.1.108:5060>
  CSeq: 1 REGISTER   Expires: 60
18:20:38 Out 192.168.1.112.5060 > 192.168.1.108.5060: SIP/2.0 401 Unauthorized
  WWW-Authenticate: Digest realm="voip_stack", nonce="e513d352dad9c93e767c1c17e98227e9", algorithm=MD5, qop="auth"

# authed REGISTER, username matches From/Contact, response recomputed
18:34:20 Out ... 401 Unauthorized
18:34:21 In  192.168.1.108.5060 > 192.168.1.112.5060: REGISTER sip:192.168.1.112 SIP/2.0
  Authorization: Digest username="100", realm="voip_stack",
    nonce="...", uri="sip:192.168.1.112",
    response="faa90fe346dc97fbbb79d4416778a6ea", algorithm=MD5,
    cnonce="0a4f113b", qop=auth, nc=00000001
  Expires: 60
18:34:21 Out 192.168.1.112.5060 > 192.168.1.108.5060: SIP/2.0 200 OK   <-- succeeds once

# next refresh reuses same nonce + nc=00000001 -> 401 again, contact flaps offline
18:34:49 Out ... SIP/2.0 401 Unauthorized
18:34:50 Out ... SIP/2.0 401 Unauthorized
18:34:51 Out ... SIP/2.0 401 Unauthorized

Note: across many capture sessions the cnonce is always 0a4f113b and nc is always 00000001.

---

2. Call media negotiation fails — VTO offers PCM/16000, HA sends BYE

Calling HA softphone -> VTO: INVITE -> 180 Ringing -> 200 OK, then HA immediately sends ACK followed by BYE, so the call drops right after answer.

HA offered:

a=rtpmap:98 OPUS/48000/2
a=rtpmap:8  PCMA/8000/1
a=rtpmap:0  PCMU/8000/1
a=rtpmap:96 L16/16000/1

VTO 200 OK SDP answer:

a=rtpmap:96 PCM/16000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=sendrecv
a=rtpmap:103 H264/90000
a=sendonly

The VTO advertises Dahua wideband PCM/16000 (payload 96) for audio plus H264 sendonly video, which does not match HA's offered L16/16000 / PCMA / PCMU / OPUS. HA appears unable to select a common audio format and tears the call down with BYE right after ACK.

Question: is Dahua PCM/16000 (payload 96) meant to be treated as L16/16000, or is a G.711-only (PCMA/PCMU) path the expected way to interoperate with Dahua VTO? Is there a way to force/pin the negotiated audio codec for a given account or route?

tcpdump — HA softphone -> VTO: INVITE -> 180 -> 200 OK -> ACK -> immediate BYE

# HA offers OPUS / PCMA / PCMU / L16
17:55:43 Out 192.168.1.112.43269 > 192.168.1.108.5060: INVITE sip:DOORBELL@192.168.1.108:5060 SIP/2.0
  From: <sip:Home%20Assistant@192.168.1.112:43269;transport=udp>;tag=2f112417ef5364c6
  To:   <sip:DOORBELL@192.168.1.108:5060>
  a=rtpmap:98 OPUS/48000/2
  a=rtpmap:8  PCMA/8000/1
  a=rtpmap:0  PCMU/8000/1
  a=rtpmap:96 L16/16000/1

17:55:43 In  192.168.1.108.5060 > 192.168.1.112.43269: SIP/2.0 180 Ringing
17:55:43 In  192.168.1.108.5060 > 192.168.1.112.43269: SIP/2.0 200 OK
  Content-Type: application/sdp   (VTO answer)
  a=rtpmap:96 PCM/16000
  a=rtpmap:99 telephone-event/8000
  a=fmtp:99 0-15
  a=sendrecv
  a=rtpmap:103 H264/90000
  a=sendonly

17:55:43 Out 192.168.1.112.43269 > 192.168.1.108.5060: ACK sip:DOORBELL@192.168.1.108:5060 SIP/2.0
17:55:43 Out 192.168.1.112.43269 > 192.168.1.108.5060: BYE sip:DOORBELL@192.168.1.108:5060 SIP/2.0
  <-- HA hangs up immediately after ACK; call never streams audio

---

3. Button-call routing

• Pressing the door button also emits Dahua-proprietary MESSAGE requests with alarm JSON (e.g. "SenseMethod": "DoorMagnetism"), which HA answers with 405 Method Not Allowed.
• The button's voice INVITE targets the Dahua "management centre" number, not a normal phonebook contact.
• Routing the button call to a TCP-registered softphone yields 480 Temporarily Unavailable with X-Voip-Stack-Decline-Reason: transport_unreachable, because the VTO leg is UDP and the softphone registered over TCP.

INVITE sip:102@192.168.1.112 SIP/2.0     (from VTO, UDP)
-> SIP/2.0 480 Temporarily Unavailable
   Reason: X-Voip-Stack;cause=480;text="transport_unreachable"
   X-Voip-Stack-Decline-Reason: transport_unreachable

Question: is cross-transport bridging (UDP caller -> TCP-registered callee) expected to work through HA, or must both legs share a transport?

tcpdump — Dahua MESSAGE (alarm JSON) + UDP INVITE to TCP-registered softphone -> 480

# Dahua-proprietary MESSAGE on button/event -> 405
In  192.168.1.108.5060 > 192.168.1.112.5060: MESSAGE sip:100@192.168.1.112:5060 SIP/2.0
  Content-Type: json/aplication
  { "Alarm": { "Channel": 5, "RoomNumber": "DOORBELL", "SenseMethod": "DoorMagnetism" } }
Out 192.168.1.112.5060 > 192.168.1.108.5060: SIP/2.0 405 Method Not Allowed

# VTO (UDP) INVITEs softphone registered over TCP -> transport_unreachable
In  192.168.1.108.5060 > 192.168.1.112.5060: INVITE sip:102@192.168.1.112:5060 SIP/2.0
  From: <sip:DOORBELL@192.168.1.112>;tag=...
  To:   <sip:102@192.168.1.112:5060>
Out 192.168.1.112.5060 > 192.168.1.108.5060: SIP/2.0 480 Temporarily Unavailable
  Reason: X-Voip-Stack;cause=480;text="transport_unreachable"
  X-Voip-Stack-Decline-Reason: transport_unreachable

# the softphone in question is registered over TCP:
In  192.168.1.160.58266 > 192.168.1.112.5060: REGISTER sip:192.168.1.112:5060 SIP/2.0
  Via: SIP/2.0/TCP 192.168.1.160:58266;alias;...
  From: "phone" <sip:phone@192.168.1.112>;tag=...
Out SIP/2.0 200 OK

---

Notes

• Registration only became stable-ish once From/Contact identity and the Authorization username were both aligned to the same value (100). Earlier the VTO put its device number (8001) in From/Contact while sending a different Authorization username, which never authenticated.
• I can attach full tcpdump captures for registration (the 401/200 flap) and for the call (INVITE -> 200 OK -> BYE) on request.

[teuchezh]

Working setup steps for a Dahua VTO (third-party SIP client to VoIP Stack)

Posting the configuration that finally produced a stable 200 OK registration, in case it helps other Dahua owners. Tested on a VTO2111D-P-S2, firmware V4.700.0.3 (User-Agent: Dahua UAC/3.0). Field names differ slightly across Dahua firmware versions, but the logic is the same.

The single biggest gotcha: the value Dahua puts in the SIP From/Contact headers (its device number / "VTO No." / "№ комнаты") must be identical to the auth username in the SIP-server page. If they differ, digest auth never matches and you get an endless 401 loop even though everything "looks" correct. Align both to the same value.

1. Create the local SIP account in Home Assistant

In the VoIP Stack integration, add a phone / voip_stack.create_account with:

• SIP username: a value you will also use as the VTO device number, e.g. 100 (a plain number is safest — avoids the case-sensitivity trap below).
• SIP password: keep it simple — letters + digits only, no leading -, no symbols, and not too long. Dahua firmware can silently mangle/truncate special characters, which produces a wrong digest hash and a permanent 401. Something like Doorbell2026 works.

2. Set the VTO device number to match

On the VTO, in Local Setting -> "Конфигурация локального устройства" / device config:

• Set "№ комнаты дома" / VTO No. / device number to the same value as the SIP username, e.g. 100.

This is the value that ends up in From:/Contact: of the REGISTER. It must equal the auth username from step 3.

3. Configure the SIP server page

On the VTO, Network Setting -> SIP Server:

• SIP-server toggle (top): leave it OFF. On this firmware the toggle means "this VTO acts as the SIP server", not "enable SIP". With it off the VTO behaves as a client that registers to your third-party server. (Counter-intuitive, but with it ON the VTO stops registering and hosts its own server.)
• Server type: Third-party SIP server.
• IP / domain: your Home Assistant IP.
• Port: 5060.
• "Custom username" toggle: turn it ON so the username field becomes editable.
• Username: the same value as steps 1 & 2 (100). This is the digest auth username and must match From/Contact.
• Password: type it by hand (don't paste), exactly matching the HA account password.
• SIP domain: leave the Dahua default (VDP) — HA ignores it.
• Leave the secondary "SIP server username/password" fields empty (they are for a different purpose).
• Apply.

4. Force the VTO to drop its cached credentials

Dahua caches the SIP digest and will keep sending an old hash after you change username/password, so it keeps failing with 401. After any credential change, force a fresh registration:

• Toggle Server type to VTO, Apply, then back to Third-party SIP server, re-enter the fields, Apply — or just reboot/power-cycle the VTO.

You can confirm it re-computed by watching the response= value in a capture change (see below).

5. Verify with tcpdump

tcpdump -n -i any host <VTO_IP> and port 5060 -A | grep -A2 -iE "register sip|200 ok|401|username"

You want to see, in the same REGISTER:

• From: <sip:100@...> and Authorization: ... username="100" — the two match.
• a freshly computed response=...
• the server replies SIP/2.0 200 OK.

If you still get 401 with matching usernames, the password differs between the VTO and HA — retype it by hand on both sides and force-refresh (step 4).

Known remaining problems (see the issue above)

Even with a clean 200 OK, two Dahua-specific issues remain unsolved for me and are the subject of this issue:

1. Registration flapping: the VTO reuses the same nonce + cnonce with nc=00000001 on every refresh, so periodic re-REGISTERs get 401 and the contact goes online/offline about every 60 s.
2. Audio never streams: on a call the VTO offers PCM/16000 (Dahua wideband) instead of L16/16000 / G.711, and HA sends BYE right after ACK.
3. Cross-transport: a UDP VTO calling a TCP-registered softphone returns 480 transport_unreachable; register the softphone over UDP to match the VTO.

Hope this saves someone the multi-hour debugging session it took to get this far.

[teuchezh]

Additional finding: an inbound INVITE (HA -> VTO) drops the VTO's SIP registration

Follow-up to the registration flapping above. I can now reproduce a hard registration reset that is triggered by a call, not just by the periodic refresh.

Reproduction

1. VTO is registered and stable (REGISTER -> 200 OK).
2. Place a call from the HA softphone to the VTO (HA is the caller, VTO is the callee).
3. The VTO announces "call ended" on the device and replies 486 Busy Here.
4. Immediately afterwards the VTO tears down its registration and starts a fresh REGISTER cycle from scratch (new Call-ID, REGISTER without auth first), which then falls back into the 401 loop.

So the VTO does not just reject the inbound call — receiving the INVITE appears to reset its whole SIP stack, dropping the binding.

Timeline from tcpdump

19:16:41  In  REGISTER (auth) ->
19:16:41  Out SIP/2.0 200 OK                      # registered, stable

19:17:02  In  INVITE sip:100@192.168.1.112        # HA calls the VTO
              From: <sip:100@192.168.1.112>       # (HA softphone -> VTO)
              SDP offer: OPUS/48000, PCMA/8000, PCMU/8000, L16/16000
19:17:02  Out INVITE sip:100@192.168.1.108        # HA opens the leg toward the VTO
19:17:02  In  SIP/2.0 486 Busy Here               # VTO -> "call ended" on device
19:17:02  Out SIP/2.0 486 Busy Here
              Reason: X-Voip-Stack;cause=486;text="busy"

19:17:09  In  REGISTER sip:192.168.1.112          # <-- VTO re-registers from scratch
              Call-ID: e230ba11...  (no Authorization)
19:17:09  Out SIP/2.0 401 Unauthorized
19:17:10  In  REGISTER (auth, same nonce, nc=00000001) ...
19:17:10  Out 401 Unauthorized
19:17:11  Out 401 Unauthorized
19:17:12  Out 401 Unauthorized                    # back in the 401 loop

Notes / open questions

• This is reproducible: a stable 200 OK binding is lost within seconds of an inbound INVITE from HA.
• The VTO is configured as a third-party SIP client (its own "SIP Server" toggle OFF). In this mode it may not be designed to accept inbound voice calls at all — but instead of cleanly rejecting the INVITE and keeping its registration, it drops the whole binding.
• Likely related to the media mismatch in the main issue (VTO expects Dahua PCM/16000, HA offers OPUS/PCMA/PCMU/L16), i.e. the VTO cannot negotiate the offered INVITE and its SIP stack reacts by resetting.
• Practical effect: any HA-initiated call to the VTO, and any failed call in general, knocks the doorbell offline until it re-registers. Only the VTO -> HA direction (button press) seems viable on this firmware.

Device: Dahua VTO2111D-P-S2, firmware V4.700.0.3, User-Agent: Dahua UAC/3.0. Full capture available on request.

[n-IA-hane]

Thank you for the detailed captures and the exact Dahua configuration. They were very useful.

I have published the fixes as the VoIP Stack v2026.8.1 pre-release. You can install it directly through HACS:

1. Open HACS → VoIP Stack.
2. Open the three-dot menu and select Redownload.
3. Under Need a different version?, select v2026.8.1.
4. Restart Home Assistant.
5. Refresh the browser/Companion frontend cache before testing the HA phone card.

This build adds a deliberately narrow Dahua interoperability profile for devices identifying as Dahua UAC/...:

• the vendor PCM/16000 offer is handled as 16 kHz, mono, signed little-endian PCM with 20 ms frames rather than being confused with standard RFC L16;
• the profile is preserved through direct calls, forwarding, ring groups and media re-INVITEs;
• stale/replayed digest nonces now receive a fresh stale=true challenge while incorrect passwords remain normal authentication failures;
• reverse calls can reuse the live registered TCP flow;
• the selected contact User-Agent is retained so HA applies the profile to the actual registered Dahua device.

The exact profile has passed simulated audio/video calls in the HA lab, but I do not own this physical VTO model, so your field test is the important remaining validation.

Could you please test these cases?

1. Leave the VTO registered for at least two or three refresh cycles and confirm whether the online/offline flapping has stopped.
2. Place a VTO → HA call and check bidirectional audio.
3. Place an HA → VTO call and check whether it now rings instead of returning 486 and resetting registration.
4. If the model offers video, test video negotiation and enabling/removing video during the call.
5. If possible, repeat the reverse call with the VTO registered over both UDP and TCP and report which transport was used.

If anything still fails, please attach a sanitized SIP capture or debug log covering REGISTER, INVITE, SDP, final response, ACK and BYE. Please remove private IP addresses, credentials and public numbers first.

[teuchezh]

Thank you for the detailed captures and the exact Dahua configuration. They were very useful.

I have published the fixes as the VoIP Stack v2026.8.1 pre-release.

Thanks for the fast turnaround — I upgraded to v2026.8.1 and field-tested it on the physical Dahua VTO2111D-P-S2, firmware V4.700.0.3 (User-Agent: Dahua UAC/3.0), SIP over UDP. Results below.

1. Registration flapping — fixed in practice ✅

The stale=true challenge works. On each refresh the VTO still sends the previous nonce first, gets a 401 ... stale=true with a fresh nonce, then re-sends and receives 200 OK. The binding is retained across refreshes (CSeq keeps incrementing, no re-REGISTER from scratch), and the online/offline flapping in HA has stopped.

REGISTER (old nonce) -> 401 Unauthorized  (stale=true, fresh nonce)
REGISTER (new nonce) -> 200 OK

Minor note: the VTO always presents the stale nonce first on every refresh, so there is one extra 401→stale→200 round-trip per refresh cycle. Not a problem functionally — registration stays up — just an observation about this firmware.

2. VTO → HA call, bidirectional audio ✅

Button press rings the HA card. Audio works in both directions. The vendor PCM/16000 profile is negotiated correctly now (no more immediate BYE after ACK).

3. HA → VTO call — no more 486 / no registration reset ✅

This is the big one. Previously an HA→VTO INVITE returned 486 Busy Here and reset the VTO registration. On v2026.8.1 it now works:

INVITE sip:100 (HA -> VTO) -> 100 Trying -> 101 Dialog Establishment -> 180 Ringing -> 200 OK
VTO SDP answer: m=audio PCM/16000 + m=video H264/90000 sendonly
... normal BYE on hangup, registration stays intact

The call sets up, media negotiates, and hanging up ends with a clean BYE instead of dropping the registration.

4. Video negotiation ✅

H264 negotiates in both call directions (VTO offers H264/90000 sendonly, HA offers/answers H264). Video shows in the HA softphone card (over HTTPS). I did not specifically stress-test add/remove video mid-call via re-INVITE yet — can try if useful.

5. Transport

Tested with the VTO registered over UDP only (this firmware registers over UDP in third-party SIP mode). I did not test a TCP registration for this device.

---

Summary: on real VTO2111D-P-S2 hardware, v2026.8.1 fixes registration stability, VTO→HA audio, and — importantly — HA→VTO calls that used to 486-and-reset. Video works too. Thank you for the Dahua interoperability profile.

Setup notes for other Dahua owners who find this: the device number / VTO No. must equal the SIP auth username (I used 100), keep the password simple (no leading -/special chars — Dahua can mangle it), and point the button's call target at a different extension than the VTO's own number, otherwise the VTO INVITEs itself and returns 486.

Perhaps my messages look too polished, but I used AI for debugging, it’s easier not to miss details and analyze the information.

IMG_8085.mp4

Please ignore the buzzing sound at the beginning of the video, it's just my phone vibrating from a notification.

[teuchezh]

So, I tested it for a while and noticed that if I answer a call using the companion app on iOS, there's no sound on the phone. I can't hear the sound coming from the intercom, and it seems like there's no sound coming from the phone either. I need to do more testing and document all the possible cases. I honestly don't know yet whether the problem is in the VoIP stack or on the phone.

[n-IA-hane]

Thank you for the additional test, and sorry: I do not currently have an iOS device available, so I cannot honestly validate Companion audio on iPhone myself.

Your hardware confirms the original Dahua interoperability paths: stable registration, bidirectional VTO/HA calls and H.264. The Companion iOS media path remains unverified.

Please keep reporting any results here. If anyone else is using VoIP Stack on iOS, feedback about both working and failing audio would be very useful. Where possible, please include:

• iOS and Companion app versions;
• call direction and which endpoint answered;
• whether microphone permission is enabled;
• whether the same call works in iOS Safari or a desktop browser;
• whether neither direction works or only iPhone transmit/receive fails.

I will leave the issue open so we can build a reliable compatibility picture instead of assuming the behaviour from platforms we have not tested.

[locradogna38-ha]

Hi,

I tested the fix included in VoIP Stack v2026.8.1 on my Dahua VTO3211D-P-S2, but unfortunately the problem is still present.

My environment is:

Home Assistant Container on Debian
VoIP Stack 2026.8.1
Dahua VTO3211D-P-S2
Firmware V4.511.0000000.0.R (2022-05-23)
UDP trunk
Browser endpoint ("Casa")

SIP registration works correctly:

REGISTER
401 Unauthorized
REGISTER (Authorization)
200 OK

The trunk stays registered without any issue.

Incoming calls also work correctly: the Home Assistant softphone rings and the caller (8001) is displayed.

However, as soon as I press Answer, the call is immediately terminated.

The SIP flow is:

INVITE
100 Trying
183 Session Progress
200 OK
ACK
BYE (sent by VoIP Stack)
200 OK

The BYE is generated by VoIP Stack, not by the Dahua device.

The SDP negotiation appears to succeed because the VTO offers PCMU/8000 and PCM/16000, while VoIP Stack answers with PCMU/8000, so there is already a common audio codec.

In addition, the VoIP Stack frontend still reports this error:

Cannot read properties of undefined (reading 'getUserMedia')

and the browser console shows:

voip-stack-engine: audio setup failed
TypeError: Cannot read properties of undefined (reading 'getUserMedia')

I also tested with the Home Assistant Companion App on iPhone, and the behaviour is exactly the same: after pressing Answer, the call is immediately disconnected.

So it seems that the fix in v2026.8.1 does not solve the issue on the VTO3211D-P-S2 running firmware V4.511.0000000.0.R.

If it helps, I can provide the complete SIP tcpdump, browser console logs, or perform any additional tests you would like me to run. Thank you for your work on VoIP Stack!

[n-IA-hane]

Thank you for the detailed VTO3211D-P-S2 follow-up. The new trace identifies a different failure from the original Dahua SIP and codec problems.

The SIP dialog reaches 200 OK and ACK, then VoIP Stack terminates it because the frontend cannot create its audio path. The reported navigator.mediaDevices.getUserMedia error confirms that the active browser or Companion web view does not expose the required microphone API. This is not a registrar or PCMU negotiation failure.

The current dev branch now performs a media capability and microphone preflight before sending Answer or starting an outgoing browser call. It therefore no longer accepts the SIP call and immediately sends BYE after discovering that audio cannot be created. In an unsupported context it keeps the incoming call ringing and reports a clear local media error. In a supported secure browser context it obtains permission before signaling and continues normally.

The existing Dahua interoperability fixes remain unchanged: digest refresh with stale nonce, PCM/16000, PCMU, H.264, bidirectional calls and clean BYE are still covered.

Please test the refreshed pre-release through HACS. Updating the repository or restarting Home Assistant alone is not sufficient because HACS keeps the previously downloaded component files:

1. In HACS, open VoIP Stack, enable pre-release versions if necessary, use the three-dot menu and select Redownload.
2. Select the 2026.8.1-dev pre-release and complete the download.
3. Restart Home Assistant.
4. Clear the Home Assistant frontend cache in the browser or Companion app. This is required because the card multimedia engine changed.
5. On desktop, use Home Assistant through HTTPS and confirm microphone permission is enabled.
6. Retry VTO to Casa and Casa to VTO, then report whether the call proceeds or which new preflight message is shown.

I do not have a VTO3211D-P-S2 or an iPhone available, so I cannot honestly claim a complete device-specific validation. Without the affected hardware, further firmware-specific work is mostly inference from captures and logs.

If you can provide an isolated disposable Home Assistant VM or LXC near the VTO, temporary VPN access and SSH access would let me reproduce and iterate independently over the weekend. Please reply here if that is possible and we can arrange the access details securely. Do not post credentials in the issue. If an isolated environment is not possible, we can continue with sanitized captures and controlled try-and-test iterations.

Thanks again for the real hardware testing.

[teuchezh]

TypeError: Cannot read properties of undefined (reading 'getUserMedia')

This problem also occurs when, for example, you use the local IP address of the Home Assistant server. Local addresses, as we know, lack SSL and use the HTTP protocol. Modern browsers, for security reasons, do not allow access to the microphone and camera on resources without SSL. Please pay attention to this as well.

[n-IA-hane]

@teuchezh is right, I hadn't thought of that! I take this for granted by now. In any case, a user pointed out to me that by properly setting some rules in the browser you can get media over non-SSL connections, but these options aren't active by default: every browser has its own method and its own options to enable. On Android apps though, I don't think you can disable SSL regardless.