Hívási folyamat topológiái

Ez a cikk az Azure Communication Services hívási folyamat topológiáit ismerteti. Ebben a cikkben az Azure Communication Services hálózati fogalmaival, a forgalom titkosításának módjával, valamint a Communication Services hívási folyamatainak ismertetésével ismerkedhet meg a hívási folyamatok elméleti dokumentációjában.

Háttér

Hálózati fogalmak

A hívási folyamat topológiáinak áttekintése előtt meghatározunk néhány kifejezést, amelyekre a dokumentumban hivatkozunk.

Az ügyfélhálózatok az Ön által kezelt hálózati szegmenseket tartalmazzák. Ez magában foglalhat vezetékes és vezeték nélküli hálózatokat az irodán belül, illetve irodák, adatközpontok és internetszolgáltatók között.

Az ügyfélhálózatok általában több olyan tűzfallal és/vagy proxykiszolgálóval rendelkező hálózati szegélyrel vannak elzárva, amelyek a szervezet biztonsági szabályzatait kényszerítik ki. Javasoljuk, hogy végezzen átfogó hálózati értékelést a kommunikációs megoldás optimális teljesítményének és minőségének biztosítása érdekében.

A Communication Services-hálózat az Azure Communication Servicest támogató hálózat. Ezt a hálózatot a Microsoft felügyeli, és világszerte terjesztik a Végfelhasználókhoz legközelebbi Microsoft-tulajdonú adatközpontokkal. Ez a hálózat felelős a továbbításért, a csoportos hívások médiafeldolgozásáért és más olyan összetevőkért, amelyek támogatják a gazdag valós idejű médiakommunikációt.

Forgalomtípusok

A Communication Services elsősorban kétféle forgalomra épül: valós idejű média - és jelátvitelre.

A rendszer valós idejű adathordozót továbbít a valós idejű átviteli protokoll (RTP) használatával. Ez a protokoll támogatja a hang-, video- és képernyőmegosztási adatátvitelt. Ezek az adatok érzékenyek a hálózati késéssel kapcsolatos problémákra. Bár a valós idejű adathordozók TCP vagy HTTP használatával is továbbíthatók, javasoljuk, hogy az UDP-t használja átviteli réteg protokollként a nagy teljesítményű végfelhasználói élmény támogatásához. Az RTP-en keresztül továbbított adathordozó-hasznos adatok SRTP használatával vannak biztosítva.

A Communication Services-megoldás felhasználói ügyféleszközeikről csatlakoznak a szolgáltatásaihoz. Az eszközök és a kiszolgálók közötti kommunikációt jelzőrendszer kezeli. Például: a hívásindítást és a valós idejű csevegést az eszközök és a szolgáltatás közötti jelzés támogatja. A legtöbb jelzőforgalom HTTPS REST-et használ, de bizonyos esetekben a SIP jelző forgalmi protokollként is használható. Bár az ilyen típusú forgalom kevésbé érzékeny a késésre, az alacsony késleltetésű jelzés kellemes végfelhasználói élményt nyújt a megoldás felhasználóinak.

Médiatitkosítás

Az Azure Communication Services SDK-t és Teams-ügyfeleket hívó hívási folyamatai a munkamenet-leírási protokoll (SDP) RFC 8866 ajánlati és válaszmodelljén alapulnak HTTPS-en keresztül. Miután a hívó elfogadta a bejövő hívást, a hívó és a hívó elfogadja a munkamenet paramétereit.

A médiaforgalom titkosítva van, és a hívó és a hívó között áramlik a Biztonságos RTP (SRTP) használatával, amely a valós idejű átviteli protokoll (RTP) profilja, amely bizalmassági, hitelesítési és visszajátszási támadásvédelmet biztosít az RTP-forgalom számára. A legtöbb esetben az ügyfél és az ügyfél közötti médiaforgalom egyeztetése az ügyfél és a kiszolgáló közötti kapcsolat jelzésével történik, és az SRTP használatával van titkosítva, amikor közvetlenül az ügyfélről az ügyfélre halad.

Az SDK-t hívó Azure Communication Services DTLS használatával hoz létre titkosítási kulcsot. A DTLS kézfogásának befejezése után az adathordozó ezzel a DTLS-tárgyalásos titkosítási kulccsal kezd áramlani az SRTP-n keresztül.

Az SDK-t és a Teams-ügyfeleket hívó Azure Communication Services hitelesítő adatokon alapuló jogkivonatot használ a média továbbítóihoz való biztonságos hozzáféréshez a TURN-en keresztül. A média továbbítók egy TLS által védett csatornán cserélik le a jogkivonatot.

Az Azure Communication Services médiaforgalma az Azure Communication Services hang-, video- és videomegosztásban részt vevő két végpontja között SRTP használatával titkosítja a médiastreamet. A titkosítási kulcsok egyeztetése a két végpont között egy jelátviteli protokollon keresztül történik, amely ALS 1.2 és AES-256 (GCM módban) titkosított UDP/TCP-csatornát használ.

Hívási folyamatok alapelvei

Az Azure Communication Services hívási folyamatait négy általános alapelv támasztja alá:

• A Communication Services-csoporthívás első résztvevője határozza meg azt a régiót, amelyben a hívás fut. Néhány topológiában kivételek vannak a szabály alól, amelyeket az alábbiakban ismertetünk.
• A Communication Services-hívások támogatására használt médiavégpont a médiafeldolgozási igények alapján van kiválasztva, és nem befolyásolja a hívás résztvevőinek száma. Egy pont–pont hívás például egy médiavégpontot használhat a felhőben az adathordozó átírásához vagy rögzítéséhez, míg a két résztvevővel folytatott hívás nem használhat médiavégpontokat. A csoportos hívások médiavégpontot használnak keverési és útválasztási célokra. Ez a végpont a hívás üzemeltetett régiója alapján van kiválasztva. Az ügyféltől a médiavégpontra küldött médiaforgalom közvetlenül irányítható, vagy az Azure-ban átviteli továbbítót is használhat, ha az ügyfél hálózati tűzfalának korlátozásai megkövetelik.
• A társközi hívások médiaforgalma a lehető legközvethetőbb útvonalat használja, feltéve, hogy a híváshoz nincs szükség médiavégpontra a felhőben. Az előnyben részesített útvonal közvetlen a távoli társhoz (ügyfélhez). Ha nem érhető el közvetlen útvonal, egy vagy több átviteli továbbító továbbítja a forgalmat. A médiaforgalomnak nem szabad olyan keresztirányú kiszolgálókat használnia, amelyek csomagformálókként, VPN-kiszolgálókként vagy más olyan függvényként működnek, amelyek késleltethetik a feldolgozást, és ronthatják a végfelhasználói élményt.
• A jelzőforgalom mindig a felhasználóhoz legközelebbi kiszolgálóra kerül.

A kiválasztott médiaútvonal részleteiről a hívási folyamatok fogalmi dokumentációjában olvashat bővebben.

Folyamatok hívása különböző topológiákban

Kommunikációs szolgáltatások (internet)

Ezt a topológiát azok az ügyfelek használják, akik a felhőből, helyszíni üzembe helyezés nélkül használják a Kommunikációs szolgáltatásokat, például az Azure közvetlen útválasztását. Ebben a topológiában a Communication Services felé irányuló és onnan érkező forgalom az interneten keresztül áramlik.

1. ábra – Communication Services-topológia

A fenti ábrán látható nyilak iránya a vállalati peremhálózatokon a kapcsolatot befolyásoló kommunikáció kezdeményezési irányát tükrözi. Adathordozó UDP esetén előfordulhat, hogy az első csomagok fordított irányban haladnak, de ezek a csomagok blokkolva lehetnek, amíg a másik irányban lévő csomagok nem áramlanak.

Folyamatleírások:

• 2. folyamat – Azt a folyamatot jelöli, amelyet egy felhasználó kezdeményezett az ügyfélhálózaton az internet felé a felhasználó Kommunikációs szolgáltatások felületének részeként. Ilyen folyamatok például a DNS és a társközi médiaátvitel.
• Flow 2' – Egy távoli mobil kommunikációs szolgáltatás felhasználója által kezdeményezett folyamatot jelöl, vpn-sel az ügyfélhálózat felé.
• 3. folyamat – Egy távoli mobilkommunikációs szolgáltatás felhasználója által a Communication Services-végpontok felé indított folyamatot jelöli.
• 4. folyamat – Azt a folyamatot jelöli, amelyet egy felhasználó kezdeményezett az ügyfélhálózaton a Communication Services felé.
• 5. folyamat – Egy társközi médiafolyamatot jelöl az egyik Kommunikációs szolgáltatás felhasználója és egy másik, az ügyfélhálózaton belüli között.
• 6. folyamat – Társközi médiafolyamatot jelöl egy távoli mobilkommunikációs szolgáltatás felhasználója és egy másik távoli mobilkommunikációs szolgáltatás felhasználója között az interneten keresztül.

Használati eset: Egy az egyhez hívás

Az egy-az-egyhez hívás azt jelenti, hogy az egyik felhasználó közvetlenül meghív egy másik felhasználót. A hívás inicializálásához a hívó SDK ip-címekből és portokból álló jelöltkészletet szerez be, beleértve a helyi, a továbbító és a reflexív (az ügyfél nyilvános IP-címét a továbbító által látott módon). A hívó SDK elküldi ezeket a jelölteket a hívott félnek; a meghívott fél szintén hasonló jelölteket szerez be, és elküldi őket a hívónak. A STUN kapcsolatellenőrzési üzenetei segítségével megtalálhatja, hogy melyik hívó/hívott fél médiaútvonala működik, és a legjobb munkaútvonal van kiválasztva. A kapcsolati útvonal létrehozása után a rendszer DTLS-kézfogást hajt végre ezen a kapcsolaton keresztül a biztonság érdekében. A DTLS kézfogás után az SRTP-kulcsok a DTLS kézfogási folyamatából származnak. Az adathordozókat (azaz az SRTP-vel védett RTP/RTCP-csomagokat) a rendszer a kiválasztott jelölt pár használatával küldi el. Az átviteli továbbító az Azure Communication Services részeként érhető el.

Ha a helyi IP-cím és a portjelöltek vagy a reflexív jelöltek kapcsolattal rendelkeznek, akkor az ügyfelek (vagy nat használatával) közötti közvetlen elérési út lesz kiválasztva a média számára. Ha az ügyfelek az ügyfélhálózaton vannak, akkor a közvetlen elérési utat kell kijelölni. Ehhez közvetlen UDP-kapcsolat szükséges az ügyfélhálózaton belül. Ha az ügyfelek egyszerre nomád felhőfelhasználók, akkor a NAT-tól/tűzfaltól függően az adathordozók közvetlen kapcsolatot használhatnak.

Ha egy ügyfél belső az ügyfélhálózaton, és egy ügyfél külső (például mobilfelhő-felhasználó), akkor nem valószínű, hogy a helyi vagy reflexív jelöltek közötti közvetlen kapcsolat engedélyezve lenne. Ebben az esetben az egyik átviteli továbbítójelöltet bármelyik ügyféltől használhatja (például a belső ügyfél lekért egy reléjelöltet az Azure-beli átviteli továbbítóból; a külső ügyfélnek képesnek kell lennie STUN/RTP/RTCP-csomagokat küldeni az átviteli továbbítónak). Egy másik lehetőség az, hogy a belső ügyfél elküldi a mobilfelhő-ügyfél által beszerzett továbbítójelöltnek. Bár erősen ajánlott az UDP-kapcsolat médiatartalmakhoz, a TCP támogatott.

Magas szintű lépések:

1. A Communication Services A felhasználója feloldja az URL-tartománynevet (DNS) a Flow 2 használatával.
2. Az A felhasználó a Flow 4 használatával lefoglal egy adathordozó-továbbítási portot a Teams átviteli továbbítóján.
3. A Communication Services A felhasználója egy "meghívást" küld ICE-jelöltekkel a Flow 4 használatával a Communication Servicesnek.
4. A Communication Services értesíti a B felhasználót a Flow 4 használatával.
5. A B felhasználó a Flow 4 használatával lefoglal egy adathordozó-továbbítási portot a Teams átviteli továbbítóján.
6. A "B" felhasználó a Flow 4 használatával küld "választ" ICE-jelöltekkel, amelyet a Rendszer a Flow 4 használatával továbbít vissza az A felhasználónak.
7. Az A felhasználó és a B felhasználó ice-kapcsolati teszteket hív meg, és a legjobban elérhető médiaútvonal van kiválasztva (a különböző használati esetekhez lásd az alábbi diagramokat).
8. Mindkét felhasználó telemetriát küld a Communication Servicesnek a Flow 4 használatával.

Ügyfélhálózat (intranet)

2. ábra – Az ügyfélhálózaton belül

A 7. lépésben ki van jelölve a társközi médiafolyamat 5. lépése.

Ez a médiaátvitel kétirányú. A Flow 5 iránya azt jelzi, hogy az egyik oldal kapcsolati szempontból kezdeményezi a kommunikációt. Ebben az esetben nem számít, hogy melyik irányt használja a rendszer, mert mindkét végpont az ügyfélhálózaton belül található.

Ügyfélhálózat külső felhasználónak (a Teams Transport Relay által továbbított adathordozó)

3. ábra – Ügyfélhálózat külső felhasználónak (az Azure Transport Relay által továbbított adathordozó)

A 7. lépésben a Flow 4 (az ügyfélhálózattól a Communication Servicesig) és a Flow 3 (távoli mobilkommunikációs szolgáltatások felhasználójától az Azure Communication Servicesig) van kiválasztva.

Ezeket a folyamatokat a Teams Transport Relay továbbítja az Azure-ban.

Ez a médiaátvitel kétirányú. Az irány azt jelzi, hogy melyik oldal kezdeményezi a kommunikációt kapcsolati szempontból. Ebben az esetben ezeket a folyamatokat a rendszer különböző átviteli protokollok és címek használatával jelzi és közvetíti.

Ügyfélhálózat külső felhasználónak (közvetlen adathordozó)

4. ábra – Ügyfélhálózat külső felhasználó felé (közvetlen adathordozó)

A 7. lépésben a Flow 2 (az ügyfél hálózatától az ügyfél társához az interneten keresztül) van kiválasztva.

A közvetlen adathordozó távoli mobilfelhasználóval (az Azure-on keresztül nem továbbítva) nem kötelező. Más szóval letilthatja ezt az útvonalat, hogy egy médiaelérési utat kényszerítsen egy átviteli továbbítón keresztül az Azure-ban.

Ez a médiaátvitel kétirányú. A Flow 2 és a távoli mobilfelhasználó közötti irány azt jelzi, hogy az egyik fél kapcsolati szempontból kezdeményezi a kommunikációt.

VPN-felhasználó belső felhasználónak (a Teams Transport Relay által továbbított adathordozó)

