MeshPTT：iOS 離線對講研究

結論Summary

• 手機對手機的對講，在實機上跑得起來。iPhone 與 iPad 之間的音訊走 Apple 的點對點 Wi‑Fi（AWDL），不經路由器；完全離線（飛航模式＋Wi‑Fi）的情境尚未實測。Wi‑Fi Aware 在實機上也可用，簽章時由 Xcode 自動加上權限，沒有遇到需要 Apple 額外核准的情況。
• App 內部延遲（實機、真實麥克風、點對點）：total p50 約 74～77 ms、p95 約 115～117 ms。這是 App 內部量到的數字，不含喇叭與麥克風硬體延遲（實機量到兩者合計約 3～9 ms）。模擬器的數字不代表無線延遲，請見「實測數字」的條件標示。
• 用 AirPods 達成 <150 ms 做不到。只要使用 AirPods 的麥克風，播放就會被拉到通話用的 HFP（16 kHz 單聲道）。整條路徑估算典型約 195 ms，合理偏緊的設定也約 159 ms，現實區間約 160–260 ms；有線耳機典型約 111 ms。判讀AirPods 麥克風上行的實測毫秒數查不到，必須實機量（實驗 E1）。
• Apple 的 PushToTalk 框架不適合「完全離線」。它的收音喚醒要靠 APNs，或區網上的自家伺服器（Local Push Connectivity）；純手機對手機、沒有伺服器時，文件中沒有任何喚醒機制。確定
• 沒有現成方案可直接用。Apple 自己的 Walkie‑Talkie 已在 watchOS 27 停用；App Store 上的離線點對點對講 App 都是獨立開發者小品、多建在已被標為棄用的 Multipeer 上，沒有一個公布延遲數字；開源可商用的幾乎沒有。確定
• 目前最大的實際問題是「回授」與「鎖屏」。兩台裝置距離很近、喇叭外放時會互相收音形成嘯叫，防回授正在開發；手動鎖屏會中斷通話，背景保活尚未處理。

標記規則：確定＝在官方文件或其他出處直接看到；判讀＝推論，會寫依據；查不到＝找過沒有可信出處。

可行性研究Feasibility

在動手寫程式之前，先針對傳輸、音訊延遲、Apple 內建功能、現成 App 與開源專案做了一輪調研（2026-11-14）。以下摘要保留原本的「確定／判讀」標記與出處連結。

2.1 傳輸路線比較

確定出處： TN3213、 Multipeer 框架頁、 MCSession、 Apple 論壇（Multipeer 與 Network.framework 共用底層）、 AWDL jitter 與 Wi‑Fi Aware 建議、 Wi‑Fi Aware 框架頁、 官方範例、 WWDC25 228、 iOS 26 Release Notes、 The Register：AWDL 延遲研究報導（摘要，非原文）、 藍牙 L2CAP（Apple 論壇）、 CBL2CAPChannel。

判讀建議路線：Wi‑Fi Aware 負責配對與資料通道，Network.framework 的點對點當 A/B 對照。依據：Apple 文件把低延遲、多連線、背景可連都寫進 Wi‑Fi Aware；論壇上 Apple 工程師在 AWDL 抖動的討論中，直接建議改試 Wi‑Fi Aware 的 realtime。

判讀3–6 人不需要多跳 mesh：單跳全連接或星狀就夠（相鄰的人在同一個空間；Apple 沒有現成的多跳路由機制，查不到）。全連接的連線數為 3 人 3 條、4 人 6 條、5 人 10 條、6 人 15 條；頻寬不是問題。

2.2 AirPods 的瓶頸：用了麥克風，播放就掉到 HFP

• 確定Apple 文件：A2DP 是「stereo, output-only」，沒有麥克風；playAndRecord 同時允許 A2DP 與 HFP 時，「the system gives hands-free ports a higher priority for routing」（allowBluetoothA2DP）。voiceChat 模式會自動套用 allowBluetoothHFP（voiceChat）。
• 確定（開發者回報）iOS 26.6.1、AirPods Pro：voiceChat 加 HFP 時，session 取樣率 16000、輸出 1 聲道（LiveKit issue #467）。
• 判讀16 kHz 單聲道對語音可懂度夠，但沒有立體聲、有「電話味」；多人同時說話只能混成單聲道。
• 判讀繞過 HFP（iPhone 內建麥克風＋AirPods 的 A2DP 播放）依文件字面可行，但有互相矛盾的回報，需實機驗；而且延遲反而更差（A2DP 下行約 140 ms，HFP 下行約 40 ms）。
• 確定iOS 26 的「高品質錄音」bluetoothHighQualityRecording 不是解法：Apple 文件寫「may increase input latency … isn't recommended for real-time communication usage」，只能搭配預設模式（拿不到語音處理的回音消除與降噪），且歐盟不支援。（官方文件、WWDC25 251、論壇實測（單一發文者））
• 判讀AirPods 的「低延遲」（Game Mode）Apple 沒有公布毫秒數，非遊戲 App 能否取得、麥克風開啟時是否仍有效都查不到；把對講 App 宣告成遊戲類別有審核風險，不列入基準方案。（Apple Newsroom、Game Mode 支援頁）

2.3 端到端延遲預算（單向，口到耳）

路徑 A：AirPods 麥克風＋AirPods 播放（HFP、voiceChat、語音處理，標準做法）。傳輸與 jitter buffer 兩欄是假設值，其餘多為推估。單位：毫秒。

判讀把幀長改 10 ms、jitter buffer 20 ms、傳輸 8 ms，典型仍約 159 ms，超過 150。結論：AirPods 路徑只有全部押樂觀才可能 <150 ms，現實區間約 160–260 ms，中位約 195 ms。

四條路徑對照（單向，毫秒）

確定A2DP 播放延遲的錨點：Stephen Coyle 量測 AirPods Pro 2 約 126 ms（9to5Mac、原文）；開發者回報 outputLatency 約 160 ms（論壇）；Game Mode 下 151 ms 降到 60 ms（論壇）。

判讀ITU‑T G.114 的說法是多數使用者在口到耳 200 ms 以內仍滿意；路徑 A 典型約 196 ms 剛好在邊緣。對講是輪流說話，容忍度可能比電話高，但這一點沒有出處，需要實驗與使用者試用確認。

2.4 PushToTalk 框架：沒有網路時能不能用？

確定官方唯一列出的收音喚醒路徑是 APNs 的 pushtotalk 推播；替代路徑是 Local Push Connectivity（需要區網上的自家伺服器、依 Wi‑Fi SSID 啟動、要向 Apple 申請受管 entitlement）。

• 有同一個區網 Wi‑Fi 和區網伺服器：有官方路徑。
• 純手機對手機、沒有 AP、沒有伺服器：文件沒有任何喚醒被 suspend 的 App 的機制。
• 框架不禁止自備點對點傳輸，但離線時它剩下的價值只有系統 UI、鎖定畫面按鈕與 audio session 優先權。藍牙喚醒後能否自行進入收音狀態：查不到、未驗證。判讀
• 確定其他限制：加入頻道必須在前景且有使用者明確操作；同時只能一個頻道；不能自己 setActive audio session。

出處：PushToTalk 教學、Local Push Connectivity、Apple 論壇：後端需求、WWDC22 10117（後兩者為摘要）。

2.5 Apple 內建功能：有沒有重造輪子？

確定沒有。Apple 內建的沒有任何一個能滿足「3–6 人、AirPods、雙向、不用網路」。

判讀iOS 26／27 沒有新增相關功能；Apple 在 2026 年不但沒補上這個缺口，還移除了自家唯一的對講功能。這代表沒有官方產品會競爭，也沒有官方方案可以借。

2.6 現成 App 與開源專案

需要網路的（只能當 UX 參考）

不需網路、點對點的

確定有約十個以上，都是獨立開發者小品，沒有任何一個公布延遲數字；評分樣本極少。「有真實使用者長期驗證的離線 iOS 即時對講 App」：查不到。

判讀共同弱點：多數建在已棄用的 Multipeer；上限多在 8 台上下（剛好涵蓋 3–6 人）；變現靠廣告與訂閱。硬體端早已解決這個需求，例如 Sena 60S（Group Mesh 24 人）、Cardo PACKTALK（最多 31 人），但那是專用無線電晶片加專用耳機，不是手機加 AirPods。確定

開源

開源專案的授權於 2026‑11‑14 讀取。「以 Bonjour 當信令、不需伺服器的 iOS WebRTC 範例」沒找到成熟的。

失敗案例與教訓判讀

• Apple Walkie‑Talkie 2019 因漏洞一度停用（MacRumors）：按下就開麥的功能是高風險隱私面，誰能開我的麥克風要設計成最嚴格的配對與明確提示。
• Bridgefy 安全漏洞（USENIX 2022）：自己做 mesh 加密與協定最容易出事，需要相互驗證、限制訊息大小、防重放。
• FireChat 等單一公司維護的離線 App 停更後就跟著死（Wikipedia）。

架構Architecture

PoC 以原生 Swift／SwiftUI 實作：一個 Universal App（iPhone＋iPad），核心邏輯放在 iOS 與 macOS 共用的 Swift Package，並附一個 macOS 命令列對等端方便自動測試。

3.1 音訊管線

• 音訊工作階段：AVAudioSession 使用 .playAndRecord＋.voiceChat，以 AVAudioEngine 處理，16 kHz 單聲道、20 ms 一幀，並開啟語音處理（回音消除）。
• 編碼選 PCM16（不壓縮）：沒有編碼延遲、沒有第三方依賴、最容易除錯；一路約 256 kbps，2–3 人在近距離無線連線上沒有問題。人數多或頻寬吃緊再換 Opus（研究階段已確認可行，幀長 2.5–60 ms、語音 16–24 kbps 即可，並內建丟包補償與 FEC）。
• 收音路徑：實機上改用 AVAudioSinkNode，每個音訊 I/O 週期（約 10 ms）就拿到資料；即時音訊執行緒只把樣本複製進環狀緩衝，轉檔與切幀交給背景佇列。
• 抖動緩衝：目前是固定目標深度（預設 2 幀，即 40 ms），缺幀時以簡單的補幀（PLC）處理；尚未自適應。

3.2 傳輸抽象層

所有傳輸實作同一個介面（單一封包 ≤ 1200 bytes），上層的配對、加密、抖動緩衝與量測完全不知道底下是哪一種無線電。

另有記憶體內的 Loopback 實作，用來做握手、重連、重複連線與敵意輸入的單元測試。專案沒有使用已被標為棄用的 MultipeerConnectivity。

• 網狀：全連接（full mesh），由 PeerID 較小的一端主動連線；重複連線有確定的取捨規則；斷線以 0.5／1／2／4 秒退避重連；心跳 1 秒、逾時 5 秒；離開時送 BYE。
• 靜默期保溫：沒在送音訊時，每 100 ms 送一個很小的 PING（約 60 bytes），並把傳輸標記為語音服務等級。原因是點對點 Wi‑Fi 在安靜時會降低活動頻率，按住說話的第一句會等它醒來。

3.3 配對與加密（概要）

1. 同一房間的裝置輸入相同的 6 位數 PIN。
2. 由 PIN 以 HKDF 推導出金鑰，雙方互送 HMAC 做相互驗證；未完成握手的對象送來的封包一律丟棄。
3. 之後每個封包以 AES‑GCM 加密，帶方向性 nonce 與重放視窗。

3.4 從實機學到的事

模擬器階段看不到、上實機才暴露的問題（都已修正並補回歸測試）：

• 探索結果抖動殺連線：實機有多個網路介面，Bonjour 探索結果會因介面清單變動而出現 changed；舊程式把它當成「對方消失」，健康連線被判斷線、變成殭屍連線。現在連線生死只看傳輸層斷線與心跳逾時。
• 收音延遲：改用 AVAudioSinkNode 之前，開啟語音處理後系統每 100 ms 才交一次資料，每批第一幀要多等 80 ms。
• 按住說話的開口延遲：靜默期連線休眠造成每段開口第一秒的延遲尖峰，加上保溫後消除。
• 統計污染：時鐘偏移尚未估出時的幾幀被算進延遲，造成假的極端值；現在估出偏移前不計入。
• 看門狗：偶發「音訊引擎啟動成功但沒在跑」，現在 2 秒沒進度就重啟引擎。

前期幾輪量測因實作缺陷作廢、修正後重測；本頁只採用修正後的數字。

使用方式How it works for the user

1. 兩台（或以上）裝置各自開啟 App，設定相同的 6 位數房間 PIN；顯示名稱預設帶入機型，可自行修改。
2. 選擇連線方式（預設為點對點；支援的裝置可選 Wi‑Fi Aware，首次需配對一次），選擇說話模式：按住說話或常開。
3. 按「開始對講」。首次使用會詢問「本機網路」與「麥克風」權限，兩者都需要允許。
4. 房間畫面顯示連線狀態，成員卡顯示對方名稱、連線方式與往返時間；按住圓鈕說話，放開就停止，對方說話時會出現跳動的波形。
5. 「延遲量測」卡即時顯示 p50、p95，以及三項驗收門檻：p50 ≤ 200 ms、p95 ≤ 300 ms、斷線 = 0（暫定值）。

目前通話中不要手動鎖屏：鎖屏會讓通話中斷。房間畫面已關閉自動鎖定。

實測數字Measurements

怎麼讀：「斷線」欄為非預期斷線次數。total＝收音時間戳到播放時刻，單位毫秒（ms）。每格「A／B」是兩台各自量到的「對方 → 自己」方向。p50 的差異來自兩台各自的收音與播放計時器相位差，不是不穩定。實機的 total 是 App 內部延遲，不含喇叭與麥克風硬體（實機量到兩者合計約 3～9 ms）。

5.1 實機（真實裝置）

條件：用 Mac 遙控自動測試，每次 40～45 秒，程式模擬每 6 秒按住說話 4 秒；真實麥克風；兩台互相收音會回授，所以播放端靜音，但播放路徑照常執行並量測。「實機・真麥克風」指真實麥克風訊號（非合成音），按住說話由程式模擬。

最終版分段數據（實機・真麥克風AWDL 點對點，iPhone 14 Pro ↔ iPad Pro 11 吋）：

• 收音端：34～36 ms（20 ms 一幀＋約 10 ms 音訊週期＋處理時間，已是這個架構的下限）；
• 網路段：p50 3 ms、p95 10～11 ms；
• 抖動緩衝到播出：p50 37～39 ms；
• 引擎重啟 0 次，掉包 0～8 幀（0.5% 以下）；雙方麥克風峰值 −0.3／−8.8 dBFS，播放端都有真實聲音。

其他實機觀察：

• 實機・真麥克風iPad Pro ↔ iPad mini 連續 41 秒零斷線；雙方麥克風都真的收到聲音（峰值 −2～−16 dBFS）。（此項報告未標註連線方式。）
• 實機・合成音Wi‑Fi AwareiPhone 14 Pro ↔ iPad mini 連續 39 秒零斷線。
• 實機・合成音送出端與播放端的峰值都是 −6.0 dBFS，內容沒有失真。
• 連線剛建立的前 2～4 秒，網路段仍有約 250 ms 的暖機尖峰，之後穩定。

5.2 模擬器（同一台 Mac，不代表無線延遲）

條件：兩台模擬器（最多同時 2 台）在同一台 10 核心 Mac 上；網路段為本機迴路，sendToRecv 約 0.8 ms；播放為每 20 ms 一次的虛擬計時器；音源為合成音；RTT p50 約 1.3–2.0 ms。抖動緩衝目標預設 2 幀。除另有標註外，以下各列的掉包、PLC、underrun 皆為 0。

最後一列的 3 次 underrun：2 次發生在測試最後 1–2 秒（對方正在離開），1 次在 macOS 命令列端第 13 秒（單次，沒有 PLC）。模擬器上的 iPad 只證明同一套程式能在 iPad 版面下編譯、啟動、互通，不證明實機 iPad 的行為。

抖動緩衝目標對照（模擬器本機迴路，iPhone ↔ iPhone，常開 45 s，每列 A／B）

模擬器斷線恢復：對方被強制結束再重開，音訊停在第 21 秒；第 26.0 秒偵測逾時（設定值 5 秒）；重開後約第 27 秒已連上，握手 0.6–0.9 ms。聲音中斷共約 6 秒，其中 5 秒是逾時偵測。

5.3 尚未量測

真實無線延遲在 Wi‑Fi Aware 最終版上的重測、完全離線（飛航模式＋Wi‑Fi）情境、走遠與穿牆、鎖屏與背景、電量與發熱、AirPods、三台同時實機對講、6 人以上。

畫面Screens

已知問題Known issues

• 鎖屏會中斷通話（有實機證據）。實測中一台裝置在第 20 秒自動鎖屏：麥克風立刻變成數位靜音（20 秒內出現 114 幀全零），App 被系統暫停，對方 5 秒後心跳逾時。房間畫面已關閉自動鎖定，但手動按電源鍵仍會斷。背景與鎖屏保活要另外處理（例如 PushToTalk 框架或 CallKit）。
• 收音端延遲曾偏高（約 60 ms），已在降低。舊的收音方式每 100 ms 才交一次資料；改用 AVAudioSinkNode 後收音端降到 34～36 ms，這已接近此架構的下限（20 ms 一幀、約 10 ms 音訊週期、加處理時間）。
• Wi‑Fi Aware 的實機數字只有合成音，且是早上版本。最終版的 Wi‑Fi Aware 傳輸沒有重測；Wi‑Fi Aware 在真實麥克風、三台同時的情境下行為仍未驗證；其中一台 iPad 還沒和另外兩台做 Wi‑Fi Aware 配對。
• 完全離線（飛航模式＋Wi‑Fi）尚未量測。測試以區網遙控裝置，飛航模式會切斷遙控通道，需要人手實測。
• 三台同時實機對講沒測；連線剛建立的前 2～4 秒網路段有約 250 ms 的暖機尖峰。
• 實機上「手指按住圓鈕」這個動作無法遠端操作。實測驗證的是程式模擬按住說話之後的完整音訊通路；按鈕本身的送話中狀態只有模擬器截圖確認。
• 中途切換音訊路由（插耳機、連藍牙）沒有實機測過；已加兩道保護（設定變更通知時引擎真的停了才重啟、看門狗 2 秒沒進度就重啟），接 AirPods 實驗時要實測。
• 抖動緩衝是固定深度、沒有自適應。實機上 0–1 幀的設定幾乎一定會 underrun；補幀（PLC）是簡單作法，聽感沒評估過。
• 即時音訊回呼裡取鎖：混音器在即時音訊回呼中取鎖，實機上有優先權反轉造成雜音的風險（模擬器看不出來）。
• PIN 只有 6 位數字，正式上線前應改用 PAKE（見 3.3）。
• 沒有跨重開 App 的固定身分。App 重開會得到新的 PeerID，對方會先看到舊的逾時（約 5 秒）再看到新的。
• 「雙方同時建連」有一個罕見競態。壓力測試中 200 次有 1～3 次在 3 秒內沒連上（系統高負載時較容易出現）；對照舊版也出現同樣的失敗，判定不是近期改動造成。實機上只有 PeerID 較小的一端撥號，兩端同時撥號很少見。
• AirPods 的限制仍在。見「可行性研究」：使用 AirPods 麥克風就會落到 HFP，延遲預算 <150 ms 無法達成。

下一步Next

1. 防回授（優先）。半雙工、發言權、嘯叫偵測自動靜音；這是近距離喇叭外放時最直接的體驗問題。
2. 離線打字互傳。沿用同一條加密點對點連線，不另開通道，讓語音不方便時也能傳文字。
3. AirPods 實驗 E1。單一 iPhone，voiceChat＋語音處理，AirPods 麥克風錄到立即回放到同一副 AirPods（不經網路），用外部麥克風錄拍手聲量間隔，Pro 2、Pro 3、AirPods 4 各量一次。環路 ≤110 ms 整條才有機會 <150 ms；110–170 ms 需改目標；>170 ms 表示 AirPods 與 <150 ms 確定不相容。PoC 的真麥克風模式與 audioSession 診斷欄位可直接沿用。判讀
4. 補齊實機驗證。完全離線情境、Wi‑Fi Aware 最終版重測、三台同時對講、走遠與穿牆、中途切換音訊路由。
5. 鎖屏與背景保活。評估 PushToTalk 框架或 CallKit，並實測 audio 背景模式在鎖屏下的存活時間（研究中看到有回報約 50 秒被系統結束，未確認）。
6. 品質與安全。自適應抖動緩衝、PLC 品質、PAKE 配對、換成 Opus 編碼。
7. 其他研究階段規劃的實驗。E2：A2DP 下行與漂移；E3：Wi‑Fi Aware 單向延遲（1／3／10 m，30 分鐘）；E5：鎖屏存活 30 分鐘；E6：路由與聽感（Conversation Awareness、通透模式、側音）；E7（選配）：6 人壓力。

尚待決定

• <150 ms 的目標是否放寬？AirPods 現實區間 160–260 ms；對講是輪流說話，可能可接受約 200 ms，但沒有出處，需實驗與試用決定。目前實機驗收門檻暫定為 p50 ≤ 200 ms、p95 ≤ 300 ms、斷線 = 0。
• 「完全離線」是否為硬性需求？若是，PushToTalk 框架的核心價值用不上，鎖屏體驗要靠 audio 背景模式。
• 能否接受 16 kHz 單聲道的 HFP 音質？這是使用 AirPods 麥克風的代價。
• 是否需要 Android？Wi‑Fi Aware 與非 Apple 裝置互通的回報很弱，跨平台會大幅增加範圍。
• 安全與隱私要求到什麼程度？會影響配對與加密的工時。