Danke für Ihr Feedback.

Lassen Sie uns einen hypothetischen Webex-Partner namens TelSP betrachten, um die verschiedenen Bereitstellungsmodelle zu veranschaulichen, die der Partner übernehmen kann.

Hier sind die allgemeinen Spezifikationen und Anforderungen von TelSP:

• Der Partner plant, sip.telsp.com als Top-Level-Domain zu verwenden, die von allen von ihm verwalteten Kunden gemeinsam genutzt wird.

• Der Partner besitzt sip.telsp.com und kann die DNS-Infrastruktur und die Zertifizierungsstellen verwalten, DNS-Adressen verwalten und Zertifikate für diese Domain und ihre Subdomains signieren.

• Der Partner kann zwei verschiedene Session Border Controller (physisch oder virtuell) als Local Gateways für den gemeinsamen PSTN-Zugang zwischen Endkunden einsetzen.

• Der Partner hat zwei physische Standorte, und beide Standorte teilen sich die PSTN-Konnektivität:

  • Miami

  • Chicago

• TelSP betreibt ihre lokalen Gateways im Namen der beiden Kunden Custa und CustB, wie sie hier genannt werden.

Das gewünschte Szenario sieht vor, dass beide Kunden die vom Partner bereitgestellten Gateways in Miami und Chicago per PSTN nutzen, wie in der Abbildung dargestellt:

Beispiel für eine vereinfachte Bereitstellung

Das folgende vereinfachte Beispiel zeigt, wie die Peer-Cert-Identität es einem einzelnen Zertifikat ermöglicht, mehrere Kundenleitungen zu unterstützen:

• Zertifikat — sip.telsp.com

• Koffer

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identität des Peer-Zertifikats — sip.telsp.com

• Ergebnis

  • Es wird ein einziges Zertifikat verwendet

  • Mehrere Kundenleitungen werden unterstützt

Verknüpfung des Kundenstandorts mit Trunk und Gateway

Die folgenden Abschnitte enthalten detaillierte Konfigurationszuordnungen für die oben beschriebene Bereitstellung.

Webex Callingermöglicht die Erstellung von Trunks und die gemeinsame Nutzung eines Trunks an mehreren Standorten. Wenn Sie den Trunk erstellen, verknüpfen Sie den Trunk mit einem Standort.

Für CuSTA lauten 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 Trunk die primäre PSTN-Verbindung für diesen Standort. Der andere Trunk 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 Routengruppen-Konzept. Einzelheiten finden Sie im Abschnitt Gateway-Trunks konfigurieren im Abschnitt Control Hub.

Für CustB wird ein ähnliches Setup mit den folgenden Trunks 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 sich mehrere Trunks teilt, schreibt Cisco die Verwendung eines eindeutigen FQDN pro Trunk vor. Einzelheiten finden Sie unter Configure-Trunks, -route-groups, -and-dial-plans-for-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 pro Standort verwenden möchten, eine Herausforderung sein.

Lesen Sie daher diese wichtigen Hinweise:

• Cisco schreibt keine IP-Adresse pro Trunk vor.

• Eine Trunk-Adresse kann in eine eindeutige IP-Adresse oder in die Adresse aufgelöst werden, die von einem anderen Trunk gemeinsam genutzt wird.

• Cisco empfiehlt aus den folgenden Gründen, jede Trunk-Verbindung mit einer eindeutigen Kombination aus IP-Adresse und Port auf dem Local Gateway zu konfigurieren:

  1. Die Aufrechterhaltung separater TCP-Verbindungslinks pro Trunk unterstützt die maximale Kapazität für gleichzeitige Anrufe pro Trunk. Die gemeinsame Nutzung von IP-Adressen und Portkombinationen über Trunks kann sich negativ auf die Anrufkapazität auswirken.

  2. Sorgt für Isolierung zwischen Kunden auf Netzwerkebene

  3. Es ist typisch, dass Session Border Controller die kurzlebige TCP-Socket-Verbindung wiederverwenden, es sei denn, es gibt eine Isolierung, die als eindeutiger Mandant, partitioniert durch eine IP-Adresse oder einen eindeutigen Listen-Port für den Mandanten, bereitgestellt wird.

  4. Eine Verbindung oder Verbindungen pro Trunk durch Mandantenisolierung bieten einen besseren Durchsatz, insbesondere bei Netzwerkbedingungen mit hohem Datenverlust. Daher wirkt sich der Traffic eines Kunden nicht auf den anderen aus.

IP-Adresse pro Gateway: Trunk-Konfiguration und Empfehlungen

Sehen Sie sich diese Beispiele verschiedener Planungsmodelle an:

Modell 1: Eindeutige IP-Adresse pro Trunk

In diesem Modell lösen alle Trunks, die von beiden Gateways gehostet werden, auf eine eindeutige IP-Adresse auf und jeder dieser Trunks kann denselben Port verwenden oder auch nicht, aber idealerweise denselben Port.

Darstellung der Informationen in einem tabellarischen Format:

In demselben Modell kann der Partner eine SRV-Adresse verwenden. Webex Callingerlaubt nur „_Schlucke“. _tcp“ als die Kombination aus Dienst und Protokoll, um die Peer-Adresse zu ermitteln, falls es sich um einen SRV-Datensatz 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: Gemeinsame IP pro Gateway, eindeutige Abhörports

In diesem Modell werden alle Trunks, die auf dem Chicago Local Gateway gehostet werden, auf dieselbe IP-Adresse aufgelöst und alle Trunks, die auf dem Miami Local Gateway gehostet werden, werden auf eine andere IP aufgelöst. Wenn jedoch dieselbe IP verwendet wird, wird jeder Trunk mit einem FQDN im Control Hub konfiguriert und mit einem eindeutigen Port konfiguriert.

In demselben Modell verwendet der Partner eine SRV-Adresse. Webex Callingerlaubt nur „_Schlucke“. _tcp“ als die Kombination aus Dienst und Protokoll, um die Peer-Adresse zu ermitteln, falls es sich um einen SRV-Datensatz 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 repräsentiert, 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.sip.telsp.com

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

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

Für SRV-basierte Trunks wird die Peer-Cert-Identität zunächst aus den konfigurierten SRV-Werten aufgefüllt und kann gemäß denselben Validierungsregeln angepasst werden.

Dem Partner gehören telsp.com und seine Subdomains. Daher liegen der DNS-Server und die Befugnis, Zertifikate von einer zugelassenen Zertifizierungsstelle signieren zu lassen, beim Partner.

• Cisco Webexerwartet, dass der Partner die FQDN- oder SRV-Adresse einschließlich A Records gemeinfrei veröffentlicht.

• Cisco Webexerwartet, dass der Partner eine der in diesem Dokument aufgeführten Zertifizierungsstellen verwendet.

Bei der Konfiguration von Trunks mit FQDN oder SRV:

• Jeder Trunk muss immer noch einen eindeutigen FQDN für Routing und Identifizierung haben

• DNS-Einträge (A Record oder SRV) müssen korrekt konfiguriert und auflösbar sein

• Diese FQDNs werden für Signalisierung und Routing verwendet. Die Zertifikatsvalidierung wird anhand der konfigurierten Peer-Cert-Identität durchgeführt, die standardmäßig die Trunk-FQDN-Werte verwendet, aber an eine gemeinsame, partnereigene Identität angepasst werden kann.

  Das Feld für die Identität des Peer-Zertifikats wird vorab aus dem Trunk-FQDN ausgefüllt und kann mit einer gemeinsamen, partnereigenen Domain überschrieben werden, um ein einziges Zertifikat für mehrere Kunden-Trunks zu verwenden.

Richten Sie das Gateway ein

Verwenden Sie diese Ressourcen, um ein lokales Gateway einzurichten.

Um Cisco CUBE einzurichten, verwenden Sie dieses Verfahren: Local Gateway auf Cisco IOS XE konfigurieren für Webex Calling

Sie können zugelassene Drittanbieter-SBCs einrichten, siehe: Erste Schritte mit Local Gateway

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

Stellen Sie jeden Trunk gemäß den entsprechenden Anweisungen für das SBC-Gerät ein. Die Cisco CUBE-Anweisungen finden Sie unter: Local Gateway auf Cisco IOS XE konfigurieren für Webex Calling

Richten Sie Sprachkurse ein, wählen Sie Peers und wählen Sie Peer-Gruppen für eingehenden und ausgehenden Verkehr für den Trunk gemäß dem Bild:

Bei der Bereitstellung eines Trunks bietet Control Hub eine Option zur Konfiguration der Peer-Cert-Identität auf der Seite Trunk hinzufügen. Diese Erweiterung vereinfacht den Arbeitsablauf, indem sie es Partnern ermöglicht, eine einzige Top-Level-Domain für mehrere Kundenorganisationen zu konfigurieren und wiederzuverwenden. Dieser Ansatz macht separate Zertifikate pro Kunde oder Trunk überflüssig, was den Betriebsaufwand reduziert und den Einrichtungsprozess vereinfacht.

Definieren Sie bei der Konfiguration von Trunks in Control Hub eine Peer-Cert-Identität, um die Verwendung eines einzigen Zertifikats für Ihre Top-Level-Domain in allen Kundenorganisationen zu ermöglichen. Stellen Sie sicher, dass die CN oder SAN des Zertifikats diese Top-Level-Domain enthält. Mit Peer-Cert-Identität verwendet das lokale Gateway ein einziges Zertifikat, dessen CN oder SAN die gemeinsame Domain des Partners enthält (zum Beispiel sip.telsp.com). Platzhalterzertifikate (zum Beispiel *.sip.telsp.com) werden nicht unterstützt. Webex Callingakzeptiert dieses Zertifikat für jeden Kunden-Trunk, der explizit mit diesem Wert als Peer-Zertifikatsidentität konfiguriert ist. Das Zertifikat muss den exakt konfigurierten Peer-Cert-Identitätswert in seinem CN oder SAN enthalten. Dadurch entfällt die Notwendigkeit, separate Zertifikate oder CN/SAN-Einträge für einzelne Trunk-FQDNs zu konfigurieren.

Domainverifizierung und Zertifikatsnutzung

Es ist wichtig zu verstehen, wie sich die Domainverifizierung von der Verwendung von Zertifikaten unterscheidet:

• Domainverifizierung (pro Kunde) — Jede Kundenorganisation muss die Domain unabhängig verifizieren (zum Beispiel sip.telsp.com), indem sie einen eindeutigen TXT-Eintrag im DNS hinzufügt. Dies stellt sicher, dass der Partner Eigentümer der Domain ist, und verhindert eine unbefugte Nutzung.

• Zertifikatsverwaltung (global) — Ein einziges Zertifikat, das für die Top-Level-Domain des Partners ausgestellt wurde, kann mithilfe der Peer-Cert-Identität von allen Kundenleitungen gemeinsam genutzt werden. Es ist nicht erforderlich, separate Zertifikate pro Kunde oder pro Trunk zu führen.

Identitätsverhalten von Peer-Cert

Die Peer-Cert-Identität definiert die Identität, die in dem vom lokalen Gateway vorgelegten Zertifikat Webex Calling erwartet wird.

Wenn konfiguriert:

• Webex Callingvalidiert das Zertifikat, indem es die konfigurierte Peer-Zertifikatsidentität mit dem CN oder SAN im Zertifikat abgleicht

• Wenn die Werte übereinstimmen, wird die TLS-Verbindung akzeptiert

• Wenn die Werte nicht übereinstimmen, wird die Verbindung abgelehnt

Nur Trunks, die explizit mit der passenden Peer-Cert-Identität konfiguriert wurden, dürfen sich authentifizieren.

Die Zertifikatsvalidierung allein ist nicht die einzige Prüfung, die während der Authentifizierung durchgeführt wird. Zusätzlich zur Validierung des Zertifikats CN oder SAN anhand der konfigurierten Peer-Zertifikatsidentität wird Webex Calling auch überprüft, ob der Trunk-FQDN explizit konfiguriert und mit der entsprechenden Peer-Zertifikatsidentität in Control Hub verknüpft ist.

Die Identität des Peer-Zertifikats wird vorab aus den Trunk-FQDN/SRV-Werten ausgefüllt. Wenn Sie die Standardeinstellungen beibehalten, ist das bestehende Verhalten der Zertifikate pro Trunk unverändert. Bestehende zertifikatsbasierte Trunks funktionieren weiterhin ohne Änderungen. Sie können in Ihrem eigenen Tempo eine gemeinsame Peer-Cert-Identität für neue oder bestehende Trunks annehmen, und beide Modelle können koexistieren.

1. Gültiges Konfigurationsbeispiel:

   • Zertifikat CN — sip.telsp.com

   • Zertifikat SAN — custa.sip.telsp.com

   • Identität des Peer-Zertifikats — custa.sip.telsp.com

   • Stamm-FQDN — trunk.miami.custa.sip.telsp.com

   Ergebnis — Die Verbindung ist erfolgreich, weil die Peer-Zertifikatsidentität (custa.sip.telsp.com) mit dem SAN-Wert im Zertifikat übereinstimmt und der Trunk-FQDN (trunk.miami.custa.sip.telsp.com) eine Subdomain der konfigurierten Peer-Cert-Identität ist.

2. Beispiel für einen Verbindungsfehler:

   • Zertifikat CN — sip.telsp.com

   • Zertifikat SAN — custa.sip.telsp.com

   • Identität des Peer-Zertifikats — custb.sip.telsp.com

   • Stamm-FQDN — trunk.miami.custb.sip.telsp.com

   Ergebnis — Die Verbindung schlägt beim TLS-Handshake fehl, weil die Identität des Peer-Zertifikats (custb.sip.telsp.com) nicht im CN oder SAN des Zertifikats vorhanden ist. Der Trunk-FQDN ist korrekt eine Subdomain der Peer-Zertifikatsidentität, aber das Zertifikat trägt diese Identität nicht.

3. Ungültiges Konfigurationsbeispiel:

   • Zertifikat CN — sip.telsp.com

   • Zertifikat SAN — custa.sip.telsp.com

   • Identität des Peer-Zertifikats — custa.sip.telsp.com

   • Stamm-FQDN — trunk.miami.custb.sip.telsp.com

   Ergebnis — Control Hub lehnt diese Konfiguration zur Speicherzeit ab, weil der Trunk-FQDN (trunk.miami.custb.sip.telsp.com) nicht der konfigurierten Peer-Cert-Identität (custa.sip.telsp.com) entspricht oder eine Unterdomäne davon ist.

Vom Partner Hub aus können Sie den Control Hub für CuStA oder CustB starten und das Gateway konfigurieren. Verwenden Sie dieses Verfahren, um für jeden Kunden Folgendes zu konfigurieren:

1. Den Trunk erstellen — Fügen Sie einen Trunk unter Calling/Call Routing/Trunk für jedes gemeinsame Partner-Gateway hinzu. Um einen Trunk einzurichten, siehe Trunks, Routengruppen und Wählpläne konfigurieren für Webex Calling

2. Eine Domain hinzufügen und verifizieren — Fügen Sie die folgende Domain hinzu und verifizieren Sie sie, die verwendet wird, um einen Trunk unter Management/Organisationseinstellungen/Domains zu erstellen.

   Kunde B	Kunde C
   sip.telsp.com	sip.telsp.com

   Beim Hinzufügen einer Domain wird ein Token generiert und in den TXT-Eintrag für die Domain auf dem DNS-Server des Partners eingefügt. Mit diesem Datensatz kann Control Hub überprüfen, ob die Domain dem Partner gehört. Einzelheiten finden Sie unter Ihre Domains verwalten

   Die gemeinsame Domain wird für die Überprüfung jedes Kunden verwendet. Da diese Überprüfung jedoch auf der Ebene der Kundenorganisation erfolgt, stellen Sie sicher, dass für jede Kundenorganisation ein anderes Token generiert und für die Überprüfung verwendet wird. Weil eine einzige Domain in allen Kundenorganisationen verwendet wird und jede Kundenorganisation die Domain unabhängig anhand eines eindeutigen TXT-Eintrags verifizieren muss, auch wenn sie dieselbe Domain teilt.

   Für die Peer-Cert-Identität ist nur eine Domainverifizierung erforderlich. Beantragen Sie die gemeinsame Domain nicht bei einer Kundenorganisation. Eine Domain kann nur von einer Organisation beansprucht werden, während dieselbe Domain in mehreren Organisationen verifiziert werden kann.

3. SBC-Adresse mit FQDN einrichten —

   Für das Miami Gateway:

   Parameter	Kunde B	Kunde C
   Standort	Denver	Boston
   Name des Übertragungswegs	Trunk_Miami	Trunk_Miami
   Kofferraumtyp	Zertifikatsbasiert	Zertifikatsbasiert
   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	LGW. Miami	LGW. Miami
   Domäne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	LGW.MIAMI.CUSTOMERB.SIP.TELSP.com: 5061	LGW.Miami.CustomerC.SIP.Telsp.com: 5062
   Maximale Anzahl gleichzeitiger Anrufe (250-6500)	500	500

   Für das Chicago Gateway:

   Parameter	Kunde B	Kunde C
   Standort	Detroit	Dallas
   Name des Übertragungswegs	Trunk_Chicago	Trunk_Chicago
   Kofferraumtyp	Zertifikatsbasiert	Zertifikatsbasiert
   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	LGW. Chicago	LGW. Chicago
   Domäne	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	LGW.Chicago.CustomerB.SIP.TELSP.com: 5061	LGW.Chicago.CustomerC.SIP.Telsp.com: 5062
   Maximale Anzahl gleichzeitiger Anrufe (250-6500)	500	500

   • (Optional) Trunk-Namen müssen in allen Kundenorganisationen nicht eindeutig sein. Wenn Sie denselben Namen wiederverwenden (zum Beispiel trunk_miami), lässt sich der Kofferraum leichter verfolgen.

   • Bestimmte SBCs ermöglichen die Konfiguration desselben Anschlusses, aber diese Konfiguration kann sich auf die Kapazität auswirken. Verwenden Sie daher andere Anschlüsse.

4. Peer-Cert-Identität —

   • Präfix — Das Präfix ist optional. Lassen Sie das Feld leer, um die Identität des Peer-Zertifikats nur auf die Domain festzulegen. Dies ist das in diesem Artikel verwendete Modell für gemeinsame Zertifikate (Peer Cert Identity — sip.telsp.com, deckt alle Kundenleitungen ab). Geben Sie optional ein Präfix ein, um eine spezifischere Zertifikatidentität zu definieren (z. B. Präfix: CustomerB, Domain: CustomerB.sip.telsp.com für ein kundenspezifisches Zertifikat). Der Trunk-FQDN selbst bleibt durch die Felder SBC-Adresse, Hostname und Domain definiert und muss der resultierenden Peer-Cert-Identität entsprechen oder eine Unterdomäne davon sein.

     Beispiel:

     Präfix — Kunde B

     Domäne — sip.telsp.com

     Ergebnis — customerb.sip.telsp.com

   • Domain: Wählen Sie eine Domain aus der Liste der in der Kundenorganisation verifizierten Domains aus. Die resultierende Peer-Cert-Identität (Präfix und Domain) muss mit der CN oder SAN des Zertifikats übereinstimmen, das Ihr SBC vorlegt. Webex Callingverwendet diesen Wert, um die TLS-Verbindung zu authentifizieren.

     

     Control Hub lehnt diese Konfiguration zur Speicherzeit ab, da der Trunk-FQDN nicht unter der konfigurierten Peer-Cert-Identität steht.

     Wenn die Identität des Peer-Zertifikats nicht mit der CN oder SAN in dem vom SBC vorgelegten Zertifikat übereinstimmt, Webex Calling lehnt er die TLS-Verbindung ab und der Trunk kann nicht hergestellt werden.

5. Verwendung von Trunks — Wählen Sie aus folgenden Gründen einen beliebigen Standort für den Kofferraum:

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

   • Sie können über eine Routengruppe auf den Trunk zugreifen.

   • Jeder Wählplan kann den Kofferraum nutzen.

6. Sehen Sie sich die Trunk-Definitionen mit den zugehörigen Standorten an:

   

   Sie können diese Trunks verwenden, um Routengruppen zu erstellen. Im Bild ist eine Routengruppe rg_miami_chicago definiert, die Anrufe an den Trunk_Miami-Trunk als primäre Option und an den Trunk_Chicago-Trunk als sekundäre Option weiterleitet.

   

   Sie können eine zweite Routengruppe rg_chicago_miami definieren, die Anrufe an den Trunk_Chicago-Trunk als primäre Option und an den Trunk_Miami-Trunk als sekundäre Option weiterleitet.

7. Die definierten Trunks und Routengruppen sind jetzt in der Option Calling Connection PSTN für jeden Standort verfügbar. Auf dem Bild sehen Sie den Standort Denver.

   

8. Sie können die Trunks und Routengruppen in der Wählplandefinition verwenden. Zum Beispiel wird ein lokaler Rufnummernbereich in Chicago für den Kunden aufgeteilt, sodass er zur RG_Chicago_Miami-Routengruppe (für alle Standorte) im Bild endet:

   

   

Bereitstellung im großen Maßstab mit APIs

Partner, die eine große Anzahl von Kundenorganisationen verwalten, können Domains in großem Umfang mithilfe von APIs anstelle der Benutzeroberfläche bereitstellen.

• Domain verifizieren

• Anrufweiterleitung