Betrachten wir einen hypothetischen Webex-Partner namens TelSP, um die verschiedenen Bereitstellungsmodelle zu veranschaulichen, die dieser Partner anwenden kann.

Hier sind die wichtigsten Spezifikationen. & Anforderungen an TelSP:

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

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

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

• Der Partner verfügt über zwei physische Standorte, die beide über eine gemeinsame PSTN-Anbindung verfügen:

  • Miami

  • Chicago

• TelSP betreibt seine lokalen Gateways im Auftrag der beiden Kunden CustA und CustB, wie sie im Folgenden genannt werden.

Das gewünschte Szenario ist, dass PSTN verfügbar ist. origination/termination für beide Kundengruppen, die die vom Partner bereitgestellten Gateways in Miami und Chicago nutzen, wie in der Abbildung dargestellt:

Zuordnung des Kundenstandorts zu Trunk und Gateway

Webex Calling ermöglicht die Erstellung von Trunks und die gemeinsame Nutzung eines Trunks über mehrere Standorte hinweg. Beim Erstellen des Stammes muss dieser einem Standort zugeordnet werden.

Für CustA lauten die Details zum Kofferraum wie folgt:

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

Bei dieser Bereitstellung ist der dem Standort zugeordnete 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 Realisierung der primären und sekundären PSTN-Verbindungsbeziehung erfolgt über ein Routengruppenkonzept. Weitere Informationen finden Sie im Abschnitt Webex-Kundeneinrichtung.

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 als primären PSTN-Anschluss auf den trunk_chicago -Stamm verweisen können.

Bei der Bereitstellung eines lokalen Gateways, das mehrere Trunks gemeinsam nutzt, schreibt Cisco die Verwendung eines eindeutigen FQDN pro Trunk vor. Weitere Informationen 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 sich jedoch für einige Partner als schwierig erweisen, die pro Gateway und Standort eine Adresse verwenden möchten.

Lesen Sie daher diese wichtigen Hinweise:

• Cisco schreibt keine IP-Adresse pro Trunk vor.

• Eine Trunk-Adresse kann entweder zu einer eindeutigen IP-Adresse oder zur Adresse, die von einem anderen Trunk gemeinsam genutzt wird, aufgelöst werden.

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

  1. Durch die Aufrechterhaltung separater TCP-Verbindungslinks pro Trunk wird die maximale Kapazität gleichzeitiger Anrufe pro Trunk unterstützt. Die gemeinsame Nutzung von IP-Adressen und Portkombinationen über mehrere Leitungen hinweg kann die Gesprächskapazität negativ beeinflussen.

  2. Bietet eine Netzwerkisolation zwischen Kunden

  3. Es ist typisch für Session Border Controller, die ephemere TCP-Socket-Verbindung wiederzuverwenden, es sei denn, es wird eine Isolation in Form eines eindeutigen Mandanten bereitgestellt, der durch eine IP-Adresse oder einen eindeutigen Listen-Port für den Mandanten partitioniert ist.

  4. Durch die Mandantenisolierung wird eine Verbindung oder mehrere Verbindungen pro Trunk ermöglicht, was insbesondere bei Netzwerkbedingungen mit hohem Datenverlust einen besseren Durchsatz gewährleistet. Daher hat der Datenverkehr eines Kunden keine Auswirkungen auf den anderen.

IP-Adresse pro Gateway: Trunk-Konfiguration und Empfehlungen

Beachten Sie diese Beispiele verschiedener Planungsmodelle:

Modell 1: Jedem Trunk wird eine eindeutige IP-Adresse zugewiesen.

In diesem Modell werden alle von beiden Gateways gehosteten Trunks auf eine eindeutige IP-Adresse aufgelöst, und jeder dieser Trunks kann denselben Port verwenden oder auch nicht, idealerweise jedoch denselben Port.

Darstellung der Informationen in tabellarischer Form:

In diesem Modell kann der Partner eine SRV-Adresse verwenden. Webex Calling erlaubt nur die Kombination aus „_sips._tcp“ als Dienst und Protokoll, um 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: Gemeinsame IP-Adresse auf einem Gateway, aber unterschiedliche Listen-Ports

In diesem Modell werden alle Trunks, die über das lokale Gateway in Chicago gehostet werden, auf dieselbe IP-Adresse aufgelöst, während alle Trunks, die über das lokale Gateway in Miami gehostet werden, auf eine andere IP-Adresse aufgelöst werden. Bei Verwendung derselben IP-Adresse wird jedoch jeder Trunk im Control Hub über einen FQDN konfiguriert und erhält einen eindeutigen Port.

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

Ein weiteres Beispiel für die Auflösung eines SRV-Datensatzes sieht wie folgt aus. In diesem Beispiel existiert ein A-Record pro IP-Adresse. Allerdings ist der Port pro Adresse eindeutig und wird durch eine spezifische 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

Der Partner besitzt telsp.com und seine Subdomains. Daher liegt die Verantwortung für den DNS-Server und die Befugnis, Zertifikate von einer zugelassenen Zertifizierungsstelle signieren zu lassen, beim Partner.

• Cisco Webex erwartet vom Partner, dass er die FQDN- oder SRV-Adresse einschließlich der A-Records öffentlich zugänglich macht.

• Cisco Webex erwartet, dass der Partner eine der in diesem Dokument veröffentlichten Zertifizierungsstellen verwendet.

Wenn Sie einen FQDN als Trunk-Adresse verwenden, richten Sie die signierten Zertifikate so ein, dass der Common Name (CN) oder die Subject Number Alternative Number (SAN) auf die FQDNs für die Trunks gesetzt ist.

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

• Wählen Sie einen der FQDNs als Common Name (CN) und die übrigen als Subject Number Alternative Number (SAN).

• Tragen Sie die Top-Level-Domain (sip.telsp.com) als CN und alle FQDNs als SANs ein.

  Zukünftig können Sie das Zertifikat anhand der Top-Level-Domain validieren, die dieser Konfiguration zugeordnet ist.

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

Gateway einrichten

Nutzen Sie diese Ressourcen, um ein lokales Gateway einzurichten.

Um Cisco CUBE einzurichten, gehen Sie wie folgt vor: Lokales Gateway unter Cisco IOS-XE für Webex Calling konfigurieren

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

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

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

Richten Sie Sprachklassen, Wählverbindungen und Wählverbindungsgruppen für den eingehenden und ausgehenden Datenverkehr des Trunks gemäß der Abbildung ein:

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

1. Erstellen Sie den Kofferraum – Fügen Sie einen Kofferraum hinzu unter Calling/Call Routing/Trunk für jedes Partner-Gateway. Informationen zum Einrichten eines Trunks finden Sie unter Trunks, Routinggruppen und Wählpläne für Webex Calling konfigurieren

2. Fügen Sie eine Domäne hinzu und überprüfen Sie diese – Fügen Sie die folgende Domäne hinzu und überprüfen Sie diese, die zum Erstellen eines Trunks unter verwendet wird. Management/Organization Settings/Domains.

   CustA	CustB
   sip.telsp.com	sip.telsp.com

   Beim Hinzufügen einer Domain wird ein Token generiert und im TXT-Eintrag für die Domain auf dem DNS-Server des Partners platziert. Dieser Datensatz ermöglicht es Control Hub zu überprüfen, ob die Domain dem Partner gehört. Weitere Informationen finden Sie unter Domains verwalten

   Da die gemeinsame Domäne zur Verifizierung jedes einzelnen Kunden verwendet wird. Da diese Überprüfung jedoch auf Ebene der Kundenorganisation erfolgt, muss sichergestellt werden, dass für jede Kundenorganisation ein anderes Token generiert und zur Überprüfung verwendet wird. Da eine einzige Domain von allen Kundenorganisationen genutzt wird, kann keine einzelne Organisation die Domain für sich beanspruchen.
3. SBC-Adresse mit FQDN einrichten—

   Für das Tor nach Miami:

   Parameter	CustA	CustB
   Standort	Denver	Boston
   Name des Übertragungswegs	trunk_miami	trunk_miami
   Trunk-Typ	Zertifikatsbasierte	Zertifikatsbasierte
   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 Tor zu Chicago:

   Parameter	CustA	CustB
   Standort	Detroit	Michael
   Name des Übertragungswegs	trunk_chicago	trunk_chicago
   Trunk-Typ	Zertifikatsbasierte	Zertifikatsbasierte
   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) Es ist nicht notwendig, für jeden Kunden einen individuellen Namen für den Trunk zu verwenden; ein einheitlicher Name kann die Nachverfolgung des Trunks erleichtern.

   • Bei manchen SBCs ist die Konfiguration desselben Ports möglich, diese Konfiguration kann sich jedoch auf die Kapazität auswirken. Verwenden Sie daher andere Anschlüsse.

4. Verwendung von Trunks – wählen Sie aufgrund folgender Gründe einen beliebigen Standort für den Trunk:

   • Der Trunk kann an jedem Standort in einer PSTN-Verbindung genutzt werden.

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

   • Jeder Wählplan kann die Amtsleitung nutzen.

5. Siehe die Stammdefinitionen mit den zugehörigen Standorten:

   

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

   

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

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

   

7. Sie können die Trunks und Routengruppen in der Wählplandefinition verwenden. Beispielsweise wird ein lokaler Rufnummernbereich in Chicago für den Kunden aufgeteilt, um an die rg_chicago_miami Routengruppe (für alle Standorte) im Bild zu enden: