Offentlig Internett

Direkte SIP-trunk (over toppen)

Kundens CUBE eller SBC skal plasseres på en offentlig IP. Dette er vår anbefalte standard distribusjonsmodell.

Siden dette er den mest forenklede tilnærmingen, er den også den minst fleksible. Fordelene med en forenklet topologi er enkel administrasjon og feilsøking. Nettverksdiagrammer fylles ut av kunden og sendes til taleteamet, og oppringingsnoder opprettes. Plassering av CUBE i en DMZ reduserer kompleksiteten ved å håndtere NAT. CUBE i seg selv er en brannmur, og de fleste mellomstore / store leverandører plasserer sin CUBE i en offentlig IP og bruker sikkerhetsfunksjonene.

Vpn

En VPN er en annen type tilkobling som bruker offentlig internett. VPN-er er ofte nødvendig når en kunde krever en sikker tilkobling for SIP og RTP. En VPN kan også være nødvendig hvis kunden ikke kan plassere kuben på et offentlig IP sted. Et klargjøringsmøte med taleteknikk kreves for VPN tilkoblinger.

Taleporter

• RTP: 8000 - 48199

• SIP: UDP 5060

IPSec VPN eller IPSec over GRE

Følgende alternativer er tilgjengelige for VPN Connectivity:

• SBC til SBC-tilkobling

• GW til GW-tilkobling

Webex Contact Center (IPSec eller IPSec over GRE-tunnel og Webex Contact Center S2S-tilkobling) for å bruke UDP/5060 i stedet for TCP/5060

En IPSec VPN eller IPSec over GRE er et godt alternativ for en sikker SIP-trunk når CUBE er på en offentlig IP. Dette er en SBC til SBC-tilkobling. (Fig. 2) Med VPN tunneler må også private IP adresseordninger vurderes for å unngå overlapp mellom kunder. For GRE-tilkoblinger er IP delnett: 10.x.248.x og 10.x.249.x.

Sted-til-sted (S2S)

En S2S-tilkobling kan distribueres hvis kunden trenger en sikker tilkobling eller ikke kan plassere kuben i en offentlig IP. Dette er en gateway-til-gateway-tilkobling. Det er ingen delnett som er spesielt utpekt for S2S-VPN tilkoblinger, da ruting er basert på interessant trafikk uten involvering av et logisk grensesnitt.

SIP-TLS og SRTP

Bruk av SRTP/SIP-TLS er et annet alternativ når CUBE er på en offentlig IP adresse. Det er imidlertid en ytelseshit for bruk av SRTP/SIP-TLS. En CUBE-enhet kan håndtere en tredjedel av SIP-øktene hvis du har sikret samtalene ved hjelp av enten TLS eller SRTP. Dette er en SBC til SBC-tilkobling.

For å etablere en SIP TLS-tilkobling, er det nødvendig å utveksle sertifikater. Følgende alternativer er tilgjengelige:

• Selvsignerte sertifikater genereres og utveksles mellom kunden og Webex Contact Center.

• Public CA – følgende trinn må fullføres for å støtte Public CA:

  • Kunden må dele rotsertifikatet som lastes inn i SBCen for Webex Contact Center.

  • Kunden må oppdatere DNS for å inkludere IP-adressene til SBC-ene for Webex Contact Center.

Privat tilkobling

Ofte tilkoblingsvalget til store bedriftsleverandører, en direkte tilkobling gir en dedikert og sikker krets. Hvis kunden trenger en direkte tilkobling, kan kunden Cisco Webex Contact Center få dokumentet VPOP Circuit Order Guidelines som det første trinnet, og et oppfølgingsdesignmøte med Webex Contact Center Voice Engineering-teamet og kundeteknikerne må gjennomføres som neste trinn. Kunden må gi et detaljert nettverksdiagram over kundens talenettverk, inkludert PSTN-operatørsammenkoblinger, for møtet. Cisco er ikke vert for noe kundeutstyr.

Uansett om kunden velger MPLS, P2P, VPLS eller SD-WAN, vil topologien se lik ut, og alle kretser vil avslutte til Webex kontaktsenterruter/GW og ikke til Webex kontaktsenter-CUBE-er.

Båndbreddekravene for en direkte tilkobling er basert på G.711-kodeken (~100 kbps per samtaleetappe), noe som tillater to anropsetapper per økt.

Krysstilkobling av datasenter

Hvis en kunde bestemmer seg for en privat tilkobling, vil det være nødvendig å bestille kryssforbindelser for datasenter som beskrevet i Cisco Webex Contact Center dokumentet VPOP Circuit Order Guidelines. Kunden vil være ansvarlig for kostnadene som påløper og for å få kundens krets til det angitte slippet. (Fig. 6.)

Cisco Webex Contact CenterDokumentet VPOP Circuit Order Guidelines vil bli gitt til kunden direkte under ombordstigningsprosessen i tilfelle dette tilkoblingsalternativet foretrekkes.

Ikke-standard distribusjoner

Hvis de anbefalte topologiene ikke oppfyller alle kravene i kundens nettverk, må det planlegges et designmøte med Cisco Voice Engineering-teamet via kundens Cisco-kontoteam for en spesiell godkjenningsprosess. Følgende er eksempler på distribusjoner og distribusjoner som ikke er standardiserte:

A2Q-unntak

PSTN-leverandør som avslutter kretsen direkte til Webex Contact Center VPOP.

Unntak for gullleier

Vi anbefaler på det sterkeste en direkte SIP-trunk for Gold Tenant-kunder. Dette er den overdrevne topologien for å plassere kuben i et offentlig IP rom. Behovet for en Gold Tenant eksisterer ofte med større leverandører; Leverandøren krever imidlertid at gullleieren er et konseptbevis for leverandørens tiltenkte produksjonsdistribusjon. Proof of concept Gold Tenant overskrider ofte bruk av åpen Internett-tilgang for en SIP-trunk og vil kreve en av de tidligere diskuterte tilkoblingstyper.

Gold Tenant-kunder vil ikke bli overvåket.

Offentlig Internett - CUBE bak brannmur

Plassering av en kube på en privat IP-adresse bak en NAT-brannmur er et annet distribusjonsalternativ. Sikkerhetskravene fra kundens IT-avdeling kan stille krav om at taleapplikasjonen skal ligge bak en brannmur. Dette alternativet har noen kjente ulemper. Selv om dette kanskje ikke forårsaker problemer i nettverkslaget, kan det føre til problemer i SIP-programlaget. Den private IP-adressen brukes i SIP-meldingene, noe som fører til anropsbehandlingsfeil. Brannmurkapasitet er en annen faktor som må vurderes for denne typen distribusjon. Brannmurer må dimensjoneres riktig for å håndtere VoIP trafikk. Brannmuren kan ellers bli en flaskehals og kan påvirke samtalekvalitet og samtalebehandling.

Dette er ulempene med denne distribusjonen:

• Mulige problemer med kubekonfigurasjon og -oppsett i begynnelsen.

• Økt belastning på brannmuren som kan påvirke talekvaliteten.

• Kunden er ansvarlig for KUBE-oppsett og brannmurstørrelse.

• Ikke en anbefalt topologi på grunn av innvirkning på serviceavtaler.

Denne topologien anbefales ikke på grunn av kompleksiteten ved håndtering av SIP og NAT. Et møte med Cisco Voice Engineering-teamet og kunden kreves for godkjenning av denne typen distribusjon.