Після налаштування Webex Calling для вашої організації можна налаштувати багажник для підключення локального шлюзу до Webex Calling. Транспорт SIP TLS захищає магістраль між локальним шлюзом і хмарою Webex. Носій між Local Gateway і Webex Calling використовує SRTP.
Огляд
Зараз Webex Calling підтримує дві версії локального шлюзу:
Локальний шлюз
Локальний шлюз для Webex для державних установ
Перш ніж почати, ознайомтеся з вимогами до локальної комутованої телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Докладніші відомості див. у розділі Привілейована архітектура Cisco для викликів Webex.
Ця стаття припускає, що виділена платформа Local Gateway існує без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функції через внесені вами зміни.
 | Процедури містять посилання на довідкову документацію команди, де ви можете дізнатися більше про окремі параметри команди. Всі посилання на команди звертаються до командного посилання керованого шлюзу Webex, якщо не вказано інше (в цьому випадку посилання на команди звертаються до голосового командного посилання Cisco IOS). Ви можете отримати доступ до всіх цих посібників у Cisco Unified Border Element Посилання на команду . Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту. |
Існує два варіанти налаштування локального шлюзу для багажника викликів Webex:
Багажник на основі реєстрації
Багажник на основі сертифікатів
Використовуйте потік завдань під локальним шлюзом на основі реєстрації або локальним шлюзом на основі сертифіката, щоб налаштувати локальний шлюз для магістралі викликів Webex.
Див. розділ Початок роботи з локальним шлюзом , щоб отримати додаткові відомості про різні типи магістралей. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортний захист транспортного рівня (TLS) для захисту багажника і безпечний протокол реального часу (SRTP) для захисту носіїв між локальним шлюзом і викликами Webex.
Виберіть CUBE як локальний шлюз. Webex для державних установ наразі не підтримує сторонні контролери кордону сеансів (SBC). Щоб переглянути останній список, див Почніть роботу з локальним шлюзом .
- Установіть Cisco IOS XE Dublin 17.12.1a або пізнішої версії для всіх локальних шлюзів Webex для державних установ.
Щоб переглянути список кореневих центрів сертифікації (CA), які підтримує Webex for Government, див Кореневі центри сертифікатів для Webex для державних установ .
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex для державних установ див Вимоги до мережі для Webex for Government (FedRAMP) .
Локальний шлюз для Webex для державних установ не підтримує такі можливості:
STUN/ICE-Lite для оптимізації шляху медіа
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex для державних установ, використовуйте такий параметр:
Багажник на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling. Докладніше про налаштування локального шлюзу на основі сертифіката див Налаштуйте транк Webex Calling на основі сертифіката .
Обов’язково потрібно налаштувати шифри GCM, що відповідають вимогам FIPS, для підтримки локального шлюзу для Webex для державних установ. Якщо ні, налаштування виклику не вдасться. Детальнішу інформацію про конфігурацію див Налаштуйте транк Webex Calling на основі сертифіката .
| Webex для державних установ не підтримує локальний шлюз на основі реєстрації. |
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі реєстрації потрібні Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
Списки ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.
| ||
| 3. | Створіть точку довіри PKI-заповнювач.
| ||
| 4. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації:
| ||
| 5. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex. 
| ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистику медіаВмикає моніторинг медіа на локальному шлюзі. медіа bulk-statsДозволяє площині керування опитати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див Медіа . дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP back-to-back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Для отримання додаткової інформації див. STUN flowdata agent-id та STUN flowdata shared-secret. асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас 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, який було оновлено раніше. Якщо сертифікат розпізнано, між локальним шлюзом і SBC для доступу до Webex Calling буде встановлено постійний сеанс TLS. Після цього локальний шлюз зможе використовувати це безпечне з’єднання для реєстрації в SBC для доступу до Webex. Коли реєстрацію оскаржують для автентифікації:
, ім’я користувача, пароль, і області параметри з облікові дані конфігурація використовується у відповіді.
Правила модифікації в профілі 100 sip використовуються для перетворення SIPS URL назад у SIP.
Реєстрація буде успішною після отримання 200 OK від SBC доступу.
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-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:
Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис 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 : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: 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 (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням 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".
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP версії 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 або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
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)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання ЦП на локальному шлюзі.
Моніторинг реєстрації SIP багажника
Цей DS перевіряє наявність незареєстрованого локального шлюзу SIP Trunk з хмарою Webex Calling кожні 60 секунд. Після виявлення події скасування реєстрації він генерує повідомлення електронної пошти та системного журналу та видаляє себе після двох випадків скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
Скасування реєстрації SIP Trunk з повідомленням електронної пошти.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#Використовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Моніторинг аномальних відключень викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб перевірити, чи ввімкнено 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 або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Встановлення діагностичних підписів для усунення несправностей
Використовуйте діагностичні підписи (ДП) для швидкого вирішення проблем. Інженери 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), до якого завантажуються зібрані діагностичні дані. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - це маркер завантаження файлу, який можна отримати з Support Case Manager за допомогою наступної команди. Маркер передавання файлу можна створити в розділі Вкладення диспетчера запитів до служби підтримки за потреби.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endЗабезпечити встановлення моніторингу високого ЦП 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 до локального шлюзу.
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 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою команди show call-home diagnostic-signature. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені 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
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди show call-home diagnostic-signature змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, і виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
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 Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0.0.10 | Зареєстровано | 08.11.2020 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | Виконується | 08.11.2020 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 ми рекомендуємо зареєструватися та керувати шлюзами через Control Hub. Це необов 'язкова конфігурація. Під час реєстрації ви можете використовувати параметр перевірки конфігурації в Центрі керування, щоб перевірити свою конфігурацію локального шлюзу та виявити будь-які проблеми з конфігурацією. В даний час тільки стовбури на основі реєстрації підтримують цю функціональність.
Для отримання додаткової інформації зверніться до наступного:
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою SIP-транка взаємного TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На наведеному нижче зображенні показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні. Надаються параметри для публічної або приватної (за NAT) адресації. Записи DNS SRV є необов’язковими, за винятком випадків балансування навантаження між кількома екземплярами CUBE.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі сертифікатів потрібні Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори 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? має підписати сертифікат пристрою.
Повне доменне ім’я, яке налаштовано в Control Hub під час створення транка, має бути сертифікатом Common Name (CN) або альтернативного імені суб’єкта (SAN) маршрутизатора. Наприклад:
Якщо налаштований транк у 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 Address), є необов 'язковими в SAN.
Незалежно від того, чи використовуєте ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з вашого локального шлюзу використовує ім’я, налаштовану в Control Hub.
Переконайтеся, що сертифікати підписані для використання клієнтами та серверами.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче. | ||
| 3. | Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA). | ||
| 4. | Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:
| ||
| 5. | Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:
| ||
| 6. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:
| ||
| 7. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex.
| ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP Back to Back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. вхідні sip-профіліДозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto. | ||||
| 6. | Налаштуйте FIPS-сумісні шифри GCM (Цей крок застосовується лише для Webex для державних установ) . Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Задає GCM як набір шифрів, який пропонує CUBE. Налаштування шифрів GCM для локального шлюзу для Webex для державних установ є обов’язковим. | ||||
| 7. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка. | ||||
| 8 | Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а «198.51.100.1» — це загальнодоступна IP-адреса інтерфейсу локального шлюзу, що звернена до Webex Calling: Ось пояснення полів для конфігурації: правила 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. SIP-профілі для вихідних повідомлень до Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. правила з 30 по 81Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingОсь пояснення полів для конфігурації: правила з 10 по 80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex. Докладніші відомості див. у розділі sip-профілі голосового класу. | ||||
| 10 | Налаштуйте параметри SIP для підтримки активності за допомогою профілю зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль Keepalive і входить в режим конфігурації голосового класу. Можна налаштувати час (у секундах), протягом якого 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 вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 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 : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: 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 для визначення логіки виявлення проблем. Типи дій включають:
Збирання виходів команди Show (Показати)
Створення консолідованого файлу журналу
Завантаження файлу в надане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та усунення різних проблем.
Перш ніж почати.
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається встановити через помилку перевірки цілісності.
Сервер SMTP (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням 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
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою 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 Software
Продукт
CUBE Enterprise в рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
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)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені 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 ввімкнено за допомогою команди показати 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 Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Ви також можете використовувати діагностичні підписи (DS) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних та автоматичної передачі даних до випадку Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, рекомендований інженером TAC як частину взаємодії з підтримкою.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" syslog та автоматизувати збір діагностичних даних, використовуючи наступні кроки:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях файлового сервера Cisco TAC (cxd.cisco.com) для завантаження діагностичних даних. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - маркер завантаження файлу, який можна отримати з Менеджера випадків підтримки, як показано нижче. Маркер завантаження файлу можна створити в розділі «Вкладення» Менеджера випадків підтримки, за необхідності.
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Ми рекомендуємо встановити моніторинг високих процесорів DS 64224 як запобіжний захід для відключення всіх сигнатур налагодження та діагностики під час високої завантаженості процесора. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
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 в локальний шлюз.
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Завантажені 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
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди показати діагностичний підпис call-home змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, та виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
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 Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
08.11.2020 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
08.11.2020 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 з виводу show call-home diagnostic-signature і виконайте наступну команду:
call-home diagnostic-signature deinstall <DS ID> Приклад:
call-home diagnostic-signature deinstall 64224
| Нові підписи періодично додаються до Інструменту пошуку підписів діагностики на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів. |
