Internet public

Trunchi SIP direct (deasupra)

CUBE sau SBC-ul clientului trebuie plasat pe un IP public. Acesta este modelul nostru standard de implementare recomandat.

Deoarece aceasta este abordarea cea mai simplistă, este și cea mai puțin flexibilă. Beneficiile unei topologii simplificate sunt ușurința de gestionare și depanare. Diagramele de rețea sunt completate de către client și trimise echipei de voce, iar colegii de apelare sunt creați. Plasarea CUBE într-un DMZ reduce complexitatea tratării cu NAT. CUBE-ul în sine este un firewall, iar majoritatea furnizorilor medii/mari își plasează CUBE-ul într-un IP public și își utilizează capacitățile de securitate.

Rețele VPN

Un VPN este un alt tip de conexiune care utilizează internetul public. VPN-urile sunt adesea necesare atunci când un client are nevoie de o conexiune securizată pentru SIP și RTP. De asemenea, poate fi necesar un VPN dacă clientul nu poate plasa CUBE într-un spațiu IP public. Pentru conexiunile VPN este necesară o întâlnire de asigurare a accesului cu Inginerie vocală.

Porturi de voce

• rtp: 8000 - 48199

• SIP: udp 5060

IPSec VPN sau IPSec prin GRE

Următoarele opțiuni sunt disponibile pentru conectivitatea VPN:

• Conectivitate SBC la SBC

• Conexiune GW - 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 VPN IPSec sau IPSec over GRE este o opțiune bună pentru un trunchi SIP securizat atunci când CUBE este pe un IP public. Aceasta este o conexiune SBC - SBC. (Fig 2) Schemele de adrese IP private pentru tunelurile VPN trebuie, de asemenea, luate în considerare pentru a evita orice suprapunere între clienți. Pentru conexiunile GRE, subrețelele IP sunt: 10.x.248.x și 10.x.249.x.

Locație la locație (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 de tip gateway to gateway. Nu există subrețele special desemnate pentru conexiunile VPN S2S, deoarece rutarea se bazează pe 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 este pe o adresă IP publică. Cu toate acestea, există un succes de performanță pentru utilizarea SRTP/SIP TLS. Un dispozitiv CUBE poate gestiona o treime din sesiunile SIP dacă ați securizat apelurile utilizând fie TLS, fie SRTP. Aceasta este o conexiune SBC - SBC.

Pentru a stabili o conexiune SIP TLS, este necesar să schimbați certificate. Sunt disponibile următoarele opțiuni:

• Certificatele autosemnate sunt generate și schimbate între client și Webex Contact Center.

• Autoritate de certificare publică – trebuie parcurși următorii pași pentru a sprijini autoritatea de certificare publică:

  • Clientul trebuie să partajeze certificatul principal 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ă

De multe ori alegerea de conexiune a furnizorilor de întreprinderi mari, o conexiune directă oferă un circuit dedicat și securizat. Dacă clientul are nevoie de o conexiune directă, acestuia i se poate furniza documentul Ghiduri privind comenzile pentru circuite VPOP pentru Cisco Webex Contact Center , ca pas inițial, iar o întâlnire de proiectare ulterioară cu echipa de inginerie vocală a Webex Contact Center și cu inginerii clientului trebuie efectuată ca pasul următor. Clientul trebuie să furnizeze o diagramă de rețea 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 vor ajunge la routerul/GW Webex Contact Center și nu la CUBE-urile Webex Contact Center.

Cerințele privind lățimea de bandă pentru o conexiune directă se bazează pe codecul G.711 (~100 kbps per segment de apel), permițând două segmente de apel per sesiune.

Interconectare centru de date

Dacă un client decide cu privire la o conexiune privată, va fi necesar să comande interconectări ale centrului de date, așa cum este descris în documentul Ghiduri de comandă a circuitelor VPOP pentru Cisco Webex Contact Center. Clientul va fi responsabil pentru costurile suportate și pentru obținerea circuitului clientului la scăderea desemnată. (Fig. 6.)

Implementări non-standard

Dacă topologiile recomandate nu îndeplinesc toate cerințele rețelei clientului, trebuie programată o întâlnire de proiectare cu echipa Cisco Voice Engineering 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 care termină circuitul direct la VPOP Webex Contact Center.

Excepții entitate găzduită Gold

Recomandăm ferm un trunchi SIP direct pentru clienții Gold Tenant. Aceasta este topologia over-the-top a plasării CUBE într-un spațiu IP public. Necesitatea unei entități găzduite de aur există adesea cu furnizori mai mari; cu toate acestea, furnizorul solicită ca entitatea găzduită de aur să fie o dovadă a conceptului pentru implementarea de producție preconizată a furnizorului. Dovada conceptului Gold Tenant depășește adesea utilizarea accesului liber la internet pentru un trunchi SIP și ar necesita unul dintre tipurile de conexiune discutate anterior.

Clienții entității găzduite Gold 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 ale departamentului IT al clientului pot stipula prezența aplicației de voce în spatele unui firewall. Această opțiune are câteva dezavantaje cunoscute. Chiar dacă este posibil ca acest lucru să nu cauzeze probleme în stratul de rețea, poate avea ca rezultat probleme în stratul de aplicație SIP. Adresa IP privată este utilizată în cadrul mesajelor SIP, ceea ce cauzează erori de procesare a apelurilor. Capacitatea firewallului este un alt factor care trebuie luat în considerare pentru acest tip de implementare. Firewallurile trebuie să fie dimensionate în mod corespunzător pentru a gestiona traficul VoIP; în caz contrar, firewallul poate deveni un obstacol și poate afecta calitatea apelurilor și procesarea apelurilor.

În continuare, găsiți dezavantajele acestei implementări:

• Posibile probleme de configurare și configurare CUBE la început.

• Sarcină crescută a firewallului care ar putea afecta calitatea vocii.

• Clientul este responsabil pentru configurarea CUBE și dimensionarea firewallului.

• Nu este o topologie recomandată din cauza impactului asupra SLA.