Dobré ráno — tady je krátký briefing k AI chatbotům a hlasovým/voice botům (s důrazem na provoz a integrace v telco). Dnes dominují témata: produkční „realtime“ voice pipeliny, měření latence a praktičtější SIP/PBX stavebnice.
VideoSDK Agents v1.0.0: sjednocený pipeline pro voice agenty + hooks, observabilita
VideoSDK vydalo Agents v1.0.0 a popisuje to jako architektonický přerod: místo dvou režimů (CascadingPipeline a RealtimePipeline) je jedna třída Pipeline, která se sama přepíná podle zvolených komponent. Prakticky to znamená, že můžete snadno skládat řetězec STT→LLM→TTS („cascade“), nebo jít do režimu „single realtime model“ (nejnižší latence), případně hybridně kombinovat (např. vlastní STT + realtime LLM, nebo realtime LLM + vlastní TTS). Důležité pro telco voice provoz je, že SDK explicitně počítá s VAD, turn detection, přerušováním (barge-in) a nabízí hooky, kde lze dělat normalizaci, redakci/PII masking, úpravy výslovnosti nebo i úplné „bypassnutí“ LLM. V praxi je to docela dobrý signál, že „voice agent runtime“ se posouvá z demo-kódu do frameworků s jasnými body pro compliance, observabilitu a tuning. Takeaway: pokud stavíte hlasové boty na WebRTC/RTC vrstvě, sjednocená pipeline + hooky + OTel vám ušetří čas hlavně při ladění latence, logování a bezpečnostních filtrů napříč STT/LLM/TTS.
Zdroj: VideoSDK – Product Updates March 2026 (Agents v1.0.0)
„300ms budget“ pro voice AI: kde mizí milisekundy a proč je streaming víc než „rychlejší model“
Chanl rozebírá prakticky (a dost střízlivě), proč voice agent, který odpovídá až po ~1,4 s, působí jako špatné spojení, a jak se to dá rozpitvat na konkrétní složky latence: STT finalizace, LLM time-to-first-token, TTS time-to-first-byte a transport. Klíčový bod je, že plně „sekvenční“ pipeline (uživatel domluví → STT zpracuje vše → LLM vygeneruje vše → TTS vysynthesizuje vše) je pro reálné hovory prakticky nepoužitelná; musíte streamovat a zpracovávat rámce paralelně. Text jde do detailu rámcového (frame-based) modelu v Pipecat a vysvětluje i obousměrné signály pro přerušení, což je pro telco barge‑in zásadní (nechcete doříkávat repliku, když zákazník skočí do řeči). Pro telco je zajímavá i část o transportu: WebRTC typicky ušetří stovky ms oproti PSTN cestě, takže „stejný“ bot bude na webu znít plynuleji než přes klasický voice trunk. Takeaway: měřte a logujte TTFT/TTFB a transport overhead, a v návrhu počítejte se streamováním a přerušením jako s defaultem — ne jako s „nice-to-have“.
Zdroj: Chanl – Voice AI pipeline (STT/LLM/TTS) a 300ms budget
DragonPBX: programovatelný PBX pro „person-to-person“ volání, webhooky a JSON „verby“
Na TADSummit vyšel rozhovor/článek o DragonPBX (side‑project Sama Machina z Jambonz) — minimalistický „programmable PBX“ zaměřený na person‑to‑person směrování, kde logika není dialplan v PBX jazyku, ale webhooks + JSON a pár jednoduchých „verbů“ (announce, connect, pause, response). Pointa je, že CPaaS typu Twilio/Vonage/Jambonz jsou skvělé pro person‑to‑application scénáře (IVR, AI agent), ale pro čisté směrování hovorů mezi lidmi (ringing, retries, ringback, routing po neúspěchu) je často potřeba něco jednoduššího a víc „PBX‑like“. Pro telco/enterprise voice provoz je důležité, že podobný stavební blok umožní oddělit routing před přijetím hovoru od „aplikace“ (IVR/AI), a do AI vrstvy posílat až to, co má smysl (ne každé zvonění). Praktický dopad pro voice boty: když máte AI agenta jako jednu z destinací, chcete čistou integraci (např. route-up do Jambonz) a možnost rozhodovat až po tom, co se stane (neodpovězeno, busy, timeouts). Takeaway: zvažte architekturu „PBX routing jako samostatná služba“ a AI/IVR jako další aplikace — zjednoduší to provoz, škálování i troubleshooting.
Zdroj: TADSummit – DragonPBX with Sam Machin
Azure Speech SDK 1.48.x: měření end‑to‑end latence v JS + CRL fixy (Linux/Android) a stop timeout
Microsoft v release notes Speech SDK (verze 1.48.1/1.48.2) přidává několik věcí, které jsou „nenápadné“, ale v produkci hodně bolí: metrika rozpoznávací latence v JavaScriptu (SpeechServiceResponse_RecognitionLatencyMs) pro end‑to‑end měření od audio vstupu po výsledek, a také Recognizer_StopTimeoutMs jako ochranu proti nekonečnému čekání při stopContinuousRecognitionAsync(). Současně je tam důležitý fix CRL cache partitioning pro Linux/Android (při zapnuté CRL kontrole), který může jinak způsobovat chyby po rotaci certifikátů nebo při přepínání regionů — typická „operational“ závada, která se projeví jako náhodné connect faily. Pro telco voice boty to znamená: (1) konečně si můžete standardizovaně sbírat latenci z klienta a porovnávat ji s backend metrikami, (2) máte jasnější kontrolu nad „shutdown“ chováním recognizeru, (3) a je dobré plánovat upgrade před deadline, pokud běžíte Linux/Android klienty s CRL verifikací. Takeaway: přidejte RecognitionLatencyMs do observability dashboardů a otestujte stop timeouty na scénářích výpadků sítě — zlepší to stabilitu hlasových aplikací v reálném provozu.
Zdroj: Microsoft Learn – Speech service release notes (Speech SDK 1.48.x)
Závěr – 3 takeaways pro telco/voice:
- Streaming a přerušování (barge‑in) nejsou „feature“, ale základní architektura, pokud chcete přirozený dialog.
- Observabilita musí jít přes celý řetězec (STT/LLM/TTS + transport); bez TTFT/TTFB a end‑to‑end metrik budete ladit naslepo.
- Oddělte call routing (PBX/SIP logika) od AI/IVR vrstvy — zjednoduší to provoz a sníží náklady na „AI na každém zvonění“.