- Startseite
- /
- Artikel
Konfigurieren eines vom Partner gehosteten Gateways
Diese Anweisungen richten sich an Partner, die ein Gateway hosten möchten. Lesen Sie die Best Practices und Empfehlungen durch.
Webex Calling ermöglicht es einem Kunden, einen Trunk des lokalen Gateways so zu konfigurieren, dass er einen PSTN-Anruf sendet und empfängt. Wenn ein Partner Übertragungswege von verschiedenen Kunden hostet, wird empfohlen, ein gemeinsames Gateway für diese Übertragungswege einzurichten.
Dieses Dokument skizziert ein übergeordnetes Schema für die Implementierung eines von einem Partner gehosteten Gateways und konzentriert sich auf das zertifikatbasierte Trunking. Das registrierungsbasierte Modell ist ein einfaches Modell für ein vom Partner gehostetes Gateway, das eine Lösung für Trunks mit kleinerer Kapazität bietet. Diese Lösung weist inhärente technische Einschränkungen für Trunks mit hoher Kapazität speziell für TCP-basiertes Datenverkehr- und Verbindungsfreigabemodell auf. Der Hauptgrund für das Erstellen von zertifikatbasierten Übertragungswegen ist die Lösung der Skalenbeschränkungen des registrierungsbasierten Modells.
Das Verfahren für die Trunk-Erstellung und Gateway-Konfiguration ähnelt dem vom Kunden gehosteten lokalen Gateway. Einzelheiten finden Sie unter: Erste Schritte mit dem lokalen Gateway
Überlegungen zur Bereitstellung
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,
sip.telsp.com
als Domäne der obersten Ebene 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 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.
Standort | Kunden | Keule B |
---|---|---|
Standorte, die Miami Gateway als primäres PSTN-Ziel verwenden |
Denver |
Michael |
Standorte, die Chicago Gateway als primäres PSTN-Ziel verwenden |
Detroit (Detroit) |
Boston |
Für einen Kunden ausgewählte Unterdomäne | custa.sip.telsp.com | custb.sip.telsp.com |
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:
Name des Übertragungswegs | FQDN | Zugeordneter Standort in Trunk-Definition |
---|---|---|
trunk_miami | trunk.miami.custa.sip.telsp.com | Denver |
trunk_chicago | trunk.chicago.custa.sip.telsp.com | Detroit (Detroit) |
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:
Name des Übertragungswegs | FQDN | Zugeordneter Standort in Trunk-Definition |
---|---|---|
trunk_miami | trunk.miami.custb.sip.telsp.com |
Michael |
trunk_chicago | trunk.chicago.custb.sip.telsp.com |
Boston |
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 Übertragungsweg als primäre PSTN-Verbindung verweisen können.
Anforderungen zum Konfigurieren der IP-Adresse
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:
-
Bietet eine Trennung der Netzwerkebene zwischen Kunden
-
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.
-
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:
Übertragungsweg-Adresse (FQDN) | IP-Adresse | Port |
---|---|---|
trunk.miami.custa.sip.telsp.com | 10.170.158.200 | 5061 |
trunk.miami.custb.sip.telsp.com | 10.170.158.201 | 5061 |
trunk.chicago.custa.sip.telsp.com | 10.170.158.100 | 5061 |
trunk.chicago.custb.sip.telsp.com | 10.170.158.101 | 5061 |
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.
Übertragungsweg-Adresse (SRV) | SRV-Adresse | Eine Aufzeichnung | IP-Adresse | Port |
---|---|---|---|---|
trunk.miami.custa.sip.telsp.com | _sips._tcp.trunk.miami.custa.sip.telsp.com | miami.custa.sip.telsp.com | 10.170.158.200 | 5061 |
trunk.miami.custb.sip.telsp.com | _sips._tcp.trunk.miami.custb.sip.telsp.com | miami.custb.sip.telsp.com | 10.170.158.201 | 5061 |
trunk.chicago.custa.sip.telsp.com | _sips._tcp.trunk.chicago.custa.sip.telsp.com | chicago.custa.sip.telsp.com | 10.170.158.100 | 5061 |
trunk.chicago.custb.sip.telsp.com | _sips._tcp.trunk.chicago.custb.sip.telsp.com | chicago.custb.sip.telsp.com | 10.170.158.101 | 5061 |
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 Adresse: 8.8.8.8#53 Nicht autoritative Antwort: _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.
Übertragungsweg-Adresse | IP-Adresse | Port |
---|---|---|
trunk.miami.custa.sip.telsp.com | 10.170.158.200 | 5061 |
trunk.miami.custb.sip.telsp.com | 10.170.158.200 | 5062 |
trunk.chicago.custa.sip.telsp.com | 10.170.158.100 | 5061 |
trunk.chicago.custb.sip.telsp.com | 10.170.158.100 | 5062 |
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.
Übertragungsweg-Adresse (SRV) | SRV-Adresse | Eine Aufzeichnung | IP-Adresse | Port |
---|---|---|---|---|
trunk.miami.custa.sip.telsp.com | _sips._tcp.trunk.miami.custa.sip.telsp.com | miami.sip.telsp.com | 10.170.158.200 | 5061 |
trunk.miami.custb.sip.telsp.com | _sips._tcp.trunk.miami.custb.sip.telsp.com | miami.sip.telsp.com | 10.170.158.200 | 5062 |
trunk.chicago.custa.sip.telsp.com | _sips._tcp.trunk.chicago.custa.sip.telsp.com | chicago.sip.telsp.com | 10.170.158.100 | 5061 |
trunk.chicago.custb.sip.telsp.com | _sips._tcp.trunk.chicago.custb.sip.telsp.com | chicago.sip.telsp.com | 10.170.158.100 | 5062 |
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 Adresse: 8.8.8.8#53 Nicht autoritative Antwort: _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 Adresse: 8.8.8.8#53 Nicht autoritative Antwort: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com
Domänenserver einrichten und Zertifikat generieren
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.
Vom Partner gehostetes Gateway | Kunde | Übertragungsweg-Adresse | Zertifikat CN/SAN |
---|---|---|---|
Miami | Kunden | trunk.miami.custa.sip.telsp.com | trunk.miami.custa.sip.telsp.com |
Keule B | trunk.miami.custb.sip.telsp.com | trunk.miami.custb.sip.telsp.com | |
Chicago | Kunden | trunk.chicago.custa.sip.telsp.com | trunk.chicago.custa.sip.telsp.com |
Keule B | trunk.chicago.custa.sip.telsp.com | trunk.chicago.custa.sip.telsp.com |
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.
Vom Partner gehostetes Gateway | Kunde | Übertragungsweg-Adresse | SRV-Adresse | Zertifikat CN/SAN |
---|---|---|---|---|
Miami | Kunden | trunk.miami.custa.sip.telsp.com | _sips._tcp.trunk.miami.custa.sip.telsp.com | trunk.miami.custa.sip.telsp.com |
Keule B | trunk.miami.custb.sip.telsp.com | _sips._tcp.trunk.miami.custb.sip.telsp.com | trunk.miami.custb.sip.telsp.com | |
Chicago | Kunden | trunk.chicago.custa.sip.telsp.com | _sips._tcp.trunk.chicago.custa.sip.telsp.com | trunk.chicago.custa.sip.telsp.com |
Keule B | trunk.chicago.custb.sip.telsp.com | _sips._tcp.trunk.chicago.custb.sip.telsp.com | trunk.chicago.custb.sip.telsp.com |
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
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:
Gateway-Trunks im Control Hub konfigurieren
Ü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:
- 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
-
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 Keule B 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. - SBC-Adresse mit FQDN einrichten –
Für das Miami-Gateway:
Parameter Kunden Keule B 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 Chicago Gateway:
Parameter Kunden Keule B Standort Detroit (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) 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.
-
- 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.
-
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 -Trunk als primäre Option und an den trunk_chicago -Trunk als sekundäre Option weiterleitet.
Sie können eine zweite Routen-Gruppe definierenrg_chicago_miami , die Anrufe an den trunk_chicago -Trunk als primäre Option und an den trunk_miami -Trunk als sekundäre Option weiterleitet.
-
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.
-
Sie können die Übertragungswege und Routen-Gruppen in der Wählplan-Definition verwenden. Beispielsweise wird ein lokaler Nummernbereich in Chicago für den Kunden aufgeteilt, um mit der rg_chicago_miami route-Gruppe (für alle Standorte) in der Abbildung zu enden: