SIP Core / sip-call-card: no audio playback on iPad (Android OK)

Configuration
1

Hi all,
I’m debugging an issue with TECH7Fox SIP Core + sip-call-card where calls connect fine on iPad, but I cannot hear any audio on iPad (incoming audio is silent). The other direction works just fine. It works perfectly on Android and desktop browsers.

This is used for a door intercom (Mobotix T26) via Asterisk (HA OS add-ons), but the problem is NOT Mobotix-specific: I also don’t get audio when calling the iPad from a Linux SIP client.

Environment

  • Home Assistant Core: 2026.1
  • SIP Core: 5.0.2 (via HACS / Tech7Fox)
  • Asterisk add-on: Tech7Fox Asterisk add-on (HA OS)
  • iPad: iPad 10th gen, iPadOS 17.5.1
  • Tested clients on iPad:
    • Safari
    • Chrome (iOS)
    • Home Assistant Companion App
      → None have audio
  • Android phone works (audio in both directions)

Symptoms

  • iPad rings and answers the call (WebRTC session establishes)
  • Microphone direction (iPad → door / Asterisk) works
  • But speaker direction (door / Asterisk → iPad) is silent
  • Asterisk shows RTP is flowing both directions
  • MixMonitor recording captures audio correctly → audio exists at Asterisk side

Asterisk codec info

From CLI core show channel ... I see negotiated codecs like:

NativeFormats: (ulaw)
WriteFormat: ulaw
ReadFormat: ulaw
WriteTranscode: No
ReadTranscode: No

NativeFormats: (opus)
WriteFormat: slin48
ReadFormat: slin48
WriteTranscode: Yes (slin@48000)->(opus@48000)
ReadTranscode: Yes (opus@48000)->(slin@48000)

So codec negotiation appears OK.

Asterisk RTP debug shows RTP flowing

Typical RTP debug lines during call:
Got  RTP packet from    192.168.0.180:58518 (type 00, seq ..., len 000170)
Sent RTP packet to      192.168.0.60:7078  (type 00, seq ..., len 000160)

... (and vice versa) ...

Sent RTP packet to      192.168.0.180:58518 (via ICE) (type 00, seq ..., len 000170)
Got  RTP packet from    192.168.0.180:58518 (type 00, seq ..., len 000170)

also reported:

Strict RTP learning after ICE completion
Strict RTP learning complete - Locking on source address ...

So ICE + RTP look active.

IPv6 note

iPad always offers IPv6 ICE candidates (cannot disable IPv6 on iPad/router).
I see IPv4 and IPv6 candidates in SDP; Asterisk locks on source addresses successfully.

Current Asterisk PJSIP endpoint config (Mobotix)

pjsip.conf excerpt:

[8001]
type=endpoint
context=from-door
disallow=all
allow=ulaw
allow=alaw
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

aors=8001
auth=8001

[8001]
type=aor
max_contacts=1
remove_existing=yes

[8001]
type=auth
auth_type=userpass
username=8001
password=xxx

rtp.conf

[general]
rtpstart=10000
rtpend=20000
icesupport=yes
stunaddr=stun.l.google.com:19302
rtp_ipv6=no

Dialplan

I tried many dialplan variants. Basic current test:

[from-door]
exten => 8001,1,NoOp(Doorbell -> iPad)
 same => n,Dial(PJSIP/104,30)
 same => n,Hangup()

I also tried early Answer/Playback warm-up ideas, but iPad still silent.

sip-call-card YAML

type: custom:sip-call-card
extensions:
  "100":
    name: morly
  "101":
    name: marina
  "102":
    name: tablet
    override_icon: mdi:doorbell
    video: true
ice_gathering_timeout: 5000
buttons: []

IMPORTANT: Safari console errors (even before calls)

On iPad Safari console I consistently get:

Unhandled Promise Rejection: TypeError: undefined is not an object
(evaluating 'this.config?.buttons.map')

This repeats very often in console.

DOM debugging observation

Using Safari dev tools I checked the component:

  • document.querySelectorAll("sip-call-card").length returns 0 (but that may be because HA uses shadow DOM)
  • I can find sip-call-dialog element, and it has config (including buttons array)

Example:

const d = document.querySelector("sip-call-dialog");
d?.config?.buttons

MixMonitor proof that audio exists

I recorded the call server-side:

Dialplan used:

[from-door]
exten => 8001,1,NoOp(Doorbell -> iPad (record test))
 same => n,Set(__RECFILE=/share/door-${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}.wav)
 same => n,MixMonitor(${RECFILE},a)
 same => n,Dial(PJSIP/104,30)
 same => n,Hangup()

Result: WAV contains proper audio (door side), but iPad still silent.

What I’m looking for / questions

  1. Is this a known iPadOS 17 WebRTC / autoplay / audio-output issue with sip-call-card / sip-core?
  2. Is the buttons.map console error a known bug? (buttons config seems required to avoid runtime errors?)
  3. Does the card create/attach its <audio> element in iOS Safari differently (maybe blocked until user interaction)?
  4. Any recommended configuration to force audio output on iPad (speaker route)?

Thanks!

Attachments I can provide

  • SIP / RTP logs from Asterisk (pjsip set logger on, rtp set debug on)
  • iPad Safari console screenshots
  • full YAML and SIP Core config
2

Maybe this? WebRTC endpoints no longer working with latest version. · Issue #422 · TECH7Fox/asterisk-hass-addons · GitHub