Für die Bereitstellung von BYoPSTN müssen die folgenden Voraussetzungen erfüllt sein. Die unten angegebenen Voraussetzungen gehen davon aus, dass der Partner über eine funktionierende Webex für Cisco BroadWorks-Bereitstellung verfügt, die Folgendes umfasst:

• Funktionieren des BroadWorks-Systems – wie im Lösungshandbuch zu Webex für Cisco BroadWorks dokumentiert

• BroadWorks ALS Lizenz mit „VoiceXML“-Dienst in ausreichender Menge (1 pro PSTN-Nummer)

• BroadWorks-Patches erforderlich:

  Für R22:

  • AP.xsp.22.0.1123.ap376935

  • AP.as.22.0.1123.ap376935

  Für R23:

  • AP.xsp.23.0.1075.ap376935

  • AP.as.23.0.1075.ap376935

  Für R24

  • AP.as.24.0.944.ap376935

• Bereitgestelltes Cisco CUBE-System (IOS Version 16.12.2 oder höher): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html

  Sowohl hardwarebasierter als auch virtueller CUBE wird unterstützt. Hardware-basierter CUBE wird für Skalierbarkeit und die Verarbeitung einer größeren Anzahl von Anrufen empfohlen.

• Webex-Partnerorganisation – wie im Lösungshandbuch zu Webex für Cisco BroadWorks beschrieben

Die Vorgehensweise, die Cisco Partner zum Hinzufügen ihrer Webex-Meeting-Einwahlnummern verwendet, ist wie folgt:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Meeting Join-Konfiguration (BYoPSTN) die Option Create Call-in Phone Number Grou p.

5. Geben Sie den Namen der Telefonnummerngruppe ein und wählen Sie Weiter .

6. Geben Sie die Details Telefonnummer ein und wählen Sie Weiter .

7. Überprüfen Sie die Details zur Telefonnummerngruppe und wählen Sie „Speichern“ .

8. Wiederholen Sie diesen Vorgang für jede Telefonnummer, die hinzugefügt werden soll.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Dieser Schritt muss nur abgeschlossen werden, wenn Sie die Option „Meeting beitreten über Rückruf“ bereitstellen möchten. Andernfalls können Sie diesen Schritt überspringen.

Wenn Sie diese Option nicht konfigurieren, können Benutzer die Einwahloption verwenden, um Meetings beizutreten, oder sie können mit Computer-Audio beitreten.

Wenn Sie die Meeting-Rückruf-Option verwenden, ist eine Rückruf-DNS-SRV-Gruppe erforderlich, um Anrufe von Webex an CUBE weiterzuleiten. Der Cisco-Partner führt die folgenden Schritte aus, um seine CUBE DNS SRV-Datensätze zu Webex hinzuzufügen:

1. Melden Sie sich bei Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Meeting Join-Konfiguration (BYoPSTN) die Option Rückruf-DNS-SRV-Gruppe erstellen .

5. Geben Sie den Rückruf-DNS SRV Gruppennamen ein .

6. Wählen Sie Weiter aus.

7. Geben Sie die Rückruf-DNS-SRV-Details ein.

8. Wählen Sie Weiter aus.

9. Überprüfen Sie die Zusammenfassung der Rückruf-DNS-SRV-Details.

10. Wählen Sie Speichern.

11. Stellen Sie alle Aktualisierungen für DNS bereit, um die neuen Datensätze in der DNS SRV-Gruppe widerzuspiegeln.

12. Wiederholen Sie diesen Vorgang für jede Rückruf-DNS-SRV-Gruppe, die hinzugefügt werden soll.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Die anfängliche Konfiguration und Verifizierung der BYoPSTN-Lösung erfordert eine Startorganisation für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe (falls Rückruf erforderlich ist). Daher wird empfohlen, dass Cisco-Partner auf ähnliche Weise eine neue Kundenvorlage für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe erstellen. Jede Kundenvorlage sollte verwendet werden, um eine entsprechende Saatgutorganisation zu generieren.

Sobald die BYoPSTN-Konfiguration mithilfe der Samenorganisationen ausgesät und verifiziert wurde, können die Telefonnummerngruppen und Rückruf-DNS-SRV-Gruppen nach Bedarf auf vorhandene Kundenvorlagen angewendet werden.

Bitte beachten Sie, dass neu erstellte Kundenvorlagen nicht von bestehenden Nicht-Testkunden verwendet werden und somit sicher zur manuellen Überprüfung der BYoPSTN-Konfiguration verwendet werden können.

Wenn Sie den Meeting-Beitritt nicht über Rückruf bereitstellen, müssen Sie Rückruf-DNS-SRV-Gruppen nicht der Kundenvorlage zuordnen. Sie müssen jedoch „Rückruf deaktivieren“ auswählen.

Gehen Sie wie folgt vor, um eine neue Kundenvorlage hinzuzufügen:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Vorlagen die Option Vorlage hinzufügen aus.

5. Geben Sie die Vorlagendetails ein. Auf der Stufe Pakettyp :

   • Wählen Sie Pakettyp als Standard .

   • Wählen Sie Meeting-Beitrittskonfiguration als Vom Partner bereitgestellte Einwahlnummern (BYoPSTN).

   • Wählen Sie eine bereitgestellte Telefonnummerngruppe .

   • Wählen Sie für Rückruf-DNS-SRV-Gruppe eine bereitgestellte Rückruf-DNS-SRV-Gruppe aus, wenn Sie die Rückrufoption für das Meeting aktivieren möchten. Andernfalls wählen Sie „Rückruf deaktivieren“ aus .

6. Wählen Sie Weiter aus.

7. Geben Sie die restlichen Vorlagendetails ein.

8. Überprüfen Sie die Zusammenfassung der Vorlagendetails.

9. Klicken Sie auf Speichern.

10. Wiederholen Sie diesen Vorgang für jede Kundenvorlage, die hinzugefügt werden muss.

Der folgende Screenshot veranschaulicht die Vorgehensweise.

Um eine vorhandene Kundenvorlage zu aktualisieren, gehen Sie wie folgt vor:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zum Abschnitt BroadWorks Calling .

4. Wählen Sie unter Vorlagen die Option Vorlage anzeigen .

5. Wählen Sie die zu aktualisierende Vorlage aus.

6. Scrollen Sie zum Abschnitt Meeting-Beitrittskonfiguration :

   • Wählen Sie Vom Partner bereitgestellte Einwahlnummern (BYoPSTN).

   • Wählen Sie eine zuvor konfigurierte Telefonnummerngruppe .

   • Wählen Sie für Rückruf-DNS-SRV-Gruppe eine bereitgestellte Rückruf-DNS-SRV-Gruppe aus, wenn Sie die Rückrufoption für das Meeting aktivieren möchten. Andernfalls wählen Sie „Rückruf deaktivieren“ aus .

7. Wählen Sie Speichern.

   Der folgende Screenshot veranschaulicht die Vorgehensweise.

Die BYoPSTN-Lösung hat mehrere verschiedene Komponenten, von denen jede richtig konfiguriert werden muss, damit die Lösung erfolgreich funktioniert. Einer der beiden Zwecke der Samenlösungsorganisationen besteht darin, eine Telefonnummer für die Zuordnung von Meeting-Zugriffscodes und eine universell eindeutige Kennung der Meeting-Site (Site UUID) zu generieren, die für den laufenden Betrieb der Lösung erforderlich sind. Der andere Zweck ist die Konfigurationsverifizierung.

Für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe, die verwendet werden soll, sollte zuvor eine entsprechende Kundenvorlage erstellt werden. Für jede dieser Kundenvorlagen muss eine Saatgutlösungsorganisation bereitgestellt werden. Die Bereitstellung dieser Startorganisationen generiert die Telefonnummer für die Zuordnung von Meeting-Zugriffscodes und eine UUID der Meeting-Site, die für die Konfiguration von BroadWorks erforderlich sind.

Verwenden Sie jede der zuvor konfigurierten Kundenvorlagen, und stellen Sie einen Subscriber für einen neuen BroadWorks-Dienstanbieter oder ein neues BroadWorks-Unternehmen mit einem Standard-Paket Benutzer bereit. Die resultierende Meeting-Site Standardpaket sollte die Option zum Beitreten zu Meeting-Einwahlnummern von Partneranbietern verwenden. Eine der folgenden Methoden kann verwendet werden, um den Subscriber bereitzustellen:

1. Stellen Sie den Test-Subscriber mithilfe der BroadWorks Subscriber-APIs bereit, wie dokumentiert am developer.webex.com.

2. Aktivieren Sie den Test-Subscriber für den IM&P-Dienst auf einem BroadWorks, das für die Verwendung der Kundenvorlage konfiguriert ist. Stellen Sie sicher, dass die Kundenvorlage das Standardpaket verwendet, um sicherzustellen, dass dem Testteilnehmer ein Standardpaket zugewiesen wird. Alternativ muss der Test-Abonnent anschließend aktualisiert werden, um das Standard-Paket zu erhalten.

Beachten Sie, dass die Saatgutlösungsorganisationen mit einem BroadWorks-Dienstleister oder einem BroadWorks Enterprise-Test verknüpft sind.

Es ist wichtig, dass diese Meeting-Site weiterhin bereitgestellt wird, da diese Site-UUID in jeder Einwahl-Meeting-Beitrittsanforderung als Authentifizierungstoken gesendet wird. Sie sollten die Startorganisation nicht löschen, da auch die zugehörige Meeting-Site gelöscht wird. Wenn die Startorganisation entfernt wird, müssen Sie eine neue bereitstellen und Broadworks mit der neuen Site-UUID neu konfigurieren.

Die primären und alle sekundären Samenlösungsorganisationen können auf Wunsch gelöscht werden, bevor die Reihe von Telefonnummern und Rückruf-DNS-SRV-Datensätzen Nicht-Testkunden zugewiesen wird. Wenn der Satz von Telefonnummern und Rückruf-DNS-SRV-Datensätzen allen nicht getesteten Kunden zugewiesen ist, werden diese Telefonnummern und Rückruf-Datensätze mit Meeting-Sites für diese Kunden verknüpft und werden für den Beitritt zum Meeting über Einwahl und Rückruf verwendet. Änderungen sollten als sich auf den Dienst auswirkende Änderungen betrachtet werden.

Um die Primary Seed Solution Organization auszuwählen, gehen Sie wie folgt vor:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zum Abschnitt BroadWorks Calling .

4. Wählen Sie unter Configuration Validation (BYoPSTN) die Option Assign .

5. Suchen Sie im Bildschirm „Organisation zuweisen“ nach einer der zuvor konfigurierten Saatgutorganisationen und wählen Sie sie aus.

6. Wählen Sie Zuweisen.

   Die ausgewählte Saatgutorganisation ist die primäre Saatgutorganisation.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Die Details zur Primary Seed Solution-Organisation, zu Telefonnummerngruppen und Rückruf-DNS-SRV-Gruppen für einen bestimmten BroadWorks-Cluster sind an einem einzigen Standort verfügbar, der JSON-Datei für die BroadWorks-Konfiguration (BYoPSTN). Diese Informationen sind für die Konfiguration von BroadWorks für BYoPSTN erforderlich.

Beachten Sie, dass die JSON-Konfigurationsdatei nur zum Anzeigen/Herunterladen verfügbar ist, nachdem die primäre Startlösungsorganisation ausgewählt wurde.

Die Vorgehensweise zum Anzeigen/Herunterladen der JSON-Konfigurationsdatei lautet wie folgt:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Cluster die Option Cluster anzeigen .

5. Wählen Sie den Cluster aus, der den für BYoPSTN konfigurierten Kundenvorlagen zugeordnet ist.

6. Blättern Sie zum Abschnitt BroadWorks-Konfiguration für BYoPSTN .

7. Klicken Sie auf JSON-Konfigurationsdatei herunterladen .

8. Wiederholen Sie diesen Vorgang für alle anderen BroadWorks-Cluster.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Sehen Sie sich die Beispiel-JSON-Konfigurationsdatei unten an. Die Datei enthält zusätzliche Informationen zu jeder Telefonnummerngruppe, Rückruf-DNS-SRV-Gruppe. Die folgenden Schlüsselkonfigurationselemente, die in BroadWorks eingegeben werden müssen, sind fett markiert.

• siteUUID: BroadWorks muss diesen Wert in den SIP-Nachrichten senden. Hierbei handelt es sich um ein Token, das Webex Edge Audio verwendet, um die Identität von BroadWorks des Cisco-Partners und seinen Zugriff auf von diesem Cisco-Partner verwaltete Meeting-Sites zu bestätigen.

• Zuordnung von Telefonnummern zu Zugriffscodes: Die Telefonnummern und die zugehörigen Webex-Zugriffscodes müssen in BroadWorks konfiguriert werden.

  • phoneNumber

  • Zugriffscode

• localeTag: Die gewünschte Ansagesprache, die der Telefonnummer zugeordnet ist, muss auf BroadWorks konfiguriert werden.

• dnsSrv: Der Rückruf-DNS-SRV muss im DNS konfiguriert sein und sich auf die gewünschten CUBE-Instanzen beziehen.

{
   "siteUUID": "491db0821791441a96c233fefb6c6dfc",
   "siteURL": " seedtestenterpriseabc.webex.com ",
   "partnerOrgId": "1da175de-3651-4467-b26b-b0d85a2cb3ad",
   "solutionValidationOrgId": "d927ac4d-3d73-4d7f-8506-a1bc0a221934",
   "customerTemplates": [
      {
         "name": "US West Std",
         "id": "27fe1337-ab1d-44b0-8b5e-ff1d32f6e3f8",
         "phoneNumberGroupId": "1bcb05bd-b919-45fd-b30e-71d2abb59e26",
         "callbackDnsSrvGroupId": "25392686-a390-49b9-bad5-cb47159c3e992"
      },
      {
         "name": "US East Std",
         "id": "070d6682-b64f-46ea-bc4b-b2e1218ba4bb",
         "phoneNumberGroupId": "12bc0b8f-ea1d-457f-8fe2-069ccf78907e",
         "callbackDnsSrvGroupId": "25392686-a390-49b9-bad5-cb47159c3e992"
      }
   ],
   "phoneNumberGroups": [
   {
         "name": "US West",
         "id": "1bcb05bd-b919-45fd-b30e-71d2abb59e26",
         "phonenumbers": [
            {
               "id": "617c5faa-1721-45c7-bc70-e6d7c20ccc29",
               "name": "US Palo Alto",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "TollFree",
               "defaultPhoneNumberType": "NONE",
               "phoneNumber": "9863502478",
               "accessCode": "88672693772924908359"
            },
            {
               "id": "48fa7c50-9da0-4c8b-9b2f-307ff435c7c7",
               "name": "US Toll San Francisco",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "PRIMARY",
               "phoneNumber": "4156551000",
               "accessCode": "88652789466280320324"
            }
         ]
      },
      {
         "name": "US East",
         "id": "12bc0b8f-ea1d-457f-8fe2-069ccf78907e",
         "phonenumbers": [
            {
               "id": "ca0c622a-8621-4477-91e0-b3e214833568",
               "name": "US Maryland",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "PRIMARY",
               "phoneNumber": "2403332200",
               "accessCode": "88631321777971704941"
            },
            {
               "id": "00875574-9a46-4447-a967-350b6176755a",
               "name": "US Florida",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "SECONDARY",
               "phoneNumber": "9049002303",
               "accessCode": "88632627551145646175"
            },
            {
               "id": "a2c10316-9266-4423-a669-d67949f99d33",
               "name": "US New York",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "TollFree",
               "defaultPhoneNumberType": "NONE",
               "phoneNumber": "8056504578",
               "accessCode": "88649679020033567943"
            }
         ]
      }
   ],
   "callbackDnsSrvGroups": [
      {
         "name": "CB US",
         "callbackDnsSrvs": [
            {
               "name": "Callback US",
               "countryCode": "US",
               "dnsSrv": "cube.us.example.com",
               "id": "c5209d17-7c2f-45b3-95a6-65d7f5f53c7e"
            }
         ],
         "id": "25392686-a390-49b9-bad5-cb47159c3e992"
      },
      {
         "name": "CB MX",
         "callbackDnsSrvs": [
            {
               "name": "Callback MX",
               "countryCode": "MX",
               "dnsSrv": "cube.mx.example.com",
               "id": "cca0e4c3-5cff-412c-a854-bfb719f603a2"
            }
         ],
         "id": "36403797-b401-50c0-cbe5-dc58260d4f003"
      }
   ]
}

Die DNS SRV-Domäne für Webex Edge Audio muss in BroadWorks konfiguriert sein. Gehen Sie wie folgt vor, um den Wert zu ermitteln.

1. Melden Sie sich beim Cisco Partner Hub an.

2. Gehen Sie zu Kunden .

3. Wählen Sie das BYoPSTN-Validierungsunternehmen aus.

4. Wählen Sie Kunden anzeigen aus.

5. Gehen Sie zu Dienste/Meetings .

6. Wählen Sie die Meeting-Site des Standardpakets aus.

7. Scrollen Sie zum Ende des seitlichen Abschnitts und wählen Sie Site konfigurieren .

8. Wählen Sie Allgemeine Einstellungen/Audioeinstellungen .

9. Wählen Sie unter dem Abschnitt Edge Audio Custom Global Call-in Numbers die Option Generate Lua Script .

10. Suchen Sie im Popup-Fenster nach dem Wert „-- Header mit CCAX-URL aktualisieren“.

     
    -- Update To header with CCAX URL
     local oldTo1 = msg:getHeader("To")
     local newTo1 = string.gsub(oldTo1, "<sip:(.+)@(.*)>", "<sip:%1@ecccx.amer.webex.com>")
     msg:modifyHeader("To", newTo1)
    

11. Extrahieren Sie den Wert in Fettdruck, zum Beispiel ecccx.amer.webex.com.

Dies ist die DNS-SRV-Domäne für Webex Edge Audio, die in BroadWorks konfiguriert werden muss.

In diesem Abschnitt wird die BroadWorks-Konfiguration beschrieben, die erforderlich ist, um die Einwahl- und Rückruf-Szenarien für Meetings zu implementieren, die in den folgenden Diagrammen dargestellt werden. Die Konfigurationsbeispiele basieren auf den Daten in der JSON-Datei, die im vorherigen Abschnitt angezeigt wurde. Nummern, Domänen, Namen von Unternehmen/Gruppen, Gerätetyp, Richtlinien, Profile usw. werden je nach Partner unterschiedlich sein.

Anrufverlauf:

1. Benutzer fordert Rückruf an. Webex leitet einen Rückruf ein.
2. Anruf wird an BroadWorks OTT weitergeleitet.
3. Der Anruf erreicht den in CH bereitgestellten CUBE. CUBE leitet den Anruf an BroadWorks weiter.
4. BroadWorks identifiziert den Anruf als Ursprung des Meeting-Gastgebers und erstellt eine Sitzung für den Benutzer des Meeting-Gastgebers und verarbeitet den Anruf.
5. Die Benutzersitzung des Meeting-Gastgebers verarbeitet den Anruf und übersetzt die gewählte Nummer. Darüber hinaus wird ein Abrechnungsdatensatz im Auftrag des Meeting-Gastgeberbenutzers generiert.
6. BroadWorks leitet den Anruf entweder an den mit dem Gerät verknüpften Benutzer (7) oder an PSTN (8) weiter.

Vorbereitungen

Die SIP-Kommunikation zwischen BroadWorks und dem CUBE kann je nach Ihren Netzwerkanforderungen über UDP oder TCP erfolgen. Wenn beispielsweise einige Netzwerk- oder Zugriffsgeräte (z. B. Gateways oder Endpunkte) in den BYoPSTN-Einwahl- oder Rückrufverläufen TCP nicht unterstützen, sollte stattdessen UDP verwendet werden.

Die Konfiguration und die in diesem Handbuch gezeigten Beispiele verwenden TCP als Transportprotokoll. Um TCP zu verwenden, stellen Sie sicher, dass Ihr BroadWorks Anwendungsserver und Netzwerkserver für TCP konfiguriert sind:

_CLI/Interface/SIP> get
networkProxyTransport = unspecified
accessProxyTransport = unspecified
supportDnsSrv = true
supportTcp = true

Anwendungsserver

Identifizieren/Geräteprofiltyp

Es sollte ein neuer Identitäts-/Geräteprofiltyp erstellt werden, der den CUBE darstellt. Stellen Sie sicher, dass Sie die folgenden Eigenschaften unten festlegen, während andere bei den Standardwerten belassen werden können:

• Signalisierungsadressentyp: Auf Intelligent Proxy Addressing (Intelligente Proxyadressierung) festlegen

• Authentifizierung – auf Aktiviert festlegen

• Unterstützungsidentität in UPDATE und Re-INVITE – Aktiviert

• Statische Registrierung möglich – Aktiviert auf festlegen

• Video aktiviert – auf deaktiviert festlegen

Im folgenden Beispiel wird der neue Identitäts-/Geräteprofiltyp „VXML _profile“ erstellt, um den CUBE darzustellen.

Virtueller Sprach-XML-Abonnent

Erstellen einer VoiceXML-Instanz

Jede Webex Meetings-PSTN-Nummer wird in BroadWorks von einem virtuellen Subscriber dargestellt, und die VoiceXML-Funktionalität für virtuelle Subscriber kann verwendet werden. Es wird empfohlen, dass ein dediziertes Unternehmen und eine dedizierte Gruppe für alle virtuellen VoiceXML-Subscriber verwendet werden. Beachten Sie, dass wir keine VoiceXML-Funktionen nutzen, aber dieser virtuelle Benutzer-Typ ist für die Interaktion mit dem CUBE geeignet.

Um den VoiceXML-Dienst zu verwenden, stellen Sie sicher, dass die Lizenz über ausreichende „VoiceXML“-Mengen verfügt und dass der Dienst auf Unternehmens- und Gruppenebene autorisiert ist und der VoiceXML-Dienst der Gruppe zugewiesen wird, wie im Beispielbild unten dargestellt.

Unter Gruppe > Dienste , wählen Sie VoiceXML aus und erstellen Sie eine Instanz für jede PSTN-Nummer.

VoiceXML-Adressen konfigurieren

Stellen Sie für jede VoiceXML-Instanz unter den VoiceXML-Adressen Folgendes bereit:

• Telefonnummer – Geben Sie die Einwahlnummer für die Webex Meetings-Site ein (z. B. 2403332200).

• Durchwahl

• Identität/Geräteprofil – Erstellen Sie eine Instanz (z. B. VXML _device Prof) basierend auf dem im vorherigen Abschnitt erstellten Gerätetyp (VXML _profile im Beispiel) und geben Sie die folgende Konfiguration ein.

• Leitung/Port – Geben Sie Folgendes im Format <access number="">@<domain> ein:

  • <access number=""> ist die Zugriffscode-Nummer für die Webex Meetings-Site (in der JSON-Datei verfügbar) (z. B. 88631321777971704941)

  • <domain> ist die Domäne von Webex Edge Audio für diese Meeting-Site (z. B. ecccspx.amer.pub.webex.com)

• Kontakt sip – Bei Meeting-Einwahlanrufen an die Zugriffsnummer wird die EINLADUNG mit einer Anforderungs-URI gesendet, die auf den Wert dieses Felds festgelegt ist. Geben Sie den SIP-Kontakt in diesem Format <sip contact="">;<Locale>;<Meetings Site="" UUID="">;<SIP transport=""> ein, wobei:

  • <sip contact=""> ist der <number> vom Feld „Leitung/Port“, aber mit der Domäne als SRV, der zur Adresse des CUBE aufgelöst wird (z. B. 88631321777971704941@cube.internal.local)

  • <Locale> stellt die Spracheinstellung entsprechend dem Gebietsschema des Benutzers dar (z. B. Gebietsschema = en_ US)

  • <Meetings Site="" UUID=""> ist Site-UUID aus der JSON-Datei (z. B. x-cisco-site-uuid=abbd70f6c519fb1ee053ad06fc0a038b)

  • <SIP transport=""> sollte transport=tcp sein, damit der AS TCP verwendet, um Nachrichten an den CUBE zu senden.

Unten finden Sie ein Beispiel für VoiceXML-Adresseneinstellungen.

Für jede zusätzliche Meeting-Zugangsnummer, die verwendet werden soll, sollte analog zu der oben genannten ein zusätzlicher virtueller VoiceXML-Abonnent erstellt werden. Dasselbe Geräteprofil kann verwendet werden, aber die Felder Leitungsport und Kontakt müssen wie oben gezeigt anhand der Zugriffsnummerinformationen konstruiert werden.

Stellen Sie sicher, dass die Einschränkungen der Anrufverarbeitungsrichtlinie, die Sie auf dem virtuellen BroadWorks-Subscriber konfigurieren, ausreichen, um die zusätzlichen BYoPSTN-Anrufe in Ihrer Telefonnummerngruppe zu verarbeiten.

Zuweisen der SIP-Authentifizierung zur VoiceXML-Instanz

Weisen Sie den Authentifizierungsdienst dem virtuellen VoiceXML-Subscriber zu. Dies wird verwendet, um SIP INVITE-Nachrichten vom CUBE im Rückruf-Szenario zu authentifizieren. Außerdem wird verhindert, dass der virtuelle VoiceXML-Abonnent Anrufe von anderen Parteien als dem CUBE annimmt.

Rufen Sie die Authentifizierungsseite für virtuelle Subscriber unter „Dienstprogramme“ auf und geben Sie den SIP-Benutzernamen und das Kennwort ein (siehe Abbildung unten):

CUBE muss mit dem gleichen Benutzernamen und Kennwort konfiguriert sein, um die INVITE-Nachrichten, die an den Anwendungsserver gesendet werden, ordnungsgemäß zu authentifizieren. Ein Beispiel für den Befehl zum Konfigurieren der SIP-Authentifizierung auf dem CUBE lautet wie folgt: sip-ua authentication username VSUB password 0 <unencrypted password> (See the CUBE onfiguration/datafill for more details).

Namedefs-Datei

Das Feld für den SIP-Kontakt des virtuellen VoiceXML-Subscribers enthält die URL, unter der der Domänenteil zur CUBE-Adresse aufgelöst wird. Dies ist ein interner SRV, und die namedefs-Datei auf dem AS kann verwendet werden, um den internen SRV in die CUBE IP aufzulösen.

In unserem Beispiel lautet der SIP-Kontakt SRV cube.internal.local und löst die Adresse 10.165.196.30 Port 5060 auf, um den CUBE zu erreichen. Auf dem AS befinden sich die /usr/local/broadworks/bw_base/conf/namedefs Datei wird wie folgt aktualisiert:

_sip.tcp.cube.internal.local SRV 1 99 5060 10.165.196.30

Webex Meetings-Anruftyp

Die Konfigurationsoptionen für die Anrufverarbeitung in Webex Meetings sind verfügbar, um zu steuern, wie Einwahlanrufe in Meetings behandelt werden. Standardmäßig werden Meeting-Einwahlanrufe als externe Anrufe verarbeitet, da Einwahlnummern in einem dedizierten Unternehmen oder Serviceanbieter gehostet werden. Externe Anrufe werden normalerweise in die Sitzungsanzahl der Sitzungszugangskontrolle aufgenommen und im CDR-Feld „ chargeIndicator“ für das Laden gekennzeichnet.

Im folgenden Beispiel wird die empfohlene Konfiguration hinzugefügt, um Meeting-Call-Ins als interne Anrufe so zu verarbeiten, dass sie nicht geladen und von der Anzahl der Sitzungszugangskontrollen ausgeschlossen werden.

Wenn Sie „N Charge Field erzwingen“ auf „true“ festlegen, basiert die Population des CDR-Felds „chargeIndicator“ auf dem konfigurierten Charge-Attribut des Anruftyps „Network Server“.

AS_CLI/System/CallP/WebexMeetings/WebexCallTypes> add "Webex Meetings" WXM true true

AS_CLI/System/CallP/WebexMeetings/WebexCallTypes> get
      Name    NS Call Type    Enforce NS Charge Field  Process As Internal For SAC-Subscriber
  ==========================================================================================
  Webex Meetings       WXM               true                                true

Virtueller Teilnehmer für VoiceXML-Meeting-Rückruf

Erstellen eines VoiceXML-Meeting-Rückruf-Abonnenten

Ein dedizierter virtueller VoiceXML-Subscriber mit einer speziellen Rückruf-Option für Webex-Meetings (nachfolgend VoiceXML-Meeting-Callback-Subscriber genannt) muss auf dem BroadWorks Application Server (AS) konfiguriert werden, um die Webex Meetings-Rückrufe zu verarbeiten. Nur eine einzelne Instanz dieses Subscribers kann auf dem Anwendungsserver konfiguriert werden.

Um die Funktion zu aktivieren, legen Sie die aktivierbare Funktion 102074 über CLI auf „true“ fest.

AS_CLI/System/ActivatableFeature> activate 102074
***** Warning *****:
This activity should only be done during a maintenance window because
this may cause large amounts of data to be added/modified/deleted and
it may take some time to execute. Features that have web page impacts
require that users and administrators log out and log back in.
Are you sure you want to continue?

Please confirm (Yes, Y, No, N): y
...Done

AS_CLI/System/ActivatableFeature> get

      Id                                               Description  Activated  Last Modified Timestamp
=============================================================================================
  102746                            BroadWorks Support for CI UUID       true
  102074          BYO PSTN Billing support for CallBack and CallIn       true      
  104256                          Weak Password Validation Service      false
  104073  Add FAC Support for Call Center Agent Join-Unjoin in CDR      false
  103542   Configurable Endpoint For Auto-Answer And Forced Answer      false
  104255    Control password usage and behavior to ensure security      false

Da die Funktion „BYO PSTN Billing Support for CallBack and CallIn“ von der Funktion „BroadWorks Support for CI UUID“ abhängt, müssen Sie vor dem Aktivieren der Funktion (102074) auch die Funktion (102746) aktivieren. Weitere Informationen finden Sie im Abschnitt „CI-Benutzer-UUID-Synchronisierung (Broadworks-Unterstützung für CI-UUID)“.

Der VoiceXML-Meeting-Rückruf-Subscriber ähnelt dem bestehenden virtuellen BYOPSTN VXML-Subscriber, hat jedoch eine neue Markierung „Webex Meeting-Rückruf“ erhalten. Dieser VoiceXML-Meeting-Rückruf-Subscriber ist mit demselben Geräteprofil wie der vorhandene virtuelle BYOPSTN VXML-Subscriber sowie der Authentifizierungsdienst mit denselben Anmeldeinformationen konfiguriert.

Ein Beispiel wird unten gezeigt:

Der VoiceXML-Meeting-Rückruf-Subscriber muss auf dem AS vorhanden sein, der den Benutzer des Meeting-Gastgebers hostet. Wenn der AS die Meeting-Rückruf-INVITE-Anforderung erhält, versucht er, während der Anrufeinrichtung sowohl den VoiceXML-Meeting-Rückruf-Benutzer als auch den Meeting-Gastgeberbenutzer im AS zu suchen. Wenn keiner dieser Benutzer gefunden wird, wird der Anruf abgelehnt.

Meeting-gastgebersitzung

Im Rückrufszenario mit dem X-Cisco-Meet-Info-Header erhält der Cisco BroadWorks Application Server eine SIP INVITE-Anforderung und identifiziert den Benutzer des Meeting-Gastgebers mit dem Host CI User UUID-Parameter des SIP X-Cisco-Meet-Info-Headers. Eine Anrufsitzung wird im Auftrag des Meeting-Gastgeberbenutzers erstellt, um den Anruf zu verarbeiten und das Dienstprofil des Benutzers auszuführen. Darüber hinaus wird ein Abrechnungsdatensatz im Auftrag des Meeting-Gastgeberbenutzers generiert. Die Meeting-ID und die Site-UUID-Informationen aus dem SIP X-Cisco-Meet-Info-Header werden im Abrechnungsdatensatz erfasst.

Ein Beispiel für den SIP X-Cisco-Meet-Info-Header wird unten angezeigt:

X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab
-04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec

Anwendungsbereitstellungsplattform

CI-Benutzer-UUID-Synchronisierung (Broadworks-Unterstützung für CI-UUID)

Die Benutzer-CI-UUID ist eine eindeutige Kennung zur Identifizierung von Benutzern in der Webex-Umgebung.

Diese Webex Provisioning Sync-Anwendung auf der Cisco BroadWorks Application Delivery Platform (ADP) wird zum Synchronisieren, Zuordnen und Speichern der Benutzer-CI-UUID in der BroadWorks-Infrastruktur verwendet, sodass sie in verschiedenen Interaktionen mit Webex und Webex für den BroadWorks-Dienst verwendet werden kann.

Lesen Sie „ Webex Meeting Callback aktivieren“, um zu erfahren, wie die CI User UUID-Verknüpfung vom Cisco BroadWorks-Netzwerkserver und dem Cisco BroadWorks-Anwendungsserver verwendet wird.

Die folgenden Schritte richten die Webex Provisioning Sync-Anwendung ein, um die BroadWork-Benutzer regelmäßig mit der CI-UUID abzufragen und zu aktualisieren.

Die Webex Provisioning Sync-Anwendung erfordert OAuth-Anmeldeinformationen mit dem spark-admin:broadworks_subscribers_read scope für den Cisco Identitätsanbieter und kann über eine Serviceanfrage bei Ihrem Onboarding-Agenten abgerufen werden.

Weitere Informationen zum Erstellen der Serviceanfrage finden Sie im Abschnitt „Abrufen von OAuth-Anmeldeinformationen für Ihr Webex für Cisco BroadWorks“ unter: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wx4bwks/Solution_Guide/wbxbw_b_solution-guide/wbxbw_b_SolutionGuide-PDF_chapter_01.html?bookSearch=true#Cisco_Generic_Topic.dita_0e1beabc-80ae-4e8d-b177-17108ec5daed

Fügen Sie das Token mit einem entsprechenden Partnernamen wie folgt hinzu:

ADP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CiscoIdentityProvider/Partners> add custBYO refreshToken
      New Password:
      Re-type New Password:
      ADP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CiscoIdentityProvider/Partners> get
       Partner Name  Refresh Token
==================================
  FederationPartner       ********
           custPart       ********
            custBYO       ********

Fügen Sie den dem OAuth-Token zugeordneten Partnernamen zur Liste der Partner hinzu, die von der Webex Provisioning Sync-Anwendung überwacht werden sollen, wobei das Flag „aktiviert“ auf „true“ gesetzt ist.

Mit dieser Webex Provisioning Sync-Anwendung wird mit der UUID-Synchronisierung des CI-Benutzers im definierten Abrufintervall begonnen.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> add custBYO true

Nachdem der Partner einbezogen wurde, kann die Webex Provisioning Sync-Anwendung jetzt die Zuordnung der CI UUID zu den BroadWorks-Benutzern durchführen.

Ändern Sie die Verbindungszeitüberschreitung mit den folgenden Befehlen:

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> set requestTimeout 30000
...Done

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> get
requestTimeout = 30000

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> cd http

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller/Http> set connectionTimeout 300
*** Warning: BroadWorks needs to be restarted for the changes to take effect ***

ADP_CLI/Application/WebexProvisioningSync/GeneralSetting/Controller/HTTP > get
connectionPoolSize = 5
connectionTimeout = 300
connectionIdleTimeOut = 300
maxConcurrentRequests = 10
maxCookieAgeInHours = 24

Diese Zuordnung kann automatisch oder manuell erfolgen. Der Befehl CLI manualSync kann die Zuordnung sofort auslösen.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> manualSync custBYO

Partner, bei denen „Aktiviert“ auf „true“ festgelegt ist, führen die zugeordneten Abfragen im Abfrageintervall durch. Während der anfänglichen Zuordnung fragt die Webex Provisioning Sync-Anwendung die Webex Subscriber-API ab, um die Daten mit der CI UUID für alle vom Partner gehosteten Benutzer abzurufen. Die externe ID des BroadWorks-Benutzers wird mit der zugehörigen CI-UUID aktualisiert. Nachfolgende Zuordnungen wirken sich auf Benutzer aus, die dem Partner hinzugefügt werden. Der Befehl status kann verwendet werden, um zu sehen, ob die Synchronisierung abgeschlossen ist.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> status
  Partner Name         Status                 Last Sync Time
============================================================
       custBYO  synchronizing
      custPart     monitoring  2023-01-29T15:36:43.873-05:00
2 entries found.

Sobald die Synchronisierung abgeschlossen ist, wechselt der Status wieder zur Überwachung. Nachfolgende Synchronisierung wird für Benutzer durchgeführt, die dem Partner nach der „Letzten Synchronisierungszeit“ hinzugefügt wurden.

Die folgende Abbildung zeigt die innerhalb der externen ID festgelegte CI-UUID:

Netzwerkserver

Anruftyp

Zu Abrechnungs- und Berichtszwecken kann es wünschenswert sein, CDRs für Meetings-Einwahlanrufe zu markieren. Dies kann mithilfe der Richtlinie „PreCallTyping“ des Netzwerkservers erfolgen.

Fügen Sie zunächst auf der NS-CLI unter /System/CallP/CallType einen neuen Anruftyp hinzu. Im folgenden Beispiel wird der neue Anruftyp „WXM“ hinzugefügt:

NS_CLI/System/CallP/CallTypes> add WXM LOCAL true false "Webex Meetings"
NS_CLI/System/CallP/CallTypes> get calltype WXM    
  CallType     Description  Category         Scope  SupportE164  Charge      
=======================================================================    
  WXM          Webex Meetings  LOCAL  User Defined         true   false

Der Anruftyp kann dann in einer PreCallTyping-Instanz verwendet werden, die Teil des Routing-Profils des BroadWorks-Benutzers ist. In diesem Beispiel wurde eine neue PreCallTyping-Instanz „wxm“ unter dem Kontext /Policy/PreCallTyping CLI hinzugefügt, es könnte sich jedoch um eine bereits verwendete PreCallTyping-Instanz handeln:

NS_CLI/Policy/PreCallTyping> add wxm true CallTypes ALL

NS_CLI/Policy/PreCallTyping> get wxm                        
Policy: PreCallTyping  Instance: wxm                        
  CallTypes:                                
    Selection = {ALL}                                
    From = {PCS, ALL, TRMT, LO, GNT, DP, WXM, LPS, OA, TPS, EA, FGB, POA, SV, SVCD, IN, MS, CSV, EM, SVCO, SMC, ZD, NIL, CT, TF, GAN, TO, DA, OAP}        
  supportLCABasedNormalization = false                        
  Enable = true 

Der nächste Schritt besteht darin, der PreCallTyping-Instanz Einträge für alle Einwahlnummern im CLI-Kontext /Policy/PreCallTyping/DialPlan hinzuzufügen. Zum Beispiel:

NS_CLI/Policy/PreCallTyping/DialPlan> add wxm 1 dflt 12403332200 12403332200 exact 11 11 WXM 0 0 Webex Meetings
NS_CLI/Policy/PreCallTyping/DialPlan> add wxm 1 dflt_e164 12403332200 12403332200 exact 11 11 WXM 0 0 Webex Meetings

NS_CLI/Policy/PreCallTyping/DialPlan> get wxm 1                
Policy: PreCallTyping  Instance: wxm  Table: DialPlan                
CC Dial Plan   From     To          Match Min Max Call Type Prefix Action  Call Ind  Description                  
================================================================================================
1 dflt      12403332200 12403332200 {exact} 11 11 {WXM}     0                      Webex Weetings
1 dflt_e164 12403332200 12403332200 {exact} 11 11 {WXM}     0                      Webex Meetings

Anschließend wird die PreCallTyping-Instanz (sofern sie noch nicht vorhanden ist) dem entsprechenden Routing-Profil des ursprünglichen Benutzers hinzugefügt, wie im folgenden Beispiel gezeigt:

NS_CLI/Policy/Profile> add Profall PreCallTyping wxm
NS_CLI/Policy/Profile> get profile Profall
Profile:  Profall
                 Policy              Instance
   ==========================================
             CallTyping           DefaultInst
          CallScreening           DefaultInst
            SubLocation           DefaultInst
              FarEndRtg           DefaultInst
             NearEndRtg           DefaultInst
             UrlDialing           DefaultInst
            MediaSrvSel           DefaultInst
                 SIMPLE           DefaultInst
              DstSvcRtg           DefaultInst
      NumberPortability           DefaultInst
             RCBasedRtg           DefaultInst
      NetVoicePortalRtg           DefaultInst
          PreCallTyping                   wxm    

BroadWorks-CDR werden nur durch Anrufe generiert, die von BW-Subscribern stammen. PSTN-Anrufe von der „Netzwerk“-Seite des AS generieren keine Quell-CDR. In beiden Fällen wird die CDR für den virtuellen VoiceXML-Subscriber beendet.

RoutingNE

Eine RoutingNE ist auf dem NS unter /System/Device/RoutingNE CLI-Kontext erforderlich, um den CUBE darzustellen. Auf diese Weise wird das NS, wenn es die INVITE vom CUBE erhält, mit dem Via-Header zum RoutingNE-Eintrag übereinstimmen, der auf dem NS bereitgestellt wird. Siehe Administrationsleitfaden für die Cisco BroadWorks-Netzwerkserver-Befehlszeile für Details zum Hinzufügen einer RoutingNE.

Im Folgenden finden Sie ein Beispiel für die Befehle zum Hinzufügen der RoutingNE „WebexMeetings“, wobei die CUBE IP-Adresse 10.165.196.30 ist. Das Beispiel zeigt auch Befehle zum Erstellen einer neuen OrigRedirect- und Profile-Instanzen, die mit der RoutingNE verknüpft werden sollen, aber auch vorhandene Instanzen können verwendet werden.

NS_CLI/Policy/OrigRedirect> add wxm_Inst true CallTypes ALL supportTrunkGroupLookups disable applyAccessSideRules enableRestrictive

NS_CLI/Policy/OrigRedirect> get  wxm_Inst
Policy: OrigRedirect  Instance: wxm_Inst
  Enable = true
  CallTypes:
    Selection = {ALL}
    From = {PCS, ALL, TRMT, LO, GNT, DP, WXM, LPS, OA, TPS, EA, FGB, POA, SV, SVCD, IN, MS, CSV, EM, SVCO, SMC, ZD, NIL, CT, TF, GAN, TO, DA, OAP}
  supportTrunkGroupLookups:
    Selection = {disable}
    From = {disable, enablePermissive, enableRestrictive}
  applyAccessSideRules:
    Selection = {enableRestrictive}
    From = {disable, enablePermissive, enableRestrictive}

NS_CLI/Policy/Profile> add wxm_routing

NS_CLI/Policy/Profile> add wmx_routing OrigRedirect wxm_Inst

NS_CLI/Policy/Profile> add wmx_routing SubLocation  DefaultInst

NS_CLI/Policy/Profile> get profile wxm_routing 
Profile:  wxm_routing
                 Policy              Instance
   ==========================================
           OrigRedirect           wxm_Inst
            SubLocation           DefaultInst

NS_CLI/System/Device/RoutingNE> add  WebexMeetings 1240364 1 99 wxm_routing false OnLine AccessRoutingNE

NS_CLI/System/Device/RoutingNE/Address> add WebexMeetings 10.165.196.30 1 99 tcp

NS_CLI/System/Device/RoutingNE> get
Network Element  WebexMeetings
   Location      =  1240364
   Static Cost   =  1
   Static Weight =  99
   Poll          =  false
   OpState       =  enabled
   State         =  OnLine
   Profile       =  wxm_routing
   Signaling Attributes=  AccessRoutingNE
 
NS_CLI/System/Device/RoutingNE/Address> get
Routing NE   Address     Cost    Weight     Port    Transport Route  
WebexMeetings   10.165.196.30     1      99     -          tcp

Mit der Beispielkonfiguration sendet der CUBE dem NS eine INVITE, die den folgenden ähnelt (wichtige Felder fett dargestellt):

INVITE sip:+19991111111@domain.com:5060 SIP/2.0
Via:SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK7C7B9EB
Remote-Party-ID:" BroadWorks
"<sip:886222222222@domain.com>;screen=no;party=calling;privacy=off
From:" BroadWorks "<sip:+12403333333@10.20.20.20>;tag=958BDDF4-1AB
To:<sip:+19991111111@domain.com>
Date:Thu, 03 Nov 2022 12:39:58 GMT
Call-ID:75D3B642-5AAB11ED-AC82BA3C-276254A1@10.20.20.30
Supported:100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:14400
Cisco-Guid: 1976459008-1521160685-2893855292-0660755617
X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec"
X-Cisco-Org-Id:82e2eb35-1610-44e7-9b20-ab607e026270
User-Agent: Cisco-SIPGateway/IOS-16.12.2s
Timestamp: 1667479198
Session-ID:
e13cc71f24ae400669d5247d8306ac23;remote=00000000000000000000000000000000
Allow:INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGSTER
CSeq:101 INVITE
Contact:<sip:+12403333333@10.20.20.20:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Max-Forwards:68

Erläuterung:

• INVITE-Anforderungs-URI enthält die Rückrufnummer

• Über Kopfzeile: enthält die IP-Adresse des CUBE, die zum Auswählen des RoutingNE-Profils verwendet wird.

• X-Cisco-Info-Meet Kopfzeile: verwendet, um hostCIUserUuid, meetingid & siteUUID zu identifizieren.

Nach dem Empfang der EINLADUNG verwendet das NS den Via-Header, um mit der RoutingNE „WebexMeetings“ zu übereinstimmen. Dadurch wird wiederum das „wxm_routing“-Routing-Profil ausgewählt, das die „wxm_ Inst“-Instanz der OrigRedirect enthält.

Die NS OrigRedirect-Richtlinie stimmt dann mit der X-CISCO-MEET-INFO-Kopfzeile überein:

X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec

mit dem Leitungsport, der auf dem virtuellen VoiceXML-Subscriber konfiguriert ist, und eine 302-Umleitung an das AS-Paar senden, das diesen Subscriber hostet. Die 302-Nachricht ähnelt der folgenden:

SIP/2.0 302 Moved temporarily
Via:SIP/2.0/TCP 10.165.196.30:5060;branch=z9hG4bK5452684
From:" Webex "<sip:+12403332200@10.165.196.30>;tag=8EEAA586-1675
To:<sip:+14519615001@10.155.6.172>;tag=394411970-1602687588994
Call-ID:ABC5CCA2-D6411EB-8AD6D92D-EE20F768@10.165.196.30
CSeq:101 INVITE
Contact:<sip:+14519615001@hs2-bwks-v-as01-alpha.bwlab.org:5060;user=phone> ;q=0.5, <sip:+14519615001@hs2-bwks-v-as02-alpha.bwlab.org:5060;user=phone>;q=0.25
Content-Length:0

Alias

Die Domäne in der INVITE-URI (im Beispiel: bw.myenterprise.com), die vom CUBE an das NS gesendet wird, muss vom NS erkannt werden. Dies kann durch Hinzufügen der Domäne im NS _ CLI/System/Alias-Kontext erfolgen. Beispiel:

NS_CLI/System/Alias> add bw.myenterprise.com

Der Befehl zum Konfigurieren der INVITE-URI-Domäne auf dem CUBE befindet sich im nächsten Abschnitt unter Dial-Peer/Sitzungsziel, z. B.:

dial-peer voice 23401 voip
session target dns:bw.myenterprise.com

HostingNE

Um die Konfigurationsoptionen für die Webex Meetings-Anrufverarbeitung für Abrechnung und Sitzungszugangskontrolle zu unterstützen, müssen die NE-Signalisierungsattribute CallTypeInfoRequired und RequiresChargeIndication des Anwendungsservers im NS_CLI/System/Device/HostingNE-Kontext aktiviert sein._ Zum Beispiel:

NS_CLI/System/Device/HostingNE> set broadworksASHostNe signaling E164Compliant,
 CallTypeInfoRequired, SourceId, RequiresNetworkIndication RequiresChargeIndication;

Webex Meeting-Rückruf aktivieren

Im Rückrufszenario mit dem SIP X-Cisco-Meet-Info-Header sendet der CUBE den Anruf an den Netzwerkserver, um die Ersteller-Umleitung an das AS-Paar zu ermöglichen. Das AS-Paar wird basierend auf dem Systemparameter enableWebexMeetingHoostLookup ermittelt.

NS_CLI/System/CallP/Options> get
  accessSideRoutingNeDeterminedViaSignaling = false
  disableNdcValidationForCalledNumbers = true
  forceRoutingNEProfile = false
  skipPrivatePoliciesOnEmergency = true
  maxReturnedContacts = 10
  enableWebexMeetingHostLookup = true

Wenn der Systemparamter enableWebexMeetingHoostLookup auf „true“ festgelegt ist, wird die CI UUID des Meeting-Gastgeberbenutzers im X-Cisco-Meet-Info-Header verwendet, um das AS-Paar zu identifizieren, das den Meeting-Gastgeberbenutzer hostet.

INVITE sip:+19991111111@domain.com:5060 SIP/2.0
Via:SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK7C7B9EB
Remote-Party-ID:" BroadWorks "<sip:886222222222@domain.com>;screen=no;party=calling;privacy=off
From:" BroadWorks "<sip:+12403333333@10.20.20.20>;tag=958BDDF4-1AB
To:<sip:+19991111111@domain.com>
Date:Thu, 03 Nov 2022 12:39:58 GMT
Call-ID:75D3B642-5AAB11ED-AC82BA3C-276254A1@10.20.20.30
Supported:100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:14400
Cisco-Guid: 1976459008-1521160685-2893855292-0660755617
X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab-04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec"
X-Cisco-Org-Id:82e2eb35-1610-44e7-9b20-ab607e026270
User-Agent: Cisco-SIPGateway/IOS-16.12.2s
Timestamp: 1667479198
Session-ID: e13cc71f24ae400669d5247d8306ac23;remote=00000000000000000000000000000000
Allow:INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGISTER
CSeq:101 INVITE
Contact:<sip:+12403333333@10.20.20.20:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Max-Forwards:68

Dieser Abschnitt enthält eine validierte Konfiguration für die Bereitstellung von Cisco Unified Border Element (CUBE) als Session Border Controller (SBC) für die Bring Your Own PSTN-Lösung.

Dieser Abschnitt konzentriert sich auf die CUBE-Konfigurationen, die für die Zusammenarbeit mit der im vorherigen Abschnitt gezeigten Beispiel-Konfiguration von Webex für Cisco BroadWorks erforderlich sind. Eine allgemeinere Erläuterung der anfänglichen CUBE-Bereitstellung und -Konfiguration finden Sie in den folgenden Handbüchern: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-overview.html

https://help.webex.com/en-us/b6vrdc/Cisco-Webex-Edge-Audio-for-CUBE-Customer-Configuration-Guide

Unsere eigene SBC-Option für Y bereitstellen

Wenn Sie CUBE nicht bereitstellen möchten, haben Sie die Möglichkeit, Ihren eigenen SBC bereitzustellen. Beachten Sie jedoch, dass dieses Dokument keine validierte Konfiguration für SBCs mit Ausnahme von CUBE bietet.

Wenn Sie Ihren eigenen SBC bereitstellen, können Sie die allgemeinen CUBE-Konfigurationsanforderungen (z. B. Zuweisungen wie Domäne, öffentliche und private Schnittstellen und Gateways) befolgen, um Ihre Konfiguration zu leiten. Detaillierte Befehlszeilenhilfe finden Sie jedoch in Ihrer SBC-Dokumentation, da sich die tatsächlichen Befehle für Ihren eigenen SBC wahrscheinlich von CUBE unterscheiden.

Sofern nicht anders angegeben, gelten die verbleibenden Konfigurationsanforderungen in Schritt 10, unabhängig davon, welchen SBC Sie bereitstellen. Die Befehlszeilenbeispiele gelten jedoch nur für CUBE, es sei denn, es wird angegeben, dass das Beispiel für andere SBCs gilt. Weitere SBCs finden Sie in der SBC-Dokumentation für Konfigurationsbefehle.

Nachdem die Konfiguration und Bereitstellung der BYoPSTN-Lösung abgeschlossen ist, muss der Partner eine Reihe von Akzeptanztestfällen durchlaufen, um seine Lösung zu zertifizieren. Dies ist ein erforderlicher Schritt, damit der Partner BYoPSTN genehmigt und aktiviert werden kann.

Die Akzeptanztestfälle werden im Dokument „Bring Your Own PSTN Acceptance Procedure Webex For Cisco BroadWorks“ beschrieben unter: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cloudCollaboration/wx4bwks/BYoPSTN/BYoPSTN_Acceptance.pdf .

Der Partner sollte den Onboarding- und Zertifizierungsteams die Ergebnisse der erfolgreich durchgeführten Abnahmetests zur Verfügung stellen.

Fragen, Probleme und Ergebnisse aus der Durchführung der Akzeptanztestfälle sollten im für das Onboarding des Partners zugewiesenen Webex-Bereich gemeldet und freigegeben werden.

Für die Bereitstellung von BYoPSTN müssen die folgenden Voraussetzungen erfüllt sein. Die unten angegebenen Voraussetzungen gehen davon aus, dass der Partner über eine funktionierende Webex für Cisco BroadWorks-Bereitstellung verfügt, die Folgendes umfasst:

• Funktionieren des BroadWorks-Systems – wie im Lösungshandbuch zu Webex für Cisco BroadWorks dokumentiert

• BroadWorks ALS Lizenz mit „VoiceXML“-Dienst in ausreichender Menge (1 pro PSTN-Nummer)

• BroadWorks-Patches erforderlich:

  Für R22:

  • AP.xsp.22.0.1123.ap376935

  • AP.as.22.0.1123.ap376935

  Für R23:

  • AP.xsp.23.0.1075.ap376935

  • AP.as.23.0.1075.ap376935

  Für R24

  • AP.as.24.0.944.ap376935

• Bereitgestelltes Cisco CUBE-System (IOS Version 16.12.2 oder höher): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html

  Sowohl hardwarebasierter als auch virtueller CUBE wird unterstützt. Hardware-basierter CUBE wird für Skalierbarkeit und die Verarbeitung einer größeren Anzahl von Anrufen empfohlen.

• Webex-Partnerorganisation – wie im Lösungshandbuch zu Webex für Cisco BroadWorks beschrieben

Die Vorgehensweise, die Cisco Partner zum Hinzufügen ihrer Webex-Meeting-Einwahlnummern verwendet, ist wie folgt:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Meeting Join-Konfiguration (BYoPSTN) die Option Create Call-in Phone Number Grou p.

5. Geben Sie den Namen der Telefonnummerngruppe ein und wählen Sie Weiter .

6. Geben Sie die Details Telefonnummer ein und wählen Sie Weiter .

7. Überprüfen Sie die Details zur Telefonnummerngruppe und wählen Sie „Speichern“ .

8. Wiederholen Sie diesen Vorgang für jede Telefonnummer, die hinzugefügt werden soll.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Dieser Schritt muss nur abgeschlossen werden, wenn Sie die Option „Meeting beitreten über Rückruf“ bereitstellen möchten. Andernfalls können Sie diesen Schritt überspringen.

Wenn Sie diese Option nicht konfigurieren, können Benutzer die Einwahloption verwenden, um Meetings beizutreten, oder sie können mit Computer-Audio beitreten.

Wenn Sie die Meeting-Rückruf-Option verwenden, ist eine Rückruf-DNS-SRV-Gruppe erforderlich, um Anrufe von Webex an CUBE weiterzuleiten. Der Cisco-Partner führt die folgenden Schritte aus, um seine CUBE DNS SRV-Datensätze zu Webex hinzuzufügen:

1. Melden Sie sich bei Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Meeting Join-Konfiguration (BYoPSTN) die Option Rückruf-DNS-SRV-Gruppe erstellen .

5. Geben Sie den Rückruf-DNS SRV Gruppennamen ein .

6. Wählen Sie Weiter aus.

7. Geben Sie die Rückruf-DNS-SRV-Details ein.

8. Wählen Sie Weiter aus.

9. Überprüfen Sie die Zusammenfassung der Rückruf-DNS-SRV-Details.

10. Wählen Sie Speichern.

11. Stellen Sie alle Aktualisierungen für DNS bereit, um die neuen Datensätze in der DNS SRV-Gruppe widerzuspiegeln.

12. Wiederholen Sie diesen Vorgang für jede Rückruf-DNS-SRV-Gruppe, die hinzugefügt werden soll.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Die anfängliche Konfiguration und Verifizierung der BYoPSTN-Lösung erfordert eine Startorganisation für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe (falls Rückruf erforderlich ist). Daher wird empfohlen, dass Cisco-Partner auf ähnliche Weise eine neue Kundenvorlage für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe erstellen. Jede Kundenvorlage sollte verwendet werden, um eine entsprechende Saatgutorganisation zu generieren.

Sobald die BYoPSTN-Konfiguration mithilfe der Samenorganisationen ausgesät und verifiziert wurde, können die Telefonnummerngruppen und Rückruf-DNS-SRV-Gruppen nach Bedarf auf vorhandene Kundenvorlagen angewendet werden.

Bitte beachten Sie, dass neu erstellte Kundenvorlagen nicht von bestehenden Nicht-Testkunden verwendet werden und somit sicher zur manuellen Überprüfung der BYoPSTN-Konfiguration verwendet werden können.

Wenn Sie den Meeting-Beitritt nicht über Rückruf bereitstellen, müssen Sie Rückruf-DNS-SRV-Gruppen nicht der Kundenvorlage zuordnen. Sie müssen jedoch „Rückruf deaktivieren“ auswählen.

Gehen Sie wie folgt vor, um eine neue Kundenvorlage hinzuzufügen:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Vorlagen die Option Vorlage hinzufügen aus.

5. Geben Sie die Vorlagendetails ein. Auf der Stufe Pakettyp :

   • Wählen Sie Pakettyp als Standard .

   • Wählen Sie Meeting-Beitrittskonfiguration als Vom Partner bereitgestellte Einwahlnummern (BYoPSTN).

   • Wählen Sie eine bereitgestellte Telefonnummerngruppe .

   • Wählen Sie für Rückruf-DNS-SRV-Gruppe eine bereitgestellte Rückruf-DNS-SRV-Gruppe aus, wenn Sie die Rückrufoption für das Meeting aktivieren möchten. Andernfalls wählen Sie „Rückruf deaktivieren“ aus .

6. Wählen Sie Weiter aus.

7. Geben Sie die restlichen Vorlagendetails ein.

8. Überprüfen Sie die Zusammenfassung der Vorlagendetails.

9. Klicken Sie auf Speichern.

10. Wiederholen Sie diesen Vorgang für jede Kundenvorlage, die hinzugefügt werden muss.

Der folgende Screenshot veranschaulicht die Vorgehensweise.

Um eine vorhandene Kundenvorlage zu aktualisieren, gehen Sie wie folgt vor:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zum Abschnitt BroadWorks Calling .

4. Wählen Sie unter Vorlagen die Option Vorlage anzeigen .

5. Wählen Sie die zu aktualisierende Vorlage aus.

6. Scrollen Sie zum Abschnitt Meeting-Beitrittskonfiguration :

   • Wählen Sie Vom Partner bereitgestellte Einwahlnummern (BYoPSTN).

   • Wählen Sie eine zuvor konfigurierte Telefonnummerngruppe .

   • Wählen Sie für Rückruf-DNS-SRV-Gruppe eine bereitgestellte Rückruf-DNS-SRV-Gruppe aus, wenn Sie die Rückrufoption für das Meeting aktivieren möchten. Andernfalls wählen Sie „Rückruf deaktivieren“ aus .

7. Wählen Sie Speichern.

   Der folgende Screenshot veranschaulicht die Vorgehensweise.

Die BYoPSTN-Lösung hat mehrere verschiedene Komponenten, von denen jede richtig konfiguriert werden muss, damit die Lösung erfolgreich funktioniert. Einer der beiden Zwecke der Samenlösungsorganisationen besteht darin, eine Telefonnummer für die Zuordnung von Meeting-Zugriffscodes und eine universell eindeutige Kennung der Meeting-Site (Site UUID) zu generieren, die für den laufenden Betrieb der Lösung erforderlich sind. Der andere Zweck ist die Konfigurationsverifizierung.

Für jede eindeutige Kombination aus Telefonnummerngruppe und Rückruf-DNS-SRV-Gruppe, die verwendet werden soll, sollte zuvor eine entsprechende Kundenvorlage erstellt werden. Für jede dieser Kundenvorlagen muss eine Saatgutlösungsorganisation bereitgestellt werden. Die Bereitstellung dieser Startorganisationen generiert die Telefonnummer für die Zuordnung von Meeting-Zugriffscodes und eine UUID der Meeting-Site, die für die Konfiguration von BroadWorks erforderlich sind.

Verwenden Sie jede der zuvor konfigurierten Kundenvorlagen, und stellen Sie einen Subscriber für einen neuen BroadWorks-Dienstanbieter oder ein neues BroadWorks-Unternehmen mit einem Standard-Paket Benutzer bereit. Die resultierende Meeting-Site Standardpaket sollte die Option zum Beitreten zu Meeting-Einwahlnummern von Partneranbietern verwenden. Eine der folgenden Methoden kann verwendet werden, um den Subscriber bereitzustellen:

1. Stellen Sie den Test-Subscriber mithilfe der BroadWorks Subscriber-APIs bereit, wie dokumentiert am developer.webex.com.

2. Aktivieren Sie den Test-Subscriber für den IM&P-Dienst auf einem BroadWorks, das für die Verwendung der Kundenvorlage konfiguriert ist. Stellen Sie sicher, dass die Kundenvorlage das Standardpaket verwendet, um sicherzustellen, dass dem Testteilnehmer ein Standardpaket zugewiesen wird. Alternativ muss der Test-Abonnent anschließend aktualisiert werden, um das Standard-Paket zu erhalten.

Beachten Sie, dass die Saatgutlösungsorganisationen mit einem BroadWorks-Dienstleister oder einem BroadWorks Enterprise-Test verknüpft sind.

Es ist wichtig, dass diese Meeting-Site weiterhin bereitgestellt wird, da diese Site-UUID in jeder Einwahl-Meeting-Beitrittsanforderung als Authentifizierungstoken gesendet wird. Sie sollten die Startorganisation nicht löschen, da auch die zugehörige Meeting-Site gelöscht wird. Wenn die Startorganisation entfernt wird, müssen Sie eine neue bereitstellen und Broadworks mit der neuen Site-UUID neu konfigurieren.

Die primären und alle sekundären Samenlösungsorganisationen können auf Wunsch gelöscht werden, bevor die Reihe von Telefonnummern und Rückruf-DNS-SRV-Datensätzen Nicht-Testkunden zugewiesen wird. Wenn der Satz von Telefonnummern und Rückruf-DNS-SRV-Datensätzen allen nicht getesteten Kunden zugewiesen ist, werden diese Telefonnummern und Rückruf-Datensätze mit Meeting-Sites für diese Kunden verknüpft und werden für den Beitritt zum Meeting über Einwahl und Rückruf verwendet. Änderungen sollten als sich auf den Dienst auswirkende Änderungen betrachtet werden.

Um die Primary Seed Solution Organization auszuwählen, gehen Sie wie folgt vor:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zum Abschnitt BroadWorks Calling .

4. Wählen Sie unter Configuration Validation (BYoPSTN) die Option Assign .

5. Suchen Sie im Bildschirm „Organisation zuweisen“ nach einer der zuvor konfigurierten Saatgutorganisationen und wählen Sie sie aus.

6. Wählen Sie Zuweisen.

   Die ausgewählte Saatgutorganisation ist die primäre Saatgutorganisation.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Die Details zur Primary Seed Solution-Organisation, zu Telefonnummerngruppen und Rückruf-DNS-SRV-Gruppen für einen bestimmten BroadWorks-Cluster sind an einem einzigen Standort verfügbar, der JSON-Datei für die BroadWorks-Konfiguration (BYoPSTN). Diese Informationen sind für die Konfiguration von BroadWorks für BYoPSTN erforderlich.

Beachten Sie, dass die JSON-Konfigurationsdatei nur zum Anzeigen/Herunterladen verfügbar ist, nachdem die primäre Startlösungsorganisation ausgewählt wurde.

Die Vorgehensweise zum Anzeigen/Herunterladen der JSON-Konfigurationsdatei lautet wie folgt:

1. Melden Sie sich beim Cisco Partner Hub an.

2. Öffnen Sie die Einstellungen.

3. Blättern Sie zu BroadWorks Calling .

4. Wählen Sie unter Cluster die Option Cluster anzeigen .

5. Wählen Sie den Cluster aus, der den für BYoPSTN konfigurierten Kundenvorlagen zugeordnet ist.

6. Blättern Sie zum Abschnitt BroadWorks-Konfiguration für BYoPSTN .

7. Klicken Sie auf JSON-Konfigurationsdatei herunterladen .

8. Wiederholen Sie diesen Vorgang für alle anderen BroadWorks-Cluster.

Die folgenden Screenshots veranschaulichen die Vorgehensweise.

Sehen Sie sich die Beispiel-JSON-Konfigurationsdatei unten an. Die Datei enthält zusätzliche Informationen zu jeder Telefonnummerngruppe, Rückruf-DNS-SRV-Gruppe. Die folgenden Schlüsselkonfigurationselemente, die in BroadWorks eingegeben werden müssen, sind fett markiert.

• siteUUID: BroadWorks muss diesen Wert in den SIP-Nachrichten senden. Hierbei handelt es sich um ein Token, das Webex Edge Audio verwendet, um die Identität von BroadWorks des Cisco-Partners und seinen Zugriff auf von diesem Cisco-Partner verwaltete Meeting-Sites zu bestätigen.

• Zuordnung von Telefonnummern zu Zugriffscodes: Die Telefonnummern und die zugehörigen Webex-Zugriffscodes müssen in BroadWorks konfiguriert werden.

  • phoneNumber

  • Zugriffscode

• localeTag: Die gewünschte Ansagesprache, die der Telefonnummer zugeordnet ist, muss auf BroadWorks konfiguriert werden.

• dnsSrv: Der Rückruf-DNS-SRV muss im DNS konfiguriert sein und sich auf die gewünschten CUBE-Instanzen beziehen.

