Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
След като конфигурирате Webex Calling за вашата организация, можете да конфигурирате багажник, за да свържете вашия локален портал към Webex Calling. SIP TLS транспортът осигурява багажника между местния портал и облака Webex. Медиите между местния портал и Webex Calling използват SRTP.
Общ преглед
В момента Webex Calling поддържа две версии на локален шлюз:
-
Локален шлюз
-
Локален шлюз за Webex за правителството
-
Преди да започнете, разберете изискванията на базираната в помещенията обществена комутирана телефонна мрежа (PSTN) и локалния шлюз (LGW) за обажданията чрез Webex Calling. Вижте Cisco Предпочитана архитектура за Webex Призоваване за повече информация.
-
Тази статия предполага, че е налице специална платформа на Local Gateway без съществуваща гласова конфигурация. Ако модифицирате съществуващ шлюз за обществена телефонна централа или внедряване на CUBE Enterprise, за да се използва като функция Local Gateway за Webex Calling, тогава обърнете внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци и функционалност на повикванията поради промените, които правите.
За информация относно поддържаните SBC на трети страни вижте съответната референтна документация на продукта.
Има две опции за конфигуриране на локалния портал за вашия багажник за повикване на Webex:
-
Багажник, базиран на регистрация
-
Багажник, базиран на сертификат
Използвайте потока на задачите или под Локален шлюз, базиран на регистрация или Базиран на сертификат локален шлюз за да конфигурирате локален шлюз за вашата линия за Webex Calling .
Виж Започнете с Local Gateway за повече информация относно различните типове багажници. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Ние използваме Session Initiation Protocol (SIP) и Защита на транспортния слой (TLS), за да защитим магистралата и защитен протокол в реално време (SRTP), за да защитим носителя между локалния шлюз и Webex Calling.
-
Изберете CUBE като ваш локален шлюз. Понастоящем Webex for Government не поддържа никакви гранични контролери на сесии (SBC) на трети страни. За да прегледате последния списък, вж Започнете с Local Gateway .
- Инсталирайте Cisco IOS XE Dublin 17.12.1a или по-нови версии за всички Webex за правителствени локални шлюзове.
-
За да прегледате списъка с основни сертифициращи органи (CA), които Webex поддържа за правителство, вж Коренни сертифициращи органи за Webex за правителство .
-
За подробности относно диапазоните на външни портове за локален шлюз в Webex за правителство, вж Мрежови изисквания за Webex за правителство (FedRAMP) .
Локален шлюз за Webex за правителството не поддържа следното:
-
STUN/ICE-Lite за оптимизиране на медийния път
-
факс (T.38)
За да конфигурирате локален шлюз за вашата линия за Webex Calling на Webex в Webex за правителство, използвайте следната опция:
-
Багажник, базиран на сертификат
Използвайте потока от задачи под Базиран на сертификат локален шлюз за да конфигурирате локалния шлюз за вашата линия за Webex Calling . За повече подробности как да конфигурирате базиран на сертификат локален шлюз, вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Задължително е да конфигурирате FIPS-съвместими GCM шифри, за да поддържате локален шлюз за Webex за правителство. Ако не, настройката на повикването е неуспешна. За подробности за конфигурацията вж Конфигуриране на базирана на сертификат магистрална връзка за Webex Calling .
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, като се използва регистриране на външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Изображението по-долу подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде следвана.
В този дизайн се използват следните основни конфигурации:
-
наематели на гласов клас: Използва се за създаване на специфични за багажника конфигурации.
-
гласов клас uri: Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
-
входяща точка за набиране: Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
-
група за набиране: Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
-
изходящ диск за набиране: Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Докато IP и SIP се превърнаха в протоколи по подразбиране за PSTN магистрали, TDM (Time Division Multiplexing) ISDN вериги все още се използват широко и се поддържат с връзките на Webex Calling . За да се активира медийна оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, понастоящем е необходимо да се използва двуетапен процес за маршрутизиране на повикване . Този подход модифицира конфигурацията за маршрутизиране на повикване , показана по-горе, като въвежда набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали, както е показано на изображението по-долу.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
-
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
-
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
-
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
или:
-
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
-
Всички базирани на регистрация внедрявания на локален шлюз изискват Cisco IOS XE 17.6.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
-
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
-
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Advantage. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
-
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
-
NTP
-
АКЛ
-
Удостоверяване на потребителя и дистанционен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес.
-
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
|
| 2 |
Защитете идентификационните данни за регистрация и STUN на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва:
|
| 3 |
Създайте заместваща PKI точка на доверие. Изисква тази точка на доверие за конфигуриране на TLS по-късно. За базирани на регистрация магистрали, тази точка на доверие не изисква сертификат - както би било необходимо за базирана на сертификат магистрала. |
| 4 |
Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация. Транспортните параметри също трябва да бъдат актуализирани, за да се гарантира надеждна защитена връзка за регистрация: Командата на сървъра cn-san-validate гарантира, че локалният шлюз позволява връзка, ако име на домакина, конфигурирано в клиент 200, е включено в полетата CN или SAN на сертификата, получен от изходящия прокси сървър.
|
| 5 |
Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA: ip http клиент прокси-сървър yourproxy.com прокси порт 80 |
| 1 |
Създайте базирана на регистрация PSTN магистрала за съществуващо местоположение в Control Hub. Отбележете информацията за магистралата, която се предоставя след създаването на магистрала. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling .  |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. медийна статистикаПозволява медиен мониторинг на местния портал. медийни масови статистикиПозволява на контролната равнина да анкетира равнината на данните за статистика на насипните повиквания. За повече информация относно тези команди вж Медия . разрешаване на връзки глътка до глъткаАктивирайте CUBE основната SIP функция на потребителски агент отзад до гръб. За повече информация вж Разрешаване на връзки . По подразбиране транспортирането на факс T.38 е разрешено. За повече информация вж факс протокол t38 (гласова услуга) . Разрешава STUN (обхождане на сесия на UDP през NAT) глобално.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . |
| 3 |
Конфигуриране кодек за гласов клас 100 филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вж кодек за гласов клас . Кодек Opus се поддържа само за PSTN канали, базирани на SIP. Ако PSTN магистралата използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитание за кодек 1 опус от кодек за гласов клас 100 конфигурация. |
| 4 |
Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . Ето обяснение на полетата за конфигурацията: зашеметяващо използване ice liteИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite . Имате нужда от зашеметяващо използване на ICE-lite за потоци от разговори, използващи оптимизация на медийния път. За да осигурите медийна оптимизация за шлюз SIP към TDM, конфигурирайте loopback dial-peer с активиран ICE-Lite на IP- IP крака. За допълнителни технически подробности се свържете с екипите на акаунта или TAC |
| 5 |
Конфигурирайте политиката за криптиране на медиите за трафика на Webex . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1_ 80 За повече информация вж гласов клас srtp-crypto . |
| 6 |
Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на параметъра на неговата дестинационна магистрала: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте dtg=, последвано от стойността на Trunk OTG/DTG, предоставена в Control Hub при създаването на магистрала. За повече информация вж глас клас uri . |
| 7 |
Конфигуриране глътка профил 100 , който ще се използва за модифициране на SIP съобщения, преди да бъдат изпратени до Webex Calling.
Ето обяснение на полетата за конфигурацията:
|
| 8 |
Конфигуриране на магистрала за Webex Calling : |
След като дефинирате наемател 100 и конфигуриране на SIP VoIP dial-peer, шлюзът инициира TLS връзка към Webex Calling. В този момент SBC за достъп представя своя сертификат на локалния шлюз. Локалният шлюз потвърждава сертификата за достъп на Webex Calling SBC, използвайки коренния пакет на CA, който беше актуализиран по-рано. Ако сертификатът бъде разпознат, се установява постоянна TLS сесия между локалния шлюз и SBC за достъп за Webex Calling . След това локалният шлюз може да използва тази защитена връзка , за да се регистрира в SBC за достъп на Webex . Когато регистрацията е оспорена за удостоверяване:
-
В потребителско име, парола, и царство параметри от пълномощията конфигурацията се използва в отговора.
-
Правилата за модификация в sip профил 100 се използват за преобразуване на SIPS URL обратно в SIP.
Регистрацията е успешна, когато се получи 200 ОК от SBC за достъп.
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN магистрала, преминете към следващия раздел Конфигурирайте локален шлюз с TDM PSTN магистрала .
За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI .
| 1 |
Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 |
Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 |
Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
След като сте изградили транк към Webex Calling, използвайте следната конфигурация, за да създадете TDM trunk за вашата PSTN услуга с маршрутизиране на повикване с обратна линия, за да позволите оптимизиране на медиите на етап на повикването на Webex .
| 1 |
Конфигурацията за обратна връзка за набиране използва групи за набиране и маркери за маршрутизиране на повикване, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да създава цикли за маршрутизиране на повикване . Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрутизиране на повикване : Ето обяснение на полетата за конфигурацията: гласов превод-правилоИзползва регулярни изрази, дефинирани в правила, за добавяне или премахване на маркери за маршрутизиране на повикване . Превишените десетични цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация, етикетът, добавен от профил за превод 100, се използва за насочване на повиквания от Webex Calling към PSTN чрез loopback dial-peers. По същия начин, етикетът, добавен от профил за превод 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профили за превод 11 и 12 премахват тези тагове, преди да доставят повиквания съответно към магистралите на Webex и PSTN. Този пример предполага, че обажданите номера от Webex Calling са представени във формат + E.164 . Правило 100 премахва водещия +, за да поддържа валиден извикан номер. След това правило 12 добавя национална или международна цифра(и) за маршрутизиране при премахване на етикета. Използвайте цифри, които отговарят на вашия местен ISDN национален план за набиране. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да добавите и премахнете съответно маркера за маршрутизиране. За повече информация вж гласов превод-профил и гласов превод-правило . |
| 2 |
Конфигурирайте TDM портовете за гласов интерфейс, както се изисква от типа на магистрала и използвания протокол. За повече информация вж Конфигуриране на ISDN PRI . Например, основната конфигурация на ISDN интерфейс с първична скорост, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следната TDM PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . превод-профил входящ 200Присвоява профила за превод, който ще добави маркер за маршрутизиране на повикване към входящия извикан номер. директно набиране навътреНасочва повикването, без да предоставя вторичен тон за набиране. За повече информация вж директно набиране навътре . порт 0/2/0:15Физическият гласов порт, свързан с тази точка за набиране. |
| 4 |
За да активирате медийната оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, можете да промените маршрутизиране на повикване чрез въвеждане на набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали. Конфигурирайте следните точки за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат пренасочени първоначално към dial-peer 10, а оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахване на маркера за маршрутизиране, повикванията ще бъдат пренасочени към външна линия с помощта на групи за набиране. Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . превод-профил входящ 11Прилага профила за превод, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикване , преди да премине към външна линия. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва, че тази точка за набиране обработва етапите на SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията 192.168.80.14Указва адреса на интерфейса на локалния рутер като цел на повикване за връщане. За повече информация вж цел на сесията (voip dial peer) . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за съобщения, изпратени чрез обратна верига. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени чрез обратна верига. За повече информация вж обвързвам . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . кодек g711alaw Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответствате на метода за компандиране, използван от вашата ISDN услуга. без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 5 |
Добавете следната конфигурация за маршрутизиране на повикване : Това приключва конфигурацията на вашия локален шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE се конфигурират.
|
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
Когато създавате линията за Webex Calling в Unified CM, уверете се, че сте конфигурирали входящия порт в настройките на профил за защита на SIP линиите на 5065. Това позволява входящи съобщения на порт 5065 и попълване на VIA заглавката с тази стойност при изпращане на съобщения до локалния шлюз.
| 1 |
Конфигуриране на следните URI гласови класове: |
| 2 |
Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове: IOS XE използва тези записи за локално определяне на целеви UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тогава тези локални конфигурации не са необходими. Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и магистрала: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060: Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com: Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com: Името на име на домакина за запис A. 192.168.80.65: IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. |
| 3 |
Конфигурирайте следните точки за набиране: |
| 4 |
Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събраните данни в кутията на Cisco TAC , за да ускорите времето за разрешаване.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития, задействащи проблем, и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми, като използвате съобщения в системния журнал, SNMP събития и чрез периодично наблюдение на специфични изходни команди show.
Типовете действия включват събиране на командни изходи:
-
Генериране на консолидиран лог файл
-
Качване на файла на предоставено от потребителя мрежово местоположение, като HTTPS, SCP, FTP сървър.
Инженерите на TAC изписват DS файловете и дигитално ги подписват за защита на интегритета. Всеки DS файл има уникален цифров идентификатор, зададен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
-
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които променяте инсталацията за неуспех поради грешката при проверка на интегритета.
-
Прост протокол за прехвърляне на поща (SMTP) сървър, от който се нуждаете, за да може местният портал да изпраща известия по имейл.
-
Уверете се, че местният портал работи с IOS XE 17.6.1 или по-висока, ако искате да използвате защитения SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1a или по-нова версия
-
Диагностичните подписи са разрешени по подразбиране.
-
Конфигурирайте защитения имейл сървър, който да се използва за изпращане на проактивни известия, ако устройството работи с Cisco IOS XE 17.6.1a или по-нова версия.
конфигуриране на терминално повикване-домашен пощенски сървър : @ приоритет 1 защитен tls край -
Конфигурирайте променливата на средатаds_email с имейл адрес на администратора, за да Ви уведоми.
конфигуриране на среда за диагностичен подпис за повикване до домаds_email край
По-долу е показана примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1a или по-нова версия за изпращане на проактивни известия до tacfaststart@gmail.com използване на Gmail като защитен SMTP сървър:
Препоръчваме ви да използвате Cisco IOS XE Bengaluru 17.6.x или по-нови версии.
call-home mail-server tacfaststart:password@smtp.gmail.com приоритет 1 защитена среда за диагностичен подпис на tlsds_email "tacfaststart@gmail.com"Локален портал, работещ на Cisco IOS XE Software, не е типичен уеб-базиран клиент на Gmail, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на профила в Gmail и да предоставим специално разрешение имейлът от устройството да бъде обработен правилно:
-
Отидете на и включете По-малко защитен достъп до приложения настройка.
-
Отговорете "Да, това бях аз", когато получавате имейл от Gmail, в който се казва: "Google попречи на някого да влезе в профила ви с помощта на приложение извън Google".
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява използването на CPU за пет секунди, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които са инсталирани в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Използвайте покажи snmp команда за активиране на SNMP. Ако не активирате, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Серия Cisco CSR 1000V
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Копирайте DS XML файла в светкавицата на локалния шлюз.
LocalGateway# копие ftp://username:password@ /DS_ 64224.xml начална флаш памет:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копирайте ftp://user:pwd@192.0.2.12/DS_ 64224.xml начална флаш памет: Достъп до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [ОК - 3571/4096 байта] 3571 байта, копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.comИзтегляне на DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително и себе си. Ако е необходимо, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на CPU на локалния шлюз.
Мониторинг SIP багажник регистрация
Този DS проверява за нерегистрация на локален Gateway SIP багажник с облак Webex Calling на всеки 60 секунди. След като се открие събитието за отписване, то генерира известие по имейл и системен журнал и се деинсталира след две поява на дерегистрация. Използвайте стъпките по-долу, за да инсталирате подписа:
-
Изтеглете DS 64117, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
СИП-СИП
Тип на проблема
SIP Trunk Отписване на регистрацията с известие по имейл.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64117.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64117.xml Заредете файл DS_ 64117.xml успех LocalGateway# -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Мониторинг на абнормни прекъсвания на повикването
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Използвайте покажи snmp команда, за да проверите дали SNMP е активиран. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 65221.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 65221.xml Заредете файл DS_ 65221.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
Инсталирайте диагностични подписи, за да отстраните проблем
Използвайте диагностични подписи (DS), за да разрешите проблемите бързо. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на неизправности в даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая Cisco TAC. Диагностичните подписи (DS) премахват необходимостта от ръчна проверка за възникване на проблема и улесняват много по-лесно отстраняването на неизправности на периодични и преходни проблеми.
Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно разрешаване на даден проблем, или можете да инсталирате подписа, препоръчан от инженера на TAC като част от ангажимента за поддръжка.
Ето един пример за това как да намерите и инсталирате DS за откриване на събитието "%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0" syslog и автоматизира събирането на диагностични данни, като използва следните стъпки:
-
Конфигурирайте допълнителна променлива на средата на DSds_fsurl_prefix което е пътят на файлов сървър на Cisco TAC (cxd.cisco.com), към който се качват събраните диагностични данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка в следната команда. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, ако е необходимо.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_fsurl_prefix "scp:// : @cxd.cisco.com" крайПример:
среда за диагностика и подпис за обаждане вкъщиds_fsurl_prefix "околна средаds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Уверете се, че SNMP е активиран с помощта на покажи snmp команда. Ако не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager край -
Уверете се, че инсталирате High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет: копирайте ftp://потребителско име:парола@ /DS_ 65095.xml начална флаш памет: -
Инсталирайте High CPU мониторинг DS 64224 и след това DS 65095 XML файл в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех зареждане на DS за диагностика на повикване до дома_ 65095.xml Заредете файл DS_ 65095.xml успех -
Проверете дали подписът е инсталиран успешно с помощта на покажете диагностичен подпис за обаждане вкъщи команда. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comИзтеглени DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-08
65095
00:12:53
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08
Проверка на изпълнението на диагностичните подписи
В следващата команда колоната „Състояние“ на покажете диагностичен подпис за обаждане вкъщи командата се променя на „работеща“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът от статистиката за диагностичния подпис на повикването у дома е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Изтеглени DSes:
|
Идентификационен номер на DS |
Име на DS |
Преразглеждане |
Статус |
Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
Показване на статистика за диагностика-подпис на повикване-дома
|
Идентификационен номер на DS |
Име на DS |
Задейства се /Макс/Деинсталиране |
Средно време за изпълнение (секунди) |
Максимално време за изпълнение (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
1 /20/г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на даден проблем.
Деинсталиране на диагностични подписи
Използвайте диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинират като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ИД от изхода на покажете диагностичен подпис за обаждане вкъщи команда и изпълнете следната команда:
деинсталиране на диагностика за домашен подпис Пример:
деинсталиране на диагностичен подпис за обаждане до дома 64224 Периодично се добавят нови подписи към инструмента за справка за диагностични подписи, въз основа на проблеми, които обикновено се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
За по-добро управление на Cisco IOS XE Gateways, препоръчваме ви да регистрирате и управлявате шлюзовете чрез Control Hub. Това е опция по избор. Когато се регистрирате, можете да използвате опцията за валидиране на конфигурацията в Control Hub, за да потвърдите конфигурацията на вашия локален шлюз и да идентифицирате всички проблеми с конфигурацията. Понастоящем тази функционалност поддържат само базирани на регистрация канали.
За повече информация вижте следното:
Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling, използвайки базиран на сертификат взаимна TLS (mTLS) външна линия SIP. Първата част на този документ илюстрира как да конфигурирате обикновен шлюз за обществена телефонна централа. В този случай всички повиквания от PSTN се пренасочват към Webex Calling и всички повиквания от Webex Calling се насочват към PSTN. Следното изображение подчертава това решение и конфигурацията за маршрутизиране на повикване от високо ниво, която ще бъде последвана.
В този дизайн се използват следните основни конфигурации:
-
наематели на гласов клас : Използва се за създаване на специфични за транк конфигурации.
-
глас клас uri : Използва се за класифициране на SIP съобщения за избор на входяща точка за набиране.
-
входяща точка за набиране : Осигурява обработка на входящи SIP съобщения и определя изходящия маршрут с група за набиране.
-
група за набиране : Дефинира изходящите телефонни точки, използвани за маршрутизиране на повикване.
-
изходящ dial-peer : Осигурява обработка на изходящи SIP съобщения и ги насочва към необходимата цел.
Докато IP и SIP се превърнаха в протоколи по подразбиране за PSTN магистрали, TDM (Time Division Multiplexing) ISDN вериги все още се използват широко и се поддържат с връзките на Webex Calling . За да се активира медийна оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, понастоящем е необходимо да се използва двуетапен процес за маршрутизиране на повикване . Този подход модифицира конфигурацията за маршрутизиране на повикване , показана по-горе, като въвежда набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали, както е показано на изображението по-долу.
Когато свързвате в помещението на Cisco Unified Communications Manager с Webex Calling, можете да използвате простата конфигурация на шлюз за обществена телефонна централа като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания.
В този документ се използват имената на хостове, IP адресите и интерфейсите, илюстрирани на следното изображение. Предоставени са опции за публично или частно (зад NAT) адресиране. SRV DNS записите не са задължителни, освен ако не се балансиране на товара в множество екземпляри на CUBE.
Използвайте указанията за конфигурация в останалата част от този документ, за да завършите конфигурацията на вашия локален шлюз, както следва:
-
Стъпка 1: Конфигурирайте базова връзка и сигурност на рутера
-
Стъпка 2: Конфигуриране на линията за Webex Calling
В зависимост от необходимата ви архитектура, следвайте едно от следните:
-
Стъпка 3: Конфигурирайте локален шлюз със SIP PSTN магистрала
-
Стъпка 4: Конфигурирайте локален шлюз със съществуваща Unified CM среда
или:
-
Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN магистрала
Базова конфигурация
Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.
-
Всички базирани на сертификати локални внедрявания на шлюз изискват Cisco IOS XE 17.9.1a или по-нови версии. За препоръчаните версии вижте Изследване на софтуера на Cisco страница. Потърсете платформата и изберете една от предложи издания.
-
Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и за технологии за сигурност.
-
Рутери от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лиценз за DNA Essentials. Рутерите без гласови карти или DSP изискват минимално лицензиране на DNA Essentials.
-
За изисквания за висок капацитет може също да изисквате лиценз за висока сигурност (HSEC) и допълнително право на пропускателна способност.
Отнесете се към Кодове за оторизация за повече подробности.
-
-
Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По-специално, конфигурирайте следното и проверете работата:
-
NTP
-
АКЛ
-
Удостоверяване на потребителя и дистанционен достъп
-
DNS
-
IP маршрутизиране
-
IP адреси
-
-
Мрежата към Webex Calling трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) на локалния шлюз или адресите на запис на услуги (SRV) трябва да се разрешават до публичен IPv4 адрес в интернет.
-
Всички SIP и медийни портове на интерфейса на локалния шлюз, обърнат към Webex , трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате съответно защитната си стена.
-
Инсталирайте подписан сертификат на локалния шлюз (по-долу са дадени подробни стъпки за конфигуриране).
-
Публичен орган за сертификати (CA), както е описано подробно в Какви основни центрове за сертифициране се поддържат за обаждания към аудио и видео платформи на Cisco Webex ? трябва да подпише сертификата на устройството.
-
FQDN , конфигуриран в Control Hub при създаване на магистрала, трябва да бъде сертификатът Common Name (CN) или Subject Alternate Name (SAN) на рутера. Например:
-
Ако конфигуриран транк в Control Hub на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на рутера трябва да съдържа cube1.lgw.com.
-
Ако конфигурирана магистрала в контролния център на вашата организация има lgws.lgw.com като SRV адрес на локалния(ите) шлюз(и), достъпен от магистралата, тогава CN или SAN в сертификата на рутера трябва да съдържа lgws.lgw.com. Записите, на които SRV адресът решава (CNAME, A Record или IP адрес), са незадължителни в SAN.
-
Независимо дали използвате FQDN или SRV за магистрала, адресът за контакт за всички нови SIP диалогови прозорци от вашия локален шлюз използва името, конфигурирано в Control Hub.
-
-
-
Уверете се, че сертификатите са подписани за използване от клиента и сървъра.
-
Качете пакета Cisco root CA в локалния шлюз.
Конфигурация
| 1 |
Уверете се, че присвоявате валидни и маршрутизирани IP адреси на всеки интерфейс от слой 3, например:
|
| 2 |
Защитете STUN идентификационните данни на рутера с помощта на симетрично криптиране. Конфигурирайте основния ключ за шифроване за криптиране и типа на криптиране, както следва: |
| 3 |
Създайте доверителна точка за криптиране със сертификат, подписан от предпочитания от вас орган за сертификати (CA). |
| 4 |
Удостоверете новия си сертификат, като използвате вашия междинен (или основен) СА сертификат, след което импортирайте сертификата (Стъпка 4). Въведете следната команда exec или конфигурация:
|
| 5 |
Импортирайте подписан сертификат за хост, като използвате следната команда exec или конфигурация:
|
| 6 |
Активирайте ексклузивността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните команди за конфигурация:
|
| 7 |
Инсталирайте пакета Cisco root CA, който включва СА сертификат, използван от Webex Calling. Използвайте crypto pki trustpool импортиране чист URL команда, за да изтеглите основния CA пакет от посочения URL и да изчистите текущия CA доверителен пул, след което инсталирайте новия пакет от сертификати: Ако трябва да използвате прокси за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA: ip http клиент прокси-сървър yourproxy.com прокси порт 80 |
| 1 |
Създайте CUBE базирана на сертификат PSTN магистрала за съществуващо местоположение в Control Hub. За повече информация вж Конфигурирайте връзки, групи маршрути и планове за набиране за Webex Calling . Отбележете информацията за магистралата, която се предоставя след създаването на багажника. Тези подробности, както е подчертано на следващата илюстрация, ще бъдат използвани в стъпките за конфигуриране в това ръководство.  |
| 2 |
Въведете следните команди, за да конфигурирате CUBE като локален шлюз за Webex Calling : Ето обяснение на полетата за конфигурацията:
Активира функциите на Cisco Unified Border Element (CUBE) на платформата. разрешаване на връзки глътка до глъткаАктивирайте CUBE основния SIP обратно към гръб функционалност на потребителския агент. За повече информация вж Разрешаване на връзки . По подразбиране транспортирането на факс T.38 е разрешено. За повече информация вж факс протокол t38 (гласова услуга) . Разрешава STUN (обхождане на сесия на UDP през NAT) глобално. Тези глобални команди за зашеметяване са необходими само при разполагане на вашия локален шлюз зад NAT.
За повече информация вж stun flowdata agent-id и stun flowdata споделена тайна . асиметричен полезен товар пъленКонфигурира SIP асиметрична поддръжка за полезен товар както за DTMF , така и за динамичен кодек. За повече информация относно тази команда вж асиметричен полезен товар . принудителна ранна офертаПринуждава локалния шлюз да изпрати SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вж ранна оферта . sip-профили входящиПозволява на CUBE да използва SIP профили за промяна на съобщенията при получаването им. Профилите се прилагат чрез dial-peers или наематели. |
| 3 |
Конфигуриране кодек за гласов клас 100 кодек филтър за багажника. В този пример се използва един и същ филтър за кодеци за всички канали. Можете да конфигурирате филтри за всеки багажник за прецизен контрол. Ето обяснение на полетата за конфигурацията: кодек за гласов клас 100Използва се за разрешаване само на предпочитани кодеци за повиквания през SIP канали. За повече информация вж кодек за гласов клас . Кодек Opus се поддържа само за PSTN канали, базирани на SIP. Ако PSTN магистралата използва гласова T1/E1 или аналогова FXO връзка, изключете предпочитание за кодек 1 опус от кодек за гласов клас 100 конфигурация. |
| 4 |
Конфигуриране гласов клас зашеметяване 100 за да активирате ICE в магистралата за Webex Calling . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: зашеметяващо използване ice liteИзползва се за активиране на ICE-Lite за всички Webex Calling , изправени пред набиране, за да позволи оптимизиране на медиите, когато е възможно. За повече информация вж използване на гласов клас зашеметяване и зашеметяващо използване ice lite . В зашеметяващо използване на защитна стена за преминаване на поток данни командата се изисква само при разполагане на вашия локален шлюз зад NAT. Имате нужда от зашеметяващо използване на ICE-lite за потоци от разговори, използващи оптимизация на медийния път. За да осигурите медийна оптимизация за шлюз SIP към TDM, конфигурирайте loopback dial-peer с активиран ICE-Lite на IP- IP крака. За допълнителни технически подробности се свържете с екипите на акаунта или TAC. |
| 5 |
Конфигурирайте политиката за криптиране на медиите за трафика на Webex . (Тази стъпка не е приложима за Webex for Government) Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Указва SHA1_ 80 като единствения SRTP шифров пакет CUBE предлага в SDP в съобщения за оферта и отговор. Webex Calling поддържа само SHA1_ 80 За повече информация вж гласов клас srtp-crypto . |
| 6 |
Конфигуриране на FIPS-съвместими GCM шифри (Тази стъпка е приложима само за Webex for Government) . Ето обяснение на полетата за конфигурацията: гласов клас srtp-crypto 100Посочва GCM като шифров пакет, който CUBE предлага. Задължително е да конфигурирате GCM шифри за локален шлюз за Webex за правителство. |
| 7 |
Конфигурирайте шаблон за уникално идентифициране на повиквания към магистрала на локален шлюз въз основа на неговото FQDN или SRV местоназначение: Ето обяснение на полетата за конфигурацията: глас клас uri 100 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този шаблон, използвайте LGW FQDN или SRV, конфигурирани в Control Hub, докато създавате магистрала. |
| 8 |
Конфигурирайте профили за манипулиране на SIP съобщение . Ако вашият шлюз е конфигуриран с публичен IP адрес, конфигурирайте профил по следния начин или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, а „198.51.100.1“ е публичният IP адрес на интерфейса на локалния шлюз пред Webex Calling: Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. Пропуснете следващата стъпка, ако сте конфигурирали вашия локален шлюз с публични IP адреси. |
| 9 |
Ако вашият шлюз е конфигуриран с частен IP адрес зад статичен NAT, конфигурирайте входящи и изходящи SIP профили, както следва. В този пример cube1.lgw.com е FQDN , конфигуриран за локалния шлюз, „10.80.13.12“ е IP адрес на интерфейса, обърнат към Webex Calling , а „192.65.79.20“ е публичният IP адрес на NAT. SIP профили за изходящи съобщения към Webex Calling
Ето обяснение на полетата за конфигурацията: правила 10 и 20За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Contact“ в съобщенията за SIP заявка и отговори трябва да съдържа стойността, предоставена за магистрала в Control Hub. Това ще бъде или FQDN на един хост, или името на име на домейн SRV, използвано за клъстер от устройства. правила от 30 до 81Преобразувайте препратките към частни адреси към външния публичен адрес за сайта, позволявайки на Webex правилно да интерпретира и маршрутизира следващите съобщения. SIP профил за входящи съобщения от Webex CallingЕто обяснение на полетата за конфигурацията: правила от 10 до 80Преобразувайте препратките към публичния адрес в конфигурирания частен адрес, позволявайки на съобщенията от Webex да бъдат правилно обработвани от CUBE. За повече информация вж гласови класове sip-профили . |
| 10 |
Конфигурирайте SIP опции за поддържане на активност с профил за промяна на заглавката. Ето обяснение на полетата за конфигурацията: гласов клас sip-options-keepalive 100Конфигурира поддържащ профил и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което Ping за SIP извън диалоговите опции се изпраща до целта за набиране, когато връзката на сърдечния ритъм към крайната точка е в състояние UP или Down. Този поддържащ профил се задейства от точката за набиране, конфигурирана към Webex. За да се гарантира, че заглавките на контактите включват напълно квалифицирано име на домейн SBC, се използва SIP профил 115. Правила 30, 40 и 50 се изискват само когато SBC е конфигуриран зад статичен NAT. В този пример cube1.lgw.com е FQDN , избрано за локалния шлюз и ако се използва статичен NAT, „10.80.13.12“ е IP адрес на интерфейса на SBC към Webex Calling и „192.65.79.20“ е публичният IP адрес на NAT . |
| 11 |
Конфигуриране на магистрала за Webex Calling : |
След като сте изградили транк към Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптирана магистрала към PSTN доставчик, базиран на SIP :
Ако вашият доставчик на услуги предлага защитена PSTN линия, можете да следвате подобна конфигурация, както е описано по-горе за линията за Webex Calling . Сигурно към сигурно маршрутизиране на повикване се поддържа от CUBE.
Ако използвате TDM / ISDN PSTN магистрала, преминете към следващия раздел Конфигурирайте локален шлюз с TDM PSTN магистрала .
За да конфигурирате TDM интерфейси за PSTN повиквания на Cisco TDM- SIP Gateways, вж. Конфигуриране на ISDN PRI .
| 1 |
Конфигурирайте следния uri на гласов клас, за да идентифицирате входящи повиквания от магистралата на PSTN: Ето обяснение на полетата за конфигурацията: глас клас uri 200 глДефинира модел за съпоставяне на входяща SIP покана с входяща магистрална точка за набиране. Когато въвеждате този модел, използвайте IP адрес на вашия IP шлюз за обществена телефонна централа. За повече информация вж глас клас uri . |
| 2 |
Конфигурирайте следната IP PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране с етикет на 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва тази точка за набиране 200 се справя с краката за SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията ipv4:192.168.80.13Посочва целевия IPv4 адрес на дестинацията, за да изпратите крака на повикването. Целта на сесията тук е IP адресът на ITSP. За повече информация вж цел на сесията (VoIP dial peer) . входящ ури през 200Определя критерий за съвпадение за заглавката на VIA с IP адреса на IP PSTN. Съпоставя всички входящи IP PSTN повиквания на локалния шлюз с dial-peer 200. За повече информация вж входящ URL адрес . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени до PSTN. За повече информация вж обвързвам . кодек за гласов клас 100Конфигурира точката за набиране да използва списъка с общи списък на филтрите за кодеци 100 . За повече информация вж кодек за гласов клас . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 3 |
Ако конфигурирате вашия локален шлюз да маршрутизиране на повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повикване . Ако конфигурирате своя локален шлюз с платформа Unified Communications Manager, преминете към следващия раздел. |
След като сте изградили транк към Webex Calling, използвайте следната конфигурация, за да създадете TDM trunk за вашата PSTN услуга с маршрутизиране на повикване с обратна линия, за да позволите оптимизиране на медиите на етап на повикването на Webex .
| 1 |
Конфигурацията за обратна връзка за набиране използва групи за набиране и маркери за маршрутизиране на повикване, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да създава цикли за маршрутизиране на повикване . Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрутизиране на повикване : Ето обяснение на полетата за конфигурацията: гласов превод-правилоИзползва регулярни изрази, дефинирани в правила, за добавяне или премахване на маркери за маршрутизиране на повикване . Превишените десетични цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности. В тази конфигурация, етикетът, добавен от профил за превод 100, се използва за насочване на повиквания от Webex Calling към PSTN чрез loopback dial-peers. По същия начин, етикетът, добавен от профил за превод 200, се използва за насочване на повиквания от PSTN към Webex Calling. Профили за превод 11 и 12 премахват тези тагове, преди да доставят повиквания съответно към магистралите на Webex и PSTN. Този пример предполага, че обажданите номера от Webex Calling са представени във формат + E.164 . Правило 100 премахва водещия +, за да поддържа валиден извикан номер. След това правило 12 добавя национална или международна цифра(и) за маршрутизиране при премахване на етикета. Използвайте цифри, които отговарят на вашия местен ISDN национален план за набиране. Ако Webex Calling представя номера в национален формат, коригирайте правила 100 и 12, за да добавите и премахнете съответно маркера за маршрутизиране. За повече информация вж гласов превод-профил и гласов превод-правило . |
| 2 |
Конфигурирайте TDM портовете за гласов интерфейс, както се изисква от типа на магистрала и използвания протокол. За повече информация вж Конфигуриране на ISDN PRI . Например, основната конфигурация на ISDN интерфейс с първична скорост, инсталиран в NIM слот 2 на устройство, може да включва следното: |
| 3 |
Конфигурирайте следната TDM PSTN точка за набиране: Ето обяснение на полетата за конфигурацията: Дефинира VoIP dial-peer с етикет 200 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . превод-профил входящ 200Присвоява профила за превод, който ще добави маркер за маршрутизиране на повикване към входящия извикан номер. директно набиране навътреНасочва повикването, без да предоставя вторичен тон за набиране. За повече информация вж директно набиране навътре . порт 0/2/0:15Физическият гласов порт, свързан с тази точка за набиране. |
| 4 |
За да активирате медийната оптимизация на IP пътищата за локални шлюзове с TDM- IP потоци на повиквания, можете да промените маршрутизиране на повикване чрез въвеждане на набор от вътрешни връзки за набиране с обратна връзка между Webex Calling и PSTN магистрали. Конфигурирайте следните точки за набиране с обратна връзка. В този случай всички входящи повиквания ще бъдат пренасочени първоначално към dial-peer 10, а оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахване на маркера за маршрутизиране, повикванията ще бъдат пренасочени към външна линия с помощта на групи за набиране. Ето обяснение на полетата за конфигурацията: Дефинира VoIP точка за набиране и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вж глас за набиране . превод-профил входящ 11Прилага профила за превод, дефиниран по-рано, за да премахне маркера за маршрутизиране на повикване , преди да премине към външна линия. дестинация-модел BAD.BADНеобходим е фиктивен модел на дестинация при маршрутизиране на изходящи повиквания с помощта на входяща група за набиране. За повече информация вж дестинация-модел (интерфейс) . протокол за сесия sipv2Указва, че тази точка за набиране обработва етапите на SIP повикване . За повече информация вж протокол за сесия (dial peer) . цел на сесията 192.168.80.14Указва адреса на интерфейса на локалния рутер като цел на повикване за връщане. За повече информация вж цел на сесията (voip dial peer) . управление на свързване източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за съобщения, изпратени чрез обратна верига. За повече информация вж обвързвам . свързване на медиен източник-интерфейс GigabitEthernet0/0/0Конфигурира интерфейса на източника и асоциирания IP адрес за медиите, изпратени чрез обратна верига. За повече информация вж обвързвам . dtmf-relay rtp-nteОпределя RTP-NTE (RFC2833) като способността на DTMF, очаквана на кол крака. За повече информация вж DTMF реле (глас през IP) . кодек g711alaw Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответствате на метода за компандиране, използван от вашата ISDN услуга. без вадДеактивира откриването на гласова активност. За повече информация вж vad (набиране) . |
| 5 |
Добавете следната конфигурация за маршрутизиране на повикване : Това приключва конфигурацията на вашия локален шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE се конфигурират.
|
Конфигурацията на PSTN- Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни магистрали към клъстер на Cisco Unified Communications Manager (UCM). В този случай всички повиквания се пренасочват през Unified CM. Обажданията от UCM на порт 5060 се насочват към PSTN, а повикванията от порт 5065 се насочват към Webex Calling. Следните постепенни конфигурации могат да бъдат добавени, за да включат този сценарий на извикване.
| 1 |
Конфигуриране на следните URI гласови класове: |
| 2 |
Конфигурирайте следните DNS записи, за да укажете SRV маршрутизиране към Unified CM хостове: IOS XE използва тези записи за локално определяне на целеви UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тогава тези локални конфигурации не са необходими. Ето обяснение на полетата за конфигурацията: Следната команда създава DNS SRV ресурсен запис. Създайте запис за всеки UCM хост и транк: IP хост_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Име на ресурсния запис на SRV 2: Приоритетът на ресурсния запис на SRV 1: Теглото на ресурсния запис на SRV 5060: Номерът на номер на порт , който да се използва за целевия хост в този ресурсен запис ucmsub5.mydomain.com: Целевият хост на ресурсния запис За да разрешите имената на целеви хост на ресурсния запис, създайте локални DNS A записи. Например: IP хост ucmsub5.mydomain.com 192.168.80.65 IP хост : Създава запис в локалната база данни на IOS XE. ucmsub5.mydomain.com: Името на име на домакина за запис A. 192.168.80.65: IP адрес на хоста. Създайте SRV ресурсните записи и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпределение на обажданията. |
| 3 |
Конфигурирайте следните точки за набиране: |
| 4 |
Добавете маршрутизиране на повикване, като използвате следните конфигурации: |
Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в базирания на Cisco IOS XE локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърляте събраните данни към случая Cisco TAC, за да ускорите времето за разделителна способност.
Диагностичните подписи (DS) са XML файлове, които съдържат информация за проблемни събития и действия за информиране, отстраняване на неизправности и отстраняване на проблема. Използвайте сислог съобщения, SNMP събития и чрез периодично наблюдение на конкретни командни изходи показване, за да определите логиката за откриване на проблеми. Видовете действия включват:
-
Събиране на командни изходи
-
Генериране на консолидиран лог файл
-
Качване на файла на потребител предоставено местоположение на мрежата като HTTPS, SCP, FTP сървър
Инженерите на TAC пишат DS файлове и цифрово го подписват за защита на интегритета. Всеки DS файл има уникалния цифров идентификатор, зададен от системата. Инструмент за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.
Преди да започнете:
-
Не редактирайте DS файла, който изтегляте от DSLT. Файловете, които променяте инсталацията за неуспех поради грешката при проверка на интегритета.
-
Прост протокол за прехвърляне на поща (SMTP) сървър, от който се нуждаете, за да може местният портал да изпраща известия по имейл.
-
Уверете се, че местният портал работи с IOS XE 17.6.1 или по-висока, ако искате да използвате защитения SMTP сървър за известия по имейл.
Предварителни изисквания
Локален шлюз, работещ с IOS XE 17.6.1 или по-висок
-
Диагностичните подписи са разрешени по подразбиране.
-
Конфигурирайте защитен имейл сървър, който използвате за изпращане на проактивни известия, ако устройството работи с IOS XE 17.6.1 или по-нова версия.
конфигуриране на терминално повикване-домашен пощенски сървър : @ приоритет 1 защитен tls край -
Конфигурирайте променливата ds_email среда с имейл адреса на администратора, за да уведомите.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_email край
Инсталирайте диагностични подписи за проактивен мониторинг
Мониторинг на високо използване на процесора
Този DS проследява 5-секундното използване на процесора с помощта на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които инсталирате в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.
-
Уверете се, че сте активирали SNMP с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено Изтеглете DS 64224, като използвате следните опции за падане в инструментаза справка за диагностични подписи:
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет:Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE Enterprise в решението за Webex Calling
Обхват на проблема
Производителност
Тип на проблема
Високо cpu utilization с имейл известие
-
Копирайте DS XML файла на светкавицата локален шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет:Следващият пример показва копиране на файла от FTP сървър към локалния шлюз.
копирайте ftp://user:pwd@192.0.2.12/DS_ 64224.xml начална флаш памет: Достъп до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [ОК - 3571/4096 байта] 3571 байта, копирани за 0,064 секунди (55797 байта/сек) -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех -
Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.comИзтегляне на DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-07 22:05:33
Когато се задейства, този подпис деинсталира всички работещи DS, включително и себе си. Ако е необходимо, моля, преинсталирайте DS 64224, за да продължите да наблюдавате високото използване на процесора на местния портал.
Мониторинг на необичайни прекъсвания на повикване
Този DS използва SNMP допитване на всеки 10 минути, за да открие необичайно прекъсване на връзката със SIP грешки 403, 488 и 503. Ако увеличението на броя на грешките е по-голямо или равно на 5 от последната анкета, той генерира системен журнал и известие по имейл. Моля, използвайте стъпките по-долу, за да инсталирате подписа.
-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 Вход за SNMP пакети 0 Грешки с лоша версия на SNMP 1 Неизвестно име на общността 0 Незаконна операция за предоставено име на общността 0 Грешки при кодиране 37763 Брой заявени променливи 2 Брой променени променливи 34560 PDU за получаване на заявка 138 PDU за получаване на следващия 2 PDU с заявка за набор 0 падане на пакети на входната опашка (максимален размер на опашката 1000) 158277 SNMP пакети изход 0 Твърде големи грешки (максимален размер на пакета 1500) 20 Няма такива грешки в името 0 Грешки с лоши стойности 0 Общи грешки 7998 PDUs за отговор 10280 Trap PDUs Пакети, които в момента са в SNMP процесна опашка за въвеждане: 0 SNMP глобален капан: разрешено -
Изтеглете DS 65221, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
SIP абнормно повикване прекъсване на връзката откриване с имейл и Syslog уведомление.
-
Копирайте DS XML файла в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 65221.xml начална флаш памет: -
Инсталирайте DS XML файла в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 65221.xml Заредете файл DS_ 65221.xml успех -
Използвайте командата покажете диагностичен подпис за обаждане вкъщи за да проверите дали подписът е инсталиран успешно. Колоната за състояние трябва да има „регистрирана“ стойност.
Инсталирайте диагностични сигнатури за отстраняване на проблем
Можете също така да използвате диагностични подписи (DS), за да разрешите проблемите бързо. Инженерите на Cisco TAC са автори на няколко подписа, които позволяват необходимите отстраняване на грешки, които са необходими за отстраняване на неизправности в даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая Cisco TAC. Това елиминира необходимостта от ръчна проверка за възникването на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.
Можете да използвате инструмента за справка за диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно решаване на даден проблем или да инсталирате подписа, който се препоръчва от инженера на TAC като част от ангажимента за поддръжка.
Ето един пример за това как да намерите и инсталирате DS за откриване на събитието "%VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0" syslog и автоматизира събирането на диагностични данни, като използва следните стъпки:
Конфигурирайте друга променлива на средата на DSds_fsurl_prefix като пътя на файлов сървър на Cisco TAC (cxd.cisco.com), за да качите диагностичните данни. Потребителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл , който може да бъде извлечен от Мениджър на случаи за поддръжка както е показано по-долу. Токенът за качване на файл може да бъде генериран в Прикачени файлове раздел на мениджъра на случаите за поддръжка, както е необходимо.
конфигуриране на среда за диагностика-подпис на терминал за повикване до дома LocalGateway(cfg-call-home-diag-sign)ds_fsurl_prefix "scp:// : @cxd.cisco.com" крайПример:
среда за диагностика и подпис за обаждане вкъщиds_fsurl_prefix "околна средаds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Уверете се, че SNMP е активиран с помощта на командното шоу snmp. Ако SNMP не е активиран, конфигурирайте snmp-сървър мениджър команда.
show snmp % SNMP агент не е активиран config t snmp-server manager край -
Препоръчваме инсталирането на High CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгвания и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Производителност
Тип на проблема
Високо използване на процесора с известие по имейл.
-
Изтеглете DS 65095, като използвате следните опции в инструментаза справка за диагностични подписи:
Име на полето
Стойност на полето
Платформа
Cisco 4300, 4400 ISR Series или Catalyst 8000V Edge софтуер
Продукт
CUBE предприятие в Webex повикване решение
Обхват на проблема
Сислогс
Тип на проблема
Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0
-
Копирайте DS XML файловете в локалния шлюз.
копирайте ftp://потребителско име:парола@ /DS_ 64224.xml начална флаш памет: копирайте ftp://потребителско име:парола@ /DS_ 65095.xml начална флаш памет: -
Инсталирайте високопроцесорния мониторинг DS 64224 и след това DS CPU XML файл в локалния шлюз.
обаждане вкъщи диагностика-сигнатура натоварване DS_ 64224.xml Заредете файл DS_ 64224.xml успех зареждане на DS за диагностика на повикване до дома_ 65095.xml Заредете файл DS_ 65095.xml успех -
Уверете се, че подписът е успешно инсталиран с помощта на диагностичен подписshow-call-home. Колоната за състоянието трябва да има "регистрирана" стойност.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comИзтеглени DSes:
Идентификационен номер на DS
Име на DS
Преразглеждане
Статус
Последна актуализация (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Регистриран
2020-11-08:00:07:45
65095
00:12:53
ДС_ LGW_ IEC_ Вall_spike_threshold
0.0.12
Регистриран
2020-11-08:00:12:53
Проверка на изпълнението на диагностичните подписи
В следващата команда колоната "Статус" на командата показва промени в диагностичния подпис на повикване-дом на "бягане", докато местният портал изпълнява действието, определено в подписа. Изходът от статистиката за диагностичния подпис на повикване-дом е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития.
показване на диагностичен подпис за обаждане до дома Текущи настройки за диагностичен подпис: Диагностичен подпис: активиран профил: CiscoTAC-1 (състояние: АКТИВНО) URL за изтегляне (и): https://tools.cisco.com/its/service/oddce/services/DDCEService Променлива на средата:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Изтеглени DSes:
|
Идентификационен номер на DS |
Име на DS |
Преразглеждане |
Статус |
Последна актуализация (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Регистриран |
2020-11-08 00:07:45 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
0.0.12 |
Изпълнява се |
2020-11-08 00:12:53 |
Показване на статистика за диагностика-подпис на повикване-дома
|
Идентификационен номер на DS |
Име на DS |
Задейства се /Макс/Деинсталиране |
Средно време за изпълнение (секунди) |
Максимално време за изпълнение (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
ДС_ LGW_ IEC_ Вall_spike_threshold |
1 /20/г |
23.053 |
23.053 |
Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, софтуерна версия, конфигурация на изпълнение и показване на командни изходи, които са от значение за отстраняване на неизправности в дадения проблем.
Деинсталиране на диагностични подписи
Използването на диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинира като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на диагностичния подпис на повикване-дом и изпълнете следната команда:
деинсталиране на диагностика за домашен подпис Пример:
деинсталиране на диагностичен подпис за обаждане до дома 64224 Периодично се добавят нови подписи към справочния инструмент за диагностични подписи, въз основа на проблеми, които се наблюдават при внедряването. TAC в момента не поддържа заявки за създаване на нови потребителски подписи.
