- Начало
- /
- Статия
Работен поток за конфигуриране на извикване на Webex
В тази статияОриентирайте се с цялата налична информация за Webex Calling, независимо дали сте партньор, администратор или потребител. Използвайте предоставените тук връзки, за да ви помогнем да започнете да използвате всички услуги и функции, налични с Webex Calling.
Изисквания за локален шлюз за Webex Calling
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling , уверете се, че:
Имат основни познания за принципите на VoIP
Имате основни работни познания за гласовите концепции на Cisco IOS-XE и IOS-XE
Имайте основно разбиране за Session Initiation Protocol (SIP)
Имайте основно разбиране за Cisco Unified Communications Manager (Unified CM), ако вашият модел за разгръщане включва Unified CM
Вижте Ръководство за корпоративна конфигурация на Cisco Unified Border Element (CUBE). за подробности.
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че вашето внедряване има един или повече от локалните шлюзове (Cisco CUBE (за IP-базирана свързаност) или Cisco IOS Gateway (за TDM-базирана свързаност)), които са в Таблица 1 на Локален шлюз за Webex Calling Ръководство за поръчка на обаждания . Освен това се уверете, че платформата работи с поддържана версия на IOS-XE съгласно Ръководство за конфигуриране на локален шлюз .
Лицензионни изисквания за локални шлюзове
Лицензите за извикване на CUBE трябва да бъдат инсталирани на локален шлюз. За повече информация вижте Ръководство за конфигуриране на Cisco Unified Border Element .
Изисквания за сертификат и сигурност за локален шлюз
Webex Calling изисква сигурна сигнализация и медии. локален шлюз извършва криптирането и TLS връзка трябва да се установи изходяща към облака със следните стъпки:
LGW трябва да бъде актуализиран с CA root bundle от Cisco PKI
Набор от идентификационни данни за SIP дайджест от конфигурационна страница за конфигурация на Trunk на Control Hub се използва за конфигуриране на LGW (стъпките са част от конфигурацията, която следва)
Корен пакет на CA валидира представения сертификат
Подканени за идентификационни данни (предоставен е SIP обобщение)
Облакът идентифицира кой локален шлюз е сигурно регистриран
Изисквания за защитна стена, NAT обход и оптимизация на медийния път за локален шлюз
В повечето случаи локален шлюз и крайните точки могат да се намират във вътрешната клиентска мрежа, като използват частни IP адреси с NAT. Корпоративната защитна стена трябва да позволява изходящ трафик (SIP, RTP/ UDP, HTTP) към конкретни IP адреси/портове, обхванати в Референтна информация за порта .
Ако искате да използвате оптимизация на медийния път с ICE, интерфейсът за Webex Calling на Webex на локалния шлюз трябва да има директен мрежов път към и от крайните точки на Webex Calling . Ако крайните точки са на различно място и няма директен мрежов път между крайните точки и интерфейса за Webex Calling на локалния шлюз, тогава локален шлюз трябва да има публичен IP адрес , присвоен на интерфейса, обърнат към Webex Calling за повиквания между локален шлюз и крайните точки за използване на оптимизация на медийния път. Освен това трябва да работи с IOS-XE версия 16.12.5.
Първата стъпка, за да получите своя Webex Calling услуги и стартиране е да завършите Помощник за първоначална настройка (FTSW). След като FTSW бъде завършен за първото ви местоположение, не е необходимо да се попълва за допълнителни местоположения.
| 1 | Щракнете върху Първи стъпки връзка в имейла за добре дошли, който получавате.
| ||
| 2 | Прегледайте и приемете условия за използване на услугата. | ||
| 3 | Прегледайте плана си и след това щракнете Започнете .
| ||
| 4 | Изберете държавата, към която вашият център за данни трябва да картографира, и въведете информацията за клиентски контакт с клиента и адреса на клиента. | ||
| 5 | Щракнете върху следващо: Местоположение по подразбиране . | ||
| 6 | Изберете от следните опции:
| ||
| 7 | Направете следните избори, за да приложите към това местоположение:
| ||
| 8 | Щракнете върху Напред. | ||
| 9 | Въведете наличен SIP адрес на Cisco Webex и щракнете Следваща и изберете Край . |
Преди да започнете
За да създадете ново местоположение, подгответе следната информация:
Адрес на местоположението
Желани телефонни номера (по избор)
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на .
| ||||
| 2 | Конфигурирайте настройките на местоположението:
| ||||
| 3 | Щракнете върху Запазете и след това изберете да / не за добавяне на числа към местоположението сега или по-късно. | ||||
| 4 | Ако сте щракнали да , изберете една от следните опции:
Изборът на опция за PSTN е на всяко ниво на местоположение (всяко местоположение има само една опция PSTN). Можете да смесвате и съпоставяте толкова опции, колкото искате за внедряването си, но всяко местоположение ще има една опция. След като изберете и осигурите опция за PSTN, можете да я промените, като щракнете Управлявайте в местоположението PSTN свойства. Някои опции, като Cisco PSTN, обаче, може да не са налични, след като е назначена друга опция. Отворете заявка за случай на поддръжката за насоки. | ||||
| 5 | Изберете дали искате да активирате номерата сега или по-късно. | ||||
| 6 | Ако сте избрали неинтегрирана CCP или PSTN, базирана на помещения, въведете Телефонни номера като стойности, разделени със запетая, и след това щракнете Потвърди . Добавят се номера за конкретното местоположение. Валидни записи се преместват в Потвърдени номера полето и невалидни записи остават в Добавете числа поле, придружено от съобщение за грешка. В зависимост от държавата на местоположението, номерата се форматират според изискванията за местно набиране. Например, ако се изисква код на държавата, можете да въведете числа със или без кода и кодът се поставя преди. | ||||
| 7 | Щракнете върху Запиши. |
Какво да направите след това
След като създадете местоположение, можете да активирате спешни 911 услуги за това местоположение. Виж RedSky Emergency 911 Service за обаждания в Webex Calling за повече информация.
Преди да започнете
 | Вземете списък на потребителите и работните пространства, свързани с местоположение: Отидете на и от падащо меню изберете местоположението, което да бъде изтрито. Вие трябва изтрийте тези потребители и работни пространства, преди да изтриете местоположението. Имайте предвид, че всички номера, свързани с това местоположение, ще бъдат върнати обратно на вашия доставчик на PSTN; вече няма да притежавате тези номера. |
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . |
| 2 | Щракнете върху |
| 3 | Изберете Изтриване на местоположение и потвърдете, че искате да изтриете това местоположение. Обикновено отнема няколко минути, преди местоположението да бъде изтрито за постоянно, но може да отнеме до един час. Можете да проверите състоянието, като щракнете |
до името на местоположението и избораМожете да промените вашата PSTN настройка, името, часова зона и езика на местоположението, след като е създадено. Имайте предвид обаче, че новият език се прилага само за нови потребители и устройства. Съществуващите потребители и устройства продължават да използват стария език.
| За съществуващи местоположения можете да активирате спешни 911 услуги. Виж RedSky Emergency 911 Service за обаждания в Webex Calling за повече информация. |
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . Ако видите символ Внимание до местоположение, това означава, че все още не сте конфигурирали телефонен номер за това местоположение. Не можете да извършвате или да получавате повиквания, докато не конфигурирате този номер. | ||||||
| 2 | (По избор) Под PSTN връзка , изберете едно от двете Свързан с облак PSTN или Базирана в помещения PSTN (локален шлюз), в зависимост от това кой вече сте конфигурирали. Щракнете върху Управлявайте за да промените тази конфигурация и след това потвърдете свързаните рискове, като изберете Продължете . След това изберете една от следните опции и щракнете Запазете :
| ||||||
| 3 | Изберете Основен номер на който може да се достигне до основния контакт на местоположението. | ||||||
| 4 | (По избор) Под Спешно обаждане , можете да изберете Идентификатор на местоположение при спешни случаи да зададете на това местоположение.
| ||||||
| 5 | Изберете Номер на гласовата поща на които потребителите могат да се обаждат, за да проверят гласовата си поща за това местоположение. | ||||||
| 6 | (По избор) Щракнете върху иконата на молив в горната част на страницата Местоположение, за да промените Име на местоположението , Език за обявяване , Език на Имейл , Часова зона , или Адрес според нуждите и след това щракнете Запазете .
|
Тези настройки са за вътрешно набиране и са налични и в съветника за първа настройка. Когато промените своя план за набиране, примерните номера в Контролен център актуализирайте, за да покажете тези промени.
 | Можете да конфигурирате разрешения за изходящи повиквания за местоположение. Виж тези стъпки за да конфигурирате разрешения за изходящи повиквания. |
| 1 | Влезте в Контролен център , отидете на , а след това превъртете до Вътрешно набиране . | ||||||||
| 2 | Конфигурирайте следните незадължителни предпочитания за набиране, ако е необходимо:
| ||||||||
| 3 | Посочете вътрешно набиране за конкретни местоположения. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете вътрешното набиране, ако е необходимо:
| ||||||||
| 4 | Посочете външно набиране за конкретни местоположения. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете външното набиране, ако е необходимо:
Въздействие върху потребителите:
|
Ако сте дистрибутор с добавена стойност, можете да използвате тези стъпки, за да започнете конфигуриране на локален шлюз Контролен център . Когато този шлюз е регистриран в облака, можете да го използвате на един или повече от вашите Webex Calling местоположения за осигуряване на маршрутизиране към корпоративен доставчик на PSTN доставчик на услуги.
 | Местоположение, което има локален шлюз , не може да бъде изтрито, когато локален шлюз се използва за други местоположения. |
Преди да започнете
След като се добави местоположение и преди да конфигурирате базиран на помещения PSTN за местоположение, трябва да създадете магистрала.
Създайте всякакви местоположения и специфични настройки и номера за всяко от тях. Местоположенията трябва да съществуват, преди да можете да добавите PSTN, базиран на помещения.
Разберете изискванията за PSTN (локален шлюз), базиран на помещения Webex Calling .
Не можете да изберете повече от една магистрала за местоположение с базирана на помещения PSTN, но можете да изберете една и съща магистрала за множество местоположения.
| 1 | Влезте в Контролен център при , отидете на Услуги > Обаждане > Маршрутизиране на обажданията и изберете Добавяне на багажника .https://admin.webex.com | ||
| 2 | Изберете местоположение. | ||
| 3 | Дайте име на багажника и щракнете Запазете .
|
Какво да направите след това
Информацията за багажника се появява на екрана Регистрирайте домейн , Група магистрали OTG/DTG , Линия/Порт , и Изходящ прокси адрес .
Препоръчваме ви да копирате тази информация от Контролен център и го поставете в локален текстов файл или документ, за да можете да се обърнете към него, когато сте готови да конфигурирате базирания на помещения PSTN.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за багажника Контролен център . Щракнете върху Извличане на потребителско име и нулиране на парола за генериране на нов набор от идентификационни данни за използване в багажника.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . | ||
| 2 | Изберете местоположение за промяна и щракнете Управлявайте . | ||
| 3 | Изберете Базирана в помещения PSTN и щракнете Следваща . | ||
| 4 | Изберете багажник от падащо меню.
| ||
| 5 | Щракнете върху известието за потвърждение, след което щракнете Запазете . |
Какво да направите след това
Трябва да вземете информация за конфигуриране , която Контролен център генерира и картографира параметрите в локален шлюз (например на Cisco CUBE, който се намира в помещенията). Тази статия ви превежда през този процес. Като справка вижте следващата диаграма за пример как Контролен център информация за конфигуриране (вляво) се съпоставя с параметрите в CUBE (вдясно):
След като завършите успешно конфигурацията на самия шлюз, можете да се върнете към Услуги > Обадете се > Местоположения в Контролен център и създаденият от вас шлюз ще бъде посочен в картата за местоположение, към която сте го присвоили, със зелена точка вляво от името. Това състояние показва, че шлюзът е сигурно регистриран в облака за повикване и служи като активен шлюз за обществена телефонна централа за местоположението.
Можете лесно да преглеждате, активирате, премахвате и добавяте телефонни номера за вашата организация Контролен център . За повече информация вж Управлявайте телефонните номера в Control Hub .
Ако изпробвате услугите на Webex и искате да преобразувате пробната си версия в платен абонамент, можете да изпратите заявка по имейл до партньора си.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , изберете иконата на сграда |
| 2 | Изберете Абонаменти раздел и след това щракнете Купете сега . До партньора ви се изпраща имейл, уведомяващ го, че се интересувате от преминаване към платен абонамент. |
Можете да използвате Контролен център за да зададете приоритета на наличните опции за повикване, в които потребителите виждат Приложение Webex . Можете също да ги активирате за обаждане с едно щракване. За повече информация вижте: Задайте опции за повикване за потребители на Webex App .
Можете да контролирате какво приложение за повиквания се отваря, когато потребителите извършват обаждания. Можете да конфигурирате настройките на клиента за повикване, включително внедряване в смесен режим за организации с потребители, упълномощени с Unified CM или Webex Calling и потребители без платени услуги за разговори от Cisco. За повече информация вижте: Настройте поведение при повикване .
Общ преглед
В момента Webex Calling поддържа две версии на локален шлюз:
Локален шлюз
Локален шлюз за Webex за правителството
Преди да започнете, разберете изискванията на базираната в помещенията обществена комутирана телефонна мрежа (PSTN) и локалния шлюз (LGW) за обажданията чрез Webex Calling. Виж Предпочитана архитектура на Cisco за обаждания в Webex Calling за повече информация.
Тази статия предполага, че е създадена специална платформа за локален шлюз без съществуваща гласова конфигурация. Ако модифицирате съществуващ шлюз за обществена телефонна централа или внедряване на CUBE Enterprise, за да се използва като функция Local Gateway за Webex Calling, тогава обърнете внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци и функционалност на повикванията поради промените, които правите.
| Процедурите съдържат връзки към справочната документация на командите, където можете да научите повече за отделните опции на командите. Всички препратки към командите отиват към Справочник за команди за управлявани шлюзи на Webex освен ако не е посочено друго (в този случай командните връзки отиват до Справочник за гласови команди на Cisco IOS ). Можете да получите достъп до всички тези ръководства в Cisco Unified Border Element Препратки към команди . За информация относно поддържаните SBC на трети страни вижте съответната референтна документация на продукта. |
Има две опции за конфигуриране на локалния шлюз за вашия Webex Calling багажник:
Багажник на базата на регистрация
Багажник, базиран на сертификати
Използвайте потока на задачите или под Локален шлюз, базиран на регистрация или Базиран на сертификат локален шлюз за да конфигурирате локален шлюз за вашия Webex Calling багажника.
Виж Започнете с Local Gateway за повече информация относно различните типове багажници. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Ние използваме Session Initiation Protocol (SIP) и Защита на транспортния слой (TLS), за да защитим магистралата и защитен протокол в реално време (SRTP), за да защитим медиите между локалния шлюз и Webex Calling .
Изберете CUBE като ваш локален шлюз. Понастоящем Webex for Government не поддържа никакви гранични контролери на сесии (SBC) на трети страни. За да прегледате последния списък, вж Започнете с Local Gateway .
- Инсталирайте Cisco IOS XE Dublin 17.12.1a или по-нови версии за всички Webex за правителствени локални шлюзове.
За да прегледате списъка с основни сертифициращи органи (CA), които Webex поддържа за правителство, вж Коренни сертифициращи органи за Webex за правителство .
За подробности относно диапазоните на външни портове за локален шлюз в Webex за правителство, вж Мрежови изисквания за Webex за правителство (FedRAMP) .
Локален шлюз за Webex за правителството не поддържа следното:
STUN/ICE-Lite за оптимизиране на медийния път
факс (T.38)
За да конфигурирате локален шлюз за вашата линия за Webex Calling на Webex в Webex за правителство, използвайте следната опция:
Багажник, базиран на сертификати
Използвайте потока от задачи под Базиран на сертификат локален шлюз за да конфигурирате локалния шлюз за вашата линия за Webex Calling . За повече подробности как да конфигурирате базиран на сертификат локален шлюз, вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Задължително е да конфигурирате FIPS-съвместими GCM шифри, за да поддържате локален шлюз за Webex за правителство. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
| Webex за правителството не поддържа базиран на регистрация локален шлюз. |
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, като се използва регистриране на външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Изображението по-долу подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде следвана.
В този дизайн се използват следните основни конфигурации:
наематели на гласов клас : Използва се за създаване на специфични за багажника конфигурации.
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
Всички базирани на регистрация внедрявания на локален шлюз изискват Cisco IOS XE 17.6.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
NTP
ACL
Удостоверяване на потребителя и дистанционен достъп
DNS
IP маршрутизиране
IP адреси
Мрежата към Webex Calling трябва да използва IPv4 адрес.
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 | Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
| ||
| 2 | Защитете идентификационните данни за регистрация и STUN на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва:
| ||
| 3 | Създайте заместваща PKI точка на доверие.
| ||
| 4 | Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация. Транспортните параметри също трябва да бъдат актуализирани, за да се гарантира надеждна защитена връзка за регистрация:
| ||
| 5 | Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати:
|
| 1 | Създайте базирана на регистрация PSTN магистрала за съществуващо местоположение в Control Hub. Отбележете информацията за магистралата, която се предоставя след създаването на магистрала. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling . | ||||
| 2 | Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. медийна статистикаПозволява наблюдение на медиите на локалния шлюз. медийни масови статистикиПозволява на контролната равнина да анкетира равнината на данни за статистика за повикването. За повече информация относно тези команди вж Медия . разрешаване на връзки глътка до глъткаАктивирайте CUBE основната SIP функция на потребителски агент отзад до гръб. За повече информация вж Разрешаване на връзки .
Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . | ||||
| 3 | Конфигуриране кодек за гласов клас 100 филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вижте кодекза гласов клас.
| ||||
| 4 | Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . Ето обяснение на полетата за конфигурацията: зашеметяване използване лед лайтИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite .
| ||||
| 5 | Конфигурирайте политиката за криптиране на медиите за трафика на Webex . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1 80_ За повече информация вж гласов клас srtp-crypto . | ||||
| 6 | Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на параметъра на неговата дестинационна магистрала: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте dtg=, последвано от стойността на Trunk OTG/DTG, предоставена в Control Hub при създаването на магистрала. За повече информация вж глас клас uri . | ||||
| 7 | Конфигуриране глътка профил 100 , който ще се използва за модифициране на SIP съобщения, преди да бъдат изпратени до Webex Calling.
Ето обяснение на полетата за конфигурацията:
| ||||
| 8 | Конфигуриране на магистрала за Webex Calling :
|
След като дефинирате наемател 100 и конфигуриране на SIP VoIP dial-peer, шлюзът инициира TLS връзка към Webex Calling. В този момент SBC за достъп представя своя сертификат на локалния шлюз. Локалният шлюз потвърждава сертификата за достъп на Webex Calling SBC, използвайки коренния пакет на CA, който беше актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп за Webex Calling . След това локалният шлюз може да използва тази защитена връзка , за да се регистрира в SBC за достъп на Webex . Когато регистрацията е оспорена за удостоверяване:
В потребителско име, парола, и царство параметри от пълномощията конфигурацията се използва в отговора.
Правилата за модификация в sip профил 100 се използват за преобразуване на SIPS URL обратно в SIP.
Регистрацията е успешна, когато се получи 200 ОК от SBC за достъп.
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
| Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE. |
| За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI . |
| 1 | Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 | Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 300 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Указва целевия IPv4 адрес на дестинацията за изпращане на етап на повикването. Целта на сесията тук е IP адрес на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Дефинира критерий за съответствие за VIA заглавката с IP адрес на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteДефинира RTP-NTE (RFC2833) като DTMF възможност, очаквана на етапа на етап на повикването. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 | Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| Когато създавате линията за Webex Calling в Unified CM, уверете се, че сте конфигурирали входящия порт в настройките на профил за защита на SIP линиите на 5065. Това позволява входящи съобщения на порт 5065 и попълване на VIA заглавката с тази стойност при изпращане на съобщения до локалния шлюз. |
| 1 | Конфигурирайте следните URI адреси на гласов клас: | ||
| 2 | Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове:
Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060 : Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com : Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com : Името на име на домакина за запис A. 192.168.80.65 : IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. | ||
| 3 | Конфигурирайте следните точки за набиране: | ||
| 4 | Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно открива често наблюдавани проблеми в базирания на IOS XE локален шлюз и генерира имейл, системен журнал или известие за терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития за задействане на проблем и действия, които трябва да се предприемат за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми, като използвате съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди show.
Типовете действия включват събиране на изходни команди show:
Генериране на консолидиран регистрационен файл
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър.
Инженерите на TAC създават DS файловете и ги подписват цифрово за защита на целостта. Всеки DS файл има уникален цифров ИД , присвоен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, от който изтегляте DSLT . Файловете, които променяте, се провалят при инсталиране поради грешка при проверка на целостта.
Сървър с прост протокол за прехвърляне на поща (SMTP), който ви е необходим, за да може локалният шлюз да изпраща известия по имейл.
Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако искате да използвате защитения SMTP сървър за имейл известия.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1a или по-нова версия
Диагностичните подписи са активирано по подразбиране.
Конфигурирайте защитения имейл сървър, който да се използва за изпращане на проактивни известия, ако устройството работи с Cisco IOS XE 17.6.1a или по-нова версия.
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
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1a или по-нова версия за изпращане на проактивни известия до tacfaststart@gmail.com използване на Gmail като защитен SMTP сървър:
| Препоръчваме ви да използвате Cisco IOS XE Bengaluru 17.6.x или по-нови версии. |
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“.
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на висока натовареност на CPU
Този DS проследява използването на CPU за пет секунди, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички отстраняване на грешки и деинсталира всички диагностични подписи, които са инсталирани в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Използвайте покажи snmp команда за активиране на SNMP. Ако не активирате, конфигурирайте snmp-сървър мениджър команда.
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 Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Копирайте 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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
ДС_ LGW_ CPU_ ПН75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг на регистрацията на външна линия SIP
Този DS проверява за дерегистрация на локален шлюз SIP транк с облака за Webex Calling на всеки 60 секунди. След като се открие събитието за отписване, то генерира известие по имейл и системен журнал и се деинсталира след две поява на дерегистрация. Използвайте стъпките по-долу, за да инсталирате подписа:
Изтеглете DS 64117, като използвате следните падащи опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
SIP- SIP
Тип на проблема
Отмяна на регистрация на 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#Използвайте покажете диагностичен подпис за обаждане вкъщи команда, за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Мониторинг на необичайни прекъсвания на разговора
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Използвайте покажи snmp команда, за да проверите дали SNMP е активиран. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Откриване на необичайно прекъсване на връзката с SIP с Имейл и известие в системния журнал.
Копирайте 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Използвайте покажете диагностичен подпис за обаждане вкъщи команда, за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Използвайте диагностични подписи (DS) за бързо разрешаване на проблеми. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC . Диагностичните подписи (DS) премахват необходимостта от ръчна проверка за възникване на проблема и улесняват много по-лесно отстраняването на неизправности на периодични и преходни проблеми.
Можете да използвате Инструмент за търсене на диагностични подписи за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример за това как да намерите и инсталирате DS за откриване на появата „% VOICE_ IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте допълнителна променлива на средата на DSds_fsurl_prefix което е пътят на файлов сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка в следната команда. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, ако е необходимо.
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 е активиран с помощта на покажи snmp команда. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp %SNMP agent not enabled config t snmp-server manager endУверете се, че сте инсталирали High CPU Monitoring DS 64224 като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо използване на CPU . Изтеглете DS 64224, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Изтеглете DS 65095, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
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:Инсталирайте High CPU мониторинг 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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
ДС_ LGW_ CPU_ ПН75
0.0.10
Регистриран
2020-11-08
65095
00:12:53
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверете изпълнението на диагностичните подписи
В следващата команда колоната „Състояние“ на покажете диагностичен подпис за обаждане вкъщи командата се променя на „работеща“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът на показване на статистически данни за диагностика и подпис за обаждане до дома е най-добрият начин да проверите дали диагностичен подпис открива събитие от интерес и изпълнява действието. Колоната „Задействано/Макс./Деинсталиране“ показва колко пъти даденият подпис е задействал събитие, максимален брой пъти, когато е дефиниран за откриване на събитие и дали подписът се деинсталира сам след откриване на максимален брой задействани събития.
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 ИД | Име на DS | Ревизия | Статус | Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 | ДС_ LGW_ CPU_ ПН75 | 0.0.10 | Регистриран | 08.11.2020 00:07:45 |
65095 | ДС_ LGW_ IEC_ Вall_spike_threshold | 0.0.12 | Изпълнява се | 08.11.2020 00:12:53 |
показва статистически данни за диагностични подписи за обаждане до дома
DS ИД | Име на DS | Задейства се /Макс/Деинсталиране | Средно време на работа (секунди) | Максимално време на работа (секунди) |
|---|---|---|---|---|
| 64224 | ДС_ LGW_ CPU_ ПН75 | 0/0/N | 0,000 | 0,000 |
65095 | ДС_ LGW_ IEC_ Вall_spike_threshold | 1 /20/г | 23.053 | 23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнение на диагностичния подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуер, текуща конфигурация и показване на командни изходи, които са подходящи за отстраняване на даден проблем.
Деинсталирайте диагностичните подписи
Използване на диагностични подписи за целите на отстраняване на неизправности обикновено се деинсталират за деинсталиране след откриване на някои проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи команда и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID>
Пример:
call-home diagnostic-signature deinstall 64224
| Нови подписи се добавят периодично към инструмента за търсене на подписи за диагностика, въз основа на проблеми, които често се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови персонализирани подписи. |
За по-добро управление на Cisco IOS XE Gateways, препоръчваме ви да регистрирате и управлявате шлюзовете чрез Control Hub. Това е опция по избор. Когато се регистрирате, можете да използвате опцията за валидиране на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате всички проблеми с конфигурацията. Понастоящем тази функционалност поддържат само базирани на регистрация канали.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, използвайки базиран на сертификат взаимна TLS (mTLS) външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Следното изображение подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде последвана.
В този дизайн се използват следните основни конфигурации:
наематели на гласов клас : Използва се за създаване на специфични за багажника конфигурации.
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение. Предоставени са опции за публично или частно (зад NAT) адресиране. SRV DNS записите не са задължителни, освен ако не се балансиране на товара в множество екземпляри на CUBE.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
Всички базирани на сертификати локални внедрявания на шлюз изискват Cisco IOS XE 17.9.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Essentials. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
За изисквания за висок капацитет може също да изисквате лиценз за висока сигурност (HSEC) и допълнително право на пропускателна способност.
Отнесете се към Кодове за оторизация за повече подробности.
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
NTP
ACL
Удостоверяване на потребителя и дистанционен достъп
DNS
IP маршрутизиране
IP адреси
Мрежата към Webex Calling трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) на локалния шлюз или адресите на запис на услуги (SRV) трябва да се разрешават до публичен IPv4 адрес в интернет.
Всички SIP и медийни портове на интерфейса на локалния шлюз, обърнат към Webex , трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате съответно защитната си стена.
Инсталирайте подписан сертификат на локалния шлюз (по-долу са дадени подробни стъпки за конфигуриране).
Публичен орган за сертификати (CA), както е описано подробно в Какви основни центрове за сертифициране се поддържат за обаждания към аудио и видео платформи на Cisco Webex ? трябва да подпише сертификата на устройството.
FQDN , конфигуриран в Control Hub при създаване на магистрала, трябва да бъде сертификатът Common Name (CN) или Subject Alternate Name (SAN) на рутера. Например:
Ако конфигуриран транк в Control Hub на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на рутера трябва да съдържа cube1.lgw.com.
Ако конфигурирана магистрала в контролния център на вашата организация има lgws.lgw.com като SRV адрес на локалния(ите) шлюз(и), достъпен от магистралата, тогава CN или SAN в сертификата на рутера трябва да съдържа lgws.lgw.com. Записите, до които SRV адресът се разрешава (CNAME, A Record или IP адрес), са незадължителни в SAN.
Независимо дали използвате FQDN или SRV за магистрала, адресът за контакт за всички нови SIP диалогови прозорци от вашия локален шлюз използва името, конфигурирано в Control Hub.
Уверете се, че сертификатите са подписани за използване на клиент и сървър.
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 | Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
| ||
| 2 | Защитете STUN идентификационните данни на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва: | ||
| 3 | Създайте доверителна точка за криптиране със сертификат, подписан от предпочитания от вас орган за сертификати (CA). | ||
| 4 | Удостоверете новия си сертификат, като използвате вашия междинен (или основен) СА сертификат, след което импортирайте сертификата (Стъпка 4). Въведете следната команда exec или конфигурация:
| ||
| 5 | Импортирайте подписан сертификат за хост, като използвате следната команда exec или конфигурация:
| ||
| 6 | Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация:
| ||
| 7 | Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати:
|
| 1 | Създайте CUBE базирана на сертификат PSTN магистрала за съществуващо местоположение в Control Hub. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling .
| ||||
| 2 | Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. разрешаване на връзки глътка до глъткаАктивирайте CUBE основния SIP обратно към гръб функционалност на потребителския агент. За повече информация вж Разрешаване на връзки .
Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез dial-peers или наематели. | ||||
| 3 | Конфигуриране кодек за гласов клас 100 кодек филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вижте кодекза гласов клас.
| ||||
| 4 | Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: зашеметяване използване лед лайтИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite .
| ||||
| 5 | Конфигурирайте политиката за криптиране на медиите за трафика на Webex . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1 80_ За повече информация вж гласов клас srtp-crypto . | ||||
| 6 | Конфигуриране на FIPS-съвместими GCM шифри (Тази стъпка е приложима само за Webex for Government) . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Посочва GCM като шифров пакет, който CUBE предлага. Задължително е да конфигурирате GCM шифри за локален шлюз за Webex за правителство. | ||||
| 7 | Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на неговото FQDN или SRV местоназначение: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте LGW FQDN или SRV, конфигурирани в Control Hub, докато създавате магистрала. | ||||
| 8 | Конфигурирайте профили за манипулиране на SIP съобщение . Ако вашият шлюз е конфигуриран с публичен IP адрес, конфигурирайте профил по следния начин или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, а „198.51.100.1“ е публичният IP адрес на интерфейса на локалния шлюз пред Webex Calling: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства.
| ||||
| 9 | Ако вашият шлюз е конфигуриран с частен IP адрес зад статичен NAT, конфигурирайте входящи и изходящи SIP профили, както следва. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, „10.80.13.12“ е IP адрес на интерфейса, обърнат към Webex Calling , а „192.65.79.20“ е публичният IP адрес на NAT. SIP профили за изходящи съобщения към Webex Calling
Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. правила от 30 до 81Преобразувайте препратките към частни адреси към външния публичен адрес за сайта, позволявайки на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Преобразувайте препратките към публичния адрес в конфигурирания частен адрес, позволявайки на съобщенията от Webex да бъдат правилно обработвани от CUBE. За повече информация вж гласови класове sip-профили . | ||||
| 10 | Конфигурирайте SIP опции за поддържане на активност с профил за промяна на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-options-keepalive 100Конфигурира поддържащ профил и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което Ping за SIP извън диалоговите опции се изпраща до целта за набиране, когато връзката на сърдечния ритъм към крайната точка е в състояние UP или Down. Този поддържащ профил се задейства от точката за набиране, конфигурирана към Webex. За да се гарантира, че заглавките на контактите включват напълно квалифицирано име на домейн SBC, се използва SIP профил 115. Правила 30, 40 и 50 се изискват само когато SBC е конфигуриран зад статичен NAT. В този пример cube1.lgw.com е FQDN , избрано за локалния шлюз и ако се използва статичен NAT, „10.80.13.12“ е IP адрес на интерфейса на SBC към Webex Calling и „192.65.79.20“ е публичният IP адрес на NAT . | ||||
| 11 | Конфигуриране на магистрала за Webex Calling :
|
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
| Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE. |
| За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI . |
| 1 | Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 | Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 300 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Указва целевия IPv4 адрес на дестинацията за изпращане на етап на повикването. Целта на сесията тук е IP адрес на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Дефинира критерий за съответствие за VIA заглавката с IP адрес на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteДефинира RTP-NTE (RFC2833) като DTMF възможност, очаквана на етапа на етап на повикването. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 | Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| 1 | Конфигурирайте следните URI адреси на гласов клас: | ||
| 2 | Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове:
Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060 : Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com : Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com : Името на име на домакина за запис A. 192.168.80.65 : IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. | ||
| 3 | Конфигурирайте следните точки за набиране: | ||
| 4 | Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно открива често наблюдавани проблеми в базирания на Cisco IOS XE локален шлюз и генерира имейл, системен журнал или известие за терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития и действия за задействане на проблем за информиране, отстраняване на неизправности и отстраняване на проблема. Използвайте съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди за показване, за да дефинирате логиката за откриване на проблеми. Типовете действия включват:
Събиране на изходни команди show
Генериране на консолидиран регистрационен файл
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър
Инженерите на TAC създават DS файлове и ги подписват цифрово за защита на целостта. Всеки DS файл има уникалния цифров ИД , присвоен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, от който изтегляте DSLT . Файловете, които променяте, се провалят при инсталиране поради грешка при проверка на целостта.
Сървър с прост протокол за прехвърляне на поща (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
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на висока натовареност на CPU
Този DS проследява 5-секундно използване на CPU с помощта на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички отстраняване на грешки и деинсталира всички диагностични подписи, които инсталирате в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Уверете се, че сте активирали SNMP с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл
Копирайте 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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
ДС_ LGW_ CPU_ ПН75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, моля, инсталирайте отново DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг на необичайни прекъсвания на разговора
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Уверете се, че SNMP е активиран с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Откриване на необичайно прекъсване на връзката с SIP с Имейл и известие в системния журнал.
Копирайте 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Използвайте командата покажете диагностичен подпис за обаждане вкъщи за да проверите дали подписът е инсталиран успешно. Колоната за състоянието трябва да има „регистрирана“ стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Можете също да използвате диагностични подписи (DS) за бързо разрешаване на проблеми. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC . Това елиминира необходимостта от ръчна проверка за възникване на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате Инструмент за търсене на диагностични подписи за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример за това как да намерите и инсталирате DS за откриване на появата „% VOICE_ IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте друга променлива на средата на DSds_fsurl_prefix като пътя на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка както е показано по-долу. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, както е необходимо.
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 е активиран с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp %SNMP agent not enabled config t snmp-server manager endПрепоръчваме да инсталирате High CPU Monitoring DS 64224 като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо използване на CPU . Изтеглете DS 64224, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Изтеглете DS 65095, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
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 65095 XML файл за мониторинг на CPU в локалния шлюз.
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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
ДС_ LGW_ CPU_ ПН75
0.0.10
Регистриран
2020-11-08:00:07:45
65095
00:12:53
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08:00:12:53
Проверете изпълнението на диагностичните подписи
В следващата команда колоната „Състояние“ на командата покажете диагностичен подпис за обаждане вкъщи се променя на „изпълнение“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът на показване на статистически данни за диагностика и подпис за обаждане до дома е най-добрият начин да проверите дали диагностичен подпис открива събитие от интерес и е изпълнило действието. Колоната „Задействано/Макс./Деинсталиране“ показва колко пъти даденият подпис е задействал събитие, максимален брой пъти, когато е дефиниран за откриване на събитие и дали подписът се деинсталира сам след откриване на максимален брой задействани събития.
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 ИД | Име на DS | Ревизия | Статус | Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 | ДС_ LGW_ CPU_ ПН75 |
0.0.10 |
Регистриран |
08.11.2020 00:07:45 |
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
0.0.12 |
Изпълнява се |
08.11.2020 00:12:53 |
показва статистически данни за диагностични подписи за обаждане до дома
DS ИД | Име на DS | Задейства се /Макс/Деинсталиране | Средно време на работа (секунди) | Максимално време на работа (секунди) |
|---|---|---|---|---|
| 64224 | ДС_ LGW_ CPU_ ПН75 |
0/0/N |
0,000 |
0,000 |
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
1 /20/г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуер, текуща конфигурация и показване на командни изходи, които са подходящи за отстраняване на даден проблем.
Деинсталирайте диагностичните подписи
Използване на диагностичните сигнатури за целите на отстраняване на неизправности обикновено се деинсталират за деинсталиране след откриване на някои проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID> Пример:
call-home diagnostic-signature deinstall 64224
| Нови подписи се добавят периодично към инструмента за търсене на диагностични подписи въз основа на проблеми, които се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови персонализирани подписи. |
Основи
Предварителни изисквания
Преди да разположите CUBE HA като локален шлюз за Webex Calling, уверете се, че имате задълбочено разбиране на следните концепции:
Редундантност от кутия към кутия от слой 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 за различни платформи:
ISR 4K серия— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
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 Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Общ преглед на решението за Webex Calling
Cisco Webex Calling е предложение за сътрудничество, което предоставя базирана в облак алтернатива с множество наематели на телефонна услуга за локална телефонна централа с множество опции за PSTN за клиенти.
Разгръщането на локален шлюз (представено по-долу) е в центъра на тази статия. Транк на локалния шлюз (базиран на помещения 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 High Availability (HA) Layer 2 Box-to-box (B2B) резервиране за запазване на повикванията с състояние на състояние |
Считано от IOS-XE 16.12.2, CUBE HA може да бъде разгърнат като локален шлюз за внедряване на магистрала за Cisco Webex Calling (базирана на помещения PSTN) и ние ще съображения на дизайна в тази статия. Тази фигура показва типична настройка на CUBE HA като локален шлюз за разгръщане на магистрала на Cisco Webex Calling .
Инфракомпонент на групата за резервиране
Компонентът Infra за групата за резервиране (RG) осигурява поддръжката на комуникационната инфраструктура от кутия до кутия между двата CUBE и договаря окончателното стабилно състояние на резервиране. Този компонент също така осигурява:
Протокол, подобен на HSRP, който договаря крайното състояние на резервиране за всеки рутер чрез обмен на съобщения за поддържане на активност и hello между двата CUBE (чрез контролния интерфейс) – GigabitEthernet3 на фигурата по-горе.
Транспортен механизъм за контролна точка на състоянието на сигнализацията и медиите за всяко повикване от активния към резервния рутер (чрез интерфейса за данни) — GigabitEthernet3 на фигурата по-горе.
Конфигуриране и управление на интерфейса за виртуален IP (VIP) за интерфейсите за трафик (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран да поддържа гласова B2B HA.
Управление на виртуални IP (VIP) адреси както за сигнализация, така и за медии
B2B HA разчита на VIP за постигане на съкращения. VIP и свързаните физически интерфейси на двата CUBE в двойката CUBE HA трябва да се намират в една и съща LAN подмрежа. Конфигурирането на VIP и обвързването на VIP интерфейса към определено гласово приложение (SIP) са задължителни за гласова поддръжка на B2B HA. Външни устройства като Unified CM, Webex Calling access SBC, доставчик на услуги или прокси, използват VIP като IP адрес на дестинацията за повикванията, преминаващи през рутерите CUBE HA. Следователно, от гледна точка на Webex Calling , двойките CUBE HA действат като един локален шлюз.
Сигнализирането на повикванията и информацията за RTP сесията на установените повиквания са контролни точки от активния рутер към рутера в режим на готовност. Когато активният рутер изпадне, рутерът в режим на готовност поема управлението и продължава да препраща RTP поток , който преди това е бил насочен от първия рутер.
Обажданията в преходно състояние по време на отказ няма да бъдат запазени след превключване. Например повиквания, които все още не са напълно установени или са в процес на промяна с функция за прехвърляне или задържане. Установените повиквания могат да бъдат прекъснати след превключване.
Съществуват следните изисквания за използване на CUBE HA като локален шлюз за преодоляване на повиквания със състояние на отказ:
CUBE HA не може да има съвместно разположени TDM или аналогови интерфейси
Gig1 и Gig2 се наричат интерфейси за трафик (SIP/ RTP), а Gig3 е интерфейс за управление/данни на групата за резервиране (RG)
Не повече от 2 двойки CUBE HA могат да бъдат поставени в един и същ домейн на слой 2, единият с идентификатор на група 1, а другият с идентификатор на група 2. Ако конфигурирате 2 HA двойки със същия идентификатор на групата, интерфейсите за управление/данни на RG трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
Порт каналът се поддържа както за интерфейси за управление на RG/данни, така и за трафик
Цялата сигнализация/медия се доставя от/към виртуалния IP адрес
Всеки път, когато платформата се презареди в CUBE-HA връзка, тя винаги се зарежда като Standby
Долният адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
Идентификатор на интерфейса за излишък, rii трябва да е уникален за комбинация от двойка/интерфейс на същия слой 2
Конфигурацията и на двата CUBE трябва да бъде идентична, включително физическа конфигурация и трябва да работи на същия тип платформа и версия на IOS-XE
Интерфейсите за обратна връзка не могат да се използват като обвързване, тъй като винаги са нагоре
Множество интерфейси за трафик (SIP/ RTP) (Gig1, Gig2) изискват конфигуриране на проследяване на интерфейса
CUBE-HA не се поддържа през кръстосана кабелна връзка за RG-контрол/връзка за данни (Gig3)
И двете платформи трябва да бъдат идентични и да бъде свързан чрез a физически превключвател през всички подобни интерфейси, за да може CUBE HA да работи, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да приключи на един и същ ключ и т.н.
Не може да има терминиран WAN на CUBE директно или на данни HA от двете страни
И двата активни/готови трябва да са в един и същ център за данни
Задължително е използването на отделен L3 интерфейс за резервиране (RG Control/data, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за поддържане на HA и контролни точки
При отказ, по-рано активният CUBE преминава през презареждане по проект, запазвайки сигнализацията и медиите
Конфигурирайте излишък и на двата CUBE
Трябва да конфигурирате резервиране от кутия до кутия от слой 2 и на двата CUBE, предназначени да бъдат използвани в HA двойка, за да изведете виртуални IP адреси.
| 1 | Конфигурирайте проследяване на интерфейса на глобално ниво, за да проследявате състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса на гласов трафик , така че активният маршрут да изпълнява своята активна роля, след като интерфейсът за трафик не работи. | ||||||
| 2 | Конфигурирайте RG за използване с VoIP HA в подрежим на резервиране на приложения.
Ето обяснение на полетата, използвани в тази конфигурация:
| ||||||
| 3 | Разрешете резервирането от кутия до кутия за приложението CUBE. Конфигурирайте RG от предишната стъпка по-долу
група за съкращения 1 —Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||||||
| 4 | Конфигурирайте интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу и приложете идентификатора на интерфейса за резервиране ( рии )
Ето обяснение на полетата, използвани в тази конфигурация:
| ||||||
| 5 | Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане последно винаги е режим на готовност.
След VCUBE-1 се стартира напълно, запазете конфигурацията на VCUBE-2 и го презаредете.
| ||||||
| 6 | Проверете дали конфигурацията от кутия до кутия работи според очакванията. Съответният изход е подчертан в смели . Презаредихме VCUBE-2 последно и според съображения на дизайна; платформата за презареждане последна винаги ще бъде В режим на готовност . |
Конфигурирайте локален шлюз и на двата CUBE
В нашата примерна конфигурация ние използваме следната информация за магистралата от Control Hub, за да изградим конфигурацията на локалния шлюз и на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
Потребителско име: Хюсеин 1076 г_ LGU
Парола: lOV12MEaZx
| 1 | Уверете се, че за паролата е създаден конфигурационен ключ с командите, показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите от тип 6 са криптирани с помощта на AES шифър и този дефиниран от потребителя конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на Контролен център параметри, показани по-горе, запишете и презаредете. SIP обработване на пълномощията от Контролен център са подчертани в смели .
За да покажем изхода на командата show, презаредихме VCUBE-2 последвано от VCUBE-1 , правене VCUBE-1 готовност CUBE и VCUBE-2 активният КУБ |
| 2 | Във всеки един момент само една платформа ще поддържа активна регистрация като локален шлюз с Webex Calling достъп SBC. Разгледайте изхода на следните команди за показване. показване на група приложения за съкращаване 1 покажете състоянието на регистъра на sip-ua
От изхода по-горе можете да видите това VCUBE-2 е активният LGW, поддържащ регистрацията с Webex Calling access SBC, докато изходът на „show sip-ua register status“ е празен в VCUBE-1 |
| 3 | Сега активирайте следните отстраняване на грешки на VCUBE-1
|
| 4 | Симулирайте отказ, като издадете следната команда на активния LGW, VCUBE-2 в този случай.
Превключването от ACTIVE към STANDBY LGW се случва в следния сценарий, освен CLI, изброен по-горе
|
| 5 | Проверете дали VCUBE-1 се е регистрирал в Webex Calling access SBC. VCUBE-2 вече щеше да се презареди.
VCUBE-1 вече е активният LGW. |
| 6 | Вижте съответния регистрационен файл за отстраняване на грешки на VCUBE-1, изпращащ SIP РЕГИСТЪР до Webex Calling ПРЕЗ виртуалния IP и получаване на 200 ОК.
|
Конфигуриране на профил за защита на SIP линиите за магистрала към локален шлюз
В случаите, когато локалният шлюз и шлюз за обществена телефонна централа се намират на едно и също устройство, Unified CM трябва да бъде активиран да разграничава два различни типа трафик (повиквания от Webex и от PSTN), които произхождат от едно и също устройство и да прилага диференциран клас на услугата към тях видове повиквания. Това диференцирано третиране на повикванията се постига чрез осигуряване на две магистрали между Unified CM и комбинирания локален шлюз и шлюз за обществена телефонна централа устройство, което изисква различни SIP портове за слушане за двата канала.
Създайте специален профил за защита на SIP линиите за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Конфигурирайте SIP профил за локалната магистрала на шлюза
Създайте специален SIP профил за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Създайте пространство за търсене на обаждания за обаждания от Webex
Създайте пространство за търсене на обаждания за повиквания, произхождащи от Webex със следните настройки:
| ||||||||||||
Конфигурирайте SIP транк към и от Webex
Създайте външна линия SIP за повикванията към и от Webex през локалния шлюз със следните настройки:
| ||||||||||||||||||||||||||
Конфигуриране на група маршрути за Webex
Създайте група маршрути със следните настройки:
| ||||||||
Конфигуриране на списък с маршрути за Webex
Създайте списък на маршрути със следните настройки:
| ||||||||||||||
Създайте дял за Webex дестинации
Създайте дял за дестинациите на Webex със следните настройки:
| ||||||||
Какво да направите след това
Уверете се, че сте добавили този дял към всички пространства за търсене на повиквания, които трябва да имат достъп до дестинациите на Webex . Трябва да добавите този дял специално към пространството за търсене на повиквания, което се използва като пространство за търсене на входящи повиквания в PSTN магистрали, така че повикванията от PSTN към Webex да могат да се насочват.
Конфигуриране на шаблони за маршрути за дестинации на Webex
Конфигурирайте модели на маршрути за всеки диапазон на DID на Webex със следните настройки:
| ||||||||||||
Конфигуриране на съкратено нормализиране на междусайтово набиране за Webex
Ако за Webex се изисква съкратено набиране между сайтове, тогава конфигурирайте модели за нормализиране на набиране за всеки диапазон на ESN на Webex със следните настройки:
| ||||||||||||||||||
Създайте група за търсене
Групите за търсене насочват входящите повиквания към група потребители или работни пространства. Можете дори да конфигурирате шаблон за маршрут към цяла група.
За повече информация как да настройвам група за търсене, вж Търсене на групи в Cisco Webex Control Hub .
Създаване на опашка на повикванията
Можете да настройвам опашка за обаждания, така че когато обажданията на клиентите не могат да бъдат отговорени, те получават автоматичен отговор, утешителни съобщения и музика в задържане , докато някой може да отговори на повикването им.
За повече информация как да настройвам и управлявате опашка за повиквания, вж Управлявайте опашките за обаждания в Cisco Webex Control Hub .
Създайте рецепционист клиент
Помогнете в подкрепа на нуждите на персонала на вашия фронт-офис. Можете да настройвам потребителите като телефонни служители, за да могат да преглеждат входящите повиквания до определени хора във вашата организация.
За информация как да настройвам и прегледате клиентите на рецепционистите, вж Клиенти на рецепцията в Cisco Webex Control Hub .
Създавайте и управлявайте автоматични служители
Можете да добавяте поздрави, да настройвам менюта и да маршрутизиране на повиквания към телефонен секретар, група за търсене, кутия за гласова поща или реален човек. Създайте 24-часов график или предоставете различни опции, когато вашият бизнес е отворен или затворен.
За информация как да създавате и управлявате автоматични оператори, вж Управлявайте автоматичните оператори в Cisco Webex Control Hub .
Конфигурирайте група за пейджинг
Груповото пейджинг позволява на потребителя да отправи еднопосочно обаждане или групова страница до до 75 целеви потребители и работни пространства чрез набиране на номер или разширение, присвоени на конкретна група за пейджинг.
За информация как да настройвам и редактирате групи за пейджинг, вж Конфигурирайте група за пейджинг в Cisco Webex Control Hub .
Настройте вдигане на обаждане
Подобрете работата в екип и сътрудничеството, като създадете група за приемане на повикване, така че потребителите да могат да отговарят на повиквания. Когато добавите потребители към група за приемане на група за приемане на повикване и член на групата е далеч или зает, друг член може да отговаря на техните повиквания.
За информация как да настройвам за приемане на група за приемане на повикване вж Вземане на обаждане в Cisco Webex Control Hub .
Настройте паркиране на повиквания
Паркиране на повиквания позволява на определена група потребители да паркират повиквания срещу други налични членове на групата за паркиране на повиквания. Паркираните обаждания могат да бъдат приемани от други членове на групата на техния телефон.
За повече информация как да настройвам паркиране на повиквания, вж Паркиране на обажданията в Cisco Webex Control Hub .
Активиране на влизане за потребители
| 1 | От изглед на клиента в , отидете на Управление > Местоположения .https://admin.webex.com |
| 2 | Изберете потребител и щракнете Обаждане . |
| 3 | Отидете до Разрешения между потребители раздел и след това изберете Влезте . |
| 4 | Включете превключвателя, за да позволите на други потребители да се добавят към текущото обаждане на този потребител. |
| 5 | Проверете Пуснете тон, когато този потребител влезе в разговор ако искате да пуснете тон на другите, когато този потребител нахлуе в тяхното обаждане. |
| 6 | Щракнете върху Запиши. |
Активиране на поверителност за потребител
| 1 | Влезте в Контролен център , и отидете на . | ||
| 2 | Изберете потребител и щракнете Обаждане . | ||
| 3 | Отидете до Разрешения между потребители област и след това изберете Поверителност . | ||
| 4 | Изберете подходящия Поверителност на автоматичния оператор настройки за този потребител.
| ||
| 5 | Проверете Активирайте поверителност поле за отметка. След това можете да решите да блокирате всички, като не избирате членове от падащ списък. Като алтернатива можете да изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състояние на линията на този потребител. Ако сте администратор на местоположение, в падащ списък се показват само потребителите, работните пространства и виртуалните линии, отнасящи се до назначените ви местоположения. Премахнете отметката от Активирайте поверителност поле за отметка, за да позволите на всеки да наблюдава състояние на линията. | ||
| 6 | Проверете Прилагане на поверителност за насочено приемане на повикване и влизане поле за отметка, за да активирате поверителност за насочено приемане на повикване и влизане.
| ||
| 7 | От Добавете член по име , изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състоянието на телефонна линия и да извикат насочено приемане на повикване и влизане. | ||
| 8 | За да филтрирате избраните от вас членове, използвайте филтриране по име, номер или вътр поле. | ||
| 9 | Щракнете върху Премахване на всички за да премахнете всички избрани членове.
| ||
| 10 | Щракнете върху Запиши. |
Конфигуриране на наблюдение
максимален брой наблюдавани линии за потребител е 50. Въпреки това, докато конфигурирате списъка за наблюдение, вземете предвид броя на съобщенията, които влияят на честотната лента между Webex Calling и вашата мрежа. Също така, определете максималните наблюдавани линии по броя на бутоните за линии на телефона на потребителя.
| 1 | От изглед на клиента вhttps://admin.webex.com , отидете на Управление и след това щракнете Потребители . | ||||
| 2 | Изберете потребителя, който искате да промените, и щракнете Обаждане . | ||||
| 3 | Отидете на Разрешения между потребители раздел и изберете Мониторинг . | ||||
| 4 | Изберете от следните:
Можете да включите виртуална линия в Добавете наблюдавана линия списък за потребителски мониторинг. | ||||
| 5 | Изберете дали искате да уведомите този потребител за паркирани повиквания, потърсете лицето или вътрешна линия за паркиране на повикване за паркиране на обаждания, което да бъде наблюдавано, и след това щракнете Запазете .
|
Активиране на предупредителния тон за свързване на повиквания за потребителите
Преди да започнете
| 1 | Влезте в Контролен център , и отидете на . | ||
| 2 | Изберете потребител и щракнете върху раздела Повиквания. | ||
| 3 | Отидете на Разрешения между потребители и щракнете Предупредителен тон за свързване на повикване . | ||
| 4 | Включете Предупредителен тон за свързване на повикване и след това щракнете Запазете .
За повече информация относно свързването на повиквания по споделена линия, вж Споделени линии на вашия мултиплатформен настолен телефон . За повече информация относно свързването на повиквания на споделена линия на Webex App вж Споделен изглед на линията за WebexApp . |
Включете хотела за потребител
| 1 | От изглед на клиента вhttps://admin.webex.com , отидете на Управление и изберете Потребители . | ||
| 2 | Изберете потребител и щракнете върху раздела Повиквания. | ||
| 3 | Отидете до Разрешения между потребители раздел и изберете Хотелиерство и включете превключвателя. | ||
| 4 | Въведете името или номера на хоста в хотела в Местоположение на хотела поле за търсене и изберете хоста за хотели, който искате да присвоите на потребителя. Може да бъде избран само един хостел. Ако изберете друг хост за хотели, първият се изтрива.
| ||
| 5 | За да ограничите времето, през което потребителят може да бъде свързан с хоста за хотели, изберете броя часове, през които потребителят може да използва хотелския хост от Лимитен период на асоцииране падащо меню. Потребителят ще излезе автоматично след избраното време.
| ||
| 6 | Щракнете върху Запиши.
|
Преглед на отчетите за обажданията
Можете да използвате страницата Анализ в Контролен център за да получите представа за това как хората използват Webex Calling и на Webex приложение (ангажиране) и качеството на медийното им изживяване при разговори. За достъп Webex Calling analytics, влизам в Контролен център , след това отидете на Анализ и изберете Обаждане раздел.
| 1 | За подробни отчети за историята на обажданията влизам в Контролен център , след това отидете на Анализ > Обаждане . |
| 2 | Изберете Подробна история на обажданията . За информация относно повиквания, използващи Специализиран екземпляр, вж Анализ на специализирани инстанции . |
| 3 | За достъп до данни за качество на медиите, влизам в Контролен център , след това отидете на Анализ и след това изберете Обаждане . За повече информация вижте Анализи за вашето портфолио за сътрудничество в облака.
|
Стартирайте инструмента CScan
CScan е инструмент за готовност на мрежата, предназначен да тества вашата мрежова връзка Webex Calling .
За повече информация вж Използвайте CScan, за да тествате качеството на мрежата за Webex Calling . |
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling , уверете се, че:
Имат основни познания за принципите на VoIP
Имате основни работни познания за гласовите концепции на Cisco IOS-XE и IOS-XE
Имайте основно разбиране за Session Initiation Protocol (SIP)
Имайте основно разбиране за Cisco Unified Communications Manager (Unified CM), ако вашият модел за разгръщане включва Unified CM
Вижте Ръководство за корпоративна конфигурация на Cisco Unified Border Element (CUBE). за подробности.
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че вашето внедряване има един или повече от локалните шлюзове, като например:
Cisco CUBE за IP-базирана свързаност
Cisco IOS Gateway за TDM-базирана свързаност
локален шлюз ви помага да мигрирате към Webex Calling със собствено темпо. локален шлюз интегрира вашето съществуващо в помещението внедряване с Webex Calling. Можете също да използвате съществуващата си Връзка с обществена телефонна централа. Виж Започнете с Local Gateway
Лицензионни изисквания за локални шлюзове
Лицензите за извикване на CUBE трябва да бъдат инсталирани на локален шлюз. За повече информация вижте Ръководство за конфигуриране на Cisco Unified Border Element .
Изисквания за сертификат и сигурност за локален шлюз
Webex Calling изисква сигурна сигнализация и медии. локален шлюз извършва криптирането и TLS връзка трябва да се установи изходяща към облака със следните стъпки:
LGW трябва да бъде актуализиран с CA root bundle от Cisco PKI
Набор от идентификационни данни за SIP дайджест от конфигурационна страница за конфигурация на Trunk на Control Hub се използва за конфигуриране на LGW (стъпките са част от конфигурацията, която следва)
Корен пакет на CA валидира представения сертификат
Подканени за идентификационни данни (предоставен е SIP обобщение)
Облакът идентифицира кой локален шлюз е сигурно регистриран
Изисквания за защитна стена, NAT обход и оптимизация на медийния път за локален шлюз
В повечето случаи локален шлюз и крайните точки могат да се намират във вътрешната клиентска мрежа, като използват частни IP адреси с NAT. Корпоративната защитна стена трябва да позволява изходящ трафик (SIP, RTP/ UDP, HTTP) към конкретни IP адреси/портове, обхванати в Референтна информация за порта .
Ако искате да използвате оптимизация на медийния път с ICE, интерфейсът за Webex Calling на Webex на локалния шлюз трябва да има директен мрежов път към и от крайните точки на Webex Calling . Ако крайните точки са на различно място и няма директен мрежов път между крайните точки и интерфейса за Webex Calling на локалния шлюз, тогава локален шлюз трябва да има публичен IP адрес , присвоен на интерфейса, обърнат към Webex Calling за повиквания между локален шлюз и крайните точки за използване на оптимизация на медийния път. Освен това трябва да работи с IOS-XE версия 16.12.5.
Първата стъпка, за да получите своя Webex Calling услуги и стартиране е да завършите Помощник за първоначална настройка (FTSW). След като FTSW бъде завършен за първото ви местоположение, не е необходимо да се попълва за допълнителни местоположения.
| 1 | Щракнете върху Първи стъпки връзка в имейла за добре дошли, който получавате.
| ||
| 2 | Прегледайте и приемете условия за използване на услугата. | ||
| 3 | Прегледайте плана си и след това щракнете Започнете .
| ||
| 4 | Изберете държавата, към която вашият център за данни трябва да картографира, и въведете информацията за клиентски контакт с клиента и адреса на клиента. | ||
| 5 | Щракнете върху следващо: Местоположение по подразбиране . | ||
| 6 | Изберете от следните опции:
| ||
| 7 | Направете следните избори, за да приложите към това местоположение:
| ||
| 8 | Щракнете върху Напред. | ||
| 9 | Въведете наличен SIP адрес на Cisco Webex и щракнете Следваща и изберете Край . |
Преди да започнете
За да създадете ново местоположение, подгответе следната информация:
Адрес на местоположението
Желани телефонни номера (по избор)
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на .
| ||||
| 2 | Конфигурирайте настройките на местоположението:
| ||||
| 3 | Щракнете върху Запазете и след това изберете да / не за добавяне на числа към местоположението сега или по-късно. | ||||
| 4 | Ако сте щракнали да , изберете една от следните опции:
Изборът на опция за PSTN е на всяко ниво на местоположение (всяко местоположение има само една опция PSTN). Можете да смесвате и съпоставяте толкова опции, колкото искате за внедряването си, но всяко местоположение ще има една опция. След като изберете и осигурите опция за PSTN, можете да я промените, като щракнете Управлявайте в местоположението PSTN свойства. Някои опции, като Cisco PSTN, обаче, може да не са налични, след като е назначена друга опция. Отворете заявка за случай на поддръжката за насоки. | ||||
| 5 | Изберете дали искате да активирате номерата сега или по-късно. | ||||
| 6 | Ако сте избрали неинтегрирана CCP или PSTN, базирана на помещения, въведете Телефонни номера като стойности, разделени със запетая, и след това щракнете Потвърди . Добавят се номера за конкретното местоположение. Валидни записи се преместват в Потвърдени номера полето и невалидни записи остават в Добавете числа поле, придружено от съобщение за грешка. В зависимост от държавата на местоположението, номерата се форматират според изискванията за местно набиране. Например, ако се изисква код на държавата, можете да въведете числа със или без кода и кодът се поставя преди. | ||||
| 7 | Щракнете върху Запиши. |
Какво да направите след това
След като създадете местоположение, можете да активирате спешни 911 услуги за това местоположение. Виж RedSky Emergency 911 Service за обаждания в Webex Calling за повече информация.
Преди да започнете
| Вземете списък на потребителите и работните пространства, свързани с местоположение: Отидете на и от падащо меню изберете местоположението, което да бъде изтрито. Вие трябва изтрийте тези потребители и работни пространства, преди да изтриете местоположението. Имайте предвид, че всички номера, свързани с това местоположение, ще бъдат върнати обратно на вашия доставчик на PSTN; вече няма да притежавате тези номера. |
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . |
| 2 | Щракнете върху |
| 3 | Изберете Изтриване на местоположение и потвърдете, че искате да изтриете това местоположение. Обикновено отнема няколко минути, преди местоположението да бъде изтрито за постоянно, но може да отнеме до един час. Можете да проверите състоянието, като щракнете |
Можете да промените вашата PSTN настройка, името, часова зона и езика на местоположението, след като е създадено. Имайте предвид обаче, че новият език се прилага само за нови потребители и устройства. Съществуващите потребители и устройства продължават да използват стария език.
| За съществуващи местоположения можете да активирате спешни 911 услуги. Виж RedSky Emergency 911 Service за обаждания в Webex Calling за повече информация. |
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . Ако видите символ Внимание до местоположение, това означава, че все още не сте конфигурирали телефонен номер за това местоположение. Не можете да извършвате или да получавате повиквания, докато не конфигурирате този номер. | ||||||
| 2 | (По избор) Под PSTN връзка , изберете едно от двете Свързан с облак PSTN или Базирана в помещения PSTN (локален шлюз), в зависимост от това кой вече сте конфигурирали. Щракнете върху Управлявайте за да промените тази конфигурация и след това потвърдете свързаните рискове, като изберете Продължете . След това изберете една от следните опции и щракнете Запазете :
| ||||||
| 3 | Изберете Основен номер на който може да се достигне до основния контакт на местоположението. | ||||||
| 4 | (По избор) Под Спешно обаждане , можете да изберете Идентификатор на местоположение при спешни случаи да зададете на това местоположение.
| ||||||
| 5 | Изберете Номер на гласовата поща на които потребителите могат да се обаждат, за да проверят гласовата си поща за това местоположение. | ||||||
| 6 | (По избор) Щракнете върху иконата на молив в горната част на страницата Местоположение, за да промените Име на местоположението , Език за обявяване , Език на Имейл , Часова зона , или Адрес според нуждите и след това щракнете Запазете .
|
Тези настройки са за вътрешно набиране и са налични и в съветника за първа настройка. Когато промените своя план за набиране, примерните номера в Контролен център актуализирайте, за да покажете тези промени.
| Можете да конфигурирате разрешения за изходящи повиквания за местоположение. Виж тези стъпки за да конфигурирате разрешения за изходящи повиквания. |
| 1 | Влезте в Контролен център , отидете на , а след това превъртете до Вътрешно набиране . | ||||||||
| 2 | Конфигурирайте следните незадължителни предпочитания за набиране, ако е необходимо:
| ||||||||
| 3 | Посочете вътрешно набиране за конкретни местоположения. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете вътрешното набиране, ако е необходимо:
| ||||||||
| 4 | Посочете външно набиране за конкретни местоположения. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете външното набиране, ако е необходимо:
Въздействие върху потребителите:
|
Ако сте дистрибутор с добавена стойност, можете да използвате тези стъпки, за да започнете конфигуриране на локален шлюз Контролен център . Когато този шлюз е регистриран в облака, можете да го използвате на един или повече от вашите Webex Calling местоположения за осигуряване на маршрутизиране към корпоративен доставчик на PSTN доставчик на услуги.
| Местоположение, което има локален шлюз , не може да бъде изтрито, когато локален шлюз се използва за други местоположения. |
Преди да започнете
След като се добави местоположение и преди да конфигурирате базиран на помещения PSTN за местоположение, трябва да създадете магистрала.
Създайте всякакви местоположения и специфични настройки и номера за всяко от тях. Местоположенията трябва да съществуват, преди да можете да добавите PSTN, базиран на помещения.
Разберете изискванията за PSTN (локален шлюз), базиран на помещения Webex Calling .
Не можете да изберете повече от една магистрала за местоположение с базирана на помещения PSTN, но можете да изберете една и съща магистрала за множество местоположения.
| 1 | Влезте в Контролен център при , отидете на Услуги > Обаждане > Маршрутизиране на обажданията и изберете Добавяне на багажника .https://admin.webex.com | ||
| 2 | Изберете местоположение. | ||
| 3 | Дайте име на багажника и щракнете Запазете .
|
Какво да направите след това
Информацията за багажника се появява на екрана Регистрирайте домейн , Група магистрали OTG/DTG , Линия/Порт , и Изходящ прокси адрес .
Препоръчваме ви да копирате тази информация от Контролен център и го поставете в локален текстов файл или документ, за да можете да се обърнете към него, когато сте готови да конфигурирате базирания на помещения PSTN.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за багажника Контролен център . Щракнете върху Извличане на потребителско име и нулиране на парола за генериране на нов набор от идентификационни данни за използване в багажника.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . | ||
| 2 | Изберете местоположение за промяна и щракнете Управлявайте . | ||
| 3 | Изберете Базирана в помещения PSTN и щракнете Следваща . | ||
| 4 | Изберете багажник от падащо меню.
| ||
| 5 | Щракнете върху известието за потвърждение, след което щракнете Запазете . |
Какво да направите след това
Трябва да вземете информация за конфигуриране , която Контролен център генерира и картографира параметрите в локален шлюз (например на Cisco CUBE, който се намира в помещенията). Тази статия ви превежда през този процес. Като справка вижте следващата диаграма за пример как Контролен център информация за конфигуриране (вляво) се съпоставя с параметрите в CUBE (вдясно):
След като завършите успешно конфигурацията на самия шлюз, можете да се върнете към Услуги > Обадете се > Местоположения в Контролен център и създаденият от вас шлюз ще бъде посочен в картата за местоположение, към която сте го присвоили, със зелена точка вляво от името. Това състояние показва, че шлюзът е сигурно регистриран в облака за повикване и служи като активен шлюз за обществена телефонна централа за местоположението.
Можете лесно да преглеждате, активирате, премахвате и добавяте телефонни номера за вашата организация Контролен център . За повече информация вж Управлявайте телефонните номера в Control Hub .
Ако изпробвате услугите на Webex и искате да преобразувате пробната си версия в платен абонамент, можете да изпратите заявка по имейл до партньора си.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , изберете иконата на сграда |
| 2 | Изберете Абонаменти раздел и след това щракнете Купете сега . До партньора ви се изпраща имейл, уведомяващ го, че се интересувате от преминаване към платен абонамент. |
Можете да използвате Контролен център за да зададете приоритета на наличните опции за повикване, в които потребителите виждат Приложение Webex . Можете също да ги активирате за обаждане с едно щракване. За повече информация вижте: Задайте опции за повикване за потребители на Webex App .
Можете да контролирате какво приложение за повиквания се отваря, когато потребителите извършват обаждания. Можете да конфигурирате настройките на клиента за повикване, включително внедряване в смесен режим за организации с потребители, упълномощени с Unified CM или Webex Calling и потребители без платени услуги за разговори от Cisco. За повече информация вижте: Настройте поведение при повикване .
Общ преглед
В момента Webex Calling поддържа две версии на локален шлюз:
Локален шлюз
Локален шлюз за Webex за правителството
Преди да започнете, разберете изискванията на базираната в помещенията обществена комутирана телефонна мрежа (PSTN) и локалния шлюз (LGW) за обажданията чрез Webex Calling. Виж Предпочитана архитектура на Cisco за обаждания в Webex Calling за повече информация.
Тази статия предполага, че е създадена специална платформа за локален шлюз без съществуваща гласова конфигурация. Ако модифицирате съществуващ шлюз за обществена телефонна централа или внедряване на CUBE Enterprise, за да се използва като функция Local Gateway за Webex Calling, тогава обърнете внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци и функционалност на повикванията поради промените, които правите.
| Процедурите съдържат връзки към справочната документация на командите, където можете да научите повече за отделните опции на командите. Всички препратки към командите отиват към Справочник за команди за управлявани шлюзи на Webex освен ако не е посочено друго (в този случай командните връзки отиват до Справочник за гласови команди на Cisco IOS ). Можете да получите достъп до всички тези ръководства в Cisco Unified Border Element Препратки към команди . За информация относно поддържаните SBC на трети страни вижте съответната референтна документация на продукта. |
Има две опции за конфигуриране на локалния шлюз за вашия Webex Calling багажник:
Багажник на базата на регистрация
Багажник, базиран на сертификати
Използвайте потока на задачите или под Локален шлюз, базиран на регистрация или Базиран на сертификат локален шлюз за да конфигурирате локален шлюз за вашия Webex Calling багажника.
Виж Започнете с Local Gateway за повече информация относно различните типове багажници. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Ние използваме Session Initiation Protocol (SIP) и Защита на транспортния слой (TLS), за да защитим магистралата и защитен протокол в реално време (SRTP), за да защитим медиите между локалния шлюз и Webex Calling .
Изберете CUBE като ваш локален шлюз. Понастоящем Webex for Government не поддържа никакви гранични контролери на сесии (SBC) на трети страни. За да прегледате последния списък, вж Започнете с Local Gateway .
- Инсталирайте Cisco IOS XE Dublin 17.12.1a или по-нови версии за всички Webex за правителствени локални шлюзове.
За да прегледате списъка с основни сертифициращи органи (CA), които Webex поддържа за правителство, вж Коренни сертифициращи органи за Webex за правителство .
За подробности относно диапазоните на външни портове за локален шлюз в Webex за правителство, вж Мрежови изисквания за Webex за правителство (FedRAMP) .
Локален шлюз за Webex за правителството не поддържа следното:
STUN/ICE-Lite за оптимизиране на медийния път
факс (T.38)
За да конфигурирате локален шлюз за вашата линия за Webex Calling на Webex в Webex за правителство, използвайте следната опция:
Багажник, базиран на сертификати
Използвайте потока от задачи под Базиран на сертификат локален шлюз за да конфигурирате локалния шлюз за вашата линия за Webex Calling . За повече подробности как да конфигурирате базиран на сертификат локален шлюз, вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Задължително е да конфигурирате FIPS-съвместими GCM шифри, за да поддържате локален шлюз за Webex за правителство. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
| Webex за правителството не поддържа базиран на регистрация локален шлюз. |
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, като се използва регистриране на външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Изображението по-долу подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде следвана.
В този дизайн се използват следните основни конфигурации:
наематели на гласов клас : Използва се за създаване на специфични за багажника конфигурации.
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
Всички базирани на регистрация внедрявания на локален шлюз изискват Cisco IOS XE 17.6.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
NTP
ACL
Удостоверяване на потребителя и дистанционен достъп
DNS
IP маршрутизиране
IP адреси
Мрежата към Webex Calling трябва да използва IPv4 адрес.
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 | Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
| ||
| 2 | Защитете идентификационните данни за регистрация и STUN на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва:
| ||
| 3 | Създайте заместваща PKI точка на доверие.
| ||
| 4 | Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация. Транспортните параметри също трябва да бъдат актуализирани, за да се гарантира надеждна защитена връзка за регистрация:
| ||
| 5 | Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати:
|
| 1 | Създайте базирана на регистрация PSTN магистрала за съществуващо местоположение в Control Hub. Отбележете информацията за магистралата, която се предоставя след създаването на магистрала. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling . | ||||
| 2 | Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. медийна статистикаПозволява наблюдение на медиите на локалния шлюз. медийни масови статистикиПозволява на контролната равнина да анкетира равнината на данни за статистика за повикването. За повече информация относно тези команди вж Медия . разрешаване на връзки глътка до глъткаАктивирайте CUBE основната SIP функция на потребителски агент отзад до гръб. За повече информация вж Разрешаване на връзки .
Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . | ||||
| 3 | Конфигуриране кодек за гласов клас 100 филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вижте кодекза гласов клас.
| ||||
| 4 | Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . Ето обяснение на полетата за конфигурацията: зашеметяване използване лед лайтИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite .
| ||||
| 5 | Конфигурирайте политиката за криптиране на медиите за трафика на Webex . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1 80_ За повече информация вж гласов клас srtp-crypto . | ||||
| 6 | Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на параметъра на неговата дестинационна магистрала: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте dtg=, последвано от стойността на Trunk OTG/DTG, предоставена в Control Hub при създаването на магистрала. За повече информация вж глас клас uri . | ||||
| 7 | Конфигуриране глътка профил 100 , който ще се използва за модифициране на SIP съобщения, преди да бъдат изпратени до Webex Calling.
Ето обяснение на полетата за конфигурацията:
| ||||
| 8 | Конфигуриране на магистрала за Webex Calling :
|
След като дефинирате наемател 100 и конфигуриране на SIP VoIP dial-peer, шлюзът инициира TLS връзка към Webex Calling. В този момент SBC за достъп представя своя сертификат на локалния шлюз. Локалният шлюз потвърждава сертификата за достъп на Webex Calling SBC, използвайки коренния пакет на CA, който беше актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп за Webex Calling . След това локалният шлюз може да използва тази защитена връзка , за да се регистрира в SBC за достъп на Webex . Когато регистрацията е оспорена за удостоверяване:
В потребителско име, парола, и царство параметри от пълномощията конфигурацията се използва в отговора.
Правилата за модификация в sip профил 100 се използват за преобразуване на SIPS URL обратно в SIP.
Регистрацията е успешна, когато се получи 200 ОК от SBC за достъп.
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
| Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE. |
| За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI . |
| 1 | Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 | Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 300 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Указва целевия IPv4 адрес на дестинацията за изпращане на етап на повикването. Целта на сесията тук е IP адрес на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Дефинира критерий за съответствие за VIA заглавката с IP адрес на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteДефинира RTP-NTE (RFC2833) като DTMF възможност, очаквана на етапа на етап на повикването. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 | Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| Когато създавате линията за Webex Calling в Unified CM, уверете се, че сте конфигурирали входящия порт в настройките на профил за защита на SIP линиите на 5065. Това позволява входящи съобщения на порт 5065 и попълване на VIA заглавката с тази стойност при изпращане на съобщения до локалния шлюз. |
| 1 | Конфигурирайте следните URI адреси на гласов клас: | ||
| 2 | Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове:
Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060 : Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com : Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com : Името на име на домакина за запис A. 192.168.80.65 : IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. | ||
| 3 | Конфигурирайте следните точки за набиране: | ||
| 4 | Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно открива често наблюдавани проблеми в базирания на IOS XE локален шлюз и генерира имейл, системен журнал или известие за терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития за задействане на проблем и действия, които трябва да се предприемат за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми, като използвате съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди show.
Типовете действия включват събиране на изходни команди show:
Генериране на консолидиран регистрационен файл
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър.
Инженерите на TAC създават DS файловете и ги подписват цифрово за защита на целостта. Всеки DS файл има уникален цифров ИД , присвоен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, от който изтегляте DSLT . Файловете, които променяте, се провалят при инсталиране поради грешка при проверка на целостта.
Сървър с прост протокол за прехвърляне на поща (SMTP), който ви е необходим, за да може локалният шлюз да изпраща известия по имейл.
Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако искате да използвате защитения SMTP сървър за имейл известия.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1a или по-нова версия
Диагностичните подписи са активирано по подразбиране.
Конфигурирайте защитения имейл сървър, който да се използва за изпращане на проактивни известия, ако устройството работи с Cisco IOS XE 17.6.1a или по-нова версия.
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
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1a или по-нова версия за изпращане на проактивни известия до tacfaststart@gmail.com използване на Gmail като защитен SMTP сървър:
| Препоръчваме ви да използвате Cisco IOS XE Bengaluru 17.6.x или по-нови версии. |
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“.
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на висока натовареност на CPU
Този DS проследява използването на CPU за пет секунди, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички отстраняване на грешки и деинсталира всички диагностични подписи, които са инсталирани в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Използвайте покажи snmp команда за активиране на SNMP. Ако не активирате, конфигурирайте snmp-сървър мениджър команда.
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 Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Копирайте 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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
ДС_ LGW_ CPU_ ПН75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг на регистрацията на външна линия SIP
Този DS проверява за дерегистрация на локален шлюз SIP транк с облака за Webex Calling на всеки 60 секунди. След като се открие събитието за отписване, то генерира известие по имейл и системен журнал и се деинсталира след две поява на дерегистрация. Използвайте стъпките по-долу, за да инсталирате подписа:
Изтеглете DS 64117, като използвате следните падащи опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
SIP- SIP
Тип на проблема
Отмяна на регистрация на 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#Използвайте покажете диагностичен подпис за обаждане вкъщи команда, за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Мониторинг на необичайни прекъсвания на разговора
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Използвайте покажи snmp команда, за да проверите дали SNMP е активиран. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Откриване на необичайно прекъсване на връзката с SIP с Имейл и известие в системния журнал.
Копирайте 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Използвайте покажете диагностичен подпис за обаждане вкъщи команда, за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Използвайте диагностични подписи (DS) за бързо разрешаване на проблеми. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC . Диагностичните подписи (DS) премахват необходимостта от ръчна проверка за възникване на проблема и улесняват много по-лесно отстраняването на неизправности на периодични и преходни проблеми.
Можете да използвате Инструмент за търсене на диагностични подписи за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример за това как да намерите и инсталирате DS за откриване на появата „% VOICE_ IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте допълнителна променлива на средата на DSds_fsurl_prefix което е пътят на файлов сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка в следната команда. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, ако е необходимо.
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 е активиран с помощта на покажи snmp команда. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp %SNMP agent not enabled config t snmp-server manager endУверете се, че сте инсталирали High CPU Monitoring DS 64224 като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо използване на CPU . Изтеглете DS 64224, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Изтеглете DS 65095, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Cisco CSR 1000V Series
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
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:Инсталирайте High CPU мониторинг 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 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 ИД
Име на 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
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 ИД | Име на 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 ИД | Име на DS | Задейства се /Макс/Деинсталиране | Средно време на работа (секунди) | Максимално време на работа (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0/0/N | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23.053 | 23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнение на диагностичния подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуер, текуща конфигурация и показване на командни изходи, които са подходящи за отстраняване на даден проблем.
Деинсталирайте диагностичните подписи
Използване на диагностични подписи за целите на отстраняване на неизправности обикновено се деинсталират за деинсталиране след откриване на някои проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи команда и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID>
Пример:
call-home diagnostic-signature deinstall 64224
| Нови подписи се добавят периодично към инструмента за търсене на подписи за диагностика, въз основа на проблеми, които често се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови персонализирани подписи. |
За по-добро управление на Cisco IOS XE Gateways, препоръчваме ви да регистрирате и управлявате шлюзовете чрез Control Hub. Това е опция по избор. Когато се регистрирате, можете да използвате опцията за валидиране на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате всички проблеми с конфигурацията. Понастоящем тази функционалност поддържат само базирани на регистрация канали.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, използвайки базиран на сертификат взаимна TLS (mTLS) външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Следното изображение подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде последвана.
В този дизайн се използват следните основни конфигурации:
наематели на гласов клас : Използва се за създаване на специфични за багажника конфигурации.
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение. Предоставени са опции за публично или частно (зад NAT) адресиране. SRV DNS записите не са задължителни, освен ако не се балансиране на товара в множество екземпляри на CUBE.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
Всички базирани на сертификати локални внедрявания на шлюз изискват Cisco IOS XE 17.9.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Essentials. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
За изисквания за висок капацитет може също да изисквате лиценз за висока сигурност (HSEC) и допълнително право на пропускателна способност.
Отнесете се към Кодове за оторизация за повече подробности.
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
NTP
ACL
Удостоверяване на потребителя и дистанционен достъп
DNS
IP маршрутизиране
IP адреси
Мрежата към Webex Calling трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) на локалния шлюз или адресите на запис на услуги (SRV) трябва да се разрешават до публичен IPv4 адрес в интернет.
Всички SIP и медийни портове на интерфейса на локалния шлюз, обърнат към Webex , трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате съответно защитната си стена.
Инсталирайте подписан сертификат на локалния шлюз (по-долу са дадени подробни стъпки за конфигуриране).
Публичен орган за сертификати (CA), както е описано подробно в Какви основни центрове за сертифициране се поддържат за обаждания към аудио и видео платформи на Cisco Webex ? трябва да подпише сертификата на устройството.
FQDN , конфигуриран в Control Hub при създаване на магистрала, трябва да бъде сертификатът Common Name (CN) или Subject Alternate Name (SAN) на рутера. Например:
Ако конфигуриран транк в Control Hub на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на рутера трябва да съдържа cube1.lgw.com.
Ако конфигурирана магистрала в контролния център на вашата организация има lgws.lgw.com като SRV адрес на локалния(ите) шлюз(и), достъпен от магистралата, тогава CN или SAN в сертификата на рутера трябва да съдържа lgws.lgw.com. Записите, до които SRV адресът се разрешава (CNAME, A Record или IP адрес), са незадължителни в SAN.
Независимо дали използвате FQDN или SRV за магистрала, адресът за контакт за всички нови SIP диалогови прозорци от вашия локален шлюз използва името, конфигурирано в Control Hub.
Уверете се, че сертификатите са подписани за използване на клиент и сървър.
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 | Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
| ||
| 2 | Защитете STUN идентификационните данни на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва: | ||
| 3 | Създайте доверителна точка за криптиране със сертификат, подписан от предпочитания от вас орган за сертификати (CA). | ||
| 4 | Удостоверете новия си сертификат, като използвате вашия междинен (или основен) СА сертификат, след което импортирайте сертификата (Стъпка 4). Въведете следната команда exec или конфигурация:
| ||
| 5 | Импортирайте подписан сертификат за хост, като използвате следната команда exec или конфигурация:
| ||
| 6 | Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация:
| ||
| 7 | Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати:
|
| 1 | Създайте CUBE базирана на сертификат PSTN магистрала за съществуващо местоположение в Control Hub. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling .
| ||||
| 2 | Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. разрешаване на връзки глътка до глъткаАктивирайте CUBE основния SIP обратно към гръб функционалност на потребителския агент. За повече информация вж Разрешаване на връзки .
Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез dial-peers или наематели. | ||||
| 3 | Конфигуриране кодек за гласов клас 100 кодек филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вижте кодекза гласов клас.
| ||||
| 4 | Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: зашеметяване използване лед лайтИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite .
| ||||
| 5 | Конфигурирайте политиката за криптиране на медиите за трафика на Webex . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1 80_ За повече информация вж гласов клас srtp-crypto . | ||||
| 6 | Конфигуриране на FIPS-съвместими GCM шифри (Тази стъпка е приложима само за Webex for Government) . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Посочва GCM като шифров пакет, който CUBE предлага. Задължително е да конфигурирате GCM шифри за локален шлюз за Webex за правителство. | ||||
| 7 | Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на неговото FQDN или SRV местоназначение: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте LGW FQDN или SRV, конфигурирани в Control Hub, докато създавате магистрала. | ||||
| 8 | Конфигурирайте профили за манипулиране на SIP съобщение . Ако вашият шлюз е конфигуриран с публичен IP адрес, конфигурирайте профил по следния начин или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, а „198.51.100.1“ е публичният IP адрес на интерфейса на локалния шлюз пред Webex Calling: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства.
| ||||
| 9 | Ако вашият шлюз е конфигуриран с частен IP адрес зад статичен NAT, конфигурирайте входящи и изходящи SIP профили, както следва. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, „10.80.13.12“ е IP адрес на интерфейса, обърнат към Webex Calling , а „192.65.79.20“ е публичният IP адрес на NAT. SIP профили за изходящи съобщения към Webex Calling
Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. правила от 30 до 81Преобразувайте препратките към частни адреси към външния публичен адрес за сайта, позволявайки на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Преобразувайте препратките към публичния адрес в конфигурирания частен адрес, позволявайки на съобщенията от Webex да бъдат правилно обработвани от CUBE. За повече информация вж гласови класове sip-профили . | ||||
| 10 | Конфигурирайте SIP опции за поддържане на активност с профил за промяна на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-options-keepalive 100Конфигурира поддържащ профил и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което Ping за SIP извън диалоговите опции се изпраща до целта за набиране, когато връзката на сърдечния ритъм към крайната точка е в състояние UP или Down. Този поддържащ профил се задейства от точката за набиране, конфигурирана към Webex. За да се гарантира, че заглавките на контактите включват напълно квалифицирано име на домейн SBC, се използва SIP профил 115. Правила 30, 40 и 50 се изискват само когато SBC е конфигуриран зад статичен NAT. В този пример cube1.lgw.com е FQDN , избрано за локалния шлюз и ако се използва статичен NAT, „10.80.13.12“ е IP адрес на интерфейса на SBC към Webex Calling и „192.65.79.20“ е публичният IP адрес на NAT . | ||||
| 11 | Конфигуриране на магистрала за Webex Calling :
|
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
| Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE. |
| За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI . |
| 1 | Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 | Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 300 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Указва целевия IPv4 адрес на дестинацията за изпращане на етап на повикването. Целта на сесията тук е IP адрес на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Дефинира критерий за съответствие за VIA заглавката с IP адрес на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteДефинира RTP-NTE (RFC2833) като DTMF възможност, очаквана на етапа на етап на повикването. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 | Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| 1 | Конфигурирайте следните URI адреси на гласов клас: | ||
| 2 | Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове:
Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060 : Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com : Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com : Името на име на домакина за запис A. 192.168.80.65 : IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. | ||
| 3 | Конфигурирайте следните точки за набиране: | ||
| 4 | Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно открива често наблюдавани проблеми в базирания на Cisco IOS XE локален шлюз и генерира имейл, системен журнал или известие за терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития и действия за задействане на проблем за информиране, отстраняване на неизправности и отстраняване на проблема. Използвайте съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди за показване, за да дефинирате логиката за откриване на проблеми. Типовете действия включват:
Събиране на изходни команди show
Генериране на консолидиран регистрационен файл
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър
Инженерите на TAC създават DS файлове и ги подписват цифрово за защита на целостта. Всеки DS файл има уникалния цифров ИД , присвоен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
Не редактирайте DS файла, от който изтегляте DSLT . Файловете, които променяте, се провалят при инсталиране поради грешка при проверка на целостта.
Сървър с прост протокол за прехвърляне на поща (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
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на висока натовареност на CPU
Този DS проследява 5-секундно използване на CPU с помощта на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички отстраняване на грешки и деинсталира всички диагностични подписи, които инсталирате в локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.
Уверете се, че сте активирали SNMP с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл
Копирайте 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 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 ИД
Име на DS
Ревизия
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително себе си. Ако е необходимо, моля, инсталирайте отново DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг на необичайни прекъсвания на разговора
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
Уверете се, че SNMP е активиран с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
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 Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Откриване на необичайно прекъсване на връзката с SIP с Имейл и известие в системния журнал.
Копирайте 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Използвайте командата покажете диагностичен подпис за обаждане вкъщи за да проверите дали подписът е инсталиран успешно. Колоната за състоянието трябва да има „регистрирана“ стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Можете също да използвате диагностични подписи (DS) за бързо разрешаване на проблеми. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая на Cisco TAC . Това елиминира необходимостта от ръчна проверка за възникване на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате Инструмент за търсене на диагностични подписи за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето пример за това как да намерите и инсталирате DS за откриване на появата „% VOICE_ IEC-3-GW: CCAPI: Вътрешна грешка (праг на повикване): IEC=1.1.181.1.29.0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:
Конфигурирайте друга променлива на средата на DSds_fsurl_prefix като пътя на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка както е показано по-долу. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, както е необходимо.
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 е активиран с помощта на командата покажи snmp . Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp %SNMP agent not enabled config t snmp-server manager endПрепоръчваме да инсталирате High CPU Monitoring DS 64224 като проактивна мярка за деактивиране на всички сигнатури за отстраняване на грешки и диагностика по време на високо използване на CPU . Изтеглете DS 64224, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо използване на CPU с известия по Имейл .
Изтеглете DS 65095, като използвате следните опции в Инструмент за търсене на диагностични подписи :
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение за обаждания на Webex Calling
Обхват на проблема
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 65095 XML файл за мониторинг на CPU в локалния шлюз.
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 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 ИД
Име на 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
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 ИД | Име на 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 ИД | Име на DS | Задейства се /Макс/Деинсталиране | Средно време на работа (секунди) | Максимално време на работа (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип на проблема, подробности за устройството, версия на софтуер, текуща конфигурация и показване на командни изходи, които са подходящи за отстраняване на даден проблем.
Деинсталирайте диагностичните подписи
Използване на диагностичните сигнатури за целите на отстраняване на неизправности обикновено се деинсталират за деинсталиране след откриване на някои проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи и изпълнете следната команда:
call-home diagnostic-signature deinstall <DS ID> Пример:
call-home diagnostic-signature deinstall 64224
| Нови подписи се добавят периодично към инструмента за търсене на диагностични подписи въз основа на проблеми, които се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови персонализирани подписи. |
Основи
Предварителни изисквания
Преди да разположите CUBE HA като локален шлюз за Webex Calling, уверете се, че имате задълбочено разбиране на следните концепции:
Редундантност от кутия към кутия от слой 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 за различни платформи:
ISR 4K серия— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
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 Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Общ преглед на решението за Webex Calling
Cisco Webex Calling е предложение за сътрудничество, което предоставя базирана в облак алтернатива с множество наематели на телефонна услуга за локална телефонна централа с множество опции за PSTN за клиенти.
Разгръщането на локален шлюз (представено по-долу) е в центъра на тази статия. Транк на локалния шлюз (базиран на помещения 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 High Availability (HA) Layer 2 Box-to-box (B2B) резервиране за запазване на повикванията с състояние на състояние |
Считано от IOS-XE 16.12.2, CUBE HA може да бъде разгърнат като локален шлюз за внедряване на магистрала за Cisco Webex Calling (базирана на помещения PSTN) и ние ще съображения на дизайна в тази статия. Тази фигура показва типична настройка на CUBE HA като локален шлюз за разгръщане на магистрала на Cisco Webex Calling .
Инфракомпонент на групата за резервиране
Компонентът Infra за групата за резервиране (RG) осигурява поддръжката на комуникационната инфраструктура от кутия до кутия между двата CUBE и договаря окончателното стабилно състояние на резервиране. Този компонент също така осигурява:
Протокол, подобен на HSRP, който договаря крайното състояние на резервиране за всеки рутер чрез обмен на съобщения за поддържане на активност и hello между двата CUBE (чрез контролния интерфейс) – GigabitEthernet3 на фигурата по-горе.
Транспортен механизъм за контролна точка на състоянието на сигнализацията и медиите за всяко повикване от активния към резервния рутер (чрез интерфейса за данни) — GigabitEthernet3 на фигурата по-горе.
Конфигуриране и управление на интерфейса за виртуален IP (VIP) за интерфейсите за трафик (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран да поддържа гласова B2B HA.
Управление на виртуални IP (VIP) адреси както за сигнализация, така и за медии
B2B HA разчита на VIP за постигане на съкращения. VIP и свързаните физически интерфейси на двата CUBE в двойката CUBE HA трябва да се намират в една и съща LAN подмрежа. Конфигурирането на VIP и обвързването на VIP интерфейса към определено гласово приложение (SIP) са задължителни за гласова поддръжка на B2B HA. Външни устройства като Unified CM, Webex Calling access SBC, доставчик на услуги или прокси, използват VIP като IP адрес на дестинацията за повикванията, преминаващи през рутерите CUBE HA. Следователно, от гледна точка на Webex Calling , двойките CUBE HA действат като един локален шлюз.
Сигнализирането на повикванията и информацията за RTP сесията на установените повиквания са контролни точки от активния рутер към рутера в режим на готовност. Когато активният рутер изпадне, рутерът в режим на готовност поема управлението и продължава да препраща RTP поток , който преди това е бил насочен от първия рутер.
Обажданията в преходно състояние по време на отказ няма да бъдат запазени след превключване. Например повиквания, които все още не са напълно установени или са в процес на промяна с функция за прехвърляне или задържане. Установените повиквания могат да бъдат прекъснати след превключване.
Съществуват следните изисквания за използване на CUBE HA като локален шлюз за преодоляване на повиквания със състояние на отказ:
CUBE HA не може да има съвместно разположени TDM или аналогови интерфейси
Gig1 и Gig2 се наричат интерфейси за трафик (SIP/ RTP), а Gig3 е интерфейс за управление/данни на групата за резервиране (RG)
Не повече от 2 двойки CUBE HA могат да бъдат поставени в един и същ домейн на слой 2, единият с идентификатор на група 1, а другият с идентификатор на група 2. Ако конфигурирате 2 HA двойки със същия идентификатор на групата, интерфейсите за управление/данни на RG трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
Порт каналът се поддържа както за интерфейси за управление на RG/данни, така и за трафик
Цялата сигнализация/медия се доставя от/към виртуалния IP адрес
Всеки път, когато платформата се презареди в CUBE-HA връзка, тя винаги се зарежда като Standby
Долният адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
Идентификатор на интерфейса за излишък, rii трябва да е уникален за комбинация от двойка/интерфейс на същия слой 2
Конфигурацията и на двата CUBE трябва да бъде идентична, включително физическа конфигурация и трябва да работи на същия тип платформа и версия на IOS-XE
Интерфейсите за обратна връзка не могат да се използват като обвързване, тъй като винаги са нагоре
Множество интерфейси за трафик (SIP/ RTP) (Gig1, Gig2) изискват конфигуриране на проследяване на интерфейса
CUBE-HA не се поддържа през кръстосана кабелна връзка за RG-контрол/връзка за данни (Gig3)
И двете платформи трябва да бъдат идентични и да бъде свързан чрез a физически превключвател през всички подобни интерфейси, за да може CUBE HA да работи, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да приключи на един и същ ключ и т.н.
Не може да има терминиран WAN на CUBE директно или на данни HA от двете страни
И двата активни/готови трябва да са в един и същ център за данни
Задължително е използването на отделен L3 интерфейс за резервиране (RG Control/data, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за поддържане на HA и контролни точки
При отказ, по-рано активният CUBE преминава през презареждане по проект, запазвайки сигнализацията и медиите
Конфигурирайте излишък и на двата CUBE
Трябва да конфигурирате резервиране от кутия до кутия от слой 2 и на двата CUBE, предназначени да бъдат използвани в HA двойка, за да изведете виртуални IP адреси.
| 1 | Конфигурирайте проследяване на интерфейса на глобално ниво, за да проследявате състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса на гласов трафик , така че активният маршрут да изпълнява своята активна роля, след като интерфейсът за трафик не работи. | ||||||
| 2 | Конфигурирайте RG за използване с VoIP HA в подрежим на резервиране на приложения.
Ето обяснение на полетата, използвани в тази конфигурация:
| ||||||
| 3 | Разрешете резервирането от кутия до кутия за приложението CUBE. Конфигурирайте RG от предишната стъпка по-долу
група за съкращения 1 —Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||||||
| 4 | Конфигурирайте интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу и приложете идентификатора на интерфейса за резервиране ( рии )
Ето обяснение на полетата, използвани в тази конфигурация:
| ||||||
| 5 | Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане последно винаги е режим на готовност.
След VCUBE-1 се стартира напълно, запазете конфигурацията на VCUBE-2 и го презаредете.
| ||||||
| 6 | Проверете дали конфигурацията от кутия до кутия работи според очакванията. Съответният изход е подчертан в смели . Презаредихме VCUBE-2 последно и според съображения на дизайна; платформата за презареждане последна винаги ще бъде В режим на готовност . |
Конфигурирайте локален шлюз и на двата CUBE
В нашата примерна конфигурация ние използваме следната информация за магистралата от Control Hub, за да изградим конфигурацията на локалния шлюз и на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
Потребителско име: Хюсеин 1076 г_ LGU
Парола: lOV12MEaZx
| 1 | Уверете се, че за паролата е създаден конфигурационен ключ с командите, показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите от тип 6 са криптирани с помощта на AES шифър и този дефиниран от потребителя конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на Контролен център параметри, показани по-горе, запишете и презаредете. SIP обработване на пълномощията от Контролен център са подчертани в смели .
За да покажем изхода на командата show, презаредихме VCUBE-2 последвано от VCUBE-1 , правене VCUBE-1 готовност CUBE и VCUBE-2 активният КУБ |
| 2 | Във всеки един момент само една платформа ще поддържа активна регистрация като локален шлюз с Webex Calling достъп SBC. Разгледайте изхода на следните команди за показване. показване на група приложения за съкращаване 1 покажете състоянието на регистъра на sip-ua
От изхода по-горе можете да видите това VCUBE-2 е активният LGW, поддържащ регистрацията с Webex Calling access SBC, докато изходът на „show sip-ua register status“ е празен в VCUBE-1 |
| 3 | Сега активирайте следните отстраняване на грешки на VCUBE-1
|
| 4 | Симулирайте отказ, като издадете следната команда на активния LGW, VCUBE-2 в този случай.
Превключването от ACTIVE към STANDBY LGW се случва в следния сценарий, освен CLI, изброен по-горе
|
| 5 | Проверете дали VCUBE-1 се е регистрирал в Webex Calling access SBC. VCUBE-2 вече щеше да се презареди.
VCUBE-1 вече е активният LGW. |
| 6 | Вижте съответния регистрационен файл за отстраняване на грешки на VCUBE-1, изпращащ SIP РЕГИСТЪР до Webex Calling ПРЕЗ виртуалния IP и получаване на 200 ОК.
|
Конфигуриране на профил за защита на SIP линиите за магистрала към локален шлюз
В случаите, когато локалният шлюз и шлюз за обществена телефонна централа се намират на едно и също устройство, Unified CM трябва да бъде активиран да разграничава два различни типа трафик (повиквания от Webex и от PSTN), които произхождат от едно и също устройство и да прилага диференциран клас на услугата към тях видове повиквания. Това диференцирано третиране на повикванията се постига чрез осигуряване на две магистрали между Unified CM и комбинирания локален шлюз и шлюз за обществена телефонна централа устройство, което изисква различни SIP портове за слушане за двата канала.
Създайте специален профил за защита на SIP линиите за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Конфигурирайте SIP профил за локалната магистрала на шлюза
Създайте специален SIP профил за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Създайте пространство за търсене на обаждания за обаждания от Webex
Създайте пространство за търсене на обаждания за повиквания, произхождащи от Webex със следните настройки:
| ||||||||||||
Конфигурирайте SIP транк към и от Webex
Създайте външна линия SIP за повикванията към и от Webex през локалния шлюз със следните настройки:
| ||||||||||||||||||||||||||
Конфигуриране на група маршрути за Webex
Създайте група маршрути със следните настройки:
| ||||||||
Конфигуриране на списък с маршрути за Webex
Създайте списък на маршрути със следните настройки:
| ||||||||||||||
Създайте дял за Webex дестинации
Създайте дял за дестинациите на Webex със следните настройки:
| ||||||||
Какво да направите след това
Уверете се, че сте добавили този дял към всички пространства за търсене на повиквания, които трябва да имат достъп до дестинациите на Webex . Трябва да добавите този дял специално към пространството за търсене на повиквания, което се използва като пространство за търсене на входящи повиквания в PSTN магистрали, така че повикванията от PSTN към Webex да могат да се насочват.
Конфигуриране на шаблони за маршрути за дестинации на Webex
Конфигурирайте модели на маршрути за всеки диапазон на DID на Webex със следните настройки:
| ||||||||||||
Конфигуриране на съкратено нормализиране на междусайтово набиране за Webex
Ако за Webex се изисква съкратено набиране между сайтове, тогава конфигурирайте модели за нормализиране на набиране за всеки диапазон на ESN на Webex със следните настройки:
| ||||||||||||||||||
Създайте група за търсене
Групите за търсене насочват входящите повиквания към група потребители или работни пространства. Можете дори да конфигурирате шаблон за маршрут към цяла група.
За повече информация как да настройвам група за търсене, вж Търсене на групи в Cisco Webex Control Hub .
Създаване на опашка на повикванията
Можете да настройвам опашка за обаждания, така че когато обажданията на клиентите не могат да бъдат отговорени, те получават автоматичен отговор, утешителни съобщения и музика в задържане , докато някой може да отговори на повикването им.
За повече информация как да настройвам и управлявате опашка за повиквания, вж Управлявайте опашките за обаждания в Cisco Webex Control Hub .
Създайте рецепционист клиент
Помогнете в подкрепа на нуждите на персонала на вашия фронт-офис. Можете да настройвам потребителите като телефонни служители, за да могат да преглеждат входящите повиквания до определени хора във вашата организация.
За информация как да настройвам и прегледате клиентите на рецепционистите, вж Клиенти на рецепцията в Cisco Webex Control Hub .
Създавайте и управлявайте автоматични служители
Можете да добавяте поздрави, да настройвам менюта и да маршрутизиране на повиквания към телефонен секретар, група за търсене, кутия за гласова поща или реален човек. Създайте 24-часов график или предоставете различни опции, когато вашият бизнес е отворен или затворен.
За информация как да създавате и управлявате автоматични оператори, вж Управлявайте автоматичните оператори в Cisco Webex Control Hub .
Конфигурирайте група за пейджинг
Груповото пейджинг позволява на потребителя да отправи еднопосочно обаждане или групова страница до до 75 целеви потребители и работни пространства чрез набиране на номер или разширение, присвоени на конкретна група за пейджинг.
За информация как да настройвам и редактирате групи за пейджинг, вж Конфигурирайте група за пейджинг в Cisco Webex Control Hub .
Настройте вдигане на обаждане
Подобрете работата в екип и сътрудничеството, като създадете група за приемане на повикване, така че потребителите да могат да отговарят на повиквания. Когато добавите потребители към група за приемане на група за приемане на повикване и член на групата е далеч или зает, друг член може да отговаря на техните повиквания.
За информация как да настройвам за приемане на група за приемане на повикване вж Вземане на обаждане в Cisco Webex Control Hub .
Настройте паркиране на повиквания
Паркиране на повиквания позволява на определена група потребители да паркират повиквания срещу други налични членове на групата за паркиране на повиквания. Паркираните обаждания могат да бъдат приемани от други членове на групата на техния телефон.
За повече информация как да настройвам паркиране на повиквания, вж Паркиране на обажданията в Cisco Webex Control Hub .
Активиране на влизане за потребители
| 1 | От изглед на клиента в , отидете на Управление > Местоположения .https://admin.webex.com |
| 2 | Изберете потребител и щракнете Обаждане . |
| 3 | Отидете до Разрешения между потребители раздел и след това изберете Влезте . |
| 4 | Включете превключвателя, за да позволите на други потребители да се добавят към текущото обаждане на този потребител. |
| 5 | Проверете Пуснете тон, когато този потребител влезе в разговор ако искате да пуснете тон на другите, когато този потребител нахлуе в тяхното обаждане. |
| 6 | Щракнете върху Запиши. |
Активиране на поверителност за потребител
| 1 | Влезте в Контролен център , и отидете на . | ||
| 2 | Изберете потребител и щракнете Обаждане . | ||
| 3 | Отидете до Разрешения между потребители област и след това изберете Поверителност . | ||
| 4 | Изберете подходящия Поверителност на автоматичния оператор настройки за този потребител.
| ||
| 5 | Проверете Активирайте поверителност поле за отметка. След това можете да решите да блокирате всички, като не избирате членове от падащ списък. Като алтернатива можете да изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състояние на линията на този потребител. Ако сте администратор на местоположение, в падащ списък се показват само потребителите, работните пространства и виртуалните линии, отнасящи се до назначените ви местоположения. Премахнете отметката от Активирайте поверителност поле за отметка, за да позволите на всеки да наблюдава състояние на линията. | ||
| 6 | Проверете Прилагане на поверителност за насочено приемане на повикване и влизане поле за отметка, за да активирате поверителност за насочено приемане на повикване и влизане.
| ||
| 7 | От Добавете член по име , изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състоянието на телефонна линия и да извикат насочено приемане на повикване и влизане. | ||
| 8 | За да филтрирате избраните от вас членове, използвайте филтриране по име, номер или вътр поле. | ||
| 9 | Щракнете върху Премахване на всички за да премахнете всички избрани членове.
| ||
| 10 | Щракнете върху Запиши. |
Конфигуриране на наблюдение
максимален брой наблюдавани линии за потребител е 50. Въпреки това, докато конфигурирате списъка за наблюдение, вземете предвид броя на съобщенията, които влияят на честотната лента между Webex Calling и вашата мрежа. Също така, определете максималните наблюдавани линии по броя на бутоните за линии на телефона на потребителя.
| 1 | От изглед на клиента вhttps://admin.webex.com , отидете на Управление и след това щракнете Потребители . | ||||
| 2 | Изберете потребителя, който искате да промените, и щракнете Обаждане . | ||||
| 3 | Отидете на Разрешения между потребители раздел и изберете Мониторинг . | ||||
| 4 | Изберете от следните:
Можете да включите виртуална линия в Добавете наблюдавана линия списък за потребителски мониторинг. | ||||
| 5 | Изберете дали искате да уведомите този потребител за паркирани повиквания, потърсете лицето или вътрешна линия за паркиране на повикване за паркиране на обаждания, което да бъде наблюдавано, и след това щракнете Запазете .
|
Активиране на предупредителния тон за свързване на повиквания за потребителите
Преди да започнете
| 1 | Влезте в Контролен център , и отидете на . | ||
| 2 | Изберете потребител и щракнете върху раздела Повиквания. | ||
| 3 | Отидете на Разрешения между потребители и щракнете Предупредителен тон за свързване на повикване . | ||
| 4 | Включете Предупредителен тон за свързване на повикване и след това щракнете Запазете .
За повече информация относно свързването на повиквания по споделена линия, вж Споделени линии на вашия мултиплатформен настолен телефон . За повече информация относно свързването на повиквания на споделена линия на Webex App вж Споделен изглед на линията за WebexApp . |
Включете хотела за потребител
| 1 | От изглед на клиента вhttps://admin.webex.com , отидете на Управление и изберете Потребители . | ||
| 2 | Изберете потребител и щракнете върху раздела Повиквания. | ||
| 3 | Отидете до Разрешения между потребители раздел и изберете Хотелиерство и включете превключвателя. | ||
| 4 | Въведете името или номера на хоста в хотела в Местоположение на хотела поле за търсене и изберете хоста за хотели, който искате да присвоите на потребителя. Може да бъде избран само един хостел. Ако изберете друг хост за хотели, първият се изтрива.
| ||
| 5 | За да ограничите времето, през което потребителят може да бъде свързан с хоста за хотели, изберете броя часове, през които потребителят може да използва хотелския хост от Лимитен период на асоцииране падащо меню. Потребителят ще излезе автоматично след избраното време.
| ||
| 6 | Щракнете върху Запиши.
|
Преглед на отчетите за обажданията
Можете да използвате страницата Анализ в Контролен център за да получите представа за това как хората използват Webex Calling и на Webex приложение (ангажиране) и качеството на медийното им изживяване при разговори. За достъп Webex Calling analytics, влизам в Контролен център , след това отидете на Анализ и изберете Обаждане раздел.
| 1 | За подробни отчети за историята на обажданията влизам в Контролен център , след това отидете на Анализ > Обаждане . |
| 2 | Изберете Подробна история на обажданията . За информация относно повиквания, използващи Специализиран екземпляр, вж Анализ на специализирани инстанции . |
| 3 | За достъп до данни за качество на медиите, влизам в Контролен център , след това отидете на Анализ и след това изберете Обаждане . За повече информация вижте Анализи за вашето портфолио за сътрудничество в облака.
|
Стартирайте инструмента CScan
CScan е инструмент за готовност на мрежата, предназначен да тества вашата мрежова връзка Webex Calling .
За повече информация вж Използвайте CScan, за да тествате качеството на мрежата за Webex Calling . |
Подготовка на средата
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling, уверете се, че:
-
Имате основни познания за принципите на VoIP
-
Имате основни работни познания за гласовите концепции на Cisco IOS-XE и IOS-XE
-
Имайте основно разбиране за Session Initiation Protocol (SIP)
-
Имате основно разбиране за Cisco Унифициран комуникационен мениджър (Unified CM), ако вашият модел за внедряване включва Unified CM
Вижте Ръководство за корпоративна конфигурация на Cisco Unified Border Element (CUBE). за подробности.
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че вашето внедряване има един или повече от локалните шлюзове, като например:
-
Cisco CUBE за IP-базирана свързаност
-
Cisco IOS Gateway за TDM-базирана свързаност
локален шлюз ви помага да мигрирате към Webex Calling със собствено темпо. локален шлюз интегрира вашето съществуващо в помещението внедряване с Webex Calling. Можете също да използвате съществуващата си Връзка с обществена телефонна централа. Виж Започнете с Local Gateway
Изисквания за лиценз за местни портали
Лицензите за повикване на CUBE трябва да бъдат инсталирани на местния портал. За повече информация вижте Ръководствотоза конфигурация на единния граничен елемент на Cisco.
Изисквания за сертификат и сигурност за местния портал
Webex Call изисква сигурна сигнализация и медии. Локалният шлюз извършва криптирането и трябва да се установи TLS връзка, изходяща към облака със следните стъпки:
-
LGW трябва да се актуализира с CA кореновия пакет от Cisco PKI
-
Набор от идентификационни данни за SIP digest от страницата за конфигуриране на багажника на Control Hub се използват за конфигуриране на LGW (стъпките са част от конфигурацията, която следва)
-
CA корен пакет валидира представения сертификат
-
Подканен за пълномощия (SIP digest предоставен)
-
Облакът идентифицира кой локален портал е сигурно регистриран
Защитна стена, 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 за вашата организация
Първата стъпка, за да получите вашите Webex Calling услуги нагоре и работи е да завършите съветника за настройка за първи път (FTSW). След като FTSW е завършен за първото ви местоположение, не е необходимо да бъде завършен за допълнителни места.
| 1 |
Кликнете върху връзката "Първи стъпки" в имейла " Добре дошли", който получавате. Имейл адресът ви на администратор се използва автоматично за влизане в контролния център, където ще бъдете подканени да създадете паролата си за администратор. След като влезете, съветникът за настройка автоматично започва. |
| 2 |
Прегледайте и приемете условията за ползване. |
| 3 |
Прегледайте плана си и след това щракнете върху Започнете. Вашият мениджър на акаунта е отговорен за активирането на първите стъпки за FTSW. Свържете се с мениджъра на профила си, ако получите известие "Не може да настроите обаждането си", когато изберете Get Start. |
| 4 |
Изберете държавата, в която вашият център за данни трябва да картографира, и въведете информацията за контакт с клиента и адреса на клиента. |
| 5 |
Кликнете върху Следващия: Местоположениепо подразбиране. |
| 6 |
Изберете от следните опции:
След като завършите съветника за настройка, уверете се, че добавяте основен номер към мястото, което създавате . |
| 7 |
Направете следните селекции, за да кандидатствате за това място:
|
| 8 |
Щракнете върху Напред. |
| 9 |
Въведете наличен SIP адрес на Cisco Webex и щракнете върху Напред и изберете Готово. |
Преди да започнете
За да създадете ново местоположение, подгответе следната информация:
-
Адрес на местоположението
-
Желани телефонни номера (по избор)
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . В регионалния център за данни ще се хоства ново местоположение, което съответства на държавата, която сте избрали с помощта на Помощник за първоначална настройка. |
| 2 |
Конфигуриране на настройките на местоположението:
|
| 3 |
Щракнете върху Запиши и след това изберете Да/ Не , за да добавите номера към местоположението сега или по-късно. |
| 4 |
Ако щракнете върху Да, изберете една от следните опции:
Изборът на опция PSTN е на всяко ниво на местоположение (всяко местоположение има само една опция PSTN). Можете да смесвате и съчетавате толкова опции, колкото искате за разполагането си, но всяко място ще има една опция. След като сте избрали и предоставили опция PSTN, можете да я промените, като щракнете върху Управление в свойствата на PSTN за местоположение. Някои опции, като например Cisco PSTN, обаче може да не са налични, след като е възложена друга опция. Отворете заявка за случай на поддръжката за насоки. |
| 5 |
Изберете дали искате да активирате числата сега или по-късно. |
| 6 |
Ако сте избрали неинтегриран ЦК или PSTN, базиран на помещения, въведете телефонни номера като стойности, разделени със запетая, и след това щракнете върху Валидиране. Числата се добавят за конкретното местоположение. Валидните записи се преместват в полето "Валидирани числа" и невалидните записи остават в полето "Добавяне на числа ", придружено от съобщение за грешка. В зависимост от страната на местоположението, номерата се форматират според местните изисквания за набиране. Например, ако се изисква код на държава, можете да въведете номера със или без кода и кодът е предназначен. |
| 7 |
Щракнете върху Запиши. |
Какво да направите след това
След като създадете местоположение, можете да разрешите спешни 911 услуги за това местоположение. Вижте RedSky Emergency 911 услуга за Webex Призоваване за повече информация.
Преди да започнете
Получете списък на потребителите и работните пространства, свързани с местоположение: Отидете на и от падащото меню изберете местоположението, което трябва да бъде изтрито. Трябва да изтриете тези потребители и работни пространства, преди да изтриете местоположението.
Имайте предвид, че всички номера, свързани с това местоположение, ще бъдат освободени обратно към вашия PSTN доставчик; вече няма да притежавате тези номера.
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . |
| 2 |
Щракнете върху |
| 3 |
Изберете Изтриване на местоположениетои потвърдете, че искате да изтриете това местоположение. Обикновено отнема няколко минути, за да може местоположението да бъде окончателно изтрито, но може да отнеме до час. Можете да проверите състоянието, като щракнете |
Можете да промените настройката на PSTN, името, часовата зона и езика на дадено местоположение, след като е създадено. Имайте предвид обаче, че новият език се прилага само за нови потребители и устройства. Съществуващите потребители и устройства продължават да използват стария език.
За съществуващи локации можете да разрешите спешни 911 услуги. Вижте RedSky Emergency 911 услуга за Webex Призоваване за повече информация.
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . Ако видите символ за предпазливост до местоположение, това означава, че все още не сте конфигурирали телефонен номер за това местоположение. Не можете да правите или получавате обаждания, докато не конфигурирате този номер. |
| 2 |
(по избор) Под PSTN връзкаизберете PSTN или PSTN ( локален шлюз), в зависимост от това кой вече сте конфигурирали. Щракнете върху Управете , за да промените тази конфигурация и след това да потвърдите свързаните рискове, като изберете Продължи. След това изберете една от следните опции и щракнете върху Запиши:
|
| 3 |
За местоположението изберете Основен номер от падащ списък , за да позволите на потребителите в това местоположение да извършват и получават повиквания. В Основен номер може да бъде присвоен към автоматичен секретар , така че външните обаждащи се да могат да се свържат с потребителите на Webex Calling на това място. Потребителите на Webex Calling в това местоположение могат също да използват този номер като свой външен идентификатор на ИД се, когато извършват повиквания. |
| 4 |
(по избор) При спешни повикванияможете да изберете идентификатор за аварийно местоположение, за да присвоите на това място. Тази настройка е незадължителна и е приложима само за държави, които я изискват. В някои страни (пример: Франция), съществуват регулаторни изисквания за клетъчните радиосистеми, за да се установи самоличността на клетката, когато провеждате спешно повикване и се предоставя на службите за спешна помощ. Други страни като САЩ и Канада прилагат определяне на местоположението, използвайки други методи. За повече информация вижте Засилено спешно повикване. Вашият доставчик на спешни повиквания може да се нуждае от информация за мрежата за достъп и се постига чрез дефиниране на нов частен заглавка за разширение на SIP, P-Access-Network-Info. Заглавката носи информация, свързана с мрежата за достъп. Когато зададете идентификатора за аварийно местоположение за местоположение, стойността на местоположението се изпраща на доставчика като част от SIP съобщението. Свържете се с вашия доставчик на спешни повиквания, за да видите дали имате нужда от тази настройка и използвайте стойността, която е предоставена от вашия доставчик на спешни повиквания. |
| 5 |
Изберете номера на гласовата поща, на който потребителите могат да се обадят, за да проверят гласовата си поща за това местоположение. |
| 6 |
(по избор) Щракнете върху иконата за молив в горната част на страницата Местоположение, за да промените иметона местоположението, езика за обявяване, езикана имейла, часовата зонаили адреса , ако е необходимо, и след това щракнете върху Save. Промяната на езика за обявяване влиза в сила незабавно за всички нови потребители и функции, добавени към това местоположение. Ако съществуващите потребители и/или функции също трябва да променят езика си за обявяване, когато са подканени, изберете Промяна за съществуващи потребители и работни пространства или Промяна за съществуващи функции. Щракнете върху Приложи. Можете да видите напредъка на страницата Задачи . Не можете да направите повече промени, докато това не приключи. Промяната на часовата зона за местоположение не актуализира часовите зони на функциите, свързани с местоположението. За да редактирате часовите зони за функции като автопридружител, ловна група и опашка за обаждания, отидете в областта Общи настройки на конкретната функция, за която искате да актуализирате часовата зона и да редактирате и запишете там. |
Тези настройки са за вътрешно набиране и също са налични в съветника за настройка за първи път. Докато променяте своя план за набиране, примерните номера в Control Hub се актуализират, за да покажат тези промени.
Можете да конфигурирате изходящи разрешения за повикване за местоположение. Вижте тези стъпки , за да конфигурирате разрешенията за изходящи повиквания.
| 1 |
Влезте в Контролен център , отидете на и след това превъртете до Вътрешно набиране . |
| 2 |
Конфигурирайте следните незадължителни предпочитания за набиране, ако е необходимо:
|
| 3 |
Посочете вътрешно набиране за конкретни места. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете вътрешното набиране, ако е необходимо:
|
| 4 |
Посочете външно набиране за конкретни местоположения. Отидете на , изберете местоположение от списъка и щракнете Обаждане . Превъртете до Набиране и след това променете външното набиране, ако е необходимо:
Въздействие върху потребителите:
|
Ако сте препродавач с добавена стойност, можете да използвате тези стъпки, за да започнете локална конфигурация на шлюза в Control Hub. Когато този шлюз е регистриран в облака, можете да го използвате на едно или повече от вашите местоположения на Webex Calling , за да осигурите маршрутизиране към доставчик на услуги за PSTN на предприятието.
Място, което има локален портал, не може да бъде изтрито, когато местният портал се използва за други места.
Преди да започнете
-
След като се добави местоположение и преди да конфигурирате PSTN на базата на помещения за местоположение, трябва да създадете багажник.
-
Създайте всички местоположения и конкретни настройки и числа на всеки един. Местоположенията трябва да съществуват, преди да можете да добавите PSTN, базиран на помещения.
-
Разберете изискванията на PSTN (локален шлюз) за Webex Calling.
-
Не можете да изберете повече от един багажник за местоположение с PSTN, базиран на помещения, но можете да изберете един и същ багажник за няколко места.
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , отидете на и изберете Добавяне на багажника . |
| 2 |
Изберете местоположение. |
| 3 |
Назовете багажника и щракнете върху Save. Името не може да бъде по-дълго от 24 знака. |
Какво да правим по-нататък
Информацията за багажника се появява на домейнана екрана , групата на багажника OTG/DTG, линията/портаи изходящия прокси адрес.
Препоръчваме ви да копирате тази информация от Контролния център и да я поставите в локален текстов файл или документ, така че да можете да се обърнете към нея, когато сте готови да конфигурирате pstN базираните на помещения.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за багажника в контролния център. Щракнете върху Извличане на потребителско име и нулиране на паролата, за да генерирате нов набор от идентификационни данни за удостоверяване , които да използвате в багажника.
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . |
| 2 |
Изберете местоположение, за да промените и щракнете върху Управление. |
| 3 |
Изберете PSTN на базата на помещения и щракнете върху Напред. |
| 4 |
Изберете багажник от падащото меню. Посетете страницата на багажника, за да управлявате избора на групата на багажника. |
| 5 |
Щракнете върху известието за потвърждение, след което щракнете върху Запиши. |
Какво да правим по-нататък
Трябва да вземете конфигурационната информация, която Control Hub генерира, и да картографирате параметрите в локалния шлюз (например на Cisco CUBE, който седи в помещенията). Тази статия ви превежда през този процес. Като препратка вижте следната диаграма например за това как информацията за конфигурацията на контролния хъб (вляво) картографира параметрите в CUBE (вдясно):
След като завършите успешно конфигурацията на самия шлюз, можете да се върнете към в Control Hub и създаденият от вас шлюз ще бъде изброен в картата за местоположение, към която сте го присвоили, със зелена точка вляво от името. Това състояние показва, че порталът е сигурно регистриран в облака за обаждания и служи като активен PSTN шлюз за местоположението.
Можете лесно да преглеждате, активирате, премахвате и добавяте телефонни номера за вашата организация в Control Hub. За повече информация вижте Управление на телефонни номера в Control Hub.
Ако изпробвате услугите на Webex и искате да конвертирате пробната си версия в платен абонамент, можете да подадете заявка за имейл до партньора си.
| 1 |
Влезте в Control Hub на адресhttps://admin.webex.com , изберете иконата на сграда |
| 2 |
Изберете раздела Абонаменти и след това щракнете върху Покупка сега. Имейл се изпраща на партньора ви, като им се съобщава, че се интересувате от конвертиране в платен абонамент. |
Можете да използвате контролния център, за да зададете приоритета на наличните опции за извикване, които потребителите виждат в Webex App. Можете също така да ги разрешите за еднократно кликване за повикване. За повече информация вижте: Задайте опции за повикване за потребители на Webex App .
Можете да контролирате какво приложение за повиквания се отваря, когато потребителите извършват обаждания. Можете да конфигурирате настройките на клиента за повиквания, включително внедряване в смесен режим за организации с потребители, които имат право на Unified CM или Webex Calling , и потребители без платени услуги за обаждания от Cisco. За повече информация вижте: Настройте поведение при повикване .
Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
Общ преглед
В момента Webex Calling поддържа две версии на локален шлюз:
-
Локален шлюз
-
Локален шлюз за Webex за правителството
-
Преди да започнете, разберете изискванията на базираната в помещенията обществена комутирана телефонна мрежа (PSTN) и локалния шлюз (LGW) за обажданията чрез Webex Calling. Вижте Cisco Предпочитана архитектура за Webex Призоваване за повече информация.
-
Тази статия предполага, че е налице специална платформа на Local Gateway без съществуваща гласова конфигурация. Ако модифицирате съществуващ шлюз за обществена телефонна централа или внедряване на CUBE Enterprise, за да се използва като функция Local Gateway за Webex Calling, тогава обърнете внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци и функционалност на повикванията поради промените, които правите.
За информация относно поддържаните SBC на трети страни вижте съответната референтна документация на продукта.
Има две опции за конфигуриране на локалния портал за вашия багажник за повикване на Webex:
-
Багажник, базиран на регистрация
-
Багажник, базиран на сертификат
Използвайте потока на задачите или под Локален шлюз, базиран на регистрация или Базиран на сертификат локален шлюз за да конфигурирате локален шлюз за вашата линия за Webex Calling .
Виж Започнете с Local Gateway за повече информация относно различните типове багажници. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Ние използваме Session Initiation Protocol (SIP) и Защита на транспортния слой (TLS), за да защитим магистралата и защитен протокол в реално време (SRTP), за да защитим носителя между локалния шлюз и Webex Calling.
-
Изберете CUBE като ваш локален шлюз. Понастоящем Webex for Government не поддържа никакви гранични контролери на сесии (SBC) на трети страни. За да прегледате последния списък, вж Започнете с Local Gateway .
- Инсталирайте Cisco IOS XE Dublin 17.12.1a или по-нови версии за всички Webex за правителствени локални шлюзове.
-
За да прегледате списъка с основни сертифициращи органи (CA), които Webex поддържа за правителство, вж Коренни сертифициращи органи за Webex за правителство .
-
За подробности относно диапазоните на външни портове за локален шлюз в Webex за правителство, вж Мрежови изисквания за Webex за правителство (FedRAMP) .
Локален шлюз за Webex за правителството не поддържа следното:
-
STUN/ICE-Lite за оптимизиране на медийния път
-
факс (T.38)
За да конфигурирате локален шлюз за вашата линия за Webex Calling на Webex в Webex за правителство, използвайте следната опция:
-
Багажник, базиран на сертификат
Използвайте потока от задачи под Базиран на сертификат локален шлюз за да конфигурирате локалния шлюз за вашата линия за Webex Calling . За повече подробности как да конфигурирате базиран на сертификат локален шлюз, вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Задължително е да конфигурирате FIPS-съвместими GCM шифри, за да поддържате локален шлюз за Webex за правителство. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, като се използва регистриране на външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Изображението по-долу подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде следвана.
В този дизайн се използват следните основни конфигурации:
-
наематели на гласов клас: Използва се за създаване на специфични за багажника конфигурации.
-
гласов клас uri: Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
-
входяща точка за набиране: Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
-
група за набиране: Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
-
изходящ диск за набиране: Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Докато IP и SIP се превърнаха в протоколи по подразбиране за PSTN магистрали, TDM (Time Division Multiplexing) ISDN вериги все още се използват широко и се поддържат с връзките на Webex Calling . За да се активира медийна оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, понастоящем е необходимо да се използва двуетапен процес за маршрутизиране на повикване . Този подход модифицира конфигурацията за маршрутизиране на повикване , показана по-горе, като въвежда набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали, както е показано на изображението по-долу.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
-
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
-
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
-
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
-
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
-
Всички базирани на регистрация внедрявания на локален шлюз изискват Cisco IOS XE 17.6.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
-
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
-
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
-
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
-
NTP
-
АКЛ
-
Удостоверяване на потребителя и дистанционен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес.
-
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
|
| 2 |
Защитете идентификационните данни за регистрация и STUN на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва:
|
| 3 |
Създайте заместваща PKI точка на доверие. Изисква тази точка на доверие за конфигуриране на TLS по-късно. За базирани на регистрация магистрали, тази точка на доверие не изисква сертификат - както би било необходимо за базирана на сертификат магистрала. |
| 4 |
Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация. Транспортните параметри също трябва да бъдат актуализирани, за да се гарантира надеждна защитена връзка за регистрация: Командата на сървъра cn-san-validate гарантира, че локалният шлюз позволява връзка, ако име на домакина, конфигурирано в клиент 200, е включено в полетата CN или SAN на сертификата, получен от изходящия прокси сървър.
|
| 5 |
Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA: ip http клиент прокси-сървър yourproxy.com прокси порт 80 |
| 1 |
Създайте базирана на регистрация PSTN магистрала за съществуващо местоположение в Control Hub. Отбележете информацията за магистралата, която се предоставя след създаването на магистрала. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling . |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. медийна статистикаПозволява медиен мониторинг на местния портал. медийни масови статистикиПозволява на контролната равнина да анкетира равнината на данните за статистика на насипните повиквания. За повече информация относно тези команди вж Медия . разрешаване на връзки глътка до глъткаАктивирайте CUBE основната SIP функция на потребителски агент отзад до гръб. За повече информация вж Разрешаване на връзки . По подразбиране транспортирането на факс T.38 е разрешено. За повече информация вж факс протокол t38 (гласова услуга) . Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . |
| 3 |
Конфигуриране кодек за гласов клас 100 филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вж кодек за гласов клас . Кодек Opus се поддържа само за PSTN канали, базирани на SIP. Ако PSTN магистралата използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитание за кодек 1 опус от кодек за гласов клас 100 конфигурация. |
| 4 |
Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . Ето обяснение на полетата за конфигурацията: зашеметяващо използване ice liteИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite . Имате нужда от зашеметяващо използване на ICE-lite за потоци от разговори, използващи оптимизация на медийния път. За да осигурите медийна оптимизация за шлюз SIP към TDM, конфигурирайте loopback dial-peer с активиран ICE-Lite на IP- IP крака. За допълнителни технически подробности се свържете с екипите на акаунта или TAC |
| 5 |
Конфигурирайте политиката за криптиране на медиите за трафика на Webex . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1_ 80 За повече информация вж гласов клас srtp-crypto . |
| 6 |
Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на параметъра на неговата дестинационна магистрала: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте dtg=, последвано от стойността на Trunk OTG/DTG, предоставена в Control Hub при създаването на магистрала. За повече информация вж глас клас uri . |
| 7 |
Конфигуриране глътка профил 100 , който ще се използва за модифициране на SIP съобщения, преди да бъдат изпратени до Webex Calling.
Ето обяснение на полетата за конфигурацията:
|
| 8 |
Конфигуриране на магистрала за Webex Calling : |
След като дефинирате наемател 100 и конфигуриране на SIP VoIP dial-peer, шлюзът инициира TLS връзка към Webex Calling. В този момент SBC за достъп представя своя сертификат на локалния шлюз. Локалният шлюз потвърждава сертификата за достъп на Webex Calling SBC, използвайки коренния пакет на CA, който беше актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп за Webex Calling . След това локалният шлюз може да използва тази защитена връзка , за да се регистрира в SBC за достъп на Webex . Когато регистрацията е оспорена за удостоверяване:
-
В потребителско име, парола, и царство параметри от пълномощията конфигурацията се използва в отговора.
-
Правилата за модификация в sip профил 100 се използват за преобразуване на SIPS URL обратно в SIP.
Регистрацията е успешна, когато се получи 200 ОК от SBC за достъп.
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN магистрала, преминете към следващия раздел Конфигурирайте локален шлюз с TDM PSTN магистрала .
За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI .
| 1 |
Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 |
Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Уточнява, че dial-peer 200 дръжки SIP кол крака. За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 |
Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
След като сте изградили транк към Webex Calling, използвайте следната конфигурация, за да създадете TDM trunk за вашата PSTN услуга с маршрутизиране на повикване с обратна линия, за да позволите оптимизиране на медиите на етап на повикването на Webex .
| 1 |
Конфигурацията за обратна връзка за набиране използва групи за набиране и маркери за маршрутизиране на повикване, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да създава цикли за маршрутизиране на повикване . Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрутизиране на повикване : Ето обяснение на полетата за конфигурацията: гласов превод-правилоИзползва регулярни изрази, дефинирани в правила, за добавяне или премахване на маркери за маршрутизиране на повикване . Превишените десетични цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация, етикетът, добавен от профил за превод 100, се използва за насочване на повиквания от Webex Calling към PSTN чрез loopback dial-peers. По същия начин, етикетът, добавен от профил за превод 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профили за превод 11 и 12 премахват тези тагове, преди да доставят повиквания съответно към магистралите на Webex и PSTN. Този пример предполага, че обажданите номера от Webex Calling са представени във формат + E.164 . Правило 100 премахва водещия +, за да поддържа валиден извикан номер. След това правило 12 добавя национална или международна цифра(и) за маршрутизиране при премахване на етикета. Използвайте цифри, които отговарят на вашия местен ISDN национален план за набиране. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да добавите и премахнете съответно маркера за маршрутизиране. За повече информация вж гласов превод-профил и гласов превод-правило . |
| 2 |
Конфигурирайте TDM портовете за гласов интерфейс, както се изисква от типа на магистрала и използвания протокол. За повече информация вж Конфигуриране на ISDN PRI . Например, основната конфигурация на ISDN интерфейс с първична скорост, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следната TDM PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . превод-профил входящ 200Присвоява профила за превод, който ще добави маркер за маршрутизиране на повикване към входящия извикан номер. директно набиране навътреНасочва повикването, без да предоставя вторичен тон за набиране. За повече информация вж директно набиране навътре . порт 0/2/0:15Физическият гласов порт, свързан с тази точка за набиране. |
| 4 |
За да активирате медийната оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, можете да промените маршрутизиране на повикване чрез въвеждане на набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали. Конфигурирайте следните точки за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат пренасочени първоначално към dial-peer 10, а оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахване на маркера за маршрутизиране, повикванията ще бъдат пренасочени към външна линия с помощта на групи за набиране. Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . превод-профил входящ 11Прилага профила за превод, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикване , преди да премине към външна линия. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва, че тази точка за набиране обработва етапите на SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията 192.168.80.14Указва адреса на интерфейса на локалния рутер като цел на повикване за връщане. За повече информация вж цел на сесията (voip dial peer) . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за съобщения, изпратени чрез обратна верига. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени чрез обратна верига. За повече информация вж обвързвам . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . кодек g711alaw Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответствате на метода за компандиране, използван от вашата ISDN услуга. без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 5 |
Добавете следната конфигурация за маршрутизиране на повикване : Това приключва конфигурацията на вашия локален шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE се конфигурират.
|
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
Когато създавате линията за Webex Calling в Unified CM, уверете се, че сте конфигурирали входящия порт в настройките на профил за защита на SIP линиите на 5065. Това позволява входящи съобщения на порт 5065 и попълване на VIA заглавката с тази стойност при изпращане на съобщения до локалния шлюз.
| 1 |
Конфигуриране на следните URI гласови класове: |
| 2 |
Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове: IOS XE използва тези записи за локално определяне на целеви UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тогава тези локални конфигурации не са необходими. Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060: Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com: Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com: Името на име на домакина за запис A. 192.168.80.65: IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. |
| 3 |
Конфигурирайте следните точки за набиране: |
| 4 |
Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми, като използвате съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди show.
Типовете действия включват събиране на командни изходи:
-
Генериране на консолидиран лог файл
-
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър.
Инженерите на TAC изписват DS файловете и дигитално ги подписват за защита на интегритета. Всеки DS файл има уникален цифров идентификатор, зададен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
-
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които променяте инсталацията за неуспех поради грешката при проверка на интегритета.
-
Прост протокол за прехвърляне на поща (SMTP) сървър, от който се нуждаете, за да може местният портал да изпраща известия по имейл.
-
Уверете се, че местният портал работи с IOS XE 17.6.1 или по-висока, ако искате да използвате защитения SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1a или по-нова версия
-
Диагностичните подписи са разрешени по подразбиране.
-
Конфигурирайте защитения имейл сървър, който да се използва за изпращане на проактивни известия, ако устройството работи с Cisco IOS XE 17.6.1a или по-нова версия.
конфигуриране на терминално повикване-домашен пощенски сървър : @ приоритет 1 защитен tls край -
Конфигурирайте променливата на средатаds_email с имейл адрес на администратора, за да Ви уведоми.
конфигуриране на среда за диагностичен подпис за повикване до домаds_email край
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1a или по-нова версия за изпращане на проактивни известия до tacfaststart@gmail.com използване на Gmail като защитен SMTP сървър:
Препоръчваме ви да използвате Cisco IOS XE Bengaluru 17.6.x или по-нови версии.
call-home mail-server tacfaststart:password@smtp.gmail.com приоритет 1 защитена среда за диагностичен подпис на tlsds_email "tacfaststart@gmail.com"Локален портал, работещ на Cisco IOS XE Software, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на профила в Gmail и да предоставим специално разрешение имейлът от устройството да бъде обработен правилно:
-
Отидете на и включете По-малко защитен достъп до приложения настройка.
-
Отговорете "Да, това бях аз", когато получавате имейл от Gmail, в който се казва: "Google попречи на някого да влезе в профила ви с помощта на приложение извън Google".
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява използването на CPU за пет секунди, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които са инсталирани в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Използвайте покажи snmp команда за активиране на SNMP. Ако не активирате, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Серия Cisco CSR 1000V
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Копирайте DS XML файла в светкавицата на локалния шлюз.
LocalGateway# копие ftp://username:password@ /DS_ 64224.xml начална флаш памет:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копирайте ftp://user:pwd@192.0.2.12/DS_ 64224.xml начална флаш памет: Достъп до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [ОК - 3571/4096 байта] 3571 байта, копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.comИзтегляне на DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително и себе си. Ако е необходимо, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг SIP багажник регистрация
Този DS проверява за нерегистрация на локален Gateway SIP багажник с облак Webex Calling на всеки 60 секунди. След като се открие събитието за отписване, то генерира известие по имейл и системен журнал и се деинсталира след две поява на дерегистрация. Използвайте стъпките по-долу, за да инсталирате подписа:
-
Изтеглете DS 64117, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
СИП-СИП
Тип на проблема
SIP Trunk Отписване на регистрацията с известие по имейл.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64117.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64117.xml Заредете файл DS_ 64117.xml успех LocalGateway# -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Мониторинг на абнормни прекъсвания на повикването
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Използвайте покажи snmp команда, за да проверите дали SNMP е активиран. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 65221.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 65221.xml Заредете файл DS_ 65221.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Използвайте диагностични подписи (DS), за да разрешите проблемите бързо. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на неизправности в даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая Cisco TAC. Диагностичните подписи (DS) премахват необходимостта от ръчна проверка за възникване на проблема и улесняват много по-лесно отстраняването на неизправности на периодични и преходни проблеми.
Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно разрешаване на даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето един пример за това как да намерите и инсталирате DS за откриване на събитието "%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0" syslog и автоматизира събирането на диагностични данни, като използва следните стъпки:
-
Конфигурирайте допълнителна променлива на средата на DSds_fsurl_prefix което е пътят на файлов сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка в следната команда. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, ако е необходимо.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_fsurl_prefix "scp:// : @cxd.cisco.com" крайПример:
среда за диагностика и подпис за обаждане вкъщиds_fsurl_prefix "околна средаds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Уверете се, че SNMP е активиран с помощта на покажи snmp команда. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager край -
Уверете се, че инсталирате High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет: копирайте ftp://потребителско име:парола@ /DS_ 65095.xml начална флаш памет: -
Инсталирайте High CPU мониторинг DS 64224 и след това DS 65095 XML файл в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех зареждане на DS за диагностика на повикване до дома_ 65095.xml Заредете файл DS_ 65095.xml успех -
Проверете дали подписът е инсталиран успешно с помощта на покажете диагностичен подпис за обаждане вкъщи команда. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comИзтеглени DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-08
65095
00:12:53
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверка на изпълнението на диагностичните подписи
В следващата команда колоната „Състояние“ на покажете диагностичен подпис за обаждане вкъщи командата се променя на „работеща“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът от статистиката за диагностичния подпис на повикването у дома е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Изтеглени DSes:
|
Идентификационен номер на DS |
Име на DS |
Преразглеждане |
Статус |
Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
Показване на статистика за диагностика-подпис на повикване-дома
|
Идентификационен номер на DS |
Име на DS |
Задейства се /Макс/Деинсталиране |
Средно време за изпълнение (секунди) |
Максимално време за изпълнение (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
1 /20/г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на даден проблем.
Деинсталиране на диагностични подписи
Използвайте диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинират като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи команда и изпълнете следната команда:
деинсталиране на диагностика за домашен подпис Пример:
деинсталиране на диагностичен подпис за обаждане до дома 64224 Периодично се добавят нови подписи към инструмента за справка за диагностични подписи, въз основа на проблеми, които обикновено се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
За по-добро управление на Cisco IOS XE Gateways, препоръчваме ви да регистрирате и управлявате шлюзовете чрез Control Hub. Това е опция по избор. Когато се регистрирате, можете да използвате опцията за валидиране на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате всички проблеми с конфигурацията. Понастоящем тази функционалност поддържат само базирани на регистрация канали.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, използвайки базиран на сертификат взаимна TLS (mTLS) външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Следното изображение подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде последвана.
В този дизайн се използват следните основни конфигурации:
-
наематели на гласов клас : Използва се за създаване на специфични за транк конфигурации.
-
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
-
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
-
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
-
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Докато IP и SIP се превърнаха в протоколи по подразбиране за PSTN магистрали, TDM (Time Division Multiplexing) ISDN вериги все още се използват широко и се поддържат с връзките на Webex Calling . За да се активира медийна оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, понастоящем е необходимо да се използва двуетапен процес за маршрутизиране на повикване . Този подход модифицира конфигурацията за маршрутизиране на повикване , показана по-горе, като въвежда набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали, както е показано на изображението по-долу.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение. Предоставени са опции за публично или частно (зад NAT) адресиране. SRV DNS записите не са задължителни, освен ако не се балансиране на товара в множество екземпляри на CUBE.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
-
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
-
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
-
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
Или:
-
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
-
Всички базирани на сертификати локални внедрявания на шлюз изискват Cisco IOS XE 17.9.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
-
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
-
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Essentials. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
За изисквания за висок капацитет може също да изисквате лиценз за висока сигурност (HSEC) и допълнително право на пропускателна способност.
Отнесете се към Кодове за оторизация за повече подробности.
-
-
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
-
NTP
-
АКЛ
-
Удостоверяване на потребителя и дистанционен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) на локалния шлюз или адресите на запис на услуги (SRV) трябва да се разрешават до публичен IPv4 адрес в интернет.
-
Всички SIP и медийни портове на интерфейса на локалния шлюз, обърнат към Webex , трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате съответно защитната си стена.
-
Инсталирайте подписан сертификат на локалния шлюз (по-долу са дадени подробни стъпки за конфигуриране).
-
Публичен орган за сертификати (CA), както е описано подробно в Какви основни центрове за сертифициране се поддържат за обаждания към аудио и видео платформи на Cisco Webex ? трябва да подпише сертификата на устройството.
-
FQDN , конфигуриран в Control Hub при създаване на магистрала, трябва да бъде сертификатът Common Name (CN) или Subject Alternate Name (SAN) на рутера. Например:
-
Ако конфигуриран транк в Control Hub на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на рутера трябва да съдържа cube1.lgw.com.
-
Ако конфигурирана магистрала в контролния център на вашата организация има lgws.lgw.com като SRV адрес на локалния(ите) шлюз(и), достъпен от магистралата, тогава CN или SAN в сертификата на рутера трябва да съдържа lgws.lgw.com. Записите, на които SRV адресът решава (CNAME, A Record или IP адрес), са незадължителни в SAN.
-
Независимо дали използвате FQDN или SRV за магистрала, адресът за контакт за всички нови SIP диалогови прозорци от вашия локален шлюз използва името, конфигурирано в Control Hub.
-
-
-
Уверете се, че сертификатите са подписани за използване от клиента и сървъра.
-
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
|
| 2 |
Защитете STUN идентификационните данни на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва: |
| 3 |
Създайте доверителна точка за криптиране със сертификат, подписан от предпочитания от вас орган за сертификати (CA). |
| 4 |
Удостоверете новия си сертификат, като използвате вашия междинен (или основен) СА сертификат, след което импортирайте сертификата (Стъпка 4). Въведете следната команда exec или конфигурация:
|
| 5 |
Импортирайте подписан сертификат за хост, като използвате следната команда exec или конфигурация:
|
| 6 |
Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация:
|
| 7 |
Инсталирайте пакета Cisco root CA, който включва СА сертификат DigiCert, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA: ip http клиент прокси-сървър yourproxy.com прокси порт 80 |
| 1 |
Създайте CUBE базирана на сертификат PSTN магистрала за съществуващо местоположение в Control Hub. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling . Отбележете информацията за магистралата, която се предоставя след създаването на багажника. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. разрешаване на връзки глътка до глъткаАктивирайте CUBE основния SIP обратно към гръб функционалност на потребителския агент. За повече информация вж Разрешаване на връзки . По подразбиране транспортирането на факс T.38 е разрешено. За повече информация вж факс протокол t38 (гласова услуга) . Разрешава STUN (обхождане на сесия на UDP през NAT) глобално. Тези глобални команди за зашеметяване са необходими само при разполагане на вашия локален шлюз зад NAT.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез dial-peers или наематели. |
| 3 |
Конфигуриране кодек за гласов клас 100 кодек филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вж кодек за гласов клас . Кодек Opus се поддържа само за PSTN канали, базирани на SIP. Ако PSTN магистралата използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитание за кодек 1 опус от кодек за гласов клас 100 конфигурация. |
| 4 |
Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: зашеметяващо използване ice liteИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite . В зашеметяващо използване на защитна стена за преминаване на поток данни командата се изисква само при разполагане на вашия локален шлюз зад NAT. Имате нужда от зашеметяващо използване на ICE-lite за потоци от разговори, използващи оптимизация на медийния път. За да осигурите медийна оптимизация за шлюз SIP към TDM, конфигурирайте loopback dial-peer с активиран ICE-Lite на IP- IP крака. За допълнителни технически подробности се свържете с екипите на акаунта или TAC. |
| 5 |
Конфигурирайте политиката за криптиране на медиите за трафика на Webex . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1_ 80 За повече информация вж гласов клас srtp-crypto . |
| 6 |
Конфигуриране на FIPS-съвместими GCM шифри (Тази стъпка е приложима само за Webex for Government) . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Посочва GCM като шифров пакет, който CUBE предлага. Задължително е да конфигурирате GCM шифри за локален шлюз за Webex за правителство. |
| 7 |
Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на неговото FQDN или SRV местоназначение: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте LGW FQDN или SRV, конфигурирани в Control Hub, докато създавате магистрала. |
| 8 |
Конфигурирайте профили за манипулиране на SIP съобщение . Ако вашият шлюз е конфигуриран с публичен IP адрес, конфигурирайте профил по следния начин или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, а „198.51.100.1“ е публичният IP адрес на интерфейса на локалния шлюз пред Webex Calling: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. Пропуснете следващата стъпка, ако сте конфигурирали вашия локален шлюз с публични IP адреси. |
| 9 |
Ако вашият шлюз е конфигуриран с частен IP адрес зад статичен NAT, конфигурирайте входящи и изходящи SIP профили, както следва. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, „10.80.13.12“ е IP адрес на интерфейса, обърнат към Webex Calling , а „192.65.79.20“ е публичният IP адрес на NAT. SIP профили за изходящи съобщения към Webex Calling
Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. правила от 30 до 81Преобразувайте препратките към частни адреси към външния публичен адрес за сайта, позволявайки на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Преобразувайте препратките към публичния адрес в конфигурирания частен адрес, позволявайки на съобщенията от Webex да бъдат правилно обработвани от CUBE. За повече информация вж гласови класове sip-профили . |
| 10 |
Конфигурирайте SIP опции за поддържане на активност с профил за промяна на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-options-keepalive 100Конфигурира поддържащ профил и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което Ping за SIP извън диалоговите опции се изпраща до целта за набиране, когато връзката на сърдечния ритъм към крайната точка е в състояние UP или Down. Този поддържащ профил се задейства от точката за набиране, конфигурирана към Webex. За да се гарантира, че заглавките на контактите включват напълно квалифицирано име на домейн SBC, се използва SIP профил 115. Правила 30, 40 и 50 се изискват само когато SBC е конфигуриран зад статичен NAT. В този пример cube1.lgw.com е FQDN , избрано за локалния шлюз и ако се използва статичен NAT, „10.80.13.12“ е IP адрес на интерфейса на SBC към Webex Calling и „192.65.79.20“ е публичният IP адрес на NAT . |
| 11 |
Конфигуриране на магистрала за Webex Calling : |
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN магистрала, преминете към следващия раздел Конфигурирайте локален шлюз с TDM PSTN магистрала .
За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI .
| 1 |
Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 |
Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Уточнява, че dial-peer 200 дръжки SIP кол крака. За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 |
Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
След като сте изградили транк към Webex Calling, използвайте следната конфигурация, за да създадете TDM trunk за вашата PSTN услуга с маршрутизиране на повикване с обратна линия, за да позволите оптимизиране на медиите на етап на повикването на Webex .
| 1 |
Конфигурацията за обратна връзка за набиране използва групи за набиране и маркери за маршрутизиране на повикване, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да създава цикли за маршрутизиране на повикване . Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрутизиране на повикване : Ето обяснение на полетата за конфигурацията: гласов превод-правилоИзползва регулярни изрази, дефинирани в правила, за добавяне или премахване на маркери за маршрутизиране на повикване . Превишените десетични цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация, етикетът, добавен от профил за превод 100, се използва за насочване на повиквания от Webex Calling към PSTN чрез loopback dial-peers. По същия начин, етикетът, добавен от профил за превод 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профили за превод 11 и 12 премахват тези тагове, преди да доставят повиквания съответно към магистралите на Webex и PSTN. Този пример предполага, че обажданите номера от Webex Calling са представени във формат + E.164 . Правило 100 премахва водещия +, за да поддържа валиден извикан номер. След това правило 12 добавя национална или международна цифра(и) за маршрутизиране при премахване на етикета. Използвайте цифри, които отговарят на вашия местен ISDN национален план за набиране. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да добавите и премахнете съответно маркера за маршрутизиране. За повече информация вж гласов превод-профил и гласов превод-правило . |
| 2 |
Конфигурирайте TDM портовете за гласов интерфейс, както се изисква от типа на магистрала и използвания протокол. За повече информация вж Конфигуриране на ISDN PRI . Например, основната конфигурация на ISDN интерфейс с първична скорост, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следната TDM PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . превод-профил входящ 200Присвоява профила за превод, който ще добави маркер за маршрутизиране на повикване към входящия извикан номер. директно набиране навътреНасочва повикването, без да предоставя вторичен тон за набиране. За повече информация вж директно набиране навътре . порт 0/2/0:15Физическият гласов порт, свързан с тази точка за набиране. |
| 4 |
За да активирате медийната оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, можете да промените маршрутизиране на повикване чрез въвеждане на набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали. Конфигурирайте следните точки за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат пренасочени първоначално към dial-peer 10, а оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахване на маркера за маршрутизиране, повикванията ще бъдат пренасочени към външна линия с помощта на групи за набиране. Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . превод-профил входящ 11Прилага профила за превод, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикване , преди да премине към външна линия. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва, че тази точка за набиране обработва етапите на SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията 192.168.80.14Указва адреса на интерфейса на локалния рутер като цел на повикване за връщане. За повече информация вж цел на сесията (voip dial peer) . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за съобщения, изпратени чрез обратна верига. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени чрез обратна верига. За повече информация вж обвързвам . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . кодек g711alaw Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответствате на метода за компандиране, използван от вашата ISDN услуга. без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 5 |
Добавете следната конфигурация за маршрутизиране на повикване : Това приключва конфигурацията на вашия локален шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE се конфигурират.
|
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| 1 |
Конфигуриране на следните URI гласови класове: |
| 2 |
Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове: IOS XE използва тези записи за локално определяне на целеви UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тогава тези локални конфигурации не са необходими. Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060: Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com: Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com: Името на име на домакина за запис A. 192.168.80.65: IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. |
| 3 |
Конфигурирайте следните точки за набиране: |
| 4 |
Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на Cisco IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърляте събраните данни към случая Cisco TAC, за да ускорите времето за разделителна способност.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за проблемни събития и действия за информиране, отстраняване на неизправности и отстраняване на проблема. Използвайте сислог съобщения, SNMP събития и чрез периодично наблюдение на конкретни командни изходи показване, за да определите логиката за откриване на проблеми. Видовете действия включват:
-
Събиране на командни изходи
-
Генериране на консолидиран лог файл
-
Качване на файла на потребител предоставено местоположение на мрежата като HTTPS, SCP, FTP сървър
Инженерите на TAC пишат DS файлове и цифрово го подписват за защита на интегритета. Всеки DS файл има уникалния цифров идентификатор, зададен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
-
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които променяте инсталацията за неуспех поради грешката при проверка на интегритета.
-
Прост протокол за прехвърляне на поща (SMTP) сървър, от който се нуждаете, за да може местният портал да изпраща известия по имейл.
-
Уверете се, че местният портал работи с IOS XE 17.6.1 или по-висока, ако искате да използвате защитения SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1 или по-висок
-
Диагностичните подписи са разрешени по подразбиране.
-
Конфигурирайте защитен имейл сървър, който използвате за изпращане на проактивни известия, ако устройството работи с IOS XE 17.6.1 или по-нова версия.
конфигуриране на терминално повикване-домашен пощенски сървър : @ приоритет 1 защитен tls край -
Конфигурирайте променливата ds_email среда с имейл адреса на администратора, за да уведомите.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_email край
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява 5-секундното използване на процесора с помощта на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които инсталирате в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Уверете се, че сте активирали SNMP с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет:Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решението за Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо cpu utilization с имейл известие
-
Копирайте DS XML файла на светкавицата локален шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копирайте ftp://user:pwd@192.0.2.12/DS_ 64224.xml начална флаш памет: Достъп до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [ОК - 3571/4096 байта] 3571 байта, копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.comИзтегляне на DSes:
Идентификационен номер на DS
Име на 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 е активиран с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 65221.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 65221.xml Заредете файл DS_ 65221.xml успех -
Използвайте командата покажете диагностичен подпис за обаждане вкъщи за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични сигнатури за отстраняване на проблем
Можете също така да използвате диагностични подписи (DS), за да разрешите проблемите бързо. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на неизправности в даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая Cisco TAC. Това елиминира необходимостта от ръчна проверка за възникването на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате инструмента за справка за диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно решаване на даден проблем или да инсталирате подписа, който се препоръчва от инженера на TAC като част от ангажимента за поддръжка.
Ето един пример за това как да намерите и инсталирате DS за откриване на събитието "%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0" syslog и автоматизира събирането на диагностични данни, като използва следните стъпки:
Конфигурирайте друга променлива на средата на DSds_fsurl_prefix като пътя на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка както е показано по-долу. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, както е необходимо.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_fsurl_prefix "scp:// : @cxd.cisco.com" крайПример:
среда за диагностика и подпис за обаждане вкъщиds_fsurl_prefix "околна средаds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager край -
Препоръчваме инсталирането на High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет: копирайте ftp://потребителско име:парола@ /DS_ 65095.xml начална флаш памет: -
Инсталирайте високопроцесорния мониторинг DS 64224 и след това DS CPU XML файл в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех зареждане на DS за диагностика на повикване до дома_ 65095.xml Заредете файл DS_ 65095.xml успех -
Уверете се, че подписът е успешно инсталиран с помощта на диагностичен подписshow-call-home. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comИзтеглени DSes:
Идентификационен номер на DS
Име на 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
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08:00:12:53
Проверка на изпълнението на диагностичните подписи
В следващата команда колоната "Статус" на командата показва промени в диагностичния подпис на повикване-дом на "бягане", докато местният портал изпълнява действието, определено в подписа. Изходът от статистиката за диагностичния подпис на повикване-дом е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Изтеглени DSes:
|
Идентификационен номер на DS |
Име на DS |
Преразглеждане |
Статус |
Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
Показване на статистика за диагностика-подпис на повикване-дома
|
Идентификационен номер на DS |
Име на DS |
Задейства се /Макс/Деинсталиране |
Средно време за изпълнение (секунди) |
Максимално време за изпълнение (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
1 /20/г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на неизправности в дадения проблем.
Деинсталиране на диагностични подписи
Използването на диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинира като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на диагностичния подпис на повикване-дом и изпълнете следната команда:
деинсталиране на диагностика за домашен подпис Пример:
деинсталиране на диагностичен подпис за обаждане до дома 64224 Периодично се добавят нови подписи към справочния инструмент за диагностични подписи, въз основа на проблеми, които се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
Приложете CUBE висока степен на достъпност като локален шлюз
Основите
Предпоставки
Преди да разгърнете CUBE HA като локален портал за Webex Calling, уверете се, че имате задълбочено разбиране на следните концепции:
-
Слой 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 за различни платформи:
-
Серия ISR 4K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
КСО 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 опции за клиенти.
Разгръщането на локалния портал (представено по-долу) е във фокуса на тази статия. Багажникът на локалния шлюз (базиран на помещения PSTN) в Webex Calling позволява свързване с PSTN услуга, собственост на клиента. Той също така осигурява свързаност с локално внедряване на IP PBX като Cisco Unified CM. Цялата комуникация до и от облака е осигурена с помощта на TLS транспорт за SIP и SRTP за медии.
Фигурата по-долу показва разгръщане на Webex Calling без съществуващ IP PBX и е приложимо за разполагане на един или няколко сайта. Конфигурацията, очертана в тази статия, се основава на това внедряване.
Слой 2 Резервираност от кутия до кутия
CUBE HA слой 2 резервираност кутия до кутия използва инфраструктурния протокол Redundancy Group (RG), за да образува активна/стендбай двойка рутери. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните си интерфейси и непрекъснато обменя съобщения за състоянието. Информацията за сесията на CUBE се проверява в двойката рутери, което позволява на рутера в режим на готовност да поеме всички отговорности за обработка на повиквания на CUBE незабавно, ако активният рутер излезе от експлоатация, което води до държавно запазване на сигнализацията и медиите.
Проверката на посочването е ограничена до свързани разговори с медийни пакети. Обажданията в транзит не се проверяват (например състояние на опитване или звънене).
В тази статия CUBE HA ще се отнася до CUBE висока наличност (HA) слой 2 кутия до кутия (B2B) съкращения за запазване на държавни повиквания
От IOS-XE 16.12.2, CUBE HA може да бъде разгърната като локален портал за разгръщане на багажника на Cisco Webex Calling (PSTN), базиран на помещения, и ще обхванем дизайнерски съображения и конфигурации в тази статия. Тази цифра показва типична настройка на CUBE HA като локален шлюз за разгръщане на багажника на Cisco Webex.
Група за съкращения Infra компонент
Компонентът Redundancy Group (RG) Infra осигурява поддръжка на комуникационната инфраструктура "кутия до кутия" между двете CUBE и договаря окончателното стабилно състояние на съкращения. Този компонент също така предвижда:
-
Протокол, подобен на HSRP, който договаря окончателното състояние на съкращения за всеки рутер, като обменя поддържани и здравейте съобщения между двете CUBE (чрез контролния интерфейс) - GigabitEthernet3 на фигурата по-горе.
-
Транспортен механизъм за проверка на сигналното и медийното състояние за всяко повикване от активния към маршрутизатора в режим на готовност (чрез интерфейса за данни) – GigabitEthernet3 на фигурата по-горе.
-
Конфигурация и управление на интерфейса Virtual IP (VIP) за интерфейсите на трафика (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран, за да поддържа глас B2B HA.
Виртуално IP (VIP) управление на адреси както за сигнализация, така и за медии
B2B HA разчита на VIP за постигане на съкращения. VIP и свързаните с тях физически интерфейси на двете CUBE в двойката CUBE HA трябва да се намират в една и съща LAN подмрежа. Конфигурацията на VIP и свързването на VIP интерфейса към конкретно гласово приложение (SIP) са задължителни за гласова поддръжка на B2B HA. Външни устройства като Unified CM, Webex Calling access SBC, доставчик на услуги или пълномощник, използват VIP като IP адрес на местоназначението за повикванията, преминаващи през рутерите CUBE HA. Следователно, от гледна точка на Webex Call, двойките CUBE HA действат като един локален шлюз.
Сигнализацията на повикванията и информацията за RTP сесията на установените повиквания се проверяват от активния рутер към рутера в режим на готовност. Когато Активният рутер падне, рутерът Standby поема контрола и продължава да препраща потока RTP, който преди това е бил маршрутизиран от първия рутер.
Обажданията в преходно състояние по време на провала няма да бъдат запазени след превключването. Например, обаждания, които все още не са напълно установени или са в процес на модифициране с функция за прехвърляне или задържане. Установените повиквания могат да бъдат изключени след превключване.
Съществуват следните изисквания за използване на CUBE HA като локален портал за държавно провал на повикванията:
-
CUBE HA не може да има TDM или аналогови интерфейси, разположени съвместно
-
Gig1 и Gig2 се наричат интерфейси за трафик (SIP/RTP), а Gig3 е интерфейс за контрол/данни на групата за съкращения (RG)
-
Не повече от 2 CUBE HA двойки могат да бъдат поставени в един и същ слой 2 домейн, един с група ID 1, а другият с група ID 2. Ако конфигурирането на 2 HA двойки с една и съща група ID, интерфейсите RG Control/Data трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
-
Портовият канал се поддържа както за RG контрол/данни, така и за интерфейси за трафик
-
Цялата сигнализация/медия се получава от/към виртуалния IP адрес
-
Всеки път, когато една платформа се презареди в CUBE-HA връзка, тя винаги се зарежда като Standby
-
Долният адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
-
Идентификатор на интерфейса за резервиране, rii трябва да бъде уникален за комбинация от двойки/интерфейси на един и същ слой 2
-
Конфигурацията на двете CUBE трябва да бъде идентична, включително физическа конфигурация и трябва да се изпълнява на един и същ тип платформа и IOS-XE версия
-
Интерфейсите Loopback не могат да се използват като свързващи, тъй като те винаги са нагоре
-
Интерфейсите за множествен трафик (SIP/RTP) (Gig1, Gig2) изискват конфигуриране на проследяването на интерфейса.
-
CUBE-HA не се поддържа чрез кръстосана кабелна връзка за връзката RG-контрол/данни (Gig3)
-
И двете платформи трябва да са идентични и да бъдат свързани чрез физически превключвател във всички също интерфейси, за да работи CUBE HA, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да се прекрати на един и същ превключвател и т.н.
-
Не може WAN да бъде прекратен директно на CUBE или Data HA от двете страни
-
И двете Active/Standby трябва да бъдат в един и същ център за данни
-
Задължително е да се използва отделен L3 интерфейс за резервиране (RG контрол/данни, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за поддържане на HA и контролно-пропускателен пункт
-
При неуспех предишният активен CUBE преминава през презареждане чрез дизайн, запазване на сигнализацията и медиите
Конфигуриране на съкращенията и на двете кубчета
Трябва да конфигурирате излишък от слой 2 от кутия до кутия на двете кубчета, предназначени да се използват в двойка HA, за да повдигнете виртуални IP адреси.
| 1 |
Конфигурирайте проследяването на интерфейса на глобално ниво, за да проследите състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса на гласовия трафик, така че активният маршрут да изпълнява активната си роля след като интерфейсът за трафик е надолу. | ||
| 2 |
Конфигуриране на RG за използване с VoIP HA в подрежим на резервиране на приложението.
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
| 3 |
Активирайте резервираността от кутия до кутия за приложението CUBE. Конфигурирайте RG от предишната стъпка по-долу
група за съкращения 1 —Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||
| 4 |
Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу, и прилагане на идентификатора на интерфейса за резервиране (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
| 5 |
Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане на последно винаги е в режим на готовност.
След като VCUBE-1 се зареди напълно, запишете конфигурацията на VCUBE-2 и го презаредите.
| ||
| 6 |
Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход е подчертан с удебелен шрифт. Презаредихме VCUBE-2 последно и според съображенията за проектиране; платформата за презареждане последно винаги ще бъде Standby. |
Конфигуриране на локален портал на двете кубчета
В нашата примерна конфигурация използваме следната информация за багажника от Control Hub, за да изградим конфигурацията на локалния шлюз на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
-
Потребителско име: Хюсеин 1076 г_ LGU
-
Парола: Артикул: LOV12MEaZx
| 1 |
Уверете се, че за паролата е създаден конфигурационен ключ, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 са криптирани с помощта на AES шифър и този потребителски дефиниран конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на контролния хъб , показани по-горе, запишете и презаредите. Идентификационните данни за SIP обработване на пълномощията от Control Hub са подчертани в смели .
За да покажем изхода на командата на шоуто, презаредихме VCUBE-2, последван от VCUBE-1, което направи VCUBE-1 готовност CUBE и VCUBE-2 активния CUBE |
| 2 |
Във всеки един момент само една платформа ще поддържа активна регистрация като локален портал с достъп до Webex Calling SBC. Обърнете внимание на изхода на следните команди на шоуто. Показване на група за кандидатстване за съкращения 1 покажете състоянието на регистъра на sip-ua
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
| 3 |
Сега активирайте следните дебъгове на VCUBE-1
|
| 4 |
Симулирайте неуспех, като издадете следната команда на активния LGW, VCUBE-2 в този случай.
Преминаването от ACTIVE към STANDBY LGW се извършва в следния сценарий, както и освен CLI, изброени по-горе
|
| 5 |
Проверете дали VCUBE-1 се е регистрирал в Webex Calling достъп SBC. VCUBE-2 щеше да се презареди досега.
VCUBE-1 вече е активният LGW. |
| 6 |
Вижте съответния дневник за отстраняване на грешки във VCUBE-1, изпращайки SIP REGISTER на Webex Call VIA виртуалния IP и получавайки 200 OK.
|
Конфигуриране на Unified CM за Webex Calling
Конфигуриране на SIP профил за сигурност на багажника за багажника към местния шлюз
В случаите, когато местният шлюз и PSTN шлюзът се намират на едно и също устройство, Unified CM трябва да има възможност да прави разлика между два различни типа трафик (повиквания от Webex и от PSTN), които произхождат от едно и също устройство и да прилага диференциран клас услуги към тези типове повиквания. Това диференцирано третиране на повикванията се постига чрез осигуряване на два багажника между Unified CM и комбинирания локален шлюз и PSTN шлюз устройство, което изисква различни SIP слушателни портове за двата багажника.
|
Създайте специален SIP профил за сигурност на багажника на локалния шлюз със следните настройки:
| ||||||||||
Конфигуриране на SIP профил за багажника на локалния шлюз
|
Създайте специален SIP профил за багажника на локалния шлюз със следните настройки:
| ||||||||||
Създаване на пространство за търсене на повиквания за обаждания от webex
|
Създайте пространство за търсене на повиквания за повиквания, произхождащи от Webex, със следните настройки:
Последният дял на NetRemote се използва само в многоклъстерна среда, където информацията за маршрутизиране се обменя между унифицирани CM клъстери, използващи Intercluster Lookup Service (ILS) или Global Dialplan репликация (GDPR). | ||||||||||
Конфигуриране на SIP багажник към и от Webex
|
Създайте SIP багажник за обажданията до и от Webex чрез локалния шлюз със следните настройки:
| ||||||||||||||||||||||||||
Конфигуриране на маршрутната група за Webex
|
Създаване на маршрутна група със следните настройки:
| ||||||||
Конфигуриране на списъка с маршрути за Webex
|
Създаване на списък с маршрути със следните настройки:
| ||||||||||||||
Създаване на дял за Webex дестинации
|
Създайте дял за дестинациите на Webex със следните настройки:
| ||||||||
Какво да правим по-нататък
Не забравяйте да добавите този дял към всички пространства за търсене на повиквания, които трябва да имат достъп до дестинациите на Webex. Трябва да добавите този дял специално към пространството за търсене на повиквания, което се използва като входящо пространство за търсене на повиквания на стволове на PSTN, така че обажданията от PSTN към Webex да могат да бъдат маршрутизирани.
Конфигуриране на маршрутни модели за Webex дестинации
|
Конфигуриране на моделите на маршрута за всеки диапазон на DID в Webex със следните настройки:
| ||||||||||||
Конфигуриране на съкратено нормализиране на междусистемното набиране за Webex
|
Ако е необходимо съкратено набиране между сайтовете на Webex, конфигурирайте моделите за нормализиране на набирането за всеки диапазон на ESN в Webex със следните настройки:
| ||||||||||||||||||
Настройване на функциите на Webex Calling
Създаване на ловна група
Ловните групи насочват входящите обаждания към група потребители или работни пространства. Можете дори да конфигурирате модел за маршрутизиране към цяла група.
За повече информация как да създадете ловна група, вижте Ловни групи в контролния центърна Cisco Webex.
Създаване на опашка за обаждания
Можете да настроите опашка за обаждания, така че когато обажданията на клиентите не могат да бъдат отговорени, да им бъде предоставен автоматизиран отговор, съобщения за комфорт и музика на изчакване, докато някой не може да отговори на обаждането им.
За повече информация как да настроите и управлявате опашка за обаждания, вижте Управление на опашките за обаждания в контролния хъбна Cisco Webex.
Създайте клиент рецепционист
Помогнете за задоволяване на нуждите на вашия персонал на фронт-офиса. Можете да настроите потребителите като телефонни придружители, така че те да могат да преглеждат входящите обаждания до определени хора във вашата организация.
За информация как да настроите и видите клиентите си рецепционисти, вижте Клиенти на рецепционисти в контролния центърна Cisco Webex.
Създаване и управление на автопридружители
Можете да добавяте поздрави, да настройвате менюта и да насочвате обаждания към отговаряща услуга, ловна група, гласова поща или истински човек. Създайте 24-часов график или осигурете различни опции, когато бизнесът ви е отворен или затворен.
За информация как да създавате и управлявате автопридружители, вижте Управление на автопридружителите в контролния хъбна Cisco Webex.
Конфигуриране на група за пейджинг
Груповото пейджиране позволява на потребителя да постави еднопосочно повикване или групова страница до 75 целеви потребители и работни пространства, като набере номер или разширение, възложено на конкретна група за пейдж.
За информация как да настроите и редактирате групи за пейджинг вижте Конфигуриране на група за пейджинг в контролния центърна Cisco Webex.
Настройване на пикап за повикване
Подобрете работата в екип и сътрудничеството чрез създаване на група за взимане на повиквания, така че потребителите да могат да си отговарят един на друг на обаждания. Когато добавите потребители към група за взимане на повиквания и член на групата е далеч или зает, друг член може да отговори на техните обаждания.
За информация как да настроите група за вземане на повиквания, вижте Call Pickup в контролния хъбна Cisco Webex.
Създаване на кол парк
Кол паркът позволява на определена група потребители да паркират обаждания срещу други налични членове на група кол парк. Паркираните обаждания могат да бъдат събирани от други членове на групата на телефона им.
За повече информация как да настроите кол парк, вижте Кол парк в контролния хъбна Cisco Webex.
Активиране на влизане за потребители
| 1 |
От изглед на клиента вhttps://admin.webex.com , отидете на . |
| 2 |
Изберете потребител и щракнете Обаждане . |
| 3 |
Отидете до Разрешения между потребители раздел и след това изберете Влезте . |
| 4 |
Включете превключвателя, за да позволите на други потребители да се добавят към текущото обаждане на този потребител. |
| 5 |
Проверете Пуснете тон, когато този потребител влезе в разговор ако искате да пуснете тон на другите, когато този потребител нахлуе в тяхното обаждане. В Пуснете тон, когато този потребител влезе в разговор настройката не се отнася за функциите за внедряване на Customer Experience Basic и Essentials. Дори и да активирате тази опция за надзорник, системата не възпроизвежда тона за уведомяване на агента, когато супервайзорът нахлуе в повикването му от опашката за повиквания. Ако искате да пуснете тон на агент, когато супервайзорът се нахлуе в повикването му, можете да го активирате чрез настройките на „Тон за уведомяване за агенти“. За повече информация вижте Създайте опашка раздел в Webex Customer Experience Basic или Основи за клиентското изживяване на Webex . |
| 6 |
Щракнете върху Запиши. |
Активиране на поверителност за потребител
| 1 |
Влезте в Контролен център , и отидете на . |
| 2 |
Изберете потребител и щракнете Обаждане . |
| 3 |
Отидете до Разрешения между потребители област и след това изберете Поверителност . |
| 4 |
Изберете подходящите настройки за поверителност на Auto Attendant за този потребител.
|
| 5 |
Поставете отметка в квадратчето Разрешаване на поверителността . След това можете да решите да блокирате всички, като не избирате членове от падащ списък. Като алтернатива можете да изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състояние на линията на този потребител. Ако сте администратор на местоположение, в падащ списък се показват само потребителите, работните пространства и виртуалните линии, отнасящи се до назначените ви местоположения. Премахнете отметката от Активирайте поверителност поле за отметка, за да позволите на всеки да наблюдава състояние на линията. |
| 6 |
Проверете Прилагане на поверителност за насочено приемане на повикване и влизане поле за отметка, за да активирате поверителност за насочено приемане на повикване и влизане.
|
| 7 |
От Добавете член по име , изберете потребителите, работните пространства и виртуалните линии, които могат да наблюдават състоянието на телефонна линия и да извикат насочено приемане на повикване и влизане. |
| 8 |
За да филтрирате избраните от вас членове, използвайте филтриране по име, номер или вътр поле. |
| 9 |
Щракнете върху Премахване на всички за да премахнете всички избрани членове. За да премахнете отделен член, щракнете Изтрийте до името на члена. |
| 10 |
Щракнете върху Запиши. |
Конфигуриране на наблюдение
максимален брой наблюдавани линии за потребител е 50. Въпреки това, докато конфигурирате списъка за наблюдение, вземете предвид броя на съобщенията, които влияят на честотната лента между Webex Calling и вашата мрежа. Също така, определете максималните наблюдавани линии по броя на бутоните за линии на телефона на потребителя.
| 1 |
От изглед на клиента вhttps://admin.webex.com , отидете на Управление и след това щракнете Потребители . |
| 2 |
Изберете потребителя, който искате да модифицирате, и щракнете върху "Обаждане". |
| 3 |
Отидете на Разрешения между потребители раздел и изберете Мониторинг . |
| 4 |
Изберете от следните:
Можете да включите виртуална линия в Добавете наблюдавана линия списък за потребителски мониторинг. |
| 5 |
Изберете дали искате да уведомите този потребител за паркирани повиквания, потърсете лицето или вътрешна линия за паркиране на повикване за паркиране на обаждания, което да бъде наблюдавано, и след това щракнете Запазете . Списъкът с наблюдаваните линии в Control Hub съответства на реда на наблюдаваните линии, които се показват на устройството на потребителя. Можете да пренаредите списъка с наблюдавани линии по всяко време. Името, което се показва за наблюдаваната линия, е името, въведено в полетата Име и Фамилия на ИД се за потребителя, работното пространство и виртуалната линия. |
Активиране на предупредителния тон за свързване на повиквания за потребителите
Преди да започнете
| 1 |
Влезте в Контролен център , и отидете на . |
| 2 |
Изберете потребител и щракнете върху раздела Повиквания. |
| 3 |
Отидете на Разрешения между потребители и щракнете Предупредителен тон за свързване на повикване . |
| 4 |
Включете Предупредителен тон за свързване на повикване и след това щракнете Запазете . По подразбиране тази функция е активирана. За повече информация относно свързването на повиквания по споделена линия, вж Споделени линии на вашия мултиплатформен настолен телефон . За повече информация относно свързването на повиквания на споделена линия на Webex App вж Споделен изглед на линията за WebexApp . |
Включете хотела за потребител
| 1 |
От изглед на клиента вhttps://admin.webex.com , отидете на Управление и изберете Потребители . |
| 2 |
Изберете потребител и щракнете върху раздела Повиквания. |
| 3 |
Отидете до Разрешения между потребители раздел и изберете Хотелиерство и включете превключвателя. |
| 4 |
Въведете името или номера на хоста в хотела в Местоположение на хотела поле за търсене и изберете хоста за хотели, който искате да присвоите на потребителя. Може да бъде избран само един хостел. Ако изберете друг хост за хотели, първият се изтрива. Ако сте администратор на местоположение, можете да зададете само хоста за хотели, отнасящ се до назначените ви местоположения. |
| 5 |
За да ограничите времето, през което потребителят може да бъде свързан с хоста за хотели, изберете броя часове, през които потребителят може да използва хотелския хост от Лимитен период на асоцииране падащо меню. Потребителят ще излезе автоматично след избраното време. Съобщение за съобщение за грешка се показва на екрана, ако лимитният период на асоцииране, определен за потребителя, надвишава периода на свързване на ограниченията на избрания хостинг хост. Например, ако хостингът на хотела има ограничен период на асоцииране от 12 часа, а периодът на свързване с ограничение на потребителя е 24 часа, се показва съобщение за грешка . В такива случаи трябва да удължите лимита на периода на асоцииране на хоста за хотели, ако е необходимо повече време за потребителя. |
| 6 |
Щракнете върху Запиши. Потребителят може също да търси и намира хоста за хотели, който иска да използва, от User Hub. За повече информация вж Достъп до вашия профил за обаждания отвсякъде . |
Тенденции за приемане и отчети за употребата на Webex Calling
Преглед на отчетите за обажданията
Можете да използвате страницата Analytics в Control Hub, за да добиете представа за това как хората използват Webex Calling и приложението Webex (ангажираност) и пъдпъдъка на медийното си преживяване при обаждания. За достъп до анализа на Webex Calling , влизам в Control Hub, след което отидете на Анализ и изберете Обаждане раздел.
| 1 |
За подробни отчети за историята на обажданията влизам в Control Hub, след което отидете на . |
| 2 |
Изберете Подробна история на обажданията . За информация относно обажданията, използващи специален екземпляр, вижте Специален инстанция Анализи. |
| 3 |
За достъп до данни за качеството на медиите, влизам в Control Hub, след което отидете на Анализ и след това изберете Обаждане . За повече информация вижте Анализи за портфолиотоси за сътрудничество в облака.
|
Стартирайте инструмента CScan
CScan е инструмент за мрежова готовност, предназначен да тества вашата мрежова връзка към Webex Calling.
|
За повече информация вижте Използвайте CScan за тестване на качеството на мрежата за обаждания наWebex. |