{
   "siteUUID": "491db0821791441a96c233fefb6c6dfc",
   "siteURL": " seedtestenterpriseabc.webex.com ",
   "partnerOrgId": "1da175de-3651-4467-b26b-b0d85a2cb3ad",
   "solutionValidationOrgId": "d927ac4d-3d73-4d7f-8506-a1bc0a221934",
   "customerTemplates": [
      {
         "name": "US West Std",
         "id": "27fe1337-ab1d-44b0-8b5e-ff1d32f6e3f8",
         "phoneNumberGroupId": "1bcb05bd-b919-45fd-b30e-71d2abb59e26",
         "callbackDnsSrvGroupId": "25392686-a390-49b9-bad5-cb47159c3e992"
      },
      {
         "name": "US East Std",
         "id": "070d6682-b64f-46ea-bc4b-b2e1218ba4bb",
         "phoneNumberGroupId": "12bc0b8f-ea1d-457f-8fe2-069ccf78907e",
         "callbackDnsSrvGroupId": "25392686-a390-49b9-bad5-cb47159c3e992"
      }
   ],
   "phoneNumberGroups": [
   {
         "name": "US West",
         "id": "1bcb05bd-b919-45fd-b30e-71d2abb59e26",
         "phonenumbers": [
            {
               "id": "617c5faa-1721-45c7-bc70-e6d7c20ccc29",
               "name": "US Palo Alto",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "TollFree",
               "defaultPhoneNumberType": "NONE",
               "phoneNumber": "9863502478",
               "accessCode": "88672693772924908359"
            },
            {
               "id": "48fa7c50-9da0-4c8b-9b2f-307ff435c7c7",
               "name": "US Toll San Francisco",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "PRIMARY",
               "phoneNumber": "4156551000",
               "accessCode": "88652789466280320324"
            }
         ]
      },
      {
         "name": "US East",
         "id": "12bc0b8f-ea1d-457f-8fe2-069ccf78907e",
         "phonenumbers": [
            {
               "id": "ca0c622a-8621-4477-91e0-b3e214833568",
               "name": "US Maryland",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "PRIMARY",
               "phoneNumber": "2403332200",
               "accessCode": "88631321777971704941"
            },
            {
               "id": "00875574-9a46-4447-a967-350b6176755a",
               "name": "US Florida",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "Toll",
               "defaultPhoneNumberType": "SECONDARY",
               "phoneNumber": "9049002303",
               "accessCode": "88632627551145646175"
            },
            {
               "id": "a2c10316-9266-4423-a669-d67949f99d33",
               "name": "US New York",
               "countryCode": "US",
               "localeTag": "en_US",
               "tollType": "TollFree",
               "defaultPhoneNumberType": "NONE",
               "phoneNumber": "8056504578",
               "accessCode": "88649679020033567943"
            }
         ]
      }
   ],
   "callbackDnsSrvGroups": [
      {
         "name": "CB US",
         "callbackDnsSrvs": [
            {
               "name": "Callback US",
               "countryCode": "US",
               "dnsSrv": "cube.us.example.com",
               "id": "c5209d17-7c2f-45b3-95a6-65d7f5f53c7e"
            }
         ],
         "id": "25392686-a390-49b9-bad5-cb47159c3e992"
      },
      {
         "name": "CB MX",
         "callbackDnsSrvs": [
            {
               "name": "Callback MX",
               "countryCode": "MX",
               "dnsSrv": "cube.mx.example.com",
               "id": "cca0e4c3-5cff-412c-a854-bfb719f603a2"
            }
         ],
         "id": "36403797-b401-50c0-cbe5-dc58260d4f003"
      }
   ]
}

Die DNS SRV-Domäne für Webex Edge Audio muss in BroadWorks konfiguriert sein. Gehen Sie wie folgt vor, um den Wert zu ermitteln.

1. Melden Sie sich beim Cisco Partner Hub an.

2. Gehen Sie zu Kunden .

3. Wählen Sie das BYoPSTN-Validierungsunternehmen aus.

4. Wählen Sie Kunden anzeigen aus.

5. Gehen Sie zu Dienste/Meetings .

6. Wählen Sie die Meeting-Site des Standardpakets aus.

7. Scrollen Sie zum Ende des seitlichen Abschnitts und wählen Sie Site konfigurieren .

8. Wählen Sie Allgemeine Einstellungen/Audioeinstellungen .

9. Wählen Sie unter dem Abschnitt Edge Audio Custom Global Call-in Numbers die Option Generate Lua Script .

10. Suchen Sie im Popup-Fenster nach dem Wert „-- Header mit CCAX-URL aktualisieren“.

     
    -- Update To header with CCAX URL
     local oldTo1 = msg:getHeader("To")
     local newTo1 = string.gsub(oldTo1, "<sip:(.+)@(.*)>", "<sip:%1@ecccx.amer.webex.com>")
     msg:modifyHeader("To", newTo1)
    

11. Extrahieren Sie den Wert in Fettdruck, zum Beispiel ecccx.amer.webex.com.

Dies ist die DNS-SRV-Domäne für Webex Edge Audio, die in BroadWorks konfiguriert werden muss.

In diesem Abschnitt wird die BroadWorks-Konfiguration beschrieben, die erforderlich ist, um die Einwahl- und Rückruf-Szenarien für Meetings zu implementieren, die in den folgenden Diagrammen dargestellt werden. Die Konfigurationsbeispiele basieren auf den Daten in der JSON-Datei, die im vorherigen Abschnitt angezeigt wurde. Nummern, Domänen, Namen von Unternehmen/Gruppen, Gerätetyp, Richtlinien, Profile usw. werden je nach Partner unterschiedlich sein.

Anrufverlauf:

1. Benutzer fordert Rückruf an. Webex leitet einen Rückruf ein.
2. Anruf wird an BroadWorks OTT weitergeleitet.
3. Der Anruf erreicht den in CH bereitgestellten CUBE. CUBE leitet den Anruf an BroadWorks weiter.
4. BroadWorks identifiziert den Anruf als Ursprung des Meeting-Gastgebers und erstellt eine Sitzung für den Benutzer des Meeting-Gastgebers und verarbeitet den Anruf.
5. Die Benutzersitzung des Meeting-Gastgebers verarbeitet den Anruf und übersetzt die gewählte Nummer. Darüber hinaus wird ein Abrechnungsdatensatz im Auftrag des Meeting-Gastgeberbenutzers generiert.
6. BroadWorks leitet den Anruf entweder an den mit dem Gerät verknüpften Benutzer (7) oder an PSTN (8) weiter.

Vorbereitungen

Die SIP-Kommunikation zwischen BroadWorks und dem CUBE kann je nach Ihren Netzwerkanforderungen über UDP oder TCP erfolgen. Wenn beispielsweise einige Netzwerk- oder Zugriffsgeräte (z. B. Gateways oder Endpunkte) in den BYoPSTN-Einwahl- oder Rückrufverläufen TCP nicht unterstützen, sollte stattdessen UDP verwendet werden.

Die Konfiguration und die in diesem Handbuch gezeigten Beispiele verwenden TCP als Transportprotokoll. Um TCP zu verwenden, stellen Sie sicher, dass Ihr BroadWorks Anwendungsserver und Netzwerkserver für TCP konfiguriert sind:

_CLI/Interface/SIP> get
networkProxyTransport = unspecified
accessProxyTransport = unspecified
supportDnsSrv = true
supportTcp = true

Anwendungsserver

Identifizieren/Geräteprofiltyp

Es sollte ein neuer Identitäts-/Geräteprofiltyp erstellt werden, der den CUBE darstellt. Stellen Sie sicher, dass Sie die folgenden Eigenschaften unten festlegen, während andere bei den Standardwerten belassen werden können:

• Signalisierungsadressentyp: Auf Intelligent Proxy Addressing (Intelligente Proxyadressierung) festlegen

• Authentifizierung – auf Aktiviert festlegen

• Unterstützungsidentität in UPDATE und Re-INVITE – Aktiviert

• Statische Registrierung möglich – Aktiviert auf festlegen

• Video aktiviert – auf deaktiviert festlegen

Im folgenden Beispiel wird der neue Identitäts-/Geräteprofiltyp „VXML _profile“ erstellt, um den CUBE darzustellen.

Virtueller Sprach-XML-Abonnent

Erstellen einer VoiceXML-Instanz

Jede Webex Meetings-PSTN-Nummer wird in BroadWorks von einem virtuellen Subscriber dargestellt, und die VoiceXML-Funktionalität für virtuelle Subscriber kann verwendet werden. Es wird empfohlen, dass ein dediziertes Unternehmen und eine dedizierte Gruppe für alle virtuellen VoiceXML-Subscriber verwendet werden. Beachten Sie, dass wir keine VoiceXML-Funktionen nutzen, aber dieser virtuelle Benutzer-Typ ist für die Interaktion mit dem CUBE geeignet.

Um den VoiceXML-Dienst zu verwenden, stellen Sie sicher, dass die Lizenz über ausreichende „VoiceXML“-Mengen verfügt und dass der Dienst auf Unternehmens- und Gruppenebene autorisiert ist und der VoiceXML-Dienst der Gruppe zugewiesen wird, wie im Beispielbild unten dargestellt.

Unter Gruppe > Dienste , wählen Sie VoiceXML aus und erstellen Sie eine Instanz für jede PSTN-Nummer.

VoiceXML-Adressen konfigurieren

Stellen Sie für jede VoiceXML-Instanz unter den VoiceXML-Adressen Folgendes bereit:

• Telefonnummer – Geben Sie die Einwahlnummer für die Webex Meetings-Site ein (z. B. 2403332200).

• Durchwahl

• Identität/Geräteprofil – Erstellen Sie eine Instanz (z. B. VXML _device Prof) basierend auf dem im vorherigen Abschnitt erstellten Gerätetyp (VXML _profile im Beispiel) und geben Sie die folgende Konfiguration ein.

• Leitung/Port – Geben Sie Folgendes im Format <access number="">@<domain> ein:

  • <access number=""> ist die Zugriffscode-Nummer für die Webex Meetings-Site (in der JSON-Datei verfügbar) (z. B. 88631321777971704941)

  • <domain> ist die Domäne von Webex Edge Audio für diese Meeting-Site (z. B. ecccspx.amer.pub.webex.com)

• Kontakt sip – Bei Meeting-Einwahlanrufen an die Zugriffsnummer wird die EINLADUNG mit einer Anforderungs-URI gesendet, die auf den Wert dieses Felds festgelegt ist. Geben Sie den SIP-Kontakt in diesem Format <sip contact="">;<Locale>;<Meetings Site="" UUID="">;<SIP transport=""> ein, wobei:

  • <sip contact=""> ist der <number> vom Feld „Leitung/Port“, aber mit der Domäne als SRV, der zur Adresse des CUBE aufgelöst wird (z. B. 88631321777971704941@cube.internal.local)

  • <Locale> stellt die Spracheinstellung entsprechend dem Gebietsschema des Benutzers dar (z. B. Gebietsschema = en_ US)

  • <Meetings Site="" UUID=""> ist Site-UUID aus der JSON-Datei (z. B. x-cisco-site-uuid=abbd70f6c519fb1ee053ad06fc0a038b)

  • <SIP transport=""> sollte transport=tcp sein, damit der AS TCP verwendet, um Nachrichten an den CUBE zu senden.

Unten finden Sie ein Beispiel für VoiceXML-Adresseneinstellungen.

Für jede zusätzliche Meeting-Zugangsnummer, die verwendet werden soll, sollte analog zu der oben genannten ein zusätzlicher virtueller VoiceXML-Abonnent erstellt werden. Dasselbe Geräteprofil kann verwendet werden, aber die Felder Leitungsport und Kontakt müssen wie oben gezeigt anhand der Zugriffsnummerinformationen konstruiert werden.

Stellen Sie sicher, dass die Einschränkungen der Anrufverarbeitungsrichtlinie, die Sie auf dem virtuellen BroadWorks-Subscriber konfigurieren, ausreichen, um die zusätzlichen BYoPSTN-Anrufe in Ihrer Telefonnummerngruppe zu verarbeiten.

Zuweisen der SIP-Authentifizierung zur VoiceXML-Instanz

Weisen Sie den Authentifizierungsdienst dem virtuellen VoiceXML-Subscriber zu. Dies wird verwendet, um SIP INVITE-Nachrichten vom CUBE im Rückruf-Szenario zu authentifizieren. Außerdem wird verhindert, dass der virtuelle VoiceXML-Abonnent Anrufe von anderen Parteien als dem CUBE annimmt.

Rufen Sie die Authentifizierungsseite für virtuelle Subscriber unter „Dienstprogramme“ auf und geben Sie den SIP-Benutzernamen und das Kennwort ein (siehe Abbildung unten):

CUBE muss mit dem gleichen Benutzernamen und Kennwort konfiguriert sein, um die INVITE-Nachrichten, die an den Anwendungsserver gesendet werden, ordnungsgemäß zu authentifizieren. Ein Beispiel für den Befehl zum Konfigurieren der SIP-Authentifizierung auf dem CUBE lautet wie folgt: sip-ua authentication username VSUB password 0 <unencrypted password> (See the CUBE onfiguration/datafill for more details).

Namedefs-Datei

Das Feld für den SIP-Kontakt des virtuellen VoiceXML-Subscribers enthält die URL, unter der der Domänenteil zur CUBE-Adresse aufgelöst wird. Dies ist ein interner SRV, und die namedefs-Datei auf dem AS kann verwendet werden, um den internen SRV in die CUBE IP aufzulösen.

In unserem Beispiel lautet der SIP-Kontakt SRV cube.internal.local und löst die Adresse 10.165.196.30 Port 5060 auf, um den CUBE zu erreichen. Auf dem AS befinden sich die /usr/local/broadworks/bw_base/conf/namedefs Datei wird wie folgt aktualisiert:

_sip.tcp.cube.internal.local SRV 1 99 5060 10.165.196.30

Webex Meetings-Anruftyp

Die Konfigurationsoptionen für die Anrufverarbeitung in Webex Meetings sind verfügbar, um zu steuern, wie Einwahlanrufe in Meetings behandelt werden. Standardmäßig werden Meeting-Einwahlanrufe als externe Anrufe verarbeitet, da Einwahlnummern in einem dedizierten Unternehmen oder Serviceanbieter gehostet werden. Externe Anrufe werden normalerweise in die Sitzungsanzahl der Sitzungszugangskontrolle aufgenommen und im CDR-Feld „ chargeIndicator“ für das Laden gekennzeichnet.

Im folgenden Beispiel wird die empfohlene Konfiguration hinzugefügt, um Meeting-Call-Ins als interne Anrufe so zu verarbeiten, dass sie nicht geladen und von der Anzahl der Sitzungszugangskontrollen ausgeschlossen werden.

Wenn Sie „N Charge Field erzwingen“ auf „true“ festlegen, basiert die Population des CDR-Felds „chargeIndicator“ auf dem konfigurierten Charge-Attribut des Anruftyps „Network Server“.

AS_CLI/System/CallP/WebexMeetings/WebexCallTypes> add "Webex Meetings" WXM true true

AS_CLI/System/CallP/WebexMeetings/WebexCallTypes> get
      Name    NS Call Type    Enforce NS Charge Field  Process As Internal For SAC-Subscriber
  ==========================================================================================
  Webex Meetings       WXM               true                                true

Virtueller Teilnehmer für VoiceXML-Meeting-Rückruf

Erstellen eines VoiceXML-Meeting-Rückruf-Abonnenten

Ein dedizierter virtueller VoiceXML-Subscriber mit einer speziellen Rückruf-Option für Webex-Meetings (nachfolgend VoiceXML-Meeting-Callback-Subscriber genannt) muss auf dem BroadWorks Application Server (AS) konfiguriert werden, um die Webex Meetings-Rückrufe zu verarbeiten. Nur eine einzelne Instanz dieses Subscribers kann auf dem Anwendungsserver konfiguriert werden.

Um die Funktion zu aktivieren, legen Sie die aktivierbare Funktion 102074 über CLI auf „true“ fest.

AS_CLI/System/ActivatableFeature> activate 102074
***** Warning *****:
This activity should only be done during a maintenance window because
this may cause large amounts of data to be added/modified/deleted and
it may take some time to execute. Features that have web page impacts
require that users and administrators log out and log back in.
Are you sure you want to continue?

Please confirm (Yes, Y, No, N): y
...Done

AS_CLI/System/ActivatableFeature> get

      Id                                               Description  Activated  Last Modified Timestamp
=============================================================================================
  102746                            BroadWorks Support for CI UUID       true
  102074          BYO PSTN Billing support for CallBack and CallIn       true      
  104256                          Weak Password Validation Service      false
  104073  Add FAC Support for Call Center Agent Join-Unjoin in CDR      false
  103542   Configurable Endpoint For Auto-Answer And Forced Answer      false
  104255    Control password usage and behavior to ensure security      false

Da die Funktion „BYO PSTN Billing Support for CallBack and CallIn“ von der Funktion „BroadWorks Support for CI UUID“ abhängt, müssen Sie vor dem Aktivieren der Funktion (102074) auch die Funktion (102746) aktivieren. Weitere Informationen finden Sie im Abschnitt „CI-Benutzer-UUID-Synchronisierung (Broadworks-Unterstützung für CI-UUID)“.

Der VoiceXML-Meeting-Rückruf-Subscriber ähnelt dem bestehenden virtuellen BYOPSTN VXML-Subscriber, hat jedoch eine neue Markierung „Webex Meeting-Rückruf“ erhalten. Dieser VoiceXML-Meeting-Rückruf-Subscriber ist mit demselben Geräteprofil wie der vorhandene virtuelle BYOPSTN VXML-Subscriber sowie der Authentifizierungsdienst mit denselben Anmeldeinformationen konfiguriert.

Ein Beispiel wird unten gezeigt:

Der VoiceXML-Meeting-Rückruf-Subscriber muss auf dem AS vorhanden sein, der den Benutzer des Meeting-Gastgebers hostet. Wenn der AS die Meeting-Rückruf-INVITE-Anforderung erhält, versucht er, während der Anrufeinrichtung sowohl den VoiceXML-Meeting-Rückruf-Benutzer als auch den Meeting-Gastgeberbenutzer im AS zu suchen. Wenn keiner dieser Benutzer gefunden wird, wird der Anruf abgelehnt.

Meeting-gastgebersitzung

Im Rückrufszenario mit dem X-Cisco-Meet-Info-Header erhält der Cisco BroadWorks Application Server eine SIP INVITE-Anforderung und identifiziert den Benutzer des Meeting-Gastgebers mit dem Host CI User UUID-Parameter des SIP X-Cisco-Meet-Info-Headers. Eine Anrufsitzung wird im Auftrag des Meeting-Gastgeberbenutzers erstellt, um den Anruf zu verarbeiten und das Dienstprofil des Benutzers auszuführen. Darüber hinaus wird ein Abrechnungsdatensatz im Auftrag des Meeting-Gastgeberbenutzers generiert. Die Meeting-ID und die Site-UUID-Informationen aus dem SIP X-Cisco-Meet-Info-Header werden im Abrechnungsdatensatz erfasst.

Ein Beispiel für den SIP X-Cisco-Meet-Info-Header wird unten angezeigt:

X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab
-04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec

Anwendungsbereitstellungsplattform

CI-Benutzer-UUID-Synchronisierung (Broadworks-Unterstützung für CI-UUID)

Die Benutzer-CI-UUID ist eine eindeutige Kennung zur Identifizierung von Benutzern in der Webex-Umgebung.

Diese Webex Provisioning Sync-Anwendung auf der Cisco BroadWorks Application Delivery Platform (ADP) wird zum Synchronisieren, Zuordnen und Speichern der Benutzer-CI-UUID in der BroadWorks-Infrastruktur verwendet, sodass sie in verschiedenen Interaktionen mit Webex und Webex für den BroadWorks-Dienst verwendet werden kann.

Lesen Sie „ Webex Meeting Callback aktivieren“, um zu erfahren, wie die CI User UUID-Verknüpfung vom Cisco BroadWorks-Netzwerkserver und dem Cisco BroadWorks-Anwendungsserver verwendet wird.

Die folgenden Schritte richten die Webex Provisioning Sync-Anwendung ein, um die BroadWork-Benutzer regelmäßig mit der CI-UUID abzufragen und zu aktualisieren.

Die Webex Provisioning Sync-Anwendung erfordert OAuth-Anmeldeinformationen mit dem spark-admin:broadworks_subscribers_read scope für den Cisco Identitätsanbieter und kann über eine Serviceanfrage bei Ihrem Onboarding-Agenten abgerufen werden.

Weitere Informationen zum Erstellen der Serviceanfrage finden Sie im Abschnitt „Abrufen von OAuth-Anmeldeinformationen für Ihr Webex für Cisco BroadWorks“ unter: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wx4bwks/Solution_Guide/wbxbw_b_solution-guide/wbxbw_b_SolutionGuide-PDF_chapter_01.html?bookSearch=true#Cisco_Generic_Topic.dita_0e1beabc-80ae-4e8d-b177-17108ec5daed

Fügen Sie das Token mit einem entsprechenden Partnernamen wie folgt hinzu:

ADP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CiscoIdentityProvider/Partners> add custBYO refreshToken
      New Password:
      Re-type New Password:
      ADP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CiscoIdentityProvider/Partners> get
       Partner Name  Refresh Token
==================================
  FederationPartner       ********
           custPart       ********
            custBYO       ********

Fügen Sie den dem OAuth-Token zugeordneten Partnernamen zur Liste der Partner hinzu, die von der Webex Provisioning Sync-Anwendung überwacht werden sollen, wobei das Flag „aktiviert“ auf „true“ gesetzt ist.

Mit dieser Webex Provisioning Sync-Anwendung wird mit der UUID-Synchronisierung des CI-Benutzers im definierten Abrufintervall begonnen.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> add custBYO true

Nachdem der Partner einbezogen wurde, kann die Webex Provisioning Sync-Anwendung jetzt die Zuordnung der CI UUID zu den BroadWorks-Benutzern durchführen.

Ändern Sie die Verbindungszeitüberschreitung mit den folgenden Befehlen:

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> set requestTimeout 30000
...Done

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> get
requestTimeout = 30000

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller> cd http

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/Controller/Http> set connectionTimeout 300
*** Warning: BroadWorks needs to be restarted for the changes to take effect ***

ADP_CLI/Application/WebexProvisioningSync/GeneralSetting/Controller/HTTP > get
connectionPoolSize = 5
connectionTimeout = 300
connectionIdleTimeOut = 300
maxConcurrentRequests = 10
maxCookieAgeInHours = 24

Diese Zuordnung kann automatisch oder manuell erfolgen. Der Befehl CLI manualSync kann die Zuordnung sofort auslösen.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> manualSync custBYO

Partner, bei denen „Aktiviert“ auf „true“ festgelegt ist, führen die zugeordneten Abfragen im Abfrageintervall durch. Während der anfänglichen Zuordnung fragt die Webex Provisioning Sync-Anwendung die Webex Subscriber-API ab, um die Daten mit der CI UUID für alle vom Partner gehosteten Benutzer abzurufen. Die externe ID des BroadWorks-Benutzers wird mit der zugehörigen CI-UUID aktualisiert. Nachfolgende Zuordnungen wirken sich auf Benutzer aus, die dem Partner hinzugefügt werden. Der Befehl status kann verwendet werden, um zu sehen, ob die Synchronisierung abgeschlossen ist.

ADP_CLI/Applications/WebexProvisioningSync/GeneralSettings/MonitoredPartners> status
  Partner Name         Status                 Last Sync Time
============================================================
       custBYO  synchronizing
      custPart     monitoring  2023-01-29T15:36:43.873-05:00
2 entries found.

Sobald die Synchronisierung abgeschlossen ist, wechselt der Status wieder zur Überwachung. Nachfolgende Synchronisierung wird für Benutzer durchgeführt, die dem Partner nach der „Letzten Synchronisierungszeit“ hinzugefügt wurden.

Die folgende Abbildung zeigt die innerhalb der externen ID festgelegte CI-UUID:

Netzwerkserver

Anruftyp

Zu Abrechnungs- und Berichtszwecken kann es wünschenswert sein, CDRs für Meetings-Einwahlanrufe zu markieren. Dies kann mithilfe der Richtlinie „PreCallTyping“ des Netzwerkservers erfolgen.

Fügen Sie zunächst auf der NS-CLI unter /System/CallP/CallType einen neuen Anruftyp hinzu. Im folgenden Beispiel wird der neue Anruftyp „WXM“ hinzugefügt:

NS_CLI/System/CallP/CallTypes> add WXM LOCAL true false "Webex Meetings"
NS_CLI/System/CallP/CallTypes> get calltype WXM    
  CallType     Description  Category         Scope  SupportE164  Charge      
=======================================================================    
  WXM          Webex Meetings  LOCAL  User Defined         true   false

Der Anruftyp kann dann in einer PreCallTyping-Instanz verwendet werden, die Teil des Routing-Profils des BroadWorks-Benutzers ist. In diesem Beispiel wurde eine neue PreCallTyping-Instanz „wxm“ unter dem Kontext /Policy/PreCallTyping CLI hinzugefügt, es könnte sich jedoch um eine bereits verwendete PreCallTyping-Instanz handeln:

NS_CLI/Policy/PreCallTyping> add wxm true CallTypes ALL

NS_CLI/Policy/PreCallTyping> get wxm                        
Policy: PreCallTyping  Instance: wxm                        
  CallTypes:                                
    Selection = {ALL}                                
    From = {PCS, ALL, TRMT, LO, GNT, DP, WXM, LPS, OA, TPS, EA, FGB, POA, SV, SVCD, IN, MS, CSV, EM, SVCO, SMC, ZD, NIL, CT, TF, GAN, TO, DA, OAP}        
  supportLCABasedNormalization = false                        
  Enable = true 

Der nächste Schritt besteht darin, der PreCallTyping-Instanz Einträge für alle Einwahlnummern im CLI-Kontext /Policy/PreCallTyping/DialPlan hinzuzufügen. Zum Beispiel:

NS_CLI/Policy/PreCallTyping/DialPlan> add wxm 1 dflt 12403332200 12403332200 exact 11 11 WXM 0 0 Webex Meetings
NS_CLI/Policy/PreCallTyping/DialPlan> add wxm 1 dflt_e164 12403332200 12403332200 exact 11 11 WXM 0 0 Webex Meetings

NS_CLI/Policy/PreCallTyping/DialPlan> get wxm 1                
Policy: PreCallTyping  Instance: wxm  Table: DialPlan                
CC Dial Plan   From     To          Match Min Max Call Type Prefix Action  Call Ind  Description                  
================================================================================================
1 dflt      12403332200 12403332200 {exact} 11 11 {WXM}     0                      Webex Weetings
1 dflt_e164 12403332200 12403332200 {exact} 11 11 {WXM}     0                      Webex Meetings

Anschließend wird die PreCallTyping-Instanz (sofern sie noch nicht vorhanden ist) dem entsprechenden Routing-Profil des ursprünglichen Benutzers hinzugefügt, wie im folgenden Beispiel gezeigt:

NS_CLI/Policy/Profile> add Profall PreCallTyping wxm
NS_CLI/Policy/Profile> get profile Profall
Profile:  Profall
                 Policy              Instance
   ==========================================
             CallTyping           DefaultInst
          CallScreening           DefaultInst
            SubLocation           DefaultInst
              FarEndRtg           DefaultInst
             NearEndRtg           DefaultInst
             UrlDialing           DefaultInst
            MediaSrvSel           DefaultInst
                 SIMPLE           DefaultInst
              DstSvcRtg           DefaultInst
      NumberPortability           DefaultInst
             RCBasedRtg           DefaultInst
      NetVoicePortalRtg           DefaultInst
          PreCallTyping                   wxm    

BroadWorks-CDR werden nur durch Anrufe generiert, die von BW-Subscribern stammen. PSTN-Anrufe von der „Netzwerk“-Seite des AS generieren keine Quell-CDR. In beiden Fällen wird die CDR für den virtuellen VoiceXML-Subscriber beendet.

RoutingNE

Eine RoutingNE ist auf dem NS unter /System/Device/RoutingNE CLI-Kontext erforderlich, um den CUBE darzustellen. Auf diese Weise wird das NS, wenn es die INVITE vom CUBE erhält, mit dem Via-Header zum RoutingNE-Eintrag übereinstimmen, der auf dem NS bereitgestellt wird. Siehe Administrationsleitfaden für die Cisco BroadWorks-Netzwerkserver-Befehlszeile für Details zum Hinzufügen einer RoutingNE.

Im Folgenden finden Sie ein Beispiel für die Befehle zum Hinzufügen der RoutingNE „WebexMeetings“, wobei die CUBE IP-Adresse 10.165.196.30 ist. Das Beispiel zeigt auch Befehle zum Erstellen einer neuen OrigRedirect- und Profile-Instanzen, die mit der RoutingNE verknüpft werden sollen, aber auch vorhandene Instanzen können verwendet werden.

NS_CLI/Policy/OrigRedirect> add wxm_Inst true CallTypes ALL supportTrunkGroupLookups disable applyAccessSideRules enableRestrictive

NS_CLI/Policy/OrigRedirect> get  wxm_Inst
Policy: OrigRedirect  Instance: wxm_Inst
  Enable = true
  CallTypes:
    Selection = {ALL}
    From = {PCS, ALL, TRMT, LO, GNT, DP, WXM, LPS, OA, TPS, EA, FGB, POA, SV, SVCD, IN, MS, CSV, EM, SVCO, SMC, ZD, NIL, CT, TF, GAN, TO, DA, OAP}
  supportTrunkGroupLookups:
    Selection = {disable}
    From = {disable, enablePermissive, enableRestrictive}
  applyAccessSideRules:
    Selection = {enableRestrictive}
    From = {disable, enablePermissive, enableRestrictive}

NS_CLI/Policy/Profile> add wxm_routing

NS_CLI/Policy/Profile> add wmx_routing OrigRedirect wxm_Inst

NS_CLI/Policy/Profile> add wmx_routing SubLocation  DefaultInst

NS_CLI/Policy/Profile> get profile wxm_routing 
Profile:  wxm_routing
                 Policy              Instance
   ==========================================
           OrigRedirect           wxm_Inst
            SubLocation           DefaultInst

NS_CLI/System/Device/RoutingNE> add  WebexMeetings 1240364 1 99 wxm_routing false OnLine AccessRoutingNE

NS_CLI/System/Device/RoutingNE/Address> add WebexMeetings 10.165.196.30 1 99 tcp

NS_CLI/System/Device/RoutingNE> get
Network Element  WebexMeetings
   Location      =  1240364
   Static Cost   =  1
   Static Weight =  99
   Poll          =  false
   OpState       =  enabled
   State         =  OnLine
   Profile       =  wxm_routing
   Signaling Attributes=  AccessRoutingNE
 
NS_CLI/System/Device/RoutingNE/Address> get
Routing NE   Address     Cost    Weight     Port    Transport Route  
WebexMeetings   10.165.196.30     1      99     -          tcp

Mit der Beispielkonfiguration sendet der CUBE dem NS eine INVITE, die den folgenden ähnelt (wichtige Felder fett dargestellt):

INVITE sip:+19991111111@domain.com:5060 SIP/2.0
Via:SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK7C7B9EB
Remote-Party-ID:" BroadWorks
"<sip:886222222222@domain.com>;screen=no;party=calling;privacy=off
From:" BroadWorks "<sip:+12403333333@10.20.20.20>;tag=958BDDF4-1AB
To:<sip:+19991111111@domain.com>
Date:Thu, 03 Nov 2022 12:39:58 GMT
Call-ID:75D3B642-5AAB11ED-AC82BA3C-276254A1@10.20.20.30
Supported:100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:14400
Cisco-Guid: 1976459008-1521160685-2893855292-0660755617
X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec"
X-Cisco-Org-Id:82e2eb35-1610-44e7-9b20-ab607e026270
User-Agent: Cisco-SIPGateway/IOS-16.12.2s
Timestamp: 1667479198
Session-ID:
e13cc71f24ae400669d5247d8306ac23;remote=00000000000000000000000000000000
Allow:INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGSTER
CSeq:101 INVITE
Contact:<sip:+12403333333@10.20.20.20:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Max-Forwards:68

Erläuterung:

• INVITE-Anforderungs-URI enthält die Rückrufnummer

• Über Kopfzeile: enthält die IP-Adresse des CUBE, die zum Auswählen des RoutingNE-Profils verwendet wird.

• X-Cisco-Info-Meet Kopfzeile: verwendet, um hostCIUserUuid, meetingid & siteUUID zu identifizieren.

Nach dem Empfang der EINLADUNG verwendet das NS den Via-Header, um mit der RoutingNE „WebexMeetings“ zu übereinstimmen. Dadurch wird wiederum das „wxm_routing“-Routing-Profil ausgewählt, das die „wxm_ Inst“-Instanz der OrigRedirect enthält.

Die NS OrigRedirect-Richtlinie stimmt dann mit der X-CISCO-MEET-INFO-Kopfzeile überein:

X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec

mit dem Leitungsport, der auf dem virtuellen VoiceXML-Subscriber konfiguriert ist, und eine 302-Umleitung an das AS-Paar senden, das diesen Subscriber hostet. Die 302-Nachricht ähnelt der folgenden:

SIP/2.0 302 Moved temporarily
Via:SIP/2.0/TCP 10.165.196.30:5060;branch=z9hG4bK5452684
From:" Webex "<sip:+12403332200@10.165.196.30>;tag=8EEAA586-1675
To:<sip:+14519615001@10.155.6.172>;tag=394411970-1602687588994
Call-ID:ABC5CCA2-D6411EB-8AD6D92D-EE20F768@10.165.196.30
CSeq:101 INVITE
Contact:<sip:+14519615001@hs2-bwks-v-as01-alpha.bwlab.org:5060;user=phone> ;q=0.5, <sip:+14519615001@hs2-bwks-v-as02-alpha.bwlab.org:5060;user=phone>;q=0.25
Content-Length:0

Alias

Die Domäne in der INVITE-URI (im Beispiel: bw.myenterprise.com), die vom CUBE an das NS gesendet wird, muss vom NS erkannt werden. Dies kann durch Hinzufügen der Domäne im NS _ CLI/System/Alias-Kontext erfolgen. Beispiel:

NS_CLI/System/Alias> add bw.myenterprise.com

Der Befehl zum Konfigurieren der INVITE-URI-Domäne auf dem CUBE befindet sich im nächsten Abschnitt unter Dial-Peer/Sitzungsziel, z. B.:

dial-peer voice 23401 voip
session target dns:bw.myenterprise.com

HostingNE

Um die Konfigurationsoptionen für die Webex Meetings-Anrufverarbeitung für Abrechnung und Sitzungszugangskontrolle zu unterstützen, müssen die NE-Signalisierungsattribute CallTypeInfoRequired und RequiresChargeIndication des Anwendungsservers im NS_CLI/System/Device/HostingNE-Kontext aktiviert sein._ Zum Beispiel:

NS_CLI/System/Device/HostingNE> set broadworksASHostNe signaling E164Compliant,
 CallTypeInfoRequired, SourceId, RequiresNetworkIndication RequiresChargeIndication;

Webex Meeting-Rückruf aktivieren

Im Rückrufszenario mit dem SIP X-Cisco-Meet-Info-Header sendet der CUBE den Anruf an den Netzwerkserver, um die Ersteller-Umleitung an das AS-Paar zu ermöglichen. Das AS-Paar wird basierend auf dem Systemparameter enableWebexMeetingHoostLookup ermittelt.

NS_CLI/System/CallP/Options> get
  accessSideRoutingNeDeterminedViaSignaling = false
  disableNdcValidationForCalledNumbers = true
  forceRoutingNEProfile = false
  skipPrivatePoliciesOnEmergency = true
  maxReturnedContacts = 10
  enableWebexMeetingHostLookup = true

Wenn der Systemparamter enableWebexMeetingHoostLookup auf „true“ festgelegt ist, wird die CI UUID des Meeting-Gastgeberbenutzers im X-Cisco-Meet-Info-Header verwendet, um das AS-Paar zu identifizieren, das den Meeting-Gastgeberbenutzer hostet.

INVITE sip:+19991111111@domain.com:5060 SIP/2.0
Via:SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK7C7B9EB
Remote-Party-ID:" BroadWorks "<sip:886222222222@domain.com>;screen=no;party=calling;privacy=off
From:" BroadWorks "<sip:+12403333333@10.20.20.20>;tag=958BDDF4-1AB
To:<sip:+19991111111@domain.com>
Date:Thu, 03 Nov 2022 12:39:58 GMT
Call-ID:75D3B642-5AAB11ED-AC82BA3C-276254A1@10.20.20.30
Supported:100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:14400
Cisco-Guid: 1976459008-1521160685-2893855292-0660755617
X-Cisco-Meet-Info:hostCIUserUuid="52f4c6cb-c6a3-4283-a1ab-04cc8828b7c1";meetingid="26551128462";siteUUID="ec6659987f473332e0531b04fc0acaec"
X-Cisco-Org-Id:82e2eb35-1610-44e7-9b20-ab607e026270
User-Agent: Cisco-SIPGateway/IOS-16.12.2s
Timestamp: 1667479198
Session-ID: e13cc71f24ae400669d5247d8306ac23;remote=00000000000000000000000000000000
Allow:INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGISTER
CSeq:101 INVITE
Contact:<sip:+12403333333@10.20.20.20:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Max-Forwards:68

Dieser Abschnitt enthält eine validierte Konfiguration für die Bereitstellung von Cisco Unified Border Element (CUBE) als Session Border Controller (SBC) für die Bring Your Own PSTN-Lösung.

Dieser Abschnitt konzentriert sich auf die CUBE-Konfigurationen, die für die Zusammenarbeit mit der im vorherigen Abschnitt gezeigten Beispiel-Konfiguration von Webex für Cisco BroadWorks erforderlich sind. Eine allgemeinere Erläuterung der anfänglichen CUBE-Bereitstellung und -Konfiguration finden Sie in den folgenden Handbüchern: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-overview.html

https://help.webex.com/en-us/b6vrdc/Cisco-Webex-Edge-Audio-for-CUBE-Customer-Configuration-Guide

Unsere eigene SBC-Option für Y bereitstellen

Wenn Sie CUBE nicht bereitstellen möchten, haben Sie die Möglichkeit, Ihren eigenen SBC bereitzustellen. Beachten Sie jedoch, dass dieses Dokument keine validierte Konfiguration für SBCs mit Ausnahme von CUBE bietet.

Wenn Sie Ihren eigenen SBC bereitstellen, können Sie die allgemeinen CUBE-Konfigurationsanforderungen (z. B. Zuweisungen wie Domäne, öffentliche und private Schnittstellen und Gateways) befolgen, um Ihre Konfiguration zu leiten. Detaillierte Befehlszeilenhilfe finden Sie jedoch in Ihrer SBC-Dokumentation, da sich die tatsächlichen Befehle für Ihren eigenen SBC wahrscheinlich von CUBE unterscheiden.

Sofern nicht anders angegeben, gelten die verbleibenden Konfigurationsanforderungen in Schritt 10, unabhängig davon, welchen SBC Sie bereitstellen. Die Befehlszeilenbeispiele gelten jedoch nur für CUBE, es sei denn, es wird angegeben, dass das Beispiel für andere SBCs gilt. Weitere SBCs finden Sie in der SBC-Dokumentation für Konfigurationsbefehle.

Nachdem die Konfiguration und Bereitstellung der BYoPSTN-Lösung abgeschlossen ist, muss der Partner eine Reihe von Akzeptanztestfällen durchlaufen, um seine Lösung zu zertifizieren. Dies ist ein erforderlicher Schritt, damit der Partner BYoPSTN genehmigt und aktiviert werden kann.

Die Akzeptanztestfälle werden im Dokument „Bring Your Own PSTN Acceptance Procedure Webex For Cisco BroadWorks“ beschrieben unter: https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cloudCollaboration/wx4bwks/BYoPSTN/BYoPSTN_Acceptance.pdf .

Der Partner sollte den Onboarding- und Zertifizierungsteams die Ergebnisse der erfolgreich durchgeführten Abnahmetests zur Verfügung stellen.

Fragen, Probleme und Ergebnisse aus der Durchführung der Akzeptanztestfälle sollten im für das Onboarding des Partners zugewiesenen Webex-Bereich gemeldet und freigegeben werden.