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 andra adpatrar för tillhandahållande 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 tjänsteleverantör kan du lämna företagsläget av i mallarna.
• 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-anknytningar:
      X509v3 utökad nyckelanvändning:
          1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS webbklientverifiering

  Vid generering av 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.

I scenariot för flera IP-adresser rekommenderar vi att du konfigurerar dina DNS-poster så att de roteras i ett roterande sätt för att distribuera klientanslutningarna från Webex.

Hur klienter hittar XSP-adresser

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

1. Klienten hämtar inledningsvis URL:er för Xsi-Actions/Xsi-Events från Cisco Webex Cloud (du angav dem när du skapade det associerade BroadWorks-samtalsklustret). Xsi-värdnamn/-domän analyseras från URL:en och klienten utför en 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 cachar för de returnerade IP-adresserna.

      Klienten ansluter till en SRV på en av de returnerade IP-adresserna. Den väljer en adress baserad på SRV prioritet och sedan vikt (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.

      (Se följande exempel 2 och 3)

2. (Valfritt) Därefter kan du tillhandahålla anpassade XSI-Actions/XSI-Events-uppgifter i enhetskonfrötionen för Webex Teams-klienten med hjälp av 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 för XSI-åtgärder/XSI Events. Det första steget i detta är att utföra samma DNS-sökprocess som beskrivs under steg 1 – denna gång genom att använda parametern %XSI_ROOT_WXT% från konfigurationsfilen.

      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

DNS-rekommendationer för XSP-noder

• Du ska använda ett enda A/AAAA-register:

  • om du behöver lösa en omvänd proxy för laddningsbalans till XSP-servrarna

• Du bör använda round-robin A/AAAA-poster:

  •  om du har flera internetriktade XSP-servrar

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

  • Katalogsökning krävs i miljöer med flera XSP:er.

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

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