Basisbeginselen van oproepstroom
De volgende sectie bevat een overzicht van de oproepstromen in Azure Communication Services. Signalerings- en mediastromen zijn afhankelijk van de typen oproepen die uw gebruikers maken. Voorbeelden van oproeptypen zijn een-op-een VoIP, een-op-een PSTN en groepsgesprekken met een combinatie van via VoIP en PSTN verbonden deelnemers. Bekijk Oproeptypen.
Over signalerings- en mediaprotocollen
Wanneer u een peer-to-peer- of groepsoproep tot stand brengt, worden er achter de schermen twee protocollen gebruikt: HTTPS (REST) voor signalering en SRTP voor media.
Signalering tussen de SDK's of tussen SDK's en Communication Services-signaleringscontrollers wordt verwerkt met HTTPS REST (TLS). Azure Communication Services maakt gebruik van TLS 1.2. Voor mediaverkeer in real time (RTP) krijgt het UDP (User Datagram Protocol) de voor eur. Als het gebruik van UDP wordt voorkomen door uw firewall, gebruikt de SDK het Transmission Control Protocol (TCP) voor media.
Laten we eens kijken naar de protocollen voor signalering en media in verschillende scenario's.
Voorbeelden oproepstromen
Case 1: VoIP waarbij een directe verbinding tussen twee apparaten mogelijk is
Bij één-op-één VoIP- of videogesprekken verkiest verkeer de meest directe weg. 'Direct pad' betekent dat als twee SDK's elkaar rechtstreeks kunnen bereiken, ze een directe verbinding tot stand brengen. Dit is meestal mogelijk wanneer twee SDK's zich in hetzelfde subnet bevinden (bijvoorbeeld in een subnet 192.168.1.0/24) of twee wanneer de apparaten zich in subnetten bevinden die elkaar kunnen zien (SDK's in subnet 10.10.0.0/16 en 192.168.1.0/24 elkaar kunnen bereiken).
Case 2: VoIP waarbij een directe verbinding tussen apparaten niet mogelijk is, maar waar verbinding tussen NAT-apparaten mogelijk is
Als twee apparaten zich in subnetten bevinden die elkaar niet kunnen bereiken (Alice werkt bijvoorbeeld vanuit een koffiebar en Bob werkt vanuit zijn kantoor) maar de verbinding tussen de NAT-apparaten mogelijk is, worden de SDK's aan de clientzijde verbonden via NAT-apparaten.
Voor Alice is dat de NAT van de koffiebar en voor Bob de NAT van zijn thuiskantoor. Het apparaat van Alice verzendt het externe adres van haar NAT en Bob doet hetzelfde. De SDK's leren de externe adressen van een STUN-service (Session Traversal Utilities for NAT) die Azure Communication Services gratis biedt. De logica die de handshake tussen Alice en Bob afhandelt, wordt ingesloten in de door Azure Communication Services geleverde SDK's. (U hebt geen aanvullende configuratie nodig)
Case 3: VoIP waarbij geen directe of NAT-verbinding mogelijk is
Als een of beide clientapparaten zich achter een symmetrische NAT bevinden, is een afzonderlijke cloudservice vereist om de media tussen de twee SDK's door te sturen. Deze service heet TURN (Traversal Using Relays around NAT) en wordt ook door de Communication Services voorzien. De Communication Services Calling SDK maakt automatisch gebruik van TURN-services op basis van gedetecteerde netwerkvoorwaarden. TURN-kosten zijn inbegrepen in de prijs van de oproep.
Case 4: Groepsgesprekken met PSTN
Zowel signalering als media voor PSTN-oproepen gebruiken de telefonieresource van Azure Communication Services. Deze resource is verbonden met andere providers.
PSTN-mediaverkeer loopt via een onderdeel dat de mediaprocessor wordt genoemd.
Notitie
Voor degenen die bekend zijn met mediaverwerking, is onze Mediaprocessor ook een Back-to-Back User Agent, zoals gedefinieerd in RFC 3261 SIP: Session Initiation Protocol, wat betekent dat het codecs kan vertalen bij het verwerken van gesprekken tussen Microsoft- en Carrier-netwerken. De signaleringscontroller van Azure Communication Services is de implementatie van een SIP-proxy door Microsoft volgens dezelfde RFC.
Voor groepsgesprekken lopen media en signalering altijd via de back-end van Azure Communication Services. De audio en/of video van alle deelnemers wordt gemengd in de mediaprocessor. Alle leden van een groepsgesprek sturen hun audio-en/of videostreams naar de mediaprocessor, die gemengde mediastreams terugstuurt.
Het standaard real-time protocol (RTP) voor groepsgesprekken is UDP (User Datagram Protocol).
Notitie
De mediaprocessor kan dienen als Multipoint Control Unit (MCU) of een Selective Forwarding Unit (SFU)
Als de SDK UDP niet kan gebruiken voor media vanwege firewallbeperkingen, wordt geprobeerd het Transmission Control Protocol (TCP) te gebruiken. Houd er rekening mee dat de mediaprocessor UDP nodig heeft. Wanneer dit gebeurt, wordt de TURN-service van Communication Services toegevoegd aan het groepsgesprek om TCP naar UDP te vertalen. TURN-kosten zijn inbegrepen in de prijs van de oproep.
Case 5: Communication Services SDK en Microsoft Teams in een geplande Teams-vergadering
Signalering stroomt door de signaleringscontroller. Media stromen door de mediaprocessor. De signaleringscontroller en mediaprocessor worden gedeeld tussen Communication Services en Microsoft Teams.
Case 6: Vroege media
Verwijst naar media (bijvoorbeeld audio en video) die worden uitgewisseld voordat een bepaalde sessie wordt geaccepteerd door de aangeroepen gebruiker. Als er een vroege mediastroom is, moet de SBC worden gekoppeld aan het eerste eindpunt dat begint met het streamen van media; mediastroom kan beginnen voordat kandidaten worden genomineerd. De SBC moet ondersteuning hebben voor het verzenden van DTMF tijdens deze fase om IVR-/voicemailscenario's in te schakelen. De SBC moet het pad met de hoogste prioriteit gebruiken waarop het heeft gecontroleerd of de nominaties niet zijn voltooid.
Volgende stappen
De volgende documenten zijn mogelijk interessant voor u:
- Meer informatie over oproeptypen
- Meer informatie over Client-serverarchitectuur
- Meer informatie over oproepstroomtopologieën