A környezet előkészítése

Döntési pontok

megfontolás Megválaszolt kérdések Erőforrások

Építészet és infrastruktúra

Hány XSP?

Hogyan veszik mTLS?

Cisco BroadWorks rendszer kapacitástervező

Cisco BroadWorks rendszermérnöki útmutató

XSP CLI referencia

Ez a dokumentum

Ügyfél- és felhasználókiépítés

Tudja állítani, hogy bízik az e-mailekben a BroadWorks-ben?

Szeretné, ha a felhasználók e-mail címeket adna meg saját fiókjaik aktiválásához?

Tud építeni eszközöket használni api?

Nyilvános API dokumentumok a https://developer.webex.com

Ez a dokumentum

Védjegyzés Milyen színt és logót szeretne használni? Webex alkalmazás márkajelzési cikk
Sablonok Melyek a különböző ügyfélhasználati esetek? Ez a dokumentum
Előfizetői funkciók ügyfélenként/vállalkozásonként/csoportonként Válassza ki a csomagot a szolgáltatás szintjének sablononkénti meghatározásához. Alap, Standard, Premium vagy Softphone.

Ez a dokumentum

Funkció/csomag mátrix

Felhasználói hitelesítés BroadWorks vagy Webex Ez a dokumentum
Kiépítési adapter (átfolyásos kiépítési lehetőségekhez)

Használ már integrált IM&P-t, például az UC-One SaaS-t?

Több sablont kíván használni?

Várható-e gyakoribb használati eset?

Ez a dokumentum

Application Server CLI hivatkozás

Építészet és infrastruktúra

  • Milyen léptékkel szeretné kezdeni? A jövőben lehetőség van a skálázásra, de a jelenlegi használati becslésnek kell vezetnie az infrastruktúra tervezését.

  • Működjön együtt a Cisco account manager / értékesítési képviselő méret az XSP infrastruktúra szerint a Cisco BroadWorks System Capacity Planner ( ) és a Ciscohttps://xchange.broadsoft.com/node/1051462BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/1051496).

  • Hogyan lesz a Cisco Webex kölcsönös TLS-kapcsolat az XSP-ekkel? Közvetlenül az XSP-hez egy DMZ-ben vagy TLS proxyn keresztül? Ez hatással van a tanúsítványkezelésre és az interfészekhez használt URL-címekre. (Nem támogatjuk a titkosítatlan TCP-kapcsolatokat a hálózat széléhez).

Ügyfél- és felhasználókiépítés

Melyik felhasználói kiépítési módszer felel meg Önnek a legjobban?

  • Flowthrough kiépítés megbízhatóe-mailekkel: Az "Integrált IM&P" szolgáltatás BroadWorks-en történő hozzárendelésével az előfizető automatikusan a Cisco Webex szolgáltatásba kerül.

    Ha azt is állíthatja, hogy a BroadWorks előfizetői e-mail címei érvényesek és egyediek a Webex számára, akkor használhatja a flowthrough kiépítés "megbízható e-mail" változatát. Az előfizetői Webex-fiókok a beavatkozásuk nélkül jönnek létre és aktiválódnak; egyszerűen letöltik az ügyfelet és bejelentkeznek.

    Az e-mail cím a Cisco Webex egyik legfontosabb felhasználói attribútuma. Ezért a Szolgáltatónak érvényes e-mail címet kell megadnia a felhasználó számára a Cisco Webex szolgáltatások nyújtásához. Ennek a broadworks-ben a felhasználó e-mail-azonosító attribútumában kell lennie. Javasoljuk, hogy másolja be az Alternatív azonosító attribútumba is.

  • Flowthrough kiépítés megbízható e-mailek nélkül: Ha nem bízhat az előfizetői e-mail címekben, továbbra is hozzárendelheti a BroadWorks integrált IM&P szolgáltatását a felhasználók webex szolgáltatásához.

    Ezzel a lehetőséggel a fiókok a szolgáltatás hozzárendelésekor jönnek létre, de az előfizetőknek meg kell adniuk és érvényesíteniük kell e-mail címüket a Webex-fiókok aktiválásához.

  • Felhasználói önkiépítés: Ez a beállítás nem igényel IM&P szolgáltatáskiosztást a BroadWorksben. Ön (vagy ügyfelei) inkább egy kiépítési linket terjesztenek, és a különböző ügyfelek letöltésére mutató linkeket a márkajelzéssel és az utasításokkal.

    Az előfizetők követik a linket, majd meg kell adniuk és érvényesíteniük e-mail címüket Webex-fiókjuk létrehozásához és aktiválásához. Ezután letöltik az ügyfelet és bejelentkeznek, és a Webex további konfigurációt hoz róluk a BroadWorks-ből (beleértve az elsődleges számokat is).

  • SP-vezérlésű kiépítés API-kon keresztül: A Cisco Webex nyilvános API-k egy sorát teszi közzé, amelyek lehetővé teszik a szolgáltatók számára, hogy felhasználói/előfizetői kiépítést építsenek ki meglévő munkafolyamataikba.

Ügyfélsablonok

Az ügyfélsablonok lehetővé teszik, hogy meghatározza azokat a paramétereket, amelyekkel az ügyfelek és a kapcsolódó előfizetők automatikusan a Cisco Webex for BroadWorks szolgáltatásra kerülnek. Szükség szerint több ügyfélsablont is konfigurálhat, de ha egy ügyfél fedélzetén tartózkodik, az csak egy sablonhoz kapcsolódik (nem alkalmazhat több sablont egy ügyfélre).

Az elsődleges sablonparaméterek közül néhány az alábbiakban található.

Csomag

  • Sablon létrehozásakor ki kell választania egy alapértelmezett csomagot (a részletekért lásd a Csomagok az Áttekintés részben). Minden felhasználó, aki rendelkezik ezzel a sablonnal, akár átfolyással, akár önkitáadással, megkapja az alapértelmezett csomagot.

  • A különböző ügyfelek számára a csomagválasztást több sablon létrehozásával és az egyes alapértelmezett csomagok kiválasztásával szabályozhatja. Ezután különböző kiépítési hivatkozásokat vagy vállalatonként eltérő kiépítési adaptereket terjeszthet, attól függően, hogy az ön által választott felhasználói kiépítési módszert választotta-e ezekhez a sablonokhoz.

  • Az adott előfizetők csomagját ebből az alapértelmezettből módosíthatja a kiépítési API használatával (lásd a Webex-szel való integráció a BroadWorks kiépítési API-jával a Hivatkozás részben) vagy a Partner Hubon keresztül.

  • Nem módosíthatja az előfizető csomagját a BroadWorks-től. Az integrált IM&P szolgáltatás hozzárendelése be- vagy kikapcsolt; ha az előfizető ezt a szolgáltatást a BroadWorks-ben rendeli meg, az adott előfizető vállalkozásának kiépítési URL-jéhez társított Partner Hub sablon határozza meg a csomagot.

Viszonteladó és vállalkozások vagy Szolgáltató és csoportok?

  • A BroadWorks rendszer konfigurálásának módja hatással van a kiépítésen keresztüli áramlásra. Ha Ön viszonteladó a Vállalatokkal, akkor sablon létrehozásakor engedélyeznie kell az Enterprise módot.
  • Ha a BroadWorks rendszere Szolgáltató módban van konfigurálva, akkor az Enterprise módot kikapcsolhatja a sablonokban.
  • Ha mindkét BroadWorks mód használatával ügyfélszervezeteket szeretne kivenni, különböző sablonokat kell használnia csoportokhoz és vállalkozásokhoz.

Hitelesítő mód

Hogyan hitelesítik az ügyfelek előfizetőit?

Hitelesítő mód BroadWorks Webex
Elsődleges felhasználói azonosító BroadWorks felhasználói azonosító E-mail-cím
Személyazonosság-szolgáltató

BroadWorks.

A hitelesítést a Cisco Webex által üzemeltetett közvetítő szolgáltatás segíti elő.

Cisco közös identitás
Többtényezős hitelesítés? Nem A többtényezős hitelesítést támogató ügyfélazonosítót igényel.

Hitelesítő adatok hitelesítésének elérési útja

  1. Böngésző indul, ahol a felhasználó e-mailt küld a kezdeti bejelentkezési folyamathoz, és felfedezi a hitelesítési módot.

  2. Böngésző ezután átirányítja a Cisco Webex üzemeltetett BroadWorks bejelentkezési oldal (Ez az oldal márkás)

  3. A felhasználó a bejelentkezési oldalon biztosítja a BroadWorks felhasználói azonosítóját és jelszavát.

  4. A felhasználói hitelesítő adatok érvényesítése a BroadWorks ellenében.

  5. A siker érdekében a Cisco Webex-től kap egy engedélyezési kódot. Ezt a Cisco Webex-szolgáltatásokhoz szükséges hozzáférési tokenek megszerzésére használják.

  1. Böngésző indul, ahol a felhasználó e-mailt küld a kezdeti bejelentkezési folyamathoz, és felfedezi a hitelesítési módot.

  2. A böngésző átirányítja az IdP-re (vagy Cisco Common Identity vagy Customer IdP), ahol bejelentkezési portállal jelennek meg.

  3. A felhasználó megfelelő hitelesítő adatokat ad meg a bejelentkezési oldalon

  4. Többtényezős hitelesítésre akkor kerülhet sor, ha az ügyfélazonosító ezt támogatja.

  5. A siker érdekében a Cisco Webex-től kap egy engedélyezési kódot. Ezt a Cisco Webex-szolgáltatásokhoz szükséges hozzáférési tokenek megszerzésére használják.

Több partneri megállapodás

A Webex-et a BroadWorks számára egy másik szolgáltatónak fogja licencbe adni? Ebben az esetben minden szolgáltatónak külön partnerszervezetre lesz szüksége a Webex Control Hubban, hogy lehetővé tegye számukra a megoldás biztosítását az ügyfélkörük számára.

Adapter és sablonok kiépítése

A flowthrough kiépítés használatakor a BroadWorks-ben megadott kiépítési URL a Control Hub sablonjából származik. Több sablonja is lehet, ezért több URL-t is ki lehet létesíteni. Ez lehetővé teszi, hogy vállalkozási alapon kiválassza, hogy melyik csomag vonatkozik az előfizetőkre, amikor megkapják az integrált IM&P szolgáltatást.

Meg kell fontolnia, hogy alapértelmezett kiépítési útvonalként rendszerszintű kiépítési URL-címet szeretne-e beállítani, és hogy ehhez melyik sablont szeretné használni. Ily módon csak kifejezetten meg kell állítania a kiépítési URL-t azoknak a vállalkozásoknak, amelyeknek más sablonra van szükségük.

Ne feledje továbbá, hogy előfordulhat, hogy már használ rendszerszintű kiépítési URL-t, például az UC-One SaaS-szal. Ebben az esetben dönthet úgy, hogy megőrzi a rendszerszintű URL-t a felhasználók UC-One SaaS-ra való kiépítéséhez, és felülbírálja azokat a vállalkozásokat, amelyek a BroadWorks Webex-re költöznek. Alternatív megoldásként érdemes lehet a másik irányba menni, és beállítani a Webex rendszerszintű URL-címét a BroadWorks számára, és újrakonfigurálni azokat a vállalkozásokat, amelyeket meg szeretne tartani az UC-One SaaS-en.

A döntéssel kapcsolatos konfigurációs lehetőségeket a Configure Application Server with Provisioning Service URL-ben, a Webex telepítése a BroadWorks-hez szakaszban részletezi.

Minimumkövetelmények

Fiókok

A Webexre kihelyezt összes előfizetőnek léteznie kell a BroadWorks rendszerében, amelyet a Webex-szel integrál. Szükség esetén több BroadWorks rendszert is integrálhat.

Minden előfizetőnek rendelkeznie kell BroadWorks licenccel és elsődleges számokkal.

A Webex minden felhasználó számára elsődleges azonosítóként használja az e-mail címeket. Ha megbízható e-mailekkel rendelkező flowthrough-kiépítést használ, akkor a felhasználóknak érvényes címekkel kell rendelkezniük a BroadWorks e-mail attribútumában.

Ha a sablon BroadWorks-hitelesítést használ, az előfizetői e-mail-címeket átmásolhatja a BroadWorks Alternatív azonosító attribútumába. Ez lehetővé teszi a felhasználók számára, hogy e-mail címükkel és BroadWorks jelszavaikkal jelentkezzenek be a Webexre.

Az adminisztrátoroknak Webex-fiókjukkal kell bejelentkezniük a Partner Hubba.

Szerverek az Ön hálózati és szoftverkövetelményeiben

  • BroadWorks példány(ok) minimális R21 SP1 verzióval. A támogatott verziókról és javításokról lásd a BroadWorks szoftverkövetelményeit (ebben a dokumentumban). Lásd még: Életciklus-kezelés - BroadSoft szerverek.


    Az R21 SP1 csak 2021 közepéig támogatott. Annak ellenére, hogy jelenleg integrálhatja a Webex-et az R21 SP1-gyel, erősen ajánljuk az R22-t vagy később a Webex-szel való integrációhoz.

  • A BroadWorks-példány(ok)nak legalább a következő kiszolgálókat kell tartalmazniuk:

    • Application Server (AS) a BroadWorks verzióval a fentiek szerint

    • Hálózati kiszolgáló (NS)

    • Profilkiszolgáló (PS)

  • Nyilvános XSP server(ek) vagy alkalmazás-kézbesítési platform (ADP), amely megfelel az alábbi követelményeknek:

    • Hitelesítési szolgáltatás (BWAuth)

    • XSI műveletek és események interfészek

    • DMS (eszközkezelő webalkalmazás)

    • CTI interfész (Számítógépes telefónia intergráció)

    • TLS 1.2 érvényes tanúsítvánnyal (nem saját kvalitát) és szükséges intermedierekkel. A vállalati keressük megkönnyítéséhez rendszerszintű rendszergazdára van szükség.

    • Kölcsönös TLS (mTLS) hitelesítés hitelesítési szolgáltatáshoz (megköveteli a nyilvános Cisco Webex ügyféltanúsítvány-láncot, amely bizalmi horgonyként van telepítve)

    • Kölcsönös TLS (mTLS) hitelesítés CTI interfészhez (Megköveteli a nyilvános Cisco Webex ügyféltanúsítvány láncot, amely bizalmi horgonyként van telepítve)

  • Egy külön XSP/ADP szerver, amely "Call Notifications Push Server" (az Ön környezetében lévő NPS, amely hívásértesítéseket küld az Apple/Google-nak. Itt "CNPS"-nek hívjuk, hogy megkülönböztessük a Webex szolgáltatásától, amely push értesítéseket küld az üzenetküldéshez és a jelenléthez).

    Ennek a kiszolgálónak R22-n vagy később kell lennie.

  • Külön XSP/ADP szervert rendelünk a CNPS-hez, mert a Webex terhelésének kiszámíthatatlansága a BWKS felhőkapcsolatokhoz negatívan befolyásolhatja az NPS szerver teljesítményét, ami az értesítési késleltetés növekedésének eredménye. Lásd a Cisco BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/422649) többet XSP skálán.

Fizikai telefonok és tartozékok

Eszközprofilok

Ezek azok a DTAF-fájlok, amelyeket be kell betöltenie az alkalmazáskiszolgálókra, hogy támogassa a Webex-alkalmazásokat, mint hívó ügyfeleket. Ezek ugyanazok a DTAF fájlok, mint az UC-One SaaS esetében, azonban van egy új config-wxt.xml.template a Webex-alkalmazásokhoz használt fájl.

Ügyfél neve

Eszközprofil típusa és csomagneve

Webex mobil sablon

https://xchange.broadsoft.com/support/uc-one/connect/software

Azonosító/eszközprofil típusa: Csatlakozás - Mobil

DTAF: ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Konfigurációs fájl: config-wxt.xml

Webex táblagép sablon

https://xchange.broadsoft.com/support/uc-one/connect/software

Azonosító/eszközprofil típusa: Csatlakozás - Táblagép

DTAF: ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Konfigurációs fájl: config-wxt.xml

Webex asztali sablon

https://xchange.broadsoft.com/support/uc-one/communicator/software

Azonosító/eszközprofil típusa: Üzleti kommunikátor - PC

DTAF: ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Konfigurációs fájl: config-wxt.xml

Tanúsítványok megrendelése

A TLS-hitelesítés tanúsítványkövetelményei

Minden szükséges kérelemhez szüksége lesz egy jól ismert tanúsítványhatóság által aláírt és a nyilvános XSP-re telepített biztonsági tanúsítványokra. Ezeket arra használjuk, hogy támogassuk a TLS-tanúsítványok ellenőrzését az XSP-kiszolgálókhoz való összes bejövő kapcsolathoz.

Ezeknek a tanúsítványoknak tartalmazniuk kell az XSP nyilvános, teljesen minősített domain nevét Alanyi közös névként vagy tárgy alternatív névként.

A kiszolgálótanúsítványok telepítésének pontos követelményei attól függnek, hogy a nyilvános XSP-k hogyan kerülnek üzembe:

  • TLS áthidaló proxyn keresztül

  • TLS-átmenő proxyn keresztül

  • Közvetlenül az XSP-hez

A következő ábra összefoglalja, hogy a CA által aláírt nyilvános szerver tanúsítványt hol kell betölteni ebben a három esetben:

A Webex alkalmazás által a hitelesítéshez támogatott nyilvánosan támogatott hitelesítések a Cisco Webex Hybrid Services támogatott tanúsítványhatóságai közöttszerepelnek.

TLS tanúsítványkövetelmények A TLS-híd proxyjáért

  • A nyilvánosan aláírt kiszolgálói tanúsítvány betöltődik a proxyba.

  • A proxy bemutatja ezt a nyilvánosan aláírt kiszolgálói tanúsítványt a Webexnek.

  • A Webex megbízik a proxy kiszolgálói tanúsítványát aláíró nyilvános szolgáltatóban.

  • A belső CA által aláírt tanúsítvány betölthető az XSP-re.

  • Az XSP bemutatja ezt a belsőleg aláírt kiszolgálói tanúsítványt a proxynak.

  • A proxy megbízik az XSP-kiszolgáló tanúsítványát aláíró belső szervezeti egyszolgáltatóban.

TLS tanúsítványkövetelmények TLS-passthrough proxyhoz vagy XSP-hez a DMZ-ben

  • A nyilvánosan aláírt kiszolgálótanúsítvány betöltődik az XSP-kbe.

  • Az XSP-k nyilvánosan aláírt kiszolgálói tanúsítványokat mutatnak be a Webexnek.

  • A Webex megbízik az XSP-k kiszolgálói tanúsítványait aláíró nyilvános ca-ben.

A CTI interfészen keresztüli kölcsönös TLS-hitelesítésre vonatkozó további tanúsítványkövetelmények

A CTI interfészhez való csatlakozáskor a Cisco Webex a Mutual TLS hitelesítés részeként ügyféltanúsítványt mutat be. A Webex ügyféltanúsítvány CA/chain tanúsítvány letölthető a Control Hubon keresztül.

A tanúsítvány letöltése:

Jelentkezzen be a Partner Hubba, a Beállítások > a BroadWorks hívása menüpontba, majd kattintson a letöltési tanúsítvány hivatkozásra.

A Webex CA tanúsítványlánc üzembe helyezésének pontos követelményei attól függnek, hogy a nyilvános XSP-ket hogyan telepítik:

  • TLS áthidaló proxyn keresztül

  • TLS-átmenő proxyn keresztül

  • Közvetlenül az XSP-hez

Az alábbi ábra az alábbi három esetben foglalja össze a tanúsítványra vonatkozó követelményeket:

1. ábra. mTLS tanúsítványcsere CTI-re különböző élkonfigurációkon keresztül

(Opció) A TLS-bridge proxy tanúsítványkövetelményei

  • A Webex nyilvánosan aláírt ügyfélbizonyítványt mutat be a meghatalmazottnak.

  • A proxy megbízik a Cisco belső hitelesítésszolgáltatójában, amely aláírta az ügyfélbizonyítványt. Letöltheti ezt a CA / láncot a Control Hub-ból, és hozzáadhatja a proxy bizalmi áruházához. A nyilvánosan aláírt XSP-kiszolgáló tanúsítvány is betöltődik a proxyba.

  • A proxy bemutatja a nyilvánosan aláírt kiszolgálói tanúsítványt a Webexnek.

  • A Webex megbízik a proxy kiszolgálói tanúsítványát aláíró nyilvános szolgáltatóban.

  • A meghatalmazott egy belsőleg aláírt ügyféltanúsítványt mutat be az XSP-knek.

    Ennek a tanúsítványnak rendelkeznie kell az x509.v3 kiterjesztési mező kiterjesztett kulcshasználattal, amely a BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 és a TLS clientAuth céllal van feltöltve. Pl..:

    X509v3 extensions:
        X509v3 Extended Key Usage:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

    A belső tanúsítvány központi idegrendszerét bwcticlient.webex.comkell.


    • A proxy belső ügyféltanúsítványainak létrehozásakor vegye figyelembe, hogy az SAN-tanúsítványok nem támogatottak. Az XSP belső kiszolgálótanúsítványai lehetnek SAN.

    • Előfordulhat, hogy a közokirat-vivő hatóságok nem hajlandók aláírni a tanúsítványokat a szükséges tulajdonosi BroadWorks OID-val. Áthidaló proxy esetén előfordulhat, hogy belső hitelesítésszolgáltatót kell használnia az ügyfél-tanúsítvány aláírására, amelyet a meghatalmazott bemutat az XSP-nek.

  • Az XSP-k bíznak a belső KB-ben.

  • Az XSP-k belsőleg aláírt kiszolgálói tanúsítványt mutatnak be.

  • A meghatalmazott megbízik a belső kbt.-ben.

  • Az Alkalmazáskiszolgáló ügyfélmegfelelősége tartalmazza a meghatalmazott által az XSP-nek bemutatott belső aláírású ügyféltanúsítvány CN-jét.

(Opció) A TLS-passthrough proxyra vagy XSP-re vonatkozó tanúsítványkövetelmények a DMZ-ben

  • A Webex egy Cisco belső CA által aláírt ügyféltanúsítványt mutat be az XSP-knek.

  • Az XSP-k megbíznak a Cisco belső hitelesítésszolgáltatójában, amely aláírta az ügyféltanúsítványt. Letöltheti ezt a CA / láncot a Control Hub-ból, és hozzáadhatja a proxy bizalmi áruházához. A nyilvánosan aláírt XSP szervertanúsítvány is betöltődik az XSP-kbe.

  • Az XSP-k bemutatják a nyilvánosan aláírt kiszolgálói tanúsítványokat a Webexnek.

  • A Webex megbízik az XSP-k kiszolgálói tanúsítványait aláíró nyilvános ca-ben.

  • Az Application Server ClientIdentity tartalmazza a Webex által az XSP-nek bemutatott Cisco által aláírt ügyféltanúsítvány CN-ját.

A hálózat előkészítése

Kapcsolat térképe

Az alábbi ábra az integrációs pontokat szemlélteti. A diagram lényege, hogy megmutassa, hogy felül kell vizsgálnia az IPS-eket és a portokat a környezetbe és a környezetből való csatlakozáshoz. A Webex által a BroadWorks számára használt kapcsolatokat a következő táblázatok ismertetik.

Az ügyfélalkalmazás normál működéséhez szükséges tűzfalkövetelmények hivatkozásként szerepelnek, mivel már help.webex.com dokumentálva vannak.

Tűzfal konfiguráció

A kapcsolattérkép és a következő táblázatok az ügyfelek (az ügyfél hálózatán vagy azon kívül), a hálózat és a Webex platform közötti kapcsolatokat és protokollokat írják le.

Csak a BroadWorks Webexre jellemző kapcsolatait dokumentáljuk. Nem mutatjuk a Webex alkalmazás és a Webex felhő közötti általános kapcsolatokat, amelyeket a következők dokumentálnak:

EMEA behatolási szabályok

(A hálózatba)

Cél Forrás Protokoll Cél Célport

WebexCloud

CTI/Auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

Az Ön XSP

TCP/TLS 8012

443

Webex alkalmazás

Xsi/DMS

bármely

HTTPS

Az Ön XSP

443

Webex alkalmazás VoIP végpontok SIP

bármely

SIP

Az Ön SBC

SP által definiált protokoll és port

TCP/UDP


Erősen ajánlott, hogy a SIP port különbözik az 5060-tól (például 5075), mivel ismert problémák vannak a szabványos SIP port (5060) mobil eszközökkel való használatával.

EMEA Egress szabályok

(Ki a hálózatból)

Cél

Forrás

Protokoll

Cél

Célport

Felhasználói kiépítés API-kon keresztül

Az alkalmazáskiszolgáló

HTTPS

webexapis.com

443

Proxy leküldéses értesítések (termelési szolgáltatás)

Az NPS-kiszolgáló

HTTPS

https://nps.uc-one.broadsoft.com/

VAGY 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex közös identitás

Az NPS-kiszolgáló

HTTPS

https://idbroker-eu.webex.com

443

Webex közös identitás

Auth Szolgáltatás XSP

HTTPS

https://idbroker-eu.webex.com/idb

https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

APNS és FCM szolgáltatások

Az NPS-kiszolgáló

HTTPS

Bármely IP-cím*

443

Proxy leküldéses értesítések (termelési szolgáltatás)

Webex közös identitás

APNS és FCM szolgáltatások

Az NPS-kiszolgáló

HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

Bármely IP-cím*

443

Felhasználói kiépítés a BroadWorks kiépítési adapteren keresztül

Az Ön BroadWorks AS

HTTPS

https://broadworks-kiépítés-híd-*.wbx2.com/

(ahol * lehet bármilyen betű. A pontos kiépítési URL-cím a Partner Hubban létrehozott sablonban érhető el)

443

† Ezek a tartományok tartalmazzák az NPS proxy állomásait, de nem tudjuk megadni a pontos címeket. A tartományok tartalmazhatnak olyan állomásokat is, amelyek nem kapcsolódnak a Webex for BroadWorks-hez. Javasoljuk, hogy konfigurálja a tűzfalat, hogy lehetővé tegye a forgalmat az NPS proxy FQDN helyett annak biztosítása érdekében, hogy a kimenő csak felé házigazdák tesszük ki az NPS proxy.

* Az APNS és az FCM nem rendelkezik rögzített IP-címekkel.

USA behatolási szabályok

(A hálózatba)

Cél

Forrás

Protokoll

Cél

Célport

WebexCloud

CTI/Auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

CTI

Az Ön XSP

TCP/TLS 8012

TLS 443

Webex alkalmazás   

Xsi/DMS

bármely

HTTPS

Az Ön XSP

443

Webex App VoIP végpontok SIP

bármely

SIP

Az Ön SBC

SP által definiált protokoll és port

TCP/UDP


Erősen ajánlott, hogy a SIP port különbözik az 5060-tól (például 5075), mivel ismert problémák vannak a szabványos SIP port (5060) mobil eszközökkel való használatával.

USA Egress szabályok

(Ki a hálózatból)

Cél

Forrás

Protokoll

Cél

Célport

Felhasználói kiépítés API-kon keresztül

Az alkalmazáskiszolgáló

HTTPS

webexapis.com

443

Proxy leküldéses értesítések (termelési szolgáltatás)

Az NPS-kiszolgáló

HTTPS

https://nps.uc-one.broadsoft.com/

VAGY 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex közös identitás

