Потік завдань налаштування локального шлюзу

Існує два варіанти налаштування локального шлюзу для багажника викликів Webex:

  • Багажник на основі реєстрації

  • Багажник на основі сертифікатів

Використовуйте потік завдань під локальним шлюзом на основі реєстрації або локальним шлюзом на основі сертифіката, щоб налаштувати локальний шлюз для магістралі викликів Webex. Див. розділ Початок роботи з локальним шлюзом , щоб отримати додаткові відомості про різні типи магістралей. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортний захист транспортного рівня (TLS) для захисту багажника і безпечний протокол реального часу (SRTP) для захисту носіїв між локальним шлюзом і викликами Webex.

Перш ніж почати

  • Розуміння вимог до загальнодоступної комутованої телефонної мережі (PSTN) та локального шлюзу (LGW) на основі приміщень для викликів Webex. Докладніші відомості див. у розділі Привілейована архітектура Cisco для викликів Webex.

  • Ця стаття припускає, що виділена платформа Local Gateway існує без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функції через внесені вами зміни.


 
Процедури містять посилання на довідкову документацію команди, де ви можете дізнатися більше про окремі параметри команди. Всі посилання на команди звертаються до командного посилання керованого шлюзу Webex, якщо не вказано інше (в цьому випадку посилання на команди звертаються до голосового командного посилання Cisco IOS). Ви можете отримати доступ до всіх цих посібників у Cisco Unified Border Element Посилання на команду .

Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту.

У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.

У цьому дизайні використовуються такі основні конфігурації:

  • клієнти голосового класу: Використовується для створення конкретних конфігурацій транка.

  • uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.

  • вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.

  • однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.

  • вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.

Call routing from/to PSTN to/from Webex Calling configuration solution

Під час підключення локального рішення 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, наприклад:


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240
2.

Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.


key config-key password-encrypt YourPassword
password encryption aes
3.

Створіть точку довіри PKI-заповнювач.


 
Ця точка довіри вимагає, щоб пізніше налаштувати TLS. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це потрібно для транка на основі сертифіката.

crypto pki trustpoint EmptyTP 
 revocation-check none
4.

Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації:


 
Команда сервера cn-san-validate гарантує, що локальний шлюз дозволить підключення, якщо ім’я хоста, налаштованого в осередку 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
  1. Установити кількість повторень tcp до 1000 (кратники 5 мс = 5 секунд).

  2. , встановити підключення таймера За допомогою команди можна налаштувати час очікування LGW для встановлення підключення за допомогою проксі, перш ніж розглянути наступний доступний параметр. За замовчуванням для цього таймера встановлено 20 секунд, а мінімальний — 5 секунд. Почніть з низького значення та збільште, якщо необхідно, щоб пристосуватись до умов мережі.


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000
5.

Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:


 

Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA:

ip http клієнт проксі-сервер вашproxy.com проксі-порт 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
1.

Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex.

2.

Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling:

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced  

Ось пояснення полів для конфігурації:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • Для захисту від шахрайства з використанням платних послуг список надійних адрес визначає список хостів і мереж, від яких локальний шлюз очікує законних викликів VoIP.

  • За замовчуванням локальний шлюз блокує всі вхідні повідомлення VoIP з IP-адрес, яких немає у його списку довірених. Статично налаштовані вузли набору з IP-адресами цільової IP-адреси сеансу або IP-адресами групи серверів є довіреними за замовчуванням, тому їх не потрібно додавати до списку довірених.

  • Під час налаштування локального шлюзу додайте до списку підмережі IP вашого регіонального центру обробки даних Webex Calling. Додаткову інформацію див. в розділі Довідкова інформація щодо портів для Webex Calling. Крім того, додайте діапазони адрес для серверів Unified Communications Manager (якщо вони використовуються) і шлюзів транка ТМЗК.


     

    Якщо ваш LGW знаходиться позаду брандмауера з обмеженим конусом NAT, ви можете відключити список довірених IP-адрес у інтерфейсі Webex Calling. Брандмауер вже захищає вас від небажаного вхідного VoIP. Вимкнути дію зменшує ваші довгострокові накладні витрати на конфігурацію, тому що ми не можемо гарантувати, що адреси вузлів Webex Calling залишаться фіксованими, і ви повинні налаштувати свій брандмауер для вузлів у будь-якому випадку.

елемент кордону режиму

Вмикає функції Cisco Unified Border Element (CUBE) на платформі.

статистику медіа

Вмикає моніторинг медіа на локальному шлюзі.

медіа bulk-stats

Дозволяє площині керування опитати площину даних для статистики масових викликів.

Додаткову інформацію про ці команди див Медіа .

дозволити-з’єднання sip до sip

Увімкніть функціонал CUBE Basic SIP back-to-back. Докладніші відомості див. у розділі Дозволити з 'єднання.


 

За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) .

