Betrachten wir einen hypothetischen Webex-Partner namens TelSP, um die verschiedenen Bereitstellungsmodelle zu veranschaulichen, die der Partner übernehmen kann.

Hier sind die allgemeinen Spezifikationen und Anforderungen von TelSP:

• Der Partner plant die Nutzung sip.telsp.com als Domäne der obersten Ebene, die von allen von ihnen verwalteten Kunden gemeinsam genutzt wird.

• Dem Partner gehört sip.telsp.com und kann die DNS-Infrastruktur und die Zertifizierungsstellen verwalten, DNS-Adressen verwalten und Zertifikate für diese Domäne und ihre Unterdomänen signieren.

• Der Partner kann zwei unterschiedliche Sitzungsrandcontroller (physisch oder virtuell) als lokale Gateways für den gemeinsamen PSTN-Zugriff unter Endkunden einsetzen.

• Der Partner verfügt über zwei physische Standorte, und beide Standorte teilen PSTN-Konnektivität:

  • Miami

  • Chicago

• TelSP betreibt ihre lokalen Gateways im Auftrag der beiden Kunden CustA und CustB, wie sie von hier aus genannt werden.

In diesem Artikel bezieht sich der Begriff „Partner“ auf den verwaltenden Webex-Partner, insbesondere TelSP in diesem Beispiel. Diese Entität hat Zugriff auf den Webex-Partner-Hub.

Das gewünschte Szenario ist die PSTN-Entstehung/Beendigung für beide Kunden, die die vom Partner bereitgestellten Miami- und Chicago-Gateways verwenden, wie in der Abbildung dargestellt:

Zuordnen des Kundenstandorts zu Trunk und Gateway

Webex Calling ermöglicht das Erstellen von Übertragungswegen und das Teilen eines Übertragungswegs über mehrere Standorte hinweg. Weisen Sie den Trunk beim Erstellen des Trunks einem Standort zu.

Für CustA sind die Trunk-Details wie folgt:

Die Abbildung zeigt die Zuordnung des Kundenstandorts zu Gateway und Trunk für CustA :

In dieser Bereitstellung ist der mit dem Standort verknüpfte Übertragungsweg die primäre PSTN-Verbindung für diesen Standort. Der andere Übertragungsweg wird als sekundäre PSTN-Verbindung oder Route für bestimmte Wählplaneinträge verwendet. Die Implementierung der primären und sekundären PSTN-Verbindungsbeziehung erfolgt durch ein Routen-Gruppenkonzept. Weitere Informationen finden Sie im Abschnitt Webex-Kundeneinrichtung .

Für CustB wird eine ähnliche Einrichtung mit den folgenden Übertragungswegen erstellt:

Die Abbildung zeigt die Zuordnung des Kundenstandorts zu Gateway und Trunk für CustB :

Die Abbildung zeigt einen dritten Standort, nämlich New York, den Sie später hinzufügen und auf den trunk_chicago Trunk als primäre PSTN-Verbindung verweisen können.

Bei der Bereitstellung eines lokalen Gateways, das mehrere Trunks teilt, VERWALTET Cisco die Verwendung eines eindeutigen FQDN pro Trunk. Weitere Informationen finden Sie unter Konfigurieren-Übertragungswege,-Routen-Gruppen und-Wählpläne-für-Webex-Calling .

Die Verwendung einer IP-Adresse und eines bekannten Ports pro Trunk ist eine ideale Wahl. Die Beschaffung einer öffentlichen IPv4-Adresse kann jedoch für einige Partner, die eine Adresse pro Gateway und Site verwenden möchten, eine Herausforderung darstellen.

Lesen Sie daher diese wichtigen Hinweise:

• Cisco weist keine IP-Adresse pro Übertragungsweg auf.

• Eine Übertragungsweg-Adresse kann zu einer eindeutigen IP-Adresse oder zur Adresse aufgelöst werden, die zwischen einem anderen Übertragungsweg geteilt wird.

• Cisco empfiehlt aus folgenden Gründen, einen eindeutigen Überwachungsport pro Übertragungsweg zu haben:

  1. Bietet eine Trennung der Netzwerkebene zwischen Kunden

  2. Es ist typisch für Session-Grenzcontroller, die ephemere TCP-Socket-Verbindung wiederzuverwenden, es sei denn, es wird eine Isolierung als eindeutiger Tenant bereitgestellt, der durch eine IP-Adresse oder einen eindeutigen Überwachungsport für den Tenant partitioniert wird.

  3. Verbindungen oder Verbindungen pro Übertragungsweg durch Tenant-Isolation bieten einen besseren Durchsatz speziell bei Netzwerkbedingungen mit hohem Datenverlust. Daher wirkt sich der Datenverkehr eines Kunden nicht auf den anderen aus.

IP-Adresse pro Gateway: Trunk-Konfiguration und Empfehlungen

