Fünf wichtige Schritte zur Vorbereitung der Bereitstellung von Cisco Spark-Hybrid-Diensten

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

Die Relevanz der folgenden fünf Punke für die Cisco Spark Hybrid-Dienstebereitstellung

 

In diesem Dokument werden die fünf wichtigsten Konfigurationselemente detailliert erläutert, die im Zusammenhang mit Cisco Spark-Hybrid-Diensten auftreten.

  

Diese fünf Punkte sind äußerst wichtig für eine erfolgreiche Bereitstellung von Expressway-gehosteten Cisco Spark-Hybrid-Diensten (Anrufdienst Aware/Connect- und Kalender-Dienst). Diese fünf möchten wir aus folgenden Gründen besonders herausstellen:

  
  •  

    Wir möchten sie erläutern, damit Sie Ihre Rolle in einer Hybrid-Bereitstellung besser verstehen und sich sicher fühlen.

      

  •  

    Dabei handelt es sich um obligatorische Vorraussetzungen, die für eine sichere Bereitstellung zwischen unserer Cloud und Ihrer lokalen Umgebung sorgen.

      

  •  

    Sie sollten als wesentliche Aktivitäten betrachtet werden: die Einrichtung kann etwas länger als eine typische Konfiguration auf einer Benutzeroberfläche in Anspruch nehmen, berücksichtigen Sie also einen ausreichenden Zeitrahmen für die Einordnung dieser Elemente.

      

  •  

    Nachdem diese Elemente in Ihrer Umgebung eingeordnet wurden, verläuft die Konfiguration der restlichen Cisco Spark-Hybrid-Dienste reibungslos.

      

  

TCP-Port 5062 in der Internet-Firewall

 

Über die Expressway-C- und Expressway-E-Bereitstellung sind Anrufe mithilfe der Firewall-Traversal-Technologien über das Internet möglich. Durch diese Bereitstellung wird Ihre lokale Anrufsteuerung über die Cisco Collaboration Cloud sicher mit Cisco Spark verbunden.

Für Expressway-C und Expressway-E müssen wegen der Traversalarchitektur der Firewall keine Eingangsports in der demilitarisierten Zone (DMZ) der Firewall geöffnet werden. Die TCP SIP-Signalports und UDP-Medienports müssen jedoch für eingehende Verbindungen in der Internet-Firewall geöffnet werden, damit eingehende Anrufe durchkommen. Dafür muss die Zeitspanne zum Öffnen des entsprechenden Ports in Ihrer Unternehmensfirewall berücksichtigt werden.

 
Die Traversalarchitektur der Firewall wird im folgenden Diagramm dargestellt:


Für eingehende Business-to-Business-Anrufe (B2B) über das SIP-Protokoll müssen beispielsweise die TCP-Ports 5060 und 5061 (5061 wird für SIP TLS eingesetzt) in der externen Firewall geöffnet werden, außerdem müssen die UDP-Medienports für Dienste wie Voice, Video, Inhaltsfreigabe, Dualvideo usw. geöffnet werden. Welche Medienports geöffnet werden müssen, hängt von der Anzahl gleichzeitiger Anrufe und der Anzahl von Diensten ab.

 

Sie können den SIP-Überwachungsport in Expressway auf einen Wert zwischen 1024 und 65534 konfigurieren. Gleichzeitig muss dieser Wert und der Protokolltyp in den öffentlichen DNS-SRV-Datensätzen angekündigt werden und derselbe Wert muss in der Internet-Firewall geöffnet werden.

 

Obwohl der Standardport für SIP TCP 5060 und für SIP TLS 5061 lautet, können auch andere Ports verwendet werden, wie das folgende Beispiel zeigt.

 

In diesem Beispiel wird davon ausgegangen, dass Port 5062 für eingehende SIP TLS-Anrufe verwendet wird.

 

Der DNS-SRV-Datensatz für ein Cluster aus zwei Expressway-Servern sieht folgendermaßen aus:

_sips._tcp.example.com SRV-Dienstadresse:

Priorität = 10

 

Gewichtung = 10

 

Port = 5062

 

SVR-Hostname = us-expe1.example.com

_sips._tcp.example.com SRV-Dienstadresse:

Priorität = 10

 

Gewichtung = 10

 

Port = 5062

 

SVR-Hostname = us-expe2.example.com

 

Dieser Datensatz bedeutet, dass Anrufe an us-expe1.example.com und us-expe2.example.com mit gleichmäßiger Lastverteilung (Priorität und Gewichtung) und TLS als Transporttyp sowie 5062 als Überwachungsportnummer weitergeleitet werden.

 

Ein einen SIP-Anruf an einen Benutzer der Unternehmensdomäne (user1@example.com) tätigendes externes Gerät (im Internet) muss die DNS abfragen, damit es in Erfahrung bringen kann, welchen Transporttyp, welche Portnummer, wie die Lastenverteilung gestaltet werden muss und an welche SIP-Server der Anruf gesendet werden muss.

 

Der DNS-Eintrag umfasst _sips._tcp, in dem Eintrag ist das SIP TLS angegeben.

 

TLS ist ein Client-Server-Protokoll, bei dem in den gängigsten Umsetzungen Zertifikate zur Authentifizierung eingesetzt werden. In einem Business-to-Business-Anrufszenario ist der TLS-Client der Anrufapparat und der TLS-Server der angerufene Apparat. Mit TLS überprüft der Client das Serverzertifikat und wenn die Zertifikatsüberprüfung fehlschlägt, wird der Anruf getrennt. Der Client benötigt kein Zertifikat.

Der TLS-Handshake wird im folgenden Diagramm veranschaulicht:


 

Die TLS-Spezifikation gibt an, dass der Server das Client-Zertifikat ebenfalls überprüfen kann, indem er in dem TLS-Handshakeprotokoll eine Zertifikatsanforderungsmeldung an den Client sendet. Diese Meldung ist nützlich bei einer Server-zu-Server-Verbindung, wie z. B. bei einer Verbindung, die zwischen Expressway-E und der Cisco Collaboration Cloud hergestellt wird. Dieses Konzept wird als TLS mit gegenseitiger Authentifizierung bezeichnet und ist bei der Integration mit Cisco Spark erforderlich.

 
Der Anrufer und Angerufene überprüfen das Zertifikat des anderen Gesprächsteilnehmers, wie das folgende Diagramm veranschaulicht:


 

Die Cloud überprüft die Expressway-Identität und Expressway überprüft die Cloud-Identität. Wenn beispielsweise die Cloud-Identität im Zertifikat (CN oder SAN) nicht mit der Konfiguration in Expressway übereinstimmt, wird die Verbindung abgebrochen.

 

Wenn die gegenseitige Authentifizierung aktiviert wird, fordert Expressway-E stets das Client-Zertifikat an. Infolge dessen funktioniert der Mobile and Remote Access (MRA) nicht, da Zertifikate bei den meisten Jabber-Clients nicht bereitgestellt werden. Kann der Anrufer in einem Business-to-Business-Szenario kein Zertifikat angeben, wird der Anruf getrennt.

 

Wir empfehlen, dass Sie einen anderen Wert als 5061 für TLS mit gegenseitiger Authentifizierung verwenden, z. B. Port 5062. Cisco Spark-Hybrid-Dienste verwenden bei SIP TLS den gleichen Eintrag wie für B2B. Im Fall von Port 5061 funktionieren einige Dienste nicht, die kein TLS-Client-Zertifikat bereitstellen können.

     

Datenverkehr für Business-to-Business, Mobile und Remote Access und Spark auf demselben Expressway-Paar

Business-to-Business- und Mobile und Remote Access-Anrufe verwenden Port 5061 für SIP TLS und für Cisco Spark-Datenverkehr wird Port 5062 für SIP TLS mit gegenseitiger Authentifizierung eingesetzt.

Gründe für die Überprüfung des Domänenbesitzes durch die Cloud

Die Domänenbesitz-Überprüfung ist Teil der Identitätsverifizierung. Die Domänenverifizierung ist eine Sicherheitsmaßnahme und eine Identitätsüberprüfung, die in der Cisco Collaboration Cloud implementiert ist, damit Sie nachweisen können, dass Sie derjenige sind, für den Sie sich ausgeben.

 

Die Identitätsüberprüfung wird in zwei Stufen vorgenommen:

  1. Domänenbesitz-Überprüfung. Dieser Schritt umfasst drei Arten von Domänen und es handelt sich dabei um eine einmalige Verifizierungsüberprüfung:

     

    • E-Mail-Domäne

       

    • Expressway-E DNS-Domäne

       

    • Verzeichnis-URI-Domäne

       

  2. Expressway-E DNS-Name-Besitz-Überprüfung. Dieser Schritt wird durch die Implementierung des TLS mit gegenseitiger Authentifizierung vorgenommen und umfasst den Einsatz öffentlicher Zertifikate in der Cloud und in Expressway. Im Gegensatz zur Domänenidentitätsüberprüfung wird dieser Schritt während eines über die Cloud getätigten und von der Cloud angenommenen Anrufs durchgeführt.

     

       

Ein Bericht zur Veranschaulichung der Relevanz der Domänenbesitz-Überprüfung

Die Cisco Collaboration Cloud führt die Domänenbesitz-Überprüfung zur Durchsetzung der Sicherheit durch. Identitätsdiebstahl ist eine mögliche Bedrohung in dieser Überprüfung, er wird jedoch im Rahmen dieser Überprüfung nicht geprüft.

 

In den folgenden Berichtsdetails wird veranschaulicht, was passieren kann, wenn die Domänenbesitz-Überprüfung nicht durchgeführt wird.

 

Ein Unternehmen, bei dem die DNS-Domäne auf "hacker.com" festgelegt ist, erwirbt Cisco Spark Hybrid Services. Ein anderes Unternehmen, bei dem die eigene Domäne auf "example.com“; festgelegt ist, setzt ebenfalls Hybrid Services ein. Eine der Geschäftsführerinnen des Unternehmens Example.com heißt Jane Roe und besitzt die Verzeichnis-URI jane.roe@example.com.

 

Der Administrator des Unternehmens Hacker.com legt eine ihrer Verzeichnis-URIs auf jane.roe@example.com und die E-Mail-Adresse auf jane.roe@hacker.com fest. Das kann sie machen, da die Cloud die SIP URI-Domäne in diesem Beispiel nicht überprüft.

 

Als Nächstes meldet Sie sich mit jane.roe@hacker.com bei Cisco Spark an. Da sie die Domäne besitzt, wird die Verifizierungs-E-Mail gelesen und beantwortet und sie kann sich anmelden. Schließlich ruft sie einen Kollegen an, John Doe, indem Sie in Ihrem Cisco Spark-Client john.doe@example.com wählt. John sitzt in seinem Büro und sieht auf seinem Videogerät einen eingehenden Anruf von jane.roe@example.com; das ist die mit dem E-Mail-Konto verknüpfte Verzeichnis-URI.

 

„;Sie ist im Ausland“;, denkt er. „;Vielleicht ist es wichtig." Er nimmt das Gespräch an und die falsche Jane Roe fragt nach wichtigen Dokumenten. Sie erklärt ihm, dass ihr Gerät kaputt ist und da sie unterwegs ist, bittet sie ihn, die Dokumente an ihre private E-Mail-Adresse zu senden, jane.roe@hacker.com. Auf diesem Weg bemerkte das Unternehmen erst nach der Rückkehr von Jane Roe im Büro, dass Unternehmensinformationen nach außen durchgesickert sind.

 

Das Unternehmen Example.com hat viele Maßnahmen zum Schutz vor betrügerischen Anrufen aus dem Internet ergriffen, ein Verantwortungsbereich der Cisco Collaboration Cloud besteht jedoch darin, sicherzustellen, dass die Identität des Anrufers aus Cisco Spark korrekt ist und nicht gefälscht wurde.

 

Für die Identitätsüberprüfung muss Cisco Spark einen Unternehmensnachweis sicherstellen, dass die in Spark-Hybridanrufen verwendeten Domänen dem Unternehmen gehören. Falls es das nicht kann, funktioniert Cisco Spark Hybrid Services nicht.

 

Damit dieser Besitz sichergestellt werden kann, sind zwei Verifizierungsschritte erforderlich:

  1. Es muss ein Nachweis erbracht werden, dass das Unternehmen die E-Mail-Domäne, Expressway-E-Domäne, Verzeichnis-URI-Domäne besitzt.

      

    •  

      All diese Domänen müssen routingfähig und den öffentlichen DNS-Servern bekannt sein.

        

    •  

      Für den Nachweis des Besitzes muss der DNS-Administrator einen DNS-Textdatensatz (TXT) eingeben. Ein TXT-Datensatz ist eine Art Ressourcendatensatz im DNS, mit dem beliebiger und unformatierter Text mit einem Host- oder anderen Namen verknüpft werden kann.

        

    •  

      Der DNS-Administrator muss den TXT-Datensatz in den Bereich eingeben, dessen Besitz nachgewiesen werden muss. Nach diesem Schritt führt Cisco Collaboration Cloud eine TXT-Datensatzabfrage für die Domäne durch.

        

    •  

      Wenn die TXT-Abfrage erfolgreich ist und das Ergebnis mit dem in Cisco Collaboration Cloud generierten Token übereinstimmt, ist die Domäne verifiziert.

        

    •  

      Der Administrator muss beispielsweise nachweisen, dass er die Domäne "example.com“; besitzt, wenn Cisco Spark und Cisco Spark Hybrid Services mit der Domäne funktionieren sollen.

        

    •  
      Der Administrator startet den Verifizierungsvorgang über das Verwaltungsportal, indem er einen TXT-Datensatz erstellt, der mit dem in Cisco Collaboration Cloud generierten Token übereinstimmt:


        
    •  
      Der DNS-Administrator erstellt anschließend einen TXT-Datensatz für diese Domäne, dabei wird der Wert auf 123456789abcdef123456789abcdef123456789abcdef123456789abcdef festgelegt, siehe folgendes Beispiel:


        
    •  

      Zu diesem Zeitpunkt kann die Cloud verifizieren, dass der TXT-Datensatz für die Domäne example.com mit dem Token übereinstimmt.

        

    •  
      Die Cloud führt eine TXT DNS-Suche durch:


        
    •  

      Da der TXT-Wert mit dem Tokenwert übereinstimmt, wird mit dieser Übereinstimmung nachgewiesen, dass der Administrator den TXT-Datensatz für die eigene Domäne zum öffentlichen DNS hinzugefügt hat und Besitzer der Domäne ist.

        

     
  2. Expressway-E DNS-Name-Besitz-Überprüfung.

      

    •  

      Die Cloud muss überprüfen, dass Expressway-E eine bestätigte Identität von einer Zertifizierungsstelle besitzt, der die Cloud vertraut. Der Expressway-E-Admininstrator muss für Expressway-E von einer der Zertifizierungsstellen ein öffentliches Zertifikat anfordern. Zum Ausstellen des Zertifikats führt die Zertifizierungsstelle einen Identitätsverifizierungsvorgang durch, der auf einer Domänenvalidierungsüberprüfung (für domänenvalidierte Zertifikate) oder Organisationsvalidierungsüberprüfung (für organisationsvalidierte Zertifikate) basiert.

        

    •  

      Anrufe in und aus der Cloud hängen von dem Zertifikat ab, das für Expressway-E ausgestellt wurde. Wenn das Zertifikat ungültig ist, wird die Verbindung getrennt.

        

    

Unterstützte Zertifizierungsstellen

Der Expressway-C-Connector-Host muss in der Cisco Collaboration Cloud registriert sein, damit die Hybrid Services funktionieren.

 

Expressway-C wird im internen Netzwerk bereitgestellt und die Cloud-Registrierung erfolgt durch eine ausgehende HTTPS-Verbindung – dieselbe Art von Verbindung wird von Browsern für eine Webserververbindung verwendet.

 

Bei der Registrierung und Verbindung mit Cisco Collaboration Cloud wird TLS eingesetzt. Expressway-C ist der TLS-Client und Cisco Collaboration Cloud ist der TLS-Server. Deshalb überprüft Expressway-C das Serverzertifikat.

 

Die Zertifizierungsstelle signiert ein Serverzertifikat mit einem eigenen privaten Schlüssel. Jeder mit dem öffentlichen Schlüssel kann die Signatur entschlüsseln und nachweisen, dass dieselbe Zertifizierungsstelle das Zertifikat signiert hat.

 

Wenn Expressway-C das von der Cloud bereitgestellte Zertifikat validieren muss, muss es den öffentlichen Schlüssel der Zertifizierungsstelle verwenden, die das Zertifikat zum Entschlüsseln der Signatur signiert hat. Im Zertifikat der Zertifizierungsstelle ist ein öffentlicher Schlüssel enthalten. Um eine Vertrauensstellung mit den von der Cloud eingesetzten Zertifizierungsstellen herzustellen, muss im Vertrauensspeicher von Expressway eine Liste der Zertifikate dieser vertrauenswürdigen Zertifizierungsstellen enthalten sein. Dabei kann Expressway verifizieren, dass der Anruf wirklich aus der Cisco Collaboration Cloud stammt.

 

Beim manuellen Upload können Sie alle relevanten Zertifikate der Zertifizierungsstellen in den Vertrauensspeicher von  Expressway-C hochladen.

 

Beim automatischen Upload lädt die Cloud diese Zertifikate in den Vertrauensspeicher von Expressway-C hoch. Wir empfehlen die Verwendung des automatischen Uploads. Die Zertifikatsliste kann sich ändern und der automatische Upload stellt sicher, dass Sie die aktuellste Liste erhalten.

 

Wenn Sie die automatische Installation der Zertifikate von Zertifizierungsstellen zulassen, werden Sie zu Cisco Cloud Collaboration Management (das Verwaltungsportal) umgeleitet. Die Umleitung wird von Expressway-C ohne Benutzereingriff vorgenommen. Sie als Cisco Spark-Administrator müssen die Authentifizierung über eine HTTPS-Verbindung durchführen. Kurz darauf leitet die Cloud die CA-Zertifikate per Push an Expressway-C.

 

Die HTTPS-Verbindung kann erst hergestellt werden, nachdem die Zertifikate in den Vertrauensspeicher von Expressway-C hochgeladen wurden.

 

Zur Vermeidung dieses Problems ist Expressway-C bereits mit vertrauenswürdigen CA-Zertifikaten für Cisco Spark vorinstalliert. Diese Zertifikate dienen nur für die Einrichtung und Validierung der ersten HTTPS-Verbindung und sie werden nicht in der Vertrauensliste von Expressway-C angezeigt. Nachdem die Zertifikate der vertrauenswürdigen Zertifizierungsstellen über die HTTPS-Verbindung abgerufen wurden, stehen diese Zertifikate zur plattformweiten Nutzung zur Verfügung; anschließend werden sie in der Vertrauensliste von Expressway-C angezeigt.

 
Aus folgenden Gründen ist dieser Vorgang sicher:
  •  

    Dazu ist ein Administratorzugriff auf Expressway-C und Cisco Cloud Collaboration Management (admin.ciscospark.com) erforderlich. Diese Verbindungen verwenden HTTPS und sind verschlüsselt.

      

  •  

    Zertifikate werden aus der Cloud per Push über dieselbe verschlüsselte Verbindung an Expressway geleitet.

      

   

In dieser Liste sind die Zertifikate der Zertifizierungsstellen aufgeführt, die die Cisco Collaboration Cloud aktuell verwendet. Diese Liste kann sich zukünftig ändern:

  • C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

     

  • C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

     

  • C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

     

  • C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

     

  • C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

     

  • C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

     

  • C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

     

  

Für Expressway-E im Traversal-Paar ist ebenfalls eine Liste von Zertifikaten der Zertifizierungsstellen erforderlich. Expressway-E kommuniziert über SIP mit TLS mit der Cisco Collaboration Cloud, das durch die gegenseitige Authentifizierung erzwungen wird. Expressway-E vertraut aus der Cloud stammenden und in die Cloud getätigten Anrufen nur, wenn der CN oder SAN des während der TLS-Verbindungseinrichtung durch die Cloud bereitgestellten Zertifikats mit dem Antragstellernamen übereinstimmt, der für die DNS-Zone in Expressway ("callservice.ciscospark.com“;) konfiguriert ist. Die Zertifizierungsstelle veröffentlicht ein Zertifikat erst nach der Identitätsüberprüfung. Der Besitz der Domäne callservice.ciscospark.com muss nachgewiesen werden, damit ein signiertes Zertifikat bereitgestellt werden kann. Da wir (Cisco) die Domäne besitzen, ist der DNS-Name "callservice.ciscospark.com" der direkte Nachweis, dass es sich bei der Gegenstelle wirklich um die Cisco Collaboration Cloud handelt.

 

Exchange-Identitätswechselkonto

 

Der Kalender-Connector integriert Cisco Spark in Microsoft Exchange 2010, 2013, 2016 oder Office 365 über ein Identitätswechselkonto. Mithilfe der Anwendungsidentitätswechsel-Verwaltungsrolle in Exchange können Anwendungen die Identität von Benutzern in einer Organisation annehmen, um Vorgänge im Namen des Benutzers durchzuführen. Die Anwendungsidentitätswechselrolle muss in Exchange konfiguriert werden und dient auf dem Kalender-Connector als Teil der Exchange-Konfiguration auf der Expressway-C-Oberfläche.

Das Exchange-Identitätswechselkonto ist die für diese Aufgabe von Microsoft empfohlene Methode. Der Zugriff über Exchange-Webdienste (EWS) mithilfe des Identitätswechselkontos ist aus folgenden Gründen sicher:

  • Der Zugriff ist für Benutzer nicht verfügbar und EWS-Verbindungen können über TLS geschützt werden.

     

  • Das Konto kann nur über EWS verwendete werden; Benutzer mit Zugriff auf ein Konto mit Identitätswechselrechten müssten eine EWS-Anwendung schreiben, um auf das Postfach eines Benutzers zuzugreifen und könnten nicht direkt über einen Postfach-Client auf das Postfach zugreifen.

     

  • Das Passwort für das Identitätswechselkonto wird verschlüsselt in Expressway-C gespeichert.

     

  

Deshalb müssen die Expressway-C-Administratoren das Passwort nicht kennen, da der Wert von einem Exchange-Administrator über die Expressway-C-Oberfläche eingegeben werden kann. Das Passwort wird nicht als Klartext dargestellt, selbst wenn der Expressway-C-Administrator über Stammzugriff auf das Expressway-C-Feld verfügt.

 

Die Sicherheit gewährleistet, dass nur die Expressway-C-Anwendung das Passwort verwendet.

 

Bereitstellung mit mehreren Expressways

Der Expressway-C-Connector-Host kann mit bis zu sechs Servern geclustert sein. In Szenarien mit mehreren Unified CM-Clustern in unterschiedlichen Regionen können Sie mehrere Expressway-C-Cluster bereitstellen – eines pro Unified CM-Cluster – sie unterstützen nur lokale Redundanz. Wenn einer der Expressway-C-Knoten ausfällt, stellt ein anderer Knoten im Cluster die Verbindung zu Cisco Collaboration Cloud und Unified CM her. Geografische Redundanz wird derzeit nicht unterstützt.

Für SIP-Signalisierung und Medien verwendete Expressway-C und Expressway-E

   

Sie können mehrere Expressway-C- und Expressway-E-Cluster in verschiedenen Regionen besitzen. Unified CM verwendet die nächstgelegenen Expressway-Cluster für ausgehende Anrufe von Unified CM an die Cisco Collaboration Cloud, auf Grundlage der Partitionen und Anrufsuchbereichskonfiguration.

  

Für eingehende Anrufe müssen Sie wissen, wie Sie den Datenverkehr zwischen den unterschiedlichen Expressway-E-Clustern des Internet Edge trennen können.

  
  •  

    Wenn die Internet Edges in demselben Rechenzentrum oder demselben Gebiet bereitgestellt werden, kann auf DNS SRV-Ebene ein Lastenausgleich stattfinden. Wenn ein Unternehmensnetzwerk beispielsweise drei Internet Edges umfasst, die für Spark-Hybrid-Anrufe eingesetzt werden, bei dem jedes aus einem Cluster von zwei Expressway-E- und Expressway-C-Knoten besteht, umfasst _sips._tcp.example.com alle sechs Expressway-E-Datensätze (3 Expressway-Es multipliziert mit 2) mit der gleichen Priorität und Gewichtung. Dieser Aufbau verteilt die Anrufe aus der Cisco Collaboration Cloud gleichmäßig auf die verschiedenen Expressway-E- und Expressway-C-Cluster.

      

  •  

    Wenn die Internet Edges in verschiedenen Regionen bereitgestellt werden, ist die beste Lösung die Nutzung von Geo DNS-Diensten.

      

    Geo DNS-Dienste werden von vielen DNS-Anbietern bereitgestellt und basieren auf der Möglichkeit von Geo DNS zur Überprüfung der Quell-IP-Adresse, dem Verständnis, welchem Land oder welcher Region diese IP-Adresse angehört und der Weiterleitungsoption der Anforderung an das Edge, das am nächsten an der Region gelegen ist. Beachten Sie, dass ein Hybrid-Anruf an Expressway-E aus der Cisco Collaboration Cloud stammt und nicht direkt vom Spark-Client. Deshalb ist die Quell-IP-Adresse eine der IP-Adressen, die die Cisco Collaboration Cloud verwendet.

      

    Auf Grundlage dieser Klassifizierung und der Konfiguration in Geo DNS wird der Anruf an den Expressway-E gesendet, der sich am nächsten an der Zone befindet, dem die Anrufer-IP-Adresse angehört.

      

  
AWS Geo DNS-Dienste werden beispielsweise folgendermaßen konfiguriert:


  

Nachdem der SRV-Datensatz erstellt wurde, wird eine "Location" Kennzeichnung angewendet und das Land wird angegeben. Ein Anruf aus der Cloud mit einer IP-Adresse, die Teil des gleichen Standorts ist (in diesem Beispiel Italien), wird an emea-expe1.example.com gesendet. Viele SRV-Datensätze können auf Grundlage der Anzahl von Regionen erstellt werden.

  

Die Konfiguration der Geo DNS hängt vom DNS-Anbieter ab und dieses Konfigurationsbeispiel dient lediglich zu Referenzzwecken.

  
Falls zwei unterschiedliche Expressway-C- und Expressway-E-Cluster in den USA und EMEA bereitgestellt werden, ist der DNS SRV-Datensatz _sips._tcp.example.com als Teil von zwei unterschiedlichen Zonen konfiguriert. Für die Nutzung von AWS sind zwei DNS SRV-Datensätze für _sips._tcp.example.com erforderlich, wie das folgende Beispiel zeigt:


  

So wird ein die Cisco Collaboration Cloud in den USA verlassender Anruf auf den Expressway-E in den USA geleitet, und nur wenn das Expressway-E-Cluster in den USA nicht verfügbar ist, wird das Expressway-E-Cluster in EMEA verwendet. Wenn der Anruf die Cisco Collaboration Cloud in EMEA verlässt, wird er an das Expressway-E-Cluster in EMEA geleitet und das US-Cluster wird nur genutzt, wenn das EMEA-Cluster nicht verfügbar ist.

  
 

Attachments

    Outcomes