Схема журнала вызова диагностика
Журналы вызовов диагностика предоставляют важные сведения о конечных точках и передаче мультимедиа для каждого участника. Они также предоставляют измерения, которые помогают понять проблемы качества.
Для каждого EndpointId
вызова (включая сервер), Службы коммуникации Azure создает отдельный журнал вызовов диагностика для каждого потока мультимедиа (аудио или видео, например) между конечными точками.
В вызове P2P каждый журнал содержит данные, относящиеся к каждому из исходящих потоков, связанных с каждой конечной точкой. В групповых вызовах participantId
служит идентификатором ключа для присоединения связанных исходящих журналов к отдельному подключению участника. Журналы вызовов диагностика остаются неизменными и одинаковы независимо от клиента участника.
Использование журналов вызовов
Мы рекомендуем собирать все доступные журналы вызовов в ресурсе log analytics, чтобы отслеживать использование звонков и улучшать качество звонков и получать новые журналы из Службы коммуникации Azure по мере их выпуска.
Существует два основных инструмента, которые можно использовать для мониторинга звонков и улучшения качества звонков.
Мы рекомендуем использовать панели мониторинга мониторинга голосовой и видеоанализатора для запуска любых исследований качества и использования вызовов диагностика по мере необходимости для изучения отдельных вызовов при необходимости детализации.
Основные понятия данных
Внимание
Если вы хотите проанализировать их, необходимо собрать журналы. Дополнительные сведения см. в статье Разделы справки журналы хранения?
Azure не хранит данные журнала вызовов, если вы не включите эти параметры диагностики. Данные вызова не доступны ретроактивно. После создания параметров диагностики накапливаются данные.
Определения данных
Схема журнала вызова диагностика
В этой таблице описано каждое свойство.
Свойство | 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 и т. д. |
Примеры данных для различных типов вызовов
Примечание.
В этой статье по умолчанию вызовы 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"
}
Ниже приведен журнал диагностика для аудиопотока из конечной точки 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"
}
Ниже приведен журнал диагностика для видеопотока из конечной точки 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"
}
Групповой вызов
Данные для группового вызова создаются в трех журналах сводки вызовов и шести журналах вызовов диагностика журналах. Ниже приведены общие поля для всех журналов в вызове:
"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"
}
Ниже приведен журнал диагностика для аудиопотока из конечной точки сервера в конечную точку 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"
}
Ниже приведен журнал диагностика для аудиопотока из конечной точки 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"
}
Ниже приведен журнал диагностика для аудиопотока с конечной точки сервера до конечной точки 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",
Часто задаваемые вопросы
Разделы справки хранить журналы?
В следующем разделе объясняется это требование.
Службы коммуникации Azure журналы не хранятся в вашей учетной записи Azure по умолчанию, поэтому вам необходимо начать их хранение, чтобы средства, такие как панель мониторинга голосовой и видеосвязи, и вызывать диагностика для работы. Чтобы собрать эти журналы вызовов, необходимо включить параметр диагностики, который направляет данные вызова в рабочую область Log Analytics.
Данные не хранятся ретроактивно, поэтому вы начинаете записывать журналы вызовов только после настройки параметра диагностики.
Следуйте инструкциям по добавлению параметров диагностики для ресурса в разделе "Включить журналы" с помощью параметров диагностики в Azure Monitor. Рекомендуется сначала собрать все журналы. После понимания возможностей в Azure Monitor определите, какие журналы необходимо сохранить и как долго. При добавлении параметра диагностики вам будет предложено выбрать журналы. Чтобы собрать все журналы, выберите allLogs.
Плата за объем данных, хранение и использование в Log Analytics в Azure Monitor взимается с помощью существующих счетчиков данных Azure. Рекомендуется отслеживать использование данных и политики хранения по мере необходимости. Дополнительные сведения см. в разделе "Управление затратами".
Если у вас несколько идентификаторов ресурсов Служб коммуникации Azure, необходимо включить эти параметры для каждого идентификатора ресурса.
Следующие шаги
Обзор всех журналов голосовой связи и видео см. в статье "Обзор журналов вызовов Службы коммуникации Azure"
Ознакомьтесь с рекомендациями по управлению качеством и надежностью звонков, см. статью "Улучшение качества звонков и управление ими".
Узнайте о панели мониторинга аналитики для мониторинга журналов голосовых звонков и видеозвонок.
Узнайте, как использовать журналы вызовов для диагностики качества и надежности вызовов, см. в статье " Диагностика звонков"