оглушення

Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.

  • Коли ви переадресовуєте виклик користувачеві Webex Calling (наприклад, обидві сторони, що викликаються, є абонентами Webex Calling, і якщо ви прив 'язуєте носій до Webex Calling SBC), то носій не може надходити до локального шлюзу, оскільки отвір не відкритий.

  • Функція прив’язки STUN на локальному шлюзі дозволяє надсилати локально згенеровані запити STUN через узгоджений шлях медіа. Це допомагає відкрити отвір у брандмауері.

Для отримання додаткової інформації див. STUN flowdata agent-id та STUN flowdata shared-secret.

асиметричне корисне навантаження повне

Налаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження.

вимушена рання пропозиція

Примушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція.

3.

Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка.


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

Ось пояснення полів для конфігурації:

кодек голосового класу 100

Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації див. Кодек голосового класу.


 

Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації.

4.

Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling.


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

Ось пояснення полів для конфігурації:

оглушення використання лід lite

Використовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.


 

Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC

5.

Налаштуйте політику шифрування медіа для трафіку Webex.


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Ось пояснення полів для конфігурації:

голосовий клас srtp-crypto 100

Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto.

6.

Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення:


voice class uri 100 sip
 pattern dtg=Dallas1463285401_LGU

Ось пояснення полів для конфігурації:

голос класу uri 100 sip

Визначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див uri класу голосу .

7.

Налаштувати профіль sip 100 , який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

Ось пояснення полів для конфігурації:

  • правило від 10 до 70 і 90

    Забезпечує, що в заголовках SIP, що використовуються для сигналізації викликів, використовується схема sip, а не sip, що вимагається для проксі Webex. Налаштування CUBE для використання sips гарантує використання безпечної реєстрації.

  • правило 80

    Змінює заголовок «Від», щоб включити ідентифікатор OTG/DTG групи транків із Control Hub, щоб однозначно ідентифікувати сайт локального шлюзу в межах підприємства.

8

Налаштувати транк Webex Calling:

  1. Створити клієнт класу голосу 100 щоб визначити та згрупувати конфігурації, необхідні спеціально для транка Webex Calling. Зокрема, дані реєстрації транка, надані в Control Hub раніше, будуть використовуватися на цьому кроці, як описано нижче. Абонентські вузли, пов’язані з цим клієнтом, пізніше успадкують ці конфігурації.


     

    У наведеному нижче прикладі використовуються значення, наведені на кроці 1, для цілей цього посібника (показані жирним шрифтом). Замініть їх значеннями для вашого транка у вашій конфігурації.

    
    voice class tenant 100
      registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
      credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
      no remote-party-id
      sip-server dns:98027369.us10.bcld.webex.com
      connection-reuse
      srtp-crypto 100
      session transport tcp tls 
      url sips 
      error-passthru
      asserted-id pai 
      bind control source-interface GigabitEthernet0/0/1
      bind media source-interface GigabitEthernet0/0/1
      no pass-thru content custom-sdp 
      sip-profiles 100 
      outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
      privacy-policy passthru
    

    Ось пояснення полів для конфігурації:

    клієнт класу голосу 100

    Визначає набір параметрів конфігурації, які використовуватимуться лише для транка Webex Calling. Для отримання додаткової інформації див. Орендар голосового класу.

    реєстратор DNS:98027369.us10.bcld.webex.com схемою ковтки закінчується термін дії 240 коефіцієнт оновлення 50 tcp tls

    Сервер реєстратора для локального шлюзу з налаштуванням реєстрації на оновлення кожні дві хвилини (50% від 240 секунд). Докладніше див. у розділі Реєстратор.

    Переконайтеся, що ви використовуєте значення Реєстрація домену з Control Hub тут.

    номер облікових даних Даллас1171197921_ LGU ім’я користувача Даллас1463285401_ LGU пароль 0 9Wt[M6ifY+ області BroadWorks

    Облікові дані для запиту на реєстрацію багажника. Для отримання додаткової інформації див. Облікові дані (SIP UA).

    Переконайтеся, що ви використовуєте значення хоста лінії/порту, імені користувача для автентифікації та пароля автентифікації відповідно з Control Hub.

    ім’я користувача для автентифікації Даллас1171197921_ LGU пароль 0 9Wt[M6ifY+ області BroadWorks
    ім’я користувача для автентифікації Даллас1171197921_ LGU пароль 0 9Wt[M6ifY+ області 98027369.us10.bcld.webex.com

    Запит автентифікації для викликів. Для отримання додаткової інформації див. Автентифікація (dial-peer).

    Переконайтеся, що ви використовуєте значення імені користувача для автентифікації, пароля автентифікації та домену реєстратора відповідно з Control Hub.

    немає ідентифікатора віддаленої сторони

    Вимкнути заголовок SIP Remote-Party-ID (RPID), оскільки Webex Calling підтримує PAI, який увімкнено за допомогою CIO asserted-id pai . Докладніше див. у розділі remote-party-id.

    sip-сервер dns:us25.sipconnect.bcld.webex.com

    Налаштовує цільовий сервер SIP для транка. Використовуйте адресу SRV граничного проксі, надану в Control Hub під час створення транка.

    з 'єднання-використання

    Використовує одне і те ж постійне з 'єднання для реєстрації та обробки викликів. Докладніші відомості див. у розділі повторне використання з 'єднання.

    srtp-крипт 100

    Налаштовує бажані набори шифрів для гілки виклику SRTP (підключення) (задано на кроці 5). Для отримання додаткової інформації див. Голосовий клас srtp-crypto.

    сесійний транспорт tcp tls

    Встановлює транспорт до TLS. Для отримання додаткової інформації див. Сесія-транспорт.

    url sips

    SRV-запит повинен бути SIP, що підтримується SBC доступу; всі інші повідомлення змінюються на SIP за допомогою SIP-профілю 200.

    error-passthru

    Вказує функціональність відповіді на помилку SIP. Докладніші відомості див. у розділі Error-passthru.

    asserted-id pai

    Вмикає обробку PAI в Local Gateway. Для отримання додаткової інформації див. Стверджений ідентифікатор.

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/1

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до WebexCalling. Докладніші відомості див. у розділі bind.

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/1

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються до WebexCalling. Докладніші відомості див. у розділі bind.

    немає прохідного контенту custom-sdp

    Команда за замовчуванням у клієнті. Докладніші відомості про цю команду див. у розділі Вміст з пропуском.

    sip-профілі 100

    Змінює SIP для SIP та змінює лінію/порт для ЗАПРОШЕННЯ та РЕЄСТРАЦІЇ повідомлень, як визначено в SIP-профілях 200 . Докладніші відомості див. у розділі sip-профілі голосового класу.

    вихідний-проксі dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Виклик доступу SBC. Вставте вихідну проксі-адресу, надану в Control Hub під час створення транка. Для отримання додаткової інформації див. Вихідний проксі-сервер.

    політика конфіденційності passthru

    Налаштовує параметри політики заголовка конфіденційності для транка, щоб передати значення конфіденційності з отриманого повідомлення до наступної гілки виклику. Докладніше див. у розділі Політика конфіденційності.

  2. Налаштуйте транк набору Webex Calling.

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     dtmf-relay rtp-nte
     voice-class stun-usage 100
     no voice-class sip localhost
     voice-class sip tenant 100
     srtp
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 100 voip
      description Inbound/Outbound Webex Calling
    

    Визначає VoIP-пір з міткою 100 і дає змістовний опис для простоти управління та усунення несправностей.

    макс. з’єднання 250

    Обмежує кількість одночасних вхідних і вихідних викликів між LGW і Webex Calling. Для транків реєстрації максимальне значення має бути 250. Використовуйте менше значення, якщо це більше підходить для вашого розгортання. Додаткову інформацію про обмеження одночасного виклику для локального шлюзу див Почніть роботу з локальним шлюзом документ.

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Вказує, що Dial-peer 100 обробляє SIP-ноги виклику. Для отримання додаткової інформації див. протокол сеансу (dial-peer).

    цільовий sip-сервер сеансу

    Указує на те, що сервер SIP, визначений у клієнті 100, успадковано та використовується як призначення для викликів від цього однорангового набору.

    вхідний запит URI 100

    Щоб задати клас голосу, який використовується для зіставлення вузла набору VoIP з єдиним ідентифікатором ресурсу (URI) вхідного виклику. Докладніше див. у розділі Вхідний URI.

    кодек голосового класу 100

    Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу.

    voice-class stun-usage 100

    Дозволяє надсилати локально згенеровані запити STUN на локальному шлюзі через узгоджений шлях медіа. STUN допомагає відкрити дірку в брандмауері для медіатрафіку.

    немає голосового класу SIP localhost

    Вимикає підстановку локального імені хоста DNS замість фізичної IP-адреси в заголовках From, Call-ID та Remote-Party-ID вихідних повідомлень.

    клієнт sip класу голосу 100

    Точка набору успадковує всі параметри, налаштовані глобально та в клієнті 100. Параметри можуть бути перевизначені на рівні вузла набору.

    srtp

    Вмикає SRTP для етапу виклику.

    немає vad

    Вимикання виявлення голосової активності.

Після визначення клієнта 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 такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК:


voice class uri 200 sip
  host ipv4:192.168.80.13

Ось пояснення полів для конфігурації:

голос класу uri 200 sip

Визначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу .

2.

Налаштуйте таку точку набору IP ТМЗК:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

Ось пояснення полів для конфігурації:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

Визначає 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 (Voice over IP).

немає vad

Вимикання виявлення голосової активності. Для отримання додаткової інформації див. VAD (набрати вузол).

3.

Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу.

  1. Створіть групи абонентів, щоб маршрутизувати виклики до Webex Calling або ТМЗК. Визначте DPG 100 з вихідним абонентом 100 для Webex Calling. DPG 100 застосовується до вхідного однорангового набору з ТМЗК. Аналогічно визначте DPG 200 з вихідним вузлом набору 200 до ТМЗК. DPG 200 застосовується до вхідного однорангового набору з Webex.

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    Ось пояснення полів для конфігурації:

    абонента 100

    Пов’язує вихідний вузол набору з групою однорангового набору. Додаткову інформацію див голосовий клас dpg .

  2. Застосуйте групи абонентів, щоб маршрутизувати виклики з Webex до ТМЗК і від ТМЗК до Webex:

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    Ось пояснення полів для конфігурації:

    призначення dpg 200

    Указує, яку групу абонентів і, отже, вузол набору потрібно використовувати для обробки вихідних викликів, представлених цьому вхідному однорангові набору.

    На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції 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 класу голосових викликів.

  1. Класифікує Unified CM до викликів Webex за допомогою порту SIP VIA:

    
    voice class uri 300 sip
     pattern :5065
    
  2. Класифікує виклики Unified CM до ТМЗК за допомогою SIP через порт:

    
    voice class uri 400 sip
     pattern :192\.168\.80\.6[0-5]:5060
    

    Класифікуйте вхідні повідомлення від UCM до транка ТМЗК за допомогою одного або кількох шаблонів, які описують вихідні адреси джерела та номер порту. За потреби для визначення шаблонів зіставлення можна використовувати регулярні вирази.

    У прикладі вище регулярний вираз використовується для зіставлення будь-якої IP-адреси в діапазоні від 192.168.80.60 до 65 і номером порту 5060.

2.

Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:


 

IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. За допомогою цієї конфігурації не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні.


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

Ось пояснення полів для конфігурації:

Наведена далі команда створює ресурсний запис 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.

Налаштуйте такі точки набору:

  1. Одноранговий набір для викликів між Unified CM і Webex Calling:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    Визначає абонентську точку VoIP з тегом 300 і містить змістовний опис для спрощення керування та усунення несправностей.

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Указує, що вузол набору 300 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (dial-peer) .

    цільовий dns сеансу:wxtocucm.io

    Визначає ціль сеансу для кількох вузлів Unified CM через роздільну здатність DNS SRV. У цьому випадку для спрямування викликів використовується локально визначений запис SRV wxtocucm.io.

    вхідні URI через 300

    Використовує URI класу голосу 300 для спрямування всього вхідного трафіку з Unified CM за допомогою порту джерела 5065 до цієї точки набору. Додаткову інформацію див вхідні URI .

    кодек голосового класу 100

    Показує список фільтрів кодеків для викликів на та з Unified CM. Додаткову інформацію див кодек голосового класу .

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    dtmf-relay rtp-nte

    Визначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) .

    немає vad

    Вимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) .

  2. Одноранговий набір для викликів між Unified CM і ТМЗК:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей.

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Указує, що вузол набору 400 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (dial-peer) .

    цільовий dns сеансу:pstntocucm.io

    Визначає ціль сеансу для кількох вузлів Unified CM через роздільну здатність DNS SRV. У цьому випадку локально визначений запис SRV pstntocucm.io використовується для спрямування викликів.

    вхідні URI через 400

    Використовує URI класу голосу 400 для спрямування всього вхідного трафіку від указаних хостів Unified CM за допомогою порту джерела 5060 до цього абонента. Додаткову інформацію див вхідні URI .

    кодек голосового класу 100

    Показує список фільтрів кодеків для викликів на та з Unified CM. Додаткову інформацію див кодек голосового класу .

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    dtmf-relay rtp-nte

    Визначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) .

    немає vad

    Вимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) .

4.

Додайте маршрутизацію виклику, використовуючи такі конфігурації:

  1. Створіть групи абонентів, щоб маршрутизувати виклики між Unified CM і Webex Calling. Визначити DPG 100 за допомогою вихідний вузол набору 100 до Webex Calling. DPG 100 застосовується до пов’язаного вхідного однорангового набору від Unified CM. Аналогічно визначте DPG 300 з вихідним вузлом набору 300 до Unified CM. DPG 300 застосовується до вхідного однорангового набору з Webex.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Створіть групи абонентів для маршрутизації викликів між Unified CM і ТМЗК. Визначити DPG 200 з вихідний вузол набору 200 до ТМЗК. DPG 200 застосовується до пов’язаного вхідного однорангового набору від Unified CM. Аналогічно визначте DPG 400 з вихідним вузлом набору 400 до Unified CM. DPG 400 застосовується до вхідного однорангового набору з ТМЗК.

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    Ось пояснення полів для конфігурації:

    абонента 100

    Пов’язує вихідний вузол набору з групою однорангового набору. Додаткову інформацію див голосовий клас dpg .

  3. Застосуйте групи абонентів, щоб маршрутизувати виклики від Webex до Unified CM і від Unified CM до Webex:

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    Ось пояснення полів для конфігурації:

    dpg призначення 300

    Указує, яку групу абонентів і, отже, вузол набору потрібно використовувати для обробки вихідних викликів, представлених цьому вхідному однорангові набору.

  4. Застосувати групи абонентів для маршрутизації викликів від ТМЗК до Unified CM і від Unified CM до PSTN:

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.

