Sdílet prostřednictvím


Základy toku volání

Následující část obsahuje přehled toků volání ve službě Azure Communication Services. Toky signálů a médií závisí na typech volání, která uživatelé dělají. Mezi příklady typů volání patří 1:1 VoIP, 1:1 do veřejné telefonní sítě a skupinové hovory obsahující kombinaci účastníků připojených přes VoIP a veřejnou telefonní síť. Zkontrolujte typy volání.

Informace o signalizačních a mediálních protokolech

Když vytvoříte volání peer-to-peer nebo skupiny, použijí se dva protokoly na pozadí – HTTPS (REST) pro signalizaci a SRTP pro média.

Signalizace mezi sadami SDK nebo mezi sadami SDK a kontrolery signalizačních služeb komunikačních služeb se zpracovává pomocí protokolu HTTPS REST (TLS). Služba Azure Communication Services používá protokol TLS 1.2. U přenosů médií v reálném čase (RTP) je upřednostňovaný protokol UDP (User Datagram Protocol). Pokud brána firewall znemožní použití protokolu UDP, sada SDK pro média použije protokol TCP (Transmission Control Protocol).

Pojďme se podívat na signalizační a mediální protokoly v různých scénářích.

Případy toku volání

Případ 1: VoIP, kde je možné přímé připojení mezi dvěma zařízeními

V případě 1:1 VoIP nebo videohovorů dává provoz přednost nejpřímější cestě. "Přímá cesta" znamená, že pokud se dvě sady SDK můžou spojit přímo, vytvoří přímé připojení. To je obvykle možné, když jsou dvě sady SDK ve stejné podsíti (například v podsíti 192.168.1.0/24) nebo dvě, když jsou zařízení v podsítích, které se vzájemně vidí (sady SDK v podsíti 10.10.0.0/16 a 192.168.1.0/24 se vzájemně můžou spojit).

Diagram showing a Direct VOIP call between users and Communication Services.

Případ 2: VoIP, kde není možné přímé připojení mezi zařízeními, ale kde je možné připojení mezi zařízeními NAT

Pokud jsou dvě zařízení umístěná v podsítích, které se navzájem nemůžou spojit (například Alice pracuje z kavárny a Bob pracuje ve své domovské kanceláři), ale připojení mezi zařízeními NAT je možné, sady SDK na straně klienta vytvoří připojení přes zařízení NAT.

Pro Alice to bude PŘEKLAD ADRES v kavárně a pro Boba to bude NAT domácí kanceláře. Zařízení Alice pošle externí adresu svého překladu adres (NAT) a Bob's udělá totéž. Sady SDK se učí externí adresy ze služby STUN (Session Traversal Utilities for NAT), kterou poskytuje služba Azure Communication Services zdarma. Logika, která zpracovává metodu handshake mezi Alice a Bobem, je vložená do sad SDK poskytovaných službou Azure Communication Services. (Nepotřebujete žádnou další konfiguraci)

Diagram showing a VOIP call which utilizes a STUN connection.

Případ 3: VoIP, kde není možné přímé ani naT připojení

Pokud je jedno nebo obě klientská zařízení za symetrickým překladem adres (NAT), vyžaduje se samostatná cloudová služba pro přenos médií mezi těmito dvěma sadami SDK. Tato služba se nazývá TURN (Traversal Using Relays around NAT) a je také poskytována komunikačními službami. Sada SDK pro volání komunikačních služeb automaticky používá služby TURN na základě zjištěných podmínek sítě. Poplatky turn jsou zahrnuté v ceně hovoru.

Diagram showing a VOIP call which utilizes a TURN connection.

Případ 4: Skupinové hovory do veřejné telefonní sítě

Signály i média pro volání do veřejné telefonní sítě používají telefonní prostředek služby Azure Communication Services. Tento prostředek je propojený s jinými operátory.

Mediální provoz ve veřejné telefonní síti prochází komponentou s názvem Procesor médií.

Diagram showing a PSTN Group Call with Communication Services.

Poznámka:

Pro ty, kteří jsou obeznámeni se zpracováním médií, je náš procesor médií také back-to-back user agent, jak je definováno v RFC 3261 SIP: Session Initiation Protocol, což znamená, že může překládat kodeky při zpracování volání mezi sítěmi Microsoft a Carrier. Kontroler signalizačních služeb Azure je implementace proxy protokolu SIP microsoftu na stejnou rfc.

U skupinových volání, médií a signalizace vždy proudí přes back-end služby Azure Communication Services. Zvuk a/nebo video od všech účastníků je smíšené v komponentě Procesor médií. Všichni členové volání skupiny posílají do procesoru médií zvukové streamy nebo video streamy, které vrací smíšené mediální proudy.

Výchozí protokol RTP (Real-Time Protocol) pro volání skupin je UDP (User Datagram Protocol).

Poznámka:

Procesor médií může fungovat jako multipointová řídicí jednotka (MCU) nebo selektivně předávací jednotka (SFU).

Diagram showing UDP media process flow within Communication Services.

Pokud sada SDK nemůže kvůli omezením brány firewall používat UDP pro média, bude proveden pokus o použití protokolu TCP (Transmission Control Protocol). Všimněte si, že komponenta Procesor médií vyžaduje UDP, takže v takovém případě bude služba TURN komunikačních služeb přidána do volání skupiny pro překlad TCP na UDP. Poplatky turn jsou zahrnuté v ceně hovoru.

Diagram showing TCP media process flow within Communication Services.

Případ 5: Sada SDK komunikačních služeb a Microsoft Teams v naplánované schůzce Teams

Signalizace prochází kontrolerem signalizace. Média procházejí procesorem médií. Kontroler signálů a procesor médií se sdílí mezi komunikačními službami a Microsoft Teams.

Diagram showing Communication Services SDK and Teams Client in a scheduled Teams meeting.

Případ 6: Časná média

Odkazuje na média (např. zvuk a video), která se vyměňují před přijetím konkrétní relace volanou uživatelem. Pokud je k dispozici počáteční tok média, musí SBC západnout na první koncový bod, který spouští streamované médium; tok médií může začínat před nominací kandidáty. SBC by měl mít podporu pro odesílání DTMF během této fáze, aby bylo možné scénáře IVR/hlasové pošty. SBC by měl používat cestu s nejvyšší prioritou, pro kterou obdržela kontroly, pokud nominace nedokončily.

Další kroky

Pro vás můžou být zajímavé následující dokumenty: