对于任何通过 **SIP Trunk** 在印度开展语音业务的企业而言，通话记录(CDR)和通话质量数据都是运营中最核心的“传感器”。它们不仅用于计费对账和故障排查，更是判断线路健康度、评估供应商 SLA 的直接依据。然而，印度的电信监管环境特殊——**TRAI 要求涉及印度 PSTN 的所有通话，SIP 信令和 RTP 媒体必须锚定在印度境内服务器**。这意味着，面向印度市场的 **SIP 中继** 在获取 CDR 和通话质量数据时，有其独特的合规要求和技术路径。
本文面向正在集成印度 **SIP Trunk** 的开发者，系统梳理如何通过 API 获取 CDR 和通话质量洞察。
在使用 **SIP Trunking** 承载大规模外呼或呼入业务时，运营团队需要回答三类问题：
**计费与对账**：每次通话的时长、费率、费用是否与账单一致?是否存在运营商侧计费异常?
**故障排查**：为什么这通电话失败了?是网络问题、运营商拦截，还是媒体锚定违规?
**质量监控**：通话的 MOS 评分、抖动、丢包率是否在可接受范围内?哪条线路的质量在下降?
这些问题，单靠 Dashboard 手动查看是无法规模化解决的。必须通过 **CDR API** 将通话数据拉取到自己的系统中，进行自动化分析和告警。
主流 SIP 中继服务商(如 Plivo、Exotel、Vobiz)均提供 RESTful 风格的 CDR 查询接口。以 Plivo 的 Zentrunk Calls API 为例，其返回的 Call 对象包含以下关键字段：
| 字段 | 类型 | 说明 |
|---|---|---|
| call_uuid | String | 通话唯一标识，后续查询录音、质量数据的索引 |
| from_number / to_number | String | 主叫/被叫号码，印度通话中需注意回退 caller ID 的情况 |
| call_direction | String | inbound 或 outbound |
| call_duration | Integer | 实际通话时长（秒） |
| bill_duration / billed_duration | Integer | 计费时长，注意计费间隔可能不同 |
| hangup_cause_name / hangup_cause_code | String / Integer | 挂断原因及数字代码，是排查失败通话的关键 |
| total_rate / total_amount | String | 每分钟费率与总费用 |
| initiation_time / answer_time / end_time | String | 呼叫发起、应答、结束的 UTC 时间戳 |
**印度的特殊注意点**：Plivo 文档明确指出，对于通过自动运营商故障转移重试的印度国内通话，`from_number` 字段记录的是重试时使用的**回退 caller ID**，而非原始发送的号码。这意味着，在印度做 CDR 分析时，不能简单地用 `from_number` 作为“原始主叫”的唯一标识，需要结合 `call_uuid` 和重试逻辑来追踪完整的呼叫链路。
CDR API 通常也提供通话质量指标。Plivo 的 Calls API 描述中明确提到 “retrieve call detail records (CDRs) **and quality insights** for calls made through your SIP trunks”。
在通话质量监控中，最核心的指标包括：
**MOS(平均意见得分)** ：1.0–5.0 的评分，综合反映感知通话质量。4.0 以上为良好，3.5–4.0 为可接受，低于 3.5 用户会明显察觉音质问题。
**抖动(Jitter)** ：语音包到达时间的变化。Exotel 的 QoS 文档建议抖动应 ≤ 20ms 为优秀，≤ 40ms 为可接受，超出则出现“choppy, robotic audio”。
**丢包率(Packet Loss)** ：TRAI 对印度语音线路的基准要求是丢包不超过 0.1%。
Vobiz 的 Voice Call Logs 页面将这些质量数据可视化呈现：每通电话的 MOS 评分、包丢失、抖动、编解码器信息，以及按 leg(呼入/呼出)拆分的 MOS 分解。开发者可以通过 CDR API 以编程方式拉取相同数据。
在印度运营 **SIP中继**，CDR 数据的一个隐含前提是**通话本身必须是合规的**。根据 TRAI 的媒体锚定要求，如果通话的 SIP 信令或 RTP 媒体未落在印度境内，呼叫会以 `violates_media_anchoring` 挂断原因直接失败。
这意味着，在排查印度通话失败时，**`hangup_cause` 中的 `violates_media_anchoring` 是一个必须优先检查的信号**。它指向的不是线路质量问题，而是架构层面的合规问题——你的 **SIP Trunk** 的媒体终止点不在印度境内。
因此，面向印度的 CDR 分析，第一层过滤应该是：**是否有大量通话因媒体锚定违规而失败?** 如果是，需要先解决架构合规问题，再谈质量优化。
| 服务商 | CDR 获取方式 | 数据保留 | 质量指标 | 印度合规特性 |
|---|---|---|---|---|
| Plivo | REST API，GET /Zentrunk/Call/{call_uuid} | 未明确 | 支持 STIR/SHAKEN 状态、SRTP 加密状态 | 要求平台在印度终止 SIP 和媒体 |
| Exotel | GET /v1/Accounts/{sid}/Calls.json | CDR 保留 18 个月 | 通过 Voice v3 API 获取录音和日志 | UL VNO 牌照，vSIP 专为印度 PSTN 设计 |
| Vobiz | CDR API，支持 Node.js/Java SDK | 未明确 | MOS 按 leg 分解、包丢失、抖动、编解码器 | 支持 140/160 号段合规分配，专注印度 AI 语音场景 |
集成建议：从 CDR 到自动化质量监控
对于正在集成印度 **SIP Trunking** 的开发团队，建议按以下步骤构建 CDR 驱动的质量监控体系：
**第一步：拉取 CDR 到自有系统**。通过服务商的 CDR API，定期(如每 5 分钟)拉取增量通话记录，存入时序数据库或数据仓库。
**第二步：建立挂断原因告警**。重点关注 `hangup_cause_code` 的分布变化。如果 `violates_media_anchoring` 突然增多，说明合规架构可能出现了问题。
**第三步：监控 MOS 趋势**。按线路、按目的地、按时间段聚合 MOS 评分。MOS 持续下降通常意味着网络路径出现了拥塞或路由变化。
**第四步：结合抖动和丢包定位根因**。MOS 下降时，检查同一时间窗口的抖动和丢包数据——抖动高通常指向网络拥塞，丢包高可能指向运营商侧问题。
**第五步：用 CDR 数据验证 SLA**。将 CDR 中的 `answer_time` 和 `call_duration` 与服务商承诺的接通率和通话时长进行对比，作为续约谈判的数据依据。
通话记录 API 是 **SIP Trunk** 运营的“黑匣子”。在印度这样监管严格、网络环境复杂的市场，拥有对 CDR 和通话质量数据的编程访问能力，意味着你可以比竞争对手更快地发现合规风险、定位质量劣化、优化线路成本。对于构建面向印度市场的 AI 语音代理或呼叫中心平台，这不仅是技术需求，更是运营能力的核心组成部分。
