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

  • Cel mai rapid de implementat

  • Ieftin

  • Toate eforturile

  • Este posibil să nu îndeplinească cerințele de securitate

Typical Direct Connection
Conexiune directă tipică

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

  • Conexiune securizată

  • Fără costuri suplimentare

  • Este nevoie de timp pentru implementare

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

Typical IPsec or IPSec over GRE Tunnel
IPsec tipic sau IPSec prin tunelul GRE

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.

Typical Site-to-Site Connection
Conexiune tipică site-to-site

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.

Typical SIP TLS and SRTP connection
Conexiune TLS și SRTP SIP tipică
Certificate publice și autosemnate

Pentru 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.

Typical Private connection
Conexiune privată tipică

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

  • Fiabilitate ridicată

  • Lățime de bandă dedicată

  • O conexiune directă este cea mai scumpă

  • Cel mai lung timp de implementare

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.

Typical Data Center Cross Connect
Conectarea încrucișată tipică a centrului de date

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.

Typical Cube behind firewall
Cub tipic în spatele firewall-ului

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.