Az NPS-kiszolgáló

HTTPS

https://idbroker.webex.com

https://idbroker-b-us.webex.com

443

Webex közös identitás

Auth Szolgáltatás XSP

HTTPS

https://idbroker.webex.com/idb

https://idbroker-b-us.webex.com/idb

https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

APNS és FCM szolgáltatások

Az NPS-kiszolgáló

HTTPS

Bármely IP-cím*

443

Felhasználói kiépítés bwks kiépítési adapteren keresztül

Az Ön BroadWorks AS

HTTPS

https://broadworks-kiépítés-híd-*.wbx2.com/

(ahol * lehet bármilyen betű. A pontos kiépítési URL-cím a Partner Hubban létrehozott sablonban érhető el)

443

† Ezek a tartományok tartalmazzák az NPS proxy állomásait, de nem tudjuk megadni a pontos címeket. A tartományok tartalmazhatnak olyan állomásokat is, amelyek nem kapcsolódnak a Webex for BroadWorks-hez. Javasoljuk, hogy konfigurálja a tűzfalat, hogy lehetővé tegye a forgalmat az NPS proxy FQDN helyett annak biztosítása érdekében, hogy a kimenő csak felé házigazdák tesszük ki az NPS proxy.

* Az APNS és az FCM nem rendelkezik rögzített IP-címekkel.

A Webex-szolgáltatások hálózati követelményei

Az előző Ingress és Egress rules tűzfaltáblák csak azokat a kapcsolatokat dokumentálják, amelyek a BroadWorks Webexre jellemzőek. A Webex alkalmazás és a Webex felhő közötti kapcsolatokkal kapcsolatos általános információkért lásd: Hálózati követelmények a Webex-szolgáltatásokhoz. Ez a cikk általános a Webex, de a következő táblázat azonosítja a különböző szakaszok a cikk, és mennyire releváns az egyes szakaszok a Webex a BroadWorks.

Táblázat Webex alkalmazáskapcsolatok hálózati követelményei (általános)

A hálózati követelményekről szóló cikk szakasza

Az információ relevanciája

A Webex által támogatott eszköztípusok és protokollok összefoglalása

Információs

Átviteli protokollok és titkosítási titkosítások felhőben regisztrált Webex alkalmazásokhoz és eszközökhöz

Információs

Webex Services – Portszámok és protokollok

El kell olvasni

IP-alhálózatok Webex médiaszolgáltatásokhoz

El kell olvasni

A Webex Services-hez elérhető tartományok és URL-ek

El kell olvasni

További URL-ek a Webex hibrid szolgáltatásaihoz

Opcionális

Proxy funkciók

Opcionális

802.1X – Port alapú hálózati hozzáférés-vezérlés

Opcionális

A SIP alapú Webex szolgáltatások hálózati követelményei

Opcionális

A Webex Edge Audio hálózati követelményei

Opcionális

Egyéb Webex Hybrid szolgáltatások és dokumentációk összefoglalása

Opcionális

Webex szolgáltatások FedRAMP ügyfeleknek

N. A.

További információk

További információ: Webex App Firewall Whitepaper (PDF).

BroadWorks redundancia támogatás

A Cisco Webex Cloud Services és a Partner hálózatához hozzáférő Webex ügyfélalkalmazások teljes mértékben támogatják a partner által biztosított Broadworks XSP redundanciát. Ha egy XSP vagy webhely nem érhető el tervezett karbantartás vagy nem tervezett okból, a Cisco szolgáltatások és alkalmazások képesek előrelépni egy másik XSP-re vagy a partner által biztosított webhelyre a kérés teljesítése érdekében.

hálózati topológia

A Broadworks XSP-k közvetlenül az interneten telepíthetők, vagy egy terheléskiegyenlítő elem, például az F5 BIG-IP által frontolt DMZ-ben tartózkodhatnak. A geo-redundancia biztosítása érdekében az XSP-k két (vagy több) adatközpontban is telepíthetők, mindegyiket egy terheléskiegyenlítő előlapja lehet, mindegyik nyilvános IP-címmel rendelkezik. Ha az XSP-k egy terheléskiegyenlítő mögött vannak, a Webex mikroszolgáltatások és alkalmazások csak a terheléskiegyenlítő IP-címét látják, és úgy tűnik, hogy a Broadworks csak egy XSP-vel rendelkezik, még akkor is, ha több XSP van mögötte.

Az alábbi példában az XSP-k két helyszínen, az A és a B webhelyen vannak telepítve. Minden helyszínen két XSP van, amelyeket egy terheléskiegyenlítő előz meg. Az A webhely XSP1 és XSP2 előlapja LB1, a B webhely pedig XSP3 és XSP4 frontálisan LB2. Csak a terheléskiegyenlítők vannak kitéve a nyilvános hálózaton, és az XSP-k a DMZ magánhálózatokban vannak.

Webex felhőszolgáltatások

DNS konfiguráció

A Webex felhő mikroszolgáltatásoknak képesnek kell lenniük megtalálni a Broadworks XSP szerver(ek)et az Xsi interfészekhez, hitelesítési szolgáltatáshoz és CTI-hez való csatlakozáshoz.

A Cisco Webex Cloud mikroszolgáltatásai DNS A/AAAA keresést végeznek a konfigurált XSP állomásnéven, és csatlakoznak a visszaadott IP-címhez. Ez lehet egy terheléskiegyenlítő élelem, vagy maga az XSP szerver. Ha több IP-címet ad vissza, a lista első IP-címe kerül kiválasztásra. Az SRV-keressünk jelenleg nem támogatott.