Діагностичні підписи (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 або новішої версії

  1. Діагностичні підписи ввімкнено за замовчуванням.

  2. Налаштуйте захищений сервер електронної пошти для надсилання проактивних сповіщень, якщо на пристрої встановлено Cisco IOS XE 17.6.1a або новішої версії.

    configure terminal 
    call-home  
    mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. Налаштуйте змінну середовища 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 та надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:

  1. Перейти до Керування обліковим записом Google > Безпека і ввімкніть Менш безпечний доступ до програми налаштування.

  2. Відповідь "Так, це був я", коли ви отримуєте електронний лист від Gmail про те, що "Google заборонив комусь увійти у ваш обліковий запис, використовуючи додаток, що не належить Google".

Встановлення діагностичних підписів для проактивного моніторингу

Моніторинг високого використання ЦП

Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP версії 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він відключає всі налагодження та видаляє всі діагностичні підписи, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.

  1. Використовуйте показати 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 
    
  2. Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Продуктивність

    Тип проблеми

    Високе використання процесора з повідомленням електронної пошти.

  3. Скопіюйте файл 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) 
    
  4. Установіть файл XML DS на локальному шлюзі.

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
  5. Використовуйте команду 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 секунд. Після виявлення події скасування реєстрації він генерує повідомлення електронної пошти та системного журналу та видаляє себе після двох випадків скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.

  1. Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    SIP-SIP

    Тип проблеми

    Скасування реєстрації SIP Trunk з повідомленням електронної пошти.

  2. Скопіюйте файл XML DS до локального шлюзу.

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: 
  3. Установіть файл XML DS на локальному шлюзі.

    call-home diagnostic-signature load DS_64117.xml 
    Load file DS_64117.xml success 
    LocalGateway#  
  4. Використовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.

Моніторинг аномальних відключень викликів

Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503.  Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.

  1. Використовуйте показати 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 
    
  2. Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Продуктивність

    Тип проблеми

    Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.

  3. Скопіюйте файл XML DS до локального шлюзу.

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. Установіть файл XML DS на локальному шлюзі.

    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    
  5. Використовуйте команду 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 та автоматизувати збір діагностичних даних, використовуючи наступні кроки:

  1. Налаштуйте додаткову змінну середовища 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"  
  2. Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.

    show snmp 
    %SNMP agent not enabled 
     
     
    config t 
    snmp-server manager 
    end 
  3. Забезпечити встановлення моніторингу високого ЦП DS 64224 як запобіжного заходу для відключення всіх сигнатур налагодження та діагностики під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Продуктивність

    Тип проблеми

    Високе використання процесора з повідомленням електронної пошти.

  4. Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Системні журнали

    Тип проблеми

    Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0

  5. Скопіюйте файли 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: 
  6. Установіть 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 
    
  7. Переконайтеся, що підпис успішно встановлено за допомогою команди 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 та маршрутизує їх до необхідної цілі.

Call routing from/to PSTN to/from Webex Calling configuration solution

Під час підключення локального рішення 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, наприклад:


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240
2.

Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.


key config-key password-encrypt YourPassword
password encryption aes
3.

Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA).

  1. Створіть пару ключів RSA за допомогою такої команди exec.

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096
  2. Створіть точку довіри для підписаного сертифіката за допомогою таких команд конфігурації:

    
    crypto pki trustpoint LGW_CERT
     enrollment terminal pem
     fqdn cube1.lgw.com
     subject-name cn=cube1.lgw.com
     subject-alt-name cube1.lgw.com
     revocation-check none
     rsakeypair lgw-key
  3. Створіть запит на підписання сертифіката (CSR) за допомогою такої команди exec або конфігурації та використовуйте її, щоб надіслати запит на підписаний сертифікат від підтримуваного постачальника CA:

    crypto pki enroll LGW_CERT
4.

Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>
5.

Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>
6.

Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2
 
7.

Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:


 

Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA:

ip http клієнт проксі-сервер вашproxy.com проксі-порт 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
1.

Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex.


 
Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику.
2.

Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling:


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

Ось пояснення полів для конфігурації:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • Для захисту від шахрайства з використанням платних послуг список довірених адрес визначає список хостів і мережевих об’єктів, від яких локальний шлюз очікує легітимних викликів VoIP.

  • За замовчуванням локальний шлюз блокує всі вхідні повідомлення VoIP з IP-адрес, яких немає у його списку довірених. Статично налаштовані вузли набору з IP-адресами цільової IP-адреси сеансу або IP-адресами групи серверів є довіреними за замовчуванням, тому їх не потрібно додавати до списку довірених.

  • Під час налаштування локального шлюзу додайте IP-підмережі для регіонального центру обробки даних Webex Calling до списку, див. Довідкова інформація про порт для Webex Calling для отримання додаткової інформації. Крім того, додайте діапазони адрес для серверів Unified Communications Manager (якщо вони використовуються) і шлюзів транка ТМЗК.

  • Щоб дізнатися більше про те, як використовувати список довірених IP-адрес для запобігання шахрайству з оплатою дорожнього збору, див. розділ Довірений IP-адрес.

елемент кордону режиму

Вмикає функції Cisco Unified Border Element (CUBE) на платформі.

дозволити-з’єднання sip до sip

Увімкніть функціонал CUBE Basic SIP Back to Back. Докладніші відомості див. у розділі Дозволити з 'єднання.


 

За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) .

