Ranní přehled vybraných novinek z oblasti AI chatbotů a voice/voicebotů se zaměřením na praktický dopad do telco provozu (kontaktní centra, IVR, realtime audio, observabilita).
OpenAI API Changelog: WebSocket mode pro Responses API + gpt-realtime-1.5 a audio modely
V oficiálním changelogu OpenAI se objevují změny, které jsou pro voiceboty a provoz v telcu zásadní: WebSocket mode pro Responses API a pokračující vývoj realtime/audio modelů (např. vydání gpt-realtime-1.5 pro Realtime API a gpt-audio-1.5 pro Chat Completions). Pro stavbu voicebota to znamená jednodušší sjednocení „klasické“ konverzace (text + tool calling) a nízkolatenčního streamingu do jedné integrační vrstvy, místo slepování několika různých SDK a endpointů. Z pohledu provozu v telco je důležité i to, že API se postupně stabilizuje kolem Responses paradigmatu (včetně věcí jako compaction a tool surfaces), což pomáhá s dlouhými session a nákladovým řízením kontextu. Praktický takeaway: pokud dnes máte oddělené pipeline (chat orchestrace vs. realtime audio), začněte plánovat jejich konvergenci na jednotný „session orchestrátor“ a připravte si metriky pro latenci po segmentech (ingest → ASR/LLM → TTS → playback). Současně se vyplatí zkontrolovat, zda vaše bezpečnostní a síťové politiky (IP allowlisty, egress) odpovídají tomu, že část komunikace půjde přes WebSocket režim.
Microsoft Foundry/Azure: doporučení WebRTC pro realtime audio (a GA protokol pro Realtime API)
Microsoft v návodu pro Azure OpenAI Realtime API explicitně doporučuje pro realtime audio použít WebRTC místo WebSocketů – hlavně kvůli nižší latenci, lepšímu „media handlingu“, kompenzaci jitteru a chování při packet loss. Pro telco/voicebot provoz je to praktické potvrzení, že „telefonní“ síťové podmínky (kolísání, ztrátovost, NAT) nejsou detail, ale klíčový faktor UX, a že transportní vrstva často rozhodne víc než samotný model. Důležitý je také posun k GA protokolu a změna endpointů (client_secrets/calls), což v praxi znamená migrační práci na tokenizaci, bezpečném vydávání ephemeral tokenů a segmentaci front-end vs. server části. Praktický takeaway: i když dnes streamujete audio přes WebSocket (např. z media gateway), pro klientské aplikace (web/mobile agent desktop) zvažte WebRTC a měřte E2E latency včetně „last mile“; zároveň si zaveďte standardní token-service pattern (ephemeral keys) a auditujte, kde by se token mohl nechtěně dostat do klienta nebo logů. Pro operátory to je i argument pro architekturu, kde se mixing/bridging děje co nejblíž hraně (edge) a model se krmí stabilizovaným streamem.
Zdroj: Microsoft Learn – Use the GPT Realtime API via WebRTC
Asterisk: opravy v res_cdrel_custom (CDR/CEL timestampy, formátování a stabilita SQLite spojení)
V releasích Asterisku (RC buildy) se objevila série oprav pro modul res_cdrel_custom, které řeší praktické problémy s timestampy (přechod z float na double kvůli přetečení/wrappingu), respektování defaultního formátu času pro CEL a korektní práci s vlastními strftime formáty. Z provozního pohledu je zajímavá i oprava, kdy reload modulu bez změny konfigurace nemá uvolnit starý config – jinak docházelo k uzavření DB spojení a následně k tomu, že se znovu neotevřelo (tiché selhávání logování). Pro telco voicebot stack je to přesně ten „neviditelný“ typ změny, který ovlivní observabilitu, korelaci událostí (call leg, transfery, konferenční bridging) a tím i schopnost rychle ladit latenci a chyby v integrační vrstvě (media gateway ↔ bot). Praktický takeaway: pokud sbíráte CDR/CEL pro analýzu botů (např. detekce dropů, barge-in, DTMF fallback), ověřte si po upgrade konzistenci časových polí a doporučuji přidat sanity check pipeline (např. monotonicita timestampů a detekce „skoků“). A pokud reloadujete Asterisk komponenty za běhu, stojí za to otestovat, že po reloadu nepřestanete potichu zapisovat do SQLite (nebo jiné DB) – to je typický zdroj „slepých míst“ v incidentu.
Zdroj: GitHub – asterisk/asterisk releases
Parlor (open-source): on-device realtime voice+vision konverzace s VAD, barge-in a streaming TTS
Projekt Parlor ukazuje, kam se posouvá „lokální“ (on-device) realtime voice architektura: browser sbírá mikrofon/kameru, posílá PCM audio + snímky přes WebSocket na FastAPI server, model (Gemma) dělá porozumění a Kokoro TTS vrací streamovanou řeč. Prakticky důležité jsou implementační detaily: Voice Activity Detection (Silero VAD) v klientovi, barge-in (přerušení asistenta mluvením) a sentence-level TTS streaming, kdy audio začne hrát dřív, než je hotová celá odpověď. Pro telco provoz to není „hotové řešení“, ale velmi dobrá inspirace pro UX a pro rozpad latence na kroky (VAD → transkripce/porozumění → generace → TTS → playback), které je možné měřit a optimalizovat. Praktický takeaway: i když v telcu typicky nepůjdete čistě on-device, stejné principy (VAD co nejblíž zdroji, barge-in jako first-class feature, streamované TTS) výrazně zlepšují pocit z konverzace a snižují frustraci volajícího. Pokud řešíte náklady a škálování, on-device/offload trend navíc naznačuje, že část „agent assist“ nebo self-service funkcí může časem běžet lokálně (např. na agent desktopu) a do cloudu posílat jen agregované signály.
Zdroj: GitHub – fikrikarim/parlor
Twilio Flex + OpenAI Realtime: obousměrný realtime překlad hovoru (architektura přes Media Streams)
Praktický technický walkthrough ukazuje implementaci obousměrného realtime překladu hovoru: jedna Node.js služba „sedí uprostřed“, bere audio z obou call legů přes Twilio Media Streams (separate WebSocket per leg), posílá ho do OpenAI Realtime pro překlad a vrací přeložené audio zpět do protilehlé větve hovoru. Z telco perspektivy je zajímavé, že autor řeší typické integrační věci: dvě čísla kvůli izolaci call legů, orchestraci přes Studio/TaskRouter, a potřebu reconnection logiky (WebSocket dropy) – to jsou přesně ty provozní hrany, které rozhodnou, jestli to bude „demo“ nebo „production-grade“. Důležité je také upozornění na konfiguraci klíčů/oprávnění pro audio modely a na to, že některé chyby selžou potichu (např. blokovaná audio oprávnění). Praktický takeaway: pokud uvažujete o multilingual self-service nebo agent assistu, počítejte s tím, že media streaming je dvoukanálový problém (caller vs agent) a že potřebujete jasnou strategii pro fallback (DTMF, přepojení na živého tlumočníka, nebo alespoň „repeat last“). Pro provoz se vyplatí hned od začátku logovat: handshake stavy streamů, délky bufferů, a timestampy přeposílání – bez toho se latence a dropy nedají účinně debuggovat.
Zdroj: ggomez.dev – Real-Time Call Translation With Twilio and OpenAI
3 takeaways pro telco/voice:
- Transport a „last mile“ (WebRTC vs WebSocket, jitter, packet loss) je pro voice UX často důležitější než samotný model – měřte E2E latenci po segmentech.
- Observabilita CDR/CEL a korektní timestampy nejsou kosmetika: bez nich těžko prokážete zlepšení i rychle najdete příčinu incidentů v bot integraci.
- Barge-in, VAD u zdroje a streamované TTS výrazně zlepšují konverzační pocit; zvažte je jako „povinné“ feature pro production voiceboty.