5. ábra – VPN-felhasználó belső felhasználónak (az Azure Relay által továbbított adathordozó

A VPN és az ügyfélhálózat közötti jelzés a Flow 2*-t használja. Az ügyfélhálózat és az Azure közötti jelzés a Flow 4-et használja. A média azonban áthalad a VPN-en, és a 3. és a 4. folyamatokkal irányítja át az Azure Media Relay-en keresztül.

VPN-felhasználó–belső felhasználó (közvetlen média)

6. ábra – VPN-felhasználótól belső felhasználóig (közvetlen adathordozó)

A VPN és az ügyfélhálózat közötti jelzés a Flow 2-t használja. Az ügyfélhálózat és az Azure közötti jelzés a 4. folyamatot használja. A média azonban áthalad a VPN-en, és a 2. folyamattal irányítja át az ügyfélhálózatról az internetre.

Ez a médiaátvitel kétirányú. A Flow 2 távoli mobilfelhasználó felé irányuló iránya azt jelzi, hogy az egyik oldal kapcsolati szempontból kezdeményezi a kommunikációt.

VPN-felhasználó külső felhasználónak (közvetlen média)

7. ábra – VPN-felhasználó külső felhasználónak (közvetlen adathordozó)

A VPN-felhasználó és az ügyfélhálózat közötti jelzés a Flow 2* és a Flow 4 és az Azure között működik. A média azonban áthalad a VPN-en, és a Flow 6-tal van irányítva.

Ez a médiaátvitel kétirányú. A Flow 6 távoli mobilfelhasználó felé irányuló iránya azt jelzi, hogy az egyik oldal kapcsolati szempontból kezdeményezi a kommunikációt.

Használati eset: Communication Services-ügyfél a PSTN-hez a Communication Services-csomagtartón keresztül

A Kommunikációs szolgáltatások lehetővé teszik a hívások indítását és fogadását a nyilvános telefonhálózatról (PSTN). Ha a PSTN-csomagtartó a Communication Services által megadott telefonszámokkal van csatlakoztatva, a használati esethez nincsenek különleges csatlakozási követelmények. Ha saját helyszíni PSTN-csomagtartót szeretne csatlakoztatni az Azure Communication Serviceshez, használhatja a közvetlen Azure-útválasztást (amely a CY2021-ben érhető el).

8. ábra – Kommunikációs szolgáltatások felhasználója a PSTN-hez az Azure Trunkon keresztül

Ebben az esetben az ügyfélhálózatról az Azure-ba történő jelzés és adathordozó a Flow 4-et használja.

Használati eset: Communication Services-csoporthívások

A hang-/video-/képernyőmegosztási (VBSS) szolgáltatás az Azure Communication Services része. Nyilvános IP-címmel rendelkezik, amelynek elérhetőnek kell lennie az ügyfélhálózatról, és elérhetőnek kell lennie egy nomád felhőügyfélről. Minden ügyfélnek/végpontnak csatlakoznia kell a szolgáltatáshoz.

A belső ügyfelek a helyi, a reflexív és a továbbítási jelölteket ugyanúgy szerzik be, mint az egy-az-egyhez hívások esetében. Az ügyfelek egy meghívásban elküldik ezeket a jelölteket a szolgáltatásnak. A szolgáltatás nem használ továbbítót, mivel nyilvánosan elérhető IP-címmel rendelkezik, ezért a helyi IP-címjelölttel válaszol. Az ügyfél és a szolgáltatás ugyanúgy ellenőrzi a kapcsolatot, mint az egy-az-egyhez hívások esetében.

9. ábra – Kommunikációs szolgáltatások csoportos hívásai

Együttműködési korlátozások

Az Azure Communication Servicesen keresztül áramló médiatartalmak az alábbiak szerint korlátozottak:

A PSTN-vel határolt külső munkamenet-szegélyvezérlőnek (SBC) le kell mondania az RTP/RTCP streamet, SRTP-vel kell védenie, és nem kell továbbítania a következő ugráshoz. Ha a folyamatot a következő ugrásra továbbítja, lehet, hogy nem érti.

Külső SIP-proxykiszolgálók. A Kommunikációs szolgáltatások egy harmadik féltől származó SBC-vel és/vagy átjáróval rendelkező SIP-párbeszédablak a Microsoft natív SIP-proxyira (a Teamshez hasonlóan) is áthaladhat. A külső SIP-proxykkal való együttműködés nem támogatott.

Külső B2BUA (vagy SBC). A Communication Services psTN-be irányuló és onnan érkező médiafolyamát egy külső SBC leállítja. A Kommunikációs szolgáltatások hálózaton belüli külső SBC-vel való együttműködés (ahol egy harmadik féltől származó SBC két Communication Services-végpontot közvetít) nem támogatott.

Nem támogatott technológiák

VPN-hálózat. A Communication Services nem támogatja a VPN-en keresztüli médiaátvitelt. Ha a felhasználók VPN-ügyfeleket használnak, az ügyfélnek fel kell osztania és át kell irányítania a médiaforgalmat egy nem VPN-kapcsolaton keresztül, a Lync médiatartalmainak vpn-alagút megkerüléséhez való engedélyezésével.

Feljegyzés

Bár a cím a Lyncet jelöli, az Azure Communication Servicesre és a Teamsre is alkalmazható.*

Csomagalakítók. A csomagmetszet, csomagvizsgálat vagy csomagformázási eszközök nem támogatottak, és jelentősen csökkenthetik a minőséget.

Következő lépések

Ismerkedés a hívással

A következő dokumentumok lehetnek érdekesek Önnek:

• További információ a hívástípusokról
• Tudnivalók az ügyfél-kiszolgáló architektúrájáról