Webex Contact Center acceptă următoarele tipuri de conectivitate:
Conectivitate |
Tipuri |
---|---|
Public Internet |
Direct IPSec VPN sau IPSec peste GRE S2S SRTP/SIP TLS |
Conectivitate privată (este necesară aprobarea) |
MPLS P2P VPLS SD-WAN WAN privat Conectarea încrucișată a centrului de date |
Versiunea IOS pentru CUBE/vCUBE ar trebui să accepte TLS 1.2. |
Public Internet
Trunchi SIP direct (deasupra)
CUBE-ul sau SBC-ul clientului ar trebui plasat pe un IP public. Acesta este modelul nostru standard de implementare recomandat.
Argumente pro |
Contra |
---|---|
|
|
Deoarece aceasta este abordarea cea mai simplistă, este și cea mai puțin flexibilă. Beneficiile unei topologii simplificate sunt ușurința gestionării și depanarea. Diagramele de rețea sunt completate de client și trimise echipei de voce și sunt create colegii de apelare. Plasarea CUBE într-un DMZ ameliorează complexitatea tratării NAT. CUBE în sine este un firewall, iar majoritatea furnizorilor medii / mari își plasează CUBE într-un IP public și folosesc capacitățile sale de securitate.
Vpn
Un VPN este un alt tip de conexiune care utilizează internetul public. VPN-urile sunt adesea necesare atunci când un client necesită o conexiune sigură pentru SIP și RTP. Un VPN ar putea fi, de asemenea, necesar în cazul în care clientul nu poate plasa CUBE într-un spațiu IP public. Pentru VPN conexiuni este necesară o întâlnire de asigurare a accesului cu ingineria vocală.
Argumente pro |
Contra |
---|---|
|
|
Porturi de voce
-
RTP: 8000 - 48199
-
SIP: UDP 5060
IPSec VPN sau IPSec peste GRE
Următoarele opțiuni sunt disponibile pentru VPN Connectivity:
-
Conectivitate SBC la SBC
-
Conectivitate GW la GW
Webex Contact Center (IPSec sau IPSec prin tunelul GRE și conectivitatea Webex Contact Center S2S) pentru a utiliza UDP/5060 în loc de TCP/5060
Un IPSec VPN sau IPSec peste GRE este o opțiune bună pentru un trunchi SIP securizat atunci când CUBE se află pe un IP public. Aceasta este o conexiune SBC la SBC. (Fig. 2) în cazul tunelurilor VPN, sistemele de adrese de IP private trebuie, de asemenea, luate în considerare pentru a evita orice suprapunere între clienți. Pentru conexiunile GRE IP subrețele sunt: 10.x.248.x și 10.x.249.x.
Site-to-Site (S2S)
O conexiune S2S poate fi implementată dacă clientul are nevoie de o conexiune securizată sau nu poate plasa CUBE într-un IP public. Aceasta este o conexiune gateway to gateway. Nu există subrețele special desemnate pentru conexiunile S2S VPN, deoarece rutarea se bazează pe un trafic interesant fără implicarea unei interfețe logice.
SIP TLS și SRTP
Utilizarea SRTP/SIP TLS este o altă opțiune atunci când CUBE se află pe o adresă IP publică. Cu toate acestea, există un hit de performanță pentru utilizarea SRTP / SIP TLS. Un dispozitiv CUBE poate gestiona o treime din sesiunile SIP dacă ați securizat apelurile utilizând TLS sau SRTP. Aceasta este o conexiune SBC la SBC.
Certificate publice și autosemnatePentru a stabili o conexiune TLS SIP, este necesar să se facă schimb de certificate. Sunt disponibile următoarele opțiuni:
-
Certificatele autosemnate sunt generate și schimbate între client și Webex Contact Center.
-
AC publică - următorii pași trebuie finalizați pentru a sprijini AC public:
-
Clientul trebuie să partajeze certificatul rădăcină care va fi încărcat în Webex Contact Center SBC.
-
Clientul trebuie să actualizeze DNS pentru a include IP-urile SBC-urilor Webex Contact Center.
-
Conectivitate privată
Adesea, alegerea conexiunii furnizorilor de întreprinderi mari, o conexiune directă oferă un circuit dedicat și sigur. În cazul în care clientul are nevoie de o conexiune directă, clientului i se poate furniza documentul Cisco Webex Contact Center VPOP Circuit Order Guidelines ca pas inițial, iar ca pas următor trebuie efectuată o întâlnire de proiectare ulterioară cu echipa Webex Contact Center Voice Engineering și inginerii clientului. Clientul trebuie să furnizeze o diagramă detaliată a rețelei de voce a clientului, inclusiv interconectările operatorului PSTN pentru întâlnire. Cisco nu va găzdui niciun echipament pentru clienți.
Indiferent dacă clientul alege MPLS, P2P, VPLS sau SD-WAN, topologia va arăta similar și toate circuitele se vor termina la Webex router Contact Center/GW și nu la Webex CUBE-uri Contact Center.
Cerințele de lățime de bandă pentru o conexiune directă se bazează pe codecul G.711 (~100kbps per picior de apel), permițând două picioare de apel pe sesiune.
Argumente pro |
Contra |
---|---|
|
|
Conectarea încrucișată a centrului de date
Dacă un client decide asupra unei conexiuni private, va fi necesar să comandați conexiuni încrucișate ale centrului de date așa cum este descris în documentul Cisco Webex Contact Center VPOP Circuit Order Guidelines. Clientul va fi responsabil pentru costul suportat și pentru aducerea circuitului clientului la picătura desemnată. (Fig. 6.)
Documentul Cisco Webex Contact Center Instrucțiuni privind comenzile de circuit VPOP va fi furnizat clientului direct în timpul procesului de îmbarcare, în cazul în care se preferă această opțiune de conectivitate. |
Implementări non-standard
Dacă topologiile recomandate nu îndeplinesc toate cerințele rețelei clientului, trebuie programată o întâlnire de proiectare cu echipa de inginerie vocală Cisco prin intermediul echipei de cont Cisco a clientului pentru un proces special de aprobare. Următoarele sunt exemple de implementări non-standard și implementări care nu sunt recomandate:
Excepții A2Q
Furnizorul PSTN termină circuitul direct la Webex Contact Center VPOP.
Excepții pentru chiriașii de aur
Vă recomandăm cu tărie un SIP Trunk direct pentru clienții Gold Tenant. Aceasta este topologia over-the-top a plasării CUBE într-un spațiu IP public. Necesitatea unui chiriaș de aur există adesea cu furnizori mai mari; cu toate acestea, furnizorul solicită chiriașului de aur să fie o dovadă a conceptului pentru implementarea producției intenționate a furnizorului. Dovada conceptului Gold Tenant depășește adesea utilizarea accesului la internet deschis pentru un trunchi SIP și ar necesita unul dintre tipurile de conexiune discutate anterior.
Clienții Gold Tenant nu vor fi monitorizați.
Internet public – CUBE în spatele firewall-ului
Plasarea unui CUBE pe o adresă IP privată în spatele unui firewall NAT este o altă opțiune de implementare. Cerințele de securitate de la departamentul IT al clientului pot stipula să aibă aplicația vocală în spatele unui firewall. Această opțiune are câteva dezavantaje cunoscute. Chiar dacă acest lucru nu poate cauza probleme în stratul de rețea, poate duce la probleme în stratul de aplicație SIP. Adresa de IP privată este utilizată în mesajele SIP, ceea ce provoacă erori de procesare a apelurilor. Capacitatea firewall-ului este un alt factor care trebuie luat în considerare pentru acest tip de implementare. Firewall-urile trebuie să fie dimensionate corespunzător pentru a gestiona traficul VoIP; firewall-ul poate deveni altfel un blocaj și poate afecta calitatea apelurilor și procesarea apelurilor.
Următoarele sunt dezavantajele acestei implementări:
-
Posibile probleme de configurare și configurare CUBE la început.
-
Încărcare crescută a firewall-ului, care ar putea afecta calitatea vocii.
-
Clientul este responsabil pentru configurarea CUBE și dimensionarea firewall-ului.
-
Nu este o topologie recomandată din cauza impactului asupra SLA-urilor.
Această topologie nu este recomandată datorită complexității tratării SIP și NAT. Pentru aprobarea acestui tip de implementare este necesară o întâlnire cu echipa de inginerie vocală Cisco și cu clientul. |