你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

通话诊断更新日志架构

项目
02/25/2025

通话诊断更新日志架构与通话诊断日志架构之间属性的唯一区别是附加 CallUpdatesVersion 属性。 CallUpdatesVersion 属性指示日志的最新程度。通话诊断更新日志架构的延迟比通话诊断日志架构低，它通过尽快发送架构属性来实现这种低延迟。相比之下，在整个日志架构完成 Microsoft 内部创建之前，通话诊断日志架构不会向你发送日志架构。

通话诊断更新日志提供了有关终结点的重要信息和各个参与者的媒体传输信息。它们还提供有助于了解呼叫质量问题的度量值。

对于呼叫中的每个 EndpointId（包括服务器），Azure 通信服务会为终结点之间的每个媒体流（例如音频或视频）创建一个不同的通话诊断更新日志。在 P2P 呼叫中，每个日志都包含与各个出站流相关的数据，而各个出站流则与各个终结点关联。在群组呼叫中，participantId 用作密钥标识符，用于将相关出站日志加入到不同的参与者连接中。通话诊断更新日志将保持不变，无论参与者租户如何，这些日志都是相同的。

如何使用呼叫日志

建议在 Log Analytics 资源中收集所有可用的呼叫日志，以便监视呼叫使用情况和改进通话质量，并在我们发布新日志时从 Azure 通信服务接收这些日志。

可使用两个主要工具来监视通话并提高通话质量。

建议使用“语音和视频见解”仪表板来启动任何质量调查，并根据需要使用通话诊断，以在需要精细的详细信息时浏览单次呼叫。

数据概念

重要

若要分析日志，必须收集这些日志。若要了解详细信息，请参阅：如何存储日志？

除非启用这些特定的诊断设置，否则 Azure 不会存储呼叫日志数据。呼叫数据不可追溯。创建诊断设置后，将累积数据。

使用通话诊断更新日志架构时，请始终引用最高的 CallUpdatesVersion 编号，确保你拥有最新的信息。每当通话数据更新时，都会创建一个新版本的包含最新信息的日志。例如，CallUpdatesVersion 编号越高，更新越新。这意味着与版本 1 相比，版本 3 更新且包含更新的更改。

有关日志版本和数据延迟的详细信息

通话结束后，会将日志的初始版本（版本 1）发送到 CallSummaryUpdates 和 CallDiagnosticUpdates 表。初始版本可能包含 null 值，如果有更多信息可用，则会创建包含更完整信息的日志更新版本。例如，由于客户端计算机与我们的服务器之间存在网络连接问题，或者仅仅是因为用户在通话后关闭笔记本电脑（在客户端数据发送之前），几小时（或几天）后再重新打开它，客户端数据可能会延迟。

由于存在这种收集差异，你可能会看到增量版本再数小时甚至数天后才到达。与等待所有调用 SDK 客户端数据被接收相比，可以使用版本来更快地了解你的通话资源。最佳情况是，所有通话参与者都结束通话，并且呼叫 SDK 能够将数据发送到服务器。

数据定义

通话诊断更新日志架构

下表介绍了每个属性。

properties	说明
`operationName`	与日志记录相关联的操作。
`operationVersion`	如果通过 API 执行 `operationName` 操作，则 `api-version` 值与该操作关联。如果没有任何 API 对应于此操作，则此版本表示操作的版本，以防与该操作关联的属性将来发生更改。
`category`	事件的日志类别。此属性是可以在资源上启用或禁用日志的粒度。出现在事件的 `properties` blob 中的属性与日志类别和资源类型中的属性相同。
`correlationId`	呼叫的唯一 ID。它可从单个呼叫期间连接的所有参与者和终结点中标识相关事件。如果需要通过 Microsoft 打开支持案例，则可以使用 `correlationId` 值轻松标识你要排查故障的呼叫。
`participantId`	生成此 ID 是用于表示 `"Participant"` 终结点 (`endpointType` = `"Server"`) 与服务器之间的双向连接。当 `callType` = `"P2P"` 时，两个终结点之间为直接连接，不会生成 `participantId` 值。
`identifier`	用户的唯一 ID。该标识可以是 Azure 通信服务用户、Microsoft Entra 用户 ID、Teams 对象 ID 或 Teams 机器人 ID。你可使用此 ID 来关联不同日志中的用户事件。
`endpointId`	表示连接到呼叫的各个终结点的唯一 ID，其中 `endpointType` 定义终结点类型。当该值为 `null` 时，连接的实体是通信服务服务器。对于本机客户端，可在跨多个呼叫 (`correlationId`) 中为同一用户保留 `EndpointId`，但当客户端是 Web 浏览器时，该属性值对于每个呼叫都是唯一的。
`endpointType`	该值用于描述各个 `endpointId` 实例的属性。可以包含 `"Server"`、`"VOIP"`、`"PSTN"`、`"BOT"`、`"Voicemail"`、`"Anonymous"` 或 `"Unknown"`。
`mediaType`	此字符串值用于描述在各个流内多个终结点之间传输的媒体类型。可能的值包括 `"Audio"`、`"Video"`、`"VBSS"`（屏幕共享）和 `"AppSharing"`（数据信道）。
`streamId`	非唯一的整数，与 `mediaType` 一起使用，可用于对同一 `participantId` 值的多个流进行唯一标识。
`transportType`	字符串值，用于描述各个 `participantId` 值的网络传输协议。可以包含 `"UDP"`、`"TCP"` 或 `"Unrecognized"`。 `"Unrecognized"` 指示系统无法确定传输协议是 TCP 还是 UDP。
`roundTripTimeAvg`	表示在 `participantDuration` 期间中获取从一个终结点到另一个终结点的 IP 数据包所花费的平均时间。这种网络传播延迟与两点之间的物理距离、光速以及在此过程中不同路由器花费的任何其他时间有关。延迟以单向时间或往返时间 (RTT) 进行度量。其值以毫秒为单位。 RTT 大于 500 毫秒会对呼叫质量产生负面影响。
`roundTripTimeMax`	在群组呼叫的 `participantDuration` 期间或 P2P 呼叫的 `callDuration` 期间度量的到达媒体流的最大 RTT（以毫秒为单位）。
`jitterAvg`	连续数据包之间的延迟的平均变化。通过缓冲，Azure 通信服务可以适应某些级别的抖动。当抖动超过缓冲时（大约在 `jitterAvg` 时间大于 30 毫秒）时，它可能会对质量产生负面影响。以不同速度传入的数据包会导致说话者的声音听起来像机器人。该指标在群组呼叫中的 `participantDuration` 期间或 P2P 呼叫中的 `callDuration` 期间内针对每个媒体流进行度量。
`jitterMax`	在各个媒体流的数据包之间测得的最大抖动值。网络突发情况可能会导致音频/视频通信流出现问题。
`packetLossRateAvg`	丢失的数据包的平均百分比。数据包丢失会对音频质量产生直接影响。小型、单独的数据包丢失几乎不会产生任何影响，而连续的突发丢失则会导致音频完全中断。被丢弃且未到达预期目的地的数据包会导致媒体出现间隙。这种情况会导致丢失音节和单词，以及视频和共享断断续续。如果数据包丢失率超过 10% (0.1)，可能会对质量产生负面影响。该指标在群组呼叫中的 `participantDuration` 期间或 P2P 呼叫中的 `callDuration` 期间内针对每个媒体流进行度量。
`packetLossRateMax`	该值表示在群呼中的 `participantDuration` 期间或 P2P 呼叫中的 `callDuration` 期间每个媒体流的最大丢包率（百分比）。网络突发情况可能会导致音频/视频通信流出现问题。
`JitterBufferSizeAvg`	每个媒体流持续时间内抖动缓冲区的平均大小。抖动缓冲区是一个共享数据区域，可以在其中收集、存储语音数据包并以均匀的间隔发送到语音处理器。抖动缓冲器用于抵消抖动的影响。抖动缓冲区可以是静态的，也可以是动态的。静态抖动缓冲区设置为固定大小，而动态抖动缓冲区则可以根据网络状况调整大小。抖动缓冲区的目标是向用户提供顺畅且不间断的音频和视频数据流。在 Web SDK 中，这个 `JitterBufferSizeAvg` 是呼叫期间 `jitterBufferDelay` 的平均值。 `jitterBufferDelay` 是保留在抖动缓冲区中的音频示例或视频帧的持续时间。通常，当 `JitterBufferSizeAvg` 值大于 200 毫秒时，它会对质量产生负面影响。
`JitterBufferSizeMax`	在每个媒体流持续时间内测得的最大抖动缓冲区大小。通常，当此值大于 200 毫秒时，它会对质量产生负面影响。
`HealedDataRatioAvg`	在音频流持续时间内，修复程序成功重建或恢复的丢包或坏包的平均百分比。修复数据率是衡量 VoIP 系统中使用的纠错技术有效性的指标。如果该值大于 0.1 (10%)，则认为流质量较差。
`HealedDataRatioMax`	在每个媒体流持续时间内测得的最大修复数据比率。如果该值大于 0.1 (10%)，则认为流质量较差。
`VideoFrameRateAvg`	视频/屏幕共享呼叫期间每秒传输的平均视频帧数。视频帧速率会影响视频流的质量和平滑度，较高的帧速率通常会使运动更平顺、更流畅。 WebRTC 视频的标准帧速率通常为每秒 30 帧 (fps)，尽管帧速率可能会因具体实施和网络条件而异。如果该值小于 7（对于视频流）或小于 1（对于屏幕共享流），则认为流质量很差。
`RecvResolutionHeight`	在视频/屏幕共享呼叫期间传输的传入视频流的平均垂直尺寸。它以像素为单位进行测量，是决定视频流整体分辨率和质量的因素之一。使用的具体分辨率可能取决于呼叫中涉及的设备的功能和网络条件。如果该值小于 240（对于视频流）或小于 768（对于屏幕共享流），则认为流质量很差。
`RecvFreezeDurationPerMinuteInMs`	传入视频/屏幕共享流的平均冻结持续时间（以每分钟毫秒数为单位）。冻结通常是由于网络状况不佳造成的，并且会降低流质量。如果该值大于 6,000 毫秒（对于视频流）或大于 25,000 毫秒（对于屏幕共享流），则认为流质量很差。
`PacketUtilization`	为给定媒体流发送或接收的数据包。通常通话时间越长，该值就会越高。如果此值为零，则可能指示媒体未处于流动状态。
`VideoBitRateAvg`	视频或屏幕共享流的平均比特率（每秒位数）。低比特率值可能指示存在网络不佳问题。可在此处找到所需的最小比特率（带宽）：网络带宽。
`VideoBitRateMax`	视频或屏幕共享流的最大比特率（每秒位数）。低比特率值可能指示存在网络不佳问题。可在此处找到所需的最小比特率（带宽）：网络带宽。
`StreamDirection`	媒体流的方向。它可以是入站，也可以是出站。
`CodecName`	用于处理媒体流的编解码器名称。它可以是 OPUS、G722、H264S、SATIN 等。
`CallUpdatesVersion`	表示日志版本，版本号较高表示最近发布的版本。

各种呼叫类型的示例数据

注意

在本文中，P2P 和群组通话默认都位于同一租户内。整篇文章中相应地说明了跨租户的所有呼叫方案。

P2P 呼叫

以下是 P2P 呼叫中所有日志的共享字段：

"time":                     "2021-07-19T18:46:50.188Z",
"resourceId":               "SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/ACS-TEST-RG/PROVIDERS/MICROSOFT.COMMUNICATION/COMMUNICATIONSERVICES/ACS-PROD-CCTS-TESTS",
"correlationId":            "aaaa0000-bb11-2222-33cc-444444dddddd",

通话诊断更新日志

通话诊断更新日志共享操作信息：

"operationName":            "CallDiagnostics",
"operationVersion":         "1.0",
"category":                 "CallDiagnostics",

下面是从 VoIP 终结点 1 到 VoIP 终结点 2 的音频流诊断更新日志：

"properties": {
    "identifier":           "acs:61fddbe3-0003-4066-97bc-6aaf143bbb84_0000000b-4fee-66cf-ac00-343a0d003158",
    "participantId":        "null",
    "endpointId":           "570ea078-74e9-4430-9c67-464ba1fa5859",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "1000",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "82",
    "roundTripTimeMax":     "88",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

下面是从 VoIP 终结点 2 到 VoIP 终结点 1 的音频流诊断更新日志：

"properties": {
    "identifier":           "acs:7af14122-9ac7-4b81-80a8-4bf3582b42d0_06f9276d-8efe-4bdd-8c22-ebc5434903f0",
    "participantId":        "null",
    "endpointId":           "a5bd82f9-ac38-4f4a-a0fa-bb3467cdcc64",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "1363841599",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "78",
    "roundTripTimeMax":     "84",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

下面是从 VoIP 终结点 1 到 VoIP 终结点 2 的视频流诊断更新日志：

"properties": {
    "identifier":           "acs:61fddbe3-0003-4066-97bc-6aaf143bbb84_0000000b-4fee-66cf-ac00-343a0d003158",
    "participantId":        "null",
    "endpointId":           "570ea078-74e9-4430-9c67-464ba1fa5859",
    "endpointType":         "VoIP",
    "mediaType":            "Video",
    "streamId":             "2804",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "103",
    "roundTripTimeMax":     "143",
    "jitterAvg":            "0",
    "jitterMax":            "4",
    "packetLossRateAvg":    "3.146336E-05",
    "packetLossRateMax":    "0.001769911"
    "callupdatesversion":   "2"
}

组呼叫

群组通话的数据在 3 个通话摘要日志和 6 个通话诊断更新日志中生成。以下是呼叫中所有日志的共享字段：

"time":                     "2021-07-05T06:30:06.402Z",
"resourceId":               "SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/ACS-TEST-RG/PROVIDERS/MICROSOFT.COMMUNICATION/COMMUNICATIONSERVICES/ACS-PROD-CCTS-TESTS",
"correlationId":            "bbbb1111-cc22-3333-44dd-555555eeeeee",

通话诊断更新日志

通话诊断更新日志共享操作信息：

"operationName":            "CallDiagnostics",
"operationVersion":         "1.0",
"category":                 "CallDiagnostics",

下面是从 VoIP 终结点 1 到服务器终结点的音频流的诊断更新日志：

"properties": {
    "identifier":           "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-729f-ac00-343a0d00d975",
    "participantId":        "04cc26f5-a86d-481c-b9f9-7a40be4d6fba",
    "endpointId":           "5ebd55df-ffff-ffff-89e6-4f3f0453b1a6",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "14884",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "46",
    "roundTripTimeMax":     "48",
    "jitterAvg":            "0",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

下面是从服务器终结点到 VoIP 终结点 1 的音频流的诊断更新日志：

"properties": {
    "identifier":           null,
    "participantId":        "04cc26f5-a86d-481c-b9f9-7a40be4d6fba",
    "endpointId":           null,
    "endpointType":         "Server",
    "mediaType":            "Audio",
    "streamId":             "2001",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "42",
    "roundTripTimeMax":     "44",
    "jitterAvg":            "1",
    "jitterMax":            "1",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

下面是从 VoIP 终结点 3 到服务器终结点的音频流的诊断更新日志：

"properties": {
    "identifier":           "acs:1797dbb3-f982-47b0-b98e-6a76084454f1_0000000b-1531-57c6-ac00-343a0d00d972",
    "participantId":        "1a9cb3d1-7898-4063-b3d2-26c1630ecf03",
    "endpointId":           "5ebd55df-ffff-ffff-ab89-19ff584890b7",
    "endpointType":         "VoIP",
    "mediaType":            "Audio",
    "streamId":             "13783",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "45",
    "roundTripTimeMax":     "46",
    "jitterAvg":            "1",
    "jitterMax":            "2",
    "packetLossRateAvg":    "0",
    "packetLossRateMax":    "0"
    "callupdatesversion":   "2"
}

下面是从服务器终结点到 VoIP 终结点 3 的音频流的诊断更新日志：

"properties": {
    "identifier":           "null",
    "participantId":        "1a9cb3d1-7898-4063-b3d2-26c1630ecf03",
    "endpointId":           null,
    "endpointType":         "Server"    
    "mediaType":            "Audio",
    "streamId":             "1000",
    "transportType":        "UDP",
    "roundTripTimeAvg":     "45",
    "roundTripTimeMax":     "46",
    "jitterAvg":            "1",
    "jitterMax":            "4",
    "packetLossRateAvg":    "0",
    "callupdatesversion":   "2"
}

常见问题解答

如何存储日志？

以下部分将对这一要求进行说明。

默认情况下，Azure 通信服务日志不会存储在 Azure 帐户中，因此你需要开始存储这些日志，以便“语音和视频见解”仪表板和通话诊断等工具正常工作。要收集这些呼叫日志，需要启用将呼叫数据定向到 Log Analytics 工作区的诊断设置。

数据不会进行追溯性存储，因此仅在配置诊断设置后开始捕获呼叫日志。

按照在 Azure Monitor 中通过诊断设置启用日志为资源添加诊断设置。建议最初收集所有日志。了解 Azure Monitor 中的功能后，确定要保留哪些日志以及要保留多长时间。添加诊断设置时，系统会提示你选择日志。若要收集所有日志，请选择“allLogs”。

Azure Monitor 的 Log Analytics 中的数据量、保留期和使用情况通过现有的 Azure 数据计量计费。出于成本考虑，建议根据需要监视数据使用情况和保留策略。有关详细信息，请参阅控制成本。

如果你有多个 Azure 通信服务资源 ID，则必须为每个资源 ID 启用这些设置。

后续步骤

查看所有语音和视频日志的概述，请参阅：Azure 通信服务呼叫日志概述
了解管理呼叫质量和可靠性的最佳做法，请参阅：改善和管理呼叫质量
了解用于监控语音呼叫和视频呼叫日志的见解仪表板。
了解如何使用呼叫日志通过呼叫诊断来诊断呼叫质量和可靠性问题，请参阅：呼叫诊断

通过

通话诊断更新日志架构

如何使用呼叫日志

数据概念

有关日志版本和数据延迟的详细信息

数据定义

通话诊断更新日志架构

各种呼叫类型的示例数据

P2P 呼叫

通话诊断更新日志

组呼叫

通话诊断更新日志

常见问题解答

如何存储日志？

后续步骤

反馈

其他资源