Přehled protokolů volání služby Azure Communication Services

Služba Azure Communication Services poskytuje možnosti protokolování, které můžete použít k monitorování a ladění řešení komunikačních služeb. Tyto možnosti nakonfigurujte prostřednictvím webu Azure Portal.

Obsah v tomto článku se týká protokolů povolených prostřednictvím služby Azure Monitor (viz také nejčastější dotazy). Pokud chcete povolit tyto protokoly pro komunikační služby, přečtěte si téma Povolení protokolování v nastavení diagnostiky.

Důležité

Pokud je chcete analyzovat, musíte shromažďovat protokoly. Další informace najdete v tématu: Návody ukládat protokoly?

Azure neukládá data protokolu volání, pokud tato konkrétní nastavení diagnostiky nepovolíte. Data volání nejsou zpětně dostupná. Jakmile vytvoříte nastavení diagnostiky, nashromáždíte data.

Jak používat protokoly volání

Doporučujeme shromáždit všechny dostupné protokoly volání v prostředku log Analytics, abyste mohli monitorovat využití volání a zlepšit kvalitu volání a přijímat nové protokoly z Azure Communication Services při jejich vydání.

Existují dva hlavní nástroje, které můžete použít k monitorování hovorů a zlepšení kvality hovorů.

• Řídicí panel přehledů pro hlasové a video
• Diagnostika volání

Doporučujeme použít řídicí panely pro přehledy hlasu a videa k zahájení jakéhokoli šetření kvality a použití diagnostiky volání podle potřeby k prozkoumání jednotlivých volání, když potřebujete podrobné podrobnosti.

Dostupné protokoly

Azure Communication Services vytvoří osm protokolů volání:

Protokoly aktualizací souhrnu volání:

Tato data protokolů dorazí do služby Azure Monitor rychleji než protokoly souhrnu volání a místo schématu protokolu souhrnu volání doporučujeme použít tyto protokoly. Tento protokol obsahuje základní informace o volání, včetně všech relevantních ID, časových razítek, koncových bodů a informací o sadě SDK.

Další informace najdete v tématu: Schéma protokolu aktualizací souhrnu volání

Protokoly souhrnu volání:

Tento protokol je podmnožinou schématu protokolu aktualizace souhrnu volání. Obsahuje základní informace o volání, včetně všech relevantních ID, časových razítek, koncových bodů a informací o sadě SDK. Pokud chcete zrychlit latenci protokolu, použijte místo toho protokoly souhrnných aktualizací volání.

Další informace najdete v tématu: Schéma protokolu souhrnu volání

Protokoly aktualizací diagnostiky volání:

Tato data protokolů přicházejí do služby Azure Monitor rychleji než diagnostické protokoly volání a místo schématu protokolu diagnostiky volání doporučujeme použít tyto protokoly. Tento protokol obsahuje informace o datovém proudu médií volání účastníka spolu se sadou metrik, které označují kvalitu měření zkušeností.

Další informace najdete v tématu: Volání diagnostiky aktualizuje schéma protokolu.

Protokoly diagnostiky volání:

Tento protokol je podmnožinou schématu protokolu diagnostiky volání. Obsahuje informace o datovém proudu spolu se sadou metrik, které označují kvalitu měření zkušeností. Pokud chcete zrychlit latenci protokolu, použijte místo toho protokoly souhrnných aktualizací volání.

Další informace najdete v tématu: Schéma protokolu diagnostiky volání

Volání protokolů operací klienta:

Obsahují podrobné události klienta volání. Tyto události protokolu se generují pro každý EndpointId hovor a počet vygenerovaných protokolů událostí závisí na operacích, které účastník provedl během hovoru.

Další informace najdete v tématu: Volání schématu protokolu operací klienta

Volání protokolů statistiky médií klienta:

Obsahují podrobné hodnoty datových proudů médií. Tyto protokoly se generují pro každý datový proud médií ve volání. Pro každý EndpointId z volání (včetně serveru) vytvoří služba Azure Communication Services pro každý datový proud médií (například zvuk nebo video) mezi koncovými body jedinečný protokol. Objem dat vygenerovaných v každém protokolu závisí na době volání a počtu mediálních páry v hovoru.

Ve volání P2P každý protokol obsahuje data, která se vztahují ke každému odchozímu datovému proudu přidruženému ke každému koncovému bodu. Každý datový proud přidružený ke endpointType = "Server" skupinovému volání vytvoří protokol, který obsahuje data pro příchozí datové proudy. Všechny ostatní datové proudy vytvářejí protokoly, které obsahují data pro odchozí datové proudy pro všechny koncové body mimo server. Ve volání skupiny použijte participantId hodnotu jako klíč pro připojení souvisejících příchozích a odchozích protokolů k jedinečnému připojení účastníka.

Další informace najdete v tématu: Volání schématu protokolů časových řad klientských médií

Protokoly ukončení průzkumu volání:

Tyto protokoly se vyplní, když klient webového volání odešle průzkum na konci hovoru. Tyto protokoly můžete použít k získání subjektivního vnímání kvality volání od uživatelů.

Další informace najdete v tématu: Přehled průzkumu na konci hovoru

Protokoly metrik volání:

Tyto protokoly obsahují agregované metriky volání v denních intervalech na základě atributů, jako jsou verze sady SDK, název operačního systému a podkód chyby. Tyto protokoly se používají na řídicím panelu pro přehledy hlasu a videa k vizualizaci dlouhodobých grafů spolehlivosti, kvality a výkonu na základě počtu úspěšných a neúspěšných volání volání rozhraní API sady SDK různých operací.

Další informace najdete v tématu: Volání schématu protokolu metrik

Koncepty dat

Následující základní popisy konceptů dat jsou specifické pro hlasové hovory a videohovory. Tyto koncepty jsou důležité ke kontrole, abyste porozuměli významu dat zachycených v protokolech.

Entity a ID

Seznamte se s následujícími termíny:

• Volání: Jak je znázorněno v datech, volání je abstrakce znázorněna correlationId. Hodnoty pro correlationId každé volání jsou jedinečné a jsou vázány na callStartTime základě a callDuration.

• Účastník: Představuje připojení mezi koncovým bodem a serverem. Účastník (participantId) je k dispozici pouze tehdy, když je hovor skupinový.

• Koncový bod: Nejvýraznější entita reprezentovaná hodnotou endpointId. Každé volání je událost, která obsahuje data ze dvou nebo více koncových bodů. Koncové body představují účastníky hovoru.

  EndpointType udává, jestli je koncový bod člověkem (pstn nebo VoIP), robotem nebo serverem, který spravuje více účastníků během hovoru. endpointType Pokud je "Server"hodnota, koncový bod nemá přiřazené jedinečné ID. Můžete analyzovat endpointType a počet hodnot, abyste zjistili, endpointId kolik uživatelů a dalších nelidských účastníků (robotů a serverů) se připojí k hovoru.

  Nativní sady SDK pro Android a iOS opakovaně používají stejnou endpointId hodnotu pro uživatele napříč několika voláními, abyste pochopili prostředí napříč relacemi. Tento proces se liší od webových koncových bodů, které vždy generují novou endpointId hodnotu pro každé nové volání.

• Stream: Nejpodrobnější entita. Pro každý směr (příchozí nebo odchozí) a mediaType hodnotu (například Audio nebo Video) existuje jeden datový proud.

P2P vs. skupinové volání

Poznámka:

V tomto článku jsou volání P2P a skupiny ve výchozím nastavení ve stejném tenantovi. Všechny scénáře volání, které jsou napříč tenanty, se zadají odpovídajícím způsobem v celém článku.

Existují dva typy volání, jak je reprezentováno callType:

• Volání peer to Peer (P2P): Připojení mezi pouze dvěma koncovými body bez koncového bodu serveru. Volání P2P se zahájí jako volání mezi těmito koncovými body a před připojením se nevytvořijí jako událost skupinového volání.

  

• Skupinové volání: Jakékoli volání, které má více než dva koncové body připojené. Volání skupin zahrnují koncový bod serveru a připojení mezi jednotlivými koncovými body a serverem. Volání P2P, která během volání přidají další koncový bod, přestanou být P2P a stanou se voláním skupiny. Časovou osu, kdy se každý koncový bod připojil k volání, můžete určit pomocí participantStartTime metrik a participantDuration metrik.

  

Příklady různých typů volání

Poznámka:

V tomto článku jsou volání P2P a skupiny ve výchozím nastavení ve stejném tenantovi. Všechny scénáře volání, které jsou napříč tenanty, se zadají odpovídajícím způsobem v celém článku.

Příklad: Volání P2P

Následující diagram představuje dva koncové body připojené přímo ve volání P2P. V tomto příkladu služba Communication Services vytvoří dva protokoly souhrnu volání (jeden pro každou participantID hodnotu) a čtyři protokoly diagnostiky volání (jeden pro každý datový proud médií).

Pro účastníky volání klientské služby Azure Communication Services existuje také řada protokolů operací volání klienta a volání protokolů časových řad statistiky médií klienta. Přesný počet těchto protokolů závisí na tom, jaký druh operací sady SDK se volá, a dobu trvání volání.

Příklad: Skupinové volání

Následující diagram představuje příklad skupinového volání se třemi participantId hodnotami (což znamená tři účastníky) a koncovým bodem serveru. V několika účastníkůch se může zobrazit více hodnot endpointId – například když se znovu připojí ke stejnému zařízení. Služba Communication Services vytvoří jeden protokol souhrnu volání pro každou participantId hodnotu. Vytvoří čtyři protokoly diagnostiky volání: jeden pro každý datový proud médií podle participantId.

Pro účastníky volání služby Azure Communication Services jsou protokoly operací volání stejné jako volání P2P. Pro každého účastníka, který používá volání sady SDK, existuje řada protokolů operací volání klienta.

Pro účastníky volání klienta služby Azure Communication Services jsou protokoly operací volání klienta a protokoly časových řad volání statistiky médií klienta stejné jako volání P2P. Pro každého účastníka používajícího volání sady SDK existuje řada protokolů operací volání a volání protokolů časových řad statistiky médií klienta.

Příklad: Volání P2P mezi tenanty

Následující diagram představuje dva účastníky ve více tenantech, kteří jsou připojeni přímo ve volání P2P. V tomto příkladu služba Communication Services vytvoří jeden protokol souhrnu volání (jeden pro každého účastníka) s redakčně upravenou verzí operačního systému a sady SDK. Služba Communication Services také vytvoří čtyři protokoly diagnostiky volání (jeden pro každý datový proud médií). Každý protokol obsahuje data, která se vztahují k odchozímu datovému participantIDproudu .

Příklad: Volání skupiny napříč tenanty

Následující diagram představuje příklad skupinového volání se třemi participantId hodnotami ve více tenantech. Služba Communication Services vytvoří pro každého účastníka jeden protokol souhrnu volání s redakčně upravenou verzí operačního systému a sady SDK. Služba Communication Services také vytvoří čtyři protokoly diagnostiky volání, které se týkají každé participantId hodnoty (jedna pro každý datový proud médií).

Poznámka:

Tato verze podporuje pouze odchozí diagnostické protokoly. Verze operačního systému a sady SDK přidružené k robotovi a účastníkovi je možné redactovat, protože komunikační služby zachází s identitami účastníků a robotů stejným způsobem.

Nejčastější dotazy

Návody ukládat protokoly?

Tento požadavek vysvětluje následující část.

Protokoly Azure Communication Services se ve výchozím nastavení neukládají do vašeho účtu Azure, takže je musíte začít ukládat, abyste mohli používat nástroje, jako je řídicí panel pro přehledy hlasových hovorů a diagnostika volání. Pokud chcete tyto protokoly volání shromáždit, musíte povolit nastavení diagnostiky, které směruje data volání do pracovního prostoru služby Log Analytics.

Data se neukládají zpětně, takže začnete zachytávat protokoly volání až po konfiguraci nastavení diagnostiky.

Podle pokynů přidejte nastavení diagnostiky pro váš prostředek v části Povolit protokoly prostřednictvím nastavení diagnostiky ve službě Azure Monitor. Doporučujeme nejprve shromáždit všechny protokoly. Jakmile porozumíte možnostem ve službě Azure Monitor, určete, které protokoly chcete zachovat a jak dlouho. Když přidáte nastavení diagnostiky, zobrazí se výzva k výběru protokolů. Pokud chcete shromáždit všechny protokoly, vyberte všechny protokoly.

Objem dat, uchovávání a využití v Log Analytics v rámci služby Azure Monitor se účtuje prostřednictvím stávajících měřičů dat Azure. Doporučujeme podle potřeby monitorovat využití dat a zásady uchovávání informací. Další informace naleznete v tématu Řízení nákladů.

Pokud máte více ID prostředků Azure Communications Services, musíte tato nastavení povolit pro každé ID prostředku.

Další kroky

• Seznamte se s osvědčenými postupy pro správu kvality a spolehlivosti hovorů, viz: Zlepšení a správa kvality hovorů

• Přečtěte si o řídicím panelu přehledů pro monitorování protokolů hlasových hovorů a videohovorů.

• Zjistěte, jak pomocí protokolů volání diagnostikovat problémy s kvalitou volání a spolehlivostí diagnostiky volání, viz: Diagnostika volání