Използвайте този поток от задачи, за да конфигурирате локален шлюз за вашия Webex Calling багажник. Стъпките, които следват, се извършват на самия локален шлюз с помощта на командния ред. Багажникът между местния шлюз и Webex Calling винаги е обезпечен с помощта на SIP TLS транспорт и SRTP за медии между местния шлюз и Webex Calling Access SBC.

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

  • Разберете помещенията базирани PSTN (локален шлюз) изисквания за Webex Calling.

  • Създайте багажник в Контролния център и го присвоете на желаното местоположение.

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

  Команда или действие Предназначение
1

Съпоставяне на параметри между контролния център и унифицирания граничен елемент на Cisco

Използвайте тази таблица като препратка за параметрите, които идват от Контролния център и където те нанасят върху локалния шлюз.

2

Извършване на конфигурация на референтна платформа

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

3

Регистрирайте локален шлюз към Webex извикване

4

Изберете такъв, в зависимост от разполагането ви:

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

  • Опцията за разполагане на локален шлюз без локален IP PBX. Местният шлюз и IP PSTN CUBE са корезидент.

  • Опцията за разполагане на локален шлюз в рамките на съществуваща обкръжение на Унифициран CM. Местният шлюз и IP PSTN CUBE са корезидент.

Таблица 1. Съпоставяне на параметри между контролния център и локалния шлюз

Control Hub

Локален шлюз

Домейн на регистратора:

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

example.com

Регистратор

example.com

Група за многосигнална връзка OTG/DTG

профили на глътки:

правило <rule-number> искане ВСЯКО глътка-заглавка

От модифициране на ">" ";otg=otgDtgId>"

Линия/порт

user@example.com

номер: потребител

Изходящо прокси

изходящ прокси (DNS име – SRV на SBC за достъп)

Потребителско име в SIP

потребителско име

Парола в SIP

парола

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

  • Гарантирайте, че конфигурацията на базовата платформа като NTPs, ACLs, разрешаване на пароли, първична парола, IP маршрутизиране, IP адреси и т.н. са конфигурирани според правилата и процедурите на вашата организация.

  • Минимално поддържано освобождаване на IOS-XE 16.12 или IOS-XE 17.3 е необходимо за всички разполагания на LGW.

1

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

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
 ip address 192.168.43.197 255.255.255.0
2

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


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes
3

Конфигурирайте IP Name Server, за да разрешите DNS справка и да гарантирате, че тя е достъпна, като го пинг:


LocalGateway#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#ip name-server 8.8.8.8
LocalGateway(config)#end
4

Разрешаване на TLS 1.2 изключителност и контейнер по подразбиране Trustpoint:

  1. Създаване на контейнер PKI Trustpoint и да го наречете sampleTP

  2. Присвояване на точката на доверие като точка по подразбиране сигнализация под sip-ua

  3. cn-san-валидиран сървър е необходим, за да се гарантира, че локалният шлюз установява връзката само ако изходящ прокси конфигуриран на наемателя 200 (описано по-късно) съвпадения с CN-SAN списък, получени от сървъра.

  4. Крипто точката на доверие е необходима, за да работи TLS, въпреки че не е необходим сертификат за локален клиент (например mTLS), за да бъде зададена връзката.

  5. Деактивирайте TLS v1.0 и v1.1, като разрешите изключителността v1.2.

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

  7. (IOS-XE 17.3.2 и по-нови) Задаване на таймери връзка установи tls <wait-timer in="" sec="">. Обхватът е между 5 и 20 секунди, а по подразбиране е 20 секунди. (LGW отнема 20 секунди, за да открие неизправността на TLS връзката, преди да се опита да установи връзка със следващия наличен Webex Calling Access SBC. Този CLI позволява на администратора да промени стойността, за да побере мрежовите условия и да открие откази на връзка с Access SBC много по-бързо).


LocalGateway#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#
LocalGateway(config)#crypto pki trustpoint sampleTP
LocalGateway(ca-trustpoint)# revocation-check crl
LocalGateway(ca-trustpoint)#exit

LocalGateway(config)#sip-ua
LocalGateway(config-sip-ua)# crypto signaling default trustpoint sampleTP cn-san-validate server

LocalGateway(config-sip-ua)# transport tcp tls v1.2
LocalGateway(config-sip-ua)# tcp-retry 1000
LocalGateway(config-sip-ua)#end
5

Актуализиране на локалния шлюз Trustpool:

По подразбиране trustpool сноп не включва "DigiCert Root CA" или "IdenTrust Търговски" сертификати, необходими за валидиране на сертификата на сървъра страна по време на TLS връзка установяване на Webex Calling.

Пакетът trustpool трябва да се актуализира, като изтеглите най-новия "Cisco Trusted Core Root Bundle" от http://www.cisco.com/security/pki/.

  1. Проверете дали съществуват сертификатите DigiCert Room CA и IdenTrust Commercial:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
  2. Ако не съществува, актуализирайте по следния начин:

    
    LocalGateway#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    LocalGateway(config)#crypto pki trustpool import clean url 
    http://www.cisco.com/security/pki/trs/ios_core.p7b
    Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b
    Loading http://www.cisco.com/security/pki/trs/ios_core.p7b 
    % PEM files import succeeded.
    LocalGateway(config)#end
    
  1. Провери:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    
    LocalGateway#show crypto pki trustpool | include IdenTrust Commercial
    cn=IdenTrust Commercial Root CA 1
    cn=IdenTrust Commercial Root CA 1

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

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

1

Въведете тези команди, за да включите локалното приложение за шлюз (вижте референтната информация за порт за Cisco Webex Calling за най-новите IP подмрежи, които трябва да бъдат добавени към списъка с гаранти):

LocalGateway#configure terminal
LocalGateway(config)#voice service voip
LocalGateway(conf-voi-serv)#ip address trusted list
LocalGateway(cfg-iptrust-list)#ipv4 x.x.x.x y.y.y.y
LocalGateway(cfg-iptrust-list)#exit
LocalGateway(conf-voi-serv)#allow-connections sip to sip
LocalGateway(conf-voi-serv)#media statistics
LocalGateway(conf-voi-serv)#media bulk-stats
LocalGateway(conf-voi-serv)#no supplementary-service sip refer
LocalGateway(conf-voi-serv)#no supplementary-service sip handle-replaces
LocalGateway(conf-voi-serv)# fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

LocalGateway(conf-serv-stun)#stun
LocalGateway(conf-serv-stun)#stun flowdata agent-id 1 boot-count 4
LocalGateway(conf-serv-stun)#stun flowdata shared-secret 0 Password123$

LocalGateway(conf-serv-stun)#sip

   LocalGateway(conf-serv-sip)#g729 annexb-all
   LocalGateway(conf-serv-sip)#early-offer forced
   LocalGateway(conf-serv-sip)#end

Обяснение на командите:

Предотвратяване на ТОЛ-измами
Device(config)# voice service voip
Device(config-voi-serv)# ip address trusted list
Device(cfg-iptrust-list)# ipv4 x.x.x.x y.y.y.y
  • Изрично дава възможност на източника IP адреси на обекти, от които местният шлюз очаква законни VoIP разговори, като Webex Calling връстници, Единни CM възли, IP PSTN.

  • По подразбиране LGW блокира всички входящи VoIP настройки за обаждания от IP адреси не в надеждния си списък. IP адреси от dial-peers с "сесия цел IP" или Server Group са надеждни по подразбиране и не е необходимо да се попълват тук.

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


     

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

  • Други IP адреси може да се наложи да бъдат конфигурирани на други интерфейси; например може да се наложи вашите Унифицирани CM адреси да бъдат добавени към вътрешно насочените интерфейси.

  • IP адресите трябва да съответстват на ПР на хостовете outbound-proxy решава на в наемател 200

  • Вижте https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.html за повече информация.

Мултимедия
voice service voip
 media statistics 
 media bulk-stats 
  • Media Statistics дава възможност за мониторинг на медиите на локалния шлюз.

  • Медийни насипни статистики дава възможност на контролния самолет да анкетира самолета за данни за насипни разговори статистика.

Основна функционалност sIP-to-SIP
allow-connections sip to sip
Допълнителни услуги
 no supplementary-service sip refer
 no supplementary-service sip handle-replaces

Забранява REFER и замества ИД на диалога в Замества заглавката с ИД на партньорската диалогова кутия.

Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html#wp2876138889 за повече информация.

Протокол за факс
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

Разрешава T.38 за факс транспорт, макар че fac трафикът няма да бъде шифрован.

Разрешаване на глобално зашеметяване
stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
  • Когато едно обаждане се препраща обратно към потребител на Webex Calling (например, както призованите, така и повикващите страни са абонати на Webex Calling и имат носителите, закотвени в Webex Calling SBC), носителят не може да тече към локалния шлюз, тъй като щифтът не е отворен.

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

  • STUN парола е предпоставка за местния шлюз за изпращане на STUN съобщения навън. IOS/IOS-XE базирани защитни стени могат да бъдат конфигурирани да проверяват за тази парола и да отварят щифтовете динамично (например без изрични правила за въвеждане). Но за случая за разполагане на локалния шлюз защитната стена е статично конфигурирана да отваря щифтове в и навън въз основа на подмятанията Webex Calling SBC. Като такава защитната стена трябва просто да третира това като всеки входящ UDP пакет, който ще задейства отвора на щифтовете, без изрично да разглежда съдържанието на пакетите.

G729
sip
  g729 annexb-all

Позволява всички варианти на G729.

SIP
early-offer forced

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

2

Конфигуриране на "SIP профил 200".

LocalGateway(config)# voice class sip-profiles 200
LocalGateway (config-class)# rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1"
LocalGateway (config-class)# rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
LocalGateway (config-class)# rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 20 request ANY sip-header From modify ">" ";otg=hussain2572_lgu>"
LocalGateway (config-class)# rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

Тези правила са

Обяснение на командите:

  • правило 9 гарантира, че заглавката е изброена като “SIP-Req-URI” а не “SIP-Req-URL”

    Това преобразува между SIP URIs и SIP URL адресите, защото Webex Calling не поддържа SIP URIs в съобщенията за заявка/отговор, а се нуждае от тях за SRV заявки, напр. _sips._tcp.<outbound-proxy>.
  • правило 20 модифицира от заглавката, за да включи параметъра OTG/DTG на Trunk Group от Контролния център, за да идентифицира еднозначно LGW сайт в рамките на предприятие.

  • Този SIP профил ще бъде приложен към гласов клас наемател 200 (обсъдено по-късно) за целия трафик пред Webex Calling.

