Paket

• Du måste välja ett standardpaket när du skapar en mall (Se Paket i avsnittet Översikt för information). Alla användare som etableras med den mallen, oavsett om de använder flowuppringning eller självetablering, får standardpaketet.

• Du har kontroll över paketvalet för olika kunder genom att skapa flera mallar och välja olika standardpaket i varje. Du kan sedan distribuera olika etableringslänkar, eller olika provisioneringsadaptrar per företag, beroende på vilken användaretableringsmetod som du har valt för mallarna.

• Du kan ändra paketet med specifika prenumeranter från denna standard med hjälp av det tillhandahållande API:et (se Integrera med Webex för BroadWorks etablerings-API i referensavsnittet) eller via partnerhubben.

• Du kan inte ändra en prenumerantens paket från BroadWorks. Tilldelningen av den integrerade IM&P-tjänsten är på eller av. Om prenumeranten tilldelas denna tjänst i BroadWorks definierar den partnerhubben som är associerad med prenumerantens företags etablerings-URL paketet.

Återförsäljare och företag eller tjänsteleverantör och grupper?

• Det sätt på vilket ditt BroadWorks-system konfigureras påverkar flödet via etableringen. Om du är en återförsäljare med företag måste du aktivera företagsläget när du skapar en mall.
• Om BroadWorks-systemet är konfigurerat i tjänsteleverantör-läge kan du lämna enterprise-läget inaktiverat i dina mallar.
• Om du planerar att etablera kundorganisationer med båda BroadWorks-lägena måste du använda olika mallar för grupper och företag.

Autentiseringsläge

Hur autentiserar kundernas prenumeranter?

(Alternativ) Certifikatkrav för TLS-bridge-proxy

• Webex visar ett offentligt signerat klientcertifikat för proxyn.

• Proxyn litar på Ciscos interna CA som signerade klientcertifikatet. Du kan hämta denna CA/-kedja från Control Hub och lägga till den i proxyns betrodda lagring. Det offentligt signerade XSP-servercertifikatet läses också in i proxyn.

• Proxyn visar det offentligt signerade servercertifikatet för Webex.

• Webex litar på den allmänna CA:en som signerade proxyns servercertifikat.

• Proxyn visar ett internt signerat klientcertifikat för XSP:erna.

  Det här certifikatet måste ha tilläggsfältet x509.v3 för utökad nyckel ifylld med BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 ochTLS-klientenAuth- syfte. E.g.:

  X509v3 extensions:
      X509v3 Extended Key Usage:
          1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

  CN för det interna certifikatet måste vara bwcticlient.webex.com.

  När du genererar interna klientcertifikat för proxyn ska du observera att SAN-certifikat inte stöds. Interna servercertifikat för XSP kan vara SAN. Offentliga certifikatutfärdare kanske inte är villiga att signera certifikat med det egna BroadWorks OID som krävs. För en bryggproxyn kan du vara tvungen att använda en intern CA för att signera klientcertifikatet som proxyn visar för XSP.

• XSP:erna litar på den interna CA:en.

• XSP:erna presenterar ett internt signerat servercertifikat.

• Proxyn litar på den interna CA:en.

• Programserverns ClientIdentity innehåller CN av det internt signerade klientcertifikatet som presenteras för XSP av proxyn.

(Alternativ) Certifikatkrav för TLS-pass proxy eller XSP i DMZ

• Webex visar ett CA-signerat klientcertifikat från Cisco för XSP:erna.

• XSPs litar på Ciscos interna CA som signerade klientcertifikatet. Du kan hämta denna CA/-kedja från Control Hub och lägga till den i proxyns betrodda lagring. Det offentligt signerade XSP-servercertifikatet laddas också i XSP:erna.

• XSP:erna presenterar de offentligt signerade servercertifikaten för Webex.

• Webex litar på den allmänna CA:en som signerade XSPs-servercertifikaten.

• Programserverns klientIdentity innehåller CN av det Cisco-signerade klientcertifikatet som presenteras för XSP av Webex.

Så här Cisco Webex Cloud hittar XSP-adresser

Cisco Webex Cloud-tjänster kommer att utföra DNS A/AAAA-sökning av det konfigurerade XSP-värdnamnet och ansluter till den returnerade IP-adressen. Detta kan vara ett edge-element för laddningsbalans eller så kan det vara själva XSP-servern. Om flera IP-adresser returneras markeras den första posten i listan.

Exempel 2 & 3 nedan registrerar A/AAAA mappning till enskilda och flera IP-adresser.

Så här hittar Webex-appar XSP-adresser

Klienten försöker hitta XSP-noderna med hjälp av följande DNS-flöde:

1. Klienten hämtar inledningsvis Xsi-Actions/Xsi-Events-URL:er från Cisco Webex Cloud (du angav dem när du skapade associerat BroadWorks-samtalskluster). Xsi-värdnamn/-domän analyseras från URL:en och klienten utför SRV sökning enligt följande:

   1. Klienten utför en SRV sökning efter_xsi-client._tcp.<xsi domain>

      (Se följande exempel 1)

   2. Om SRV sökning returnerar ett eller flera mål:

      Klienten gör en A/AAAA-sökning efter dessa mål och cachelagrar de returnerade IP-adresserna.

      Varje A/AAAA-post måste mappa till en IP-adress. Vi behöver den här konfigurationen eftersom klientens XSI-händelseslag måste gå till samma IP-adress som används för att etablera händelsekanalen. Om du mappar A/AAAA-namnet till mer än en IP-adress skickar klienten till slut pulsslag till en adress där den inte etablerar en händelsekanal. Detta resulterar i att kanalen tas ner och dessutom i avsevärt mer intern trafik, vilket försämrar prestandan för ditt XSP-kluster.

      Klienten ansluter till ett av målen (och därmed sin A/AAAA-registrering med en enda IP-adress) baserat på prioriteten SRV och sedan vikta (eller slumpmässigt om alla är lika).

   3. Om SRV inte returnerar några mål:

      Klienten gör en A/AAAA-sökning av Xsi-rotparametern och försöker sedan ansluta till den returnerade IP-adressen. Detta kan vara ett edge-element för laddningsbalans eller så kan det vara själva XSP-servern.

      Som nämnts ovan måste A/AAAA-posten åtgärdas till en IP-adress av samma anledning.

      (Se följande exempel 2)

2. (Valfritt) Därefter kan du tillhandahålla anpassade XSI-Actions/XSI-Events-uppgifter i enhetskonfigurationen för Webex-appen med följande taggar:

   
   <protocols>
       <xsi>
           <paths>
               <root>%XSI_ROOT_WXT%</root>
               <actions>%XSI_ACTIONS_PATH_WXT%</actions>
               <events>%XSI_EVENTS_PATH_WXT%</events>
           </paths>
       </xsi>
   </protocols>

   1. Dessa konfigurationsparametrar har företräde framför en konfiguration i ditt BroadWorks-kluster i Control Hub.

   2. Om de finns jämförs klienten med den ursprungliga XSI-adressen den tog emot via BroadWorks-klusterkonfigurationen.

   3. Om någon skillnad upptäcks kommer klienten att initiera om anslutningen till XSI Actions/XSI Events. Det första steget i detta är att utföra samma DNS-sökningsprocess som beskrivs under steg 1 – denna gång som du begär en sökning efter värdet i%XSI_ROOT_WXT%parametern från dess konfigurationsfil.

      Se till att skapa motsvarande poster SRV du använder den här taggen för att ändra Xsi-gränssnitten.

Exempel på DNS-poster

Om du mappar din DNS A/AAAA-registrering till flera IP-adresser (för att tillhandahålla redundanta anslutningar för mikrotjänster enligt bilden i föregående tabell) får du inte använda samma A/AAAA-register som klienterns XSI-adress. I så fall kan du konfigurera en SRV-post för kunderna (se tabell 1 ovan), men SRV måste lösa problemet till en annan uppsättning av A/AAAA-register. Som tidigare nämnts måste dessa A/AAAA-register mappa till en IP-adress var.

DNS-rekommendationer för XSP-noder

• Du ska använda en enda A/AAAA-post om du behöver lösa en omvänd proxy för laddningsbalans till XSP-servrarna.

• Du ska endast använda round-robin A/AAAA poster om:

  • du har flera internetriktade XSP-servrar som du vill att Webex-mikrotjänster ska kunna hitta.

  • du använder inte round-robin A/AAAA-posterna för att lösa klientens XSI-adress.

• Du måste använda DNS-serviceupptäckt om du:

  • Behöver katalogsökning i miljöer med flera XSP:er.

  • Har befintliga integreringar som kräver en SRV identifiering.

  • Har unika konfigurationer där standard A/AAAA-poster inte är tillräckliga.