Общ преглед

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

  • Локален шлюз

  • Локален шлюз за Webex за правителството

Ключови съображения

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

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

Процедурите съдържат връзки към справочна документация за команди, където можете да научите повече за отделните опции на командите. Всички връзки към команди водят към Webex Managed Gateways Command Reference, освен ако не е посочено друго (в този случай връзките към командите водят към Cisco IOS Voice Command Reference). Можете да получите достъп до всички тези ръководства в Cisco Unified Border Element Command References.

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

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

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

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

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

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

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

Ключови съображения

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

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

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

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

Локалният шлюз за Webex за правителството не поддържа следното:

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

  • Факс (T.38)

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

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

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

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

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

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

Преглед на дизайна

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

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

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

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

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

  • група от dial-peer: Дефинира изходящите dial-peers, използвани за по-нататъшно маршрутизиране на повиквания.

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

Пренасочване на повиквания from/to PSTN to/from Решение за конфигуриране на Webex Calling

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

Конфигурация за маршрутизиране на повиквания с набор от вътрешни точки за обратно избиране между Webex Calling и PSTN trunk линии

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

Диаграма на решението, показваща Unified Communications Manager, който осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания

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

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

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

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

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

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

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

  • Стъпка 4: Конфигурирайте Local Gateway със съществуваща Unified CM среда

    Или:

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

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

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

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

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

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

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

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

    • НТП

    • АКЛ

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

    • DNS

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

    • IP адреси

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

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

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

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 гарантира, че локалният шлюз разрешава връзка, ако името на хоста, конфигурирано в клиент 200, е включено в полетата CN или SAN на сертификата, получен от изходящия прокси сървър.

  1. Задайте tcp-retry count на 1000 (кратни на 5 ms) = 5 секунди).

  2. Командата timer connection establish ви позволява да настроите колко време 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

Инсталирайте пакета Cisco root CA, който включва сертификата IdenTrust Commercial Root CA1, използван от Webex Calling. Използвайте командата crypto pki trustpool import clean url, за да изтеглите root 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 канал, базиран на регистрация, за съществуващо местоположение в Control Hub. Запишете информацията за магистралата, която е предоставена след създаването ѝ. Детайлите, подчертани на илюстрацията, се използват в стъпките за конфигуриране в това ръководство. За повече информация вижте Конфигуриране на канали, групи маршрути и планове за набиране за Webex Calling.

Регистриран PSTN канал
2

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

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

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


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

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

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

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

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

режим border-element

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

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

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

групови статистики за медии

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

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

позволяват връзки sip към sip

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

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

зашеметявам

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

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

За повече информация вижте stun flowdata agent-id и stun flowdata shared-secret.

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

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

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

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

3

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

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


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

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

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

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

4

Конфигурирайте гласов клас stun-usage 100, за да активирате ICE на Webex Calling trunk.


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

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

употреба на зашеметяващ леден лайт

Използва се за активиране на ICE-Lite за всички dial-peers, насочени към Webex Calling, за да се позволи оптимизация на медийното съдържание, когато е възможно. За повече информация вижте употреба на зашеметяване в клас глас и употреба на зашеметяване в Ice Lite.

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

5

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


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

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

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

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

6

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


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

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

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

Дефинира шаблон, който да съответства на входяща SIP покана към входящ dial-peer от trunk. Когато въвеждате този шаблон, използвайте dtg=, последвано от Trunk OTG/DTG стойност, предоставена в Control Hub при създаването на trunk-а. За повече информация вижте voice class 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 "" "" 
 rule 50 response ANY sip-header To modify "" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

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

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

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

  • правило 80

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

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

8

Конфигуриране на Webex Calling trunk:

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

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

    
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 trunk. За повече информация вижте клиент на гласов клас.

    регистратор dns:98027369.us10.bcld.webex.com схема sips изтича 240 коефициент на опресняване 50 tcp tls

    Регистратор сървър за Local Gateway с регистрация настроен да се обновява на всеки две минути (50% от 240 секунди). За повече информация вижте регистратор.

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

    номер на идентификационни данни Dallas1171197921_LGU потребителско име Dallas1463285401_LGU парола 0 9Wt[M6ifY+ област BroadWorks

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

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

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

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

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

    няма идентификатор на отдалечена страна

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

    DNS на SIP сървъра: us25.sipconnect.bcld.webex.com

    Конфигурира целевия SIP сървър за trunk-а. Използвайте SRV адреса на Edge прокси, предоставен в Control Hub, когато сте създали вашия trunk.

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

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

    srtp-крипто 100

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

    TCP TLS за транспорт на сесия

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

    без обновяване на сесията

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

    URL отпивания

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

    преминаване през грешка

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

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

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

    asserted-id pay

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

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

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

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

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

    контрол на свързването интерфейс на източника GigabitEthernet0/0/1

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

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

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

    няма прехвърляемо съдържание custom-sdp

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

    sip-профили 100

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

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

    Webex Достъп до повиквания SBC. Въведете адреса на изходящия прокси сървър, предоставен в Control Hub, когато сте създали вашия trunk. За повече информация вижте изходящ прокси.

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

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

  2. Конфигурирайте Webex Calling trunk 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, вижте документа Първи стъпки с Local Gateway.

    шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

    SIP-сървър за целевия сървър на сесията

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

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

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

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

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

    използване на зашеметяващ метод за гласов клас 100

    Позволява локално генерираните STUN заявки на локалния шлюз да бъдат изпращани по договорения медиен път. STUN помага за отваряне на дупка в защитната стена за медиен трафик. За повече информация вижте voice-class stun-usage.

    без гласов клас sip localhost

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

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

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

    srtp

    Позволява SRTP за крака на повикване.

    без ВАД

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

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

  • Параметрите username, passwordи realm от конфигурацията credentials се използват в отговора.

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

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

Блок-схема на удостоверяване и регистрация на Webex Calling с локален шлюз

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

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

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

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

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

1

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


voice class uri 200 sip
  host ipv4:192.168.80.13

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

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

Дефинира шаблон, който да съответства на входяща SIP покана към входящ dial-peer от trunk. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте voice class 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 и дава смислено описание за лесно управление и отстраняване на проблеми. За повече информация вижте глас от dial-peer.

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

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

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

гласов клас sip asserted-id pai

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

контрол на свързването интерфейс на източника GigabitEthernet0/0/0

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

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

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

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

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

DTMF-реле rtp-nte

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

без вади

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

3

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

  1. Създайте групи от dial-peer, за да насочвате повиквания към Webex Calling или PSTN. Дефинирайте DPG 100 с изходящ dial-peer 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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  2. Приложете групи от dial-peer, за да маршрутизирате повиквания от Webex към PSTN и от PSTN към Webex: 

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

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

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

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

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

Конфигуриране на локален шлюз с TDM PSTN trunk

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

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

1

Конфигурацията на dial-peer с обратна връзка използва групи 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 чрез loopback dial-peers. По подобен начин, етикетът, добавен от 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 и дава смислено описание за лесно управление и отстраняване на проблеми. За повече информация вижте гласово свързване от точка за избиране.

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

порт 0/2/0:15

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

4

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

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

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

контрол на свързването интерфейс на източника GigabitEthernet0/0/0

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

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

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

DTMF-реле rtp-nte

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

кодек g711alaw

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

без ВАД

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

5

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

  1. Създайте групи от dial-peer, за да маршрутизирате повиквания между PSTN и Webex trunk линиите, чрез обратната връзка.

    
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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  2. Прилагане на групи от dial-peer за маршрутизиране на повиквания.

    
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

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

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

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

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

Въведете информация за профила за сигурност на SIP trunk
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 trunk, използвайки един или повече шаблони, които описват изходните адреси и номера на порта. Регулярните изрази могат да се използват за дефиниране на съвпадащи модели, ако е необходимо.

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

2

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

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


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

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

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

ip хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.моятдомейн.com

_sip._udp.pstntocucm.io: Име на записа на SRV ресурс

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

1: Тегло на записа на ресурса SRV

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

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

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

IP адрес на хост ucmsub5.mydomain.com 192.168.80.65

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

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

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

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

3

Конфигурирайте следните dial-peers:

  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

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

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

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

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

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

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

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

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

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

    контрол на свързването source-interface GigabitEthernet0/0/0

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

    свързващи медии source-interface GigabitEthernet0/0/0

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

    DTMF-реле rtp-nte

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

    без ВАД

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

  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

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

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

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

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

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

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

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

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

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

    контрол на свързването source-interface GigabitEthernet0/0/0

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

    свързващи медии source-interface GigabitEthernet0/0/0

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

    DTMF-реле rtp-nte

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

    без ВАД

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

4

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

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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  3. Приложете групи от dial-peer, за да маршрутизирате повиквания от Webex към Unified CM и от Unified CM към Webex: 

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

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

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

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

  4. Приложете групи от dial-peer, за да маршрутизирате повиквания от PSTN към Unified CM и от Unified CM към PSTN:

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

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

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

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

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

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

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

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

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

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

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

  • Прост протокол за прехвърляне на поща (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 :@ priority 1 secure tls 
end

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

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email  
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% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които са инсталирани в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.

  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 предприятие в Webex повикване решение

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

    Производителност

    Тип на проблема

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

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

    LocalGateway# copy ftp://username:password@/DS_64224.xml bootflash:

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

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

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

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

  5. Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност. 

    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

    Изтегляне на DSes:

    Идентификационен номер на DS

    Име на DS

    Преразглеждане

    Статус

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

    64224

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-07 22:05:33

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

Мониторинг SIP багажник регистрация

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

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

    Име на полето

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

    Платформа

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

    Продукт

    CUBE предприятие в Webex повикване решение

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

    СИП-СИП

    Тип на проблема

    SIP Trunk Отписване на регистрацията с известие по имейл.

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

    copy ftp://username:password@/DS_64117.xml bootflash:

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

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

  4. Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.

Мониторинг на абнормни прекъсвания на повикването

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

  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 предприятие в Webex повикване решение

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

    Производителност

    Тип на проблема

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

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

    copy ftp://username:password@/DS_65221.xml bootflash:

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

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

  5. Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност.

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

Използвайте диагностични подписи (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 в следната команда. Токенът за качване на файл може да бъде генериран в секцията Attachments на Support Case Manager, ако е необходимо. 

    configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com"  
end

    Пример: 

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

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

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

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

    Име на полето

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

    Платформа

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

    Продукт

    CUBE предприятие в Webex повикване решение

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

    Производителност

    Тип на проблема

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

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

    Име на полето

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

    Платформа

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

    Продукт

    CUBE предприятие в Webex повикване решение

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

    Сислогс

    Тип на проблема

    Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0

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

    copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

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

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

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

    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

    Изтеглени DSes:

    Идентификационен номер на DS

    Име на DS

    Преразглеждане

    Статус

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

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-08

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    Регистриран

    2020-11-08

Проверка на изпълнението на диагностичните подписи

В следната команда колоната „Статус“ на командата show call-home diagnostic-signature се променя на „изпълнява се“, докато локалният шлюз изпълнява действието, дефинирано в сигнатурата. Изходът от статистиката за диагностичния подпис на повикването у дома е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития. 

show call-home 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

Изтеглени DSes:

Идентификационен номер на DS

Име на DS

Преразглеждане

Статус

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

64224

DS_LGW_CPU_MON75

0.0.10

Регистриран

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

Изпълнява се

2020-11-08 00:12:53

Показване на статистика за диагностика-подпис на повикване-дома

Идентификационен номер на DS

Име на DS

Задействано/Max/Deinstall

Средно време за изпълнение (секунди)

Максимално време за изпълнение (секунди)

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

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

Деинсталиране на диагностични подписи

Използвайте диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинират като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на командата show call-home diagnostic-signature и изпълнете следната команда:

call-home diagnostic-signature deinstall

Пример:

call-home diagnostic-signature deinstall 64224

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

Управлявайте и валидирайте Cisco IOS XE Gateways чрез Control Hub

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

За повече информация вижте следното:

Преглед на дизайна

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

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

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

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

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

  • група от dial-peer: Дефинира изходящите dial-peers, използвани за по-нататъшно маршрутизиране на повиквания.

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

Пренасочване на повиквания from/to PSTN to/from Решение за конфигуриране на Webex Calling

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

Диаграма на решението, показваща Unified Communications Manager, който осигурява централизирано маршрутизиране и обработка на всички PSTN и Webex Calling повиквания

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

Имената на хостовете, IP адресите и интерфейсите, използвани в конфигурации на локален шлюз, базирани на сертификати

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

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

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

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

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

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

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

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

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

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

    • НТП

    • АКЛ

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

    • DNS

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

    • IP адреси

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

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

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

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

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

      • Ако конфигуриран транк в Control Hub на вашата организация има cube1.lgw.com:5061 като FQDN на локалния шлюз, тогава CN или SAN в сертификата на рутера трябва да съдържа cube1.lgw.com.

      • Ако конфигуриран транк в Control Hub на вашата организация има lgws.lgw.com като SRV адрес на локалния(ите) шлюз(ове), достъпен(и) от транка, тогава CN или SAN в сертификата на рутера трябва да съдържа lgws.lgw.com. Записите, на които SRV адресът решава (CNAME, A Record или IP адрес), са незадължителни в SAN.

      • Независимо дали използвате FQDN или SRV за магистралата, адресът за контакт за всички нови SIP диалози от вашия локален шлюз трябва да използва името, конфигурирано в Control Hub.

    • Уверете се, че сертификатите са подписани за използване от клиента и сървъра.

  • Качете пакета на Cisco root CA към локалния шлюз. Този пакет включва коренния сертификат на 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

Създайте точка за доверие за криптиране със сертификат за вашия домейн, подписан от поддържан сертифициращ орган (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

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

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

    • име-на-субект: За валидиране на повиквания от локален шлюз, Webex трябва да съпостави FQDN в заглавките на SIP контакта с тези, включени или в атрибута Subject Common Name (CN), или в полето Subject Alternative Name (SAN) на SBC сертификата. Полето за тема трябва да съдържа поне един атрибут CN и може да включва и други атрибути, ако е необходимо. За повече информация вижте име-на-субект.

    • Alternativna-ime-na-tema: Полето „Алтернативно име на субекта“ (SAN) на SBC сертификата може да включва списък с допълнителни FQDN имена. Webex проверява този списък, за да валидира заглавката на SIP контакта в съобщенията от локалния шлюз, ако атрибутът „Subject CN“ на сертификата не съвпада.

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

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

    crypto pki enroll LGW_CERT

4

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


crypto pki authenticate LGW_CERT

5

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


crypto pki import LGW_CERT certificate

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 url, за да изтеглите root 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, базиран на сертификат, trunk
1

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

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

Създадена е PSTN магистрала, базирана на CUBE сертификат
2

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


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

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


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

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

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

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

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

режим border-element

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

позволяват връзки sip към sip

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

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

зашеметявам

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

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

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

За повече информация вижте stun flowdata agent-idи stun flowdata shared-secret.

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

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

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

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

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

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

3

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

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


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

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

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

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

4

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


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

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

употреба на зашеметяващ леден лайт

Използва се за активиране на ICE-Lite за всички dial-peers, насочени към Webex Calling, за да се позволи оптимизация на медийното съдържание, когато е възможно. За повече информация вижте употреба на зашеметяване в клас глас и употреба на зашеметяване в Ice Lite.

Командатаstun usage firewall-traversal flowdataе необходима само при разполагане на вашия локален шлюз зад NAT.

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

5

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


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

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

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

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

6

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


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

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

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

Указва GCM като набор от шифри, предлагани от CUBE. Задължително е да конфигурирате GCM шифри за Local Gateway за Webex for Government.

7

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


voice class uri 100 sip
 pattern cube1.lgw.com

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

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

Дефинира шаблон, който да съответства на входяща SIP покана към входящ dial-peer от trunk. Когато въвеждате този шаблон, използвайте FQDN или SRV на магистралата, конфигурирани в Control Hub за магистралата.

Използвайте адреса на Webex Calling edge, базиран на SRV, на локалния шлюз, когато конфигурирате trunk-ове, базирани на сертификати.

8

Конфигурирайте профили за манипулиране на SIP съобщения. Ако вашият шлюз е конфигуриран с публичен 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 да удостоверява съобщения от вашия локален шлюз, заглавката „Contact“ в SIP заявките и отговорите трябва да съдържа стойността, предоставена за trunk-а в Control Hub-а. Това ще бъде или FQDN на един хост, или SRV името, използвано за клъстер от устройства.

9

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

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

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

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

правила 10 и 20

За да позволите на Webex да удостоверява съобщения от вашия локален шлюз, заглавката „Контакт“ в SIP заявките и отговорите трябва да съдържа стойността, предоставена за trunk-а в Control Hub. Това ще бъде или 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 опции за поддържане на активността с профил за модификация на заглавката.


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "

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

гласов клас sip-options-keepalive 100

Конфигурира профил за поддържане на активност и влиза в режим на конфигуриране на гласов клас. Можете да конфигурирате времето (в секунди), в което SIP Out of Dialog Options Ping се изпраща до dial-target, когато heartbeat връзката към крайната точка е в състояние UP (Нагоре) или Down (Надолу).

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

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

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

11

Конфигуриране на Webex Calling trunk:

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

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

    
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. За повече информация вижте remote-party-id.

    DNS на SIP сървъра: us25.sipconnect.bcld.webex.com

    Конфигурира целевия SIP сървър за trunk-а. Използвайте SRV адреса на Edge прокси, предоставен в Control Hub, когато сте създали вашия trunk.

    srtp-крипто 100

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

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

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

    TCP TLS за транспорт на сесия

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

    без обновяване на сесията

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

    преминаване през грешка

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

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

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

    asserted-id pay

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

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

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

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

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

    контрол на свързването интерфейс на източника GigabitEthernet0/0/1

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

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

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

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

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

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

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

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

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

  2. Конфигурирайте Webex Calling trunk 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 и дава смислено описание за лесно управление и отстраняване на неизправности. За повече информация вижте гласово свързване от точка за избиране.

    шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

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

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

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

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

    използване на зашеметяващ метод за гласов клас 100

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

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

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

    опции за sip на гласовия клас - профил за поддържане на жива активност 100

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

    srtp

    Позволява SRTP за крака на повикване.

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

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

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

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

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

1

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


voice class uri 200 sip
  host ipv4:192.168.80.13

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

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

Дефинира шаблон, който да съответства на входяща SIP покана към входящ dial-peer от trunk. Когато въвеждате този шаблон, използвайте IP адреса на вашия IP PSTN шлюз. За повече информация вижте voice class 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 и дава смислено описание за лесно управление и отстраняване на проблеми. За повече информация вижте глас от dial-peer.

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

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

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

гласов клас sip asserted-id pai

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

контрол на свързването интерфейс на източника GigabitEthernet0/0/0

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

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

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

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

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

DTMF-реле rtp-nte

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

без ВАД

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

3

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

  1. Създайте групи от dial-peer, за да насочвате повиквания към Webex Calling или PSTN. Дефинирайте DPG 100 с изходящ dial-peer 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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  2. Приложете групи от dial-peer, за да маршрутизирате повиквания от Webex към PSTN и от PSTN към Webex: 

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

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

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

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

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

Конфигуриране на локален шлюз с TDM PSTN trunk

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

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

1

Конфигурацията на dial-peer с обратна връзка използва групи 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 чрез loopback dial-peers. По подобен начин, етикетът, добавен от 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 и дава смислено описание за лесно управление и отстраняване на проблеми. За повече информация вижте гласово свързване от точка за избиране.

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

порт 0/2/0:15

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

4

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

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

шаблон-на-дестинация ЛОШО.ЛОШО

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

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

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

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

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

контрол на свързването интерфейс на източника GigabitEthernet0/0/0

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

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

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

DTMF-реле rtp-nte

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

кодек g711alaw

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

без ВАД

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

5

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

  1. Създайте групи от dial-peer, за да маршрутизирате повиквания между PSTN и Webex trunk линиите, чрез обратната връзка.

    
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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  2. Прилагане на групи от dial-peer за маршрутизиране на повиквания.

    
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

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

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

Конфигурацията за PSTN-Webex Calling в предишните раздели може да бъде променена, за да включва допълнителни канали към клъстер 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 trunk, използвайки един или повече шаблони, които описват изходните адреси и номера на порта. Регулярните изрази могат да се използват за дефиниране на съвпадащи модели, ако е необходимо.

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

2

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

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


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

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

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

ip хост _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.моятдомейн.com

_sip._udp.pstntocucm.io: Име на записа на SRV ресурс

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

1: Тегло на записа на ресурса SRV

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

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

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

IP адрес на хост ucmsub5.mydomain.com 192.168.80.65

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

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

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

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

3

Конфигурирайте следните dial-peers:

  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

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

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

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

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

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

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

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

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

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

    контрол на свързването source-interface GigabitEthernet0/0/0

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

    свързващи медии source-interface GigabitEthernet0/0/0

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

    DTMF-реле rtp-nte

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

    без ВАД

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

  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

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

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

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

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

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

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

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

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

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

    контрол на свързването source-interface GigabitEthernet0/0/0

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

    свързващи медии source-interface GigabitEthernet0/0/0

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

    DTMF-реле rtp-nte

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

    без ВАД

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

4

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

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

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

    dial-peer 100

    Свързва изходящ dial-peer с група dial-peer. За повече информация вижте voice-class dpg.

  3. Приложете групи от dial-peer, за да маршрутизирате повиквания от Webex към Unified CM и от Unified CM към Webex: 

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

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

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

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

  4. Приложете групи от dial-peer, за да маршрутизирате повиквания от 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 локален портал и генерират известие за имейл, сислог или терминално съобщение за събитието. Можете също така да инсталирате DS, за да автоматизирате събирането на диагностични данни и да прехвърляте събраните данни към случая Cisco TAC, за да ускорите времето за разделителна способност.

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

  • Събиране на командни изходи

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

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

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

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

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

  • Прост протокол за прехвърляне на поща (SMTP) сървър, от който се нуждаете, за да може местният портал да изпраща известия по имейл.

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

Предварителни изисквания

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

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

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

    
configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

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

    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_email  
end

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

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

Този DS проследява 5-секундното използване на процесора с помощта на SNMP OID 1.3.6.1.4.1.9.2.1.56. Когато използването достигне 75% или повече, то деактивира всички дебъгвания и деинсталира всички диагностични подписи, които инсталирате в Local Gateway. Използвайте тези стъпки по-долу, за да инсталирате подписа.

  1. Уверете се, че сте активирали SNMP с помощта на командното шоу 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, като използвате следните опции за падане в инструментаза справка за диагностични подписи:

    copy ftp://username:password@/DS_64224.xml bootflash:

    Име на полето

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

    Платформа

    Софтуер Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge

    Продукт

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

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

    Производителност

    Тип на проблема

    Високо cpu utilization с имейл известие

    Изтеглете DS 64224 от инструмента за търсене на диагностични сигнатури

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

    copy ftp://username:password@/DS_64224.xml bootflash:

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

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

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

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

  5. Използвайте командата за диагностика-подпис на повикване-дом, за да проверите дали подписът е успешно инсталиран. Колоната за състоянието трябва да има "регистрирана" стойност. 

    
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

    Изтегляне на DSes:

    Идентификационен номер на DS

    Име на DS

    Преразглеждане

    Статус

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

    64224

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-07 22:05:33

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

Мониторинг на необичайни прекъсвания на повикване

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

  1. Уверете се, че SNMP е активиран с помощта на командното шоу 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 серия или Catalyst 8000V Edge

    Продукт

    CUBE предприятие в Webex повикване решение

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

    Производителност

    Тип на проблема

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

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

    copy ftp://username:password@/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 Case Manager, както е показано по-долу. Токенът за качване на файл може да бъде генериран в секцията Attachments на Support Case Manager, ако е необходимо.

    Токенът за качване на файл, генериран в секцията „Прикачени файлове“ на мениджъра на заявки за поддръжка
    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com"  
end

    Пример: 

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

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

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

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

    Име на полето

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

    Платформа

    Софтуер Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge

    Продукт

    CUBE предприятие в Webex повикване решение

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

    Производителност

    Тип на проблема

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

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

    Име на полето

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

    Платформа

    Софтуер Cisco 4300, 4400 ISR серия или Catalyst 8000V Edge

    Продукт

    CUBE предприятие в Webex повикване решение

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

    Сислогс

    Тип на проблема

    Сислог - % ГЛАС_IEC-3-GW: CCAPI: Вътрешна грешка (праг на скока на повикването): IEC=1.1.181.1.29.0

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

    
copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/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. Колоната за състоянието трябва да има "регистрирана" стойност. 

    
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

    Изтеглени DSes:

    Идентификационен номер на DS

    Име на DS

    Преразглеждане

    Статус

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

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    Регистриран

    2020-11-08:00:07:45

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    Регистриран

    2020-11-08:00:12:53

Проверка на изпълнението на диагностичните подписи

В следващата команда колоната "Статус" на командата показва промени в диагностичния подпис на повикване-дом на "бягане", докато местният портал изпълнява действието, определено в подписа. Изходът от статистиката за диагностичния подпис на повикване-дом е най-добрият начин да се провери дали диагностичният подпис открива събитие от интерес и изпълнява действието. Колоната "Задействан/Макс/Деинсталиране" показва колко пъти даденият подпис е задействал събитие, максималния брой пъти, когато е определен за откриване на събитие и дали подписът се деинсталира след откриване на максималния брой задействани събития. 

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

Изтеглени DSes:

Идентификационен номер на DS

Име на DS

Преразглеждане

Статус

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

64224

DS_LGW_CPU_MON75

0.0.10

Регистриран

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

Изпълнява се

2020-11-08 00:12:53

Показване на статистика за диагностика-подпис на повикване-дома

Идентификационен номер на DS

Име на DS

Задействано/Max/Deinstall

Средно време за изпълнение (секунди)

Максимално време за изпълнение (секунди)
64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

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

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

Деинсталиране на диагностични подписи

Използването на диагностичните подписи за целите на отстраняване на неизправности обикновено се дефинира като деинсталиране след откриване на някои проблемни събития. Ако искате да деинсталирате подпис ръчно, извлечете DS ID от изхода на диагностичния подпис на повикване-дом и изпълнете следната команда:

call-home diagnostic-signature deinstall

Пример:

call-home diagnostic-signature deinstall 64224

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