3

Конфигуриране на codec профил, STUN дефиниция и SRTP Crypto suite.

LocalGateway(config)# voice class codec 99
LocalGateway(config-class)# codec preference 1 g711ulaw
LocalGateway(config-class)# codec preference 2 g711alaw 
LocalGateway(config-class)# exit
LocalGateway(config)# voice class srtp-crypto 200
LocalGateway(config-class)# crypto 1 AES_CM_128_HMAC_SHA1_80
LocalGateway(config-class)# exit
LocalGateway(config)# voice class stun-usage 200
LocalGateway(config-class)# stun usage firewall-traversal flowdata
LocalGateway(config-class)# stun usage ice lite
LocalGateway(config-class)# exit

Обяснение на командите:

  • Гласов клас кодец 99: Позволява както g711 (mu, така и a-law) кодеци за сесии. Прилага се върху всички dial-връстници.

  • Гласов клас srtp-crypto 200: Задава SHA1_80 като единственият SRTP шифър-суит, който се предлага от местния шлюз в SDP в оферта и отговор. Webex Calling поддържа само SHA1_80.

  • Ще се прилага за глас клас наемател 200 (обсъдено по-късно) пред Webex Calling.

  • Гласов клас зашеметяване-използване 200: Дефинира използването на STUN. Прилага се за всички Webex Calling-facing (2XX етикет) dial-peers, за да се избегне никакъв начин аудио, когато единни CM телефон препраща повикването към друг Webex Calling телефон.


 

В случаите, когато носителят е закотвен в ITSP SBC и Локалният шлюз стои зад NAT и чака входящия медиен поток от ITSP, тази команда може да се приложи на ITSP, изправена пред dial-peers.


 

Зашеметяване използване леденият лит е необходим за потоците на обажданията, които използват оптимизацията на медийния път.

4

Параметри на центъра за управление на картата към конфигурацията на локалния шлюз:

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

След това наемател 200 се прилага за всички Webex Calling, изправени пред dial-peers (2xx етикет) в рамките на локалната конфигурация на шлюза. Функцията за гласов клас наемател дава възможност за групиране и конфигуриране на SIP багажник параметри иначе направено под гласова услуга voip и sip-ua. Когато даден наемател е конфигуриран и приложен под комут-партньорска, конфигурациите на IOS-XE се прилагат в следния ред на предпочитание:

  • Dial-peer конфигурация

  • Конфигурация на наемателя

  • Глобална конфигурация (гласова услуга voip / sip-ua)

5

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


 

Командният ред и параметрите по-долу са само примери. Трябва да използвате параметрите за собствено разполагане.

LocalGateway(config)#voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls 
  url sips 
  error-passthru
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 200 
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com  
  privacy-policy passthru

Обяснение на командите:

voice class tenant 200

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

registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

Регистратор сървър за локален шлюз с регистрацията, зададена за обновяване на всеки две минути (50% от 240 секунди). За повече информация https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1687622014вж.

credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks

Идентификационни данни за Trunk Registration предизвикателство. За повече информация https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp3153621104вж.

authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks
authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

Предизвикателство за удостоверяване на повиквания. За повече информация https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462вж.

no remote-party-id

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

sip-server dns:40462196.cisco-bcld.com
Webex Повикващи сървъри. За повече информация вж. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462
connection-reuse

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

srtp-crypto 200

Указва SHA1_80, както е определено в voice class srtp-crypto 200.

session transport tcp tls
Задава транспорт до TLS
url sips

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

error-passthru

SIP грешка отговор pass-thru функционалност

asserted-id pai

Включва обработката на PAI в местния шлюз.

bind control source-interface GigabitEthernet0/0/1

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

bind media source-interface GigabitEthernet0/0/1

Интерфейс на източника на медии, изправен пред Webex Calling.

no pass-thru content custom-sdp

Команда по подразбиране под наемател.

sip-profiles 200

Променя СВПС в SIP и променя Line/Port за ПОКАНИ и РЕГИСТРИРАЙТЕ съобщенията, както е определено в voice class sip-profiles 200.

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

Уебекс повикващия достъп SBC. За повече информация https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-o1.html#wp3297755699вж.

privacy-policy passthru

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

След като наемател 200 е дефиниран в рамките на местния шлюз и е конфигуриран SIP VoIP dial-peer, след това шлюзът инициира TLS връзка към Webex Calling, в който момент Достъпът SBC представя сертификата си на местния шлюз. Локалният шлюз валидира сертификата Webex Calling Access SBC с помощта на ca корен пакет актуализира по-рано. Установена е постоянна TLS сесия между местния шлюз и Webex Calling Access SBC. След това Местният шлюз изпраща РЕГИСТЪР до SBC за достъп, който е оспорено. Регистрация AOR е number@domain. Номерът е взет от идентификационни данни "номер" параметър и домейн от "регистратор DNS:<fqdn>". Когато Регистрацията е оспорена, потребителското име, паролата и царството параметри от идентификационни данни се използват за изграждане на заглавката и sip-профил 200 конвертира SIPS URL обратно към SIP. Регистрацията е успешна, след като 200 OK се получи от Access SBC.

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

  1. Гласов клас наематели—Първо ще създадем допълнителни наематели за dial-peers, изправени пред ITSP, подобни на наемател 200, които създадохме за Webex Calling, изправени пред dial-peers.

  2. URIs за гласов клас—Модели, определящи ХОСТ IP адреси/портове за различни стволове, прекратяващи се на Local Gateway: Webex Призоваване към LGW; и PSTN SIP багажника прекратяване на LGW.

  3. Изходящи връстници за набиране—За маршрутиране на изходящи кол крака от LGW до ITSP SIP багажника и Webex Calling.

  4. Гласов клас DPG—Целеви изходящи dial-peers, извиквани от входящ dial-peer.

  5. Входящи dial-peers—За да приемете входящите кол крака от ITSP и Webex Calling.

Конфигурацията в този раздел може да се използва или за хоствана от партньора локална настройка на шлюз, както е показано по-долу, или за шлюз за локален клиентски сайт.

1

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

  1. Гласов клас наемател 100 се прилага на всички ИЗХОДЯЩи dial-peers с лице IP PSTN.

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Гласов клас наемател 300 се прилага на всички ВХОДЯЩИ dial-peers от IP PSTN.

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

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

  1. Дефиниране на IP адреса на хоста на ITSP:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Дефиниране на модел за уникално идентифициране на локален сайт на шлюз в рамките на предприятие въз основа на параметъра TrunkGroup OTG/DTG на Control Hub:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    Местният шлюз в момента не поддържа подчертаване "_" в модела на мача. Като заобиколно решение използваме точка "." (мач всеки), за да съответства на "_".

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
3

Конфигуриране на следните връстници за изходящо набиране:

  1. Изходящ dial-peer към IP PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad

    Обяснение на командите:

    dial-peer voice 101 voip
     description Outgoing dial-peer to PSTN
    

    Определя VOIP dial-peer с етикет 101 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    destination-pattern BAD.BAD

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

    session protocol sipv2

    Указва, че този dial-peer ще се справя с SIP краката за обаждания.

    session target ipv4:192.168.80.13

    Показва целевия IPv4 адрес на местоназначението, където ще бъде изпратен този позивен крак. В този случай IP адресът на ITSP.

    voice-class codec 99

    Показва списък с предпочитания за кодец 99, който да се използва за този dial-peer.

    dtmf-relay rtp-nte

    Определя RTP-NTE (RFC2833) като Възможност dTMF очаква на този крак повикване.

    voice-class sip tenant 100

    Dial-peer ще наследи всички параметри от Tenant 100, освен ако същият този параметър не е дефиниран под самия dial-peer.

    no vad

    Забранява откриването на гласова активност.

  2. Изходящ dial-peer към Webex Calling (Този dial-peer ще бъде актуализиран, за да служи като Inbound dial-peer от Webex Calling, както и по-късно в ръководството за конфигуриране).

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Обяснение на командите:

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

    Определя VOIP dial-peer с маркер на 200201 и е дадено смислено описание за лекота на управление и отстраняване на неизправности

    session target sip-server

    Показва, че глобалният SIP сървър е местоназначението за обаждания от този партньорска набиране. Webex Calling сървърът, дефиниран в наемател 200, е наследен за този dial-peer.

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

    Dial-peer наследява всички параметри от Наемател 200 (LGW <--> Webex Calling Trunk), освен ако същият този параметър не е дефиниран под самия dial-peer. </-->

    srtp

    SRTP е активиран за този краче за обаждания.

    no vad

    Забранява откриването на гласова активност.

4

Конфигуриране на следните dial-peer групи (DPG):

  1. Определя dial-peer група 100. Изходящ dial-peer 101 е целта за всяка входяща dial-peer извикване на dial-peer група 100. Ние ще приложим DPG 100 за входящи dial-peer 200201 за Webex Calling --> LGW --> PSTN път.

    voice class dpg 100
     description Incoming WxC(DP200201) to IP PSTN(DP101)
     dial-peer 101 preference 1
    
  2. Дефинирайте dial-peer група 200 с изходяща dial-peer 200201 като цел заPSTN --> LGW --> Webex Calling път. DPG 200 ще се прилага за входящи dial-peer 100, дефинирани по-късно.

    voice class dpg 200
     description Incoming IP PSTN(DP100) to Webex Calling(DP200201)
     dial-peer 200201 preference 1
    
5

Конфигуриране на следните входящи dial-peers:

  1. Входящ dial-peer за входящи IP PSTN повикване крака:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 200
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Обяснение на командите

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    Указва, че този dial-peer ще се справя с SIP краката за обаждания.

    incoming uri via 100

    Целият входящ трафик от IP PSTN до LocalGW е съчетан на входящия IP адрес на заглавката на входящия VIA, определен в гласов клас URI 100 SIP, за да съответства въз основа на изходния IP (ITSP's) адрес.

    destination dpg 200

    С местоназначението DPG 200, IOS-XE чрез преминава класическите критерии за изходящо комутическо-партньорска съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, дефинирани в рамките на дестинация Dial-peer група 200, която е dial-peer 200201.

    voice-class sip tenant 300

    Dial-peer ще наследи всички параметри от Наемател 300, освен ако същият този параметър не е дефиниран под самия dial-peer.

    no vad

    Забранява откриването на гласова активност.

  2. Входящ dial-peer за входящи webex Повикване на краката:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination dpg 100
     incoming uri request 200
     

    Обяснение на командите

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

    Актуализира VOIP dial-peer с маркер на 200201 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    incoming uri request 200

    Целият входящ трафик от Webex Calling to LGW може да бъде съчетан по уникалния модел dtg в заявката URI, като уникално се идентифицира местният сайт на шлюза в рамките на Предприятие и в екосистемата Webex Calling.

    destination dpg 100

    С местоназначението DPG 100, IOS-XE чрез преминава класическите критерии за изходящо комутическо-партньорска съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, определени в рамките на дестинация Dial-peer група 100, която е dial-peer 101.

    max-conn 250

    Ограничава броя на едновременните обаждания до 250 между LGW и Webex Calling, като приема един-единствен dial-peer, изправен пред Webex Calling както за входящите, така и за изходящите повиквания, както е определено в това ръководство. За повече подробности относно едновременните ограничения на обажданията, включващи местен шлюз, посетете https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

PSTN към Уебекс повикване

Всички входящи IP PSTN повикване крака на местния шлюз са съчетани на dial-peer 100, тъй като тя определя съвпадение критерии за заглавката на VIA с IP АДРЕСА IP PSTN. Изходящ избор dial-peer е продиктувано от DPG 200, който директно се позовава на изходящи dial-peer 200201, който има Webex Calling сървър, посочен като целева дестинация.

Webex Повикване към PSTN

Всички входящи Webex Call повикване крака на местния шлюз са съчетани на dial-peer 200201, тъй като отговаря на критерии за съвпадение за заявка URI заглавен модел с параметъра TrunkGroup OTG/DTG, уникален за това локално разполагане на шлюз. Изходящ dial-peer избор е продиктувано от DPG 100, който директно се позовава изходящи dial-peer 101, който има IP PSTN IP адрес, посочен като целева дестинация.

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

  1. Наематели на гласов клас—Трябва да създадете допълнителни наематели за връстници за набиране, изправени пред Унифициран CM и ITSP, подобно на наемател 200, които създадохме за Webex Calling, изправени пред dial-peers.

  2. URIs за гласов клас—Модели, определящи ХОСТ IP адреси/портове за различни стволове, прекратяващи се на LGW: от Унифициран CM до LGW за PSTN дестинации; Унифициран CM към LGW за Webex Повикващи дестинации; Webex Призоваване към LGW; и PSTN SIP багажника прекратяване на LGW.

  3. Гласов клас сървър-група—Целеви IP адреси/портове за изходящи стволове от LGW до Унифициран CM, LGW до Webex Calling, и LGW към PSTN SIP багажника.

  4. Изходящи връстници за набиране—За маршрутиране на изходящи кол крака от LGW до Унифициран CM, ITSP SIP багажник и/или Webex Calling.

  5. Гласов клас DPG—Целева изходяща dial-peer(и), извиквана (и) от входящ dial-peer.

  6. Входящи dial-peers —За да приемете входящите кол крака от Унифициран CM, ITSP и/или Webex Calling.

1

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

  1. Гласов клас наемател 100 се прилага на всички изходящи dial-peers с лице Унифициран CM и IP PSTN:

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Гласов клас наемател 300 ще се прилага на всички входящи dial-peers от Унифициран CM и IP PSTN:

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

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

  1. Определя IP адреса на хоста на ITSP:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Дефиниране на модел за уникално идентифициране на локален сайт на шлюз в рамките на предприятие въз основа на параметъра TrunkGroup OTG/DTG на Control Hub:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    Местният шлюз в момента не поддържа подчертаване "_" в модела на мача. Като заобиколно решение използваме точка "." (мач всеки), за да съответства на "_".

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
  3. Определя Унифициран CM сигнализация VIA порт за Webex повикващия багажник:

    voice class uri 300 sip
     pattern :5065
    
  4. Определя CUCM източник сигнализация IP и VIA порт за PSTN багажник:

    voice class uri 302 sip
     pattern 192.168.80.60:5060
    
3

Конфигуриране на следните гласови клас сървър-групи:

  1. Определя целевия IP адрес на хост на Unified CM trunk и номера на порта за Унифицирана CM група 1 (5 възела). Унифициран CM използва порт 5065 за входящ трафик на Webex повикващия багажник (Webex Calling <-> LGW --> Унифициран CM). </->

    voice class server-group 301
     ipv4 192.168.80.60 port 5065
    
  2. Определя целевия IP адрес на хост на Unified CM trunk и номера на порта за Унифицирана CM група 2, ако е приложимо:

    voice class server-group 303
     ipv4 192.168.80.60 port 5065
    
  3. Определя целевия IP адрес на унифициран CM trunk за Унифицирана CM група 1 (5 възела). Унифициран CM използва порт по подразбиране 5060 за входящ трафик на PSTN багажника. Без зададен номер на порт се използва по подразбиране 5060. (PSTN <-> LGW --> унифициран CM)</->

    voice class server-group 305
     ipv4 192.168.80.60
    
  4. Определя целевия IP адрес на унифициран CM trunk за Унифицирана CM група 2, ако е приложимо.

    voice class server-group 307 
     ipv4 192.168.80.60
    
4

Конфигуриране на следните изходящи dial-peers:

  1. Изходящ dial-peer към IP PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Обяснение на командите

    dial-peer voice 101 voip
    description Outgoing dial-peer to PSTN

    Определя VOIP dial-peer с етикет 101 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    destination-pattern BAD.BAD

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

    session protocol sipv2

    Указва, че този dial-peer ще се справя с SIP краката за обаждания.

    session target ipv4:192.168.80.13

    Показва целевия IPv4 адрес на местоназначението, където ще бъде изпращан този позивен крак. (В този случай IP адресът на ITSP.)

    voice-class codec 99

    Показва списък с предпочитания за кодец 99, който да се използва за този dial-peer.

    voice-class sip tenant 100

    Dial-peer ще наследи всички параметри от Tenant 100, освен ако същият този параметър не е дефиниран под самия dial-peer.

  2. Изходящ dial-peer към Webex Calling (Този dial-peer ще бъде актуализиран, за да служи като Inbound dial-peer от Webex Calling, както и по-късно в ръководството за конфигуриране.):

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Обяснение на командите

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

    Определя VOIP dial-peer с маркер на 200201 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    session target sip-server

    Показва, че глобалният SIP сървър е местоназначението за обаждания от този партньорска набиране. Webex Calling сървърът, дефиниран в наемател 200, ще бъде наследен за този dial-peer.

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

    Dial-peer наследява всички параметри от Наемател 200 (LGW <--> Webex Calling Trunk), освен ако същият този параметър не е дефиниран под самия dial-peer. </-->

    srtp

    SRTP е активиран за този краче за обаждания.

  3. Изходящ dial-peer към Уебекс повикващия багажник на Унифициран CM:

    dial-peer voice 301 voip
     description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 301
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Обяснение на командите

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling – Nodes 1 to 5

    Определя VOIP dial-peer с етикет 301 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    session server-group 301

    Вместо сесия цел IP в dial-peer, ние сме сочи към Група местоназначение сървър (сървър-група 301 за dial-peer 301) за определяне на няколко целеви UCM възли макар примерът показва само един възел.

    Сървърна група в партньорската група за изходящи набиране

    С няколко връстници за набиране в DPG и няколко сървъра в групата на сървъра dial-peer, можем да постигнем произволно разпределение на обажданията над всички абонати на Унифицирана CM обработка на повиквания или лов въз основа на дефинирано предпочитание. Всяка сървърна група може да има до пет сървъра (IPv4/v6 със или без порт). Втора dial-peer и втора сървърна група се изисква само ако се използват повече от пет абонати за обработка на обаждания.

    Вижте https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html за повече информация.

  4. Втори изходящ dial-peer към Webex повикващия багажник на Unified CM, ако имате повече от 5 Унифицирани CM възела:

    dial-peer voice 303 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from Webex Calling - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 303
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
  5. Изходящ dial-peer към PSTN багажника на Унифициран CM:

    dial-peer voice 305 voip
     description Outgoing dial-peer to CUCM-Group-1 
    for inbound from PSTN - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 305
     voice-class codec 99 
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
  6. Втори изходящ dial-peer към PSTN Trunk на Унифициран CM, ако имате повече от 5 Унифицирани CM възли:

    dial-peer voice 307 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from PSTN - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 307
     voice-class codec 99  
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
5

Конфигуриране на следния DPG:

  1. Определя DPG 100. Изходящ dial-peer 101 е целта за всяка входяща dial-peer извикване на dial-peer група 100. Ние ще прилагаме DPG 100 за входящи dial-peer 302, дефинирани по-късно за Унифицирания CM --> LGW --> PSTN път:

    voice class dpg 100
     dial-peer 101 preference 1
    
  2. Дефиниране на DPG 200 с изходяща 200201 за набиране като цел за Унифициран CM --> LGW --> Webex Calling път:

    voice class dpg 200
     dial-peer 200201 preference 1
    
  3. Дефиниране на DPG 300 за изходящи dial-peers 301 или 303 за Webex извикване --> LGW --> Унифициран CM път:

    voice class dpg 300
     dial-peer 301 preference 1
     dial-peer 303 preference 1
    
  4. Дефиниране на DPG 302 за изходящи dial-peers 305 или 307 за PSTN --> LGW --> Унифициран CM път:

    voice class dpg 302
     dial-peer 305 preference 1
     dial-peer 307 preference 1
    
6

Конфигуриране на следните входящи dial-peers:

  1. Входящ dial-peer за входящи IP PSTN повикване крака:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 302
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Обяснение на командите

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    Указва, че този dial-peer ще се справя с SIP краката за обаждания.

    incoming uri via 100

    Целият входящ трафик от IP PSTN до LGW е съчетан на входящия IP адрес на заглавката на входящия VIA, определен в гласов клас URI 100 SIP, за да съответства въз основа на изходния IP (ITSP's) адрес.

    destination dpg 302

    С местоназначението DPG 302, IOS-XE чрез преминава класическите критерии за изходящо комутическо съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, дефинирани в рамките на местоназначение DPG 302, които могат да бъдат или dial-peer 305, или dial-peer 307.

    voice-class sip tenant 300

    Dial-peer ще наследи всички параметри от Наемател 300, освен ако същият този параметър не е дефиниран под самия dial-peer.

  2. Входящ dial-peer за входящи webex Повикване на краката:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination dpg 300
     incoming uri request 200
     

    Обяснение на командите

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

    Актуализира VOIP dial-peer с маркер на 200201 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    incoming uri request 200

    Целият входящ трафик от Webex Calling to LGW може да бъде съчетан по уникалния модел dtg в URI за заявка, като уникално се идентифицира местен сайт на шлюз в рамките на Предприятие и в екосистемата Webex Calling.

    destination dpg 300

    С местоназначението DPG 300, IOS-XE чрез преминава класическите критерии за изходящо комутическо-партньорска съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, определени в рамките на местоназначение DPG 300, които могат да бъдат или dial-peer 301 или dial-peer 303.

    max-conn 250

    Ограничава броя на едновременните обаждания до 250 между LGW и Webex Calling, ако приемем един-единствен dial-peer, изправен пред Webex Calling както за входящи, така и за изходящи повиквания, както е определено в това ръководство. За повече подробности относно едновременните ограничения на обажданията, включващи местен шлюз, посетете https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

  3. Входящ dial-peer за входящите Унифицирани CM повикване крака с Webex Calling като дестинация:

    dial-peer voice 300 voip
     description Incoming dial-peer from CUCM for Webex Calling
     session protocol sipv2
     destination dpg 200
     incoming uri via 300
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Обяснение на командите

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

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

    incoming uri via 300

    Целият входящ трафик от Унифициран CM до LGW е съчетан на порта на източника (5065), дефиниран в гласов клас URI 300 SIP.

    destination dpg 200

    С местоназначението DPG 200, IOS-XE чрез преминава класическите критерии за изходящо комутическо-партньорска съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, определени в рамките на местоназначение DPG 200, които ще бъдат dial-peer 200201.

    voice-class sip tenant 300

    Dial-peer ще наследи всички параметри от Наемател 300, освен ако същият този параметър не е дефиниран под самия dial-peer.

  4. Входящ dial-peer за входящи Унифицирани CM повикване крака с PSTN като местоназначението:

    dial-peer voice 302 voip
     description Incoming dial-peer from CUCM for PSTN
     session protocol sipv2
     destination dpg 100
     incoming uri via 302
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Обяснение на командите

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

    Определя VOIP dial-peer с маркер 302 и е дадено смислено описание за лекота на управление и отстраняване на неизправности.

    incoming uri via 302

    Целият входящ трафик от Унифициран CM до LGW за PSTN дестинация е съчетан на Унифициран CM източник сигнализация IP адрес и VIA порт, дефинирани в глас клас URI 302 SIP. Използва се стандартен SIP порт 5060.

    destination dpg 100

    С местоназначението DPG 100, IOS-XE чрез преминава класическите критерии за изходящо комутическо-партньорска съвпадение и веднага пристъпва към настройка на изходящия кол крак с помощта на комутационни връстници, определени в рамките на местоназначение DPG 100, които ще бъдат dial-peer 101.

    voice-class sip tenant 300

    Dial-peer ще наследи всички параметри от Наемател 300, освен ако същият този параметър не е дефиниран под самия dial-peer.

IP PSTN към унифициран CM PSTN багажник

Webex повикваща платформа към унифициран CM Webex повикващия багажник

Унифициран CM PSTN багажник към IP PSTN

Унифициран CM Webex повикваща багажника към Webex повикваща платформа

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

Диагностични подписи (DS) са XML файлове, които съдържат информация за проблем задейства събития и действия, които трябва да бъдат предприети за информиране, отстраняване на неизправности и отстраняване на проблема. Логиката на откриване на проблеми се дефинира с помощта на syslog съобщения, SNMP събития и чрез периодично наблюдение на конкретни шоу командни изходи. Типовете действия включват събиране на шоу командни изходи, генериране на консолидиран регистрационен файл и качване на файла на потребител, предоставен мрежово местоположение като HTTPS, SCP, FTP сървър. DS файлове са автор на TAC инженери и са цифрово подписани за защита на целостта. Всеки DS файл има уникален цифров ИД, присвоен от системата. Инструмент за търсене на диагностични подписи (DSLT) е един източник за намиране на приложими подписи за наблюдение и отстраняване на различни проблеми.

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

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

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

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

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

Локален шлюз, изпълняващ IOS XE 17.3.2 или по-висока

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

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

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    LocalGateway(config)#end 
  3. Конфигуриране на променливата на средата ds_email с имейл адреса на администратора, който трябва да бъде уведомен.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 

Локален шлюз, изпълняващ IOS XE 16.11.1 или по-висока

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

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

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server  <email server> priority 1 
    LocalGateway(config)#end 
    
  3. Конфигуриране на променливата на средата ds_email с имейл адреса на администратора, който трябва да бъде уведомен.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 
    

Локален шлюз, работещ 16.9.x версия

  1. Въведете следните команди, за да разрешите диагностични подписи.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home reporting contact-email-addr sch-smart-licensing@cisco.com  
    LocalGateway(config)#end  
  2. Конфигурирайте имейл сървъра, който да се използва за изпращане на проактивни известия, ако устройството работи с версия по-рано от 17.3.2.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server  <email server> priority 1 
    LocalGateway(config)#end 
  3. Конфигуриране на променливата на средата ds_email с имейл адреса на администратора, който трябва да бъде уведомен.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 

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


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

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

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

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

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

Следене на високото използване на процесора

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

  1. Осигурете SNMP е активирана с помощта на командата шоу snmp. Ако не е разрешена, конфигурирайте командата "мениджър на snmp-сървър".

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Изтеглете DS 64224 с помощта на следните падащи опции в Инструмент за справка за диагностични подписи:

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

    Име на поле

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

    Платформа

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

    Продукт

    КУБ Ентърпрайз в Уебекс извикване решение

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

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

    Тип проблем

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

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

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

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

    
    LocalGateway# 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) 
    LocalGateway # 
  4. Инсталирайте DS XML файла в локалния шлюз.

    
    LocalGateway# call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    LocalGateway# 
  5. Проверете дали подписът е успешно инсталиран с помощта на показване на диагностика-подпис по повикване-начало. Колоната за състояние трябва да има "регистрирана" стойност.

    
    LocalGateway# 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

    ЛокалГейтуей #


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

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

Този DS проверява за un-регистрация на локален шлюз SIP Trunk с Cisco Webex Calling облак на всеки 60 секунди. След като бъде открит събитието за регистрация на ООН, то генерира известие по имейл и syslog и се деинсталира след две събития в un-registration. Моля, използвайте стъпките по-долу, за да инсталирате подписа.

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

    Име на поле

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

    Платформа

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

    Продукт

    КУБ Ентърпрайз в Уебекс извикване решение

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

    SIP-SIP

    Тип проблем

    SIP Trunk Un-регистрация с известие по имейл

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

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
  3. Инсталирайте DS XML файла в локалния шлюз.

    
    LocalGateway# call-home diagnostic-signature load DS_64117.xml 
    Load file DS_64117.xml success 
    LocalGateway#  
  4. Проверете дали подписът е успешно инсталиран с помощта на показване на диагностика-подпис по повикване-начало. Колоната за състояние трябва да има "регистрирана" стойност.

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

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

  1. Проверете дали SNMP е активиран с помощта на командата шоу snmp. Ако не е разрешена, конфигурирайте командата "мениджър на snmp-сървър".

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Изтеглете DS 65221 с помощта на следните опции в Инструмент за справка за диагностични подписи:

    Име на поле

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

    Платформа

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

    Продукт

    КУБ Ентърпрайз в Уебекс извикване решение

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

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

    Тип проблем

    SIP необичайно откриване на прекъсване на разговора с Имейл и Syslog Уведомление

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

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. Инсталирайте DS XML файла в локалния шлюз.

    
    LocalGateway# call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    LocalGateway# 
  5. Проверете дали подписът е успешно инсталиран с помощта на показване на диагностика-подпис по повикване-начало. Колоната за състояние трябва да има "регистрирана" стойност.

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

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

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

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

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

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

    Пример:

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. Осигурете SNMP е активирана с помощта на командата шоу snmp. Ако не е разрешена, конфигурирайте командата "мениджър на snmp-сървър".

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
     
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
  3. Препоръчително е да инсталирате high CPU мониторинг DS 64224 като проактивна мярка за деактивиране на всички дебъгове и диагностика подписи по време на високо използване на процесора. Изтеглете DS 64224, като използвате следните опции в Инструмент за справка за диагностични подписи:

    Име на поле

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

    Платформа

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

    Продукт

    КУБ Ентърпрайз в Уебекс извикване решение

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

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

    Тип проблем

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

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

    Име на поле

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

    Платформа

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

    Продукт

    КУБ Ентърпрайз в Уебекс извикване решение

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

    Syslogs

    Тип проблем

    Syslog - %VOICE_IEC-3-GW: CCAPI: Вътрешна грешка (Праг на скока на обажданията): IEC=1,1,181,1,29,0

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

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: 
  6. Инсталирайте високо cpu мониторинг DS 64224 и след това DS 65095 XML файл в локалния шлюз.

    
    LocalGateway# call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    LocalGateway# 
    LocalGateway# call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    LocalGateway# 
  7. Проверете дали подписът е успешно инсталиран с помощта на показване на диагностика-подпис по повикване-начало. Колоната за състояние трябва да има "регистрирана" стойност.

    
    LocalGateway# 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

    ЛокалГейтуей #

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

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


LocalGateway# 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

ЛокалГейтуей #

LocalGateway# показват статистика за диагностика-подпис по повикване-начало

ИД на DS

Име на DS

Задействано/Макс/Деинсталирайте

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

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

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

ЛокалГейтуей #

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

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

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


LocalGateway# call-home diagnostic-signature deinstall <DS ID> 
LocalGateway# 

Пример:


LocalGateway# call-home diagnostic-signature deinstall 64224 
LocalGateway# 

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