Поделиться через

Вызов диагностика обновляет схему журнала

  • Статья

Единственное различие в свойствах между схемой журнала вызова диагностика обновления и схемой журнала вызова диагностика является дополнительным CallUpdatesVersion свойством. Свойство CallUpdatesVersion указывает, как последнее значение журнала. Вызов диагностика обновляет схему журнала с меньшей задержкой, чем схема журнала вызова диагностика, она достигает этой низкой задержки путем отправки свойств схемы сразу после их отправки. В отличие от этого, схема журнала вызова диагностика не отправляет схему журнала, пока не завершится создание всей схемы журнала.

Журналы обновления вызовов диагностика предоставляют важные сведения о конечных точках и передаче мультимедиа для каждого участника. Они также предоставляют измерения, которые помогают понять проблемы качества.

Для каждого EndpointId вызова (включая сервер), Службы коммуникации Azure создает отдельный вызов диагностика журнал обновлений для каждого потока мультимедиа (аудио или видео, например) между конечными точками. В вызове P2P каждый журнал содержит данные, относящиеся к каждому из исходящих потоков, связанных с каждой конечной точкой. В групповых вызовах participantId служит идентификатором ключа для присоединения связанных исходящих журналов к отдельному подключению участника. Вызов диагностика журналы обновлений остаются неизменными и одинаковы независимо от клиента участника.

Использование журналов вызовов

Мы рекомендуем собирать все доступные журналы вызовов в ресурсе log analytics, чтобы отслеживать использование звонков и улучшать качество звонков и получать новые журналы из Службы коммуникации Azure по мере их выпуска.

Существует два основных инструмента, которые можно использовать для мониторинга звонков и улучшения качества звонков.

Мы рекомендуем использовать панели мониторинга мониторинга голосовой и видеоанализатора для запуска любых исследований качества и использования вызовов диагностика по мере необходимости для изучения отдельных вызовов при необходимости детализации.

Основные понятия данных

Внимание

Если вы хотите проанализировать их, необходимо собрать журналы. Дополнительные сведения см. в статье Разделы справки журналы хранения?

Azure не хранит данные журнала вызовов, если вы не включите эти параметры диагностики. Данные вызова не доступны ретроактивно. После создания параметров диагностики накапливаются данные.

При использовании схемы журнала обновлений диагностики вызовов всегда обратитесь к самому CallUpdatesVersion высокому номеру, чтобы убедиться, что у вас есть самые актуальные сведения. При обновлении данных вызова создается новая версия журнала, содержащая самые актуальные сведения. Например, чем выше CallUpdatesVersion число, тем более последнее обновление. Это означает, что версия 3 является более новой и включает более последние изменения по сравнению с версией 1.

Дополнительные сведения о версиях журналов и задержке данных

После завершения вызова исходная версия журнала (версия 1) отправляется в таблицы CallSummaryUpdates и CallDiagnosticUpdates. Начальные версии могут содержать null значения, если дополнительные сведения становятся доступными обновленными версиями журналов, создаются с более полной информацией. Например, данные клиента могут быть отложены из-за проблем с сетевым подключением между клиентским компьютером и нашими серверами, или что-то простое, как пользователь, закрывающий крышку на ноутбуке после вызова до отправки и повторного открытия его часов (или дней).

Из-за таких вариантов коллекции могут отображаться добавочные версии, поступающие часы или даже через несколько дней. Вы можете использовать версии для более быстрого понимания вызываемого ресурса, чем ожидание, пока не будут получены все вызывающие клиентские данные пакета SDK. Лучший сценарий — для всех участников вызовов, чтобы завершить их вызовы, и для того, чтобы вызывающий пакет SDK мог отправлять данные на сервер.

Определения данных

Вызов диагностика обновляет схему журнала

В этой таблице описано каждое свойство.

