Spezifikation des TLS-Trunk-Transportprotokolls
Wenn Sie TLS als Trunk-Transportprotokoll für BYOC Premises oder BYOC Cloud auswählen, können Sie sichere Trunks erstellen. Genauer gesagt, ermöglichen sichere Trunks für BYOC die sichere Kommunikation von entfernten VoIP-Endpunkten mit Genesys Cloud über SIP TLS (SIPS) und Secure RTP (SRTP). Sichere VoIP-Anrufe schützen sowohl die Steuerung (Signalisierung) als auch die Medien (Audio) des Anrufs.
Weitere Informationen finden Sie unter Wählen Sie ein Trunk-Transportprotokoll.
Anforderungen
Um einen sicheren Trunk für BYOC Cloud einzurichten, muss Ihr Netzbetreiber oder Telefonieanbieter auch sichere VoIP-Verbindungen mit SIP über TLS und SRTP unterstützen. BYOC Cloud unterstützt kein IPSEC für sichere Trunks. Das Einrichten eines sicheren BYOC-Cloud-Trunks ähnelt dem Einrichten eines nicht sicheren Trunks, weist jedoch nur wenige alternative Einstellungen auf. Sichere Verbindungen haben jedoch andere Voraussetzungen, damit die Verbindung erfolgreich ist.
Verbindung
Das Gerät, von dem der Anruf ausgeht, initiiert die VoIP-Verbindungen. Beide VoIP-Endpunkte fungieren jedoch sowohl als Server als auch als Client. Sie konfigurieren eine sichere TLS-Verbindung für beide Endpunkte sowohl für eingehende als auch für ausgehende Anrufe. Beide VoIP-Endpunkte müssen über ein X.509-Zertifikat verfügen, das von einer öffentlichen Zertifizierungsstelle unterzeichnet wurde, und jeder Client-Endpunkt muss der Zertifizierungsstelle vertrauen, die den Server unterzeichnet hat.Beide Verbindungen verwenden unidirektionales oder serverseitiges TLS, aber gegenseitiges TLS (MTLS) wird nicht unterstützt.
Sichere Trunks für BYOC Cloud verbinden sich mit denselben VoIP-Endpunkten wie die unsicheren Gegenstücke. Weitere Informationen zu diesen Verbindungsadressen finden Sie unter BYOC Cloud public SIP IP addresses.
Ports und Protokollversionen
BYOC Cloud unterstützt nur Endpunkte, die das Protokoll TLS Version 1.2 verwenden.
Zu den unterstützten TLS-Chiffren gehören:
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA*
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384*
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
* Für den ephemeren Diffie-Hellman-Schlüsselaustausch mit elliptischer Kurve (ECDHE) werden nur elliptische Kurven vom Typ secp384r1 (NIST/SECG-Kurve über ein 384-Bit-Primzahlfeld) unterstützt.
Nur TLS-Listener sind an Host-Port 5061 verfügbar.
Zertifikat Vertrauen
Wenn der Client eine sichere Verbindung zu einem Server herstellt, prüft er die Gültigkeit des Zertifikats. Das Zertifikat bestätigt die Legitimität des enthaltenen Schlüssels. Ein gültiges Zertifikat erfüllt die folgenden Anforderungen:
Zertifizierungsstelle
Eine angesehene Zertifizierungsstelle muss das Zertifikat ausstellen, damit es gültig ist.
Die Endpunkte des Kunden müssen den Endpunkten der BYOC-Cloud vertrauen. Genesys Cloud signiert die BYOC Cloud-Endpunkte mit X.509-Zertifikaten, die von DigiCert, einer öffentlichen Zertifizierungsstelle, ausgestellt werden. Genauer gesagt ist die Stammzertifizierungsstelle, die die BYOC-Cloud-Endpunkte signiert, nach Regionen getrennt und verwendet Zertifikate, die entweder von DigiCert High Assurance EV Root CA oder DigiCert Global Root G2/DigiCert Global Root G3 autorisiert wurden. Sie können das entsprechende öffentliche Stammschlüsselzertifikat für Ihre Region von DigiCert herunterladen.
Dateiformate für Zertifikate
Root-CA-Zertifikate sind in zwei verschiedenen Dateiformaten erhältlich: DER und PEM. Beide Dateiformate enthalten dieselben Daten, unterscheiden sich aber in der Art ihrer Kodierung. Sie müssen nur das Dateiformat herunterladen, das am besten zu Ihrem System passt.
- Ein DER-Zertifikat wird nach der Methode der Distinguished Encoding Rules (DER) kodiert, die ein binäres Format ist. DER-Zertifikate sind für die Verwendung in Java-basierten Systemen vorgesehen.
- Ein PEM-Zertifikat wird mit der Privacy-Enhanced Mail (PEM)-Methode kodiert, die ein Base64-kodiertes Format ist. PEM-Zertifikate sind für die Verwendung in Unix-basierten Systemen vorgesehen.
Zertifizierungsstellen nach Region
Die Regionen, die Zertifikate von DigiCert High Assurance EV Root CA verwenden, sind:
- Asien-Pazifik (Tokio) / apne1
- Asien-Pazifik (Seoul) / apne2
- Asien-Pazifik (Sydney) / apse2
- Asien-Pazifik (Mumbai) / aps1
- Kanada (Zentral) / cac1
- Europa (Frankfurt) / euc1
- Europa (Irland) / euw1
- Europa (London) / euw2
- Südamerika (São Paulo) / sae1
- US-Ost (Nordvirginia) / use1
- US-Ost (Ohio) / use2
- US-West (Oregon) / usw2
Laden Sie das DigiCert High Assurance EV Root CA-Zertifikat in dem Dateiformat herunter, das für Ihr System am besten geeignet ist.
Laden Sie das DigiCert Global Root G2-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.
Laden Sie das DigiCert Global Root G3-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.
Die Regionen, die Zertifikate von DigiCert Global Root G2 und DigiCert Global Root G3 verwenden, sind:
- Asien-Pazifik (Osaka) / apne3
- Europa (Zürich) / euc2
- Naher Osten (UAE) / mec1
Laden Sie das DigiCert Global Root G2-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.
Laden Sie das DigiCert Global Root G3-Zertifikat in dem Dateiformat herunter, das am besten zu Ihrem System passt.
Die BYOC-Cloud-Endpunkte müssen auch den Kunden-Endpunkten vertrauen. Damit die BYOC-Cloud-Endpunkte den Kunden-Endpunkten vertrauen können, muss eine dieser öffentlichen Zertifizierungsstellen die Kunden-Endpunkte signieren:
- Actalis
- Amazon Trust Services
- Certum
- DigiCert / QuoVadis / Symantec / Thawte / Verisign
- Anvertrauen
- GlobalSign
- Go Daddy / Starfield
- Forschungsgruppe Internetsicherheit
- Netzwerk-Lösungen
- Sectigo / AddTrust / Comodo / UserTrust
- SwissSign
- Telia / TeliaSonera
- Trustwave / Sicheres Vertrauen / Viking Cloud
Alle entfernten Endpunkte, die sichere SIP TLS-Verbindungen von BYOC Cloud SIP-Servern empfangen, müssen mit einem Zertifikat konfiguriert werden. Dieses Zertifikat ist entweder selbst signiert oder, was häufiger der Fall ist, von einer Zwischenzertifizierungsstelle signiert, die von einer der Stammzertifizierungsstellen ausgestellt wurde, denen die Genesys Cloud BYOC Cloud SIP-Server vertrauen. Wenn das Zertifikat nicht signiert ist, schlägt die Verbindung fehl. Der entfernte Endpunkt sollte sein Endzertifikat sowie alle Zwischenzertifizierungsstellen im TLS-Handshake vorlegen.
Zertifizierungsstelle | Gemeinsamer Name des Wurzelzertifikats | Hashwert des Betreffs |
---|---|---|
Actalis |
Stammzertifizierungsstelle für Actalis-Authentifizierung |
930ac5d2 |
Amazon Trust Services |
Amazon Root CA 1 |
ce5e74ef |
Amazon Trust Services |
Amazon Root CA 2 |
6d41d539 |
Amazon Trust Services |
Amazon Root CA 3 |
8cb5ee0f |
Amazon Trust Services |
Amazon Root CA 4 |
de6d66f3 |
Certum |
Certum CA |
442adcac |
Certum |
Vertrauenswürdige Netzwerkzertifizierungsstelle von Certum |
48bec511 |
Certum |
Vertrauenswürdige Netzwerkzertifizierungsstelle von Certum 2 |
40193066 |
DigiCert |
DigiCert Global Root CA |
3513523f |
DigiCert |
DigiCert High Assurance EV Root CA |
244b5494 |
DigiCert |
DigiCert Global Root G2 |
607986c7 |
DigiCert |
DigiCert Global Root G3 |
dd8e9d41 |
DigiCert |
DigiCert ECC P384 Root G5 |
c1223238 |
DigiCert |
DigiCert RSA4096 Wurzel G5 |
9ccd262b |
DigiCert |
DigiCert TLS ECC P384 Root G5 |
9846683b |
DigiCert |
DigiCert TLS RSA4096 Wurzel G5 |
d52c538d |
DigiCert / QuoVadis |
QuoVadis Wurzel-CA 2 |
d7e8dc79 |
DigiCert / QuoVadis |
QuoVadis Wurzel-CA 3 |
76faf6c0 |
DigiCert / QuoVadis |
QuoVadis Wurzel-CA 1 G3 |
749e9e03 |
DigiCert / QuoVadis |
QuoVadis Wurzel-CA 2 G3 |
064e0aa9 |
DigiCert / QuoVadis |
QuoVadis Wurzel-CA 3 G3 |
e18bfb83 |
DigiCert / Tauwetter |
thawte Primäre Wurzel-CA |
2e4eed3c |
DigiCert / Tauwetter |
thawte Primäre Wurzel-CA - G2 |
c089bbbd |
DigiCert / Tauwetter |
thawte Primary Root CA - G3 |
ba89ed3b |
DigiCert / Tauwetter |
thawte Primary Root CA - G4 |
854dca2b |
DigiCert / Verisign |
VeriSign Klasse 3 Öffentliche primäre Zertifizierungsstelle - G5 |
b204d74a |
Anvertrauen |
Entrust Root-Zertifizierungsstelle |
6b99d060 |
Anvertrauen |
Entrust.net Zertifizierungsstelle (2048) |
aee5f10d |
Anvertrauen |
Entrust Root-Zertifizierungsstelle - EC1 |
106f3e4d |
Anvertrauen |
Entrust Root-Zertifizierungsstelle - G2 |
02265526 |
Anvertrauen |
Entrust Root-Zertifizierungsstelle - G3 |
425d82a9 |
Anvertrauen |
Entrust Root-Zertifizierungsstelle - G4 |
5e98733a |
GlobalSign |
GlobalSign Root E46 |
feffd413 |
GlobalSign |
GlobalSign Root R46 |
002c0b4f |
GlobalSign |
GlobalSign Root CA - R3 |
062cdee6 |
GlobalSign |
GlobalSign ECC Root CA - R4 |
b0e59380 |
GlobalSign |
GlobalSign ECC Root CA - R5 |
1d3472b9 |
GlobalSign |
GlobalSign Root CA - R6 |
dc4d6a89 |
Go Daddy / Starfield |
Go Daddy Zertifizierungsstelle der Klasse 2 |
f081611a |
Go Daddy / Starfield |
Go Daddy Root-Zertifizierungsstelle - G2 |
cbf06781 |
Go Daddy / Starfield |
Go Daddy Root-Zertifizierungsstelle - G3 |
4b82aaf1 |
Go Daddy / Starfield |
Go Daddy Root-Zertifizierungsstelle - G4 |
fd8d27e1 |
Go Daddy / Starfield |
Starfield Klasse 2 Zertifizierungsstelle |
f387163d |
Go Daddy / Starfield |
Starfield Root-Zertifizierungsstelle - G2 |
4bfab552 |
Go Daddy / Starfield |
Starfield Root-Zertifizierungsstelle - G3 |
3661ca00 |
Go Daddy / Starfield |
Starfield Root-Zertifizierungsstelle - G4 |
978d3d03 |
Go Daddy / Starfield |
Starfield Services Root-Zertifizierungsstelle - G2 |
09789157 |
Go Daddy / Starfield / Amazon Trust Services |
Starfield Services Root-Zertifizierungsstelle |
006016b6 |
Internet Security Research Group (ISRG) |
ISRG-Wurzel X1 |
4042bcee |
Internet Security Research Group (ISRG) |
ISRG-Wurzel X2 |
0b9bc432 |
Netzwerk-Lösungen |
Network Solutions Zertifizierungsstelle (Dez-2029) |
4304c5e5 |
Netzwerk-Lösungen |
Network Solutions Zertifizierungsstelle (Dez-2030) |
4304c5e5 |
Netzwerk-Lösungen |
Network Solutions EV SSL CA |
4df989ce |
Sectigo |
AAA-Zertifikatsdienste |
ee64a828 |
Sectigo |
AddTrust Externe CA-Wurzel |
157753a5 |
Sectigo |
COMODO ECC-Zertifizierungsstelle |
eed8c118 |
Sectigo |
COMODO RSA-Zertifizierungsstelle |
d6325660 |
Sectigo |
USERTrust ECC-Zertifizierungsstelle |
f30dd6ad |
Sectigo |
USERTrust RSA-Zertifizierungsstelle |
fc5a8f99 |
Sectigo |
UTN-USERFirst-Hardware |
b13cc6df |
SwissSign |
SwissSign Silver CA - G2 |
57bcb2da |
SwissSign |
SwissSign Gold CA - G2 |
4f316efb |
SwissSign |
SwissSign Platinum CA - G2 |
a8dee976 |
Telia |
TeliaSonera Root CA v1 |
5cd81ad7 |
Telia |
Telia Root CA v2 |
8f103249 |
Trustwave |
Sichere globale CA |
b66938e9 |
Trustwave |
SecureTrust CA |
f39fc864 |
Trustwave |
Globale Zertifizierungsstelle von Trustwave |
f249de83 |
Trustwave |
Trustwave Global ECC P256 Zertifizierungsstelle |
9b5697b0 |
Trustwave |
Trustwave Global ECC P384 Zertifizierungsstelle |
d887a5bb |
TLS-Handshake mit zwischengeschaltetem Vertrauen
TLS verwendet einen Handshake, um die sichere Verbindung zwischen den beiden Endpunkten auszuhandeln. Der Handshake umfasst sowohl öffentliche Zertifikate als auch verbindungsspezifische Anforderungen. Der Client initiiert den Handshake und fordert vom Server eine sichere Verbindung an. Der Server muss sowohl sein eigenes signiertes Zertifikat als auch alle Zwischenzertifikate in der Zertifikatskette bereitstellen.
Die BYOC-Cloud-Endpunkte stellen ihr eigenes Server-Zertifikat und alle Zwischenzertifikate in der Zertifikatskette bereit, wenn sie während des TLS-Handshakes als Server fungieren. Die Endpunkte des Kunden sollten nur der oben aufgeführten DigiCert-Root-Zertifizierungsstelle vertrauen.
Die BYOC-Cloud-Endpunkte vertrauen nur den Stammzertifizierungsstellen-Zertifikaten der oben aufgeführten Anbieter. Die Kundenendpunkte müssen sowohl ihr eigenes Serverzertifikat als auch alle Zwischenzertifizierungsstellen-Zertifikate in der Zertifikatskette bereitstellen, wenn sie während des TLS-Handshakes als Server fungieren.
Validierung von Themennamen
Ein gültiges Zertifikat muss den Subjektnamen des Ortes enthalten, mit dem sich der Client verbunden hat (URI).
Ein Client einer sicheren Verbindung verwendet die Überprüfung des Betreffs, um sicherzustellen, dass der entfernte Endpunkt sich als das erwartete Ziel identifiziert. Wenn ein Serverzertifikat den Namen, mit dem der Client verbunden ist, weder als Common Name noch als Subject Alternate Name enthält, sollte der Client diese Verbindung ablehnen.
Um sicherzustellen, dass die Validierung des Subjektnamens erfolgreich ist, verwenden Verbindungen zur BYOC Cloud die folgende Tabelle als Liste möglicher Endpunkte.
US-Ost (N. Virginia) / us-ost-1
Gängiger Name |
---|
lb01.voice.use1.pure.cloud lb02.voice.use1.pure.cloud lb03.voice.use1.pure.cloud lb04.voice.use1.pure.cloud |
US East 2 (Ohio) / us-east-2
Gängiger Name |
---|
lb01.voice.use2.us-gov-pure.cloud lb02.voice.use2.us-gov-pure.cloud lb03.voice.use2.us-gov-pure.cloud lb04.voice.use2.us-gov-pure.cloud |
US-West (Oregon) / us-west-2
Gängiger Name |
---|
lb01.voice.usw2.pure.cloud lb02.voice.usw2.pure.cloud lb03.voice.usw2.pure.cloud lb04.voice.usw2.pure.cloud |
Kanada (Kanada Zentral) / ca-central-1
Gängiger Name |
---|
lb01.voice.cac1.pure.cloud lb02.voice.cac1.pure.cloud lb03.voice.cac1.pure.cloud lb04.voice.cac1.pure.cloud |
Südamerika (Sao Paulo) / sae1
Gängiger Name |
---|
lb01.voice.sae1.pure.cloud lb02.voice.sae1.pure.cloud lb03.voice.sae1.pure.cloud lb04.voice.sae1.pure.cloud |
Europa (Irland) / eu-west-1
Gängiger Name |
---|
lb01.voice.euw1.pure.cloud lb02.voice.euw1.pure.cloud lb03.voice.euw1.pure.cloud lb04.voice.euw1.pure.cloud |
Europa (London) / eu-west-2
Gängiger Name |
---|
lb01.voice.euw2.pure.cloud lb02.voice.euw2.pure.cloud lb03.voice.euw2.pure.cloud lb04.voice.euw2.pure.cloud |
Europa (Frankfurt) / eu-central-1
Gängiger Name |
---|
lb01.voice.euc1.pure.cloud lb02.voice.euc1.pure.cloud lb03.voice.euc1.pure.cloud lb04.voice.euc1.pure.cloud |
Europa (Zürich) / euc2
Gängiger Name |
---|
lb01.voice.euc2.pure.cloud lb02.voice.euc2.pure.cloud lb03.voice.euc2.pure.cloud lb04.voice.euc2.pure.cloud |
Naher Osten (UAE) / mec1
Gängiger Name |
---|
lb01.voice.mec1.pure.cloud lb02.voice.mec1.pure.cloud lb03.voice.mec1.pure.cloud lb04.voice.mec1.pure.cloud |
Asien-Pazifik (Tokio) / ap-northeast-1
Gängiger Name |
---|
lb01.voice.apne1.pure.cloud lb02.voice.apne1.pure.cloud lb03.voice.apne1.pure.cloud lb04.voice.apne1.pure.cloud |
Asien-Pazifik (Seoul) / ap-nordost-2
Gängiger Name |
---|
lb01.voice.euw2.pure.cloud lb02.voice.euw2.pure.cloud lb03.voice.euw2.pure.cloud lb04.voice.euw2.pure.cloud |
Asien-Pazifik (Sydney) / ap-southeast-2
Gängiger Name |
---|
lb01.voice.apse2.pure.cloud lb02.voice.apse2.pure.cloud lb03.voice.apse2.pure.cloud lb04.voice.apse2.pure.cloud |
Asien-Pazifik (Mumbai) / ap-south-1
Gängiger Name |
---|
lb01.voice.euw2.pure.cloud lb02.voice.euw2.pure.cloud lb03.voice.euw2.pure.cloud lb04.voice.euw2.pure.cloud |
Asien-Pazifik (Osaka) / apne3
Gängiger Name |
---|
lb01.voice.euw3.pure.cloud lb03.voice.euw2.pure.cloud lb03.voice.euw3.pure.cloud lb04.voice.euw3.pure.cloud |
Öffentliche Zertifizierungsstellen müssen die X.509-Zertifikate des Kundenendpunkts mit dem gemeinsamen Namen oder dem alternativen Namen des Betreffs signieren, der als Wert für die SIP-Server oder Proxies des Trunks verwendet wird. Der BYOC-Endpunkt validiert die Verbindung anhand des Hostnamens - eine IP-Adresse ist nicht zulässig. Weitere Informationen zu BYOC Cloud Trunks finden Sie unter Erstellen eines BYOC Cloud Trunks.
Überprüfung des Datums
Ein gültiges Zertifikat muss innerhalb der Gültigkeitsdauer liegen und das Ablaufdatum darf nicht überschritten sein.
X.509-Zertifikate haben eine Gültigkeitsdauer, d. h. einen Datumsbereich, der angibt, wann das Zertifikat akzeptabel ist. Wenn das Ablaufdatum erreicht ist, erneuert Genesys Cloud das Zertifikat des Endpunkts mit einem neuen Zertifikat, das eine verlängerte Gültigkeitsdauer enthält.
Zertifikat widerrufsliste
Ein gültiges Zertifikat muss ein aktiv ausgestelltes Zertifikat sein und darf nicht in der Sperrliste der Behörden enthalten sein.
Wenn eine öffentliche Zertifizierungsstelle X.509-Zertifikate signiert, enthält sie eine Adresse einer Zertifikatswiderrufsliste. Die öffentliche Zertifizierungsstelle kann ein Zertifikat vor Ablauf der Frist sperren, indem sie es in eine Sperrliste aufnimmt. Der sichere Client prüft die Sperrliste, wenn er eine Verbindung herstellt, und bestätigt, dass das Zertifikat gültig ist. Eine öffentliche Zertifizierungsstelle widerruft in der Regel ein öffentliches Endpunktzertifikat, wenn die Sicherheit des Schlüsselpaars gefährdet ist.
SIP-URI
Die SIP-URI ist ein Mechanismus, der einen VoIP-Endpunkt verbindet. Jeder VoIP-Endpunkt hat eine entsprechende SIP-URI, um sich mit der jeweiligen Gegenstelle zu verbinden. Der URI enthält die Remote-Adresse des SIP-Geräts in Form eines DNS-Hostnamens, der das Protokoll, die Zielnummer und den Remote-Host enthält.
Neben dem Hostnamen kann der URI auch Attribute zur Steuerung der Verbindung enthalten. Sie wenden Attribute auf den Benutzerteil und den Hostteil des URI an. Damit der URI korrekt funktioniert, müssen Sie Attribute auf den entsprechenden Teil des URI anwenden.
Die primären Attribute geben die Leitungswahl und das Transportprotokoll an. Bei sicheren Verbindungen gibt das Attribut transport das TLS-Transportprotokoll an.
Attribut | Standort des Attributs | Beschreibung | Werte |
---|---|---|---|
Transport | Host | Transport-Protokoll | UDP | TCP | TLS |
TGRP | Benutzer | Kennzeichnung der Leitungsgruppe | Benutzerdefinierte Kennung für eingehende SIP-Terminierung |
Kontext des Stammes | Benutzer | Namensraum der Fernmeldegruppe | Regionalspezifischer Namensraum |
Weitere Informationen finden Sie im Abschnitt Eingehend unter Configure SIP routing for a BYOC Cloud trunk.
Eingehende SIP-Weiterleitung
Wenn Sie sicheres SIP für BYOC Cloud unter Verwendung von TLS verwenden, empfiehlt Genesys Cloud, dass Sie eine Reihe von unterschiedlichen URIs für jeden Proxy verwenden, der TGRP für eingehendes SIP-Routing verwendet. Es gibt jedoch noch einige andere Optionen, die Sie bei der Auswahl einer Methode zur Weiterleitung eingehender Nachrichten in Betracht ziehen sollten:
TGRP (Trunk Group Routing Protocol)
Es empfiehlt sich, eine TGRP-Konfiguration zu verwenden, da sie die Auswahl der Leitung auf der Grundlage der Attribute der SIP-URI ermöglicht. TGRP-Attribute steuern das Routing, so dass der Hostname des Anfrage-URIs auf einen Wert gesetzt wird, der als Common Name oder Subject Alternate Name des X.509-Zertifikats definiert ist. Mit dieser Konfiguration kann die Überprüfung des Betreffs erfolgreich durchgeführt werden.
DNIS (Dienst zur Identifizierung gewählter Nummern)
DNIS-Routing kann mit Secure BYOC Cloud Trunks funktionieren; allerdings kann die Validierung des Subjektnamens die Machbarkeit dieser Routing-Option einschränken. Sie verwenden DNIS-Routing in der Regel, wenn der Betreiber die Kontrolle über den SIP-URI einschränkt und stattdessen eine IP-Adresse bevorzugt. Wenn Anrufe direkt an eine IP-Adresse und nicht an einen unterstützten Hostnamen gesendet werden, schlägt die Validierung des Betreffnamens der X.509-Zertifikate fehl.
FQDN (Vollständig qualifizierter Domänenname)
FQDNs können mit Secure BYOC Cloud Trunks funktionieren; es wird jedoch nicht erwartet, dass die Validierung des Subjektnamens des X.509-Zertifikats erfolgreich ist, da die FQDNs benutzerdefiniert sind. Wildcard-Zertifikate könnten die benutzerdefinierten Namen unterstützen, werden aber nicht verwendet, weil sie von einigen SIP-Geräten nicht unterstützt werden.
SRV-Einträge für TLS sind verfügbar, und die Proxy-Zertifikate enthalten den SRV-Domänennamen und den Namen des SRV-Eintrags. Öffentliche Zertifizierungsstellen gestatten jedoch nicht die Verwendung von Unterstrichen in allgemeinen Namen und alternativen Namen von Subjekten, die in SRV-Einträgen für Dienst- und Transportnamen verwendet werden. Wenn das entfernte SIP-Gerät den gemeinsamen Namen des Zertifikats validiert, wird nur der Domänenname validiert. Es wird nicht der gesamte Name des Ressourcendatensatzes validiert, der den Dienst und den Transport umfasst.
Weitere Informationen finden Sie im Abschnitt Eingehend unter Configure SIP routing for a BYOC Cloud trunk.
Beispiele
Damit Sie Ihren SIP-URI richtig konfigurieren können, wird im Folgenden ein Beispiel für eine Verbindung mit TGRP aufgeführt. Dieses Beispiel zeigt alle derzeit erforderlichen Host-Einträge, die zur Verteilung von Anrufen zwischen den einzelnen BYOC-SIP-Proxies verwendet werden. Außerdem wird der FQDN-Hostname jedes Proxys angezeigt, der verwendet wird, um die Prüfung des Betreffnamens des X.509-Zertifikats zu bestehen. Das Protokoll wird bereitgestellt, um sicherzustellen, dass der entfernte Endpunkt eine sichere Verbindung initiiert.
Wenn Sie TLS als Trunk-Transportprotokoll für BYOC Premises wählen, stellen Sie sichere Trunks direkt zwischen dem Kundenendpunkt und dem Genesys Cloud Edge her. Eine organisationsspezifische Zertifizierungsstelle stellt ein Serverzertifikat aus, das jeden Genesys Cloud Edge TLS-Endpunkt signiert. Die Stammzertifizierungsstelle Ihres Unternehmens ist das gültige Zertifikat, das den SIP-Dienst verwaltet.
Sie können das öffentliche Schlüsselzertifikat für Ihre Organisation von Genesys Cloud aus erhalten. Weitere Informationen finden Sie unter Konfigurieren von Zertifizierungsstellen.
Sie können die Einstellungen für die Transport- und Mediensicherheit in der Konfiguration der externen Leitung anpassen. Weitere Informationen finden Sie unter Externe Leitungseinstellungen.