Представяме ви Обаждане в Webex
Представете си, че можете да използвате корпоративни функции за обаждане в облак, мобилност и PBX, заедно с приложението Webex за съобщения и срещи и обаждания от софтуерен клиент за Webex Calling или устройство на Cisco. Точно това може да ви предложи Webex Calling.
Webex Calling предоставя следните предимства:
Абонаменти за обаждания за потребители на телефония и общи части
Достъп до приложението Webex за всеки потребител
Достъп до обществена комутационна телефонна мрежа (PSTN), за да позволите на вашите потребители да набират номера извън организацията. Услугата се предоставя чрез съществуваща корпоративна инфраструктура (локален шлюз без локална IP PBX или със съществуваща Unified CM среда за разговори)
Webex Calling поддържа следните функции. За повече информация вижте главата Конфигуриране на функции за повикване на Webex.
Функция |
Описание |
---|---|
Автоматичен секретар |
Можете да добавяте поздрави, да настройвате менюта и да насочвате повиквания към телефонен секретар, група за търсене, кутия за гласова поща или реален човек. Можете да създадете 24-часов график или да предоставите различни опции, когато вашият бизнес е отворен или затворен. Можете дори да насочвате повиквания въз основа на атрибути за идентификация на обаждащия се, за да създавате VIP списъци или да обработвате повиквания от определени регионални кодове по различен начин. |
Опашка на повикванията |
Можете да настроите опашка за обаждания, така че когато не може да се отговори на входящите повиквания, на обаждащите се предоставя автоматичен отговор, утешителни съобщения и музика на изчакване, докато някой може да отговори на повикването им. |
Поемане на повиквания |
Можете да подобрите работата в екип и сътрудничеството, като създадете група за приемане на повиквания, така че потребителите да могат да отговарят на повиквания. Когато добавите потребители към група за приемане на повиквания и член на групата е далеч или зает, друг член може да отговаря на техните повиквания. |
Паркиране на повикване |
Можете да включите паркирането на повикванията, така че потребителите да могат да поставят обаждане на задържане и да го вдигнат от друг телефон. |
Група за търсене |
Може да искате да настроите групи за лов в следните сценарии:
|
Група за пейджинг |
Можете да създадете група за пейджинг, така че потребителите да могат да изпращат аудио съобщение до човек, отдел или екип. Когато някой изпрати съобщение до група за пейджинг, съобщението се възпроизвежда на всички устройства в групата. |
Клиент за рецепционисти |
Помогнете да поддържате нуждите на персонала на вашия фронт-офис, като им предоставите пълен набор от опции за контрол на повикванията, широкомащабно наблюдение на линии, опашка за обаждания, множество опции и изгледи на директории, интеграция с Outlook и др. |
Потребителите могат да конфигурират следните функции в https://settings.webex.com, които се стартират кръстосано в Портала за обаждащи се потребители.
Функция |
Описание |
---|---|
Анонимно отхвърляне на повиквания |
Потребителите могат да отхвърлят входящи повиквания с блокирани идентификатори на обаждащия се. |
Без прекъсване на работата |
Ако телефоните на потребителите не са свързани към мрежата по някаква причина (като прекъсване на захранването, проблеми с мрежата и т.н.), потребителите могат да пренасочват входящите повиквания към конкретен телефонен номер. |
Пренасочване на повикванията |
Потребителите могат да пренасочват входящи повиквания към друг телефон. |
Селективно пренасочване на повиквания |
Потребителите могат да пренасочват повиквания в определени часове от конкретни обаждащи се. Тази настройка ще има предимство пред пренасочването на повиквания. |
Уведомяване за обаждане |
Потребителите могат да си изпращат имейл, когато получат обаждане според предварително зададени критерии като телефонен номер или дата и час. |
Повикване изчакване |
Потребителите могат да разрешат приемане на допълнителни входящи повиквания. |
Не ме безпокойте |
Потребителите могат временно да оставят всички обаждания да отиват директно към гласовата поща. |
Office Anywhere |
Потребителите могат да използват избраните от тях телефони („Местоположения“) като разширение на техния бизнес телефонен номер и план за набиране. |
Приоритетен сигнал |
Потребителите могат да позвънят на телефоните си с отличителен звън, когато са изпълнени предварително определени критерии, като телефонен номер или дата и час. |
Отдалечен офис |
Потребителите могат да извършват обаждания от отдалечен телефон и той да се показва от тяхната бизнес линия. В допълнение, всички входящи повиквания към тяхната бизнес линия ще звънят на този отдалечен телефон. |
Селективно приемане на повиквания |
Потребителите могат да приемат обаждания в определени часове от конкретни обаждащи се. |
Селективно отхвърляне на повикване |
Потребителите могат да отхвърлят обаждания в определени часове от конкретни обаждащи се. |
Последователен пръстен |
Звънете на до 5 устройства едно след друго за входящи повиквания. |
Едновременен Пръстен |
Звънене на потребителски и други („получатели на повикване“) номера по едно и също време за входящи повиквания. |
Осигуряване на услуги, устройства и потребители в Control Hub, кръстосано стартиране до подробна конфигурация в Обаждане на администраторския портал
Control Hub (https://admin.webex.com) е портал за управление, който се интегрира с Webex Calling, за да рационализира вашите поръчки и конфигурация и да централизира управлението ви на пакетната оферта— Обаждания в Webex, Приложение Webex и Срещи.
Control Hub е централната точка за предоставяне на всички услуги, устройства и потребители. Можете да направите настройка за първи път на вашата услуга за обаждания, да регистрирате MPP телефони в облака (използвайки MAC адрес), да конфигурирате потребители чрез асоцииране на устройства, добавяне на номера, услуги, функции за повикване и т.н. Освен това от Control Hub можете да стартирате кръстосано към портала за администратори за обаждания.
Потребителски опит
Потребителите имат достъп до следните интерфейси:
Приложение за обаждания на Webex— Софт-клиент за обаждания, брандирани от Cisco. За повече информация вижте Разгледайте новото приложение за обаждания на Cisco Webex.
Настройки на Webex (https://settings.webex.com) – Интерфейс, в който потребителите могат да задават предпочитания за потребителския профил, да изтеглят приложението Webex и да стартират кръстосано в Потребителския портал за обаждания за настройки за повиквания. За повече информация вижте Промяна на настройките на Cisco Webex.
Приложение Webex – Приложение, включено в абонамента като клиент за екипни съобщения с марка Cisco. За повече информация вижте Първи стъпки с приложението Cisco Webex.
Webex Meetings—Добавено по избор приложение като решение за срещи. За повече информация вижте Webex Meetings.
Общ преглед
Webex Calling може да намали оперативните разходи и да подобри производителността, като ви помогне да мигрирате критични бизнес комуникации към облака. Когато се комбинира с други приложения и устройства на Webex, това е сърцето на цялостното корпоративно обаждане в облак и съвместна работа. Cisco поддържа локално, в облака и внедряване на смесени модели, за да поддържа клиентите си свързани и продуктивни отвсякъде; дори по време на разрушителни пазарни събития.
Webex Calling вече включва специална опция за облачен екземпляр, базирана на архитектурата на Cisco Unified Communications Manager. Специализираният екземпляр е интегриран с Webex Calling и се възползва от услугите на платформата Webex, като предоставя иновации в облака и подобрено изживяване на клиентите, които трябва да поддържат по-стари крайни точки на Cisco, локални решения за оцеляване или съществуващи интеграции, част от критични бизнес работни процеси.
Добавката за специален екземпляр за повиквания в Webex включва:
Cisco Unified Communications Manager
Cisco Unified IM и присъствие
Cisco Unified Unity Connection
Автомагистрала на Cisco
Cisco Emergency Responder (само за регион на Америка)
Прост път на миграция
Специализираният екземпляр за Webex Calling осигурява опростен път за миграция в облак от наследена PBX, както и локални системи Unified Communications Manager.
Специализираният екземпляр облекчава точките на болка, свързани с миграциите на корпоративни обаждания към облака:
Без прекъсвания – Специализираният екземпляр има същите функции, функционалност, потребителско изживяване и опции за интеграция, поддържани от Unified Communications Manager, разположени на място, включително поддръжка за Jabber и Webex App. Това създава безпроблемна миграция към облака, без да се изисква обучение за краен потребител или администратор за съществуващи клиенти на Unified Communications Manager. Специализираният екземпляр може да бъде свързан към PBX на трети страни, което позволява на новите клиенти на Cisco гъвкав график за миграция.
Персонализиране – Специален частен екземпляр за всеки клиент позволява силно персонализирано внедряване в облак, което е уникална разлика от другите предложения за обаждания в облак на пазара. Отворените API на Dedicated Instance позволяват дълбоки интеграции на приложения на трети страни, позволявайки на клиентите да изградят среда за повиквания, която поддържа уникални бизнес работни потоци.
Безкомпромисна сигурност – С Dedicated Instance клиентите имат достъп до всички функции за защита на Unified Communications Manager за крайни точки и UC приложения като криптирани медии, защитен SRST, защитена OTT регистрация, използваща MRA.
В допълнение, клиентите имат достъп до важни функции за физическа сигурност, като Cisco Survivable Remote Site Telephony (SRST) за свързване на сайта в случай, че мрежовите връзки паднат и Cisco Emergency Responder и Nomadic E911, за да гарантират, че служителите могат да бъдат локализирани от службите за спешна помощ, когато са в офиса или в хибриден режим на работа.
Разширена възвръщаемост на инвестициите – Специализираният екземпляр поддържа същите гласови и видео крайни точки като свързаната версия на UC Manager, елиминирайки изискването за опресняване на всички крайни точки на клиента при мигриране към облака и разширяване на ROI на тези активи.
Basic Inter-Op – Специализиран екземпляр е интегриран с Webex Calling за маршрутизиране на повиквания през платформата Webex. Клиентите имат гъвкавостта да разпределят потребителите както в Специализиран инстанционен модел, така и в Webex Calling и да се коригират с течение на времето, ако е необходимо, за да отговорят на техните бизнес изисквания за обаждания в облак.
Клиентите, които разделят потребителите на различни платформи, ще изпитат различни функции. Функциите за повикване не са хармонизирани между Специализиран екземпляр и Webex Calling. Например потребителите на Webex Calling не могат да бъдат част от група за търсене на Специализиран екземпляр. |
Наличност на решение
Услугата Специализиран инстанция е достъпна в световен мащаб и може да се поръча като добавка за Webex Calling Flex Plan 3.0 чрез партньори в определени държави. Вижте Глобалното ръководство за наличност за повече подробности.
Специализираният екземпляр поддържа същото ниво на локализация като нашия локален мениджър за обединени комуникации. Той поддържа тонове за телефон и шлюз в 82 държави, портал за самообслужване на 50 езика и клиенти на повече от 30 езика.
Ползи
- Специализирано приложение за повикване, хоствано и управлявано от Cisco в центрове за данни на Webex
- Персонализирана платформа за обаждания
- Гъвкава, бързо мащабируема архитектура
- Познато потребителско изживяване, което намалява необходимостта от преквалификация на служителите
- Обединен клиент за обаждания, съобщения, срещи и екипно сътрудничество, който може да се използва на всички типове устройства
- Съвместимост с цялото портфолио на Cisco от телефони, шлюзове и видео устройства
- Интегрира се със срещи, съобщения и обаждания на Webex като част от пакета Webex, позволявайки невероятно изживяване на клиентите от край до край.
За поддържани крайни точки и устройства, моля, кликнете тук.
Направете обиколка на Control Hub
Control Hub е вашият единствен достъпен уеб-базиран интерфейс за управление на вашата организация, управление на вашите потребители, възлагане на услуги, анализиране на тенденциите за приемане и качеството на обажданията и др.

За да задействате организацията си, препоръчваме ви да поканите няколко потребители да се присъединят към Приложението Webex, като въведете техните имейл адреси в Control Hub. Насърчавайте хората да използват услугите, които предоставяте, включително обаждания, и да ви дават обратна връзка за опита си. Когато сте готови, винаги можете да добавите още потребители.
Препоръчваме ви да използвате най-новата настолна версия на Google Chrome или Mozilla Firefox за достъп до Control Hub. Браузърите на мобилни устройства и други настолни браузъри могат да дадат неочаквани резултати. |
Използвайте информацията, представена по-долу, като обобщение на високо ниво за това какво да очаквате, когато настройвате вашата организация с услуги. За по-подробна информация вижте отделните глави за инструкции стъпка по стъпка.
Първи стъпки
След като вашият партньор създаде вашия акаунт, ще получите имейл за добре дошли. Кликнете върху връзката Първи стъпки в имейла, като използвате Chrome или Firefox за достъп до Control Hub. Връзката автоматично ви влиза с имейл адреса на вашия администратор. След това ще бъдете подканени да създадете вашата администраторска парола.

Съветник за първи път за изпитания
Ако вашият партньор ви е регистрирал за пробен период, съветникът за настройка автоматично стартира, след като влезете в Control Hub. Съветникът ви превежда през основните настройки, за да стартирате вашата организация с Webex Calling, наред с други услуги. Можете да настроите и прегледате настройките си за обаждания, преди да завършите инструкциите на съветника.

Прегледайте вашите настройки
Когато Control Hub се зареди, можете да прегледате настройките си.

Добавяне на потребители
След като сте настроили услугите си, сте готови да добавите хора от фирмения си указател. Отидете на Потребители и кликнете върху Управление на потребителите.

Ако използвате Microsoft Active Directory, препоръчваме първо да активирате Синхронизиране на директории и след това да решите как искате да добавяте потребители. Щракнете върху Напред и следвайте инструкциите, за да настроите Cisco Directory Connector.
Настройване на единен вход (SSO)
Приложението Webex използва основно удостоверяване. Можете да изберете да настроите SSO, така че потребителите да се удостоверяват с вашия доставчик на корпоративна идентичност, използвайки своите корпоративни идентификационни данни, вместо отделна парола, съхранявана и управлявана в Webex.
Отидете на Настройки, превъртете до Удостоверяване, щракнете върху Промяна и след това изберете Интегриране на доставчик на самоличност от трета страна.

Разпределяне на услуги на потребителите
Трябва да зададете услуги на потребителите, които сте добавили, за да могат хората да започнат да използват Приложението Webex.
Отидете на Потребители, щракнете върху Управление на потребителите, изберете Експортиране и импортиране на потребители с CSV файл и след това щракнете върху Експортиране.
Във файла, който изтегляте, просто добавете True за услугите, които искате да присвоите на всеки от своите потребители.

Импортирайте завършения файл, щракнете върху Добавяне и премахване на услуги и след това върху Изпращане. Вече сте готови да конфигурирате функции за повиквания, да регистрирате устройства, които могат да бъдат споделени на общо място, и да регистрирате и асоциирате устройства с потребители.
Дайте възможност на вашите потребители
След като сте добавили потребители и са им присвоени услуги, те могат да започнат да използват поддържаните от тях многоплатформени телефони (MPP) за Обаждания в Webex и Приложение Webex за съобщения и срещи. Насърчете ги да използват Настройки на Cisco Webex като едно гише за достъпа.
Роля на локалния портал
Локалният шлюз е ръбово устройство, управлявано от предприятие или партньор, за взаимодействие с обществена комутационна телефонна мрежа (PSTN) и съвместна работа с наследени публични клонове (PBX) (включително Unified CM).
Можете да използвате Control Hub, за да присвоите локален шлюз към местоположение, след което Control Hub предоставя параметри, които можете да конфигурирате на CUBE. Тези стъпки регистрират локалния шлюз в облака и след това услугата PSTN се предоставя през шлюза на потребителите на Webex Calling на определено място.
За да посочите и поръчате локален шлюз, прочетете ръководството за поръчка на локален шлюз.
Поддържани локални внедрявания на шлюз за Обаждания в Webex
Поддържат се следните основни внедрявания:
Локалният шлюз може да бъде разгърнат самостоятелно или в разгръщания, където е необходима интеграция в Cisco Unified Communications Manager.
Разгръщане на локален шлюз без локална IP PBX
Самостоятелни внедрявания на локален шлюз
Тази фигура показва внедряване на Webex Calling без съществуваща IP PBX и е приложима за едно местоположение или внедряване на няколко места.
За всички обаждания, които не съвпадат с вашите дестинации за Webex Calling, Webex Calling изпраща тези обаждания до локалния шлюз, който е назначен за местоположението за обработка. Локалният шлюз насочва всички повиквания, които идват от Webex Calling към PSTN и в другата посока, PSTN към Webex Calling.
PSTN шлюзът може да бъде специална платформа или coresident с локалния шлюз. Както на следващата фигура, ние препоръчваме специалния вариант на PSTN шлюз на това разгръщане; може да се използва, ако съществуващият PSTN шлюз не може да се използва като локален шлюз за Webex Calling.
Разгръщане на локален шлюз на Coresident
Локалният шлюз може да бъде базиран на IP, свързващ се към ITSP с помощта на SIP магистрала или TDM базиран с помощта на ISDN или аналогова верига. Следната фигура показва внедряване на Webex Calling, при което локалният шлюз е coresident с PSTN GW/SBC.
Разгръщане на локален шлюз с локална Unified CM PBX
Интеграциите с Unified CM са необходими в следните случаи:
Местоположенията с активиран Webex Calling се добавят към съществуващо внедряване на Cisco UC, където Unified CM се внедрява като локално решение за контрол на повиквания
Изисква се директно набиране между телефони, регистрирани в Unified CM, и телефони в местоположения на Webex Calling.
Тази фигура показва внедряване на Webex Calling, при което клиентът има съществуваща Unified CM IP PBX.
Webex Calling изпраща повиквания, които не съвпадат с дестинациите за Webex Calling на клиента, към локалния шлюз. Това включва PSTN номера и вътрешни разширения на Unified CM, които Webex Calling не може да види. Локалният шлюз насочва всички повиквания, които идват от Webex Calling към Unified CM и обратно. След това Unified CM насочва входящите повиквания към местни дестинации или към PSTN според съществуващия план за набиране. Унифицираният CM план за набиране нормализира числата като +E.164. PSTN шлюзът може да бъде специален или сърезидентен с локалния шлюз.
Специализиран PSTN шлюз
Специализираният вариант на PSTN шлюз на това внедряване, както е показано на тази диаграма, е препоръчителната опция и може да се използва, ако съществуващият PSTN шлюз не може да се използва като локален шлюз за Webex Calling.
Coresident PSTN Gateway
Тази фигура показва внедряване на Webex Calling с Unified CM, където локалният шлюз е coresident с PSTN шлюза/SBC.
Webex Calling насочва всички повиквания, които не съвпадат с дестинациите на Webex Calling на клиента към локалния шлюз, който е назначен за местоположението. Това включва PSTN дестинации и повиквания в мрежата към вътрешни разширения на Unified CM. Локалният шлюз насочва всички повиквания към Unified CM. След това Unified CM насочва обажданията към локално регистрирани телефони или към PSTN през локалния шлюз, който разполага с PSTN/SBC функционалност.
Съображения за маршрутизиране на повиквания
Обаждания от Webex Calling към Unified CM
Логиката за маршрутизиране на Webex Calling работи по следния начин: ако номерът, който е набран в крайна точка на Webex Calling, не може да бъде насочен към друга дестинация в рамките на същия клиент в Webex Calling, тогава повикването се изпраща до локалния шлюз за по-нататъшна обработка. Всички повиквания извън мрежата (извън Webex Calling) се изпращат към локалния шлюз.
За внедряване на Webex Calling без интегриране в съществуващ Unified CM, всяко повикване извън мрежата се счита за PSTN обаждане. Когато се комбинира с Unified CM, обаждането извън мрежата все още може да бъде повикване в мрежата до всяка дестинация, хоствана на Unified CM, или реално повикване извън мрежата до PSTN дестинация. Разликата между последните два типа повиквания се определя от Unified CM и зависи от корпоративния план за набиране, който е осигурен в Unified CM.
Следната фигура показва потребител на Webex Calling, който набира национален номер в САЩ.
Unified CM сега, базиран на конфигурирания план за набиране, насочва повикването към локално регистрирана крайна точка, на която извиканата дестинация е предоставена като номер на директория. За това планът за набиране на Unified CM трябва да поддържа маршрутизиране на +E.164 номера.
Обаждания от Unified CM до Webex Calling
За да активирате пренасочването на повиквания от Unified CM към Webex Calling в Unified CM, трябва да бъде осигурен набор от маршрути за дефиниране на набора от +E.164 и адресите на корпоративния номерационен план в Webex Calling .
С тези маршрути са възможни и двата сценария на повикване, показани на следващата фигура.
Ако обаждащ се в PSTN се обади на DID номер, който е присвоен на устройство Webex Calling, тогава повикването се предава на предприятието през PSTN шлюза на предприятието и след това се улавя Unified CM. Извиканият адрес на това обаждане съвпада с един от маршрутите за Обаждания в Webex, който е осигурен в Unified CM и повикването се изпраща до локалния шлюз. (Извиканият адрес трябва да бъде във формат +E.164, когато се изпраща до локалния шлюз.) След това логиката за маршрутизиране на повиквания в Webex гарантира, че повикването се изпраща до предвиденото устройство за Webex Calling въз основа на присвояване на DID.
Освен това обажданията, произхождащи от регистрирани крайни точки в Unified CM, насочени към дестинации в Webex Calling, подлежат на плана за набиране, който е осигурен в Unified CM. Обикновено този план за набиране позволява на потребителите да използват обичайните корпоративни навици за набиране, за да извършват повиквания. Тези навици не включват непременно само +E.164 набиране. Всеки навик за набиране, различен от +E.164, трябва да се нормализира до +E.164, преди повикванията да се изпращат към локалния шлюз, за да се даде възможност за правилно маршрутизиране в Webex Calling.
Клас на обслужване (CoS)
Прилагането на строг клас ограничения на услугите винаги се препоръчва поради различни причини, включително избягване на цикли на разговори и предотвратяване на измами с пътни такси. В контекста на интегрирането на Webex Calling Local Gateway с Unified CM клас услуга, ние трябва да разгледаме класа на услугата за:
Устройства, регистрирани в Unified CM
Обаждания, идващи в Unified CM от PSTN
Обаждания, идващи в Unified CM от Webex Calling
Устройства, регистрирани в Unified CM
Добавянето на дестинациите за Webex Calling като нов клас дестинации към съществуваща настройка на CoS е доста лесно: разрешението за повикване до дестинации за Webex Calling обикновено е еквивалентно на разрешението за обаждане на място (включително между сайтовите) дестинации.
Ако корпоративен план за набиране вече прилага разрешение за „(съкратено) в мрежата между сайтове“, тогава вече има обезпечен дял в Unified CM, който можем да използваме и предоставяме всички известни в мрежата Webex Calling дестинации в същия дял.
В противен случай концепцията за „(съкратено) разрешение между сайтове в мрежата“ все още не съществува, тогава трябва да бъде осигурен нов дял (например „onNetRemote“), добавят се дестинациите за Webex Calling към този дял и накрая този нов дял трябва да бъде добавен към съответните пространства за търсене на извиквания.
Обаждания, идващи в Unified CM от PSTN
Добавянето на дестинациите за Webex Calling като нов клас дестинации към съществуваща настройка на CoS е доста лесно: разрешението за повикване до дестинации за Webex Calling обикновено е еквивалентно на разрешението за обаждане на място (включително между сайтовите) дестинации.
Ако корпоративен план за набиране вече прилага разрешение за „(съкратено) в мрежата между сайтове“, тогава вече има обезпечен дял в Unified CM, който можем да използваме и предоставяме всички известни в мрежата Webex Calling дестинации в същия дял.
В противен случай концепцията за „(съкратено) разрешение между сайтове в мрежата“ все още не съществува, тогава трябва да бъде осигурен нов дял (например „onNetRemote“), добавят се дестинациите за Webex Calling към този дял и накрая този нов дял трябва да бъде добавен към съответните пространства за търсене на извиквания.
Обаждания, идващи в Unified CM от Webex Calling
Обажданията, идващи от PSTN, се нуждаят от достъп до всички дестинации на Webex Calling. Това изисква добавяне на горния дял, съдържащ всички дестинации на Webex Calling, към пространството за търсене на повиквания, използвано за входящи повиквания в PSTN магистралата. Достъпът до дестинациите за Webex Calling идва в допълнение към вече съществуващия достъп.
Докато за повиквания от PSTN достъпът до Unified CM DID и DID за Webex Calling е необходим, повикванията, произхождащи от Webex Calling, се нуждаят от достъп до Unified CM DID и PSTN дестинации.

Тази фигура сравнява тези два различни класа услуги за повиквания от PSTN и Webex Calling. Фигурата също така показва, че ако функционалността на PSTN шлюза е локализирана с локалния шлюз, тогава са необходими две магистрали от комбинирания PSTN GW и локален шлюз към Unified CM: един за повиквания, произхождащи от PSTN и един за повиквания, произхождащи от Webex Calling. Това се дължи на изискването за прилагане на диференцирани пространства за търсене на обаждания по тип трафик. С две входящи канала на Unified CM това може лесно да се постигне чрез конфигуриране на необходимото пространство за търсене на повиквания за входящи повиквания във всяка магистрала.
Интеграция на план за набиране
Това ръководство предполага съществуваща инсталация, която се основава на най-добрите настоящи практики в „Предпочитана архитектура за локални внедрявания на Cisco Collaboration, CVD“. Най-новата версия е налична тук.
Препоръчителният дизайн на схемата за набиране следва подхода за проектиране, който е документиран в главата План за набиране на най-новата версия на Cisco Collaboration System SRND, достъпна тук.

Тази фигура показва общ преглед на препоръчания дизайн на схемата за набиране. Основните характеристики на този дизайн на схемата за набиране включват:
Всички номера на директории, които са конфигурирани в Unified CM, са във формат +E.164.
Всички номера на директории се намират в един и същ дял (DN) и са маркирани като спешни.
Основното маршрутизиране се основава на +E.164.
Всички навици за набиране извън +E.164 (например съкратено вътрешно набиране и PSTN набиране с използване на общи навици за набиране) се нормализират (глобализират) до +E.164, използвайки модели за превод за нормализиране на набиране.
Моделите за превод за нормализиране на набиране използват модел на превод, извикващ наследяване на пространството за търсене; те имат зададена опция „Използване на пространството за търсене на обаждания на източника“.
Класът на услугата се реализира чрез използване на специфични за сайта и клас пространства за търсене на обаждания.
Възможностите за достъп до PSTN (например достъп до международни PSTN дестинации) се реализират чрез добавяне на дялове със съответните модели на маршрут +E.164 към пространството за търсене на повиквания, определящо класа на услугата.
Достъпност до Webex Calling

За да добавите достъпност за дестинациите за повиквания в Webex към този план за набиране, трябва да бъде създаден дял, представляващ всички дестинации за повиквания в Webex („Webex повикване”) и към този дял се добавя модел на маршрут +E.164 за всеки диапазон DID в повикване на Webex. Този модел на маршрут препраща към списък с маршрути само с един член: групата маршрути със SIP магистрала към локалния шлюз за повиквания към Webex Calling. Тъй като всички набрани дестинации се нормализират към +E.164 или като се използват модели за преобразуване на нормализиране на набиране за повиквания, произхождащи от регистрирани крайни точки в Unified CM, или трансформации на входяща повиквана страна за повиквания, произхождащи от PSTN, този единичен набор от модели на маршрут +E.164 е достатъчен за постигане достъпност за дестинации в Webex Calling независимо от използвания навик за набиране.
Ако например потребител набере „914085550165“, тогава моделът за превод на нормализиране на набиране в дял „UStoE164“ нормализира този низ за набиране на „+14085550165“, който след това съвпада с модела на маршрута за дестинация за повикване на Webex в дял „Webex Calling“. Unified CM в крайна сметка изпраща обаждането до локалния шлюз.
Добавете съкратено междусайтово набиране

Препоръчителният начин за добавяне на съкратено междусайтово набиране към референтния план за набиране е да добавите модели за превод на нормализиране на набиране за всички сайтове под плана за номериране на предприятието към специален дял („ESN“, Enterprise Significant Numbers). Тези модели на превод прихващат низове за набиране във формата на плана за номериране на предприятието и нормализират набрания низ до +E.164.
За да добавите корпоративно съкратено набиране към дестинациите за повикване на Webex, добавяте съответния модел за превод за нормализиране на набиране за местоположението за повикване на Webex към дяла „Webex Calling“ (например „8101XX“ на диаграмата). След нормализиране повикването отново се изпраща до Webex Calling след съвпадение на шаблона на маршрута в дяла „Webex Calling“.
Не препоръчваме добавяне на съкратен модел за нормализиране на транслиране на набиране за повиквания на Webex Calling към дяла „ESN“, тъй като тази конфигурация може да създаде нежелани цикли за маршрутизиране на повиквания.
Манипулатори на протоколи за повикване
Webex Calling регистрира следните манипулатори на протоколи в операционната система, за да активира функцията за обаждане чрез щракване от уеб браузъри или друго приложение. Следните протоколи стартират аудио или видео обаждане в приложението Webex, когато това е приложението за повиквания по подразбиране на Mac или Windows:
КЛИКНЕТЕ ОБЗАВЕТЕ: или ЩРАКНЕТЕ ИЗВИКВАНЕ: //
SIP: или SIP://
ТЕЛ: или ТЕЛ://
WEBEXTEL: или WEBEXTEL://
Манипулатори на протоколи за Windows
Други приложения могат да се регистрират за манипулаторите на протоколи преди приложението Webex. В Windows 10, системният прозорец, за да поиска от потребителите да изберат кое приложение да използват, за да стартират повикването. Потребителското предпочитание може да бъде запомнено, ако потребителят постави отметка до Винаги да използва това приложение.
Ако потребителите трябва да нулират настройките на приложението за повиквания по подразбиране, за да могат да изберат Приложение Webex, можете да им инструктирате да променят асоциациите на протокола за Приложение Webex в Windows 10:
Отворете системните настройки Настройки на приложението по подразбиране, щракнете върху Задаване на настройки по подразбиране по приложение и след това изберете Приложение Webex .
За всеки протокол изберете Приложение Webex .
Манипулатори на протоколи за macOS
В Mac OS, ако други приложения са регистрирани към протоколите за повиквания преди Приложението Webex, потребителите трябва да конфигурират своето Приложение Webex да бъде опцията за повикване по подразбиране.
В Приложение Webex за Mac потребителите могат да потвърдят, че Приложение Webex е избрано за настройката Започване на разговори с в общите предпочитания. Те могат също да отметнат Винаги се свързвай с Microsoft Outlook, ако искат да извършват обаждания в Приложението Webex, когато щракнат върху номера на контакт в Outlook.
Изисквания за извикване
Лицензиране
Webex Calling е достъпен чрез плана Cisco за сътрудничество Flex. Трябва да закупите план на Enterprise Agreement (EA) (за всички потребители, включително 50% устройства с работни области) или план на именуван потребител (NU) (някои или всички потребители).
Webex Calling предоставя три типа лицензи ("Видове станции")
Професионално—Тези лицензи предоставят пълна функция, зададена за цялата ви организация. Тази оферта включва единни комуникации (Webex Calling), мобилност (настолни и мобилни клиенти с поддръжка за няколко устройства), екипно сътрудничество в Webex App, както и възможност за собличане на срещи с до 1000 участници на среща.
Basic—Изберете тази опция, ако потребителите Ви се нуждаят от ограничени функции без мобилност или единни комуникации. Те все още ще получат пълнофунклютна гласова оферта, но са ограничени до едно устройство на потребител.
Основните лицензи са достъпни само ако имате наименуван потребителски абонамент. Основни лицензи не се поддържат за абонаменти за Корпоративно споразумение.
Работни области (известни още като Обща област)—Изберете тази опция, ако търсите основен браво-тон с ограничен набор от функции за обаждания, подходящи за области като стаи за почивка, лобита и конферентни зали.
Тази документация по-късно ви показва как да използвате контролния център, за да управлявате тези разпределения на лицензи на различни места във вашата организация.
Изисквания за пропускателната способност
Всяко устройство във видеоразговор изисква до 2 Mbps. Всяко устройство в аудио разговор изисква 100 kbps. Телефоните при престой се нуждаят от минимална честотна лента.
Локален шлюз за помещения базирани PSTN
И двете добавена стойност риселъри (VARs) и доставчици на услуги (SPs) може да осигури PSTN достъп до Webex Calling организации. Местен шлюз в момента е единствената възможност за предоставяне на помещения базирани PSTN достъп. Местният шлюз може да бъде разгърнат самостоятелен или в разгръщания, където се изисква интегриране в Cisco Unified Communications Manager. Следват изискванията на местния шлюз.
Поддържани устройства
Webex Calling поддържа Cisco мултиплатформа (MPP) IP телефони. Като администратор можете да регистрирате следните телефони в облака. Вижте следните помощни статии за повече информация:
За пълен списък на поддържаните устройства за Webex Calling вижте Поддържани устройства за Webex Calling. |
Cisco Webex стая, съвет и бюро устройства се поддържат като устройства в работна област, която създавате в контролния център. Вижте "Cisco Webex стая, съвет и бюро устройства" в поддържани устройства за Webex calling за повече информация. Въпреки това, можете да предоставите тези устройства с PSTN услуга, като активирате Webex Calling за работната област.
Защитна стена
Отговаряйте на изискванията на защитната стена, които са документирани в Порт референтна информация за Cisco Webex Calling.
Изисквания за локален шлюз за webex извикване
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling, гарантирайте, че
Притежавайте основни познания по принципите на VoIP
Разполагайте с основни работни познания за гласовите концепции cisco IOS-XE и IOS-XE
Да има основно разбиране на Протокола за започване на сесия (SIP)
Имате основно разбиране на Cisco унифициран мениджър комуникации (Унифициран CM), ако вашият модел за разполагане включва Унифициран CM
Повече подробности можете да намерите в Ръководството за конфигуриране на унифициран граничен елемент (CUBE) на Cisco на https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че разполагането ви има един или повече от локалните шлюзове (Cisco CUBE (за IP-базирана свързаност) или Cisco IOS Gateway (за TDM-базирана свързаност)), които са в таблица 1 на локалния шлюз за Webex Calling Ordering Guide. Освен това се уверете, че платформата се изпълнява поддържа IOS-XE издание като на локалното ръководствоза конфигуриране на шлюз.
Изисквания за лиценз за локални шлюзове
НА локалния шлюз трябва да се инсталират лицензи за извикване на CUBE. За повече информация вижте Ръководствотоза конфигуриране на унифицирани гранични елементи на Cisco.
Изисквания за сертификат и сигурност за локален шлюз
Webex Calling изисква сигурна сигнализация и медии. Локалният шлюз извършва шифроването и TLS връзка трябва да бъде установена изходяща към облака със следните стъпки:
LGW трябва да се актуализира с CA корен пакет от Cisco PKI
Набор от SIP идентификационни данни за храносмилане от страницата за конфигуриране на Trunk на Контролния център се използват за конфигуриране на LGW (стъпките са част от конфигурацията, която следва)
CA корен сноп валидира представени сертификат
Подканени за идентификационни данни (осигурено SIP храносмилане)
Облакът идентифицира кой локален шлюз е сигурно регистриран
Защитна стена, NAT traversal и изисквания за оптимизиране на медийния път за локален шлюз
В повечето случаи локалният шлюз и крайни точки могат да пребивават във вътрешната клиентска мрежа, като използват частни IP адреси с NAT. Защитната стена на предприятието трябва да позволява изходящ трафик (SIP, RTP/UDP, HTTP) към конкретни IP адреси/портове, обхванати в Информация за препраткакъм портове.
Ако искате да услоите Оптимизиране на медийния път с ICE, webex Calling интерфейсът на локалния шлюз, изправен пред интерфейса, трябва да има директен мрежов път до и от крайните точки на Webex Calling. Ако крайните точки са на различно място и няма директен мрежов път между крайните точки и интерфейса webex Calling на локалния шлюз, изправен, тогава локалният шлюз трябва да има публичен IP адрес, присвоен на интерфейса, пред който е изправен Webex Calling, за обаждания между локалния шлюз и крайните точки за използване на оптимизацията на медийния път. Освен това трябва да се изпълнява IOS-XE версия 16.12.5.
Персонализирайте вашата организация за Webex Calling в Control Hub. След като активирате първото си местоположение чрез Съветника за настройка за първи път, можете да настроите и управлявате допълнителни местоположения, присвояване и използване на магистрала, опции за план за набиране, потребители, устройства и функции.
Първата стъпка, за да стартирате услугите си за Webex Calling, е да завършите Съветника за първа настройка (FTSW). След като FTSW бъде завършен за първото ви местоположение, не е необходимо да се попълва за допълнителни местоположения.
1 | Кликнете върху връзката Първи стъпки в имейла за добре дошли, който получавате.
|
||
2 | Прегледайте и приемете условията за ползване. |
||
3 | Прегледайте плана си и след това кликнете върху Първи стъпки.
|
||
4 | Изберете държавата, към която вашият център за данни трябва да картографира, и въведете информацията за контакт с клиента и адреса на клиента. |
||
5 | Кликнете върху Напред: Местоположение по подразбиране. |
||
6 | Изберете от следните опции:
|
||
7 | Направете следните избори, за да приложите към това местоположение:
|
||
8 | Щракнете върху Напред. |
||
9 | Въведете наличен SIP адрес на Cisco Webex и щракнете върху Напред и изберете Край. |
Преди да започнете
За да създадете ново местоположение, подгответе следната информация:
Адрес на местоположението
Желани телефонни номера (по избор)
1 | От изгледа на клиента в https://admin.webex.com отидете на и кликнете върху Добавяне на местоположение. Имайте предвид, че новите местоположения ще бъдат хоствани в регионалния център за данни, който съответства на държавата, която сте избрали с помощта на съветника за първа настройка. |
||||
2 | Конфигурирайте настройките на местоположението:
|
||||
3 | Кликнете върху Запазване и след това изберете Да/ Не, за да добавите номера към местоположението сега или по-късно. |
||||
4 | Ако сте щракнали върху Да, изберете една от следните опции:
Изборът на опция за PSTN е на всяко ниво на местоположение (всяко местоположение има само една опция PSTN). Можете да смесвате и съпоставяте толкова опции, колкото искате за внедряването си, но всяко местоположение ще има една опция. След като изберете и осигурите опция за PSTN, можете да я промените, като щракнете върху Управление в свойствата на PSTN за местоположение. Някои опции, като Cisco PSTN, обаче, може да не са налични, след като е назначена друга опция. Отворете заявка за поддръжка за насоки. |
||||
5 | Изберете дали искате да активирате номерата сега или по-късно. |
||||
6 | Ако сте избрали неинтегриран CCP или PSTN, базиран на помещения, въведете Телефонни номера като стойности, разделени със запетая, и след това щракнете върху Потвърждаване. Добавят се номера за конкретното местоположение. Валидните записи се преместват в полето Валидирани номера, а невалидните остават в полето Добавяне на номера, придружени от съобщение за грешка. В зависимост от държавата на местоположението, номерата се форматират според изискванията за местно набиране. Например, ако се изисква код на държавата, можете да въведете цифри със или без кода и кодът се поставя преди. |
||||
7 | Щракнете върху Запиши. |
Какво да направите след това
След като създадете местоположение, можете да активирате спешни 911 услуги за това местоположение. Вижте RedSky Emergency 911 Service for Webex Calling за повече информация.
Преди да започнете
Вземете списък на потребителите и работните пространства, свързани с местоположение: Отидете на изтриете тези потребители и работни пространства, преди да изтриете местоположението. и от падащото меню изберете местоположението, което да бъде изтрито. Трябва даИмайте предвид, че всички номера, свързани с това местоположение, ще бъдат върнати обратно на вашия доставчик на PSTN; вече няма да притежавате тези номера. |
1 | От изгледа на клиента в https://admin.webex.com отидете на . |
2 | Кликнете върху |
3 | Изберете Изтриване на местоположение и потвърдете, че искате да изтриете това местоположение. Обикновено отнема няколко минути, преди местоположението да бъде изтрито за постоянно, но може да отнеме до един час. Можете да проверите състоянието, като щракнете върху |
Можете да промените вашата PSTN настройка, името, часовата зона и езика на местоположението, след като бъде създадено. Имайте предвид обаче, че новият език се прилага само за нови потребители и устройства. Съществуващите потребители и устройства продължават да използват стария език.
За съществуващи местоположения можете да активирате спешни 911 услуги. Вижте RedSky Emergency 911 Service for Webex Calling за повече информация. |
1 | От изгледа на клиента в https://admin.webex.com отидете на и след това изберете местоположението, което искате да актуализирате. Ако видите символ Внимание до местоположение, това означава, че все още не сте конфигурирали телефонен номер за това местоположение. Не можете да извършвате или получавате никакви обаждания, докато не конфигурирате този номер. |
||||||
2 | (По избор) Под PSTN връзка изберете или PSTN, свързан с облак, или базиран в помещения PSTN (локален шлюз), в зависимост от това кой вече сте конфигурирали. Щракнете върху Управление, за да промените тази конфигурация, и след това потвърдете свързаните рискове, като изберете Продължи. След това изберете една от следните опции и кликнете върху Запазване:
|
||||||
3 | Изберете Основния номер, на който можете да се свържете с основния контакт на местоположението. |
||||||
4 | (По избор) Под Спешни обаждания можете да изберете Идентификатор на местоположение при спешни случаи, за да присвоите това местоположение.
|
||||||
5 | Изберете Номера на гласовата поща, на който потребителите могат да се обадят, за да проверят гласовата си поща за това местоположение. |
||||||
6 | (По избор) Щракнете върху иконата на молив в горната част на страницата с местоположение, за да промените Име на местоположение, Език за обявление, Език на имейл, Часова зона или Адрес, ако е необходимо, след което кликнете върху Запазване.
|
Тези настройки са за вътрешно набиране и са налични и в съветника за първа настройка. Докато променяте своя план за набиране, примерните номера в Control Hub се актуализират, за да покажат тези промени.
Кодовете за изходящо набиране не се поддържат на устройствата Webex App, Webex Calling App или Cisco Room. |
Можете да конфигурирате разрешения за изходящи повиквания за местоположение. Вижте тези стъпки, за да конфигурирате разрешенията за изходящи повиквания. |
1 | От изгледа на клиента в https://admin.webex.com отидете на и след това превъртете до Вътрешно набиране. |
||
2 | Конфигурирайте следните незадължителни предпочитания за набиране, ако е необходимо:
|
||
3 | Посочете вътрешно набиране за конкретни местоположения. Отидете на Набиране и след това променете вътрешния и външно набиране според нуждите: , изберете местоположение, превъртете до
Въздействие върху потребителите:
|
Ако сте дистрибутор с добавена стойност, можете да използвате тези стъпки, за да започнете конфигуриране на локален шлюз в Control Hub. Когато този шлюз е регистриран в облака, можете да го използвате на едно или повече от вашите Webex Calling местоположения, за да осигурите маршрутизиране към корпоративен доставчик на PSTN услуги.
Местоположение, което има локален шлюз, не може да бъде изтрито, когато локалният шлюз се използва за други местоположения. |
Преди да започнете
След като се добави местоположение и преди да конфигурирате базиран на помещения PSTN за местоположение, трябва да създадете магистрала.
Създайте всякакви местоположения и специфични настройки и номера за всяко от тях. Местоположенията трябва да съществуват, преди да можете да добавите PSTN, базиран на помещения.
Разберете изискванията за PSTN (локален шлюз) на базата на помещения за Обаждания в Webex.
Не можете да изберете повече от една магистрала за местоположение с базирана на помещения PSTN, но можете да изберете една и съща магистрала за множество местоположения.
1 | От изгледа на клиента в https://admin.webex.com отидете на и изберете Добавяне на багажника. |
||
2 | Изберете местоположение. |
||
3 | Дайте име на багажника и кликнете върху Запазване.
|
Какво да направите след това
Информацията за магистралата се показва на екрана Регистриране на домейн, Trank Group OTG/DTG, Линия/Порт и Изходящ прокси адрес.
Препоръчваме ви да копирате тази информация от Control Hub и да я поставите в локален текстов файл или документ, за да можете да се обърнете към нея, когато сте готови да конфигурирате базирания в помещения PSTN.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за транка в Control Hub. Щракнете върху Извличане на потребителско име и нулиране на парола, за да генерирате нов набор от идентификационни данни, които да използвате в багажника.
1 | От изгледа на клиента в https://admin.webex.com отидете на . |
||
2 | Изберете местоположение за промяна и кликнете върху Управление. |
||
3 | Изберете Базиран в помещения PSTN и кликнете върху Напред. |
||
4 | Изберете багажник от падащото меню.
|
||
5 | Щракнете върху известието за потвърждение, след което върху Запазване. |
Какво да направите след това
Трябва да вземете конфигурационната информация, генерирана от Control Hub, и да картографирате параметрите в локалния шлюз (например на Cisco CUBE, който се намира в помещенията). Тази статия ви превежда през този процес. Като справка вижте следната диаграма за пример как информацията за конфигурацията на Control Hub (вляво) се съпоставя с параметрите в CUBE (вдясно):
След като завършите успешно конфигурацията на самия шлюз, можете да се върнете към Control Hub и създаденият от вас шлюз ще бъде посочен в картата за местоположение, към която сте го присвоили, със зелена точка вляво от името. Това състояние показва, че шлюзът е сигурно регистриран в облака за повикване и служи като активен PSTN шлюз за местоположението.
вМожете лесно да преглеждате, активирате, премахвате и добавяте телефонни номера за вашата организация в Control Hub. За повече информация вижте Управление на телефонни номера в Control Hub.
Ако изпробвате услугите на Webex и искате да преобразувате пробната си версия в платен абонамент, можете да изпратите заявка по имейл до партньора си.
1 | От изгледа на клиента в https://admin.webex.com изберете иконата на сграда |
2 | Изберете раздела Абонаменти и след това кликнете върху Купете сега. До партньора ви се изпраща имейл, уведомяващ го, че се интересувате от преминаване към платен абонамент. |
Можете да използвате Control Hub, за да зададете приоритета на наличните опции за обаждания, които потребителите виждат в Приложението Webex. Можете също да ги активирате за обаждане с едно щракване.
1 | От изгледа на клиента в https://admin.webex.com отидете на , превъртете до Обаждане и след това изберете Настройки на клиента. |
||
2 | Плъзнете и пуснете опциите за повиквания, които искате потребителите да виждат, в полето Налични опции за обаждане и след това ги пренаредете в приоритетния ред, който искате за вашите потребители. Други опции, които са скрити за потребителите, се показват в полето Опции за скрити обаждания, както е показано на тази примерна екранна снимка: |
||
3 | Включете Активиране на обаждане с едно кликване, ако искате потребителите да могат да извършват повикване с опцията за първото обаждане, която сте конфигурирали в предишната стъпка.
|
Можете да контролирате какво приложение за повикване се отваря, когато потребителите извършват PSTN повиквания. След като конфигурирате тази настройка на ниво организация, можете да замените тази настройка за конкретни потребители.
Изберете опцията за цялата организация само ако сте готови да мигрирате цялата си организация. |
Преди да започнете
Вашата организация трябва да има правилните абонаменти за поведението на обажданията, което изберете.
Потребителите трябва да имат валидни телефонни номера. Ако номерата са невалидни, Приложението Webex все още изпраща номера до избраното от вас приложение за обаждания, но обаждането от това приложение няма да бъде успешно.
От изгледа на клиента в https://admin.webex.com отидете на и след това превъртете до Поведение при обаждане и след това изберете едно от следните: .
Появява се съобщение, което показва, че поведението на повикване е актуализирано. Потребителите вече могат да извършват PSTN повиквания от Приложение Webex или приложението Webex Calling. Потребителите трябва да имат инсталирано съответното приложение, за да извършват PSTN повиквания от Приложение Webex. Уверете се, че сте уведомили хората какъв избор правите и дали друго приложение се използва за извършване на PSTN повиквания.
|
След като конфигурирате Webex Calling за вашата организация, можете да конфигурирате магистрала за свързване на вашия локален шлюз към Webex Calling. Транкът между локалния шлюз и облака Webex винаги е защитен чрез SIP TLS транспорт. Медията между локалния шлюз и Webex Calling използва SRTP.
Поток на задачите за конфигуриране на локален шлюз
Има две опции за конфигуриране на локалния шлюз за вашата магистрала Webex Calling:
Багажник, базиран на регистрация
Багажник, базиран на сертификат
Използвайте потока от задачи или под Базиран на регистрация локален шлюз или базиран на сертификат локален шлюз, за да конфигурирате локален шлюз за вашата Webex Calling магистрала. Вижте Конфигуриране на връзки, групи маршрути и планове за набиране за Webex Calling за повече информация относно различните типове линии. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Използваме протокол за започване на сесия (SIP) и транспорт на сигурността на транспортния слой (TLS), за да защитим магистралата, и защитен протокол в реално време (SRTP), за да защитим медиите между локалния шлюз и Webex Calling.
Преди да започнете
Разберете изискванията за базирана на място обществена комутируема телефонна мрежа (PSTN) и локален шлюз (LGW) за обаждания чрез Webex. Вижте Предпочитана архитектура на Cisco за Webex Calling за повече информация.
Тази статия предполага, че е налице специална платформа за локален шлюз без съществуваща гласова конфигурация. Ако модифицирате съществуващ PSTN шлюз или корпоративно внедряване на локален шлюз, за да използвате като функция за локален шлюз за Webex Calling, тогава обърнете специално внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци на повиквания и функционалност поради промените, които правите.
Създайте ствол в Control Hub и го задайте на местоположението. Вижте Конфигуриране на връзки, групи маршрути и планове за набиране за Webex Calling за повече информация.
Преди да започнете
Уверете се, че следната базова конфигурация на платформата, която конфигурирате, е настроена в съответствие с правилата и процедурите на вашата организация:
НТП
ACL
активиране на пароли
основна парола
IP маршрутизиране
IP адреси и т.н
Необходима ви е минимална поддържана версия на Cisco IOS XE 16.12 или IOS-XE 17.3 за всички внедрявания на локален шлюз.
1 | Уверете се, че присвоявате на всички интерфейси на ниво 3 валидни и маршрутизирани IP адреси:
|
2 | Конфигурирайте предварително първичен ключ за паролата, като използвате следните команди, преди да използвате в идентификационните данни и споделените тайни. Вие шифровате паролите тип 6 с помощта на AES шифър и дефиниран от потребителя първичен ключ.
|
3 | Конфигурирайте IP сървъра за имена, за да активирате DNS търсене и ping, за да сте сигурни, че сървърът е достъпен. Локалният шлюз използва DNS за разрешаване на прокси адреси на Webex Calling:
|
4 | Активиране на изключителността на TLS 1.2 и точка за доверие по подразбиране:
|
5 | Актуализирайте доверителния пул на локалния шлюз: Пакетът за доверие по подразбиране не включва сертификатите „DigiCert Root CA“ или „IdenTrust Commercial“, които са ви необходими за валидиране на сертификата от страна на сървъра по време на установяване на TLS връзка към Webex Calling. Изтеглете най-новия „Cisco Trusted Core Root Bundle“ от http://www.cisco.com/security/pki/, за да актуализирате пакета trustpool. |
Преди да започнете
Уверете се, че сте изпълнили стъпките в Control Hub, за да създадете местоположение и да добавите ствол за това местоположение. В следващия пример получавате информацията от Control Hub.
1 | Въведете следните команди, за да включите приложението Local Gateway (вижте Референтна информация за портове за Cisco Webex Calling за най-новите IP подмрежи, които трябва да добавите към списъка за доверие):
Ето обяснение на полетата за конфигурацията:
|
||||
2 | Конфигурирайте „SIP профил 200“.
Ето обяснение на полетата за конфигурацията:
|
||||
3 | Конфигурирайте профил на кодек, дефиниция на зашеметяване и SRTP Crypto пакет.
Ето обяснение на полетата за конфигурацията:
|
||||
4 | Съпоставете параметрите на контролния център към конфигурацията на локалния шлюз. Добавете Webex Calling като наемател в локалния шлюз. Необходима ви е конфигурация, за да регистрирате локалния шлюз под клиент на гласов клас 200. Трябва да получите елементите на тази конфигурация от страницата Trunk Info от Control Hub, както е показано на следното изображение. Следващият пример показва кои са полетата, които се съпоставят към съответния CLI на локалния шлюз. Приложете клиент 200 към всички точки за набиране, обърнати към Webex Calling (2xx маркер) в рамките на конфигурацията на локалния шлюз. Функцията за наемател на гласов клас позволява групиране и конфигуриране на параметри на SIP трънк, които иначе се извършват при гласова услуга VoIP и sip-ua. Когато конфигурирате клиент и го приложите под точка за набиране, следният ред на предпочитание се прилага за конфигурациите на локален шлюз:
|
||||
5 | Конфигурирайте voice class tenant 200, за да активирате регистрация на магистрала от Local Gateway към Webex Calling въз основа на параметрите, които сте получили от Control Hub:
Ето обяснение на полетата за конфигурацията:
|
След като дефинирате клиент 200 в рамките на локалния шлюз и конфигурирате SIP VoIP dial-peer, шлюзът инициира TLS връзка към Webex Calling, в който момент SBC за достъп представя своя сертификат към локалния шлюз. Локалният шлюз потвърждава SBC сертификата за достъп до Webex Calling, като използва основния пакет на CA, който е актуализиран по-рано. Установява постоянна TLS сесия между локалния шлюз и SBC за достъп до Webex Calling. След това локалният шлюз изпраща РЕГИСТРАТОР към SBC за достъп, който е предизвикан. AOR за регистрация е номер@домейн. Номерът е взет от параметъра „номер“ на идентификационните данни и домейна от „dns на регистратора:<fqdn>“. Когато регистрацията е оспорена:
параметрите username, password и realm от credentials се използват за изграждане на заглавката и sip-профила 200.
преобразува SIPS url обратно в SIP.
Това внедряване изисква следната конфигурация на локалния шлюз:
Клиенти на гласов клас – Създавате допълнителни клиенти за точки за набиране, изправени пред ITSP, подобно на клиента 200, който създавате за Webex Calling, обърнати към точки за набиране.
URI адреси на гласови класове – Вие дефинирате шаблони за IP адреси/портове на хостове за различни канали, завършващи на локален шлюз:
Webex Calling към LGW
PSTN SIP магистрален край на LGW
Изходящи точки за набиране – Можете да маршрутизирате крака на изходящо повикване от LGW към ITSP SIP транк и Webex Calling.
Гласов клас DPG – Можете да извикате за насочване към изходящите точки за набиране от входяща точка за набиране.
Входящи точки за набиране—Можете да приемате крака на входящо повикване от ITSP и Webex Calling.
Използвайте конфигурациите или за настройка на локален шлюз, хостван от партньор, или за шлюз на клиентски сайт, както е показано на следното изображение.
1 | Конфигурирайте следните наематели на гласови класове: |
2 | Конфигурирайте следния uri адрес на гласов клас: |
3 | Конфигурирайте следните изходящи точки за набиране: |
4 | Конфигурирайте следните групи за набиране (dpg): |
5 | Конфигурирайте следните входящи точки за набиране: |
- PSTN към Webex Calling
-
Съпоставете всички входящи крака на IP PSTN повикване на локалния шлюз с точка за набиране 100, за да определите критерий за съответствие за заглавката на VIA с IP адреса на IP PSTN. DPG 200 извиква изходяща точка за набиране 200201, която има сървъра Webex Calling като целева дестинация.
- Webex Обаждания към PSTN
-
Съпоставете всички входящи крака на повикване Webex Calling на локалния шлюз с точка за набиране 200201, за да определите критерия за съвпадение за образеца на заглавката на REQUEST URI с параметъра OTG/DTG на групата на ствола, уникален за това внедряване на локален шлюз. DPG 100 извиква изходяща точка за набиране 101, която има IP PSTN IP адреса като целева дестинация.
Това внедряване изисква следната конфигурация на локалния шлюз:
Клиенти на гласов клас – Създавате повече клиенти за точки за набиране, обърнати към Unified CM и ITSP, подобно на клиент 200, който създавате за Webex Calling, обърнати към точки за набиране.
URI адреси на гласови класове – Вие дефинирате шаблон за IP адреси/портове на хостове за различни връзки, завършващи на LGW от:
Унифициран CM към LGW за PSTN дестинации
Унифициран CM към LGW за дестинации на Webex Calling
Webex Calling до LGW дестинации
PSTN SIP магистрален край на LGW
Сървърна група от гласов клас – Можете да насочвате IP адреси/портове за изходящи канали от:
LGW към Unified CM
LGW към Webex Calling
LGW към PSTN SIP магистрала
Изходящи точки за набиране – Можете да маршрутизирате крака на изходящо повикване от:
LGW към Unified CM
ITSP SIP трънк
Webex Calling
Гласов клас DPG – Можете да извикате за насочване към изходящи точки за набиране от входяща точка за набиране.
Входящи точки за набиране – Можете да приемате крака на входящо повикване от Unified CM, ITSP и Webex Calling.
1 | Конфигурирайте следните наематели на гласови класове: |
2 | Конфигурирайте следния uri адрес на гласов клас: |
3 | Конфигурирайте следните гласови клас сървърни групи: |
4 | Конфигурирайте следните изходящи точки за набиране: |
5 | Конфигурирайте следния DPG: |
6 | Конфигурирайте следните входящи точки за набиране: |
IP PSTN към Unified CM PSTN магистрала
Платформа Webex Calling към магистрала Unified CM Webex Calling
Унифициран CM PSTN канал към IP PSTN
Унифициран CM Webex Calling канал към платформата Webex Calling
Diagnostic Signatures (DS) проактивно открива често срещани проблеми в базирания на IOS XE локален шлюз и генерира имейл, системен журнал или известие за терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни към кутията на Cisco TAC, за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Логиката за откриване на проблеми се дефинира с помощта на syslog съобщения, SNMP събития и чрез периодично наблюдение на специфични изходни данни на командата show. Типовете действия включват събиране на изходни данни от командата show, генериране на консолидиран лог файл и качване на файла в мрежово местоположение, предоставено от потребителя, като HTTPS, SCP, FTP сървър. DS файловете са създадени от инженери на TAC и са цифрово подписани за защита на целостта. Всеки DS файл има уникален цифров идентификатор, зададен от системата. Инструментът за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които модифицирате, не успяват да се инсталират поради грешка при проверка на целостта.
Сървър на Simple Mail Transfer Protocol (SMTP), от който се нуждаете, за да може локалният шлюз да изпраща известия по имейл.
Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако желаете да използвате защитен SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз с IOS XE 17.3.2 или по-нова версия
Диагностичните подписи са активирани по подразбиране.
Конфигурирайте защитен имейл сървър, който да се използва за изпращане на проактивно известие, ако устройството работи с Cisco IOS XE 17.3.2 или по-нова версия.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Конфигурирайте променливата на средата ds_email с имейл адреса на администратора, когото да уведомите.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Локален шлюз с версия 16.11.1 или по-нова
Диагностичните подписи са активирани по подразбиране
Конфигурирайте имейл сървъра, който да се използва за изпращане на проактивни известия, ако устройството работи с версия, по-стара от 17.3.2.
configure terminal call-home mail-server <email server> priority 1 end
Конфигурирайте променливата на средата ds_email с имейл адреса на администратора, който да бъде уведомен.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Локален шлюз, работещ с версия 16.9.x
Въведете следните команди, за да активирате диагностичните подписи.
configure terminal call-home reporting contact-email-addr sch-smart-licensing@cisco.com end
Конфигурирайте имейл сървъра, който да се използва за изпращане на проактивни известия, ако устройството работи с версия, по-стара от 17.3.2.
configure terminal call-home mail-server <email server> priority 1 end
Конфигурирайте променливата на средата ds_email с имейл адреса на администратора, който да бъде уведомен.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.3.2, за изпращане на проактивни известия до tacfaststart@gmail.com с помощта на Gmail като защитен SMTP сървър:
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Локалният шлюз, работещ на софтуера Cisco IOS XE, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на Gmail акаунт и да предоставим конкретно разрешение, за да се обработва правилно имейлът от устройството: |
Отидете на Достъп до по-малко защитено приложение.
и включете настройкатаОтговорете „Да, бях аз“, когато получите имейл от Gmail, в който се казва „Google попречи на някого да влезе в акаунта ви чрез приложение, което не е на Google“.
Инсталирайте диагностични сигнатури за проактивно наблюдение
Мониторинг на високо натоварване на процесора
Този DS проследява 5-секундното използване на процесора, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички грешки и деинсталира всички диагностични подписи, които са инсталирани в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Уверете се, че активирате SNMP с помощта на командата show snmp. Ако не активирате, конфигурирайте командата „snmp-server manager“.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Изтеглете DS 64224, като използвате следните падащи опции в Инструмент за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
Високо използване на процесора с известие по имейл.
Копирайте DS XML файла във флаш локалния шлюз.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
Инсталирайте DS XML файла в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com
Изтеглете DSes:
DS ID
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, моля, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на процесора на локалния шлюз.
Мониторинг на SIP trunk регистрация
Този DS проверява за отмяна на регистрацията на локален шлюз SIP Trunk с Cisco Webex Calling облак на всеки 60 секунди. След като събитието за отмяна на регистрация бъде открито, то генерира имейл и известие за системния журнал и се деинсталира след две събития за отмяна на регистрация. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Изтеглете DS 64117, като използвате следните падащи опции в Инструмент за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
ГЛЪТКА-ГЛЪТКА
Тип проблем
Дерегистрация на SIP Trunk с известие по имейл.
Копирайте DS XML файла в локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
Инсталирайте DS XML файла в локалния шлюз.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
Мониторинг на необичайни прекъсвания на повикване
Този DS използва SNMP запитване на всеки 10 минути, за да открие необичайно прекъсване на връзката с SIP грешки 403, 488 и 503. Ако нарастването на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Проверете дали SNMP е активиран с помощта на командата show snmp. Ако не е разрешено, конфигурирайте командата “snmp-server manager”.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Изтеглете DS 65221, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
SIP ненормално откриване на прекъсване на повикване с имейл и Syslog Notification.
Копирайте DS XML файла в локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Инсталирайте DS XML файла в локалния шлюз.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични сигнатури за отстраняване на проблем
Диагностичните подписи (DS) също могат да се използват за бързо разрешаване на проблеми. Инженерите на Cisco TAC са създали няколко сигнатури, които позволяват необходимите отстраняване на грешки, необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC. Това елиминира необходимостта от ръчна проверка за възникване на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно разрешаване на даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример как да намерите и инсталирате DS за откриване на събитието „%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте допълнителна променлива на средата на DS ds_fsurl_prefix, която е пътя на файловия сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е означението за качване на файл, което може да бъде извлечено от Support Case Manager със следната команда. Означението за качване на файл може да бъде генерирано в секцията Прикачени файлове на Мениджъра на случаи за поддръжка, ако е необходимо.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Пример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Уверете се, че SNMP е активиран, като използвате командата show snmp. Ако не е разрешено, конфигурирайте командата “snmp-server manager”.
show snmp %SNMP agent not enabled config t snmp-server manager end
Уверете се, че сте инсталирали DS 64224 за високо наблюдение на процесора като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо натоварване на процесора. Изтеглете DS 64224, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
Високо използване на процесора с известие по имейл.
Изтеглете DS 65095, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Syslogs
Тип проблем
Syslog - %VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на пик на повикване): IEC=1.1.181.1.29.0
Копирайте DS XML файловете в локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Инсталирайте DS 64224 DS 64224 и след това DS 65095 XML файла за наблюдение на високо процесора в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Изтеглени DSes:
DS ID
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверете изпълнението на диагностичните подписи
В следващата команда колоната „Статус“ на командата show call-home diagnostic-signature се променя на „running“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Резултатът от показване на статистически данни за диагностичен подпис за повикване вкъщи е най-добрият начин да проверите дали диагностичен подпис открива интересно събитие и да изпълните действието. Колоната „Triggered/Max/Deinstall“ показва колко пъти даден подпис е задействал събитие, максималния брой пъти, когато е дефинирано да открие събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Изтеглени DSes:
DS ID |
Име на DS |
Ревизия |
Статус |
Последна актуализация (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
показване на статистически данни за диагностичен подпис при повикване вкъщи
DS ID |
Име на DS |
Задействано/Макс./Деинсталиране |
Средно време на работа (секунди) |
Максимално време на работа (секунди) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/N |
0,000 |
0,000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
20 1 г |
23,053 |
23,053 |
Имейлът за известяване, който се изпраща по време на изпълнение на диагностичен подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуера, работеща конфигурация и показва изходни данни на командата, които са подходящи за отстраняване на даден проблем.
Деинсталиране на диагностични подписи
Диагностичните сигнатури, които се използват за целите на отстраняване на неизправности, обикновено се дефинират за деинсталиране след откриване на определен брой възникнали проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на show call-home diagnostic-signature и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID>
Пример:
call-home diagnostic-signature deinstall 64224
Нови сигнатури се добавят периодично към инструмента за търсене на сигнатури за диагностика въз основа на проблеми, които често се наблюдават при внедрявания. Понастоящем TAC не поддържа заявки за създаване на нови персонализирани подписи. |
Преди да започнете
Уверете се, че следната базова конфигурация на платформата, която конфигурирате, е настроена в съответствие с правилата и процедурите на вашата организация:
НТП
ACL
активиране на пароли
основна парола
IP маршрутизиране
IP адреси и т.н
Имате нужда от минимално поддържано издание на IOS XE 17.6 за всички внедрявания на локален шлюз.
1 | Уверете се, че присвоявате валидни и маршрутизиращи IP адреси на всички интерфейси на ниво 3:
|
||||
2 | Трябва предварително да конфигурирате първичен ключ за паролата със следните команди, преди да се използва като идентификационни данни и споделени тайни. Паролите тип 6 са криптирани с помощта на AES шифър и дефиниран от потребителя първичен ключ.
|
||||
3 | Конфигурирайте IP Name Server, за да активирате DNS търсене. Изпратете ping на IP сървъра за имена и се уверете, че сървърът е достъпен. Локалният шлюз трябва да разреши Webex Calling прокси адреси с помощта на този DNS:
|
||||
4 | Активиране на TLS 1.2 Exclusivity и заместител по подразбиране Trustpoint:
|
||||
5 | Ако основният сертификат има междинен CA, тогава изпълнете следните команди:
|
||||
6 | Създайте точка на доверие, която да държи основния сертификат. (Изпълнете следните команди, ако няма междинен CA.)
|
||||
7 | Конфигурирайте SIP-UA да използва създадената от вас точка за доверие.
|
Преди да започнете
Мрежата към Webex Calling трябва да използва обществен IPv4 адрес. Пълно квалифицирани имена на домейни (FQDN) или адреси на служебни записи (SRV) трябва да се преобразуват в публичен IPv4 адрес в интернет.
Всички SIP и медийни портове на външния интерфейс трябва да са достъпни от интернет. Портовете не трябва да са зад преобразуване на мрежови адреси (NAT). Уверете се, че актуализирате защитната стена на мрежовите компоненти на вашето предприятие.
Инсталирайте подписан сертификат на локалния шлюз.
Сертификатът трябва да бъде подписан от CA, както е посочено в Кои главни сертифициращи органи се поддържат за повиквания към аудио и видео платформи на Cisco Webex? .
FQDN, избрано от контролния център, трябва да бъде общото име (CN) или алтернативното име на субект (SAN) на сертификата. Например:
Ако канал, конфигуриран от контролния център на вашата организация, има london.lgw.cisco.com:5061 като FQDN на локалния шлюз, тогава CN или SAN трябва да съдържат london.lgw.cisco.com в сертификата.
Ако канал, конфигуриран от контролния център на вашата организация, има london.lgw.cisco.com като SRV адрес на локалния шлюз, тогава CN или SAN трябва да съдържат london.lgw.cisco.com в сертификата. Записите, към които адресът SRV разрешава (CNAME, запис или IP адрес), не са задължителни в SAN.
В примера за FQDN или SRV, който се използва за вашата съединителна линия, адресът за контакт за всички нови SIP диалогови прозорци от вашия локален шлюз трябва да има london.lgw.cisco.com в частта за хост на SIP адреса. Вижте Стъпка 5 за конфигуриране.
Уверете се, че сертификатите са подписани за използване от клиент и сървър.
Трябва да качите доверителния пакет в локалния шлюз, както е посочено в Кои главни сертифициращи органи се поддържат за повиквания към аудио и видео платформи на Cisco Webex?.
1 | Въведете следните команди, за да включите приложението Local Gateway (вижте Референтна информация за портове за Cisco Webex Calling за най-новите IP подмрежи, които да добавите като доверен списък):
Ето обяснение на полетата за конфигурацията:
|
||
2 | Конфигурирайте "гласов клас кодек 100."
Ето обяснение на полетата за конфигурацията: Гласов клас кодек 100 Позволява opus и двата g711 (mu и a-law) кодеци за сесии. Прилага предпочитания кодек към всички точки за набиране. Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3562947976 за повече информация. |
||
3 | Конфигурирайте "гласов клас stun-usage 100", за да активирате ICE.
Ето обяснение на полетата за конфигурацията: Гласов клас stun-usage 100 Определя използването на зашеметяване. Прилага зашеметяване към всички точки за набиране, обърнати към Webex Calling, за да избегне по никакъв начин звук, когато Unified CM телефон пренасочва повикването към друг телефон Webex Calling. Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v2.html#wp1961799183 за повече информация. |
||
4 | Конфигурирайте "гласов клас srtp-crypto 100", за да ограничите поддържаното крипто.
Ето обяснение на полетата за конфигурацията: Гласов клас srtp-crypto 100Указва SHA1_80 като единствения пакет за шифроване на SRTP, който се предлага от локален шлюз в SDP в оферта и отговор. Webex Calling поддържа само SHA1_80.
Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp1731779246 за повече информация.
|
||
5 | Конфигурирайте „SIP профили 100“. В примера cube1.abc.lgwtrunking.com е избраното FQDN за локалния шлюз и „172.xxx“ е IP адресът на интерфейса на локалния шлюз, който е към Webex Calling:
Ето обяснение на полетата за конфигурацията:
|
||
6 | Конфигурирайте следните четири изходящи точки за набиране: |
||
7 | Създайте група за набиране въз основа на точката за набиране към Webex Calling в модела активен/активен.
Ето обяснение на полетата за конфигурацията:
Свързва изходяща точка за набиране с група точки за набиране 100 и конфигурира точка за набиране 101, 102, 103 и 104 със същото предпочитание. Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624 за повече информация. |
||
8 | Създайте група за набиране въз основа на точката за набиране към Webex Calling в основния/резервен модел.
Ето обяснение на полетата за конфигурацията:
Свързва изходяща точка за набиране с група точки за набиране 100 и конфигурира точка за набиране 101 и 102 като първо предпочитание. Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940 за повече информация.
Свързва изходяща точка за набиране с групата точка за набиране 100и конфигурира точка за набиране 103 и 104 като второ предпочитание. Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940 за повече информация. |
||
9 | Конфигурирайте входяща точка за набиране от Webex Calling. Входящото съвпадение се основава на uri заявката.
Ето обяснение на полетата за конфигурацията:
|
Това внедряване изисква следната конфигурация на локалния шлюз:
URI адреси на гласови класове—Можете да дефинирате модели на IP адреси/портове на хостове за различни връзки, завършващи на локален шлюз:
Webex Calling към LGW
PSTN SIP магистрален край на LGW
Изходящи точки за набиране—Можете да насочвате крака на изходящо повикване от LGW към SIP магистрала на доставчик на интернет телефонни услуги (ITSP) и Webex Calling.
Гласов клас DPG – Можете да извикате за насочване към изходящи точки за набиране от входяща точка за набиране.
Входящи точки за набиране—Можете да приемате крака на входящо повикване от ITSP и Webex Calling.
Използвайте конфигурацията или за настройка на локален шлюз, хостван от партньор, или за локален шлюз на клиентски сайт. Вижте следното:
1 | Конфигурирайте следния uri адрес на гласов клас: |
2 | Конфигурирайте следните изходящи точки за набиране: |
3 | Конфигурирайте следната група за набиране (dpg): |
4 | Конфигурирайте следните входящи точки за набиране: |
- PSTN към Webex Calling:
-
Съпоставете всички входящи крака на IP PSTN повикване на локалния шлюз с точка за набиране 122, за да определите критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Dpg 100 извиква изходяща точка за набиране 101,102,103,104, която има Webex Calling сървър като целева дестинация.
- Webex Обаждания към PSTN:
-
Съпоставете всички входящи крака на повикване Webex Calling на локалния шлюз с точка за набиране 110, за да определите критерия за съвпадение за модела на заглавката на REQUEST URI с името на хоста на локалния шлюз, уникален за локалния шлюз разгръщане. Dpg 120 извиква изходяща точка за набиране 121, която има IP PSTN IP адреса като целева дестинация.
Това внедряване изисква следната конфигурация на локалния шлюз:
URI адреси на гласови класове—Можете да дефинирате модели на IP адреси/портове на хостове за различни връзки, завършващи на LGW от:
Унифициран CM към LGW за PSTN дестинации
Унифициран CM към LGW за дестинации на Webex Calling
Webex Calling до LGW дестинации
PSTN SIP магистрален край на LGW дестинации
Сървърна група от гласов клас – Можете да насочвате IP адреси или портове за изходящи канали от:
LGW към Unified CM
LGW към Webex Calling
LGW към PSTN SIP магистрала
Изходящи точки за набиране – Можете да маршрутизирате крака на изходящо повикване от:
LGW към Unified CM
SIP магистрала на доставчик на интернет телефонни услуги (ITSP).
Webex Calling
Гласов клас dpg – Можете да се насочите към извикване на изходящи точки за набиране от входяща точка за набиране.
Входящи точки за набиране – Можете да приемате крака на входящо повикване от Unified CM, ITSP и Webex Calling.
1 | Конфигурирайте следните URI адреси на гласови класове: |
2 | Конфигурирайте следните гласови клас сървърни групи: |
3 | Конфигурирайте следните изходящи точки за набиране: |
4 | Конфигурирайте следната група за набиране (DPG): |
5 | Конфигурирайте следните входящи точки за набиране: |
Diagnostic Signatures (DS) проактивно открива често наблюдавани проблеми в базирания на Cisco IOS XE локален шлюз и генерира известие по имейл, системен журнал или терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни към кутията на Cisco TAC, за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Логиката за откриване на проблеми се дефинира с помощта на syslog съобщения, SNMP събития и чрез периодично наблюдение на специфични изходни данни на командата show. Типовете действия включват събиране на изходни данни от командата show, генериране на консолидиран лог файл и качване на файла в мрежово местоположение, предоставено от потребителя, като HTTPS, SCP, FTP сървър. DS файловете са създадени от инженери на TAC и са цифрово подписани за защита на целостта. Всеки DS файл има уникален цифров идентификатор, зададен от системата. Инструментът за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които модифицирате, не успяват да се инсталират поради грешка при проверка на целостта.
Сървър на Simple Mail Transfer Protocol (SMTP), от който се нуждаете, за да може локалният шлюз да изпраща известия по имейл.
Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако желаете да използвате защитен SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз с IOS XE 17.6.1 или по-нова версия
Диагностичните подписи са активирани по подразбиране.
Конфигурирайте защитения имейл сървър, който използвате за изпращане на проактивно известие, ако устройството работи с IOS XE 17.6.1 или по-нова версия.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Конфигурирайте променливата на средата ds_email с имейл адреса на администратора, когото да уведомите.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Локален шлюз с версия 17.6.1
Въведете следните команди, за да активирате диагностичните подписи.
configure terminal call-home reporting contact-email-addr sch-smart-licensing@cisco.com end
Конфигурирайте имейл сървъра, който да се използва за изпращане на проактивни известия, ако устройството работи с версия, по-стара от 17.6.1.
configure terminal call-home mail-server <email server> priority 1 end
Конфигурирайте променливата на средата ds_email с имейл адреса на администратора, който уведомявате.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1, за изпращане на проактивни известия до tacfaststart@gmail.com с помощта на Gmail като защитен SMTP сървър:
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Локалният шлюз, работещ на софтуера Cisco IOS XE, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на Gmail акаунт и да предоставим конкретно разрешение, за да се обработва правилно имейлът от устройството: |
Отидете на Достъп до по-малко защитено приложение.
и включете настройкатаОтговорете „Да, бях аз“, когато получите имейл от Gmail, в който се казва „Google попречи на някого да влезе в акаунта ви чрез приложение, което не е на Google“.
Инсталирайте диагностични сигнатури за проактивно наблюдение
Мониторинг на високо натоварване на процесора
Този DS проследява 5-секундното използване на процесора, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички отстраняване на грешки и деинсталира всички диагностични подписи, които инсталирате в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Уверете се, че SNMP е активиран, като използвате командата show snmp. Ако не активирате, конфигурирайте командата „snmp-server manager“.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Изтеглете DS 64224, като използвате следните падащи опции в Инструмент за търсене на диагностични подписи:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
Високо използване на процесора с известие по имейл.
Копирайте DS XML файла във флаш локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
Инсталирайте DS XML файла в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com
Изтеглете DSes:
DS ID
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, моля, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на процесора на локалния шлюз.
Мониторинг на необичайни прекъсвания на повикване
Този DS използва SNMP запитване на всеки 10 минути, за да открие необичайно прекъсване на връзката с SIP грешки 403, 488 и 503. Ако нарастването на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Проверете дали SNMP е активиран с помощта на командата show snmp. Ако не е разрешено, конфигурирайте командата “snmp-server manager”.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Изтеглете DS 65221, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
SIP ненормално откриване на прекъсване на повикване с имейл и Syslog Notification.
Копирайте DS XML файла в локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Инсталирайте DS XML файла в локалния шлюз.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични сигнатури за отстраняване на проблем
Диагностичните подписи (DS) също могат да се използват за бързо разрешаване на проблеми. Инженерите на Cisco TAC са създали няколко сигнатури, които позволяват необходимите отстраняване на грешки, необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC. Това елиминира необходимостта от ръчна проверка за възникване на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример как да намерите и инсталирате DS за откриване на събитието „%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте допълнителна променлива на средата на DS ds_fsurl_prefix, която е пътя на файловия сървър на CiscoTAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е означението за качване на файл, което може да бъде извлечено от Support Case Manager, както е показано по-долу. Означението за качване на файл може да бъде генерирано в секцията Прикачени файлове на Мениджъра на заявки за поддръжка, ако е необходимо.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Пример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Уверете се, че SNMP е активиран, като използвате командата show snmp. Ако не е разрешено, конфигурирайте командата “snmp-server manager”.
show snmp %SNMP agent not enabled config t snmp-server manager end
Препоръчваме да инсталирате DS 64224 за високо наблюдение на процесора като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо натоварване на процесора. Изтеглете DS 64224, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Производителност
Тип проблем
Високо използване на процесора с известие по имейл.
Изтеглете DS 65095, като използвате следните опции в Инструмента за търсене на диагностични подписи:
Име на полето
Стойност на полето
Платформа
Серия Cisco 4300, 4400 ISR или серия Cisco CSR 1000V
Продукт
CUBE Enterprise в решението за обаждания Webex
Обхват на проблема
Syslogs
Тип проблем
Syslog - %VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на пик на повикване): IEC=1.1.181.1.29.0
Копирайте DS XML файловете в локалния шлюз.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Инсталирайте DS 64224 DS 64224 и след това DS 65095 XML файла за наблюдение на високо процесора в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
Уверете се, че подписът е инсталиран успешно, като използвате show call-home diagnostic-signature. Колоната за състояние трябва да има „регистрирана“ стойност.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Изтеглени DSes:
DS ID
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Регистриран
2020-11-08:00:12:53
Проверете изпълнението на диагностичните подписи
В следващата команда колоната „Статус“ на командата show call-home diagnostic-signature се променя на „running“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Резултатът от показване на статистически данни за диагностичен подпис за повикване вкъщи е най-добрият начин да проверите дали диагностичен подпис открива интересно събитие и е изпълнил действието. Колоната „Triggered/Max/Deinstall“ показва колко пъти даден подпис е задействал събитие, максималния брой пъти, когато е дефинирано да открие събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Изтеглени DSes:
DS ID |
Име на DS |
Ревизия |
Статус |
Последна актуализация (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
показване на статистически данни за диагностичен подпис при повикване вкъщи
DS ID |
Име на DS |
Задействано/Макс./Деинсталиране |
Средно време на работа (секунди) |
Максимално време на работа (секунди) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/N |
0,000 |
0,000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
20 1 г |
23,053 |
23,053 |
Имейлът с известие, изпратен по време на изпълнение на диагностичния подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуера, работеща конфигурация и показване на изходни данни на командата, които са подходящи за отстраняване на даден проблем.

Деинсталиране на диагностични подписи
Използването на диагностичните сигнатури за целите на отстраняване на неизправности обикновено се дефинира за деинсталиране след откриване на определен брой възникнали проблеми. Ако желаете да деинсталирате подпис ръчно, извлечете DS ID от изхода на show call-home diagnostic-signature и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID>
Пример:
call-home diagnostic-signature deinstall 64224
Нови сигнатури се добавят периодично към инструмента за търсене на сигнатури за диагностика въз основа на проблеми, които често се наблюдават при внедрявания. Понастоящем TAC не поддържа заявки за създаване на нови персонализирани подписи. |
Local Gateway (LGW) е единственият вариант за предоставяне на помещения базирани PSTN достъп за Cisco Webex Calling клиенти. Целта на този документ е да Ви съдейства при изграждането на конфигурация на Local Gateway с помощта на CUBE висока наличност, активни/в режим на готовност Кубове за състояние отказ на активни повиквания.
Основите
Предварителни изисквания
Преди да разположите CUBE HA като локален шлюз за Webex Calling, уверете се, че имате задълбочено разбиране на следните понятия:
Layer 2 кутия-към-кутия съкращения с CUBE Enterprise за състояние запазване на повиквания
Указанията за конфигуриране, предоставени в тази статия, предполагат специализирана платформа за локален шлюз без съществуваща гласова конфигурация. Ако съществуващо разполагане на ПРЕДПРИЯТИЕ CUBE се променя, за да се използва и функцията за локален шлюз за Cisco Webex Calling, обърнете голямо внимание на конфигурацията, приложена, за да се гарантира, че съществуващите потоци от обаждания и функционалности не са прекъснати и се уверете, че се придържате към изискванията за дизайн на CUBE HA.
Хардуерни и софтуерни компоненти
CUBE HA като локален шлюз изисква IOS-XE версия 16.12.2 или по-нова и платформа, на която се поддържат както CUBE HA, така и LGW функции.
Шоу командите и регистрационните файлове в тази статия се основават на минимално издание на софтуера на Cisco IOS-XE 16.12.2 внедрени на vCUBE (CSR1000v). |
Референтен материал
Ето някои подробни ръководства за конфигуриране на CUBE HA за различни платформи:
CSR 1000v (vCUBE)—https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco предпочитана архитектура за Cisco Webex призование—https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Преглед на решението за извикване на Webex
Cisco Webex Calling е предложение за сътрудничество, което осигурява мулти-наемат облак-базирана алтернатива на предварително PBX телефонна услуга с множество PSTN опции за клиенти.
Локалното разполагане на Gateway (представено по-долу) е във фокуса на тази статия. Местен шлюз (Помещения базирани PSTN) багажник в Webex Calling позволява свързаност към клиент собственост PSTN услуга. Той също така осигурява свързаност към атентален IP PBX разполагане като Cisco Unified CM. Цялата комуникация от и до облака е обезпечена с помощта на TLS транспорт за SIP и SRTP за медии.
Фигурата по-долу показва разполагане на Webex Calling без никакъв съществуващ IP PBX и е приложимо за разполагане на един или няколко сайта. Конфигурацията, очертана в тази статия, се основава на това разполагане.
Слой 2 Кутия към кутия Съкращения
CUBE HA слой 2 кутия към кутия уволнение използва протокола за инфраструктура на Групата за съкращения (RG) за формиране на активна / в режим на готовност двойка рутери. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните им интерфейси и непрекъснато обменят съобщения за състоянието. CUBE сесия информация е чек-посочи в двойката рутери, даващи възможност на рутера в режим на готовност да вземе всички cube повикване обработка отговорности над веднага, ако активният рутер излиза от експлоатация, което води до състояние запазване на сигнализация и медии.
Посочването на проверка е ограничено до свързани повиквания с мултимедийни пакети. Повикванията при транзит не се проверяват заострени (например състояние на опитване или звънене). В тази статия CUBE HA ще се отнася до CUBE висока наличност (HA) слой 2 Кутия към кутия (B2B) съкращения за състояние запазване на повиквания |
Считано от IOS-XE 16.12.2, CUBE HA може да се разположи като Локален шлюз за Cisco Webex Calling trunk (Premises-based PSTN) разполагания и ще покрием съображения и конфигурации на дизайна в тази статия. Тази фигура показва типичен КУБ HA настройка като Локален шлюз за Cisco Webex Calling багажник разполагане.
Редунданси Група Infra компонент
Компонентът Infra на Групата за съкращения (RG) осигурява подкрепата за комуникационната инфраструктура "кутия към кутия" между двете Кубове и договаря окончателното стабилно състояние на съкращения. Този компонент също така предоставя:
Протокол, подобен на HSRP, който договаря окончателното състояние на съкращения за всеки рутер чрез обмен на keepalive и hello съобщения между двете Кубове (чрез контролния интерфейс)—GigabitEthernet3 на фигурата по-горе.
Транспортен механизъм за контролно определяне на сигнализирането и медийното състояние за всяко обаждане от активния към маршрутизатора за готовност (чрез интерфейса за данни)—GigabitEthernet3 на фигурата по-горе.
Конфигуриране и управление на интерфейса virtual IP (VIP) за интерфейсите за трафик (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран да поддържа глас B2B HA.
Управление на виртуален IP (VIP) адрес както за сигнализация, така и за медии
B2B HA разчита на VIP, за да постигне съкращения. VIP и свързаните физически интерфейси и на двата Кубчета в двойката CUBE HA трябва да пребивават на една и съща LAN подмрежа. Конфигурацията на VIP и свързването на VIP интерфейса с определено гласово приложение (SIP) са задължителни за гласова B2B HA поддръжка. Външни устройства като Унифициран CM, Webex Calling access SBC, доставчик на услуги или прокси, използват VIP като ip адрес местоназначение за разговорите, превъртащи през рутерите CUBE HA. Оттук от гледна точка на Webex Calling двойките CUBE HA действат като един-единствен местен шлюз.
Сигналната информация за повикванията и RTP сесийната информация на установените повиквания се проверяват от активния маршрутизатор към маршрутизатора за готовност. Когато Рутерът Active слиза надолу, маршрутизаторът Standby поема и продължава да препраща RTP потока, който преди това е бил насочван от първия рутер.
Обажданията в преходно състояние в момента на отказ няма да бъдат запазени след превключването. Например обажданията, които все още не са напълно установени или са в процес на промяна с функция за прехвърляне или задържане. Установените обаждания могат да бъдат прекъснати след превключването.
Следните изисквания съществуват за използване на CUBE HA като локален шлюз за състояние отказ на повиквания:
CUBE HA не може да има TDM или аналогови интерфейси съвместно разположени
Gig1 и Gig2 са наричани интерфейси трафик (SIP/RTP) и Gig3 е Redundancy Group (RG) Контрол/интерфейс за данни
Не повече от 2 CUBE HA двойки могат да бъдат поставени в един и същ слой 2 домейн, един с група ID 1, а другият с група ID 2. Ако конфигурирането на 2 HA двойки със същия ид на група, интерфейсите RG Control/Data трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
Порт канал се поддържа както за RG Control/ данни и трафик интерфейси
Всички сигнализация/носители се произхождат от/към Виртуалния IP адрес
По всяко време платформа е презаредена в CUBE-HA връзка, тя винаги ботуши нагоре като Standby
По-нисък адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
Redundancy Интерфейс Идентификатор, rii трябва да бъде уникален за двойка / интерфейс комбинация на същия Слой 2
Конфигурация на двете Кубове трябва да бъде идентичен включително физическа конфигурация и трябва да се изпълнява на един и същ тип платформа и IOS-XE версия
Интерфейсите за loopback не могат да се използват толкова обвързващи, колкото винаги са нагоре
Няколко интерфейса на трафика (SIP/RTP) (Gig1, Gig2) изискват проследяването на интерфейса да бъде конфигурирано
CUBE-HA не се поддържа през кръстосване кабелна връзка за връзката RG-контрол/данни (Gig3)
И двете платформи трябва да бъдат идентични и да бъдат свързани чрез физически Превключвател във всички по същия начин интерфейси, за да работи CUBE HA, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да се прекрати на един и същ превключвател и така нататък.
Не може WAN да е прекратено на CUBEs директно или Data HA от двете страни
И двете Активни/В режим на готовност трябва да са в един и същ център за данни
Задължително е да се използва отделен L3 интерфейс за съкращения (RG Control/data, Gig3). т.е интерфейс, използван за трафик, не може да се използва за ha keepalives и контролно-пропускателен пункт
При отказ преди това активният КУБ преминава през презареждане по дизайн, запазвайки сигнализацията и носителя
Конфигуриране на съкращаване на двете кубове
Трябва да конфигурирате layer 2 кутия-към-кутия уволнение на двете CUBEs, предназначени да бъдат използвани в HA двойка, за да изведе виртуални IPs.
1 | Конфигуриране на проследяване на интерфейс на глобално ниво за проследяване на състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса за гласово движение, така че активният маршрут да доста активната си роля, след като интерфейсът на трафика е надолу. |
||||||
2 | Конфигуриране на RG за използване с VoIP HA под режим на съкращения на приложението.
Ето обяснение на полетата, използвани в тази конфигурация:
|
||||||
3 | Разрешаване на съкращаване от кутия към кутия за приложението CUBE. Конфигуриране на RG от предишната стъпка под
съкращения-група 1—Добавяне и премахване на тази команда изисква презареждане за актуализираната конфигурация да влезе в сила. Ще презаредим платформите, след като цялата конфигурация е приложена. |
||||||
4 | Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IPs, както е показано по-долу, и прилагайте идентификатора на интерфейса за съкращения (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
|