Свойство Description
operationName Операция, связанная с записью журнала.
operationVersion Значение api-version , связанное с операцией, если operationName операция была выполнена через API. Если API не соответствует этой операции, версия представляет версию операции, если свойства, связанные с операцией, изменяются в будущем.
category Категория журнала для события. Это свойство является степенью детализации, при которой можно включить или отключить журналы в ресурсе. Свойства, отображаемые в большом двоичном объекте события, совпадают с properties категорией журнала и типом ресурса.
correlationId Уникальный идентификатор для вызова. Он определяет коррелированные события от всех участников и конечных точек, которые подключаются во время одного вызова. Если вам когда-либо нужно открыть вариант поддержки с корпорацией Майкрософт, можно использовать correlationId значение, чтобы легко определить вызов, который вы устраняете.
participantId Идентификатор, созданный для представления двустороннего подключения между конечной "Participant" точкой (endpointType = "Server") и сервером. При callType = "P2P"наличии прямого подключения между двумя конечными точками и не participantId создается никакого значения.
identifier Уникальный идентификатор пользователя. Удостоверение может быть Службы коммуникации Azure пользователем, идентификатором пользователя Microsoft Entra, идентификатором объекта Teams или идентификатором бота Teams. Этот идентификатор можно использовать для сопоставления событий пользователей в журналах.
endpointId Уникальный идентификатор, представляющий каждую конечную точку, подключенную к вызову, где endpointType определяет тип конечной точки. Если значение равно null, подключенная сущность является сервером служб коммуникации. EndpointId может сохраняться для одного пользователя в нескольких вызовах () для собственных клиентов,correlationId но является уникальным для каждого вызова, когда клиент является веб-браузером.
endpointType Значение, описывающее свойства каждого endpointId экземпляра. Он может содержать "Server", , "PSTN""Voicemail""Anonymous""VOIP""BOT"или ."Unknown"
mediaType Строковое значение, описывающее тип носителя, передаваемого между конечными точками в каждом потоке. Возможные значения: "Audio", ( "Video""VBSS" общий доступ к экранам) и "AppSharing" (канал данных).
streamId Целое число, ненующееся вместе с mediaTypeним, можно использовать для уникальной идентификации потоков одного и того же participantId значения.
transportType Строковое значение, описывающее сетевой транспортный протокол для каждого participantId значения. Он может содержать "UDP", "TCP"или "Unrecognized". "Unrecognized" указывает, что система не могла определить, был ли тип транспорта TCP или UDP.
roundTripTimeAvg Среднее время, необходимое для получения IP-пакета из одной конечной точки в другую в течение определенного participantDuration периода. Эта задержка распространения сети связана с физическим расстоянием между двумя точками, скоростью света и любыми издержками, которые принимают различные маршрутизаторы между ними.

Задержка измеряется как односторонняя или круговая поездка (RTT). Его значение, выраженное в миллисекундах. RTT больше 500 мс отрицательно влияет на качество вызова.
roundTripTimeMax Максимальное значение RTT (в миллисекундах) измеряется в потоке мультимедиа в течение participantDuration периода в групповом вызове или в callDuration течение периода вызова P2P.
jitterAvg Эффект среднего изменения задержки между последовательными пакетами. Службы коммуникации Azure могут адаптироваться к некоторым уровням дрожания благодаря применению буферизации. При превышении буферизации, которая примерно за раз jitterAvg превышает 30 мс, она может отрицательно повлиять на качество. Пакеты, поступающие с разной скоростью, приводят к тому, что голос говорящего звучит как голос робота.

Эта метрика измеряется для каждого потока participantDuration мультимедиа за период в групповом вызове или за callDuration период вызова P2P.
jitterMax Максимальное значение трясти, измеряемое между пакетами для каждого потока мультимедиа. Всплески в условиях сети могут привести к проблемам в потоке аудио-и видеопотока.
packetLossRateAvg Средний процент потерянных пакетов. Потеря пакетов напрямую влияет на качество звука. Небольшие, отдельные потерянные пакеты почти не оказывают влияния, в то время как потери в обратном режиме приводят к тому, что звук полностью вырезается. Пакеты удаляются и не приходят в целевое место назначения, приводят к пробелам в мультимедиа. Эта ситуация приводит к пропущенным слогам и словам, а также к отрезку видео и совместному использованию.

Скорость потери пакетов, превышающая 10 % (0,1), скорее всего, оказывает негативное влияние на качество. Эта метрика измеряется для каждого потока participantDuration мультимедиа за период в групповом вызове или за callDuration период вызова P2P.
packetLossRateMax Это значение представляет максимальную скорость потери пакетов (процент) для каждого потока participantDuration мультимедиа за период вызова группы или callDuration за период вызова P2P. Всплески в условиях сети могут привести к проблемам в потоке аудио-и видеопотока.
JitterBufferSizeAvg Средний размер буфера jitter в течение каждого потока мультимедиа. Буфер jitter — это общая область данных, в которой голосовые пакеты могут собираться, храниться и отправляться в голосовой процессор в равномерном интервале. Буфер Jitter используется для противодействия эффектам дрожи.

Буферы Jitter могут быть статическими или динамическими. Статические буферы jitter задаются в фиксированном размере, а динамические буферы jitter могут настраивать их размер в зависимости от сетевых условий. Цель буфера jitter — обеспечить непрерывный и непрерывный поток звуковых и видеоданных пользователю.

В веб-пакете SDK это JitterBufferSizeAvg среднее значение jitterBufferDelay во время вызова. Длительность jitterBufferDelay звукового примера или видеокадр, который остается в буфере дрожи.

Как правило, если JitterBufferSizeAvg значение больше 200 мс, оно отрицательно влияет на качество.
JitterBufferSizeMax Максимальный размер буфера jitter, измеряемый во время каждого потока мультимедиа.

Как правило, если это значение больше 200 мс, оно отрицательно влияет на качество.
HealedDataRatioAvg Средняя доля потерянных или поврежденных пакетов данных успешно восстановлена или восстановлена целителем в течение длительности аудиопотока. Соотношение данных, исцеляемое, является мерой эффективности методов исправления ошибок, используемых в системах VoIP.

Если это значение больше 0,1 (10%), мы считаем поток плохим качеством.
HealedDataRatioMax Максимальное соотношение данных, измеряемое в течение каждого потока мультимедиа.

Если это значение больше 0,1 (10%), мы считаем поток плохим качеством.
VideoFrameRateAvg Среднее количество видеокадров, передаваемых в секунду во время вызова видео/экранного управления. Частота кадров видео может повлиять на качество и гладкость видеопотока, с более высокими скоростями кадров, что обычно приводит к более гладкому и более плавному движениям жидкости. Стандартная частота кадров для видео WebRTC обычно составляет 30 кадров в секунду (fps), хотя частота кадров может отличаться в зависимости от конкретных условий реализации и сети.

Качество потока считается плохим, если это значение меньше 7 для видеопотока или менее 1 для потока общего доступа к экранам.
RecvResolutionHeight Среднее значение вертикального размера входящего видеопотока, передаваемого во время вызова видео/экранов. Он измеряется в пикселях и является одним из факторов, определяющих общее разрешение и качество видеопотока. Определенное разрешение может зависеть от возможностей устройств и сетевых условий, участвующих в вызове.

Качество потока считается плохим, если это значение меньше 240 для видеопотока или менее 768 для потока общего доступа к экранам.
RecvFreezeDurationPerMinuteInMs Средняя продолжительность замораживания в миллисекундах в минуту для входящего потока видео/экранов. Замораживание обычно связано с плохим состоянием сети и может снизить качество потока.

Качество потока считается плохим, если это значение больше 6000 мс для видеопотока или больше 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"
}

Групповой вызов

Данные для группового вызова создаются в трех журналах сводки вызовов и шести вызовах диагностика журналах обновлений. Ниже приведены общие поля для всех журналов в вызове:

"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.

Плата за объем данных, хранение и использование в Log Analytics в Azure Monitor взимается с помощью существующих счетчиков данных Azure. Рекомендуется отслеживать использование данных и политики хранения по мере необходимости. Дополнительные сведения см. в разделе "Управление затратами".

Если у вас несколько идентификаторов ресурсов Служб коммуникации Azure, необходимо включить эти параметры для каждого идентификатора ресурса.

Следующие шаги