Unhealthy 是 Meta 在运营商合作中使用的通话质量指标，对应讲稿中的 %BAD Calls：一通电话被评为最差档的比例。它出现在 Meta 网络团队的 VAMOS 项目里，用来比较不同国家、运营商和网络改造前后的通话体验。下文依次给出它的出处与用途、定义与四档分级、在分层指标体系中的位置、各国案例的公开数值、客户端的测量字段、P2P 与中继的机制，以及站在网络角度如何干预这一指标。
每一通 WhatsApp 通话按体验分为 BAD、Fair、Good、GREAT 四档。%BAD Calls 是 BAD 档通话占全部通话的百分比，在讲稿中与 Unhealthy Calls 并列为同一指标的两种写法。讲稿将它列为质量类关键指标，与代表效率的 %P2P Success 并列。
这一指标见于 Meta 网络基础设施团队在 MENOG 25 上的演讲《Improving QoE for Real Time Calling》（2025 年 11 月 27 日），讲者为 Bhartendu Chaurasia，Meta 伦敦 Network Ecosystem Engineering – EMEA 负责人。讲稿共 28 页，主题是 Meta 与运营商合作改善 OTT 实时通话体验的 VAMOS 项目。
VAMOS 的工作方式是与各国运营商做工程层面的联合调整，再用同一套指标验收效果。讲稿的世界地图列出了 Bell、AT&T、Telefónica、TIM、Claro、Orange、Vodafone、Jio、Airtel、Safaricom、Globe 等运营商标识，对应不同地区的合作项目。%BAD 与 %P2P Success 是讲稿第 14 页给出的两个关键指标，分别对应质量与效率。
在其他公开渠道中，这一称呼出现较少。Meta 工程博客、GSMA 与其他 NOG 会议的公开材料、学术论文和 WhatsApp 通话专利中，均以时延、丢包、码率、冻结、卡顿等下层量讨论通话质量，未使用 %BAD / Unhealthy 这一分档口径。WhatsApp 的核心通话专利（US10129412B1 / EP2993861B1，2014 年优先权）内容集中于路径建立与 P2P / 中继切换，同样未涉及质量分档。
来源：MENOG 25 讲稿 archive.menog.org · 议程页 pretalx.ripe.net · 专利 EP2993861B1 patentimages.storage.googleapis.com
讲稿第 11 页 “Characterizing calling quality” 将通话分为四档。BAD 与 GREAT 附有简短注释，Fair 与 Good 未作说明，四档均未给出数值门槛。
同一页给出两个改进方向：Area 1 面向 BAD 一端，表述为解决差体验的底层原因、减少 %Unhealthy calls；Area 2 面向 GREAT 一端，目标是提高高清通话的可用性与时长占比。
| 关键指标 | 讲稿分类 | 含义 |
|---|---|---|
| % BAD Calls / Unhealthy Calls | Quality | BAD 档通话占比。讲稿关键指标页的数值以 X% 占位，未给出全球值 |
| % P2P Success | Efficiency | 成功建立直连、未经中继转发的通话占比，讲稿以 Y% 占位 |
讲稿第 13 页以四层结构描述应用质量，自下而上为网络条件、网络 KPI、服务层指标和体验层。%BAD 位于体验层，被归为复合指标。
按这一划分，MOS 属于感知指标的例子，LMQR 属于情境指标的例子，%BAD 属于复合指标，三者在体验层并列。讲稿未给出 LMQR 的全称与定义，也未说明 %BAD 与 MOS 之间的换算关系。行业中常见的 MOS 经验阈值属于通用评测口径，与讲稿的分类是两套体系。
讲稿的数值主要集中在案例页。以下为图面所载数据。
口径：On-Net Cellular · 蓝 = 语音，红 = 视频 · 单位 %
同页卡塔尔两家运营商的图面数值为 70.11 / 95.76 与 70.77 / 72.47（语音 / 视频），明显高于同页其他国家，讲稿未对这一差异作说明。该页纵轴标注为 “P2P Success Rate”，横轴为 “% Bad / ASN”。图中另有 5 组柱子未标注国家。
2024 年 2 月 18 日 – 3 月 4 日 · 左 = 调整前，右 = 调整后
video_rx_bitrate_p50（kbps）· 干预依次为 QCI 设置更新、CGNAT 改全锥型、CGNAT 二次更新与 RAN 优化
MTN 集团于 2025 年 4 月 14–15 日宣布与 Meta 在 12 个市场开展合作，尼日利亚为首个落地市场，合作自 MWC 2024 起推进。声明原文提到尼日利亚早期结果中关键绩效指标有显著改善，包括 50% 的改善，未指明该数字对应的具体指标名称。
讲稿中尼日利亚案例的数据期为 2025 年 9 月，与上述 4 月声明分属不同时段。其他运营商方面，Airtel 与 Meta 2022 年 12 月的合作内容为海底光缆 2Africa Pearls 与 WhatsApp 商业集成，与通话质量指标无关。
讲稿的 TECH PRIMER 部分介绍了客户端结构，逆向社区对协议与遥测的整理提供了字段层面的补充。两者共同呈现的是客户端产生的原始量，分档本身的计算规则不在其中。
WACRG 是逆向工程社区整理的 WhatsApp 通话协议规范。与测量相关的字段如下：
| 机制 | 内容 |
|---|---|
| RTCP Sender Report（PT 200） | 28 字节，含 sender SSRC、NTP 与 RTP 时间戳、发包计数与发送字节计数，接收报告块数量为 0 |
| PT 208 / PT 209 | 分别为 12 字节与 8 字节，仅含本地与远端 SSRC，用于流的对应与通话开始前的标识 |
<relaylatency> | 客户端上报到各 relay 的实测往返时延；<te> 中 latency 编码为 0x02000000 + rtt_ms 的十进制字符串，如 RTT 45ms 编码为 “33554477” |
<te2> | relay 候选列表，属性含 relay_id、relay_name、is_fna 与可选的 c2r_rtt |
<terminate> | 可携带 duration（总时长，秒）与 audio_duration（音频时长，秒），两字段均为可选 |
来源：WACRG 规范 wacrg.org
WAM（WhatsApp Analytics Module）是客户端的统计回传通道，数据以 w:stats 命名空间的 base64 二进制发送。逆向工具 ZWAM 公开的 protobuf 结构显示，通话事件 WamCall 为 WamEvent 的第 3 号字段，包含 500 多个字段，涉及编解码表现、带宽估计与质量相关量。已公开转录的示例字段如下：
| Tag | 字段 | 含义 |
|---|---|---|
| 1 | call_side | 主叫 / 被叫 |
| 63 | call_result | 连接结果 |
| 92 | call_t | 总通话时长（毫秒） |
| 112 | call_tx_avg_bitrate | 上行平均码率（bps） |
| 120 | call_rx_avg_bitrate | 下行平均码率（bps） |
| 163 | video_enabled | 是否为视频通话 |
| 195 | video_width | 视频宽度 |
公开转录仅包含上述示例字段，完整字段清单未见公开。开源实现 whatsmeow 覆盖的是信令层事件（CallOffer、CallAccept、CallRelayLatency、CallTerminate 等），不包含通话质量统计与 WamCall 的实现。
来源：DeepWiki 对 ZWAM 的整理 deepwiki.com/clarithromycine/zwam
在讲稿框架中，%P2P Success 与 %BAD 是并列的两个关键指标，前者归于效率，后者归于质量。讲稿按国家与运营商并排呈现两组数据，未给出两者的相关性数值，各案例页呈现的量也不相同：肯尼亚页以 %BAD 为主，尼日利亚页以 P2P 为主，印尼页为码率，菲律宾页为码率与 %BAD。
路径选择本身以实测质量为依据。按讲稿的切换规则，通话中持续监测各条可用路径，当其他路径在 RTT 与丢包上带来实质改善时即可切换，包括由 P2P 切至 relay 的情形。
@Scale 的国际通话工作提供了中继路径的量化结果。国际通话约占 Meta 通话量的五分之一。原有架构中一通跨国通话只经一个中继点，RTCP 反馈需走完整条跨国链路。cross-relay 架构改为两端各连接就近的 relay，relay 之间经 Meta 骨干网相连，并引入逐跳反馈、relay 缓存数据包以支持快速重传、以及由 relay 代发丢包重传请求。文中举例，当一端到其 relay 的时延占端到端时延的 20% 时，重传时间可减少 80%。文中给出的结果为：
该文未使用 %BAD 口径，其冻结与卡顿数据与 %BAD 之间没有公开的对应关系。
%BAD 是位于体验层的顶层复合指标，不能直接干预，只能动它下面的层。它统计的是最差档通话占全部通话的比例，是一个尾部指标：平均体验的改善不必然带来 %BAD 的下降，优化的目标是找到最差的那批通话、把尾巴削掉。
讲稿第 13 页的分层图给出了自下而上的影响链条，下层量的变化逐层传导到顶层：
案例中与 %BAD 一起观察的量包括：通话 RTT 的 p50 / p90、视频接收码率 p50、中继反馈 RTT、视频冻结率、音频卡顿率。这些量同向变化时，%BAD 随之变化。
站在网络角度，终端不存在独立的干预手段。终端的码率自适应只是跟随网络：网络给多少吞吐、丢多少包，终端就落在哪一档。因此「视频码率推上去」在网络侧的含义，就是承载能力、丢包和抖动被改好；视频接收码率 p50 是网络质量在应用层最直观的读数。
网络侧的改善把可承载的视频码率推上去，%BAD 随之显著下降，两个案例同时给出了码率与 %BAD 两组数：
| 案例 | 视频接收码率 p50 | 其他同页指标 | 视频 %BAD |
|---|---|---|---|
| 肯尼亚 | 约 160K → 255K | 通话 RTT p50 约 165 → 98 毫秒 | 约 44% → 30% |
| 菲律宾 | 约 210K → 225–232K | — | 约 24% → 20.5% |
两例方向一致，码率升幅较大的肯尼亚，%BAD 的降幅也较大。印尼案例呈现的是链条的前半段：QCI 调整、两次 CGNAT 更新、RAN 优化依次实施，视频接收码率约 75 → 200 kbps；该案例讲稿只给了码率，没有 %BAD。
%BAD 中还包括接通受阻与可靠性问题，这部分与码率无关，需要从网络可达性与路径层面处理。
%BAD 的公式与分数线未公开，无法按公式反推参数，只能经验式优化：按运营商、地区、接入类型切分数据，先定位尾部集中在哪一段网络；一次只动一个因素，例如只改 CGNAT 或只调整 QCI；再看 %BAD 与服务层指标是否同向移动来验收。讲稿中的全部案例都采用这一打法。