оглушення

Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.


 
Ці глобальні команди зупинки потрібні лише під час розгортання локального шлюзу за NAT.
  • Коли ви переадресовуєте виклик користувачеві Webex Calling (наприклад, обидві сторони, що викликаються, є абонентами Webex Calling, і якщо ви прив 'язуєте носій до Webex Calling SBC), то носій не може надходити до локального шлюзу, оскільки отвір не відкритий.

  • Функція прив’язки STUN на локальному шлюзі дозволяє надсилати локально згенеровані запити STUN через узгоджений шлях медіа. Це допомагає відкрити отвір у брандмауері.

Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret .

асиметричне корисне навантаження повне

Налаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження.

вимушена рання пропозиція

Примушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція.

вхідні sip-профілі

Дозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів.

3.

Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка.


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

Ось пояснення полів для конфігурації:

кодек голосового класу 100

Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації див. Кодек голосового класу.


 

Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації.

4.

Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling.


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

Ось пояснення полів для конфігурації:

оглушення використання лід lite

Використовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.


 
, дані потоку обходу використання брандмауера stun команда потрібна лише під час розгортання локального шлюзу за NAT.

 
Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC.
5.

Налаштуйте політику шифрування медіа для трафіку Webex.


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Ось пояснення полів для конфігурації:

голосовий клас srtp-crypto 100

Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto.

6.

Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення:


voice class uri 100 sip
 pattern cube1.lgw.com

Ось пояснення полів для конфігурації:

голос класу uri 100 sip

Визначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка.

7.

Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а «198.51.100.1» — це загальнодоступна IP-адреса інтерфейсу локального шлюзу, що звернена до Webex Calling:


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 

Ось пояснення полів для конфігурації:

правила 10 і 20

Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв.


 

Пропустіть наступний крок, якщо ви налаштували локальний шлюз із загальнодоступними IP-адресами.

8

Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP наступним чином. У цьому прикладі cube1.lgw.com є повним доменом, налаштованим для локального шлюзу, «10.80.13.12» — це IP-адреса інтерфейсу, що звернена до Webex Calling, а «192.65.79.20» — це загальнодоступна IP-адреса NAT.

SIP-профілі для вихідних повідомлень до Webex Calling

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

Ось пояснення полів для конфігурації:

правила 10 і 20

Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв.

правила з 30 по 81

Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення.

Профіль SIP для вхідних повідомлень із Webex Calling

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

Ось пояснення полів для конфігурації:

правила з 10 по 80

Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex.

Докладніші відомості див. у розділі sip-профілі голосового класу.

9

Налаштуйте параметри SIP для підтримки активності за допомогою профілю зміни заголовка.


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

Ось пояснення полів для конфігурації:

голосовий клас 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. .

10

Налаштувати транк Webex Calling:

  1. Створити клієнт класу голосу 100 щоб визначити та згрупувати конфігурації, необхідні спеціально для транка Webex Calling. Абонентські вузли, пов’язані з цим клієнтом пізніше, успадкують такі конфігурації:


     

    У наведеному нижче прикладі використовуються значення, наведені на кроці 1, для цілей цього посібника (показані жирним шрифтом). Замініть їх значеннями для вашого транка у вашій конфігурації.

    
    voice class tenant 100
     no remote-party-id
     sip-server dns:us25.sipconnect.bcld.webex.com
     srtp-crypto 100
     localhost dns:cube1.lgw.com
     session transport tcp tls
     no session refresh
     error-passthru
     bind control source-interface GigabitEthernet0/0/1
     bind media source-interface GigabitEthernet0/0/1
     no pass-thru content custom-sdp
     sip-profiles 100 
     sip-profiles 110 inbound
     privacy-policy passthru
    !

    Ось пояснення полів для конфігурації:

    клієнт класу голосу 100

    Рекомендовано використовувати клієнтів для налаштування транків, які мають власний сертифікат TLS і список перевірки CN або SAN. Тут профіль tls, пов’язаний із клієнтом, містить точку довіри, яка буде використовуватися для прийняття або створення нових підключень, а також список CN або SAN для перевірки вхідних підключень. Для отримання додаткової інформації див. Орендар голосового класу.

    немає ідентифікатора віддаленої сторони

    Вимкнути заголовок SIP Remote-Party-ID (RPID), оскільки Webex Calling підтримує PAI, який увімкнено за допомогою CIO asserted-id pai . Докладніше див. у розділі remote-party-id.

    DNS сервера sip:us25.sipconnect.bcld.webex.com

    Налаштовує цільовий сервер SIP для транка. Використовуйте адресу SRV граничного проксі, надану в Control Hub під час створення транка

    srtp-крипт 100

    Налаштовує бажані набори шифрів для гілки виклику SRTP (підключення) (задано на кроці 5). Для отримання додаткової інформації див. Голосовий клас srtp-crypto.

    Локальний хост DNS: cube1.lgw.com

    Налаштовує CUBE на заміну фізичної IP-адреси в заголовках «Від», «Ідентифікатор виклику» та «Ідентифікатор віддаленої сторони» у вихідних повідомленнях із наданим FQDN.

    сесійний транспорт tcp tls

    Встановлює транспортування до TLS для пов’язаних вузлів набору. Для отримання додаткової інформації див. Сесія-транспорт.

    Немає оновлення сеансу

    Глобальне вимкнення оновлення сеансу SIP.

    error-passthru

    Вказує функціональність відповіді на помилку SIP. Докладніші відомості див. у розділі Error-passthru.

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/1

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих у Webex Calling. Докладніші відомості див. у розділі bind.

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/1

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються до Webex Calling. Докладніші відомості див. у розділі bind.

    профілі sip класу голосу 100

    Застосовує профіль зміни заголовка (загальнодоступна IP-адреса або NAT-адресація) для використання для вихідних повідомлень. Для отримання додаткової інформації див. профілі SIP голосового класу.

    вхідні профілі 110 класу голосу

    Застосовує профіль зміни заголовка (тільки адресація NAT) для використання для вхідних повідомлень. Додаткову інформацію див. в розділі про профілі sip класу голосу.

    політика конфіденційності перехідний

    Налаштовує параметри політики заголовка конфіденційності для транка, щоб передати значення конфіденційності з отриманого повідомлення до наступної гілки виклику. Докладніше див. у розділі Політика конфіденційності.

  2. Налаштуйте транк набору Webex Calling.

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     voice-class stun-usage 100
     voice-class sip rel1xx disable
     voice-class sip asserted-id pai
     voice-class sip tenant 100
     voice-class sip options-keepalive profile 100
     dtmf-relay rtp-nte 
     srtp
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling

    Визначає абонентську точку VoIP з тегом 100 і містить змістовний опис для спрощення керування та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором».

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Визначає вузол набору 100 обробляє гілки виклику SIP. Для отримання додаткової інформації див. протокол сеансу (dial-peer).

    цільовий sip-сервер сеансу

    Указує на те, що сервер SIP, визначений у клієнті 100, успадковано та використовується як призначення для викликів від цього однорангового набору.

    вхідний запит URI 100

    Щоб задати клас голосу, який використовується для зіставлення вузла набору VoIP з єдиним ідентифікатором ресурсу (URI) вхідного виклику. Додаткову інформацію див вхідні URI .

    кодек голосового класу 100

    Показує список фільтрів кодеків для викликів на та з Webex Calling. Для отримання додаткової інформації див. Кодек голосового класу.

    Voice-class stun-usage 100

    Дозволяє надсилати локально згенеровані запити STUN на локальному шлюзі через узгоджений шлях медіа. STUN допомагає відкрити дірку в брандмауері для медіатрафіку.

    голос-клас sip підтверджений ідентифікатор pai

    Встановлює інформацію про вихідні виклики за допомогою заголовка ідентифікатора конфіденційності (PAI). Додаткову інформацію див затверджений ідентифікатор sip-класу голосу .

    Voice-Class sip клієнта 100

    Точка набору успадковує всі параметри, налаштовані глобально та в клієнті 100. Параметри можуть бути перевизначені на рівні вузла набору. Додаткову інформацію див клієнт sip класу голосу .

    voice-class sip options-keepalive profile 100

    Ця команда використовується для моніторингу доступності групи серверів SIP або кінцевих точок за допомогою певного профілю (100).

    srtp

    Вмикає SRTP для етапу виклику.

Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:


 

Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів.


 

Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI .

1.

Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК:


voice class uri 200 sip
  host ipv4:192.168.80.13

Ось пояснення полів для конфігурації:

голос класу uri 200 sip

Визначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу .

2.

Налаштуйте таку точку набору IP ТМЗК:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

Ось пояснення полів для конфігурації:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

Визначає 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 (Voice over IP).

немає vad

Вимикання виявлення голосової активності. Для отримання додаткової інформації див. VAD (набрати вузол).

3.

Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу.

  1. Створіть групи абонентів, щоб маршрутизувати виклики до Webex Calling або ТМЗК. Визначте DPG 100 з вихідним абонентом 100 для Webex Calling. DPG 100 застосовується до вхідного однорангового набору з ТМЗК. Аналогічно визначте DPG 200 з вихідним вузлом набору 200 до ТМЗК. DPG 200 застосовується до вхідного однорангового набору з Webex.

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    Ось пояснення полів для конфігурації:

    абонента 100

    Пов’язує вихідний вузол набору з групою однорангового набору. Додаткову інформацію див голосовий клас dpg .

  2. Застосуйте групи абонентів, щоб маршрутизувати виклики з Webex до ТМЗК і від ТМЗК до Webex:

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    Ось пояснення полів для конфігурації:

    призначення dpg 200

    Указує, яку групу абонентів і, отже, вузол набору потрібно використовувати для обробки вихідних викликів, представлених цьому вхідному однорангові набору.

    На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.

Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 — до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.

1.

Налаштуйте наведені нижче URI класу голосових викликів.

  1. Класифікує Unified CM до викликів Webex за допомогою порту SIP VIA:

    
    voice class uri 300 sip
     pattern :5065
    
  2. Класифікує виклики Unified CM до ТМЗК за допомогою SIP через порт:

    
    voice class uri 400 sip
     pattern :192\.168\.80\.6[0-5]:5060
    

    Класифікуйте вхідні повідомлення від UCM до транка ТМЗК за допомогою одного або кількох шаблонів, які описують вихідні адреси джерела та номер порту. За потреби для визначення шаблонів зіставлення можна використовувати регулярні вирази.

    У прикладі вище регулярний вираз використовується для зіставлення будь-якої IP-адреси в діапазоні від 192.168.80.60 до 65 і номером порту 5060.

2.

Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:


 

IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. За допомогою цієї конфігурації не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні.


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

Ось пояснення полів для конфігурації:

Наведена далі команда створює ресурсний запис 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.

Налаштуйте такі точки набору:

  1. Одноранговий набір для викликів між Unified CM і Webex Calling:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    Визначає абонентську точку VoIP з тегом 300 і містить змістовний опис для спрощення керування та усунення несправностей.

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Указує, що вузол набору 300 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (dial-peer) .

    цільовий dns сеансу:wxtocucm.io

    Визначає ціль сеансу для кількох вузлів Unified CM через роздільну здатність DNS SRV. У цьому випадку для спрямування викликів використовується локально визначений запис SRV wxtocucm.io.

    вхідні URI через 300

    Використовує URI класу голосу 300 для спрямування всього вхідного трафіку з Unified CM за допомогою порту джерела 5065 до цієї точки набору. Додаткову інформацію див вхідні URI .

    кодек голосового класу 100

    Показує список фільтрів кодеків для викликів на та з Unified CM. Додаткову інформацію див кодек голосового класу .

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    dtmf-relay rtp-nte

    Визначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) .

    немає vad

    Вимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) .

  2. Одноранговий набір для викликів між Unified CM і ТМЗК:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Ось пояснення полів для конфігурації:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей.

    призначення-шаблон BAD.BAD

    Фіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. У цьому випадку можна використовувати будь-який допустимий шаблон призначення.

    протокол сеансу sipv2

    Указує, що вузол набору 400 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (dial-peer) .

    цільовий dns сеансу:pstntocucm.io

    Визначає ціль сеансу для кількох вузлів Unified CM через роздільну здатність DNS SRV. У цьому випадку локально визначений запис SRV pstntocucm.io використовується для спрямування викликів.

    вхідні URI через 400

    Використовує URI класу голосу 400 для спрямування всього вхідного трафіку від указаних хостів Unified CM за допомогою порту джерела 5060 до цього абонента. Додаткову інформацію див вхідні URI .

    кодек голосового класу 100

    Показує список фільтрів кодеків для викликів на та з Unified CM. Додаткову інформацію див кодек голосового класу .

    джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0

    Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати .

    dtmf-relay rtp-nte

    Визначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) .

    немає vad

    Вимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) .

4.

Додайте маршрутизацію виклику, використовуючи такі конфігурації:

  1. Створіть групи абонентів, щоб маршрутизувати виклики між Unified CM і Webex Calling. Визначити DPG 100 за допомогою вихідний вузол набору 100 до Webex Calling. DPG 100 застосовується до пов’язаного вхідного однорангового набору від Unified CM. Аналогічно визначте DPG 300 з вихідним вузлом набору 300 до Unified CM. DPG 300 застосовується до вхідного однорангового набору з Webex.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Створіть групи абонентів для маршрутизації викликів між Unified CM і ТМЗК. Визначити DPG 200 з вихідний вузол набору 200 до ТМЗК. DPG 200 застосовується до пов’язаного вхідного однорангового набору від Unified CM. Аналогічно визначте DPG 400 з вихідним вузлом набору 400 до Unified CM. DPG 400 застосовується до вхідного однорангового набору з ТМЗК.

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    Ось пояснення полів для конфігурації:

    абонента 100

    Пов’язує вихідний вузол набору з групою однорангового набору. Додаткову інформацію див голосовий клас dpg .

  3. Застосуйте групи абонентів, щоб маршрутизувати виклики від Webex до Unified CM і від Unified CM до Webex:

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    Ось пояснення полів для конфігурації:

    dpg призначення 300

    Указує, яку групу абонентів і, отже, вузол набору потрібно використовувати для обробки вихідних викликів, представлених цьому вхідному однорангові набору.

  4. Застосувати групи абонентів для маршрутизації викликів від ТМЗК до Unified CM і від Unified CM до PSTN:

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.

Діагностичні підписи (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 або вище

  1. Діагностичні підписи ввімкнено за замовчуванням.

  2. Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо на пристрої встановлено IOS XE 17.6.1 або вище.

    
    configure terminal 
    call-home  
    mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. Налаштуйте змінну середовища 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% або більше, він відключає всі налагодження і видаляє всі діагностичні підписи, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.

  1. Переконайтеся, що ви ввімкнули 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 
    
  2. Завантажте 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

    Область проблеми

    Продуктивність

    Тип проблеми

    Високе використання ЦП зі сповіщенням електронною поштою

  3. Скопіюйте файл 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) 
    
  4. Установіть файл XML DS на локальному шлюзі.

    
    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success  
  5. Використовуйте команду 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 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.

  1. Переконайтеся, що 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 
  2. Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Продуктивність

    Тип проблеми

    Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.

  3. Скопіюйте файл XML DS до локального шлюзу.

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. Установіть файл XML DS на локальному шлюзі.

    
    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
  5. Використовуйте команду 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 та автоматизувати збір діагностичних даних, використовуючи наступні кроки:

  1. Налаштуйте іншу змінну середовища 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"  
  2. Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.

    
    show snmp 
    %SNMP agent not enabled 
     
    config t 
    snmp-server manager 
    end 
  3. Ми рекомендуємо встановити моніторинг високих процесорів DS 64224 як запобіжний захід для відключення всіх сигнатур налагодження та діагностики під час високої завантаженості процесора. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.

    Назва поля

    Значення поля

    Платформа

    Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software

    Продукт

    Корпоративна версія CUBE у рішенні Webex Calling

    Область проблеми

    Продуктивність

    Тип проблеми

    Високе використання процесора з повідомленням електронної пошти.

  4. Завантажте 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

  5. Скопіюйте файли 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: 
  6. Встановіть високопродуктивний моніторинг процесора 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 
    
  7. Переконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому . У стовпці стану має бути значення «Зареєстровано».

    
    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 не підтримує запити на створення нових користувацьких підписів.