Példa: A partner DNS A rekord felfedezése Round-Robin kiegyensúlyozott internet-orientált XSP szerver / Load Balancers

Rekord típusa

Név

Cél

Cél

A

xsp.example.com

198.51.100.48

Pontok LB1-re (A oldal)

A

xsp.example.com

198.51.100.49

Pontok az LB2-re (B oldal)

Feladatátvétel

Amikor a Webex mikroszolgáltatások kérést küldenek az XSP/Load Balancer-nek, és a kérés sikertelen, több dolog is megtörténhet:

  • Ha a hiba hálózati hibára (pl.: TCP, SSL), a Webex mikroszolgáltatások blokkoltként jelölik meg az IP-t, és azonnal végrehajtják az útvonal-előrejutást a következő IP-re.

  • Ha egy hibakód (HTTP 5xx) visszakerül, a Webex mikroszolgáltatások blokkolva jelölik az IP-t, és azonnal végrehajtják az útvonalelőleget a következő IP-re.

  • Ha 2 másodpercen belül nem érkezik HTTP-válasz, a kérés kiesik, és a Webex mikroszolgáltatások blokkoltként jelölik meg az IP-t, és útvonalelőleget hajtanak végre a következő IP-re.

Minden kérést háromszor próbálnak ki, mielőtt a hiba visszakerül a mikroszolgáltatáshoz.

Ha egy IP szerepel a blokkolt listában, az nem kerül fel a címek listájába, amelyet akkor próbálhat meg kipróbálni, amikor kérést küld egy XSP-nek. Egy előre meghatározott időszak után a blokkolt IP lejár, és visszatér a listába, hogy megpróbálja, ha egy másik kérést tesznek.

Ha az összes IP-cím le van tiltva, a mikroszolgáltatás továbbra is megpróbálja elküldeni a kérést úgy, hogy véletlenszerűen kiválaszt egy IP-címet a blokkolt listából. Ha sikeres, az IP-cím törlődik a letiltott listáról.

Állapot

A Webex Cloud-szolgáltatások XSP-ekkel vagy terheléskiegyenlítőkhöz való csatlakoztatásának állapota a Control Hubban látható. A BroadWorks calling cluster alatt a kapcsolat állapota jelenik meg az alábbi interfészekhez:

  • XSI műveletek

  • XSI események

  • Hitelesítési szolgáltatás

A kapcsolat állapota az oldal betöltésekor vagy a bemeneti frissítések során frissül. A kapcsolatok állapotai lehetnek:

  • zöld: Amikor a felület elérhető az A rekord kereső egyik EP-jén.

  • piros: Ha az A rekordkeresőben lévő összes IPs elérhetetlen, és a felület nem érhető el.

A következő szolgáltatások használják a mikroszolgáltatásokat az XSP-khez való csatlakozáshoz, és az XSP interfész elérhetősége hatással van iktatására:

  • Webex alkalmazás bejelentkezése

  • Webex App token frissítés

  • Nem megbízható e-mail/önaktiválás

  • Broadworks szolgáltatás állapotfelmérése

Webex alkalmazás

DNS konfiguráció

A Webex alkalmazás az XSP Xtended Services Interface (XSI-Actions & XSI-Events) és Eszközkezelési szolgáltatás (DMS) szolgáltatásait olja el.

Ez elvégzi a DNS SRV keresést _xsi-client._tcp.<xsi domain> a konfigurált URL-címről, hogy megtalálja az XSI-szolgáltatás XSP-állomásait vagy terheléskiegyenlítőit.

Az alábbiakban egy példa az SRV rekordok.

Rekord típusa

Rögzítés

Cél

Cél

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc1.example.com

Xsi interfész ügyfélfelfedezése

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc2.example.com

Xsi interfész ügyfélfelfedezése

A

xsp-dc1.example.com

198.51.100.48

Pontok LB1-re (A oldal)

A

xsp-dc2.example.com

198.51.100.49

Pontok az LB2-re (B oldal)


Minden A/AAAA rekordnak egy IP-címre kell leképezze. Ha a terheléskiegyenlítő/él eszköz mögött több XSP van egy DMZ-ben, a terheléskiegyenlítőt úgy kell beállítani, hogy fenntartsa a munkamenet tartósságát, hogy ugyanazon munkamenet összes kérését ugyanarra az XSP-re igazítsa.

Azért rendeljük meg ezt a konfigurációt, mert az ügyfél XSI-esemény szívverésének ugyanarra az XSP-re kell mennie, amelyet az eseménycsatorna létrehozásához használnak.

Ha az A/AAAA nevet több IP-címre térképeli fel, vagy ha a terheléskiegyenlítő/élelem nem tartja fenn a munkamenet tartósságát, az ügyfél végül szívverést küld egy XSP-nek, ahol nem hozott létre eseménycsatornát. Ez azt eredményezi, hogy a csatorna leszakad, és lényegesen nagyobb belső forgalommal jár, ami rontja az XSP fürt teljesítményét.

A bejelentkezési folyamat során a Webex alkalmazás lekéri a DMS URL-t is, hogy letöltse a konfigurációs fájlt. Az URL-ben lévő állomás elemzésre kerül, és a Webex alkalmazás elvégzi a gazdagép DNS A/AAAA keresését, hogy csatlakozzon a DMS szolgáltatást üzemeltető XSP-hez.

Példa: DNS A Rekord a Round-Robin kiegyensúlyozott internet-orientált XSP szerver / Load Balancers felfedezéséhez a Webex App-tal a konfigurációs fájlok letöltéséhez a DMS-en keresztül:

Rekord típusa

Név

Cél

Cél

A

xsp-dms.example.com

198.51.100.48

Pontok LB1-re (A oldal)

A

xsp-dms.example.com

198.51.100.49

Pontok az LB2-re (B oldal)

Hogyan találja meg a Webex alkalmazás az XSP-címeket?

Az ügyfél a következő DNS-folyamat segítségével próbálja megtalálni az XSP-csomópontokat:

  1. Az ügyfél először a Cisco Webex felhőből lekéri az Xsi-Actions/Xsi-Events URL-eket (a kapcsolódó BroadWorks Calling Cluster létrehozásakor beírta őket). Az Xsi hostname/domain az URL-ről származik, és az ügyfél az alábbiak szerint végzi el az SRV-kereséseket:

    1. Az ügyfél SRV-t keres _xsi client._tcp.<xsi domain="">

    2. Ha az SRV-keresés egy vagy több célt ad vissza:

      1. Az ügyfél nem A / AAAA keresni ezeket a célokat, és gyorsítótárak a visszaküldött IP-címeket.

      2. Az ügyfél csatlakozik az egyik célhoz (és ezért az A/AAAA rekordjához egyetlen IP-címmel) az SRV prioritás alapján, majd a súly (vagy véletlenszerűen, ha mindegyik egyenlő).

    3. Ha az SRV-keresés nem ad vissza célokat:

      Az ügyfél A/AAAA-t keres az Xsi gyökérparaméterben, majd megpróbál csatlakozni a visszaadott IP-címhez. Ez lehet egy terheléskiegyenlítő élelem, vagy maga az XSP szerver.

      Mint megjegyezték, az A/AAAA rekordnak ugyanazon okokból egy IP-címre kell rendeződnie.

  2. (Nem kötelező) Ezt követően a Webex alkalmazás eszközkonfigurációjában egyéni XSI-Actions/XSI-Events adatokat adhat meg a következő címkék használatával:

    <protocols>
    	<xsi>
    		<paths>
    			<root>%XSI_ROOT_WXT%</root>
    			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
    			<events>%XSI_EVENTS_PATH_WXT%</events>
    		</paths>
    	</xsi>
    </protocols>
    1. Ezek a konfigurációs paraméterek elsőbbséget élveznek a BroadWorks-fürt vezérlőközpontjában található konfigurációkkal szemben.

    2. Ha léteznek, az ügyfél összehasonlítja az eredeti XSI-címmel, amely a BroadWorks Cluster konfiguráción keresztül érkezett.

    3. Ha eltérést észlel, az ügyfél újra inicializálja az XSI Actions/ XSI Events kapcsolatot. Ennek első lépése az 1. lépésben felsorolt DNS-megkeresési folyamat végrehajtása – ezúttal a %XSI_ROOT_WXT% paraméter értékének megkeresése a konfigurációs fájlból.


      Győződjön meg róla, hogy létrehozza a megfelelő SRV-rekordokat, ha ezzel a címkével módosítja az Xsi-interfészeket.
Feladatátvétel

A bejelentkezés során a Webex Alkalmazás DNS SRV keresést végez a _xsi-client._tcp.<xsi domain="">számára, összeállítja a házigazdák listáját, és csatlakozik az egyik állomáshoz az SRV prioritás, majd a súly alapján. Ez a csatlakoztatott állomás lesz a kiválasztott minden jövőbeli kéréshez. Ezután megnyílik egy eseménycsatorna a kiválasztott állomás előtt, és rendszeresen szívverést küld a csatorna ellenőrzésére. Az első után küldött kérések között szerepel egy cookie, amely a HTTP-válaszban kerül vissza, ezért fontos, hogy a terheléskiegyenlítő megtartsa a munkamenet tartósságát (affinitás), és mindig küldjön kéréseket ugyanarra a háttér-XSP szerverre.

Ha egy kérés vagy egy fogadóhoz intézett szívverés-kérés sikertelen, több dolog is előfordulhat:

  • Ha a hiba hálózati hibára (pl.: TCP, SSL), a Webex Alkalmazás azonnal átirányítja az előlegeket a lista következő állomására.

  • Hibakód (HTTP 5xx) visszaküldeni, a kérelem nem azonnal.

  • Ha a válasz egy időn belül nem érkezik meg, akkor a kérést az időtúllépés miatt sikertelennek tekintik, és a következő kéréseket a következő állomásnak küldik. Az időzített kérés azonban sikertelennek minősül. Egyes kérelmeket sikertelenség után újra megpróbálnak (növekvő újrafelvételi idővel). Azokat a kéréseket, amelyek szerint a feltételezett nem létfontosságú nem létfontosságú, nem perelik újra.

Ha egy új állomást sikeresen kipróbálnak, akkor az új kijelölt állomássá válik, ha a gazdagép jelen van a listában. Miután a lista utolsó állomását kipróbálták, a Webex alkalmazás áttér az elsőre.

Szívverés esetén, ha két egymást követő kérési hiba van, a Webex alkalmazás újra inicializálja az eseménycsatornát.

Ne feledje, hogy a Webex Alkalmazás nem hajt végre hiba-vissza, és a DNS-szolgáltatás felderítése csak egyszer történik meg bejelentkezéskor.

Bejelentkezéskor a Webex alkalmazás megpróbálja letölteni a konfigurációs fájlt az XSP / Dms felületen keresztül. A lekért DMS URL-ben A/AAAA rekordot keres a gazdagépről, és csatlakozik az első IP-hez. Először megpróbálja elküldeni a konfigurációs fájl letöltésére vonatkozó kérést egy SSO token használatával. Ha ez bármilyen okból sikertelen, akkor újra megpróbálja, de az eszköz felhasználónevével és jelszavával.