Öffentliches Internet

Direkter SIP-Übertragungsweg (oben)

Der CUBE oder SBC des Kunden sollte auf einer öffentlichen IP platziert werden. Dies ist unser empfohlenes Standardbereitstellungsmodell.

Da dies der einfachste Ansatz ist, ist er auch der am wenigsten flexible. Die Vorteile einer vereinfachten Topologie sind eine einfache Verwaltung und Fehlerbehebung. Netzwerkdiagramme werden vom Kunden ausgefüllt und an das Sprachteam übermittelt, und Dial-Peers werden erstellt. Das Platzieren des CUBE in einer DMZ erleichtert den Umgang mit NAT. Der CUBE selbst ist eine Firewall, und die meisten mittleren/großen Anbieter platzieren ihren CUBE in einer öffentlichen IP und nutzen seine Sicherheitsfunktionen.

VPNs

Ein VPN ist eine andere Art von Verbindung, die öffentliches Internet verwendet. VPNs werden oft benötigt, wenn ein Kunde eine sichere Verbindung für SIP und RTP benötigt. Ein VPN ist möglicherweise auch erforderlich, wenn der Kunde den CUBE nicht in einem öffentlichen IP-Bereich platzieren kann. Für VPN-Verbindungen ist ein Bereitstellungsmeeting mit Sprachtechnik erforderlich.

Sprachports

• RTP: 8000 - 48199

• SIP: UPD 5060

IPSec-VPN oder IPSec über GRE

Die folgenden Optionen sind für VPN-Verbindungen verfügbar:

• SBC- zu SBC-Konnektivität

• GW-zu-GW-Konnektivität

Webex Contact Center (IPSec oder IPSec über GRE-Tunnel und Webex Contact Center S2S-Konnektivität) zur Verwendung von UDP/5060 statt TCP/5060

Ein IPSec-VPN oder IPSec über GRE ist eine gute Option für einen sicheren SIP-Übertragungsweg, wenn sich der CUBE auf einer öffentlichen IP befindet. Dies ist eine SBC-zu-SBC-Verbindung. (Abb. 2) Private IP-Adressschemata mit VPN-Tunneln müssen ebenfalls berücksichtigt werden, um Überschneidungen zwischen Kunden zu vermeiden. Für GRE-Verbindungen sind die IP-Subnetze: 10.x.248.x und 10.x.249.x.

Site-to-Site (S2S)

Eine S2S-Verbindung kann bereitgestellt werden, wenn der Kunde eine sichere Verbindung benötigt oder den CUBE nicht in einer öffentlichen IP platzieren kann. Dies ist eine Gateway-zu-Gateway-Verbindung. Es gibt keine Subnetze, die speziell für S2S VPN-Verbindungen vorgesehen sind, da das Routing auf interessantem Datenverkehr ohne Einbeziehung einer logischen Schnittstelle basiert.

SIP TLS und SRTP

Die Verwendung von SRTP/SIP TLS ist eine weitere Option, wenn sich der CUBE auf einer öffentlichen IP-Adresse befindet. Bei der Verwendung von SRTP/SIP TLS gibt es jedoch einen Performance-Hit. Ein CUBE-Gerät kann ein Drittel der SIP-Sitzungen verarbeiten, wenn Sie die Anrufe entweder mit TLS oder SRTP gesichert haben. Dies ist eine SBC-zu-SBC-Verbindung.

Um eine SIP-TLS-Verbindung herzustellen, müssen Zertifikate ausgetauscht werden. Folgende Optionen sind verfügbar:

• Selbstsignierte Zertifikate werden generiert und zwischen dem Kunden und dem Webex Contact Center ausgetauscht.

• Öffentliche Zertifizierungsstelle – Die folgenden Schritte müssen zur Unterstützung der öffentlichen Zertifizierungsstelle abgeschlossen werden:

  • Der Kunde muss das Stammzertifikat freigeben, das in den Webex Contact Center SBC geladen wird.

  • Der Kunde muss den DNS aktualisieren, um die IPs der Webex Contact Center SBCs aufzunehmen.

Private Konnektivität

Oft die Verbindungswahl großer Unternehmensanbieter, eine direkte Verbindung bietet eine dedizierte und sichere Schaltung. Wenn der Kunde eine direkte Verbindung benötigt, kann er im ersten Schritt das Dokument Cisco Webex Contact Center VPOP Circuit Order Guidelines (Richtlinien zur Bestellung von Cisco Webex Contact Center Voice Engineering) erhalten. Im nächsten Schritt muss ein weiteres Design-Meeting mit dem Webex Contact Center Voice Engineering-Team und den Kundeningenieuren durchgeführt werden. Der Kunde muss ein detailliertes Netzwerkdiagramm des Sprachnetzwerks des Kunden bereitstellen, das PSTN-Netzverbindungen für das Meeting enthält. Cisco hostet keine Kundengeräte.

Unabhängig davon, ob der Kunde MPLS, P2P, VPLS oder SD-WAN wählt, sieht die Topologie ähnlich aus und alle Schaltungen enden mit dem Webex Contact Center-Router/GW und nicht mit den Webex Contact Center-CUBEs.

Die Bandbreitenanforderungen für eine direkte Verbindung basieren auf dem G.711-Codec (~100 Kbit/s pro Call Leg), der zwei Call Legs pro Sitzung ermöglicht.

Rechenzentrum – Cross Connect

Wenn sich ein Kunde für eine private Verbindung entscheidet, müssen Rechenzentrum-Cross-Connects bestellt werden, wie im Dokument Cisco Webex Contact Center VPOP Circuit Bestellrichtlinien beschrieben. Der Kunde ist für die angefallenen Kosten und dafür verantwortlich, den Schaltkreis des Kunden an die angegebene Stelle zu bringen. (Abb. 6.)

Nicht standardmäßige Bereitstellungen

Wenn die empfohlenen Topologien nicht alle Anforderungen des Kundennetzwerks erfüllen, muss ein Design-Meeting mit dem Cisco Voice Engineering-Team über das Cisco Account Team des Kunden für einen speziellen Genehmigungsprozess angesetzt werden. Im Folgenden finden Sie Beispiele für nicht standardmäßige und nicht empfohlene Bereitstellungen:

A2Q-Ausnahmen

PSTN-Anbieter, die den Schaltkreis direkt mit dem Webex Contact Center-VPOP beenden.

Gold-Mandanten-Ausnahmen

Wir empfehlen dringend einen direkten SIP-Übertragungsweg für Gold Tenant-Kunden. Dies ist die Top-Topologie, bei der der CUBE in einem öffentlichen IP-Bereich platziert wird. Der Bedarf an einem Gold Tenant besteht oft bei größeren Anbietern; der Anbieter verlangt jedoch, dass der Gold Tenant ein Machbarkeitsnachweis für die beabsichtigte Produktionsbereitstellung des Anbieters ist. Der Machbarkeitsnachweis, den Gold Tenant häufig über die Verwendung eines offenen Internetzugangs für einen SIP-Trunk hinausgeht, würde einen der zuvor besprochenen Verbindungstypen erfordern.

Gold Tenant-Kunden werden nicht überwacht.

Öffentliches Internet – CUBE hinter der Firewall

Eine weitere Bereitstellungsoption ist das Platzieren eines CUBE auf einer privaten IP-Adresse hinter einer NAT-Firewall. Die Sicherheitsanforderungen der IT-Abteilung des Kunden können vorschreiben, dass die Sprachanwendung hinter einer Firewall steht. Diese Option hat einige bekannte Nachteile. Auch wenn dies keine Probleme auf der Netzwerkebene verursacht, kann es zu Problemen auf der SIP-Anwendungsebene kommen. Die private IP-Adresse wird in den SIP-Nachrichten verwendet, was zu Fehlern bei der Anrufverarbeitung führt. Die Firewall-Kapazität ist ein weiterer Faktor, der bei dieser Art von Bereitstellung berücksichtigt werden muss. Firewalls müssen für den Umgang mit VoIP-Datenverkehr entsprechend dimensioniert sein; andernfalls kann die Firewall zu einem Engpass werden und die Anrufqualität und Anrufverarbeitung beeinträchtigen.

Im Folgenden sind die Nachteile dieser Bereitstellung aufgeführt:

• Mögliche CUBE-Konfigurations- und Einrichtungsprobleme zu Beginn.

• Erhöhte Belastung der Firewall, die sich auf die Sprachqualität auswirken könnte.

• Der Kunde ist für die CUBE-Einrichtung und die Dimensionierung der Firewall verantwortlich.

• Keine empfohlene Topologie aufgrund der Auswirkungen auf SLAs.