Dela via

Anropa nätverksinterna komponenter

I artikeln beskrivs anropsflödena i Azure Communication Services. Signal- och medieflöden beror på vilka typer av samtal användarna gör. Exempel på samtalstyper är en-till-en VoIP, en-till-en via det publika kommuterade telefonnätet (PSTN), och gruppsamtal som innehåller en kombination av VoIP- och PSTN-anslutna deltagare. Mer information finns i Samtalstyper.

Signalerings- och medieprotokoll

När du upprättar ett peer-to-peer- eller gruppanrop används två protokoll i bakgrunden – HTTPS (REST) för signalering och SRTP (Secure Real-time Transport Protocol) för media.

Signalering mellan SDK:er eller mellan SDK:er och Kommunikationstjänsters signalstyrenheter hanteras med HTTPS REST (TLS). Azure Communication Services använder TLS 1.2. För realtidsmediatrafik (RTP) rekommenderar vi användardatagramprotokoll (UDP). Om brandväggen förhindrar användning av UDP använder SDK:t TCP (Transmission Control Protocol) för media.

Nu ska vi gå igenom signal- och medieprotokollen i olika scenarier.

Samtalsflödesscenarier

Fall 1: VoIP med en direktanslutning mellan två enheter

I individuella VoIP- eller videosamtal föredrar trafiken den mest direkta vägen. Direkt sökväg innebär att om två SDK:er kan nå varandra direkt upprättar de en direktanslutning. Direkt sökväg är möjlig när två SDK:er finns i samma undernät (till exempel i ett undernät 192.168.1.0/24) eller två när enheterna är live i undernät som kan se varandra (SDK:er i undernätet 10.10.0.0/16 och 192.168.1.0/24 kan nå ut till varandra).

Diagram som visar ett direkt VOIP-anrop mellan användare och Kommunikationstjänster.

Fall 2: VoIP där en direkt anslutning mellan enheter inte är möjlig, men en anslutning mellan NAT-enheter är möjlig

Om två enheter finns i undernät som inte kan nå varandra, men anslutningen mellan NAT-enheterna (network address translation) är möjlig, upprättar SDK:erna på klientsidan anslutning via NAT-enheter. Till exempel om Alice arbetar från ett kafé och Bob arbetar från ett hemmakontor.

För Alice är det NAT:et för kaféet och för Bob är det NAT:et för hemmakontoret. Alice enhet skickar den externa adressen för hennes NAT och Bobs gör samma sak. SDK:erna lär sig de externa adresserna från session traversal verktyg för NAT-tjänst (STUN) som Azure Communication Services tillhandahåller kostnadsfritt. Logiken som hanterar handskakningen mellan Alice och Bob är inbäddad i azure Communication Services-tillhandahållna SDK:er. Du behöver ingen tillagd konfiguration.

Diagram som visar ett VOIP-anrop med hjälp av ett verktyg för sessionstraversering för NAT (STUN)-anslutning.

Fall 3: VoIP där en direkt- eller NAT-anslutning inte är möjlig

Om en eller båda klientenheterna ligger bakom en symmetrisk NAT krävs en separat molntjänst för att vidarebefordra mediet mellan de två SDK:erna. Den här tjänsten kallas traversering med hjälp av reläer runt NAT (TURN) och tillhandahålls också av Azure Communication Services. Communication Services Calling SDK använder automatiskt TURN-tjänster baserat på identifierade nätverksförhållanden. TURN-avgifter ingår i priset för samtalet.

Diagram som visar en VOIP över en genomföring med hjälp av reläer genom NAT (TURN) anslutning.

Ärende 4: Gruppsamtal med PSTN

Både signalering och media för PSTN-anrop använder azure communication services-telefoniresursen. Den här resursen är sammankopplad med andra operatörer.

PSTN-medietrafik flödar via en medieprocessorkomponent.

Diagram som visar ett PSTN-gruppsamtal med Kommunikationstjänster.

Anmärkning

Medieprocessorn är också en back to back-användaragent, enligt definitionen i RFC 3261 SIP: Session Initiation Protocol, vilket innebär att den kan översätta codecs vid hantering av anrop mellan Microsoft- och Carrier-nätverk. Signalstyrenheten för Azure Communication Services är Microsofts implementering av en SIP-proxy per samma RFC.

För gruppanrop flödar media och signaler alltid via Azure Communication Services-serverdelen. Ljud och/eller video från alla deltagare blandas i medieprocessorn. Alla medlemmar i ett gruppsamtal skickar sina ljud- och videoströmmar till medieprocessorn, som returnerar blandade medieströmmar.

Standardprotokollet i realtid (RTP) för gruppanrop är UDP (User Datagram Protocol).

Anmärkning

Medieprocessorn kan fungera som en mcu (multipoint control unit) eller selektiv vidarebefordransenhet (SFU).

Diagram som visar UDP-medieprocessflödet i Communication Services.

Om SDK:t inte kan använda UDP för media på grund av brandväggsbegränsningar försöker den använda TCP (Transmission Control Protocol). Medieprocessorkomponenten kräver UDP, så i det här fallet läggs Tjänsten Communication Services TURN till i gruppanropet för att översätta TCP till UDP. TURN-avgifter ingår i priset för samtalet.

Diagram som visar TCP-medieprocessflödet i Communication Services.

Ärende 5: Communication Services SDK och Microsoft Teams i ett schemalagt Teams-möte

Signalering flödar genom signalstyrenheten. Media flödar genom medieprocessorn. Signalstyrenheten och medieprocessorn delas mellan Communication Services och Microsoft Teams.

Diagram som visar Communication Services SDK och Teams Client i ett schemalagt Teams-möte.

Fall 6: Tidiga medier

Refererar till media som utbyts, till exempel ljud och video, innan samtalsmottagaren godkänner sessionen. För tidigt medieflöde måste sessionsgränskontrollen (SBC) låsa sig vid den första slutpunkten som börjar strömma media. Medieflödet kan börja innan kandidater nomineras. SBC måste ha stöd för att skicka multifrekvens med dubbla toner (DTMF) under den här fasen för att aktivera IVR/röstbrevlådescenarier. SBC bör använda den sökväg med högst prioritet som den tar emot kontroller på, om nomineringarna inte är slutförda.

Nästa steg

Kom igång med samtal

  • Last updated on