Openbaar Internet

Directe SIP-lijn (over de bovenkant)

De CUBE of SBC van de klant moet op een openbaar IP worden geplaatst. Dit is ons aanbevolen standaard implementatiemodel.

Aangezien dit de meest simplistische benadering is, is het ook de minst flexibel. De voordelen van een vereenvoudigde topologie zijn managementgemak en probleemoplossing. Netwerkdiagrammen worden door de klant ingevuld, naar het spraakteam verzonden en dial-peers worden gemaakt. Wanneer u de CUBE in een DMZ plaatst, wordt het omgaan met NAT verlicht. De CUBE zelf is een firewall. De meeste middelgrote/grote providers plaatsen hun CUBE in een openbaar IP en gebruiken deze beveiligingsmogelijkheden.

Vpn

Een VPN is een ander type verbinding dat gebruikmaakt van openbaar internet. VPN's zijn vaak nodig wanneer een klant een veilige verbinding voor SIP en RTP vereist. Een VPN kan ook vereist zijn als de klant de CUBE niet in een openbare IP ruimte kan plaatsen. Voor VPN verbindingen is een inrichtingsvergadering met Voice Engineering vereist.

Spraakpoorten

• RTP: 8000 - 48199

• SIP: UDP 5060

IPSec VPN of IPSec over de GRE

Voor VPN Connectivity zijn de volgende opties beschikbaar:

• SBC naar SBC connectiviteit

• GW naar GW connectiviteit

Webex Contact Center (IPSec of IPSec via de GRE-tunnel en Webex Contact Center S2S Connectivity) om UDP/5060 te gebruiken in plaats van TCP/5060

Een IPSec VPN of IPSec over GRE is een goede optie voor veilige SIP-lijnen wanneer de CUBE zich op een openbaar IP bevindt. Dit is een SBC-naar-SBC-verbinding. (fig 2) met VPN tunnels moeten ook particuliere IP adresschema's in overweging worden genomen om overlapping tussen klanten te voorkomen. Voor GRE-verbindingen IP subnetten: 10.x.248.x en 10.x.249.x.

Site-naar-site (S2S)

Een S2S-verbinding kan worden geïmplementeerd als de klant een veilige verbinding nodig heeft of als de CUBE niet in een openbaar IP kan worden geplaatst. Dit is een verbinding met de gateway-to-gateway. Er zijn geen subnetten die speciaal zijn aangewezen voor S2S-VPN-verbindingen, omdat de routering is gebaseerd op interessant verkeer zonder de tussenkomst van een logische interface.

SIP-TLS en SRTP

Als u SRTP/SIP-TLS gebruikt, is een andere optie wanneer de CUBE op een openbaar IP adres staat. Er is echter wel een prestatiehit voor het gebruik van SRTP/SIP TLS. Een CUBE-apparaat kan een derde van de SIP-sessies afhandelen als u de gesprekken hebt beveiligd met TLS of SRTP. Dit is een SBC-naar-SBC-verbinding.

Om een SIP-TLS verbinding tot stand te brengen, zijn certificaten nodig. De volgende opties zijn beschikbaar:

• Zelfondertekende certificaten worden gegenereerd en uitgewisseld tussen de klant en Webex contactcenter.

• Openbare ca: de volgende stappen moeten worden uitgevoerd om Public CA te ondersteunen:

  • De klant moet het hoofdcertificaat delen dat in de Webex Contact Center SBC wordt geladen.

  • De klant moet de DNS bijwerken met de IP's van de Webex contactcenter-SBC's.

Privé-verbinding

Vaak is een directe verbinding de keuze voor grote zakelijke providers en biedt een directe verbinding een toegewijd en veilig circuit. Als de klant een directe verbinding nodig heeft, kan de klant als eerste stap de Cisco Webex Contact Center Document met VPOP-circuitorderrichtlijnen krijgen, en er wordt een follow-up ontwerpvergadering met het Webex Contact Center Voice Engineering team en de technische medewerkers van de klant uitgevoerd als volgende stap. De klant moet een gedetailleerd netwerkschema overgeven van het spraaknetwerk van de klant, inclusief PSTN-carrierverbindingen voor de vergadering. Cisco host geen klantenapparatuur.

Ongeacht of de klant kiest voor MPLS, P2P, VPLS of SD-WAN, zal de topologie er hetzelfde uitzien en zullen alle circuits eindigen in Webex Contact Center router/GW en niet aan Webex Contact Center CUBEs.

De vereiste bandbreedte voor direct verbinden is gebaseerd op de G.711-codec (~100 kb per gespreksleg), waarbij twee gespreksleg per sessie mogelijk is.

Datacenter cross connect (verbinding tussen datacenters)

Als een klant besluit over een privéverbinding, is het noodzakelijk om kruisverbindingen voor datacenters te bestellen zoals beschreven in het Cisco Webex Contact Center document met richtlijnen voor volgorde van VPOP-circuit. De klant is verantwoordelijk voor de gemaakte kosten en voor het naar de bestemming van de klant gebrachte circuit. (Fig. 6.)

Het Cisco Webex Contact Center document met de VPOP-circuitvolgorderichtlijnen wordt direct tijdens het aan boord gaan aan de klant verstrekt in het geval dat deze connectiviteitsoptie de voorkeur krijgt.

Niet-standaard implementaties

Als de aanbevolen topologieën niet voldoen aan alle vereisten van het netwerk van de klant, moet voor een speciaal goedkeuringsproces een ontwerpvergadering worden gepland met het Cisco Voice Engineering-team via het Cisco accountteam van de klant. Hieronder ziet u voorbeelden van niet-standaard implementaties en implementaties die niet worden aanbevolen:

A2Q-uitzonderingen

PSTN-provider beëindigt de circuit rechtstreeks met Webex Contact Center VPOP.

Gouden tenant uitzondering

We raden klanten met het sterkste een directe SIP-lijn aan voor Gold Tenant-klanten. Dit is de over-the-top topologie van het plaatsen van de CUBE in een openbare IP ruimte. De behoefte aan een Gold Tenant bestaat vaak bij grotere aanbieders; de provider vereist echter dat de gouden tenant een proof of concept is voor de beoogde productie-implementatie van de provider. De proof of concept Gold Tenant overtreft vaak het gebruik van open internettoegang voor een SIP-lijn en vereist een van de eerder besproken verbindingstypen.

Gold Tenant-klanten worden niet gecontroleerd.

Openbaar Internet – CUBE achter firewall

Als u een CUBE op een privé IP adres achter een NAT-firewall plaatst, is dat een andere implementatieoptie. De beveiligingsvereisten van de IT-afdeling van de klant kunnen bepalen dat de spraaktoepassing achter een firewall moet staan. Deze optie heeft een paar bekende op den tijd. Ook al leidt dit mogelijk niet tot problemen in de netwerklaag, maar kan het leiden tot problemen in de SIP-toepassingslaag. In de SIP-berichten wordt het privé-IP adres gebruikt, waardoor oproepverwerkingsfouten optreden. Firewall-capaciteit is een andere factor die moet worden overwogen voor dit type implementatie. Firewalls moeten de juiste grootte hebben voor het verwerken van VoIP. Anders kan de firewall een bottleneck worden en kan het de kwaliteit van gesprekken en het verwerken van gesprekken beïnvloeden.

Het volgende zijn de nadelen van deze implementatie:

• Mogelijke problemen met de CUBE-configuratie en configuratie aan het begin.

• Extra belasting van de firewall, die de spraakkwaliteit kan beïnvloeden.

• De klant is verantwoordelijk voor het instellen van de CUBE en de firewall.

• Geen aanbevolen topologie vanwege de impact op SLA's.

Deze topologie wordt niet aanbevolen vanwege de complexiteit van het omgaan met SIP en NAT. Er is een vergadering met het cisco Voice Engineering-team en de klant vereist voor goedkeuring van dit type implementatie.