Openbaar internet

Directe SIP-trunk (over de bovenkant)

De CUBE of SBC van de klant moet op een openbaar IP-adres worden geplaatst. Dit is ons aanbevolen standaardimplementatiemodel.

Aangezien dit de meest simplistische aanpak is, is het ook de minst flexibele. De voordelen van een vereenvoudigde topologie zijn eenvoudig beheer en probleemoplossing. Netwerkdiagrammen worden door de klant ingevuld en ingediend bij het spraakteam, en dial peers worden gemaakt. Het plaatsen van de CUBE in een DMZ vermindert de complexiteit van het omgaan met NAT. De CUBE zelf is een firewall en de meeste middelgrote/grote providers plaatsen hun CUBE in een openbaar IP en gebruiken de beveiligingsmogelijkheden.

VPN's

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

Spraakpoorten

• rtp: 8000 - 48199

• SIP: udp 5060

IPSec VPN of IPSec via GRE

De volgende opties zijn beschikbaar voor VPN-connectiviteit:

• Verbinding tussen SBC en SBC

• Verbinding van GW naar GW

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

Een IPSec VPN of IPSec via GRE is een goede optie voor een veilige SIP-trunk als de CUBE zich op een openbaar IP bevindt. Dit is een SBC-naar-SBC-verbinding. (Afb. 2) met VPN-tunnels moeten ook privé IP-adresschema's worden overwogen om overlapping tussen klanten te voorkomen. Voor GRE-verbindingen zijn de IP-subnetten: 10.x.248.x en 10.x.249.x.

Site-to-site (S2S)

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

SIP TLS en SRTP

SRTP/SIP TLS gebruiken is een andere optie wanneer de CUBE zich op een openbaar IP-adres bevindt. Er is echter een prestatieshit 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, is het noodzakelijk certificaten uit te wisselen. De volgende opties zijn beschikbaar:

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

• Openbare certificeringsinstantie – de volgende stappen moeten worden uitgevoerd om openbare certificeringsinstanties te ondersteunen:

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

  • De klant moet de DNS bijwerken om de IP's van de Webex Contact Center-SBC's op te nemen.

Privéconnectiviteit

Vaak is de verbinding keuze van grote enterprise providers, een directe verbinding biedt een specifiek en veilig circuit. Als de klant een rechtstreekse verbinding nodig heeft, kan de klant het document Richtlijnen voor circuitvolgorde van Cisco Webex Contact Center VPOP ontvangen als de eerste stap, en een follow-upontwerpvergadering met het Webex Contact Center Voice Engineering-team en de klantingenieurs moeten als volgende stap worden uitgevoerd. De klant moet voor de vergadering een gedetailleerd netwerkdiagram van het spraaknetwerk van de klant, inclusief PSTN-interconnects van de provider. Cisco zal geen apparatuur van klanten hosten.

Ongeacht of de klant MPLS, P2P, VPLS of SD-WAN kiest, ziet de topologie er vergelijkbaar uit en worden alle circuits beëindigd met Webex Contact Center-router/GW en niet met Webex Contact Center-CUBE's.

De bandbreedtevereisten voor een directe verbinding zijn gebaseerd op de G.711-codec (~100 kbps per gespreksgedeelte), wat twee gespreksgedeelten per sessie mogelijk maakt.

Kruisverbinding met datacenter

Als een klant beslist over een privéverbinding, moet er een kruisverbinding met het datacenter worden besteld, zoals beschreven in het document Richtlijnen voor bestellingen van het VPOP-circuit van Cisco Webex Contact Center. De klant zal verantwoordelijk zijn voor de gemaakte kosten en om het circuit van de klant naar de aangegeven daling te brengen. (Afb. 6.)

Niet-standaard implementaties

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

A2Q-uitzonderingen

PSTN-provider die het circuit rechtstreeks naar Webex Contact Center VPOP beëindigt.

Gouden tenantuitzonderingen

We raden sterk een directe SIP-trunk voor klanten van Gold Tenant aan. Dit is de over-the-top topologie waarbij de CUBE in een openbare IP-ruimte wordt geplaatst. De behoefte aan een Gold Tenant bestaat vaak bij grotere providers; de provider vereist echter dat de Gold Tenant een proof of concept is voor de beoogde productie-implementatie van de provider. Het proof of concept Gold Tenant overschrijdt vaak het gebruik van open internettoegang voor een SIP-trunk en vereist een van de eerder besproken verbindingstypen.

Klanten van Gold Tenant worden niet gecontroleerd.

Openbaar internet - CUBE achter firewall

Een andere implementatieoptie is het plaatsen van een CUBE op een privé IP-adres achter een NAT-firewall. De beveiligingsvereisten van de IT-afdeling van de klant kunnen bepalen dat de spraaktoepassing achter een firewall moet worden geplaatst. Deze optie heeft een aantal bekende nadelen. Hoewel dit mogelijk geen problemen veroorzaakt in de netwerklaag, kan het leiden tot problemen in de SIP-toepassingslaag. Het privé IP-adres wordt in de SIP-berichten gebruikt, waardoor gespreksverwerkingsfouten worden veroorzaakt. Firewallcapaciteit is een andere factor waarmee bij dit type implementatie rekening moet worden gehouden. De afmetingen van firewalls moeten correct zijn aangepast om VoIP-verkeer te verwerken. Anders kan de firewall een knelpunt worden en de gesprekskwaliteit en -verwerking beïnvloeden.

Dit zijn de nadelen van deze implementatie:

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

• Verhoogde belasting van de firewall die invloed kan hebben op de spraakkwaliteit.

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

• Geen aanbevolen topologie vanwege impact op SLA's.