- Начало
- /
- Статия
Благодарим за обратната връзка.
Работен поток за конфигуриране на извикване на 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. |
Подготовка на средата
Общи предпоставки
Преди да конфигурирате локален шлюз за 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 за вашата организация
Първата стъпка, за да стартирате и стартирате услугите си за обаждания на Webex Calling , е да завършите Помощник за първоначална настройка (FTSW). След като FTSW бъде завършен за първото ви местоположение, не е необходимо да се попълва за допълнителни местоположения.
| 1 | Щракнете върху Първи стъпки връзка в имейла за добре дошли, който получавате. Вашият администраторски имейл адрес се използва автоматично за влизам в Control Hub, където ще бъдете подканени да създадете своята администраторска парола. След като влизам, автоматично се стартира съветникът за настройка. |
| 2 | Прегледайте и приемете условия за използване на услугата. |
| 3 | Прегледайте плана си и след това щракнете Започнете . Мениджърът на вашия акаунт е отговорен за активиране на първите стъпки за FTSW. Свържете се с мениджъра на акаунта си, ако получите известие „Cannot Setup Your Call“, когато изберете Започнете . |
| 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 | За местоположението изберете Основен номер от падащ списък , за да позволите на потребителите в това местоположение да извършват и получават повиквания. В Основен номер може да бъде присвоен към автоматичен секретар , така че външните обаждащи се да могат да се свържат с потребителите на Webex Calling на това място. Потребителите на Webex Calling в това местоположение могат също да използват този номер като свой външен идентификатор на ИД се, когато извършват повиквания. |
| 4 | (По избор) Под Спешно обаждане , можете да изберете Идентификатор на местоположение при спешни случаи да зададете на това местоположение. Тази настройка е незадължителна и е приложима само за държави, които я изискват. В някои държави (пример: Франция), съществуват регулаторни изисквания за клетъчните радиосистеми за установяване на самоличността на клетката, когато извършвате спешно повикване и е предоставена на органите за спешна помощ. Други страни като САЩ и Канада прилагат определяне на местоположението, използвайки други методи. За повече информация вж Подобрено спешно повикване . Вашият доставчик на спешно повикване може да се нуждае от информация за мрежата за достъп и се постига чрез дефиниране на нова частна SIP заглавка на разширението, P-Access-Network-Info. Заглавката носи информация, свързана с мрежата за достъп. Когато зададете идентификатора на спешно местоположение за местоположение, стойността на местоположението се изпраща на доставчика като част от SIP съобщение. Свържете се с вашия доставчик на спешно повикване , за да видите дали имате нужда от тази настройка и използвайте стойността, предоставена от вашия доставчик на спешно повикване ." |
| 5 | Изберете Номер на гласовата поща на които потребителите могат да се обаждат, за да проверят гласовата си поща за това местоположение. |
| 6 | (По избор) Щракнете върху иконата на молив в горната част на страницата Местоположение, за да промените Име на местоположението , Език за обявяване , Език на Имейл , Часова зона , или Адрес според нуждите и след това щракнете Запазете . Промяна на Език за обявяване влиза в сила незабавно за всички нови потребители и функции, добавени към това местоположение. Ако на съществуващите потребители и/или функции също трябва да се промени езикът на съобщенията, когато бъдете подканени, изберете Промяна за съществуващи потребители и работни пространства или Промяна за съществуващи функции . Щракнете върху Приложете . Можете да видите напредъка на Задачи страница. Не можете да правите повече промени, докато това не приключи. Промяна на Часова зона за местоположение не актуализира часовите зони на функциите, свързани с местоположението. За да редактирате часовите зони за функции като автоматичен секретар оператор, група за търсене и опашка за обаждания, отидете на Общи настройки област на конкретната функция, за която искате да актуализирате часова зона и да редактирате и запишете там. |
Тези настройки са за вътрешно набиране и са налични и в съветника за първа настройка. Докато променяте своя план за набиране, примерните номера в 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 | Дайте име на багажника и щракнете Запазете . Името не може да бъде по-дълго от 24 знака. |
Какво да направите след това
Информацията за багажника се появява на екрана Регистрирайте домейн , Група магистрали OTG/DTG , Линия/Порт , и Изходящ прокси адрес .
Препоръчваме ви да копирате тази информация от Control Hub и да я поставите в локален текстов файл или документ, за да можете да се обърнете към нея, когато сте готови да конфигурирате базирания на помещения PSTN.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за багажника в Control Hub. Щракнете върху Извличане на потребителско име и нулиране на парола за генериране на нов набор от идентификационни данни за използване в багажника.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , отидете на . |
| 2 | Изберете местоположение за промяна и щракнете Управлявайте . |
| 3 | Изберете Базирана в помещения PSTN и щракнете Следваща . |
| 4 | Изберете багажник от падащо меню. Посетете страницата на магистралата, за да управлявате избора на вашата група съединителни линии канали. |
| 5 | Щракнете върху известието за потвърждение, след което щракнете Запазете . |
Какво да направите след това
Трябва да вземете информация за конфигуриране , която Control Hub генерира, и да картографирате параметрите в локален шлюз (например на Cisco CUBE, който се намира в помещенията). Тази статия ви превежда през този процес. Като справка вижте следната диаграма за пример как информация за конфигуриране на Control Hub (вляво) се съпоставя с параметрите в CUBE (вдясно):
След като завършите успешно конфигурацията на самия шлюз, можете да се върнете към в Control Hub и създаденият от вас шлюз ще бъде изброен в картата за местоположение, към която сте го присвоили, със зелена точка вляво от името. Това състояние показва, че шлюзът е сигурно регистриран в облака за повикване и служи като активен шлюз за обществена телефонна централа за местоположението.
Можете лесно да преглеждате, активирате, премахвате и добавяте телефонни номера за вашата организация в Control Hub. За повече информация вж Управлявайте телефонните номера в Control Hub .
Ако изпробвате услугите на Webex и искате да преобразувате пробната си версия в платен абонамент, можете да изпратите заявка по имейл до партньора си.
| 1 | Влезте в Control Hub на адресhttps://admin.webex.com , изберете иконата на сграда |
| 2 | Изберете Абонаменти раздел и след това щракнете Купете сега . До партньора ви се изпраща имейл, уведомяващ го, че се интересувате от преминаване към платен абонамент. |
Можете да използвате Control Hub, за да зададете приоритета на наличните опции за повикване, които потребителите виждат в приложението Webex . Можете също да ги активирате за обаждане с едно щракване. За повече информация вижте: Задайте опции за повикване за потребители на Webex App .
Можете да контролирате какво приложение за повиквания се отваря, когато потребителите извършват обаждания. Можете да конфигурирате настройките на клиента за повиквания, включително внедряване в смесен режим за организации с потребители, които имат право на Unified CM или Webex Calling , и потребители без платени услуги за обаждания от Cisco. За повече информация вижте: Настройте поведение при повикване .
Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
Общ преглед
В момента Webex Calling поддържа две версии на локален шлюз:
Локален шлюз
Локален шлюз за Webex за правителството
Преди да започнете, разберете изискванията на базираната в помещенията обществена комутирана телефонна мрежа (PSTN) и локалния шлюз (LGW) за обажданията чрез Webex Calling. Виж Предпочитана архитектура на Cisco за обаждания в Webex Calling за повече информация.
Тази статия предполага, че е създадена специална платформа за локален шлюз без съществуваща гласова конфигурация. Ако модифицирате съществуващ шлюз за обществена телефонна централа или внедряване на CUBE Enterprise, за да се използва като функция Local Gateway за Webex Calling, тогава обърнете внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци и функционалност на повикванията поради промените, които правите.
За информация относно поддържаните 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 .
Този раздел описва как да конфигурирате 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
ACL
Удостоверяване на потребителя и дистанционен достъп
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 точка за набиране с етикет на 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел 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, преминете към следващия раздел. |
След като сте изградили транк към 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.
Типовете действия включват събиране на изходни команди 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
Продукт
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
Продукт
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
Продукт
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 мониторинг 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 съобщения и ги насочва към необходимата цел.
Докато 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
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 доверителен пул, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси за достъп до интернет чрез 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 точка за набиране с етикет на 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел 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, преминете към следващия раздел. |
След като сте изградили транк към 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 събития и чрез периодично наблюдение на специфични изходни команди за показване, за да дефинирате логиката за откриване на проблеми. Типовете действия включват:
Събиране на изходни команди 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 мониторинг 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 CPU 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: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 като локален шлюз
Основи
Предварителни изисквания
Преди да разположите 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 шифър и този дефиниран от потребителя конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на Control Hub, показани по-горе, запазете и презаредете. Идентификационните данни за SIP обработване на пълномощията от Control Hub са подчертани в смели .
За да покажем изхода на командата 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 ОК.
|
Конфигуриране на Unified CM за Webex Calling
Конфигуриране на профил за защита на SIP линиите за магистрала към локален шлюз
В случаите, когато локалният шлюз и шлюз за обществена телефонна централа се намират на едно и също устройство, Unified CM трябва да бъде активиран да разграничава два различни типа трафик (повиквания от Webex и от PSTN), които произхождат от едно и също устройство и да прилага диференциран клас на услугата към тях видове повиквания. Това диференцирано третиране на повикванията се постига чрез осигуряване на две магистрали между Unified CM и комбинирания локален шлюз и шлюз за обществена телефонна централа устройство, което изисква различни SIP портове за слушане за двата канала.
Създайте специален профил за защита на SIP линиите за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Конфигурирайте SIP профил за локалната магистрала на шлюза
Създайте специален SIP профил за магистрала на локалния шлюз със следните настройки:
| ||||||||||
Създайте пространство за търсене на обаждания за обаждания от Webex
Създайте пространство за търсене на обаждания за повиквания, произхождащи от Webex със следните настройки:
Последният дял onNetRemote се използва само в многоклъстерна среда, където информация за маршрутизиране се обменя между Unified CM клъстери, използвайки услуга за междуклъстерно търсене (ILS) или Global Dialplan Replication (GDPR). | ||||||||||
Конфигурирайте SIP транк към и от Webex
Създайте външна линия SIP за повикванията към и от Webex през локалния шлюз със следните настройки:
| ||||||||||||||||||||||||||
Конфигуриране на група маршрути за Webex
Създайте група маршрути със следните настройки:
| ||||||||
Конфигуриране на списък с маршрути за Webex
Създайте списък на маршрути със следните настройки:
| ||||||||||||||
Създайте дял за Webex дестинации
Създайте дял за дестинациите на Webex със следните настройки:
| ||||||||
Какво да направите след това
Уверете се, че сте добавили този дял към всички пространства за търсене на повиквания, които трябва да имат достъп до дестинациите на Webex . Трябва да добавите този дял специално към пространството за търсене на повиквания, което се използва като пространство за търсене на входящи повиквания в PSTN магистрали, така че повикванията от PSTN към Webex да могат да се насочват.
Конфигуриране на шаблони за маршрути за дестинации на Webex
Конфигурирайте модели на маршрути за всеки диапазон на DID на Webex със следните настройки:
| ||||||||||||
Конфигуриране на съкратено нормализиране на междусайтово набиране за Webex
Ако за Webex се изисква съкратено набиране между сайтове, тогава конфигурирайте модели за нормализиране на набиране за всеки диапазон на ESN на Webex със следните настройки:
| ||||||||||||||||||
Настройване на функциите на Webex Calling
Създайте група за търсене
Групите за търсене насочват входящите повиквания към група потребители или работни пространства. Можете дори да конфигурирате шаблон за маршрут към цяла група.
За повече информация как да настройвам група за търсене, вж Търсене на групи в 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 | Проверете Пуснете тон, когато този потребител влезе в разговор ако искате да пуснете тон на другите, когато този потребител нахлуе в тяхното обаждане. В Пуснете тон, когато този потребител влезе в разговор настройката не се отнася за функциите за внедряване на Customer Experience Basic и Essentials. Дори и да активирате тази опция за надзорник, системата не възпроизвежда тона за уведомяване на агента, когато супервайзорът нахлуе в повикването му от опашката за повиквания. Ако искате да пуснете тон на агент, когато супервайзорът се нахлуе в повикването му, можете да го активирате чрез настройките на „Тон за уведомяване за агенти“. За повече информация вижте Създайте опашка раздел в Webex Customer Experience Basic или Основи за клиентското изживяване на Webex . |
| 6 | Щракнете върху Запиши. |
Активиране на поверителност за потребител
| 1 | Влезте в Контролен център , и отидете на . |
| 2 | Изберете потребител и щракнете Обаждане . |
| 3 | Отидете до Разрешения между потребители област и след това изберете Поверителност . |
| 4 | Изберете подходящия Поверителност на автоматичния оператор настройки за този потребител.
|
| 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
Преглед на отчетите за обажданията
Можете да използвате страницата Анализ в Control Hub, за да получите представа за това как хората използват обажданията в Webex Calling и Webex приложение (ангажиране), както и качеството на медийното им преживяване за разговори. За достъп до анализа на Webex Calling , влизам в Control Hub, след което отидете на Анализ и изберете Обаждане раздел.
| 1 | За подробни отчети за историята на обажданията влизам в Control Hub, след което отидете на . |
| 2 | Изберете Подробна история на обажданията . За информация относно повиквания, използващи Специализиран екземпляр, вж Анализ на специализирани инстанции . |
| 3 | За достъп до данни за качеството на медиите, влизам в Control Hub, след което отидете на Анализ и след това изберете Обаждане . За повече информация вижте Анализи за вашето портфолио за сътрудничество в облака.
|
Стартирайте инструмента CScan
CScan е инструмент за готовност на мрежата, предназначен да тества мрежова връзка с Webex Calling.
За повече информация вж Използвайте CScan, за да тествате качеството на мрежата за Webex Calling . |
Подготовка на средата
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling, уверете се, че:
-
Имате основни познания за принципите на VoIP
-
Имате основни работни познания за гласовите концепции на Cisco IOS-XE и IOS-XE
-
Имате основно разбиране за протокола за стартиране на сесия (SIP)
-
Имате основно разбиране за Cisco Унифициран комуникационен мениджър (Unified CM), ако вашият модел за внедряване включва Unified CM
Вижте Ръководство за корпоративна конфигурация на Cisco Unified Border Element (CUBE) за подробности.
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че разполагането ви има един или повече от локалните шлюзове, като например:
-
Cisco CUBE за IP-базирана свързаност
-
Cisco IOS шлюз за базирана на TDM свързаност
Локалният шлюз ви помага да мигрирате към Webex Calling със собствено темпо. Локалният шлюз интегрира съществуващото ви локално разполагане с Webex Calling. Можете също да използвате съществуващата си PSTN връзка. Вижте Първи стъпки с локален шлюз
Изисквания за лиценз за местни портали
Лицензите за повикване на 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 |
Влезте в Control Hub, отидете на и след това превъртете до Вътрешно набиране. |
| 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.
Можете да управлявате какво се отваря приложението за повиквания, когато потребителите извършват повиквания. Можете да конфигурирате настройките на повикващия клиент, включително разполагане на смесен режим за организации с потребители с права с Unified CM или Webex Calling, и потребители без платени услуги за повиквания от Cisco. За повече информация вижте: Настройване на поведението при повиквания.
Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
Общ преглед
Webex Calling в момента поддържа две версии на локален шлюз:
-
Локален шлюз
-
Локален шлюз за Webex for Government
-
Преди да започнете, разберете изискванията за локална обществена комутируема телефонна мрежа (PSTN) и локален шлюз (LGW) за Webex Calling. Вижте Cisco Предпочитана архитектура за Webex Призоваване за повече информация.
-
Тази статия предполага, че е налице специална платформа на Local Gateway без съществуваща гласова конфигурация. Ако промените съществуващ PSTN шлюз или разполагане на CUBE Enterprise, за да се използва като функция за локален шлюз за Webex Calling, тогава обърнете внимателно внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци на повиквания и функционалност поради направените промени.
За информация относно поддържаните SBC от трети страни вижте съответната продуктова референтна документация.
Има две опции за конфигуриране на локалния портал за вашия багажник за повикване на Webex:
-
Багажник, базиран на регистрация
-
Багажник, базиран на сертификат
Използвайте потока на задачите или под Базиран на регистрация локален шлю з, или Базиран на сертификат локален шлю з, за да конфигурирате локален шлюз за вашата съединителна линия на Webex Calling.
Вижте Първи стъпки с локален шлю з за повече информация относно различните типове съединителни линии. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Използваме протокол за стартиране на сесия (SIP) и транспорт за защита на транспортния слой (TLS), за да защитим съединителната линия, и защитен протокол в реално време (SRTP), за да защитим мултимедията между локалния шлюз и Webex Calling.
-
Изберете CUBE като локален шлюз. Понастоящем Webex for Government не поддържа гранични контрольори на сесии (SBC) на трети страни. За да прегледате най-новия списък, вижте Първи стъпки с локален шлюз.
- Инсталирайте версията на Cisco IOS XE Dublin 17.12.1a или по-нова за всички локални шлюзове на Webex for Government.
-
За да прегледате списъка с главни сертифициращи органи (СО), които Webex за правителство поддържат, вижте Главни сертифициращи органи за Webex за правителство.
-
За подробности относно диапазоните от външни портове за локален шлюз в Webex for Government вижте Мрежови изисквания за Webex for Government (FedRAMP).
Локалният шлюз за Webex for Government не поддържа следното:
-
STUN/ICE-Lite за оптимизиране на пътя на мултимедията
-
Факс (T.38)
За да конфигурирате локален шлюз за своята съединителна линия на Webex Calling в Webex for Government, използвайте следната опция:
-
Багажник, базиран на сертификат
Използвайте потока на задачите под Базиран на сертификат локален шлю з, за да конфигурирате локалния шлюз за вашата съединителна линия на Webex Calling. За повече подробности как да конфигурирате базиран на сертификат локален шлюз вижте Конфигуриране на базирана на сертификат външна връзка на Webex Calling.
Задължително е да конфигурирате съвместими с FIPS шифри на GCM да поддържа локален шлюз за Webex for Government. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вижте Конфигуриране на базираната на сертификат външна връзка на Webex Calling.
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling чрез регистриране на SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от 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, можете да използвате конфигурацията на прост PSTN шлюз като базова линия за изграждане на решението, показано на следващата схема. В този случай 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 Software Researc h. Потърсете платформата и изберете едно от предложенит е издания.
-
Маршрутизаторите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за технологии за Unified Communications, така и за сигурност.
-
Маршрутизаторите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
-
Изградете базова конфигурация за вашата платформа, която следва вашите бизнес правила. По-специално, конфигурирайте следното и проверете работата:
-
нтр
-
АКЛ
-
Удостоверяване на потребители и отдалечен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес.
-
Качете основния пакет на Cisco CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че сте задали валидни и подлежащи на маршрутизиране IP адреси към интерфейси от Слой 3, например:
|
| 2 |
Защитете регистрационните и STUN идентификационните данни на маршрутизатора с помощта на симетрично шифроване. Конфигурирайте основния ключ за шифроване и типа на шифроването, както следва:
|
| 3 |
Създайте надеждна PKI точка за съхранение. Изисква тази точка на доверие да конфигурира TLS по-късно. За външни връзки, базирани на регистрация, тази точка на доверие не изисква сертификат – както би се изисквало за външна връзка, базирана на сертификат. |
| 4 |
Разрешете изключителност на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигуриране. Параметрите на транспорта също трябва да бъдат актуализирани, за да се осигури надеждна защитена връзка за регистрация: Командата на сървъра cn-san-validate гарантира, че локалният шлюз позволява връзка, ако името на хоста, конфигурирано в клиент 200, е включено или в полетата CN, или SAN на сертификата, получен от изходящия прокси сървър.
|
| 5 |
Инсталирайте пакета root CA на Cisco, който включва сертификата DigiCert CA, използван от Webex Calling. Използвайте командата Импортиране на чист URL адрес на crypto pki trustpool , за да изтеглите главния пакет от CA от посочения URL и да изчистите текущия CA trustpool, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета от CA: ip http клиент прокси-сървър yourproxy.com прокси-порт 80 |
| 1 |
Създайте базирана на регистрация външна връзка на PSTN за съществуващо местоположение в Control Hub. Обърнете внимание на информацията за съединителната линия, която се предоставя след като съединителната линия бъде създадена. Тези подробности, както е подчертано в следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. За повече информация вижте Конфигуриране на външни връзки, групи за маршрутизиране и планове за набиране за Webex Calling. |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз на Webex Calling: Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. статистика на медиитеПозволява медиен мониторинг на местния портал. групова статистика за мултимедияПозволява на контролната равнина да анкетира равнината на данните за статистика на насипните повиквания. За повече информация относно тези команди вижте Мултимедия. allow-връзки sip към sipРазрешаване на основната функционалност на обратен SIP на CUBE. За повече информация вижте Разрешаване на връзки. По подразбиране е активиран транспорт на факс T.38. За повече информация вижте факс протокол t38 (гласова услуга). Активира STUN (Session Traversal of UDP through NAT) глобално.
За повече информация вижте ИД на stun flowdata аген т и stun flowdata споделена тайна. Асиметричният полезен обем е пъленКонфигурира поддръжка на асиметричен полезен товар за SIP както за DTMF, така и за динамични кодеци. За повече информация относно тази команда вижте асиметричен полезен обем. принудително ранно предложениеПринудете локалния шлюз да изпраща информация за SDP в първоначалното съобщение \„ПОКАНА\“, вместо да изчаква потвърждение от съседния си колега. За повече информация относно тази команда вижте ранно предложение. |
| 3 |
Конфигурирайте филтъра за кодек от гласов клас 100 за съединителната линия. В този пример се използва един и същ филтър за кодек за всички съединителни линии. Можете да конфигурирате филтри за всяка съединителна линия за прецизно управление. Ето обяснение на полетата за конфигурацията: кодек от гласов клас 100Използва се за позволяване само на предпочитани кодеци за повиквания през съединителни линии на SIP. За повече информация вижте кодек за гласов клас. Кодекът Opus се поддържа само за SIP-базирани PSTN съединителни линии. Ако PSTN съединителната линия използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитанието за кодек 1 опус от конфигурацията на кодек от гласов клас 100 . |
| 4 |
Конфигурирайте използването на stun-ове от гласов клас 100 , за да активирате ICE на съединителната линия на Webex Calling. Ето обяснение на полетата за конфигурацията: използване на лед liteИзползва се за активиране на ICE-Lite за всички връстници за набиране на Webex Calling, за да позволи оптимизация на мултимедията, когато е възможно. За повече информация вижте Използване на камък от гласов кла с и Lite за използване на камък. Изисквате stun използване на ICE-lite за потоци на повиквания с използване на оптимизиране на пътя на мултимедията. За да осигурите оптимизация на мултимедията за SIP към TDM шлюз, конфигурирайте връстник за набиране с loopback с 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Дефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този модел, използвайте dtg=, последван от стойността на OTG/DTG на съединителната линия, предоставена в Control Hub, когато съединителната линия е създадена. За повече информация вижте uri на гласов клас. |
| 7 |
Конфигурирайте sip профил 100, който ще се използва за промяна на SIP съобщенията, преди да бъдат изпратени на Webex Calling.
Ето обяснение на полетата за конфигурацията:
|
| 8 |
Конфигуриране на външна връзка на Webex Calling: |
След като дефинирате клиент 100 и конфигурирате връстник за SIP VoIP набиране, шлюзът инициира TLS връзка към Webex Calling. В този момент достъпът SBC представя сертификата си на локалния шлюз. Локалният шлюз валидира SBC сертификата за достъп до Webex Calling, като използва корневи пакет на CA, който е актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп до Webex Calling. След това локалният шлюз може да използва тази защитена връзка, за да се регистрира със SBC за достъп до Webex. Когато регистрацията е оспорена за удостоверяване:
-
Параметрите на потребителското име, паролата иобластт а от конфигурацията на идентификационните данн и се използват в отговора.
-
Правилата за модифициране в sip профил 100 се използват за преобразуване на URL адреса на SIPS обратно в SIP.
Регистрацията е успешна, когато се получи 200 OK от SBC за достъп.
След като сте изградили съединителна линия към Webex Calling по-горе, използвайте следната конфигурация, за да създадете нешифрована съединителна линия към SIP базиран доставчик на PSTN:
Ако вашият доставчик на услуги предлага защитена PSTN съединителна линия, може да следвате подобна конфигурация, както е подробно описано по-горе за съединителната линия на Webex Calling. Маршрутизирането на защитено до защитено повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN съединителна линия, преминете към следващия раздел Конфигуриране на локален шлюз с TDM PSTN съединителна линия.
За да конфигурирате TDM интерфейси за сегментите на PSTN повикване в Cisco TDM-SIP шлюзовете, вижте Конфигуриране на ISDN PRI.
| 1 |
Конфигурирайте следния URI за гласов клас, за да идентифицирате входящите повиквания от PSTN съединителната линия: Ето обяснение на полетата за конфигурацията: гласов клас uri 200 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте uri на гласов клас. |
| 2 |
Конфигурирайте следния връстник за набиране на IP PSTN: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 20 0 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел BAD.BADИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че връстник за набиране 20 0 обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вижте целта на сесията (връстник за VoIP набиране). входящ URI през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съвпада с всички входящи IP PSTN сегменти на повикване в локалния шлюз с връстник за набиране 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 външна връзка за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на мултимедията в сегмента на повикванията на Webex.
| 1 |
Конфигурацията на връстната връзка за набиране използва групи за набиране и етикети за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли на маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на етикети за маршрутизиране на повиквания: Ето обяснение на полетата за конфигурацията: правило за превод на гласИзползва регулярни изрази, дефинирани в правила, за да добавя или премахва етикети за маршрутизиране на повиквания. Цифрите над десетичната запетая („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация етикетът, добавен от профил за транслация 100, се използва за насочване на повиквания от Webex Calling към PSTN през връстниците за набиране с loopback. По същия начин етикетът, добавен от профил за транслация 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профилите за транслация 11 и 12 премахват тези етикети, преди да се доставят повиквания съответно към Webex и PSTN връзките. Този пример предполага, че набраните номера от Webex Calling са представени във формат +E.164. Правило 100 премахва водещия +, за да поддържа валиден набран номер. Правило 12 след това добавя национална или международна цифра за маршрутизиране при премахване на етикета. Използвайте цифри, които съответстват на вашия локален национален план за набиране на ISDN. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да просто добавите и премахнете съответно маркера за маршрутизиране. За повече информация вижте профил за гласов прево д и правило за гласов превод. |
| 2 |
Конфигурирайте портовете за TDM гласов интерфейс според изискванията на използвания тип съединителна линия и протокол. За повече информация вижте Конфигуриране на ISDN PRI. Например основната конфигурация на интерфейс с Primary Rate ISDN, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следния TDM PSTN връстник за набиране: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 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 повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията 192.168.80.14Указва адреса на локалния интерфейс на маршрутизатора като цел за обратно повикване. За повече информация вижте целта на сесията (връстник за набиране на VOIP). обвързване на контролния източник-интерфейс 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). В този случай всички повиквания се маршрутизират чрез Унифициран CM. Повикванията от UCM на порт 5060 се маршрутизират към PSTN, а повикванията от порт 5065 се маршрутизират към Webex Calling. Следните нарастващи конфигурации могат да бъдат добавени, за да се включи този сценарий за повиквания.
Когато създавате багажника на Webex Calling в Unified CM, се уверете, че сте конфигурирали входящия порт в настройките на профила за защита на SIP Trunk на 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: Име на хост за запис. 192.168.80.65: IP адресът на хоста. Създайте записи на SRV ресурси и записи A, за да отразите вашата среда на UCM и предпочитаната стратегия за разпределяне на повикванията. |
| 3 |
Конфигурирайте следните връстници за набиране: |
| 4 |
Добавете маршрутизиране на повикванията, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и прехвърлянето на събраните данни в Cisco TAC случай, за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми с помощта на syslog съобщения, SNMP събития и чрез периодично наблюдение на конкретни команди за показване.
Типовете действия включват събиране на командни изходи:
-
Генериране на консолидиран лог файл
-
Качване на файла в осигурено от потребителя мрежово местоположение, например 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 сигурна tls диагностика-подпис среда ds_email "tacfaststart@gmail.com" Локален портал, работещ на Cisco IOS XE Software, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на профила в Gmail и да предоставим специално разрешение имейлът от устройството да бъде обработен правилно:
-
Отидете на и включете настройката По-малко сигурен достъп до приложението .
-
Отговорете "Да, това бях аз", когато получавате имейл от Gmail, в който се казва: "Google попречи на някого да влезе в профила ви с помощта на приложение извън Google".
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява използването на процесора за пет секунди при използване на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които са инсталирани в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Използвайте командата показване на snmp , за да активирате SNMP. Ако не активирате, тогава конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
ISR серия Cisco 4300, 4400 или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Копирайте DS XML файла в светкавицата на локалния шлюз.
LocalGateway# копие на ftp://потребителско име:парола@/DS_64224.xml bootflash:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копиране на ftp://потребител:pwd@192.0.2.12/DS_64224.xml bootflash: Достъп до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK – 3571/4096 байта] 3571 байта са копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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, за да продължите да наблюдавате голямото използване на процесора в локалния шлюз.
Мониторинг SIP багажник регистрация
Този DS проверява за нерегистрация на локален Gateway SIP багажник с облак Webex Calling на всеки 60 секунди. След като бъде открито събитието за дерегистриране, то генерира известие по имейл и syslog и се деинсталира след две повторения за дерегистриране. Използвайте стъпките по-долу, за да инсталирате подписа:
-
Изтеглете DS 64117, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
СИП-СИП
Тип на проблема
SIP Trunk Отписване на регистрацията с известие по имейл.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_64117.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностика и подпис на повикване-домашен номер_64117.xml Успешно зареждане на файла DS_64117.xml LocalGateway# -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Мониторинг на абнормни прекъсвания на повикването
Този DS използва SNMP анкета на всеки 10 минути, за да открие необичайно прекъсване на връзката с SIP грешки 403, 488 и 503. Ако увеличението на броя грешки е по-голямо или равно на 5 от последната анкета, то генерира syslog и имейл известие. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Използвайте командата показване на snmp , за да проверите дали е разрешено SNMP. Ако не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_65221.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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 и автоматизира събирането на диагностични данни, като използва следните стъпки:
-
Конфигурирайте допълнителна променлива на средата на DS, ds_fsurl_prefix която е пътят на файловия сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е маркер за качване на файла, който може да бъде извлечен от Диспечер на случаи на поддръжката в следната команда. Маркерът за качване на файла може да се генерира в раздела Прикачени файлове на диспечера на случаи на поддръжката, ако е необходимо.
конфигуриране на терминал call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" крайПример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Уверете се, че SNMP е разрешено с помощта на командата показване на snmp . Ако не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp %SNMP агента не е активиран конфигурация до края на диспечера на snmp сървъра -
Уверете се, че инсталирате 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 bootflash: копиране на ftp://потребителско име:парола@/DS_65095.xml bootflash: -
Инсталирайте High CPU мониторинг DS 64224 и след това DS 65095 XML файл в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Зареждане на файла DS_64224.xml успешно повикване-home diagnostic-signature load 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
ДД_ЛГ_ВИЕ_КВall_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверка на изпълнението на диагностичните подписи
В следната команда колоната „Състояние“ на командата показване на call-home diagnostic-signature се променя на „изпълнява“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът от статистиката за диагностичния подпис на повикването у дома е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за повикване до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: 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 |
ДД_ЛГ_ВИЕ_КВ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 |
ДД_ЛГ_ВИЕ_КВall_spike_threshold |
1/20/Г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на даден проблем.
Деинсталиране на диагностични подписи
Използвайте диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинират като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на командата показване на диагностика-подпис на повикване-дом и изпълнете следната команда:
деинсталиране на диагностика-подпис за повикване-дом Пример:
деинсталиране на диагностика за повикване-домашен подпис 64224 Периодично се добавят нови подписи към инструмента за справка за диагностични подписи, въз основа на проблеми, които обикновено се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
За по-добро управление на шлюзовете на Cisco IOS XE препоръчваме да запишете и управлявате шлюзовете чрез Control Hub. Конфигурацията е незадължителна. Когато сте се записали, можете да използвате опцията за проверка на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате евентуални проблеми с конфигурацията. В момента само съединителни линии, базирани на регистрация, поддържат тази функционалност.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling с използване на базиран на сертификат взаимен TLS (mTLS) SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от 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, можете да използвате конфигурацията на прост PSTN шлюз като базова линия за изграждане на решението, показано на следващата схема. В този случай 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 Software Researc h. Потърсете платформата и изберете едно от предложенит е издания.
-
Маршрутизаторите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за технологии за Unified Communications, така и за сигурност.
-
Маршрутизаторите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Essentials. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
За изискванията за висок капацитет може да изисквате и лиценз за висока защита (HSEC) и допълнителни права за пропускателна способност.
Вижте Кодове за удостоверяван е за повече подробности.
-
-
Изградете базова конфигурация за вашата платформа, която следва вашите бизнес правила. По-специално, конфигурирайте следното и проверете работата:
-
нтр
-
АКЛ
-
Удостоверяване на потребители и отдалечен достъп
-
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) сертификат на маршрутизатора. Например:
-
Ако конфигурирана външна връзка в контролния център на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на маршрутизатора трябва да съдържа cube1.lgw.com.
-
Ако конфигурирана външна връзка в Control Hub на вашата организация има lgws.lgw.com като SRV адрес на локалните шлюзове, достъпни от външната връзка, тогава CN или SAN в сертификата на маршрутизатора трябва да съдържат lgws.lgw.com. Записите, на които SRV адресът решава (CNAME, A Record или IP адрес), са незадължителни в SAN.
-
Независимо дали използвате FQDN, или SRV за външната линия, адресът на контакта за всички нови SIP диалози от вашия локален шлюз използва името, конфигурирано в Control Hub.
-
-
-
Уверете се, че сертификатите са подписани за използване от клиента и сървъра.
-
Качете основния пакет на Cisco CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че сте задали валидни и подлежащи на маршрутизиране IP адреси към интерфейси от Слой 3, например:
|
| 2 |
Защитете идентификационните данни за STUN на рутера с помощта на симетрично шифроване. Конфигурирайте основния ключ за шифроване и типа на шифроването, както следва: |
| 3 |
Създайте точка на доверие за шифроване със сертификат, подписан от предпочитания от вас сертифициращ орган (CA). |
| 4 |
Удостоверете новия си сертификат, като използвате своя междинен (или главен) CA сертификат, след което импортирайте сертификата (стъпка 4). Въведете следната команда за exec или конфигуриране:
|
| 5 |
Импортирайте подписан сертификат на организатор с помощта на следната команда за exec или конфигуриране:
|
| 6 |
Разрешете изключителност на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигуриране:
|
| 7 |
Инсталирайте пакета root CA на Cisco, който включва сертификата DigiCert CA, използван от Webex Calling. Използвайте командата Импортиране на чист URL адрес на crypto pki trustpool , за да изтеглите главния пакет от CA от посочения URL и да изчистите текущия CA trustpool, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета от CA: ip http клиент прокси-сървър yourproxy.com прокси-порт 80 |
| 1 |
Създайте PSTN багажник, базиран на CUBE, за съществуващо местоположение в Control Hub. За повече информация вижте Конфигуриране на външни връзки, групи за маршрутизиране и планове за набиране за Webex Calling. Запишете информацията за съединителната линия, която се предоставя след като съединителната линия бъде създадена. Тези подробности, както е подчертано в следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз на Webex Calling: Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. allow-връзки sip към sipРазрешаване на основна SIP на CUBE обратно към обратно функционалността на потребителския агент. За повече информация вижте Разрешаване на връзки. По подразбиране е активиран транспорт на факс T.38. За повече информация вижте факс протокол t38 (гласова услуга). Активира STUN (Session Traversal of UDP through NAT) глобално. Тези глобални команди за stun се изискват само при разгръщане на вашия локален шлюз зад NAT.
За повече информация вижте ИД на stun flowdata агент и stun flowdata споделена тайна. Асиметричният полезен обем е пъленКонфигурира поддръжка на асиметричен полезен товар за SIP както за DTMF, така и за динамични кодеци. За повече информация относно тази команда вижте асиметричен полезен обем. принудително ранно предложениеПринудете локалния шлюз да изпраща информация за SDP в първоначалното съобщение \„ПОКАНА\“, вместо да изчаква потвърждение от съседния си колега. За повече информация относно тази команда вижте ранно предложение. sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез връстници за набиране или клиенти. |
| 3 |
Конфигурирайте филтъра за кодек от гласов клас 100 за съединителната линия. В този пример се използва един и същ филтър за кодек за всички съединителни линии. Можете да конфигурирате филтри за всяка съединителна линия за прецизно управление. Ето обяснение на полетата за конфигурацията: кодек от гласов клас 100Използва се за позволяване само на предпочитани кодеци за повиквания през съединителни линии на SIP. За повече информация вижте кодек за гласов клас. Кодекът Opus се поддържа само за SIP-базирани PSTN съединителни линии. Ако PSTN съединителната линия използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитанието за кодек 1 опус от конфигурацията на кодек от гласов клас 100 . |
| 4 |
Конфигурирайте използването на stun-ове от гласов клас 100 , за да активирате ICE на съединителната линия на Webex Calling. (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: използване на лед liteИзползва се за активиране на ICE-Lite за всички връстници за набиране на Webex Calling, за да позволи оптимизация на мултимедията, когато е възможно. За повече информация вижте Използване на камък от гласов кла с и Lite за използване на камък. Командата защитна стена за използване на камък-traversal flowdata е необходима само когато разполагате с вашия локален шлюз зад NAT. Изисквате stun използване на ICE-lite за потоци на повиквания с използване на оптимизиране на пътя на мултимедията. За да осигурите оптимизация на мултимедията за SIP към TDM шлюз, конфигурирайте връстник за набиране с loopback с 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 for Government. |
| 7 |
Конфигурирайте шаблон за уникално идентифициране на повикванията към съединителна линия на локален шлюз въз основа на неговия FQDN или SRV на местоназначението: Ето обяснение на полетата за конфигурацията: гласов клас uri 100 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този модел, използвайте LGW FQDN или SRV, конфигуриран в Control Hub, докато създавате съединителна линия. |
| 8 |
Конфигурирайте профили за обработка на SIP съобщения. Ако шлюза ви е конфигуриран с публичен IP адрес, конфигурирайте профил, както следва, или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN, конфигуриран за локалния шлюз, а "198.51.100.1" е публичният IP адрес на интерфейса за локален шлюз, насочен към Webex Calling: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволи на Webex да удостоверява съобщения от вашия локален шлюз, заглавката \„Контакт\“ в съобщенията за 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 да удостоверява съобщения от вашия локален шлюз, заглавката \„Контакт\“ в съобщенията за SIP заявки и отговори трябва да съдържа стойността, осигурена за съединителната линия в Control Hub. Това ще бъде или FQDN на един хост, или името на SRV домейна, използвано за клъстер от устройства. правила 30—81Конвертирайте препратките към частни адреси във външния публичен адрес за сайта, което позволява на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от гласов клас sip-профили от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Конвертирайте препратките към публичен адрес в конфигурирания частен адрес, което позволява съобщенията от Webex да се обработват правилно от CUBE. За повече информация вижте профили на SIP за гласов клас. |
| 10 |
Конфигурирайте поддържане на опции за SIP с профил за модифициране на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-опции-поддържане 100Конфигурира профил за поддържане и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което SIP Out of Dialog Options Ping се изпраща до целта за набиране, когато сърдечната връзка към крайната точка е в състояние НАГОРЕ или Надолу. Този профил за запазване на комуникацията се задейства от връстник за набиране, конфигуриран към 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 по-горе, използвайте следната конфигурация, за да създадете нешифрована съединителна линия към SIP базиран доставчик на PSTN:
Ако вашият доставчик на услуги предлага защитена PSTN съединителна линия, може да следвате подобна конфигурация, както е подробно описано по-горе за съединителната линия на Webex Calling. Маршрутизирането на защитено до защитено повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN съединителна линия, преминете към следващия раздел Конфигуриране на локален шлюз с TDM PSTN съединителна линия.
За да конфигурирате TDM интерфейси за сегментите на PSTN повикване в Cisco TDM-SIP шлюзовете, вижте Конфигуриране на ISDN PRI.
| 1 |
Конфигурирайте следния URI за гласов клас, за да идентифицирате входящите повиквания от PSTN съединителната линия: Ето обяснение на полетата за конфигурацията: гласов клас uri 200 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте uri на гласов клас. |
| 2 |
Конфигурирайте следния връстник за набиране на IP PSTN: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 20 0 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел BAD.BADИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че връстник за набиране 20 0 обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вижте целта на сесията (връстник за VoIP набиране). входящ URI през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съвпада с всички входящи IP PSTN сегменти на повикване в локалния шлюз с връстник за набиране 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 външна връзка за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на мултимедията в сегмента на повикванията на Webex.
| 1 |
Конфигурацията на връстната връзка за набиране използва групи за набиране и етикети за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли на маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на етикети за маршрутизиране на повиквания: Ето обяснение на полетата за конфигурацията: правило за превод на гласИзползва регулярни изрази, дефинирани в правила, за да добавя или премахва етикети за маршрутизиране на повиквания. Цифрите над десетичната запетая („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация етикетът, добавен от профил за транслация 100, се използва за насочване на повиквания от Webex Calling към PSTN през връстниците за набиране с loopback. По същия начин етикетът, добавен от профил за транслация 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профилите за транслация 11 и 12 премахват тези етикети, преди да се доставят повиквания съответно към Webex и PSTN връзките. Този пример предполага, че набраните номера от Webex Calling са представени във формат +E.164. Правило 100 премахва водещия +, за да поддържа валиден набран номер. Правило 12 след това добавя национална или международна цифра за маршрутизиране при премахване на етикета. Използвайте цифри, които съответстват на вашия локален национален план за набиране на ISDN. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да просто добавите и премахнете съответно маркера за маршрутизиране. За повече информация вижте профил за гласов прево д и правило за гласов превод. |
| 2 |
Конфигурирайте портовете за TDM гласов интерфейс според изискванията на използвания тип съединителна линия и протокол. За повече информация вижте Конфигуриране на ISDN PRI. Например основната конфигурация на интерфейс с Primary Rate ISDN, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следния TDM PSTN връстник за набиране: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 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 повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията 192.168.80.14Указва адреса на локалния интерфейс на маршрутизатора като цел за обратно повикване. За повече информация вижте целта на сесията (връстник за набиране на VOIP). обвързване на контролния източник-интерфейс 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). В този случай всички повиквания се маршрутизират чрез Унифициран 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: Име на хост за запис. 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 среда с имейл адреса на администратора, за да уведомите.
конфигуриране на терминал call-home-подпис на 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-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash:Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо cpu utilization с имейл известие
-
Копирайте DS XML файла на светкавицата локален шлюз.
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копиране на ftp://потребител:pwd@192.0.2.12/DS_64224.xml bootflash: Достъп до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK – 3571/4096 байта] 3571 байта са копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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 от последната анкета, то генерира syslog и имейл известие. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_65221.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностика и подпис за повикване-дом_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 и автоматизира събирането на диагностични данни, като използва следните стъпки:
Конфигурирайте друга променлива на средата на DS ds_fsurl_prefix като път на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номер на случай, а паролата е маркер за качване на файла, който може да бъде извлечен от Диспечер на случаи за поддръжка , както е показано по-долу. Маркерът за качване на файл може да се генерира в раздела Прикачени файлове на диспечера на случаи за поддръжка, както се изисква.
конфигуриране на терминал call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" крайПример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активирано, конфигурирайте командата SNMP-сървър .
показване на snmp %SNMP агента не е активиран конфигурация до края на диспечера на snmp сървъра -
Препоръчваме инсталирането на High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash: копиране на ftp://потребителско име:парола@/DS_65095.xml bootflash: -
Инсталирайте файла за наблюдение на процесора DS 64224 и след това DS 65095 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
ДДЛГ_ВИЕ_КВ_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 |
ДД_ЛГ_ВИЕ_КВ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 |
ДД_ЛГ_ВИЕ_КВ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 от предишната стъпка под
redundancy-group 1 – Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||
| 4 |
Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу, и прилагане на идентификатора на интерфейса за резервиране (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
| 5 |
Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане на последно винаги е в режим на готовност.
След като VCUBE-1 се зареди напълно, запишете конфигурацията на VCUBE-2 и го презаредите.
| ||
| 6 |
Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход е подчертан с удебелен шрифт. Презаредихме VCUBE-2 последно и според съображенията за проектиране; платформата за презареждане последно винаги ще бъде Standby. |
Конфигуриране на локален портал на двете кубчета
В нашата примерна конфигурация използваме следната информация за багажника от Control Hub, за да изградим конфигурацията на локалния шлюз на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
-
Потребителско име: Hussain1076_ЛГУ
-
Парола: Артикул: LOV12MEaZx
| 1 |
Уверете се, че за паролата е създаден конфигурационен ключ, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 са криптирани с помощта на AES шифър и този потребителски дефиниран конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на контролния хъб , показани по-горе, запишете и презаредите. Идентификационните данни за SIP Digest от Control Hub се открояват в получер.
За да покажем изхода на командата на шоуто, презаредихме VCUBE-2, последван от VCUBE-1, което направи VCUBE-1 готовност CUBE и VCUBE-2 активния CUBE |
| 2 |
Във всеки един момент само една платформа ще поддържа активна регистрация като локален портал с достъп до Webex Calling SBC. Обърнете внимание на изхода на следните команди на шоуто. Показване на група за кандидатстване за съкращения 1 показване на статус нарегистриране на sip-ua
От изхода по-горе можете да видите, че VCUBE-2 е активната LGW, поддържаща регистрацията с SBC за достъп до Webex Calling, докато изхода от „показване на състоянието на регистриране на sip-ua“ е празен в 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 Customer Experience Essentials. |
| 6 |
Щракнете върху Запиши. |
Разрешаване на поверителност за потребител
| 1 |
Влезте в Control Hub и отидете на . |
| 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 |
Влезте в Control Hub и отидете на . |
| 2 |
Изберете потребител и щракнете върху раздела Повиквания. |
| 3 |
Отидете на Разрешения между потребители и щракнете върху Предупредителен тон за мост между повиквания. |
| 4 |
Включете Предупредителен тон за мост между повиквания, след което щракнете върху Запиши. Тази функция е активирана по подразбиране. За повече информация относно мост между повиквания по споделена MPP линия вижте Споделени линии на вашия мултиплатформен настолен телефон. За повече информация относно мост между повиквания в споделена линия в приложението Webex вижте Появяване на споделена линия за 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. |
Внедряване на високата степен на достъпност на 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 от предишната стъпка под
redundancy-group 1 – Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||
| 4 |
Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу, и прилагане на идентификатора на интерфейса за резервиране (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
| 5 |
Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане на последно винаги е в режим на готовност.
След като VCUBE-1 се зареди напълно, запишете конфигурацията на VCUBE-2 и го презаредите.
| ||
| 6 |
Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход е подчертан с удебелен шрифт. Презаредихме VCUBE-2 последно и според съображенията за проектиране; платформата за презареждане последно винаги ще бъде Standby. |
Конфигуриране на локален портал на двете кубчета
В нашата примерна конфигурация използваме следната информация за багажника от Control Hub, за да изградим конфигурацията на локалния шлюз на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
-
Потребителско име: Hussain1076_ЛГУ
-
Парола: Артикул: LOV12MEaZx
| 1 |
Уверете се, че за паролата е създаден конфигурационен ключ, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 са криптирани с помощта на AES шифър и този потребителски дефиниран конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на контролния хъб , показани по-горе, запишете и презаредите. Идентификационните данни за SIP Digest от Control Hub се открояват в получер.
За да покажем изхода на командата на шоуто, презаредихме VCUBE-2, последван от VCUBE-1, което направи VCUBE-1 готовност CUBE и VCUBE-2 активния CUBE |
| 2 |
Във всеки един момент само една платформа ще поддържа активна регистрация като локален портал с достъп до Webex Calling SBC. Обърнете внимание на изхода на следните команди на шоуто. Показване на група за кандидатстване за съкращения 1 показване на статуса на регистриране на sip-ua
От изхода по-горе можете да видите, че VCUBE-2 е активната LGW, поддържаща регистрацията с SBC за достъп до Webex Calling, докато изхода от „показване на състоянието на регистриране на sip-ua“ е празен в 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.
|
Преглед на обаждането на Webex
Представете си, че можете да използвате функции за повиквания, мобилност и PBX в облака от корпоративен клас, заедно с приложението Webex за съобщения и срещи и повиквания от софтуерен клиент на Webex Calling или устройство на Cisco. Точно това може да ви предложи Webex Call .
Webex Calling предоставя следните функции и предимства:
-
Абонаменти за обаждания за потребители на телефония и общи части.
-
Сигурни и надеждни облачни услуги, предоставяни от доверени регионални доставчици на услуги
-
Достъп до приложението Webex за всеки потребител, добавяйки богати унифицирани комуникации и услуги за екипно сътрудничество.
-
Webex Meetings като незадължителна, интегрирана добавка за предоставяне на първокласните срещи, които корпоративните потребители очакват.
-
Достъп до публични комутируеми телефонни мрежи (PSTN), за да позволите на вашите потребители да набират номера извън организацията. Услугата се предоставя чрез съществуваща корпоративна инфраструктура
-
Локален шлюз без локална IP PBX
-
Съществуваща среда за повиквания в Unified CM
-
Опции за PSTN, предоставени от партньора или от Cisco
-
-
Поддръжка от ниво 1, осигурена от вашия партньор, поддръжка от следващо ниво, осигурена от Cisco
Control Hub е уеб базиран портал за управление, който се интегрира с Webex Calling, за да рационализирате вашите поръчки и конфигурация и да централизирате управлението на пакетната оферта – Webex Calling, приложението Webex и Webex Meetings.
|
Функция |
Описание |
|---|---|
|
Автоматичен секретар |
Можете да добавяте поздрави, да настройвате менюта и да насочвате повиквания към услуга за отговаряне, група за търсене, кутия за гласова поща или истински човек. Можете да създадете 24-часов график или да предоставите различни опции, когато бизнесът ви е отворен или затворен. Можете дори да маршрутизирате повиквания въз основа на ID атрибути на повикващия, за да създадете VIP списъци или да обработвате повиквания от определени кодове на области по различен начин. |
|
Опашка на повикванията |
Можете да настроите опашка на повикванията, когато не можете да отговаряте на входящи повиквания. Можете да предоставите на повикващите автоматизиран отговор, успокояващи съобщения и музика при задържане, докато някой може да отговори на повикването им. |
|
Поемане на повиквания |
Можете да подобрите екипната работа и сътрудничеството, като създадете група за приемане на повиквания, така че потребителите да могат да отговарят на повиквания от други потребители. Когато добавите потребители към група за взимане на повиквания и член на групата е далеч или зает, друг член може да отговори на техните обаждания. |
|
Паркиране на повикване |
Можете да включите прехвърлянето на повиквания, за да позволите на потребителите да задържат повикване и да го поемат от друг телефон. |
|
Група за търсене |
Може да искате да създадете ловни групи в следните сценарии:
|
|
Група за пейджинг |
Можете да създадете група за пейдж, така че потребителите да могат да изпращат аудио съобщение на човек, отдел или екип. Когато някой изпрати съобщение до група за пейдж, съобщението се възпроизвежда на всички устройства в групата. |
|
Клиент за рецепционисти |
Помогнете да подкрепите нуждите на персонала на вашия фронт-офис, като им предоставите пълен набор от опции за контрол на повикванията, широкомащабен мониторинг на линията, опашка на повиквания, множество опции и изгледи на директории, интеграция на Outlook и др. |
|
Функция |
Описание |
|---|---|
|
Анонимно отхвърляне на повиквания |
Потребителите могат да отхвърлят входящи повиквания с блокирани ИД на повикващия. |
|
Без прекъсване на работата |
Ако телефоните на потребителите не са свързани към мрежата по причини като спиране на тока, мрежови проблеми и т.н., потребителите могат да пренасочват входящите повиквания към определен телефонен номер. |
|
Пренасочване на повикванията |
Потребителите могат да препращат входящите обаждания към друг телефон. |
|
Селективен спедитор на повиквания |
Потребителите могат да препращат повиквания в определено време от конкретни обаждащи се. Тази настройка ще има предимство пред препращането на повиквания. |
|
Уведомление за повикване |
Потребителите могат да си изпратят имейл, когато получат обаждане съгласно предварително определени критерии като телефонен номер или дата и час. |
|
Повикване изчакване |
Потребителите могат да разрешат отговор на допълнителни входящи повиквания. |
|
Не ме безпокойте |
Потребителите могат временно да разрешат всички повиквания да отиват директно в гласовата поща. |
|
Office Anywhere |
Потребителите могат да използват избраните от тях телефони ("Местоположения") като продължение на своя бизнес телефонен номер и план за набиране. |
|
Приоритетна тревога |
Потребителите могат да звънят на телефоните си с отличителен пръстен, когато са изпълнени предварително определени критерии, като например телефонен номер или дата и час. |
|
Отдалечен офис |
Потребителите могат да извършват обаждания от отдалечен телефон и да го показват от тяхната бизнес линия. Освен това, всички входящи повиквания до тяхната служебна линия звънят на този отдалечен телефон. |
|
Селективно приемане на повиквания |
Потребителите могат да приемат обаждания в определено време от конкретни обаждащи се. |
|
Селективно отхвърляне на повиквания |
Потребителите могат да отхвърлят обаждания в определено време от конкретни обаждащи се. |
|
Последователен пръстен |
Пръстен до 5 устройства един след друг за входящи повиквания. |
|
Едновременен Пръстен |
Пръстен потребители и други ("получатели на повиквания") номера в същото време за входящи повиквания. |
Обезпечаване на услуги, устройства и потребители в Control Hub, кръстосано стартиране към подробна конфигурация в портала за администриране на повиквания
Control Hub ( https://admin.webex.com) е портал за управление, който се интегрира с Webex Calling за рационализиране на вашите поръчки и конфигурация и централизиране на вашето управление на пакетната оферта – Webex Calling, приложението Webex и Meetings.
Control Hub е централната точка за предоставяне на всички услуги, устройства и потребители. Можете да направите за първи път настройка на вашата услуга за обаждания, да регистрирате MPP телефони в облака (с помощта на MAC адрес), да конфигурирате потребителите чрез свързване на устройства, добавяне на номера, услуги, функции за обаждания и т.н. Също така, от контролния хъбможете да стартирате кръстосано до порталаза администриране на повиквания.
Потребителски опит
Потребителите имат достъп до следните интерфейси:
-
Webex Call приложение - Soft-клиент за обаждане, което е брандирано от Cisco. За повече информация вижте Разгледайте новото приложениеза обаждания на Cisco Webex.
-
Настройки за Webex ( https://settings.webex.com) – интерфейс, където потребителите могат да задават предпочитания за профила, да изтеглят приложението Webex и кръстосано стартиране в Calling User Portal за настройки за повиквания. За повече информация вижте Промяна на настройкитена Cisco Webex.
-
Webex App-Приложение, включено в абонамента като клиент за екипни съобщения с марката Cisco. За повече информация вижте Започнете с приложениетоCisco Webex.
-
Webex Meetings – Незадължително приложение, добавено като решение за срещи. За повече информация вижте Webex Срещи.
Администратори на клиенти
Като администратор на клиент на пробен или платен абонамент за Webex Calling, можете да настроите своята организация в Control Hub, като добавите местоположения, лицензи, телефонни номера, функции за повиквания, потребители и работни области (устройства за стая, които се регистрират в облака на Webex). Можете да управлявате всички тези компоненти и от там.
-
За насоки вижте Ръководството за конфигуриране на клиенти на Cisco Webex, които се обаждат.
-
За повече информация относно предложението на Webex Calling вижте Cisco Webex Calling в листа с данни за плана за Cisco Collaboration Flex за крайни клиенти
Партньори
Като доставчик на партньорски услуги можете да брандирате, предлагате и продавате Webex Calling на клиентите си. Можете да настройвате и разширявате пробни периоди, да внедрявате услуги за клиентите си и да създавате и предоставяте поръчки за клиентите си.
-
За насоки вижте Ръководството за конфигуриране на клиенти на Cisco Webex, които се обаждат (Програма за ранно записване на партньори).
-
За повече ресурси за партньори вижте ресурси Webex Calling Sales Connect. (Изисква се партньорски идентификационни данни.)
Наличност
Вижте заглавката на Webex Calling в статията Къде е наличен Cisco Webex Calling за страни, в които Webex Calling е наличен за продажба.
Направете обиколка на Control Hub
Control Hub е вашият единствен уеб-базиран интерфейс за управление на вашата организация, управление на вашите потребители, възлагане на услуги, анализиране на тенденциите в осиновяването и качество на обажданията и др.
За да стартирате организацията си, препоръчваме ви да поканите няколко потребители да се присъединят към приложението Webex , като въведете техните имейл адреси в контролния хъб. Насърчавайте хората да използват услугите, които предоставяте, включително обаждането, и да ви дадат обратна връзка за техния опит. Когато сте готови, винаги можете да добавите повече потребители.
Препоръчваме ви да използвате най-новата десктоп версия на Google Chrome или Mozilla Firefox за достъп до контролния хъб. Браузърите на мобилни устройства и други настолни браузъри могат да доведат до неочаквани резултати.
Използвайте информацията, представена по-долу, като обобщение на високо ниво за това какво да очаквате, когато вашата организация се настрои с услуги. За по-подробна информация вижте отделните глави за инструкции стъпка по стъпка.
Първи стъпки
След като партньорът ви създаде профила ви, ще получите имейл за добре дошли. Щракнете върху връзката Първи стъпки в имейла, като използвате Chrome или Firefox за достъп до Control Hub. Връзката автоматично ви подписва с вашия администраторски имейл адрес. След това ще бъдете подканени да създадете паролата на администратора си.
Магьосник за първи път за изпитания
Ако партньорът ви ви е регистрирал за пробен период, съветникът за настройка автоматично започва след като влезете в Control Hub. Съветникът ви преведе през основните настройки, за да подготви вашата организация и да работи с Webex Calling, наред с други услуги. Можете да настроите и прегледате настройките си за повикване, преди да завършите преминаването на съветника.
Прегледайте настройките си
Когато контролният хъб се зареди, можете да прегледате настройките си.
Добавяне на потребители
Сега, когато сте настроили услугите си, сте готови да добавите хора от директорията на вашата компания. Отидете на потребителите и щракнете върху Управление на потребителите .
Ако използвате Microsoft Active Directory, препоръчваме първо да разрешите синхронизацията на директориите и след това да решите как искате да добавите потребители. Щракнете върху Напред и следвайте инструкциите , за да настроите конектора за директория на Cisco.
Настройване на единичен знак (SSO)
Приложението Webex използва базово удостоверяване. Можете да изберете да настроите SSO, така че потребителите да се удостоверяват с вашия доставчик на корпоративна самоличност с помощта на техните корпоративни идентификационни данни, а не с отделна парола, съхранена и управлявана в Webex.
Отидете в Настройки, превъртете до удостоверяване, щракнете върху Промянаи след това изберете Интегриране на доставчикна идентичност от третастрана.
Разпределяне на услуги на потребителите
Трябва да присвоите услуги на потребителите, които сте добавили, така че хората да могат да започнат да използват Webex App.
Отидете на потребителите, щракнете върху Управление на потребителите, изберете Експортиране и импортиране на потребители с CSV файли след това щракнете върху Експортиране .
Във файла, който изтегляте, просто добавете True за услугите, които искате да присвоите на всеки от вашите потребители.
Импортирайте попълнения файл, щракнете върху Добавяне и премахване на услугии след това щракнете върху Изпращане. Вече сте готови да конфигурирате функциите за обаждания, да регистрирате устройства, които могат да бъдат споделени на общо място, и да регистрирате и свързвате устройства с потребителите.
Овластяване на вашите потребители
Сега, когато сте добавили потребители и им е възложени услуги, те могат да започнат да използват поддържаните си мултиплатформени телефони (MPPs) за Webex Calling и Webex App за съобщения и срещи. Насърчавайте ги да използват настройките на Cisco Webex като обслужване на едно гише за достъпа.
Ролята на местния портал
Местният портал е корпоративно или партньорско управлявано устройство за съвместна работа и наследен обмен на публични клонове (PBX) (включително Unified CM).
Можете да използвате Control Hub, за да присвоите локален шлюз на място, след което Control Hub предоставя параметри, които можете да конфигурирате на CUBE. Тези стъпки регистрират локалния шлюз с облака, а след това услугата PSTN се предоставя чрез портала към потребителите на Webex Calling на определено място.
За да зададете и поръчате местен шлюз, прочетете ръководствотоза поръчка на местния шлюз.
Поддържани локални разполагания на шлюзове за Webex повикване
Поддържат се следните основни разполагания:
Местният портал може да бъде разположен самостоятелно или в разполагания, където се изисква интеграция в Cisco Unified Communications Manager.
Локални разполагания на шлюзове без локален IP PBX
Самостоятелни локални разполагания на портали
Тази цифра показва разгръщане на Webex Calling без съществуващ IP PBX и е приложима за едно място или разполагане на няколко локации.
За всички повиквания, които не съответстват на вашите дестинации за обаждания на Webex, Webex Calling изпраща тези обаждания до местния портал, който е присвоен на местоположението за обработка. Местният портал маршрутизира всички повиквания, които идват от Webex Call до PSTN и в другата посока, PSTN до Webex Calling.
PSTN порталът може да бъде специална платформа или съжител с местния портал. Както и в следващата фигура, препоръчваме специалния вариант на PSTN шлюза на това разполагане; може да се използва, ако съществуващият PSTN шлюз не може да се използва като локален портал Webex Call .
Съвместно разполагане на локален портал
Локалният шлюз може да бъде IP базиран, свързвайки се към ITSP с помощта на SIP багажник или TDM базиран с помощта на ISDN или аналогова верига. Следващата цифра показва разгръщане на Webex Call , където местният портал е съжител на PSTN GW/SBC.
Разполагане на локален шлюз с единен CM PBX на място
Интеграции с Unified CM се изискват в следните случаи:
-
Местоположенията с възможност за повикване на Webex се добавят към съществуващо внедряване на Cisco UC, където Unified CM серазгръща като решение за контрол на повикванията на място
-
Необходимо е директно набиране между телефони, регистрирани в Unified CM и телефони в местоположенията на Webex Call .
Тази цифра показва разгръщане на Webex Call , където клиентът има съществуващ Unified CM IP PBX.
Webex Calling изпраща обаждания, които не съответстват на дестинациите за обаждания на клиента Webex до местния портал. Това включва PSTN номера и Unified CM вътрешни разширения, които Webex Calling не може да види. Местният портал маршрутизира всички повиквания, които идват от Webex Calling до Unified CM и обратно. След това единната CM маршрутизира входящите повиквания до местните дестинации или до PSTN съгласно съществуващия план за набиране. Единният план за набиране на CM нормализира числата като +E.164. Порталът PSTN може да бъде специален или съжител с местния портал.
Специален PSTN шлюз
Специалният вариант на PSTN шлюза на това разполагане, както е показано на тази диаграма, е препоръчителната опция и може да се използва, ако съществуващият PSTN шлюз не може да се използва като локален портал Webex Call .
Съжител на PSTN Гейтуей
Тази цифра показва разгръщане на Webex Calling с унифициран CM, където местният портал е съжител на PSTN шлюза / SBC.
Webex Call маршрути всички повиквания, които не съответстват на Webex Calling дестинации на клиента към местния шлюз, който е присвоен на местоположението. Това включва PSTN дестинации и в мрежата повиквания към Unified CM вътрешни разширения. Местният портал маршрутизира всички обаждания до Unified CM. След това Unified CM маршрутизира обаждания до локално регистрирани телефони или до PSTN през локалния шлюз, който има съвместно разположен PSTN/SBC функционалност.
Съображения за маршрутизиране на обажданията
Обаждания от Webex, призоваващи към унифицирана CM
Логиката за маршрутизиране на Webex Calling работи по следния начин: ако номерът, който е набран на крайна точка на Webex Calling, не може да бъде насочен към друга дестинация в рамките на същия клиент в Webex Calling , тогава обаждането се изпраща до местния портал за по-нататъшна обработка. Всички обаждания извън мрежата (извън Webex Calling) се изпращат до местния портал.
За внедряване на Webex Calling без интегриране в съществуващ Unified CM, всяко повикване извън мрежата се счита за PSTN повикване. Когато се комбинира с Unified CM, повикването извън мрежата все още може да бъде повикване в мрежата до всяка дестинация, хоствана на Unified CM или истинско обаждане извън мрежата до дестинация за PSTN. Разликата между последните два типа повиквания се определя от Единния CM и зависи от плана за набиране на предприятието, който е предоставен на Unified CM.
Следващата цифра показва потребител на Webex Call , който набира национален номер в САЩ.
Унифицираният CM сега въз основа на конфигурирания план за набиране насочва повикването до локално регистрирана крайна точка, на която нареченото местоназначение се предоставя като номер на директория. За тази цел Единният план за набиране на CM трябва да поддържа маршрутизиране на +E.164 номера.
Обаждания от унифициран CM до Webex повикване
За да се даде възможност за маршрутизиране на повиквания от Unified CM до Webex Призоваване на Unified CM, трябва да се предостави набор от маршрути, за да се определи наборът от +E.164 и адресите на плана за номериране на предприятието в Webex Calling.
С тези маршрути са възможни и двата сценария на повикване, показани на следващата цифра.
Ако повикващият в PSTN извика DID номер, който е присвоен на устройство за повикване на Webex, тогава повикването се предава на предприятието чрез PSTN шлюза на предприятието и след това удря Unified CM. Нареченият адрес на това повикване съвпада с един от маршрутите за повикване на Webex, който е предоставен в Unified CM и повикването се изпраща до местния портал. (Повикваният адрес трябва да е във формат +E.164, когато се изпраща към локалния шлюз.) След това логиката за маршрутизиране на Webex Calling гарантира, че повикването се изпраща до съответното устройство с Webex Calling въз основа на задаването на DID.
Също така, повикванията, произхождащи от регистрирани крайни точки на Unified CM, насочени към дестинации в Webex Calling, са предмет на плана за набиране, който е предоставен на Unified CM. Обикновено този план за набиране позволява на потребителите да използват общи навици за набиране на предприятия, за да извършват разговори. Тези навици не включват непременно само +E.164 набиране. Всеки навик за набиране, различен от +E.164, трябва да бъде нормализиран до +E.164, преди обажданията да бъдат изпратени до местния портал, за да се даде възможност за правилно маршрутизиране в Webex Calling.
Клас на обслужване (CoS)
Прилагането на строг клас ограничения на услугите винаги се препоръчва по различни причини, включително избягване на цикли на повикване и предотвратяване на измами с пътни такси. В контекста на интегрирането на Webex Calling Local Gateway с унифициран CM клас услуги трябва да разгледаме класа на обслужване за:
-
Устройства, регистрирани с Унифициран CM
-
Призиви, идващи в Unified CM от PSTN
-
Обаждания, идващи в Unified CM от Webex Calling
Устройства, регистрирани с Унифициран CM
Добавянето на дестинациите Webex Calling като нов клас дестинации към съществуваща настройка на CoS е доста право напред: разрешение за обаждане до дестинации за обаждания на Webex обикновено е еквивалентно на разрешението за повикване на предпоставката (включително междусайтови) дестинации.
Ако планът за набиране на предприятието вече изпълнява разрешение "(съкратено) междусистемно в мрежата", тогава вече има дял, предоставен на Unified CM, който можем да използваме и предоставим всички известни дестинации в мрежата Webex Calling в същия дял.
В противен случай концепцията за разрешение "(съкратено) междусистемно място" все още не съществува, тогава трябва да бъде предоставен нов дял (например "onNetRemote"), дестинациите за извикване на Webex се добавят към този дял и накрая този нов дял трябва да бъде добавен към съответните пространства за търсене на повиквания.
Призиви, идващи в Unified CM от PSTN
Добавянето на дестинациите Webex Calling като нов клас дестинации към съществуваща настройка на CoS е доста право напред: разрешение за обаждане до дестинации за обаждания на Webex обикновено е еквивалентно на разрешението за повикване на предпоставката (включително междусайтови) дестинации.
Ако планът за набиране на предприятието вече изпълнява разрешение "(съкратено) междусистемно в мрежата", тогава вече има дял, предоставен на Unified CM, който можем да използваме и предоставим всички известни дестинации в мрежата Webex Calling в същия дял.
В противен случай концепцията за разрешение "(съкратено) междусистемно място" все още не съществува, тогава трябва да бъде предоставен нов дял (например "onNetRemote"), дестинациите за извикване на Webex се добавят към този дял и накрая този нов дял трябва да бъде добавен към съответните пространства за търсене на повиквания.
Обаждания, идващи в Unified CM от Webex Calling
Обажданията, идващи от PSTN, се нуждаят от достъп до всички дестинации за обаждания на Webex. Това изисква добавяне на горния дял, който държи всички дестинации за повикване на Webex към пространството за търсене на повиквания, използвано за входящи повиквания на багажника на PSTN. Достъпът до дестинациите за обаждания на Webex идва в допълнение към вече съществуващия достъп.
Докато за повиквания от PSTN достъп до унифицирани CM DIDs и Webex повикване DIDs се изисква повиквания с произход от Webex повикване нужда достъп до унифицирани CM DIDs и PSTN дестинации.
Тази цифра сравнява тези два различни класа услуги за разговори от PSTN и Webex Calling. Фигурата показва също, че ако функционалността на PSTN шлюза е съчетана с локалния портал, тогава са необходими два багажника от комбинирания PSTN GW и локалния портал към Unified CM: един за повиквания с произход от PSTN и един за повиквания с произход от Webex Calling. Това се дължи на изискването за прилагане на диференцирани пространства за търсене на повиквания по тип трафик. С два входящи багажника на Unified CM това може лесно да се постигне чрез конфигуриране на необходимото пространство за търсене на повиквания за входящи повиквания на всеки багажник.
Интеграция на плана за набиране
Това ръководство предполага съществуваща инсталация, която се основава на най-добрите актуални практики в "Предпочитана архитектура за внедряване на Cisco сътрудничество на място, CVD". Най-новата версия е достъпна тук.
Препоръчителният дизайн на плана за набиране следва подхода на проектиране, който е документиран в главата Dial Plan на най-новата версия на системата за сътрудничество Cisco SRND, налична тук.
Тази цифра показва преглед на препоръчителния дизайн на плана за набиране. Основните характеристики на този дизайн на плана за набиране включват:
-
Всички номера на директории, които са конфигурирани на Unified CM, са във формат +E.164.
-
Всички номера на директории пребивават в един и същ дял (DN) и са маркирани спешно.
-
Маршрутизирането на ядрото се основава на +E.164.
-
Всички навици за набиране извън +E.164 (например съкратено набиране в рамките на обекта и набиране на PSTN, използвайки общи навици за набиране) се нормализират (глобализират) до +E.164, като се използват модели за превод на нормализиране на набирането.
-
Набирането на модели за нормализиране на превода използва модел на превод, призоваващ наследяване на пространството за търсене; те имат набор от опции "Използване на пространството за търсене на повиквания на оригинатора".
-
Класът на услугата се изпълнява с помощта на сайт и клас специфични за услугата пространства за търсене на повиквания.
-
Възможностите за достъп до PSTN (например достъп до международни дестинации за PSTN) се изпълняват чрез добавяне на дялове със съответните модели на маршрута +E.164 към пространството за търсене, определящо класа услуги.
Достъпност на Webex повикване
За да добавите достъпност за дестинациите за извикване на Webex към този план за набиране, трябва да се създаде дял, представляващ всички дестинации за извикване на Webex ("Webex Calling") и към този дял се добавя модел на маршрут +E.164 за всеки диапазон на DID в Webex Call. Този маршрутен модел препраща към списък с маршрути само с един член: маршрутната група със SIP багажника до местния портал за обаждания до Webex Calling. Тъй като всички набрани дестинации се нормализират до +E.164 или с помощта на модели за превод за нормализиране на набирането за повиквания, произхождащи от регистрирани крайни точки на Unified CM, или входящи наречени партийни трансформации за повиквания, произхождащи от PSTN, този единствен набор от модели на маршрути +E.164 е достатъчен, за да се постигне достъпност за дестинации в Webex Calling независимо от използвания навик за набиране.
Ако например потребител набере "914085550165", тогава моделът на превод за нормализиране на набирането в дял "UStoE164" нормализира този низ за набиране до "+14085550165", който след това съответства на модела на маршрута за дестинация за повикване на Webex в дял "Webex Calling". Единната CM в крайна сметка изпраща призива към местния портал.
Добавяне на съкратено междусайтно набиране
Препоръчителният начин да добавите съкратено междусистемно набиране към референтния план за набиране е да добавите модели за превод на нормализиране на набирането за всички сайтове по плана за номериране на предприятието към специален дял ("ESN", Enterprise Significant Numbers). Тези модели на превод прихващат струните за набиране във формата на плана за номериране на предприятието и нормализират набрания низ до +E.164.
За да добавите съкратено набиране на предприятия към дестинациите за обаждания на Webex, добавяте съответния модел на превод за нормализиране на набирането за местоположението на Webex Calling към дяла "Webex Calling" (например "8101XX" в диаграмата). След нормализиране обаждането отново се изпраща на Webex Call, след като съответства на модела на маршрута в дяла "Webex Calling".
Не препоръчваме да добавяте съкратения модел за превод на нормализиране на набирането за Webex Calling повиквания към дяла "ESN", защото тази конфигурация може да създаде нежелани цикли за маршрутизиране на повиквания.
Протоколни манипулатори за повикване
Webex Calling регистрира следните манипулатори на протоколи с операционната система, за да позволи функционалност за кликване до повикване от уеб браузъри или друго приложение. Следните протоколи стартират аудио или видео повикване в Webex App, когато това е приложението за повикване по подразбиране на Mac или Windows:
-
КЛИКТОКОЛ: или CLICKTOCALL://
-
СИП: или SIP://
-
ТЕЛ: или TEL://
-
УЕБЕКСТЕЛ: или WEBEXTEL://
Протоколни манипулатори за Windows
Други приложения могат да се регистрират за манипулаторите на протокола преди приложениетоWebex. В Windows 10 системният прозорец да поиска от потребителите да изберат кое приложение да използват, за да стартират повикването. Предпочитанията на потребителя могат да бъдат запомнени, ако потребителят проверява Винаги използвайте това приложение.
Ако потребителите трябва да нулират настройките на приложението за повикване по подразбиране, така че да могат да изберат Webex App, можете да ги инструктирате да променят асоциациите на протоколите за Webex App в Windows 10:
-
Отворете системните настройки Настройки на приложението по подразбиране , щракнете върху Задаване на настройки по подразбиране по приложение и след това изберете Приложение Webex.
-
За всеки протокол изберете Приложение Webex.
Протоколни манипулатори за macOS
На Mac OS, ако други приложения, регистрирани в протоколите за обаждания преди Webex App, потребителите трябва да конфигурират своето Webex приложение , за да бъде опцията за повикване по подразбиране.
В приложението Webex за Mac потребителите могат да потвърдят, че приложението Webex е избрано за Стартиране на повиквания с настройка в общите предпочитания. Те могат също да проверят Винаги свързвай с Microsoft Outlook , ако искат да извършват повиквания в приложението Webex, когато щракнат върху номер на контакт на Outlook.
Подготовка на средата
Общи предпоставки
Преди да конфигурирате локален шлюз за Webex Calling, уверете се, че:
-
Имате основни познания за принципите на VoIP
-
Имате основни работни познания за гласовите концепции на Cisco IOS-XE и IOS-XE
-
Имате основно разбиране за протокола за стартиране на сесия (SIP)
-
Имате основно разбиране за Cisco Унифициран комуникационен мениджър (Unified CM), ако вашият модел за внедряване включва Unified CM
Вижте Ръководство за корпоративна конфигурация на Cisco Unified Border Element (CUBE) за подробности.
Хардуерни и софтуерни изисквания за локален шлюз
Уверете се, че разполагането ви има един или повече от локалните шлюзове, като например:
-
Cisco CUBE за IP-базирана свързаност
-
Cisco IOS шлюз за базирана на TDM свързаност
Локалният шлюз ви помага да мигрирате към Webex Calling със собствено темпо. Локалният шлюз интегрира съществуващото ви локално разполагане с Webex Calling. Можете също да използвате съществуващата си PSTN връзка. Вижте Първи стъпки с локален шлюз
Изисквания за лиценз за местни портали
Лицензите за повикване на 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
Правилно конфигурираната защитна стена и прокси сървър са от съществено значение за успешното разполагане на Calling. Webex Calling използва SIP и HTTPS за сигнализиране на повикванията и свързаните с тях адреси и портове за мултимедия, мрежова връзка и свързване на шлюза, тъй като Webex Calling е глобална услуга.
Не всички конфигурации на защитната стена изискват отваряне на портовете. Ако обаче изпълнявате правила от вътрешната към външната страна, трябва да отворите портове за необходимите протоколи, за да разрешите услугите.
Превод на мрежови адреси (NAT)
Функциите за превод на мрежови адреси (NAT) и превод на адреси на портове (PAT) се прилагат на границата между двете мрежи за превод на адресни пространства или за предотвратяване на сблъсък на IP адресни пространства.
Организациите използват технологии на шлюза, като защитни стени и прокси сървъри, които предоставят NAT или PAT услуги, за да осигурят достъп до интернет до приложенията на приложението Webex или Webex устройства, които са в частно място за IP адреси. Тези шлюзове карат трафикът от вътрешни приложения Или Устройства към интернет да изглежда идва от един или повече публично маршрутизирани IP адреси.
-
Ако разполагате с NAT, не е задължително да отваряте входящ порт на защитната стена.
-
Потвърдете размера на набора от NAT, необходим за свързване с приложения или устройства, когато множество потребители на приложения и устройства имат достъп до услуги с Webex Calling и Webex Aware с помощта на NAT или PAT. Уверете се, че към наборите от NAT са зададени адекватни публични IP адреси, за да се предотврати изчерпването на портовете. Изчерпването на портове допринася за това, че вътрешните потребители и устройства не могат да се свързват с услугите Webex Calling и Webex Aware.
-
Определете разумни периоди на обвързване и избягвайте манипулирането със SIP на NAT устройството.
-
Конфигурирайте минимално време за изчакване на NAT, за да гарантирате правилната работа на устройствата. Пример: Телефоните на Cisco изпращат съобщение за обновяване НА регистъра на всеки 1-2 минути.
-
Ако мрежата прилага NAT или SPI, тогава задайте по-голямо време за изчакване (от поне 30 минути) за връзките. Това време на изчакване позволява надеждна свързаност, като същевременно намалява консумацията на батерията на мобилните устройства на потребителите.
SIP шлюз за слой на приложение
Ако маршрутизаторът или защитната стена са запознати със SIP, което означава, че е активиран SIP Application Layer Gateway (ALG) или подобен шлюз, препоръчваме да изключите тази функционалност за точна работа на услугата. Въпреки че целият трафик на Webex Calling е шифрован, някои внедрявания на SIP ALG могат да причинят проблеми с преминаването на защитната стена. Ето защо препоръчваме да изключите SIP ALG, за да осигурите висококачествено обслужване.
Проверете в документацията на съответния производител за стъпките за деактивиране на SIP ALG на конкретни устройства.
Поддръжка на прокси сървър за Webex Calling
Организациите разгръщат интернет защитна стена или интернет прокси сървър и защитна стена, за да инспектират, ограничават и контролират HTTP трафика, който напуска и влиза в тяхната мрежа. По този начин защитават тяхната мрежа от различни форми на кибератаки.
Прокси сървърите изпълняват няколко функции за защита, като например:
-
Разрешете или блокирайте достъпа до определени URL адреси.
-
Удостоверяване на потребителя
-
Проверка на IP адрес/домейн/име на хост/репутация на URI
-
Дешифроване и проверка на трафика
При конфигуриране на прокси функцията се прилага за всички приложения, които използват протокола HTTP.
Приложението Webex и приложенията за устройства Webex включват следното:
-
Услуги на Webex
-
Процедури за активиране на устройства на клиента (CDA), използващи платформата за обезпечаване на облака на Cisco, като GDS, EDOS активиране, обезпечаване и включване в облака на Webex.
-
Удостоверяване със сертификат
-
Надграждане на фърмуера
-
Отчети за статуса
-
Качвания на PRT
-
Услуги на XSI
Ако е конфигуриран адрес на прокси сървър, само сигналният трафик (HTTP/HTTPS) се изпраща към прокси сървъра. Клиентите, които използват SIP, за да се регистрират в услугата Webex Calling, и свързаната с нея мултимедия, не се изпращат към прокси сървъра. Ето защо, позволете на тези клиенти да преминават директно през защитната стена.
Поддържани опции за прокси сървър, конфигурация и типове удостоверяване
Поддържаните типове прокси сървъри са:
-
Изричен прокси сървър (проверка или непроверка) – Конфигуриране на клиентите или приложението, или устройството с изричен прокси сървър, за да укажете сървъра за използване.
-
Прозрачен прокси сървър (без проверка) – клиентите не са конфигурирани да използват определен адрес на прокси сървъра и не изискват промени, за да работят с прокси сървър без проверка.
-
Прозрачен прокси сървър (проверка) – клиентите не са конфигурирани да използват определен адрес на прокси сървъра. Не са необходими промени в конфигурацията на HTTP; обаче приложението или устройствата за вашите клиенти се нуждаят от корневи сертификат, за да се доверят на прокси сървъра. ИТ екипът използва инспектиращите прокси сървъри, за да наложи правила на уеб сайтовете за посещение и типовете съдържание, които не са разрешени.
Конфигурирайте ръчно прокси адресите за устройствата на Cisco и приложението Webex с помощта на:
-
Операционна система на платформата
-
Потребителски интерфейс на устройството
-
Автоматично откриване с помощта на уеб прокси механизми, като:
-
Автоматично откриване на уеб прокси сървър (WPAD) – Протокол за автоматично откриване на уеб прокси сървър
-
Файлове за автоматично конфигуриране на прокси сървъра (PAC) – Файлове за автоматично конфигуриране на прокси сървъра
-
Докато конфигурирате предпочитаните си типове продукти, изберете от следните типове конфигурации на прокси сървъри и удостоверяване в таблицата:
|
Продукт |
Конфигурация на прокси сървър |
Вид удостоверяване |
|---|---|---|
|
Webex за Mac |
Ръчно, WPAD, PAC |
Без удостоверяване, Базово, NTLM,† |
|
Webex за Windows |
Ръчно, WPAD, PAC, GPO |
Без удостоверяване, Базово, NTLM, † , Съгласуване † |
|
Webex за iOS |
Ръчно, WPAD, PAC |
Без удостоверяване, Базово, Хеширано, NTLM |
|
Webex за Android |
Ръчно, PAC |
Без удостоверяване, Базово, Хеширано, NTLM |
|
Уеб приложение на Webex |
Поддържа се чрез ОС |
Без удостоверяване, Базово, Хеширано, NTLM, Съгласуване † |
|
Устройства с Webex |
WPAD, PAC или Ръчно |
Без удостоверяване, Базово, Хеширано |
|
IP телефони Cisco |
Ръчно, WPAD, PAC |
Без удостоверяване, Базово, Хеширано |
|
Възел за Webex Video Mesh |
Ръчно |
Без удостоверяване, Базово, Хеширано, NTLM |
За легенди в таблицата:
-
† Mac NTLM Auth – Машината не трябва да е влязла в домейна, потребителят получава подкана за парола
-
† Windows NTLM Auth – Поддържа се само ако машината е влязла в домейна
-
Преговаряйте за † – Kerberos с резервно удостоверяване на NTLM.
-
За да свържете устройство от серията Cisco Webex Board, Desk или Room към прокси сървър, вижте Свързване на вашето устройство от серията Board, Desk или Room към прокси сървър.
-
За Cisco IP телефони вижте Настройване на прокси сървър като пример за конфигуриране на прокси сървъра и настройките.
За Без удостоверяванеконфигурирайте клиента с прокси адрес, който не поддържа удостоверяване. Когато използвате Удостоверяване в прокси сървър, конфигурирайте с валидни идентификационни данни. Прокситата, които инспектират уеб трафика, може да пречат на връзките с уеб гнездото. Ако възникне този проблем, заобикалянето на неинспектирания трафик към *.Webex.com може да реши проблема. Ако вече виждате други записи, добавете точка и запетая след последния запис и след това въведете изключението в Webex.
Настройки на прокси сървър за операционна система Windows
Microsoft Windows поддържа две мрежови библиотеки за HTTP трафик (WinINet и WinHTTP), които позволяват конфигуриране на прокси сървър. WinINet е супернабор от WinHTTP.
-
WinInet е предназначен за настолни клиентски приложения за един потребител
-
WinHTTP е проектиран главно за многопотребителски, базирани на сървъри приложения
Когато избирате между двете, изберете WinINet за настройките на конфигурацията на прокси сървъра. За подробности вижте wininet-vs-winhttp.
Вижте Конфигуриране на списък с разрешени домейни за достъп до Webex, докато сте във вашата корпоративна мрежа за подробности относно следното:
-
За да сте сигурни, че хората влизат в приложения само с помощта на акаунти от предварително дефиниран списък с домейни.
-
Използвайте прокси сървър за прихващане на заявки и ограничаване на домейните, които са разрешени.
Проверка на прокси сървъра и закачане на сертификати
Приложението и устройствата Webex валидират сертификатите на сървърите при установяването на TLS сесии. Сертификатът проверява дали като издателя на сертификата и цифровия подпис разчитат на проверка на веригата от сертификати до главния сертификат. За да извършат проверките за валидиране, приложението и устройствата Webex използват набор от надеждни главни сертификати на сертифициращ орган, инсталирани в хранилището за доверие на операционната система.
Ако сте разположили прокси сървър за проверка на TLS, за да прехващате, дешифрирате и инспектирате трафика на Webex Calling. Уверете се, че сертификатът, който се представя от прокси сървъра (вместо сертификата за услуга Webex), е подписан от сертифициращ орган, а главният сертификат е инсталиран в хранилището за доверие на вашето приложение Webex или устройство Webex.
-
За приложение Webex – Инсталирайте CA сертификата, който се използва за подписване на сертификата от прокси сървъра в операционната система на устройството.
-
За устройства Webex Room и мултиплатформени IP телефони на Cisco – отворете заявка за услуга с екипа TAC, за да инсталирате CA сертификата.
Тази таблица показва приложението Webex и устройствата Webex, които поддържат проверка на TLS от прокси сървъри
|
Продукт |
Поддържа персонализирани надеждни сертифициращи орган за TLS инспекция |
|---|---|
|
Приложение Webex (Windows, Mac, iOS, Android, интернет) |
Да |
|
Устройства Webex Room |
Да |
|
Мултиплатформени Cisco IP телефон (MPP) |
Да |
Конфигурация на защитната стена
Cisco поддържа услугите Webex Calling и Webex Aware в защитени центрове за данни на Cisco и Amazon Web Services (AWS). Amazon е запазила своите IP подмрежи единствено за Cisco и е осигурила услугите, разположени в тези подмрежи, в рамките на виртуалния частен облак на AWS.
Конфигурирайте защитната стена, за да позволите комуникация от вашите устройства, приложения на приложението и интернет услугите, за да изпълняват правилно функциите си. Тази конфигурация позволява достъп до всички поддържани услуги в облака Webex Calling и Webex Aware, имена на домейни, IP адреси, портове и протоколи.
Списък с бели списъци или отворен достъп до следното, така че услугите Webex Calling и Webex Aware да функционират правилно.
-
URL адресите/домейните, споменати в раздела Домейни и URL адреси за услугите на Webex Calling
-
IP подмрежи, портове и протоколи, споменати в раздела IP подмрежи за услугите Webex Calling
-
Ако използвате Webex Suite на услуги за сътрудничество в облака в рамките на тяхната организация, Webex Meetings, Messaging, Webex Attendant Console и други услуги, тогава се уверете, че имате IP подмрежите, а домейните/URL адресите, посочени в тези статии, са отворени Мрежови изисквания за Webex Services и Мрежови изисквания за Attendant Console
Ако използвате само защитна стена, филтрирането на трафика на Webex Calling само с помощта на IP адреси не се поддържа, тъй като някои от наборите от IP адреси са динамични и могат да се променят по всяко време. Актуализирайте редовно правилата си, ако не успеете да актуализирате списъка с правила на защитната стена, това може да повлияе на работата на вашите потребители. Cisco не поддържа филтриране на поднабор от IP адреси въз основа на определен географски регион или доставчик на облачни услуги. Филтрирането по региони може да доведе до сериозно влошаване на услугата за повиквания.
Cisco не поддържа динамично променящи се набори от IP адреси, поради което не са изброени в тази статия.
Ако защитната ви стена не поддържа филтриране на домейн/URL адреси, използвайте опцията за корпоративен прокси сървър. Тази опция филтри/позволява по URL адрес/домейн сигналния трафик на HTTPs към услугите Webex Calling и Webex Aware във вашия прокси сървър, преди да се пренасочи към защитната стена.
Можете да конфигурирате трафик с помощта на филтриране на портове и IP подмрежа за повиквания. Тъй като мултимедийният трафик изисква директен достъп до интернет, изберете опцията за филтриране на URL адреси за сигнален трафик.
За Webex Calling UDP е предпочитаният транспортен протокол за мултимедия на Cisco и препоръчва използване само на SRTP през UDP. TCP и TLS като транспортни протоколи за мултимедия не се поддържат за Webex Calling в производствени среди. Ориентираният към връзката характер на тези протоколи оказва влияние върху качеството на мултимедията в загубените мрежи. Ако имате запитвания относно транспортния протокол, подайте билет за поддръжка.
Домейни и URL адреси за услугите на Webex Calling
Знак * в началото на URL адреса (например *.webex.com) показва, че услугите в домейна от първо ниво и всички поддомейни са достъпни.
|
Домейн/URL адрес |
Описание |
Приложения Webex и устройства, използващи тези домейни/URL адреси |
|---|---|---|
|
Услуги на Cisco Webex | ||
|
*.broadcloudpbx.com |
Webex оторизиране микроуслуги за кръстосано стартиране от Control Hub до Call Admin портал. |
Control Hub |
|
*.broadcloud.com.au |
Webex Call услуги в Австралия. |
Всички |
|
*.broadcloud.eu |
Услуги за обаждания на Webex в Европа. |
Всички |
|
*.broadcloudpbx.net |
Извикване на клиентска конфигурация и услуги за управление. |
Уеб Екс Апс |
|
*.webex.com *.cisco.com |
Основни услуги на Webex Calling и Webex Aware
Когато телефонът се свърже към мрежата за първи път или след нулиране до фабричните настройки без зададени опции за DHCP, той се свързва със сървър за активиране на устройството за обезпечаване с нулево докосване. Новите телефони използват activate.cisco.com и телефоните с версия на фърмуера, по-ранна от 11.2(1), продължете да използвате webapps.cisco.com за обезпечаване. Изтеглете фърмуера на устройството и локалните актуализации от binaries.webex.com. Разрешете на многоплатформени телефони Cisco (MPPs), по-стари от версия 12.0.3, достъп до sudirenewal.cisco.com през порт 80 за подновяване на инсталирания от производителя сертификат (MIC) и имат защитен уникален идентификатор на устройството (SUDI). За подробности вижте Известие за поле. |
Всички |
|
*.ucmgmt.cisco.com |
Услуги за обаждания на Webex |
Control Hub |
|
*.wbx2.com и *.ciscospark.com |
Използва се за осведоменост в облака за достъп до услугите на Webex Calling и Webex Aware по време на и след включването. Тези услуги са необходими за
|
Всички |
|
*.webexapis.com |
Микроуслуги на Webex, които управляват вашите приложения на приложението Webex и устройства с Webex.
|
Всички |
|
*.webexcontent.com |
Услуги за съобщения на Webex, свързани с общо съхранение на файлове, включително:
|
Услуги за съобщения за приложения на Webex. Мястото за съхранение на файлове с webexcontent.com е заменено от clouddrive.com през октомври 2019 г. |
|
*.accompany.com |
Интегриране на информация за участниците |
Приложения Webex |
|
Допълнителни услуги, свързани с Webex (домейни на трети страни) | ||
|
*.appdynamics.com *.eum-appdynamics.com |
Проследяване на производителността, грешка и улавяне на сривове, показатели за сесията. |
Control Hub |
|
*.sipflash.com |
Услуги за управление на устройства. Надграждане на фърмуера и защитени цели за включване. |
Уеб Екс Апс |
|
*.walkme.com *.walkmeusercontent.com |
Webex клиент за ориентиране на потребителя. Осигурява обиколки на борда и използване за нови потребители. За повече информация относно WalkMe, кликнете тук. |
Уеб Екс Апс |
|
*.google.com *.googleapis.com |
Известия до приложенията Webex на мобилни устройства (Пример: ново съобщение, когато се отговори на повикването) За IP подмрежите вижте тези връзки Услуга за съобщения в облака на Google Firebase (FCM) Услуга за пуш известия на Apple (APNS) За APNS Apple изброява IP подмрежите за тази услуга. | Приложение Webex |
IP подмрежи за услуги на Webex Calling
|
IP подмрежи за услугите на Webex Calling*† | ||
|---|---|---|
|
23.89.0.0/16 |
85.119.56.0/23 |
128.177.14.0/24 |
|
128.177.36.0/24 |
135.84.168.0/21 |
139.177.64.0/21 |
|
139.177.72.0/23 |
144.196.0.0/16 |
150.253.128.0/17 |
|
163.129.0.0/17 |
170.72.0.0/16 |
170.133.128.0/18 |
|
185.115.196.0/22 |
199.19.196.0/23 |
199.19.199.0/24 |
|
199.59.64.0/21 | ||
|
Конфигуриране на устройството и управление на фърмуера (Cisco устройства) | ||
|
3.20.185.219 |
3.130.87.169 |
3.134.166.179 |
|
52.26.82.54 |
72.163.10.96/27 |
72.163.15.64/26 |
|
72.163.15.128/26 |
72.163.24.0/23 |
72.163.10.128/25 |
|
173.37.146.128/25 |
173.36.127.0/26 |
173.36.127.128/26 |
|
173.37.26.0/23 |
173.37.149.96/27 |
192.133.220.0/26 |
|
192.133.220.64/26 | ||
|
Конфигурация на приложението Webex | ||
|
62.109.192.0/18 |
64.68.96.0/19 |
150.253.128.0/17 |
|
207.182.160.0/19 | ||
|
Цел на връзката | Изходни адреси | Изходни портове | Протокол | Адреси на местоназначение | Пристанища на местоназначение | Бележки | |
|---|---|---|---|---|---|---|---|
| Сигнализация на повиквания към Webex повикване (SIP TLS) | Външен локален шлюз (NIC) | 8000-65535 | TCP | Обърнете се към IP подмрежи за Webex услуги за обаждания. | 5062, 8934 |
Тези IP адреси/портове са необходими за сигнализиране на изходящи SIP-TLS повиквания от локални шлюзове, устройства и приложения на приложението Webex (източник) към облака на Webex Calling (местоназначение). Порт 5062 (изисква се за базирана на сертификат външна връзка). и порт 8934 (изисква се за базираната на регистрация съединителна линия | |
| Устройства | 5060-5080 | 8934 | |||||
| Приложение Webex | Ефимерна (зависима от OS) | ||||||
| Сигнализиране на повикванията от Webex Calling (SIP TLS) към локален шлюз |
диапазон от адреси в Webex Calling. Вижте IP подмрежи за услуги на Webex Calling | 8934 | TCP | IP или диапазон от IP адреси, избрани от клиента за неговия локален шлюз | Порт или диапазон от портове, избрани от клиента за неговия локален шлюз |
Прилага се за локални шлюзове, базирани на сертификат. Необходимо е да се установи връзка от Webex Calling към локален шлюз. Локалният шлюз, базиран на регистрация, работи по повторното използване на връзка, създадена от локалния шлюз. Целевият порт е избран от клиента Конфигуриране на съединителни линии | |
| Повикване на мултимедия към Webex Calling (STUN, SRTP/SRTCP, T38, DTLS) | Локален шлюз външен NIC | 8000-48199†* | СДП | Обърнете се към IP подмрежи за Webex услуги за обаждания. |
5004, 9000 (STUN портове) Аудио: 8500-8599 Видео: 8600-8699 19560-65535 (SRTP през UDP) |
| |
| Устройства† * | 19560-19661 | ||||||
|
VG400 ATA устройства | 19560-19849 | ||||||
| Приложение Webex† * |
Аудио: 8500-8599 Видео: 8600-8699 | ||||||
|
WebRTC | Ефимерно (според правилата на браузъра) | ||||||
| Мултимедия за повиквания от Webex Calling (SRTP/SRTCP, T38) |
диапазон от адреси в Webex Calling. Вижте IP подмрежи за услуги на Webex Calling | 19560-65535 (SRTP през UDP) | UDP | IP или диапазон от IP адреси, избрани от клиента за неговия локален шлюз | Диапазон от мултимедийни портове, избран от клиента за неговия локален шлюз | ||
| Сигнализация на повиквания към PSTN шлюза (SIP TLS) | Вътрешен NIC локален портал | 8000-65535 | TCP | Вашият ITSP pstn gw или унифициран CM | Зависи от опцията PSTN (например, обикновено 5060 или 5061 за Unified CM) | ||
| Повикване на мултимедията към PSTN шлюз (SRTP/SRTCP) | Вътрешен NIC локален портал | 8000-48199†* | СДП | Вашият ITSP pstn gw или унифициран CM | Зависи от опцията за PSTN (например обикновено 5060 или 5061 за Unified CM) | ||
| Конфигурация на устройството и управление на фърмуера (Cisco устройства) | Устройства за повикване на Webex | Мимолетен | TCP |
Вижте IP подмрежи за услуги на Webex Calling | 443, 6970, 80 |
Задължително поради следните причини:
| |
| Конфигурация на приложението Webex | Приложения на приложението Webex | Мимолетен | TCP |
Вижте IP подмрежи за услуги на Webex Calling | 443, 8443 | Използва се за Удостоверяване на Ид брокер, услуги за конфигуриране на приложението Webex за клиенти, Базиран на браузър уеб достъп за самообслужване И Достъп до административен интерфейс. TCP порт 8443 се използва от приложението Webex при настройка на Cisco Unified CM за изтегляне на конфигурация. Само клиентите, които използват настройката за свързване с Webex Calling, трябва да отворят порта. | |
| Синхронизация на времето на устройството (NTP) | Устройства за повикване на Webex | 51494 | СДП | Обърнете се към IP подмрежи за Webex услуги за обаждания. | 123 | Тези IP адреси са необходими за синхронизиране на времето за устройства (MPP телефони, ATA и SPA ATAs) | |
|
Преобразуване на системата за имена на домейни (DNS) | Устройства за Webex Calling, приложението Webex и устройства за Webex | Мимолетен | UDP и TCP | Дефиниран от хоста | 53 | Използва се за DNS търсения за откриване на IP адресите на услугите на Webex Calling в облака. Въпреки че типичните DNS търсения се извършват през UDP, някои може да изискват TCP, ако отговорите на заявката не могат да се поберат в UDP пакети. | |
| Мрежов протокол за време (NTP) | Приложение Webex и устройства с Webex | 123 | СДП | Дефиниран от хоста | 123 | Синхронизация на времето | |
| ЦСкан | Уеб базиран инструмент за предварителна квалификация на мрежата за Webex Calling | Мимолетен | TCP | Обърнете се към IP подмрежи за Webex услуги за обаждания. | 8934 и 443 | Уеб базиран инструмент за предварителна квалификация на Мрежата за готовност за Webex Calling. Отидете на cscan.webex.com за повече информация. | |
| UDP | 19569-19760 | ||||||
| Допълнителни услуги на Webex Calling и Webex Aware (трета страна) | |||||||
| Пуш известия за услугите APNS и FCM | Приложения на Webex Calling | Мимолетен | TCP |
Вижте IP подмрежите, споменати под връзките | 443, 2197, 5228, 5229, 5230, 5223 | Известия до приложенията Webex на мобилни устройства (Пример: Когато получите ново съобщение или когато бъде отговорено на повикване) | |
-
† *Диапазонът на мултимедийни портове CUBE може да се конфигурира с диапазон rtp-порт.
-
† *Мултимедийни портове за устройства и приложения, които се задават динамично в гнездата на SRTP порта. SRTP портовете са дори номерирани портове, а съответният SRTCP порт се разпределя с поредния нечетен порт.
-
Ако за вашите приложения и устройства е конфигуриран адрес на прокси сървър, сигналният трафик се изпраща към прокси сървъра. Мултимедията пренасяше SRTP през UDP потоци директно към защитната стена вместо към прокси сървъра.
-
Ако използвате NTP и DNS услуги във вашата корпоративна мрежа, тогава отворете портове 53 и 123 през защитната стена.
Качество на услугата (QoS)
Позволява ви да разрешите обозначаване на пакети от локалното устройство или клиента към платформата в облака Webex Calling. QoS ви позволява да приоритизирате трафика в реално време пред трафика на данни. Разрешаването на тази настройка променя маркерите за QoS за приложения и устройства, които използват SIP сигнализация и мултимедия.
| Адреси на източника | Тип трафик | Адреси на местоназначение | Изходни портове | Пристанища на местоназначение | Клас и стойност на DSCP |
|---|---|---|---|---|---|
| Приложение Webex | Аудио |
Вижте IP подмрежи, домейни и URL адреси за услугите на Webex Calling | 8500-8599 | 8500-8599, 19560-65535 | Ускорено препращане (46) |
| Приложение Webex | Видео | 8600-8699 | 8600-8699, 19560-65535 | Осигурено пренасочване 41 (34) | |
| Приложение Webex | Сигнализиране | Ефимерна (зависима от OS) | 8934 | CS0 (0) | |
| Устройства с Webex (MPP и стая) | Аудио и видео | 19560-19661 | 19560-65535 |
Ускорено препращане (46) и Осигурено пренасочване 41 (34) | |
| Устройства с Webex | Сигнализиране | 5060-5080 | 8934 | Избор на клас 3 (24) |
-
Създайте отделен QoS профил за аудио и видео/споделяне, тъй като те имат различен диапазон на изходния порт, за да маркират по различен начин трафика.
-
За клиенти на Windows: За да активирате диференциране на UDP портове източник за вашата организация, се свържете с местния екип за акаунти. Без да го активирате, не можете да разграничавате между аудио и видео/споделяне чрез правилата за Windows QoS (GPO), защото портове източник са едни и същи за аудио/видео/споделяне. За подробности вижте Активиране на диапазоните от портове за мултимедия за приложението Webex
-
За устройства с Webex конфигурирайте промените в настройките за QoS от настройките за устройства в Control Hub. За подробности вижте Конфигуриране и промяна на настройките на устройство в Webex-Calling
Срещи/съобщения на Webex - Изисквания към мрежата
За клиенти, които използват Webex Suite на услуги за сътрудничество в облака, регистрираните в облака продукти Webex включват MPP устройствата към Webex Cloud за услуги като „Хронология на повикванията“, „Търсене в указателя“, „Срещи“ и „Съобщения“. Уверете се, че домейните/URL/IP адресите/портовете, споменати в тази статия, са отворени Мрежови изисквания за услугите на Webex.
Мрежови изисквания за Webex for Government (FedRAMP)
За клиенти, които изискват списъка с домейни, URL адреси, диапазони от IP адреси и портове за услуги на Webex for Government (FedRAMP), информацията може да бъде намерена тук: Изисквания към мрежата за Webex for Government
Мрежови изисквания за Webex Attendant Console
За клиенти, които използват Attendant Console – функции за рецепционисти, оператори и оператори, се уверете, че домейните/URL/IP адресите/портове/протоколите са отворени Мрежови изисквания за Attendant Console
Първи стъпки с локалния шлюз на Webex Calling
За клиенти, които използват решението за локален шлюз с Webex Calling за базирана на помещения PSTN и работна съвместимост на SBC на трети страни, прочетете през статията Първи стъпки с локален шлюз
Препратки
За да знаете Какво е новото в Webex Calling, вижте Какво е новото в Webex Calling
За изисквания за защита за Webex Calling вижте Статия
Статия за оптимизиране на мултимедията на Webex Calling с установяване на интерактивна свързаност (ICE) Webex
Хронология на ревизиите на документи
|
Дата |
Направихме следните промени в тази статия |
|---|---|
|
21 януари 2025 г. |
Добавени са подробности за използването на шлюза за слой на приложение на SIP. |
|
08 януари 2025 г. |
Преместен е адресът на IP подмрежата, свързан с конфигурацията на устройството и конфигурацията на приложението Webex, в раздела IP подмрежи за услуги на Webex Calling |
|
17 декември 2024 г. |
Добавена е поддръжка към WebRTC за спецификацията за мултимедия за Webex Calling. |
|
14 ноември 2024 г. |
Актуализиран е поддържаният диапазон от портове за мултимедия за повиквания в Webex Calling за ATA устройство от серията VG400 |
|
11 ноември 2024 г. |
Добавен е поддържаният диапазон от портове за мултимедия за повиквания в Webex Calling за ATA устройство от серията VG400 |
|
25 юли 2024 г. |
Добавена е IP подмрежата 52.26.82.54, тъй като е необходима за конфигуриране на устройства Cisco ATA и управление на фърмуера. |
|
18 юли 2024 г. |
Актуализирано със следните подробности:
|
|
28 юни 2024 г. |
Актуализирано е използването и на двата диапазона SRTP/ SRTCP порта за спецификацията на мултимедията на Webex Calling. |
|
11 юни 2024 г. |
Премахнат е домейнът "huron-dev.com", тъй като не се използва. |
|
06 май 2024 г. |
Актуализирано е използването и на двата диапазона SRTP/ SRTCP порта за спецификацията на мултимедията на Webex Calling. |
|
03 април 2024 г. | Актуализирани са IP подмрежите за услугите на Webex Calling с 163.129.0.0/17, за да се отчете разширяването на пазара на Webex Calling за региона на Индия. |
|
18 декември 2023 г. |
Включва URL адреса и изискването за порт 80 на sudirenewal.cisco.com за конфигуриране на устройството и управление на фърмуера на подновяването на MIC на MPP телефона на Cisco. |
|
11 декември 2023 г. |
Актуализирани IP подмрежите за услугите на Webex Calling, за да включват по-голям набор от IP адреси. 150.253.209.128/25 – променено на 150.253.128.0/17 |
|
29 ноември 2023 г. |
Актуализирани са IP подмрежите за услугите на Webex Calling, за да включват по-голям набор от IP адреси, за да се приспособи разширяването на региона на Webex Calling за бъдещ растеж. 144.196.33.0/25 – променено на 144.196.0.0/16 Разделите на IP подмрежите за услугите на Webex Calling под Webex Calling (SIP TLS) и Call media to Webex Calling (STUN, SRTP) се актуализират за яснота относно базираната на сертификат външна връзка и изискванията за защитна стена за локалния шлюз. |
|
14 август 2023 г. |
Добавихме следните IP адреси 144.196.33.0/25 и 150.253.156.128/25, за да поддържаме увеличени изисквания за капацитет за услугите на Edge и Webex Calling. Този диапазон от IP адреси се поддържа само в региона на САЩ. |
|
05 юли 2023 г. |
Добавена е връзката https://binaries.webex.com за инсталиране на фърмуера на Cisco MPP. |
|
07 март 2023 г. |
Преработихме цялата статия, за да включва:
|
|
05 март 2023 г. |
Актуализиране на статията, за да включва следното:
|
|
15 ноември 2022 г. |
Добавихме следните IP адреси за конфигуриране на устройства и управление на фърмуера (устройства Cisco):
Премахнахме следните IP адреси от конфигурацията на устройството и управлението на фърмуера (устройства на Cisco):
|
|
14 ноември 2022 г. |
Добавена е IP подмрежа 170.72.242.0/24 за услугата Webex Calling. |
|
септември 08, 2022 |
Преходи на фърмуера на Cisco MPP да се използва https://binaries.webex.com като URL адрес на хоста за надграждане на фърмуера на MPP във всички региони. Тази промяна подобрява производителността на надстройката на фърмуера. |
|
Август 30, 2022 |
Премахната препратка към порт 80 от „Конфигурация на устройството и управление на фърмуера“ (устройства Cisco), конфигурация на приложението и CSмогат да се редят в таблицата „Порт“, тъй като няма зависимост. |
|
август 18, 2022 |
Няма промяна в решението. Актуализиран портовете за местоназначение 5062 (необходими за багажника, базиран на сертификат), 8934 (необходим за багажника, базиран на регистрация) за сигнализиране на повикване до Webex Calling (SIP TLS). |
|
юли 26, 2022 |
Добавен е IP адресът 54.68.1.225, който е необходим за надграждане на фърмуера на устройствата Cisco 840/860. |
|
юли 21, 2022 |
Актуализира портовете за местоназначение 5062, 8934 за сигнализация на повиквания към Webex Calling (SIP TLS). |
|
юли 14, 2022 |
Добавени са URL адресите, които поддържат пълна функция на услугите на Webex Aware. Добавена е IP подмрежа 23.89.154.0/25 за услугата Webex Calling. |
|
юни 27, 2022 |
Актуализира домейна и URL адресите за услугите за обаждания на Webex: *.broadcloudpbx.com *.broadcloud.com.au *.broadcloud.eu *.broadcloudpbx.net |
|
юни 15, 2022 |
Добавени са следните портове и протоколи под IP адреси и портове за Webex Call Services:
Актуализирана информация в раздела Срещи/съобщения на Webex – Мрежови изисквания |
|
Май 24, 2022 |
Добавена е IP подмрежата 52.26.82.54/24 към 52.26.82.54/32 за услугата Webex Calling |
|
Май 6, 2022 |
Добавена е IP подмрежата 52.26.82.54/24 за услугата Webex Calling |
|
април 7, 2022 |
Диапазонът от вътрешни и външни UDP портове за локален шлюз е актуализиран до 8000-48198† |
|
април 5, 2022 |
Добавени са следните IP подмрежи за услугата Webex Call:
|
|
Март 29, 2022 |
Добавени са следните IP подмрежи за услугата Webex Call:
|
|
септември 20, 2021 |
Добавени са 4 нови IP подмрежи за услугата Webex Call:
|
|
април 2, 2021 |
Добавено *.ciscospark.com под Домейни и URL адреси за услуги на Webex Calling , за да поддържа случаи на използване на Webex Calling в приложението Webex. |
|
25 март 2021 г. |
Добавени са 6 нови IP диапазона за activate.cisco.com, който влиза в сила от 8 май 2021 г.
|
|
Март 4, 2021 |
Заменени Webex Calling дискретни IP адреси и по-малки IP диапазони с опростени диапазони в отделна таблица за лесно разбиране за конфигурацията на защитната стена. |
|
февруари 26, 2021 |
Добавен е 5004 като пристанище за дестинация за Call media към Webex Calling (STUN, SRTP) в подкрепа на интерактивното установяване на свързаност (ICE), което ще бъде достъпно в Webex Calling през април 2021 г. |
|
февруари 22, 2021 |
Домейните и URL адресите вече са изброени в отделна таблица. Таблицата за IP адреси и портове се регулира така, че да групира IP адреси за едни и същи услуги. Добавянето на колоната „Бележки“ към таблицата за IP адреси и портове, което помага за разбирането на изискванията. Преместване на следните IP адреси в опростени диапазони за конфигуриране на устройства и управление на фърмуера (устройства Cisco):
Добавяне на следните IP адреси за конфигурация на приложения, защото клиентът на Cisco Webex сочи към по-нов DNS SRV в Австралия през март 2021 г.
|
|
януари 21, 2021 |
Добавихме следните IP адреси към конфигурацията на устройството и управлението на фърмуера (устройства Cisco):
Премахнахме следните IP адреси от конфигурацията на устройството и управлението на фърмуера (устройства на Cisco):
Добавихме следните IP адреси към конфигурацията на приложението:
Премахнахме следните IP адреси от конфигурацията на приложението:
Премахнахме следните номера на портове от конфигурацията на приложението:
Добавихме следните домейни към конфигурацията на приложението:
|
|
декември 23, 2020 |
Добавени са нови IP адреси за конфигуриране на приложения към референтните изображения на порта. |
|
декември 22, 2020 |
Актуализира реда Конфигурация на приложението в таблиците, за да включи следните IP адреси: 135.84.171.154 и 135.84.172.154. Скрийте мрежовите диаграми, докато не бъдат добавени тези IP адреси. |
|
декември 11, 2020 |
Актуализира конфигурацията на устройството и управлението на фърмуера (Cisco устройства) и редовете за конфигуриране на приложението за поддържаните канадски домейни. |
|
октомври 16, 2020 |
Актуализира сигнализацията на повикванията и записите в медиите със следните IP адреси:
|
|
септември 23, 2020 |
Съгласно CScan, заменен 199.59.64.156 с 199.59.64.197. |
|
август 14, 2020 |
Добавени са още IP адреси в подкрепа на въвеждането на центрове за данни в Канада: Сигнализация на повиквания към Webex Calling (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24 |
|
Август 12, 2020 |
Добавени са още IP адреси в подкрепа на въвеждането на центрове за данни в Канада:
|
|
Юли 22, 2020 |
Добавен е следният IP адрес в подкрепа на въвеждането на центрове за данни в Канада: 135.84.173.146 |
|
юни 9, 2020 |
Направихме следните промени в CScan въвеждането:
|
|
април 11, 2020 |
Добавихме следните домейни и IP адреси към конфигурацията на приложението:
Актуализирахме следните домейни с допълнителни IP адреси към конфигурацията на устройството и управлението на фърмуера:
|
|
27 февруари 2020 г. |
Добавихме следния домейн и портове към конфигурацията на устройството и управлението на фърмуера: cloudupgrader.webex.com—443, 6970 |
Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
Общ преглед
Webex Calling в момента поддържа две версии на локален шлюз:
-
Локален шлюз
-
Локален шлюз за Webex for Government
-
Преди да започнете, разберете изискванията за локална обществена комутируема телефонна мрежа (PSTN) и локален шлюз (LGW) за Webex Calling. Вижте Cisco Предпочитана архитектура за Webex Призоваване за повече информация.
-
Тази статия предполага, че е налице специална платформа на Local Gateway без съществуваща гласова конфигурация. Ако промените съществуващ PSTN шлюз или разполагане на CUBE Enterprise, за да се използва като функция за локален шлюз за Webex Calling, тогава обърнете внимателно внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци на повиквания и функционалност поради направените промени.
Процедурите съдържат връзки към справочна документация за команди, където можете да научите повече за отделните опции за команди. Всички препратки към командите отиват в Препратката към управлявани шлюзове на Webex , освен ако не е посочено друго (в този случай връзките към командите отиват в Cisco IOS Voice Command Reference). Можете да получите достъп до всички тези ръководства на Cisco Unified Border Element Command References.
За информация относно поддържаните SBC от трети страни вижте съответната продуктова референтна документация.
Има две опции за конфигуриране на локалния портал за вашия багажник за повикване на Webex:
-
Багажник, базиран на регистрация
-
Багажник, базиран на сертификат
Използвайте потока на задачите или под Базиран на регистрация локален шлюз , или Базиран на сертификат локален шлюз , за да конфигурирате локален шлюз за вашата съединителна линия на Webex Calling.
Вижте Първи стъпки с локален шлюз за повече информация относно различните типове съединителни линии. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Използваме протокол за стартиране на сесия (SIP) и транспорт за защита на транспортния слой (TLS), за да защитим съединителната линия, и защитен протокол в реално време (SRTP), за да защитим мултимедията между локалния шлюз и Webex Calling.
-
Изберете CUBE като локален шлюз. Понастоящем Webex for Government не поддържа гранични контрольори на сесии (SBC) на трети страни. За да прегледате най-новия списък, вижте Първи стъпки с локален шлюз.
- Инсталирайте версията на Cisco IOS XE Dublin 17.12.1a или по-нова за всички локални шлюзове на Webex for Government.
-
За да прегледате списъка с главни сертифициращи органи (СО), които Webex за правителство поддържа, вижте Главни сертифициращи органи за Webex за правителство.
-
За подробности относно диапазоните от външни портове за локален шлюз в Webex for Government вижте Мрежови изисквания за Webex for Government (FedRAMP).
Локалният шлюз за Webex for Government не поддържа следното:
-
STUN/ICE-Lite за оптимизиране на пътя на мултимедията
-
Факс (T.38)
За да конфигурирате локален шлюз за своята съединителна линия на Webex Calling в Webex for Government, използвайте следната опция:
-
Багажник, базиран на сертификат
Използвайте потока на задачите под Базиран на сертификат локален шлюз , за да конфигурирате локалния шлюз за вашата съединителна линия на Webex Calling. За повече подробности как да конфигурирате базиран на сертификат локален шлюз вижте Конфигуриране на базирана на сертификат външна връзка на Webex Calling.
Задължително е да конфигурирате съвместими с FIPS шифри на GCM да поддържа локален шлюз за Webex for Government. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вижте Конфигуриране на базираната на сертификат външна връзка на Webex Calling.
Webex for Government не поддържа базиран на регистрация локален шлюз.
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling чрез регистриране на SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от 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, можете да използвате конфигурацията на прост PSTN шлюз като базова линия за изграждане на решението, показано на следващата схема. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В целия този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани в следващото изображение.
Използвайте инструкциите за конфигуриране в останалата част на този документ, за да завършите конфигурирането на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигуриране на базовата свързаност и защита на маршрутизатора
-
Стъпка 2: Конфигуриране на съединителна линия за Webex Calling
В зависимост от необходимата архитектура, следвайте или:
-
Стъпка 3: Конфигуриране на локален шлюз със SIP PSTN външна връзка
-
Стъпка 4: Конфигурирайте Local Gateway със съществуваща Unified CM среда
Или:
-
Стъпка 3: Конфигуриране на локален шлюз с TDM PSTN съединителна линия
Конфигурация на базовата линия
Първата стъпка при подготовката на вашия маршрутизатор Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която осигурява вашата платформа и установява свързаност.
-
Всички разполагания на локални шлюзове, базирани на регистрация, изискват Cisco IOS XE 17.6.1a или по-нови версии. Препоръчва се Cisco IOS 17.12.2 или следващи версии. За препоръчителните версии вижте страницата Cisco Software Research . Потърсете платформата и изберете едно от предложените издания.
-
Маршрутизаторите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за технологии за Unified Communications, така и за сигурност.
-
Маршрутизаторите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
-
Изградете базова конфигурация за вашата платформа, която следва вашите бизнес правила. По-специално, конфигурирайте и проверете следното:
-
нтр
-
АКЛ
-
Удостоверяване на потребители и отдалечен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес.
-
Качете основния пакет на Cisco CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че сте задали валидни и подлежащи на маршрутизиране IP адреси към интерфейси от Слой 3, например:
|
| 2 |
Защитете регистрационните и STUN идентификационните данни на маршрутизатора с помощта на симетрично шифроване. Конфигурирайте основния ключ за шифроване и типа на шифроването, както следва:
|
| 3 |
Създайте надеждна PKI точка за съхранение. Изисква тази точка на доверие да конфигурира TLS по-късно. За външни връзки, базирани на регистрация, тази точка на доверие не изисква сертификат – както би се изисквало за външна връзка, базирана на сертификат. |
| 4 |
Разрешете изключителност на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигуриране. Параметрите на транспорта също трябва да бъдат актуализирани, за да се осигури надеждна защитена връзка за регистрация: Командата на сървъра cn-san-validate гарантира, че локалният шлюз позволява връзка, ако името на хоста, конфигурирано в клиент 200, е включено или в полетата CN, или SAN на сертификата, получен от изходящия прокси сървър.
|
| 5 |
Инсталирайте пакета root CA на Cisco, който включва сертификата DigiCert CA, използван от Webex Calling. Използвайте командата Импортиране на чист URL адрес на crypto pki trustpool , за да изтеглите главния пакет от CA от посочения URL и да изчистите текущия CA trustpool, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета от CA: ip http клиент прокси-сървър yourproxy.com прокси-порт 80 |
| 1 |
Създайте базирана на регистрация външна връзка на PSTN за съществуващо местоположение в Control Hub. Обърнете внимание на информацията за съединителната линия, която се предоставя след като съединителната линия бъде създадена. Подробностите, подчертани в илюстрацията, се използват в стъпките за конфигуриране в това ръководство. За повече информация вижте Конфигуриране на външни връзки, групи за маршрутизиране и планове за набиране за Webex Calling. |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз на Webex Calling: Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. статистика на медиитеПозволява медиен мониторинг на местния портал. групова статистика за мултимедияПозволява на контролната равнина да анкетира равнината на данните за статистика на насипните повиквания. За повече информация относно тези команди вижте Мултимедия. allow-връзки sip към sipРазрешаване на основната функционалност на обратен SIP на CUBE. За повече информация вижте Разрешаване на връзки. По подразбиране е активиран транспорт на факс T.38. За повече информация вижте факс протокол t38 (гласова услуга). Активира STUN (Session Traversal of UDP through NAT) глобално.
За повече информация вижте ИД на stun flowdata агент и stun flowdata споделена тайна. Асиметричният полезен обем е пъленКонфигурира поддръжка на асиметричен полезен товар за SIP както за DTMF, така и за динамични кодеци. За повече информация вижте асиметричен полезен обем. принудително ранно предложениеПринудете локалния шлюз да изпраща информация за SDP в първоначалното съобщение за ПОКАНА, вместо да изчаква потвърждение от съседния си колега. За повече информация относно тази команда вижте ранно предложение. |
| 3 |
Конфигурирайте кодек от гласов клас 100 , позволяващ кодеци G.711 само за всички външни връзки. Този прост подход е подходящ за повечето разполагания. Ако е необходимо, в списъка могат да бъдат добавени допълнителни типове кодеци, поддържани както от системи за генериране, така и от системи за терминиране. Поддържат се по-сложни решения, включващи транскодиране с помощта на DSP модули, но не са включени в това ръководство. Ето обяснение на полетата за конфигурацията: кодек от гласов клас 100Използва се за разрешаване само на предпочитани кодеци за SIP съединителна линия повиквания. За повече информация вижте кодек за гласов клас. |
| 4 |
Конфигурирайте използването на stun-ове от гласов клас 100 , за да активирате ICE на съединителната линия на Webex Calling. Ето обяснение на полетата за конфигурацията: използване на лед liteИзползва се за активиране на ICE-Lite за всички връстници за набиране на Webex Calling, за да позволи оптимизация на мултимедията, когато е възможно. За повече информация вижте Използване на камък от гласов клас и Lite за използване на камък. Оптимизацията на мултимедията се договаря, когато е възможно. Ако повикването изисква мултимедийни услуги в облака, например записване, мултимедията не може да бъде оптимизирана. |
| 5 |
Конфигурирайте правилата за шифроване на мултимедия за трафика на Webex. Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_80 като единствената SRTP оферта на CUBE с шифър в SDP в съобщенията за предложение и отговор. Webex Calling поддържа само SHA1_80. За повече информация вижте гласов клас srtp-crypto. |
| 6 |
Конфигурирайте шаблон за идентифициране на повикванията към външна връзка на локален шлюз въз основа на параметъра външна връзка на местоназначението: Ето обяснение на полетата за конфигурацията: гласов клас uri 100 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този модел, използвайте dtg=, последван от стойността OTG/DTG на съединителната линия, предоставена в Control Hub, когато съединителната линия е създадена. За повече информация вижте uri на гласов клас. |
| 7 |
Конфигурирайте sip профил 100, който ще се използва за промяна на SIP съобщенията, преди да бъдат изпратени на Webex Calling.
Ето обяснение на полетата за конфигурацията:
Американски или канадски доставчик на PSTN може да предложи проверка на ИД на повикващия за нежелани и измамни повиквания, с допълнителната конфигурация, посочена в показанието за нежелани или измамни повиквания в статията Webex Calling . |
| 8 |
Конфигуриране на външна връзка на Webex Calling: |
След като дефинирате клиента 100 и конфигурирате връстник за SIP VoIP набиране, шлюзът инициира TLS връзка към Webex Calling. В този момент SBC за достъп представя сертификата си на локалния шлюз. Локалният шлюз валидира SBC сертификата за достъп до Webex Calling, като използва корневи пакет на CA, който е актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп до Webex Calling. След това локалният шлюз може да използва тази защитена връзка, за да се регистрира със SBC за достъп до Webex. Когато регистрацията е оспорена за удостоверяване:
-
Параметрите на потребителското име, паролата иобластта от конфигурацията за идентификационни данни се използват в отговора.
-
Правилата за модифициране в sip профил 100 се използват за преобразуване на URL адреса на SIPS обратно в SIP.
Регистрацията е успешна, когато се получи 200 OK от SBC за достъп.
След като сте изградили съединителна линия към Webex Calling по-горе, използвайте следната конфигурация, за да създадете нешифрована съединителна линия към SIP базиран доставчик на PSTN:
Ако вашият доставчик на услуги предлага защитена PSTN съединителна линия, може да следвате подобна конфигурация, както е подробно описано по-горе за съединителната линия на Webex Calling. CUBE поддържа защитено маршрутизиране на повикванията.
Ако използвате TDM / ISDN PSTN съединителна линия, преминете към следващия раздел Конфигуриране на локален шлюз с TDM PSTN съединителна линия.
За да конфигурирате TDM интерфейси за сегментите на PSTN повикване в Cisco TDM-SIP шлюзовете, вижте Конфигуриране на ISDN PRI.
| 1 |
Конфигурирайте следния URI за гласов клас, за да идентифицирате входящите повиквания от PSTN съединителната линия: Ето обяснение на полетата за конфигурацията: гласов клас uri 200 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте uri на гласов клас. |
| 2 |
Конфигурирайте следния връстник за набиране на IP PSTN: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че този връстник за набиране обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4: 192.168.80.13Указва целевия адрес за повикванията, изпратени до доставчика на PSTN. Това може да е или IP адрес, или име на DNS хост. За повече информация вижте целта на сесията (връстник за VoIP набиране). входящ URI през 200Указва гласовия клас, използван за съпоставяне на входящите повиквания към този връстник за набиране с помощта на ПОКАНА ЧРЕЗ URI на заглавка. За повече информация вижте входящия URL адрес. гласов клас sip asserted-id pai
(По избор) Включва обработката на заглавката P-Asserted-Identity и управлява как се използва това за съединителната линия на PSTN. Ако се използва тази команда, самоличността на повикващата страна, предоставена от връстник за входящо набиране, се използва за изходящите заглавия „От“ и P-Asserted-Identity. Ако тази команда не се използва, самоличността на повикващата страна, предоставена от връстника за входящо набиране, се използва за изходящите заглавки „От“ и „ИД на отдалечената страна“. За повече информация вижте SIP asserted-id на гласов клас. обвързване на изходния интерфейс за управление 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 външна връзка за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на мултимедията в сегмента на повикванията на Webex.
Ако не изисквате оптимизация на IP мултимедията, следвайте стъпките за конфигуриране за SIP PSTN багажник. Използвайте гласов порт и POTS-връстник за набиране (както е показано в стъпки 2 и 3) вместо PSTN VoIP-връстник за набиране.
| 1 |
Конфигурацията на връстната връзка за набиране използва групи за набиране и етикети за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли на маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на етикети за маршрутизиране на повиквания: Ето обяснение на полетата за конфигурацията: правило за превод на гласИзползва регулярни изрази, дефинирани в правила, за да добавя или премахва етикети за маршрутизиране на повиквания. Цифрите над десетичната запетая („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация етикетът, добавен от профил за транслация 100, се използва за насочване на повиквания от Webex Calling към PSTN през връстниците за набиране с loopback. По същия начин етикетът, добавен от профил за транслация 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профилите за транслация 11 и 12 премахват тези етикети, преди да се доставят повиквания съответно към Webex и PSTN връзките. Този пример предполага, че набраните номера от Webex Calling са представени във формат +E.164. Правило 100 премахва водещия +, за да поддържа валиден набран номер. Правило 12 след това добавя национална или международна цифра за маршрутизиране при премахване на етикета. Използвайте цифри, които съответстват на вашия локален национален план за набиране на ISDN. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да просто добавите и премахнете съответно маркера за маршрутизиране. За повече информация вижте профил за гласов превод и правило за гласов превод. |
| 2 |
Конфигурирайте портовете за TDM гласов интерфейс според изискванията на използвания тип съединителна линия и протокол. За повече информация вижте Конфигуриране на ISDN PRI. Например основната конфигурация на интерфейс с Primary Rate ISDN, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следния TDM PSTN връстник за набиране: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте местоназначение-модел (интерфейс). входящ профил за транслация 200Задава профила за транслация, който ще добави етикет за маршрутизиране на повиквания към входящия набран номер. директно набиранеМаршрутизира повикването, без да осигурява вторичен тон за набиране. За повече информация вижте директно набиране. порт 0/2/0:15Физическият гласов порт, свързан с този връстник за набиране. |
| 4 |
За да активирате мултимедийна оптимизация на IP пътищата за локални шлюзове с TDM-IP потоци за повиквания, можете да промените маршрутизирането на повикванията, като въведете набор от връстници за вътрешно набиране между Webex Calling и PSTN съединителни линии. Конфигурирайте следните връстници за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат маршрутизирани първоначално към dial-peer 10 и оттам към dial-peer 11 или 12 въз основа на приложения етикет за маршрутизиране. След премахването на маркера за маршрутизиране повикванията ще бъдат маршрутизирани към изходящата съединителна линия с помощта на групи от връстници за набиране. Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. входящ профил за превод 11Прилага профила за транслация, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикванията, преди да премине към изходящата съединителна линия. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че този връстник за набиране обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4: 192.168.80.14Указва адреса на локалния интерфейс на маршрутизатора като цел за обратно повикване. За повече информация вижте целта на сесията (връстник за набиране на VOIP). обвързване на изходния интерфейс за управление 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). В този случай всички повиквания се маршрутизират чрез Унифициран CM. Повикванията от UCM на порт 5060 се маршрутизират към PSTN, а повикванията от порт 5065 се маршрутизират към Webex Calling. Следните нарастващи конфигурации могат да бъдат добавени, за да се включи този сценарий за повиквания.
Когато създавате багажника на Webex Calling в Unified CM, се уверете, че сте конфигурирали входящия порт в настройките на профила за защита на SIP Trunk на 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: Име на хост за запис. 192.168.80.65: IP адресът на хоста. Създайте записи на SRV ресурси и записи A, за да отразите вашата среда на UCM и предпочитаната стратегия за разпределяне на повикванията. |
| 3 |
Конфигурирайте следните връстници за набиране: |
| 4 |
Добавете маршрутизиране на повикванията, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и прехвърлянето на събраните данни в Cisco TAC случай, за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми с помощта на syslog съобщения, SNMP събития и чрез периодично наблюдение на конкретни команди за показване.
Типовете действия включват събиране на командни изходи:
-
Генериране на консолидиран лог файл
-
Качване на файла в осигурено от потребителя мрежово местоположение, например 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 сигурна tls диагностика-подпис среда ds_email "tacfaststart@gmail.com" Локален портал, работещ на Cisco IOS XE Software, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на профила в Gmail и да предоставим специално разрешение имейлът от устройството да бъде обработен правилно:
-
Отидете на и включете настройката По-малко сигурен достъп до приложението .
-
Отговорете "Да, това бях аз", когато получавате имейл от Gmail, в който се казва: "Google попречи на някого да влезе в профила ви с помощта на приложение извън Google".
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява използването на процесора за пет секунди при използване на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които са инсталирани в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Използвайте командата показване на snmp , за да активирате SNMP. Ако не активирате, тогава конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Копирайте DS XML файла в светкавицата на локалния шлюз.
LocalGateway# копие на ftp://потребителско име:парола@/DS_64224.xml bootflash:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копиране на ftp://потребител:pwd@192.0.2.12/DS_64224.xml bootflash: Достъп до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK – 3571/4096 байта] 3571 байта са копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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, за да продължите да наблюдавате голямото използване на процесора в локалния шлюз.
Мониторинг SIP багажник регистрация
Този DS проверява за нерегистрация на локален Gateway SIP багажник с облак Webex Calling на всеки 60 секунди. След като бъде открито събитието за дерегистриране, то генерира известие по имейл и syslog и се деинсталира след две повторения за дерегистриране. Използвайте стъпките по-долу, за да инсталирате подписа:
-
Изтеглете DS 64117, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
СИП-СИП
Тип на проблема
SIP Trunk Отписване на регистрацията с известие по имейл.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_64117.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностика и подпис на повикване-домашен номер_64117.xml Успешно зареждане на файла DS_64117.xml LocalGateway# -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Мониторинг на абнормни прекъсвания на повикването
Този DS използва SNMP анкета на всеки 10 минути, за да открие необичайно прекъсване на връзката с SIP грешки 403, 488 и 503. Ако увеличението на броя грешки е по-голямо или равно на 5 от последната анкета, то генерира syslog и имейл известие. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Използвайте командата показване на snmp , за да проверите дали е разрешено SNMP. Ако не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_65221.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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 и автоматизира събирането на диагностични данни, като използва следните стъпки:
-
Конфигурирайте допълнителна променлива на средата на DS, ds_fsurl_prefix която е пътят на файловия сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е маркер за качване на файла, който може да бъде извлечен от Диспечер на случаи на поддръжката в следната команда. Маркерът за качване на файла може да се генерира в раздела Прикачени файлове на диспечера на случаи на поддръжката, ако е необходимо.
конфигуриране на терминал call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" крайПример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Уверете се, че SNMP е разрешено с помощта на командата показване на snmp . Ако не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp %SNMP агента не е активиран конфигурация до края на диспечера на snmp сървъра -
Уверете се, че инсталирате 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 bootflash: копиране на ftp://потребителско име:парола@/DS_65095.xml bootflash: -
Инсталирайте High CPU мониторинг DS 64224 и след това DS 65095 XML файл в локалния шлюз.
call-home diagnostic-signature load DS_64224.xml Зареждане на файла DS_64224.xml успешно повикване-home diagnostic-signature load 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
ДД_ЛГВ_ИЕК_Вall_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверка на изпълнението на диагностичните подписи
В следната команда колоната „Състояние“ на командата показване на call-home diagnostic-signature се променя на „изпълнява“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът от статистиката за диагностичния подпис на повикването у дома е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за повикване до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: 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 |
ДД_ЛГВ_ИЕК_В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 |
ДД_ЛГВ_ИЕК_Вall_spike_threshold |
1/20/Г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на даден проблем.
Деинсталиране на диагностични подписи
Използвайте диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинират като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на командата показване на диагностика-подпис на повикване-дом и изпълнете следната команда:
деинсталиране на диагностика-подпис за повикване-дом Пример:
деинсталиране на диагностика за повикване-домашен подпис 64224 Периодично се добавят нови подписи към инструмента за справка за диагностични подписи, въз основа на проблеми, които обикновено се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
За по-добро управление на шлюзовете на Cisco IOS XE препоръчваме да запишете и управлявате шлюзовете чрез Control Hub. Конфигурацията е незадължителна. Когато сте се записали, можете да използвате опцията за проверка на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате евентуални проблеми с конфигурацията. В момента само съединителни линии, базирани на регистрация, поддържат тази функционалност.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling с използване на базиран на сертификат взаимен TLS (mTLS) SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от 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, можете да използвате конфигурацията на прост PSTN шлюз като базова линия за изграждане на решението, показано на следващата схема. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В целия този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани в следващото изображение. Предоставят се опции за публично или частно (зад NAT) адресиране. SRV DNS записите са по желание, освен ако не се балансира натоварването между няколко екземпляра на CUBE.
Използвайте инструкциите за конфигуриране в останалата част на този документ, за да завършите конфигурирането на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигуриране на базовата свързаност и защита на маршрутизатора
-
Стъпка 2: Конфигуриране на съединителна линия за Webex Calling
В зависимост от необходимата архитектура, следвайте или:
-
Стъпка 3: Конфигуриране на локален шлюз със SIP PSTN външна връзка
-
Стъпка 4: Конфигурирайте Local Gateway със съществуваща Unified CM среда
Или:
-
Стъпка 3: Конфигуриране на локален шлюз с TDM PSTN съединителна линия
Конфигурация на базовата линия
Първата стъпка при подготовката на вашия маршрутизатор Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която осигурява вашата платформа и установява свързаност.
-
Всички базирани на сертификат локални шлюзове изискват Cisco IOS XE 17.9.1a или по-нови версии. Препоръчва се Cisco IOS XE 17.12.2 или по-нова версия. За препоръчителните версии вижте страницата Cisco Software Research . Потърсете платформата и изберете едно от предложените издания.
-
Маршрутизаторите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за технологии за Unified Communications, така и за сигурност.
-
Маршрутизаторите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
За изискванията за висок капацитет може да изисквате и лиценз за висока защита (HSEC) и допълнителни права за пропускателна способност.
Вижте Кодове за удостоверяване за повече подробности.
-
-
Изградете базова конфигурация за вашата платформа, която следва вашите бизнес правила. По-специално, конфигурирайте и проверете следното:
-
нтр
-
АКЛ
-
Удостоверяване на потребители и отдалечен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) или адресите на записи на услуги (SRV) на локалния шлюз, конфигурирани в Control Hub, трябва да се преобразуват в публичен IPv4 адрес в интернет.
-
Всички SIP и мултимедийни портове в интерфейса на локалния шлюз, с който се сблъсква Webex, трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате съответно защитната стена.
-
Следвайте подробните стъпки за конфигуриране, предоставени по-долу, за да инсталирате подписан сертификат на локалния шлюз:
-
Публичен сертифициращ орган (CA), както е подробно описано в Какви главни сертифициращи органи се поддържат за повикванията към аудио и видео платформите в Cisco Webex? , трябва да подпише сертификата на устройството.
-
Общото име на субекта на сертификата (CN) или едно от алтернативните имена на субекта (SAN) трябва да бъде същото като FQDN, конфигурирано в Control Hub. Например:
-
Ако конфигурирана външна връзка в контролния център на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на маршрутизатора трябва да съдържа cube1.lgw.com.
-
Ако конфигурирана външна връзка в Control Hub на вашата организация има lgws.lgw.com като SRV адрес на локалните шлюзове, достъпни от външната връзка, тогава CN или SAN в сертификата на маршрутизатора трябва да съдържат lgws.lgw.com. Записите, на които SRV адресът решава (CNAME, A Record или IP адрес), са незадължителни в SAN.
-
Независимо дали използвате FQDN, или SRV за външната линия, адресът на контакта за всички нови SIP диалози от вашия локален шлюз трябва да използва името, конфигурирано в Control Hub.
-
-
Уверете се, че сертификатите са подписани за използване от клиента и сървъра.
-
-
Качете основния пакет на Cisco CA в локалния шлюз. Този пакет включва корневи сертификат на CA, използван за потвърждаване на платформата Webex.
Конфигурация
| 1 |
Уверете се, че сте задали валидни и подлежащи на маршрутизиране IP адреси към интерфейси от Слой 3, например:
|
| 2 |
Защитете идентификационните данни за STUN на рутера с помощта на симетрично шифроване. Конфигурирайте основния ключ за шифроване и типа на шифроването, както следва: |
| 3 |
Създайте точка на доверие за шифроване със сертификат за вашия домейн, подписан от поддържан сертифициращ орган (CA). |
| 4 |
Предоставете сертификата на CA за междинно подписване, който се използва за удостоверяване на вашия сертификат на организатор. Въведете следната команда за exec или конфигуриране:
|
| 5 |
Импортирайте подписания сертификат на организатор с помощта на следната команда EXEC или конфигурация:
|
| 6 |
Разрешете изключителност на TLS1.2 и посочете точката на доверие по подразбиране, която да се използва за гласови приложения при използване на следните конфигурационни команди:
|
| 7 |
Инсталирайте пакета root CA на Cisco, който включва сертификата DigiCert CA, използван от Webex Calling. Използвайте командата Импортиране на чист URL адрес URL адрес, за да изтеглите главния пакет от CA от посочения URL и да изчистите текущия CA доверителен басейн, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета от CA: ip http клиент прокси-сървър yourproxy.com прокси-порт 80 |
| 1 |
Създайте PSTN багажник, базиран на сертификат на CUBE, за съществуващо местоположение в контролния център. За повече информация вижте Конфигуриране на външни връзки, групи за маршрутизиране и планове за набиране за Webex Calling. Запишете информацията за съединителната линия, която се предоставя след като съединителната линия бъде създадена. Тези подробности, както е подчертано в следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз на Webex Calling: Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. allow-връзки sip към sipРазрешаване на основна SIP на CUBE обратно към обратно функционалността на потребителския агент. За повече информация вижте Разрешаване на връзки. По подразбиране е активиран транспорт на факс T.38. За повече информация вижте факс протокол t38 (гласова услуга). Активира STUN (Session Traversal of UDP through NAT) глобално. Тези глобални команди за stun се изискват само при разгръщане на вашия локален шлюз зад NAT.
За повече информация вижте ИД на stun flowdata агент и stun flowdata споделена тайна. Асиметричният полезен обем е пъленКонфигурира поддръжка на асиметричен полезен товар за SIP както за DTMF, така и за динамични кодеци. За повече информация относно тази команда вижте асиметричен полезен обем. принудително ранно предложениеПринудете локалния шлюз да изпраща информация за SDP в първоначалното съобщение за ПОКАНА, вместо да изчаква потвърждение от съседния си колега. За повече информация относно тази команда вижте ранно предложение. sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез връстници за набиране или клиенти. |
| 3 |
Конфигурирайте кодек от гласов клас 100 , позволяващ кодеци G.711 само за всички външни връзки. Този прост подход е подходящ за повечето разполагания. Ако е необходимо, в списъка могат да бъдат добавени допълнителни типове кодеци, поддържани както от системи за генериране, така и от системи за терминиране. Поддържат се по-сложни решения, включващи транскодиране с помощта на DSP модули, но не са включени в това ръководство. Ето обяснение на полетата за конфигурацията: кодек от гласов клас 100Използва се за разрешаване само на предпочитани кодеци за SIP съединителна линия повиквания. За повече информация вижте кодек за гласов клас. |
| 4 |
Конфигурирайте използването на stun-ове от гласов клас 100 , за да активирате ICE на съединителната линия на Webex Calling. (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: използване на лед liteИзползва се за активиране на ICE-Lite за всички връстници за набиране на Webex Calling, за да позволи оптимизация на мултимедията, когато е възможно. За повече информация вижте Използване на камък от гласов клас и Lite за използване на камък. Командата защитна стена за използване на камък-traversal flowdata е необходима само когато разполагате с вашия локален шлюз зад NAT. Оптимизацията на мултимедията се договаря, когато е възможно. Ако повикването изисква мултимедийни услуги в облака, например записване, мултимедията не може да бъде оптимизирана. |
| 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 for Government. |
| 7 |
Конфигурирайте шаблон за уникално идентифициране на повикванията към съединителна линия на локален шлюз въз основа на неговия FQDN или SRV на местоназначението: Ето обяснение на полетата за конфигурацията: гласов клас uri 100 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този модел, използвайте FQDN или SRV на съединителната линия, конфигуриран в Control Hub за съединителната линия. |
| 8 |
Конфигурирайте профили за обработка на SIP съобщения. Ако шлюза ви е конфигуриран с публичен IP адрес, конфигурирайте профил, както следва, или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN, конфигуриран за локалния шлюз: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволи на Webex да удостоверява съобщения от вашия локален шлюз, заглавката \„Контакт\“ в съобщенията за 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 да удостоверява съобщения от вашия локален шлюз, заглавката \„Контакт\“ в съобщенията за SIP заявки и отговори трябва да съдържа стойността, осигурена за съединителната линия в Control Hub. Това ще бъде или FQDN на един хост, или името на SRV, използвано за клъстер от устройства. правила 30—81Конвертирайте препратките към частни адреси във външния публичен адрес за сайта, което позволява на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от гласов клас sip-профили от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Конвертирайте препратките към публичен адрес в конфигурирания частен адрес, като позволите на CUBE да обработва съобщенията от Webex. За повече информация вижте профили на SIP за гласов клас. Американски или канадски доставчик на PSTN може да предложи проверка на ИД на повикващия за нежелани и измамни повиквания, с допълнителната конфигурация, посочена в показанието за нежелани или измамни повиквания в статията Webex Calling . |
| 10 |
Конфигурирайте поддържане на опции за SIP с профил за модифициране на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-опции-поддържане 100Конфигурира профил за поддържане и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което SIP Out of Dialog Options Ping се изпраща до целта за набиране, когато сърдечната връзка към крайната точка е в състояние НАГОРЕ или Надолу. Този профил за запазване на комуникацията се задейства от връстник за набиране, конфигуриран към 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 по-горе, използвайте следната конфигурация, за да създадете нешифрована съединителна линия към SIP базиран доставчик на PSTN:
Ако вашият доставчик на услуги предлага защитена PSTN съединителна линия, може да следвате подобна конфигурация, както е подробно описано по-горе за съединителната линия на Webex Calling. CUBE поддържа защитено маршрутизиране на повикванията.
Ако използвате TDM / ISDN PSTN съединителна линия, преминете към следващия раздел Конфигуриране на локален шлюз с TDM PSTN съединителна линия.
За да конфигурирате TDM интерфейси за сегментите на PSTN повикване в Cisco TDM-SIP шлюзовете, вижте Конфигуриране на ISDN PRI.
| 1 |
Конфигурирайте следния URI за гласов клас, за да идентифицирате входящите повиквания от PSTN съединителната линия: Ето обяснение на полетата за конфигурацията: гласов клас uri 200 sipДефинира шаблон, който съответства на входяща SIP покана към връстник за набиране на входяща съединителна линия. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте uri на гласов клас. |
| 2 |
Конфигурирайте следния връстник за набиране на IP PSTN: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че този връстник за набиране обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4: 192.168.80.13Указва целевия адрес за повикванията, изпратени до доставчика на PSTN. Това може да е или IP адрес, или име на DNS хост. За повече информация вижте целта на сесията (връстник за VoIP набиране). входящ URI през 200Указва гласовия клас, използван за съпоставяне на входящите повиквания към този връстник за набиране с помощта на ПОКАНА ЧРЕЗ URI на заглавка. За повече информация вижте входящия URL адрес. гласов клас sip asserted-id pai
(По избор) Включва обработката на заглавката P-Asserted-Identity и управлява как се използва това за съединителната линия на PSTN. Ако се използва тази команда, самоличността на повикващата страна, предоставена от връстник за входящо набиране, се използва за изходящите заглавия „От“ и P-Asserted-Identity. Ако тази команда не се използва, самоличността на повикващата страна, предоставена от връстника за входящо набиране, се използва за изходящите заглавки „От“ и „ИД на отдалечената страна“. За повече информация вижте SIP asserted-id на гласов клас. обвързване на изходния интерфейс за управление 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 външна връзка за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на мултимедията в сегмента на повикванията на Webex.
Ако не изисквате оптимизация на IP мултимедията, следвайте стъпките за конфигуриране за SIP PSTN багажник. Използвайте гласов порт и POTS-връстник за набиране (както е показано в стъпки 2 и 3) вместо PSTN VoIP-връстник за набиране.
| 1 |
Конфигурацията на връстната връзка за набиране използва групи за набиране и етикети за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли на маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на етикети за маршрутизиране на повиквания: Ето обяснение на полетата за конфигурацията: правило за превод на гласИзползва регулярни изрази, дефинирани в правила, за да добавя или премахва етикети за маршрутизиране на повиквания. Цифрите над десетичната запетая („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация етикетът, добавен от профил за транслация 100, се използва за насочване на повиквания от Webex Calling към PSTN през връстниците за набиране с loopback. По същия начин етикетът, добавен от профил за транслация 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профилите за транслация 11 и 12 премахват тези етикети, преди да се доставят повиквания съответно към Webex и PSTN връзките. Този пример предполага, че набраните номера от Webex Calling са представени във формат +E.164. Правило 100 премахва водещия +, за да поддържа валиден набран номер. Правило 12 след това добавя национална или международна цифра за маршрутизиране при премахване на етикета. Използвайте цифри, които съответстват на вашия локален национален план за набиране на ISDN. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да просто добавите и премахнете съответно маркера за маршрутизиране. За повече информация вижте профил за гласов превод и правило за гласов превод. |
| 2 |
Конфигурирайте портовете за TDM гласов интерфейс според изискванията на използвания тип съединителна линия и протокол. За повече информация вижте Конфигуриране на ISDN PRI. Например основната конфигурация на интерфейс с Primary Rate ISDN, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следния TDM PSTN връстник за набиране: Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте местоназначение-модел (интерфейс). входящ профил за транслация 200Задава профила за транслация, който ще добави етикет за маршрутизиране на повиквания към входящия набран номер. директно набиранеМаршрутизира повикването, без да осигурява вторичен тон за набиране. За повече информация вижте директно набиране. порт 0/2/0:15Физическият гласов порт, свързан с този връстник за набиране. |
| 4 |
За да активирате мултимедийна оптимизация на IP пътищата за локални шлюзове с TDM-IP потоци за повиквания, можете да промените маршрутизирането на повикванията, като въведете набор от връстници за вътрешно набиране между Webex Calling и PSTN съединителни линии. Конфигурирайте следните връстници за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат маршрутизирани първоначално към dial-peer 10 и оттам към dial-peer 11 или 12 въз основа на приложения етикет за маршрутизиране. След премахването на маркера за маршрутизиране повикванията ще бъдат маршрутизирани към изходящата съединителна линия с помощта на групи от връстници за набиране. Ето обяснение на полетата за конфигурацията: Дефинира връстник за набиране на VoIP и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте глас на връстник за набиране. входящ профил за превод 11Прилага профила за транслация, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикванията, преди да премине към изходящата съединителна линия. местоназначение-модел ЛОШО.ЛОШОИзисква се макет на местоназначението, когато маршрутизирате изходящи повиквания с помощта на група връстници за входящо набиране. За повече информация вижте местоназначение-модел (интерфейс). протокол за сесия sipv2Указва, че този връстник за набиране обработва сегментите на SIP повикване. За повече информация вижте протокол за сесия (връстник за набиране). цел на сесията ipv4: 192.168.80.14Указва адреса на локалния интерфейс на маршрутизатора като цел за обратно повикване. За повече информация вижте целта на сесията (връстник за набиране на VOIP). обвързване на изходния интерфейс за управление 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). В този случай всички повиквания се маршрутизират чрез Унифициран 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: Име на хост за запис. 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 среда с имейл адреса на администратора, за да уведомите.
конфигуриране на терминал call-home-подпис на 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-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash:Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решение Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо cpu utilization с имейл известие
-
Копирайте DS XML файла в светкавицата на локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копиране на ftp://потребител:pwd@192.0.2.12/DS_64224.xml bootflash: Достъп до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK – 3571/4096 байта] 3571 байта са копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностични подписи за повикване-дом_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 от последната анкета, то генерира syslog и имейл известие. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активирана, конфигурирайте командата SNMP-сървър .
показване на snmp% SNMP агента не е активиран конфигурация на диспечера на snmp сървъра край показване на snmp Шаси: 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 Отговор PDU 10280 Trap PDU Пакети в момента в опашката за въвеждане на SNMP процес: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_65221.xml bootflash: -
Инсталирайте DS XML файла в локалния шлюз.
Успешно зареждане на диагностика и подпис за повикване-дом_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 и автоматизира събирането на диагностични данни, като използва следните стъпки:
Конфигурирайте друга променлива на средата на DS ds_fsurl_prefix като път на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номер на случай, а паролата е маркер за качване на файла, който може да бъде извлечен от Диспечер на случаи за поддръжка , както е показано по-долу. Маркерът за качване на файл може да се генерира в раздела Прикачени файлове на диспечера на случаи за поддръжка, както се изисква.
конфигуриране на терминал call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" крайПример:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активирано, конфигурирайте командата SNMP-сървър .
показване на snmp %SNMP агента не е активиран конфигурация до края на диспечера на snmp сървъра -
Препоръчваме инсталирането на High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копиране на ftp://потребителско име:парола@/DS_64224.xml bootflash: копиране на ftp://потребителско име:парола@/DS_65095.xml bootflash: -
Инсталирайте файла за наблюдение на процесора DS 64224 и след това DS 65095 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
ДДЛГВ_ИЕК_В_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 |
ДД_ЛГВ_ИЕК_В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 |
ДД_ЛГВ_ИЕК_Вall_spike_threshold |
1/20/Г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на неизправности в дадения проблем.
Деинсталиране на диагностични подписи
Използването на диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинира като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на диагностичния подпис на повикване-дом и изпълнете следната команда:
деинсталиране на диагностика-подпис за повикване-дом Пример:
деинсталиране на диагностика за повикване-домашен подпис 64224 Периодично се добавят нови подписи към справочния инструмент за диагностични подписи, въз основа на проблеми, които се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
Конфигуриране на 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 |
Влезте в контролния хъб. |
| 2 |
Отидете на . Ако видите символ за предпазливост до местоположение, това означава, че все още не сте конфигурирали телефонен номер за това местоположение. Не можете да правите или получавате обаждания, докато не конфигурирате този номер. |
| 3 |
(по избор) Под PSTN връзкаизберете PSTN или PSTN ( локален шлюз), в зависимост от това кой вече сте конфигурирали. Щракнете върху Управете , за да промените тази конфигурация и след това да потвърдите свързаните рискове, като изберете Продължи. След това изберете една от следните опции и щракнете върху Запиши:
За да мигрирате, вижте Мигриране към планове за повиквания на Cisco по-долу. |
| 4 |
За местоположението изберете Главен номер от падащия списък. Основният номер може да бъде зададен на автоматичен оператор или друго местоназначение в рамките на местоположението, така че външните повикващи се насочват към подходящо местоназначение. Задължително е да зададете главен номер за местоположението, ако то има съединителни линии или обекти само за вътрешни номера, като потребители, работни области, виртуални линии или функции. Без основен номер съединителните линии не могат да се използват и обектите само с вътрешен номер не могат да извършват или получават вътрешни или външни повиквания. Потребителите в това местоположение могат също да използват този номер като свой ИД на външен повикващ, когато извършват PSTN повиквания. Ако изберете безплатен номер като главен номер за дадено местоположение, препоръчваме да актуализирате номера за обратно повикване при спешни случаи за местоположението, тъй като за безплатен номер няма адрес на службите за спешна помощ. За повече информация вижте Конфигуриране на номер за аварийно повикване за местоположение. |
| 5 |
(по избор) При спешни повикванияможете да изберете идентификатор за аварийно местоположение, за да присвоите на това място. Тази настройка е незадължителна и е приложима само за държави, които я изискват. В някои страни (пример: Франция), съществуват регулаторни изисквания за клетъчните радиосистеми, за да се установи самоличността на клетката, когато провеждате спешно повикване и се предоставя на службите за спешна помощ. Други страни като САЩ и Канада прилагат определянето на местоположението чрез други методи. За повече информация вижте Засилено спешно повикване. Вашият доставчик на спешни повиквания може да се нуждае от информация за мрежата за достъп и това се постига чрез дефиниране на ново частно заглавие за разширение на SIP, P-Access-Network-Info. Заглавката носи информация, свързана с мрежата за достъп. Когато зададете идентификатора за аварийно местоположение за местоположение, стойността на местоположението се изпраща на доставчика като част от SIP съобщението. Свържете се с вашия доставчик на спешни повиквания, за да видите дали имате нужда от тази настройка и използвайте стойността, която е предоставена от вашия доставчик на спешни повиквания. |
| 6 |
Изберете номера на гласовата поща, на който потребителите могат да се обадят, за да проверят гласовата си поща за това местоположение. |
| 7 |
(по избор) Щракнете върху иконата за молив в горната част на страницата Местоположение, за да промените иметона местоположението, езика за обявяване, езикана имейла, часовата зонаили адреса , ако е необходимо, и след това щракнете върху Save. Промяната на езика за обявяване влиза в сила незабавно за всички нови потребители и функции, добавени към това местоположение. Ако съществуващите потребители и/или функции също трябва да променят езика си за обявяване, когато са подканени, изберете Промяна за съществуващи потребители и работни пространства или Промяна за съществуващи функции. Щракнете върху Приложи. Можете да видите напредъка на страницата Задачи . Не можете да направите повече промени, докато това не приключи. Промяната на часовата зона за местоположение не актуализира часовите зони на функциите, свързани с местоположението. За да редактирате часовите зони за функции като автоматичен оператор, група за търсене и опашка на повикванията, отидете в областта Общи настройки на конкретната функция, за която искате да актуализирате часовата зона, и редактирайте и запишете там. |
Мигриране към плановете за повиквания на Cisco
Можете да промените вашата PSTN връзка за съществуващо местоположение на Cisco PSTN. Можете например да промените местоположенията за локално базираните PSTN (локален шлюз) или неинтегрирани CCP връзки към Cisco PSTN. Cisco PSTN предоставя облачно PSTN решение от Cisco.
Всички преносими номера остават функционални, с изключение на малко прекъсване по време на планираното време за завършване на пренасянето.
Също така не можете да направите промяна в управлението на номера за местоположение, което преминава през PSTN връзка. Но съществуващите номера остават функционални и все пак можете да задавате или отменяте номера за местоположението. Не можете да добавяте, изтривате и премествате номера за това местоположение. По време на този процес профилът за маршрутизиране автоматично се актуализира, което активира Cisco PSTN.
В момента възможността за промяна на PSTN връзката за съществуващо местоположение на Cisco PSTN не се поддържа за региона на Япония.
При промяна на PSTN връзката се прилага абонамент с лиценз за повиквания и услугата за фактуриране получава известие.
Ограничения:
-
Мигрирането от интегрирано местоположение на IntelePeer към местоположение на Cisco PSTN не се поддържа
-
Местоположението на специализирания екземпляр не може да бъде мигрирано в Cisco PSTN
-
За промяната на PSTN връзката може да са необходими няколко поръчки за портове. Ако е така, тези поръчки са свързани, така че да завършат едновременно. Всяка промяна на датата или отмяна на поръчка за пренасяне трябва да се приложи към всички свързани поръчки за пренасяне за промяната на връзката.
Как се инициира промяна на PSTN връзка
| 1 |
Влезте в контролния хъб. |
| 2 |
Отидете на . |
| 3 |
Изберете местоположението, за което искате да промените PSTN връзката на Cisco PSTN. |
| 4 |
Отидете в раздела Повиквания , щракнете върху опцията Управление до локалната PSTN или неинтегрираната свързана с облака PSTN. |
| 5 |
Редактиране до тип връзка. |
| 6 |
Изберете картата на Планове за повиквания на Cisco и изберете абонамента, който разпределя плана за повиквания на Cisco за потребителите в това местоположение. Щракнете върху Напред. |
| 7 |
За вашето потвърждение се появява страница за промяна на връзката. Щракнете върху Напред и проверете готовността на порта за вашите номера. Бутонът „Напред“ активира само ако всички номера в списъка са преносими. Прочетете тези показалци:
|
| 8 |
Щракнете върху Напред и предоставете информацията за договора. Това е основният контакт по договора за всички местоположения, използващи планове за повиквания на Cisco (САЩ). Всички промени в този контакт се прилагат за всички други местоположения, използващи планове за повиквания на Cisco (САЩ). |
| 9 |
Щракнете върху Напред. Показва се известие с искане за вашето потвърждение, за да запишете информацията за договора си за това местоположение. Изберете Да, променете. |
| 10 |
Въведете адреса на услугата за спешна помощ и щракнете върху Запиши. При спешен случай местният екип за реакция при спешни случаи използва този адрес, за да намери повикващия. |
| 11 |
Показва се обобщената страница с броя създадени портове. Ако има само една поръчка, можете да видите допълнителна стъпка, наречена Предоставяне на допълнителна информация. За множество поръчки е наличен селектор на поръчки най-отгоре, за да се придвижвате между тях. Щракнете върху Напред и въведете подробностите, за да завършите съветника за пренасяне. Поръчките се подават едновременно, когато е предоставена цялата информация за едно искане за мигриране на PSTN. По подразбиране датата на твърдия ангажимент за поръчка е съгласувана във всички поръчки. Промяната на PSTN връзката се прилага автоматично, след като последната свързана поръчка бъде пренесена напълно.
Подробностите за мигрирането са достъпни в раздела . Изберете ИД на поръчката, за да видите подробностите за поръчката в изглед на страничен панел. Можете да видите типа като Промяна на PSTN за поръчки, създадени от промяна на PSTN връзката. |
Отмяна на промяната на PSTN връзката
Администратор може да отмени мигрирането на PSTN, когато местоположението все още е в състояние на преход.
| 1 |
Влезте в контролния хъб. |
| 2 |
Отидете на . |
| 3 |
Изберете местоположението, за което искате да отмените PSTN връзката. |
| 4 |
Отидете в раздела Повиквания и щракнете върху бутона Отмяна на промяната на PSTN връзката . |
| 5 |
Щракнете върху Да, продължете, за да потвърдите отмяната. |
Конфигуриране на план за набиране в Webex Calling
Можете да контролирате плана за набиране на вашето разполагане на Webex Calling с кодове за изходящо набиране. Персонализирайте дължините на разширенията, префиксите за маршрутизиране и предпочитанията за набиране (вътрешни и външни), за да бъдат съвместими с навиците за набиране на вашите потребители.
Тези настройки са за вътрешно набиране и също са налични в съветника за настройка за първи път. Докато промените плана си за набиране, примерните номера в актуализацията на Control Hub, за да покажат тези промени.
Можете да конфигурирате разрешенията за изходящи повиквания за дадено местоположение. Вижте тези стъпки , за да конфигурирате разрешения за изходящи повиквания.
| 1 |
Влезте в Control Hub, отидете на и след това превъртете до Вътрешно набиране. |
| 2 |
Конфигурирайте следните незадължителни предпочитания за набиране, ако е необходимо:
|
| 3 |
Посочете вътрешно набиране за конкретни места. Отидете на , изберете местоположение от списъка и щракнете върху Повиквания. Превъртете до Набиране и след това променете вътрешното набиране, ако е необходимо:
|
| 4 |
Посочете външно набиране за определени местоположения. Отидете на , изберете местоположение от списъка и щракнете върху Повиквания. Превъртете до Набиране и след това променете външното набиране, ако е необходимо:
Въздействие върху потребителите:
|
Конфигуриране на PSTN (локален шлюз) в контролния хъб
Ако сте препродавач с добавена стойност, можете да използвате тези стъпки, за да започнете локална конфигурация на шлюза в 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 базираните на помещения.
Ако загубите идентификационните данни, трябва да ги генерирате от екрана с информация за багажника в контролния център. Щракнете върху Извличане на потребителско име и нулиране на паролата, за да генерирате нов набор от идентификационни данни за удостоверяване , които да използвате в багажника.
Изберете багажник за 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 от пробен период в Control Hub
Ако изпробвате услугите на Webex и искате да конвертирате пробната си версия в платен абонамент, можете да подадете заявка за имейл до партньора си.
| 1 |
Влезте в Control Hub на адрес https://admin.webex.com, изберете иконата на сграда |
| 2 |
Изберете раздела Абонаменти и след това щракнете върху Покупка сега. Имейл се изпраща на партньора ви, като им се съобщава, че се интересувате от конвертиране в платен абонамент. |
Задаване на опции за повиквания
Можете да използвате контролния център, за да зададете приоритета на наличните опции за извикване, които потребителите виждат в Webex App. Можете също така да ги разрешите за еднократно кликване за повикване. За повече информация вижте: Задайте опции за повиквания за потребителите на приложението Webex.
Настройване на поведение при повикване
Можете да управлявате какво се отваря приложението за повиквания, когато потребителите извършват повиквания. Можете да конфигурирате настройките на повикващия клиент, включително разполагане на смесен режим за организации с потребители с права с Unified CM или Webex Calling, и потребители без платени услуги за повиквания от Cisco. За повече информация вижте: Настройване на поведението при повиквания.
Конфигуриране на 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 Customer Experience Essentials. |
| 6 |
Щракнете върху Запиши. |
Разрешаване на поверителност за потребител
| 1 |
Влезте в Control Hub и отидете на . |
| 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 |
Влезте в Control Hub и отидете на . |
| 2 |
Изберете потребител и щракнете върху раздела Повиквания. |
| 3 |
Отидете на Разрешения между потребители и щракнете върху Предупредителен тон за мост между повиквания. |
| 4 |
Включете Предупредителен тон за мост между повиквания, след което щракнете върху Запиши. Тази функция е активирана по подразбиране. За повече информация относно мост между повиквания по споделена MPP линия вижте Споделени линии на вашия мултиплатформен настолен телефон. За повече информация относно мост между повиквания в споделена линия в приложението Webex вижте Появяване на споделена линия за WebexApp. |
Включете хотела за потребител
| 1 |
От изгледа за клиент в https://admin.webex.com отидете на Управление и изберете Потребители. |
| 2 |
Изберете потребител и щракнете върху раздела Повиквания. |
| 3 |
Отидете в раздела Разрешения между потребители , изберете Резервиране на работно място и включете превключвателя. |
| 4 |
Въведете името или номера на хоста за резервиране на работно място в полето за търсене Местоположение на резервиране на работно място и изберете хоста за резервиране, който искате да зададете на потребителя. Може да бъде избран само един организатор за резервиране на работно място. Ако изберете друг хост за резервиране на работно място, първият се изтрива. Ако сте администратор на местоположение, можете да зададете само хоста за резервиране на работно място, свързан с зададените ви местоположения. |
| 5 |
За да ограничите времето, което потребителят може да бъде асоцииран с организатора на резервиране на работно място, изберете броя часове, които потребителят може да използва организатора на работно място, от падащия списък Период на асоцииране с ограничение . Потребителят ще излезе автоматично след избраното време. На екрана се показва съобщение за грешка, ако посоченият за потребителя период на асоцииране надвишава периода на ограничаване на асоцииране на избрания хост за резервиране на работно място. Например, ако хостът за резервиране на работно място има период на ограничаване на свързването от 12 часа, а периодът на ограничаване на свързването на потребителя е 24 часа, се показва съобщение за грешка. В такива случаи е необходимо да удължите ограничителния период на асоцииране на организатора на резервиране на работно място, ако е необходимо повече време за потребителя. |
| 6 |
Щракнете върху Запиши. Потребителят може също да търси и да намери хоста за резервиране на работно място, който иска да използва, от User Hub. За повече информация вижте Достъп до профила ви за повиквания от всяко място. |
Тенденции за приемането и отчети за използването за Webex Calling
Преглед на отчетите за повикванията
Можете да използвате страницата Анализ в Control Hub, за да видите как се използват услугите на Webex Calling, ангажираността в приложението Webex и качеството на работата с мултимедията за повиквания. За достъп до анализа на Webex Calling:
| 1 |
Влезте в контролния хъб. |
| 2 |
Отидете в Анализи и изберете раздела Повиквания . |
| 3 |
Изберете Подробна хронология на повикванията. Подробностите за хронологията на повикванията се показват с данни за качеството на мултимедията.
|
| 4 |
За достъп до данни за качеството на мултимедията влезте в Control Hub, след което отидете на Анализи и изберете Повиквания. |
