Подгответе вашата среда
Точки за вземане на решения
Разглеждане | Въпроси за отговор | Ресурси |
Архитектура и инфраструктура |
Колко XSP? Как приемат mTLS? |
Cisco BroadWorks System Capacity Planner Ръководство за системно инженерство на Cisco BroadWorks XSP CLI справочник Този документ |
Предоставяне на клиенти и потребители | Можете ли да твърдите, че имате доверие на имейли в BroadWorks? Искате ли потребителите да предоставят имейл адреси, за да активират собствените си акаунти? Можете ли да създадете инструменти за използване на нашия API? |
Public API документи на адрес https://developer.webex.com Този документ |
Брандиране | Какъв цвят и лого искате да използвате? | Статия за брандиране на Webex приложение |
Шаблони | Какви са вашите различни случаи на използване на клиенти? | Този документ |
Характеристики на абонатите за клиент/предприятие/група | Изберете пакет, за да дефинирате ниво на обслужване за всеки шаблон. Основен, Стандартен, Премиум или Софтфон. | Този документ Матрица характеристики/пакет |
Удостоверяване на потребителя | BroadWorks или Webex | Този документ |
Адаптер за осигуряване (за опции за преходно осигуряване) | Използвате ли вече интегриран IM&P, например за UC-One SaaS? Възнамерявате ли да използвате няколко шаблона? Очаква ли се по-често срещан случай на употреба? |
Този документ Справка за CLI на сървъра на приложения |
Архитектура и инфраструктура
С какъв мащаб смятате да започнете? Възможно е да се разшири в бъдеще, но текущата ви оценка за използване трябва да стимулира инфраструктурното планиране.
Работете с вашия мениджър на акаунти/търговски представител на Cisco , за да оразмерите вашата XSP инфраструктура, според Cisco BroadWorks System Capacity Planner и на Ръководство за системно инженерство на Cisco BroadWorks .
Как Webex ще направи взаимни TLS връзки към вашите XSP? Директно към XSP в DMZ или чрез TLS прокси? Това засяга управлението на сертификатите ви и URL адресите, които използвате за интерфейсите. ( Ние не поддържаме некриптирани TCP връзки до края на вашата мрежа ).
Предоставяне на клиенти и потребители
Кой метод за осигуряване на потребители ви подхожда най-добре?
Поточно осигуряване с доверени имейли : Чрез присвояване на услугата „Интегриран IM&P“ на BroadWorks, абонатът автоматично се предоставя в Webex.
Ако можете също така да потвърдите, че имейл адресите на абонатите в BroadWorks са валидни и уникални за Webex, тогава можете да използвате варианта на „доверен имейл“ на осигуряване на поток. Абонатските акаунти в Webex се създават и активират без тяхна намеса; те просто изтеглят клиента и влизам.
Имейл адресът е ключов потребителски атрибут на Webex. Следователно Доставчикът на услуги трябва да предостави валиден имейл адрес за потребителя, за да му предостави услугите на Webex . Това трябва да бъде в атрибута Имейл ИД на потребителя в BroadWorks. Препоръчваме ви да го копирате и в атрибута Alternate ИД .
Предоставяне на поток без доверени имейли : Ако не можете да се доверите на имейл адресите на абонатите, все пак можете да присвоите услугата Интегриран IM&P в BroadWorks за обезпечавам потребители в Webex.
С тази опция акаунтите се създават, когато възлагате услугата, но абонатите трябва да предоставят и валидират своите имейл адреси, за да активират акаунтите в Webex .
Самопредоставяне на потребителя : Тази опция не изисква присвояване на услугата IM&P в BroadWorks. Вие (или вашите клиенти) вместо това разпространявате връзка за осигуряване и връзките за изтегляне на различните клиенти с вашата марка и инструкции.
Абонатите следват връзката, след което предоставят и потвърждават своите имейл адреси, за да създадат и активират своите акаунти в Webex . След това те изтеглят клиента и влизам, а Webex извлича допълнителна конфигурация за тях от BroadWorks (включително техните основни номера).
SP контролирано предоставяне чрез API : Webex разкрива набор от публични приложни програмни интерфейси (API), които позволяват на доставчиците на услуги да вграждат обезпечаване на потребител/абонат в своите съществуващи работни потоци.
Изисквания за осигуряване
Следващата таблица обобщава изискванията за всеки метод за осигуряване. В допълнение към тези изисквания, вашето внедряване трябва да отговаря на общите системни изисквания, описани в това ръководство.
Метод на обезпечаване |
Изисквания |
---|---|
Предоставяне на поток (Доверени или ненадеждни имейли) |
API за предоставяне на Webex автоматично добавя съществуващи потребители на BroadWorks към Webex , след като потребителят изпълни изискванията и вие превключите Интегриран IM+P услуга за вкл. Има два потока (доверени имейли или ненадеждни имейли), които задавате чрез клиентския шаблон на Webex. Изисквания на BroadWorks:
Изисквания на Webex : Шаблонът на клиента включва следните настройки:
|
Самопредоставяне на потребителя |
Администраторът предоставя на съществуващ потребител на BroadWorks връзка към портала за активиране на потребителя. Потребителят трябва да влезе в портала с идентификационни данни на BroadWorks и да предостави валиден имейл адрес. След като имейлът бъде потвърден, Webex извлича допълнителна информация за потребителя , за да завърши обезпечаването. Изисквания на BroadWorks:
Изисквания на Webex : Шаблонът на клиента включва следните настройки:
|
SP контролирано обезпечаване чрез API (Доверени или ненадеждни имейли) |
Webex разкрива набор от публични приложни програмни интерфейси (API), които ви позволяват да вграждате обезпечаване на потребители в съществуващите си работни процеси и инструменти. Има два потока:
Изисквания на BroadWorks:
Изисквания на Webex :
За да използвате API, отидете на Абонати на BroadWorks . |
Необходими корекции с поточно осигуряване
Ако използвате поточно осигуряване, трябва да инсталирате системна корекция и да приложите свойство на CLI. Вижте списъка по-долу за инструкции, които се отнасят за вашата версия на BroadWorks:
За R22:
Инсталирайте AP.as.22.0.1123.ap376508 .
След инсталацията задайте свойството
bw.msg.includeIsEnterpriseInOSSschema
доtrue
от CLI в Опции за поддръжка/контейнер .За повече информация вижте бележките за корекцияhttps://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt .
За R23:
Инсталирайте AP.as.23.0.1075.ap376509
След инсталацията задайте свойството
bw.msg.includeIsEnterpriseInOSSschema
доtrue
от CLI в Опции за поддръжка/контейнер .За повече информация вижте бележките за корекцияhttps://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt .
За R24:
Инсталирайте AP.as.24.0.944.ap375100
След инсталацията задайте свойството
bw.msg.includeIsEnterpriseInOSSschema
доtrue
от CLI в Опции за поддръжка/контейнер .За повече информация вижте бележките за корекцияhttps://www.cisco.com/web/software/286326332/154326/AP.as.24.0.944.ap375100.txt .
След като изпълните тези стъпки, няма да можете да предоставяте на нови потребители услуги UC-One Collaborate. Новоосигурените потребители трябва да са потребители на Webex за Cisco BroadWorks.
|
Поддържани езикови локали
По време на обезпечаването езикът, който е бил присвоен в BroadWorks на първия осигурен администриращ потребител , се присвоява автоматично като локал по подразбиране за тази клиентска организация. Тази настройка определя езика по подразбиране, използван за имейли за активиране, срещи и покани за срещи в рамките на тази клиентска организация.
Пет символни езикови локали в (ISO-639-1)_ (ISO-3166) формат се поддържат. напримерen_ US съответства на English_ Съединените щати. Ако е поискан само двубуквен език (използвайки формат ISO-639-1), услугата ще генерира езиков локал с пет знака, като комбинира искания език с код на държава от шаблона, т.е. "requestedLanguage_ CountryCode", ако не може да се получи валиден локал, тогава се използва разумният локал по подразбиране въз основа на необходимия езиков код.
Следващата таблица изброява поддържаните локали и съпоставянето, което преобразува двубуквен езиков код в петсимволен локал за ситуации, при които петсимволен локал не е наличен.
Поддържани езикови локали (ISO-639-1)_ (ISO-3166) |
Ако е наличен само двубуквен езиков код... |
|
---|---|---|
Езиков код (ISO-639-1) ** |
Вместо това използвайте разумен език по подразбиране (ISO-639-1)_ (ISO-3166) |
|
en_САЩ en_AU en_GB en_CA |
en |
en_САЩ |
fr_FR fr_CA |
fr |
fr_FR |
cs_CZ |
cs |
cs_CZ |
da_DK |
да |
da_DK |
de_DE |
de |
de_DE |
hu_HU |
ху |
hu_HU |
id_ИД |
ид |
id_ИД |
it_ИТ |
it |
it_ИТ |
ja_JP |
я |
ja_JP |
ko_KR |
ko |
ko_KR |
es_ES es_CO es_MX |
es |
es_ES |
nl_NL |
nl |
nl_NL |
nb_НЕ |
nb |
nb_НЕ |
pl_PL |
мн.ч |
pl_PL |
pt_PT pt_БР |
т |
pt_PT |
ru_RU |
ru |
ru_RU |
ro_RO |
ро |
ro_RO |
zh_CN zh_TW |
ж |
zh_CN |
sv_SE |
sv |
sv_SE |
ar_SA |
ar |
ar_SA |
tr_TR |
tr |
tr_TR |
Локалитеes_ CO,id_ ИД,nb_ НЕ иpt_ PT не се поддържат от Webex Meeting Sites. За тези локали сайтовете на Webex Meetings ще бъдат само на английски език. Английският е локалът по подразбиране за сайтове, ако за сайта не се изисква/невалиден/неподдържан локал. Това поле за език е приложимо при създаване на сайт за организация и Webex Meetings . Ако в публикация или в API на абоната не е споменат език, тогава езикът от шаблона ще се използва като език по подразбиране. |
Брандиране
Администраторите на партньори могат да използват Advanced Branding Customizations, за да персонализират как приложението Webex изглежда за клиентските организации, които партньорът управлява. Администраторите на партньори могат да персонализират следните настройки, за да гарантират, че приложението Webex отразява марката и идентичността на компанията:
Фирмени лога
Уникални цветови схеми за светъл или тъмен режим
Персонализирани URL адреси за поддръжка
За подробности как да персонализирате марката, вижте Конфигуриране на разширени персонализации на марката .
|
Шаблони на клиенти
Клиентски шаблони ви позволяват да дефинирате параметрите, чрез които клиентите и свързаните абонати се предоставят автоматично на Webex за Cisco BroadWorks. Можете да конфигурирате няколко клиентски шаблона според изискванията, но когато се присъедините към клиент, той е свързан само с един шаблон (не можете да приложите няколко шаблона към един клиент).
Някои от основните параметри на шаблона са изброени по-долу.
Пакет
Трябва да изберете пакет по подразбиране, когато създавате шаблон (вж Пакети в секцията Преглед за подробности). Всички потребители, които са осигурени с този шаблон, независимо дали чрез поточно или самостоятелно предоставяне, получават пакета по подразбиране.
Имате контрол върху избора на пакети за различни клиенти, като създавате множество шаблони и избирате различни пакети по подразбиране във всеки. След това можете да разпространявате различни връзки за осигуряване или различни адаптери за осигуряване за предприятие, в зависимост от избрания от вас метод за обезпечаване на потребителите за тези шаблони.
Можете да промените пакета от конкретни абонати от това по подразбиране, като използвате API за осигуряване (вж Документация за API на Webex за Cisco BroadWorks или чрез Partner Hub (виж Промяна на потребителския пакет в Partner Hub ) .
Не можете да промените абонатския пакет от BroadWorks. Присвояването на интегрираната услуга IM&P е включено или изключено; ако на абоната е назначена тази услуга в BroadWorks, шаблонът на Partner Hub, свързан с URL за осигуряване на предприятието на този абонат, дефинира пакета.
Реселър и предприятия или доставчик на услуги и групи?
Начинът, по който е конфигурирана вашата BroadWorks система, оказва влияние върху потока чрез обезпечаване. Ако сте търговец на Enterprises, тогава трябва да активирате режима Enterprise, когато създавате шаблон.
Ако вашата система BroadWorks е конфигурирана в режим на доставчик на услуги, можете да оставите изключен режим Enterprise във вашите шаблони.
Ако планирате да предоставяте организации на клиенти, използвайки и двата режима на BroadWorks, трябва да използвате различни шаблони за групи и предприятия.
Уверете се, че сте приложили корекциите на BroadWorks, които са необходими за осигуряване на поток. За подробности вж Необходими корекции с поточно осигуряване .
|
Режим на удостоверяване
Решете как искате абонатите да се удостоверяват, когато влизат в Webex. Можете да зададете режим с помощта на Режим на удостоверяване настройка в клиентския шаблон. Следващата таблица очертава някои от опциите.
Тази настройка няма ефект върху влизането в портала за активиране на потребителя. Потребителите, които влизам в портала, трябва да въведат своя ИД на потребител и парола на BroadWorks, както са конфигурирани в BroadWorks, независимо от това как конфигурирате Режим на удостоверяване на клиентския шаблон.
|
Режим на удостоверяване | BroadWorks | Webex |
Идентичност на първичния потребител | ИД на потребител на BroadWorks | Имейл адрес |
Доставчик на самоличност | BroadWorks.
|
Обща идентичност на Cisco |
Многофакторно удостоверяване? | Не | Изисква IdP на клиента, който поддържа многофакторно удостоверяване. |
Път за валидиране на идентификационни данни |
|
|
За по-подробна разбивка на потока за влизане в SSO с директно удостоверяване към BroadWorks, вж. Поток за влизане в SSO .
|
UTF-8 кодиране с удостоверяване на BroadWorks
С удостоверяване на BroadWorks препоръчваме да конфигурирате UTF-8 кодиране за заглавката за удостоверяване. UTF-8 разрешава проблем, който може да възникне с пароли, които използват специални знаци, при което уеб браузърът не кодира символите правилно. Използването на UTF-8 кодиран, базов 64-кодиран заглавка разрешава този проблем.
Можете да конфигурирате UTF-8 кодиране, като изпълните една от следните CLI команди на XSP или ADP:
XSP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
ADP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
Страна
Трябва да изберете държава, когато създавате шаблон. Тази държава ще бъде автоматично присвоена като държава на организация за всички клиенти, които са осигурени с шаблона в Обща идентичност. Освен това държавата на организацията ще определи глобалните номера за повикване по подразбиране за Cisco PSTN в Webex Meeting Sites.
Глобалните номера за повикване на сайта по подразбиране ще бъдат зададени на първия наличен номер за набиране, дефиниран в телефонния домейн, въз основа на държавата на организацията. Ако държавата на организацията не е намерена в номера за набиране, дефиниран в телефонния домейн, ще се използва номерът по подразбиране за това местоположение.
S № |
Местоположение |
Код на страна |
Име на страна |
---|---|---|---|
1 |
AMER |
+1 |
САЩ, Калифорния |
2 |
APAC |
+65 |
Сингапур |
3 |
ANZ |
+61 |
Австралия |
4 |
EMEA |
+44 |
Обединеното кралство |
5 |
ЕВРО |
+49 |
Германия |
Множество партньорски договорености
Ще дадете ли подлиценз на Webex за Cisco BroadWorks на друг доставчик на услуги? В този случай всеки доставчик на услуги ще се нуждае от отделна партньорска организация в Webex Control Hub, за да му позволи да предоставя решението за своята клиентска база.
Осигуряващ адаптер и шаблони
Когато използвате поточно обезпечаване, URL за осигуряване, който въвеждате в BroadWorks, се извлича от шаблона в Control Hub. Можете да имате множество шаблони и следователно множество URL адреси за осигуряване. Това ви позволява да изберете, на база предприятие по предприятие, кой пакет да приложите към абонатите, когато им бъде предоставена интегрираната услуга IM&P.
Трябва да помислите дали искате да зададете URL за осигуряване на системно ниво като път за осигуряване по подразбиране и кой шаблон искате да използвате за това. По този начин трябва само изрично да зададете URL за осигуряване за онези предприятия, които се нуждаят от различен шаблон.
Също така, имайте предвид, че може вече да използвате URL за предоставяне на системно ниво, например с UC-One SaaS. Ако случаят е такъв, можете да изберете да запазите URL на системно ниво за предоставяне на потребители на UC-One SaaS и да отмените за тези предприятия, които преминават към Webex за Cisco BroadWorks . Като алтернатива, може да искате да отидете по другия начин и да зададете URL на системно ниво за Webex за BroadWorks и да преконфигурирате тези предприятия, които искате да запазите на UC-One SaaS.
Изборите на конфигурация, свързани с това решение, са подробно описани в Конфигурирайте сървъра на приложения с URL на услугата за предоставяне .
Прокси за адаптер за осигуряване
За допълнителна сигурност, Provisioning Adapter Proxy ви позволява да използвате HTTP(S) прокси на платформата за доставка на приложения за осигуряване на поток между AS и Webex. Прокси връзката създава TCP тунел от край до край, който препраща трафик между AS и Webex, като по този начин отрича необходимостта AS да се свързва директно с публичния интернет. За сигурни връзки може да се използва TLS .
Тази функция изисква да настройвам проксито на BroadWorks. За подробности вж Описание на функцията за прокси на адаптера за осигуряване на Cisco BroadWorks .
Минимални изисквания
Акаунти
Всички абонати, които предоставяте за Webex , трябва да съществуват в системата BroadWorks, която интегрирате с Webex. Можете да интегрирате множество BroadWorks системи, ако е необходимо.
Всички абонати трябва да имат лицензи на BroadWorks и основен номер или разширение.
Webex използва имейл адресите като основни идентификатори за всички потребители. Ако използвате поточно осигуряване с надеждни имейли, тогава вашите потребители трябва да имат валидни адреси в атрибута имейл в BroadWorks.
Ако вашият шаблон използва удостоверяване на BroadWorks, можете да копирате имейл адресите на абонатите в атрибута Alternate ИД в BroadWorks. Това дава възможност на потребителите да влизат в Webex , използвайки своите имейл адреси и пароли за BroadWorks.
Вашите администратори трябва да използват своите акаунти в Webex , за да влизам в Partner Hub.
Не се поддържа включване на администратор на BroadWorks към Webex за Cisco BroadWorks. Можете да включите BroadWorks да се обаждате само на потребители, които имат основен номер и/или вътрешен номер. Ако използвате поточно осигуряване, на потребителите трябва също да бъде присвоена интегрираната услуга за IM&P.
|
Сървъри във вашата мрежа и софтуерни изисквания
Инстанция(и) на BroadWorks с минимална версия R22. Вижте Софтуерните изисквания на BroadWorks (в този документ) за поддържани версии и корекции. За повече информация вж Политика за жизнения цикъл на продуктите на BroadSoft раздел в Политика за жизнения цикъл на BroadSoft и матрица за Матрица на съвместимостта на софтуера BroadWorks .
Инстанцията(ите) на BroadWorks трябва да включва поне следните сървъри:
Сървър на приложения (AS) с версия на BroadWorks както по-горе
Мрежов сървър (NS)
Сървър на профили (PS)
Обществен XSP сървър(и) или платформа за доставка на приложения (ADP), отговарящи на следните изисквания:
Услуга за удостоверяване (BWAuth)
XSI интерфейси за действия и събития
DMS ( уеб приложение за управление на устройства)
CTI интерфейс (интегриране на компютърна телефония)
TLS 1.2 с валиден сертификат (не самоподписан) и всички необходими междинни продукти. Изисква администратор на системно ниво за улесняване на търсенето в предприятието.
Взаимно удостоверяване на TLS (mTLS) за услуга за удостоверяване (изисква публичната верига от сертификат на клиент на Webex , инсталирана като надеждни котви)
Взаимно удостоверяване на TLS (mTLS) за CTI интерфейс (изисква публичната верига сертификат на клиент на Webex , инсталирана като надеждни котви)
Отделен XSP/ADP сървър, действащ като „сървър за изпращане на известия за обаждания“ (NPS във вашата среда, използван за изпращане на известия за обаждания към Apple/Google. Тук го наричаме „CNPS“, за да го разграничим от услугата в Webex , която доставя push известия за съобщения и присъствие).
Този сървър трябва да е на R22 или по-нова версия.
Ние налагаме отделен XSP/ADP сървър за CNPS, тъй като непредсказуемостта на натоварването от Webex за BWKS облачни връзки може да повлияе негативно на производителността на NPS сървъра, в резултат на увеличаване на забавянето на известията. Вижте Ръководство за системно инженерство на Cisco BroadWorks за повече в XSP мащаб.
Платформи за приложения на Webex
За да изтеглите английската версия на приложението Webex , отидете наhttps://www.webex.com/webexfromserviceproviders-downloads.html . Приложението Webex е достъпно на:
Windows компютри/лаптопи
Apple компютри / лаптопи с MacOS
iOS (Apple store)
Android (Play Store)
интернет браузъри (отидете наhttps://teams.webex.com/ )
Локализирани версии
За да изтеглите локализирана версия на приложението Webex , използвайте една от тези връзки:
https://origin-webex-uat.cisco.com/ko/webexfromserviceproviders-downloads.html (корейски)
https://origin-webex-uat.cisco.com/fr/webexfromserviceproviders-downloads.html (френски)
https://origin-webex-uat.cisco.com/pt/webexfromserviceproviders-downloads.html (португалски)
https://origin-webex-uat.cisco.com/zh-tw/webexfromserviceproviders-downloads.html (китайски традиционен)
https://origin-webex-uat.cisco.com/zh-cn/webexfromserviceproviders-downloads.html (опростен китайски)
https://origin-webex-uat.cisco.com/ja/webexfromserviceproviders-downloads.html (Япония)
https://origin-webex-uat.cisco.com/es/webexfromserviceproviders-downloads.html (Испания)
https://origin-webex-uat.cisco.com/de/webexfromserviceproviders-downloads.html (немски)
https://origin-webex-uat.cisco.com/it/webexfromserviceproviders-downloads.html (италиански)
Физически телефони и аксесоари
IP телефони на Cisco :
Cisco IP телефон от серия 6800 с Многоплатформен фърмуер
Cisco IP телефон от серия 7800 с Многоплатформен фърмуер
Cisco IP телефон от серия 8800 с Многоплатформен фърмуер
Вижhttps://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html за модели и повече информация.
Поддържаме телефони на трети страни по същия начин, както при други интеграции на BroadWorks. Те обаче все още нямат интеграция за контакти и присъствие с Webex за Cisco BroadWorks.
адаптери:
Cisco ATA 191 мултиплатформен аналогов телефонен адаптер
Cisco ATA 192 мултиплатформен аналогов телефонен адаптер
Вижhttps://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html за модели и повече информация.
слушалки:
Наушници Cisco от серия 500
Вижhttps://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.htmlза модели и повече информация.
- Устройства с операционна система в стаята:
Серия Webex Room and Room Kit
Серия Webex Desk
Серия Webex
Интеграция на устройство
За подробности как да включите и обслужите Room OS и MPP устройства за Webex за Cisco BroadWorks, вж. Ръководство за интегриране на устройство за Webex за Cisco BroadWorks .
Профили на устройства
Следват DTAF файловете, които трябва да заредите на вашите сървъри на приложения, за да поддържате приложението Webex като клиент за повикване. Те са същите DTAF файлове, използвани за UC-One SaaS, но има нов config-wxt.xml.template
файл, който се използва за приложението Webex .
За да изтеглите най-новите профили на устройства, отидете на платформата за доставка на приложения Изтегляне на софтуер сайт, за да получите най-новите DTAF файлове. Тези изтегляния работят както за ADP, така и за XSP.
Име на клиента |
Тип на профила на устройството и име на пакета |
---|---|
Webex Мобилен Шаблон |
Тип профил на самоличност/устройство: Свързване - Мобилно DTAF: Конфигурационен файл: |
Webex таблетка Шаблон |
Тип профил на самоличност/устройство: Connect - таблет DTAF: Конфигурационен файл: |
Webex работен плот Шаблон |
Тип профил на самоличност/устройство: Бизнес комуникатор - компютър DTAF: Конфигурационен файл: |
Идентифициране/профил на устройството
Всички потребители на Webex за Cisco BroadWorks трябва да имат Профил на самоличност/устройство присвоен в BroadWorks, който използва един от горните профили на устройство, за да извършва повиквания с помощта на приложението Webex . Профилът предоставя конфигурацията, която позволява на потребителя да извършва повиквания.
Получаване на OAuth идентификационни данни за вашия Webex за Cisco BroadWorks
Подайте заявка за услуга с вашия агент за включване или с Cisco TAC , за да осигурите Cisco OAuth за вашия акаунт на федерация на доставчика на Cisco Identity Provider.
Използвайте следното заглавие на заявката за съответните функции:
XSP AuthService Configuration", за да конфигурирате услугата на XSP.
„NPS Configuration for Auth Proxy Setup“, за да конфигурирате NPS да използва прокси за удостоверяване.
CI User UUID Sync' за CI потребител UUID синхронизация. За повече подробности относно тази функция вижте: Поддръжка на Cisco BroadWorks за CI UUID .
Конфигурирайте BroadWorks, за да активирате Cisco Billing за BroadWorks и Webex за абонаменти за BroadWorks.
Cisco ви дава клиентски ИД за OAuth, клиентска тайна и токен за опресняване, който е валиден за 60 дни. Ако токенът изтече, преди да го използвате, можете да повдигнете друга заявка.
Ако вече сте получили идентификационни данни на Cisco OAuth Identity Provider, попълнете нова заявка за услуга, за да актуализирате своите идентификационни данни. |
Поръчайте сертификати
Изисквания за сертификат за TLS удостоверяване
Ще ви трябват сертификати за сигурност, подписани от добре познат орган за сертификати и разположени на вашите публични XSP, за всички необходими приложения. Те ще се използват за поддръжка на проверка на TLS сертификат за всички входящи връзки към вашите XSP сървъри.
Тези сертификати трябва да включват вашето публично напълно квалифицирано име на домейн XSP като общо име на субект или алтернативно име на субект.
Точните изисквания за разполагане на тези сървърни сертификати зависят от начина, по който се разполагат вашите публични XSP:
Чрез TLS мостов прокси
Чрез TLS прокси прокси
Директно към XSP
Следната диаграма обобщава къде трябва да се зареди сертификат на сървъра, подписан от CA, в тези три случая:
В списъка са изброени публично поддържаните CA, които Webex приложение поддържа за удостоверяване Поддържани сертифициращи органи за хибридни услуги на Webex .
Изисквания за TLS сертификат за TLS-bridge прокси
Публично подписаният сертификат на сървъра се зарежда в прокси сървъра.
Проксито представя този публично подписан сертификат на сървъра на Webex.
Webex се доверява на публичния CA, който е подписал сертификат на сървъра.
Вътрешен CA подписан сертификат може да бъде зареден в XSP.
XSP представя този вътрешно подписан сертификат на сървъра на прокси сървъра.
Проксито се доверява на вътрешния CA, който е подписал сертификат на сървъра.
Изисквания за TLS сертификат за TLS прокси или XSP в DMZ
Публично подписаният сертификат на сървъра се зарежда в XSP.
XSP представят публично подписани сървърни сертификати на Webex.
Webex се доверява на публичния CA, който е подписал сървърните сертификати на XSP.
Допълнителни изисквания за сертификат за взаимно TLS удостоверяване през CTI интерфейс
Когато се свързва с CTI интерфейса, Webex представя сертификат на клиент като част от взаимното TLS удостоверяване. сертификат на клиент на Webex е достъпен за изтегляне чрез Control Hub.
За да изтеглите сертификата:
Влезте в Partner Hub, трябва
и щракнете върху връзката за изтегляне на сертификат.Точните изисквания за внедряване на тази верига от сертификати на Webex СА сертификат зависят от начина, по който се разполагат вашите публични XSP:
Чрез TLS мостов прокси
Чрез TLS прокси прокси
Директно към XSP
Следната диаграма обобщава изискванията за сертификат в тези три случая:
(Опция) Изисквания за сертификат за TLS-bridge прокси
Webex представя публично подписан сертификат на клиент на проксито.
Проксито се доверява на вътрешния CA на Cisco , който е подписал сертификат на клиент. Можете да изтеглите този CA/верига от Control Hub и да го добавите към хранилището за доверие на проксито. Публично подписаният XSP сертификат на сървъра също се зарежда в прокси сървъра.
Проксито представя публично подписания сертификат на сървъра на Webex.
Webex се доверява на публичния CA, който е подписал сертификат на сървъра.
Проксито представя вътрешно подписан сертификат на клиент на XSP.
Този сертификат трябва имат полето за разширение x509.v3 Разширено използване на ключове попълнен с OID на BroadWorks 1.3.6.1.4.1.6431.1.1.8.2.1.3 и TLS clientAuth цел. напр.:
X509v3 extensions: X509v3 Extended Key Usage: 1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication
CN на вътрешния сертификат трябва да бъде bwcticlient.webex.com .
Когато генерирате вътрешни клиентски сертификати за прокси сървъра, имайте предвид, че SAN сертификатите не се поддържат. Вътрешните сървърни сертификати за XSP могат да бъдат SAN.
Публичните сертифициращи органи може да не желаят да подписват сертификати със собствения BroadWorks OID, който се изисква. В случай на мостов прокси, може да бъдете принудени да използвате вътрешен CA, за да подпишете сертификат на клиент , който проксито представя на XSP.
XSP се доверяват на вътрешния CA.
XSP представят вътрешно подписан сертификат на сървъра.
Проксито се доверява на вътрешния CA.
Сървъра за приложения ClientIdentity съдържа CN на вътрешно подписания сертификат на клиент, представен на XSP от проксито.
(Опция) Изисквания за сертификат за TLS-прокси прокси или XSP в DMZ
Webex представя вътрешен сертификат на клиент на Cisco , подписан от CA на XSP.
XSP се доверяват на вътрешния CA на Cisco , който е подписал сертификат на клиент. Можете да изтеглите този CA/верига от Control Hub и да го добавите към хранилището за доверие на проксито. Публично подписаният XSP сертификат на сървъра също се зарежда в XSP.
XSP представят публично подписаните сървърни сертификати на Webex.
Webex се доверява на публичния CA, който е подписал сървърните сертификати на XSP.
Сървърът на приложенията ClientIdentity съдържа CN на подписания от Cisco сертификат на клиент, представен на XSP от Webex.
Подгответе вашата мрежа
За повече информация относно връзките, които се използват от Webex за Cisco BroadWorks, вижте: Мрежови изисквания за Webex за Cisco BroadWorks . Тази статия съдържа списък с IP адреси, портове и протоколи, необходими за конфигуриране на правилата за вход и изход на защитната стена.
Мрежови изисквания за услугите на Webex
Предходните таблици на защитната стена с правила за влизане и изход документират само връзките, които са специфични за Webex за Cisco BroadWorks. За обща информация относно връзките между Webex приложение и облака Webex вж Мрежови изисквания за услугите на Webex . Тази статия е обща за Webex, но таблицата по-долу идентифицира различните раздели на статията и доколко всеки раздел е подходящ за Webex за Cisco BroadWorks.
Раздел за мрежовите изисквания, член |
Уместност на информацията |
---|---|
Обобщение на типовете устройства и протоколите, поддържани от Webex |
Информационно |
Транспортни протоколи и криптиращи шифри за регистрирани в облака Webex приложения и устройства |
Информационно |
Трябва да се прочете |
|
Трябва да се прочете |
|
Домейни и URL адреси, които трябва да бъдат достъпни за услугите на Webex |
Трябва да се прочете |
Незадължително |
|
Незадължително |
|
Незадължително |
|
Незадължително |
|
Незадължително |
|
Незадължително |
|
Webex услуги за клиенти на FedRAMP |
Няма |
Допълнителна информация
За допълнителна информация вж Бяла книга за защитната стена на приложението Webex (PDF) .
Поддръжка на съкращения на BroadWorks
Webex Cloud услуги на Webex и клиентските приложения на Webex, които трябва да имат достъп до мрежата на партньора, напълно поддържат резервирането на Broadworks XSP, предоставено от партньора. Когато XSP или сайт е недостъпен поради планирана поддръжка или непланирана причина, услугите и приложенията на Webex могат да преминат към друг XSP или сайт, предоставен от партньора, за да изпълнят заявка.
Топология на мрежата
XSP на Broadworks могат да бъдат разгърнати директно в Интернет или могат да се намират в DMZ, преден от елемент за балансиране на товара като F5 BIG- IP. За да осигурят резервиране на географски данни, XSP могат да бъдат разгърнати в два (или повече) центъра за данни, всеки от които може да бъде изправен от балансьор на натоварване, всеки от които има публичен IP адрес. Ако XSP са зад балансира на натоварването, микроуслугите и приложението Webex виждат само IP адрес на балансиращото устройство и изглежда, че Broadworks има само един XSP, дори ако зад него има множество XSP.
В примера по-долу XSP са разгърнати на два обекта, сайт A и сайт B. Има два XSP, предствани от Load Balancer на всеки сайт. Сайт A има XSP1 и XSP2, предствани от LB1, а сайт B има XSP3 и XSP4, предствани от LB2. Само Load Balancers са изложени в публичната мрежа, а XSP са в частните мрежи на DMZ.
Webex Cloud
DNS конфигурация
Webex Cloud трябва да могат да намират сървъра(ите) на Broadworks XSP за свързване към Xsi интерфейсите, услугата за удостоверяване и CTI.
Webex Cloud ще извършат DNS A/AAAA търсене на конфигурираното XSP име на хост и ще се свържат с върнатия IP адрес. Това може да е крайен елемент за балансиране на товара или може да е самият XSP сървър. Ако бъдат върнати няколко IP адреса, първият IP в списъка ще бъде избран. Търсенето на SRV в момента не се поддържа.
Пример: DNS A Record на партньора за откриване на Round-Robin балансиран XSP сървър/балансиране на натоварването, ориентиран към интернет.
Тип на запис |
Име |
Цел |
Предназначение |
---|---|---|---|
О: |
|
|
Насочва към LB1 (сайт A) |
О: |
|
|
Насочва към LB2 (сайт Б) |
При отказ
Когато микроуслугите на Webex изпратят заявка до XSP/Load Balancer и заявката не успее, могат да се случат няколко неща:
Ако повредата се дължи на мрежова грешка (напр. TCP, SSL), микроуслугите на Webex маркират IP като блокиран и незабавно извършват преминаване към следващия IP.
Ако има код на грешката (HTTP5xx ) се връща, микроуслугите на Webex маркират IP като блокиран и незабавно извършват преминаване към следващия IP.
Ако не се получи HTTP отговор в рамките на 2 секунди, заявката изтече и микроуслугите на Webex маркират IP като блокиран и изпълняват маршрут напред към следващия IP.
Всяка заявка се изпробва 3 пъти, преди грешката да бъде докладвана обратно на микроуслугата.
Когато IP е в блокирания списък, той няма да бъде включен в списъка с адреси, които да опитате при изпращане на заявка до XSP. След предварително определен период от време блокираният IP изтича и се връща в списъка, за да опита, когато бъде направена друга заявка.
Ако всички IP адреси са блокирани, микроуслугата все пак ще се опита да изпрати заявката, като избере на случаен принцип IP адрес от списъка с блокирани. Ако е успешен, този IP адрес се премахва от списъка с блокирани.
Статус
Състоянието на свързаността на услугите Webex Cloud към XSP или Load Balancers може да се види в Control Hub. Под клъстер за повиквания на BroadWorks се показва състояние на свързването за всеки от тези интерфейси:
XSI Actions
XSI Events
Услуга на удостоверяване
Състоянието на състояние на свързването се актуализира, когато страницата се зареди или по време на актуализации на въвеждане. Състоянията на връзките могат да бъдат:
зелено: Когато интерфейсът може да бъде достигнат на един от IP адресите в търсенето на A запис.
червено: Когато всички IP адреси в търсенето на запис A са недостъпни и интерфейсът е недостъпен.
Следните услуги използват микроуслугите за свързване към XSP и са повлияни от наличността на XSP интерфейса:
Вход в приложението Webex
Обновяване на токена на приложението Webex
Недоверен имейл/самоактивиране
Проверка на състоянието на Broadworks Service
Приложение Webex
DNS конфигурация
Приложението Webex осъществява достъп до услугите Xtended Services Interface (XSI-Actions & XSI-Events) и Device Management Service (DMS) на XSP.
За да намери услугата XSI, приложението Webex извършва търсене на DNS SRV _xsi-client._tcp.<webex app xsi domain>
. SRV сочи към конфигурирания URL за XSP хостовете или балансьорите на натоварване за услугата XSI. Ако търсенето на SRV не е налично, приложението Webex се връща към A/AAAA търсене.
SRV може да се разреши към множество A/AAAA цели. Въпреки това, всеки A/AAAA запис трябва да се съпоставя само с един IP адрес . Ако има множество XSP в DMZ зад балансиращото устройство/крайното устройство, се изисква балансиращото устройство да бъде конфигурирано да поддържа устойчивост на сесията, за да насочва всички заявки от една и съща сесия към същия XSP. Ние налагаме тази конфигурация, тъй като сърдечните удари на XSI-събитието на клиента трябва да отиват към същия XSP, който се използва за установяване на канала за събитие.
В пример 1 записът A/AAAA за webex-app-xsp.example.com не съществува и не е необходимо. Ако вашият DNS изисква да бъде дефиниран един A/AAAA запис, тогава трябва да бъде върнат само 1 IP адрес . Независимо от това, SRV все още трябва да бъде дефиниран за приложението Webex . Ако приложението Webex използва името A/AAAA, което се разделя на повече от един IP адрес, или ако елементът за балансиране на натоварването/ръба не поддържа постоянство на сесията, клиентът в крайна сметка изпраща удари към XSP, където не е установил канал за събития. Това води до разкъсване на канала, а също и до значително повече вътрешен трафик, което влошава производителността на вашия XSP клъстер. Тъй като Webex Cloud и Webex App имат различни изисквания при търсене на A/AAAA записи, трябва да използвате отделно FQDN за Webex Cloud и Webex App за достъп до вашите XSP. Както е показано в примерите, Webex Cloud използва A запис |
Пример 1 — Множество XSP, всеки зад отделни балансиращи устройства
В този пример SRV сочи към множество A записи, като всеки A запис сочи към различен балансьор на натоварване на различен сайт. Приложението Webex винаги ще използва първия IP адрес в списъка и ще се премести към следващия запис само ако първият не работи.
Тип на запис |
Записване |
Цел |
Предназначение |
---|---|---|---|
SRV |
|
|
Клиентско откриване на интерфейса Xsi |
SRV |
|
|
Клиентско откриване на интерфейса Xsi |
О: |
|
|
Посочва LB1 (сайт A) |
О: |
|
|
Насочва към LB2 (сайт B) |
Пример 2 — Множество XSP зад един балансьор на натоварване (с TLS Bridge)
За първоначалната заявка балансьорът на натоварване избира произволен XSP. Този XSP връща бисквитка, която приложението Webex включва в бъдещи заявки. За бъдещи заявки балансьорът на натоварване използва бисквитката, за да насочи връзката към правилния XSP, като гарантира, че каналът за събития няма да се счупи.
Тип на запис |
Записване |
Цел |
Предназначение |
---|---|---|---|
SRV |
|
|
Балансьор на натоварване |
О: |
LB.example.com |
|
IP адрес на балансира на натоварването (XSP са зад балансира на натоварването) |
DMS URL
По време на процеса на влизане, приложението Webex също ще извлече DMS URL , за да изтегли своя конфигурационен файл. Хостът в URL ще се анализира синтактично и приложението Webex ще извърши DNS A/AAAA търсене на хоста, за да се свърже с XSP, който хоства услугата DMS.
Пример: DNS A Запис за откриване на Round-Robin балансиран XSP сървър/балансери на натоварването от Webex App за изтегляне на конфигурационни файлове чрез DMS:
Тип на запис |
Име |
Цел |
Предназначение |
---|---|---|---|
О: |
|
|
Посочва LB1 (сайт A) |
О: |
|
|
Насочва към LB2 (сайт B) |
Как приложението Webex намира XSP адреси
Клиентът се опитва да намери XSP възлите, използвайки следния DNS поток:
Първоначално клиентът извлича URL адреси на Xsi-Actions/Xsi-Events от Webex Cloud (вие ги въведохте, когато създавате свързания BroadWorks Calling Cluster). Името на хост Xsi/домейна се анализира от URL и клиентът извършва SRV търсене, както следва:
Клиентът извършва SRV търсене за_xsi -клиент._tcp .<xsi domain="">
Ако търсенето на SRV върне една или повече A/AAAA цели:
Клиентът прави A/AAAA търсене за тези цели и кешира върнатите IP адреси.
Клиентът се свързва с една от целите (и следователно неговия A/AAAA запис с един IP адрес) въз основа на приоритета на SRV, след това теглото (или на случаен принцип, ако всички са равни).
Ако търсенето на SRV не върне никакви цели:
Клиентът прави A/AAAA търсене на основния параметър Xsi и след това се опитва да се свърже с върнатия IP адрес. Това може да е крайен елемент за балансиране на товара или може да е самият XSP сървър.
както беше отбелязано, записът A/AAAA трябва да се разреши до един IP адрес по същите причини.
(По избор) Впоследствие можете да предоставите персонализирани подробности за XSI-Actions/XSI-Events в конфигурация на устройството за Webex приложение, като използвате следните тагове:
<protocols> <xsi> <paths> <root>%XSI_ROOT_WXT%</root> <actions>%XSI_ACTIONS_PATH_WXT%</actions> <events>%XSI_EVENTS_PATH_WXT%</events> </paths> </xsi> </protocols>
Тези конфигурационни параметри имат предимство пред всяка конфигурация във вашия BroadWorks Cluster в Control Hub.
Ако съществуват, клиентът ще сравни с оригиналния XSI адрес, който е получил чрез конфигурацията на BroadWorks Cluster.
Ако има някаква разлика, клиентът ще инициализира отново своята връзка XSI Actions/XSI Events. Първата стъпка в това е да извършите същия процес на търсене на DNS , посочен в стъпка 1 – този път да поискате търсене за стойността в%XSI_ROOT_WXT% параметър от неговия конфигурационен файл.
Уверете се, че сте създали съответните SRV записи, ако използвате този маркер за промяна на Xsi интерфейсите.
При отказ
По време на влизане приложението Webex извършва търсене на DNS SRV за_xsi -клиент._tcp .<xsi domain=""> , изгражда списък с хостове и се свързва с един от хостовете въз основа на приоритета на SRV, след това теглото. Този свързан хост става избран за всички бъдещи заявки. След това към избрания хост се отваря канал за събитие и редовно се изпраща пулс за проверка на канала. Всички заявки, изпратени след първата, включват бисквитка, която се връща в HTTP отговора, следователно е важно балансьорът на натоварване да поддържа постоянството на сесията (афинитет) и винаги да изпраща заявки до един и същ бекенд XSP сървър.
Ако заявка или заявка за сърдечен ритъм към хост не успее, могат да се случат няколко неща:
Ако повредата се дължи на мрежова грешка (напр. TCP, SSL), маршрутът на приложението Webex преминава незабавно към следващия хост в списъка.
Ако има код на грешката (HTTP5xx ) се връща, приложението Webex маркира този IP адрес като блокиран и маршрутът преминава към следващия хост в списъка.
Ако отговорът не бъде получен в рамките на определен период от време, тогава заявката се счита за неуспешна поради изчакване и следващите заявки се изпращат до следващия хост. Въпреки това, заявката за изтекло време се счита за неуспешна. Някои заявки се изпробват повторно след неуспех (с увеличаване на времето за повторен опит). Заявките, за които се предполага, че не са жизненоважни, не се изпълняват повторно.
Когато нов хост бъде изпробван успешно, той става новият избран хост, ако хостът присъства в списъка. След като бъде изпробван последният хост в списъка, приложението Webex ще се прехвърли към първия.
В случай на сърдечен ритъм, ако има две последователни неуспешни заявки, приложението Webex ще инициализира повторно канала за събитие.
Имайте предвид, че приложението Webex не извършва възстановяване при отказ и откриването на DNS услуга се извършва само веднъж при влизане.
По време на влизане приложението Webex се опитва да изтегли конфигурационния файл през интерфейса XSP/Dms. Той извършва търсене на A/AAAA запис на хоста в извлечения DMS URL и се свързва с първия IP. Първо ще се опита да изпрати заявката за изтегляне на конфигурационния файл с помощта на SSO маркер. Ако това не успее по някаква причина, ще опита отново, но с потребителското име и паролата на устройството.