Sehen Sie sich diese Beispiele für verschiedene Modelle für die Planung an:

Modell 1: Eindeutige IP-Adresse pro Trunk

In diesem Modell werden alle Trunks, die von beiden Gateways gehostet werden, zu einer eindeutigen IP-Adresse aufgelöst, und jeder dieser Trunks kann denselben Port verwenden oder auch nicht, aber im Idealfall denselben Port.

Darstellung der Informationen in tabellarischem Format:

In demselben Modell kann der Partner eine SRV-Adresse verwenden. Webex Calling erlaubt nur _sips._tcp als Kombination aus Dienst und Protokoll, die Peer-Adresse zu ermitteln, wenn es sich um einen SRV-Eintrag handelt.

Ein Beispiel dafür, wie ein SRV-Datensatz aufgelöst wird

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modell 2: Freigegebene IP auf einem Gateway, aber unterschiedliche Überwachungsports

In diesem Modell werden alle auf dem lokalen Gateway in Chicago gehosteten Trunks in dieselbe IP-Adresse aufgelöst und alle auf dem lokalen Gateway in Miami gehosteten Trunks in eine andere IP-Adresse aufgelöst. Wenn Sie jedoch dieselbe IP verwenden, wird jeder Übertragungsweg mit einem FQDN im Control Hub konfiguriert und mit einem eindeutigen Port konfiguriert.

In demselben Modell verwendet der Partner eine SRV-Adresse. Webex Calling erlaubt nur _sips._tcp als Kombination aus Dienst und Protokoll, die Peer-Adresse zu ermitteln, wenn es sich um einen SRV-Eintrag handelt.

Ein weiteres Beispiel dafür, wie ein SRV-Datensatz aufgelöst wird, ist wie folgt. In diesem Beispiel gibt es 1 A Datensatz pro IP-Adresse. Der Port ist jedoch pro Adresse eindeutig und wird durch eine bestimmte DNS-Konfiguration dargestellt, die eine SRV-Adresse mit dem richtigen Port verknüpft.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5062 miami.custa.sip.telsp.com

Der Partner besitzt telsp.com und seine Unterdomänen. Daher liegt der DNS-Server und die Behörde, um Zertifikate zu erhalten, die von einer genehmigten Zertifizierungsstelle signiert sind, beim Partner.

• Cisco Webex erwartet, dass der Partner die FQDN- oder SRV-Adresse einschließlich A-Einträge in der öffentlichen Domäne veröffentlicht.

• Cisco Webex erwartet, dass der Partner eine der in diesem Dokument genannten Zertifizierungsstellen verwendet.

Wenn Sie einen FQDN als Trunk-Adresse verwenden, richten Sie die signierten Zertifikate so ein, dass der allgemeine Name (CN) oder die Betreff Nummer alternative Nummer (SAN) auf die FQDNs für die Trunks festgelegt ist.

Verwenden Sie eine der folgenden Methoden, um die FQDNs im Zertifikat zu generieren:

• Wählen Sie einen der FQDNs als allgemeinen Namen (CN) und den Rest als Betreff Nummer alternative Nummer (SAN) aus.

• Platzieren Sie die Top-Level-Domäne (sip.telsp.com) als CN und alle FQDNs als SANs.

  In Zukunft können Sie das Zertifikat basierend auf der Domäne der obersten Ebene validieren, die mit dieser Konfiguration geeignet ist.

Wenn Sie einen SRV als Übertragungsweg-Adresse verwenden, richten Sie signierte Zertifikate mit dem CN oder SAN für den Host-Teil der SRV-Adresse ein. Der A-Datensatz oder CNAME, in den die SRV-Adresse aufgelöst wird, ist nicht erforderlich.

Gateway einrichten

Verwenden Sie diese Ressourcen, um ein lokales Gateway einzurichten.

Gehen Sie folgendermaßen vor, um Cisco CUBE einzurichten: Lokales Gateway unter Cisco IOS-XE für Webex Calling konfigurieren

Sie können genehmigte SBCs von Drittanbietern einrichten, siehe: Erste Schritte mit dem lokalen Gateway

Sie können den Gateway-Übertragungsweg im Voraus konfigurieren.

Richten Sie das vom Partner gehostete Gateway gemäß diesen Richtlinien ein: Erste Schritte mit dem lokalen Gateway

Legen Sie jeden Übertragungsweg gemäß den entsprechenden Anweisungen für das SBC-Gerät fest. Die Cisco CUBE-Anweisungen finden Sie unter: Lokales Gateway unter Cisco IOS-XE für Webex Calling konfigurieren

Richten Sie gemäß dem Bild Sprachklassen, Dial-Peers und Dial-Peer-Gruppen für den ein- und ausgehenden Datenverkehr für den Trunk ein:

Über den Partner-Hub können Sie den Control Hub für CustA oder CustB starten und das Gateway konfigurieren. Gehen Sie wie folgt vor, um für jeden Kunden Folgendes zu konfigurieren:

1. Trunk erstellen: Fügen Sie einen Trunk unter „Calling/Call Routing/Trunk“ für jedes gemeinsam genutzte Partner-Gateway hinzu. Informationen zum Einrichten eines Trunks finden Sie unter Konfigurieren von Trunks, Routen-Gruppen und Wählplänen für Webex Calling

2. Domäne hinzufügen und verifizieren – Fügen Sie die folgende Domäne hinzu, die zum Erstellen eines Übertragungswegs unter Management/Organisationseinstellungen/Domänen verwendet wird, und verifizieren Sie sie.

   Kunden	Kustz
   sip.telsp.com	sip.telsp.com

   Beim Hinzufügen einer Domäne wird ein Token generiert und im TXT-Datensatz für die Domäne im DNS-Server des Partners platziert. Mit diesem Datensatz kann Control Hub überprüfen, ob die Domäne im Besitz des Partners ist. Weitere Informationen finden Sie unter Domänen verwalten

   Da Die gemeinsame Domäne für die Verifizierung bei jedem Kunden verwendet wird. Da diese Überprüfung jedoch auf Kundenorganisationsebene erfolgt, stellen Sie sicher, dass auf jeder Kundenorganisation ein anderes Token für die Überprüfung generiert und verwendet wird. Da eine einzelne Domäne in Kundenorganisationen verwendet wird, kann keine Organisation den Domänenbesitz beanspruchen.

3. SBC-Adresse mit FQDN einrichten –

   Für das Miami-Gateway:

   Parameter	Kunden	Kustz
   Standort	Denver	Boston
   Name des Übertragungswegs	trunk_miami	trunk_miami
   Trunk-Typ	Zertifikatsbasiert	Zertifikatsbasiert
   Device Type (Gerätetyp)	z. B. Cisco Unified Border Element (oder ein anderes unterstütztes Gerät)	z. B. Cisco Unified Border Element (oder ein anderes unterstütztes Gerät)
   SBC-Adresstyp	FQDN	FQDN
   Hostname	trunk.miami.custa	trunk.miami.custb
   Domäne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Maximale Anzahl gleichzeitiger Anrufe (250-6500)	500	500

   Für das Chicago Gateway:

   Parameter	Kunden	Kustz
   Standort	Detroit (Detroit)	Dallas
   Name des Übertragungswegs	trunk_chicago	trunk_chicago
   Trunk-Typ	Zertifikatsbasiert	Zertifikatsbasiert
   Device Type (Gerätetyp)	z. B. Cisco Unified Border Element (oder ein anderes unterstütztes Gerät)	z. B. Cisco Unified Border Element (oder ein anderes unterstütztes Gerät)
   SBC-Adresstyp	FQDN	FQDN
   Hostname	trunk.chicago.custa	trunk.chicago.custb
   Domäne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Maximale Anzahl gleichzeitiger Anrufe (250-6500)	500	500

   (Optional) Sie haben keinen eindeutigen Namen für den Übertragungsweg für alle Kunden und der gleiche Name kann bei der Nachverfolgung des Übertragungswegs hilfreich sein. Bestimmte SBCs erlauben die Konfiguration desselben Ports, aber diese Konfiguration kann sich auf die Kapazität auswirken. Verwenden Sie daher verschiedene Ports.

4. Trunks verwenden: Wählen Sie einen beliebigen Speicherort für den Trunk aus, und zwar aufgrund der folgenden Gründe:

   • Jeder Standort kann den Trunk in einer PSTN-Verbindung verwenden.

   • Sie können über eine Routen-Gruppe auf den Übertragungsweg zugreifen.

   • Jeder Wählplan kann den Trunk verwenden.

5. Sehen Sie sich die Trunk-Definitionen mit den zugeordneten Standorten an:

   

   Sie können diese Übertragungswege verwenden, um Routen-Gruppen zu erstellen. Im Bild wird eine Routen-Gruppe rg_miami_chicago definiert, die Anrufe an den trunk_miami -Übertragungsweg als primäre Option und an den trunk_chicago -Übertragungsweg als sekundäre Option weiterleitet.

   

   Sie können eine zweite Routen-Gruppe rg_chicago_miami definieren, die Anrufe an den trunk_chicago -Übertragungsweg als primäre Option und an den trunk_miami -Übertragungsweg als sekundäre Option weiterleitet.

6. Die definierten Übertragungswege und Routen-Gruppen sind jetzt in der Option Calling Connection PSTN für jeden Standort verfügbar. Im Bild sehen Sie sich den Denver-Standort an.

   

7. Sie können die Übertragungswege und Routen-Gruppen in der Wählplan-Definition verwenden. Zum Beispiel: die Chicago Area NPAs sind aufgeteilt, um die rg_chicago_miami Routen-Gruppe (für alle Standorte) im Bild zu beenden: