10 октомври 2026 г. | 3126 преглеждане(ия) | 1 души считат, че това е полезно
Конфигуриране на локален шлюз на Cisco IOS XE за Webex Calling
list-menuОбратна връзка?
След като конфигурирате Webex Calling за вашата организация, можете да конфигурирате багажник за свързване на локалния шлюз към Webex Calling. SIP TLS транспортът защитава багажника между локалния шлюз и облака Webex. Медиите между Local Gateway и Webex Calling използват SRTP.

Webex CallingПонастоящем поддържа две версии на Local Gateway:

  • Локален портал

  • Местен портал за Webex за правителството

Основни съображения

  • Преди да започнете, разберете изискванията за обществена комутирана телефонна мрежа (PSTN) и локален шлюз (LGW), базирани на помещенията. Webex Calling Вижте Предпочитаната архитектура на Cisco Webex Calling за повече информация.

  • Тази статия предполага, че е налице специална платформа Local Gateway без съществуваща гласова конфигурация. Ако промените съществуващ PSTN шлюз или внедряване на CUBE EnterpriseWebex Calling, за да използвате като функция Local Gateway, обърнете внимателно внимание на конфигурацията. Уверете се, че не прекъсвате съществуващите потоци на повиквания и функционалност поради промените, които правите.

Процедурите съдържат връзки към документация за справка с командите, където можете да научите повече за отделните опции за команди. Всички препратки към командите отиват към Командната справка на Webex Man aged Gateways, освен ако не е посочено друго (в този случай командните връзки отиват към Референция за Cisco IOSгласови команди). Можете да получите достъп до всички тези ръководства в Коман Cisco Unified Border Element дни препратки.

За информация относно поддържаните SBC на трети страни вижте съответната референтна документация за продукта.

Конфигурирайте вашия локален шлюз

Има две опции за конфигуриране на локалния шлюз за вашия Webex Calling багажник:

  • Базиран на регистрация багажник

  • Базиран на сертификат багажник

Използвайте потока от задачи или в локалния шлюз, базиран на регистрация, или локален шлюз, бази ран на серти фикат, за да конфигурирате Локален шлюз за вашия багажник. Webex Calling

Вижте Първи стъпки с Local Gateway за повече информация относно различните типове багажници. Изпълнете следните стъпки на самия локален шлюз, като използвате интерфейса на командния ред (CLI). Използваме протокол за иницииране на сесия (SIP) и транспорт на сигурността на транспортния слой (TLS), за да защитим багажника и защитен протокол в реално време (SRTP) за защита на медиите между локал ния шлюз и. Webex Calling

Основни съображения

  • Изберете CUBE като локален шлюз. Webex for Government понастоящем не поддържа никакви контролери на гранични сесии (SBC) на трети страни. За да прегледате последния списък, вижте Първи стъпки с Local Gateway.

  • Инстали Cisco IOS райте XE Dublin 17.12.1a или по-нови версии за всички Webex за местни портали на правителството.

  • За да прегледате списъка на органите за основно сертифициране (CA), които Webex подкрепя от правителството, вижте Органите за основен сертификат за Webex за правителството.

  • За подробности относно обхватите на външните портове за Local Gateway в Webex for Government вижте М режови изисквания за. Webex for Government (FedRAMP)

Местният портал за Webex за правителството не поддържа следното:

  • Stun/ICE-Lite за оптимизация на медийния път

  • Факс (Т.38)

Конфигурирайте вашия локален шлюз за Webex за правителството

За да конфигурирате локален шлюз за вашия Webex Calling багажник в Webex for Government, използвайте следната опция:

  • Базиран на сертификат багажник

Използвайте потока от задачи в локалния шлюз, базиран на сертификат и, за да конфигурирате локалния шлюз за вашия Webex Calling багажник. За повече подробности относно това как да конфигурирате локален шлюз, базиран на сертификати, вижте Конфигу риране на базиран на Webex Calling сертификат и багажник.

Задължително е да конфигурирате GCM шифри, съвместими с FIPS, за да поддържате Local Gateway за Webex за правителството. Ако не, настройката на повикването се провали. За подробности за конфигурацията вижте Конфигу риране на Webex Calling базиран на сертификати багажник.

Webex for Government не поддържа локален шлюз, базиран на регистрация.

Общ преглед на дизайна

Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз заWebex Calling, като използвате регистриращ SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от PSTN се насочват към Webex Calling и всички оба ждания от Webex Calling се насочват към PSTN. Изображението по-долу подчертава това решение и конфигурацията за маршрутизиране на повиквания на високо ниво, която ще бъде следвана.

В този дизайн се използват следните основни конфигурации:

  • наематели на гласов клас: Използ ва се за създаване на специфични конфигурации за багажника.

  • uri гласов клас: Използ ва се за класифициране на SIP съобщения за избор на входящ dial-peer.

  • входящ диал-peer: Осигурява лечение на входящи SIP съобщения и определя изходящия маршрут, използвайки група с на биране на партньори.

  • набираща група: Определя изходящите на биращи колони, използвани за маршрутизиране на нататъшни повиквания.

  • изходящ dial-peer: Осигурява лечение на изходящи SIP съобщения и ги насочва към необходимата цел .

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

За оптимизация на Webex Calling медиите с ISDN схеми за създаване на интерактивна свързаност (ICE) и TDM (Time Division Multiplexing) е необходимо да използвате процес на маршрутизиране на повиквания с два крака.

Докато IP и SIP са се превърнали в протоколи по подразбиране за PSTN стволовете, TDM (Time Division Multiplexing) ISDN схеми остават често срещани и се поддържат изцяло от. Webex Calling За да активирате оптимизацията на медиите за тези потоци от разговори TDM-IP, трябва да използвате интерактивно установяване на свързаност (ICE), което позволява на крайните точки да договарят директни медийни пътища.

Постигането на тази оптимизация изисква процес на маршрутизиране на повиквания с два крака. Този подход променя стандарт ната конфигурация за маршрутизиране, като въвежда набор от вътрешни връщащи връщачи между Webex Calling и PSTN стволовете, както е илюстрирано на изображението по-долу.

Call routing configuration with a set of internal loop-back dial-peers between Webex Calling and PSTN trunks

Когато свързвате локално Cisco Unified Communications Manager решение сWebex Calling, можете да използвате простата конфигурация на PSTN шлюз като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай Unified Communications Manager осигурява централизирано маршрутизиране и третиране на всички PSTN и обаждания. Webex Calling

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

В целия този документ се използват имената на хоста, IP адресите и интерфейсите, илюстри рани на следното изображение.

The host names, IP addresses, and interfaces used in Call routing configuration solutions

Използвайте указанията за конфигуриране в останалата част от този документ, за да завършите конфигурацията на локалния шлюз, както следва:

  • Стъпка 1: Конфигурирайте базовата връзка и сигурност на рутера

  • Стъпка 2: Конфигурирайте Webex Calling багажника

    В зависимост от изискваната от вас архитектура следвайте:

  • Стъпка 3: Конфигурирайте локален шлюз с SIP PSTN багажник

  • Стъпка 4: Конфигуриране на локален шлюз със съществуваща Unified CM среда

    Или:

  • Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN багажник

Конфигурирайте свързаността и сигурността

Базова конфигурация

Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.

  • Всички внедрявания на локален шлюз, базирани на регистрация, изискват Cisco IOS XE 17.6.1a или по-нови версии. Cisco IOSПрепоръчва се 17.12.2 или по-нова версия. За препоръчаните версии вижте страницата за изследване на софтуера на Cisco. Потърсете платформата и изберете една от предлож ените издания.

    • Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и с технологии за сигурност.

    • Рутерите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Ad vantage. Рутерите без гласови карти или DSP изискват минимум лицензиране на DNA Essentials.

  • Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По- специално конфигурирайте и проверете следното:

    • NTP

    • ACL

    • Удостоверяване на потребителя и отдалечен достъп

    • DNS

    • IP маршрутизиране

    • IP адреси

  • Мрежата към Webex Calling нея трябва да използва IPv4 адрес.

  • Качете пакета root CA на Cisco в локалния шлюз.

Когато конфигурирате страната на наемателяWebex Calling, с която да се свързвате, се поддържат само адреси, базирани на SRV.

Конфигурация

1

Уверете се, че присвоявате валидни и маршрутизируеми IP адреси на всеки интерфейс от слой 3, например:


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

2

Защитете идентификационните данни за регистрация и STUN на рутера, като използвате симетрично криптиране. Конфигурирайте първичния ключ за криптиране и типа на криптиране, както следва:


key config-key password-encrypt YourPassword
password encryption aes

3

Създайте заместител PKI доверителна точка.

Изисква тази надеждна точка за конфигуриране на TLS по-късно. За стволовете, базирани на регистрация, тази надеждна точка не изисква сертификат - както се изисква за багажник, базиран на сертификат.


crypto pki trustpoint EmptyTP 
 revocation-check none
4

Активирайте изключителността на TLS1.2 и посочете точката на доверие по подразбиране, като използвате следните конфигурационни команди. Актуализирайте параметрите на транспорта, за да осигурите надеждна сигурна връзка за регистрация:

Коман cn-san-validate serverдата гарантира, че Локалният шлюз позволява връзка, ако името на хоста, конфигурирано в tenant 200, е включено в полетата CN или SAN на сертификата, получен от изходящия прокси сървър.

  1. Задайте броя на повторните опити на tcp- на 1000 (кратни 5-msec = 5 секунди).

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


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

5

Инсталирайте пакета root CA на Cisco, който включва сертификата IDEntrust Commercial Root CA1, използван от. Webex Calling Използвайте командата crypto pki trustpool import clean url, за да изтеглите коренния пакет CA от посочения URL адрес и да изчистите текущия CA trustpool, след което инсталирайте новия пакет от сертификати:

Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA:

ip http клиентски прокси-сървър yourproxy.com прокси-порт 80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Конфигуриране на базата на Webex Calling регистрация багажник
1

Създайте базиран на регистрация PSTN багажник за съществуващо местоположение в контрол ния център. Забележете информацията за багажника, която се предоставя, след като багажникът е създаден. Подробностите, подчертани на илюстрацията, се използват в стъпките за конфигуриране в това ръководство. За повече информация вижте Конфигу риране на стволове, групи маршрути и планове за набиране Webex Calling.

PSTN trunk registered
2

Въведете следните команди, за да конфигурирате CUBE като Webex Calling локален шлюз:

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

Ето обяснение на полетата за конфигурацията:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • За да се предпази от измами с пътни такси, списъкът с доверени адреси определя списък с хостове и мрежи, от които Local Gateway очаква легитимни VoIP разговори.

  • По подразбиране Local Gateway блокира всички входящи VoIP съобщения от IP адреси, които не са в неговия доверен списък. По подразбиране се вярват статично конфигурирани диал-връстници с „целеви IP адреси на сесията“ или IP адреси на сървърната група. Добавянето на тези IP адреси към доверения списък не е необходимо.

  • Когато конфигурирате локалния шлюз, добавете IP подмрежите на вашия регионален център за Webex Calling данни към списъка. За повече информация вижте Ре ферентна информация за порт за Webex Calling. Също така добавете адресни диапазони за сървърите на Unified Communications Manager (ако се използват) и магист ралните шлюзове на PSTN.

    Ако вашият LGW е зад защитна стена с ограничен конусен NAT, може да предпочетете да деактивирате списъка с доверени IP адреси в Webex Calling облицовъчния интерфейс. Защитната стена вече ви предпазва от нежелан входящ VoIP. Деактивирането на действието намалява раз ходите ви за по-дългосрочна конфигурация, тъй като не можем да гарантираме, че адресите на Webex Calling връстниците остават фиксирани и във всеки случай трябва да конфигурирате защитната стена за връстниците си.

режим граничен елемент

Акти Cisco Unified Border Element вира (CUBE) функции на платформата.

медийна статистика

Позволява мониторинг на медиите на локалния шлюз.

медийна масова статистика

Позволява на контролната равнина да изследва равнината на данните за статистика за групови повиквания.

За повече информация относно тези команди вижте Медии.

допускане на връзки sip към sip

Активирайте CUBE основната SIP функционалност на потребителския агент обратно към обратно . За повече информация вижте Разреш аване на връзки.

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

зашеметяване

Активира STUN (сесийно преминаване на UDP през NAT) в световен мащаб.

  • Функцията STUN свързвания на Local Gateway позволява локално генерираните заявки за STUN да бъдат изпращани по договорения медийен път. Това помага да се отвори дупката в защитната стена.

За повече информация вижте идентификатор на агента за зашеметяване на потока и споделени секретни данни за зашеметяване на пото ка.

асиметричен полезен товар пълен

Конфигурира SIP асиметрична поддръжка на полезен товар както за DTMF , така и за динамични кодеци. За повече информация вижте ас иметричен полезен товар .

принудителна ранна оферта

Прин уждава Local Gateway да изпраща SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вижте ранна оферта.

3

Конфигури райте кодек от гласов клас 100, позволяващ G.711 кодеци само за всички стволове. Този прост подход е подходящ за повечето внедрявания. Ако е необходимо, към списъка могат да бъдат добавени допълнителни типове кодеци, поддържани както от първоначални, така и от крайни системи.

Поддържат се по-сложни решения, включ ващи тран скодиране с помощта на DSP модули, но не са включени в това ръководство. 


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

Ето обяснение на полетата за конфигурацията:

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

Използва се само за разрешаване на предпочитани кодеци за SIP стволови обаждания. За повече информация вижте ко дек от гласов клас.

4

Конфигури райте гласовия клас Stun-Usage 100, за да активирате ICE на багажника. Webex Calling


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

Ето обяснение на полетата за конфигурацията:

зашеметяващо използване на лед лит

Използва се за активи ране на Ice-Lite за всички изправени хора, за да позвол Webex Calling и оптимизация на медиите, когато е възможно. За повече информация вижте използване на гласовия клас зашеметяване и използване на за шеметяване ice lite.

Оптимизацията на медиите се договаря, където е възможно. Ако обаждането изисква облачни медийни услуги, като например запис, носителят не може да бъде оптимизиран.

5

Конфигурирайте правилата за криптиране на медиите за трафика на Webex.


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Ето обяснение на полетата за конфигурацията:

гласов клас srtp-крипто 100

Определ SHA1_80 я като единствения пакет за шифри SRTP, който CUBE предлага в SDP в съобщенията за оферти и отговори. Webex Callingсамо опори SHA1_80. За повече информация вижте гласов клас srtp-crypto.

6

Конфигурирайте шаблон за идентифициране на повиквания към багажника на Local Gateway въз основа на параметъра на дестинационния ствол: 


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

Ето обяснение на полетата за конфигурацията:

гласов клас тип 100 sip

Определя модел, който да съответства на входяща SIP покана с в ходящ багажник за набиране. Когато въвеждате този модел, използвайте dtg= последвано от стойността на Trunk OTG/DTG, предоставена в контролния център при създаването на багажника. За повече информация вижте URI гласов клас.

7

Конфигури райте SIP профил 100, който ще се използва за модифициране на SIP съобщения, преди да бъдат изпратениWebex Calling.


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

Ето обяснение на полетата за конфигурацията:

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

    Гарантира, че SIP заглавките, използвани за сигнализиране на повиквания, използват SIP, а не SIP схема, която Webex прокси сървърите изискват. Конфигурирането на CUBE за използване на SIP гарантира, че се използва сигурна регистрация.

  • правило 80

    Модифицира заглавката From, за да включва идентификатора OTG/DTG на основната група от контролния център, за да идентифицира уникално сайт на локален шлю з в предприятието.

Американският или канадският доставчик на PSTN може да предложи проверка на идентификатора на обаждащия се за спам и обаждания с измама, с допълнителната конфигурация, посочена в индика цията за повикване за спам или измама в статията. Webex Calling

8

Конфигуриране на Webex Calling багажника:

  1. Създайте гласов клас наем ател 100, за да дефинирате и групирате конфигурациите, необходими специално за Webex Calling багажника. По-специално, данните за регистрация на багажника, предоставени по-рано в Control Hub, ще бъдат използвани в тази стъпка, както е описано по-долу. По-късно наемателите, свързани с този наемател, ще наследят тези конфигурации.

    Следващият пример използва стойностите, илюстрирани в стъпка 1 за целите на това ръководство (показани с удебелен шрифт). Заменете ги със стойности за багажника ви във вашата конфигурация.

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

    Ето обяснение на полетата за конфигурацията:

    гласов клас наемател 100

    Определя набор от конфигура ционни параметри, които ще се използват само за Webex Calling багажника. За повече информация вижте Наемател на гласов клас.

    регистратор dns:98027369.us 10.bcld.webex.com схема sips изтича 240 съотношение на опресняване 50 tcp tls

    Регистриращ сървър за локалния шлюз с настройката за регистрация да се опреснява на всеки две минути (50% от 240 секунди). За повече информация вижте регистратора.

    Уверете се, че използвате стойността на Регистрирайте домейна от контролния център тук.

    идентификационен номер Dallas1171197921_LGU потребителско име Dallas1463285401_LGU парола 0 9Wt [M6ify+ царство БродУъркс

    Идентификации за предизвикателство за регистрация на багажника За повече информация вижте идентифика ционни данни (SIP UA).

    Уверете се, че използвате съответно стойностите за хост на линия/порт, потребителско име за удостоверяване и парола за удостоверяване от контролния център тук .

    потребителско име за удостоверяване Dallas1171197921_LGU парола 0 9Wt [M6 ify+ царство BroadWorks
    потребителско име за удостоверяване Dallas1171197921_LGU парола 0 9Wt [M6ify+ царство 98027369.us10.bcld.webex.com

    Предизвик ателство за удостоверяване на разговори. За повече информация вижте удостоверяване (dial-peer).

    Уверете се, че използвате съответно стойностите на потребителското име за удостоверяване, паролата за удостоверяване и домейна на регистратора от контролния център тук.

    няма идентификационен номер за дистанцион но парти

    Деактивирайте заглавката на SIP Remote-Party-ID (RPID), тъй като Webex Calling поддържа PAI, който е активиран с помощта на asserted-id pai. За повече информация вижте дистанционния идентификатор на парти.

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

    Конфигурира целевия SIP сървър за багажника. Използвайте адреса на Edge proxy SRV, предоставен в контролния център, когато създавате багажника си.

    свързване-повторна употреба

    Използва същата постоянна връзка за регистрация и обработка на повиквания. За повече информация вижте повторна употреба на свързване.

    srtp-крипто 100

    Конфигурира предпочитаните пакет и за шифроване за SRTP повикване (връзка) (посочено в стъпка 5). За повече информация вижте гласов клас srtp-crypto.

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

    Задава транспорт до TLS. За повече информация вижте сесия -транспорт.

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

    Деактивира обновяването на SIP сесията за разговори между CUBE и Webex. За повече информация вижте Освежаване на сес ията.

    URL глътки

    SRV заявката трябва да бъде SIP, както се поддържа от SBC за достъп; всички останали съобщения се променят на SIP чрез sip-profile 200.

    грешка-пропускане

    Задава функцията за преминаване през отговор на SIP грешка. За повече информация вижте грешка-pass thru.

    rel1xx деактивиране

    Деактивира използването на надеждни временни отговори за Webex Calling багажника. За повече информация вижте rel1xx.

    утвърден идентификационен приятел

    (Незадължително) Включва обработката на заглавката P-Asserted-Identity и контролира как това се използва за багажника. Webex Calling

    Webex Callingвключва заглав ки P-Asserted-Identity (PAI) в InVites за изходящи повиквания към локалния шлюз.

    Ако тази команда е конфигурирана, информацията за обаждащия се от заглавката на PAI се използва за попълване на изходящите заглавки F rom и PAI/Remote-Party-ID.

    Ако тази команда не е конфигурирана, информацията за обаждащия се от заглавката From се използва за попълване на изходящите заглав ки From и PA I/Remote-Party-ID.

    За повече информация вижте asserted-id.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/1

    Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до Webex Calling. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник GigabiteThernet0/0/1

    Конфигурира интерфейса на източника и свързания IP адрес за носители, изпратени до WebExCalling. За повече информация вижте обвър зване.

    без потребителско съдържание за преминаване през потребителство-sdp

    Команда по подразбиране под наемател. За повече информация относно тази команда вижте съдържанието pass-thru .

    сип-профили 100

    Променя SIP в SIP и променя линия /порт за съобщения INVITE и REGISTER, както е дефинирано в sip-профили 100. За повече информация вижте SIP-профили от гласов клас.

    изходен прокси dns: dfw04.sipconnect-us.bcld.webex.com

    Webex Callingдостъп до SBC. Поставете изходящия прокси адрес, предоставен в контрол ния център, когато създавате багажника си. За повече информация вижте Outbound-proxy.

    Политика за поверителност passthru

    Конфигурира опциите на политиката за заглавка за поверителност, за да може багажника да предава стойностите за поверителност от полученото съобщение към следващия етап на повикване. За повече информация вижте Политика за по верителност.

  2. Конфигурирайте Webex Calling багажника за dial-peer. 

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

    Ето обяснение на полетата за конфигурацията:

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

    Дефинира VoIP dial-peer с маркер 100 и дава смислено описание за по- лесно управление и отстраняване на неизправности.

    макс-конн 250

    Ограничава броя на едновременните входящи и изходящи повиквания между LGW и. Webex Calling За регистрационни стволове максималната конфигурирана стойност трябва да бъде 250. Потребителят по-ниска стойност, ако това би било по-подходящо за вашето в недряване. За повече информация относно ограниченията за едновременни повиквания за Local Gateway вижте документа „За почнете работа с локален шлюз“.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте модел на местоназначение (интерфейс).

    протокол за сесия sipv2

    Указва, че dial-peer 100 обработва SIP краката за повикване . За повече информация вижте протокол на сесията (dial-peer).

    sip-сървър за целеви сесии

    Показва, че SIP сървърът, дефини ран в tenant 100, е наследен и използван за местоназначението за обаждания от този партньор за набиране. За повече информация вижте цел на сесията (VoIP dial peer).

    входяща заявка URI 100

    За да посочите гласовия клас, използван за съвпадение на VoIP набиране с идентификатора на единния ресурсен идентификатор (URI) на входящо повикване. За повече информация вижте входящи URI.

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

    Конфигурира dial-peer да използва общия списък с фил три за кодеци 100. За повече информация вижте кодек от гласов клас .

    използване на гласовата класа 100

    Позволява локално генерираните заявки за STUN на Local Gateway да бъдат изпращани по договорения медийен път. STUN помага да се отвори дупка за защитна стена за медиен трафик. За повече информация вижте използването на гласов клас .

    няма локален хост от гласов клас sip

    Деактивира замяната на името на локалния хост на DNS вместо физическия IP адрес в заглавките From, Call-ID и Remote-Party-ID на изходящите съобщения.

    гласов клас SIP наемател 100

    Dial-peer наследява всички параметри, конфигурирани глобално и в tenant 100. Параметрите могат да бъдат отменени на ниво набиране.

    сртп

    Активира SRTP за крака на повикването .

    не какво

    Деактивира откриването на гласова активност.

  3. (Незадължително) Принудително повикване само към аудио.

    Видеоклипове с Webex Calling помощта на потоци от повиквания на локален шлюз не се поддържат. Въпреки че видеото може да функционира в някои сценарии, това може да доведе до влошено качество и неочаквано поведение. За да принудите пови квания само към аудио, приложете следната команда под вашите Webex Calling диал-peer:

    voice-class sip audio forced

    Ако решите да разрешите видео, обажданията може да не се извършват както се очаква.

9

За да конфигурирате мрежови устройства като CUBE и да препратите заглавки на протокола за иницииране на сесия (SIP), които устройството не обработва, използвайте тези команди. Тези команди позволяват на устройството да преминава през неподдържани SIP заглавки, включително заглавки за географско местоположение и PIDF-LO (Формат на данни за присъствие - обект за местоположение), на локалния шлюз. Тази функционалност поддържа услугите на Nomadic E911, като гарантира, че критичната информация за местоположението се запазва и препраща правилно.

  1. Набирайте партньорска конфигурация

    Voice service voip
 sip
  pass-thru headers unsupp

  2. Набирайте специфична конфигурация за партньори

    
Dial-peer voice 911 voip
 voice-class sip pass-thru headers unsupp

  3. Конфигурация на гласовия клас за определени заглавки

    За да прокси заглавките на гео местоположението:

    
voice class sip-hdr-passthrulist 200 
 passthru-hdr Geolocation-Routing
 passthru-hdr Geolocation
 passthru-hdr-unsupp

    Прилагайте преминаването към входящата/изходящия набиращ колега

    
dial-peer voice 100 voip  // inbound
 voice-class sip pass-thru headers 200
dial-peer voice 200 voip  // outbound
 voice-class sip pass-thru headers 200

    За да активирате преминаването на тялото на PIDFO, използвайте:

    
voice service voip 
 sip 
  pass-thru content unsupp

След като дефинирате наемателя 100 и конфигурирате SIP VoIP dial-peer, шлюзът инициира TLS връзка към. Webex Calling В този момент SBC за достъп представя сертификата си на Локалния шлюз. Локалният шлюз валидира сертификата Webex Calling за достъп SBC с помощта на коренния пакет CA , който е актуализиран по-рано. Ако сертификатът бъде разпознат, между локалния шлюз и Webex Calling достъп SBC се създава постоянна TLS сесия. След това локалният шлюз може да използва тази сигурна връзка, за да се регистрира в SBC за достъп до Webex. Когато регистрацията е оспорена за удостоверяване:

  • Потреб ителското име, парол ата и параметр ите на царството от конфигура цията на идентификационните данни се използват в отговора.

  • Правилата за модификация в sip profile 100 се използват за конвертиране на SIPS URL обратно в SIP.

Регистрацията е успешна, когато се получи 200 OK от SBC за достъп.

Flow diagram of authentication and registration of Webex Calling with Local gateway

Конфигуриране на локален шлюз с SIP PSTN багажник

След като сте изградили багажник Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптиран багажник към SIP базиран PSTN доставчик:

Ако вашият доставчик на услуги предлага защитен PSTN багажник, можете да следвате подобна конфигурация, описана по-горе за багажникаWebex Calling. CUBE поддържа сигурно маршрутизиране на повиквания.

Ако използвате TDM/ISDN PSTN багажник, преминете към следващия раздел Конфигу риране на локален шлюз с TDM PSTN багажник.

За да конфигурирате TDM интерфейси за PSTN разговори на шлюзовете на Cisco TDM-SIP, вижте Конфигуриране на ISDN PRI.

1

Конфигурирайте следния URI гласов клас, за да идентифицирате входящи повиквания от багажника на PSTN :


voice class uri 200 sip
  host ipv4:192.168.80.13

Ето обяснение на полетата за конфигурацията:

гласов клас тип 200 sip

Определя модел, който да съответства на входяща SIP покана с в ходящ багажник за набиране. Когато въвеждате този модел, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте URI гласов клас.

2

Конфигурирайте следния IP PSTN dial-peer:


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

Ето обяснение на полетата за конфигурацията:


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

Дефини ра VoIP dial-peer с маркер 200 и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вижте наби ращ глас.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте модел на местоназначение (интерфейс).

протокол за сесия sipv2

Указва, че този набиращ колега обработва SIP краката за повикване. За повече информация вижте протокол на сесията (колега за набиране).

цел на сесията ipv4:192.168.80.13

Задава целевия адрес за повиквания, изпратени до доставчика на PSTN. Това може да бъде или IP адрес, или име на DNS хост. За повече информация вижте цел на сесията (VoIP набиращ партньор).

входящи URI чрез 200

Указва гласовия клас, използван за съпоставяне на входящите повиквания с този диален партньор с помощта на URI на заглавката INVITE VIA. За повече информация вижте входящ URL адрес.

гласов клас глътка утвърден-id пай

(Незадължително) Включва обработ ката на заглавката P-Asserted-Identity и контролира как това се използва за багажника на PSTN. Ако се използва тази команда, идентичността на повикващата страна, предоставена от входящия dial-peer, се използва за изходящите заглавки From и P-Asserted-Identity. Ако тази команда не се използва, идентичността на повикващата страна, предоставена от входящия диал-peer, се използва за заглавките от изходящия и отдалечен идентификатор на партията. За повече информация вижте glase-class sip asserted-id.

интерфейс източник за управление на връзката Gigab iteThernet0/0/0

Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

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

Конфигурира dial-peer да използва общия списък с филтри за кодеци 100. За повече информация вижте кодек от гласов клас .

DTMF-реле RTP-NTE

Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

не какво

Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

3

Ако конфигурирате локалния шлюз да насочва само повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повиквания. Ако конфигурирате локалния шлюз с платформа Unified Communications Manager, преминете към следващия раздел.

  1. Създайте набиращи групи, за да насочите повиквания към Webex Calling или към PSTN. Определете DPG 100 с изходящ набиращ връщане 100 към. Webex Calling DPG 100 се прилага към входящия dial-peer от PSTN. По същия начин дефинирайте DPG 200 с изходящ dial-peer 200 към PSTN. DPG 200 се прилага към входящия dial-peer от Webex.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  2. Приложете набиращи групи за насочване на повиквания от Webex към PSTN и от PSTN към Webex: 

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

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 200

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

    Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.

Конфигурирайте локален шлюз с TDM PSTN багажник

След като сте изградили багажник към негоWebex Calling, използвайте следната конфигурация, за да създадете TDM багажник за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на медиите в режима за повикване на Webex.

Ако не се нуждаете от оптимизация на IP медиите, следвайте стъпките за конфигуриране на SIP PSTN багажника. Използвайте гласов порт и POTS dial-peer (както е показано в стъпки 2 и 3) вместо PSTN VoIP dial-peer.

1

Конфигурацията за обратно dial-peer използва групи за набиране и маркери за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли за маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрут изиране на повиквания:


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

Ето обяснение на полетата за конфигурацията:

правило за гласов превод

Използва регулярни изрази, дефинирани в правилата, за да добавя или премахва маркерите за маршрутизиране на повиквания. Свръхдекадните цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности.

В тази конфигурация маркерът, добавен от translation-profile 100, се използва за насочване на повиквания Webex Calling към PSTN чрез обратните циферни колони. По същия начин маркерът, добавен от translation-profile 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 на устройство, може да включва следното:


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

Конфигурирайте следния TDM PSTN dial-peer:


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

Ето обяснение на полетата за конфигурацията: 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

Дефини ра VoIP dial-peer с маркер 200 и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вижте наби ращ глас.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте модел на местоназначение (интерфейс).

входящ профил за превод 200

Присвоява профил а за превод, който ще добави маркер за маршрутизиране на повиквания към входящия повикан номер.

директно навътре набиране

Маршрутира повикването, без да осигурява вторичен набиращ тон. За повече информация вижте директно навътре на биране.

порт 0/2/ 0:15

Физическият гласов порт, свързан с този dial-peer.

4

За да активирате медийна оптимизация на IP пътища за локални шлюзове с потоци от повиквания TDM-IP, можете да промените маршрутизирането на повиквания, като въведете набор от вътрешни връщащи връщачи между и PSTN стволовете. Webex Calling Конфигурирайте следните връстници за обратно набиране. В този случай всички входящи повиквания ще бъдат насочени първоначално към dial-peer 10 и оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахването на маркера за маршрутизиране повикванията ще бъдат насочени към изходящия ствол с помощта на диал-peer групи.


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

Ето обяснение на полетата за конфигурацията: 


dial-peer voice 10 voip
 description Outbound loop-around leg

Дефинира VoIP dial-peer и дава смислено описание за по-лесно управление и отстраняване на неизправности . За повече информация вижте наби ращ глас.

входящ профил за превод 11

Прилага дефинирания по-рано профил на превод, за да премахне маркера за маршрутизиране на повиквания, преди да премине към из ходящия багажник.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. За повече информация вижте модел на местоназначение (интерфейс).

протокол за сесия sipv2

Указва, че този набиращ колега обработва SIP краката за повикване. За повече информация вижте протокол на сесията (колега за набиране).

цел на сесията ipv4:192.168.80.14

Определя адре са на локалния интерфейс на рутера като цел за повикване за обратно връщане. За повече информация вижте цел на сесията (VoIP dial peer).

интерфейс източник за управление на връзката Gigab iteThernet0/0/0

Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени през обратния цикъл. За повече информация вижте обвър зване.

интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

Конфигурира интерфейса на източника и свързания IP адрес за носители, изпратени през обратния цикъл. За повече информация вижте обвър зване.

DTMF-реле RTP-NTE

Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

кодек g711alaw

Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответства на метода на компандиране, използван от вашата ISDN услуга.

не какво

Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

5

Добавете следната конфигурация за маршрутизиране на повиквания:

  1. Създайте набиращи групи, за да насочите повиквания между стволовете PSTN и Webex чрез обратния цикъл.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  2. Прилагайте набиращи групи, за да маршрутизирате повиквания.

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 200

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.
Конфигуриране на локален шлюз със съществува Unified CM ща среда

Конфигу Webex Calling рацията на PSTN в предишните раздели може да бъде променена, за да включва допълнителни стволове към Cisco Unified Communications Manager (UCM) клъстер. В този случай всички обаждания се насочват чрезUnified CM. Обажданията от UCM на порт 5060 се насочват към PSTN и обажданията от порт 5065 се насочват към. Webex Calling Следните инкрементални конфигурации могат да бъдат добавени, за да включат този сценарий за извикване.

Когато създавате Webex Calling багажника, уве рете сеUnified CM, че конфигурирате входящия порт в настройките на профила за сигурност на SIP Trunk на 5065. Това позволява входящи съобщения на порт 5065 и попълване на заглавката VIA с тази стойност при изпращане на съобщения до Локалния шлюз.

Enter SIP trunk security profile information
1

Конфигурирайте следните URI гласови класи:

  1. Класифицира Unified CM към Webex обаждания с помощта на SIP VIA порт:

    
voice class uri 300 sip
 pattern :5065

  2. Класифицира Unified CM се към PSTN обаждания с помощта на SIP през порт:

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

    Класифицирайте входящите съобщения от UCM към PSTN багажника, като използвате един или повече модели, които описват първоначалните източници и номера на порта. Регулярни изрази могат да се използват за дефиниране на съвпа дащи модели, ако е необходимо.

    В горния пример се използва регуларен израз, за да съответства на всеки IP адрес в диапазона 192.168.80.60 до 65 и номер на порт 5060.

2

Конфигурирайте следните DNS записи, за да зададете SRV маршрутизиране към хостове Unified CM :

IOS XE използва тези записи за локално определяне на целевите UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тези локални конфигурации не са необходими.


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

Ето обяснение на полетата за конфигурацията:

Следващата команда създава запи DNS SRV с на ресурси. Създайте запис за всеки UCM хост и багажник:

IP хост _sip. _udp.pstn tocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_глътка. _udp.pstn tocucm.io: Име на записа на SRV ресурса

2: При оритетът на записа на ресурсите на SRV

1: Рекордното тегло на ресурса SRV

5060: Н омерът на порта, който да се използва за целевия хост в този запис на ресурса

ucmsub5.mydomain .com: Целевият хост на записа на ресурса

За да разрешите имената на целевите хост на записа на ресурсите, създайте локални DNS A записи. Например:

IP хост ucmsub5.mydomain.com 192.168.80.65

ip host: Създава запис в локалната база данни IOS XE.

ucmsub5.mydomain.com: Името на хост на записа A.

192.168.80.65: IP адресът на хоста.

Създайте записи на SRV ресурси и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпространение на повиквания.

3

Конфигурирайте следните набиращи устройства:

  1. Dial-peer за разговори между и: Unified CM Webex Calling

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

    Ето обяснение на полетата за конфигурацията:

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

    Дефини ра VoIP dial-peer с маркер 300 и дава смислено описание за по-лесно управление и отстраняване на неизправности.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение.

    протокол за сесия sipv2

    Указва, че dial-peer 300 обработва SIP краката за повикване . За повече информация вижте протокол на сесията (dial-peer).

    цел на сесията dns: wxtocucm.io

    Определя целта на сесията на множество Unified CM възли чрез раздел DNS SRV ителна способност. В този случай локално дефинира ният SRV запис wxtocucm.io се използва за насочване на повиквания.

    входящи URI чрез 300

    Използва гласов клас URI 300, за да насочи целия входящ трафик от Unified CM използване на изходен порт 5065 към този dial-peer. За повече информация вижте входящи URI.

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

    Показва списъка с филтри за коде ци за обаждания към и отUnified CM. За повече информация вижте ко дек от гласов клас.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

    DTMF-реле RTP-NTE

    Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

    не какво

    Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

  2. Dial-peer за разговори между Unified CM и PSTN:

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

    Ето обяснение на полетата за конфигурацията:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    Дефини ра VoIP dial-peer с маркер 400 и дава смислено описание за по-лесно управление и отстраняване на неизправности.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение.

    протокол за сесия sipv2

    Указва, че dial-peer 400 обработва SIP крака за повикване . За повече информация вижте протокол на сесията (dial-peer).

    цел на сесията dns:pstntocucm.io

    Определя целта на сесията на множество Unified CM възли чрез раздел DNS SRV ителна способност. В този случай локално дефинира ният SRV запис pstntocucm.io се използва за насочване на повиквания.

    входящи URI чрез 400

    Използва гласов клас URI 400 за насочване на целия входящ трафик от посочените хост Unified CM ове, използвайки изходен порт 5060 към този dial-peer. За повече информация вижте входящи URI.

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

    Показва списъка с филтри за коде ци за обаждания към и отUnified CM. За повече информация вижте ко дек от гласов клас.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

    DTMF-реле RTP-NTE

    Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

    не какво

    Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

4

Добавете маршрутизиране на повиквания, като използвате следните конфигурации:

  1. Създайте набиращи групи, за да насочите повиквания между Unified CM и. Webex Calling Определете DPG 100 с из ходящо набиране 100 към. Webex Calling DPG 100 се прилага към свързания входящ dial-peer от. Unified CM По същия начин дефинирайте DPG 300 с изходящ диал-peer 300 към. Unified CM DPG 300 се прилага към входящия dial-peer от Webex.

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Създайте набиращи групи за насочване на повиквания между Unified CM и PSTN. Определете DPG 200 с из ходящ dial-peer 200 към PSTN. DPG 200 се прилага към свързания входящ dial-peer от. Unified CM По същия начин дефинирайте DPG 400 с изходящ dial-peer 400 към. Unified CM DPG 400 се прилага към входящия dial-peer от PSTN.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  3. Прилагайте набиращи групи за насочване на повиквания от Webex към Unified CM и от към Webex: Unified CM 

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

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 300

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

  4. Прилагайте набиращи групи за насочване на повиквания от PSTN към Unified CM и от Unified CM към PSTN:

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

    Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.

Наблюдаване и отстраняване на неизправности Локален шлюз, базиран на регистрация

Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в локалния шлюз, базиран на IOS Xe, и генерира имейл, syslog или известие за съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и прехвърляне на събрани данни към кутията, за да ускор Cisco TAC ите времето за разрешаване.

Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития за за действане на проблеми и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Можете да дефинирате логиката за откриване на проблеми, като използвате syslog съобщения, SNMP събития и чрез периодично наблюдение на конкретни изходи за показване на команди.

Типовете действия включват събиране на показване на командни изходи:

  • Генериране на консолидиран регистрационен файл

  • Качване на файла на предоставено от потребителя мрежово местоположение като HTTPS, SCP, FTP сървър .

Инженерите на TAC създават DS файловете и ги подписват цифрово за защита на целостта. Всеки DS файл има уникален цифров идентификатор, зададен от системата. Инструментът за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.

Преди да започнете:

  • Не редактирайте файла DS, който изтегляте от DSL T. Файловете, които променяте, не успяват да инсталирате поради грешка при проверка на целостта.

  • Сървър за обикновен протокол за прехвърляне на поща (SMTP), който е необходим за локалния шлюз за изпращане на известия по имейл.

  • Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако искате да използвате защитения SMTP сървър за имейл известия.

Предпоставки

Локален шлюз, работещ с IOS XE 17.6.1a или по-нова версия

  1. Диагностичните подписи са активирани по подразбиране.

  2. Конфигурирайте защитения имейл сървър, който да се използва за изпращане на проактивно известие, ако устройството работи с Cisco IOS XE 17.6.1a или по-нова версия.

    configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. Конфигурирайте променливата на ds_emailсредата с имейл адреса на админист ратора, който да ви уведоми. 

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email <email address> 
end

Следното показва примерна конфигурация на локален шлюз, работещ на Cisco IOS XE 17.6.1a или по-нова версия, за да изпраща проактивни известия до tacfaststart@gmail.com, използвайки Gmail като защитен SMTP сървър:

Препоръчваме ви да използвате Cisco IOS XE Bengaluru 17.6.x или по-нови версии.

call-home  
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com"

Локалният шлюз, работещ на Cisco IOS XE Software, не е типичен уеб базиран Gmail клиент, който поддържа OAuth, така че трябва да конфигурираме конкретна настройка на акаунта в Gmail и да предоставим конкретно разрешение имейлът от устройството да бъде обработен правилно:

  1. Отидете в Управление на акаунта в Google > Защита и включете настрой ката за достъп до приложението По-малко сигурен.

  2. Отговорете „Да, бях аз“, когато получите имейл от Gmail, в който се казва „Google е попречила на някой да влезе в профила ви с помощта на приложение, което не е на Google“.

Инсталирайте диагностични подписи за проактивен мониторинг

Мониторинг на високото използване на процесора

Този DS проследява използването на процесора за пет секунди, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички грешки и деинсталира всички диагностични подписи, които са инсталирани в Локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.

  1. Използвайте командата show 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

  2. Изтеглете DS 64224, като използвате следните падащи опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Високо използване на процесора с известяване по имейл.

  3. Копирайте файла DS XML в светкавицата Local Gateway.

    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    Следващият пример показва копирането на файла от FTP сървър към локалния шлюз. 

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
[OK - 3571/4096 bytes] 
3571 bytes copied in 0.064 secs (55797 bytes/sec)

  4. Инсталирайте файла DS XML в локалния шлюз.

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. Използвайте командата show call-home diagnostic-signature, за да проверите дали подписът е инсталиран успешно. Колоната за състоя нието трябва да има стойност „регистрирана“. 

    show call-home diagnostic-signature  
Current diagnostic-signature settings: 
Diagnostic-signature: enabled 
Profile: CiscoTAC-1 (status: ACTIVE) 
Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
Environment variable: 
ds_email: username@gmail.com

    Изтеглете DSE:

    DS ID

    Име на DS

    Ревизиране

    Състояние

    Последна актуализация (GMT+ 00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-07 22:05:33

    Когато се задейства, този подпис деинсталира всички работещи DSs, включително самия себе си. Ако е необходимо, инсталирайте отново DS 64224, за да продължите да наблюдавате високото използване на процесора на локалния шлюз.

Следене на регистрацията на SIP багажника

Този DS проверява за дерегистрация на локален SIP Trunk с Webex Calling облак на всеки 60 секунди. След като събитието за дерегистрация бъде открито, то генерира имейл и syslog известие и се деинсталира след две събития за дерегистрация. Използвайте стъпките по-долу, за да инсталирате подписа:

  1. Изтеглете DS 64117, като използвате следните падащи опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    SIP-SIP

    Тип проблем

    Отписване на SIP Trunk с уведомяване по имейл.

  2. Копирайте файла DS XML в локалния шлюз.

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. Инсталирайте файла DS XML в локалния шлюз. 

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. Използвайте командата show call-home diagnostic-signature, за да проверите дали подписът е инсталиран успешно. Колоната за състоя нието трябва да има стойност „регистрирана“.

Наблюдение на ненормални прекъсвания

Този DS използва SNMP анкета на всеки 10 минути, за да открие ненормално прекъсване на повик ването с SIP грешки 403, 488 и 503.  Ако увеличението на броя на грешките е по-голямо или рав но на 5 от последната анкета, то генерира syslog и известие по имейл. Моля , използвайте стъпките по-долу, за да инсталирате подписа.

  1. Използвайте командата show 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

  2. Изтеглете DS 65221, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Откриване на ненормално прекъсване на повикването SIP с имейл и из вестие на Syslog.

  3. Копирайте файла DS XML в локалния шлюз. 

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. Инсталирайте файла DS XML в локалния шлюз. 

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. Използвайте командата show call-home diagnostic-signature, за да проверите дали подписът е инсталиран успешно. Колоната за състоя нието трябва да има стойност „регистрирана“.

Инсталирайте диагностични подписи, за да отстраните проблем

Използвайте диагностични подписи (DS) за бързо разрешаване на проблеми. Cisco TACинженерите са напи сали няколко подписа, които позволяват необходимите грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая. Cisco TAC Диагностичните подписи (DS) елиминират необходимостта от ръчна проверка за възникване на проблема и ул есняват отстраняването на прекъсващи и преходни проблеми.

Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате за самостоятелно решаване на даден проблем или можете да инсталирате подписа, препоръчан от инженера TAC като част от ангажимента за поддръжка.

Ето пример за това как да намерите и инсталирате DS за откриване на възникването „% VOICE_IEC -3-GW: CCAPI: Вътрешна грешка (праг на скок на повикване): IEC = 1.1.181.1.29. 0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:

  1. Конфигурирайте допълнителна променлива на DS среда ds_fsurl_prefix, която е пътят на Cisco TAC файловия сървър (cxd.cisco.com), към който се качват събраните диагностични данни. Потреб ителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файл, който може да бъде извлечен от Support Case Manager в следната команда. Токенът за качване на файлове може да бъде генериран в раздела При качени файлове на диспечера на казуси за поддръжка, ако е необходимо. 

    configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
end

    Пример: 

    call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. Уверете се, че SNMP е активиран с помощта на коман дата show snmp . Ако не е активиран, конфигурирайте командата snmp-server manager .

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. Уверете се, че инсталирате High CPU monitoring DS 64224 като проактивна мярка за деактивиране на всички грешки и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Високо използване на процесора с известяване по имейл.

  4. Изтеглете DS 65095, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или Cisco CSR 1000V серия

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Сислогс

    Тип проблем

    Syslog -% VOICE_IEC -3-GW: CCAPI: Вътрешна грешка (праг на скока на повикване): IEC = 1.1.181.1.29.0

  5. Копирайте файловете DS XML в локалния шлюз.

    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:

  6. Инсталирайте файла с висок процесор DS 64224 и след това XML файла DS 65095 в локалния шлюз. 

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success 
 
call-home diagnostic-signature load DS_65095.xml 
Load file DS_65095.xml success

  7. Проверете дали подписът е инсталиран успешно с помощта на командата show call-home diagnostic -signature. Колоната за състоя нието трябва да има стойност „регистрирана“. 

    show call-home diagnostic-signature  
Current diagnostic-signature settings: 
Diagnostic-signature: enabled 
Profile: CiscoTAC-1 (status: ACTIVE) 
Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
Environment variable: 
           ds_email: username@gmail.com 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com

    Изтеглени DSE:

    DS ID

    Име на 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 се променя на „стартираща“, докато локалният шлюз изпълнява действието, определено в подписа. Изходът на статистиката за диагностичния подпис за показ ване на обаждане е най-добрият начин да проверите дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната „Triggered/Max/Deinstall“ показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е дефинирано за откриване на събитие и дали подписът се деинсталира сам след откриване на максималния брой задействани събития. 

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

Изтеглени DSE:

DS ID

Име на 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 ID

Име на 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 ID от изхода на командата show call-home diagnostic-signature и изпълнете следната команда:

call-home diagnostic-signature deinstall <DS ID>

Пример:

call-home diagnostic-signature deinstall 64224

Нови подписи се добавят периодично към инструмента за търсене на подписи за диагностика въз основа на проблеми, които често се наблюдават при внедряването. Понастоящем TAC не поддържа заявки за създаване на нови персонализирани подписи.

Управление и валидиране на Cisco IOS XE шлюзове чрез Control Hub

За по-добро управление на Cisco IOS XE Gateways препоръчваме да се запишете и управлявате шлюзовете чрез контролния център. Това е опционална конфигурация. Когато се регистрирате, можете да използвате опцията за проверка на конфигурацията в контролния център, за да потвърдите конфигу рацията на локалния шлюз и да идентифицирате всички проблеми с конфигурацията. Понастоящем само базирани на регистрация стволове поддържат тази функционалност.

За повече информация относно управлението на шлюза, валидирането на локалния шлюз и оцеляването на сайта вижте следните статии:

Общ преглед на дизайна

Този раздел описва как да конфигурирате Cisco Unified Border Element (CUBE) като локален шлюз за Webex Calling използване на базиран на сертификат, взаимен TLS (MTLS) SIP багажник. Първата част на този документ илюстрира как да конфигурирате прост PSTN шлюз. В този случай всички повиквания от PSTN се насочват към Webex Calling и всички оба ждания от Webex Calling се насочват към PSTN. Следващото изображение подчертава това решение и конфигурацията за маршрутизиране на повиквания на високо ниво, която ще бъде следвана.

В този дизайн се използват следните основни конфигурации:

  • наематели на гласов клас: Използва се за създаване на специфични конфигурации за багажника.

  • uri гласов клас: Използва се за класифициране на SIP съобщения за избор на в ходящ dial-peer.

  • входящ диал-peer: Осигурява лечение на входящи SIP съобщения и определя изходящия маршрут, използвайки група с набиране на партньори.

  • набираща група: Определя изходя щите набиращи колони, използвани за маршрутизиране на нататъшни повиквания.

  • изходящ dial-peer: Осигур ява лечение на изходящи SIP съобщения и ги насочва към необходимата цел.

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

За оптимизация на Webex Calling медиите с ISDN схеми за създаване на интерактивна свързаност (ICE) и TDM (Time Division Multiplexing) е необходимо да използвате процес на маршрутизиране на повиквания с два крака.

Докато IP и SIP са се превърнали в протоколи по подразбиране за PSTN стволовете, TDM (Time Division Multiplexing) ISDN схеми остават често срещани и се поддържат изцяло от. Webex Calling За да активирате оптимизацията на медиите за тези потоци от разговори TDM-IP, трябва да използвате интерактивно установяване на свързаност (ICE), което позволява на крайните точки да договарят директни медийни пътища.

Постигането на тази оптимизация изисква процес на маршрутизиране на повиквания с два крака. Този подход променя стандарт ната конфигурация за маршрутизиране, като въвежда набор от вътрешни връщащи връщачи между Webex Calling и PSTN стволовете, както е илюстрирано на изображението по-долу.

Call routing configuration with a set of internal loop-back dial-peers between Webex Calling and PSTN trunks

Когато свързвате локално Cisco Unified Communications Manager решение сWebex Calling, можете да използвате простата конфигурация на PSTN шлюз като базова линия за изграждане на решението, илюстрирано на следващата диаграма. В този случай единният мениджър за комуникации осигурява централизирано маршрутизиране и третиране на всички PSTN и обаждания. Webex Calling

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

В целия този документ се използват имената на хоста, IP адресите и интерфейсите, илюстри рани на следното изображение. Предвидени са варианти за публично или частно (зад NAT) адресиране. SRV DNS записите не са задължителни, освен ако не се балансира натоварването в множество екземпляри на CUBE .

The host names, IP addresses, and interfaces used in certificate based local gateway configurations

Използвайте указанията за конфигуриране в останалата част от този документ, за да завършите конфигурацията на локалния шлюз, както следва:

  • Стъпка 1: Конфигурирайте базовата връзка и сигурност на рутера

  • Стъпка 2: Конфигурирайте Webex Calling багажника

    В зависимост от изискваната от вас архитектура следвайте:

  • Стъпка 3: Конфигурирайте локален шлюз с SIP PSTN багажник

  • Стъпка 4: Конфигуриране на локален шлюз със съществуваща Unified CM среда

    Или:

  • Стъпка 3: Конфигурирайте локален шлюз с TDM PSTN багажник

Конфигурирайте свързаността и сигурността

Базова конфигурация

Първата стъпка в подготовката на вашия рутер Cisco като локален шлюз за Webex Calling е да изградите базова конфигурация, която защитава вашата платформа и установява свързаност.

  • Всички внедрявания на локален шлюз, базирани на сертификати, изискват Cisco IOS XE 17.9.1a или по-нови версии. Cisco IOSПрепоръчва се XE 17.12.2 или по-нова версия. За препоръчаните версии вижте страницата за изследване на софтуера на Cisco. Потърсете платформата и изберете една от предлож ените издания.

    • Рутерите от серията ISR4000 трябва да бъдат конфигурирани както с лицензи за унифицирани комуникации, така и с технологии за сигурност.

    • Рутерите от серията Catalyst Edge 8000, оборудвани с гласови карти или DSP, изискват лицензиране на DNA Ad vantage. Рутерите без гласови карти или DSP изискват минимум лицензиране на DNA Essentials.

    • За изисквания с голям капацитет може да се нуждаете и от лиценз за висока сигурност (HSEC) и допълнително право на пропускателна способност.

      Вижте кодов ете за от оризация за повече подробности.

  • Създайте базова конфигурация за вашата платформа, която следва вашите бизнес политики. По- специално конфигурирайте и проверете следното:

    • NTP

    • ACL

    • Удостоверяване на потребителя и отдалечен достъп

    • DNS

    • IP маршрутизиране

    • IP адреси

  • Мрежата към Webex Calling нея трябва да използва IPv4 адрес. Напълно квалифицираните имена на домейни (FQDN) или сервизни записи (SRV) локален шлюз, конфигурирани в контролния център, трябва да отговарят на публичен IPv4 адрес в интернет.

  • Всички SIP и медийни портове на интерфейса Local Gateway, обърнат към Webex, трябва да са достъпни от интернет, директно или чрез статичен NAT. Уверете се, че актуализирате защитната стена съответно.

  • Следвайте подробните стъпки за конфигуриране, предоставени по-долу, за да инсталирате подписан сертификат на локал ния шлюз:

    • Публичен Certificate Authority (CA), описан подробно в Какви органи за основен сертификат се поддържат за повиквания към Cisco Webex аудио и видео платформи? трябва да подпише сертификата за устройството.

    • Поддържат се сертификати, съдържащи само удостоверяване на сървъра с разширено използване на ключа (EKU) Webex Callingне потвърждава или не налага наличието на EKU за удостоверяване на клиента по време на установяване на TLS ръкостискане.

      Някои контролери на гранични сесии (SBC) на трети страни могат да наложат стриктно валидиране на EKU и могат да отхвърлят сертификати, които не включват EKU за удостоверяване на клиента. В такива случаи се уверете, че SBC е конфигуриран да приема сертификати само с EKU за удостоверяване на сървъра или да деактивира стриктната проверка на EKU (ако се поддържа).

    • Общото наименование на сертификата (CN) или едно от алтернативните имена на предмета (SAN) трябва да са същите като FQDN, конфигурирани в контролния център.

      Когато купувате сертификат с общо наименование (CN) или алтернативно наименование на субекта (SAN), уверете се, че сертификатът използва само малки букви. В конфигурацията на Control Hub всички записи на FQDN автоматично се преобразуват в малки букви и всяко несъответствие в буквения корпус между FQDN и сертификата ще предотврати успешната регистрация на багажника.

      Например:

      • Ако конфигуриран багажник в контролния център на вашата организация има 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 диалогови прозорци от вашия локален шлюз трябва да използва името, конфигурирано в контролния център.

  • Качете пакета root CA на Cisco в локалния шлюз. Този пакет включва основния сертификат за CA, използван за проверка на платформата Webex.

Конфигурация

1

Уверете се, че присвоявате валидни и маршрутизируеми IP адреси на всеки интерфейс от слой 3, например:


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

2

Защитете идентификационните данни на STUN на рутера с помощта на симетрично криптиране. Конфигурирайте първичния ключ за криптиране и типа на криптиране, както следва:


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

Създайте надеждна точка за криптиране със сертификат за вашия домейн, подписан от поддържан Certificate Authority (CA).

  1. Създайте двойка ключове RSA, като използвате следната команда exec.

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. Използвайте следните конфигурационни команди, за да създадете надеждна точка за сертификата, като посочите стойностите на полетата, които да се използват в заявката за подписване на сертификат: 

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn none
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key
 hash sha256

    Бележки за полетата за сертификат:

    • fqdn: Това не е задължително поле за. Webex Calling Настройване на тази конфигурация на „none“, за да не се включва това поле в заявката за подпис ване на сертификат. Ако трябва да включите FQDN, използвайки тази команда, няма влияние върху операцията Local Gateway.

    • Subject name: За валидиране на повиквания от локален шлюз Webex трябва да съответства на FQDN в заглавките за SIP контакти с тези, включени или в атрибута Общо име на тема (CN) или полето Алтернативно име на субекта (SAN) на сертификата SBC. Полето за предмет трябва да съдържа поне атрибут по КН и може да включва други атрибути, ако се изисква. За повече информация вижте име на тема.

    • Subject-alt-name: Пол ето Алтернативно име на субекта (SAN) на сертификата SBC може да включва списък с допълнителни FQDNS. Webex проверява този списък, за да потвърди заглавката на SIP контакта в съобщенията от Local Gateway, ако атрибутът Subject CN на сертификата не е съвпадащ.

    • Хеш: Препоръчва се заявките за подписване на сертификати (CSR) да бъдат подписани чрез SHA256. Cisco IOSXE 17.11.1 използва този алгоритъм по подразбиране и за по-ранно издание използвайте командата Hash.

  3. Генерирайте заявка за подписване на сертификат (CSR) със следната команда exec или конфигурация и я използвайте, за да поискате подписан сертификат от поддържан доставчик на CA:

    crypto pki enroll LGW_CERT

4

Предоставете сертификата на CA за междинно подписване, за да удостоверявате сертификата си за хост. Въведете следната команда exec или конфигурация:


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

5

Импортирайте подписания хост сертификат, като използвате следната команда exec или конфигурация:


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

6

Активирайте изключителността на TLS1.2 и посочете точката на доверие по подразбиране, която да се използва за гласови приложения, като използвате следните конфигурационни команди:


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

7

Инсталирайте пакета Cisco root CA, който включва сертификата IDEntrust Commercial Root CA 1, използван отWebex Calling. Използвайте командата crypto pki trustpool import clean url, за да изтеглите коренния пакет CA от посочения URL адрес и да изчистите текущия CA trustpool, след което инсталирайте новия пакет от сертификати:

Ако трябва да използвате прокси сървър за достъп до интернет чрез HTTPS, добавете следната конфигурация, преди да импортирате пакета CA:

ip http клиентски прокси-сървър yourproxy.com прокси-порт 80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Конфигуриране на базиран на Webex Calling сертификати багажник
1

Създайте базиран на CUBE сертификат PSTN багажник за съществуващо местоположение в контролния център. За повече информация вижте Конфигу риране на стволове, групи маршрути и планове за набиране Webex Calling.

Забележете информацията за багажника при създаването на багажника. Тези подробности, както е подчертано на следната илюстрация, се използват в стъпките за конфигуриране в това ръководство.

CUBE certificate-based PSTN trunk group is created

2

Въведете следните команди, за да конфигурирате CUBE като Webex Calling локален шлюз:


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

Ето обяснение на полетата за конфигурацията:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • За да се предпази от измами с пътни такси, списъкът с доверени адреси определя списък с хостове и мрежови субекти, от които Local Gateway очаква легитимни VoIP разговори.

  • По подразбиране локалният шлюз блокира всички входящи VoIP съобщения от IP адреси, които не са в неговия доверен списък. По подразбиране се вярват статично конфигурирани диал-връстници с „целеви IP адреси на сесията“ или IP адреси на сървърната група. Не е нужно да добавяте тези IP адреси към списъка с доверени данни.

  • Когато конфигурирате локалния шлюз, добавете IP подмрежите за вашия регионален център за Webex Calling данни към списъка, вижте Информация за справка за порт Webex Calling за повече информация. Също така добавете адресни диапазони за сървърите на Unified Communications Manager (ако се използват) и магист ралните шлюзове на PSTN.

  • За повече информация как да използвате списък с доверени IP адреси, за да предотвратите измами с пътни такси, виж те доверен IP адрес.

режим граничен елемент

Акти Cisco Unified Border Element вира (CUBE) функции на платформата.

допускане на връзки sip към sip

Активирайте CUBE основната SIP функционалност на потребителския агент обратно към обратно. За повече информация вижте Разреш аване на връзки.

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

зашеметяване

Активира STUN (сесийно преминаване на UDP през NAT) в световен мащаб.

Тези глобални команди за зашеметяване са необходими само при внедряване на вашия Local Gateway зад NAT.

  • Функцията STUN свързвания на Local Gateway позволява локално генерираните заявки за STUN да бъдат изпращани по договорения медийен път. Това помага да се отвори дупката в защитната стена.

За повече информация вижте идентификатор на агента за зашеметяване на потока и споделени секретни данни за зашеметяване на пото ка.

асиметричен полезен товар пълен

Конфигурира SIP асиметрична поддръжка на полезен товар както за DTMF , така и за динамични кодеци. За повече информация относно тази команда вижте асиметричен полезен товар .

принудителна ранна оферта

Прин уждава Local Gateway да изпраща SDP информация в първоначалното съобщение INVITE, вместо да чака потвърждение от съседния партньор. За повече информация относно тази команда вижте ранна оферта.

SIP-профили входящи

Позволява на CUBE да използва SIP профили за модифици ране на съобщенията при получаването им. Профилите се прилагат чрез наематели или наематели.

3

Конфигури райте кодек от гласов клас 100, позволяващ G.711 кодеци само за всички стволове. Този прост подход е подходящ за повечето внедрявания. Ако е необходимо, добавете към списъка допълнителни типове кодеци, поддържани както от първоначални, така и от крайни системи.

Поддържат се по-сложни решения, включ ващи тран скодиране с помощта на DSP модули, но не са включени в това ръководство. 


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

Ето обяснение на полетата за конфигурацията:

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

Използва се само за разрешаване на предпочитани кодеци за SIP стволови обаждания. За повече информация вижте ко дек от гласов клас.

4

Конфигури райте гласовия клас Stun-Usage 100, за да активирате ICE на багажника. Webex Calling (Тази стъпка не е приложима за Webex за правителството)


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

Ето обяснение на полетата за конфигурацията:

зашеметяващо използване на лед лит

Използва се за активи ране на Ice-Lite за всички изправени хора, за да позвол Webex Calling и оптимизация на медиите, когато е възможно. За повече информация вижте използване на гласовия клас зашеметяване и използване на за шеметяване ice lite.

Командата за използване на зашеметяваща защитна стена е необходима само при внед ряване на локалния шлюз зад NAT.

Оптимизацията на медиите се договаря, където е възможно. Ако обаждането изисква облачни медийни услуги, като например запис, носителят не може да бъде оптимизиран.

5

Конфигурирайте правилата за криптиране на медиите за трафика на Webex. (Тази стъпка не е приложима за Webex за правителството)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Ето обяснение на полетата за конфигурацията:

гласов клас srtp-крипто 100

Определ SHA1_80 я като единствения пакет за шифри SRTP, който CUBE предлага в SDP в съобщенията за оферти и отговори. Webex Callingсамо опори SHA1_80. За повече информация вижте гласов клас srtp-crypto.

6

Конфигурирайте GCM шифри, съвместими с FIPS (Тази стъпка е приложима само за Webex за правителството). 


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

Ето обяснение на полетата за конфигурацията:

гласов клас srtp-крипто 100

Определя GCM като пакета за шифри, който CUBE предлага. Задължително е да конфигурирате GCM шифри за Local Gateway за Webex за правителството.

7

Конфигурирайте шаблон за уникално идентифициране на повиквания към багажника на Local Gateway въз основа на местоназначението му FQDN или SRV:


voice class uri 100 sip
 pattern cube1.lgw.com

Ето обяснение на полетата за конфигурацията:

гласов клас тип 100 sip

Определя модел, който да съответства на входяща SIP покана с в ходящ багажник за набиране. Когато въвеждате този модел, използвайте багажника FQDN или SRV, конфигурирани в контролния център за багажника.

По време на конфигуриране от страна на наематели на базирани на сертификати стволове заWebex Calling, използвайте само SRV-базиран Webex Calling Edge адрес на локалния шлюз. FqDNS вече не се поддържат.

8

Конфигурирайте профилите за манипулиране на съобщения Ако шлюзът ви е конфигури ран с публичен IP адрес, конфигурирайте профил по следния начин или преминете към следващата стъпка, ако използвате NAT. В този пример cube1.lgw.com е FQDN, конфигуриран за локалния шлюз:


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

Ето обяснение на полетата за конфигурацията:

Правила 10 и 20

За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Контакт“ в съобщенията за SIP заявки и отговори трябва да съдържа стойността, предоставена за багажника в контролния център. Това ще бъде или FQDN на един хост, или името SRV, използвано за клъстер от устройства.

9

Ако шлюзът ви е конфигуриран с частен IP адрес зад статичен NAT, конфигурирайте входящите и изходящите SIP профили, както следва. В този пример, cube1.lgw.com е FQDN, конфигуриран за локалния шлюз, „10.80.13.12" е IP адресът на интерфейса, а „192.65.79.20" е публичният IP адрес на NAT. Webex Calling

SIP профили за изходящи съобщения към Webex Calling 

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

Ето обяснение на полетата за конфигурацията:

Правила 10 и 20

За да позволите на Webex да удостоверява съобщенията от вашия локален шлюз, заглавката „Контакт“ в съобщенията за заявки и отговори на SIP трябва да съдържа стойността, предоставена за багажника в контролния център. Това ще бъде или FQDN на един хост, или името SRV, използвано за клъстер от устройства.

правила 30 до 81

Конвертирайте препратките към частни адреси към външния публичен адрес за сайта, позволявайки на Webex правилно да интерпретира и насочва следващите съобщения.

SIP профил за входящи съобщения от Webex Calling 

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

Ето обяснение на полетата за конфигурацията:

правила от 10 до 80

Конвертирайте препратките към публичен адрес към конфигурирания частен адрес, позволявайки на CUBE да обработва съобщенията от Webex.

За повече информация вижте SIP-профили от гласов клас.

Американският или канадският доставчик на PSTN може да предложи проверка на идентификатора на обаждащия се за спам и обаждания с измама, с допълнителната конфигурация, посочена в индика цията за повикване за спам или измама в статията. Webex Calling

10

Конфигурирайте SIP Options Keepalive с профил за модификация на заглавката.


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

Ето обяснение на полетата за конфигурацията:

гласов клас sip- опции-Keepalive 100

Конфигурира keepalive профил и влиза в режим на конфигуриране на гласовия клас. Можете да конфигурирате времето (в секунди), при което SIP Out of Dialog Options Ping се изпраща към набиращата цел, когато връзката на сърдечния ритъм към крайната точка е в състояние НАГОРЕ или надолу.

Този keepalive профил се задейства от диал-peer, конфигуриран към Webex.

За да се гарантира, че заглавките на контактите включват напълно квалифицираното име на домейн на SBC, се използва SIP профил 115. Правила 30, 40 и 50 се изискват само когато SBC е конфигуриран зад статичен NAT.

В този пример, cube1.lgw.com е FQDN, избран за локалния шлюз и ако се използва статичен NAT, „10.80.13.12" е IP адресът на SBC интерфейса към и „192.65.79.20" е публичният IP адрес на NAT. Webex Calling

11

Конфигуриране на Webex Calling багажника:

  1. Създайте гласов клас наем ател 100, за да дефинирате и групирате конфигурациите, необходими специално за Webex Calling багажника. Dial-peer, свързани с този наемател, по-късно наследява следните конфигурации:

    Следващият пример използва стойностите, илюстрирани в стъпка 1 за целите на това ръководство (показани с удебелен шрифт). Заменете ги със стойности за багажника ви във вашата конфигурация.

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

    Ето обяснение на полетата за конфигурацията:

    гласов клас наемател 100

    Препоръчваме ви да използвате наематели за конфигуриране на стволовете, които имат собствен TLS сертификат и списък за валидиране на CN или SAN. Тук tls-профилът, свързан с наемателя, съдържа точката на доверие, която да се използва за приемане или създаване на нови връзки, и има списък CN или SAN за валидиране на входящите връзки. За повече информация вижте Наемател на гласов клас.

    няма идентификационен номер за дистанцион но парти

    Деактивирайте заглавката SIP Remote-Party-ID (RPID), тъй като Webex Calling поддържа PAI, която е активирана с помощта на команда asserted-id pai. За повече информация вижте дистанционния идентификатор на парти.

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

    Конфигурира целевия SIP сървър за багажника. Използвайте адреса на Edge proxy SRV, предоставен в контролния център, когато създавате багажника

    srtp-крипто 100

    Конфигурира предпочитаните пакет и за шифрове за връзка (връзка) за SRTP повикване (посочено в стъпка 5). За повече информация вижте гласов клас srtp-crypto.

    локален хост DNS: cube1.lgw.com

    Конфигурира CUBE да замени физическия IP адрес в заглавките From, Call-ID и Remote-Party-ID в изходящите съобщения с предоставения FQDN. Използвайте багажника FQDN или SRV, конфигурирани в контролния център за багажника тук.

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

    Задава транспорт до TLS за асоциирани набиращи колеги. За повече информация вижте сесия -транспорт.

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

    Деактивира обновяването на SIP сесията за разговори между CUBE и Webex. За повече информация вижте Освежаване на сес ията.

    грешка-пропускане

    Задава функцията за преминаване през отговор на SIP грешка. За повече информация вижте грешка-pass thru.

    rel1xx деактивиране

    Деактивира използването на надеждни временни отговори за Webex Calling багажника. За повече информация вижте rel1xx.

    утвърден идентификационен приятел

    (Незадължително) Включва обработката на заглавката P-Asserted-Identity и контролира как това се използва за багажника. Webex Calling

    Webex Callingвключва заглав ки P-Asserted-Identity (PAI) в InVites за изходящи повиквания към локалния шлюз.

    Ако тази команда е конфигурирана, информацията за обаждащия се от заглавката на PAI се използва за попълване на изходящите заглавки F rom и PAI/Remote-Party-ID.

    Ако тази команда не е конфигурирана, информацията за обаждащия се от заглавката From се използва за попълване на изходящите заглав ки From и PA I/Remote-Party-ID.

    За повече информация вижте asserted-id.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/1

    Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени до Webex Calling. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник GigabiteThernet0/0/1

    Конфигурира интерфейса на източника и свързания IP адрес за носители, изпратени доWebex Calling. За повече информация вижте обвър зване.

    SIP профили от гласов клас 100

    Прилага профила за модификация на заглавката (публичен IP или NAT адресиране), който да се използва за изходящи съобщения. За повече информация вижте SIP профили от гласов клас.

    SIP профили от гласов клас 110 входящи

    Само за внедряния LGW зад NAT: Прилага профила за модификация на заглавката, който да се използва за входящи съобщения. За повече информация вижте SIP профили от гласов клас.

    политика за поверителност passthru

    Конфигурира CUBE за прозрачно предаване на заглавките за поверителност от полученото съобщение към следващия етап на повикване. За повече информация вижте Политика за по верителност.

  2. Конфигурирайте Webex Calling багажника за dial-peer.

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

    Ето обяснение на полетата за конфигурацията:

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

    Дефини ра VoIP dial-peer с маркер 100 и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вижте наби ращ глас.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай можете да използвате всеки валиден модел на дестинация. За повече информация вижте модел на местоназначение (интерфейс).

    протокол за сесия sipv2

    Указва, че този набиращ колега обработва SIP краката за повикване. За повече информация вижте протокол на сесията (dial-peer).

    sip-сървър за целеви сесии

    Показва, че SIP сървърът, дефини ран в tenant 100, е наследен и използван за местоназначението за обаждания от този партньор за набиране.

    входяща заявка URI 100

    Указва гласовия клас, използ ван за съпоставяне на входящите повиквания с този диален партньор с помощта на URI на заглавката INVITE REQUEST. За повече информация вижте входящи URI.

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

    Показва списъка с филтри за коде ци за обаждания към и отWebex Calling. За повече информация вижте ко дек от гласов клас.

    използване на гласовата класа 100

    Позволява локално генерираните заявки за STUN от Local Gateway да бъдат изпращани по договорения медийен път. Пакетите STUN помагат за отваряне на отвор на защитната стена за медиен трафик и откриване на валидни пътища за оптимизация на медиите.

    гласов клас SIP наемател 100

    Dial-peer наследява всички параметри, конфигурирани глобално и в tenant 100. Параметрите могат да бъдат отменени на ниво набиране. За повече информация вижте наемател на глът ки от гласов клас.

    опции за гласов клас SIP-Keepalive профил 100

    Тази команда следи наличието на група SIP сървъри или крайни точки, използвайки определен профил (100).

    сртп

    Активира SRTP за крака на повикването .

  3. (Незадължително) Принудително повикване само към аудио.

    Видеоклипове с Webex Calling помощта на потоци от повиквания на локален шлюз не се поддържат. Въпреки че видеото може да функционира в някои сценарии, това може да доведе до влошено качество и неочаквано поведение. За да принудите пови квания само към аудио, приложете следната команда под вашите Webex Calling диал-peer:

    voice-class sip audio forced

    Ако решите да разрешите видео, обажданията може да не се извършват както се очаква.

12

(Незадължително) За да конфигурирате мрежови устройства като CUBE и да препратите заглавки на протокола за иницииране на сесия (SIP), които устройството не обработва, използвайте тези команди. Тези команди позволяват на устройството да преминава през неподдържани SIP заглавки, включително заглавки за географско местоположение и PIDF-LO (Формат на данни за присъствие - обект за местоположение), на локалния шлюз. Тази функционалност поддържа услугите на Nomadic E-911, като гарантира, че критичната информация за местоположението се запазва и препраща правилно.

  1. Набирайте партньорска конфигурация

    Voice service voip
 sip
  pass-thru headers unsupp

  2. Конфигурация, специфична за набиране

    
Dial-peer voice 911 voip
 voice-class sip pass-thru headers unsupp

  3. Конфигурация на гласовия клас за определени заглавки

    За да прокси заглавките на гео местоположението:

    
voice class sip-hdr-passthrulist 200 
 passthru-hdr Geolocation-Routing
 passthru-hdr Geolocation
 passthru-hdr-unsupp

    Прилагайте преминаването към входящата/изходящия набиращ колега

    
dial-peer voice 100 voip  // inbound
 voice-class sip pass-thru headers 200
dial-peer voice 200 voip  // outbound
 voice-class sip pass-thru headers 200

    За да активирате преминаването на тялото на PIDFO, използвайте:

    
voice service voip 
 sip 
  pass-thru content unsupp
Конфигуриране на локален шлюз с SIP PSTN багажник

След като сте изградили багажник Webex Calling по-горе, използвайте следната конфигурация, за да създадете некриптиран багажник към SIP базиран PSTN доставчик:

Ако вашият доставчик на услуги предлага защитен PSTN багажник, можете да следвате подобна конфигурация, описана по-горе за багажникаWebex Calling. CUBE поддържа сигурно маршрутизиране на повиквания.

Ако използвате TDM/ISDN PSTN багажник, преминете към следващия раздел Конфигу риране на локален шлюз с TDM PSTN багажник.

За да конфигурирате TDM интерфейси за PSTN разговори на шлюзовете на Cisco TDM-SIP, вижте Конфигуриране на ISDN PRI.

1

Конфигурирайте следния URI гласов клас, за да идентифицирате входящи повиквания от багажника на PSTN :


voice class uri 200 sip
  host ipv4:192.168.80.13

Ето обяснение на полетата за конфигурацията:

гласов клас тип 200 sip

Определя модел, който да съответства на входяща SIP покана с в ходящ багажник за набиране. Когато въвеждате този модел, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте URI гласов клас.

2

Конфигурирайте следния IP PSTN dial-peer:


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

Ето обяснение на полетата за конфигурацията:


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

Дефини ра VoIP dial-peer с маркер 200 и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вижте наби ращ глас.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте модел на местоназначение (интерфейс).

протокол за сесия sipv2

Указва, че този набиращ колега обработва SIP краката за повикване. За повече информация вижте протокол на сесията (колега за набиране).

цел на сесията ipv4:192.168.80.13

Задава целевия адрес за повиквания, изпратени до доставчика на PSTN. Това може да бъде или IP адрес, или име на DNS хост. За повече информация вижте цел на сесията (VoIP набиращ партньор).

входящи URI чрез 200

Указва гласовия клас, използван за съпоставяне на входящите повиквания с този диален партньор с помощта на URI на заглавката INVITE VIA. За повече информация вижте входящ URL адрес.

гласов клас глътка утвърден-id пай

(Незадължително) Включва обработ ката на заглавката P-Asserted-Identity и контролира как това се използва за багажника на PSTN. Ако се използва тази команда, идентичността на повикващата страна, предоставена от входящия dial-peer, се използва за изходящите заглавки From и P-Asserted-Identity. Ако тази команда не се използва, идентичността на повикващата страна, предоставена от входящия диал-peer, се използва за заглавките от изходящия и отдалечен идентификатор на партията. За повече информация вижте glase-class sip asserted-id.

интерфейс източник за управление на връзката Gigab iteThernet0/0/0

Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

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

Конфигурира dial-peer да използва общия списък с филтри за кодеци 100. За повече информация вижте кодек от гласов клас .

DTMF-реле RTP-NTE

Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

не какво

Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

3

Ако конфигурирате локалния шлюз да насочва само повиквания между Webex Calling и PSTN, добавете следната конфигурация за маршрутизиране на повиквания. Ако конфигурирате локалния шлюз с платформа Unified Communications Manager, преминете към следващия раздел.

  1. Създайте набиращи групи, за да насочите повиквания към Webex Calling или към PSTN. Определете DPG 100 с изходящ набиращ връщане 100 към. Webex Calling DPG 100 се прилага към входящия dial-peer от PSTN. По същия начин дефинирайте DPG 200 с изходящ dial-peer 200 към PSTN. DPG 200 се прилага към входящия dial-peer от Webex.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  2. Приложете набиращи групи за насочване на повиквания от Webex към PSTN и от PSTN към Webex: 

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

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 200

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

    Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.

Конфигурирайте локален шлюз с TDM PSTN багажник

След като сте изградили багажник към негоWebex Calling, използвайте следната конфигурация, за да създадете TDM багажник за вашата PSTN услуга с маршрутизиране на обратни повиквания, за да позволите оптимизация на медиите в режима за повикване на Webex.

Ако не се нуждаете от оптимизация на IP медиите, следвайте стъпките за конфигуриране на SIP PSTN багажника. Използвайте гласов порт и POTS dial-peer (както е показано в стъпки 2 и 3) вместо PSTN VoIP dial-peer.

1

Конфигурацията за обратно dial-peer използва групи за набиране и маркери за маршрутизиране на повиквания, за да гарантира, че повикванията преминават правилно между Webex и PSTN, без да се създават цикли за маршрутизиране на повиквания. Конфигурирайте следните правила за превод, които ще се използват за добавяне и премахване на маркерите за маршрут изиране на повиквания:


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

Ето обяснение на полетата за конфигурацията:

правило за гласов превод

Използва регулярни изрази, дефинирани в правилата, за да добавя или премахва маркерите за маршрутизиране на повиквания. Свръхдекадните цифри („A“) се използват за добавяне на яснота при отстраняване на неизправности.

В тази конфигурация маркерът, добавен от translation-profile 100, се използва за насочване на повиквания Webex Calling към PSTN чрез обратните циферни колони. По същия начин маркерът, добавен от translation-profile 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 на устройство, може да включва следното:


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

Конфигурирайте следния TDM PSTN dial-peer:


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

Ето обяснение на полетата за конфигурацията: 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

Дефини ра VoIP dial-peer с маркер 200 и дава смислено описание за по-лесно управление и отстраняване на неизправности. За повече информация вижте наби ращ глас.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение. За повече информация вижте модел на местоназначение (интерфейс).

входящ профил за превод 200

Присвоява профил а за превод, който ще добави маркер за маршрутизиране на повиквания към входящия повикан номер.

директно навътре набиране

Маршрутира повикването, без да осигурява вторичен набиращ тон. За повече информация вижте директно навътре на биране.

порт 0/2/ 0:15

Физическият гласов порт, свързан с този dial-peer.

4

За да активирате медийна оптимизация на IP пътища за локални шлюзове с потоци от повиквания TDM-IP, можете да промените маршрутизирането на повиквания, като въведете набор от вътрешни връщащи връщачи между и PSTN стволовете. Webex Calling Конфигурирайте следните връстници за обратно набиране. В този случай всички входящи повиквания ще бъдат насочени първоначално към dial-peer 10 и оттам към dial-peer 11 или 12 въз основа на приложения маркер за маршрутизиране. След премахването на маркера за маршрутизиране повикванията ще бъдат насочени към изходящия ствол с помощта на диал-peer групи.


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

Ето обяснение на полетата за конфигурацията: 


dial-peer voice 10 voip
 description Outbound loop-around leg

Дефинира VoIP dial-peer и дава смислено описание за по-лесно управление и отстраняване на неизправности . За повече информация вижте наби ращ глас.

входящ профил за превод 11

Прилага дефинирания по-рано профил на превод, за да премахне маркера за маршрутизиране на повиквания, преди да премине към из ходящия багажник.

модел на дестинация BAD.BAD

При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. За повече информация вижте модел на местоназначение (интерфейс).

протокол за сесия sipv2

Указва, че този набиращ колега обработва SIP краката за повикване. За повече информация вижте протокол на сесията (колега за набиране).

цел на сесията ipv4:192.168.80.14

Определя адре са на локалния интерфейс на рутера като цел за повикване за обратно връщане. За повече информация вижте цел на сесията (VoIP dial peer).

интерфейс източник за управление на връзката Gigab iteThernet0/0/0

Конфигурира интерфейса на източника и свързания IP адрес за съобщения, изпратени през обратния цикъл. За повече информация вижте обвър зване.

интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

Конфигурира интерфейса на източника и свързания IP адрес за носители, изпратени през обратния цикъл. За повече информация вижте обвър зване.

DTMF-реле RTP-NTE

Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

кодек g711alaw

Принуждава всички PSTN повиквания да използват G.711. Изберете a-law или u-law, за да съответства на метода на компандиране, използван от вашата ISDN услуга.

не какво

Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

5

Добавете следната конфигурация за маршрутизиране на повиквания:

  1. Създайте набиращи групи, за да насочите повиквания между стволовете PSTN и Webex чрез обратния цикъл.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  2. Прилагайте набиращи групи, за да маршрутизирате повиквания.

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 200

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.
Конфигуриране на локален шлюз със съществува Unified CM ща среда

Конфигу Webex Calling рацията на PSTN в предишните раздели може да бъде променена, за да включва допълнителни стволове към Cisco Unified Communications Manager (UCM) клъстер. В този случай всички обаждания се насочват чрезUnified CM. Обажданията от UCM на порт 5060 се насочват към PSTN и обажданията от порт 5065 се насочват към. Webex Calling Следните инкрементални конфигурации могат да бъдат добавени, за да включат този сценарий за извикване.

1

Конфигурирайте следните URI гласови класи:

  1. Класифицира Unified CM към Webex обаждания с помощта на SIP VIA порт:

    
voice class uri 300 sip
 pattern :5065

  2. Класифицира Unified CM се към PSTN обаждания с помощта на SIP през порт:

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

    Класифицирайте входящите съобщения от UCM към PSTN багажника, като използвате един или повече модели, които описват първоначалните източници и номера на порта. Регулярни изрази могат да се използват за дефиниране на съвпа дащи модели, ако е необходимо.

    В горния пример се използва регуларен израз, за да съответства на всеки IP адрес в диапазона 192.168.80.60 до 65 и номер на порт 5060.

2

Конфигурирайте следните DNS записи, за да зададете SRV маршрутизиране към хостове Unified CM :

IOS XE използва тези записи за локално определяне на целевите UCM хостове и портове. С тази конфигурация не е необходимо да конфигурирате записи във вашата DNS система. Ако предпочитате да използвате вашия DNS, тези локални конфигурации не са необходими.


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

Ето обяснение на полетата за конфигурацията:

Следващата команда създава запи DNS SRV с на ресурси. Създайте запис за всеки UCM хост и багажник:

IP хост _sip. _udp.pstn tocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_глътка. _udp.pstn tocucm.io: Име на записа на SRV ресурса

2: При оритетът на записа на ресурсите на SRV

1: Рекордното тегло на ресурса SRV

5060: Н омерът на порта, който да се използва за целевия хост в този запис на ресурса

ucmsub5.mydomain .com: Целевият хост на записа на ресурса

За да разрешите имената на целевите хост на записа на ресурсите, създайте локални DNS A записи. Например:

IP хост ucmsub5.mydomain.com 192.168.80.65

ip host: Създава запис в локалната база данни IOS XE.

ucmsub5.mydomain.com: Името на хост на записа A.

192.168.80.65: IP адресът на хоста.

Създайте записи на SRV ресурси и A записи, за да отразяват вашата UCM среда и предпочитаната стратегия за разпространение на повиквания.

3

Конфигурирайте следните набиращи устройства:

  1. Dial-peer за разговори между и: Unified CM Webex Calling

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

    Ето обяснение на полетата за конфигурацията:

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

    Дефини ра VoIP dial-peer с маркер 300 и дава смислено описание за по-лесно управление и отстраняване на неизправности.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение.

    протокол за сесия sipv2

    Указва, че dial-peer 300 обработва SIP краката за повикване . За повече информация вижте протокол на сесията (dial-peer).

    цел на сесията dns: wxtocucm.io

    Определя целта на сесията на множество Unified CM възли чрез раздел DNS SRV ителна способност. В този случай локално дефинира ният SRV запис wxtocucm.io се използва за насочване на повиквания.

    входящи URI чрез 300

    Използва гласов клас URI 300, за да насочи целия входящ трафик от Unified CM използване на изходен порт 5065 към този dial-peer. За повече информация вижте входящи URI.

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

    Показва списъка с филтри за коде ци за обаждания към и отUnified CM. За повече информация вижте ко дек от гласов клас.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

    DTMF-реле RTP-NTE

    Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

    не какво

    Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

  2. Dial-peer за разговори между Unified CM и PSTN:

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

    Ето обяснение на полетата за конфигурацията:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    Дефини ра VoIP dial-peer с маркер 400 и дава смислено описание за по-лесно управление и отстраняване на неизправности.

    модел на дестинация BAD.BAD

    При маршрутизиране на изходящи повиквания с помощта на входяща група с помощта на входяща група за набиране е необходим фиктивен модел на дестинация. В този случай може да се използва всеки валиден модел на местоназначение.

    протокол за сесия sipv2

    Указва, че dial-peer 400 обработва SIP крака за повикване . За повече информация вижте протокол на сесията (dial-peer).

    цел на сесията dns:pstntocucm.io

    Определя целта на сесията на множество Unified CM възли чрез раздел DNS SRV ителна способност. В този случай локално дефинира ният SRV запис pstntocucm.io се използва за насочване на повиквания.

    входящи URI чрез 400

    Използва гласов клас URI 400 за насочване на целия входящ трафик от посочените хост Unified CM ове, използвайки изходен порт 5060 към този dial-peer. За повече информация вижте входящи URI.

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

    Показва списъка с филтри за коде ци за обаждания към и отUnified CM. За повече информация вижте ко дек от гласов клас.

    интерфейс източник за управление на връзката Gigab iteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за съобщения, изпратени до PSTN. За повече информация вижте обвър зване.

    интерфейс за свързване на медиен източник Gig abiteThernet0/0/0

    Конфигурира интерфей са на източника и свързания IP адрес за носители, изпратени до PSTN. За повече информация вижте обвър зване.

    DTMF-реле RTP-NTE

    Определя RTP-NTE (RFC2833) като способността на DTMF, очаквана при повикването. За повече информация вижте DTMF Relay (Voice over IP).

    не какво

    Деактивира откриването на гласова активност. За повече информация вижте vad (peer за набиране).

4

Добавете маршрутизиране на повиквания, като използвате следните конфигурации:

  1. Създайте набиращи групи, за да насочите повиквания между Unified CM и. Webex Calling Определете DPG 100 с из ходящо набиране 100 към. Webex Calling DPG 100 се прилага към свързания входящ dial-peer от. Unified CM По същия начин дефинирайте DPG 300 с изходящ диал-peer 300 към. Unified CM DPG 300 се прилага към входящия dial-peer от Webex.

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Създайте набиращи групи за насочване на повиквания между Unified CM и PSTN. Определете DPG 200 с из ходящ dial-peer 200 към PSTN. DPG 200 се прилага към свързания входящ dial-peer от. Unified CM По същия начин дефинирайте DPG 400 с изходящ dial-peer 400 към. Unified CM DPG 400 се прилага към входящия dial-peer от PSTN.

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

    Ето обяснение на полетата за конфигурацията:

    набиращ колега 100

    Свързва изходящ набиращ партньор с група за наби ране. За повече информация вижте dpg от гласов клас .

  3. Прилагайте набиращи групи за насочване на повиквания от Webex към Unified CM и от към Webex: Unified CM 

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

    Ето обяснение на полетата за конфигурацията:

    дестинация dpg 300

    Определя коя група за набиране и следователно диал-peer трябва да се използва за изходящо третиране на повиквания, представени на този входящ наби ращ партньор.

  4. Прилагайте набиращи групи за насочване на повиквания от PSTN към Unified CM и от Unified CM към PSTN:

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

    Това завърш ва конфигурацията на локалния шлюз. Запазете конфигурацията и презаредете платформата, ако това е първият път, когато функциите на CUBE са конфигурирани.

Наблюдение и отстраняване на неизправности Локален шлюз, базиран на сертификат

Диагностичните подписи (DS) проактивно откриват често наблюдавани проблеми в Cisco IOS XE-базирания локален шлюз и генерира имейл, syslog или известие за терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърлите събрани данни към кутията, Cisco TAC за да ускорите времето за разрешаване.

Диагностичните подписи (DS) са XML файлове, които съдържат информация за събития за за действане на проблеми и действия за информиране, отстраняване на неизправности и отстраняване на проблема. Използвайте syslog съобщения, SNMP събития и чрез периодично наблюдение на конкретни изходи за показване на команди, за да дефинирате логиката за откриване на проблеми. Видовете действия включват:

  • Събиране на показване на командни изходи

  • Генериране на консолидиран регистрационен файл

  • Качване на файла на предоставено от потребителя мрежово местоположение като HTTPS, SCP, FTP сървър

Инженерите на TAC създават DS файлове и ги подписват цифрово за защита на целостта. Всеки DS файл има уникалния цифров идентификатор, зададен от системата. Инструментът за търсене на диагностични подписи (DSLT) е единствен източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.

Преди да започнете:

  • Не редактирайте файла DS, който изтегляте от DSL T. Файловете, които променяте, не успяват да инсталирате поради грешка при проверка на целостта.

  • Сървър за обикновен протокол за прехвърляне на поща (SMTP), който е необходим за локалния шлюз за изпращане на известия по имейл.

  • Уверете се, че локалният шлюз работи с IOS XE 17.6.1 или по-нова версия, ако искате да използвате защитения SMTP сървър за имейл известия.

Предпоставки

Локален шлюз, работещ с IOS XE 17.6.1 или по-нова версия

  1. Диагностичните подписи са активирани по подразбиране.

  2. Конфигурирайте защитения имейл сървър, който използвате за изпращане на проактивно известие, ако устройството работи с IOS XE 17.6.1 или по-нова версия.

    
configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. Конфигурирайте променливата на ds_emailсредата с имейл адреса на админи стратора, за да уведомите.

    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
end

Инсталирайте диагностични подписи за проактивен мониторинг

Мониторинг на високото използване на процесора

Този DS проследява 5-секундното използване на процесора, използвайки SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, той деактивира всички грешки и деинсталира всички диагностични подписи, които инсталирате в Локалния шлюз. Използвайте тези стъпки по-долу, за да инсталирате подписа.

  1. Уверете се, че сте активирали SNMP с помощта на командата show sn mp. Ако 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

  2. Изтеглете DS 64224, като използвате следните падащи опции в Инструмента за търсене на диагностични подписи:

    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или софтуер Catalyst 8000V Edge

    Продукт

    CUBE Ентърпрайз в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Високо използване на процесора с известяване по имейл

    Download DS 64224 from Diagnostic Signatures Lookup tool

  3. Копирайте файла DS XML в светкавицата Local Gateway.

    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    Следващият пример показва копирането на файла от FTP сървър към локалния шлюз.

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
[OK - 3571/4096 bytes] 
3571 bytes copied in 0.064 secs (55797 bytes/sec)

  4. Инсталирайте файла DS XML в локалния шлюз.

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. Използвайте командата show call-home diagnostic-signature, за да проверите дали подписът е инсталиран успешно. Колоната за състоя нието трябва да има стойност „регистрирана“. 

    
show call-home diagnostic-signature  
Current diagnostic-signature settings: 
 Diagnostic-signature: enabled 
 Profile: CiscoTAC-1 (status: ACTIVE) 
 Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
 Environment variable: 
           ds_email: username@gmail.com

    Изтеглете DSE:

    DS ID

    Име на DS

    Ревизиране

    Състояние

    Последна актуализация (GMT+ 00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-07 22:05:33

    Когато се задейства, този подпис деинсталира всички работещи DSs, включително самия себе си. Ако е необходимо, моля, инсталирайте отново DS 64224, за да продължите да наблюдавате високото използване на процесора на локалния шлюз.

Наблюдение на ненормални прекъсвания

Този DS използва SNMP анкета на всеки 10 минути, за да открие ненормално прекъсване на повик ването с SIP грешки 403, 488 и 503.  Ако увеличението на броя на грешките е по-голямо или рав но на 5 от последната анкета, то генерира syslog и известие по имейл. Моля , използвайте стъпките по-долу, за да инсталирате подписа.

  1. Уверете се, че SNMP е активиран с помощта на командата show sn mp. Ако 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

  2. Изтеглете DS 65221, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или софтуер Catalyst 8000V Edge

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Откриване на ненормално прекъсване на повикването SIP с имейл и из вестие на Syslog.

  3. Копирайте файла DS XML в локалния шлюз.

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. Инсталирайте файла DS XML в локалния шлюз. 

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. Използвайте командата show call-home diagnostic-signature, за да проверите дали под писът е инсталиран успешно. Колоната за състоя нието трябва да има стойност „регистрирана“.

Инсталирайте диагностични подписи, за да отстраните проблем

Можете също да използвате диагностични подписи (DS) за бързо разрешаване на проблеми. Cisco TACинженерите са напи сали няколко подписа, които позволяват необходимите грешки, които са необходими за отстраняване на даден проблем, откриване на възникването на проблема, събиране на правилния набор от диагностични данни и автоматично прехвърляне на данните към случая. Cisco TAC Това елиминира необходимостта от ръчна проверка за възникване на проблема и прави отстраняването на неизправности на периодични и преходни проблеми много по-лесно.

Можете да използвате инструмента за търсене на диагностични подписи, за да намерите приложимите подписи и да ги инсталирате, за да разрешите самостоятелно даден проблем или да инсталирате подписа, препоръчан от инженера TAC като част от ангажимента за поддръжка.

Ето пример за това как да намерите и инсталирате DS за откриване на възникването „% VOICE_IEC -3-GW: CCAPI: Вътрешна грешка (праг на скок на повикване): IEC = 1.1.181.1.29. 0" syslog и автоматизирайте събирането на диагностични данни, като използвате следните стъпки:

  1. Конфигурирайте друга променлива на DS средата ds_fsurl_prefixкато път на Cisco TAC файловия сървър (cxd.cisco.com), за да качите диагностичните данни. Потреб ителското име в пътя на файла е номерът на случая, а паролата е токенът за качване на файлове, който може да бъде извлечен от Support C ase Manager, както е показано по-долу. Токенът за качване на файлове може да бъде генериран в раздела При качени файлове на диспечера на казуси за поддръжка , ако е необходимо.

    The file upload token generated in the Attachments section of the Support Case Manager 
    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
end

    Пример: 

    
call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. Уверете се, че SNMP е активиран с помощта на командата show sn mp. Ако SNMP не е активиран, конфигурирайте командата snmp-server manager.

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. Препоръчваме да инсталирате High CPU monitoring DS 64224 като проактивна мярка за деактивиране на всички грешки и диагностични подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или софтуер Catalyst 8000V Edge

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Изпълнение

    Тип проблем

    Високо използване на процесора с известяване по имейл.

  4. Изтеглете DS 65095, като използвате следните опции в Инструмента за търсене на диагностични подписи:

    Име на полето

    Стойност на полето

    Платформа

    Cisco 4300, 4400 ISR серия или софтуер Catalyst 8000V Edge

    Продукт

    CUBE Enterprise в Webex Calling решение

    Обхват на проблема

    Сислогс

    Тип проблем

    Syslog -% VOICE_IEC -3-GW: CCAPI: Вътрешна грешка (праг на скока на повикване): IEC = 1.1.181.1.29.0

  5. Копирайте файловете DS XML в локалния шлюз.

    
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:

  6. Инсталирайте високотехнологичния процесор DS 64224 и след това XML файла DS 65095 в локалния шлюз. 

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success 
call-home diagnostic-signature load DS_65095.xml 
Load file DS_65095.xml success

  7. Проверете дали подписът е инсталиран успешно, като използвате показване на диагност ичния под пис за обаждане. Колоната за състоя нието трябва да има стойност „регистрирана“. 

    
show call-home diagnostic-signature  
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

    Изтеглени DSE:

    DS ID

    Име на 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

Проверете изпълнението на диагностичните сигнали

В следващата команда колоната „ Състояние“ на командата показва диагностичния подпис на обажданията се променя на „стар тиращ“, докато локалният шлюз изпълнява действието, дефинирано в подписа. Изходът на статистиката за диагностичния подпис за показване на обаждане е най-добрият начин да проверите дали диагностичният подпис открива събитие от интерес и е изпълнил действието. Колоната „Triggered/Max/Deinstall“ показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е дефинирано за откриване на събитие и дали подписът се деинсталира сам след откриване на максималния брой задействани събития. 

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

Изтеглени DSE:

DS ID

Име на 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 ID

Име на 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

Имейлът за уведомяване, който се изпраща по време на изпълнението на диагностичния подпис, съдържа ключова информация като тип проблем, подробности за устройството, версия на софтуера, изпълнена конфигурация и показване на командни изходи, които са подходящи за отстраняване на задад ения проблем.

Notification email that is sent during Diagnostic Signature execution

Деинсталирайте диагностични подписи

Използването на диагностичните подписи за целите на отстраняването на неизправности обикновено се дефинира за деинсталиране след откриване на някои проблеми. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на show call-home diagnostic-signature и изпълнете следната коман да:

call-home diagnostic-signature deinstall <DS ID>

Пример:

call-home diagnostic-signature deinstall 64224

Нови подписи се добавят периодично към инструмента за търсене на подписи за диагностика въ з основа на проблеми, наблюдавани при внедряването. Понастоящем TAC не поддържа заявки за създаване на нови персонализирани подписи.

Беше ли полезна тази статия?
Беше ли полезна тази статия?
ЦениПриложение WebexСрещиCallingИзпращане на съобщенияСподеляне на екрана
Webex SuiteCallingСрещиИзпращане на съобщенияSlidoУебинариEventsContact CenterCPaaSЗащитаControl Hub
СлушалкиКамериСерия на бюротоСерия RoomСерия BoardСерия PhoneАксесоари
ОбразованиеЗдравеопазванеДържавен секторФинансиСпорт и развлеченияFrontlineНестопански организацииСтартиращи компанииХибридна работа
ИзтеглянияПрисъединяване към тестова срещаОнлайн уроциИнтеграцииДостъпностПриобщаванеУебинари в реално време и при поискванеОбщност на WebexWebex разработчициНовини и иновации
CiscoСвържете се с поддръжкатаВръзка с отдел „Продажби“Webex BlogWebex – лидерство в мисленетоМагазин за стоки на WebexКариери
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Правила и условияДекларация за поверителностБисквиткиТърговски марки
©2026 Cisco и/или техните филиали. Всички права запазени.
Правила и условияДекларация за поверителностБисквиткиТърговски марки