Дякуємо за відгук.
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Надіслати відгук?Огляд
Webex Calling наразі підтримує дві версії локального шлюзу:
-
Локальний шлюз
-
Локальний шлюз для Webex for Government
-
Перед початком ознайомтеся з вимогами локальної телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise на використання як функції локального шлюзу для Webex Calling, зверніть увагу на цю конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функціональність через внесені вами зміни.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації щодо продуктів.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифіката , щоб налаштувати локальний шлюз для вашого транка Webex Calling.
Додаткову інформацію про різні типи транка див. в розділі Початок роботи з локальним шлюзом . Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціювання сеансу (SIP) і протокол безпеки транспортного рівня (TLS) для захисту транка, а протокол безпеки в реальному часі (SRTP) для захисту медіафайлів між локальним шлюзом і Webex Calling.
-
Виберіть CUBE як локальний шлюз. Webex for Government наразі не підтримує жодних сторонніх контролерів прикордонних сеансів (SBC). Щоб переглянути останній список, див. розділ Початок роботи з локальним шлюзом.
- Установіть Cisco IOS XE Dublin 17.12.1a або пізніші версії для всіх Webex для державних локальних шлюзів.
-
Щоб переглянути список кореневих органів сертифікації (CA), які підтримує Webex for Government, див. розділ Кореневі органи сертифікації для Webex for Government.
-
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex for Government див. в статті Вимоги до мережі для Webex for Government (FedRAMP).
Локальний шлюз для Webex for Government не підтримує таке:
-
STUN/ICE-Lite для оптимізації шляху медіафайлів
-
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex for Government, скористайтеся таким параметром.
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у локальному шлюзі на основі сертифіката , щоб налаштувати локальний шлюз для транка Webex Calling. Додаткову інформацію про налаштування локального шлюзу на основі сертифіката див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Необхідно налаштувати шифри GCM, сумісні з FIPS, для підтримки локального шлюзу для Webex for Government. Якщо ні, не вдасться налаштувати виклик. Додаткові відомості про конфігурацію див. в розділі Налаштування транка на основі сертифіката Webex Calling.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи SIP-транк, що реєструється. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. На наведеному нижче зображенні висвітлено це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2: Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3: Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштувати локальний шлюз з існуючим уніфікованим середовищем CM
Або:
-
Крок 3: Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора 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.
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу.
-
Передайте пакет кореневого CA Cisco до локального шлюзу.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть реєстраційні дані та облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так:
|
| 3 |
Створіть точку довіри PKI-заповнювача. Ця точка довіри вимагає, щоб налаштувати TLS пізніше. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це було б потрібно для транка на основі сертифіката. |
| 4 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням за допомогою наступних команд конфігурації. Також необхідно оновити параметри транспортування, щоб забезпечити надійне безпечне з'єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволяє з’єднання, якщо ім’я хоста, налаштоване в клієнті 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистого URL-адреси , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Зверніть увагу на інформацію про транк, яка надається після його створення. Деталі, виділені на ілюстрації, використовуються в кроках конфігурації цього посібника. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling.  |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистика медіаЗабезпечує моніторинг медіафайлів на локальному шлюзі. масові стани медіаДозволяє площині управління опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див. у розділі Медіа. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базової функції оператора SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Додаткову інформацію див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шаблон для ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте dtg=, після чого вказується значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 7 |
Налаштуйте профіль SIP 100, який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 8 |
Налаштуйте транк Webex Calling: |
Після визначення клієнта 100 та налаштування вузла набору SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі доступ SBC надає свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат доступу SBC Webex Calling за допомогою кореневої групи CA, яка була оновлена раніше. Якщо сертифікат розпізнано, між локальним шлюзом і доступом Webex Calling SBC встановлюється постійний сеанс TLS. Потім локальний шлюз може використовувати це захищене з’єднання, щоб зареєструватися в системі доступу Webex SBC. Коли з’являється проблема реєстрації на автентифікацію:
-
У відповіді використовуються параметри ім’я користувача, пароль і області з конфігурації облікових даних .
-
Правила модифікації в sip профілі 100 використовуються для перетворення URL SIPS назад у SIP.
Реєстрація успішна, коли 200 OK отримано з SBC доступу.
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. CUBE підтримує безпечну маршрутизацію виклику.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.13Задає цільову адресу для викликів, надісланих постачальнику ТМЗК. Це може бути IP-адреса або ім’я хоста DNS. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає клас голосового зв’язку, який використовується для зіставлення вхідних викликів із цим одноранговим абонентом за допомогою ЗАПРОШЕННЯ ЧЕРЕЗ URI заголовка. Додаткову інформацію див. в URL-адресу вхідного виклику. ідентифікатор сертифікації sip-класу голосового типу pai
(Необов’язково) Вмикає обробку заголовка P-Asserted-Identity і керує тим, як він використовується для транка ТМЗК. Якщо використовується ця команда, для заголовків вихідних параметрів From і P-Asserted-Identity використовуватиметься ідентифікатор абонента, що телефонує, наданий від вхідного однорангового абонента для вихідних викликів. Якщо ця команда не використовується, для заголовків ідентифікатора абонента, що телефонує, наданий із вхідного абонента для набору, використовуватиметься ідентифікатор абонента, що телефонує, а також для заголовків ідентифікатора віддаленого абонента. Додаткову інформацію див. в розділі sip asserted-id для голосового класу. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0
Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
Якщо вам не потрібна оптимізація IP-медіафайлів, виконайте кроки конфігурації для SIP ТМЗК-транка. Використовуйте голосовий порт і вузол набору POTS (як показано в кроках 2 і 3) замість вузла набору VoIP ТМЗК.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 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. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. Також можна встановити DS для автоматичного збору діагностичних даних і перенесення зібраних даних до випадку Cisco TAC, щоб прискорити час роздільної здатності.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. Визначити логіку виявлення проблем можна за допомогою повідомлень syslog, подій 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 або новіші версії.
сервер електронної пошти виклику tacfaststart:password@smtp.gmail.com пріоритет 1 безпечне середовище діагностичного підпису TLS ds_email "tacfaststart@gmail.com" Локальний шлюз, запущений на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати певні налаштування облікового запису Gmail і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Перейдіть до розділу й увімкніть параметр Менш безпечний доступ до програми .
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Використовуйте команду показати snmp , щоб увімкнути SNMP. Якщо його не ввімкнути, налаштуйте команду snmp-server manager .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 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 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR серії або Cisco CSR 1000V серії
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# копіювати ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису на домашній виклик DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор 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 перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Після виявлення події скасування реєстрації буде створено сповіщення електронною поштою та системного лотка й видалено після двох повторень скасування реєстрації. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64117.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Завантажити файл DS_64117.xml успішно LocalGateway# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Використовуйте команду показати snmp , щоб перевірити, чи ввімкнено SNMP. Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 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 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису на домашній виклик 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" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix , яка є шляхом сервера файлів Cisco TAC (cxd.cisco.com), на який передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати з Диспетчера запитів підтримки у наведеній нижче команді. Маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки, якщо необхідно.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику на домашній номер ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Упевніться, що SNMP увімкнено за допомогою команди показати snmp . Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
Завантаження діагностичного підпису домашнього виклику 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Завантажені DS:
Ідентифікатор 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
Перевірка виконання діагностичних підписів
"У наступній команді стовпець ""Стан"" команди показати виклик-домашній діагностичний підпис зміниться на ""Запустити"", тоді як локальний шлюз виконує дію, визначену в підписі." Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: 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 Завантажені DS:
|
Ідентифікатор 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/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS із виводу команди показати виклик-домашній діагностичний підпис і запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Для кращого керування шлюзами Cisco IOS XE рекомендуємо зареєструвати шлюзи й керувати ними через Control Hub. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub для перевірки конфігурації локального шлюзу та виявлення будь-яких проблем з конфігурацією. Зараз цю функцію підтримують лише транки на основі реєстрації.
Додаткову інформацію див. в наступному.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою взаємного SIP-транка TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. Наведене нижче зображення висвітлює це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні. Надано параметри для загальнодоступних або приватних (за NAT) адрес. Записи DNS SRV необов’язкові, за винятком випадків, коли балансування навантаження між кількома екземплярами CUBE.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2: Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3: Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштувати локальний шлюз з існуючим уніфікованим середовищем CM
Або:
-
Крок 3: Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора 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) і додаткове право на пропускну здатність.
Додаткову інформацію див. в розділі Коди авторизації .
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу. Адреси повного доменного імені (FQDN) або запису служби (SRV) локального шлюзу, налаштовані в Control Hub, мають зіставити з загальнодоступною IPv4-адресою в інтернеті.
-
Усі порти SIP і медіафайлів в інтерфейсі локального шлюзу, що facing Webex, повинні бути доступними з інтернету безпосередньо або через статичний NAT. Упевніться, що брандмауер було оновлено належним чином.
-
Виконайте наведені нижче докладні кроки конфігурації, щоб установити підписаний сертифікат на локальний шлюз:
-
Загальнодоступний центр сертифікації (CA), докладний у розділі Які кореневі органи сертифікації підтримуються для викликів на аудіо- та відеоплатформи Cisco Webex? , повинен підписати сертифікат пристрою.
-
Спільне ім’я суб’єкта сертифіката (CN) або одне з альтернативних імен суб’єкта (SAN) має збігатися з повним доменним ім’ям, налаштованим у Control Hub. Наприклад:
-
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді 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.
-
-
Переконайтеся, що сертифікати підписані для використання клієнта й сервера.
-
-
Передайте пакет кореневого CA Cisco до локального шлюзу. Ця пакет містить кореневий сертифікат CA, який використовується для перевірки платформи Webex.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так: |
| 3 |
Створіть точку довіри шифрування за допомогою сертифіката для домену, підписаного підтримуваним центром сертифікації (CA). |
| 4 |
Надайте сертифікат CA проміжного підписання, який використовується для автентифікації вашого сертифіката організатора. Введіть таку команду виконання або конфігурації:
|
| 5 |
Імпортуйте підписаний сертифікат організатора за допомогою наведених далі команд виконання або конфігурації:
|
| 6 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням, яка буде використовуватися для голосових застосунків за допомогою таких команд конфігурації:
|
| 7 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистої url-адреси url , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. Зверніть увагу на інформацію про транк, яка надається після створення транка. Ці відомості, як підкреслено в наведеній нижче ілюстрації, використовуватимуться в кроках конфігурації цього посібника.  |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базового SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди stun потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Докладніше про цю команду див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. вхідні профілі sipДозволяє CUBE використовувати профілі SIP для зміни повідомлень під час їх отримання. Профілі застосовуються через однорангових абонентів або клієнтів. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Команда використання брандмауера й обходу потокових даних потрібна лише під час розгортання локального шлюзу за NAT. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шифри GCM, сумісні з FIPS (Цей крок застосовується лише для Webex для державних установ). Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає GCM як набір шифрів, який пропонує CUBE. Необхідно налаштувати шифри GCM для локального шлюзу для Webex for Government. |
| 7 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену призначення або SRV: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте повне доменне ім’я транка або SRV, налаштоване в Control Hub для транка. |
| 8 |
Налаштуйте профілі керування повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль так, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу: Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. |
| 9 |
Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP так. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу, "10.80.13.12" є IP-адресою інтерфейсу, що стикається з Webex Calling, а "192.65.79.20" є публічною IP-адресою NAT. Запит щодо правила 10 SIP для вихідних повідомлень для вихідних повідомлень до голосового класу Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. правила 30-81Перетворіть посилання на приватні адреси на зовнішню публічну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень від голосового класу Webex CallingОсь пояснення полів для конфігурації: правила 10-80Перетворіть посилання на публічні адреси в налаштовану приватну адресу, що дозволить CUBE обробляти повідомлення від Webex. Додаткову інформацію див. в sip-профілях голосового класу. Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 10 |
Налаштуйте параметри SIP для збереження з профілем зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль, який зберігається, і переходить у режим конфігурації класу голосового зв’язку. Можна налаштувати час (у секундах), коли сигнал SIP Out of Dialog Options надсилається цільовому набору, коли серцебиття з’єднання з кінцевим пристроєм перебуває в стані "ВГОРУ" або "Вниз". Цей профіль увімкнено з однорангового абонента, налаштованого на Webex. Щоб переконатися, що заголовки контактів містять повне доменне ім’я SBC, використовується SIP-профіль 115. Правила 30, 40 і 50 потрібні, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, вибраним для локального шлюзу, і якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC у напрямку Webex Calling, а "192.65.79.20" – загальнодоступною IP-адресою NAT. |
| 11 |
Налаштуйте транк Webex Calling: |
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. CUBE підтримує безпечну маршрутизацію виклику.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.13Задає цільову адресу для викликів, надісланих постачальнику ТМЗК. Це може бути IP-адреса або ім’я хоста DNS. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає клас голосового зв’язку, який використовується для зіставлення вхідних викликів із цим одноранговим абонентом за допомогою ЗАПРОШЕННЯ ЧЕРЕЗ URI заголовка. Додаткову інформацію див. в URL-адресу вхідного виклику. ідентифікатор сертифікації sip-класу голосового типу pai
(Необов’язково) Вмикає обробку заголовка P-Asserted-Identity і керує тим, як він використовується для транка ТМЗК. Якщо використовується ця команда, для заголовків вихідних параметрів From і P-Asserted-Identity використовуватиметься ідентифікатор абонента, що телефонує, наданий від вхідного однорангового абонента для вихідних викликів. Якщо ця команда не використовується, для заголовків ідентифікатора абонента, що телефонує, наданий із вхідного абонента для набору, використовуватиметься ідентифікатор абонента, що телефонує, а також для заголовків ідентифікатора віддаленого абонента. Додаткову інформацію див. в розділі sip asserted-id для голосового класу. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0
Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
Якщо вам не потрібна оптимізація IP-медіафайлів, виконайте кроки конфігурації для SIP ТМЗК-транка. Використовуйте голосовий порт і вузол набору POTS (як показано в кроках 2 і 3) замість вузла набору VoIP ТМЗК.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 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. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події 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 або новішої версії.
налаштуйте сервер електронної пошти термінального виклику :@ пріоритет 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% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера snmp-сервера .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 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 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор 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 включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 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 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик 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" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях сервера файлів Cisco TAC (cxd.cisco.com) для передавання діагностичних даних. Ім’я користувача в шляху файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати в Диспетчер запитів підтримки , як показано нижче. За потреби маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть файл DS 64224 для моніторингу CPU, а потім файл DS 65095 XML у локальний шлюз.
завантаження діагностичного підпису домашнього виклику DS_64224.xml Завантаження файлу DS_64224.xml успішне завантаження файлу DS_65095.xml Завантаження файлу DS_65095.xml успішно -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: 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Завантажені DS:
Ідентифікатор 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
DSLGW_IEC_C_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 Завантажені DS:
|
Ідентифікатор 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/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти зі сповіщенням, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення вихідних команд, які мають відношення до усунення несправностей із цією проблемою.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблем. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS з виводу показу діагностичного підпису виклику додому та запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку діагностичних сигнатур періодично додаються нові підписи на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
