A hívási folyamat alapjai
Az alábbi szakasz áttekintést nyújt az Azure Communication Services hívási folyamatáról. A jel- és médiafolyamatok a felhasználók által kezdeményezett hívások típusától függenek. A hívástípusok közé tartoznak például az egy-az-egyHez VoIP, az egy-az-egyhez PSTN és a VoIP és a PSTN-hez csatlakozó résztvevők kombinációját tartalmazó csoportos hívások. Tekintse át a hívástípusokat.
Tudnivalók a jel- és médiaprotokollokról
Társközi vagy csoportos hívás létrehozásakor a rendszer két protokollt használ a színfalak mögött : HTTPS (REST) a jelátvitelhez és az SRTP-t a média számára.
Az SDK-k vagy az SDK-k és a Kommunikációs szolgáltatások jelátviteli vezérlői közötti jelzést HTTPS REST (TLS) kezeli. Az Azure Communication Services a TLS 1.2-t használja. A valós idejű médiaforgalom (RTP) esetében a User Datagram Protocol (UDP) van előnyben. Ha a tűzfal megakadályozza az UDP használatát, az SDK az átviteli vezérlési protokollt (TCP) fogja használni a médiatartalmakhoz.
Tekintsük át a különböző forgatókönyvekben használt jel- és médiaprotokollokat.
Hívási folyamatok esetei
1. eset: VoIP, ahol közvetlen kapcsolat lehetséges két eszköz között
Az egy-az-egyhez VoIP- vagy videohívásokban a forgalom a legközvetebb útvonalat részesíti előnyben. A "közvetlen elérési út" azt jelenti, hogy ha két SDK közvetlenül elérheti egymást, akkor közvetlen kapcsolatot létesítenek. Ez általában akkor lehetséges, ha két SDK ugyanabban az alhálózatban található (például egy 192.168.1.0/24 alhálózatban vagy kettőben, amikor az eszközök egymásnak látható alhálózatokban élnek (a 10.10.0.0/16 és 192.168.1.0/24 alhálózatban található SDK-k képesek elérni egymást).
2. eset: VoIP, ahol az eszközök közötti közvetlen kapcsolat nem lehetséges, de ahol a NAT-eszközök közötti kapcsolat lehetséges
Ha két olyan alhálózaton található, amely nem tudja elérni egymást (például Alice egy kávézóból dolgozik, Bob pedig az otthoni irodájából dolgozik), de a NAT-eszközök közötti kapcsolat lehetséges, az ügyféloldali SDK-k NAT-eszközökön keresztül létesítik a kapcsolatot.
Alice számára ez lesz a NAT a kávézó és Bob lesz a NAT a home office. Alice eszköze elküldi a NAT külső címét, Bobé pedig ugyanezt teszi. Az SDK-k az Azure Communication Services által ingyenesen biztosított STUN (Session Traversal Utilities for NAT) szolgáltatásból tanulják meg a külső címeket. Az Alice és Bob közötti kézfogást kezelő logika az Azure Communication Services által biztosított SDK-kba van ágyazva. (Nincs szükség további konfigurációra)
3. eset: VoIP, ahol sem közvetlen, sem NAT-kapcsolat nem lehetséges
Ha egy vagy mindkét ügyféleszköz szimmetrikus NAT mögött található, külön felhőszolgáltatás szükséges a két SDK közötti adathordozó továbbításához. Ezt a szolgáltatást TURN-nek (a NAT körüli továbbítók használatával) nevezik, és a kommunikációs szolgáltatások is biztosítják. A Communication Services Calling SDK automatikusan TURN-szolgáltatásokat használ az észlelt hálózati feltételek alapján. A TURN díjakat a hívás ára tartalmazza.
4. eset: Csoportos hívások PSTN-vel
A PSTN-hívások jelzése és adathordozója egyaránt az Azure Communication Services telefonos erőforrását használja. Ez az erőforrás más szolgáltatókkal van összekapcsolva.
A PSTN-médiaforgalom egy Media Processor nevű összetevőn halad át.
Feljegyzés
Azok számára, akik ismerik a médiafeldolgozást, a Media Processor is egy Back to Back felhasználói ügynök, ahogy azt az RFC 3261 SIP: Session Initiation Protocol határozza meg, ami azt jelenti, hogy képes lefordítani a kodekeket a Microsoft és a Carrier hálózatok közötti hívások kezelésekor. Az Azure Communication Services jelátviteli vezérlője a Microsoft SIP-proxyjának implementálása ugyanazon RFC-nként.
Csoportos hívások esetén a média és a jelátvitel mindig az Azure Communication Services háttérrendszerén keresztül zajlik. Az összes résztvevő hang- és/vagy videoképe vegyesen szerepel a Media Processor összetevőben. A csoportos hívás minden tagja elküldi a hang- és/vagy videostreameket a médiafeldolgozónak, amely vegyes médiastreameket ad vissza.
A csoportos hívások alapértelmezett valós idejű protokollja (RTP) a User Datagram Protocol (UDP).
Feljegyzés
A médiafeldolgozó többpontos vezérlőegységként (MCU) vagy szelektív továbbítási egységként (SFU) működhet
Ha az SDK tűzfalkorlátozások miatt nem tudja használni az UDP-t a médiatartalmakhoz, megkísérli használni a Transmission Control Protocol (TCP) protokollt. Vegye figyelembe, hogy a Médiafeldolgozó összetevőhöz UDP szükséges, ezért ebben az esetben a Communication Services TURN szolgáltatás hozzá lesz adva a csoporthíváshoz a TCP UDP-hez való fordításához. A TURN díjakat a hívás ára tartalmazza.
5. eset: A Communication Services SDK és a Microsoft Teams ütemezett Teams-értekezleten
A jelátviteli vezérlőn keresztül áramlik. A médiafolyamatok a médiafeldolgozón keresztül áramlnak. A jelátviteli vezérlő és a médiafeldolgozó meg van osztva a Kommunikációs szolgáltatások és a Microsoft Teams között.
6. eset: Korai média
Azokra a médiatartalmakra (például hang- és videofájlokra) hivatkozik, amelyeket a meghívott felhasználó egy adott munkamenet elfogadása előtt cserél le. Ha korai médiafolyamat van, az SBC-nek az első végponthoz kell csatlakoznia, amely elindítja a streamelési adathordozót; a médiafolyamat elindulhat a jelöltek jelölése előtt. Az SBC-nek támogatnia kell a DTMF küldését ebben a fázisban az IVR/hangposta forgatókönyvek engedélyezéséhez. Az SBC-nek azt a legmagasabb prioritású útvonalat kell használnia, amelyen ellenőrzést kapott, ha a jelölések nem fejeződtek be.
Következő lépések
A következő dokumentumok lehetnek érdekesek Önnek: