- Головна
- /
- Стаття
Дякуємо за відгук.
Робочий процес конфігурації Webex Calling
У цій статті
Надіслати відгук?Отримуйте свої контакти з усією доступною інформацією про Webex Calling, незалежно від того, чи ви партнер, адміністратор або користувач. Використовуйте наведені тут посилання, щоб допомогти почати використання всіх служб і функцій, доступних із Webex Calling.
Вимоги до локального шлюзу для Webex Calling
Загальні передумови
Перш ніж налаштувати локальний шлюз для Webex Calling , переконайтеся, що ви:
Базові знання принципів VoIP
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
Мати базові знання про протокол ініціації сеансу (SIP)
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Див Посібник із налаштування підприємства Cisco Unified Border Element (CUBE). для отримання додаткової інформації.
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Упевніться, що розгортання має один або кілька локальних шлюзів [Cisco CUBE (для підключення на основі IP) або шлюз Cisco IOS (для підключення на основі TDM)], які наведено в таблиці 1 розділу Посібник із замовлення локального шлюзу для Webex Calling. Крім того, упевніться, що на платформі запущено підтримуваний випуск IOS-XE, як описано в посібнику з налаштування локального шлюзу.
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
Надходить запит облікових даних (наданих SIP-дайджестом)
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1. | Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте.
| ||
| 2. | Перегляньте й прийміть умови обслуговування. | ||
| 3. | Перегляньте план і клацніть Початок роботи.
| ||
| 4. | Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. | ||
| 5. | Клацніть Далі. Розміщення за замовчуванням. | ||
| 6. | Виберіть один із наведених далі варіантів.
| ||
| 7. | Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
| ||
| 8 | Клацніть Далі. | ||
| 9 | Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
Адреса розташування
Бажані номери телефону (необов’язково)
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку .
| ||||
| 2. | Налаштуйте параметри розташування.
| ||||
| 3. | Натисніть Зберегти, а потім виберіть Так/Ні, щоб додати номери до розташування зараз або пізніше. | ||||
| 4. | Якщо ви клацнули Додати зараз, виберіть один із наведених нижче параметрів.
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Щоб отримати допомогу, створіть запит до служби підтримки. | ||||
| 5. | Виберіть, чи потрібно активувати номери зараз або пізніше. | ||||
| 6. | Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. | ||||
| 7. | Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Перш ніж почати
 | Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до розділу й в розкривному меню виберіть розташування, яке потрібно видалити. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори. Майте на увазі, що будь-які номери, пов 'язані з цим розташуванням, будуть повернуті вашому постачальнику послуг PSTN; ви більше не будете володіти цими номерами. |
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . |
| 2. | Клацніть |
| 3. | Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай потрібно кілька хвилин, щоб остаточно видалити розташування, але процес може тривати до однієї години. Щоб перевірити стан, можна клацнути |
поруч з ім’ям розташування і вибрати Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
| Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling. |
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. | ||||||
| 2. | (Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
| ||||||
| 3. | Виберіть основний номер, за яким можна зв’язатися з основним контактом розташування. | ||||||
| 4. | (Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню.
| ||||||
| 5. | Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. | ||||||
| 6. | (Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти.
|
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. Коли ви змінюєте абонентську групу, приклади номерів у Control Hub оновіть, щоб відобразити ці зміни.
 | Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки, щоб налаштувати дозволи на вихідні виклики. |
| 1. | Увійти в Control Hub , перейдіть до , а потім перейдіть до Внутрішній набір . | ||||||||
| 2. | За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
| ||||||||
| 3. | Налаштуйте внутрішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть внутрішній набір відповідно до:
| ||||||||
| 4. | Укажіть зовнішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть зовнішній набір відповідно до:
Вплив на користувачів.
|
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
 | Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань. |
Перш ніж почати
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1. | Увійдіть до Центру керування на сторінці, перейдіть до розділу Послуги > Виклик > Маршрутизація викликів і виберіть Додати багажник.https://admin.webex.com | ||
| 2. | Виберіть розташування. | ||
| 3. | Укажіть ім’я транку й клацніть Зберегти.
|
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . | ||
| 2. | Виберіть розташування, яке необхідно змінити, і клацніть Керування. | ||
| 3. | Виберіть PSTN на базі локальних ресурсів і клацніть Далі. | ||
| 4. | Виберіть транк у розкривному меню.
| ||
| 5. | Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). У цій статті розглянуто цей процес. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
Після успішного завершення конфігурації на самому шлюзі можна повернутися до розділу Служби > Виклик > Розташування в Control Hub. Створений вами шлюз буде відображено в призначеній йому картці розташування із зеленою крапкою ліворуч від імені. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
Якщо ви пробуєте сервіси Webex і хочете перетворити пробну версію на платну підписку, ви можете надіслати запит електронною поштою своєму партнеру.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , виберіть значок будівлі |
| 2. | Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
Ви можете використовувати Control Hub, щоб встановити пріоритет доступних опцій виклику, які користувачі бачать у додатку Webex. Ви також можете ввімкнути їх для одного натискання на виклик. Додаткову інформацію див. на сторінці Встановіть параметри виклику для користувачів Webex App.
Ви можете керувати тим, що додаток для викликів відкривається, коли користувачі здійснюють виклики. Ви можете налаштувати параметри клієнта виклику, включаючи розгортання в змішаному режимі для організацій з користувачами, які мають право на виклик Unified CM або Webex, і користувачами без платних послуг виклику від Cisco. Додаткову інформацію див. на сторінці Налаштуйте поведінку викликів .
Огляд
Зараз Webex Calling підтримує дві версії локального шлюзу:
Локальний шлюз
Локальний шлюз для Webex для державних установ
Перш ніж почати, ознайомтеся з вимогами до локальної комутованої телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Докладніші відомості див. у розділі Привілейована архітектура Cisco для викликів Webex.
Ця стаття припускає, що виділена платформа Local Gateway існує без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функції через внесені вами зміни.
| Процедури містять посилання на довідкову документацію команди, де ви можете дізнатися більше про окремі параметри команди. Всі посилання на команди звертаються до командного посилання керованого шлюзу Webex, якщо не вказано інше (в цьому випадку посилання на команди звертаються до голосового командного посилання Cisco IOS). Ви можете отримати доступ до всіх цих посібників у Cisco Unified Border Element Посилання на команду . Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту. |
Існує два варіанти налаштування локального шлюзу для багажника викликів Webex:
Багажник на основі реєстрації
Багажник на основі сертифікатів
Використовуйте потік завдань під локальним шлюзом на основі реєстрації або локальним шлюзом на основі сертифіката, щоб налаштувати локальний шлюз для магістралі викликів Webex.
Див. розділ Початок роботи з локальним шлюзом , щоб отримати додаткові відомості про різні типи магістралей. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортний захист транспортного рівня (TLS) для захисту багажника і безпечний протокол реального часу (SRTP) для захисту носіїв між локальним шлюзом і викликами Webex.
Виберіть CUBE як локальний шлюз. Webex для державних установ наразі не підтримує сторонні контролери кордону сеансів (SBC). Щоб переглянути останній список, див Почніть роботу з локальним шлюзом .
- Установіть Cisco IOS XE Dublin 17.12.1a або пізнішої версії для всіх локальних шлюзів Webex для державних установ.
Щоб переглянути список кореневих центрів сертифікації (CA), які підтримує Webex for Government, див Кореневі центри сертифікатів для Webex для державних установ .
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex для державних установ див Вимоги до мережі для Webex for Government (FedRAMP) .
Локальний шлюз для Webex для державних установ не підтримує такі можливості:
STUN/ICE-Lite для оптимізації шляху медіа
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex для державних установ, використовуйте такий параметр:
Багажник на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling. Докладніше про налаштування локального шлюзу на основі сертифіката див Налаштуйте транк Webex Calling на основі сертифіката .
Обов’язково потрібно налаштувати шифри GCM, що відповідають вимогам FIPS, для підтримки локального шлюзу для Webex для державних установ. Якщо ні, налаштування виклику не вдасться. Детальнішу інформацію про конфігурацію див Налаштуйте транк Webex Calling на основі сертифіката .
| Webex для державних установ не підтримує локальний шлюз на основі реєстрації. |
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі реєстрації потрібні Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
Списки ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.
| ||
| 3. | Створіть точку довіри PKI-заповнювач.
| ||
| 4. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації:
| ||
| 5. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex. | ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистику медіаВмикає моніторинг медіа на локальному шлюзі. медіа bulk-statsДозволяє площині керування опитати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див Медіа . дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP back-to-back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Для отримання додаткової інформації див. STUN flowdata agent-id та STUN flowdata shared-secret. асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto. | ||||
| 6. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див uri класу голосу . | ||||
| 7. | Налаштувати профіль sip 100 , який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
| ||||
| 8 | Налаштувати транк Webex Calling:
|
Після визначення клієнта 100 і налаштувати абонентську точку SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі SBC доступу представляє свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат SBC для доступу до Webex Calling за допомогою кореневого пакета CA, який було оновлено раніше. Якщо сертифікат розпізнано, між локальним шлюзом і SBC для доступу до Webex Calling буде встановлено постійний сеанс TLS. Після цього локальний шлюз зможе використовувати це безпечне з’єднання для реєстрації в SBC для доступу до Webex. Коли реєстрацію оскаржують для автентифікації:
, ім’я користувача, пароль, і області параметри з облікові дані конфігурація використовується у відповіді.
Правила модифікації в профілі 100 sip використовуються для перетворення SIPS URL назад у SIP.
Реєстрація буде успішною після отримання 200 OK від SBC доступу.
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 — до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
| Під час створення транка Webex Calling в Unified CM переконайтеся, що ви налаштували вхідний порт у параметрах профілю безпеки транка SIP на 5065. Це дозволяє вхідні повідомлення через порт 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу. |
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. | ||
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:
Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. | ||
| 3. | Налаштуйте такі точки набору: | ||
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) активно виявляють поширені проблеми в локальному шлюзі на БАЗІ IOS XE і генерують повідомлення електронної пошти, системного журналу або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це файли XML, які містять інформацію про події, що викликають проблему, і дії, які необхідно виконати для інформування, усунення несправностей та усунення проблеми. Можна визначити логіку виявлення проблем за допомогою повідомлень системного журналу, подій SNMP і за допомогою періодичного моніторингу конкретних виводів команд show.
Типи дій включають збирання виходів команди show:
Створення консолідованого файлу журналу
Передавання файлу в надане користувачем мережеве розташування, як-от HTTPS, SCP, FTP-сервер.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та усунення різних проблем.
Перш ніж почати.
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається встановити через помилку перевірки цілісності.
Сервер SMTP (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням IOS XE 17.6.1 або вище, якщо ви хочете використовувати захищений SMTP-сервер для електронних повідомлень.
Передумови
Локальний шлюз під керуванням IOS XE 17.6.1a або новішої версії
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти для надсилання проактивних сповіщень, якщо на пристрої встановлено Cisco IOS XE 17.6.1a або новішої версії.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора, щоб сповістити вас.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Далі наведено приклад конфігурації локального шлюзу, що працює на Cisco IOS XE 17.6.1a або пізнішої версії для надсилання проактивних сповіщень на tacfaststart@gmail.com використання Gmail як захищеного сервера SMTP:
| Ми рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або пізнішої версії. |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com" | Локальний шлюз, що працює на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати конкретне налаштування облікового запису Gmail та надати конкретний дозвіл на правильну обробку електронної пошти з пристрою: |
Перейти до і ввімкніть Менш безпечний доступ до програми налаштування.
Відповідь "Так, це був я", коли ви отримуєте електронний лист від Gmail про те, що "Google заборонив комусь увійти у ваш обліковий запис, використовуючи додаток, що не належить Google".
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP версії 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він відключає всі налагодження та видаляє всі діагностичні підписи, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб увімкнути SNMP. Якщо не ввімкнути, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Наступний приклад показує копіювання файлу з FTP-сервера на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання ЦП на локальному шлюзі.
Моніторинг реєстрації SIP багажника
Цей DS перевіряє наявність незареєстрованого локального шлюзу SIP Trunk з хмарою Webex Calling кожні 60 секунд. Після виявлення події скасування реєстрації він генерує повідомлення електронної пошти та системного журналу та видаляє себе після двох випадків скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
Скасування реєстрації SIP Trunk з повідомленням електронної пошти.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#Використовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Моніторинг аномальних відключень викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб перевірити, чи ввімкнено SNMP. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Встановлення діагностичних підписів для усунення несправностей
Використовуйте діагностичні підписи (ДП) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних та автоматичної передачі даних до випадку Cisco TAC. Діагностичні підписи (DS) усувають необхідність вручну перевіряти виникнення проблеми та значно спрощують усунення періодичних і тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, рекомендований інженером TAC як частину взаємодії з підтримкою.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" syslog та автоматизувати збір діагностичних даних, використовуючи наступні кроки:
Налаштуйте додаткову змінну середовища DS, ds_fsurl_prefix яка є шляхом файлового сервера Cisco TAC (cxd.cisco.com), до якого завантажуються зібрані діагностичні дані. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - це маркер завантаження файлу, який можна отримати з Support Case Manager за допомогою наступної команди. Маркер передавання файлу можна створити в розділі Вкладення диспетчера запитів до служби підтримки за потреби.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endЗабезпечити встановлення моніторингу високого ЦП DS 64224 як запобіжного заходу для відключення всіх сигнатур налагодження та діагностики під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою команди show call-home diagnostic-signature. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди show call-home diagnostic-signature змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, і виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0.0.10 | Зареєстровано | 08.11.2020 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | Виконується | 08.11.2020 00:12:53 |
показати статистику діагностичного підпису виклику додому
Ідентифікатор DS | Ім’я DS | Запущено/Максимальна кількість/Видалення | Середній час виконання (секунди) | Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0/0/N | 0,000 | 0,000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23,053 | 23,053 |
Електронний лист сповіщення, який надсилається під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версія програмного забезпечення, поточна конфігурація та показ виходів команд, які мають відношення до усунення заданої проблеми.
Видалення діагностичних підписів
Використання діагностичних підписів для усунення несправностей зазвичай визначається для видалення після виявлення деяких проблемних випадків. Якщо потрібно видалити підпис вручну, отримайте ідентифікатор DS із виводу файлу показати підпис діагностики виклику додому і виконайте таку команду:
call-home diagnostic-signature deinstall <DS ID>
Приклад:
call-home diagnostic-signature deinstall 64224
| Нові підписи додаються до інструменту пошуку підписів діагностики періодично, на основі проблем, які зазвичай спостерігаються при розгортанні. Наразі TAC не підтримує запити на створення нових користувацьких підписів. |
Для кращого управління шлюзами Cisco IOS XE ми рекомендуємо зареєструватися та керувати шлюзами через Control Hub. Це необов 'язкова конфігурація. Під час реєстрації ви можете використовувати параметр перевірки конфігурації в Центрі керування, щоб перевірити свою конфігурацію локального шлюзу та виявити будь-які проблеми з конфігурацією. В даний час тільки стовбури на основі реєстрації підтримують цю функціональність.
Для отримання додаткової інформації зверніться до наступного:
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою SIP-транка взаємного TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На наведеному нижче зображенні показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні. Надаються параметри для публічної або приватної (за NAT) адресації. Записи DNS SRV є необов’язковими, за винятком випадків балансування навантаження між кількома екземплярами CUBE.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі сертифікатів потрібні Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Essentials. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Для вимог високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і права на додаткову пропускну здатність.
Див Коди авторизації для отримання додаткової інформації.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
Списки ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4. Повні доменні імена локального шлюзу (FQDN) або адреси записів служби (SRV) повинні перетворюватися на загальнодоступну адресу IPv4 в інтернеті.
Усі SIP-порти й медіапорти на інтерфейсі локального шлюзу, зверненому до Webex, повинні бути доступні з інтернету безпосередньо або через статичний NAT. Переконайтеся, що ви відповідно оновили свій брандмауер.
Установіть підписаний сертифікат на локальний шлюз (нижче наведено докладні кроки налаштування).
Загальнодоступний центр сертифікації (CA), як детально описано в Які кореневі центри сертифікації підтримуються для викликів до аудіо- та відеоплатформ Cisco Webex? має підписати сертифікат пристрою.
Повне доменне ім’я, яке налаштовано в Control Hub під час створення транка, має бути сертифікатом Common Name (CN) або альтернативного імені суб’єкта (SAN) маршрутизатора. Наприклад:
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді CN або SAN у сертифікаті маршрутизатора має містити cube1.lgw.com.
Якщо налаштований транк у Control Hub вашої організації має lgws.lgw.com як адресу SRV локальних шлюзів, доступних із транка, тоді CN або SAN у сертифікаті маршрутизатора має містити lgws.lgw.com. Записи, які адреса SRV вирішує (CNAME, A Record або IP Address), є необов 'язковими в SAN.
Незалежно від того, чи використовуєте ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з вашого локального шлюзу використовує ім’я, налаштовану в Control Hub.
Переконайтеся, що сертифікати підписані для використання клієнтами та серверами.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче. | ||
| 3. | Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA). | ||
| 4. | Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:
| ||
| 5. | Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:
| ||
| 6. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:
| ||
| 7. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex.
| ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP Back to Back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. вхідні sip-профіліДозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto. | ||||
| 6. | Налаштуйте FIPS-сумісні шифри GCM (Цей крок застосовується лише для Webex для державних установ) . Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Задає GCM як набір шифрів, який пропонує CUBE. Налаштування шифрів GCM для локального шлюзу для Webex для державних установ є обов’язковим. | ||||
| 7. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка. | ||||
| 8 | Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а «198.51.100.1» — це загальнодоступна IP-адреса інтерфейсу локального шлюзу, що звернена до Webex Calling: Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв.
| ||||
| 9 | Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP наступним чином. У цьому прикладі cube1.lgw.com є повним доменом, налаштованим для локального шлюзу, «10.80.13.12» — це IP-адреса інтерфейсу, що звернена до Webex Calling, а «192.65.79.20» — це загальнодоступна IP-адреса NAT. SIP-профілі для вихідних повідомлень до Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. правила з 30 по 81Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingОсь пояснення полів для конфігурації: правила з 10 по 80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex. Докладніші відомості див. у розділі sip-профілі голосового класу. | ||||
| 10 | Налаштуйте параметри SIP для підтримки активності за допомогою профілю зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль Keepalive і входить в режим конфігурації голосового класу. Можна налаштувати час (у секундах), протягом якого SIP-відповідь «За межами діалогового вікна параметрів» надсилається об’єкту набору, коли контрольне підключення до кінцевої точки перебуває в стані UP або Down. Цей профіль підтримання активності запускається з точки набору, налаштованої на Webex. Щоб переконатися, що заголовки контактів включають повне доменне ім’я SBC, використовується профіль SIP 115. Правила 30, 40 і 50 є обов’язковими, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є FQDN, вибраним для локального шлюзу. Якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC для Webex Calling, а "192.65.79.20" є загальнодоступною IP-адресою NAT. . | ||||
| 11 | Налаштувати транк Webex Calling:
|
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 — до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. | ||
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:
Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. | ||
| 3. | Налаштуйте такі точки набору: | ||
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) активно виявляють поширені проблеми в локальному шлюзі на БАЗІ CISCO IOS XE і генерують повідомлення електронної пошти, системного журналу або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про події, що викликають проблему, та дії для інформування, усунення несправностей та усунення проблеми. Використовуйте повідомлення системного журналу, події SNMP та через періодичний моніторинг конкретних виходів команд Show для визначення логіки виявлення проблем. Типи дій включають:
Збирання виходів команди Show (Показати)
Створення консолідованого файлу журналу
Завантаження файлу в надане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та усунення різних проблем.
Перш ніж почати.
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається встановити через помилку перевірки цілісності.
Сервер SMTP (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням IOS XE 17.6.1 або вище, якщо ви хочете використовувати захищений SMTP-сервер для електронних повідомлень.
Передумови
Локальний шлюз під управлінням IOS XE 17.6.1 або вище
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо на пристрої встановлено IOS XE 17.6.1 або вище.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора, яку ви повідомляєте.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він відключає всі налагодження і видаляє всі діагностичні підписи, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
CUBE Enterprise в рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Наступний приклад показує копіювання файлу з FTP-сервера на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг аномальних відключень викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Ви також можете використовувати діагностичні підписи (DS) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних та автоматичної передачі даних до випадку Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, рекомендований інженером TAC як частину взаємодії з підтримкою.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" syslog та автоматизувати збір діагностичних даних, використовуючи наступні кроки:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях файлового сервера Cisco TAC (cxd.cisco.com) для завантаження діагностичних даних. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - маркер завантаження файлу, який можна отримати з Менеджера випадків підтримки, як показано нижче. Маркер завантаження файлу можна створити в розділі «Вкладення» Менеджера випадків підтримки, за необхідності.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endМи рекомендуємо встановити моніторинг високих процесорів DS 64224 як запобіжний захід для відключення всіх сигнатур налагодження та діагностики під час високої завантаженості процесора. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Встановіть високопродуктивний моніторинг процесора DS 64224, а потім файл DS 65095 XML в локальний шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому . У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди показати діагностичний підпис call-home змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, та виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
08.11.2020 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
08.11.2020 00:12:53 |
показати статистику діагностичного підпису виклику додому
Ідентифікатор DS | Ім’я DS | Запущено/Максимальна кількість/Видалення | Середній час виконання (секунди) | Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0/0/N |
0,000 |
0,000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23,053 |
23,053 |
Електронний лист сповіщення, який надсилається під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, деталі пристрою, версія програмного забезпечення, поточна конфігурація та показ виходів команд, які мають відношення до усунення заданої проблеми.
Видалення діагностичних підписів
Використовуйте діагностичні підписи для усунення несправностей, які зазвичай визначаються для видалення після виявлення деяких проблем. Якщо ви бажаєте видалити підпис вручну, отримайте ідентифікатор DS з виводу show call-home diagnostic-signature і виконайте наступну команду:
call-home diagnostic-signature deinstall <DS ID> Приклад:
call-home diagnostic-signature deinstall 64224
| Нові підписи періодично додаються до Інструменту пошуку підписів діагностики на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів. |
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
| Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v). |
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
| Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються. У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану |
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1. | Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||||||
| 2. | Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||||||
| 3. | Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Налаштуйте RG з попереднього кроку в розділі
redundancy-group 1: додавання та видалення цієї команди вимагає перезавантаження з метою застосування оновленої конфігурації. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||||||
| 4. | Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||||||
| 5. | Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||||||
| 6. | Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
Ім’я користувача: Hussain1076_LGU
Пароль: lOV12MEaZx
| 1. | Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем.
Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. Облікові дані SIP-дайджест-автентифікації від Control Hub виділено жирним шрифтом.
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2. | У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 показати стан реєстру sip-ua
З наведених вище даних виводу видно, що VCUBE-2 є активним локальним шлюзом, який підтримує реєстрацію в SBC доступу Webex Calling, тоді як вихідні дані параметра show sip-ua register status залишаються порожніми у VCUBE-1 |
| 3. | Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4. | Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2.
Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5. | Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6. | Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK».
|
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Увімкнути вхід для користувачів
| 1. | З поля зору клієнта в , перейдіть до Виклики > розташування.https://admin.webex.com |
| 2. | Виберіть користувача та клацніть Виклик . |
| 3. | Перейдіть до Дозволи між користувачами розділу, а потім виберіть Втрутитися . |
| 4. | Увімкніть перемикач, щоб дозволити іншим користувачам додавати себе до поточного виклику цього користувача. |
| 5. | Перевірте Відтворювати сигнал, коли цей користувач включається на виклик якщо ви хочете відтворювати сигнал іншим користувачам, коли цей користувач втручається на його виклик. |
| 6. | Клацніть Зберегти. |
Увімкнути конфіденційність для користувача
| 1. | Увійти в Control Hub , і перейдіть до . | ||
| 2. | Виберіть користувача та клацніть Виклик . | ||
| 3. | Перейдіть до Дозволи між користувачами область, а потім виберіть Конфіденційність . | ||
| 4. | Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
| ||
| 5. | Установіть прапорець Увімкнути конфіденційність. Потім ви можете заблокувати всіх, не вибираючи учасників із розкривного списку. Крім того, можна вибрати користувачів, робочі області та віртуальні лінії, які можуть відстежувати стан лінії цього користувача. Якщо ви адміністратор розташування, у розкривному списку відображатимуться лише користувачі, робочі області та віртуальні лінії, що належать до ваших призначених розташувань. Зніміть прапорець Увімкнути конфіденційність прапорець, щоб дозволити всім спостерігати за станом лінії. | ||
| 6. | Перевірте Забезпечте конфіденційність для спрямованого підхоплення викликів і входу прапорець, щоб увімкнути конфіденційність для спрямованого підхоплення викликів і вторгнення.
| ||
| 7. | Від Додати учасника за іменем , виберіть користувачів, робочі області та віртуальні лінії, які можуть відстежувати стан телефонної лінії та активувати спрямоване підхоплення та вхід виклику. | ||
| 8 | Щоб фільтрувати вибраних учасників, використовуйте фільтр за іменем, номером або внутр поле. | ||
| 9 | Клацніть Видалити все , щоб видалити всіх вибраних учасників.
| ||
| 10 | Клацніть Зберегти. |
Налаштуйте моніторинг
Максимальна кількість відстежуваних ліній для користувача становить 50. Однак під час налаштування списку моніторингу враховуйте кількість повідомлень, які впливають на пропускну здатність між Webex Calling і мережею. Також визначте максимальну кількість контрольованих ліній за кількістю кнопок ліній на телефоні користувача.
| 1. | З перегляду клієнта вhttps://admin.webex.com , перейдіть до Керування а потім клацніть Користувачі . | ||||
| 2. | Виберіть користувача, якого потрібно змінити, і натисніть Виклик. | ||||
| 3. | Перейти до Дозволи між користувачами і виберіть Моніторинг . | ||||
| 4. | Виберіть один із наведених далі варіантів.
Ви можете включити віртуальну лінію в Додати контрольовану лінію список для моніторингу користувачів. | ||||
| 5. | Виберіть, чи хочете ви сповіщати цього користувача про запарковані виклики, знайдіть особу або внутрішній номер для паркування викликів, які потрібно відстежити, а потім клацніть Зберегти .
|
Увімкнути попереджувальний сигнал мосту викликів для користувачів
Перш ніж почати
| 1. | Увійти в Control Hub , і перейдіть до . | ||
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. | ||
| 3. | Перейти до Дозволи між користувачами і клацніть Попереджувальний сигнал мосту викликів . | ||
| 4. | Увімкніть попереджувальний сигнал перемикання викликів, а потім натисніть Зберегти.
Додаткову інформацію про мости викликів на спільній лінії MPP див Спільні лінії на багатоплатформовому настільному телефоні . Додаткову інформацію про міст викликів на спільній лінії програми Webex див Вигляд спільної лінії для WebexApp . |
Увімкнення функції «Резервування ресурсів» для користувача
| 1. | У вікні клієнта перейдіть https://admin.webex.comдо розділу Керування та виберіть Користувачі. | ||
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. | ||
| 3. | Перейдіть до Дозволи між користувачами і виберіть Готелі і ввімкніть перемикач. | ||
| 4. | Введіть ім’я або номер організатора готелю в поле Розташування готелів поле пошуку та виберіть організатора, якого потрібно призначити користувачеві. Можна вибрати лише одного господаря готелю. Якщо ви виберете іншого господаря готелю, перший буде видалено.
| ||
| 5. | Щоб обмежити час, протягом якого користувач може бути пов’язаний із організатором готелів, виберіть кількість годин, протягом яких користувач може використовувати організатора готелів у списку Обмежений період асоціації розкривний список. Користувач автоматично вийде з системи через вибраний час.
| ||
| 6. | Клацніть Зберегти.
|
Перегляд звітів про виклики
На сторінці аналітики в Control Hub можна отримати відомості про те, як користувачі використовують Webex Calling і програму Webex (взаємодія), а також про якість мультимедіа викликів. Щоб отримати доступ до аналітики Webex Calling, увійдіть у Control Hub, перейдіть до розділу Аналітика й клацніть вкладку Виклики.
| 1. | Щоб отримати докладні звіти про історію дзвінків, увійдіть у Control Hub, а потім перейдіть до Аналітика > Виклики. |
| 2. | Виберіть Детальна історія викликів. Інформацію про виклики за допомогою виділеного екземпляра див. в розділі Аналітика виділеного екземпляра. |
| 3. | Щоб отримати доступ до даних про якість мультимедіа, увійдіть у Control Hub, перейдіть до розділу Аналітика й виберіть Виклики. Додаткову інформацію див. в статті Аналітика для вашого портфеля рішень щодо співпраці в хмарі.
|
Запустіть інструмент CScan
CScan — це інструмент перевірки готовності мережі, призначений для тестування підключення мережі до Webex Calling.
Додаткову інформацію див. в статті Використання CScan для тестування якості мережі Webex Calling. |
Загальні передумови
Перш ніж налаштувати локальний шлюз для Webex Calling , переконайтеся, що ви:
Базові знання принципів VoIP
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
Мати базові знання про протокол ініціації сеансу (SIP)
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Див Посібник із налаштування підприємства Cisco Unified Border Element (CUBE). для отримання додаткової інформації.
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Переконайтеся, що ваше розгортання має один або кілька локальних шлюзів, наприклад:
Cisco CUBE для підключення на основі IP
Шлюз Cisco IOS для підключення на основі TDM
Локальний шлюз допомагає перейти на Webex Calling у зручному для вас темпі. Локальний шлюз інтегрує ваше наявне локальне розгортання з Webex Calling. Ви також можете використовувати наявне підключення до ТМЗК. Див Почніть роботу з локальним шлюзом
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
Надходить запит облікових даних (наданих SIP-дайджестом)
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1. | Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте.
| ||
| 2. | Перегляньте й прийміть умови обслуговування. | ||
| 3. | Перегляньте план і клацніть Початок роботи.
| ||
| 4. | Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. | ||
| 5. | Клацніть Далі. Розміщення за замовчуванням. | ||
| 6. | Виберіть один із наведених далі варіантів.
| ||
| 7. | Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
| ||
| 8 | Клацніть Далі. | ||
| 9 | Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
Адреса розташування
Бажані номери телефону (необов’язково)
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку .
| ||||
| 2. | Налаштуйте параметри розташування.
| ||||
| 3. | Натисніть Зберегти, а потім виберіть Так/Ні, щоб додати номери до розташування зараз або пізніше. | ||||
| 4. | Якщо ви клацнули Додати зараз, виберіть один із наведених нижче параметрів.
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Щоб отримати допомогу, створіть запит до служби підтримки. | ||||
| 5. | Виберіть, чи потрібно активувати номери зараз або пізніше. | ||||
| 6. | Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. | ||||
| 7. | Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Перш ніж почати
| Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до розділу й в розкривному меню виберіть розташування, яке потрібно видалити. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори. Майте на увазі, що будь-які номери, пов 'язані з цим розташуванням, будуть повернуті вашому постачальнику послуг PSTN; ви більше не будете володіти цими номерами. |
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . |
| 2. | Клацніть |
| 3. | Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай потрібно кілька хвилин, щоб остаточно видалити розташування, але процес може тривати до однієї години. Щоб перевірити стан, можна клацнути |
Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
| Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling. |
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. | ||||||
| 2. | (Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
| ||||||
| 3. | Виберіть основний номер, за яким можна зв’язатися з основним контактом розташування. | ||||||
| 4. | (Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню.
| ||||||
| 5. | Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. | ||||||
| 6. | (Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти.
|
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. Коли ви змінюєте абонентську групу, приклади номерів у Control Hub оновіть, щоб відобразити ці зміни.
| Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки, щоб налаштувати дозволи на вихідні виклики. |
| 1. | Увійти в Control Hub , перейдіть до , а потім перейдіть до Внутрішній набір . | ||||||||
| 2. | За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
| ||||||||
| 3. | Налаштуйте внутрішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть внутрішній набір відповідно до:
| ||||||||
| 4. | Укажіть зовнішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть зовнішній набір відповідно до:
Вплив на користувачів.
|
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
| Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань. |
Перш ніж почати
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1. | Увійдіть до Центру керування на сторінці, перейдіть до розділу Послуги > Виклик > Маршрутизація викликів і виберіть Додати багажник.https://admin.webex.com | ||
| 2. | Виберіть розташування. | ||
| 3. | Укажіть ім’я транку й клацніть Зберегти.
|
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
| 1. | Увійдіть до Центру керування за адресоюhttps://admin.webex.com, перейдіть на сторінку . | ||
| 2. | Виберіть розташування, яке необхідно змінити, і клацніть Керування. | ||
| 3. | Виберіть PSTN на базі локальних ресурсів і клацніть Далі. | ||
| 4. | Виберіть транк у розкривному меню.
| ||
| 5. | Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). У цій статті розглянуто цей процес. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
Після успішного завершення конфігурації на самому шлюзі можна повернутися до розділу Служби > Виклик > Розташування в Control Hub. Створений вами шлюз буде відображено в призначеній йому картці розташування із зеленою крапкою ліворуч від імені. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
Якщо ви пробуєте сервіси Webex і хочете перетворити пробну версію на платну підписку, ви можете надіслати запит електронною поштою своєму партнеру.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , виберіть значок будівлі |
| 2. | Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
Ви можете використовувати Control Hub, щоб встановити пріоритет доступних опцій виклику, які користувачі бачать у додатку Webex. Ви також можете ввімкнути їх для одного натискання на виклик. Додаткову інформацію див. на сторінці Встановіть параметри виклику для користувачів Webex App.
Ви можете керувати тим, що додаток для викликів відкривається, коли користувачі здійснюють виклики. Ви можете налаштувати параметри клієнта виклику, включаючи розгортання в змішаному режимі для організацій з користувачами, які мають право на виклик Unified CM або Webex, і користувачами без платних послуг виклику від Cisco. Додаткову інформацію див. на сторінці Налаштуйте поведінку викликів .
Огляд
Зараз Webex Calling підтримує дві версії локального шлюзу:
Локальний шлюз
Локальний шлюз для Webex для державних установ
Перш ніж почати, ознайомтеся з вимогами до локальної комутованої телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Докладніші відомості див. у розділі Привілейована архітектура Cisco для викликів Webex.
Ця стаття припускає, що виділена платформа Local Gateway існує без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функції через внесені вами зміни.
| Процедури містять посилання на довідкову документацію команди, де ви можете дізнатися більше про окремі параметри команди. Всі посилання на команди звертаються до командного посилання керованого шлюзу Webex, якщо не вказано інше (в цьому випадку посилання на команди звертаються до голосового командного посилання Cisco IOS). Ви можете отримати доступ до всіх цих посібників у Cisco Unified Border Element Посилання на команду . Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту. |
Існує два варіанти налаштування локального шлюзу для багажника викликів Webex:
Багажник на основі реєстрації
Багажник на основі сертифікатів
Використовуйте потік завдань під локальним шлюзом на основі реєстрації або локальним шлюзом на основі сертифіката, щоб налаштувати локальний шлюз для магістралі викликів Webex.
Див. розділ Початок роботи з локальним шлюзом , щоб отримати додаткові відомості про різні типи магістралей. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортний захист транспортного рівня (TLS) для захисту багажника і безпечний протокол реального часу (SRTP) для захисту носіїв між локальним шлюзом і викликами Webex.
Виберіть CUBE як локальний шлюз. Webex для державних установ наразі не підтримує сторонні контролери кордону сеансів (SBC). Щоб переглянути останній список, див Почніть роботу з локальним шлюзом .
- Установіть Cisco IOS XE Dublin 17.12.1a або пізнішої версії для всіх локальних шлюзів Webex для державних установ.
Щоб переглянути список кореневих центрів сертифікації (CA), які підтримує Webex for Government, див Кореневі центри сертифікатів для Webex для державних установ .
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex для державних установ див Вимоги до мережі для Webex for Government (FedRAMP) .
Локальний шлюз для Webex для державних установ не підтримує такі можливості:
STUN/ICE-Lite для оптимізації шляху медіа
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex для державних установ, використовуйте такий параметр:
Багажник на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling. Докладніше про налаштування локального шлюзу на основі сертифіката див Налаштуйте транк Webex Calling на основі сертифіката .
Обов’язково потрібно налаштувати шифри GCM, що відповідають вимогам FIPS, для підтримки локального шлюзу для Webex для державних установ. Якщо ні, налаштування виклику не вдасться. Детальнішу інформацію про конфігурацію див Налаштуйте транк Webex Calling на основі сертифіката .
| Webex для державних установ не підтримує локальний шлюз на основі реєстрації. |
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі реєстрації потрібні Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
Списки ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.
| ||
| 3. | Створіть точку довіри PKI-заповнювач.
| ||
| 4. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації:
| ||
| 5. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex. | ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистику медіаВмикає моніторинг медіа на локальному шлюзі. медіа bulk-statsДозволяє площині керування опитати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див Медіа . дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP back-to-back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Для отримання додаткової інформації див. STUN flowdata agent-id та STUN flowdata shared-secret. асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto. | ||||
| 6. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див uri класу голосу . | ||||
| 7. | Налаштувати профіль sip 100 , який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
| ||||
| 8 | Налаштувати транк Webex Calling:
|
Після визначення клієнта 100 і налаштувати абонентську точку SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі SBC доступу представляє свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат SBC для доступу до Webex Calling за допомогою кореневого пакета CA, який було оновлено раніше. Якщо сертифікат розпізнано, між локальним шлюзом і SBC для доступу до Webex Calling буде встановлено постійний сеанс TLS. Після цього локальний шлюз зможе використовувати це безпечне з’єднання для реєстрації в SBC для доступу до Webex. Коли реєстрацію оскаржують для автентифікації:
, ім’я користувача, пароль, і області параметри з облікові дані конфігурація використовується у відповіді.
Правила модифікації в профілі 100 sip використовуються для перетворення SIPS URL назад у SIP.
Реєстрація буде успішною після отримання 200 OK від SBC доступу.
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 — до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
| Під час створення транка Webex Calling в Unified CM переконайтеся, що ви налаштували вхідний порт у параметрах профілю безпеки транка SIP на 5065. Це дозволяє вхідні повідомлення через порт 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу. |
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. | ||
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:
Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. | ||
| 3. | Налаштуйте такі точки набору: | ||
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) активно виявляють поширені проблеми в локальному шлюзі на БАЗІ IOS XE і генерують повідомлення електронної пошти, системного журналу або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це файли XML, які містять інформацію про події, що викликають проблему, і дії, які необхідно виконати для інформування, усунення несправностей та усунення проблеми. Можна визначити логіку виявлення проблем за допомогою повідомлень системного журналу, подій SNMP і за допомогою періодичного моніторингу конкретних виводів команд show.
Типи дій включають збирання виходів команди show:
Створення консолідованого файлу журналу
Передавання файлу в надане користувачем мережеве розташування, як-от HTTPS, SCP, FTP-сервер.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та усунення різних проблем.
Перш ніж почати.
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається встановити через помилку перевірки цілісності.
Сервер SMTP (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням IOS XE 17.6.1 або вище, якщо ви хочете використовувати захищений SMTP-сервер для електронних повідомлень.
Передумови
Локальний шлюз під керуванням IOS XE 17.6.1a або новішої версії
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти для надсилання проактивних сповіщень, якщо на пристрої встановлено Cisco IOS XE 17.6.1a або новішої версії.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора, щоб сповістити вас.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Далі наведено приклад конфігурації локального шлюзу, що працює на Cisco IOS XE 17.6.1a або пізнішої версії для надсилання проактивних сповіщень на tacfaststart@gmail.com використання Gmail як захищеного сервера SMTP:
| Ми рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або пізнішої версії. |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com" | Локальний шлюз, що працює на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати конкретне налаштування облікового запису Gmail та надати конкретний дозвіл на правильну обробку електронної пошти з пристрою: |
Перейти до і ввімкніть Менш безпечний доступ до програми налаштування.
Відповідь "Так, це був я", коли ви отримуєте електронний лист від Gmail про те, що "Google заборонив комусь увійти у ваш обліковий запис, використовуючи додаток, що не належить Google".
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP версії 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він відключає всі налагодження та видаляє всі діагностичні підписи, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб увімкнути SNMP. Якщо не ввімкнути, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Наступний приклад показує копіювання файлу з FTP-сервера на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання ЦП на локальному шлюзі.
Моніторинг реєстрації SIP багажника
Цей DS перевіряє наявність незареєстрованого локального шлюзу SIP Trunk з хмарою Webex Calling кожні 60 секунд. Після виявлення події скасування реєстрації він генерує повідомлення електронної пошти та системного журналу та видаляє себе після двох випадків скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
Скасування реєстрації SIP Trunk з повідомленням електронної пошти.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#Використовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Моніторинг аномальних відключень викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб перевірити, чи ввімкнено SNMP. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
Встановлення діагностичних підписів для усунення несправностей
Використовуйте діагностичні підписи (ДП) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних та автоматичної передачі даних до випадку Cisco TAC. Діагностичні підписи (DS) усувають необхідність вручну перевіряти виникнення проблеми та значно спрощують усунення періодичних і тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, рекомендований інженером TAC як частину взаємодії з підтримкою.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" syslog та автоматизувати збір діагностичних даних, використовуючи наступні кроки:
Налаштуйте додаткову змінну середовища DS, ds_fsurl_prefix яка є шляхом файлового сервера Cisco TAC (cxd.cisco.com), до якого завантажуються зібрані діагностичні дані. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - це маркер завантаження файлу, який можна отримати з Support Case Manager за допомогою наступної команди. Маркер передавання файлу можна створити в розділі Вкладення диспетчера запитів до служби підтримки за потреби.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endЗабезпечити встановлення моніторингу високого ЦП DS 64224 як запобіжного заходу для відключення всіх сигнатур налагодження та діагностики під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою команди show call-home diagnostic-signature. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди show call-home diagnostic-signature змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, і виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0.0.10 | Зареєстровано | 2020-11-08 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | Виконується | 2020-11-08 00:12:53 |
показати статистику діагностичного підпису виклику додому
Ідентифікатор DS | Ім’я DS | Запущено/Максимальна кількість/Видалення | Середній час виконання (секунди) | Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 | 0/0/N | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23.053 | 23.053 |
Електронний лист сповіщення, який надсилається під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версія програмного забезпечення, поточна конфігурація та показ виходів команд, які мають відношення до усунення заданої проблеми.
Видалення діагностичних підписів
Використання діагностичних підписів для усунення несправностей зазвичай визначається для видалення після виявлення деяких проблемних випадків. Якщо потрібно видалити підпис вручну, отримайте ідентифікатор DS із виводу файлу показати підпис діагностики виклику додому і виконайте таку команду:
call-home diagnostic-signature deinstall <DS ID>
Приклад:
call-home diagnostic-signature deinstall 64224
| Нові підписи додаються до інструменту пошуку підписів діагностики періодично, на основі проблем, які зазвичай спостерігаються при розгортанні. Наразі TAC не підтримує запити на створення нових користувацьких підписів. |
Для кращого управління шлюзами Cisco IOS XE ми рекомендуємо зареєструватися та керувати шлюзами через Control Hub. Це необов 'язкова конфігурація. Під час реєстрації ви можете використовувати параметр перевірки конфігурації в Центрі керування, щоб перевірити свою конфігурацію локального шлюзу та виявити будь-які проблеми з конфігурацією. В даний час тільки стовбури на основі реєстрації підтримують цю функціональність.
Для отримання додаткової інформації зверніться до наступного:
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою SIP-транка взаємного TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На наведеному нижче зображенні показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні. Надаються параметри для публічної або приватної (за NAT) адресації. Записи DNS SRV є необов’язковими, за винятком випадків балансування навантаження між кількома екземплярами CUBE.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі сертифікатів потрібні Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Essentials. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Для вимог високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і права на додаткову пропускну здатність.
Див Коди авторизації для отримання додаткової інформації.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
Списки ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4. Повні доменні імена локального шлюзу (FQDN) або адреси записів служби (SRV) повинні перетворюватися на загальнодоступну адресу IPv4 в інтернеті.
Усі SIP-порти й медіапорти на інтерфейсі локального шлюзу, зверненому до Webex, повинні бути доступні з інтернету безпосередньо або через статичний NAT. Переконайтеся, що ви відповідно оновили свій брандмауер.
Установіть підписаний сертифікат на локальний шлюз (нижче наведено докладні кроки налаштування).
Загальнодоступний центр сертифікації (CA), як детально описано в Які кореневі центри сертифікації підтримуються для викликів до аудіо- та відеоплатформ Cisco Webex? має підписати сертифікат пристрою.
Повне доменне ім’я, яке налаштовано в Control Hub під час створення транка, має бути сертифікатом Common Name (CN) або альтернативного імені суб’єкта (SAN) маршрутизатора. Наприклад:
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді CN або SAN у сертифікаті маршрутизатора має містити cube1.lgw.com.
Якщо налаштований транк у Control Hub вашої організації має lgws.lgw.com як адресу SRV локальних шлюзів, доступних із транка, тоді CN або SAN у сертифікаті маршрутизатора має містити lgws.lgw.com. Записи, які адреса SRV вирішує (CNAME, A Record або IP Address), є необов 'язковими в SAN.
Незалежно від того, чи використовуєте ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з вашого локального шлюзу використовує ім’я, налаштовану в Control Hub.
Переконайтеся, що сертифікати підписані для використання клієнтами та серверами.
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
| ||
| 2. | Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче. | ||
| 3. | Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA). | ||
| 4. | Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:
| ||
| 5. | Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:
| ||
| 6. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:
| ||
| 7. | Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів:
|
| 1. | Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Для отримання додаткової інформації див. розділ Налаштування стовбурів, груп маршрутів та планів набору для викликів Webex.
| ||||
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP Back to Back. Докладніші відомості див. у розділі Дозволити з 'єднання.
Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Для отримання додаткової інформації про цю команду див. Асиметричне корисне навантаження. вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Для отримання додаткової інформації про цю команду див. Рання пропозиція. вхідні sip-профіліДозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів. | ||||
| 3. | Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Для отримання додаткової інформації дивіться кодекголосового класу.
| ||||
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: оглушення використання лід liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Для отримання додаткової інформації див. Використання голосового класу STUN та використання STUN Ice Lite.
| ||||
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Для отримання додаткової інформації див. Голосовий клас srtp-crypto. | ||||
| 6. | Налаштуйте FIPS-сумісні шифри GCM (Цей крок застосовується лише для Webex для державних установ) . Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Задає GCM як набір шифрів, який пропонує CUBE. Налаштування шифрів GCM для локального шлюзу для Webex для державних установ є обов’язковим. | ||||
| 7. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка. | ||||
| 8 | Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а «198.51.100.1» — це загальнодоступна IP-адреса інтерфейсу локального шлюзу, що звернена до Webex Calling: Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв.
| ||||
| 9 | Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP наступним чином. У цьому прикладі cube1.lgw.com є повним доменом, налаштованим для локального шлюзу, «10.80.13.12» — це IP-адреса інтерфейсу, що звернена до Webex Calling, а «192.65.79.20» — це загальнодоступна IP-адреса NAT. SIP-профілі для вихідних повідомлень до Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. правила з 30 по 81Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingОсь пояснення полів для конфігурації: правила з 10 по 80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex. Докладніші відомості див. у розділі sip-профілі голосового класу. | ||||
| 10 | Налаштуйте параметри SIP для підтримки активності за допомогою профілю зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль Keepalive і входить в режим конфігурації голосового класу. Можна налаштувати час (у секундах), протягом якого SIP-відповідь «За межами діалогового вікна параметрів» надсилається об’єкту набору, коли контрольне підключення до кінцевої точки перебуває в стані UP або Down. Цей профіль підтримання активності запускається з точки набору, налаштованої на Webex. Щоб переконатися, що заголовки контактів включають повне доменне ім’я SBC, використовується профіль SIP 115. Правила 30, 40 і 50 є обов’язковими, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є FQDN, вибраним для локального шлюзу. Якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC для Webex Calling, а "192.65.79.20" є загальнодоступною IP-адресою NAT. . | ||||
| 11 | Налаштувати транк Webex Calling:
|
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
| Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів. |
| Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI . |
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає VoIP-пір з тегом 300 і дає змістовний опис для простоти управління та усунення несправностей. Докладніші відомості див. у розділі «Голос, що набирається одноранговим набором». призначення-шаблон BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Для отримання додаткової інформації див. розділ призначення-шаблон (інтерфейс). протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Докладніші відомості див. у розділі Протокол сеансу (вузол набору). ціль сеансу ipv4:192.168.80.13Вказує цільову адресу IPv4 призначення для надсилання етапу виклику. Метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності для заголовка VIA з IP-адресою IP PSTN. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Для отримання додаткової інформації див. Кодек голосового класу. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на етапі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 — до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. | ||
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM:
Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. | ||
| 3. | Налаштуйте такі точки набору: | ||
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) активно виявляють поширені проблеми в локальному шлюзі на БАЗІ CISCO IOS XE і генерують повідомлення електронної пошти, системного журналу або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про події, що викликають проблему, та дії для інформування, усунення несправностей та усунення проблеми. Використовуйте повідомлення системного журналу, події SNMP та через періодичний моніторинг конкретних виходів команд Show для визначення логіки виявлення проблем. Типи дій включають:
Збирання виходів команди Show (Показати)
Створення консолідованого файлу журналу
Завантаження файлу в надане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та усунення різних проблем.
Перш ніж почати.
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається встановити через помилку перевірки цілісності.
Сервер SMTP (Simple Mail Transfer Protocol), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що локальний шлюз працює під управлінням IOS XE 17.6.1 або вище, якщо ви хочете використовувати захищений SMTP-сервер для електронних повідомлень.
Передумови
Локальний шлюз під управлінням IOS XE 17.6.1 або вище
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо на пристрої встановлено IOS XE 17.6.1 або вище.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора, яку ви повідомляєте.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Встановлення діагностичних підписів для проактивного моніторингу
Моніторинг високого використання ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він відключає всі налагодження і видаляє всі діагностичні підписи, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
CUBE Enterprise в рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Наступний приклад показує копіювання файлу з FTP-сервера на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. Стовпець статусу повинен мати «зареєстроване» значення.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг аномальних відключень викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, він генерує сповіщення системного журналу та електронної пошти. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення аномального виклику SIP з електронною поштою та сповіщенням Syslog.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду show call-home diagnostic-signature, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Ви також можете використовувати діагностичні підписи (DS) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних та автоматичної передачі даних до випадку Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, рекомендований інженером TAC як частину взаємодії з підтримкою.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" syslog та автоматизувати збір діагностичних даних, використовуючи наступні кроки:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях файлового сервера Cisco TAC (cxd.cisco.com) для завантаження діагностичних даних. Ім 'я користувача в шляху до файлу - це номер справи, а пароль - маркер завантаження файлу, який можна отримати з Менеджера випадків підтримки, як показано нижче. Маркер завантаження файлу можна створити в розділі «Вкладення» Менеджера випадків підтримки, за необхідності.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endМи рекомендуємо встановити моніторинг високих процесорів DS 64224 як запобіжний захід для відключення всіх сигнатур налагодження та діагностики під час високої завантаженості процесора. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання процесора з повідомленням електронної пошти.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Встановіть високопродуктивний моніторинг процесора DS 64224, а потім файл DS 65095 XML в локальний шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому . У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець «Статус» команди показати діагностичний підпис call-home змінюється на «працює», поки локальний шлюз виконує дію, визначену в підписі. Вивід статистики діагностичного підпису show call-home є найкращим способом перевірки того, чи виявляє діагностичний підпис подію, що представляє інтерес, та виконує дію. У стовпці «Тригеризований/Макс/Деінсталяція» вказується кількість разів, коли даний підпис викликав подію, максимальна кількість разів, коли він визначається для виявлення події, і чи видаляється сам підпис після виявлення максимальної кількості викликаних подій.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
Ідентифікатор DS | Ім’я DS | Редакція | Стан | Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
показати статистику діагностичного підпису виклику додому
Ідентифікатор DS | Ім’я DS | Запущено/Максимальна кількість/Видалення | Середній час виконання (секунди) | Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 | DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Електронний лист сповіщення, який надсилається під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, деталі пристрою, версія програмного забезпечення, поточна конфігурація та показ виходів команд, які мають відношення до усунення заданої проблеми.
Видалення діагностичних підписів
Використовуйте діагностичні підписи для усунення несправностей, які зазвичай визначаються для видалення після виявлення деяких проблем. Якщо ви бажаєте видалити підпис вручну, отримайте ідентифікатор DS з виводу show call-home diagnostic-signature і виконайте наступну команду:
call-home diagnostic-signature deinstall <DS ID> Приклад:
call-home diagnostic-signature deinstall 64224
| Нові підписи періодично додаються до Інструменту пошуку підписів діагностики на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів. |
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
| Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v). |
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
| Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються. У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану |
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1. | Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||||||
| 2. | Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||||||
| 3. | Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Налаштуйте RG з попереднього кроку в розділі
redundancy-group 1: додавання та видалення цієї команди вимагає перезавантаження з метою застосування оновленої конфігурації. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||||||
| 4. | Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||||||
| 5. | Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||||||
| 6. | Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
Ім’я користувача: Hussain1076_LGU
Пароль: lOV12MEaZx
| 1. | Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем.
Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. Облікові дані SIP-дайджест-автентифікації від Control Hub виділено жирним шрифтом.
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2. | У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 показати стан реєстру sip-ua
З наведених вище даних виводу видно, що VCUBE-2 є активним локальним шлюзом, який підтримує реєстрацію в SBC доступу Webex Calling, тоді як вихідні дані параметра show sip-ua register status залишаються порожніми у VCUBE-1 |
| 3. | Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4. | Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2.
Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5. | Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6. | Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK».
|
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Увімкнути вхід для користувачів
| 1. | З поля зору клієнта в , перейдіть до Виклики > розташування.https://admin.webex.com |
| 2. | Виберіть користувача та клацніть Виклик . |
| 3. | Перейдіть до Дозволи між користувачами розділу, а потім виберіть Втрутитися . |
| 4. | Увімкніть перемикач, щоб дозволити іншим користувачам додавати себе до поточного виклику цього користувача. |
| 5. | Перевірте Відтворювати сигнал, коли цей користувач включається на виклик якщо ви хочете відтворювати сигнал іншим користувачам, коли цей користувач втручається на його виклик. |
| 6. | Клацніть Зберегти. |
Увімкнути конфіденційність для користувача
| 1. | Увійти в Control Hub , і перейдіть до . | ||
| 2. | Виберіть користувача та клацніть Виклик . | ||
| 3. | Перейдіть до Дозволи між користувачами область, а потім виберіть Конфіденційність . | ||
| 4. | Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
| ||
| 5. | Установіть прапорець Увімкнути конфіденційність. Потім ви можете заблокувати всіх, не вибираючи учасників із розкривного списку. Крім того, можна вибрати користувачів, робочі області та віртуальні лінії, які можуть відстежувати стан лінії цього користувача. Якщо ви адміністратор розташування, у розкривному списку відображатимуться лише користувачі, робочі області та віртуальні лінії, що належать до ваших призначених розташувань. Зніміть прапорець Увімкнути конфіденційність прапорець, щоб дозволити всім спостерігати за станом лінії. | ||
| 6. | Перевірте Забезпечте конфіденційність для спрямованого підхоплення викликів і входу прапорець, щоб увімкнути конфіденційність для спрямованого підхоплення викликів і вторгнення.
| ||
| 7. | Від Додати учасника за іменем , виберіть користувачів, робочі області та віртуальні лінії, які можуть відстежувати стан телефонної лінії та активувати спрямоване підхоплення та вхід виклику. | ||
| 8 | Щоб фільтрувати вибраних учасників, використовуйте фільтр за іменем, номером або внутр поле. | ||
| 9 | Клацніть Видалити все , щоб видалити всіх вибраних учасників.
| ||
| 10 | Клацніть Зберегти. |
Налаштуйте моніторинг
Максимальна кількість відстежуваних ліній для користувача становить 50. Однак під час налаштування списку моніторингу враховуйте кількість повідомлень, які впливають на пропускну здатність між Webex Calling і мережею. Також визначте максимальну кількість контрольованих ліній за кількістю кнопок ліній на телефоні користувача.
| 1. | З перегляду клієнта вhttps://admin.webex.com , перейдіть до Керування а потім клацніть Користувачі . | ||||
| 2. | Виберіть користувача, якого потрібно змінити, і натисніть Виклик. | ||||
| 3. | Перейти до Дозволи між користувачами і виберіть Моніторинг . | ||||
| 4. | Виберіть один із наведених далі варіантів.
Ви можете включити віртуальну лінію в Додати контрольовану лінію список для моніторингу користувачів. | ||||
| 5. | Виберіть, чи хочете ви сповіщати цього користувача про запарковані виклики, знайдіть особу або внутрішній номер для паркування викликів, які потрібно відстежити, а потім клацніть Зберегти .
|
Увімкнути попереджувальний сигнал мосту викликів для користувачів
Перш ніж почати
| 1. | Увійти в Control Hub , і перейдіть до . | ||
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. | ||
| 3. | Перейти до Дозволи між користувачами і клацніть Попереджувальний сигнал мосту викликів . | ||
| 4. | Увімкніть попереджувальний сигнал перемикання викликів, а потім натисніть Зберегти.
Додаткову інформацію про мости викликів на спільній лінії MPP див Спільні лінії на багатоплатформовому настільному телефоні . Додаткову інформацію про міст викликів на спільній лінії програми Webex див Вигляд спільної лінії для WebexApp . |
Увімкнення функції «Резервування ресурсів» для користувача
| 1. | У вікні клієнта перейдіть https://admin.webex.comдо розділу Керування та виберіть Користувачі. | ||
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. | ||
| 3. | Перейдіть до Дозволи між користувачами і виберіть Готелі і ввімкніть перемикач. | ||
| 4. | Введіть ім’я або номер організатора готелю в поле Розташування готелів поле пошуку та виберіть організатора, якого потрібно призначити користувачеві. Можна вибрати лише одного господаря готелю. Якщо ви виберете іншого господаря готелю, перший буде видалено.
| ||
| 5. | Щоб обмежити час, протягом якого користувач може бути пов’язаний із організатором готелів, виберіть кількість годин, протягом яких користувач може використовувати організатора готелів у списку Обмежений період асоціації розкривний список. Користувач автоматично вийде з системи через вибраний час.
| ||
| 6. | Клацніть Зберегти.
|
Перегляд звітів про виклики
На сторінці аналітики в Control Hub можна отримати відомості про те, як користувачі використовують Webex Calling і програму Webex (взаємодія), а також про якість мультимедіа викликів. Щоб отримати доступ до аналітики Webex Calling, увійдіть у Control Hub, перейдіть до розділу Аналітика й клацніть вкладку Виклики.
| 1. | Щоб отримати докладні звіти про історію дзвінків, увійдіть у Control Hub, а потім перейдіть до Аналітика > Виклики. |
| 2. | Виберіть Детальна історія викликів. Інформацію про виклики за допомогою виділеного екземпляра див. в розділі Аналітика виділеного екземпляра. |
| 3. | Щоб отримати доступ до даних про якість мультимедіа, увійдіть у Control Hub, перейдіть до розділу Аналітика й виберіть Виклики. Додаткову інформацію див. в статті Аналітика для вашого портфеля рішень щодо співпраці в хмарі.
|
Запустіть інструмент CScan
CScan — це інструмент перевірки готовності мережі, призначений для тестування підключення мережі до Webex Calling.
Додаткову інформацію див. в статті Використання CScan для тестування якості мережі Webex Calling. |
Підготовка середовища
General prerequisites
Before you configure a local gateway for Webex Calling, ensure that you:
-
Базові знання принципів VoIP
-
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
-
Have a basic understanding of the Session Initiation Protocol (SIP)
-
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
See the Cisco Unified Border Element (CUBE) Enterprise Configuration Guide for details.
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Make sure that your deployment has one or more of the local gateways, such as:
-
Cisco CUBE for IP-based connectivity
-
Cisco IOS Gateway for TDM-based connectivity
The local gateway helps you migrate to Webex Calling at your own pace. The local gateway integrates your existing on-premises deployment with Webex Calling. You can also use your existing PSTN connection. See Get started with Local Gateway
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
-
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
-
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
-
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
-
Надходить запит облікових даних (наданих SIP-дайджестом)
-
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Налаштування Webex Calling для організації
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1 |
Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте. Ваша адреса електронної пошти адміністратора автоматично використовується для входу в Control Hub, де вам буде запропоновано створити пароль адміністратора. Після входу майстер налаштування буде запущено автоматично. |
| 2 |
Перегляньте й прийміть умови обслуговування. |
| 3 |
Перегляньте план і клацніть Початок роботи. За перші кроки з активації з використанням майстра першого встановлення відповідає ваш менеджер із роботи з клієнтами. У разі отримання сповіщення «Не вдалося налаштувати виклик» після натискання кнопки Початок роботи зверніться до менеджера із роботи з клієнтами. |
| 4 |
Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. |
| 5 |
Клацніть Далі. Розміщення за замовчуванням. |
| 6 |
Виберіть один із наведених далі варіантів.
Після завершення роботи майстра встановлення упевніться, що ви додаєте основний номер до створеного розташування. |
| 7 |
Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
|
| 8 |
Клацніть Далі. |
| 9 |
Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
-
Адреса розташування
-
Бажані номери телефону (необов’язково)
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . A new location will be hosted in the regional data center that corresponds to the country you selected using the First Time Setup Wizard. |
| 2 |
Налаштуйте параметри розташування.
|
| 3 |
Натисніть кнопку Зберегти , а потім виберіть так / ні , щоб додати номери до розташування зараз або пізніше. |
| 4 |
Якщо ви натиснули кнопку Так, виберіть один із наступних параметрів:
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Open a support case for guidance. |
| 5 |
Виберіть, чи потрібно активувати номери зараз або пізніше. |
| 6 |
Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. |
| 7 |
Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Перш ніж почати
Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до розділу й в розкривному меню виберіть розташування, яке потрібно видалити. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори.
Keep in mind that any numbers associated with this location will be released back to your PSTN provider; you'll no longer own those numbers.
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . |
| 2 |
Click |
| 3 |
Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай потрібно кілька хвилин, щоб остаточно видалити розташування, але процес може тривати до однієї години. Щоб перевірити стан, можна клацнути |
Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
| 1 |
Log in to the Control Hub at https://admin.webex.com, go to . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. |
| 2 |
(Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
|
| 3 |
For the location, select the Main Number from the drop-down list to enable users in that location to make and receive calls. The Main Number can be assigned to the auto attendant so that the external callers can contact Webex Calling users at that location. Webex Calling users in that location can also use this number as their external caller ID when making calls. |
| 4 |
(Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню. Це налаштування необов’язкове й застосовується лише для країн, які цього потребують. У деяких країнах (як-от Франція), існують нормативні вимоги до стільникових радіосистем із метою встановлення ідентифікатора стільникового зв’язку під час здійснення екстреного виклику й надання до них доступу екстреним службам. Other countries like the U.S and Canada implement location determination using other methods. Додаткову інформацію див. в статті Розширені екстрені виклики. Вашому постачальнику екстрених викликів може знадобитися інформація про мережу доступу, яка досягається шляхом визначення нового заголовка приватного розширення SIP (P-Access-Network-Info). Заголовок містить інформацію, пов’язану з мережею доступу. У разі налаштування ідентифікатора місця надзвичайної ситуації для розташування значення розташування надсилається постачальнику як частина повідомлення SIP. Зверніться до свого постачальника екстрених викликів, щоб дізнатися, чи потрібне вам це налаштування, і використовуйте значення, яке надав ваш постачальник екстрених викликів. |
| 5 |
Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. |
| 6 |
(Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти. Зміна параметра Мова оголошень набуває чинності негайно для всіх нових користувачів і функцій, доданих до цього розташування. Якщо для наявних користувачів і/або функцій також потрібно змінити мову оголошень, коли з’явиться запит, виберіть Змінити для наявних користувачів і робочих просторів або Змінити для наявних функцій. Клацніть Застосувати. Перебіг виконання можна переглянути на сторінці Завдання. Поки це налаштування не буде завершено, внести інші зміни буде неможливо. У разі змінювання часового поясу для розташування не буде оновлено часові пояси функцій, пов’язаних із розташуванням. Щоб змінити часові пояси для таких функцій, як автосекретар, група пошуку й черга викликів, перейдіть до області Загальні налаштування певної функції, для якої потрібно оновити часовий пояс, змініть налаштування там і збережіть їх. |
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. As you change your dial plan, the example numbers in the Control Hub update to show these changes.
Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки, щоб налаштувати дозволи на вихідні виклики.
| 1 |
Sign in to Control Hub, go to , and then scroll to Internal Dialing. |
| 2 |
За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
|
| 3 |
Налаштуйте внутрішній набір для певних розташувань. Go to , select a location from the list, and click Calling. Scroll to Dialing, and then change internal dialing as needed:
|
| 4 |
Specify external dialing for specific locations. Go to , select a location from the list, and click Calling. Scroll to Dialing, and then change external dialing as needed:
Вплив на користувачів.
|
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань.
Перш ніж почати
-
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
-
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
-
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
-
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1 |
Log in to Control Hub at https://admin.webex.com, go to , and select Add Trunk. |
| 2 |
Виберіть розташування. |
| 3 |
Укажіть ім’я транку й клацніть Зберегти. Довжина імені не може перевищувати 24 символи. |
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . |
| 2 |
Виберіть розташування, яке необхідно змінити, і клацніть Керування. |
| 3 |
Виберіть PSTN на базі локальних ресурсів і клацніть Далі. |
| 4 |
Виберіть транк у розкривному меню. Перейдіть на сторінку транку, щоб керувати параметрами транкової групи. |
| 5 |
Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). This article walks you through this process. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
After you successfully complete the configuration on the gateway itself, you can return to in Control Hub and the gateway that you created will be listed in the location card that you assigned it to with a green dot to the left of the name. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
If you're trying out Webex services and you'd like to convert your trial to a paid subscription, you can submit an email request to your partner.
| 1 |
Log in to Control Hub at https://admin.webex.com, select the building icon |
| 2 |
Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
You can use Control Hub to set the priority of available calling options that users see in Webex App. You can also enable them for single click-to-call. Додаткову інформацію див. на сторінці Set calling options for Webex App users.
You can control what calling application opens when users make calls. You can configure the calling client settings, including mixed-mode deployment for organizations with users entitled with Unified CM or Webex Calling and users without paid calling services from Cisco. Додаткову інформацію див. на сторінці Set up calling behavior.
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Огляд
Webex Calling currently supports two versions of Local Gateway:
-
Локальний шлюз
-
Local Gateway for Webex for Government
-
Before you begin, understand the premises-based Public Switched Telephone Network (PSTN) and Local Gateway (LGW) requirements for Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. If you modify an existing PSTN gateway or CUBE Enterprise deployment to use as the Local Gateway function for Webex Calling, then pay careful attention to the configuration. Ensure that you don't interrupt the existing call flows and functionality because of the changes that you make.
For information on the supported third-party SBCs, refer to the respective product reference documentation.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Use the task flow either under the Registration-based Local Gateway or Certificate-based Local Gateway to configure Local Gateway for your Webex Calling trunk.
See Get started with Local Gateway for more information on different trunk types. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). We use Session Initiation Protocol (SIP) and Transport Layer Security (TLS) transport to secure the trunk and Secure Real Time Protocol (SRTP) to secure the media between the Local Gateway and Webex Calling.
-
Select CUBE as your Local Gateway. Webex for Government doesn’t currently support any third-party Session Border Controllers (SBCs). To review the latest list, see Get started with Local Gateway.
- Install Cisco IOS XE Dublin 17.12.1a or later versions for all Webex for Government Local Gateways.
-
To review the list of root Certificate Authorities (CAs) that Webex for Government support, see Root certificate authorities for Webex for Government.
-
For details on the external port ranges for Local Gateway in Webex for Government, see Network requirements for Webex for Government (FedRAMP).
Local Gateway for Webex for Government doesn’t support the following:
-
STUN/ICE-Lite for media path optimization
-
Fax (T.38)
To configure Local Gateway for your Webex Calling trunk in Webex for Government, use the following option:
-
Магістраль на основі сертифікатів
Use the task flow under the Certificate-based Local Gateway to configure the Local Gateway for your Webex Calling trunk. For more details on how to configure a certificate-based Local Gateway, see Configure Webex Calling certificate-based trunk.
It’s mandatory to configure FIPS-compliant GCM ciphers to support Local Gateway for Webex for Government. If not, the call setup fails. For configuration details, see Configure Webex Calling certificate-based trunk.
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using a registering SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The image below highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Крок 1: Configure router baseline connectivity and security
-
Крок 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Крок 3: Configure Local Gateway with SIP PSTN trunk
-
Крок 4: Configure Local Gateway with existing Unified CM environment
Or:
-
Крок 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All registration-based Local Gateway deployments require Cisco IOS XE 17.6.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Advantage licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
ACLs
-
User authentication and remote access
-
DNS
-
IP-маршрутизація
-
IP addresses
-
-
The network toward Webex Calling must use an IPv4 address.
-
Upload the Cisco root CA bundle to the Local Gateway.
Конфігурація
| 1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
| 2 |
Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:
|
| 3 |
Create a placeholder PKI trustpoint. Requires this trustpoint to configure TLS later. For registration-based trunks, this trustpoint doesn't require a certificate - as would be required for a certificate-based trunk. |
| 4 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands. Transport parameters should also be updated to ensure a reliable secure connection for registration: The cn-san-validate server command ensures that the Local Gateway permits a connection if the host name configured in tenant 200 is included in either the CN or SAN fields of the certificate received from the outbound proxy.
|
| 5 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
| 1 |
Create a registration based PSTN trunk for an existing location in Control Hub. Make a note of the trunk information that is provided once the trunk has been created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. |
| 2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Ось пояснення полів для конфігурації:
Enables Cisco Unified Border Element (CUBE) features on the platform. media statisticsЗабезпечує моніторинг медіафайлів на локальному шлюзі. media bulk-statsДозволяє площині управління опитувати площину даних для статистики масових викликів. For more information on these commands, see Media. allow-connections sip to sipEnable CUBE basic SIP back-to-back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. |
| 3 |
Configure voice class codec 100 filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Ось пояснення полів для конфігурації: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
| 4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. Ось пояснення полів для конфігурації: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams |
| 5 |
Configure the media encryption policy for Webex traffic. Ось пояснення полів для конфігурації: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
| 6 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination trunk parameter: Ось пояснення полів для конфігурації: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use dtg= followed by the Trunk OTG/DTG value provided in Control Hub when the trunk was created. For more information, see voice class uri. |
| 7 |
Configure sip profile 100, which will be used to modify SIP messages before they are sent to Webex Calling.
Ось пояснення полів для конфігурації:
|
| 8 |
Configure Webex Calling trunk: |
After you define tenant 100 and configure a SIP VoIP dial-peer, the gateway initiates a TLS connection toward Webex Calling. At this point the access SBC presents its certificate to the Local Gateway. The Local Gateway validates the Webex Calling access SBC certificate using the CA root bundle that was updated earlier. If the certificate is recognised, a persistent TLS session is established between the Local Gateway and Webex Calling access SBC. The Local Gateway is then able to use this secure connection to register with the Webex access SBC. When the registration is challenged for authentication:
-
The username, password, and realm parameters from the credentials configuration is used in the response.
-
The modification rules in sip profile 100 are used to convert SIPS URL back to SIP.
Registration is successful when a 200 OK is received from the access SBC.
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
| 1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Ось пояснення полів для конфігурації: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
| 2 |
Configure the following IP PSTN dial-peer: Ось пояснення полів для конфігурації: Визначає циферблат VoIP з тегом 200 і дає змістовний опис для простоти управління і усунення несправностей. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Визначає, що циферблат 200 обробляє ніжки виклику SIP. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. For more information, see DTMF Relay (Voice over IP). no vadВимикання виявлення голосової активності. For more information, see vad (dial peer). |
| 3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
| 1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Ось пояснення полів для конфігурації: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
| 2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
| 3 |
Configure the following TDM PSTN dial-peer: Ось пояснення полів для конфігурації: Визначає циферблат VoIP з тегом 200 і дає змістовний опис для простоти управління і усунення несправностей. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
| 4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Ось пояснення полів для конфігурації: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vadВимикання виявлення голосової активності. For more information, see vad (dial peer). |
| 5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
When creating the Webex Calling trunk in Unified CM, ensure that you configure the incoming port in the SIP Trunk Security Profile settings to 5065. This allows incoming messages on port 5065 and populate the VIA header with this value when sending messages to the Local Gateway.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Ось пояснення полів для конфігурації: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. Наприклад: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
| 3 |
Configure the following dial-peers: |
| 4 |
Add call routing using the following configurations: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. You can also install the DS to automate diagnostics data collection and transfer-collected data to the Cisco TAC case to accelerate resolution time.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. You can define the problem detection logic using syslog messages, SNMP events and through periodic monitoring of specific show command outputs.
Типи дій включають збір результатів команд показу:
-
Створення об'єднаного файлу журналу
-
Uploading the file to a user-provided network location such as HTTPS, SCP, FTP server.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Local Gateway running IOS XE 17.6.1a or higher
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Configure the secure email server to be used to send proactive notification if the device is running Cisco IOS XE 17.6.1a or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Configure the environment variable ds_email with the email address of the administrator to notify you.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1a or higher to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
We recommend you to use the Cisco IOS XE Bengaluru 17.6.x or later versions.
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 і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Go to and turn on the Less secure app access setting.
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
This DS tracks CPU utilization for five seconds using the SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Use the show snmp command to enable SNMP. If you do not enable, then configure the snmp-server manager command.
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: увімкнено -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature 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, а також видалить себе. If necessary, reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
Моніторинг реєстрації SIP-транка
Ця DS перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Once the unregistration event is detected, it generates an email and syslog notification and uninstalls itself after two unregistration occurrences. Use the steps below to install the signature:
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Use the show snmp command to check whether SNMP is enabled. If it is not enabled, configure the snmp-server manager command.
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: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Інсталяція діагностичних сигнатур для виправлення неполадок
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Diagnostic Signatures (DS) eliminate the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, який рекомендується інженером TAC як частину підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Configure an additional DS environment variable ds_fsurl_prefix which is the Cisco TAC file server path (cxd.cisco.com) to which the collected diagnostics data are uploaded. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager in the following command. The file upload token can be generated in the Attachments section of the Support Case Manager, as needed.
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" -
Ensure that SNMP is enabled using the show snmp command. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Verify that the signature is successfully installed using the show call-home diagnostic-signature command. Стовпець стану повинен мати значення "зареєстровано".
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
Перевірка виконання діагностичних підписів
In the following command, the “Status” column of the show call-home diagnostic-signature command changes to “running” while the Local Gateway executes the action defined within the 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: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Triggered/Max/Deinstall |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 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 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. If you want to uninstall a signature manually, retrieve the DS ID from the output of the show call-home diagnostic-signature command and run the following command:
call-home diagnostic-signature deinstall <DS ID> Приклад:
call-home diagnostic-signature deinstall 64224 До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
For better management of Cisco IOS XE Gateways, we recommend that you enroll and manage the gateways through the Control Hub. It is an optional configuration. When enrolled, you can use the configuration validation option in the Control Hub to validate your Local Gateway configuration and identify any configuration issues. Currently, only registration-based trunks support this functionality.
For more information, refer the following:
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using certificate-based mutual TLS (mTLS) SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The following image highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used. Options are provided for public or private (behind NAT) addressing. SRV DNS records are optional, unless load balancing across multiple CUBE instances.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Крок 1: Configure router baseline connectivity and security
-
Крок 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Крок 3: Configure Local Gateway with SIP PSTN trunk
-
Крок 4: Configure Local Gateway with existing Unified CM environment
Or:
-
Крок 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All certificate-based Local Gateway deployments require Cisco IOS XE 17.9.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Essentials licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
For high-capacity requirements, you may also require a High Security (HSEC) license and additional throughput entitlement.
Refer to Authorization Codes for further details.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
ACLs
-
User authentication and remote access
-
DNS
-
IP-маршрутизація
-
IP addresses
-
-
The network toward Webex Calling must use a IPv4 address. Local Gateway Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
All SIP and media ports on the Local Gateway interface facing Webex must be accessible from the internet, either directly or via static NAT. Ensure that you update your firewall accordingly.
-
Install a signed certificate on the Local Gateway (the following provides detailed configuration steps).
-
A public Certificate Authority (CA) as detailed in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? must sign the device certificate.
-
The FQDN configured in the Control Hub when creating a trunk must be the Common Name (CN) or Subject Alternate Name (SAN) certificate of the router. Наприклад:
-
If a configured trunk in the Control Hub of your organization has cube1.lgw.com:5061 as FQDN of the Local Gateway, then the CN or SAN in the router certificate must contain cube1.lgw.com.
-
If a configured trunk in the Control Hub of your organization has lgws.lgw.com as the SRV address of the Local Gateway(s) reachable from the trunk, then the CN or SAN in the router certificate must contain lgws.lgw.com. Записи, до яких вирішується адреса SRV (CNAME, A Record або IP-адреса), не є обов'язковими в SAN.
-
Whether you use an FQDN or SRV for the trunk, the contact address for all new SIP dialogs from your Local Gateway uses the name configured in the Control Hub.
-
-
-
Переконайтеся, що сертифікати підписано для використання клієнта та сервера.
-
Upload the Cisco root CA bundle to the Local Gateway.
Конфігурація
| 1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
| 2 |
Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows: |
| 3 |
Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA). |
| 4 |
Authenticate your new certificate using your intermediate (or root) CA certificate, then import the certificate (Step 4). Enter the following exec or configuration command:
|
| 5 |
Import a signed host certificate using the following exec or configuration command:
|
| 6 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:
|
| 7 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
| 1 |
Create a CUBE certificate-based PSTN trunk for an existing location in Control Hub. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. Make a note of the trunk information that is provided once the trunk is created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. |
| 2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Ось пояснення полів для конфігурації:
Enables Cisco Unified Border Element (CUBE) features on the platform. allow-connections sip to sipEnable CUBE basic SIP back to back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally. These global stun commands are only required when deploying your Local Gateway behind NAT.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. sip-profiles inboundEnables CUBE to use SIP profiles to modify messages as they are received. Profiles are applied via dial-peers or tenants. |
| 3 |
Configure voice class codec 100 codec filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Ось пояснення полів для конфігурації: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
| 4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. (This step is not applicable for Webex for Government) Ось пояснення полів для конфігурації: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. The stun usage firewall-traversal flowdata command is only required when deploying your Local Gateway behind NAT. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams. |
| 5 |
Configure the media encryption policy for Webex traffic. (This step is not applicable for Webex for Government) Ось пояснення полів для конфігурації: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
| 6 |
Configure FIPS-compliant GCM ciphers (This step is applicable only for Webex for Government). Ось пояснення полів для конфігурації: voice class srtp-crypto 100Specifies GCM as the cipher-suite that CUBE offers. It is mandatory to configure GCM ciphers for Local Gateway for Webex for Government. |
| 7 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination FQDN or SRV: Ось пояснення полів для конфігурації: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use LGW FQDN or SRV configured in Control Hub while creating a trunk. |
| 8 |
Configure SIP message manipulation profiles. If your gateway is configured with a public IP address, configure a profile as follows or skip to the next step if you are using NAT. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway and "198.51.100.1" is the public IP address of the Local Gateway interface facing Webex Calling: Ось пояснення полів для конфігурації: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. Skip the next step if you have configured your Local Gateway with public IP addresses. |
| 9 |
If your gateway is configured with a private IP address behind static NAT, configure inbound and outbound SIP profiles as follows. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway, "10.80.13.12" is the interface IP address facing Webex Calling and "192.65.79.20" is the NAT public IP address. SIP profiles for outbound messages to Webex Calling
Ось пояснення полів для конфігурації: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. rules 30 to 81Convert private address references to the external public address for the site, allowing Webex to correctly interpret and route subsequent messages. SIP profile for inbound messages from Webex CallingОсь пояснення полів для конфігурації: rules 10 to 80Convert public address references to the configured private address, allowing messages from Webex to be correctly processed by CUBE. For more information, see voice class sip-profiles. |
| 10 |
Configure a SIP Options keepalive with header modification profile. Ось пояснення полів для конфігурації: voice class sip-options-keepalive 100Configures a keepalive profile and enters voice class configuration mode. You can configure the time (in seconds) at which an SIP Out of Dialog Options Ping is sent to the dial-target when the heartbeat connection to the endpoint is in UP or Down status. This keepalive profile is triggered from the dial-peer configured towards Webex. To ensure that the contact headers include the SBC fully qualified domain name, SIP profile 115 is used. Rules 30, 40, and 50 are required only when the SBC is configured behind static NAT. In this example, cube1.lgw.com is the FQDN selected for the Local Gateway and if static NAT is used, "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. |
| 11 |
Configure Webex Calling trunk: |
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
| 1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Ось пояснення полів для конфігурації: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
| 2 |
Configure the following IP PSTN dial-peer: Ось пояснення полів для конфігурації: Визначає циферблат VoIP з тегом 200 і дає змістовний опис для простоти управління і усунення несправностей. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Визначає, що циферблат 200 обробляє ніжки виклику SIP. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. For more information, see DTMF Relay (Voice over IP). no vadВимикання виявлення голосової активності. For more information, see vad (dial peer). |
| 3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
| 1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Ось пояснення полів для конфігурації: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
| 2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
| 3 |
Configure the following TDM PSTN dial-peer: Ось пояснення полів для конфігурації: Визначає циферблат VoIP з тегом 200 і дає змістовний опис для простоти управління і усунення несправностей. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
| 4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Ось пояснення полів для конфігурації: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vadВимикання виявлення голосової активності. For more information, see vad (dial peer). |
| 5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Ось пояснення полів для конфігурації: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. Наприклад: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
| 3 |
Configure the following dial-peers: |
| 4 |
Add call routing using the following configurations: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події SNMP і за допомогою періодичного моніторингу конкретних виходів команд show для визначення логіки виявлення проблеми. До типів дій відносяться:
-
Збирання показаних командних виходів
-
Створення об'єднаного файлу журналу
-
Завантаження файлу на вказане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз, що працює під керуванням IOS XE 17.6.1 або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Configure the secure email server that you use to send proactive notification if the device is running IOS XE 17.6.1 or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Налаштуйте змінну ds_email середовища з адресою електронної пошти адміністратора, про яку ви сповіщаєте.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. If SNMP is not enabled, then configure the snmp-server manager command.
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: увімкнено Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Продукт
CUBE Enterprise in Webex Calling solution
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
show call-home diagnostic-signature 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, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг ненормальних роз 'єднань дзвінків
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Переконайтеся, що SNMP включений за допомогою команди show snmp. If SNMP is not enabled, configure the snmp-server manager command.
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: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Use the command show call-home diagnostic-signature to verify that the signature is successfully installed. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Діагностичні підписи (DS) також можна використовувати для швидкого вирішення проблем. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
За допомогою засобу пошуку діагностичних підписів можна знайти відповідні підписи та інсталювати їх для самостійного вирішення певної проблеми, або інсталювати підпис, рекомендований інженером TAC як частину підтримки підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Configure another DS environment variable ds_fsurl_prefix as the Cisco TAC file server path (cxd.cisco.com) to upload the diagnostics data. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager as shown in the following. The file upload token can be generated in the Attachments section of the Support Case Manager, as required.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. If SNMP not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Install the high CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець "Стан" команди показує діагностичний підпис виклику додому змінюється на "запущений", поки Локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи діагностичний підпис виявляє подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Triggered/Max/Deinstall |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 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 не підтримує запити на створення нових користувацьких підписів.
Implement CUBE high availability as Local Gateway
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
-
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
-
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.
У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
-
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
-
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
-
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
-
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
-
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
-
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
-
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
-
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
-
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
-
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
-
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
-
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
-
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
-
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
-
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
-
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
-
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
-
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
-
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
-
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1 |
Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||
| 2 |
Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 3 |
Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Configure the RG from the previous step under
redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||
| 4 |
Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 5 |
Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||
| 6 |
Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
-
Ім’я користувача: Hussain1076_LGU
-
Пароль: lOV12MEaZx
| 1 |
Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем.
Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. SIP Digest credentials from Control Hub are highlighted in bold.
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2 |
У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
| 3 |
Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4 |
Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2.
Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5 |
Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6 |
Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK».
|
Налаштування Unified CM для Webex Calling
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
|
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
|
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
|
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
Останній розділ onNetRemote використовується лише в багатокластерному середовищі, де обмін інформацією про маршрутизацію між кластерами Unified CM здійснюється за допомогою служби міжкластерного пошуку (ILS) або глобальної реплікації абонентської групи (GDPR). | ||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
|
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
|
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
|
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
|
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
|
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
|
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування функцій Webex Calling
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Enable barge-in for users
| 1 |
From the customer view in https://admin.webex.com, go to . |
| 2 |
Select a user and click Calling. |
| 3 |
Go to the Between-user permissions section, and then select Barge in. |
| 4 |
Turn on the toggle to allow other users to add themselves to this user's ongoing call. |
| 5 |
Check Play a tone when this user Barges In on a call if you want to play a tone to others when this user barges in on their call. The Play a tone when this user Barges In on a call setting doesn't apply to Customer Experience Basic and Essentials supervisor barge-in functionality. Even if you enable this option for a supervisor, the system doesn't play the notification tone to the agent when a supervisor barges in on their call queue call. If you want to play a tone to an agent when a supervisor barges in on their call, you can enable it through ‘Notification tone for agents’ settings. For more information, see the Create a queue section in Webex Customer Experience Basic or Webex Customer Experience Essentials. |
| 6 |
Клацніть Зберегти. |
Enable privacy for a user
| 1 |
Sign in to Control Hub, and go to . |
| 2 |
Choose a user and click Calling. |
| 3 |
Go to the Between-user Permissions area and then choose Privacy. |
| 4 |
Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
|
| 5 |
Установіть прапорець Увімкнути конфіденційність. You can then decide to block everyone by not choosing members from the drop-down list. Alternatively, you can choose the users, workspaces, and virtual lines that can monitor the line status of this user. If you're a location administrator, only the users, workspaces, and virtual lines pertaining to your assigned locations appear in the drop-down list. Uncheck the Enable Privacy check box to allow everyone to monitor the line status. |
| 6 |
Check the Enforce privacy for directed call pickup and barge-in check box to enable privacy for directed call pickup and barge-in.
|
| 7 |
From Add member by name, choose the users, workspaces, and virtual lines that can monitor the phone line status and invoke directed call pickup and barge-in. |
| 8 |
To filter the members that you select, use the filter by name, number or ext field. |
| 9 |
Click Remove All to remove all the selected members. To remove an individual member, click Delete next to the member's name. |
| 10 |
Клацніть Зберегти. |
Configure monitoring
The maximum number of monitored lines for a user is 50. However, while configuring the monitoring list, consider the number of messages that impact the bandwidth between Webex Calling and your network. Also, determine the maximum monitored lines by the number of line buttons on the user's phone.
| 1 |
From the customer view in https://admin.webex.com, go to Management and then click Users. |
| 2 |
Виберіть користувача, якого потрібно змінити, і натисніть кнопку Виклик. |
| 3 |
Go to Between-user Permissions section, and select Monitoring. |
| 4 |
Виберіть один із наведених далі варіантів.
You can include a virtual line in the Add Monitored Line list for user monitoring. |
| 5 |
Choose if you wish to notify this user about parked calls, search for the person or call park extension to be monitored, and then click Save. Порядок ліній з відстеженням у списку в Control Hub відповідає порядку ліній з відстеженням, які відображаються на пристрої користувача. You can reorder the list of monitored lines at any time. The name that appears for the monitored line is the name entered in the Caller ID First Name and Last Name fields for the user, workspace, and virtual line. |
Enable call bridge warning tone for users
Перш ніж почати
| 1 |
Sign in to Control Hub, and go to . |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Go to Between-user Permissions, and click Call Bridging Warning Tone. |
| 4 |
Turn on Call Bridging Warning Tone, and then click Save. By default, this feature is enabled. For more information on call bridging on an MPP shared line, see Shared lines on your multiplatform desk phone. For more information on call bridging on a Webex App shared line, see Shared line appearance for WebexApp. |
Увімкнення функції «Резервування ресурсів» для користувача
| 1 |
From the customer view in https://admin.webex.com, go to Management and select Users. |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Go to the Between-user Permissions section, and select Hoteling and turn on the toggle. |
| 4 |
Enter the name or number of the hoteling host in the Hoteling Location search field and choose the hoteling host that you want to assign to the user. Only one hoteling host can be selected. If you choose another hoteling host, the first one gets deleted. If you're a location administrator, you can assign only the hoteling host pertaining to your assigned locations. |
| 5 |
To limit the time a user can be associated to the hoteling host, choose the number of hours that the user can use the hoteling host from the Limit Association Period drop-down. The user will be logged out automatically after the chosen time. An error message is displayed in the screen if the limit association period specified for the user exceeds the limit association period of the chosen hoteling host. For example, if the hoteling host has a limit association period of 12 hours and the user's limit association period is 24 hours, an error message is displayed. In such cases, you need to extend the limit association period of the hoteling host if more time is needed for the user. |
| 6 |
Клацніть Зберегти. A user can also search, and locate the hoteling host they want to use from the User Hub. For more information, see Access your calling profile from anywhere. |
Adoption trends and usage reports for Webex Calling
View calling reports
На сторінці аналітики в Control Hub можна отримати відомості про те, як користувачі використовують Webex Calling і програму Webex (взаємодія), а також про якість мультимедіа викликів. To access Webex Calling analytics, sign in to Control Hub, then go to Analytics and select the Calling tab.
| 1 |
For detailed call history reports, sign in to Control Hub, then go to . |
| 2 |
Select Detailed Call History. Інформацію про виклики за допомогою виділеного екземпляра див. в розділі Аналітика виділеного екземпляра. |
| 3 |
To access media quality data, sign in to Control Hub, then go to Analytics and then select Calling. Додаткову інформацію див. в статті Аналітика для вашого портфеля рішень щодо співпраці в хмарі.
|
Run the CScan tool
CScan — це інструмент перевірки готовності мережі, призначений для тестування підключення мережі до Webex Calling.
|
Додаткову інформацію див. в статті Використання CScan для тестування якості мережі Webex Calling. |
Підготовка середовища
Загальні передумови
Перш ніж налаштувати локальний шлюз для Webex Calling, переконайтеся, що ви:
Базові знання принципів VoIP
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
Мати базові знання про протокол ініціації сеансу (SIP)
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Див Посібник із налаштування підприємства Cisco Unified Border Element (CUBE). для отримання додаткової інформації.
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Переконайтеся, що ваше розгортання має один або кілька локальних шлюзів, наприклад:
Cisco CUBE для підключення на основі IP
Шлюз Cisco IOS для підключення на основі TDM
Локальний шлюз допомагає перейти на Webex Calling у зручному для вас темпі. Локальний шлюз інтегрує ваше наявне локальне розгортання з Webex Calling. Ви також можете використовувати наявне підключення до ТМЗК. Див Почніть роботу з локальним шлюзом
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
Надходить запит облікових даних (наданих SIP-дайджестом)
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Налаштування Webex Calling для організації
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1. | Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте. Ваша адреса електронної пошти адміністратора автоматично використовується для входу в Control Hub, де вам буде запропоновано створити пароль адміністратора. Після входу майстер налаштування буде запущено автоматично. |
| 2. | Перегляньте й прийміть умови обслуговування. |
| 3. | Перегляньте план і клацніть Початок роботи. За перші кроки з активації з використанням майстра першого встановлення відповідає ваш менеджер із роботи з клієнтами. У разі отримання сповіщення «Не вдалося налаштувати виклик» після натискання кнопки Початок роботи зверніться до менеджера із роботи з клієнтами. |
| 4. | Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. |
| 5. | Клацніть Далі. Розміщення за замовчуванням. |
| 6. | Виберіть один із наведених далі варіантів.
Після завершення роботи майстра встановлення упевніться, що ви додаєте основний номер до створеного розташування. |
| 7. | Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
|
| 8 | Клацніть Далі. |
| 9 | Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
Адреса розташування
Бажані номери телефону (необов’язково)
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , перейдіть до . Нове розташування буде розміщено в регіональному центрі обробки даних, що відповідає країні, яку ви вибрали за допомогою майстра першого налаштування. |
| 2. | Налаштуйте параметри розташування.
|
| 3. | Клацніть Зберегти а потім виберіть Так / Ні щоб додати номери до розташування зараз або пізніше. |
| 4. | Якщо клацнути Так , виберіть один із таких варіантів:
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Щоб отримати допомогу, створіть запит до служби підтримки. |
| 5. | Виберіть, чи потрібно активувати номери зараз або пізніше. |
| 6. | Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. |
| 7. | Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Перш ніж почати
Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до розділу й в розкривному меню виберіть розташування, яке потрібно видалити. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори.
Майте на увазі, що будь-які номери, пов’язані з цим розташуванням, буде передано вашому провайдеру ТМЗК; ви більше не будете володіти цими номерами.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , перейдіть до . |
| 2. | Клацніть |
| 3. | Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай потрібно кілька хвилин, щоб остаточно видалити розташування, але процес може тривати до однієї години. Щоб перевірити стан, можна клацнути |
Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
| 1. | Увійдіть до Control Hub за адресоюhttps://admin.webex.com , перейдіть до . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. |
| 2. | (Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
|
| 3. | Для розташування виберіть Основний номер у розкривному списку, щоб дозволити користувачам у цьому розташуванні здійснювати та приймати виклики. , Основний номер можна призначити автосекретарю, щоб зовнішні абоненти, що телефонують, могли зв’язатися з користувачами Webex Calling у цьому розташуванні. Користувачі Webex Calling у цьому розташуванні також можуть використовувати цей номер як зовнішній ідентифікатор абонента, що телефонує, під час здійснення викликів. |
| 4. | (Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню. Це налаштування необов’язкове й застосовується лише для країн, які цього потребують. У деяких країнах (як-от Франція), існують нормативні вимоги до стільникових радіосистем із метою встановлення ідентифікатора стільникового зв’язку під час здійснення екстреного виклику й надання до них доступу екстреним службам. Інші країни, як-от США та Канада, застосовують визначення розташування за допомогою інших методів. Додаткову інформацію див. в статті Розширені екстрені виклики. Вашому постачальнику екстрених викликів може знадобитися інформація про мережу доступу, яка досягається шляхом визначення нового заголовка приватного розширення SIP (P-Access-Network-Info). Заголовок містить інформацію, пов’язану з мережею доступу. У разі налаштування ідентифікатора місця надзвичайної ситуації для розташування значення розташування надсилається постачальнику як частина повідомлення SIP. Зверніться до свого постачальника екстрених викликів, щоб дізнатися, чи потрібне вам це налаштування, і використовуйте значення, яке надав ваш постачальник екстрених викликів. |
| 5. | Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. |
| 6. | (Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти. Зміна параметра Мова оголошень набуває чинності негайно для всіх нових користувачів і функцій, доданих до цього розташування. Якщо для наявних користувачів і/або функцій також потрібно змінити мову оголошень, коли з’явиться запит, виберіть Змінити для наявних користувачів і робочих просторів або Змінити для наявних функцій. Клацніть Застосувати. Перебіг виконання можна переглянути на сторінці Завдання. Поки це налаштування не буде завершено, внести інші зміни буде неможливо. У разі змінювання часового поясу для розташування не буде оновлено часові пояси функцій, пов’язаних із розташуванням. Щоб змінити часові пояси для таких функцій, як автосекретар, група пошуку й черга викликів, перейдіть до області Загальні налаштування певної функції, для якої потрібно оновити часовий пояс, змініть налаштування там і збережіть їх. |
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. Коли ви змінюєте абонентську групу, приклади номерів у Control Hub оновлюються, щоб відобразити ці зміни.
Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки, щоб налаштувати дозволи на вихідні виклики.
| 1. | Увійти в Control Hub , перейдіть до , а потім перейдіть до Внутрішній набір . |
| 2. | За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
|
| 3. | Налаштуйте внутрішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть внутрішній набір відповідно до:
|
| 4. | Укажіть зовнішній набір для певних розташувань. Перейти до , виберіть розташування зі списку й клацніть Виклик . Прокрутіть до Набір номера , а потім змініть зовнішній набір відповідно до:
Вплив на користувачів.
|
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань.
Перш ніж почати
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , перейдіть до і виберіть Додати транк . |
| 2. | Виберіть розташування. |
| 3. | Укажіть ім’я транку й клацніть Зберегти. Довжина імені не може перевищувати 24 символи. |
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , перейдіть до . |
| 2. | Виберіть розташування, яке необхідно змінити, і клацніть Керування. |
| 3. | Виберіть PSTN на базі локальних ресурсів і клацніть Далі. |
| 4. | Виберіть транк у розкривному меню. Перейдіть на сторінку транку, щоб керувати параметрами транкової групи. |
| 5. | Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). У цій статті розглянуто цей процес. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
Після успішного завершення конфігурації на самому шлюзі можна повернутися до розділу Служби > Виклик > Розташування в Control Hub. Створений вами шлюз буде відображено в призначеній йому картці розташування із зеленою крапкою ліворуч від імені. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
Якщо ви тестуєте служби Webex і хочете перетворити свою пробну версію на платну підписку, можна надіслати запит електронною поштою своєму партнеру.
| 1. | Увійдіть до Control Hub на сторінціhttps://admin.webex.com , виберіть значок будівлі |
| 2. | Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
Ви можете використовувати Control Hub, щоб установити пріоритет доступних параметрів викликів, які користувачі бачать у програмі Webex. Ви також можете ввімкнути їх для виклику одним клацанням. Додаткову інформацію див. на сторінці Налаштуйте параметри викликів для користувачів програми Webex .
Ви можете керувати програмою викликів, яка відкриватиметься, коли користувачі здійснюють виклики. Можна налаштувати параметри клієнта викликів, зокрема розгортання в змішаному режимі для організацій, у яких користувачі мають права на Unified CM або Webex Calling, а також користувачів без платних послуг викликів від Cisco. Додаткову інформацію див. на сторінці Налаштуйте поведінку викликів .
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Огляд
Зараз Webex Calling підтримує дві версії локального шлюзу:
Локальний шлюз
Локальний шлюз для Webex для державних установ
Перш ніж почати, ознайомтеся з вимогами до локальної комутованої телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Див Переважна архітектура Cisco для Webex Calling для отримання додаткової інформації.
У цій статті передбачається, що використовується окрема платформа локального шлюзу без наявної конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не перериваєте наявні потоки викликів і функції через внесені вами зміни.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту.
Є два варіанти налаштування локального шлюзу для транка Webex Calling.
Транк на основі реєстрації
Транк на основі сертифіката
Використовуйте потік завдань або під Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling.
Див Почніть роботу з локальним шлюзом для отримання додаткової інформації про різні типи транків. Виконайте наведені далі кроки на самому локальному шлюзі за допомогою інтерфейсу командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортний засіб безпеки транспортного рівня (TLS) для захисту транка, а протокол Secure Real Time Protocol (SRTP) для захисту медіа між локальним шлюзом і Webex Calling.
Виберіть CUBE як локальний шлюз. Webex для державних установ наразі не підтримує сторонні контролери кордону сеансів (SBC). Щоб переглянути останній список, див Почніть роботу з локальним шлюзом .
- Установіть Cisco IOS XE Dublin 17.12.1a або пізнішої версії для всіх локальних шлюзів Webex для державних установ.
Щоб переглянути список кореневих центрів сертифікації (CA), які підтримує Webex for Government, див Кореневі центри сертифікатів для Webex для державних установ .
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex для державних установ див Вимоги до мережі для Webex for Government (FedRAMP) .
Локальний шлюз для Webex для державних установ не підтримує такі можливості:
STUN/ICE-Lite для оптимізації шляху медіа
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex для державних установ, використовуйте такий параметр:
Транк на основі сертифіката
Використовуйте потік завдань у розділі Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling. Докладніше про налаштування локального шлюзу на основі сертифіката див Налаштуйте транк Webex Calling на основі сертифіката .
Обов’язково потрібно налаштувати шифри GCM, що відповідають вимогам FIPS, для підтримки локального шлюзу для Webex для державних установ. Якщо ні, налаштування виклику не вдасться. Детальнішу інформацію про конфігурацію див Налаштуйте транк Webex Calling на основі сертифіката .
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, якої буде дотримано.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу: Використовується для створення конкретних конфігурацій транка.
URI класу голосу: Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору: Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
група абонентів: Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору: Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Хоча IP і SIP стали протоколами за замовчуванням для транків ТМЗК, канали ISDN TDM (мультиплексування з часовим розділенням) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати процес маршрутизації викликів із двох етапів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх вузлів набору з зворотним зв’язком між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити налаштування локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4. Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
Для всіх розгортань локального шлюзу на основі реєстрації потрібні Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінки. Знайдіть платформу та виберіть одну з запропоновано випусків.
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
NTP
ACL
Автентифікація користувача та віддалений доступ
DNS
IP-маршрутизація
IP-адреси
Мережа для Webex Calling має використовувати адресу IPv4.
Передати кореневий CA пакет Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
|
| 2. | Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.
|
| 3. | Створіть точку довіри PKI-заповнювач. Ця точка довіри вимагає, щоб пізніше налаштувати TLS. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це потрібно для транка на основі сертифіката. |
| 4. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволяє підключення, якщо ім’я хоста, налаштованого в осередку 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5. | Установіть пакет кореневого CA Cisco, який містить сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий CA пакет із вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA: ip http клієнт проксі-сервер yourproxy.com проксі-порт 80 |
| 1. | Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Додаткову інформацію див Налаштуйте транки, групи маршрутів і абонентські групи для Webex Calling . |
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Нижче наведено пояснення полів для конфігурації.
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистику медіаВмикає моніторинг медіа на локальному шлюзі. медіа bulk-statsДозволяє площині керування опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див Медіа . дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP back-to-back. Додаткову інформацію див Дозволити підключення . За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) . Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Додаткову інформацію про цю команду див асиметричне корисне навантаження . вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Додаткову інформацію про цю команду див рання пропозиція . |
| 3. | Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Нижче наведено пояснення полів для конфігурації. кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див кодек голосового класу . Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації. |
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. Нижче наведено пояснення полів для конфігурації. оглушення використання ice liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, щоб забезпечити оптимізацію медіа, коли це можливо. Додаткову інформацію див використання оглушення класу голосу і оглушення використання ice lite . Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC |
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. Нижче наведено пояснення полів для конфігурації. голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Додаткову інформацію див голосовий клас srtp-crypto . |
| 6. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Нижче наведено пояснення полів для конфігурації. голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див uri класу голосу . |
| 7. | Налаштувати профіль sip 100 , який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Нижче наведено пояснення полів для конфігурації.
|
| 8 | Налаштуйте транк Webex Calling: |
Після визначення клієнта 100 і налаштувати абонентську точку SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі SBC доступу представляє свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат SBC для доступу до Webex Calling за допомогою кореневого пакета CA, який було оновлено раніше. Якщо сертифікат розпізнано, між локальним шлюзом і SBC для доступу до Webex Calling буде встановлено постійний сеанс TLS. Після цього локальний шлюз зможе використовувати це безпечне підключення для реєстрації в SBC доступу до Webex. Коли реєстрацію оскаржують для автентифікації:
, ім’я користувача, пароль, і області параметри з облікові дані конфігурація використовується у відповіді.
Правила модифікації в профілі 100 sip використовуються для перетворення SIPS URL назад на SIP.
Реєстрація буде успішною, коли буде отримано 200 OK від SBC доступу.
Побудувавши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете застосувати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів.
Якщо ви використовуєте транк ТМЗК TDM/ISDN, перейдіть до наступного розділу Налаштуйте локальний шлюз із транком ТМЗК TDM .
Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI .
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Нижче наведено пояснення полів для конфігурації. голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP з тегом 200 і містить змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузл набору) . ціль сеансу ipv4:192.168.80.13Указує цільову IPv4-адресу призначення для надсилання гілки виклику. Цільовою метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій збігу для заголовка VIA з IP-адресою IP ТМЗК. Зіставляє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Додаткову інформацію див кодек голосового класу . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, що очікується на гілці виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після створення транка для Webex Calling скористайтеся наведеною далі конфігурацією, щоб створити транк TDM для служби ТМЗК із зворотною маршрутизацією виклику, щоб оптимізувати медіа на гілці виклику Webex.
| 1. | Конфігурація зворотного набору абонентів використовує групи абонентів і теги маршрутизації викликів, щоб забезпечити коректну передачу викликів між Webex і ТМЗК без створення петель маршрутизації викликів. Налаштуйте такі правила перекладу, які використовуватимуться для додавання та видалення тегів маршрутизації викликів: Нижче наведено пояснення полів для конфігурації. правило перекладу голосуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Для наочності під час усунення несправностей використовуються цифри, що перевищують десяток ("A"). У цій конфігурації тег, доданий профілем трансляції 100, використовується для спрямування викликів із Webex Calling до ТМЗК через точки зворотного набору. Аналогічно, тег, доданий профілем 200 перекладу, використовується для спрямування викликів із ТМЗК до Webex Calling. Профілі перекладу 11 і 12 видаляють ці теги перед доставкою викликів до транків Webex і ТМЗК відповідно. У цьому прикладі передбачається, що номери, на які набирається виклик із Webex Calling, представлені у форматі +E.164. Правило 100 видаляє + на початку, щоб зберегти дійсний номер виклику. Правило 12 потім додає національну або міжнародну цифру маршрутизації під час видалення тега. Використовуйте цифри, які відповідають вашій місцевій національній абонентській групі ISDN. Якщо Webex Calling надає номери в національному форматі, відкоригуйте правила 100 і 12, щоб просто додати або видалити тег маршрутизації відповідно. Додаткову інформацію див голосовий переклад-профіль і правило перекладу голосу . |
| 2. | Налаштуйте порти голосового інтерфейсу TDM відповідно до типу транка та використовуваного протоколу. Додаткову інформацію див Налаштування ISDN PRI . Наприклад, базова конфігурація інтерфейсу ISDN з основною швидкістю, установленого в гнізді NIM 2 на пристрої, може включати таке: |
| 3. | Налаштуйте таку абонентську точку TDM PSTN: Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP з тегом 200 і надає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . вхідний профіль перекладу 200Призначає профіль перекладу, який додасть тег маршрутизації виклику до номера вхідних викликів. прямий набір всерединуМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див прямий набір всередину . порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цією точкою набору. |
| 4. | Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, запровадивши набір внутрішніх точок набору зворотного набору між Webex Calling і транками ТМЗК. Налаштуйте такі точки зворотного набору. У цьому випадку всі вхідні виклики будуть спочатку маршрутизуватися на одноранговий комутатор 10, а звідти на вузол набору 11 або 12 залежно від застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизуватися до вихідного транка за допомогою груп однорангового набору. Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP та дає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . вхідний профіль перекладу 11Застосовує профіль перекладу, визначений раніше, щоб видалити тег маршрутизації виклику перед передачею до вихідного транка. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Указує, що цей вузол набору обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузл набору) . ціль сеансу 192.168.80.14Задає адресу інтерфейсу локального маршрутизатора як ціль виклику для повернення. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих через петлю. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються через петлю. Додаткову інформацію див прив’язати . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, що очікується на гілці виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . кодек g711alaw Примусово використовувати всі виклики ТМЗК G.711. Виберіть a-law або u-law, щоб відповідати методу компандування, який використовується вашою службою ISDN. немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 5. | Додайте таку конфігурацію маршрутизації викликів: На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 – до Webex Calling. Для включення цього сценарію викликів можна додати наступні додаткові конфігурації.
Під час створення транка Webex Calling в Unified CM переконайтеся, що ви налаштували вхідний порт у параметрах профілю безпеки транка SIP на 5065. Це дозволяє вхідні повідомлення через порт 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу.
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. |
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. З цією конфігурацією не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні. Нижче наведено пояснення полів для конфігурації. Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Ім’я ресурсного запису SRV 2 : Пріоритет ресурсного запису SRV 1 : Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. |
| 3. | Налаштуйте такі точки набору: |
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) проактивно виявляє поширені проблеми в локальному шлюзі на базі IOS XE і створює сповіщення електронної пошти, системного журналу або повідомлення терміналу про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це файли XML, які містять інформацію про події, що викликають проблему, і дії, які необхідно виконати для інформування, усунення несправностей та усунення проблеми. Можна визначити логіку виявлення проблем за допомогою повідомлень системного журналу, подій SNMP і за допомогою періодичного моніторингу конкретних виводів команд show.
Типи дій включають збір виводів команди show:
Створення зведеного файлу журналу
Передавання файлу в надане користувачем мережеве розташування, як-от сервер HTTPS, SCP, FTP.
Інженери TAC створюють файли DS і цифрово підписують їх для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку застосовних підписів для моніторингу та усунення несправностей різних проблем.
Перш ніж почати.
Не змінюйте файл DS, з якого завантажено DSLT . Файли, які ви змінюєте, не встановлюються через помилку перевірки цілісності.
Сервер простого протоколу передавання пошти (SMTP), який потрібен для локального шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що на локальному шлюзі встановлено IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз під керуванням IOS XE 17.6.1a або пізнішої версії
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти для надсилання проактивних сповіщень, якщо на пристрої встановлено Cisco IOS XE 17.6.1a або пізнішої версії.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовищаds_email з адресою електронної пошти адміністратора, щоб сповістити вас.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Далі наведено приклад конфігурації локального шлюзу, що працює на Cisco IOS XE 17.6.1a або новішої версії для надсилання проактивних сповіщень на tacfaststart@gmail.com використання Gmail як захищеного сервера SMTP:
Ми рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або пізнішої версії.
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com" Локальний шлюз, що працює на програмному забезпеченні Cisco IOS XE, не є звичайним вебклієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати конкретне налаштування облікового запису Gmail і надати конкретний дозвіл, щоб електронна пошта з пристрою оброблялася правильно:
Перейти до і ввімкніть Менш безпечний доступ до програми налаштування.
Відповідайте "Так, це був я", коли ви отримаєте електронний лист від Gmail із зазначенням "Google заборонив комусь увійти у ваш обліковий запис за допомогою програми, яка не належить Google".
Установіть діагностичні підписи для проактивного моніторингу
Моніторинг високого рівня використання ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP версії 1.3.6.1.4.1.9.2.1.56. Коли рівень використання досягає 75 % або більше, він вимикає всі налагодження та видаляє всі діагностичні підписи, установлені на локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб увімкнути SNMP. Якщо не ввімкнути, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Висока завантаженість ЦП за допомогою сповіщення електронною поштою.
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з сервера FTP на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте показати підпис діагностики виклику додому команду, щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature 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-транка локального шлюзу з хмарою Webex Calling кожні 60 секунд. Після виявлення події скасування реєстрації створюється сповіщення електронною поштою й системний журнал і видаляється після двох повторень скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
Скасування реєстрації SIP-транка за допомогою сповіщення електронною поштою.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#Використовуйте показати підпис діагностики виклику додому команду, щоб переконатися, що підпис успішно встановлено. Стовпець стану має містити значення "зареєстровано".
Моніторинг незвичайних роз’єднань викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, виконайте наведені нижче дії.
Використовуйте показати snmp команду, щоб перевірити, чи ввімкнено SNMP. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення ненормального відключення виклику SIP за допомогою сповіщення електронної пошти та системного журналу.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте показати підпис діагностики виклику додому команду, щоб переконатися, що підпис успішно встановлено. Стовпець стану має містити значення "зареєстровано".
Установіть діагностичні підписи, щоб усунути проблему
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення певної проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичного перенесення даних до справи Cisco TAC. Діагностичні підписи (DS) усувають необхідність вручну перевіряти виникнення проблеми та значно спрощують усунення періодичних і тимчасових проблем.
Ви можете використовувати Інструмент пошуку діагностичних підписів щоб знайти відповідні підписи та встановити їх для самостійного вирішення певної проблеми, або ви можете встановити підпис, рекомендований інженером TAC як частину завдання з підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" системний журнал і автоматизуйте збір діагностичних даних, виконавши такі кроки:
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix який є шляхом до файлового сервера Cisco TAC (cxd.cisco.com), до якого передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль є маркером передавання файлу, який можна отримати з Диспетчер запитів підтримки у такій команді. Маркер передавання файлу можна створити в розділі Вкладення диспетчера запитів до служби підтримки за потреби.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endОбов’язково встановіть DS 64224 моніторингу високого рівня ЦП як запобіжний захід, щоб вимкнути всі підписи налагодження та діагностики під час високого рівня використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Висока завантаженість ЦП за допомогою сповіщення електронною поштою.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому команду. Стовпець стану має містити значення "зареєстровано".
show call-home diagnostic-signature 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
Зареєстровано
08.11.2020
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
08.11.2020
Перевірте виконання діагностичних підписів
У наведеній далі команді стовпець "Стан" показати підпис діагностики виклику додому команда змінюється на "виконується", поки локальний шлюз виконує дію, визначену в підписі. Вивід показати статистику діагностики підпису виклику додому є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і чи виконує дію. У стовпці "Запущено/Максимально/Видалити" вказано, скільки разів наданий підпис ініціював подію, максимальну кількість випадків, коли вона була визначена для виявлення події, а також чи видаляється підпис після виявлення максимальної кількості ініційованих подій.
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. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub, щоб перевірити конфігурацію локального шлюзу та виявити будь-які проблеми з конфігурацією. Наразі цю функцію підтримують лише транки на основі реєстрації.
Додаткові відомості див. тут:
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою SIP-транка взаємного TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На наведеному нижче зображенні показано це рішення та конфігурація маршрутизації викликів високого рівня, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
клієнти голосового класу : Використовується для створення конкретних конфігурацій транка.
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Хоча IP і SIP стали протоколами за замовчуванням для транків ТМЗК, канали ISDN TDM (мультиплексування з часовим розділенням) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати процес маршрутизації викликів із двох етапів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх вузлів набору з зворотним зв’язком між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні. Надаються параметри для публічної або приватної (за NAT) адресації. Записи DNS SRV є необов’язковими, за винятком випадків балансування навантаження між кількома екземплярами CUBE.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити налаштування локального шлюзу таким чином:
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
Крок 4. Налаштуйте локальний шлюз із наявним середовищем 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 або IP-адреса), є необов’язковими в SAN.
Незалежно від того, чи використовуєте ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з вашого локального шлюзу використовує ім’я, налаштовану в Control Hub.
Переконайтеся, що сертифікати підписані для використання клієнтом і сервером.
Передати кореневий CA пакет Cisco на локальний шлюз.
Конфігурація
| 1. | Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
|
| 2. | Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче. |
| 3. | Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA). |
| 4. | Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:
|
| 5. | Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:
|
| 6. | Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:
|
| 7. | Установіть пакет кореневого CA Cisco, який містить сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий CA пакет із вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA: ip http клієнт проксі-сервер yourproxy.com проксі-порт 80 |
| 1. | Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див Налаштуйте транки, групи маршрутів і абонентські групи для Webex Calling . Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. |
| 2. | Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Нижче наведено пояснення полів для конфігурації.
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP Back to Back. Додаткову інформацію див Дозволити підключення . За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) . Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди зупинки потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Додаткову інформацію про цю команду див асиметричне корисне навантаження . вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Додаткову інформацію про цю команду див рання пропозиція . вхідні sip-профіліДозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів. |
| 3. | Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Нижче наведено пояснення полів для конфігурації. кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див кодек голосового класу . Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації. |
| 4. | Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. (Цей крок не застосовується до Webex для державних установ) Нижче наведено пояснення полів для конфігурації. оглушення використання ice liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, щоб забезпечити оптимізацію медіа, коли це можливо. Додаткову інформацію див використання оглушення класу голосу і оглушення використання ice lite . , дані потоку обходу використання брандмауера команда потрібна лише під час розгортання локального шлюзу за NAT. Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC. |
| 5. | Налаштуйте політику шифрування медіа для трафіку Webex. (Цей крок не застосовується до Webex для державних установ) Нижче наведено пояснення полів для конфігурації. голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA180._ Додаткову інформацію див голосовий клас srtp-crypto . |
| 6. | Налаштуйте FIPS-сумісні шифри GCM (Цей крок застосовується лише до Webex для державних установ) . Нижче наведено пояснення полів для конфігурації. голосовий клас srtp-crypto 100Задає GCM як набір шифрів, який пропонує CUBE. Налаштування шифрів GCM для локального шлюзу для Webex для державних установ є обов’язковим. |
| 7. | Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення: Нижче наведено пояснення полів для конфігурації. голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка. |
| 8 | Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а "198.51.100.1" є загальнодоступною IP-адресою інтерфейсу локального шлюзу, з якого звернено Webex Calling: Нижче наведено пояснення полів для конфігурації. правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. Пропустіть наступний крок, якщо ви налаштували локальний шлюз із загальнодоступними IP-адресами. |
| 9 | Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP наступним чином. У цьому прикладі cube1.lgw.com є повним доменом, налаштованим для локального шлюзу, «10.80.13.12» — це IP-адреса інтерфейсу, що звернена до Webex Calling, а «192.65.79.20» — це загальнодоступна IP-адреса NAT. Профілі SIP для вихідних повідомлень у Webex Calling
Нижче наведено пояснення полів для конфігурації. правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. правила з 30 по 81Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingНижче наведено пояснення полів для конфігурації. правила з 10 по 80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex. Додаткову інформацію див sip-профілі класу голосу . |
| 10 | Налаштуйте параметри SIP для збереження активності за допомогою профілю зміни заголовка. Нижче наведено пояснення полів для конфігурації. голосовий клас sip-options-keepalive 100Налаштовує профіль підтримки активності та переходить у режим конфігурації голосового класу. Можна налаштувати час (у секундах), протягом якого SIP-відповідь «За межами діалогового вікна параметрів» надсилається об’єкту набору, коли контрольне підключення до кінцевої точки перебуває в стані UP або Down. Цей профіль підтримання активності запускається з точки набору, налаштованої на Webex. Щоб переконатися, що заголовки контактів включають повне доменне ім’я SBC, використовується профіль SIP 115. Правила 30, 40 і 50 є обов’язковими, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є FQDN, вибраним для локального шлюзу, і якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC для Webex Calling, а "192.65.79.20" є загальнодоступною IP-адресою NAT. . |
| 11 | Налаштуйте транк Webex Calling: |
Побудувавши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете застосувати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів.
Якщо ви використовуєте транк ТМЗК TDM/ISDN, перейдіть до наступного розділу Налаштуйте локальний шлюз із транком ТМЗК TDM .
Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI .
| 1. | Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Нижче наведено пояснення полів для конфігурації. голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2. | Налаштуйте таку точку набору IP ТМЗК: Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP з тегом 200 і містить змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузл набору) . ціль сеансу ipv4:192.168.80.13Указує цільову IPv4-адресу призначення для надсилання гілки виклику. Цільовою метою сеансу тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій збігу для заголовка VIA з IP-адресою IP ТМЗК. Зіставляє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Додаткову інформацію див кодек голосового класу . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, що очікується на гілці виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3. | Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після створення транка для Webex Calling скористайтеся наведеною далі конфігурацією, щоб створити транк TDM для служби ТМЗК із зворотною маршрутизацією виклику, щоб оптимізувати медіа на гілці виклику Webex.
| 1. | Конфігурація зворотного набору абонентів використовує групи абонентів і теги маршрутизації викликів, щоб забезпечити коректну передачу викликів між Webex і ТМЗК без створення петель маршрутизації викликів. Налаштуйте такі правила перекладу, які використовуватимуться для додавання та видалення тегів маршрутизації викликів: Нижче наведено пояснення полів для конфігурації. правило перекладу голосуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Для наочності під час усунення несправностей використовуються цифри, що перевищують десяток ("A"). У цій конфігурації тег, доданий профілем трансляції 100, використовується для спрямування викликів із Webex Calling до ТМЗК через точки зворотного набору. Аналогічно, тег, доданий профілем 200 перекладу, використовується для спрямування викликів із ТМЗК до Webex Calling. Профілі перекладу 11 і 12 видаляють ці теги перед доставкою викликів до транків Webex і ТМЗК відповідно. У цьому прикладі передбачається, що номери, на які набирається виклик із Webex Calling, представлені у форматі +E.164. Правило 100 видаляє + на початку, щоб зберегти дійсний номер виклику. Правило 12 потім додає національну або міжнародну цифру маршрутизації під час видалення тега. Використовуйте цифри, які відповідають вашій місцевій національній абонентській групі ISDN. Якщо Webex Calling надає номери в національному форматі, відкоригуйте правила 100 і 12, щоб просто додати або видалити тег маршрутизації відповідно. Додаткову інформацію див голосовий переклад-профіль і правило перекладу голосу . |
| 2. | Налаштуйте порти голосового інтерфейсу TDM відповідно до типу транка та використовуваного протоколу. Додаткову інформацію див Налаштування ISDN PRI . Наприклад, базова конфігурація інтерфейсу ISDN з основною швидкістю, установленого в гнізді NIM 2 на пристрої, може включати таке: |
| 3. | Налаштуйте таку абонентську точку TDM PSTN: Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP з тегом 200 і надає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . вхідний профіль перекладу 200Призначає профіль перекладу, який додасть тег маршрутизації виклику до номера вхідних викликів. прямий набір всерединуМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див прямий набір всередину . порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цією точкою набору. |
| 4. | Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, запровадивши набір внутрішніх точок набору зворотного набору між Webex Calling і транками ТМЗК. Налаштуйте такі точки зворотного набору. У цьому випадку всі вхідні виклики будуть спочатку маршрутизуватися на одноранговий комутатор 10, а звідти на вузол набору 11 або 12 залежно від застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизуватися до вихідного транка за допомогою груп однорангового набору. Нижче наведено пояснення полів для конфігурації. Визначає абонентську точку VoIP та дає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . вхідний профіль перекладу 11Застосовує профіль перекладу, визначений раніше, щоб видалити тег маршрутизації виклику перед передачею до вихідного транка. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Указує, що цей вузол набору обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузл набору) . ціль сеансу 192.168.80.14Задає адресу інтерфейсу локального маршрутизатора як ціль виклику для повернення. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих через петлю. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються через петлю. Додаткову інформацію див прив’язати . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, що очікується на гілці виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . кодек g711alaw Примусово використовувати всі виклики ТМЗК G.711. Виберіть a-law або u-law, щоб відповідати методу компандування, який використовується вашою службою ISDN. немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 5. | Додайте таку конфігурацію маршрутизації викликів: На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 – до Webex Calling. Для включення цього сценарію викликів можна додати наступні додаткові конфігурації.
| 1. | Налаштуйте наведені нижче URI класу голосових викликів. |
| 2. | Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. З цією конфігурацією не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні. Нижче наведено пояснення полів для конфігурації. Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp .pstntocucm.io : Ім’я ресурсного запису SRV 2 : Пріоритет ресурсного запису SRV 1 : Вага ресурсного запису SRV 5060 : Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com : Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com : Ім’я організатора запису A. 192.168.80.65 : IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. |
| 3. | Налаштуйте такі точки набору: |
| 4. | Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) проактивно виявляє поширені проблеми в локальному шлюзі на базі Cisco IOS XE і створює сповіщення електронної пошти, системного журналу або повідомлення терміналу про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це файли XML, які містять інформацію про події, що викликають проблему, і дії для інформування, усунення несправностей та усунення проблеми. Використовуйте повідомлення системного журналу, події SNMP та періодичний моніторинг конкретних виводів команд show, щоб визначити логіку виявлення проблем. До типів дій належать:
Збір виводів команди show
Створення зведеного файлу журналу
Передавання файлу в надане користувачем мережеве розташування, як-от сервер HTTPS, SCP, FTP
Інженери TAC створюють файли DS і цифрово підписують їх для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку застосовних підписів для моніторингу та усунення несправностей різних проблем.
Перш ніж почати.
Не змінюйте файл DS, з якого завантажено DSLT . Файли, які ви змінюєте, не встановлюються через помилку перевірки цілісності.
Сервер простого протоколу передавання пошти (SMTP), який потрібен для локального шлюзу для надсилання сповіщень електронною поштою.
Переконайтеся, що на локальному шлюзі встановлено IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз під керуванням IOS XE 17.6.1 або новішої версії
Діагностичні підписи ввімкнено за замовчуванням.
Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо на пристрої встановлено IOS XE 17.6.1 або новішої версії.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls endНалаштуйте змінну середовищаds_email за допомогою адреси електронної пошти адміністратора, щоб сповістити вас.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Установіть діагностичні підписи для проактивного моніторингу
Моніторинг високого рівня використання ЦП
Цей DS відстежує 5-секундне використання ЦП за допомогою OID SNMP версії 1.3.6.1.4.1.9.2.1.56. Коли рівень використання досягає 75 % або більше, він вимикає всі налагодження та видаляє всі діагностичні підписи, які ви встановлюєте на локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з сервера FTP на локальний шлюз.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml successВикористовуйте показати підпис діагностики виклику додому команду, щоб переконатися, що підпис успішно встановлено. Стовпець стану має містити значення "зареєстровано".
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання ЦП на локальному шлюзі.
Моніторинг незвичайних роз’єднань викликів
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення аномального відключення виклику з відображенням помилок SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 з останнього опитування, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, виконайте наведені нижче дії.
Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabledЗавантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Виявлення ненормального відключення виклику SIP за допомогою сповіщення електронної пошти та системного журналу.
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml successВикористовуйте команду показати підпис діагностики виклику додому щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Установіть діагностичні підписи, щоб усунути проблему
Ви також можете використовувати діагностичні підписи (DS) для швидкого вирішення проблем. Інженери Cisco TAC створили кілька підписів, які дозволяють виконувати необхідні налагодження, необхідні для усунення певної проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичного перенесення даних до справи Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
Ви можете використовувати Інструмент пошуку діагностичних підписів щоб знайти відповідні підписи та встановити їх для самостійного вирішення певної проблеми, або ви можете встановити підпис, рекомендований інженером TAC як частину завдання з підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" системний журнал і автоматизуйте збір діагностичних даних, виконавши такі кроки:
Налаштуйте іншу змінну середовища DSds_fsurl_prefix як шлях до файлового сервера Cisco TAC (cxd.cisco.com), щоб передати дані діагностики. Ім’я користувача в шляху до файлу є номером запиту, а пароль є маркером передавання файлу, який можна отримати з Диспетчер запитів підтримки як показано далі. Маркер передавання файлу можна створити в Вкладення розділ диспетчера запитів підтримки (якщо потрібно).
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endПриклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"Переконайтеся, що SNMP ввімкнено за допомогою команди показати snmp . Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
show snmp %SNMP agent not enabled config t snmp-server manager endМи рекомендуємо встановити DS 64224 моніторингу високого рівня ЦП як запобіжний захід, щоб вимкнути всі підписи налагодження та діагностики під час високого рівня використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Висока завантаженість ЦП за допомогою сповіщення електронною поштою.
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:Установіть XML-файл моніторингу високого рівня ЦП DS 64224, а потім DS 65095 на локальний шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml successПереконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому . У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature 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
Перевірте виконання діагностичних підписів
У такій команді стовпець "Стан" команди показати підпис діагностики виклику додому змінюється на "виконується", поки локальний шлюз виконує дію, визначену в підписі. Вивід показати статистику діагностики підпису виклику додому є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і чи виконує дію. У стовпці "Запущено/Максимально/Видалити" вказано, скільки разів наданий підпис ініціював подію, максимальну кількість випадків, коли вона була визначена для виявлення події, а також чи видаляється підпис після виявлення максимальної кількості ініційованих подій.
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 не підтримує запити на створення нових користувацьких підписів.
Впровадження CUBE високого рівня доступності як локального шлюзу
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.
У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1. | Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||
| 2. | Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 3. | Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Налаштуйте RG з попереднього кроку в розділі
redundancy-group 1: додавання та видалення цієї команди вимагає перезавантаження з метою застосування оновленої конфігурації. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||
| 4. | Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 5. | Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||
| 6. | Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
Ім’я користувача: Hussain1076_LGU
Пароль: lOV12MEaZx
| 1. | Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем.
Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. Облікові дані SIP-дайджест-автентифікації від Control Hub виділено жирним шрифтом.
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2. | У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 показати стан реєстру sip-ua
З наведених вище даних виводу видно, що VCUBE-2 є активним локальним шлюзом, який підтримує реєстрацію в SBC доступу Webex Calling, тоді як вихідні дані параметра show sip-ua register status залишаються порожніми у VCUBE-1 |
| 3. | Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4. | Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2.
Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5. | Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6. | Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK».
|
Налаштування Unified CM для Webex Calling
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
Останній розділ onNetRemote використовується лише в багатокластерному середовищі, де обмін інформацією про маршрутизацію між кластерами Unified CM здійснюється за допомогою служби міжкластерного пошуку (ILS) або глобальної реплікації абонентської групи (GDPR). | ||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування функцій Webex Calling
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Увімкнути вхід для користувачів
| 1. | З перегляду клієнта вhttps://admin.webex.com , перейдіть до . |
| 2. | Виберіть користувача та клацніть Виклик . |
| 3. | Перейдіть до Дозволи між користувачами розділу, а потім виберіть Втрутитися . |
| 4. | Увімкніть перемикач, щоб дозволити іншим користувачам додавати себе до поточного виклику цього користувача. |
| 5. | Перевірте Відтворювати сигнал, коли цей користувач включається на виклик якщо ви хочете відтворити сигнал іншим користувачам, коли цей користувач втручається на його виклик. , Відтворювати сигнал, коли цей користувач включається на виклик це налаштування не застосовується до Customer Experience Basic і Essentials для вторгнення наглядача. Навіть якщо цей параметр увімкнено для наглядача, система не відтворюватиме сигнал сповіщення оператора, коли наглядач втручається до його виклику в черзі викликів. Якщо ви хочете відтворювати сигнал оператору, коли наглядач втручається на його виклик, його можна ввімкнути в налаштуваннях "Сигнал сповіщення для операторів". Додаткову інформацію див Створіть чергу розділ у Базові можливості Webex Customer Experience або Основи взаємодії з клієнтами Webex . |
| 6. | Клацніть Зберегти. |
Увімкнути конфіденційність для користувача
| 1. | Увійти в Control Hub , і перейдіть до . |
| 2. | Виберіть користувача та клацніть Виклик . |
| 3. | Перейдіть до Дозволи між користувачами область, а потім виберіть Конфіденційність . |
| 4. | Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
|
| 5. | Установіть прапорець Увімкнути конфіденційність. Потім ви можете заблокувати всіх, не вибираючи учасників із розкривного списку. Крім того, можна вибрати користувачів, робочі області та віртуальні лінії, які можуть відстежувати стан лінії цього користувача. Якщо ви адміністратор розташування, у розкривному списку відображатимуться лише користувачі, робочі області та віртуальні лінії, що належать до ваших призначених розташувань. Зніміть прапорець Увімкнути конфіденційність прапорець, щоб дозволити всім спостерігати за станом лінії. |
| 6. | Перевірте Забезпечте конфіденційність для спрямованого підхоплення викликів і входу прапорець, щоб увімкнути конфіденційність для спрямованого підхоплення викликів і вторгнення.
|
| 7. | Від Додати учасника за іменем , виберіть користувачів, робочі простори та віртуальні лінії, які можуть відстежувати стан телефонної лінії та активувати спрямоване підхоплення та вхід виклику. |
| 8 | Щоб фільтрувати вибраних учасників, використовуйте фільтр за іменем, номером або внутр поле. |
| 9 | Клацніть Видалити все , щоб видалити всіх вибраних учасників. Щоб видалити окремого учасника, клацніть Видалити поруч із іменем учасника. |
| 10 | Клацніть Зберегти. |
Налаштуйте моніторинг
Максимальна кількість відстежуваних ліній для користувача становить 50. Однак під час налаштування списку моніторингу враховуйте кількість повідомлень, які впливають на пропускну здатність між Webex Calling і мережею. Також визначте максимальну кількість контрольованих ліній за кількістю кнопок ліній на телефоні користувача.
| 1. | З перегляду клієнта вhttps://admin.webex.com , перейдіть до Керування а потім клацніть Користувачі . |
| 2. | Виберіть користувача, якого потрібно змінити, і клацніть Виклик . |
| 3. | Перейти до Дозволи між користувачами і виберіть Моніторинг . |
| 4. | Виберіть один із наведених далі варіантів.
Ви можете включити віртуальну лінію в Додати контрольовану лінію список для моніторингу користувачів. |
| 5. | Виберіть, чи хочете ви сповіщати цього користувача про запарковані виклики, знайдіть особу або внутрішній номер для паркування викликів, які потрібно відстежити, а потім клацніть Зберегти . Порядок ліній з відстеженням у списку в Control Hub відповідає порядку ліній з відстеженням, які відображаються на пристрої користувача. Ви можете будь-коли змінити порядок у списку відстежуваних ліній. Ім’я, яке відображається для контрольованої лінії, є ім’ям, введеним у полях імені та прізвища ідентифікатора абонента, що телефонує, для користувача, робочого простору та віртуальної лінії. |
Увімкнути попереджувальний сигнал мосту викликів для користувачів
Перш ніж почати
| 1. | Увійти в Control Hub , і перейдіть до . |
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. |
| 3. | Перейти до Дозволи між користувачами і клацніть Попереджувальний сигнал мосту викликів . |
| 4. | Увімкніть Попереджувальний сигнал мосту викликів , а потім клацніть Зберегти . За замовчуванням цю функцію ввімкнено. Додаткову інформацію про мости викликів на спільній лінії MPP див Спільні лінії на вашому багатоплатформовому настільному телефоні . Докладніше про мост викликів на спільній лінії програми Webex див Вигляд спільної лінії для WebexApp . |
Увімкнення функції «Резервування ресурсів» для користувача
| 1. | З перегляду клієнта вhttps://admin.webex.com , перейдіть до Керування і виберіть Користувачі . |
| 2. | Виберіть користувача й перейдіть на вкладку Виклики. |
| 3. | Перейдіть до Дозволи між користувачами і виберіть Готелі і ввімкніть перемикач. |
| 4. | Введіть ім’я або номер організатора готелю в поле Розташування готелів поле пошуку й виберіть організатора, якого потрібно призначити користувачеві. Можна вибрати лише одного організатора готелів. Якщо ви виберете іншого організатора готелів, першого буде видалено. Якщо ви адміністратор розташування, ви можете призначити лише організатора готелів, що стосується ваших призначених розташувань. |
| 5. | Щоб обмежити час, протягом якого користувач може бути пов’язаний із організатором готелів, виберіть кількість годин, протягом яких користувач може використовувати організатора готелів у списку Обмежений період асоціації розкривний. Вихід користувача буде автоматично виконано після вибраного часу. Повідомлення про помилку відображається на екрані, якщо період зв’язку обмеження, указаний для користувача, перевищує період обмеження зв’язку вибраного організатора готелів. Наприклад, якщо для організатора готелів встановлено обмеження періоду зв’язку в 12 годин, а обмеження для користувача — 24 години, з’явиться повідомлення про помилку. У таких випадках потрібно продовжити період обмеження зв’язку організатора готелів, якщо користувачеві потрібно більше часу. |
| 6. | Клацніть Зберегти. Користувач також може шукати та знаходити організатора готелів, який він хоче використовувати, у центрі користувачів. Додаткову інформацію див Отримайте доступ до свого профілю викликів будь-де . |
Тенденції запровадження і звіти про використання для Webex Calling
Перегляд звітів про виклики
На сторінці аналітики в Control Hub можна отримати відомості про те, як користувачі використовують Webex Calling і програму Webex (взаємодія), а також про якість мультимедіа викликів. Щоб отримати доступ до аналітики Webex Calling, увійдіть у Control Hub, перейдіть до розділу Аналітика й клацніть вкладку Виклики.
| 1. | Щоб отримати докладні звіти про історію викликів, увійдіть у Control Hub, а потім перейдіть до . |
| 2. | Виберіть Детальна історія викликів . Інформацію про виклики за допомогою виділеного екземпляра див. в розділі Аналітика виділеного екземпляра. |
| 3. | Щоб отримати доступ до даних про якість мультимедіа, увійдіть у Control Hub, перейдіть до розділу Аналітика й виберіть Виклики. Додаткову інформацію див. в статті Аналітика для вашого портфеля рішень щодо співпраці в хмарі.
|
Запустіть інструмент CScan
CScan — це інструмент перевірки готовності мережі, призначений для тестування підключення мережі до Webex Calling.
Додаткову інформацію див. в статті Використання CScan для тестування якості мережі Webex Calling. |
Підготовка середовища
Загальні передумови
Перш ніж налаштувати локальний шлюз для Webex Calling, переконайтеся, що ви:
-
Базові знання принципів VoIP
-
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
-
Базове розуміння протоколу ініціювання сеансу (SIP).
-
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Додаткову інформацію див. в Cisco Unified Border Element (CUBE) Enterprise Configuration Guide .
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Переконайтеся, що у вашому розгортанні є один або кілька локальних шлюзів, як-от:
-
Cisco CUBE для підключення на основі IP
-
Шлюз Cisco IOS для з’єднання на основі TDM
Локальний шлюз допомагає виконати міграцію до Webex Calling у вашому власному темпі. Локальний шлюз інтегрує наявне локальне розгортання з Webex Calling. Також можна використовувати наявне підключення до ТМЗК. Див. розділ Початок роботи з локальним шлюзом
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
-
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
-
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
-
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
-
Надходить запит облікових даних (наданих SIP-дайджестом)
-
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Налаштування Webex Calling для організації
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1 |
Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте. Ваша адреса електронної пошти адміністратора автоматично використовується для входу в Control Hub, де вам буде запропоновано створити пароль адміністратора. Після входу майстер налаштування буде запущено автоматично. |
| 2 |
Перегляньте й прийміть умови обслуговування. |
| 3 |
Перегляньте план і клацніть Початок роботи. За перші кроки з активації з використанням майстра першого встановлення відповідає ваш менеджер із роботи з клієнтами. У разі отримання сповіщення «Не вдалося налаштувати виклик» після натискання кнопки Початок роботи зверніться до менеджера із роботи з клієнтами. |
| 4 |
Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. |
| 5 |
Клацніть Далі. Розміщення за замовчуванням. |
| 6 |
Виберіть один із наведених далі варіантів.
Після завершення роботи майстра встановлення упевніться, що ви додаєте основний номер до створеного розташування. |
| 7 |
Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
|
| 8 |
Клацніть Далі. |
| 9 |
Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
-
Адреса розташування
-
Бажані номери телефону (необов’язково)
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . Нове розташування буде розміщено в регіональному центрі обробки даних, яке відповідає країні, яку ви вибрали за допомогою майстра першого встановлення. |
| 2 |
Налаштуйте параметри розташування.
|
| 3 |
Натисніть кнопку Зберегти , а потім виберіть так / ні , щоб додати номери до розташування зараз або пізніше. |
| 4 |
Якщо ви натиснули кнопку Так, виберіть один із наступних параметрів:
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Створіть запит до служби підтримки , щоб отримати інструкції. |
| 5 |
Виберіть, чи потрібно активувати номери зараз або пізніше. |
| 6 |
Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. |
| 7 |
Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Перш ніж почати
Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до розділу й в розкривному меню виберіть розташування, яке потрібно видалити. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори.
Майте на увазі, що всі номери, пов’язані з цим розташуванням, будуть повернені вашому постачальнику ТМЗК. Ви більше не будете власниками цих номерів.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . |
| 2 |
Клацніть |
| 3 |
Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай потрібно кілька хвилин, щоб остаточно видалити розташування, але процес може тривати до однієї години. Щоб перевірити стан, можна клацнути |
Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. |
| 2 |
(Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
|
| 3 |
Для розташування виберіть основний номер із розкривного списку, щоб користувачі в цьому розташуванні могли здійснювати та приймати виклики. Основний номер можна призначити автосекретарю, щоб зовнішні абоненти, що телефонують, могли зв’язуватися з користувачами Webex Calling у цьому розташуванні. Користувачі Webex Calling у цьому розташуванні також можуть використовувати цей номер як ідентифікатор абонента, що телефонує, під час здійснення викликів. |
| 4 |
(Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню. Це налаштування необов’язкове й застосовується лише для країн, які цього потребують. У деяких країнах (як-от Франція), існують нормативні вимоги до стільникових радіосистем із метою встановлення ідентифікатора стільникового зв’язку під час здійснення екстреного виклику й надання до них доступу екстреним службам. Інші країни, як-от США та Канада, використовують інші методи визначення місцезнаходження. Додаткову інформацію див. в статті Розширені екстрені виклики. Вашому постачальнику екстрених викликів може знадобитися інформація про мережу доступу, яка досягається шляхом визначення нового заголовка приватного розширення SIP (P-Access-Network-Info). Заголовок містить інформацію, пов’язану з мережею доступу. У разі налаштування ідентифікатора місця надзвичайної ситуації для розташування значення розташування надсилається постачальнику як частина повідомлення SIP. Зверніться до свого постачальника екстрених викликів, щоб дізнатися, чи потрібне вам це налаштування, і використовуйте значення, яке надав ваш постачальник екстрених викликів. |
| 5 |
Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. |
| 6 |
(Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти. Зміна параметра Мова оголошень набуває чинності негайно для всіх нових користувачів і функцій, доданих до цього розташування. Якщо для наявних користувачів і/або функцій також потрібно змінити мову оголошень, коли з’явиться запит, виберіть Змінити для наявних користувачів і робочих просторів або Змінити для наявних функцій. Клацніть Застосувати. Перебіг виконання можна переглянути на сторінці Завдання. Поки це налаштування не буде завершено, внести інші зміни буде неможливо. У разі змінювання часового поясу для розташування не буде оновлено часові пояси функцій, пов’язаних із розташуванням. Щоб змінити часові пояси для таких функцій, як автосекретар, група пошуку й черга викликів, перейдіть до області Загальні налаштування певної функції, для якої потрібно оновити часовий пояс, змініть налаштування там і збережіть їх. |
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. Під час зміни абонентської групи наведіть приклади номерів в оновленні Control Hub, щоб відобразити ці зміни.
Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки, щоб налаштувати дозволи на вихідні виклики.
| 1 |
Увійдіть до Control Hub, перейдіть до , а потім прокрутіть до Набір внутрішніх номерів. |
| 2 |
За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
|
| 3 |
Налаштуйте внутрішній набір для певних розташувань. Перейдіть до розділу , виберіть розташування зі списку та клацніть Виклики. Прокрутіть до Набір, а потім змініть внутрішній набір за потреби:
|
| 4 |
Задайте зовнішній набір для певних розташувань. Перейдіть до розділу , виберіть розташування зі списку та клацніть Виклики. Прокрутіть до Набір, а потім змініть зовнішній набір за потреби:
Вплив на користувачів.
|
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань.
Перш ніж почати
-
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
-
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
-
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
-
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до і виберіть Додати транк. |
| 2 |
Виберіть розташування. |
| 3 |
Укажіть ім’я транку й клацніть Зберегти. Довжина імені не може перевищувати 24 символи. |
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . |
| 2 |
Виберіть розташування, яке необхідно змінити, і клацніть Керування. |
| 3 |
Виберіть PSTN на базі локальних ресурсів і клацніть Далі. |
| 4 |
Виберіть транк у розкривному меню. Перейдіть на сторінку транку, щоб керувати параметрами транкової групи. |
| 5 |
Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). У цій статті описано цей процес. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
Після успішного завершення конфігурації самого шлюзу можна повернутися до меню в Control Hub. Створений вами шлюз буде перераховано на карті розташування, якій ви його призначили, із зеленою крапкою ліворуч від імені. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
Якщо ви намагаєтеся користуватися службами Webex і хочете перетворити пробну версію на платну підписку, можна надіслати запит електронною поштою вашому партнеру.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, виберіть значок будівлі |
| 2 |
Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
Можна використовувати Control Hub, щоб установити пріоритетність доступних параметрів виклику, які користувачі бачать у програмі Webex. Їх також можна ввімкнути для виклику одним клацанням. Додаткову інформацію див. на сторінці Установіть параметри виклику для користувачів програми Webex.
Ви можете керувати, яка програма для викликів відкривається, коли користувачі виконують виклики. Можна налаштувати параметри клієнта викликів, зокрема розгортання змішаного режиму для організацій, де користувачі мають право користуватися Unified CM або Webex Calling, і користувачів без платних послуг телефонії від Cisco. Додаткову інформацію див. на сторінці Налаштуйте поведінку викликів.
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Огляд
Webex Calling наразі підтримує дві версії локального шлюзу:
-
Локальний шлюз
-
Локальний шлюз для Webex for Government
-
Перед початком ознайомтеся з вимогами локальної телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise на використання як функції локального шлюзу для Webex Calling, зверніть увагу на цю конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функціональність через внесені вами зміни.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації щодо продуктів.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифіката , щоб налаштувати локальний шлюз для вашого транка Webex Calling.
Додаткову інформацію про різні типи транка див. в розділі Початок роботи з локальним шлюзом . Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціювання сеансу (SIP) і протокол безпеки транспортного рівня (TLS) для захисту транка, а протокол безпеки в реальному часі (SRTP) для захисту медіафайлів між локальним шлюзом і Webex Calling.
-
Виберіть CUBE як локальний шлюз. Webex for Government наразі не підтримує жодних сторонніх контролерів прикордонних сеансів (SBC). Щоб переглянути останній список, див. розділ Початок роботи з локальним шлюзом.
- Установіть Cisco IOS XE Dublin 17.12.1a або пізніші версії для всіх Webex для державних локальних шлюзів.
-
Щоб переглянути список кореневих органів сертифікації (CA), які підтримує Webex for Government, див. розділ Кореневі органи сертифікації для Webex for Government.
-
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex for Government див. в статті Вимоги до мережі для Webex for Government (FedRAMP).
Локальний шлюз для Webex for Government не підтримує таке:
-
STUN/ICE-Lite для оптимізації шляху медіафайлів
-
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex for Government, скористайтеся таким параметром.
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у локальному шлюзі на основі сертифіката , щоб налаштувати локальний шлюз для транка Webex Calling. Додаткову інформацію про налаштування локального шлюзу на основі сертифіката див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Необхідно налаштувати шифри GCM, сумісні з FIPS, для підтримки локального шлюзу для Webex for Government. Якщо ні, не вдасться налаштувати виклик. Додаткові відомості про конфігурацію див. в розділі Налаштування транка на основі сертифіката Webex Calling.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи SIP-транк, що реєструється. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. На наведеному нижче зображенні висвітлено це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2: Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3: Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштуйте локальний шлюз з наявним середовищем Unified CM.
Або:
-
Крок 3: Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі реєстрації потребують Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте наступне та перевірте роботу:
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу.
-
Передайте пакет кореневого CA Cisco до локального шлюзу.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть реєстраційні дані та облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так:
|
| 3 |
Створіть точку довіри PKI-заповнювача. Ця точка довіри вимагає, щоб налаштувати TLS пізніше. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це було б потрібно для транка на основі сертифіката. |
| 4 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням за допомогою наступних команд конфігурації. Також необхідно оновити параметри транспортування, щоб забезпечити надійне безпечне з'єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволяє з’єднання, якщо ім’я хоста, налаштоване в клієнті 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистого URL-адреси , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Зверніть увагу на інформацію про транк, яка надається після його створення. Ці відомості, як підкреслено в наведеній нижче ілюстрації, використовуватимуться в кроках конфігурації цього посібника. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистика медіаЗабезпечує моніторинг медіафайлів на локальному шлюзі. масові стани медіаДозволяє площині управління опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див. у розділі Медіа. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базової функції оператора SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Докладніше про цю команду див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. |
| 3 |
Налаштуйте фільтр кодека класу голосу 100 для транка. У цьому прикладі один і той самий фільтр кодека використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див. в розділі кодек голосового класу. Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове підключення FXO, виключіть бажаний кодек 1 opus з конфігурації кодека класу voice 100 . |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Вам потрібне використання ICE-lite для потоків викликів із використанням оптимізації шляху мультимедіа. Щоб забезпечити оптимізацію мультимедіа для шлюзу SIP до TDM, налаштуйте абонент зворотного набору з увімкненим ICE-Lite на гілці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до облікового запису або команди TAC. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його параметра транка призначення: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub, коли був створений транк. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 7 |
Налаштуйте профіль SIP 100, який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
|
| 8 |
Налаштуйте транк Webex Calling: |
Після визначення клієнта 100 та налаштування вузла набору SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі доступ SBC надає свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат доступу SBC Webex Calling за допомогою кореневої групи CA, яка була оновлена раніше. Якщо сертифікат розпізнано, між локальним шлюзом і доступом Webex Calling SBC буде встановлено постійний сеанс TLS. Потім локальний шлюз може використовувати це захищене з’єднання, щоб зареєструватися в системі доступу Webex SBC. Коли з’являється проблема реєстрації на автентифікацію:
-
У відповіді використовуються параметри ім’я користувача, пароль і області з конфігурації облікових даних .
-
Правила модифікації в sip профілі 100 використовуються для перетворення URL SIPS назад у SIP.
Реєстрація успішна, коли 200 OK отримано з SBC доступу.
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. Безпечна маршрутизація виклику підтримується CUBE.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Визначає, що вузол для набору номера 200 обробляє гілки виклику SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Збігається з усіма гілками вхідних IP-викликів ТМЗК на локальному шлюзі з одноранговим набором 200. Додаткову інформацію див. в URL-адресу вхідного виклику. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). ціль сеансу 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
Під час створення транка Webex Calling у Unified CM переконайтеся, що вхідний порт у параметрах профілю безпеки SIP-транка налаштовано на 5065. Це дозволяє вхідні повідомлення на порту 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. Також можна встановити DS для автоматичного збору діагностичних даних і перенесення зібраних даних до випадку Cisco TAC, щоб прискорити час роздільної здатності.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. Визначити логіку виявлення проблем можна за допомогою повідомлень syslog, подій SNMP і періодичного моніторингу певних виходів команд show.
Типи дій включають збір результатів команд показу:
-
Створення об'єднаного файлу журналу
-
Передавання файлу в надане користувачем мережеве розташування, як-от сервер HTTPS, SCP або FTP.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз працює IOS XE 17.6.1a або новіша
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте безпечний сервер електронної пошти, щоб використовувати його для надсилання проактивних сповіщень, якщо пристрій працює з Cisco IOS XE 17.6.1a або пізнішої версії.
налаштувати сервер електронної пошти термінального виклику :@ пріоритет 1 безпечний кінець tls -
Налаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора для сповіщення.
налаштування середовища діагностики-підпису термінального виклику-домашнього ds_email
Нижче наведено приклад конфігурації локального шлюзу, який працює в Cisco IOS XE 17.6.1a або новішої версії для надсилання проактивних сповіщень на адресу tacfaststart@gmail.com за допомогою Gmail як безпечного сервера SMTP:
Рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або новіші версії.
сервер електронної пошти виклику tacfaststart:password@smtp.gmail.com пріоритет 1 безпечне середовище діагностичного підпису TLS ds_email "tacfaststart@gmail.com" Локальний шлюз, запущений на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати певні налаштування облікового запису Gmail і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Перейдіть до розділу й увімкніть параметр Менш безпечний доступ до програми .
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Використовуйте команду показати snmp , щоб увімкнути SNMP. Якщо його не ввімкнути, налаштуйте команду snmp-server manager .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR серії або Cisco CSR 1000V серії
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# копіювати ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису на домашній виклик DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання CPU в локальному шлюзі.
Моніторинг реєстрації SIP-транка
Ця DS перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Після виявлення події скасування реєстрації буде створено сповіщення електронною поштою та системного лотка й видалено після двох повторень скасування реєстрації. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64117.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Завантажити файл DS_64117.xml успішно LocalGateway# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Використовуйте команду показати snmp , щоб перевірити, чи ввімкнено SNMP. Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису на домашній виклик DS_65221.xml Успішно завантажено файл DS_65221.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Інсталяція діагностичних сигнатур для виправлення неполадок
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Діагностичні підписи (DS) позбавляють необхідності вручну перевіряти виникнення проблеми та значно полегшують виправлення переривних та тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, який рекомендується інженером TAC як частину підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix , яка є шляхом сервера файлів Cisco TAC (cxd.cisco.com), на який передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати з Диспетчера запитів підтримки у наведеній нижче команді. Маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки, якщо необхідно.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику на домашній номер ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Упевніться, що SNMP увімкнено за допомогою команди показати snmp . Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
Завантаження діагностичного підпису домашнього виклику DS_64224.xml Завантаження файлу DS_64224.xml успішне завантаження файлу DS_65095.xml Завантаження файлу DS_65095.xml успішно -
Упевніться, що підпис успішно встановлено за допомогою команди показати виклик-домашній діагностичний підпис . Стовпець стану повинен мати значення "зареєстровано".
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08
Перевірка виконання діагностичних підписів
"У наступній команді стовпець ""Стан"" команди показати виклик-домашній діагностичний підпис зміниться на ""Запустити"", тоді як локальний шлюз виконує дію, визначену в підписі." Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS із виводу команди показати виклик-домашній діагностичний підпис і запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Для кращого керування шлюзами Cisco IOS XE рекомендуємо зареєструвати шлюзи й керувати ними через Control Hub. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub для перевірки конфігурації локального шлюзу та виявлення будь-яких проблем з конфігурацією. Зараз цю функцію підтримують лише транки на основі реєстрації.
Додаткову інформацію див. в наступному.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи взаємний SIP-транк TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. Наведене нижче зображення висвітлює це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні. Надано параметри для загальнодоступних або приватних (за NAT) адрес. Записи DNS SRV необов’язкові, за винятком випадків, коли балансування навантаження між кількома екземплярами CUBE.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2: Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3: Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштуйте локальний шлюз з наявним середовищем Unified CM.
Або:
-
Крок 3: Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі сертифікатів потребують Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Essentials. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
Для вимог до високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і додаткове право на пропускну здатність.
Додаткову інформацію див. в розділі Коди авторизації .
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте наступне та перевірте роботу:
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу. Адреси повного доменного імені (FQDN) або запису служби (SRV) локального шлюзу мають зіставити з загальнодоступною IPv4-адресою в інтернеті.
-
Усі порти SIP і медіафайлів в інтерфейсі локального шлюзу, що facing Webex, повинні бути доступними з інтернету безпосередньо або через статичний NAT. Упевніться, що брандмауер було оновлено належним чином.
-
Установіть підписаний сертифікат на локальний шлюз (далі наведено докладні кроки конфігурації).
-
Загальнодоступний центр сертифікації (CA), докладний у розділі Які кореневі органи сертифікації підтримуються для викликів на аудіо- та відеоплатформи Cisco Webex? , повинен підписати сертифікат пристрою.
-
Повне доменне ім’я, налаштоване в Control Hub під час створення транка, має бути сертифікатом маршрутизатора Загальне ім’я (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-адреса), не є обов'язковими в SAN.
-
Незалежно від того, чи використовується ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з локального шлюзу використовує ім’я, налаштоване в Control Hub.
-
-
-
Переконайтеся, що сертифікати підписано для використання клієнта та сервера.
-
Передайте пакет кореневого CA Cisco до локального шлюзу.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так: |
| 3 |
Створіть точку довіри шифрування за допомогою сертифіката, підписаного бажаним центром сертифікації (CA). |
| 4 |
Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду виконання або конфігурації:
|
| 5 |
Імпортувати підписаний сертифікат організатора за допомогою наведених далі команд виконання або конфігурації:
|
| 6 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням за допомогою таких команд конфігурації:
|
| 7 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистого URL-адреси , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. Зверніть увагу на інформацію про транк, яка надається після створення транка. Ці відомості, як підкреслено в наведеній нижче ілюстрації, використовуватимуться в кроках конфігурації цього посібника. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базового SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди stun потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Докладніше про цю команду див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. вхідні профілі sipДозволяє CUBE використовувати профілі SIP для зміни повідомлень під час їх отримання. Профілі застосовуються через однорангових абонентів або клієнтів. |
| 3 |
Налаштуйте фільтр кодека голосового класу 100 кодека для транка. У цьому прикладі один і той самий фільтр кодека використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див. в розділі кодек голосового класу. Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове підключення FXO, виключіть бажаний кодек 1 opus з конфігурації кодека класу voice 100 . |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Команда використання брандмауера й обходу потокових даних потрібна лише під час розгортання локального шлюзу за NAT. Вам потрібне використання ICE-lite для потоків викликів із використанням оптимізації шляху мультимедіа. Щоб забезпечити оптимізацію мультимедіа для шлюзу SIP до TDM, налаштуйте абонент зворотного набору з увімкненим ICE-Lite на гілці IP-IP. За додатковою технічною інформацією зверніться до команди облікового запису або команди TAC. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шифри GCM, сумісні з FIPS (Цей крок застосовується лише для Webex для державних установ). Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає GCM як набір шифрів, який пропонує CUBE. Необхідно налаштувати шифри GCM для локального шлюзу для Webex for Government. |
| 7 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену призначення або SRV: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштоване в Control Hub під час створення транка. |
| 8 |
Налаштуйте профілі керування повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль так, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу, а "198.51.100.1" є публічною IP-адресою інтерфейсу локального шлюзу, що відповідає Webex Calling: Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, яке використовується для кластера пристроїв. Пропустіть наступний крок, якщо ви налаштували локальний шлюз з загальнодоступними IP-адресами. |
| 9 |
Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP так. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу, "10.80.13.12" є IP-адресою інтерфейсу, що стикається з Webex Calling, а "192.65.79.20" є публічною IP-адресою NAT. Запит щодо правила 10 SIP для вихідних повідомлень для вихідних повідомлень до голосового класу Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, яке використовується для кластера пристроїв. правила 30-81Перетворіть посилання на приватні адреси на зовнішню публічну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень від голосового класу Webex CallingОсь пояснення полів для конфігурації: правила 10-80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, що дозволить CUBE правильно обробляти повідомлення з Webex. Додаткову інформацію див. в sip-профілях голосового класу. |
| 10 |
Налаштуйте параметри SIP для збереження з профілем зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль, який зберігається, і переходить у режим конфігурації класу голосового зв’язку. Можна налаштувати час (у секундах), коли сигнал SIP Out of Dialog Options надсилається цільовому набору, коли серцебиття з’єднання з кінцевим пристроєм перебуває в стані "ВГОРУ" або "Вниз". Цей профіль увімкнено з однорангового абонента, налаштованого на Webex. Щоб переконатися, що заголовки контактів містять повне доменне ім’я SBC, використовується SIP-профіль 115. Правила 30, 40 і 50 потрібні, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, вибраним для локального шлюзу, і якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC у напрямку Webex Calling, а "192.65.79.20" – загальнодоступною IP-адресою NAT. |
| 11 |
Налаштуйте транк Webex Calling: |
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. Безпечна маршрутизація виклику підтримується CUBE.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Визначає, що вузол для набору номера 200 обробляє гілки виклику SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Збігається з усіма гілками вхідних IP-викликів ТМЗК на локальному шлюзі з одноранговим набором 200. Додаткову інформацію див. в URL-адресу вхідного виклику. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає однорангову службу набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). ціль сеансу 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події SNMP і за допомогою періодичного моніторингу конкретних виходів команд show для визначення логіки виявлення проблеми. До типів дій відносяться:
-
Збирання показаних командних виходів
-
Створення об'єднаного файлу журналу
-
Завантаження файлу на вказане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз, що працює під керуванням IOS XE 17.6.1 або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте безпечний сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо пристрій працює під керуванням IOS XE 17.6.1 або новішої версії.
налаштуйте сервер електронної пошти термінального виклику :@ пріоритет 1 безпечний кінець tls -
Налаштуйте змінну ds_email середовища з адресою електронної пошти адміністратора, про яку ви сповіщаєте.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_email кінець
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера snmp-сервера .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, будь ласка, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг ненормальних роз 'єднань дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик DS_65221.xml Успішно завантажено файл DS_65221.xml -
Використовуйте команду показати виклик-домашній діагностичний підпис , щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Діагностичні підписи (DS) також можна використовувати для швидкого вирішення проблем. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
За допомогою засобу пошуку діагностичних підписів можна знайти відповідні підписи та інсталювати їх для самостійного вирішення певної проблеми, або інсталювати підпис, рекомендований інженером TAC як частину підтримки підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях сервера файлів Cisco TAC (cxd.cisco.com) для передавання діагностичних даних. Ім’я користувача в шляху файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати в Диспетчер запитів підтримки , як показано нижче. За потреби маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть файл DS 64224 для моніторингу CPU, а потім файл DS 65095 XML у локальний шлюз.
завантаження діагностичного підпису домашнього виклику DS_64224.xml Завантаження файлу DS_64224.xml успішне завантаження файлу DS_65095.xml Завантаження файлу DS_65095.xml успішно -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DSLGW_IEC_C_all_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець "Стан" команди показує діагностичний підпис виклику додому змінюється на "запущений", поки Локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи діагностичний підпис виявляє подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти зі сповіщенням, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення вихідних команд, які мають відношення до усунення несправностей із цією проблемою.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблем. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS з виводу показу діагностичного підпису виклику додому та запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку діагностичних сигнатур періодично додаються нові підписи на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Впровадити CUBE High Availability як локальний шлюз
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
-
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
-
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.
У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
-
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
-
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
-
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
-
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
-
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
-
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
-
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
-
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
-
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
-
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
-
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
-
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
-
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
-
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
-
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
-
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
-
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
-
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
-
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
-
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1 |
Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||
| 2 |
Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 3 |
Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Налаштуйте RG на попередньому кроці в розділі
група резервування 1—Щоб додати та видалити цю команду, необхідно перезавантажити оновлену конфігурацію. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||
| 4 |
Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 5 |
Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||
| 6 |
Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). VCUBE |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
-
Ім’я користувача: Хуссейн1076_ЛГУ
-
Пароль: lOV12MEaZx
| 1 |
Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем. LocalGateway#conf Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. Облікові дані дайджест SIP з Control Hub виділені жирним шрифтом .
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2 |
У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 показати стан реєстрації sip-ua VCUBE VCUBE З виводу вище можна побачити, що VCUBE-2 є активним LGW, який підтримує реєстрацію за допомогою Webex Calling access SBC, тоді як вивід "показати стан реєстрації sip-ua" порожній у VCUBE-1 |
| 3 |
Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4 |
Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2. VCUBE Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5 |
Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6 |
Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK». VCUBE
|
Налаштування Unified CM для Webex Calling
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
|
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
|
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
|
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
Останній розділ onNetRemote використовується лише в багатокластерному середовищі, де обмін інформацією про маршрутизацію між кластерами Unified CM здійснюється за допомогою служби міжкластерного пошуку (ILS) або глобальної реплікації абонентської групи (GDPR). | ||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
|
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
|
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
|
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
|
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
|
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
|
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування функцій Webex Calling
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Увімкнути втручання для користувачів
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до . |
| 2 |
Виберіть користувача та клацніть Виклики. |
| 3 |
Перейдіть до розділу Дозволи між користувачами , а потім виберіть Втручання. |
| 4 |
Увімкніть перемикач, щоб дозволити іншим користувачам додавати себе до поточних викликів цього користувача. |
| 5 |
Установіть прапорець параметра Відтворювати сигнал, коли цей користувач втручається у виклик , якщо ви хочете відтворювати сигнал до інших користувачів, коли цей користувач втручається у виклик. Параметр Відтворювати сигнал, коли цей користувач втручається у виклик , не застосовується до функцій втручання головного адміністратора Customer Experience і основної ліцензії. Навіть якщо ввімкнути цей параметр для наглядача, система не відтворюватиме сигнал сповіщення оператору, коли наглядач втручається у виклик своєї черги викликів. "Якщо ви хочете відтворювати сигнал для оператора, коли наглядач втручається у виклик, ви можете ввімкнути його за допомогою налаштувань ""Сигнал сповіщень для операторів""." Додаткову інформацію див. в розділі Створити чергу в Webex Customer Experience Basic або Webex Customer Experience Essentials. |
| 6 |
Клацніть Зберегти. |
Увімкнути конфіденційність для користувача
| 1 |
Увійдіть до Control Hub і перейдіть до . |
| 2 |
Виберіть користувача й клацніть Виклики. |
| 3 |
Перейдіть до області дозволів між користувачами , а потім виберіть параметр Конфіденційність. |
| 4 |
Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
|
| 5 |
Установіть прапорець Увімкнути конфіденційність. Після цього можна вирішити блокувати всіх учасників, не вибравши учасників із розкривного списку. Крім того, можна вибрати користувачів, робочі простори й віртуальні лінії, які можуть моніторити стан лінії цього користувача. Якщо ви адміністратор розташування, у розкривному списку відображатимуться лише користувачі, робочі простори й віртуальні лінії, що стосуються призначених вам розташувань. Зніміть прапорець Увімкнути конфіденційність , щоб дозволити всім моніторити стан лінії. |
| 6 |
Установіть прапорець Забезпечення конфіденційності для керованого підхоплення викликів і втручання , щоб увімкнути конфіденційність для керованого підхоплення викликів і втручання.
|
| 7 |
У розділі Додати учасника за іменем виберіть користувачів, робочі простори й віртуальні лінії, які можуть моніторити стан телефонної лінії та застосовувати функції керованого підхоплення викликів і втручання у виклик. |
| 8 |
Щоб відфільтрувати вибраних учасників, використовуйте фільтр за полем імені, номера або внутрішнього номера . |
| 9 |
Клацніть Видалити все , щоб видалити всіх вибраних учасників. Щоб видалити окремого члена, клацніть Видалити поруч з іменем члена. |
| 10 |
Клацніть Зберегти. |
Налаштувати моніторинг
Максимальна кількість вибраних для моніторингу ліній для користувача становить 50. Однак під час налаштування списку моніторингу враховуйте кількість повідомлень, які впливають на пропускну здатність між Webex Calling і вашою мережею. Також визначте максимальну кількість вибраних для моніторингу ліній за кількістю кнопок лінії на телефоні користувача.
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до Керування , а потім клацніть Користувачі. |
| 2 |
Виберіть користувача, якого потрібно змінити, і натисніть кнопку Виклик. |
| 3 |
Перейдіть до розділу Дозволи між користувачами і виберіть Моніторинг. |
| 4 |
Виберіть один із наведених далі варіантів.
Віртуальну лінію можна додати до списку Додати вибрану для моніторингу лінію для моніторингу користувачів. |
| 5 |
Виберіть, чи бажаєте ви сповістити цього користувача про запарковані виклики, знайдіть користувача або внутрішній номер для паркування викликів для моніторингу, а потім клацніть Зберегти. Порядок ліній з відстеженням у списку в Control Hub відповідає порядку ліній з відстеженням, які відображаються на пристрої користувача. Ви можете будь-коли змінити порядок списку вибраних для моніторингу ліній. Ім’я, що з’являється для контрольованої лінії, це ім’я, введене в поля ідентифікатора абонента, що телефонує, ім’я та прізвище для користувача, робочого простору й віртуальної лінії. |
Увімкнути попереджувальний сигнал мосту виклику для користувачів
Перед початком
| 1 |
Увійдіть до Control Hub і перейдіть до . |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Перейдіть до Дозволи між користувачами і клацніть Попереджувальний сигнал мосту викликів. |
| 4 |
Увімкніть попереджувальний сигнал мосту викликів, а потім клацніть Зберегти. За замовчуванням цю функцію ввімкнено. Додаткову інформацію про мосту викликів на спільній лінії MPP див. в розділі Спільні лінії на багатоплатформовому настільному телефоні. Додаткову інформацію про міст викликів на спільній лінії програми Webex див. в розділі Зовнішній вигляд спільних ліній для WebexApp. |
Увімкнення функції «Резервування ресурсів» для користувача
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до Керування і виберіть Користувачі. |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Перейдіть до розділу Дозволи між користувачами , виберіть Готелі й увімкніть перемикач. |
| 4 |
Введіть ім’я або номер організатора готелів у полі пошуку Розташування готелів і виберіть організатора готелів, якого ви хочете призначити користувачу. Можна вибрати лише одного організатора готелів. Якщо ви виберете іншого організатора готелів, перший буде видалено. Якщо ви адміністратор розташування, ви можете призначити лише головного комп’ютера, що стосується призначених вам розташувань. |
| 5 |
Щоб обмежити час, протягом якого користувач може бути пов’язаний із організатором готелів, виберіть кількість годин, протягом яких користувач може використовувати організатора готелів із розкривного списку Період обмеження асоціації . Користувач буде автоматично виходити з системи після вибраного часу. Якщо обмежений період асоціації, заданий для користувача, перевищує обмежений період асоціації вибраного головного комп’ютера, з’явиться на екрані повідомлення про помилку. Наприклад, якщо організатор готелю має обмежений період асоціації в 12 годин, а обмежений період асоціації користувача становить 24 години, з’явиться повідомлення про помилку. У таких випадках необхідно подовжити обмежений період асоціації хоста, якщо для користувача потрібен більше часу. |
| 6 |
Клацніть Зберегти. Користувач також може шукати та знайти хост-готель, який він хоче використовувати в користувацькому центрі. Додаткову інформацію див. в розділі Доступ до профілю викликів із будь-якого місця. |
Тенденції впровадження та звіти про використання для Webex Calling
Переглянути звіти про виклики
На сторінці аналітики в Control Hub можна отримати відомості про те, як користувачі використовують Webex Calling і програму Webex (взаємодія), а також про якість мультимедіа викликів. Щоб отримати доступ до аналітики Webex Calling, увійдіть у Control Hub, потім перейдіть до Аналітика і виберіть вкладку Виклики .
| 1 |
Щоб отримати докладні звіти про історію викликів, увійдіть у Control Hub, а потім перейдіть до . |
| 2 |
Виберіть детальну історію викликів. Інформацію про виклики за допомогою виділеного екземпляра див. в розділі Аналітика виділеного екземпляра. |
| 3 |
Щоб отримати доступ до даних про якість мультимедіа, увійдіть у Control Hub, потім перейдіть до Аналітика і виберіть Виклики. Додаткову інформацію див. в статті Аналітика для вашого портфеля рішень щодо співпраці в хмарі.
|
Запустити інструмент CScan
CScan — це інструмент перевірки готовності мережі, призначений для тестування підключення мережі до Webex Calling.
|
Додаткову інформацію див. в статті Використання CScan для тестування якості мережі Webex Calling. |
Впровадити CUBE High Availability як локальний шлюз
Основи
Обов’язкові умови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
-
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
-
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.
У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
-
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
-
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
-
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
-
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
-
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
-
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
-
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
-
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
-
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
-
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
-
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
-
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
-
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
-
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
-
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
-
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
-
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін
-
Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних
-
З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану
-
Під час аварійного перемикання попередньо активна платформа CUBE перезавантажується (передбачено розробкою), зберігаючи дані передачі сигналів і мультимедіа
Налаштування резервування на обох CUBE
Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.
| 1 |
Налаштуйте відстеження інтерфейсу на глобальному рівні з метою відстеження стану інтерфейсу.
CLI відстеження використовується в RG для відстеження стану інтерфейсу голосового трафіку, щоб після вимикання інтерфейсу активний маршрут більше не знаходився в активному стані. | ||
| 2 |
Налаштуйте RG для використання з HA VoIP в межах підрежиму резервування програми.
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 3 |
Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Налаштуйте RG на попередньому кроці в розділі
група резервування 1—Щоб додати та видалити цю команду, необхідно перезавантажити оновлену конфігурацію. Ми перезавантажимо платформи після застосування всієї конфігурації. | ||
| 4 |
Налаштуйте інтерфейси Gig1 і Gig2 за допомогою їхніх відповідних віртуальних IP-адрес, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii)
Нижче наведено пояснення полів, які використовуються в цій конфігурації.
| ||
| 5 |
Збережіть конфігурацію першої платформи CUBE й перезавантажте її. Платформа, яку було перезавантажено останньою, завжди знаходиться в резервному режимі.
Після повного завантаження платформи VCUBE-1 збережіть конфігурацію платформи VCUBE-2 й перезавантажте її.
| ||
| 6 |
Упевніться, що конфігурація типу Box-to-Box працює належним чином. Відповідні вихідні дані виділено жирним. Ми перезавантажили платформу VCUBE-2 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі Standby (Резервний). VCUBE |
Налаштування локального шлюзу на обох CUBE
У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.
-
Ім’я користувача: Хуссейн1076_ЛГУ
-
Пароль: lOV12MEaZx
| 1 |
Упевніться, що для пароля створено ключ конфігурації за допомогою наведених нижче команд, перш ніж його можна буде використовувати в облікових даних або спільних секретах. Паролі 6-го типу шифруються за допомогою шифру AES і цього ключа конфігурації, визначеного користувачем. LocalGateway#conf Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. Облікові дані дайджест SIP з Control Hub виділені жирним шрифтом .
Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE |
| 2 |
У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show. show redundancy application group 1 показати стан реєстрації sip-ua VCUBE VCUBE З виводу вище можна побачити, що VCUBE-2 є активним LGW, який підтримує реєстрацію за допомогою Webex Calling access SBC, тоді як вивід "показати стан реєстрації sip-ua" порожній у VCUBE-1 |
| 3 |
Тепер увімкніть наведені нижче налагодження у VCUBE-1
|
| 4 |
Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2. VCUBE Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище
|
| 5 |
Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. VCUBE-2 вже має бути перезавантажено.
VCUBE-1 наразі є активним локальним шлюзом. |
| 6 |
Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну IP-адресу й отримує повідомлення «200 OK». VCUBE
|
Огляд Webex Calling
Уявіть, що ви можете використовувати хмарні функції викликів, мобільності й PBX корпоративного рівня разом із програмою Webex для обміну повідомленнями, нарад і викликів із програмного клієнта Webex Calling або пристрою Cisco. Усі ці можливості доступні у Webex Calling.
Webex Call надає такі функції та переваги:
-
Виклик підписок для користувачів телефонії та зон загального користування.
-
Безпечні та надійні хмарні сервіси, що надаються надійними регіональними постачальниками послуг
-
Доступ до додатків Webex для кожного користувача, додаючи багаті уніфіковані комунікації та служби спільної роботи в команді.
-
Webex Meetings як необов’язковий інтегрований додатковий модуль для надання преміальних можливостей для проведення нарад, яких очікують корпоративні користувачі.
-
Доступ до загальнодоступних телефонних мереж (ТМЗК), щоб дозволити користувачам набирати номери за межами організації. Послуга надається через наявну інфраструктуру підприємства.
-
Локальний шлюз без локального IP PBX
-
Наявне середовище виклику Unified CM
-
Надані партнером або Cisco параметри ТМЗК
-
-
Підтримка Tier 1, що надається вашим партнером, підтримка наступного рівня, що надається компанією Cisco
Control Hub – це вебпортал керування, який інтегрується з Webex Calling, щоб оптимізувати замовлення та конфігурацію та централізувати керування пакетною пропозицією — Webex Calling, програма Webex і Webex Meetings.
|
Функція |
Опис |
|---|---|
|
Автосекретар |
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Можна створити 24-годинний розклад або налаштувати різні параметри для робочого й неробочого часу. Можна навіть маршрутизувати виклики на основі атрибутів ідентифікатора абонента, що телефонує, щоб створювати VIP-списки або по-різному обробляти виклики, які надходять з певних кодів населеного пункту. |
|
Черга викликів |
Якщо ви не можете відповісти на вхідні виклики, можна налаштувати чергу викликів. Ви можете надати абонентам, що телефонують, автоматичну відповідь, заспокійливі повідомлення та музику на утриманні, поки хтось не зможе відповісти на їхній виклик. |
|
Прийняти виклик |
Можна покращити командну роботу та співпрацю, створивши групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий. |
|
Паркування викликів |
Можна ввімкнути паркування викликів, щоб дозволити користувачам розміщувати виклик на утриманні та підхоплювати його з іншого телефону. |
|
Група пошуку |
Необхідність налаштувати групи пошуку може виникнути в наведених нижче випадках.
|
|
Пейджингова група |
Можна створити пейджингову групу, щоб користувачі могли надсилати голосові повідомлення для особи, відділу або робочої групи. Коли хтось надсилає повідомлення пейджинговій групі, це повідомлення відтворюється на всіх пристроях у групі. |
|
Клієнт-секретар |
Забезпечте підтримку персоналу свого фронт-офісу, надавши користувачам повний набір параметрів керування викликами, можливість розгорнутого відстеження ліній, створення черг викликів, кілька варіантів параметрів каталогів і їхніх подань, використання інтеграції Outlook тощо. |
|
Функція |
Опис |
|---|---|
|
Відхилення анонімних викликів |
Користувачі можуть відхиляти вхідні виклики з заблокованими ідентифікаторами абонента, що телефонує. |
|
Безперервність бізнес-процесів |
Якщо телефони користувачів не підключені до мережі з такої причини, як перебої в живленні, проблеми мережі тощо, користувачі можуть переадресовувати вхідні виклики на певний номер телефону. |
|
Переадресація викликів |
Користувачі можуть переадресувати вхідні виклики на інший телефон. |
|
Вибіркова переадресація викликів |
Користувачі можуть переадресувати виклики в певний час від певних абонентів. Це налаштування матиме пріоритет над функцією «Переадресація викликів». |
|
Сповіщення про виклик |
Користувачі можуть надсилати собі електронний лист у разі отримання виклику відповідно до заздалегідь визначених критеріїв, як-от номера телефону або дати й часу. |
|
Виклик на очікуванні |
Користувачі можуть дозволити відповідати на додаткові вхідні виклики. |
|
Не турбувати |
Користувачі можуть тимчасово дозволити всім викликам спрямовуватися безпосередньо на голосову пошту. |
|
Office Anywhere |
Користувачі можуть використовувати вибрані телефони («розташування») як додатковий номер свого робочого номера телефону й абонентської групи. |
|
Пріоритетне сповіщення |
Користувачі можуть налаштувати спеціальний сигнал виклику на телефоні, який буде відтворюватися відповідно до заздалегідь визначених критеріїв, як-от номера телефону або дати й часу. |
|
Віддалений офіс |
Користувачі можуть здійснювати виклики з віддаленого телефону, й вони будуть відображатися як виклики з їхнього робочого номера телефону. Крім того, будь-які вхідні виклики на бізнес-лінію дзвонять на цьому віддаленому телефоні. |
|
Вибіркове прийняття викликів |
Користувачі можуть приймати виклики в певний час від певних абонентів. |
|
Вибіркове відхилення викликів |
Користувачі можуть відхиляти виклики в певний час від певних абонентів. |
|
Послідовний дзвінок |
Вхідні виклики можуть послідовно надходити не більше ніж на 5 пристроїв. |
|
Одночасний дзвінок |
Вхідні виклики можуть одночасно надходити на номери користувачів і інших абонентів («отримувачів викликів»). |
Підготовка служб, пристроїв і користувачів у Control Hub, перехресний запуск до детальної конфігурації на порталі адміністрування викликів
Control Hub (https://admin.webex.com) — це портал керування, який інтегрується з Webex Calling, щоб оптимізувати замовлення та конфігурацію та централізувати керування пакетною пропозицією — Webex Calling, програма Webex і Meetings.
З Control Hub починається підготовка всіх служб, пристроїв і користувачів. Тут можна виконати початкове налаштування служби викликів, зареєструвати телефони MPP в хмарі (використовуючи MAC-адресу), налаштувати користувачів шляхом зв’язування пристроїв, додавання номерів, послуг, функцій виклику тощо. Крім того, з Control Hub можна виконати перехресний запуск порталу адміністрування Calling.
Можливості користувачів
Користувачі мають доступ до наведених нижче інтерфейсів.
-
Програма Webex Calling: програмний клієнт для викликів під брендом Cisco. Додаткову інформацію див. в статті Огляд нової програми Cisco Webex Calling.
-
Налаштування Webex (https://settings.webex.com) — інтерфейс, за допомогою якого користувачі можуть встановлювати бажані параметри профілю, завантажити програму Webex і перехресний запуск на користувацький портал Calling для налаштування викликів. Додаткову інформацію див. в статті Змінювання налаштувань Cisco Webex.
-
Програма Webex — програма, яку включено до передплати як клієнт для обміну повідомленнями в команді під брендом Cisco. Додаткову інформацію див. в статті Початок роботи з програмою Cisco Webex.
-
Webex Meetings — додаткова програма, яку додано як рішення для нарад. Додаткову інформацію див. в статті Webex Meetings.
Адміністратори клієнтів
Як адміністратор клієнта з пробною версією або платною підпискою Webex Calling, ви можете налаштувати свою організацію в Control Hub, додавши розташування, ліцензії, номери телефонів, функції викликів, користувачів і робочі області (кімнатні пристрої, що реєструються в хмарі Webex). Ви також можете керувати всіма цими компонентами звідти.
-
Додаткову інформацію про пропозицію Webex Calling див. в Cisco Webex Calling у Cisco Collaboration Flex Plan для кінцевих клієнтів.
Партнери
Як постачальник партнерських послуг, ви можете брендувати, продавати та продавати Webex Calling своїм клієнтам. Ви можете налаштувати та розширити пробні версії, розгорнути послуги для своїх клієнтів, а також створювати та надавати замовлення для своїх клієнтів.
Доступність
Див. заголовок Webex Calling у статті Де доступний Cisco Webex для країн, де Webex Calling доступний для продажу.
Огляд Control Hub
Control Hub — це єдиний зручний вебінтерфейс для керування організацією і користувачами, призначення служб, аналізу тенденцій запровадження та якості викликів тощо.
Щоб забезпечити злагоджену роботу організації, рекомендується запросити кількох користувачів приєднатися до програми Webex. Для цього необхідно ввести їхні адреси електронної пошти в Control Hub. Заохочуйте користувачів використовувати надані вами служби, включно з викликами, і надавати вам відгуки про їхню роботу. За необхідності ви завжди можете додати інших користувачів.
Для доступу в Control Hub рекомендовано використовувати останню настільну версію Google Chrome або Mozilla Firefox. Використання браузерів на мобільних пристроях, а також інших настільних браузерів може призвести до непередбачуваних результатів.
Нижче наведено зведену інформацію щодо можливих сценаріїв під час налаштування служб в організації. Більш докладну інформацію наведено в окремих розділах із покроковими інструкціями.
Початок роботи
Після того як ваш партнер створить ваш обліковий запис, ви отримаєте привітальний електронний лист. Клацніть посилання Початок роботи в електронному листі. Для доступу до Control Hub використовуйте Chrome або Firefox. Посилання забезпечить автоматичний вхід із використанням вашої адреси електронної пошти адміністратора. Далі вам буде запропоновано створити пароль адміністратора.
Майстер початкового налаштування пробних версій
Якщо ваш партнер зареєстрував для вас використання пробної версії, майстер налаштування буде запущено автоматично після входу в Control Hub. Майстер виконає базові налаштування, щоб забезпечити для організації роботу Webex Calling разом з іншими службами. Перед завершенням роботи майстра можна налаштувати й перевірити налаштування Calling.
Перевірка налаштувань
Перевірити налаштування можна під час завантаження Control Hub.
Додавання користувачів
Після налаштування служб можна додати користувачів із каталогу вашої компанії. У розділі Користувачі виберіть Керування користувачами.
У разі використання Microsoft Active Directory рекомендується спочатку ввімкнути синхронізацію каталогу, а потім вибрати спосіб додавання користувачів. Клацніть Далі й дотримуйтеся інструкцій щодо налаштування з’єднувача каталогів Cisco.
Налаштування єдиного входу (SSO)
Програма Webex використовує базову автентифікацію. Можна налаштувати SSO, щоб користувачі автентифікувалися за допомогою постачальника ідентифікаційних даних підприємства за допомогою його корпоративних облікових даних, а не окремого пароля, що зберігається та керується у Webex.
Перейдіть до розділу Налаштування, прокрутіть сторінку до пункту Автентифікація, клацніть Змінити, а потім виберіть Інтегрувати стороннього постачальника посвідчень.
Призначення служб користувачам
Щоб користувачі, яких було додано, могли почати користуватися програмою Webex, потрібно призначити їм служби.
У розділі Користувачі клацніть Керування користувачами, виберіть Експорт і імпорт користувачів за допомогою файлу CSV, а потім клацніть Експорт.
У завантаженому файлі просто додайте значення True для служб, які необхідно призначити кожному з користувачів.
Імпортуйте готовий файл, клацніть Додавання і видалення служб, а потім клацніть Надіслати. Тепер можна розпочати налаштування функцій виклику, зареєструвати пристрої, до яких можна буде надати спільний доступ на загальному робочому місці, а також зареєструвати пристрої та зв’язати їх із користувачами.
Розширення можливостей користувачів
Тепер, коли користувачів додано і їм призначено служби, вони можуть почати використовувати свої підтримувані багатоплатформові телефони (MPP) для Webex Calling і програму Webex для обміну повідомленнями й нарад. Порадьте їм використовувати налаштування Cisco Webex як універсальний інструмент доступу.
Роль локального шлюзу
Локальний шлюз — це граничний пристрій (корпоративний або керований партнером), який використовується для взаємодії з телефонною мережею загального користування (PSTN) або застарілими внутрішніми телефонними мережами (включно з Unified CM).
За допомогою Control Hub можна призначити локальний шлюз розташуванню, після чого Control Hub надасть параметри, які можна налаштувати в CUBE. Ці кроки забезпечать реєстрацію локального шлюзу в хмарі. Після цього служба PSTN буде надаватися через шлюз користувачам Webex Calling у певному розташуванні.
Щоб вибрати й замовити локальний шлюз, ознайомтеся з посібником із замовлення локального шлюзу.
Підтримувані розгортання локальних шлюзів для Webex Calling
Підтримуються наведені нижче базові розгортання.
Локальний шлюз може бути розгорнуто автономно або в розгортаннях, де потрібна інтеграція в Cisco Unified Communications Manager.
Розгортання локального шлюзу без локальної внутрішньої телефонної мережі з підтримкою IP
Автономні розгортання локальних шлюзів
На цьому малюнку зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до одного розташування або розгортання з кількома розташуваннями.
Webex Calling направляє всі виклики, які не відповідають вашим призначенням Webex Calling, для обробки на локальний шлюз, призначений розташуванню. Локальний шлюз маршрутизує всі виклики, які надходять від Webex Calling, до PSTN і у зворотному напрямку — з PSTN до Webex Calling.
Шлюз PSTN може бути виділеною платформою або розміщеним спільно з локальним шлюзом. Як зображено на малюнку нижче, для цього розгортання рекомендується вибрати виділений шлюз PSTN. Цей варіант можна використовувати, якщо наявний шлюз PSTN не можна використовувати як локальний шлюз Webex Calling.
Розгортання спільно розміщеного локального шлюзу
Локальний шлюз може працювати на базі IP (підключення до ITSP виконується за допомогою SIP-транку) або TDM (підключення за допомогою ISDN або аналогової схеми). На малюнку нижче зображено розгортання Webex Calling, де локальний шлюз є спільно розміщеним зі шлюзом PSTN або SBC.
Розгортання локального шлюзу з локальною внутрішньою телефонною мережею Unified CM
Інтеграція з Unified CM потрібна в наведених нижче випадках.
-
Розташування з підтримкою Webex Calling додано до наявного розгортання Cisco UC, де Unified CM розгорнуто як локальне рішення для керування викликами
-
Між телефонами, зареєстрованими в Unified CM, і телефонами в розташуваннях Webex Calling необхідний прямий набір.
На цьому малюнку показано розгортання Webex Calling, де клієнт має наявну внутрішню телефонну мережу Unified CM із підтримкою IP.
Webex Calling надсилає виклики, які не відповідають призначенням Webex Calling клієнта, на локальний шлюз. Сюди відносяться номери PSTN і внутрішні додаткові номери Unified CM, які Webex Calling не може розпізнати. Локальний шлюз маршрутизує всі виклики, які надходять від Webex Calling, до Unified CM і навпаки. Потім Unified CM маршрутизує вхідні виклики до локальних призначень або в PSTN відповідно до наявної абонентської групи. Абонентська група Unified CM нормалізує номери у формат +E.164. Шлюз PSTN може бути виділеним або розміщеним спільно з локальним шлюзом.
Виділений шлюз PSTN
Варіант із виділеним шлюзом PSTN цього розгортання, як показано на цій схемі, є рекомендованим варіантом і може використовуватися, якщо наявний шлюз PSTN не можна використовувати як локальний шлюз Webex Calling.
Шлюз PSTN, розміщений спільно
На цьому малюнку зображено розгортання Webex Calling з Unified CM, де локальний шлюз є спільно розміщеним зі шлюзом PSTN або SBC.
Webex Calling маршрутизує всі виклики, які не відповідають призначенням Webex Calling клієнта, на локальний шлюз, який призначено розташуванню. Сюди відносяться призначення PSTN і виклики в середині мережі на внутрішні додаткові номери Unified CM. Локальний шлюз маршрутизує всі виклики в Unified CM. Потім Unified CM маршрутизує виклики на локально зареєстровані телефони або в PSTN через локальний шлюз, який має функціональні можливості PSTN або SBC.
Відомості щодо маршрутизації викликів
Здійснення викликів із Webex Calling в Unified CM
Логіка маршрутизації Webex Calling: якщо номер, який набрано на термінальному пристрої Webex Calling, не може бути маршрутизовано до будь-якого іншого призначення в межах одного клієнта у Webex Calling, цей виклик для подальшої обробки спрямовується до локального шлюзу. Усі виклики поза мережею (за межами Webex Calling) спрямовуються до локального шлюзу.
Якщо розгортання Webex Calling виконано без інтеграції в наявну систему Unified CM, будь-який виклик поза мережею вважається викликом PSTN. У разі поєднання з Unified CM виклик поза мережею все ще може бути викликом усередині мережі до будь-якого призначення, розміщеного в Unified CM, або реальним викликом поза мережею до призначення PSTN. Відмінність між двома останніми типами викликів визначається Unified CM і залежить від корпоративної абонентської групи, яку підготовлено в Unified CM.
На схемі нижче показано набір національного номера в США користувачем Webex Calling.
Unified CM тепер базується на налаштованій абонентській групі й маршрутизує виклик на локально зареєстрований термінальний пристрій, де призначення виклику підготовлено як номер абонента. Для цього абонентська група Unified CM повинна підтримувати маршрутизацію на номери +E.164.
Здійснення викликів з Unified CM у Webex Calling
Щоб увімкнути маршрутизацію викликів з Unified CM до Webex Calling, в Unified CM необхідно підготувати набір маршрутів для визначення набору номерів +E.164, а у Webex Calling адреси групи корпоративних номерів.
За наявності цих маршрутів можливі обидва сценарії викликів, наведені на малюнку нижче.
Якщо абонент у мережі PSTN телефонує на номер DID, який призначено пристрою Webex Calling, виклик спрямовується в організацію через її шлюз PSTN, а потім до Unified CM. Адреса цього виклику, яку було набрано, відповідає одному з маршрутів Webex Calling, який підготовлено в Unified CM, і виклик спрямовується на локальний шлюз. (Адреса виклику повинна бути у форматі +E.164 під час надсилання до локального шлюзу.) Логіка маршрутизації Webex Calling потім упевніться, що виклик надіслано на призначений пристрій Webex Calling на основі призначення DID.
Крім того, виклики, які було ініційовано на зареєстрованих у Unified CM термінальних пристроях, адресовані призначенням у Webex Calling, залежать від абонентської групи, яку було підготовлено в Unified CM. Як правило, ця абонентська група дозволяє користувачам здійснювати виклики, використовуючи загальні корпоративні варіанти набору номерів в організації. Ці варіанти не обов’язково можуть включати тільки набір номерів +E.164. Щоб забезпечити правильну маршрутизацію у Webex Calling, будь-який варіант набору, який відрізняється від +E.164, необхідно нормалізувати у формат +E.164 перед тим, як виклики буде спрямовано на локальний шлюз.
Клас служби (CoS)
Завжди рекомендується впроваджувати обмеження вузького класу служб із різних причин, включно з метою уникнення циклів викликів і запобігання шахрайству з платними службами. У контексті інтеграції локального шлюзу Webex Calling із класом служби Unified CM потрібно враховувати клас служби наведених нижче варіантів.
-
Пристрої, зареєстровані в Unified CM
-
Виклики, що надходять в Unified CM з PST
-
Виклики, що надходять в Unified CM з Webex Calling
Пристрої, зареєстровані в Unified CM
Додати призначення Webex Calling як новий клас призначень до наявного налаштування класу служби досить просто: надання дозволу на виклик призначень Webex Calling зазвичай еквівалентно наданню дозволу на виклик локальних (у тому числі між об’єктами) призначень.
Якщо в корпоративній абонентській групі вже реалізовано дозвіл «(скорочений) внутрішньомережевий набір між об’єктами», це означає, що вже існує розділ, підготовлений в Unified CM, який можна використовувати, і необхідно підготувати всі відомі внутрішньомережеві призначення Webex Calling у тому ж розділі.
В іншому випадку поняття дозволу «(скорочений) внутрішньомережевий набір між об’єктами» ще не існує. Це означає, що потрібно підготувати новий розділ (наприклад, onNetRemote), додати до цього розділу призначення Webex Calling, і, нарешті, цей новий розділ потрібно додати до відповідних пошукових просторів виклику.
Виклики, що надходять в Unified CM з PST
Додати призначення Webex Calling як новий клас призначень до наявного налаштування класу служби досить просто: надання дозволу на виклик призначень Webex Calling зазвичай еквівалентно наданню дозволу на виклик локальних (у тому числі між об’єктами) призначень.
Якщо в корпоративній абонентській групі вже реалізовано дозвіл «(скорочений) внутрішньомережевий набір між об’єктами», це означає, що вже існує розділ, підготовлений в Unified CM, який можна використовувати, і необхідно підготувати всі відомі внутрішньомережеві призначення Webex Calling у тому ж розділі.
В іншому випадку поняття дозволу «(скорочений) внутрішньомережевий набір між об’єктами» ще не існує. Це означає, що потрібно підготувати новий розділ (наприклад, onNetRemote), додати до цього розділу призначення Webex Calling, і, нарешті, цей новий розділ потрібно додати до відповідних пошукових просторів виклику.
Виклики, що надходять в Unified CM з Webex Calling
Для викликів, які надходять із PSTN, потрібен доступ до всіх призначень Webex Calling. Для цього необхідно додати наведений вище розділ, що містить усі призначення Webex Calling, до простору пошуку викликів, який використовується для вхідних викликів у транку PSTN. Доступ до призначень Webex Calling надається на додаток до вже наявного доступу.
Для викликів із PSTN необхідний доступ до DID Unified CM і DID Webex Calling, а для викликів, які ініційовано у Webex Calling, необхідний доступ до DID Unified CM і призначень PSTN.
На цьому малюнку порівнюються два різних класи служби для викликів із PSTN і Webex Calling. На малюнку також показано, що у разі спільного розміщення функціональних можливостей шлюзу PSTN і локального шлюзу потрібні два транки від комбінованого шлюзу PSTN і локального шлюзу до Unified CM: один для викликів, які ініційовано в PSTN, і один для викликів, які ініційовано у Webex Calling. Це обумовлено вимогою застосовувати диференційовані простори пошуку викликів для кожного типу трафіку. Цього можна легко досягти за допомогою двох вхідних транків у Unified CM: необхідно налаштувати на кожному транку потрібний простір пошуку для вхідних викликів.
Інтеграція абонентської групи
Цей посібник передбачає наявне встановлення, яке базується на актуальних практичних порадах, наведених у розділі «Бажана архітектура для локальних розгортань рішень Cisco Collaboration, CVD». Остання версія доступна тут.
Рекомендований проєкт абонентської групи відповідає підходу до проєктування, який описано в розділі «Абонентська група» останньої версії SRND до системи Cisco Collaboration. Цей документ доступний тут.
На цьому малюнку показано огляд рекомендованого проєкту абонентської групи. Нижче наведено ключові характеристики цього проєкту абонентської групи.
-
Усі номери абонентів, які налаштовано в Unified CM, мають формат +E.164.
-
Усі номери абонентів знаходяться в одному розділі (DN), і їх позначено як термінові.
-
Основна маршрутизація базується на форматі +E.164.
-
Усі варіанти набору, які відрізняються від E.164 (наприклад, скорочений набір в об’єктах і набір номерів PSTN із використанням загальних варіантів набору номера), нормалізовано (глобалізовано) до формату +E.164 з використанням шаблонів перетворення нормалізації набору номера.
-
У шаблонах перетворення нормалізації набору номера використовується успадкування простору пошуку викликів у шаблоні перетворення. У цих шаблонах налаштовано параметр «Використовувати простір пошуку викликів джерела».
-
Клас служби впроваджується з використанням просторів пошуку викликів, специфічних для об’єкта й класу служби.
-
Можливості доступу до PSTN (наприклад, доступ до міжнародних призначень PSTN) впроваджуються шляхом додавання розділів з відповідними шаблонами маршрутів +E.164 до простору пошуку викликів, що визначає клас служби.
Досяжність Webex Calling
Щоб додати досяжність для призначень Webex Calling до цієї абонентської групи, необхідно створити розділ, що представляє всі призначення Webex Calling (під назвою Webex Calling), а також додати до цього розділу шаблон маршруту +E.164 для кожного діапазону DID у Webex Calling. Цей шаблон маршруту посилається на список маршрутів лише з одним учасником: група маршрутів із SIP-транком до локального шлюзу для викликів Webex Calling. Усі набрані призначення нормалізовано до +E.164 за допомогою шаблонів перетворення нормалізації набору для викликів, які ініційовано із зареєстрованих в Unified CM термінальних пристроїв, або перетворення номера абонента, якому телефонують для викликів, які ініційовано в PSTN. Тому цього єдиного набору шаблонів маршрутів +E.164 достатньо для досягнення досяжності призначень у Webex Calling, незалежно від використовуваного варіанта набору номера.
Наприклад, якщо користувач набирає номер 914085550165, то шаблон перетворення нормалізації набору номера в розділі UStoE164 нормалізує цей рядок набору в +14085550165, який потім відповідає шаблону маршруту для призначення Webex Calling у розділі Webex Calling. Unified CM у кінцевому підсумку спрямовує виклик на локальний шлюз.
Додавання скороченого міжоб’єктного набору
Рекомендованим способом додавання скороченого міжоб’єктного набору до вказаної абонентської групи є додавання шаблонів перетворення нормалізації набору для всіх об’єктів у групі корпоративних номерів до виділеного розділу (номер корпоративного значення, або ESN). Ці шаблони перетворення перехоплюють рядки набору у форматі групи корпоративних номерів і нормалізують набраний рядок у формат +E.164.
Щоб додати корпоративний скорочений набір до призначень Webex Calling, необхідно додати відповідний шаблон перетворення нормалізації набору для розташування Webex Calling до розділу Webex Calling (наприклад, 8101XX на схемі). Після процесу нормалізації виклик знову спрямовується до Webex Calling. Це виконується після відповідності шаблону маршруту в розділі Webex Calling.
Не рекомендується додавати шаблон перетворення нормалізації скороченого набору для викликів Webex Calling до розділу ESN, оскільки ця конфігурація може створювати небажані цикли маршрутизації викликів.
Обробники протоколів для Calling
Webex Calling реєструє наведені нижче обробники протоколів в операційній системі, щоб забезпечити доступ до функціональних можливостей швидких викликів із веббраузерів або іншої програми. Наступні протоколи починають аудіо- або відеовиклик у програмі Webex, коли ця програма використовується для викликів за замовчуванням на комп’ютері Mac або Windows:
-
CLICKTOCALL: або CLICKTOCALL://
-
SIP: або SIP://
-
TEL: або TEL://
-
WEBEXTEL: або WEBEXTEL://
Обробники протоколів для Windows
Інші програми можуть реєструвати обробники протоколів раніше за програму Webex. У Windows 10 передбачено системне вікно із запитом для користувачів щодо того, яку програму використовувати для запуску виклику. Встановивши прапорець у полі Завжди використовувати цю програму, можна запам’ятати налаштування користувача.
Якщо користувачам потрібно скинути налаштування програми для викликів за замовчуванням, щоб вони могли вибрати програму Webex, можна запропонувати їм змінити зв’язки протоколів для програми Webex у Windows 10.
-
Відкрийте розділ Налаштування програми за замовчуванням , клацніть Установити параметри за замовчуванням за програмою, а потім виберіть програму Webex.
-
Для кожного протоколу виберіть програму Webex.
Обробники протоколів для macOS
Якщо в Mac OS інші програми зареєстровано в протоколах викликів раніше за програму Webex, користувачі повинні налаштувати програму Webex як службу для викликів за замовчуванням.
У програмі Webex для Mac користувачі можуть підтвердити, що програму Webex вибрано для параметра Почати виклики, із налаштуванням у розділі загальних бажаних параметрів. Вони також можуть встановити прапорець параметра Завжди підключатися до Microsoft Outlook , якщо вони хочуть здійснювати виклики в програмі Webex, клацнувши номер контакту Outlook.
Підготовка середовища
Загальні передумови
Перш ніж налаштувати локальний шлюз для Webex Calling, переконайтеся, що ви:
-
Базові знання принципів VoIP
-
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
-
Базове розуміння протоколу ініціювання сеансу (SIP).
-
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Додаткову інформацію див. в Cisco Unified Border Element (CUBE) Enterprise Configuration Guide .
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Переконайтеся, що у вашому розгортанні є один або кілька локальних шлюзів, як-от:
-
Cisco CUBE для підключення на основі IP
-
Шлюз Cisco IOS для з’єднання на основі TDM
Локальний шлюз допомагає виконати міграцію до Webex Calling у вашому власному темпі. Локальний шлюз інтегрує наявне локальне розгортання з Webex Calling. Також можна використовувати наявне підключення до ТМЗК. Див. розділ Початок роботи з локальним шлюзом
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
Webex Calling вимагає безпечного варіанта передавання сигналів і мультимедіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
-
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
-
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
-
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
-
Надходить запит облікових даних (наданих SIP-дайджестом)
-
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Довідкова інформація щодо портів для Webex Calling
Правильно налаштований брандмауер і проксі необхідні для успішного розгортання Calling. Webex Calling використовує SIP і HTTPS для передавання сигналів виклику, а також пов’язані адреси та порти для медіа, мережевого з’єднання та з шлюзами, оскільки Webex Calling є глобальною службою.
Не всі конфігурації брандмауера потребують відкриття портів. Однак якщо ви виконуєте внутрішні правила, ви повинні відкрити порти для необхідних протоколів, щоб вимкнути служби.
Переклад мережевої адреси (NAT)
Функції перетворення мережевих адрес (NAT) і перетворення адрес порту (PAT) застосовуються на кордоні між двома мережами для перекладу просторів адрес або запобігання зіткненню просторів IP-адрес.
Організації використовують технології шлюзів, як-от брандмауери і проксі-сервери, що надають служби NAT або PAT, для надання доступу до інтернету до програм Webex або пристроїв Webex, що знаходяться в приватному просторі IP-адреси. Через ці шлюзи здається, що трафік від внутрішніх програм або пристроїв до інтернету надходить з однієї або кількох загальнодоступних IP-адрес, які можна маршрутизувати.
-
У разі розгортання NAT необов’язково відкривати вхідний порт на брандмауері.
-
Перевірте розмір пулу NAT, потрібний для підключення програми або пристроїв, коли кілька користувачів програми та пристроїв отримують доступ до служб визначення Webex Calling і Webex за допомогою NAT або PAT. Переконайтеся, що пулам NAT призначено належні публічні IP-адреси, щоб запобігти виснаженню портів. Виснаження портів призводить до того, що внутрішні користувачі та пристрої не можуть підключитися до служб Webex Calling і Webex Aware.
-
Визначте розумні періоди прив’язки та уникайте маніпулювання SIP на пристрої NAT.
-
Налаштуйте мінімальний тайм-аут NAT, щоб забезпечити належну роботу пристроїв. Приклад: Телефони Cisco надсилають повідомлення про оновлення РЕЄСТРУ подальшого спостереження кожні 1–2 хвилини.
-
Якщо у вашій мережі впроваджено NAT або SPI, установіть більший тайм-аут (принаймні 30 хвилин) для з’єднань. Цей тайм-аут дозволяє надійне підключення та одночасно знижує споживання заряду акумулятора мобільних пристроїв користувачів.
шлюз рівня застосунку SIP
Якщо маршрутизатор або брандмауер мають SIP Aware, що означає, що ввімкнено SIP Application Layer Gateway (ALG) або аналогічний рівень, рекомендуємо вимкнути цю функцію для точної роботи служби. Хоча увесь трафік Webex Calling зашифровано, деякі реалізації SIP ALG можуть спричинити проблеми з обходом брандмауера. Тому ми рекомендуємо вимкнути SIP ALG, щоб забезпечити високу якість обслуговування.
Перевірте відповідну документацію виробника, щоб визначити кроки для вимкнення SIP ALG на певних пристроях.
Підтримка проксі-сервера для Webex Calling
Організації розгортають інтернет-брандмауер або інтернет-проксі-сервер і брандмауер, щоб перевіряти, обмежувати та контролювати HTTP-трафік, який виходить із мережі та входить до неї. Таким чином, захищаючи свою мережу від різних форм кібератак.
Проксі-сервери виконують кілька функцій безпеки, наприклад:
-
Дозволити або блокувати доступ до певних URL-адрес.
-
Аутентифікація користувачів
-
Пошук репутації IP-адреси/домену/імені хоста/URI
-
Розшифровка та перевірка трафіку
У разі налаштування функції проксі вона застосовується до всіх програм, які використовують протокол HTTP.
Програма Webex і програми пристрою Webex включають наступне:
-
Служби Webex
-
Процедури активації пристрою клієнта (CDA) за допомогою платформи підготовки хмари Cisco, як-от GDS, EDOS, підготовка та приєднання до хмари Webex.
-
Автентифікація сертифіката
-
Оновлення мікропрограми
-
Звіти про стан
-
Вивантаження PRT
-
Служби XSI
Якщо налаштовано адресу проксі-сервера, на проксі-сервер надсилається лише трафік Сигналів (HTTP/HTTPS). Клієнти, які використовують SIP для реєстрації в службі Webex Calling, і пов’язані медіа, не надсилаються на проксі. Тому дозвольте цим клієнтам проходити безпосередньо через брандмауер.
Підтримувані параметри проксі, конфігурація та типи автентифікації
Підтримувані типи проксі:
-
Явний проксі (інспектування або неінспектування) — налаштуйте клієнти програми або пристрою з явним проксі-сервером, щоб указати сервер для використання.
-
Прозорий проксі (неінспектування) – клієнти не налаштовані на використання конкретної адреси проксі-сервера, і не потребують змін для роботи з проксі-сервером, що не інспектує.
-
Прозорий проксі (перевірка) – клієнти не налаштовані на використання конкретної адреси проксі-сервера. Зміни конфігурації HTTP не потрібні, однак вашим клієнтам або програмі, або пристроям потрібен кореневий сертифікат, щоб вони довіряли проксі. ІТ-команда використовує перевірку проксі-серверів для виконання політики на вебсайтах щодо відвідування та типів контенту, які заборонено.
Налаштуйте проксі-адреси вручну для пристроїв Cisco та програми Webex за допомогою:
-
ОС платформи
-
Інтерфейс користувача пристрою
-
Автоматично виявлено за допомогою механізмів Web Proxy, як-от:
-
Web Proxy Auto Discovery (WPAD) — протокол автоматичного виявлення веб-проксі
-
Файли автоматичної конфігурації проксі (PAC) — Файли автоматичної конфігурації проксі
-
Під час налаштування бажаних типів продуктів виберіть із таких конфігурацій проксі та типів автентифікації в таблиці:
|
Продукт |
Конфігурація проксі |
Тип автентифікації |
|---|---|---|
|
Webex для Mac |
Вручну, WPAD, PAC |
Немає автентифікації, Basic, NTLM,† |
|
Webex для Windows |
Вручну, WPAD, PAC, GPO |
Немає автентифікації, Basic, NTLM, †, узгодження † |
|
Webex для iOS |
Вручну, WPAD, PAC |
Без автентифікації, базова, дайджест, NTLM |
|
Webex для Android |
Вручну, PAC |
Без автентифікації, базова, дайджест, NTLM |
|
Webex Web App |
Підтримується через ОС |
Немає автентифікації, Basic, Digest, NTLM, узгодження † |
|
Пристрої Webex |
WPAD, PAC або вручну |
Без автентифікації, базова, дайджест |
|
IP-телефони Cisco |
Вручну, WPAD, PAC |
Без автентифікації, базова, дайджест |
|
Video Mesh Node у Webex |
Вручну |
Без автентифікації, базова, дайджест, NTLM |
Для легенд у таблиці:
-
†Автентифікація Mac NTLM – не потрібно входити до комп’ютера на домен, користувачу запропоновано пароль
-
†Автентифікація Windows NTLM — підтримується, лише якщо комп’ютер увійшов на домен
-
Узгоджуйте †- Kerberos із резервною автентифікацією NTLM.
-
Щоб підключити пристрій серії Cisco Webex Board, Desk або Room до проксі-сервера, див. розділ Підключити пристрій серії Board, Desk або Room до проксі-сервера.
-
Для IP-телефонів Cisco див. Налаштування проксі-сервера як приклад налаштування проксі-сервера та налаштувань.
Щоб Немає автентифікації, налаштуйте клієнт за допомогою проксі-адреси, яка не підтримує автентифікацію. Під час використання автентифікації проксі налаштуйте за допомогою допустимих облікових даних. Проксі-сервери, які перевіряють веб-трафік, можуть перешкоджати з'єднанню веб-сокетів. У разі виникнення цієї проблеми може вирішити проблему шляхом обходу неінспекційного трафіку на сайт *.Webex.com. Якщо ви вже бачите інші записи, додайте крапку з комою після останнього запису, а потім введіть виняток Webex.
Налаштування проксі для Windows OS
Microsoft Windows підтримує дві мережеві бібліотеки для HTTP-трафіку (WinINet і WinHTTP), які дозволяють конфігурацію проксі-сервера.WinINet є надмножиною WinHTTP.
-
WinInet розроблений для однокористувацьких застосунків для настільних ПК
-
WinHTTP розроблений насамперед для багатокористувацьких серверних програм.
Вибираючи між двома параметрами, виберіть WinINet для налаштувань конфігурації проксі. Подробиці див. у розділі wininet-vs-winhttp.
Додаткові відомості див. у розділі Налаштування списку дозволених доменів для доступу до Webex у вашій корпоративній мережі .
-
Щоб користувачі входили в програми, використовуючи облікові записи з попередньо визначеного списку доменів.
-
Використовуйте проксі-сервер для перехоплення запитів і обмеження дозволених доменів.
Перевірка проксі й закріплення сертифіката
Програма й пристрої Webex перевіряють сертифікати серверів, коли вони встановлюють сеанси TLS. Сертифікати перевіряють, що емітент сертифікатів і цифровий підпис залежать від перевірки ланцюжка сертифікатів до кореневого сертифіката. Щоб виконати перевірки перевірки, програма Webex і пристрої використовують набір довірених кореневих сертифікатів CA, установлених у сховищі довірених сертифікатів операційної системи.
Якщо ви розгорнули проксі-перевірку TLS для перехоплення, дешифрування та перевірки трафіку Webex Calling. Переконайтеся, що сертифікат, який надає проксі (замість сертифіката служби Webex), підписаний центром сертифікації, а кореневий сертифікат установлено в сховищі довірених даних вашої програми Webex або пристрою Webex.
-
Для програми Webex установіть сертифікат ЦС, який використовується для підписання сертифіката проксі-сервером в операційній системі пристрою.
-
Для пристроїв Webex Room і багатоплатформових IP-телефонів Cisco відкрийте запит на обслуговування до команди TAC для встановлення сертифіката CA.
У цій таблиці наведено програму Webex і пристрої Webex, які підтримують перевірку TLS проксі-серверами
|
Продукт |
Підтримує перевірку TLS для користувацьких довірених ЦС |
|---|---|
|
Програма Webex (для Windows, Mac, iOS, Android, інтернету) |
Так |
|
Пристрої Webex Room |
Так |
|
Багатоплатформові IP-телефони Cisco (MPP) |
Так |
Конфігурація брандмауера
Cisco підтримує служби Webex Calling і Webex Aware у захищених центрах обробки даних Cisco й Amazon Web Services (AWS). Amazon зарезервувала свої IP-підмережі для виняткового використання Cisco й забезпечила служби, розташовані в цих підмережах, у віртуальному приватному хмарі AWS.
Налаштуйте брандмауер, щоб дозволити зв’язок із ваших пристроїв, застосунків і служб, пов’язаних із Інтернетом, виконувати свої функції належним чином. Ця конфігурація дозволяє отримати доступ до всіх підтримуваних хмарних служб Webex Calling і Webex Aware, доменних імен, IP-адрес, портів і протоколів.
Список білих або відкрийте доступ до наведеного нижче, щоб служби Webex Calling і Webex Aware працювали правильно.
-
URL-адреси/домени, зазначені в розділі Домени та URL для служб Webex Calling
-
IP-підмережі, порти та протоколи, зазначені в розділі IP-підмережі для служб Webex Calling
-
Якщо ви використовуєте Webex Suite хмарних служб співпраці в межах їхньої організації, консолі оператора Webex Meetings, обміну повідомленнями, консолі оператора Webex та інші служби, переконайтеся, що у вас є IP-підмережі, для доменів/URL, згаданих у цих статтях, відкрито Вимоги до мережі для служб Webex і Вимоги до мережі для консолі оператора.
Якщо ви використовуєте лише брандмауер, фільтрування трафіку Webex Calling лише за допомогою IP-адрес не підтримується, оскільки деякі пули IP-адрес динамічні й можуть змінитися в будь-який час. Регулярно оновлюйте правила. Нездатність оновлювати список правил брандмауера може вплинути на досвід ваших користувачів. Cisco не схвалює фільтрування підмножини IP-адрес за конкретним географічним регіоном або постачальником хмарних послуг. Фільтрування за регіонами може призвести до серйозної деградації можливостей викликів.
Cisco не підтримує динамічну зміну пулів IP-адрес, тому його не перелічено в цій статті.
Якщо ваш брандмауер не підтримує фільтрування домену/URL, скористайтеся параметром корпоративного проксі-сервера. Цей параметр фільтрує/дозволяє за URL/доменом трафік HTTP, що передають сигнали до служб Webex Calling і Webex Aware на проксі-сервері перед переадресацією у брандмауер.
Можна налаштувати трафік за допомогою фільтрації портів і підмережі IP для медіавикликів. Оскільки медіатрафік вимагає прямого доступу до інтернету, виберіть параметр фільтрування URL-адрес для сигнального трафіку.
Для Webex Calling UDP є бажаним транспортним протоколом Cisco для медіафайлів, і він рекомендує використовувати лише SRTP замість UDP. TCP і TLS як транспортні протоколи для медіа не підтримуються для Webex Calling у виробничих середовищах. Орієнтований на зв’язок характер цих протоколів впливає на якість мультимедіа в мережах з втратами. Якщо у вас є запити щодо транспортного протоколу, надішліть запит до служби підтримки.
Домени та URL-адреси для служб Webex Calling
*, що відображається на початку URL-адреси (наприклад, *.webex.com), означає, що служби в домені верхнього рівня та на всіх субдоменах доступні.
|
Домен / URL |
Опис |
Програми й пристрої Webex, які використовують ці домени або URL-адреси |
|---|---|---|
|
Служби Cisco Webex | ||
|
*.broadcloudpbx.com |
Мікросервіси авторизації Webex для перехресного запуску від Control Hub до порталу виклику адміністратора. |
Control Hub |
|
*.broadcloud.com.au |
Служби Webex Calling в Австралії. |
Усе |
|
*.broadcloud.eu |
Служби Webex Calling в Європі. |
Усе |
|
*.broadcloudpbx.net |
Конфігурація клієнта Calling і керування послугами. |
Програми Webex |
|
*.webex.com *.cisco.com |
Основні служби Webex Calling і Webex Aware
Коли телефон вперше підключається до мережі або після відновлення заводських налаштувань без установлених параметрів DHCP, він контактує з сервером активації пристрою для надання нульової сенсорної інформації. Нові телефони використовують activate.cisco.com і телефони з випуском мікропрограми раніше 11.2(1), продовжуйте використовувати для підготовки вебзастосунків.cisco.com. Завантажте оновлення мікропрограми пристрою та локалізації з binaries.webex.com. Дозвольте телефонам Cisco Multiplatform Phones (MPP) старіше версії 12.0.3 отримувати доступ до sudirenewal.cisco.com через порт 80 для подовження встановленого сертифіката виробника (MIC) та наявності безпечного унікального ідентифікатора пристрою (SUDI). Додаткову інформацію див. в Повідомленні про поля. |
Усі |
|
*.ucmgmt.cisco.com |
Служби Webex Calling |
Control Hub |
|
*.wbx2.com та *.ciscospark.com |
Використовується для обізнаності хмари для зв’язку зі службами Webex Calling і Webex Aware під час приєднання та після. Ці служби необхідні для
|
Усі |
|
*.webexapis.com |
Мікрослужби Webex, які керують вашими програмами програми Webex і пристроями Webex.
|
Усі |
|
*.webexcontent.com |
Служби обміну повідомленнями Webex, пов’язані з загальним сховищем файлів, зокрема:
|
Служби обміну повідомленнями для програм Webex. Сховище файлів за допомогою webexcontent.com замінено на clouddrive.com у жовтні 2019 року |
|
*.accompany.com |
Інтеграція People Insights |
Програми Webex |
|
Додаткові служби, пов’язані з Webex (сторонні домени) | ||
|
*.appdynamics.com *.eum-appdynamics.com |
Відстеження продуктивності, запис помилок і аварійних збоїв, показники сеансу. |
Control Hub |
|
*.sipflash.com |
Служби керування пристроями. Оновлення версії мікропрограми та безпечна реєстрація. |
Програми Webex |
|
*.walkme.com *.walkmeusercontent.com |
Клієнт посібника користувача Webex. Надає інструкції з приєднання і використання для нових користувачів. Щоб отримати додаткову інформацію про WalkMe, клацніть тут. |
Програми Webex |
|
*.google.com *.googleapis.com |
Сповіщення для програм Webex на мобільних пристроях (приклад: нове повідомлення, коли отримано відповідь на виклик) Для IP-підмереж див. ці посилання Служба Google Firebase Cloud Messaging (FCM) Служба сповіщень Apple Push (APNS) Для APNS Apple перелічує IP-підмережі для цієї служби. | Додаток Webex |
Підмережі IP для служб Webex Calling
|
IP-підмережі для служб Webex Calling*† | ||
|---|---|---|
|
23.89.0.0/16 |
85.119.56.0/23 |
128.177.14.0/24 |
|
128.177.36.0/24 |
135.84.168.0/21 |
139.177.64.0/21 |
|
139.177.72.0/23 |
144.196.0.0/16 |
150.253.128.0/17 |
|
163.129.0.0/17 |
170.72.0.0/16 |
170.133.128.0/18 |
|
185.115.196.0/22 |
199.19.196.0/23 |
199.19.199.0/24 |
|
199.59.64.0/21 | ||
|
Керування конфігурацією пристрою та мікропрограмою (відхилення Cisco) | ||
|
3.20.185.219 |
3.130.87.169 |
3.134.166.179 |
|
52.26.82.54 |
72.163.10.96/27 |
72.163.15.64/26 |
|
72.163.15.128/26 |
72.163.24.0/23 |
72.163.10.128/25 |
|
173.37.146.128/25 |
173.36.127.0/26 |
173.36.127.128/26 |
|
173.37.26.0/23 |
173.37.149.96/27 |
192.133.220.0/26 |
|
192.133.220.64/26 | ||
|
Конфігурація програми Webex | ||
|
62.109.192.0/18 |
64.68.96.0/19 |
150.253.128.0/17 |
|
207.182.160.0/19 | ||
|
Мета підключення | Адреси джерела | Порти джерела | Протокол | Адреси призначення | Порти призначення | Примітки | |
|---|---|---|---|---|---|---|---|
| Передавання сигналів виклику до Webex Calling (TLS SIP) | Зовнішній (NIC) локального шлюзу | 8000-65535 | TCP | Див. розділ Підмережі IP для служб Webex Calling. | 5062, 8934 |
Ці IP-адреси/порти необхідні для передавання сигналів виклику SIP-TLS від локальних шлюзів, пристроїв і програм Webex (джерело) до хмари Webex Calling (призначення). Порт 5062 (вимагається для транка на основі сертифіката). І порт 8934 (вимагається для транка на основі реєстрації | |
| Пристрої | 5060-5080 | 8934 | |||||
| Додаток Webex | Тимчасовий (залежить від ОС) | ||||||
| Передавання сигналів виклику від Webex Calling (SIP TLS) до локального шлюзу |
Діапазон адрес Webex Calling. Посилання на IP-підмережі для служб Webex Calling | 8934 | TCP | Вибрана клієнтом IP-адреса або діапазон IP-адрес для локального шлюзу | Порт або діапазон портів, вибраний клієнтом для локального шлюзу. |
Застосовується до локальних шлюзів на основі сертифіката. Необхідно встановити з’єднання від Webex Calling до локального шлюзу. Локальний шлюз на основі реєстрації працює над повторним використанням з’єднання, створеного з локального шлюзу. Порт призначення – клієнт вибрав Налаштувати транки. | |
| Носії викликів у Webex Calling (STUN, SRTP/SRTCP, T38, DTLS) | Зовнішній NIC локального шлюзу | 8000-48199†* | UDP | Див. розділ Підмережі IP для служб Webex Calling. |
5004, 9000 (порти STUN) Аудіо: 8500-8599 Відео: 8600-8699 19560-65535 (SRTP через UDP) |
| |
| Пристрої†* | 19560-19661 | ||||||
|
Пристрої VG400 ATA | 19560-19849 | ||||||
| Програма Webex†* |
Аудіо: 8500-8599 Відео: 8600-8699 | ||||||
|
WebRTC | Ефемерний (згідно з політикою браузера) | ||||||
| Медіафайли викликів із Webex Calling (SRTP/SRTCP, T38) |
Діапазон адрес Webex Calling. Посилання на IP-підмережі для служб Webex Calling | 19560-65535 (SRTP через UDP) | UDP | Вибрана клієнтом IP-адреса або діапазон IP-адрес для локального шлюзу | Діапазон медіапортів, вибраний клієнтом для локального шлюзу. | ||
| Передавання сигналів виклику до шлюзу PSTN (TLS SIP) | Внутрішній NIC локального шлюзу | 8000-65535 | TCP | Ваш шлюз PSTN ITSP або Unified CM | Залежить від параметра PSTN (наприклад, зазвичай для Unified CM використовується 5060 або 5061) | ||
| Виклик медіафайлів на шлюз PSTN (SRTP/SRTCP) | Внутрішній NIC локального шлюзу | 8000-48199†* | UDP | Ваш шлюз PSTN ITSP або Unified CM | Залежить від параметра ТМЗК (наприклад, зазвичай 5060 або 5061 для Unified CM) | ||
| Конфігурація пристрою і керування мікропрограмним забезпеченням (пристрої Cisco) | Пристрої Webex Calling | Короткотерміновий | TCP |
Посилання на IP-підмережі для служб Webex Calling | 443, 6970, 80 |
Вимагається з таких причин:
| |
| Конфігурація програми Webex | Програми Webex | Короткотерміновий | TCP |
Посилання на IP-підмережі для служб Webex Calling | 443, 8443 | Використовується для автентифікації Id Broker, служб конфігурації програми Webex для клієнтів, вебдоступу на основі браузера для самообслуговування Та доступу до Адміністративного інтерфейсу. Порт TCP 8443 використовується програмою Webex у налаштуванні Cisco Unified CM для завантаження конфігурації. Відкривати порт повинні лише клієнти, які використовують налаштування для підключення до Webex Calling. | |
| Синхронізація часу пристрою (NTP) | Пристрої Webex Calling | 51494 | UDP | Див. розділ Підмережі IP для служб Webex Calling. | 123 | Ці IP-адреси необхідні для синхронізації часу на пристроях (телефони MPP, ATA й SPA ATA) | |
|
Роздільна здатність системи доменних імен (DNS) | Пристрої Webex Calling, програма Webex і пристрої Webex | Короткотерміновий | UDP й TCP | Визначив хост | 53 | Використовується для пошуку DNS з метою виявлення IP-адрес служб Webex Calling у хмарі. Хоча типові пошуки DNS виконуються через UDP, деякі з них можуть потребувати TCP, якщо відповіді запиту не вписуються в пакети UDP. | |
| Протокол мережевого часу (NTP) | Програма Webex і пристрої Webex | 123 | UDP | Визначив хост | 123 | Синхронізація часу | |
| CScan | Інструмент підготовки до кваліфікації для Webex Calling на основі вебмережі | Короткотерміновий | TCP | Див. розділ Підмережі IP для служб Webex Calling. | 8934 і 443 | Інструмент для попередньої кваліфікації готовності до мережі для Webex Calling. Додаткову інформацію див. на сторінці cscan.webex.com. | |
| UDP | 19569-19760 | ||||||
| Додаткові служби Webex Calling і Webex Aware (третя сторона) | |||||||
| Push-сповіщення APNS і служби FCM | Програми Webex Calling | Короткотерміновий | TCP |
Посилання на IP-підмережі, зазначені за посиланнями | 443, 2197, 5228, 5229, 5230, 5223 | Сповіщення для програм Webex на мобільних пристроях (приклад: Коли ви отримаєте нове повідомлення або на виклик) | |
-
†*Діапазон медіапорту CUBE можна налаштувати за допомогою діапазону порту rtp.
-
†*Медіапорти для пристроїв і програм, динамічно призначені в діапазонах портів SRTP. Порти SRTP є парними номерами, а відповідний порт SRTCP виділений з послідовним непарним номером порту.
-
Якщо для ваших програм і пристроїв налаштовано адресу проксі-сервера, трафік сигналів буде надіслано на проксі. Мультимедіа, які транспортують SRTP через потоки UDP безпосередньо до вашого брандмауера замість проксі-сервера.
-
Якщо ви використовуєте служби NTP і DNS у своїй корпоративній мережі, відкрийте порти 53 і 123 через брандмауер.
Якість обслуговування (QoS)
Дозволяє ввімкнути позначення пакетів із локального пристрою або клієнта на хмарну платформу Webex Calling. Завдяки QoS можна визначити пріоритет трафіку в реальному часі над іншим трафіком даних. Увімкнення цього параметра призведе до зміни маркування QoS для програм і пристроїв, які використовують сигнали SIP та медіафайли.
| Адреси джерела | Тип трафіку | Адреси призначення | Порти джерела | Порти призначення | Клас і значення DSCP |
|---|---|---|---|---|---|
| Додаток Webex | Аудіо |
Посилання на IP-підмережі, домени та URL-адреси для служб Webex Calling | 8500-8599 | 8500-8599, 19560-65535 | Прискорена переадресація (46) |
| Додаток Webex | Відео | 8600-8699 | 8600-8699, 19560-65535 | Гарантована переадресація 41 (34) | |
| Додаток Webex | Передавання сигналів | Тимчасовий (залежить від ОС) | 8934 | cs0 (0) | |
| Пристрої Webex (MPP і кімната) | Аудіо та відео | 19560-19661 | 19560-65535 |
Прискорена переадресація (46) & Гарантована переадресація 41 (34) | |
| Пристрої Webex | Передавання сигналів | 5060-5080 | 8934 | Селектор класу 3 (24) |
-
Створіть окремий профіль QoS для аудіо- та відео- та спільного доступу, оскільки вони мають інший діапазон портів джерела для різних позначок трафіку.
-
Для клієнтів Windows: Щоб увімкнути диференціацію вихідного порту UDP для вашої організації, зверніться до команди локальних облікових записів. Якщо цей параметр не ввімкнено, ви не можете розрізнити аудіо та відео/спільний доступ за допомогою політики QoS Windows (GPO), оскільки вихідні порти однакові для аудіо/відео/спільного доступу. Додаткову інформацію див. в розділі Увімкнути діапазони портів джерела медіа для програми Webex
-
Для пристроїв Webex налаштуйте зміни налаштувань QoS у налаштуваннях пристрою Control Hub. Додаткову інформацію див. в розділі Налаштування та зміна налаштувань пристрою у Webex-Calling.
Webex Meetings / обмін повідомленнями: вимоги до мережі
Для клієнтів, які використовують Webex Suite хмарних служб співпраці, зареєстрованих у хмарі продуктами Webex, вбудувати пристрої MPP до хмари Webex для таких служб, як історія викликів, пошук у каталозі, наради та обмін повідомленнями. Переконайтеся, що домени/URL/IP-адреси/порти, зазначені в цій статті, відкриті вимоги до мережі для служб Webex.
Вимоги до мережі для Webex for Government
Для клієнтів, які потребують списку доменів, URL-адрес, діапазонів IP-адрес і портів для Webex for Government Services (FedRAMP), інформацію можна знайти тут: Вимоги до мережі для Webex for Government
Вимоги до мережі для консолі оператора Webex
Для клієнтів, які використовують консоль оператора – функцію секретарів, секретарів і операторів, переконайтеся, що в розділі «Домени/URL/IP-адреси/порти/протоколи» відкрито Вимоги до мережі для консолі оператора.
Початок роботи з локальним шлюзом Webex Calling
Для клієнтів, які використовують рішення локального шлюзу з Webex Calling для локальних ТМЗК і сторонніх SBC, ознайомтеся зі статтею Початок роботи з локальним шлюзом.
Посилання
Щоб дізнатися, що нового у Webex Calling, перегляньте розділ Нові можливості у Webex Calling.
Вимоги Безпеки для Webex Calling див. в статті
Стаття Оптимізація мультимедіа Webex Calling із інтерактивним установленням підключення (ICE)
Історія перегляду документа
|
Дата |
До цієї статті внесено наведені нижче зміни |
|---|---|
|
21 січня 2025 року |
Додано відомості про використання шлюзу рівня застосунку SIP. |
|
8 січня 2025 року |
Переміщено адресу IP-підмережі, пов’язану з конфігурацією пристрою та конфігурацією програми Webex, у розділ IP-підмережі для служб Webex Calling . |
|
17 грудня 2024 року |
До WebRTC додано підтримку для специфікації мультимедіа Webex Calling. |
|
14 листопада 2024 року |
Оновлено підтримуваний діапазон портів для медіафайлів викликів Webex Calling для пристрою ATA серії VG400. |
|
11 листопада 2024 року |
Додано підтримуваний діапазон портів для медіафайлів викликів Webex Calling для пристрою ATA серії VG400 |
|
25 липня 2024 року |
Додано IP-підмережу 52.26.82.54, оскільки вона є обов’язковою для конфігурації пристрою Cisco ATA та керування мікропрограмою. |
|
18 липня 2024 року |
Оновлено з наступними деталями:
|
|
28 червня 2024 року |
Оновлено використання обох діапазонів портів SRTP/ SRTCP для специфікації медіафайлів Webex Calling. |
|
11 червня 2024 року |
Домен "huron-dev.com" видалено, оскільки він не використовується. |
|
06 травня 2024 р. |
Оновлено використання обох діапазонів портів SRTP/ SRTCP для специфікації медіафайлів Webex Calling. |
|
03 квітня 2024 р. | Підмережі IP для служб Webex Calling оновлено на рівні 163.129.0.0/17, щоб адаптувати розширення ринку Webex Calling для регіону Індії. |
|
18 грудня 2023 року |
Включено URL-адресу sudirenewal.cisco.com та вимоги до порту 80 для конфігурації пристрою та керування мікропрограмним забезпеченням подовження МІКРОФОНА телефону Cisco MPP. |
|
11 грудня 2023 року |
Підмережі IP для служб Webex Calling оновлено, щоб включити більший набір IP-адрес. 150.253.209.128/25 – змінено на 150.253.128.0/17 |
|
29 листопада 2023 року |
Підмережі IP для служб Webex Calling оновлено, щоб включити більший набір IP-адрес для забезпечення розширення регіону Webex Calling для подальшого зростання. 144.196.33.0/25 – змінено на 144.196.0.0/16 Для ясності щодо транкінгу на основі сертифіката та вимог брандмауера для локального шлюзу оновлено підмережі IP для Webex Calling (SIP TLS) і медіафайлів викликів на Webex Calling (STUN, SRTP). |
|
14 серпня 2023 р. |
Ми додали такі IP-адреси 144.196.33.0/25 і 150.253.156.128/25 для підтримки додаткових вимог до місткості для служб Edge і Webex Calling. Цей діапазон IP-адрес підтримується лише в регіоні США. |
|
5 липня 2023 року |
Додано посилання, https://binaries.webex.com щоб установити мікропрограму Cisco MPP. |
|
7 березня 2023 р. |
Ми переглянули всю статтю, щоб включити:
|
|
5 березня 2023 р. |
Оновлення статті, щоб включити таке:
|
|
15 листопада 2022 р. |
Для конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco) додано такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco):
|
|
14 листопада 2022 року |
Додано IP-підмережу 170.72.242.0/24 для служби Webex Calling. |
|
Вересень 08, 2022 |
Мікропрограма Cisco MPP переходить на використання https://binaries.webex.com як URL-адреса організатора для оновлення версії мікропрограми MPP в усіх регіонах. Ця зміна підвищує продуктивність оновлення мікропрограми. |
|
Серпень 30, 2022 |
Посилання на порт 80 видалено з розділу «Конфігурація пристрою та керування мікропрограмним забезпеченням (пристрої Cisco)», конфігурація застосунку та рядки CScan у таблиці «Порт», оскільки немає залежності. |
|
Серпень 18, 2022 |
Жодних змін у рішенні. Оновлено порти призначення 5062 (необхідні для багажника на основі сертифікатів), 8934 (необхідні для каналу реєстрації) для сигналізації виклику до Webex Calling (SIP TLS). |
|
Липень 26, 2022 |
Додано IP-адресу 54.68.1.225, яка потрібна для оновлення прошивки пристроїв Cisco 840/860. |
|
Липень 21, 2022 |
Оновлено порти призначення 5062, 8934 для сигналізації виклику до Webex Calling (SIP TLS). |
|
Липень 14, 2022 |
Додано URL-адреси, які підтримують повну функцію служб Webex Aware. Додано IP-підмережу 23.89.154.0/25 для служби Webex Calling. |
|
Червні 27, 2022 |
Оновлено домен та URL-адреси для послуг Webex Calling: *.broadcloudpbx.com *.broadcloud.com.au *.broadcloud.eu *.broadcloudpbx.net |
|
Червні 15, 2022 |
Додано такі порти та протоколи в розділі IP-адреси та порти для послугвиклику Webex:
Оновлена інформація в розділі Webex Meetings/Messaging — Вимоги до мережі |
|
Травень 24, 2022 |
Додано IP-підмережу 52.26.82.54/24 до 52.26.82.54/32 для послуги Webex Calling |
|
Травень 6, 2022 |
Додано IP-підмережу 52.26.82.54/24 для послуги Webex Calling |
|
7 квітня 2022 р. |
Діапазон внутрішніх і зовнішніх портів UDP локального шлюзу оновлено до 8000-48198† |
|
5 квітня 2022 р. |
Додано наступні підмережі IP для служби Webex Calling:
|
|
29 березня 2022 р. |
Додано наступні підмережі IP для служби Webex Calling:
|
|
20 вересня 2021 р. |
Додано 4 нові підмережі IP для служби Webex Calling:
|
|
2 квітня 2021 р. |
Додано *.ciscospark.com у розділі Домени та URL-адреси для служб Webex Calling для підтримки випадків використання Webex Calling у програмі Webex. |
|
25 березня 2021 р. |
Додано 6 нових діапазонів IP-адрес для activate.cisco.com. Термін дії набуває чинності з 8 травня 2021 року.
|
|
4 березня 2021 р. |
Замінено дискретні IP-адреси Webex Calling і менші діапазони IP зі спрощеними діапазонами в окремій таблиці для зручності розуміння конфігурації брандмауера. |
|
26 лютого 2021 р. |
Додано 5004 як порт призначення для виклику медіа до Webex Calling (STUN, SRTP) для підтримки інтерактивного встановлення зв'язку (ICE), яке буде доступне у Webex Calling у квітні 2021 року. |
|
22 лютого 2021 р. |
Домени і URL тепер перелічено в окремій таблиці. Таблиця IP-адрес і портів налаштована з урахуванням групових IP-адрес для тих самих служб. Додавання стовпця Примітки до таблиці IP-адрес і портів, що допоможе вам зрозуміти вимоги. Переміщення таких IP-адрес у спрощені діапазони для конфігурації пристроїв і керування мікропрограмним забезпеченням (пристрої Cisco):
Додавання таких IP-адрес для конфігурації застосунку, оскільки клієнт Cisco Webex вказує на новіший DNS SRV в Австралії у березні 2021 року.
|
|
21 січня 2021 р. |
До конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco) додано такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco):
Ми додали до конфігурації застосунку такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації застосунку:
Ми видалили з конфігурації застосунку такі номери портів:
До конфігурації застосунку додано такі домени:
|
|
23 грудня 2020 р. |
До довідкових зображень портів додано нові IP-адреси конфігурації програм. |
|
22 грудня 2020 р. |
В рядок «Конфігурація програми» в таблицях додано наступні IP-адреси: 135.84.171.154 і 135.84.172.154. Приховуйте мережеві діаграми, доки не буде додано ці IP-адреси. |
|
11 грудня 2020 р. |
Оновлено конфігурацію пристрою і систему керування мікропрограмним забезпеченням (пристрої Cisco), а також рядки конфігурації програми для підтримуваних канадських доменів. |
|
16 жовтня 2020 р. |
Оновлено сигнальні й мультимедійні записи з використанням таких IP-адрес:
|
|
23 вересня 2020 р. |
У CScan замінено 199.59.64.156 на 199.59.64.197. |
|
14 серпня 2020 р. |
Додано додаткові IP-адреси для підтримки впровадження центрів обробки даних у Канаді: Передавання сигналів виклику до Webex Calling (TLS SIP): 135.84.173.0/25, 135.84.174.0/25, 199.19.19.197.0/24, 199.19.199.0/24 |
|
12 серпня 2020 р. |
Додано додаткові IP-адреси для підтримки впровадження центрів обробки даних у Канаді:
|
|
22 липня 2020 р. |
Додано наступну IP-адресу для підтримки впровадження центрів обробки даних у Канаді: 135.84.173.146 |
|
9 червня 2020 р. |
До запису CScan внесено наведені нижче зміни.
|
|
11 березня 2020 р. |
Ми додали такі домени та IP-адреси до конфігурації застосунку:
У розділі конфігурації пристрою і керування мікропрограмним забезпеченням оновлено наступні домени (додано додаткові IP-адреси):
|
|
27 лютого 2020 р. |
У розділі конфігурації пристрою і керування мікропрограмним забезпеченням додано наступний домен і порти: cloudupgrader.webex.com—443, 6970 |
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Огляд
Webex Calling наразі підтримує дві версії локального шлюзу:
-
Локальний шлюз
-
Локальний шлюз для Webex for Government
-
Перед початком ознайомтеся з вимогами локальної телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise на використання як функції локального шлюзу для Webex Calling, зверніть увагу на цю конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функціональність через внесені вами зміни.
Процедури містять посилання на довідкову документацію з команд, де ви можете дізнатися більше про окремі параметри команд. Якщо не зазначено інше, посилання на команди перейдуть до посилання на команди керованих шлюзів Webex (у такому випадку посилання на команди перейдуть до посилання на голосові команди Cisco IOS). Усі ці посібники можна отримати за посиланням на команди Cisco Unified Border Element.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації щодо продуктів.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифіката , щоб налаштувати локальний шлюз для вашого транка Webex Calling.
Додаткову інформацію про різні типи транка див. в розділі Початок роботи з локальним шлюзом . Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціювання сеансу (SIP) і протокол безпеки транспортного рівня (TLS) для захисту транка, а протокол безпеки в реальному часі (SRTP) для захисту медіафайлів між локальним шлюзом і Webex Calling.
-
Виберіть CUBE як локальний шлюз. Webex for Government наразі не підтримує жодних сторонніх контролерів прикордонних сеансів (SBC). Щоб переглянути останній список, див. розділ Початок роботи з локальним шлюзом.
- Установіть Cisco IOS XE Dublin 17.12.1a або пізніші версії для всіх Webex для державних локальних шлюзів.
-
Щоб переглянути список кореневих органів сертифікації (CA), які підтримує Webex for Government, див. розділ Кореневі органи сертифікації для Webex for Government.
-
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex for Government див. в статті Вимоги до мережі для Webex for Government (FedRAMP).
Локальний шлюз для Webex for Government не підтримує таке:
-
STUN/ICE-Lite для оптимізації шляху медіафайлів
-
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex for Government, скористайтеся таким параметром.
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у локальному шлюзі на основі сертифіката , щоб налаштувати локальний шлюз для транка Webex Calling. Додаткову інформацію про налаштування локального шлюзу на основі сертифіката див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Необхідно налаштувати шифри GCM, сумісні з FIPS, для підтримки локального шлюзу для Webex for Government. Якщо ні, не вдасться налаштувати виклик. Додаткові відомості про конфігурацію див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Webex for Government не підтримує локальний шлюз на основі реєстрації.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи SIP-транк, що реєструється. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. На наведеному нижче зображенні висвітлено це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2. Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3. Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштувати локальний шлюз з існуючим уніфікованим середовищем CM
Або:
-
Крок 3. Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі реєстрації потребують Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовано використовувати Cisco IOS 17.12.2 або пізнішої версії. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу.
-
Передайте пакет кореневого CA Cisco до локального шлюзу.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть реєстраційні дані та облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так:
|
| 3 |
Створіть точку довіри PKI-заповнювача. Ця точка довіри вимагає, щоб налаштувати TLS пізніше. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це було б потрібно для транка на основі сертифіката. |
| 4 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням за допомогою наступних команд конфігурації. Також необхідно оновити параметри транспортування, щоб забезпечити надійне безпечне з'єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволяє з’єднання, якщо ім’я хоста, налаштоване в клієнті 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистого URL-адреси , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Зверніть увагу на інформацію про транк, яка надається після його створення. Деталі, виділені на ілюстрації, використовуються в кроках конфігурації цього посібника. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистика медіаЗабезпечує моніторинг медіафайлів на локальному шлюзі. масові стани медіаДозволяє площині управління опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див. у розділі Медіа. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базової функції оператора SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Додаткову інформацію див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропозиції набору шифру SRTP CUBE в SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шаблон для ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте dtg=, після чого вказується значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 7 |
Налаштуйте профіль SIP 100, який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 8 |
Налаштуйте транк Webex Calling: |
Після визначення клієнта 100 та налаштування вузла набору SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі доступ SBC надає свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат доступу SBC Webex Calling за допомогою кореневої групи CA, яка була оновлена раніше. Якщо сертифікат розпізнано, між локальним шлюзом і доступом Webex Calling SBC встановлюється постійний сеанс TLS. Потім локальний шлюз може використовувати це захищене з’єднання, щоб зареєструватися в системі доступу Webex SBC. Коли з’являється проблема реєстрації на автентифікацію:
-
У відповіді використовуються параметри ім’я користувача, пароль і області з конфігурації облікових даних .
-
Правила модифікації в sip профілі 100 використовуються для перетворення URL SIPS назад у SIP.
Реєстрація успішна, коли 200 OK отримано з SBC доступу.
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. CUBE підтримує безпечну маршрутизацію виклику.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.13Задає цільову адресу для викликів, надісланих постачальнику ТМЗК. Це може бути IP-адреса або ім’я хоста DNS. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає клас голосового зв’язку, який використовується для зіставлення вхідних викликів із цим одноранговим абонентом за допомогою ЗАПРОШЕННЯ ЧЕРЕЗ URI заголовка. Додаткову інформацію див. в URL-адресу вхідного виклику. ідентифікатор сертифікації sip-класу голосового типу pai
(Необов’язково) Вмикає обробку заголовка P-Asserted-Identity і керує тим, як він використовується для транка ТМЗК. Якщо використовується ця команда, для заголовків вихідних параметрів From і P-Asserted-Identity використовуватиметься ідентифікатор абонента, що телефонує, наданий від вхідного однорангового абонента для вихідних викликів. Якщо ця команда не використовується, для заголовків ідентифікатора абонента, що телефонує, наданий із вхідного абонента для набору, використовуватиметься ідентифікатор абонента, що телефонує, а також для заголовків ідентифікатора віддаленого абонента. Додаткову інформацію див. в розділі sip asserted-id для голосового класу. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0
Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
Якщо вам не потрібна оптимізація IP-медіафайлів, виконайте кроки конфігурації для SIP ТМЗК-транка. Використовуйте голосовий порт і вузол набору POTS (як показано в кроках 2 і 3) замість вузла набору VoIP ТМЗК.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
Під час створення транка Webex Calling у Unified CM переконайтеся, що вхідний порт у параметрах профілю безпеки SIP-транка налаштовано на 5065. Це дозволяє вхідні повідомлення на порту 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. Також можна встановити DS для автоматичного збору діагностичних даних і перенесення зібраних даних до випадку Cisco TAC, щоб прискорити час роздільної здатності.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. Визначити логіку виявлення проблем можна за допомогою повідомлень syslog, подій SNMP і періодичного моніторингу певних виходів команд show.
Типи дій включають збір результатів команд показу:
-
Створення об'єднаного файлу журналу
-
Передавання файлу в надане користувачем мережеве розташування, як-от сервер HTTPS, SCP або FTP.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз працює IOS XE 17.6.1a або новіша
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте безпечний сервер електронної пошти, щоб використовувати його для надсилання проактивних сповіщень, якщо пристрій працює з Cisco IOS XE 17.6.1a або пізнішої версії.
налаштувати сервер електронної пошти термінального виклику :@ пріоритет 1 безпечний кінець tls -
Налаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора для сповіщення.
налаштування середовища діагностики-підпису термінального виклику-домашнього ds_email
Нижче наведено приклад конфігурації локального шлюзу, який працює в Cisco IOS XE 17.6.1a або новішої версії для надсилання проактивних сповіщень на адресу tacfaststart@gmail.com за допомогою Gmail як безпечного сервера SMTP:
Рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або новіші версії.
сервер електронної пошти виклику tacfaststart:password@smtp.gmail.com пріоритет 1 безпечне середовище діагностичного підпису TLS ds_email "tacfaststart@gmail.com" Локальний шлюз, запущений на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати певні налаштування облікового запису Gmail і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Перейдіть до розділу й увімкніть параметр Менш безпечний доступ до програми .
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Використовуйте команду показати snmp , щоб увімкнути SNMP. Якщо його не ввімкнути, налаштуйте команду snmp-server manager .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR серії або Cisco CSR 1000V серії
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# копіювати ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису виклику на домашній номер телефону DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання CPU в локальному шлюзі.
Моніторинг реєстрації SIP-транка
Ця DS перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Після виявлення події скасування реєстрації буде створено сповіщення електронною поштою та системного лотка й видалено після двох повторень скасування реєстрації. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64117.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Завантажити файл DS_64117.xml успішно LocalGateway# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Використовуйте команду показати snmp , щоб перевірити, чи ввімкнено SNMP. Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
Завантаження діагностичного підпису на домашній виклик DS_65221.xml Успішно завантажено файл DS_65221.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Інсталяція діагностичних сигнатур для виправлення неполадок
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Діагностичні підписи (DS) позбавляють необхідності вручну перевіряти виникнення проблеми та значно полегшують виправлення переривних та тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, який рекомендується інженером TAC як частину підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix , яка є шляхом сервера файлів Cisco TAC (cxd.cisco.com), на який передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати з Диспетчера запитів підтримки у наведеній нижче команді. Маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки, якщо необхідно.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику на домашній номер ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Упевніться, що SNMP увімкнено за допомогою команди показати snmp . Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
Завантаження діагностичного підпису домашнього виклику DS_64224.xml Завантаження файлу DS_64224.xml успішне завантаження файлу DS_65095.xml Завантаження файлу DS_65095.xml успішно -
Упевніться, що підпис успішно встановлено за допомогою команди показати виклик-домашній діагностичний підпис . Стовпець стану повинен мати значення "зареєстровано".
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08
Перевірка виконання діагностичних підписів
"У наступній команді стовпець ""Стан"" команди показати виклик-домашній діагностичний підпис зміниться на ""Запустити"", тоді як локальний шлюз виконує дію, визначену в підписі." Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS із виводу команди показати виклик-домашній діагностичний підпис і запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Для кращого керування шлюзами Cisco IOS XE рекомендуємо зареєструвати шлюзи й керувати ними через Control Hub. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub для перевірки конфігурації локального шлюзу та виявлення будь-яких проблем з конфігурацією. Зараз цю функцію підтримують лише транки на основі реєстрації.
Додаткову інформацію див. в наступному.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою взаємного SIP-транка TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. Наведене нижче зображення висвітлює це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні. Надано параметри для загальнодоступних або приватних (за NAT) адрес. Записи DNS SRV необов’язкові, за винятком випадків, коли балансування навантаження між кількома екземплярами CUBE.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2. Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3. Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштувати локальний шлюз з існуючим уніфікованим середовищем CM
Або:
-
Крок 3. Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі сертифікатів потребують Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовано використовувати Cisco IOS XE 17.12.2 або пізнішої версії. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
Для вимог до високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і додаткове право на пропускну здатність.
Додаткову інформацію див. в розділі Коди авторизації .
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
ntp
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу. Адреси локального шлюзу з повними доменними іменами (FQDN) або записом служби (SRV), налаштовані в Control Hub, мають зіставити з загальнодоступною IPv4-адресою в інтернеті.
-
Усі порти SIP і медіафайлів в інтерфейсі локального шлюзу, що facing Webex, повинні бути доступними з інтернету безпосередньо або через статичний NAT. Упевніться, що брандмауер було оновлено належним чином.
-
Виконайте наведені нижче докладні кроки конфігурації, щоб установити підписаний сертифікат на локальний шлюз:
-
Загальнодоступний центр сертифікації (CA), докладний у розділі Які кореневі органи сертифікації підтримуються для викликів на аудіо- та відеоплатформи Cisco Webex? , повинен підписати сертифікат пристрою.
-
Спільне ім’я суб’єкта сертифіката (CN) або одне з альтернативних імен суб’єкта (SAN) має збігатися з повним доменним ім’ям, налаштованим у Control Hub. Наприклад:
-
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді CN або SAN у сертифікаті маршрутизатора має містити cube1.lgw.com.
-
Якщо налаштований транк у Control Hub вашої організації має lgws.lgw.com як адресу SRV локальних шлюзів, доступну з транка, тоді CN або SAN у сертифікаті маршрутизатора має містити lgws.lgw.com. Записи, до яких вирішується адреса SRV (CNAME, A Record або IP-адреса), не є обов'язковими в SAN.
-
Незалежно від того, чи використовується ви FQDN або SRV для транка, в адресі контакту для всіх нових діалогових вікон SIP з локального шлюзу необхідно використовувати ім’я, налаштоване в Control Hub.
-
-
Переконайтеся, що сертифікати підписані для використання клієнта й сервера.
-
-
Передайте пакет кореневого CA Cisco до локального шлюзу. Ця пакет містить кореневий сертифікат CA, який використовується для перевірки платформи Webex.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так: |
| 3 |
Створіть точку довіри шифрування за допомогою сертифіката для домену, підписаного підтримуваним центром сертифікації (CA). |
| 4 |
Надайте сертифікат CA проміжного підписання, який використовується для автентифікації вашого сертифіката організатора. Введіть таку команду виконання або конфігурації:
|
| 5 |
Імпортуйте підписаний сертифікат організатора за допомогою наведених далі команд виконання або конфігурації:
|
| 6 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням, яка буде використовуватися для голосових застосунків за допомогою таких команд конфігурації:
|
| 7 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистої url-адреси url , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. Зверніть увагу на інформацію про транк, яка надається після створення транка. Ці відомості, як підкреслено в наведеній нижче ілюстрації, використовуватимуться в кроках конфігурації цього посібника. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базового SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди stun потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Докладніше про цю команду див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. вхідні профілі sipДозволяє CUBE використовувати профілі SIP для зміни повідомлень під час їх отримання. Профілі застосовуються через однорангових абонентів або клієнтів. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Команда використання брандмауера й обходу потокових даних потрібна лише під час розгортання локального шлюзу за NAT. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропозиції набору шифру SRTP CUBE в SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шифри GCM, сумісні з FIPS (Цей крок застосовується лише для Webex for Government). Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає GCM як набір шифрів, який пропонує CUBE. Необхідно налаштувати шифри GCM для локального шлюзу для Webex for Government. |
| 7 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену призначення або SRV: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте повне доменне ім’я транка або SRV, налаштоване в Control Hub для транка. |
| 8 |
Налаштуйте профілі керування повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль так, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу: Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. |
| 9 |
Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP так. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу, "10.80.13.12" є IP-адресою інтерфейсу, що стикається з Webex Calling, а "192.65.79.20" є публічною IP-адресою NAT. Запит щодо правила 10 SIP для вихідних повідомлень для вихідних повідомлень до голосового класу Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. правила 30-81Перетворіть посилання на приватні адреси у зовнішню публічну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень від голосового класу Webex CallingОсь пояснення полів для конфігурації: правила 10-80Перетворіть посилання на публічні адреси в налаштовану приватну адресу, що дозволить CUBE обробляти повідомлення від Webex. Додаткову інформацію див. в sip-профілях голосового класу. Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 10 |
Налаштуйте параметри SIP для збереження з профілем зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль, який зберігається, і переходить у режим конфігурації класу голосового зв’язку. Можна налаштувати час (у секундах), коли сигнал SIP Out of Dialog Options надсилається цільовому набору, коли серцебиття з’єднання з кінцевим пристроєм перебуває в стані "ВГОРУ" або "Вниз". Цей профіль увімкнено з однорангового абонента, налаштованого на Webex. Щоб переконатися, що заголовки контактів містять повне доменне ім’я SBC, використовується SIP-профіль 115. Правила 30, 40 і 50 потрібні, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, вибраним для локального шлюзу, і якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC у напрямку Webex Calling, а "192.65.79.20" – загальнодоступною IP-адресою NAT. |
| 11 |
Налаштуйте транк Webex Calling: |
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. CUBE підтримує безпечну маршрутизацію виклику.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.13Задає цільову адресу для викликів, надісланих постачальнику ТМЗК. Це може бути IP-адреса або ім’я хоста DNS. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає клас голосового зв’язку, який використовується для зіставлення вхідних викликів із цим одноранговим абонентом за допомогою ЗАПРОШЕННЯ ЧЕРЕЗ URI заголовка. Додаткову інформацію див. в URL-адресу вхідного виклику. ідентифікатор сертифікації sip-класу голосового типу pai
(Необов’язково) Вмикає обробку заголовка P-Asserted-Identity і керує тим, як він використовується для транка ТМЗК. Якщо використовується ця команда, для заголовків вихідних параметрів From і P-Asserted-Identity використовуватиметься ідентифікатор абонента, що телефонує, наданий від вхідного однорангового абонента для вихідних викликів. Якщо ця команда не використовується, для заголовків ідентифікатора абонента, що телефонує, наданий із вхідного абонента для набору, використовуватиметься ідентифікатор абонента, що телефонує, а також для заголовків ідентифікатора віддаленого абонента. Додаткову інформацію див. в розділі sip asserted-id для голосового класу. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0
Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
Якщо вам не потрібна оптимізація IP-медіафайлів, виконайте кроки конфігурації для SIP ТМЗК-транка. Використовуйте голосовий порт і вузол набору POTS (як показано в кроках 2 і 3) замість вузла набору VoIP ТМЗК.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події SNMP і за допомогою періодичного моніторингу конкретних виходів команд show для визначення логіки виявлення проблеми. До типів дій відносяться:
-
Збирання показаних командних виходів
-
Створення об'єднаного файлу журналу
-
Завантаження файлу на вказане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз, що працює під керуванням IOS XE 17.6.1 або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте безпечний сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо пристрій працює під керуванням IOS XE 17.6.1 або новішої версії.
налаштуйте сервер електронної пошти термінального виклику :@ пріоритет 1 безпечний кінець tls -
Налаштуйте змінну ds_email середовища з адресою електронної пошти адміністратора, про яку ви сповіщаєте.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_email кінець
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера snmp-сервера .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Доступ до ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0.064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик DS_64224.xml Успішно завантажено файл DS_64224.xml -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, будь ласка, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг ненормальних роз 'єднань дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t диспетчер snmp-сервера кінець показати snmp Шасі: Введення пакетів SNMP ABCDEFGHIGK 149655 0 Неправильних помилок версії SNMP 1 Невідоме ім’я спільноти 0 Надано неправильну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитаних змінних 2 Кількість змінених змінних 34560 Отримати-запит PDU 138 Отримати-наступні PDU 2 PDU-запити на встановлення 0 Краплі пакетів вхідних даних черги (максимальний розмір черги 1000) 158277 SNMP пакетів 0 Завеликі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імені 0 Неправильних значень 0 Загальні помилки 7998 Відповіді PDU 10280 PDU-пакети пасток PDU, що зараз перебувають у черзі введення процесу SNMP: 0 глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
завантаження діагностичного підпису на домашній виклик DS_65221.xml Успішно завантажено файл DS_65221.xml -
Використовуйте команду показати виклик-домашній діагностичний підпис , щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Діагностичні підписи (DS) також можна використовувати для швидкого вирішення проблем. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
За допомогою засобу пошуку діагностичних підписів можна знайти відповідні підписи та інсталювати їх для самостійного вирішення певної проблеми, або інсталювати підпис, рекомендований інженером TAC як частину підтримки підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Налаштуйте іншу змінну середовища DS ds_fsurl_prefix як шлях сервера файлів Cisco TAC (cxd.cisco.com) для передавання діагностичних даних. Ім’я користувача в шляху файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати в Диспетчер запитів підтримки , як показано нижче. За потреби маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки.
налаштуйте термінальний виклик-домашній діагностичний підпис LocalGateway(cfg-call-home-diag-sign)середовище ds_fsurl_prefix "scp://:@cxd.cisco.com" endПриклад:
середовище діагностичного підпису виклику ds_fsurl_prefix " середовище ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
показати snmp %SNMP оператор не ввімкнуто конфігурацію t кінець менеджера snmp-сервера -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
скопіюйте ftp://username:password@/DS_64224.xml bootflash: копіювати ftp://username:password@/DS_65095.xml bootflash: -
Установіть файл DS 64224 для моніторингу CPU, а потім файл DS 65095 XML у локальний шлюз.
завантаження діагностичного підпису домашнього виклику DS_64224.xml Завантаження файлу DS_64224.xml успішне завантаження файлу DS_65095.xml Завантаження файлу DS_65095.xml успішно -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DSLGW_IEC_C_all_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець "Стан" команди показує діагностичний підпис виклику додому змінюється на "запущений", поки Локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи діагностичний підпис виявляє подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати виклик-домашній діагностичний підпис Поточні налаштування діагностичного підпису: Діагностичний підпис: увімкнений профіль: CiscoTAC-1 (стан: активний) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/РІК |
23.053 |
23.053 |
Повідомлення електронної пошти зі сповіщенням, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення вихідних команд, які мають відношення до усунення несправностей із цією проблемою.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблем. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS з виводу показу діагностичного підпису виклику додому та запустіть таку команду:
видалення діагностичного підпису для виклику на домашній номер Приклад:
видалення діагностичного підпису на домашній виклик 64224 До засобу пошуку діагностичних сигнатур періодично додаються нові підписи на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Налаштування Webex Calling для організації
Налаштування параметрів викликів у майстрі першого встановлення
Першим кроком для отримання і запуску служб Webex Calling є виконання налаштування за допомогою майстра першого встановлення. Після того як майстер першого встановлення завершить налаштування для першого розташування, його не потрібно буде запускати для додаткових розташувань.
| 1 |
Клацніть посилання Початок роботи в привітальному електронному листі, який ви отримаєте. Ваша адреса електронної пошти адміністратора автоматично використовується для входу в Control Hub, де вам буде запропоновано створити пароль адміністратора. Після входу майстер налаштування буде запущено автоматично. |
| 2 |
Перегляньте й прийміть умови обслуговування. |
| 3 |
Перегляньте план і клацніть Початок роботи. За перші кроки з активації з використанням майстра першого встановлення відповідає ваш менеджер із роботи з клієнтами. У разі отримання сповіщення «Не вдалося налаштувати виклик» після натискання кнопки Початок роботи зверніться до менеджера із роботи з клієнтами. |
| 4 |
Виберіть країну, з якою слід зіставити ваш центр обробки даних, і введіть інформацію для контакту з клієнтом і адресу клієнта. |
| 5 |
Клацніть Далі. Розміщення за замовчуванням. |
| 6 |
Виберіть один із наведених далі варіантів.
Після завершення роботи майстра встановлення упевніться, що ви додаєте основний номер до створеного розташування. |
| 7 |
Налаштуйте наведені нижче параметри, які необхідно застосувати до цього розташування.
|
| 8 |
Клацніть Далі. |
| 9 |
Введіть доступну SIP-адресу Cisco Webex, клацніть Далі й виберіть Завершити. |
Додавання розташування
Перш ніж почати
Щоб створити нове розташування, підготуйте наведену далі інформацію.
-
Адреса розташування
-
Бажані номери телефону (необов’язково)
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . Нове розташування буде розміщено в регіональному центрі обробки даних, яке відповідає країні, яку ви вибрали за допомогою майстра першого встановлення. |
| 2 |
Налаштуйте параметри розташування.
|
| 3 |
Натисніть кнопку Зберегти , а потім виберіть так / ні , щоб додати номери до розташування зараз або пізніше. |
| 4 |
Якщо ви натиснули кнопку Так, виберіть один із наступних параметрів:
Вибір параметра PSTN доступний на рівні кожного розташування (кожне розташування має лише один параметр PSTN). Можна вибрати скільки завгодно параметрів для вашого розгортання, але кожне розташування матиме один параметр. У разі необхідності змінити параметр PSTN, коли його вибрано й підготовлено, клацніть Керування у властивостях PSTN розташування. Однак деякі параметри, як-от PSTN Cisco, можуть бути недоступні після призначення іншого параметра. Створіть запит до служби підтримки , щоб отримати інструкції. |
| 5 |
Виберіть, чи потрібно активувати номери зараз або пізніше. |
| 6 |
Якщо вибрано неінтегровану CCP або PSTN на базі локальних ресурсів, введіть номери телефону як значення, розділені комами, а потім клацніть Перевірити. Номери додаються для певного розташування. Допустимі записи буде переміщено до поля Перевірені номери, а неприпустимі записи залишаться в полі Додати номери, яке буде супроводжуватися повідомленням про помилку. Залежно від країни розташування номери буде відформатовано відповідно до місцевих вимог набору номера. Наприклад, якщо код країни є обов’язковим, можна ввести номери з кодом або без нього, і код буде додано. |
| 7 |
Клацніть Зберегти. |
Що далі
Після створення розташування можна ввімкнути для цього розташування служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
Видалити розташування
Перед початком
Після видалення користувачів і пов’язаних із ним робочих областей можна видалити розташування, яке або не використовується, або яке було налаштовано неправильно. Коли ви видаляєте розташування, ви видаляєте всі призначені служби та номери.
Отримайте список користувачів і робочих просторів, пов’язаних із розташуванням. Перейдіть до і в розкривному меню виберіть розташування для видалення. Перед тим як видалити розташування, слід видалити цих користувачів і робочі простори.
Майте на увазі, що всі номери, пов’язані з цим розташуванням, будуть повернені вашому постачальнику ТМЗК. Ви більше не будете власними номерами.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . |
| 2 |
Клацніть |
| 3 |
Натисніть Видалити розташування і підтвердьте, що потрібно видалити це розташування. Зазвичай для остаточного видалення розташування знадобиться кілька хвилин, але це може зайняти до години. Щоб перевірити стан, можна клацнути |
Оновлення наявного розташування
Після створення розташування можна змінити його налаштування PSTN, ім’я, часовий пояс і мову. Майте на увазі, що нову мову буде застосовано лише для нових користувачів і пристроїв. Для наявних користувачів і пристроїв буде використано стару мову.
Для наявних розташувань можна ввімкнути служби екстреної допомоги 911. Додаткову інформацію див. в розділі Служба екстреної допомоги 911 RedSky для Webex Calling.
| 1 |
Увійдіть у Центркерування. |
| 2 |
Перейдіть до . Якщо поруч із розташуванням відображається символ попередження, це означає, що номер телефону для цього розташування ще не налаштовано. Ви не зможете здійснювати або приймати будь-які виклики, поки не налаштуєте цей номер. |
| 3 |
(Необов’язково.) У розділі Підключення до PSTN виберіть PSTN із підключенням до хмари або PSTN на базі локальних ресурсів (локальний шлюз), залежно від того, який із цих параметрів уже налаштовано. Клацніть Керування, щоб змінити цю конфігурацію, а потім підтвердьте, що ви усвідомлюєте пов’язані ризики, вибравши Продовжити. Після цього виберіть один із наведених нижче параметрів і клацніть Зберегти.
Для міграції див. розділ Міграція до планів Cisco Calling нижче. |
| 4 |
Для розташування виберіть Основний номер із розкривного списку. Основний номер можна призначити автосекретарю або іншому адресату в межах розташування, щоб зовнішні абоненти, що телефонують, були маршрутизовані до відповідного призначення. Необхідно призначити основний номер розташуванню, якщо воно має будь-які транки або об’єкти, які використовують лише внутрішні номери, як-от користувачі, робочі простори, віртуальні лінії або функції. Без основного номера транки недоступні для використання, а об’єкти, які використовують тільки внутрішні номери, не можуть здійснювати або приймати внутрішні або зовнішні виклики. Користувачі в цьому розташуванні також можуть використовувати цей номер як ідентифікатор абонента, що телефонує, для здійснення викликів ТМЗК. Якщо ви виберете безкоштовний номер як основний номер для розташування, ми рекомендуємо оновити номер екстреного зворотного виклику для розташування, оскільки на безкоштовному номері немає адреси служб екстреної допомоги. Для отримання додаткової інформації див. Налаштування номера екстреного зворотного виклику для місця розташування. |
| 5 |
(Необов’язково.) У розділі Екстрені виклики можна вибрати параметр Ідентифікатор місця надзвичайної ситуації, щоб призначити його цьому розташуванню. Це налаштування необов’язкове й застосовується лише для країн, які цього потребують. У деяких країнах (як-от Франція), існують нормативні вимоги до стільникових радіосистем із метою встановлення ідентифікатора стільникового зв’язку під час здійснення екстреного виклику й надання до них доступу екстреним службам. Інші країни, як-от США та Канада, використовують інші методи визначення місцезнаходження. Додаткову інформацію див. в статті Розширені екстрені виклики. Вашому постачальнику екстрених викликів може знадобитися інформація про мережу доступу, і цього досягти шляхом визначення нового приватного заголовка внутрішнього номера SIP «P-Access-Network-Info». Заголовок містить інформацію, пов’язану з мережею доступу. У разі налаштування ідентифікатора місця надзвичайної ситуації для розташування значення розташування надсилається постачальнику як частина повідомлення SIP. Зверніться до свого постачальника екстрених викликів, щоб дізнатися, чи потрібне вам це налаштування, і використовуйте значення, яке надав ваш постачальник екстрених викликів. |
| 6 |
Виберіть номер голосової пошти, за яким користувачі можуть зателефонувати, щоб перевірити голосову пошту для цього розташування. |
| 7 |
(Необов’язково.) Клацніть значок олівця у верхній частині сторінки «Розташування» і змініть такі параметри, як Ім’я розташування, Мова оголошень, Мова електронної пошти, Часовий пояс або Адреса, якщо це необхідно, а потім клацніть Зберегти. Зміна параметра Мова оголошень набуває чинності негайно для всіх нових користувачів і функцій, доданих до цього розташування. Якщо для наявних користувачів і/або функцій також потрібно змінити мову оголошень, коли з’явиться запит, виберіть Змінити для наявних користувачів і робочих просторів або Змінити для наявних функцій. Клацніть Застосувати. Перебіг виконання можна переглянути на сторінці Завдання. Поки це налаштування не буде завершено, внести інші зміни буде неможливо. У разі змінювання часового поясу для розташування не буде оновлено часові пояси функцій, пов’язаних із розташуванням. Щоб змінити часові пояси для таких функцій, як автосекретар, група пошуку та черга викликів, перейдіть до області Загальні налаштування конкретної функції, для якої потрібно оновити часовий пояс, і відредагуйте й збережіть там. |
Перейти до планів Cisco Calling
Ви можете змінити підключення до ТМЗК для наявного розташування на Cisco ТМЗК. Наприклад, можна змінити розташування для локального ТМЗК (локального шлюзу) або неінтегрованих підключень CCP до Cisco ТМЗК. Cisco ТМЗК надає хмарне рішення ТМЗК від Cisco.
Усі доступні для перенесення номери залишаються функціональними, за винятком невеликих перерв протягом запланованого часу завершення перенесення.
Крім того, ви не можете внести будь-яку зміну керування номерами для розташування, що проходить перехід підключення до ТМЗК. Але наявні номери залишаються функціональними, і ви все ще можете призначити або скасувати призначення номерів розташуванню. Ви не можете додавати, видаляти або переміщати номери для цього розташування. Під час цього процесу профіль маршрутизації автоматично оновлюється, увімкнувши Cisco ТМЗК.
Наразі можливість змінення підключення до ТМЗК для наявного розташування на Cisco ТМЗК не підтримується для регіону Японії.
Під час зміни підключення до ТМЗК застосовується підписка з ліцензією на виклики, і платіжна служба отримує сповіщення.
Обмеження.
-
Міграція з інтегрованого розташування IntelePeer до розташування Cisco ТМЗК не підтримується
-
Розташування виділеного екземпляра не можна перенести до Cisco ТМЗК.
-
Для зміни підключення до ТМЗК може знадобитися кілька замовлень на перенесення. Якщо так, ці замовлення пов’язані, щоб вони виконувалися одночасно. Будь-яка зміна дати або скасування одного замовлення на перенесення має застосовуватися до всіх пов’язаних замовлень на перенесення, щоб змінити підключення.
Ініціювання зміни підключення до PSTN
| 1 |
Увійдіть у Центркерування. |
| 2 |
Перейдіть до . |
| 3 |
Виберіть розташування, для якого потрібно змінити підключення до ТМЗК на Cisco ТМЗК. |
| 4 |
Перейдіть на вкладку Виклики , клацніть параметр Керування поруч із локальною ТМЗК або неінтегрованою ТМЗК з підключенням до хмари. |
| 5 |
Змініть поруч із Типом підключення. |
| 6 |
Виберіть картку планів Cisco Calling і виберіть передплату, яка виділяє план Cisco Calling для користувачів у цьому розташуванні. Клацніть Далі. |
| 7 |
Для підтвердження з’явиться сторінка зміни підключення. Клацніть Далі і перевірте готовність порту для своїх номерів. Кнопка "Далі" вмикається, лише якщо всі номери в списку доступні для перенесення. Прочитайте ці вказівники:
|
| 8 |
Клацніть Далі і надайте інформацію про договір. Це основний контакт для договорів для всіх розташувань, що використовують плани Cisco Calling (США). Будь-які зміни в цьому контакті буде застосовано до всіх інших розташувань, що використовують плани Cisco Calling (США). |
| 9 |
Клацніть Далі. З’явиться сповіщення з проханням зберегти інформацію про договір для цього розташування. Виберіть Так, змініть. |
| 10 |
Введіть адресу служби екстреної допомоги та клацніть Зберегти. В екстреному випадку місцева аварійно-рятувальна команда використовує цю адресу для визначення місцезнаходження абонента, що телефонує. |
| 11 |
На сторінці зведених даних відображається кількість створених портів. Якщо існує тільки одне замовлення, ви можете побачити додатковий крок під назвою Надати додаткову інформацію. Для кількох замовлень зверху доступний селектор замовлень для переміщення між ними. Клацніть Далі і введіть відомості, щоб завершити роботу майстра перенесення. Замовлення надсилаються відразу, коли вся інформація надається для одного запиту на міграцію ТМЗК. За замовчуванням дата виконання замовлення є послідовною для всіх замовлень. Зміна підключення до ТМЗК буде автоматично застосована після повного перенесення останнього пов’язаного замовлення.
Відомості про міграцію доступні на вкладці . Виберіть ідентифікатор замовлення, щоб переглянути відомості про замовлення в поданні на бічній панелі. Тип можна побачити як Змінити ТМЗК для замовлень, створених у результаті зміни підключення до ТМЗК. |
Скасувати зміну підключення до PSTN
Адміністратор може скасувати міграцію ТМЗК, якщо розташування все ще перебуває в стані переходу.
| 1 |
Увійдіть у Центркерування. |
| 2 |
Перейдіть до . |
| 3 |
Виберіть розташування, для якого потрібно скасувати підключення до ТМЗК. |
| 4 |
Перейдіть на вкладку Виклики, клацніть кнопку Скасувати зміну підключення до ТМЗК . |
| 5 |
Клацніть Так, продовжити, щоб підтвердити скасування. |
Налаштувати абонентську групу Webex Calling
Ви можете керувати абонентською групою для розгортання webex Call за допомогою вихідних кодів набору. Налаштуйте довжину розширення, префікси маршрутизації та налаштування набору (внутрішні та зовнішні), щоб бути сумісними зі звичками набору ваших користувачів.
Ці налаштування призначено для внутрішнього набору, і вони також доступні в майстрі першого встановлення. Під час зміни абонентської групи наведіть приклади номерів в оновленні Control Hub, щоб відобразити ці зміни.
Можна налаштувати дозволи на вихідні виклики для розташування. Перегляньте ці кроки для налаштування дозволів на вихідні виклики.
| 1 |
Увійдіть до Control Hub, перейдіть до , а потім прокрутіть до Набір внутрішніх номерів. |
| 2 |
За потреби налаштуйте наведені нижче додаткові бажані параметри набору.
|
| 3 |
Налаштуйте внутрішній набір для певних розташувань. Перейдіть до розділу , виберіть розташування зі списку та клацніть Виклики. Прокрутіть до Набір, а потім змініть внутрішній набір за потреби:
|
| 4 |
Задайте зовнішній набір для певних розташувань. Перейдіть до розділу , виберіть розташування зі списку та клацніть Виклики. Прокрутіть до Набір, а потім змініть зовнішній набір за потреби:
Вплив на користувачів.
|
Налаштування PSTN на базі локальних ресурсів (локальний шлюз) у Control Hub
Реселери, які створюють додану вартість, можуть скористатися цими кроками, щоб розпочати налаштування конфігурації локального шлюзу в Control Hub. Коли цей шлюз зареєстровано в хмарі, його можна використовувати в одному або кількох розташуваннях Webex Calling, щоб забезпечити маршрутизацію до корпоративного постачальника послуг PSTN.
Розташування з локальним шлюзом не можна видалити, якщо локальний шлюз використовується для інших розташувань.
Створення транку
Перш ніж почати
-
Після того, як розташування додано, і перед тим, як налаштувати PSTN на базі локальних ресурсів для розташування, необхідно створити транк.
-
Створіть будь-які розташування та певні налаштування і номери для кожного з них. Розташування має існувати, перш ніж можна буде додати PSTN на базі локальних ресурсів.
-
Ознайомтеся з вимогами до PSTN на базі локальних ресурсів (локальний шлюз) для Webex Calling.
-
Неможливо вибрати більше одного транку для розташування з PSTN на базі локальних ресурсів, але можна вибрати один і той самий транк для кількох розташувань.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до і виберіть Додати транк. |
| 2 |
Виберіть розташування. |
| 3 |
Укажіть ім’я транку й клацніть Зберегти. Довжина імені не може перевищувати 24 символи. |
Що далі
На екрані буде відображено інформацію про транк: домен реєстрації, OTG/DTG транкової групи, лінію/порт, адресу вихідного проксі.
Рекомендується скопіювати цю інформацію з Control Hub і вставити її у локальний текстовий файл або документ, щоб можна було легко знайти її під час налаштування PSTN на базі локальних ресурсів.
У разі втрати облікових даних необхідно створити їх, використовуючи екран інформації про транк у Control Hub. Клацніть Отримати ім’я користувача й скинути пароль, щоб створити новий набір облікових даних автентифікації для використання на транку.
Виберіть транк для PSTN на базі локальних ресурсів
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, перейдіть до . |
| 2 |
Виберіть розташування, яке необхідно змінити, і клацніть Керування. |
| 3 |
Виберіть PSTN на базі локальних ресурсів і клацніть Далі. |
| 4 |
Виберіть транк у розкривному меню. Перейдіть на сторінку транку, щоб керувати параметрами транкової групи. |
| 5 |
Клацніть повідомлення про підтвердження і далі Зберегти. |
Що далі
Необхідно мати інформацію про конфігурацію, створену в Control Hub, і зіставити параметри у локальному шлюзі (наприклад, у Cisco CUBE, який розташовано локально). У цій статті описано цей процес. Для довідки див. схему нижче, в якій наведено приклад зіставлення інформації про конфігурацію Control Hub (ліворуч) з параметрами CUBE (праворуч).
Після успішного завершення конфігурації самого шлюзу можна повернутися до меню в Control Hub. Створений вами шлюз буде перераховано на карті розташування, якій ви його призначили, із зеленою крапкою ліворуч від імені. Цей стан вказує на те, що шлюз безпечно зареєстровано в хмарі викликів і він є активним шлюзом PSTN для розташування.
Керування номерами телефону
В Control Hub можна легко переглядати, активувати, видаляти й додавати номери телефону для своєї організації. Додаткову інформацію див. в статті Керування номерами телефону в Control Hub.
Запит на придбання послуг Webex у Control Hub із пробної версії
Якщо ви намагаєтеся користуватися службами Webex і хочете перетворити пробну версію на платну підписку, можна надіслати запит електронною поштою вашому партнеру.
| 1 |
Увійдіть до Control Hub за адресою https://admin.webex.com, виберіть значок будівлі |
| 2 |
Перейдіть на вкладку Передплата й клацніть Придбати зараз. Вашому партнеру буде надіслано електронний лист із повідомленням про те, що ви зацікавлені в переході на платну передплату. |
Установити параметри виклику
Можна використовувати Control Hub, щоб установити пріоритетність доступних параметрів виклику, які користувачі бачать у програмі Webex. Їх також можна ввімкнути для виклику одним клацанням. Додаткову інформацію див. на сторінці Установіть параметри виклику для користувачів програми Webex.
Налаштувати поведінку викликів
Ви можете керувати, яка програма для викликів відкривається, коли користувачі виконують виклики. Можна налаштувати параметри клієнта викликів, зокрема розгортання змішаного режиму для організацій, де користувачі мають право користуватися Unified CM або Webex Calling, і користувачів без платних послуг телефонії від Cisco. Додаткову інформацію див. на сторінці Налаштуйте поведінку викликів.
Налаштування Unified CM для Webex Calling
Налаштування профілю безпеки SIP-транку для транку до локального шлюзу
У випадках, коли локальний шлюз і шлюз PSTN знаходяться на одному пристрої, необхідно увімкнути Unified CM, щоб диференціювати два різні типи трафіку (виклики з Webex і з PSTN), які ініційовано з одного пристрою, і застосовувати диференційований клас служби до цих типів викликів. Ця диференційована обробка викликів досягається шляхом підготовки двох транків між Unified CM і комбінованим пристроєм локального шлюзу й шлюзу PSTN, яка вимагає різних портів прослуховування SIP для двох транків.
|
Створіть виділений профіль безпеки SIP-транку для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Налаштування SIP-профілю для транку локального шлюзу
|
Створіть виділений SIP-профіль для транку локального шлюзу з наведеними нижче налаштуваннями.
| ||||||||||
Створення простору пошуку викликів для викликів із Webex
|
Створіть простір пошуку викликів для викликів, які ініційовано з Webex, із наведеними нижче налаштуваннями.
Останній розділ onNetRemote використовується лише в багатокластерному середовищі, де обмін інформацією про маршрутизацію між кластерами Unified CM здійснюється за допомогою служби міжкластерного пошуку (ILS) або глобальної реплікації абонентської групи (GDPR). | ||||||||||
Налаштування SIP-транку до Webex і у зворотному напрямку
|
Створіть SIP-транк для викликів у напрямку до Webex і зворотному напрямку через локальний шлюз із наведеними нижче налаштуваннями.
| ||||||||||||||||||||||||||
Налаштування групи маршрутів для Webex
|
Створіть групу маршрутів із наведеними нижче налаштуваннями.
| ||||||||
Налаштування списку маршрутів для Webex
|
Створіть список маршрутів із наведеними нижче налаштуваннями.
| ||||||||||||||
Створення розділу для призначень Webex
|
Створіть розділ для призначень Webex із наведеними нижче налаштуваннями.
| ||||||||
Що далі
Обов’язково додайте цей розділ до всіх пошукових просторів, які повинні мати доступ до призначень Webex. Необхідно додати цей розділ саме до простору пошуку викликів, який використовується як простір пошуку вхідних викликів на транках PSTN, щоб виклики з PSTN можна було маршрутизувати до Webex.
Налаштування шаблонів маршрутів для призначень Webex
|
Налаштуйте шаблони маршрутів для кожного діапазону DID у Webex із наведеними нижче налаштуваннями.
| ||||||||||||
Налаштування нормалізації скороченого міжоб’єктного набору для Webex
|
Якщо для Webex потрібен скорочений міжоб’єктний набір, налаштуйте шаблони нормалізації набору для кожного діапазону ESN у Webex із наведеними нижче налаштуваннями.
| ||||||||||||||||||
Налаштування функцій Webex Calling
Налаштування групи пошуку
Групи пошуку забезпечують маршрутизацію вхідних викликів до групи користувачів або робочих просторів. Можна навіть налаштувати шаблон маршрутизації до всієї групи.
Додаткову інформацію щодо налаштування групи пошуку див. в статті Групи пошуку в Cisco Webex Control Hub.
Створення черги викликів
Можна налаштувати чергу викликів у такий спосіб, щоб у разі неможливості надання відповіді на виклики клієнтів вони отримували автоматичну відповідь, повідомлення підтримки, а також відтворювалася музика режиму утримання, поки хтось не зможе відповісти на виклик.
Додаткову інформацію щодо налаштування черги викликів і керування нею див. в статті Керування чергами викликів у Cisco Webex Control Hub.
Створення клієнта-секретаря
Забезпечте підтримку персоналу свого фронт-офісу. Можна налаштувати користувачів як телефонних операторів, щоб вони могли відстежувати вхідні виклики, які надходять певним особам у вашій організації.
Додаткову інформацію щодо налаштування і перегляду клієнтів-секретарів див. в статті Клієнти-секретарі в Cisco Webex Control Hub.
Створення автосекретарів і керування ними
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Створіть 24-годинний розклад або налаштуйте різні параметри для робочого й неробочого часу.
Додаткову інформацію щодо створення автосекретарів і керування ними див. в статті Керування автосекретарями в Cisco Webex Control Hub.
Налаштування пейджингової групи
Функція групового пейджингу дає змогу користувачам здійснювати односторонній виклик або надсилати групове повідомлення для групи чисельністю до 75 цільових користувачів і робочих просторів за допомогою набору номера або додаткового номера, призначеного певній пейджинговій групі.
Додаткову інформацію щодо налаштування і змінювання пейджингових груп див. в статті Налаштування пейджингової групи в Cisco Webex Control Hub.
Налаштування підхоплення викликів
Щоб покращити співпрацю в команді, створіть групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий.
Додаткову інформацію щодо налаштування групи підхоплення викликів див. в статті Підхоплення викликів у Cisco Webex Control Hub.
Налаштування паркування викликів
Функція паркування викликів дозволяє певній групі користувачів паркувати виклики для інших доступних учасників групи паркування викликів. Запарковані виклики можуть підхоплювати інші учасники групи на своїх телефонах.
Додаткову інформацію щодо налаштування паркування викликів див. в статті Паркування викликів у Cisco Webex Control Hub.
Увімкнути втручання для користувачів
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до . |
| 2 |
Виберіть користувача та клацніть Виклики. |
| 3 |
Перейдіть до розділу Дозволи між користувачами , а потім виберіть Втручання. |
| 4 |
Увімкніть перемикач, щоб дозволити іншим користувачам додавати себе до поточних викликів цього користувача. |
| 5 |
Установіть прапорець параметра Відтворювати сигнал, коли цей користувач втручається у виклик , якщо ви хочете відтворювати сигнал до інших користувачів, коли цей користувач втручається у виклик. Відтворювати сигнал, коли цей користувач втручається у виклик , не застосовується до функцій втручання головного адміністратора Customer Experience і основної ліцензії. Навіть якщо ввімкнути цей параметр для наглядача, система не відтворюватиме сигнал сповіщення оператору, коли наглядач втручається у виклик своєї черги викликів. "Якщо ви хочете відтворювати сигнал для оператора, коли наглядач втручається у виклик, ви можете ввімкнути його за допомогою налаштувань ""Сигнал сповіщень для операторів""." Додаткову інформацію див. в розділі Створити чергу в Webex Customer Experience Basic або Webex Customer Experience Essentials. |
| 6 |
Клацніть Зберегти. |
Увімкнути конфіденційність для користувача
| 1 |
Увійдіть до Control Hub і перейдіть до . |
| 2 |
Виберіть користувача й клацніть Виклики. |
| 3 |
Перейдіть до області дозволів між користувачами , а потім виберіть параметр Конфіденційність. |
| 4 |
Виберіть відповідні налаштування конфіденційності автосекретаря для цього користувача.
|
| 5 |
Установіть прапорець Увімкнути конфіденційність. Після цього можна вирішити блокувати всіх учасників, не вибравши учасників із розкривного списку. Крім того, можна вибрати користувачів, робочі простори й віртуальні лінії, які можуть моніторити стан лінії цього користувача. Якщо ви адміністратор розташування, у розкривному списку відображатимуться лише користувачі, робочі простори й віртуальні лінії, що стосуються призначених вам розташувань. Зніміть прапорець Увімкнути конфіденційність , щоб дозволити всім моніторити стан лінії. |
| 6 |
Установіть прапорець Забезпечення конфіденційності для керованого підхоплення викликів і втручання , щоб увімкнути конфіденційність для керованого підхоплення викликів і втручання.
|
| 7 |
У розділі Додати учасника за іменем виберіть користувачів, робочі простори й віртуальні лінії, які можуть моніторити стан телефонної лінії та застосовувати функції керованого підхоплення викликів і втручання у виклик. |
| 8 |
Щоб відфільтрувати вибраних учасників, використовуйте фільтр за полем імені, номера або внутрішнього номера . |
| 9 |
Клацніть Видалити все , щоб видалити всіх вибраних учасників. Щоб видалити окремого члена, клацніть Видалити поруч з іменем члена. |
| 10 |
Клацніть Зберегти. |
Налаштувати моніторинг
Максимальна кількість вибраних для моніторингу ліній для користувача становить 50. Однак під час налаштування списку моніторингу враховуйте кількість повідомлень, які впливають на пропускну здатність між Webex Calling і вашою мережею. Також визначте максимальну кількість вибраних для моніторингу ліній за кількістю кнопок лінії на телефоні користувача.
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до Керування , а потім клацніть Користувачі. |
| 2 |
Виберіть користувача, якого потрібно змінити, і натисніть кнопку Виклик. |
| 3 |
Перейдіть до розділу Дозволи між користувачами і виберіть Моніторинг. |
| 4 |
Виберіть один із наведених далі варіантів.
Віртуальну лінію можна додати до списку Додати вибрану для моніторингу лінію для моніторингу користувачів. |
| 5 |
Виберіть, чи бажаєте ви сповістити цього користувача про запарковані виклики, знайдіть користувача або внутрішній номер для паркування викликів для моніторингу, а потім клацніть Зберегти. Порядок ліній з відстеженням у списку в Control Hub відповідає порядку ліній з відстеженням, які відображаються на пристрої користувача. Ви можете будь-коли змінити порядок списку вибраних для моніторингу ліній. Ім’я, що з’являється для контрольованої лінії, це ім’я, введене в поля ідентифікатора абонента, що телефонує, ім’я та прізвище для користувача, робочого простору й віртуальної лінії. |
Увімкнути попереджувальний сигнал мосту виклику для користувачів
Перед початком
| 1 |
Увійдіть до Control Hub і перейдіть до . |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Перейдіть до Дозволи між користувачами і клацніть Попереджувальний сигнал мосту викликів. |
| 4 |
Увімкніть попереджувальний сигнал мосту викликів, а потім клацніть Зберегти. За замовчуванням цю функцію ввімкнено. Додаткову інформацію про мосту викликів на спільній лінії MPP див. в розділі Спільні лінії на багатоплатформовому настільному телефоні. Додаткову інформацію про міст викликів на спільній лінії програми Webex див. в розділі Зовнішній вигляд спільних ліній для WebexApp. |
Увімкнення функції «Резервування ресурсів» для користувача
| 1 |
З подання клієнта в https://admin.webex.com перейдіть до Керування і виберіть Користувачі. |
| 2 |
Виберіть користувача й перейдіть на вкладку Виклики. |
| 3 |
Перейдіть до розділу Дозволи між користувачами , виберіть Готелі й увімкніть перемикач. |
| 4 |
Введіть ім’я або номер організатора готелів у полі пошуку Розташування готелів і виберіть організатора готелів, якого ви хочете призначити користувачу. Можна вибрати лише одного організатора готелів. Якщо ви виберете іншого організатора готелів, перший буде видалено. Якщо ви адміністратор розташування, ви можете призначити лише головного комп’ютера, що стосується призначених вам розташувань. |
| 5 |
Щоб обмежити час, протягом якого користувач може бути пов’язаний із організатором готелів, виберіть кількість годин, протягом яких користувач може використовувати організатора готелів із розкривного списку Період обмеження асоціації . Користувач буде автоматично виходити з системи після вибраного часу. Якщо обмежений період асоціації, заданий для користувача, перевищує обмежений період асоціації вибраного головного комп’ютера, з’явиться на екрані повідомлення про помилку. Наприклад, якщо організатор готелю має обмежений період асоціації в 12 годин, а обмежений період асоціації користувача становить 24 години, з’явиться повідомлення про помилку. У таких випадках необхідно подовжити обмежений період асоціації хоста, якщо для користувача потрібен більше часу. |
| 6 |
Клацніть Зберегти. Користувач також може шукати та знайти хост-готель, який він хоче використовувати в користувацькому центрі. Додаткову інформацію див. в розділі Доступ до профілю викликів із будь-якого місця. |
Тенденції впровадження та звіти про використання для Webex Calling
Переглянути звіти про виклики
Ви можете використовувати сторінку Аналітика в Control Hub, щоб переглянути використання служб Webex Calling, взаємодію в програмі Webex і якість їхньої мультимедіа викликів. Щоб отримати доступ до аналітики Webex Calling, виконайте наведені нижче дії.
| 1 |
Увійдіть у Центркерування. |
| 2 |
Перейдіть до Аналітика і виберіть вкладку Виклики . |
| 3 |
Виберіть детальну історію викликів. Деталі історії викликів відображаються з даними про якість мультимедіа.
|
| 4 |
Щоб отримати доступ до даних про якість мультимедіа, увійдіть у Control Hub, потім перейдіть до Аналітика і виберіть Виклики. |
Огляд Webex Calling
Уявіть, що ви можете використовувати хмарні функції викликів, мобільності й PBX корпоративного рівня, а також для обміну повідомленнями, нарад і викликів із програмного клієнта або пристрою Cisco. Це саме те, що він має вам запропонувати.
надає наступні функції та переваги:
-
Виклик підписок для користувачів телефонії та зон загального користування.
-
Безпечні та надійні хмарні сервіси, що надаються надійними регіональними постачальниками послуг
-
доступ для кожного користувача, додавання багатих уніфікованих комунікацій і служб співпраці в команді.
-
Webex Meetings як необов’язковий інтегрований додатковий модуль для надання преміальних можливостей для проведення нарад, яких очікують корпоративні користувачі.
-
Доступ до загальнодоступних телефонних мереж (ТМЗК), щоб дозволити користувачам набирати номери за межами організації. Послуга надається через наявну інфраструктуру підприємства.
-
Локальний шлюз без локального IP PBX
-
Наявне середовище виклику Unified CM
-
Надані партнером або Cisco параметри ТМЗК
-
-
Підтримка Tier 1, що надається вашим партнером, підтримка наступного рівня, що надається компанією Cisco
— вебпортал керування, який інтегрується з тим, щоб оптимізувати ваші замовлення та конфігурацію, а також централізувати керування пакетною пропозицією — і Webex Meetings.
|
Функція |
Опис |
|---|---|
|
Автосекретар |
Можна додати привітання, налаштувати меню, а також маршрутизувати виклики до служби автовідповідача, групи пошуку, скриньки голосової пошти або реальної особи. Можна створити 24-годинний розклад або налаштувати різні параметри для робочого й неробочого часу. Можна навіть маршрутизувати виклики на основі атрибутів ідентифікатора абонента, що телефонує, щоб створювати VIP-списки або по-різному обробляти виклики, які надходять з певних кодів населеного пункту. |
|
Черга викликів |
Якщо ви не можете відповісти на вхідні виклики, можна налаштувати чергу викликів. Ви можете надати абонентам, що телефонують, автоматичну відповідь, заспокійливі повідомлення та музику на утриманні, поки хтось не зможе відповісти на їхній виклик. |
|
Прийняти виклик |
Можна покращити командну роботу та співпрацю, створивши групу підхоплення викликів, щоб користувачі могли відповідати на виклики інших користувачів. Якщо користувачів додано до групи підхоплення викликів, то один учасник групи може відповідати на виклик іншого учасника, коли він відсутній або зайнятий. |
|
Паркування викликів |
Можна ввімкнути паркування викликів, щоб дозволити користувачам розміщувати виклик на утриманні та підхоплювати його з іншого телефону. |
|
Група пошуку |
Необхідність налаштувати групи пошуку може виникнути в наведених нижче випадках.
|
|
Пейджингова група |
Можна створити пейджингову групу, щоб користувачі могли надсилати голосові повідомлення для особи, відділу або робочої групи. Коли хтось надсилає повідомлення пейджинговій групі, це повідомлення відтворюється на всіх пристроях у групі. |
|
Клієнт-секретар |
Забезпечте підтримку персоналу свого фронт-офісу, надавши користувачам повний набір параметрів керування викликами, можливість розгорнутого відстеження ліній, створення черг викликів, кілька варіантів параметрів каталогів і їхніх подань, використання інтеграції Outlook тощо. |
|
Функція |
Опис |
|---|---|
|
Відхилення анонімних викликів |
Користувачі можуть відхиляти вхідні виклики з заблокованими ідентифікаторами абонента, що телефонує. |
|
Безперервність бізнес-процесів |
Якщо телефони користувачів не підключені до мережі з такої причини, як перебої в живленні, проблеми мережі тощо, користувачі можуть переадресовувати вхідні виклики на певний номер телефону. |
|
Переадресація викликів |
Користувачі можуть переадресувати вхідні виклики на інший телефон. |
|
Вибіркова переадресація викликів |
Користувачі можуть переадресувати виклики в певний час від певних абонентів. Це налаштування матиме пріоритет над функцією «Переадресація викликів». |
|
Сповіщення про виклик |
Користувачі можуть надсилати собі електронний лист у разі отримання виклику відповідно до заздалегідь визначених критеріїв, як-от номера телефону або дати й часу. |
|
Виклик на очікуванні |
Користувачі можуть дозволити відповідати на додаткові вхідні виклики. |
|
Не турбувати |
Користувачі можуть тимчасово дозволити всім викликам спрямовуватися безпосередньо на голосову пошту. |
|
Office Anywhere |
Користувачі можуть використовувати вибрані телефони («розташування») як додатковий номер свого робочого номера телефону й абонентської групи. |
|
Пріоритетне сповіщення |
Користувачі можуть налаштувати спеціальний сигнал виклику на телефоні, який буде відтворюватися відповідно до заздалегідь визначених критеріїв, як-от номера телефону або дати й часу. |
|
Віддалений офіс |
Користувачі можуть здійснювати виклики з віддаленого телефону, й вони будуть відображатися як виклики з їхнього робочого номера телефону. Крім того, будь-які вхідні виклики на бізнес-лінію дзвонять на цьому віддаленому телефоні. |
|
Вибіркове прийняття викликів |
Користувачі можуть приймати виклики в певний час від певних абонентів. |
|
Вибіркове відхилення викликів |
Користувачі можуть відхиляти виклики в певний час від певних абонентів. |
|
Послідовний дзвінок |
Вхідні виклики можуть послідовно надходити не більше ніж на 5 пристроїв. |
|
Одночасний дзвінок |
Вхідні виклики можуть одночасно надходити на номери користувачів і інших абонентів («отримувачів викликів»). |
Підготовка служб, пристроїв і користувачів у , перехресний запуск до детальної конфігурації в
( ) — це портал керування, який інтегрується з метою оптимізації ваших замовлень і конфігурації, а також централізації керування пакетною пропозицією — , і .
є центральним пунктом для підготовки всіх служб, пристроїв і користувачів. Тут можна виконати початкове налаштування служби викликів, зареєструвати телефони MPP в хмарі (використовуючи MAC-адресу), налаштувати користувачів шляхом зв’язування пристроїв, додавання номерів, послуг, функцій виклику тощо. Крім того, з , ви можете перехресний запуск на .
Можливості користувачів
Користувачі мають доступ до наведених нижче інтерфейсів.
-
програма — програмний клієнт для викликів під брендом Cisco. Додаткову інформацію див. в статті Огляд нової програми Cisco Webex Calling.
-
( ) — інтерфейс, де користувачі можуть встановлювати бажані параметри профілю, завантажити програму Webex і перехресний запуск у налаштування для викликів. Додаткову інформацію див. в статті Змінювання налаштувань Cisco Webex.
-
Програма Webex — програма, яку включено до передплати як клієнт для обміну повідомленнями в команді під брендом Cisco. Додаткову інформацію див. в статті Початок роботи з програмою Cisco Webex.
-
Webex Meetings — додаткова програма, яку додано як рішення для нарад. Додаткову інформацію див. в статті Webex Meetings.
Адміністратори клієнтів
Як адміністратор клієнта з пробною версією або платною підпискою на , ви можете налаштувати свою організацію, додавши розташування, ліцензії, номери телефонів, функції викликів, користувачів і робочі області (кімнатні пристрої, що реєструються в хмарі Webex). Ви також можете керувати всіма цими компонентами звідти.
-
Додаткову інформацію про пропозицію див. в Cisco Webex Calling у таблиці даних плану Cisco Collaboration Flex для кінцевих клієнтів.
Партнери
Як партнер постачальник послуг, ви можете брендувати, марнувати та продавати своїм клієнтам. Ви можете налаштувати та розширити пробні версії, розгорнути послуги для своїх клієнтів, а також створювати та надавати замовлення для своїх клієнтів.
Доступність
Перегляньте заголовок статті Де доступний Cisco Webex для країн, де він доступний для продажу.
Ознайомитися з
— це ваш єдиний доступ до вебінтерфейсу для керування вашою організацією, керування користувачами, призначення служб, аналізу тенденцій запровадження та якості викликів тощо.
Щоб ваша організація працювала, рекомендовано запросити кількох користувачів приєднатися, ввівши їхні адреси електронної пошти в . Заохочуйте користувачів використовувати надані вами служби, включно з викликами, і надавати вам відгуки про їхню роботу. За необхідності ви завжди можете додати інших користувачів.
Для доступу радимо використовувати останню класичну версію Google Chrome або Mozilla Firefox. Використання браузерів на мобільних пристроях, а також інших настільних браузерів може призвести до непередбачуваних результатів.
Нижче наведено зведену інформацію щодо можливих сценаріїв під час налаштування служб в організації. Більш докладну інформацію наведено в окремих розділах із покроковими інструкціями.
Початок роботи
Після того як ваш партнер створить ваш обліковий запис, ви отримаєте привітальний електронний лист. Клацніть посилання Початок роботи в електронному листі. Щоб отримати доступ, скористайтеся Chrome або Firefox. Посилання забезпечить автоматичний вхід із використанням вашої адреси електронної пошти адміністратора. Далі вам буде запропоновано створити пароль адміністратора.
Майстер початкового налаштування пробних версій
Якщо ваш партнер зареєстрував вас на ознайомлювальну версію, майстер налаштування автоматично розпочнеться після того, як ви ввійдете в . Майстер проконсультує вас із основними налаштуваннями, щоб ваша організація працювала з , серед інших служб. Перед завершенням роботи майстра можна налаштувати й перевірити налаштування Calling.
Перевірка налаштувань
Коли завантаження, можна переглядати налаштування.
Додавання користувачів
Після налаштування служб можна додати користувачів із каталогу вашої компанії. У розділі Користувачі виберіть Керування користувачами.
У разі використання Microsoft Active Directory рекомендується спочатку ввімкнути синхронізацію каталогу, а потім вибрати спосіб додавання користувачів. Клацніть Далі й дотримуйтеся інструкцій щодо налаштування з’єднувача каталогів Cisco.
Налаштування єдиного входу (SSO)
використовує базову автентифікацію. Можна налаштувати SSO, щоб користувачі автентифікувалися за допомогою постачальника ідентифікаційних даних підприємства за допомогою його корпоративних облікових даних, а не окремого пароля, що зберігається та керується у Webex.
Перейдіть до розділу Налаштування, прокрутіть сторінку до пункту Автентифікація, клацніть Змінити, а потім виберіть Інтегрувати стороннього постачальника посвідчень.
Призначення служб користувачам
Ви повинні призначити служби доданим користувачам, щоб користувачі могли почати використовувати .
У розділі Користувачі клацніть Керування користувачами, виберіть Експорт і імпорт користувачів за допомогою файлу CSV, а потім клацніть Експорт.
У завантаженому файлі просто додайте значення True для служб, які необхідно призначити кожному з користувачів.
Імпортуйте готовий файл, клацніть Додавання і видалення служб, а потім клацніть Надіслати. Тепер можна розпочати налаштування функцій виклику, зареєструвати пристрої, до яких можна буде надати спільний доступ на загальному робочому місці, а також зареєструвати пристрої та зв’язати їх із користувачами.
Розширення можливостей користувачів
Тепер, коли ви додали користувачів і їм призначено служби, вони можуть почати використовувати свої підтримувані багатоплатформові телефони (MPP) для обміну повідомленнями та нарад. Порадьте їм використовувати налаштування Cisco Webex як універсальний інструмент доступу.
Роль локального шлюзу
Локальний шлюз — це граничний пристрій (корпоративний або керований партнером), який використовується для взаємодії з телефонною мережею загального користування (PSTN) або застарілими внутрішніми телефонними мережами (включно з Unified CM).
Ви можете використовувати, щоб призначити локальний шлюз до розташування, після чого він надає параметри, які можна налаштувати на CUBE. Ці кроки реєструють локальний шлюз у хмарі, а потім служба ТМЗК через шлюз надається користувачам у певному розташуванні.
Щоб вибрати й замовити локальний шлюз, ознайомтеся з посібником із замовлення локального шлюзу.
Підтримувані розгортання локального шлюзу для
Підтримуються наведені нижче базові розгортання.
Локальний шлюз може бути розгорнуто автономно або в розгортаннях, де потрібна інтеграція в Cisco Unified Communications Manager.
Розгортання локального шлюзу без локальної внутрішньої телефонної мережі з підтримкою IP
Автономні розгортання локальних шлюзів
На цій діаграмі показано розгортання без наявних IP PBX і застосовується до одного розташування або розгортання з кількома розташуваннями.
Для всіх викликів, які не збігаються з вашими адресами призначення, надсилає ці виклики до локального шлюзу, призначеного для обробки розташування. Локальний шлюз маршрутизує всі виклики, що надходять із ТМЗК, а в іншому напрямку — до ТМЗК.
Шлюз PSTN може бути виділеною платформою або розміщеним спільно з локальним шлюзом. Як і на наведеному нижче рисунку, ми рекомендуємо варіант виділеного шлюзу ТМЗК цього розгортання. Він може бути використаний, якщо наявний шлюз ТМЗК не може бути використаний як локальний шлюз.
Розгортання спільно розміщеного локального шлюзу
Локальний шлюз може працювати на базі IP (підключення до ITSP виконується за допомогою SIP-транку) або TDM (підключення за допомогою ISDN або аналогової схеми). На наведеній нижче діаграмі показано розгортання, де локальний шлюз пов’язаний із ТМЗК GW/SBC.
Розгортання локального шлюзу з локальною внутрішньою телефонною мережею Unified CM
Інтеграція з Unified CM потрібна в наведених нижче випадках.
-
-увімкнені розташування додаються до наявного розгортання Cisco UC, де розгортається Unified CM як рішення для локального керування викликами
-
Потрібен прямий набір між телефонами, зареєстрованими в Unified CM, і телефонами в розташуваннях.
На цій діаграмі показано розгортання, де клієнт має наявний Unified CM IP PBX.
Webex Calling надсилає виклики, які не відповідають напрямкам призначення клієнта, до локального шлюзу. Сюди відносяться номери PSTN і внутрішні додаткові номери Unified CM, які Webex Calling не може розпізнати. Локальний шлюз маршрутизує всі виклики, які надходять від Webex Calling, до Unified CM і навпаки. Потім Unified CM маршрутизує вхідні виклики до локальних призначень або в PSTN відповідно до наявної абонентської групи. Абонентська група Unified CM нормалізує номери у формат +E.164. Шлюз PSTN може бути виділеним або розміщеним спільно з локальним шлюзом.
Виділений шлюз PSTN
Варіант виділеного шлюзу ТМЗК цього розгортання, як показано на цій діаграмі, є рекомендованим параметром і може використовуватися, якщо наявний шлюз ТМЗК не може бути використаний як локальний шлюз.
Шлюз PSTN, розміщений спільно
На цій діаграмі показано розгортання з Unified CM, де локальний шлюз пов’язаний із шлюзом ТМЗК/SBC.
Webex Calling усі виклики, які не відповідають пунктам призначення клієнта, маршрутизується до локального шлюзу, призначеного для розташування. Сюди відносяться призначення PSTN і виклики в середині мережі на внутрішні додаткові номери Unified CM. Локальний шлюз маршрутизує всі виклики в Unified CM. Потім Unified CM маршрутизує виклики на локально зареєстровані телефони або в PSTN через локальний шлюз, який має функціональні можливості PSTN або SBC.
Відомості щодо маршрутизації викликів
Виклики від на Unified CM
Логіка маршрутизації працює так: Якщо номер, набраний на кінцевому пристрої, не може бути переспрямований до іншого призначення в межах того самого клієнта у Webex Calling, виклик буде надіслано до локального шлюзу для подальшої обробки. Усі виклики поза мережею (за межами Webex Calling) спрямовуються до локального шлюзу.
Для розгортання без інтеграції в наявний Unified CM будь-який виклик поза мережею вважається викликом ТМЗК. У разі поєднання з Unified CM виклик поза мережею все ще може бути викликом усередині мережі до будь-якого призначення, розміщеного в Unified CM, або реальним викликом поза мережею до призначення PSTN. Відмінність між двома останніми типами викликів визначається Unified CM і залежить від корпоративної абонентської групи, яку підготовлено в Unified CM.
На наведеній нижче діаграмі показано, як користувач набирає національний номер в США.
Unified CM тепер базується на налаштованій абонентській групі й маршрутизує виклик на локально зареєстрований термінальний пристрій, де призначення виклику підготовлено як номер абонента. Для цього абонентська група Unified CM повинна підтримувати маршрутизацію на номери +E.164.
Виклики З Unified CM до
Щоб увімкнути маршрутизацію виклику з Unified CM до Unified CM, потрібно підготувати набір маршрутів, щоб визначити набір адрес плану +E.164 та плану нумерації підприємства в .
За наявності цих маршрутів можливі обидва сценарії викликів, наведені на малюнку нижче.
Якщо абонент, що телефонує в ТМЗК, викликає номер DID, призначений пристрою, тоді виклик передається до підприємства через шлюз ТМЗК підприємства, а потім потрапляє в Unified CM. Адреса виклику цього виклику збігається з одним із маршрутів, наданих в Unified CM, і виклик надсилається до локального шлюзу. (Адреса виклику повинна бути у форматі +E.164 під час надсилання до локального шлюзу.) Логіка маршрутизації Webex Calling потім упевніться, що виклик надіслано на призначений пристрій на основі призначення DID.
Крім того, до викликів, які надходять із зареєстрованих кінцевих пристроїв Unified CM, націлених на пункт призначення в , надається абонентська група, що надається в Unified CM. Як правило, ця абонентська група дозволяє користувачам здійснювати виклики, використовуючи загальні корпоративні варіанти набору номерів в організації. Ці варіанти не обов’язково можуть включати тільки набір номерів +E.164. Щоб забезпечити правильну маршрутизацію у Webex Calling, будь-який варіант набору, який відрізняється від +E.164, необхідно нормалізувати у формат +E.164 перед тим, як виклики буде спрямовано на локальний шлюз.
Клас служби (CoS)
Завжди рекомендується впроваджувати обмеження вузького класу служб із різних причин, включно з метою уникнення циклів викликів і запобігання шахрайству з платними службами. В контексті інтеграції Local Gateway з класом обслуговування Unified CM необхідно розглянути клас обслуговування для:
-
Пристрої, зареєстровані в Unified CM
-
Виклики, що надходять в Unified CM з PST
-
Виклики, що надходять в Unified CM з Webex Calling
Пристрої, зареєстровані в Unified CM
Додавання напрямів призначення як нового класу напрямів до наявного налаштування CoS є досить прямим кроком: дозвіл на здійснення викликів у напрямки зазвичай еквівалентний дозволу на здійснення локальних (зокрема міжсайтових) викликів.
Якщо корпоративна абонентська група вже реалізує дозвіл «(скорочено) в мережі між сайтами», то на Unified CM уже є розділ, який ми можемо використовувати та підготувати всі відомі в мережі напрямки в одному розділі.
В іншому випадку концепція дозволу «(скорочено) на веб-сайті» ще не існує, тому потрібно підготувати новий розділ (наприклад, «onNetRemote»), додати призначення до цього розділу, і, нарешті, цей новий розділ потрібно додати до відповідних просторів пошуку викликів.
Виклики, що надходять в Unified CM з PST
Додавання напрямів призначення як нового класу напрямів до наявного налаштування CoS є досить прямим кроком: дозвіл на здійснення викликів у напрямки зазвичай еквівалентний дозволу на здійснення локальних (зокрема міжсайтових) викликів.
Якщо корпоративна абонентська група вже реалізує дозвіл «(скорочено) в мережі між сайтами», то на Unified CM уже є розділ, який ми можемо використовувати та підготувати всі відомі в мережі напрямки в одному розділі.
В іншому випадку концепція дозволу «(скорочено) на веб-сайті» ще не існує, тому потрібно підготувати новий розділ (наприклад, «onNetRemote»), додати призначення до цього розділу, і, нарешті, цей новий розділ потрібно додати до відповідних просторів пошуку викликів.
Виклики, що надходять в Unified CM з Webex Calling
Виклики, які надходять із ТМЗК, потребують доступу до всіх напрямків. Це вимагає додавання наведеного вище розділу, який утримує всі призначення в простір пошуку викликів, що використовується для вхідних викликів на транку ТМЗК. Доступ до пункту призначення надається на додаток до наявного доступу.
Тоді як для викликів із доступу до ТМЗК до Unified CM DID і DID, потрібні виклики, які ініціюють доступ до Unified CM DID і пунктів призначення PSTN.
На цьому малюнку порівнюються два різних класи служби для викликів із PSTN і Webex Calling. На малюнку також показано, що у разі спільного розміщення функціональних можливостей шлюзу PSTN і локального шлюзу потрібні два транки від комбінованого шлюзу PSTN і локального шлюзу до Unified CM: один для викликів, які ініційовано в PSTN, і один для викликів, які ініційовано у Webex Calling. Це обумовлено вимогою застосовувати диференційовані простори пошуку викликів для кожного типу трафіку. Цього можна легко досягти за допомогою двох вхідних транків у Unified CM: необхідно налаштувати на кожному транку потрібний простір пошуку для вхідних викликів.
Інтеграція абонентської групи
Цей посібник передбачає наявне встановлення, яке базується на актуальних практичних порадах, наведених у розділі «Бажана архітектура для локальних розгортань рішень Cisco Collaboration, CVD». Остання версія доступна тут.
Рекомендований проєкт абонентської групи відповідає підходу до проєктування, який описано в розділі «Абонентська група» останньої версії SRND до системи Cisco Collaboration. Цей документ доступний тут.
На цьому малюнку показано огляд рекомендованого проєкту абонентської групи. Нижче наведено ключові характеристики цього проєкту абонентської групи.
-
Усі номери абонентів, які налаштовано в Unified CM, мають формат +E.164.
-
Усі номери абонентів знаходяться в одному розділі (DN), і їх позначено як термінові.
-
Основна маршрутизація базується на форматі +E.164.
-
Усі варіанти набору, які відрізняються від E.164 (наприклад, скорочений набір в об’єктах і набір номерів PSTN із використанням загальних варіантів набору номера), нормалізовано (глобалізовано) до формату +E.164 з використанням шаблонів перетворення нормалізації набору номера.
-
У шаблонах перетворення нормалізації набору номера використовується успадкування простору пошуку викликів у шаблоні перетворення. У цих шаблонах налаштовано параметр «Використовувати простір пошуку викликів джерела».
-
Клас служби впроваджується з використанням просторів пошуку викликів, специфічних для об’єкта й класу служби.
-
Можливості доступу до PSTN (наприклад, доступ до міжнародних призначень PSTN) впроваджуються шляхом додавання розділів з відповідними шаблонами маршрутів +E.164 до простору пошуку викликів, що визначає клас служби.
Досяжність Webex Calling
Щоб додати досяжність для призначень Webex Calling до цієї абонентської групи, необхідно створити розділ, що представляє всі призначення Webex Calling (під назвою Webex Calling), а також додати до цього розділу шаблон маршруту +E.164 для кожного діапазону DID у Webex Calling. Цей шаблон маршруту посилається на список маршрутів лише з одним учасником: група маршрутів із SIP-транком до локального шлюзу для викликів Webex Calling. Усі набрані призначення нормалізовано до +E.164 за допомогою шаблонів перетворення нормалізації набору для викликів, які ініційовано із зареєстрованих в Unified CM термінальних пристроїв, або перетворення номера абонента, якому телефонують для викликів, які ініційовано в PSTN. Тому цього єдиного набору шаблонів маршрутів +E.164 достатньо для досягнення досяжності призначень у Webex Calling, незалежно від використовуваного варіанта набору номера.
Наприклад, якщо користувач набирає номер 914085550165, то шаблон перетворення нормалізації набору номера в розділі UStoE164 нормалізує цей рядок набору в +14085550165, який потім відповідає шаблону маршруту для призначення Webex Calling у розділі Webex Calling. Unified CM у кінцевому підсумку спрямовує виклик на локальний шлюз.
Додавання скороченого міжоб’єктного набору
Рекомендованим способом додавання скороченого міжоб’єктного набору до вказаної абонентської групи є додавання шаблонів перетворення нормалізації набору для всіх об’єктів у групі корпоративних номерів до виділеного розділу (номер корпоративного значення, або ESN). Ці шаблони перетворення перехоплюють рядки набору у форматі групи корпоративних номерів і нормалізують набраний рядок у формат +E.164.
Щоб додати корпоративний скорочений набір до призначень Webex Calling, необхідно додати відповідний шаблон перетворення нормалізації набору для розташування Webex Calling до розділу Webex Calling (наприклад, 8101XX на схемі). Після процесу нормалізації виклик знову спрямовується до Webex Calling. Це виконується після відповідності шаблону маршруту в розділі Webex Calling.
Не рекомендується додавати шаблон перетворення нормалізації скороченого набору для викликів Webex Calling до розділу ESN, оскільки ця конфігурація може створювати небажані цикли маршрутизації викликів.
Обробники протоколів для Calling
реєструє наведені нижче обробники протоколів з операційною системою, щоб увімкнути функцію "натисніть, щоб здійснити виклик" із веббраузерів або іншого застосунку. Наступні протоколи починають аудіо- або відеовиклик у програмі Webex, коли ця програма використовується для викликів за замовчуванням на комп’ютері Mac або Windows:
-
CLICKTOCALL: або CLICKTOCALL://
-
SIP: або SIP://
-
TEL: або TEL://
-
WEBEXTEL: або WEBEXTEL://
Обробники протоколів для Windows
Інші програми можуть зареєструватися на обробники протоколу до . У Windows 10 передбачено системне вікно із запитом для користувачів щодо того, яку програму використовувати для запуску виклику. Встановивши прапорець у полі Завжди використовувати цю програму, можна запам’ятати налаштування користувача.
Якщо користувачам потрібно скинути налаштування програми викликів за замовчуванням, щоб вони могли вибрати , ви можете попросити їх змінити асоціації протоколу для Windows 10:
-
Відкрийте розділ Налаштування програми за замовчуванням , клацніть Установити параметри за замовчуванням за програмою, а потім виберіть .
-
Для кожного протоколу виберіть .
Обробники протоколів для macOS
На Mac OS, якщо інші програми зареєструвалися в протоколах викликів раніше , користувачі повинні налаштувати цей параметр, щоб бути параметром виклику за замовчуванням.
У разі використання Mac користувачі можуть підтвердити, що вибрано для Почати виклики з налаштуванням у розділі загальних бажаних параметрів. Вони також можуть встановити прапорець параметра Завжди підключатися до Microsoft Outlook , якщо вони хочуть здійснювати виклики на номер контакту Outlook, коли натискають на номер контакту Outlook.
Підготовка середовища
Загальні передумови
Перш ніж налаштовувати локальний шлюз для , переконайтеся, що:
-
Базові знання принципів VoIP
-
Базові знання принципів роботи голосових функцій Cisco IOS-XE й IOS-XE
-
Базове розуміння протоколу ініціювання сеансу (SIP).
-
Базова уява про Cisco Unified Communications Manager (Unified CM), якщо ваша модель розгортання містить Unified CM
Додаткову інформацію див. в Cisco Unified Border Element (CUBE) Enterprise Configuration Guide .
Вимоги до апаратного й програмного забезпечення для локального шлюзу
Переконайтеся, що у вашому розгортанні є один або кілька локальних шлюзів, як-от:
-
Cisco CUBE для підключення на основі IP
-
Шлюз Cisco IOS для з’єднання на основі TDM
Локальний шлюз допомагає виконати міграцію до Webex Calling у вашому власному темпі. Локальний шлюз інтегрує наявне локальне розгортання з Webex Calling. Також можна використовувати наявне підключення до ТМЗК. Див. розділ Початок роботи з локальним шлюзом
Вимоги до ліцензій для локальних шлюзів
На локальному шлюзі має бути встановлено ліцензії на виклики CUBE. Додаткову інформацію див. в посібнику з налаштування Cisco Unified Border Element.
Вимоги до сертифікатів і безпеки для локального шлюзу
потребує безпечного передавання сигналів і медіа. Локальний шлюз забезпечує шифрування; підключення TLS має бути встановлено для вихідних викликів до хмари за допомогою наведених далі кроків.
-
Локальний шлюз необхідно оновити за допомогою пакета кореневого ЦС, отриманого в Cisco PKI
-
Щоб налаштувати локальний шлюз, необхідно використовувати набір облікових даних SIP-дайджест-автентифікації зі сторінки налаштування транку в Control Hub (ці кроки є частиною конфігурації, яку наведено нижче)
-
Виконується перевірка наданого сертифікату за допомогою пакета кореневого ЦС
-
Надходить запит облікових даних (наданих SIP-дайджестом)
-
Хмара визначає, який локальний шлюз зареєстровано безпечно
Вимоги до брандмауера, обходу NAT й оптимізації шляху мультимедіа для локального шлюзу
У більшості випадків локальний шлюз і термінальні пристрої можуть знаходитися у внутрішній мережі клієнта, використовуючи приватні IP-адреси з NAT. Корпоративний брандмауер повинен дозволити вихідний трафік (SIP, RTP/UDP, HTTP) на певні IP-адреси/порти, які описано в розділі Довідкова інформація щодо портів.
Щоб використовувати оптимізацію шляху мультимедіа з ICE, інтерфейс локального шлюзу в напрямку Webex Calling повинен мати прямий мережевий шлях до термінальних пристроїв Webex Calling і від них. Щоб використовувати оптимізацію шляху мультимедіа, коли термінальні пристрої знаходяться в іншому розташуванні й між ними та інтерфейсом локального шлюзу в напрямку Webex Calling немає прямого мережевого шляху, локальний шлюз повинен мати загальнодоступну IP-адресу, призначену інтерфейсу в напрямку Webex Calling, для здійснення викликів між локальним шлюзом і термінальним пристроєм. Крім того, він повинен працювати під керуванням IOS-XE версії 16.12.5.
Довідкова інформація про порт для
Правильно налаштований брандмауер і проксі необхідні для успішного розгортання Calling. використовує SIP і HTTPS для передавання сигналів виклику, а також пов’язані адреси та порти для медіа, підключення до мережі та з’єднання шлюзів як глобальна служба.
Не всі конфігурації брандмауера потребують відкриття портів. Однак якщо ви виконуєте внутрішні правила, ви повинні відкрити порти для необхідних протоколів, щоб вимкнути служби.
Переклад мережевої адреси (NAT)
Функції перетворення мережевих адрес (NAT) і перетворення адрес порту (PAT) застосовуються на кордоні між двома мережами для перекладу просторів адрес або запобігання зіткненню просторів IP-адрес.
Організації використовують технології шлюзів, як-от брандмауери і проксі-сервери, що надають служби NAT або PAT, для надання доступу до інтернету до програм Webex або пристроїв Webex, що знаходяться в приватному просторі IP-адреси. Через ці шлюзи здається, що трафік від внутрішніх програм або пристроїв до інтернету надходить з однієї або кількох загальнодоступних IP-адрес, які можна маршрутизувати.
-
У разі розгортання NAT необов’язково відкривати вхідний порт на брандмауері.
-
Перевірте розмір пулу NAT, потрібний для підключення програми або пристроїв, коли кілька користувачів програми та пристроїв отримують доступ до служб визначення Webex Calling і Webex за допомогою NAT або PAT. Переконайтеся, що пулам NAT призначено належні публічні IP-адреси, щоб запобігти виснаженню портів. Виснаження портів призводить до того, що внутрішні користувачі та пристрої не можуть підключитися до служб Webex Calling і Webex Aware.
-
Визначте розумні періоди прив’язки та уникайте маніпулювання SIP на пристрої NAT.
-
Налаштуйте мінімальний тайм-аут NAT, щоб забезпечити належну роботу пристроїв. Приклад: Телефони Cisco надсилають повідомлення про оновлення РЕЄСТРУ подальшого спостереження кожні 1–2 хвилини.
-
Якщо у вашій мережі впроваджено NAT або SPI, установіть більший тайм-аут (принаймні 30 хвилин) для з’єднань. Цей тайм-аут дозволяє надійне підключення та одночасно знижує споживання заряду акумулятора мобільних пристроїв користувачів.
шлюз рівня застосунку SIP
Якщо маршрутизатор або брандмауер мають SIP Aware, що означає, що ввімкнено SIP Application Layer Gateway (ALG) або аналогічний рівень, рекомендуємо вимкнути цю функцію для точної роботи служби. Хоча увесь трафік Webex Calling зашифровано, деякі реалізації SIP ALG можуть спричинити проблеми з обходом брандмауера. Тому ми рекомендуємо вимкнути SIP ALG, щоб забезпечити високу якість обслуговування.
Перевірте відповідну документацію виробника, щоб визначити кроки для вимкнення SIP ALG на певних пристроях.
Підтримка проксі-сервера для
Організації розгортають інтернет-брандмауер або інтернет-проксі-сервер і брандмауер, щоб перевіряти, обмежувати та контролювати HTTP-трафік, який виходить із мережі та входить до неї. Таким чином, захищаючи свою мережу від різних форм кібератак.
Проксі-сервери виконують кілька функцій безпеки, наприклад:
-
Дозволити або блокувати доступ до певних URL-адрес.
-
Аутентифікація користувачів
-
Пошук репутації IP-адреси/домену/імені хоста/URI
-
Розшифровка та перевірка трафіку
У разі налаштування функції проксі вона застосовується до всіх програм, які використовують протокол HTTP.
Програма Webex і програми пристрою Webex включають наступне:
-
Служби Webex
-
Процедури активації пристрою клієнта (CDA) за допомогою платформи підготовки хмари Cisco, як-от GDS, EDOS, підготовка та приєднання до хмари Webex.
-
Автентифікація сертифіката
-
Оновлення мікропрограми
-
Звіти про стан
-
Вивантаження PRT
-
Служби XSI
Якщо налаштовано адресу проксі-сервера, на проксі-сервер надсилається лише трафік Сигналів (HTTP/HTTPS). Клієнти, які використовують SIP для реєстрації в службі Webex Calling, і пов’язані медіа, не надсилаються на проксі. Тому дозвольте цим клієнтам проходити безпосередньо через брандмауер.
Підтримувані параметри проксі, конфігурація та типи автентифікації
Підтримувані типи проксі:
-
Явний проксі (інспектування або неінспектування) — налаштуйте клієнти програми або пристрою з явним проксі-сервером, щоб указати сервер для використання.
-
Прозорий проксі (неінспектування) – клієнти не налаштовані на використання конкретної адреси проксі-сервера, і не потребують змін для роботи з проксі-сервером, що не інспектує.
-
Прозорий проксі (перевірка) – клієнти не налаштовані на використання конкретної адреси проксі-сервера. Зміни конфігурації HTTP не потрібні, однак вашим клієнтам або програмі, або пристроям потрібен кореневий сертифікат, щоб вони довіряли проксі. ІТ-команда використовує перевірку проксі-серверів для виконання політики на вебсайтах щодо відвідування та типів контенту, які заборонено.
Налаштуйте проксі-адреси вручну для пристроїв Cisco та програми Webex за допомогою:
-
ОС платформи
-
Інтерфейс користувача пристрою
-
Автоматично виявлено за допомогою механізмів Web Proxy, як-от:
-
Web Proxy Auto Discovery (WPAD) — протокол автоматичного виявлення веб-проксі
-
Файли автоматичної конфігурації проксі (PAC) — Файли автоматичної конфігурації проксі
-
Під час налаштування бажаних типів продуктів виберіть із таких конфігурацій проксі та типів автентифікації в таблиці:
|
Продукт |
Конфігурація проксі |
Тип автентифікації |
|---|---|---|
|
Webex для Mac |
Вручну, WPAD, PAC |
Немає автентифікації, Basic, NTLM,† |
|
Webex для Windows |
Вручну, WPAD, PAC, GPO |
Немає автентифікації, Basic, NTLM, †, узгодження † |
|
Webex для iOS |
Вручну, WPAD, PAC |
Без автентифікації, базова, дайджест, NTLM |
|
Webex для Android |
Вручну, PAC |
Без автентифікації, базова, дайджест, NTLM |
|
Webex Web App |
Підтримується через ОС |
Немає автентифікації, Basic, Digest, NTLM, узгодження † |
|
Пристрої Webex |
WPAD, PAC або вручну |
Без автентифікації, базова, дайджест |
|
IP-телефони Cisco |
Вручну, WPAD, PAC |
Без автентифікації, базова, дайджест |
|
Video Mesh Node у Webex |
Вручну |
Без автентифікації, базова, дайджест, NTLM |
Для легенд у таблиці:
-
†Автентифікація Mac NTLM – не потрібно входити до комп’ютера на домен, користувачу запропоновано пароль
-
†Автентифікація Windows NTLM — підтримується, лише якщо комп’ютер увійшов на домен
-
Узгоджуйте †- Kerberos із резервною автентифікацією NTLM.
-
Щоб підключити пристрій серії Cisco Webex Board, Desk або Room до проксі-сервера, див. розділ Підключити пристрій серії Board, Desk або Room до проксі-сервера.
-
Для IP-телефонів Cisco див. Налаштування проксі-сервера як приклад налаштування проксі-сервера та налаштувань.
Для No Authentication налаштуйте клієнт із проксі-адресою, яка не підтримує автентифікацію. Під час використання Proxy Authentication налаштуйте за допомогою допустимих облікових даних. Проксі-сервери, які перевіряють веб-трафік, можуть перешкоджати з'єднанню веб-сокетів. У разі виникнення цієї проблеми може вирішити проблему шляхом обходу неінспекційного трафіку на сайт *.Webex.com. Якщо ви вже бачите інші записи, додайте крапку з комою після останнього запису, а потім введіть виняток Webex.
Налаштування проксі для Windows OS
Microsoft Windows підтримує дві мережеві бібліотеки для HTTP-трафіку (WinINet і WinHTTP), які дозволяють конфігурацію проксі-сервера.WinINet є надмножиною WinHTTP.
-
WinInet розроблений для однокористувацьких застосунків для настільних ПК
-
WinHTTP розроблений насамперед для багатокористувацьких серверних програм.
Вибираючи між двома параметрами, виберіть WinINet для налаштувань конфігурації проксі. Подробиці див. у розділі wininet-vs-winhttp.
Додаткові відомості див. у розділі Налаштування списку дозволених доменів для доступу до Webex у вашій корпоративній мережі .
-
Щоб користувачі входили в програми, використовуючи облікові записи з попередньо визначеного списку доменів.
-
Використовуйте проксі-сервер для перехоплення запитів і обмеження дозволених доменів.
Перевірка проксі й закріплення сертифіката
Програма й пристрої Webex перевіряють сертифікати серверів, коли вони встановлюють сеанси TLS. Сертифікати перевіряють, що емітент сертифікатів і цифровий підпис залежать від перевірки ланцюжка сертифікатів до кореневого сертифіката. Щоб виконати перевірки перевірки, програма Webex і пристрої використовують набір довірених кореневих сертифікатів CA, установлених у сховищі довірених сертифікатів операційної системи.
Якщо ви розгорнули проксі-перевірку TLS для перехоплення, дешифрування та перевірки трафіку Webex Calling. Переконайтеся, що сертифікат, який надає проксі (замість сертифіката служби Webex), підписаний центром сертифікації, а кореневий сертифікат установлено в сховищі довірених даних вашої програми Webex або пристрою Webex.
-
Для програми Webex установіть сертифікат ЦС, який використовується для підписання сертифіката проксі-сервером в операційній системі пристрою.
-
Для пристроїв Webex Room і багатоплатформових IP-телефонів Cisco відкрийте запит на обслуговування до команди TAC для встановлення сертифіката CA.
У цій таблиці наведено програму Webex і пристрої Webex, які підтримують перевірку TLS проксі-серверами
|
Продукт |
Підтримує перевірку TLS для користувацьких довірених ЦС |
|---|---|
|
Програма Webex (для Windows, Mac, iOS, Android, інтернету) |
Так |
|
Пристрої Webex Room |
Так |
|
Багатоплатформові IP-телефони Cisco (MPP) |
Так |
Конфігурація брандмауера
Cisco підтримує служби Webex Aware у безпечних центрах обробки даних Cisco й Amazon Web Services (AWS). Amazon зарезервувала свої IP-підмережі для виняткового використання Cisco й забезпечила служби, розташовані в цих підмережах, у віртуальному приватному хмарі AWS.
Налаштуйте брандмауер, щоб дозволити зв’язок із ваших пристроїв, застосунків і служб, пов’язаних із Інтернетом, виконувати свої функції належним чином. Ця конфігурація дозволяє отримувати доступ до всіх підтримуваних хмарних служб і хмарних служб Webex Aware, доменних імен, IP-адрес, портів і протоколів.
Список білих або відкрийте доступ до наведеного нижче, щоб служби та служби Webex Aware працювали правильно.
-
URL-адреси/домени, зазначені в розділі Домени та URL для служб Webex Calling
-
IP-підмережі, порти та протоколи, зазначені в розділі IP-підмережі для служб Webex Calling
-
Якщо ви використовуєте Webex Suite хмарних служб співпраці в межах їхньої організації, консолі оператора Webex Meetings, обміну повідомленнями, консолі оператора Webex та інші служби, переконайтеся, що у вас є IP-підмережі, для доменів/URL, згаданих у цих статтях, відкрито Вимоги до мережі для служб Webex і Вимоги до мережі для консолі оператора.
Якщо ви використовуєте лише брандмауер, фільтрування трафіку тільки за допомогою IP-адрес не підтримується, оскільки деякі пули IP-адрес динамічні й можуть змінитися в будь-який час. Регулярно оновлюйте правила. Нездатність оновлювати список правил брандмауера може вплинути на досвід ваших користувачів. Cisco не схвалює фільтрування підмножини IP-адрес за конкретним географічним регіоном або постачальником хмарних послуг. Фільтрування за регіонами може призвести до серйозної деградації можливостей викликів.
Cisco не підтримує динамічну зміну пулів IP-адрес, тому його не перелічено в цій статті.
Якщо ваш брандмауер не підтримує фільтрування домену/URL, скористайтеся параметром корпоративного проксі-сервера. Цей параметр фільтрує/дозволяє за URL/доменом трафік HTTP, що передають сигнали, і служби Webex Aware на вашому проксі-сервері перед переадресацією у брандмауер.
Можна налаштувати трафік за допомогою фільтрації портів і підмережі IP для медіавикликів. Оскільки медіатрафік вимагає прямого доступу до інтернету, виберіть параметр фільтрування URL-адрес для сигнального трафіку.
Для , UDP є бажаним транспортним протоколом Cisco для медіа, і він рекомендує використовувати лише SRTP замість UDP. TCP і TLS як транспортні протоколи для медіа не підтримуються в виробничих середовищах. Орієнтований на зв’язок характер цих протоколів впливає на якість мультимедіа в мережах з втратами. Якщо у вас є запити щодо транспортного протоколу, надішліть запит до служби підтримки.
Домени та URL-адреси для служб Webex Calling
*, що відображається на початку URL-адреси (наприклад, *.webex.com), означає, що служби в домені верхнього рівня та на всіх субдоменах доступні.
|
Домен / URL |
Опис |
Програми й пристрої Webex, які використовують ці домени або URL-адреси |
|---|---|---|
|
Служби Cisco Webex | ||
|
*.broadcloudpbx.com |
Мікросервіси авторизації Webex для перехресного запуску від Control Hub до порталу виклику адміністратора. |
Control Hub |
|
*.broadcloud.com.au |
Служби Webex Calling в Австралії. |
Усе |
|
*.broadcloud.eu |
Служби Webex Calling в Європі. |
Усе |
|
*.broadcloudpbx.net |
Конфігурація клієнта Calling і керування послугами. |
Програми Webex |
|
*.webex.com *.cisco.com |
Основні служби Webex Calling і Webex Aware
Коли телефон вперше підключається до мережі або після відновлення заводських налаштувань без установлених параметрів DHCP, він контактує з сервером активації пристрою для надання нульової сенсорної інформації. Нові телефони використовують activate.cisco.com і телефони з випуском мікропрограми раніше 11.2(1), продовжуйте використовувати для підготовки вебзастосунків.cisco.com. Завантажте оновлення мікропрограми пристрою та локалізації з binaries.webex.com. Дозвольте телефонам Cisco Multiplatform Phones (MPP) старіше версії 12.0.3 отримувати доступ до sudirenewal.cisco.com через порт 80 для подовження встановленого сертифіката виробника (MIC) та наявності безпечного унікального ідентифікатора пристрою (SUDI). Додаткову інформацію див. в Повідомленні про поля. |
Усі |
|
*.ucmgmt.cisco.com |
Служби Webex Calling |
Control Hub |
|
*.wbx2.com та *.ciscospark.com |
Використовується для обізнаності хмари для зв’язку зі службами Webex Calling і Webex Aware під час приєднання та після. Ці служби необхідні для
|
Усі |
|
*.webexapis.com |
Мікрослужби Webex, які керують вашими програмами програми Webex і пристроями Webex.
|
Усі |
|
*.webexcontent.com |
Служби обміну повідомленнями Webex, пов’язані з загальним сховищем файлів, зокрема:
|
Служби обміну повідомленнями для програм Webex. Сховище файлів за допомогою webexcontent.com замінено на clouddrive.com у жовтні 2019 року |
|
*.accompany.com |
Інтеграція People Insights |
Програми Webex |
|
Додаткові служби, пов’язані з Webex (сторонні домени) | ||
|
*.appdynamics.com *.eum-appdynamics.com |
Відстеження продуктивності, запис помилок і аварійних збоїв, показники сеансу. |
Control Hub |
|
*.sipflash.com |
Служби керування пристроями. Оновлення версії мікропрограми та безпечна реєстрація. |
Програми Webex |
|
*.walkme.com *.walkmeusercontent.com |
Клієнт посібника користувача Webex. Надає інструкції з приєднання і використання для нових користувачів. Щоб отримати додаткову інформацію про WalkMe, клацніть тут. |
Програми Webex |
|
*.google.com *.googleapis.com |
Сповіщення для програм Webex на мобільних пристроях (приклад: нове повідомлення, коли отримано відповідь на виклик) Для IP-підмереж див. ці посилання Служба Google Firebase Cloud Messaging (FCM) Служба сповіщень Apple Push (APNS) Для APNS Apple перелічує IP-підмережі для цієї служби. | Програма Webex |
Підмережі IP для служб Webex Calling
|
IP-підмережі для служб Webex Calling*† | ||
|---|---|---|
|
23.89.0.0/16 |
85.119.56.0/23 |
128.177.14.0/24 |
|
128.177.36.0/24 |
135.84.168.0/21 |
139.177.64.0/21 |
|
139.177.72.0/23 |
144.196.0.0/16 |
150.253.128.0/17 |
|
163.129.0.0/17 |
170.72.0.0/16 |
170.133.128.0/18 |
|
185.115.196.0/22 |
199.19.196.0/23 |
199.19.199.0/24 |
|
199.59.64.0/21 | ||
|
Керування конфігурацією пристрою та мікропрограмою (пристрої Cisco) | ||
|
3.20.185.219 |
3.130.87.169 |
3.134.166.179 |
|
52.26.82.54 |
72.163.10.96/27 |
72.163.15.64/26 |
|
72.163.15.128/26 |
72.163.24.0/23 |
72.163.10.128/25 |
|
173.37.146.128/25 |
173.36.127.0/26 |
173.36.127.128/26 |
|
173.37.26.0/23 |
173.37.149.96/27 |
192.133.220.0/26 |
|
192.133.220.64/26 | ||
|
Конфігурація програми Webex | ||
|
62.109.192.0/18 |
64.68.96.0/19 |
150.253.128.0/17 |
|
207.182.160.0/19 | ||
|
Мета підключення | Адреси джерела | Порти джерела | Протокол | Адреси призначення | Порти призначення | Примітки | |
|---|---|---|---|---|---|---|---|
| Передавання сигналів виклику до Webex Calling (TLS SIP) | Зовнішній (NIC) локального шлюзу | 8000-65535 | TCP | Див. розділ Підмережі IP для служб Webex Calling. | 5062, 8934 |
Ці IP-адреси/порти необхідні для передавання сигналів виклику SIP-TLS від локальних шлюзів, пристроїв і програм Webex (джерело) до хмари Webex Calling (призначення). Порт 5062 (вимагається для транка на основі сертифіката). І порт 8934 (вимагається для транка на основі реєстрації | |
| Пристрої | 5060-5080 | 8934 | |||||
| Програма Webex | Тимчасовий (залежить від ОС) | ||||||
| Передавання сигналів виклику від Webex Calling (SIP TLS) до локального шлюзу |
Діапазон адрес Webex Calling. Посилання на IP-підмережі для служб Webex Calling | 8934 | TCP | IP-адреси або діапазони IP, вибрані клієнтом для локального шлюзу | Порт або діапазон портів, вибраний клієнтом для локального шлюзу. |
Застосовується до локальних шлюзів на основі сертифіката. Необхідно встановити з’єднання від Webex Calling до локального шлюзу. Локальний шлюз на основі реєстрації працює над повторним використанням з’єднання, створеного з локального шлюзу. Порт призначення – клієнт вибрав Налаштувати транки. | |
| Носії викликів у Webex Calling (STUN, SRTP/SRTCP, T38, DTLS) | Зовнішній NIC локального шлюзу | 8000-48199†* | UDP | Див. розділ Підмережі IP для служб Webex Calling. |
5004, 9000 (порти STUN) Аудіо: 8500-8599 Відео: 8600-8699 19560-65535 (SRTP через UDP) |
| |
| Пристрої†* | 19560-19661 | ||||||
|
Пристрої VG400 ATA | 19560-19849 | ||||||
| Програма Webex†* |
Аудіо: 8500-8599 Відео: 8600-8699 | ||||||
|
WebRTC | Ефемерний (згідно з політикою браузера) | ||||||
| Медіафайли викликів із Webex Calling (SRTP/SRTCP, T38) |
Діапазон адрес Webex Calling. Посилання на IP-підмережі для служб Webex Calling | 19560-65535 (SRTP через UDP) | UDP | Вибрана клієнтом IP-адреса або діапазон IP-адрес для локального шлюзу | Діапазон медіапортів, вибраний клієнтом для локального шлюзу. | ||
| Передавання сигналів виклику до шлюзу PSTN (TLS SIP) | Внутрішній NIC локального шлюзу | 8000-65535 | TCP | Ваш шлюз PSTN ITSP або Unified CM | Залежить від параметра PSTN (наприклад, зазвичай для Unified CM використовується 5060 або 5061) | ||
| Виклик медіафайлів на шлюз PSTN (SRTP/SRTCP) | Внутрішній NIC локального шлюзу | 8000-48199†* | UDP | Ваш шлюз PSTN ITSP або Unified CM | Залежить від параметра ТМЗК (наприклад, зазвичай 5060 або 5061 для Unified CM) | ||
| Конфігурація пристрою і керування мікропрограмним забезпеченням (пристрої Cisco) | Пристрої Webex Calling | Короткотерміновий | TCP |
Посилання на IP-підмережі для служб Webex Calling | 443, 6970, 80 |
Вимагається з таких причин:
| |
| Конфігурація програми Webex | Програми Webex | Короткотерміновий | TCP |
Посилання на IP-підмережі для служб Webex Calling | 443, 8443 | Використовується для автентифікації Id Broker, служб конфігурації програми Webex для клієнтів, вебдоступу на основі браузера для самообслуговування Та доступу до Адміністративного інтерфейсу. Порт TCP 8443 використовується програмою Webex у налаштуванні Cisco Unified CM для завантаження конфігурації. Відкривати порт повинні лише клієнти, які використовують налаштування для підключення до Webex Calling. | |
| Синхронізація часу пристрою (NTP) | Пристрої Webex Calling | 51494 | UDP | Див. розділ Підмережі IP для служб Webex Calling. | 123 | Ці IP-адреси необхідні для синхронізації часу на пристроях (телефони MPP, ATA й SPA ATA) | |
|
Роздільна здатність системи доменних імен (DNS) | Пристрої Webex Calling, програма Webex і пристрої Webex | Короткотерміновий | UDP й TCP | Визначив хост | 53 | Використовується для пошуку DNS з метою виявлення IP-адрес служб Webex Calling у хмарі. Хоча типові пошуки DNS виконуються через UDP, деякі з них можуть потребувати TCP, якщо відповіді запиту не вписуються в пакети UDP. | |
| Протокол мережевого часу (NTP) | Програма Webex і пристрої Webex | 123 | UDP | Визначив хост | 123 | Синхронізація часу | |
| CScan | Інструмент підготовки до кваліфікації для Webex Calling на основі вебмережі | Короткотерміновий | TCP | Див. розділ Підмережі IP для служб Webex Calling. | 8934 і 443 | Інструмент для попередньої кваліфікації готовності до мережі для Webex Calling. Додаткову інформацію див. на сторінці cscan.webex.com. | |
| UDP | 19569-19760 | ||||||
| Додаткові служби Webex Calling і Webex Aware (третя сторона) | |||||||
| Push-сповіщення APNS і служби FCM | Програми Webex Calling | Короткотерміновий | TCP |
Посилання на IP-підмережі, зазначені за посиланнями | 443, 2197, 5228, 5229, 5230, 5223 | Сповіщення для програм Webex на мобільних пристроях (приклад: Коли ви отримаєте нове повідомлення або на виклик) | |
-
†*Діапазон медіапорту CUBE можна налаштувати за допомогою діапазону порту rtp.
-
†*Медіапорти для пристроїв і програм, динамічно призначені в діапазонах портів SRTP. Порти SRTP є парними номерами, а відповідний порт SRTCP виділений з послідовним непарним номером порту.
-
Якщо для ваших програм і пристроїв налаштовано адресу проксі-сервера, трафік сигналів буде надіслано на проксі. Мультимедіа, які транспортують SRTP через потоки UDP безпосередньо до вашого брандмауера замість проксі-сервера.
-
Якщо ви використовуєте служби NTP і DNS у своїй корпоративній мережі, відкрийте порти 53 і 123 через брандмауер.
Якість обслуговування (QoS)
Дозволяє ввімкнути позначення пакетів із локального пристрою або клієнта на хмарну платформу Webex Calling. Завдяки QoS можна визначити пріоритет трафіку в реальному часі над іншим трафіком даних. Увімкнення цього параметра призведе до зміни маркування QoS для програм і пристроїв, які використовують сигнали SIP та медіафайли.
| Адреси джерела | Тип трафіку | Адреси призначення | Порти джерела | Порти призначення | Клас і значення DSCP |
|---|---|---|---|---|---|
| Програма Webex | Аудіо |
Посилання на IP-підмережі, домени та URL-адреси для служб Webex Calling | 8500-8599 | 8500-8599, 19560-65535 | Прискорена переадресація (46) |
| Програма Webex | Відео | 8600-8699 | 8600-8699, 19560-65535 | Гарантована переадресація 41 (34) | |
| Програма Webex | Передавання сигналів | Тимчасовий (залежить від ОС) | 8934 | cs0 (0) | |
| Пристрої Webex (MPP і кімната) | Аудіо та відео | 19560-19661 | 19560-65535 |
Прискорена переадресація (46) & Гарантована переадресація 41 (34) | |
| Пристрої Webex | Передавання сигналів | 5060-5080 | 8934 | Селектор класу 3 (24) |
-
Створіть окремий профіль QoS для аудіо- та відео- та спільного доступу, оскільки вони мають інший діапазон портів джерела для різних позначок трафіку.
-
Для клієнтів Windows: Щоб увімкнути диференціацію вихідного порту UDP для вашої організації, зверніться до команди локальних облікових записів. Якщо цей параметр не ввімкнено, ви не можете розрізнити аудіо та відео/спільний доступ за допомогою політики QoS Windows (GPO), оскільки вихідні порти однакові для аудіо/відео/спільного доступу. Додаткову інформацію див. в розділі Увімкнути діапазони портів джерела медіа для програми Webex
-
Для пристроїв Webex налаштуйте зміни налаштувань QoS у налаштуваннях пристрою Control Hub. Додаткову інформацію див. в розділі Налаштування та зміна налаштувань пристрою у Webex-Calling.
Webex Meetings / обмін повідомленнями: вимоги до мережі
Для клієнтів, які використовують Webex Suite хмарних служб співпраці, зареєстрованих у хмарі продуктами Webex, вбудувати пристрої MPP до хмари Webex для таких служб, як історія викликів, пошук у каталозі, наради та обмін повідомленнями. Переконайтеся, що домени/URL/IP-адреси/порти, зазначені в цій статті, відкриті вимоги до мережі для служб Webex.
Вимоги до мережі для Webex for Government
Для клієнтів, які потребують списку доменів, URL-адрес, діапазонів IP-адрес і портів для Webex for Government Services (FedRAMP), інформацію можна знайти тут: Вимоги до мережі для Webex for Government
Вимоги до мережі для консолі оператора Webex
Для клієнтів, які використовують консоль оператора – функцію секретарів, секретарів і операторів, переконайтеся, що в розділі «Домени/URL/IP-адреси/порти/протоколи» відкрито Вимоги до мережі для консолі оператора.
Початок роботи з локальним шлюзом Webex Calling
Для клієнтів, які використовують рішення локального шлюзу з Webex Calling для локальних ТМЗК і сторонніх SBC, ознайомтеся зі статтею Початок роботи з локальним шлюзом.
Посилання
Щоб дізнатися, що нового у Webex Calling, перегляньте розділ Нові можливості у Webex Calling.
Вимоги Безпеки для Webex Calling див. в статті
Стаття Оптимізація мультимедіа Webex Calling із інтерактивним установленням підключення (ICE)
Історія перегляду документа
|
Дата |
До цієї статті внесено наведені нижче зміни |
|---|---|
|
21 січня 2025 року |
Додано відомості про використання шлюзу рівня застосунку SIP. |
|
8 січня 2025 року |
Переміщено адресу IP-підмережі, пов’язану з конфігурацією пристрою та конфігурацією програми Webex, у розділ IP-підмережі для служб Webex Calling . |
|
17 грудня 2024 року |
До WebRTC додано підтримку для специфікації мультимедіа Webex Calling. |
|
14 листопада 2024 року |
Оновлено підтримуваний діапазон портів для медіафайлів викликів Webex Calling для пристрою ATA серії VG400. |
|
11 листопада 2024 року |
Додано підтримуваний діапазон портів для медіафайлів викликів Webex Calling для пристрою ATA серії VG400 |
|
25 липня 2024 року |
Додано IP-підмережу 52.26.82.54, оскільки вона є обов’язковою для конфігурації пристрою Cisco ATA та керування мікропрограмою. |
|
18 липня 2024 року |
Оновлено з наступними деталями:
|
|
28 червня 2024 року |
Оновлено використання обох діапазонів портів SRTP/ SRTCP для специфікації медіафайлів Webex Calling. |
|
11 червня 2024 року |
Домен "huron-dev.com" видалено, оскільки він не використовується. |
|
06 травня 2024 р. |
Оновлено використання обох діапазонів портів SRTP/ SRTCP для специфікації медіафайлів Webex Calling. |
|
03 квітня 2024 р. | Підмережі IP для служб Webex Calling оновлено на рівні 163.129.0.0/17, щоб адаптувати розширення ринку Webex Calling для регіону Індії. |
|
18 грудня 2023 року |
Включено URL-адресу sudirenewal.cisco.com та вимоги до порту 80 для конфігурації пристрою та керування мікропрограмним забезпеченням подовження МІКРОФОНА телефону Cisco MPP. |
|
11 грудня 2023 року |
Підмережі IP для служб Webex Calling оновлено, щоб включити більший набір IP-адрес. 150.253.209.128/25 – змінено на 150.253.128.0/17 |
|
29 листопада 2023 року |
Підмережі IP для служб Webex Calling оновлено, щоб включити більший набір IP-адрес для забезпечення розширення регіону Webex Calling для подальшого зростання. 144.196.33.0/25 – змінено на 144.196.0.0/16 Для ясності щодо транкінгу на основі сертифіката та вимог брандмауера для локального шлюзу оновлено підмережі IP для Webex Calling (SIP TLS) і медіафайлів викликів на Webex Calling (STUN, SRTP). |
|
14 серпня 2023 р. |
Ми додали такі IP-адреси 144.196.33.0/25 і 150.253.156.128/25 для підтримки додаткових вимог до місткості для служб Edge і Webex Calling. Цей діапазон IP-адрес підтримується лише в регіоні США. |
|
5 липня 2023 року |
Додано посилання, https://binaries.webex.com щоб установити мікропрограму Cisco MPP. |
|
7 березня 2023 р. |
Ми переглянули всю статтю, щоб включити:
|
|
5 березня 2023 р. |
Оновлення статті, щоб включити таке:
|
|
15 листопада 2022 р. |
Для конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco) додано такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco):
|
|
14 листопада 2022 року |
Додано IP-підмережу 170.72.242.0/24 для служби Webex Calling. |
|
Вересень 08, 2022 |
Мікропрограма Cisco MPP переходить на використання https://binaries.webex.com як URL-адреса організатора для оновлення версії мікропрограми MPP в усіх регіонах. Ця зміна підвищує продуктивність оновлення мікропрограми. |
|
Серпень 30, 2022 |
Посилання на порт 80 видалено з розділу «Конфігурація пристрою та керування мікропрограмним забезпеченням (пристрої Cisco)», конфігурація застосунку та рядки CScan у таблиці «Порт», оскільки немає залежності. |
|
Серпень 18, 2022 |
Жодних змін у рішенні. Оновлено порти призначення 5062 (необхідні для багажника на основі сертифікатів), 8934 (необхідні для каналу реєстрації) для сигналізації виклику до Webex Calling (SIP TLS). |
|
Липень 26, 2022 |
Додано IP-адресу 54.68.1.225, яка потрібна для оновлення прошивки пристроїв Cisco 840/860. |
|
Липень 21, 2022 |
Оновлено порти призначення 5062, 8934 для сигналізації виклику до Webex Calling (SIP TLS). |
|
Липень 14, 2022 |
Додано URL-адреси, які підтримують повну функцію служб Webex Aware. Додано IP-підмережу 23.89.154.0/25 для служби Webex Calling. |
|
Червні 27, 2022 |
Оновлено домен та URL-адреси для послуг Webex Calling: *.broadcloudpbx.com *.broadcloud.com.au *.broadcloud.eu *.broadcloudpbx.net |
|
Червні 15, 2022 |
Додано такі порти та протоколи в розділі IP-адреси та порти для послугвиклику Webex:
Оновлена інформація в розділі Webex Meetings/Messaging — Вимоги до мережі |
|
Травень 24, 2022 |
Додано IP-підмережу 52.26.82.54/24 до 52.26.82.54/32 для послуги Webex Calling |
|
Травень 6, 2022 |
Додано IP-підмережу 52.26.82.54/24 для послуги Webex Calling |
|
7 квітня 2022 р. |
Діапазон внутрішніх і зовнішніх портів UDP локального шлюзу оновлено до 8000-48198† |
|
5 квітня 2022 р. |
Додано наступні підмережі IP для служби Webex Calling:
|
|
29 березня 2022 р. |
Додано наступні підмережі IP для служби Webex Calling:
|
|
20 вересня 2021 р. |
Додано 4 нові підмережі IP для служби Webex Calling:
|
|
2 квітня 2021 р. |
Додано *.ciscospark.com у розділі Домени та URL-адреси для служб Webex Calling для підтримки випадків використання Webex Calling у програмі Webex. |
|
25 березня 2021 р. |
Додано 6 нових діапазонів IP-адрес для activate.cisco.com. Термін дії набуває чинності з 8 травня 2021 року.
|
|
4 березня 2021 р. |
Замінено дискретні IP-адреси Webex Calling і менші діапазони IP зі спрощеними діапазонами в окремій таблиці для зручності розуміння конфігурації брандмауера. |
|
26 лютого 2021 р. |
Додано 5004 як порт призначення для виклику медіа до Webex Calling (STUN, SRTP) для підтримки інтерактивного встановлення зв'язку (ICE), яке буде доступне у Webex Calling у квітні 2021 року. |
|
22 лютого 2021 р. |
Домени і URL тепер перелічено в окремій таблиці. Таблиця IP-адрес і портів налаштована з урахуванням групових IP-адрес для тих самих служб. Додавання стовпця Примітки до таблиці IP-адрес і портів, що допоможе вам зрозуміти вимоги. Переміщення таких IP-адрес у спрощені діапазони для конфігурації пристроїв і керування мікропрограмним забезпеченням (пристрої Cisco):
Додавання таких IP-адрес для конфігурації застосунку, оскільки клієнт Cisco Webex вказує на новіший DNS SRV в Австралії у березні 2021 року.
|
|
21 січня 2021 р. |
До конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco) додано такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації пристрою та керування мікропрограмним забезпеченням (пристрої Cisco):
Ми додали до конфігурації застосунку такі IP-адреси:
Ми видалили такі IP-адреси з конфігурації застосунку:
Ми видалили з конфігурації застосунку такі номери портів:
До конфігурації застосунку додано такі домени:
|
|
23 грудня 2020 р. |
До довідкових зображень портів додано нові IP-адреси конфігурації програм. |
|
22 грудня 2020 р. |
В рядок «Конфігурація програми» в таблицях додано наступні IP-адреси: 135.84.171.154 і 135.84.172.154. Приховуйте мережеві діаграми, доки не буде додано ці IP-адреси. |
|
11 грудня 2020 р. |
Оновлено конфігурацію пристрою і систему керування мікропрограмним забезпеченням (пристрої Cisco), а також рядки конфігурації програми для підтримуваних канадських доменів. |
|
16 жовтня 2020 р. |
Оновлено сигнальні й мультимедійні записи з використанням таких IP-адрес:
|
|
23 вересня 2020 р. |
У CScan замінено 199.59.64.156 на 199.59.64.197. |
|
14 серпня 2020 р. |
Додано додаткові IP-адреси для підтримки впровадження центрів обробки даних у Канаді: Передавання сигналів виклику до Webex Calling (TLS SIP): 135.84.173.0/25, 135.84.174.0/25, 199.19.19.197.0/24, 199.19.199.0/24 |
|
12 серпня 2020 р. |
Додано додаткові IP-адреси для підтримки впровадження центрів обробки даних у Канаді:
|
|
22 липня 2020 р. |
Додано наступну IP-адресу для підтримки впровадження центрів обробки даних у Канаді: 135.84.173.146 |
|
9 червня 2020 р. |
До запису CScan внесено наведені нижче зміни.
|
|
11 березня 2020 р. |
Ми додали такі домени та IP-адреси до конфігурації застосунку:
У розділі конфігурації пристрою і керування мікропрограмним забезпеченням оновлено наступні домени (додано додаткові IP-адреси):
|
|
27 лютого 2020 р. |
У розділі конфігурації пристрою і керування мікропрограмним забезпеченням додано наступний домен і порти: cloudupgrader.webex.com—443, 6970 |
Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Огляд
Webex Calling наразі підтримує дві версії локального шлюзу:
-
Локальний шлюз
-
Локальний шлюз для Webex for Government
-
Перед початком ознайомтеся з вимогами локальної телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise на використання як функції локального шлюзу для Webex Calling, зверніть увагу на цю конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функціональність через внесені вами зміни.
Процедури містять посилання на довідкову документацію з команд, де ви можете дізнатися більше про окремі параметри команд. Якщо не зазначено інше, посилання на команди перейдуть до посилання на команди керованих шлюзів Webex (у такому випадку посилання на команди перейдуть до посилання на голосові команди Cisco IOS). Усі ці посібники можна отримати за посиланням на команди Cisco Unified Border Element.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації щодо продуктів.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифіката , щоб налаштувати локальний шлюз для вашого транка Webex Calling.
Додаткову інформацію про різні типи транка див. в розділі Початок роботи з локальним шлюзом . Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціювання сеансу (SIP) і протокол безпеки транспортного рівня (TLS) для захисту транка, а протокол безпеки в реальному часі (SRTP) для захисту медіафайлів між локальним шлюзом і Webex Calling.
-
Виберіть CUBE як локальний шлюз. Webex for Government наразі не підтримує жодних сторонніх контролерів прикордонних сеансів (SBC). Щоб переглянути останній список, див. розділ Початок роботи з локальним шлюзом.
- Установіть Cisco IOS XE Dublin 17.12.1a або пізніші версії для всіх Webex для державних локальних шлюзів.
-
Щоб переглянути список кореневих органів сертифікації (CA), які підтримує Webex for Government, див. розділ Кореневі органи сертифікації для Webex for Government.
-
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex for Government див. в статті Вимоги до мережі для Webex for Government (FedRAMP).
Локальний шлюз для Webex for Government не підтримує таке:
-
STUN/ICE-Lite для оптимізації шляху медіафайлів
-
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex for Government, скористайтеся таким параметром.
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у локальному шлюзі на основі сертифіката , щоб налаштувати локальний шлюз для транка Webex Calling. Додаткову інформацію про налаштування локального шлюзу на основі сертифіката див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Необхідно налаштувати шифри GCM, сумісні з FIPS, для підтримки локального шлюзу для Webex for Government. Якщо ні, не вдасться налаштувати виклик. Додаткові відомості про конфігурацію див. в розділі Налаштування транка на основі сертифіката Webex Calling.
Webex for Government не підтримує локальний шлюз на основі реєстрації.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи SIP-транк, що реєструється. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. На наведеному нижче зображенні висвітлено це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Хоча IP та SIP стали протоколами за замовчуванням для транків ТМЗК, схеми ISDN TDM (мультиплексування з поділом часу) все ще широко використовуються та підтримуються транками Webex Calling. Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати двосторонній процес маршрутизації викликів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
-
Крок 1. Налаштування базового з’єднання та безпеки маршрутизатора
-
Крок 2: Налаштувати транк Webex Calling
Залежно від необхідної архітектури виконайте такі дії:
-
Крок 3: Налаштувати локальний шлюз із SIP ТМЗК-транком
-
Крок 4: Налаштувати локальний шлюз з існуючим уніфікованим середовищем CM
Або:
-
Крок 3: Налаштування локального шлюзу з транком ТМЗК
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі реєстрації потребують Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовано використовувати Cisco IOS 17.12.2 або пізнішої версії. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
NTP
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу.
-
Передайте пакет кореневого CA Cisco до локального шлюзу.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть реєстраційні дані та облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так:
|
| 3 |
Створіть точку довіри PKI-заповнювача. Ця точка довіри вимагає, щоб налаштувати TLS пізніше. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це було б потрібно для транка на основі сертифіката. |
| 4 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням за допомогою наступних команд конфігурації. Також необхідно оновити параметри транспортування, щоб забезпечити надійне безпечне з'єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволяє з’єднання, якщо ім’я хоста, налаштоване в клієнті 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистого URL-адреси , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Зверніть увагу на інформацію про транк, яка надається після його створення. Деталі, виділені на ілюстрації, використовуються в кроках конфігурації цього посібника. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистика медіаЗабезпечує моніторинг медіафайлів на локальному шлюзі. масові стани медіаДозволяє площині управління опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див. у розділі Медіа. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базової функції оператора SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Додаткову інформацію див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шаблон для ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте dtg=, після чого вказується значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 7 |
Налаштуйте профіль SIP 100, який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 8 |
Налаштуйте транк Webex Calling: |
Після визначення клієнта 100 та налаштування вузла набору SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі доступ SBC надає свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат доступу SBC Webex Calling за допомогою кореневої групи CA, яка була оновлена раніше. Якщо сертифікат розпізнано, між локальним шлюзом і доступом Webex Calling SBC встановлюється постійний сеанс TLS. Потім локальний шлюз може використовувати це захищене з’єднання, щоб зареєструватися в системі доступу Webex SBC. Коли з’являється проблема реєстрації на автентифікацію:
-
У відповіді використовуються параметри ім’я користувача, пароль і області з конфігурації облікових даних .
-
Правила модифікації в sip профілі 100 використовуються для перетворення URL SIPS назад у SIP.
Реєстрація успішна, коли 200 OK отримано з SBC доступу.
Після того як ви створили транк у напрямку Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк у напрямку постачальника ТМЗК на базі SIP.
Якщо ваш постачальник послуг пропонує безпечний транк ТМЗК, ви можете використовувати ту саму конфігурацію, яку описано вище для транка Webex Calling. CUBE підтримує безпечну маршрутизацію виклику.
Якщо ви використовуєте транк ТМЗК TDM / ISDN, перейдіть до наступного розділу Налаштування локального шлюзу за допомогою транка ТМЗК TDM.
Щоб налаштувати інтерфейси TDM для гілок виклику PSTN у шлюзах Cisco TDM-SIP, див. розділ Налаштування ISDN PRI.
| 1 |
Налаштуйте такий URI-клас голосового зв’язку для ідентифікації вхідних викликів із транка ТМЗК: Ось пояснення полів для конфігурації: 200 sip URI класу голосового зв’язкуВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте IP-адресу вашого шлюзу IP ТМЗК. Додаткову інформацію див. в розділі URI класу голосового зв’язку. |
| 2 |
Налаштуйте такий вузол набору IP-адрес ТМЗК: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.13Задає цільову адресу для викликів, надісланих постачальнику ТМЗК. Це може бути IP-адреса або ім’я хоста DNS. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). вхідні URI через 200Визначає клас голосового зв’язку, який використовується для зіставлення вхідних викликів із цим одноранговим абонентом за допомогою ЗАПРОШЕННЯ ЧЕРЕЗ URI заголовка. Додаткову інформацію див. в URL-адресу вхідного виклику. ідентифікатор сертифікації sip-класу голосового типу pai
(Необов’язково) Вмикає обробку заголовка P-Asserted-Identity і керує тим, як він використовується для транка ТМЗК. Якщо використовується ця команда, для заголовків вихідних параметрів From і P-Asserted-Identity використовуватиметься ідентифікатор абонента, що телефонує, наданий від вхідного однорангового абонента для вихідних викликів. Якщо ця команда не використовується, для заголовків ідентифікатора абонента, що телефонує, наданий із вхідного абонента для набору, використовуватиметься ідентифікатор абонента, що телефонує, а також для заголовків ідентифікатора віддаленого абонента. Додаткову інформацію див. в розділі sip asserted-id для голосового класу. прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0
Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для повідомлень, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див. у розділі прив’язки. кодек голосового класу 100Налаштування вузла набору для використання спільного списку фільтрів кодека 100. Додаткову інформацію див. в розділі кодек голосового класу. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 3 |
Якщо ви налаштовуєте локальний шлюз лише для маршрутизації викликів між Webex Calling і ТМЗК, додайте таку конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після побудови транка у напрямку Webex Calling використовуйте наведену далі конфігурацію, щоб створити транк TDM для вашої служби ТМЗК з маршрутизацією зворотного виклику, щоб дозволити оптимізацію мультимедіа в гілці виклику Webex.
Якщо вам не потрібна оптимізація IP-медіафайлів, виконайте кроки конфігурації для SIP ТМЗК-транка. Використовуйте голосовий порт і вузол набору POTS (як показано в кроках 2 і 3) замість вузла набору VoIP ТМЗК.
| 1 |
Конфігурація однорангового набору зворотного виклику використовує групи однорангових викликів і теги маршрутизації викликів, щоб переконатися, що виклики передаються правильно між Webex і ТМЗК, без створення циклів маршрутизації викликів. Налаштуйте наведені нижче правила перетворення, які будуть використовуватися для додавання та видалення тегів маршрутизації викликів. Ось пояснення полів для конфігурації: правило голосового перекладуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Додаткові десятирічні цифри («А») використовуються для додавання чіткості під час усунення несправностей. У цій конфігурації тег, доданий профілем перетворення 100, використовується для спрямування викликів із Webex Calling до ТМЗК через абонентів зворотного виклику. Аналогічно, тег, доданий профілем перетворення 200, використовується для спрямування викликів із ТМЗК у Webex Calling. Профілі перекладу 11 та 12 видаляють ці теги, перш ніж здійснювати виклики до транків Webex і ТМЗК відповідно. Цей приклад припускає, що номери, яких викликають у Webex Calling, представлені у форматі +E.164. Правило 100 видаляє початкове значення +, щоб зберегти допустимий номер, з якого йде виклик. Правило 12 потім додає національні або міжнародні цифри маршрутизації під час видалення тегу. Використовуйте цифри, які відповідають місцевій національній абонентській групі ISDN. Якщо Webex Calling представляє номери у національному форматі, налаштуйте правила 100 і 12, щоб просто додати та видалити тег маршрутизації відповідно. Додаткову інформацію див. в розділі профіль голосового перекладу та правило голосового перекладу. |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до вимог використовуваного типу транка та протоколу. Додаткову інформацію див. в розділі Налаштування ISDN PRI. Наприклад, базова конфігурація інтерфейсу ISDN Primary Rate, встановленого в слоті NIM 2 пристрою, може включати наступне: |
| 3 |
Налаштуйте такий одноранговий вузол набору TDM PSTN: Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP з тегом 200 і дає змістовний опис для простоти керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. У цьому випадку можна використовувати будь-який допустимий шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). вхідні дані з профілю перекладу 200Призначте профіль перетворення, який додасть тег маршрутизації виклику до вхідного набраного номера. прямий-внутрішній-набірМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див. в розділі особистий набір. порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цим вузлом набору. |
| 4 |
Щоб увімкнути оптимізацію мультимедіа IP-шляхів для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, ввівши набір внутрішніх однорангових абонентів зворотного циклу між Webex Calling і транками ТМЗК. Налаштуйте такі однорангові вузли для набору зворотного циклу. У цьому випадку всі вхідні виклики будуть маршрутизовані спочатку до однорангового набору 10, а звідти до однорангового набору 11 або 12 на основі застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизовані до вихідного транка за допомогою груп однорангових викликів. Ось пояснення полів для конфігурації: Визначає одноранговий вузол для набору VoIP та дає змістовний опис для зручності керування та усунення несправностей. Додаткову інформацію див. в розділі голос абонента для набору номера. вхідні дані з профілю перекладу 11Застосовує профіль перетворення, визначений раніше, щоб видалити тег маршрутизації виклику перед передаванням до вихідного транка. шаблон призначення ПОГАНИЙ.ПОГАНИЙПід час маршрутизації вихідних викликів за допомогою групи вхідних однорангових викликів потрібен шаблон призначення. Додаткову інформацію див. в розділі цільовий шаблон (інтерфейс). протокол сеансу sipv2Вказує, що цей одноранговий набір обробляє гілки викликів SIP. Додаткову інформацію див. в протоколі сеансу (вузол набору). цільовий сеанс ipv4: 192.168.80.14Задає адресу локального інтерфейсу маршрутизатора як ціль виклику для зворотного виклику. Додаткову інформацію див. в цільовому призначенні сеансу (вузол набору VoIP). прив’язати керування вихідним інтерфейсом GigabitEthernet0/0/0Налаштування вихідного інтерфейсу та пов’язаної з ним IP-адреси для повідомлень, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. прив’язати медіаінтерфейс джерела GigabitEthernet0/0/0Налаштування вихідного інтерфейсу й пов’язаної з ним IP-адреси для медіафайлів, надісланих через зворотний цикл. Додаткову інформацію див. у розділі прив’язки. dtmf- relay rtp- ntВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див. в розділі Ретрансляція DTMF (голосовий зв’язок через IP). кодек g711alaw Змушує всі виклики ТМЗК використовувати G.711. Виберіть a-law або u-law, щоб відповідати методу компіляції, що використовується вашою службою ISDN. не вадВимикання виявлення голосової активності. Додаткову інформацію див. у розділі vad (вузол набору). |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: Це завершує конфігурацію вашого локального шлюзу. Збережіть конфігурацію та перезавантажте платформу, якщо це вперше налаштовано функції CUBE.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
Під час створення транка Webex Calling у Unified CM переконайтеся, що вхідний порт у параметрах профілю безпеки SIP-транка налаштовано на 5065. Це дозволяє вхідні повідомлення на порту 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. Також можна встановити DS для автоматичного збору діагностичних даних і перенесення зібраних даних до випадку Cisco TAC, щоб прискорити час роздільної здатності.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. Визначити логіку виявлення проблем можна за допомогою повідомлень syslog, подій SNMP і періодичного моніторингу певних виходів команд show.
Типи дій включають збір результатів команд показу:
-
Створення об'єднаного файлу журналу
-
Передавання файлу в надане користувачем мережеве розташування, як-от сервер HTTPS, SCP або FTP.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз працює IOS XE 17.6.1a або новіша
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте безпечний сервер електронної пошти, щоб використовувати його для надсилання проактивних сповіщень, якщо пристрій працює з Cisco IOS XE 17.6.1a або пізнішої версії.
configure terminal call-home mail-server: @ priority 1 secure tls end -
Налаштуйте змінну середовища ds_email з адресою електронної пошти адміністратора для сповіщення.
configure terminal call-home diagnostic-signature environment ds_emailend
Нижче наведено приклад конфігурації локального шлюзу, який працює в Cisco IOS XE 17.6.1a або новішої версії для надсилання проактивних сповіщень на адресу tacfaststart@gmail.com за допомогою Gmail як безпечного сервера SMTP:
Рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або новіші версії.
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com" Локальний шлюз, запущений на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати певні налаштування облікового запису Gmail і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Перейдіть до розділу й увімкніть параметр Менш безпечний доступ до програми .
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Використовуйте команду показати snmp , щоб увімкнути SNMP. Якщо його не ввімкнути, налаштуйте команду snmp-server manager .
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR серії або Cisco CSR 1000V серії
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
LocalGateway# copy ftp://username:password@/DS_64224.xml bootflash: У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
show call-home diagnostic-signature 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, щоб продовжити моніторинг високого рівня використання CPU в локальному шлюзі.
Моніторинг реєстрації SIP-транка
Ця DS перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Після виявлення події скасування реєстрації буде створено сповіщення електронною поштою та системного лотка й видалено після двох повторень скасування реєстрації. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@/DS_64117.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Використовуйте команду показати snmp , щоб перевірити, чи ввімкнено SNMP. Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Інсталяція діагностичних сигнатур для виправлення неполадок
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Діагностичні підписи (DS) позбавляють необхідності вручну перевіряти виникнення проблеми та значно полегшують виправлення переривних та тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, який рекомендується інженером TAC як частину підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix , яка є шляхом сервера файлів Cisco TAC (cxd.cisco.com), на який передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль – маркер передавання файлу, який можна отримати з Диспетчера запитів підтримки у наведеній нижче команді. Маркер передавання файлу можна створити в розділі Вкладення Диспетчера запитів підтримки, якщо необхідно.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://: @cxd.cisco.com" end Приклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Упевніться, що SNMP увімкнено за допомогою команди показати snmp . Якщо цей параметр не ввімкнено, налаштуйте команду диспетчера сервера snmp .
show snmp %SNMP agent not enabled config t snmp-server manager end -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@/DS_64224.xml bootflash: copy ftp://username:password@ /DS_65095.xml bootflash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Упевніться, що підпис успішно встановлено за допомогою команди показати виклик-домашній діагностичний підпис . Стовпець стану повинен мати значення "зареєстровано".
show call-home diagnostic-signature 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
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 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS із виводу команди показати виклик-домашній діагностичний підпис і запустіть таку команду:
call-home diagnostic-signature deinstall
Приклад:
call-home diagnostic-signature deinstall 64224
До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Для кращого керування шлюзами Cisco IOS XE рекомендуємо зареєструвати шлюзи й керувати ними через Control Hub. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub для перевірки конфігурації локального шлюзу та виявлення будь-яких проблем з конфігурацією. Зараз цю функцію підтримують лише транки на основі реєстрації.
Додаткову інформацію див. в наступному.
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою взаємного SIP-транка TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються на Webex Calling, а всі виклики з Webex Calling маршрутизуються в ТМЗК. Наведене нижче зображення висвітлює це рішення та конфігурацію маршрутизації викликів на високому рівні, яку буде слідувати.
У цьому проекті використовуються наступні основні конфігурації:
-
клієнти голосового класу: Використовується для створення специфічних конфігурацій транка.
-
URI класу голосового зв’язку: Використовується для класифікації повідомлень SIP для вибору вхідного абонента набору.
-
вузол вхідного набору: Забезпечує обробку вхідних повідомлень SIP і визначає вихідний маршрут за допомогою групи однорангового набору.
-
група однорангового набору: Визначає однорангові вузли для вихідного набору, що використовуються для маршрутизації подальшого виклику.
-
вузол для вихідного набору: Забезпечує обробку вихідних повідомлень SIP і маршрутизує їх до потрібної цілі.
Під час підключення локального рішення Cisco Unified Communications Manager до Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову лінію для побудови рішення, ілюстрованого на наведеній нижче діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена організаторів, IP-адреси та інтерфейси, наведені на наведеному нижче зображенні. Надано параметри для загальнодоступних або приватних (за NAT) адрес. Записи DNS SRV необов’язкові, за винятком випадків, коли балансування навантаження між кількома екземплярами CUBE.
Використовуйте настанови з конфігурації в решті цього документа, щоб завершити конфігурацію локального шлюзу так:
Базова конфігурація
Першим кроком під час підготовки маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка забезпечить безпеку вашої платформи та встановлення підключення.
-
Усі розгортання локального шлюзу на основі сертифікатів потребують Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовано використовувати Cisco IOS XE 17.12.2 або пізнішої версії. Рекомендовані версії див. на сторінці Cisco Software Research . Знайдіть платформу й виберіть один із запропонованих випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані як з ліцензіями Unified Communications, так і з ліцензіями технології безпеки.
-
Маршрутизатори серії Catalyst Edge 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP потребують мінімального ліцензування DNA Essentials.
-
Для вимог до високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і додаткове право на пропускну здатність.
Додаткову інформацію див. в розділі Коди авторизації .
-
-
Створіть базову конфігурацію для платформи, яка відповідає вашим політикам бізнесу. Зокрема, налаштуйте та перевірте наведене нижче.
-
NTP
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа, що підключається до Webex Calling, повинна використовувати IPv4-адресу. Адреси локального шлюзу з повними доменними іменами (FQDN) або записом служби (SRV), налаштовані в Control Hub, мають зіставити з загальнодоступною IPv4-адресою в інтернеті.
-
Усі порти SIP і медіафайлів в інтерфейсі локального шлюзу, що facing Webex, повинні бути доступними з інтернету безпосередньо або через статичний NAT. Упевніться, що брандмауер було оновлено належним чином.
-
Виконайте наведені нижче докладні кроки конфігурації, щоб установити підписаний сертифікат на локальний шлюз:
-
Загальнодоступний центр сертифікації (CA), докладний у розділі Які кореневі органи сертифікації підтримуються для викликів на аудіо- та відеоплатформи Cisco Webex? , повинен підписати сертифікат пристрою.
-
Спільне ім’я суб’єкта сертифіката (CN) або одне з альтернативних імен суб’єкта (SAN) має збігатися з повним доменним ім’ям, налаштованим у Control Hub. Наприклад:
-
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді CN або SAN у сертифікаті маршрутизатора має містити cube1.lgw.com.
-
Якщо налаштований транк у Control Hub вашої організації має lgws.lgw.com як адресу SRV локальних шлюзів, доступну з транка, тоді CN або SAN у сертифікаті маршрутизатора має містити lgws.lgw.com. Записи, до яких вирішується адреса SRV (CNAME, A Record або IP-адреса), не є обов'язковими в SAN.
-
Незалежно від того, чи використовується ви FQDN або SRV для транка, в адресі контакту для всіх нових діалогових вікон SIP з локального шлюзу необхідно використовувати ім’я, налаштоване в Control Hub.
-
-
Переконайтеся, що сертифікати підписані для використання клієнта й сервера.
-
-
Передайте пакет кореневого CA Cisco до локального шлюзу. Ця пакет містить кореневий сертифікат CA, який використовується для перевірки платформи Webex.
Конфігурація
| 1 |
Переконайтеся, що ви призначаєте допустимі IP-адреси, які можна маршрутизувати, будь-яким інтерфейсам рівня 3, наприклад:
|
| 2 |
Захистіть облікові дані STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування так: |
| 3 |
Створіть точку довіри шифрування за допомогою сертифіката для домену, підписаного підтримуваним центром сертифікації (CA). |
| 4 |
Надайте сертифікат CA проміжного підписання, який використовується для автентифікації вашого сертифіката організатора. Введіть таку команду виконання або конфігурації:
|
| 5 |
Імпортуйте підписаний сертифікат організатора за допомогою наведених далі команд виконання або конфігурації:
|
| 6 |
Увімкніть ексклюзивність TLS1.2 і задайте точку довіри за замовчуванням, яка буде використовуватися для голосових застосунків за допомогою таких команд конфігурації:
|
| 7 |
Установіть кореневий пакет CA Cisco, який містить сертифікат CA DigiCert, який використовується Webex Calling. Використовуйте команду crypto pki trustpool імпорту чистої url-адреси url , щоб завантажити кореневий пакет CA з вказаної URL-адреси та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, перед імпортом пакету CA додайте таку конфігурацію: ip-адреса проксі-сервера yourproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див. в розділі Налаштування транків, груп маршрутів і абонентські групи для Webex Calling. Зверніть увагу на інформацію про транк, яка надається після створення транка. Ці відомості, як підкреслено в наведеній нижче ілюстрації, використовуватимуться в кроках конфігурації цього посібника. |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. sip-підключення дозволу на sipУвімкніть функцію оператора користувача CUBE базового SIP назад до назад. Додаткову інформацію див. в розділі Дозволити з’єднання. За замовчуванням протокол T.38 увімкнено. Додаткову інформацію див. в факсимільному протоколі t38 (голосова служба). Вмикає STUN (Обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди stun потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див. в розділі ідентифікатор оператора stun flowdata та stun flowdata shared-secret. асиметричне корисне навантаження повнеНалаштування підтримки асиметричного корисного навантаження SIP для навантаження як DTMF, так і для динамічного кодека. Докладніше про цю команду див. в розділі Асиметричне корисне навантаження. примусова рання пропозиціяЗмушує локальний шлюз надсилати інформацію SDP в початковому повідомленні ЗАПРОШЕННЯ, а не очікує підтвердження від сусіднього вузла. Додаткову інформацію про цю команду див. в розділі рання пропозиція. вхідні профілі sipДозволяє CUBE використовувати профілі SIP для зміни повідомлень під час їх отримання. Профілі застосовуються через однорангових абонентів або клієнтів. |
| 3 |
Налаштуйте кодек класу голосового зв’язку 100 , що дозволить кодекам G.711 тільки для всіх транків. Цей простий підхід підходить для більшості розгортань. За потреби до списку можуть бути додані додаткові типи кодеків, які підтримуються як вихідними, так і системами завершення. Більш складні рішення, що включають транскодування за допомогою модулів DSP, підтримуються, але не включені в цей посібник. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів SIP-транка. Додаткову інформацію див. в розділі кодек голосового класу. |
| 4 |
Налаштуйте використання голосового класу stun-використання 100 , щоб увімкнути ICE на транку Webex Calling. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: використання stun ice liteВикористовується для ввімкнення ICE-Lite для всіх однорангових абонентів Webex Calling, щоб дозволити оптимізацію мультимедіа, коли це можливо. Додаткову інформацію див. в розділі використання звукового класу та використання звуку lite ice lite. Команда використання брандмауера й обходу потокових даних потрібна лише під час розгортання локального шлюзу за NAT. Оптимізація мультимедіа проводиться там, де це можливо. Якщо для виклику потрібні хмарні медіаслужби, як-от запис, медіафайли неможливо оптимізувати. |
| 5 |
Налаштуйте політику шифрування медіафайлів для трафіку Webex. (Цей крок не застосовується до Webex for Government) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_80 як єдиний пропонує набір шифрів CUBE SRTP у SDP в повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_80. Додаткову інформацію див. в розділі голосового класу srtp-crypto. |
| 6 |
Налаштуйте шифри GCM, сумісні з FIPS (Цей крок застосовується лише для Webex for Government). Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає GCM як набір шифрів, який пропонує CUBE. Необхідно налаштувати шифри GCM для локального шлюзу для Webex for Government. |
| 7 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену призначення або SRV: Ось пояснення полів для конфігурації: URI класу голосового зв’язку 100 sipВизначає шаблон, який відповідає вхідному запрошенню SIP до однорангового абонента вхідного транка. Під час введення цього шаблону використовуйте повне доменне ім’я транка або SRV, налаштоване в Control Hub для транка. |
| 8 |
Налаштуйте профілі керування повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль так, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу: Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. |
| 9 |
Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP так. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, налаштованим для локального шлюзу, "10.80.13.12" є IP-адресою інтерфейсу, що відповідає Webex Calling, а "192.65.79.20" є публічною IP-адресою NAT. Профілі SIP для вихідних повідомлень у Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20"Щоб дозволити Webex автентифікувати повідомлення з вашого локального шлюзу, заголовок ""Контакт"" у повідомленнях запиту SIP та відповідей має містити значення, надане для транка в Control Hub." Це буде або повне доменне ім’я одного хоста, або ім’я SRV, яке використовується для кластера пристроїв. правила 30-81Перетворіть посилання на приватні адреси у зовнішню публічну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingОсь пояснення полів для конфігурації: правила 10-80Перетворіть посилання на публічні адреси в налаштовану приватну адресу, що дозволить CUBE обробляти повідомлення від Webex. Додаткову інформацію див. в sip-профілях голосового класу. Постачальник ТМЗК у США або Канаді може запропонувати перевірку ідентифікатора абонента, що телефонує, для спаму та шахрайських викликів із додатковою конфігурацією, зазначеною в повідомленні про спам чи шахрайський виклик у статті Webex Calling . |
| 10 |
Налаштуйте параметри SIP для збереження з профілем зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль, який зберігається, і переходить у режим конфігурації класу голосового зв’язку. Можна налаштувати час (у секундах), коли сигнал SIP Out of Dialog Options надсилається цільовому набору, коли серцебиття з’єднання з кінцевим пристроєм перебуває в стані "ВГОРУ" або "Вниз". Цей профіль увімкнено з однорангового абонента, налаштованого на Webex. Щоб переконатися, що заголовки контактів містять повне доменне ім’я SBC, використовується SIP-профіль 115. Правила 30, 40 і 50 потрібні, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є повним доменним ім’ям, вибраним для локального шлюзу, і якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC у напрямку Webex Calling, а "192.65.79.20" – загальнодоступною IP-адресою NAT. |
| 11 |
Налаштуйте транк Webex Calling: |
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM на порту 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 маршрутизуються до Webex Calling. Щоб включити цей сценарій виклику, можна додати такі інкрементні конфігурації.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте наступні записи DNS, щоб указати маршрутизацію SRV до вузлів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. У разі цієї конфігурації не потрібно налаштовувати записи у вашій системі DNS. Якщо ви віддаєте перевагу використанню DNS, тоді ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює запис ресурсу DNS SRV. Створіть запис для кожного хоста й транка UCM: ip-хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я запису ресурсу SRV 2: Пріоритет запису ресурсу SRV 1: Вага запису ресурсу SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому записі ресурсу ucmsub5.mydomain.com: Цільовий організатор запису ресурсу Щоб вирішити цільові імена хостів для запису ресурсів, створіть локальні записи DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 IP-хост: Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису. 192.168.80.65: IP-адреса організатора. Створіть записи ресурсів SRV і записи, щоб відображати середовище UCM і бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі вузли для набору: |
| 4 |
Додати маршрутизацію виклику за допомогою таких конфігурацій: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події SNMP і за допомогою періодичного моніторингу конкретних виходів команд show для визначення логіки виявлення проблеми. До типів дій відносяться:
-
Збирання показаних командних виходів
-
Створення об'єднаного файлу журналу
-
Завантаження файлу на вказане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку відповідних підписів для моніторингу та виправлення різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз, що працює під керуванням IOS XE 17.6.1 або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивного сповіщення, якщо пристрій працює під керуванням IOS XE 17.6.1 або новішої версії.
configure terminal call-home mail-server: @ priority 1 secure tls end -
Налаштуйте змінну ds_email середовища з адресою електронної пошти адміністратора, про яку ви сповіщаєте.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_emailend
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера snmp-сервера .
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
copy ftp://username:password@/DS_64224.xml bootflash: Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
copy ftp://username:password@/DS_64224.xml bootflash: У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, будь ласка, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг ненормальних роз 'єднань дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин, щоб виявляти відключення викликів від’єднання з помилками SIP 403, 488 та 503. Якщо приросту кількості помилок від останнього опитування перевищує або дорівнює 5, буде створено системний журнал і сповіщення електронною поштою. Щоб установити підпис, скористайтеся наведеними нижче кроками.
-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
copy ftp://username:password@/DS_65221.xml bootflash: -
Установіть файл XML DS на локальному шлюзі.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Використовуйте команду показати виклик-домашній діагностичний підпис , щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Діагностичні підписи (DS) також можна використовувати для швидкого вирішення проблем. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
За допомогою засобу пошуку діагностичних підписів можна знайти відповідні підписи та інсталювати їх для самостійного вирішення певної проблеми, або інсталювати підпис, рекомендований інженером TAC як частину підтримки підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Налаштуйте іншу змінну середовища 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://: @cxd.cisco.com" end Приклад:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте команду диспетчера сервера snmp .
show snmp %SNMP agent not enabled config t snmp-server manager end -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, серії ISR 4400 або програмне забезпечення Catalyst 8000V Edge
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
copy ftp://username:password@/DS_64224.xml bootflash: copy ftp://username:password@ /DS_65095.xml bootflash: -
Установіть файл DS 64224 для моніторингу CPU, а потім файл DS 65095 XML у локальний шлюз.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
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
DSLGW_IEC_C_all_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець "Стан" команди показує діагностичний підпис виклику додому змінюється на "запущений", поки Локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи діагностичний підпис виявляє подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено/Макс/Видалення |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Повідомлення електронної пошти зі сповіщенням, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення вихідних команд, які мають відношення до усунення несправностей із цією проблемою.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблем. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS з виводу показу діагностичного підпису виклику додому та запустіть таку команду:
call-home diagnostic-signature deinstall Приклад:
call-home diagnostic-signature deinstall 64224
До засобу пошуку діагностичних сигнатур періодично додаються нові підписи на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Впровадження CUBE високого рівня доступності як локального шлюзу
Основи
Передумови
Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.
-
Резервування типу Box-to-box другого рівня з використанням корпоративного розгортання CUBE для утримання викликів зі збереженням стану
У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.
Компоненти апаратного й програмного забезпечення
Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.
Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).
Довідковий матеріал
Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.
-
Серія ISR 4K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Бажана архітектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.
У цій статті розглянуто розгортання локального шлюзу (представлено нижче). Транк локального шлюзу (PSTN на базі локальних ресурсів) у Webex Calling дозволяє виконати підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до розгортання внутрішньої телефонної мережі з підтримкою IP на базі локальних ресурсів, як-от Cisco Unified CM. Увесь зв’язок із хмарою в обох напрямках захищено за допомогою передавання даних TLS для SIP й SRTP для мультимедіа.
На малюнку нижче зображено розгортання Webex Calling без будь-якої наявної внутрішньої телефонної мережі з підтримкою IP. Ця схема застосовується до розгортання з одним або кількома об’єктами. Конфігурація, яку описано в цій статті, базується на цьому розгортанні.
Резервування типу Box-to-Box другого рівня
У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.
Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.
У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану
Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.
Компонент інфраструктури групи резервування
Компонент інфраструктури групи резервування (RG) забезпечує підтримку інфраструктури зв’язку типу Box-to-Box між двома CUBE й погоджує остаточний стабільний стан резервування. Цей компонент також надає наведені нижче дані.
-
Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями щодо перевірки активності (keepalive) і привітальними повідомленнями (hello) між двома CUBE (через інтерфейс керування): GigabitEthernet3 на малюнку вище.
-
Транспортний механізм під час контролю стану передавання сигналів і мультимедіа від активного до резервного маршрутизатора для кожного виклику (через інтерфейс даних): GigabitEthernet3 на малюнку вище.
-
Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.
Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.
Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа
B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (SIP) є обов’язковими для B2B HA голосового зв’язку. Зовнішні пристрої, такі як Unified CM, SBC доступу Webex Calling, постачальник послуг або проксі, використовують VIP як IP-адресу призначення для викликів, що проходять через маршрутизатори CUBE HA. Отже, з позиції Webex Calling пари CUBE HA діють як єдиний локальний шлюз.
Інформація щодо передавання сигналів викликів і сеансу RTP встановлених викликів перевіряється під час передавання від активного маршрутизатора до резервного. Коли активний маршрутизатор аварійно припиняє роботу, резервний маршрутизатор переходить в активний режим і продовжує пересилати потік RTP, який раніше був спрямований першим маршрутизатором.
У разі аварійного перемикання виклики в перехідному стані не буде збережено після перемикання. Наприклад, виклики, підключення яких іще не було повністю встановлено, або такі, що знаходяться в процесі зміни за допомогою функції переведення або утримання виклику. Після перемикання встановлені виклики може бути відключено.
Існують наведені нижче вимоги до використання CUBE HA як локального шлюзу з метою збереження стану виклику після аварійного перемикання.
-
У CUBE HA не можуть спільно розміщуватися TDM або аналогові інтерфейси
-
Gig1 і Gig2 є інтерфейсами трафіку (SIP/RTP), а Gig3 — інтерфейсом керування групою резервування (RG)/передавання даних.
-
В одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)
-
Канал порту підтримується як для інтерфейсу керування RG / передавання даних, так і для інтерфейсу трафіку
-
Усі дані сигналів/мультимедіа надходять з віртуальної IP-адреси й на неї
-
Кожного разу, коли виконується перезавантаження платформи у взаємодії з CUBE-HA, вона завжди завантажується як резервна
-
Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі
-
Ідентифікатор інтерфейсу резервування, rii, має бути унікальним для комбінації «Пара/інтерфейс» на одному рівні 2
-
Конфігурація обох CUBE має бути ідентичною, включно з фізичною конфігурацією, і повинна працювати на платформі одного типу й версії IOS-XE
-
Інтерфейси замикання на себе не можна використовувати як прив’язки, оскільки вони завжди знаходяться в активному стані
-
Використання кількох інтерфейсів (Gig1, Gig2) трафіку (SIP/RTP) вимагає налаштування відстеження інтерфейсу
-
CUBE-HA не підтримується в разі використання перехресного кабельного підключення для зв’язування інтерфейсу керування RG/передавання даних (Gig3)
-
Обидві платформи повинні бути ідентичними, і їх має бути підключено через фізичний перемикач на всіх аналогічних інтерфейсах для роботи CUBE HA, тобто GE0/0/0 CUBE-1 і CUBE-2 повинні перериватися на одному комутаторі тощо.
-
Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін