- Pagină de pornire
- /
- Articol
Flux de lucru de configurare a apelurilor Webex
Obțineți rulmenții cu toate informațiile disponibile despre Webex Calling, indiferent dacă sunteți partener, administrator sau utilizator. Utilizați linkurile furnizate aici pentru a vă ajuta să începeți utilizarea tuturor serviciilor și funcțiilor disponibile cu Webex Calling.
Cerințe privind gateway-ul local pentru Webex Calling
Condiţii generale
Înainte de a configura un gateway local pentru Webex Calling, asigurați-vă că:
Cunoașterea de bază a principiilor VoIP
Cunoașterea de bază a conceptelor de voce Cisco IOS-XE și IOS-XE
Să înțelegeți de bază Protocolul de inițiere sesiuni (SIP)
Aveți o înțelegere de bază a Cisco Unified Communications Manager (Unified CM) dacă modelul dvs. de implementare include Unified CM
Consultați Ghidul de configurare Enterprise Cisco Unified Border Element (CUBE) pentru detalii.
Cerințe hardware și software pentru gateway-ul local
Asigurați-vă că implementarea dvs. are una sau mai multe dintre gateway-urile locale (Cisco CUBE (pentru conectivitate bazată pe IP) sau Cisco IOS Gateway (pentru conectivitate bazată pe TDM)) care se află în Tabelul 1 al gateway-ului local pentru Ghidul de comandă Webex Calling. În plus, asigurați-vă că platforma rulează o versiune IOS-XE acceptată conform Ghidului de configurare a gateway-ului local.
Cerințe de licență pentru gateway-urile locale
Licențele de apelare CUBE trebuie instalate pe gateway-ul local. Pentru mai multe informații, consultați Ghidul de configurare a elementului de frontieră Cisco Unified.
Cerințe de certificare și securitate pentru gateway-ul local
Webex Calling necesită semnalizare și media securizate. Gateway-ul local efectuează criptarea, iar o conexiune TLS trebuie să fie stabilită la ieșirea din cloud cu următorii pași:
LGW trebuie actualizat cu pachetul rădăcină CA de la Cisco PKI
Se utilizează un set de date de autentificare SIP digest din pagina de configurare trunchiuri a Control Hub pentru a configura LGW (pașii fac parte din configurația care urmează)
Validează pachetul rădăcină CA prezentat certificat
Solicitată pentru datele de autentificare (SIP Digest furnizat)
Cloud-ul identifică care gateway-ul local este înregistrat în siguranță
Firewall, NAT Traversal și cerințele de optimizare a căilor media pentru gateway-ul local
În cele mai multe cazuri, gateway-ul local și punctele finale pot locui în rețeaua de clienți interni, folosind adrese IP private cu NAT. Firewall-ul întreprinderii trebuie să permită traficul de ieșire (SIP, RTP/UDP, HTTP) către anumite adrese IP/porturi, acoperite de informațiile de referință portuare.
Dacă doriți să utilizați Optimizarea căilor media cu ICE, interfața cu care se confruntă Webex Calling a gateway-ului local trebuie să aibă o cale de rețea directă către și de la punctele finale Webex Calling. Dacă punctele finale se află într-o locație diferită și nu există o cale de rețea directă între punctele finale și interfața Webex Calling cu care se confruntă gateway-ul local, atunci gateway-ul local trebuie să aibă o adresă IP publică atribuită interfeței cu care se confruntă Webex Calling pentru apeluri între gateway-ul local și punctele finale pentru a utiliza optimizarea căii media. În plus, trebuie să fie rulează iOS-XE versiunea 16.12.5.
Primul pas pentru a vă obține Webex Calling servicii de funcționare este de a finaliza Asistentul pentru prima configurare (FTSW). Odată ce FTSW este finalizat pentru prima locație, nu trebuie să fie finalizat pentru locații suplimentare.
1 | Faceți clic pe Primii pași linkul din e-mailul de bun venit pe care îl primiți.
| ||
2 | Consultați și acceptați condițiile de furnizare a serviciilor și condițiile . | ||
3 | Examinați-vă planul și apoi faceți clic Începeți .
| ||
4 | Selectați țara în care ar trebui să mapați centru de date și introduceți informațiile de contact client și adresa clientului. | ||
5 | Faceți clic pe Înainte. Locație implicită: | ||
6 | Alegeți dintre următoarele opțiuni:
| ||
7 | Efectuați următoarele selecții pentru a aplica în această locație:
| ||
8 | Faceți clic pe Înainte. | ||
9 | Introduceți o adresă Cisco Webex SIP disponibilă și faceți clic În continuare și selectați Terminați . |
Înainte de a începe
Pentru a crea o locație nouă, pregătiți următoarele informații:
Adresă locație
Numere de telefon dorite (opțional)
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați .
| ||||
2 | Configurați setările locației:
| ||||
3 | Faceți clic Salvați și apoi alegeți Da / Nu pentru a adăuga numere la locație acum sau mai târziu. | ||||
4 | Dacă ați făcut clic Da , alegeți una dintre următoarele opțiuni:
Alegerea opțiunii PSTN este la fiecare nivel de locație (fiecare locație are o singură opțiune PSTN). Puteți combina câte opțiuni doriți pentru implementare, dar fiecare locație va avea o opțiune. După ce ați selectat și ați configurat o opțiune PSTN, puteți să o modificați făcând clic Gestionați în proprietățile PSTN ale locației. Cu toate acestea, unele opțiuni, cum ar fi Cisco PSTN, pot să nu fie disponibile după ce a fost atribuită o altă opțiune. Deschideți un caz de asistență pentru îndrumare. | ||||
5 | Alegeți dacă doriți să activați numerele acum sau mai târziu. | ||||
6 | Dacă ați selectat non-integrated CCP sau Premises-based PSTN, introduceți Numere de telefon ca valori separate prin virgulă, apoi faceți clic Validați . Numerele sunt adăugate pentru locația specifică. Intrările valide se mută în Numere validate câmp, iar intrările nevalide rămân în câmpul Adăugare numere câmp însoțit de un mesaj de eroare. În funcție de țara locației, numerele sunt formatate în funcție de cerințele locale de apelare. De exemplu, dacă este necesar un cod de țară, puteți introduce numere cu sau fără cod, iar codul este adăugat înainte. | ||||
7 | Faceți clic pe Salvați. |
Ce este de făcut în continuare
După ce creați o locație, puteți activa serviciile 911 de urgență pentru locația respectivă. Vedeți Serviciu RedSky 911 de urgență pentru Webex Calling pentru mai multe informații.
Înainte de a începe
Obțineți o listă a utilizatorilor și a spațiilor de lucru asociate cu o locație: Accesați ștergeți acești utilizatori și spațiile de lucru înainte de a șterge locația. iar din meniu derulant, selectați locația de șters. TrebuieRețineți că orice numere asociate cu această locație vor fi returnate furnizorului dvs. PSTN; nu veți mai deține acele numere. |
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . |
2 | Clic |
3 | Alegeți Ștergeți locația , și confirmați că doriți să ștergeți locația respectivă. De obicei, durează câteva minute pentru ca locația să fie ștearsă definitiv, dar poate dura până la o oră. Puteți verifica starea făcând clic lângă numele locației și selectând Stare ștergere . |
După crearea acesteia, puteți modifica configurația PSTN, numele, ora locală și limba unei locații. Rețineți totuși că noua limbă se aplică numai utilizatorilor și dispozitivelor noi. Utilizatorii și dispozitivele existențe continuă să utilizeze limba veche.
Pentru locațiile existente, puteți activa serviciile 911 de urgență. Vedeți Serviciu RedSky 911 de urgență pentru Webex Calling pentru mai multe informații. |
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . Dacă vedeți un simbol Atenție lângă o locație, înseamnă că nu ați configurat încă un număr de telefon pentru locația respectivă. Nu puteți efectua sau primi apeluri până când nu configurați numărul respectiv. | ||||||
2 | (Opțional) Sub Conexiune PSTN , selectați oricare PSTN conectat la cloud sau PSTN la sediu (gateway local), în funcție de cel pe care l-ați configurat deja. Faceți clic Gestionați pentru a modifica configurația respectivă și apoi recunoașteți riscurile asociate prin selectare Continuați . Alegeți una dintre următoarele opțiuni și apoi faceți clic Salvați :
| ||||||
3 | Selectați Număr principal la care poate fi contactat principalul contact al locației. | ||||||
4 | (Opțional) Sub Apelare de urgență , puteți selecta Identificator locație de urgență pentru a atribui acestei locații.
| ||||||
5 | Selectați Număr mesagerie vocală pe care utilizatorii le pot apela pentru a-și verifica mesageria vocală pentru această locație. | ||||||
6 | (Opțional) Faceți clic pe pictograma creion din partea de sus a paginii Locație pentru a modifica Nume locație , Limba anunțului , Limbă E-mail , Fus orar , sau Adresă după cum este necesar, apoi faceți clic Salvați .
|
Aceste setări sunt pentru apelarea internă și sunt disponibile și în expertul de configurare pentru prima dată. Pe măsură ce modificați planul de apelare, numerele de exemplu din actualizarea Control Hub pentru a afișa aceste modificări.
Puteți configura permisiunile de apelare de ieșire pentru o locație. Vedeți acești pași pentru a configura permisiunile de apelare de ieșire. |
1 | Conectați-vă la Control Hub, accesați , apoi defilați la apelare internă. | ||||||||
2 | Configurați următoarele preferințe de apelare opționale, după cum este necesar:
| ||||||||
3 | Specificați apelarea internă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea internă după cum este necesar: , selectați o locație din listă și faceți clic pe
| ||||||||
4 | Specificați apelarea externă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea externă după cum este necesar: , selectați o locație din listă și faceți clic pe
Impact asupra utilizatorilor:
|
Dacă sunteți un reseller cu valoare adăugată, puteți utiliza acești pași pentru a începe configurarea gateway local în Control Hub . Când acest gateway este înregistrat în cloud, îl puteți utiliza pe unul sau mai multe dintre dvs Webex Calling locații pentru a oferi rutare către un furnizor serviciu PSTN enterprise .
O locație care are un gateway local nu poate fi ștearsă atunci când gateway local este utilizat pentru alte locații. |
Înainte de a începe
Odată ce o locație este adăugată și înainte de a configura PSTN local pentru o locație, trebuie să creați un trunchi.
Creați orice locații și setări și numere specifice pentru fiecare dintre ele. Locațiile trebuie să existe înainte de a putea adăuga un PSTN local.
Înțelegeți cerințele PSTN (gateway local) în sediul pentru Webex Calling .
Nu puteți alege mai mult de un trunchi pentru o locație cu PSTN local, dar puteți alege același trunchi pentru mai multe locații.
1 | Conectați-vă la Control Hub la , accesați Servicii > Apelare > Dirijarea apelurilor , și selectați Adăugare trunchi .https://admin.webex.com | ||
2 | Selectați o locație. | ||
3 | Denumiți trunchiul și faceți clic Salvați .
|
Ce este de făcut în continuare
Informațiile privind trunchiul apar pe ecran Înregistrare domeniu, grup trunchi OTG/DTG, linie/port , Adresă proxy de ieșire .
Vă recomandăm să copiați aceste informații din Control Hub și inserați-l într-un fișier text local sau un document, astfel încât să puteți face referire la acesta atunci când sunteți gata să configurați gateway local.
Dacă pierdeți acreditările, trebuie să le regenerați din ecranul cu informații despre trunchi din Control Hub. Faceți clic Preluați numele de utilizator și resetarea parolei pentru a genera un nou set de date de autentificare de utilizat pe trunchi.
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . | ||
2 | Selectați o locație de modificat și faceți clic Gestionați . | ||
3 | Selectați PSTN la sediu și faceți clic În continuare . | ||
4 | Alegeți un trunchi din meniu derulant.
| ||
5 | Faceți clic pe notificarea de confirmare, apoi faceți clic Salvați . |
Ce este de făcut în continuare
Trebuie să luați informație de configurare care Control Hub a generat și mapați parametrii în gateway local (de exemplu, pe un Cisco CUBE care se află în incintă). Acest articol vă ghidează prin acest proces. Ca referință, consultați următoarea diagramă pentru un exemplu despre modul în care Control Hub informație de configurare (din stânga) se asociază cu parametrii din CUBE (pe dreapta):
După ce ați finalizat cu succes configurația pe gateway-ul propriu-zis, puteți reveni la Servicii > Apelați > Locații în Control Hub iar gateway-ul pe care l-ați creat va fi afișat în cardul de locație căruia i-ați alocat-o cu un punct verde în stânga numelui.
Această stare indică faptul că gateway-ul este înregistrat securizat în cloud-ul de apelare și că servește ca gateway PSTN activ pentru locație.Puteți vizualiza, activa, elimina și adăuga cu ușurință numere de telefon pentru organizația dvs. în Control Hub . Pentru mai multe informații, consultați Gestionați numerele de telefon în Control Hub .
Dacă încercați serviciile Webex și doriți să transformați perioada de încercare într-un abonament cu plată, puteți trimite o solicitare prin e-mail partenerului dvs.
1 | Conectați-vă la Control Hub la https://admin.webex.com, selectați pictograma de construcție |
2 | Selectați Abonamente filă, apoi faceți clic Achiziționați acum . Partenerul dvs. îi este trimis un e-mail prin care îl informează că sunteți interesat să treceți la un abonament cu plată. |
Puteți utiliza Control Hub pentru a seta prioritatea opțiunilor de apelare disponibile pe care le văd utilizatorii în Aplicația Webex . Le puteți activa și pentru un singur clic pentru apelare. Pentru mai multe informații, consultați: Setați opțiunile de apelare pentru utilizatorii aplicației Webex .
Puteți controla ce aplicație de apelare se deschide atunci când utilizatorii efectuează apeluri. Puteți configura setările clientului apelant, inclusiv implementarea în mod mixt pentru organizații cu utilizatori cu drepturi de utilizare Unified CM sau Webex Calling și utilizatorii fără servicii de apelare cu plată de la Cisco. Pentru mai multe informații, consultați: Configurați comportamentul de apelare.
Prezentare generală
Webex Calling acceptă în prezent două versiuni ale gateway-ului local:
Gateway local
Gateway local pentru Webex for Government
Înainte de a începe, înțelegeți cerințele locale privind rețeaua de telefonie publică comutată (PSTN) și gateway-ul local (LGW) pentru Webex Calling. Vedeți Arhitectură Cisco Preferred pentru Webex Calling pentru mai multe informații.
Acest articol presupune că există o platformă gateway locală dedicată, fără nicio configurație vocală existentă. Dacă modificați un gateway PSTN existent sau implementarea CUBE Enterprise pentru a-l utiliza ca funcție a gateway-ului local pentru Webex Calling, acordați o atenție deosebită configurației. Asigurați-vă că nu întrerupeți fluxurile de apeluri existente și funcționalitatea din cauza modificărilor pe care le efectuați.
Procedurile conțin link-uri către documentația de referință a comenzii, unde puteți afla mai multe despre opțiunile individuale ale comenzii. Toate linkurile de referință la comandă merg la Referință pentru comandă Webex Managed Gateways cu excepția cazului în care se specifică altfel (caz în care, linkurile de comandă merg la Referință pentru comandă vocală Cisco IOS ). Puteți accesa toate aceste ghiduri la Cisco Unified Border Element Command References. Pentru informații privind SBC-urile terță parte acceptate, consultați documentația de referință a produsului respectivă. |
Există două opțiuni de configurare a gateway-ului local pentru dvs Webex Calling trunchi:
Trunchi bazat pe înregistrare
Trunchi bazat pe certificat
Utilizați fluxul de activități fie sub Gateway local bazat pe înregistrare sau Gateway local bazat pe certificat pentru a configura Local Gateway pentru dvs Webex Calling trunchi.
Consultați Începeți cu gateway-ul local pentru mai multe informații despre diferite tipuri de trunchiuri. Efectuați următorii pași pe gateway-ul local propriu-zis, utilizând Command Line Interface (CLI). Utilizăm Protocol de inițiere sesiuni (SIP) și transportul TLS ( Securitate strat de transport ) pentru a securiza trunchiul și protocolul securizat în timp real ( SRTP) pentru a securiza media dintre gateway-ul local și Webex Calling .
Selectați CUBE ca Gateway local. Webex for Government nu acceptă în prezent niciun controler de frontieră pentru sesiune terță (SBC). Pentru a revizui cea mai recentă listă, consultați Începeți cu gateway-ul local.
- Instalați versiunile Cisco IOS XE Dublin 17.12.1a sau versiuni ulterioare pentru toate gateway-urile locale Webex for Government.
Pentru a revizui lista autorităților de certificare rădăcină (AC) care acceptă Webex for Government, consultați autoritățile de certificare rădăcină pentru Webex for Government.
Pentru detalii despre intervalele de porturi externe pentru gateway-ul local din Webex for Government, consultați cerințele rețelei pentru Webex for Government (FedRAMP).
Gateway-ul local pentru Webex for Government nu acceptă următoarele:
STUN/ICE-Lite pentru optimizarea căii media
Fax (T.38)
Pentru a configura gateway-ul local pentru trunchiul dvs. Webex Calling în Webex for Government, utilizați următoarea opțiune:
Trunchi bazat pe certificat
Utilizați fluxul de activități din gateway-ul local bazat pe certificat pentru a configura gateway-ul local pentru trunchiul Webex Calling. Pentru mai multe detalii despre modul de configurare a unui gateway local bazat pe certificate, consultați Configurați trunchiul bazat pe certificate Webex Calling.
Este obligatoriu să configurați criptoare GCM conforme cu FIPS pentru a sprijini gateway-ul local pentru Webex for Government. Dacă nu, configurarea apelului eșuează. Pentru detalii de configurare, consultați Configurați trunchiul bazat pe certificatul Webex Calling.
Webex for Government nu acceptă gateway-ul local bazat pe înregistrare. |
Această secțiune descrie modul de configurare a unui element de frontieră Cisco Unified (CUBE) ca gateway local pentru Webex Calling, utilizând un trunchi SIP de înregistrare. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Imaginea de mai jos evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
cursanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup peer-dial: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe înregistrare necesită versiuni Cisco IOS XE 17.6.1a sau ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe de tehnologie de securitate.
Routerele din seria Catalyst Edge 8000 echipate cu carduri vocale sau DSPs necesită acordarea licenței DNA Advantage. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
NTP
ACL-uri
Autentificare utilizator și acces la distanță
DNS
Rutare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
| ||
2 | Protejați acreditările de înregistrare și STUN pe router prin criptare simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
| ||
3 | Creați un punct de încredere PKI pentru titularul plasamentului.
| ||
4 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare. Parametrii de transport ar trebui, de asemenea, să fie actualizați pentru a asigura o conexiune sigură și fiabilă pentru înregistrare:
| ||
5 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate:
|
1 | Creați un trunchi PSTN bazat pe înregistrare pentru o locație existentă în Control Hub. Notaţi informaţiile trunchiului care sunt furnizate după ce trunchiul a fost creat. Aceste detalii, așa cum se evidențiază în ilustrația următoare, vor fi utilizate în etapele de configurare din acest ghid. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling . | ||||
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. statistici mediaPermite monitorizarea media pe gateway-ul local. stări colective mediaPermite planului de control să interogheze planul de date pentru statistică apeluri în bloc . Pentru mai multe informații despre aceste comenzi, consultați Media. permite conexiuni sip la sipActivați funcționalitatea de bază a agentului de utilizator SIP back-to-back CUBE. Pentru mai multe informații, consultați Permiteți conexiuni .
Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata secret-partajat . sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcină utilă asimetrică . ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați ofertă anticipată . | ||||
3 | Configurare codec clasă vocală 100 filtru pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codeculclasei de voce.
| ||||
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling.
Iată o explicație a câmpurilor pentru configurare: stunutilizaregheațăliteUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stunării clasei de voce și stun utilisation ice lite .
| ||||
5 | Configurați politica de criptare media pentru traficul Webex.
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1 80._ Pentru mai multe informații, consultați clasa de voce srtp-crypto . | ||||
6 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza parametrului trunchiului de destinație:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați dtg= urmat de valoarea Trunk OTG/DTG furnizată în Control Hub atunci când trunchiul a fost creat. Pentru mai multe informații, consultați clasa vocală uri. | ||||
7 | Configurare profil sip 100, care va fi utilizat pentru a modifica mesajele SIP înainte de a fi trimise către Webex Calling.
Iată o explicație a câmpurilor pentru configurare:
| ||||
8 | Configurați trunchiul Webex Calling: |
După ce definiți entitatea găzduită 100 și configurați un peer de apelare SIP VoIP, gateway-ul inițiază o conexiune TLS către Webex Calling. În acest moment, SBC de acces își prezintă certificatul la gateway-ul local. Gateway-ul local validează certificatul SBC de acces Webex Calling utilizând pachetul rădăcină CA care a fost actualizat mai devreme. Dacă certificatul este recunoscut, se stabilește o sesiune TLS persistentă între gateway-ul local și accesul Webex Calling SBC. Gateway-ul local este apoi capabil să utilizeze această conexiune securizată pentru a se înregistra la SBC de acces Webex. Când înregistrarea este contestată pentru autentificare:
În răspuns se utilizează numele de utilizator, parola și parametrii domeniului din configurația de acreditări .
Regulile de modificare din profilul sip 100 sunt utilizate pentru a converti URL-ul SIPS înapoi la SIP.
Înscrierea este reușită atunci când un 200 OK este primit de la SBC de acces.
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE. |
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI. |
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește un dial-peer VoIP cu eticheta de 300 și oferă o descriere semnificativă pentru o gestionare ușoară și depanare. Pentru mai multe informații, consultați voce dial-peer. model-destinație RĂU.PROBĂTEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați model-destinație (interfață) . protocol de sesiune sipv2Specifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocol de sesiune (dial peer) . țintă sesiune ipv4:192.168.80.13Indică adresă IPv4 țintă a destinației pentru a trimite segmentul de componentă apel. Ținta sesiunii aici este adresă IP a ITSP . Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP a PSTN adresă IP. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec de clasă voce . dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe segmentul de componentă apel. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
Atunci când creați trunchiul Webex Calling în Unified CM, asigurați-vă că configurați portul de intrare în setările profilului de securitate al trunchiului SIP la 5065. Acest lucru permite mesajele de intrare pe portul 5065 și populează antetul VIA cu această valoare atunci când trimiteți mesaje către gateway-ul local. |
1 | Configurați următoarele URI pentru clase de voce: | ||
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM:
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. | ||
3 | Configurați următorii colegi de apelare: | ||
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe IOS XE și generează notificarea evenimentului prin e-mail, syslog sau mesaj terminal. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în carcasa Cisco TAC pentru a accelera timpul de rezoluție.
Semnături de diagnosticare (DS) sunt fișiere XML care conțin informații despre declanșarea problemelor evenimente și acțiuni care urmează să fie luate pentru a informa, depanare, și remedia problema. Puteți defini logica de detectare a problemei prin utilizarea mesajelor syslog, a evenimentelor SNMP și prin monitorizarea periodică a ieșirilor specifice ale comenzii de afișare.
Tipurile de acțiuni includ colectarea ieșirilor comenzii show:
Generarea unui fișier jurnal consolidat
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP.
Inginerii TAC creează fișierele DS și le semnează digital pentru a proteja integritatea. Fiecare fișier DS are un ID numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o sursă unică de găsire a semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS din care descărcați DSLT . Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server SMTP(Simple Mail Transfer Protocol) de care aveți nevoie pentru ca gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați server SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway-ul local care rulează IOS XE 17.6.1a sau mai mare
Semnăturile de diagnosticare este activată implicit.
Configurați serverul de e-mail securizat pentru a fi utilizat pentru a trimite o notificare proactivă dacă dispozitivul rulează Cisco IOS XE 17.6.1a sau o versiune ulterioară.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediuds_email cu adresa de e-adresă de e-mail a administratorului pentru a vă anunța.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Următoarele afișează un exemplu de configurare a unui gateway local care rulează pe Cisco IOS XE 17.6.1a sau mai mare pentru a trimite notificările proactive către tacfaststart @gmail.com utilizarea Gmail ca server SMTP securizat:
Vă recomandăm să utilizați versiunile Cisco IOS XE Bengaluru 17.6.x sau versiuni ulterioare. |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway local care rulează pe software-ul Cisco IOS XE nu este un client Gmail obișnuit, bazat pe web, care acceptă OAuth, așa că trebuie să configuram o anumită setare pentru contul Gmail și să oferim permisiunea specifică pentru ca e-mailul de pe dispozitiv să fie procesat corect: |
Accesați la aplicație mai puțin securizată.
și activați setarea de accesRăspundeți „Da, eu am fost” atunci când primiți un e-mail de la Gmail prin care se spune „Google a împiedicat pe cineva să se conecteze la contul dvs. utilizând o aplicație non-Google”.
Instalați semnături de diagnosticare pentru o monitorizare proactivă
Monitorizarea gradului de utilizare ridicat al CPU
Acest DS urmărește utilizarea CPU timp de cinci secunde folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când gradul de utilizare atinge 75% sau mai mult, acesta dezactivează toate remediile și dezinstalează toate semnăturile de diagnosticare care sunt instalate în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a activa SNMP. Dacă nu activați, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Copiați fișier XML în flash-ul Gateway local.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe gateway-ul local.
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)
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
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
Descărcați DS:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_ LGW_ CPU_ MON75
0.0.10
Înscris
07.11.2020 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv ea însăși. Dacă este necesar, reinstalați DS 64224 pentru a continua monitorizarea utilizării ridicate a procesorului pe gateway-ul local.
Monitorizarea înregistrării SIP trunk
Acest DS verifică dacă există anularea înregistrării unui trunchi SIP Gateway local în Webex Calling la fiecare 60 de secunde. Odată ce evenimentul de anulare a înscrierii este detectat, acesta generează un e-mail și o notificare syslog și se dezinstalează după două apariții de dezactivare. Utilizați pașii de mai jos pentru a instala semnătura:
Descărcați DS 64117 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
SIP- SIP
Tip problemă
Dezactivare trunchi SIP cu notificare prin e- E-mail .
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează interogare SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erorile SIP 403, 488 și 503. Dacă numărul de erori este mai mare sau egal cu 5 din ultimul sondaj, acesta generează un syslog și o notificare prin e-mail. Vă rugăm să utilizați pașii de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a verifica dacă SNMP este activat. Dacă nu este activată, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Detectare deconectare anormală a apelurilor SIP cu notificare prin e- E-mail și Syslog.
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Instalați semnături de diagnosticare pentru a depana o problemă
Utilizați Semnăturile de diagnosticare (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au creat mai multe semnături care permit debug-urile necesare pentru a depana o anumită problemă, a detecta apariția problemei, a colecta setul corect de date de diagnosticare și a transfera datele automat în carcasa Cisco TAC . Semnăturile de diagnosticare (DS) elimină necesitatea de a verifica manual apariția problemei și facilitează mult soluționarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare prin următorii pași:
Configurați o variabilă de mediu DS suplimentarăds_fsurl_prefix care este calea server de fișiere Cisco TAC (cxd.cisco.com) în care sunt încărcate datele de diagnosticare colectate. Numele de utilizator din calea fișierului este numărul cazului, iar parola este tokenul de încărcare fișier , care poate fi preluat din Asistență Case Manager în următoarea comandă. Tokenul de încărcare fișier poate fi generat în Atașamente secțiunea Support Case Manager, după caz.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând afișare snmp comandă . Dacă nu este activată, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Asigurați-vă că ați instalat DS 64224 pentru monitorizarea CPU ridicat ca o măsură proactivă pentru a dezactiva toate semnările de depanare și diagnosticare în timpul perioadei de utilizare ridicată a CPU . Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Syslog-uri
Tip problemă
Syslog - %VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0
Copiați fișierele DS XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișier XML DS 64224 și apoi DS 65095 pentru monitorizarea CPU înalt în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând aplicația afișați semnătura-diagnostic call-home comanda. Coloana de stare trebuie să aibă o valoare „înscrisă”.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_ LGW_ CPU_ MON75
0.0.10
Înscris
08.11.2020
65095
00:12:53
DS_ LGW_ IEC_ Call_spike_threshold
0.0.12
Înscris
08.11.2020
Verificați execuția semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a fișierului afișați semnătura-diagnostic call-home comanda trece la „rulare” în timp ce gateway-ul local execută acțiunea definită în semnătură. Ieșirea din afișați statisticile pentru semnătura de diagnosticare apel-home este cel mai bun mod de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și execută acțiunea. Coloana „Declanșat/Max/Deinstalare” indică de câte ori semnătura dată a declanșat un eveniment, de număr maxim de ori în care este definită detectarea unui eveniment și dacă semnătura se dezinstalează după detectarea număr maxim de evenimente declanșate.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_ LGW_ CPU_ MON75 | 0.0.10 | Înscris | 08.11.2020, 00:07:45 |
65095 | DS_ LGW_ IEC_ Call_spike_threshold | 0.0.12 | Rulare | 08-11-2020 00:12:53 |
afișați statisticile pentru semnătura de diagnosticare apel-home
ID DS | Nume DS | Declanșat /Max/Deinstall | Durată medie de rulare (secunde) | Durată maximă de rulare (secunde) |
---|---|---|---|---|
64224 | DS_ LGW_ CPU_ MON75 | 0/0/N | 0,000 | 0,000 |
65095 | DS_ LGW_ IEC_ Call_spike_threshold | 1 /20/A | 23.053 | 23.053 |
E-mailul de notificare care este trimis în timpul execuției semnăturii de diagnosticare conține informații cheie precum tipul problemei, detaliile dispozitivului, versiune software, configurația de rulare și ieșirile de afișare a comenzii care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizare Semnăturile de diagnosticare în scopuri de depanare sunt de obicei definite pentru a fi dezinstalate după detectarea unor probleme. Dacă doriți să dezinstalați manual o semnătură, recuperați ID-ul DS de la ieșirea din afișarea semnăturii de diagnosticare la domiciliu comandă și executați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic în Instrumentul de căutare semnături pentru diagnosticare, pe baza problemelor observate de obicei în implementări. TAC nu acceptă momentan solicitările de creare de noi semnături personalizate. |
Pentru o mai bună gestionare a gateway-urilor Cisco IOS XE, vă recomandăm să înscrieți și să gestionați gateway-urile prin Control Hub. Este o configurație opțională. Când sunteți înscris, puteți utiliza opțiunea de validare a configurației din Control Hub pentru a valida configurația Gateway-ului local și a identifica orice probleme de configurare. În prezent, numai trunchiurile bazate pe înregistrare acceptă această funcționalitate.
Pentru mai multe informații, consultați următoarele:
Această secțiune descrie modul de configurare a unui element de frontieră Unified Cisco (CUBE) ca gateway local pentru Webex Calling, utilizând trunchiul SIP TLS (mTLS) bazat pe certificate. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Următoarea imagine evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
cursanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup peer-dial: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine. Opțiunile sunt prevăzute pentru abordarea publică sau privată (în spatele NAT). Înregistrările DNS SRV sunt opționale, cu excepția cazului în care sarcina este echilibrată în mai multe instanțe CUBE.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe certificate necesită versiuni Cisco IOS XE 17.9.1a sau versiuni ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe de tehnologie de securitate.
Routerele din seria Catalyst Edge 8000 echipate cu carduri vocale sau DSPs necesită licențiere ADN Essentials. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Pentru cerințele de capacitate ridicată, puteți solicita, de asemenea, o licență de înaltă securitate (HSEC) și un drept suplimentar de tranzit.
Consultați Codurile de autorizare pentru detalii suplimentare.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
NTP
ACL-uri
Autentificare utilizator și acces la distanță
DNS
Rutare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4. Adresa locală Gateway Nume domeniu complet calificat (FQDN) sau Înregistrare serviciu (SRV) trebuie să se rezolve la o adresă IPv4 publică pe internet.
Toate porturile SIP și media de pe interfața Gateway Local cu care se confruntă Webex trebuie să fie accesibile de pe internet, fie direct, fie prin NAT static. Asigurați-vă că actualizați firewall-ul în mod corespunzător.
Instalați un certificat semnat pe gateway-ul local (următorul oferă pașii de configurare detaliați).
O autoritate publică de certificare (CA), așa cum este detaliată în Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platformele audio și video Cisco Webex? trebuie să semneze certificatul dispozitivului.
FQDN configurat în Control Hub atunci când se creează un trunchi trebuie să fie numele comun (CN) sau certificatul de nume alternativ al subiectului (SAN) al routerului. De exemplu:
Dacă un trunchi configurat în Control Hub al organizației dvs. are cube1.lgw.com:5061 ca FQDN al gateway-ului local, atunci CN sau SAN din certificatul router trebuie să conțină cube1.lgw.com.
Dacă un trunchi configurat în Control Hub al organizației dvs. are lgws.lgw.com ca adresa SRV a gateway-ului (gateway-urilor) local care poate fi accesată din trunchi, atunci CN sau SAN din certificatul router trebuie să conțină lgws.lgw.com. Înregistrările în care se rezolvă adresa SRV (CNAME, A Înregistrare sau IP Address) sunt opționale în SAN.
Indiferent dacă utilizați un FQDN sau un SRV pentru trunchi, adresa de contact pentru toate dialogurile SIP noi din gateway-ul local utilizează numele configurat în Control Hub.
Asigurați-vă că certificatele sunt semnate pentru utilizare client și server.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
| ||
2 | Protejați acreditările STUN pe router utilizând criptarea simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
| ||
3 | Creați un punct de încredere pentru criptare cu un certificat semnat de autoritatea de certificare preferată (CA). | ||
4 | Autentificați-vă noul certificat utilizând certificatul CA intermediar (sau rădăcină), apoi importați certificatul (Pasul 4). Introduceți următoarea comandă de exec sau configurare:
| ||
5 | Importați un certificat de gazdă semnat utilizând următoarea comandă exec sau de configurare:
| ||
6 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare:
| ||
7 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate:
|
1 | Creați un trunchi PSTN bazat pe certificat CUBE pentru o locație existentă în Control Hub. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling .
| ||||
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. permite conexiuni sip la sipActivați CUBE SIP de bază înapoi la funcționalitatea de agent de utilizator înapoi. Pentru mai multe informații, consultați Permiteți conexiuni .
Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata partajate-secret. sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcină utilă asimetrică . ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați ofertă anticipată . intrare profiluri sipPermite CUBE să utilizeze profiluri SIP pentru a modifica mesajele pe măsură ce acestea sunt primite. Profilurile sunt aplicate prin intermediul asociaților de apelare sau al chiriașilor. | ||||
3 | Configurare codec clasă vocală 100 filtru codec pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codeculclasei de voce.
| ||||
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: stunutilizaregheațăliteUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stunării clasei de voce și stun utilisation ice lite .
| ||||
5 | Configurați politica de criptare media pentru traficul Webex. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1 80._ Pentru mai multe informații, consultați clasa de voce srtp-crypto . | ||||
6 | Configurați cifrele GCM conforme cu FIPS (Acest pas se aplică numai pentru Webex for Government).
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică GCM ca suita cipher pe care CUBE o oferă. Este obligatorie configurarea criptelor GCM pentru gateway-ul local pentru Webex for Government. | ||||
7 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza destinației sale FQDN sau SRV:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați FQDN sau SRV LGW configurat în Control Hub în timp ce creați un trunchi. | ||||
8 | Configurați profilurile de manipulare a mesajelor SIP. Dacă gateway-ul dvs. este configurat cu o adresă IP publică, configurați un profil după cum urmează sau treceți la pasul următor dacă utilizați NAT. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local și „198.51.100.1” este adresa IP publică a interfeței gateway-ului local care se confruntă cu Webex Calling:
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive.
| ||||
9 | Dacă gateway-ul dvs. este configurat cu o adresă IP privată în spatele NAT statică, configurați profilurile SIP de intrare și de ieșire după cum urmează. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local, „10.80.13.12” este adresa IP de interfață cu care se confruntă Webex Calling și „192.65.79.20” este adresa IP publică NAT. Profiluri SIP pentru mesajele de ieșire către Webex Calling
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive. normele 30-81Convertiți referințele adresei private la adresa publică externă a site-ului, permițând Webex să interpreteze corect și să dirijeze mesajele ulterioare. Profil SIP pentru mesajele de intrare din Webex Calling
Iată o explicație a câmpurilor pentru configurare: normele 10-80Convertiți referințele adresei publice la adresa privată configurată, permițând procesarea corectă a mesajelor din Webex de către CUBE. Pentru mai multe informații, consultați profiluri pentru clasa de voce . | ||||
10 | Configurați un SIP Opțiuni în viață cu profilul de modificare a antetului.
Iată o explicație a câmpurilor pentru configurare: clasă vocală sip-opțiuni-keepalive 100Configurați un profil keepalive și intră în modul de configurare a clasei de voce. Puteți configura timpul (în secunde) la care un Ping SIP Out of Dialog Options este trimis către ținta de apelare atunci când conexiunea bătăilor inimii la punctul final este în stare în sus sau în jos. Acest profil Keepalive este declanșat din dial-peer-ul configurat către Webex. Pentru a vă asigura că antetele de contact includ numele de domeniu complet calificat SBC, se utilizează profilul SIP 115. Regulile 30, 40 și 50 sunt necesare numai atunci când SBC este configurat în spatele NAT statice. În acest exemplu, cube1.lgw.com este FQDN selectat pentru gateway-ul local și dacă se utilizează NAT static, „10.80.13.12” este adresa IP a interfeței SBC către Webex Calling și „192.65.79.20” este adresa IP publică NAT. | ||||
11 | Configurați trunchiul Webex Calling: |
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE. |
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI. |
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește un dial-peer VoIP cu eticheta de 300 și oferă o descriere semnificativă pentru o gestionare ușoară și depanare. Pentru mai multe informații, consultați voce dial-peer. model-destinație RĂU.PROBĂTEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați model-destinație (interfață) . protocol de sesiune sipv2Specifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocol de sesiune (dial peer) . țintă sesiune ipv4:192.168.80.13Indică adresă IPv4 țintă a destinației pentru a trimite segmentul de componentă apel. Ținta sesiunii aici este adresă IP a ITSP . Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP a PSTN adresă IP. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec de clasă voce . dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe segmentul de componentă apel. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
1 | Configurați următoarele URI pentru clase de voce: | ||
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM:
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. | ||
3 | Configurați următorii colegi de apelare: | ||
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe Cisco IOS XE și generează notificarea evenimentului prin e-mail, syslog sau mesaj terminal. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în carcasa Cisco TAC pentru a accelera timpul de rezoluție.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele de declanșare a problemei și acțiunile de informare, depanare și remediere a problemei. Utilizați mesajele syslog, evenimentele SNMP și prin monitorizarea periodică a ieșirilor specifice comenzii show pentru a defini logica de detectare a problemei. Tipurile de acțiune includ:
Colectarea ieșirilor comenzii show
Generarea unui fișier jurnal consolidat
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi serverul HTTPS, SCP, FTP
Inginerii TAC creează fișiere DS și le semnează digital pentru a proteja integritatea. Fiecare fișier DS are ID -ul numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o sursă unică de găsire a semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS din care descărcați DSLT . Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server SMTP(Simple Mail Transfer Protocol) de care aveți nevoie pentru ca gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați server SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway local care rulează IOS XE 17.6.1 sau o versiune ulterioară
Semnăturile de diagnosticare este activată implicit.
Configurați serverul de e-mail securizat pe care îl utilizați pentru a trimite notificări proactive dacă dispozitivul rulează IOS XE 17.6.1 sau o versiune ulterioară.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediuds_email cu adresa de e-adresă de e-mail a administratorului pentru a vă notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Instalați semnături de diagnosticare pentru o monitorizare proactivă
Monitorizarea gradului de utilizare ridicat al CPU
Acest DS urmărește utilizarea CPU timp de 5 secunde, folosind OID-ul SNMP 1.3.6.1.4.1.9.2.1.56. Când gradul de utilizare atinge 75% sau mai mult, acesta dezactivează toate remediile și dezinstalează toate semnăturile de diagnosticare pe care le instalați în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Asigurați-vă că ați activat SNMP utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în soluția Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail
Copiați fișier XML în flash-ul Gateway local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe gateway-ul local.
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)
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
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
Descărcați DS:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_ LGW_ CPU_ MON75
0.0.10
Înscris
07.11.2020 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv ea însăși. Dacă este necesar, vă rugăm să reinstalați DS 64224 pentru a continua să monitorizați gradul de utilizare ridicat al CPU pe gateway-ul local.
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează interogare SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erorile SIP 403, 488 și 503. Dacă numărul de erori este mai mare sau egal cu 5 din ultimul sondaj, acesta generează un syslog și o notificare prin e-mail. Vă rugăm să utilizați pașii de mai jos pentru a instala semnătura.
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Detectare deconectare anormală a apelurilor SIP cu notificare prin e- E-mail și Syslog.
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați comanda afișați semnătura-diagnostic call-home pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Instalați semnături de diagnosticare pentru a depana o problemă
De asemenea, puteți utiliza Semnăturile de diagnosticare (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au creat mai multe semnături care permit debug-urile necesare pentru a depana o anumită problemă, a detecta apariția problemei, a colecta setul corect de date de diagnosticare și a transfera datele automat în carcasa Cisco TAC . Acest lucru elimină necesitatea verificării manuale a apariției problemei și face mult depanarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare prin următorii pași:
Configurați o altă variabilă de mediu DSds_fsurl_prefix ca calea server de fișiere Cisco TAC (cxd.cisco.com) pentru a încărca datele de diagnosticare. Numele de utilizator din calea fișierului este numărul cazului, iar parola este tokenul de încărcare fișier , care poate fi preluat din Asistență Case Manager după cum se arată în cele ce urmează. Tokenul de încărcare fișier poate fi generat în Atașamente secțiunea Manager caz de asistență, după caz.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Vă recomandăm să instalați DS 64224 pentru monitorizarea CPU ridicat ca o măsură proactivă pentru a dezactiva toate semnările de depanare și diagnosticare în timpul perioadei de utilizare ridicată a CPU . Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Syslog-uri
Tip problemă
Syslog - %VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0
Copiați fișierele DS XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișier XML DS 64224 cu monitorizare CPU ridicată și apoi DS 65095 în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând afișarea semnăturii de diagnosticare la domiciliu. Coloana de stare trebuie să aibă o valoare „înscrisă”.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_ LGW_ CPU_ MON75
0.0.10
Înscris
2020-11-08:00:07:45
65095
00:12:53
DS_ LGW_ IEC_ Call_spike_threshold
0.0.12
Înscris
2020-11-08:00:12:53
Verificați execuția semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a comenzii afișați semnătura-diagnostic call-home trece la „rulare” în timp ce gateway-ul local execută acțiunea definită în semnătură. Ieșirea din afișați statisticile pentru semnătura de diagnosticare apel-home este cel mai bun mod de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și a executat acțiunea. Coloana „Declanșat/Max/Deinstalare” indică de câte ori semnătura dată a declanșat un eveniment, de număr maxim de ori în care este definită detectarea unui eveniment și dacă semnătura se dezinstalează după detectarea număr maxim de evenimente declanșate.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_ LGW_ CPU_ MON75 |
0.0.10 |
Înscris |
08.11.2020, 00:07:45 |
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
0.0.12 |
Rulare |
08-11-2020 00:12:53 |
afișați statisticile pentru semnătura de diagnosticare apel-home
ID DS | Nume DS | Declanșat /Max/Deinstall | Durată medie de rulare (secunde) | Durată maximă de rulare (secunde) |
---|---|---|---|---|
64224 | DS_ LGW_ CPU_ MON75 |
0/0/N |
0,000 |
0,000 |
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
1 /20/A |
23.053 |
23.053 |
E-mailul de notificare care este trimis în timpul execuției semnăturii de diagnosticare conține informații cheie precum tipul problemei, detaliile dispozitivului, versiune software, configurația de rulare și ieșirile de afișare a comenzii care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemei. Dacă doriți să dezinstalați manual o semnătură, preluați ID -ul DS din ieșirea lui afișați semnătura-diagnostic call-home și rulați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic în Instrumentul de căutare a semnăturilor pentru diagnosticare, pe baza problemelor observate în implementări. TAC nu acceptă momentan solicitările de creare de noi semnături personalizate. |
Fundamentale
Cerințe preliminare
Înainte de a implementa CUBE HA ca gateway local pentru Webex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
Layer 2 redundanță box-to-box cu CUBE Enterprise pentru păstrarea constantă a apelurilor
Orientările de configurare prevăzute în acest articol presupun o platformă locală de gateway dedicată, fără o configurație vocală existentă. Dacă o implementare CUBE existentă a întreprinderii este modificată pentru a utiliza și funcția gateway locală pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri existente și funcționalitățile nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită versiunea IOS-XE 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și funcțiile LGW.
Comenzile și jurnalele spectacolului din acest articol se bazează pe versiunea minimă de software a Cisco IOS-XE 16.12.2 implementată pe un vCUBE (CSR1000v). |
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diferite platforme:
Seria ISR 4K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE) — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Arhitectură preferată Cisco pentru Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Prezentare generală Soluție Webex Calling
Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud multi-tenant la serviciul de telefonie PBX prestabilit, cu mai multe opțiuni PSTN pentru clienți.
Implementarea gateway-ului local (reprezentată mai jos) se află în centrul acestui articol. Trunchiul gateway local (PSTN la sediu) în Webex Calling permite conexiunea la un serviciu PSTN deținut de client. Acesta oferă, de asemenea, conectivitate la o implementare IP PBX în rețeaua corporatistă , cum ar fi Cisco Unified CM. Toate comunicațiile către și din cloud sunt securizate prin intermediul transportului TLS pentru SIP și SRTP pentru mass-media.
Figura de mai jos afișează o implementare Webex Calling fără niciun PBX IP existent și se aplică unei implementări unice sau multi-site. Configurația prezentată în acest articol se bazează pe această implementare.
Nivelul 2 Redundanță Box-to-Box
Redundanța CUBE HA strat 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) pe interfețele respective și face schimb continuu de mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate de-a lungul perechii de routere care permit routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ iese din serviciu, ceea ce duce la păstrarea constantă a semnalizării și a mass-mediei.
Verificarea punctajului este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt bifate (de exemplu, o stare de încercare sau de apel). În acest articol, CUBE HA se va referi la CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundanță pentru păstrarea constantă a apelurilor |
Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca gateway local pentru implementările trunchiului Cisco Webex Calling (PSTN local) și vom acoperi considerațiile de proiectare și configurațiile din acest articol. Această cifră afișează o configurare tipică CUBE HA ca gateway local pentru o implementare trunchi Cisco Webex Calling.
Componentă Intra Grup de redundanță
Componenta Infra a Grupului de Redundanță (RG) oferă suport pentru infrastructura de comunicare box-to-box între cele două CUB-uri și negociază starea finală stabilă de redundanță. Această componentă oferă, de asemenea:
Un protocol de tip HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și salut între cele două CUBEs (prin interfața de control) - GigabitEthernet3 în figura de mai sus.
Un mecanism de transport pentru verificarea stării de semnalizare și media pentru fiecare apel de la router-ul activ la router-ul standby (prin interfața de date) - GigabitEthernet3 în figura de mai sus.
Configurarea și gestionarea interfeței Virtual IP (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie configurată special pentru a sprijini vocea B2B HA.
Gestionarea adreselor IP virtuale (VIP) atât pentru semnalizare, cât și pentru media
B2B HA se bazează pe VIP pentru a obține redundanță. Interfețele fizice VIP și asociate pe ambele CUBE din perechea CUBE HA trebuie să reziste pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație vocală (SIP) sunt obligatorii pentru asistența vocală B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling Access SBC, furnizorul de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care trec prin routerele CUBE HA. Prin urmare, din punct de vedere Webex Calling, perechile CUBE HA acționează ca un singur gateway local.
Semnalizarea apelurilor și informațiile despre sesiunea RTP ale apelurilor stabilite sunt verificate de la routerul activ la routerul standby. Când routerul Activ coboară, routerul Standby preia și continuă să redirecționeze fluxul RTP care a fost direcționat anterior de primul router.
Apelurile într-o stare tranzitorie în momentul nereușitei nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt pe deplin stabilite încă sau sunt în curs de modificare cu o funcție de transfer sau de menținere. Apelurile configurate pot fi deconectate după comutare.
Următoarele cerințe există pentru utilizarea CUBE HA ca gateway local pentru defalcarea statică a apelurilor:
CUBE HA nu poate avea interfețe TDM sau analogice co-localizate
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP/RTP) și Gig3 este Redundancy Group (RG) Control/interfață de date
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu strat 2, unul cu id de grup 1 și celălalt cu id de grup 2. Dacă configurați 2 perechi HA cu același id de grup, interfețele RG Control/Date trebuie să aparțină diferitelor domenii din stratul 2 (vlan, comutator separat)
Canalul portuar este acceptat atât pentru controlul RG/date, cât și pentru interfețele de trafic
Toate semnalele/mass-media sunt obținute de la/la adresa IP virtuală
Oricând o platformă este reîncărcată într-o relație CUBE-HA, ea începe întotdeauna ca Standby
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
Identificatorul interfeței de redundanță, rii trebuie să fie unic pentru o combinație pereche/interfață în același strat 2
Configurația pe ambele CUBEs trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
Interfețele Loopback nu pot fi utilizate ca legături, deoarece acestea sunt întotdeauna în sus
Interfețele de trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea monitorizării interfeței
CUBE-HA nu este acceptată printr-o conexiune prin cablu încrucișată pentru link-ul RG-control/date (Gig3)
Ambele platforme trebuie să fie identice și să fie conectate printr-o Comutator fizic pe toate interfețele la fel pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
Nu se poate termina WAN pe CUBEs direct sau Data HA pe nici o parte
Ambele active/standby trebuie să fie în același centru de date
Este obligatoriu să se utilizeze o interfață L3 separată pentru redundanță (RG Control/date, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru keepalives HA și puncte de control
După eșec, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media
Configurați redundanța pe Ambele CUBE-uri
Trebuie să configurați redundanța de la 2 la 2 pe ambele CUBEs destinate utilizării într-o pereche HA pentru a aduce IPs virtuale.
1 | Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât traseul activ va juca destul de rolul său activ după ce interfața de trafic este în jos. | ||||||
2 | Configurați un RG pentru utilizare cu VoIP HA în submodul de redundanță al aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||||||
3 | Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG din pasul anterior de mai jos
redundanță-grup 1—Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să intre în vigoare. Vom reîncărca platformele după ce toate configurațiile au fost aplicate. | ||||||
4 | Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, după cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||||||
5 | Salvați configurația primului CUBE și reîncărcați-l. Platforma pentru a reîncărca ultima este întotdeauna standby.
După ce VCUBE-1 cizme complet, salvați configurația VCUBE-2 și reîncărcați-l.
| ||||||
6 | Verificați dacă configurația cutie-la-cutie funcționează conform așteptărilor. Ieșirea relevantă este evidențiată în îndrăzneală. Am reîncărcat ultimul VCUBE-2 și conform considerațiilor de proiectare; platforma de reîncărcare va fi întotdeauna în așteptare.
|
Configurați un gateway local pe Ambele CUBE-uri
În configurația exemplului nostru, folosim următoarele informații despre trunchiuri din Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt următoarele:
Nume utilizator: Hussain1076_LGU
Parolă: lOV12MEaZx
1 | Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditările sau secretele partajate. Parolele de tip 6 sunt criptate folosind AES cipher și această cheie de configurare definită de utilizator.
Iată configurația gateway-ului local care se va aplica ambelor platforme pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. Datele de autentificare SIP Digest din Control Hub sunt evidențiate în mod îndrăzneț.
Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând VCUBE-1 standby-ul CUBE și VCUBE-2 CUBE activ |
2 | În orice moment dat, o singură platformă va menține o înregistrare activă ca gateway local cu accesul Webex Calling SBC. Aruncați o privire la ieșirea din următoarele comenzi spectacol. afișați grupul de aplicații de redundanță 1 afișați starea înregistrării sip-ua
Din ieșirea de mai sus, puteți vedea că VCUBE-2 este LGW-ul activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea „afișează starea de înregistrare sip-ua” este necompletată în VCUBE-1 |
3 | Acum activați următoarele depanări pe VCUBE-1
|
4 | Simulați eșecul prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.
Trecerea de la ACTIVE la STANDBY LGW are loc în scenariul următor, precum și în afara CLI enumerate mai sus
|
5 | Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling Access SBC. VCUBE-2 s-ar fi reîncărcat până acum.
VCUBE-1 este acum LGW-ul activ. |
6 | Uitați-vă la jurnalul de depanare relevant din VCUBE-1 care trimite un ÎNREGISTRATOR SIP către Webex Calling PRIN IP-ul virtual și primește un OK 200.
|
Configurați profilul de securitate al trunchiurilor SIP pentru trunchiuri la gateway-ul local
În cazurile în care gateway-ul local și gateway-ul PSTN se află pe același dispozitiv, Unified CM trebuie să fie activat pentru a diferenția între două tipuri diferite de trafic (apeluri de la Webex și de la PSTN) care provin de la același dispozitiv și aplică o clasă de servicii diferențiată pentru aceste tipuri de apeluri. Acest tratament diferențiat al apelurilor se realizează prin asigurarea a două trunchiuri între Unified CM și gateway-ul local combinat și gateway-ul PSTN, care necesită diferite porturi SIP de ascultare pentru cele două trunchiuri.
Creați un profil de securitate dedicat trunchiului SIP pentru trunchiul gateway local cu următoarele setări:
|
Configurați profilul SIP pentru trunchiul gateway local
Creați un profil SIP dedicat trunchiului gateway local cu următoarele setări:
|
Creați un spațiu de căutare pentru apeluri din Webex
Creați un spațiu de căutare pentru apeluri care provin din Webex cu următoarele setări:
|
Configurați un trunchi SIP la și de la Webex
Creați un trunchi SIP pentru apelurile către și de la Webex prin gateway-ul local cu următoarele setări:
|
Configurați grupul de rutare pentru Webex
Creați un grup de rute cu următoarele setări:
|
Configurați lista de rutare pentru Webex
Creați o listă de rute cu următoarele setări:
|
Creați o partiție pentru Webex Destinations
Creați o partiție pentru destinațiile Webex cu următoarele setări:
|
Ce este de făcut în continuare
Asigurați-vă că adăugați această partiție în toate spațiile de căutare prin apelare care ar trebui să aibă acces la destinațiile Webex. Trebuie să adăugați această partiție în mod specific în spațiul de căutare pentru apelare utilizat ca spațiu de căutare pentru apelare de intrare pe trunchiurile PSTN, astfel încât apelurile din PSTN către Webex să poată fi direcționate.
Configurați modelele de rută pentru destinațiile Webex
Configurați modelele de rute pentru fiecare interval DID pe Webex cu următoarele setări:
|
Configurați standardizarea abreviată a apelurilor intersite pentru Webex
Dacă apelarea inter-site abreviată este necesară pentru Webex, configurați modelele de normalizare a apelării pentru fiecare interval ESN din Webex cu următoarele setări:
|
Configurați un grup de hunt
Grupurile de hunt direcționează apelurile primite către un grup de utilizatori sau către spații de lucru. Puteți chiar să configurați un model pentru a ruta către un întreg grup.
Pentru mai multe informații despre configurarea unui grup de hunt, consultați Grupuri de vânătoare în Cisco Webex Control Hub .
Creați o coadă de apeluri
Puteți configura o coadă de apeluri astfel încât, atunci când apelurile clienților nu pot fi preluate, aceștia să beneficieze de un răspuns automat, mesaje de confort și muzică în așteptare până când cineva își poate răspunde la apel.
Pentru mai multe informații despre configurarea și gestionarea unei secvențe de apeluri, consultați Gestionați cozile de apeluri în Cisco Webex Control Hub .
Creați un client recepționer
Ajutați-vă să susțineți nevoile personalului de la biroul din față. Puteți configura utilizatorii ca însoțitori telefonici, astfel încât aceștia să poată filtra apelurile primite către anumite persoane din organizația dvs.
Pentru informații despre configurarea și vizualizarea clienților recepționeri, consultați Clienți-recepționeri în Cisco Webex Control Hub .
Creați și gestionați operatorii automati
Puteți să adăugați mesaje de felicitare, să configurați meniuri și să dirijare apeluri către un serviciu telefonic, un grup de hunt, o căsuță poștă vocală sau o persoană reală. Creați un program de 24 de ore pe zi sau oferiți diferite opțiuni atunci când afacerea dvs. este deschisă sau închisă.
Pentru informații despre crearea și gestionarea operatorilor automati, consultați Gestionați operatorii automati în Cisco Webex Control Hub .
Configurați un grup de difuzare
Apelarea de grup permite unui utilizator să efectueze un apel unidirecțional sau o pagină de grup către până la 75 de utilizatori și spații de lucru țintă prin formarea unui număr sau a unui interior alocat unui anumit grup de difuzare.
Pentru informații despre configurarea și editarea grupurilor de difuzare, consultați Configurați un grup de difuzare în Cisco Webex Control Hub .
Configurați preluarea apelurilor
Îmbunătățiți munca în echipă și colaborarea prin crearea unui grup de preluare apel, astfel încât utilizatorii să își poată răspunde reciproc la apelurile. Când adăugați utilizatori într-un grup de preluare apel și un membru al grupului este absent sau ocupat, un alt membru poate răspunde la apelurile acestora.
Pentru informații despre configurarea unui grup de preluare apel, consultați Preluare apeluri în Cisco Webex Control Hub .
Configurați parcarea apelurilor
Parcarea apelurilor permite unui grup definit de utilizatori să parcheze apelurile împotriva altor membri disponibili ai unui grup de parcare a apelurilor. Apelurile parcate pot fi preluate de alți membri ai grupului pe telefonul lor.
Pentru mai multe informații despre configurarea parcării apelurilor, consultați Parcare apel în Cisco Webex Control Hub .
Activați barge-in pentru utilizatori
1 | Din vizualizarea clientului din , accesați Apelarea > locații.https://admin.webex.com |
2 | Selectați un utilizator și faceți clic pe Apelare. |
3 | Accesați secțiunea Permisiuni între utilizatori , apoi selectați Barge. |
4 | Activați comutatorul pentru a permite altor utilizatori să se adauge la apelul în curs al acestui utilizator. |
5 | Verificați Redați un ton atunci când acest utilizator intră într-un apel dacă doriți să redați un ton altor persoane atunci când acest utilizator intră în apel. |
6 | Faceți clic pe Salvați. |
Activați confidențialitatea pentru un utilizator
1 | Conectați-vă la Control Hub și accesați . | ||
2 | Alegeți un utilizator și faceți clic pe Apelare. | ||
3 | Accesați zona Permisiuni între utilizatori și apoi alegeți Confidențialitate. | ||
4 | Alegeți cel adecvat Confidențialitate operator automat setări pentru acest utilizator.
| ||
5 | Verificați Activați Confidențialitate casetă de selectare. Apoi, puteți decide să blocați pe toată lumea, nealegând membri din lista derulantă. Alternativ, puteți alege utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei acestui utilizator. Dacă sunteți administrator de locație, în lista derulantă apar numai utilizatorii, spațiile de lucru și liniile virtuale referitoare la locațiile atribuite. Debifați caseta de selectare Activare confidențialitate pentru a permite tuturor să monitorizeze starea liniei. | ||
6 | Verificați Confidențialitatea impunerii pentru preluarea apelurilor direcționate și caseta de selectare pentru înscriere pentru a activa confidențialitatea pentru preluarea apelurilor direcționate și înscriere.
| ||
7 | Din Adăugați membru după nume, alegeți utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei telefonice și pot invoca preluarea apelurilor direcționate și intrarea în rețea. | ||
8 | Pentru a filtra membrii pe care îi selectați, utilizați filtrul după nume, număr sau câmp text. | ||
9 | Faceți clic pe Eliminare toate pentru a elimina toți membrii selectați.
| ||
10 | Faceți clic pe Salvați. |
Configurați monitorizarea
Numărul maxim de linii monitorizate pentru un utilizator este de 50. Cu toate acestea, în timp ce configurați lista de monitorizare, luați în considerare numărul de mesaje care afectează lățimea de bandă dintre Webex Calling și rețeaua dvs. De asemenea, determinați liniile maxime monitorizate de numărul de butoane de linie de pe telefonul utilizatorului.
1 | Din vizualizarea clientului din https://admin.webex.com, accesați Management și apoi faceți clic pe Utilizatori. | ||||
2 | Selectați utilizatorul pe care doriți să îl modificați și faceți clic Apelare . | ||||
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Monitorizare. | ||||
4 | Alegeți dintre următoarele:
Puteți include o linie virtuală în lista Adăugare linie monitorizată pentru monitorizarea utilizatorului. | ||||
5 | Alegeți dacă doriți să notificați acest utilizator despre apelurile parcate, căutați persoana sau extensia de parcare a apelurilor care urmează să fie monitorizată, apoi faceți clic pe Salvare.
|
Activați tonul de avertizare prin punte de apel pentru utilizatori
Înainte de a începe
1 | Conectați-vă la Control Hub și accesați . | ||
2 | Selectați un utilizator și faceți clic pe fila Apelare. | ||
3 | Accesați Permisiuni între utilizatori și faceți clic pe Call Bridging Warning Tone. | ||
4 | Porniți Ton de avertizare pentru trecerea apelurilor , apoi faceți clic Salvați .
Pentru mai multe informații despre conectarea la apel pe o linie MPP partajată, consultați liniile partajate de pe telefonul dvs. de birou pentru mai multe platforme. Pentru mai multe informații despre conectarea apelurilor pe o linie partajată a aplicației Webex, consultați aspectul liniei partajate pentru WebexApp. |
Activați hotelizarea pentru un utilizator
1 | Din vizualizarea clientului înhttps://admin.webex.com , accesați Management și selectați Utilizatori . | ||
2 | Selectați un utilizator și faceți clic pe fila Apelare. | ||
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Hoteling și activați comutatorul. | ||
4 | Introduceți numele sau numărul gazdei hotelului în câmpul de căutare Hotel Location și alegeți gazda hotelului pe care doriți să o alocați utilizatorului. Poate fi selectată o singură gazdă hotelieră. Dacă alegeți o altă gazdă hotelieră, prima este ștearsă.
| ||
5 | Pentru a limita timpul în care un utilizator poate fi asociat cu gazda hotelului, alegeți numărul de ore pe care utilizatorul le poate utiliza gazda hotelului din lista derulantă Limit Association Period . Utilizatorul va fi deconectat automat după ora aleasă.
| ||
6 | Faceți clic pe Salvați.
|
Vizualizați rapoartele privind apelurile
Puteți utiliza pagina Analytics în Control Hub pentru a obține o perspectivă asupra modului în care oamenii utilizează Webex Calling și Webex aplicație (implicare) și calitatea experienței lor media de apel. Pentru a accesa Webex Calling analytics, conectați-vă la Control Hub , apoi accesați Analytics și selectați Apelare filă.
1 | Pentru rapoarte detaliate privind istoricul apelurilor, conectați-vă la Control Hub , apoi accesați Analytics > Apelare . |
2 | Selectați Istoric detaliat apeluri . Pentru informații despre apelurile care utilizează Instanța dedicată, consultați Analiză de instanță dedicată . |
3 | Pentru a accesa date de calitate media, conectați-vă la Control Hub , apoi accesați Analytics și apoi selectați Apelare . Pentru mai multe informații, consultați Statistici pentru portofoliul dvs. de colaborare în cloud.
|
Rulați instrumentul CScan
CScan este un instrument de pregătire a rețelei, conceput pentru a vă testa conexiune la rețea Webex Calling .
Pentru mai multe informații, consultați Utilizați CScan pentru a testa calitatea rețelei Webex Calling . |
Condiţii generale
Înainte de a configura un gateway local pentru Webex Calling, asigurați-vă că:
Cunoașterea de bază a principiilor VoIP
Cunoașterea de bază a conceptelor de voce Cisco IOS-XE și IOS-XE
Să înțelegeți de bază Protocolul de inițiere sesiuni (SIP)
Aveți o înțelegere de bază a Cisco Unified Communications Manager (Unified CM) dacă modelul dvs. de implementare include Unified CM
Consultați Ghidul de configurare Enterprise Cisco Unified Border Element (CUBE) pentru detalii.
Cerințe hardware și software pentru gateway-ul local
Asigurați-vă că implementarea are una sau mai multe dintre gateway-urile locale, cum ar fi:
Cisco CUBE pentru conectivitate bazată pe IP
Gateway Cisco IOS pentru conectivitate bazată pe TDM
Gateway-ul local vă ajută să migrați la Webex Calling în ritmul propriu. Gateway-ul local integrează implementarea locală existentă cu Webex Calling. De asemenea, puteți utiliza conexiunea PSTN existentă. Consultați Începeți cu gateway-ul local
Cerințe de licență pentru gateway-urile locale
Licențele de apelare CUBE trebuie instalate pe gateway-ul local. Pentru mai multe informații, consultați Ghidul de configurare a elementului de frontieră Cisco Unified.
Cerințe de certificare și securitate pentru gateway-ul local
Webex Calling necesită semnalizare și media securizate. Gateway-ul local efectuează criptarea, iar o conexiune TLS trebuie să fie stabilită la ieșirea din cloud cu următorii pași:
LGW trebuie actualizat cu pachetul rădăcină CA de la Cisco PKI
Se utilizează un set de date de autentificare SIP digest din pagina de configurare trunchiuri a Control Hub pentru a configura LGW (pașii fac parte din configurația care urmează)
Validează pachetul rădăcină CA prezentat certificat
Solicitată pentru datele de autentificare (SIP Digest furnizat)
Cloud-ul identifică care gateway-ul local este înregistrat în siguranță
Firewall, NAT Traversal și cerințele de optimizare a căilor media pentru gateway-ul local
În cele mai multe cazuri, gateway-ul local și punctele finale pot locui în rețeaua de clienți interni, folosind adrese IP private cu NAT. Firewall-ul întreprinderii trebuie să permită traficul de ieșire (SIP, RTP/UDP, HTTP) către anumite adrese IP/porturi, acoperite de informațiile de referință portuare.
Dacă doriți să utilizați Optimizarea căilor media cu ICE, interfața cu care se confruntă Webex Calling a gateway-ului local trebuie să aibă o cale de rețea directă către și de la punctele finale Webex Calling. Dacă punctele finale se află într-o locație diferită și nu există o cale de rețea directă între punctele finale și interfața Webex Calling cu care se confruntă gateway-ul local, atunci gateway-ul local trebuie să aibă o adresă IP publică atribuită interfeței cu care se confruntă Webex Calling pentru apeluri între gateway-ul local și punctele finale pentru a utiliza optimizarea căii media. În plus, trebuie să fie rulează iOS-XE versiunea 16.12.5.
Primul pas pentru a vă obține Webex Calling servicii de funcționare este de a finaliza Asistentul pentru prima configurare (FTSW). Odată ce FTSW este finalizat pentru prima locație, nu trebuie să fie finalizat pentru locații suplimentare.
1 | Faceți clic pe Primii pași linkul din e-mailul de bun venit pe care îl primiți.
| ||
2 | Consultați și acceptați condițiile de furnizare a serviciilor și condițiile . | ||
3 | Examinați-vă planul și apoi faceți clic Începeți .
| ||
4 | Selectați țara în care ar trebui să mapați centru de date și introduceți informațiile de contact client și adresa clientului. | ||
5 | Faceți clic pe Înainte. Locație implicită: | ||
6 | Alegeți dintre următoarele opțiuni:
| ||
7 | Efectuați următoarele selecții pentru a aplica în această locație:
| ||
8 | Faceți clic pe Înainte. | ||
9 | Introduceți o adresă Cisco Webex SIP disponibilă și faceți clic În continuare și selectați Terminați . |
Înainte de a începe
Pentru a crea o locație nouă, pregătiți următoarele informații:
Adresă locație
Numere de telefon dorite (opțional)
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați .
| ||||
2 | Configurați setările locației:
| ||||
3 | Faceți clic Salvați și apoi alegeți Da / Nu pentru a adăuga numere la locație acum sau mai târziu. | ||||
4 | Dacă ați făcut clic Da , alegeți una dintre următoarele opțiuni:
Alegerea opțiunii PSTN este la fiecare nivel de locație (fiecare locație are o singură opțiune PSTN). Puteți combina câte opțiuni doriți pentru implementare, dar fiecare locație va avea o opțiune. După ce ați selectat și ați configurat o opțiune PSTN, puteți să o modificați făcând clic Gestionați în proprietățile PSTN ale locației. Cu toate acestea, unele opțiuni, cum ar fi Cisco PSTN, pot să nu fie disponibile după ce a fost atribuită o altă opțiune. Deschideți un caz de asistență pentru îndrumare. | ||||
5 | Alegeți dacă doriți să activați numerele acum sau mai târziu. | ||||
6 | Dacă ați selectat non-integrated CCP sau Premises-based PSTN, introduceți Numere de telefon ca valori separate prin virgulă, apoi faceți clic Validați . Numerele sunt adăugate pentru locația specifică. Intrările valide se mută în Numere validate câmp, iar intrările nevalide rămân în câmpul Adăugare numere câmp însoțit de un mesaj de eroare. În funcție de țara locației, numerele sunt formatate în funcție de cerințele locale de apelare. De exemplu, dacă este necesar un cod de țară, puteți introduce numere cu sau fără cod, iar codul este adăugat înainte. | ||||
7 | Faceți clic pe Salvați. |
Ce este de făcut în continuare
După ce creați o locație, puteți activa serviciile 911 de urgență pentru locația respectivă. Vedeți Serviciu RedSky 911 de urgență pentru Webex Calling pentru mai multe informații.
Înainte de a începe
Obțineți o listă a utilizatorilor și a spațiilor de lucru asociate cu o locație: Accesați ștergeți acești utilizatori și spațiile de lucru înainte de a șterge locația. iar din meniu derulant, selectați locația de șters. TrebuieRețineți că orice numere asociate cu această locație vor fi returnate furnizorului dvs. PSTN; nu veți mai deține acele numere. |
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . |
2 | Clic |
3 | Alegeți Ștergeți locația , și confirmați că doriți să ștergeți locația respectivă. De obicei, durează câteva minute pentru ca locația să fie ștearsă definitiv, dar poate dura până la o oră. Puteți verifica starea făcând clic lângă numele locației și selectând Stare ștergere . |
După crearea acesteia, puteți modifica configurația PSTN, numele, ora locală și limba unei locații. Rețineți totuși că noua limbă se aplică numai utilizatorilor și dispozitivelor noi. Utilizatorii și dispozitivele existențe continuă să utilizeze limba veche.
Pentru locațiile existente, puteți activa serviciile 911 de urgență. Vedeți Serviciu RedSky 911 de urgență pentru Webex Calling pentru mai multe informații. |
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . Dacă vedeți un simbol Atenție lângă o locație, înseamnă că nu ați configurat încă un număr de telefon pentru locația respectivă. Nu puteți efectua sau primi apeluri până când nu configurați numărul respectiv. | ||||||
2 | (Opțional) Sub Conexiune PSTN , selectați oricare PSTN conectat la cloud sau PSTN la sediu (gateway local), în funcție de cel pe care l-ați configurat deja. Faceți clic Gestionați pentru a modifica configurația respectivă și apoi recunoașteți riscurile asociate prin selectare Continuați . Alegeți una dintre următoarele opțiuni și apoi faceți clic Salvați :
| ||||||
3 | Selectați Număr principal la care poate fi contactat principalul contact al locației. | ||||||
4 | (Opțional) Sub Apelare de urgență , puteți selecta Identificator locație de urgență pentru a atribui acestei locații.
| ||||||
5 | Selectați Număr mesagerie vocală pe care utilizatorii le pot apela pentru a-și verifica mesageria vocală pentru această locație. | ||||||
6 | (Opțional) Faceți clic pe pictograma creion din partea de sus a paginii Locație pentru a modifica Nume locație , Limba anunțului , Limbă E-mail , Fus orar , sau Adresă după cum este necesar, apoi faceți clic Salvați .
|
Aceste setări sunt pentru apelarea internă și sunt disponibile și în expertul de configurare pentru prima dată. Pe măsură ce modificați planul de apelare, numerele de exemplu din actualizarea Control Hub pentru a afișa aceste modificări.
Puteți configura permisiunile de apelare de ieșire pentru o locație. Vedeți acești pași pentru a configura permisiunile de apelare de ieșire. |
1 | Conectați-vă la Control Hub, accesați , apoi defilați la apelare internă. | ||||||||
2 | Configurați următoarele preferințe de apelare opționale, după cum este necesar:
| ||||||||
3 | Specificați apelarea internă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea internă după cum este necesar: , selectați o locație din listă și faceți clic pe
| ||||||||
4 | Specificați apelarea externă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea externă după cum este necesar: , selectați o locație din listă și faceți clic pe
Impact asupra utilizatorilor:
|
Dacă sunteți un reseller cu valoare adăugată, puteți utiliza acești pași pentru a începe configurarea gateway local în Control Hub . Când acest gateway este înregistrat în cloud, îl puteți utiliza pe unul sau mai multe dintre dvs Webex Calling locații pentru a oferi rutare către un furnizor serviciu PSTN enterprise .
O locație care are un gateway local nu poate fi ștearsă atunci când gateway local este utilizat pentru alte locații. |
Înainte de a începe
Odată ce o locație este adăugată și înainte de a configura PSTN local pentru o locație, trebuie să creați un trunchi.
Creați orice locații și setări și numere specifice pentru fiecare dintre ele. Locațiile trebuie să existe înainte de a putea adăuga un PSTN local.
Înțelegeți cerințele PSTN (gateway local) în sediul pentru Webex Calling .
Nu puteți alege mai mult de un trunchi pentru o locație cu PSTN local, dar puteți alege același trunchi pentru mai multe locații.
1 | Conectați-vă la Control Hub la , accesați Servicii > Apelare > Dirijarea apelurilor , și selectați Adăugare trunchi .https://admin.webex.com | ||
2 | Selectați o locație. | ||
3 | Denumiți trunchiul și faceți clic Salvați .
|
Ce este de făcut în continuare
Informațiile privind trunchiul apar pe ecran Înregistrare domeniu, grup trunchi OTG/DTG, linie/port , Adresă proxy de ieșire .
Vă recomandăm să copiați aceste informații din Control Hub și inserați-l într-un fișier text local sau un document, astfel încât să puteți face referire la acesta atunci când sunteți gata să configurați gateway local.
Dacă pierdeți acreditările, trebuie să le regenerați din ecranul cu informații despre trunchi din Control Hub. Faceți clic Preluați numele de utilizator și resetarea parolei pentru a genera un nou set de date de autentificare de utilizat pe trunchi.
1 | Conectați-vă la Control Hub lahttps://admin.webex.com , accesați . | ||
2 | Selectați o locație de modificat și faceți clic Gestionați . | ||
3 | Selectați PSTN la sediu și faceți clic În continuare . | ||
4 | Alegeți un trunchi din meniu derulant.
| ||
5 | Faceți clic pe notificarea de confirmare, apoi faceți clic Salvați . |
Ce este de făcut în continuare
Trebuie să luați informație de configurare care Control Hub a generat și mapați parametrii în gateway local (de exemplu, pe un Cisco CUBE care se află în incintă). Acest articol vă ghidează prin acest proces. Ca referință, consultați următoarea diagramă pentru un exemplu despre modul în care Control Hub informație de configurare (din stânga) se asociază cu parametrii din CUBE (pe dreapta):
După ce ați finalizat cu succes configurația pe gateway-ul propriu-zis, puteți reveni la Servicii > Apelați > Locații în Control Hub iar gateway-ul pe care l-ați creat va fi afișat în cardul de locație căruia i-ați alocat-o cu un punct verde în stânga numelui.
Această stare indică faptul că gateway-ul este înregistrat securizat în cloud-ul de apelare și că servește ca gateway PSTN activ pentru locație.Puteți vizualiza, activa, elimina și adăuga cu ușurință numere de telefon pentru organizația dvs. în Control Hub . Pentru mai multe informații, consultați Gestionați numerele de telefon în Control Hub .
Dacă încercați serviciile Webex și doriți să transformați perioada de încercare într-un abonament cu plată, puteți trimite o solicitare prin e-mail partenerului dvs.
1 | Conectați-vă la Control Hub la https://admin.webex.com, selectați pictograma de construcție |
2 | Selectați Abonamente filă, apoi faceți clic Achiziționați acum . Partenerul dvs. îi este trimis un e-mail prin care îl informează că sunteți interesat să treceți la un abonament cu plată. |
Puteți utiliza Control Hub pentru a seta prioritatea opțiunilor de apelare disponibile pe care le văd utilizatorii în Aplicația Webex . Le puteți activa și pentru un singur clic pentru apelare. Pentru mai multe informații, consultați: Setați opțiunile de apelare pentru utilizatorii aplicației Webex .
Puteți controla ce aplicație de apelare se deschide atunci când utilizatorii efectuează apeluri. Puteți configura setările clientului apelant, inclusiv implementarea în mod mixt pentru organizații cu utilizatori cu drepturi de utilizare Unified CM sau Webex Calling și utilizatorii fără servicii de apelare cu plată de la Cisco. Pentru mai multe informații, consultați: Configurați comportamentul de apelare.
Prezentare generală
Webex Calling acceptă în prezent două versiuni ale gateway-ului local:
Gateway local
Gateway local pentru Webex for Government
Înainte de a începe, înțelegeți cerințele locale privind rețeaua de telefonie publică comutată (PSTN) și gateway-ul local (LGW) pentru Webex Calling. Vedeți Arhitectură Cisco Preferred pentru Webex Calling pentru mai multe informații.
Acest articol presupune că există o platformă gateway locală dedicată, fără nicio configurație vocală existentă. Dacă modificați un gateway PSTN existent sau implementarea CUBE Enterprise pentru a-l utiliza ca funcție a gateway-ului local pentru Webex Calling, acordați o atenție deosebită configurației. Asigurați-vă că nu întrerupeți fluxurile de apeluri existente și funcționalitatea din cauza modificărilor pe care le efectuați.
Procedurile conțin link-uri către documentația de referință a comenzii, unde puteți afla mai multe despre opțiunile individuale ale comenzii. Toate linkurile de referință la comandă merg la Referință pentru comandă Webex Managed Gateways cu excepția cazului în care se specifică altfel (caz în care, linkurile de comandă merg la Referință pentru comandă vocală Cisco IOS ). Puteți accesa toate aceste ghiduri la Cisco Unified Border Element Command References. Pentru informații privind SBC-urile terță parte acceptate, consultați documentația de referință a produsului respectivă. |
Există două opțiuni de configurare a gateway-ului local pentru dvs Webex Calling trunchi:
Trunchi bazat pe înregistrare
Trunchi bazat pe certificat
Utilizați fluxul de activități fie sub Gateway local bazat pe înregistrare sau Gateway local bazat pe certificat pentru a configura Local Gateway pentru dvs Webex Calling trunchi.
Consultați Începeți cu gateway-ul local pentru mai multe informații despre diferite tipuri de trunchiuri. Efectuați următorii pași pe gateway-ul local propriu-zis, utilizând Command Line Interface (CLI). Utilizăm Protocol de inițiere sesiuni (SIP) și transportul TLS ( Securitate strat de transport ) pentru a securiza trunchiul și protocolul securizat în timp real ( SRTP) pentru a securiza media dintre gateway-ul local și Webex Calling .
Selectați CUBE ca Gateway local. Webex for Government nu acceptă în prezent niciun controler de frontieră pentru sesiune terță (SBC). Pentru a revizui cea mai recentă listă, consultați Începeți cu gateway-ul local.
- Instalați versiunile Cisco IOS XE Dublin 17.12.1a sau versiuni ulterioare pentru toate gateway-urile locale Webex for Government.
Pentru a revizui lista autorităților de certificare rădăcină (AC) care acceptă Webex for Government, consultați autoritățile de certificare rădăcină pentru Webex for Government.
Pentru detalii despre intervalele de porturi externe pentru gateway-ul local din Webex for Government, consultați cerințele rețelei pentru Webex for Government (FedRAMP).
Gateway-ul local pentru Webex for Government nu acceptă următoarele:
STUN/ICE-Lite pentru optimizarea căii media
Fax (T.38)
Pentru a configura gateway-ul local pentru trunchiul dvs. Webex Calling în Webex for Government, utilizați următoarea opțiune:
Trunchi bazat pe certificat
Utilizați fluxul de activități din gateway-ul local bazat pe certificat pentru a configura gateway-ul local pentru trunchiul Webex Calling. Pentru mai multe detalii despre modul de configurare a unui gateway local bazat pe certificate, consultați Configurați trunchiul bazat pe certificate Webex Calling.
Este obligatoriu să configurați criptoare GCM conforme cu FIPS pentru a sprijini gateway-ul local pentru Webex for Government. Dacă nu, configurarea apelului eșuează. Pentru detalii de configurare, consultați Configurați trunchiul bazat pe certificatul Webex Calling.
Webex for Government nu acceptă gateway-ul local bazat pe înregistrare. |
Această secțiune descrie modul de configurare a unui element de frontieră Cisco Unified (CUBE) ca gateway local pentru Webex Calling, utilizând un trunchi SIP de înregistrare. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Imaginea de mai jos evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
cursanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup peer-dial: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe înregistrare necesită versiuni Cisco IOS XE 17.6.1a sau ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe de tehnologie de securitate.
Routerele din seria Catalyst Edge 8000 echipate cu carduri vocale sau DSPs necesită acordarea licenței DNA Advantage. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
NTP
ACL-uri
Autentificare utilizator și acces la distanță
DNS
Rutare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
| ||
2 | Protejați acreditările de înregistrare și STUN pe router prin criptare simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
| ||
3 | Creați un punct de încredere PKI pentru titularul plasamentului.
| ||
4 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare. Parametrii de transport ar trebui, de asemenea, să fie actualizați pentru a asigura o conexiune sigură și fiabilă pentru înregistrare:
| ||
5 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate:
|
1 | Creați un trunchi PSTN bazat pe înregistrare pentru o locație existentă în Control Hub. Notaţi informaţiile trunchiului care sunt furnizate după ce trunchiul a fost creat. Aceste detalii, așa cum se evidențiază în ilustrația următoare, vor fi utilizate în etapele de configurare din acest ghid. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling . | ||||
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. statistici mediaPermite monitorizarea media pe gateway-ul local. stări colective mediaPermite planului de control să interogheze planul de date pentru statistică apeluri în bloc . Pentru mai multe informații despre aceste comenzi, consultați Media. permite conexiuni sip la sipActivați funcționalitatea de bază a agentului de utilizator SIP back-to-back CUBE. Pentru mai multe informații, consultați Permiteți conexiuni .
Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata secret-partajat . sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcină utilă asimetrică . ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați ofertă anticipată . | ||||
3 | Configurare codec clasă vocală 100 filtru pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codeculclasei de voce.
| ||||
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling.
Iată o explicație a câmpurilor pentru configurare: stunutilizaregheațăliteUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stunării clasei de voce și stun utilisation ice lite .
| ||||
5 | Configurați politica de criptare media pentru traficul Webex.
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1 80._ Pentru mai multe informații, consultați clasa de voce srtp-crypto . | ||||
6 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza parametrului trunchiului de destinație:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați dtg= urmat de valoarea Trunk OTG/DTG furnizată în Control Hub atunci când trunchiul a fost creat. Pentru mai multe informații, consultați clasa vocală uri. | ||||
7 | Configurare profil sip 100, care va fi utilizat pentru a modifica mesajele SIP înainte de a fi trimise către Webex Calling.
Iată o explicație a câmpurilor pentru configurare:
| ||||
8 | Configurați trunchiul Webex Calling: |
După ce definiți entitatea găzduită 100 și configurați un peer de apelare SIP VoIP, gateway-ul inițiază o conexiune TLS către Webex Calling. În acest moment, SBC de acces își prezintă certificatul la gateway-ul local. Gateway-ul local validează certificatul SBC de acces Webex Calling utilizând pachetul rădăcină CA care a fost actualizat mai devreme. Dacă certificatul este recunoscut, se stabilește o sesiune TLS persistentă între gateway-ul local și accesul Webex Calling SBC. Gateway-ul local este apoi capabil să utilizeze această conexiune securizată pentru a se înregistra la SBC de acces Webex. Când înregistrarea este contestată pentru autentificare:
În răspuns se utilizează numele de utilizator, parola și parametrii domeniului din configurația de acreditări .
Regulile de modificare din profilul sip 100 sunt utilizate pentru a converti URL-ul SIPS înapoi la SIP.
Înscrierea este reușită atunci când un 200 OK este primit de la SBC de acces.
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE. |
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI. |
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește un dial-peer VoIP cu eticheta de 300 și oferă o descriere semnificativă pentru o gestionare ușoară și depanare. Pentru mai multe informații, consultați voce dial-peer. model-destinație RĂU.PROBĂTEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați model-destinație (interfață) . protocol de sesiune sipv2Specifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocol de sesiune (dial peer) . țintă sesiune ipv4:192.168.80.13Indică adresă IPv4 țintă a destinației pentru a trimite segmentul de componentă apel. Ținta sesiunii aici este adresă IP a ITSP . Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP a PSTN adresă IP. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec de clasă voce . dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe segmentul de componentă apel. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
Atunci când creați trunchiul Webex Calling în Unified CM, asigurați-vă că configurați portul de intrare în setările profilului de securitate al trunchiului SIP la 5065. Acest lucru permite mesajele de intrare pe portul 5065 și populează antetul VIA cu această valoare atunci când trimiteți mesaje către gateway-ul local. |
1 | Configurați următoarele URI pentru clase de voce: | ||
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM:
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. | ||
3 | Configurați următorii colegi de apelare: | ||
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe IOS XE și generează notificarea evenimentului prin e-mail, syslog sau mesaj terminal. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în carcasa Cisco TAC pentru a accelera timpul de rezoluție.
Semnături de diagnosticare (DS) sunt fișiere XML care conțin informații despre declanșarea problemelor evenimente și acțiuni care urmează să fie luate pentru a informa, depanare, și remedia problema. Puteți defini logica de detectare a problemei prin utilizarea mesajelor syslog, a evenimentelor SNMP și prin monitorizarea periodică a ieșirilor specifice ale comenzii de afișare.
Tipurile de acțiuni includ colectarea ieșirilor comenzii show:
Generarea unui fișier jurnal consolidat
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP.
Inginerii TAC creează fișierele DS și le semnează digital pentru a proteja integritatea. Fiecare fișier DS are un ID numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o sursă unică de găsire a semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS din care descărcați DSLT . Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server SMTP(Simple Mail Transfer Protocol) de care aveți nevoie pentru ca gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați server SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway-ul local care rulează IOS XE 17.6.1a sau mai mare
Semnăturile de diagnosticare este activată implicit.
Configurați serverul de e-mail securizat pentru a fi utilizat pentru a trimite o notificare proactivă dacă dispozitivul rulează Cisco IOS XE 17.6.1a sau o versiune ulterioară.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediuds_email cu adresa de e-adresă de e-mail a administratorului pentru a vă anunța.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Următoarele afișează un exemplu de configurare a unui gateway local care rulează pe Cisco IOS XE 17.6.1a sau mai mare pentru a trimite notificările proactive către tacfaststart @gmail.com utilizarea Gmail ca server SMTP securizat:
Vă recomandăm să utilizați versiunile Cisco IOS XE Bengaluru 17.6.x sau versiuni ulterioare. |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway local care rulează pe software-ul Cisco IOS XE nu este un client Gmail obișnuit, bazat pe web, care acceptă OAuth, așa că trebuie să configuram o anumită setare pentru contul Gmail și să oferim permisiunea specifică pentru ca e-mailul de pe dispozitiv să fie procesat corect: |
Accesați la aplicație mai puțin securizată.
și activați setarea de accesRăspundeți „Da, eu am fost” atunci când primiți un e-mail de la Gmail prin care se spune „Google a împiedicat pe cineva să se conecteze la contul dvs. utilizând o aplicație non-Google”.
Instalați semnături de diagnosticare pentru o monitorizare proactivă
Monitorizarea gradului de utilizare ridicat al CPU
Acest DS urmărește utilizarea CPU timp de cinci secunde folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când gradul de utilizare atinge 75% sau mai mult, acesta dezactivează toate remediile și dezinstalează toate semnăturile de diagnosticare care sunt instalate în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a activa SNMP. Dacă nu activați, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Copiați fișier XML în flash-ul Gateway local.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe gateway-ul local.
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)
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
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
Descărcați DS:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_ LGW_ CPU_ MON75
0.0.10
Înscriși
07.11.2020 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv ea însăși. Dacă este necesar, reinstalați DS 64224 pentru a continua monitorizarea utilizării ridicate a procesorului pe gateway-ul local.
Monitorizarea înregistrării SIP trunk
Acest DS verifică dacă există anularea înregistrării unui trunchi SIP Gateway local în Webex Calling la fiecare 60 de secunde. Odată ce evenimentul de anulare a înscrierii este detectat, acesta generează un e-mail și o notificare syslog și se dezinstalează după două apariții de dezactivare. Utilizați pașii de mai jos pentru a instala semnătura:
Descărcați DS 64117 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
SIP- SIP
Tip problemă
Dezactivare trunchi SIP cu notificare prin e- E-mail .
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează interogare SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erorile SIP 403, 488 și 503. Dacă numărul de erori este mai mare sau egal cu 5 din ultimul sondaj, acesta generează un syslog și o notificare prin e-mail. Vă rugăm să utilizați pașii de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a verifica dacă SNMP este activat. Dacă nu este activată, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Detectare deconectare anormală a apelurilor SIP cu notificare prin e- E-mail și Syslog.
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Instalați semnături de diagnosticare pentru a depana o problemă
Utilizați Semnăturile de diagnosticare (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au creat mai multe semnături care permit debug-urile necesare pentru a depana o anumită problemă, a detecta apariția problemei, a colecta setul corect de date de diagnosticare și a transfera datele automat în carcasa Cisco TAC . Semnăturile de diagnosticare (DS) elimină necesitatea de a verifica manual apariția problemei și facilitează mult soluționarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare prin următorii pași:
Configurați o variabilă de mediu DS suplimentarăds_fsurl_prefix care este calea server de fișiere Cisco TAC (cxd.cisco.com) în care sunt încărcate datele de diagnosticare colectate. Numele de utilizator din calea fișierului este numărul cazului, iar parola este tokenul de încărcare fișier , care poate fi preluat din Asistență Case Manager în următoarea comandă. Tokenul de încărcare fișier poate fi generat în Atașamente secțiunea Support Case Manager, după caz.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând afișare snmp comandă . Dacă nu este activată, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Asigurați-vă că ați instalat DS 64224 pentru monitorizarea CPU ridicat ca o măsură proactivă pentru a dezactiva toate semnările de depanare și diagnosticare în timpul perioadei de utilizare ridicată a CPU . Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Seria Cisco 4300, 4400 ISR sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Syslog-uri
Tip problemă
Syslog - %VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0
Copiați fișierele DS XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișier XML DS 64224 și apoi DS 65095 pentru monitorizarea CPU înalt în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând aplicația afișați semnătura-diagnostic call-home comanda. Coloana de stare trebuie să aibă o valoare „înscrisă”.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscriși
2020-11-08
Verificați execuția semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a fișierului afișați semnătura-diagnostic call-home comanda trece la „rulare” în timp ce gateway-ul local execută acțiunea definită în semnătură. Ieșirea din afișați statisticile pentru semnătura de diagnosticare apel-home este cel mai bun mod de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și execută acțiunea. Coloana „Declanșat/Max/Deinstalare” indică de câte ori semnătura dată a declanșat un eveniment, de număr maxim de ori în care este definită detectarea unui eveniment și dacă semnătura se dezinstalează după detectarea număr maxim de evenimente declanșate.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0.0.10 | Înscriși | 2020-11-08 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | Rulare | 2020-11-08 00:12:53 |
afișați statisticile pentru semnătura de diagnosticare apel-home
ID DS | Nume DS | Declanșat /Max/Deinstall | Durată medie de rulare (secunde) | Durată maximă de rulare (secunde) |
---|---|---|---|---|
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 |
E-mailul de notificare care este trimis în timpul execuției semnăturii de diagnosticare conține informații cheie precum tipul problemei, detaliile dispozitivului, versiune software, configurația de rulare și ieșirile de afișare a comenzii care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizare Semnăturile de diagnosticare în scopuri de depanare sunt de obicei definite pentru a fi dezinstalate după detectarea unor probleme. Dacă doriți să dezinstalați manual o semnătură, recuperați ID-ul DS de la ieșirea din afișarea semnăturii de diagnosticare la domiciliu comandă și executați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic în Instrumentul de căutare semnături pentru diagnosticare, pe baza problemelor observate de obicei în implementări. TAC nu acceptă momentan solicitările de creare de noi semnături personalizate. |
Pentru o mai bună gestionare a gateway-urilor Cisco IOS XE, vă recomandăm să înscrieți și să gestionați gateway-urile prin Control Hub. Este o configurație opțională. Când sunteți înscris, puteți utiliza opțiunea de validare a configurației din Control Hub pentru a valida configurația Gateway-ului local și a identifica orice probleme de configurare. În prezent, numai trunchiurile bazate pe înregistrare acceptă această funcționalitate.
Pentru mai multe informații, consultați următoarele:
Această secțiune descrie modul de configurare a unui element de frontieră Unified Cisco (CUBE) ca gateway local pentru Webex Calling, utilizând trunchiul SIP TLS (mTLS) bazat pe certificate. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Următoarea imagine evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
cursanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup peer-dial: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine. Opțiunile sunt prevăzute pentru abordarea publică sau privată (în spatele NAT). Înregistrările DNS SRV sunt opționale, cu excepția cazului în care sarcina este echilibrată în mai multe instanțe CUBE.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe certificate necesită versiuni Cisco IOS XE 17.9.1a sau versiuni ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe de tehnologie de securitate.
Routerele din seria Catalyst Edge 8000 echipate cu carduri vocale sau DSPs necesită licențiere ADN Essentials. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Pentru cerințele de capacitate ridicată, puteți solicita, de asemenea, o licență de înaltă securitate (HSEC) și un drept suplimentar de tranzit.
Consultați Codurile de autorizare pentru detalii suplimentare.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
NTP
ACL-uri
Autentificare utilizator și acces la distanță
DNS
Rutare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4. Adresa locală Gateway Nume domeniu complet calificat (FQDN) sau Înregistrare serviciu (SRV) trebuie să se rezolve la o adresă IPv4 publică pe internet.
Toate porturile SIP și media de pe interfața Gateway Local cu care se confruntă Webex trebuie să fie accesibile de pe internet, fie direct, fie prin NAT static. Asigurați-vă că actualizați firewall-ul în mod corespunzător.
Instalați un certificat semnat pe gateway-ul local (următorul oferă pașii de configurare detaliați).
O autoritate publică de certificare (CA), așa cum este detaliată în Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platformele audio și video Cisco Webex? trebuie să semneze certificatul dispozitivului.
FQDN configurat în Control Hub atunci când se creează un trunchi trebuie să fie numele comun (CN) sau certificatul de nume alternativ al subiectului (SAN) al routerului. De exemplu:
Dacă un trunchi configurat în Control Hub al organizației dvs. are cube1.lgw.com:5061 ca FQDN al gateway-ului local, atunci CN sau SAN din certificatul router trebuie să conțină cube1.lgw.com.
Dacă un trunchi configurat în Control Hub al organizației dvs. are lgws.lgw.com ca adresa SRV a gateway-ului (gateway-urilor) local care poate fi accesată din trunchi, atunci CN sau SAN din certificatul router trebuie să conțină lgws.lgw.com. Înregistrările în care se rezolvă adresa SRV (CNAME, A Înregistrare sau IP Address) sunt opționale în SAN.
Indiferent dacă utilizați un FQDN sau un SRV pentru trunchi, adresa de contact pentru toate dialogurile SIP noi din gateway-ul local utilizează numele configurat în Control Hub.
Asigurați-vă că certificatele sunt semnate pentru utilizare client și server.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
| ||
2 | Protejați acreditările STUN pe router utilizând criptarea simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
| ||
3 | Creați un punct de încredere pentru criptare cu un certificat semnat de autoritatea de certificare preferată (CA). | ||
4 | Autentificați-vă noul certificat utilizând certificatul CA intermediar (sau rădăcină), apoi importați certificatul (Pasul 4). Introduceți următoarea comandă de exec sau configurare:
| ||
5 | Importați un certificat de gazdă semnat utilizând următoarea comandă exec sau de configurare:
| ||
6 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare:
| ||
7 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate:
|
1 | Creați un trunchi PSTN bazat pe certificat CUBE pentru o locație existentă în Control Hub. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling .
| ||||
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. permite conexiuni sip la sipActivați CUBE SIP de bază înapoi la funcționalitatea de agent de utilizator înapoi. Pentru mai multe informații, consultați Permiteți conexiuni .
Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata partajate-secret. sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcină utilă asimetrică . ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați ofertă anticipată . intrare profiluri sipPermite CUBE să utilizeze profiluri SIP pentru a modifica mesajele pe măsură ce acestea sunt primite. Profilurile sunt aplicate prin intermediul asociaților de apelare sau al chiriașilor. | ||||
3 | Configurare codec clasă vocală 100 filtru codec pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codeculclasei de voce.
| ||||
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: stunutilizaregheațăliteUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stunării clasei de voce și stun utilisation ice lite .
| ||||
5 | Configurați politica de criptare media pentru traficul Webex. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1 80._ Pentru mai multe informații, consultați clasa de voce srtp-crypto . | ||||
6 | Configurați cifrele GCM conforme cu FIPS (Acest pas se aplică numai pentru Webex for Government).
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică GCM ca suita cipher pe care CUBE o oferă. Este obligatorie configurarea criptelor GCM pentru gateway-ul local pentru Webex for Government. | ||||
7 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza destinației sale FQDN sau SRV:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați FQDN sau SRV LGW configurat în Control Hub în timp ce creați un trunchi. | ||||
8 | Configurați profilurile de manipulare a mesajelor SIP. Dacă gateway-ul dvs. este configurat cu o adresă IP publică, configurați un profil după cum urmează sau treceți la pasul următor dacă utilizați NAT. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local și „198.51.100.1” este adresa IP publică a interfeței gateway-ului local care se confruntă cu Webex Calling:
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive.
| ||||
9 | Dacă gateway-ul dvs. este configurat cu o adresă IP privată în spatele NAT statică, configurați profilurile SIP de intrare și de ieșire după cum urmează. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local, „10.80.13.12” este adresa IP de interfață cu care se confruntă Webex Calling și „192.65.79.20” este adresa IP publică NAT. Profiluri SIP pentru mesajele de ieșire către Webex Calling
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive. normele 30-81Convertiți referințele adresei private la adresa publică externă a site-ului, permițând Webex să interpreteze corect și să dirijeze mesajele ulterioare. Profil SIP pentru mesajele de intrare din Webex Calling
Iată o explicație a câmpurilor pentru configurare: normele 10-80Convertiți referințele adresei publice la adresa privată configurată, permițând procesarea corectă a mesajelor din Webex de către CUBE. Pentru mai multe informații, consultați profiluri pentru clasa de voce . | ||||
10 | Configurați un SIP Opțiuni în viață cu profilul de modificare a antetului.
Iată o explicație a câmpurilor pentru configurare: clasă vocală sip-opțiuni-keepalive 100Configurați un profil keepalive și intră în modul de configurare a clasei de voce. Puteți configura timpul (în secunde) la care un Ping SIP Out of Dialog Options este trimis către ținta de apelare atunci când conexiunea bătăilor inimii la punctul final este în stare în sus sau în jos. Acest profil Keepalive este declanșat din dial-peer-ul configurat către Webex. Pentru a vă asigura că antetele de contact includ numele de domeniu complet calificat SBC, se utilizează profilul SIP 115. Regulile 30, 40 și 50 sunt necesare numai atunci când SBC este configurat în spatele NAT statice. În acest exemplu, cube1.lgw.com este FQDN selectat pentru gateway-ul local și dacă se utilizează NAT static, „10.80.13.12” este adresa IP a interfeței SBC către Webex Calling și „192.65.79.20” este adresa IP publică NAT. | ||||
11 | Configurați trunchiul Webex Calling: |
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE. |
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI. |
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește un dial-peer VoIP cu eticheta de 300 și oferă o descriere semnificativă pentru o gestionare ușoară și depanare. Pentru mai multe informații, consultați voce dial-peer. model-destinație RĂU.PROBĂTEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați model-destinație (interfață) . protocol de sesiune sipv2Specifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocol de sesiune (dial peer) . țintă sesiune ipv4:192.168.80.13Indică adresă IPv4 țintă a destinației pentru a trimite segmentul de componentă apel. Ținta sesiunii aici este adresă IP a ITSP . Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP a PSTN adresă IP. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec de clasă voce . dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe segmentul de componentă apel. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
1 | Configurați următoarele URI pentru clase de voce: | ||
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM:
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. | ||
3 | Configurați următorii colegi de apelare: | ||
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe Cisco IOS XE și generează notificarea evenimentului prin e-mail, syslog sau mesaj terminal. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în carcasa Cisco TAC pentru a accelera timpul de rezoluție.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele de declanșare a problemei și acțiunile de informare, depanare și remediere a problemei. Utilizați mesajele syslog, evenimentele SNMP și prin monitorizarea periodică a ieșirilor specifice comenzii show pentru a defini logica de detectare a problemei. Tipurile de acțiune includ:
Colectarea ieșirilor comenzii show
Generarea unui fișier jurnal consolidat
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi serverul HTTPS, SCP, FTP
Inginerii TAC creează fișiere DS și le semnează digital pentru a proteja integritatea. Fiecare fișier DS are ID -ul numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o sursă unică de găsire a semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS din care descărcați DSLT . Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server SMTP(Simple Mail Transfer Protocol) de care aveți nevoie pentru ca gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați server SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway local care rulează IOS XE 17.6.1 sau o versiune ulterioară
Semnăturile de diagnosticare este activată implicit.
Configurați serverul de e-mail securizat pe care îl utilizați pentru a trimite notificări proactive dacă dispozitivul rulează IOS XE 17.6.1 sau o versiune ulterioară.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediuds_email cu adresa de e-adresă de e-mail a administratorului pentru a vă notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Instalați semnături de diagnosticare pentru o monitorizare proactivă
Monitorizarea gradului de utilizare ridicat al CPU
Acest DS urmărește utilizarea CPU timp de 5 secunde, folosind OID-ul SNMP 1.3.6.1.4.1.9.2.1.56. Când gradul de utilizare atinge 75% sau mai mult, acesta dezactivează toate remediile și dezinstalează toate semnăturile de diagnosticare pe care le instalați în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Asigurați-vă că ați activat SNMP utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante în Instrumentul de căutare a semnăturilor de diagnosticare :
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în soluția Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail
Copiați fișier XML în flash-ul Gateway local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe gateway-ul local.
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)
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișați semnătura-diagnostic call-home comandă pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
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
Descărcați DS:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv ea însăși. Dacă este necesar, vă rugăm să reinstalați DS 64224 pentru a continua să monitorizați gradul de utilizare ridicat al CPU pe gateway-ul local.
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează interogare SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erorile SIP 403, 488 și 503. Dacă numărul de erori este mai mare sau egal cu 5 din ultimul sondaj, acesta generează un syslog și o notificare prin e-mail. Vă rugăm să utilizați pașii de mai jos pentru a instala semnătura.
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Detectare deconectare anormală a apelurilor SIP cu notificare prin e- E-mail și Syslog.
Copiați fișier XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișier XML în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați comanda afișați semnătura-diagnostic call-home pentru a verifica dacă semnătura a fost instalată cu succes. Coloana de stare trebuie să aibă o valoare „înscrisă”.
Instalați semnături de diagnosticare pentru a depana o problemă
De asemenea, puteți utiliza Semnăturile de diagnosticare (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au creat mai multe semnături care permit debug-urile necesare pentru a depana o anumită problemă, a detecta apariția problemei, a colecta setul corect de date de diagnosticare și a transfera datele automat în carcasa Cisco TAC . Acest lucru elimină necesitatea verificării manuale a apariției problemei și face mult depanarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare prin următorii pași:
Configurați o altă variabilă de mediu DSds_fsurl_prefix ca calea server de fișiere Cisco TAC (cxd.cisco.com) pentru a încărca datele de diagnosticare. Numele de utilizator din calea fișierului este numărul cazului, iar parola este tokenul de încărcare fișier , care poate fi preluat din Asistență Case Manager după cum se arată în cele ce urmează. Tokenul de încărcare fișier poate fi generat în Atașamente secțiunea Manager caz de asistență, după caz.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Vă recomandăm să instalați DS 64224 pentru monitorizarea CPU ridicat ca o măsură proactivă pentru a dezactiva toate semnările de depanare și diagnosticare în timpul perioadei de utilizare ridicată a CPU . Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip problemă
Utilizare ridicată a CPU cu notificare prin e- E-mail .
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentul de căutare a semnăturilor de diagnosticare :
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge 8000V Catalyst
Produs
CUBE Enterprise în Webex Calling
Domeniul de aplicare al problemei
Syslog-uri
Tip problemă
Syslog - %VOICE_ IEC-3-GW: CCAPI: Eroare internă (pragul vârfului apelului): IEC=1.1.181.1.29.0
Copiați fișierele DS XML în gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișier XML DS 64224 cu monitorizare CPU ridicată și apoi DS 65095 în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând afișarea semnăturii de diagnosticare la domiciliu. Coloana de stare trebuie să aibă o valoare „înscrisă”.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscriși
2020-11-08:00:12:53
Verificați execuția semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a comenzii afișați semnătura-diagnostic call-home trece la „rulare” în timp ce gateway-ul local execută acțiunea definită în semnătură. Ieșirea din afișați statisticile pentru semnătura de diagnosticare apel-home este cel mai bun mod de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și a executat acțiunea. Coloana „Declanșat/Max/Deinstalare” indică de câte ori semnătura dată a declanșat un eveniment, de număr maxim de ori în care este definită detectarea unui eveniment și dacă semnătura se dezinstalează după detectarea număr maxim de evenimente declanșate.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DS descărcate:
ID DS | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Înscriși |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișați statisticile pentru semnătura de diagnosticare apel-home
ID DS | Nume DS | Declanșat /Max/Deinstall | Durată medie de rulare (secunde) | Durată maximă de rulare (secunde) |
---|---|---|---|---|
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 |
E-mailul de notificare care este trimis în timpul execuției semnăturii de diagnosticare conține informații cheie precum tipul problemei, detaliile dispozitivului, versiune software, configurația de rulare și ieșirile de afișare a comenzii care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemei. Dacă doriți să dezinstalați manual o semnătură, preluați ID -ul DS din ieșirea lui afișați semnătura-diagnostic call-home și rulați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic în Instrumentul de căutare a semnăturilor pentru diagnosticare, pe baza problemelor observate în implementări. TAC nu acceptă momentan solicitările de creare de noi semnături personalizate. |
Fundamentale
Cerințe preliminare
Înainte de a implementa CUBE HA ca gateway local pentru Webex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
Layer 2 redundanță box-to-box cu CUBE Enterprise pentru păstrarea constantă a apelurilor
Orientările de configurare prevăzute în acest articol presupun o platformă locală de gateway dedicată, fără o configurație vocală existentă. Dacă o implementare CUBE existentă a întreprinderii este modificată pentru a utiliza și funcția gateway locală pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri existente și funcționalitățile nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită versiunea IOS-XE 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și funcțiile LGW.
Comenzile și jurnalele spectacolului din acest articol se bazează pe versiunea minimă de software a Cisco IOS-XE 16.12.2 implementată pe un vCUBE (CSR1000v). |
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diferite platforme:
Seria ISR 4K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE) — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Arhitectură preferată Cisco pentru Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Prezentare generală Soluție Webex Calling
Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud multi-tenant la serviciul de telefonie PBX prestabilit, cu mai multe opțiuni PSTN pentru clienți.
Implementarea gateway-ului local (reprezentată mai jos) se află în centrul acestui articol. Trunchiul gateway local (PSTN la sediu) în Webex Calling permite conexiunea la un serviciu PSTN deținut de client. Acesta oferă, de asemenea, conectivitate la o implementare IP PBX în rețeaua corporatistă , cum ar fi Cisco Unified CM. Toate comunicațiile către și din cloud sunt securizate prin intermediul transportului TLS pentru SIP și SRTP pentru mass-media.
Figura de mai jos afișează o implementare Webex Calling fără niciun PBX IP existent și se aplică unei implementări unice sau multi-site. Configurația prezentată în acest articol se bazează pe această implementare.
Nivelul 2 Redundanță Box-to-Box
Redundanța CUBE HA strat 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) pe interfețele respective și face schimb continuu de mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate de-a lungul perechii de routere care permit routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ iese din serviciu, ceea ce duce la păstrarea constantă a semnalizării și a mass-mediei.
Verificarea punctajului este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt bifate (de exemplu, o stare de încercare sau de apel). În acest articol, CUBE HA se va referi la CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundanță pentru păstrarea constantă a apelurilor |
Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca gateway local pentru implementările trunchiului Cisco Webex Calling (PSTN local) și vom acoperi considerațiile de proiectare și configurațiile din acest articol. Această cifră afișează o configurare tipică CUBE HA ca gateway local pentru o implementare trunchi Cisco Webex Calling.
Componentă Intra Grup de redundanță
Componenta Infra a Grupului de Redundanță (RG) oferă suport pentru infrastructura de comunicare box-to-box între cele două CUB-uri și negociază starea finală stabilă de redundanță. Această componentă oferă, de asemenea:
Un protocol de tip HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și salut între cele două CUBEs (prin interfața de control) - GigabitEthernet3 în figura de mai sus.
Un mecanism de transport pentru verificarea stării de semnalizare și media pentru fiecare apel de la router-ul activ la router-ul standby (prin interfața de date) - GigabitEthernet3 în figura de mai sus.
Configurarea și gestionarea interfeței Virtual IP (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie configurată special pentru a sprijini vocea B2B HA.
Gestionarea adreselor IP virtuale (VIP) atât pentru semnalizare, cât și pentru media
B2B HA se bazează pe VIP pentru a obține redundanță. Interfețele fizice VIP și asociate pe ambele CUBE din perechea CUBE HA trebuie să reziste pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație vocală (SIP) sunt obligatorii pentru asistența vocală B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling Access SBC, furnizorul de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care trec prin routerele CUBE HA. Prin urmare, din punct de vedere Webex Calling, perechile CUBE HA acționează ca un singur gateway local.
Semnalizarea apelurilor și informațiile despre sesiunea RTP ale apelurilor stabilite sunt verificate de la routerul activ la routerul standby. Când routerul Activ coboară, routerul Standby preia și continuă să redirecționeze fluxul RTP care a fost direcționat anterior de primul router.
Apelurile într-o stare tranzitorie în momentul nereușitei nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt pe deplin stabilite încă sau sunt în curs de modificare cu o funcție de transfer sau de menținere. Apelurile configurate pot fi deconectate după comutare.
Următoarele cerințe există pentru utilizarea CUBE HA ca gateway local pentru defalcarea statică a apelurilor:
CUBE HA nu poate avea interfețe TDM sau analogice co-localizate
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP/RTP) și Gig3 este Redundancy Group (RG) Control/interfață de date
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu strat 2, unul cu id de grup 1 și celălalt cu id de grup 2. Dacă configurați 2 perechi HA cu același id de grup, interfețele RG Control/Date trebuie să aparțină diferitelor domenii din stratul 2 (vlan, comutator separat)
Canalul portuar este acceptat atât pentru controlul RG/date, cât și pentru interfețele de trafic
Toate semnalele/mass-media sunt obținute de la/la adresa IP virtuală
Oricând o platformă este reîncărcată într-o relație CUBE-HA, ea începe întotdeauna ca Standby
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
Identificatorul interfeței de redundanță, rii trebuie să fie unic pentru o combinație pereche/interfață în același strat 2
Configurația pe ambele CUBEs trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
Interfețele Loopback nu pot fi utilizate ca legături, deoarece acestea sunt întotdeauna în sus
Interfețele de trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea monitorizării interfeței
CUBE-HA nu este acceptată printr-o conexiune prin cablu încrucișată pentru link-ul RG-control/date (Gig3)
Ambele platforme trebuie să fie identice și să fie conectate printr-o Comutator fizic pe toate interfețele la fel pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
Nu se poate termina WAN pe CUBEs direct sau Data HA pe nici o parte
Ambele active/standby trebuie să fie în același centru de date
Este obligatoriu să se utilizeze o interfață L3 separată pentru redundanță (RG Control/date, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru keepalives HA și puncte de control
După eșec, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media
Configurați redundanța pe Ambele CUBE-uri
Trebuie să configurați redundanța de la 2 la 2 pe ambele CUBEs destinate utilizării într-o pereche HA pentru a aduce IPs virtuale.
1 | Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât traseul activ va juca destul de rolul său activ după ce interfața de trafic este în jos. | ||||||
2 | Configurați un RG pentru utilizare cu VoIP HA în submodul de redundanță al aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||||||
3 | Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG din pasul anterior de mai jos
redundanță-grup 1—Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să intre în vigoare. Vom reîncărca platformele după ce toate configurațiile au fost aplicate. | ||||||
4 | Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, după cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||||||
5 | Salvați configurația primului CUBE și reîncărcați-l. Platforma pentru a reîncărca ultima este întotdeauna standby.
După ce VCUBE-1 cizme complet, salvați configurația VCUBE-2 și reîncărcați-l.
| ||||||
6 | Verificați dacă configurația cutie-la-cutie funcționează conform așteptărilor. Ieșirea relevantă este evidențiată în îndrăzneală. Am reîncărcat ultimul VCUBE-2 și conform considerațiilor de proiectare; platforma de reîncărcare va fi întotdeauna în așteptare.
|
Configurați un gateway local pe Ambele CUBE-uri
În configurația exemplului nostru, folosim următoarele informații despre trunchiuri din Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt următoarele:
Nume utilizator: Hussain1076_LGU
Parolă: lOV12MEaZx
1 | Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditările sau secretele partajate. Parolele de tip 6 sunt criptate folosind AES cipher și această cheie de configurare definită de utilizator.
Iată configurația gateway-ului local care se va aplica ambelor platforme pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. Datele de autentificare SIP Digest din Control Hub sunt evidențiate în mod îndrăzneț.
Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând VCUBE-1 standby-ul CUBE și VCUBE-2 CUBE activ |
2 | În orice moment dat, o singură platformă va menține o înregistrare activă ca gateway local cu accesul Webex Calling SBC. Aruncați o privire la ieșirea din următoarele comenzi spectacol. afișați grupul de aplicații de redundanță 1 afișați starea înregistrării sip-ua
Din ieșirea de mai sus, puteți vedea că VCUBE-2 este LGW-ul activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea „afișează starea de înregistrare sip-ua” este necompletată în VCUBE-1 |
3 | Acum activați următoarele depanări pe VCUBE-1
|
4 | Simulați eșecul prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.
Trecerea de la ACTIVE la STANDBY LGW are loc în scenariul următor, precum și în afara CLI enumerate mai sus
|
5 | Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling Access SBC. VCUBE-2 s-ar fi reîncărcat până acum.
VCUBE-1 este acum LGW-ul activ. |
6 | Uitați-vă la jurnalul de depanare relevant din VCUBE-1 care trimite un ÎNREGISTRATOR SIP către Webex Calling PRIN IP-ul virtual și primește un OK 200.
|
Configurați profilul de securitate al trunchiurilor SIP pentru trunchiuri la gateway-ul local
În cazurile în care gateway-ul local și gateway-ul PSTN se află pe același dispozitiv, Unified CM trebuie să fie activat pentru a diferenția între două tipuri diferite de trafic (apeluri de la Webex și de la PSTN) care provin de la același dispozitiv și aplică o clasă de servicii diferențiată pentru aceste tipuri de apeluri. Acest tratament diferențiat al apelurilor se realizează prin asigurarea a două trunchiuri între Unified CM și gateway-ul local combinat și gateway-ul PSTN, care necesită diferite porturi SIP de ascultare pentru cele două trunchiuri.
Creați un profil de securitate dedicat trunchiului SIP pentru trunchiul gateway local cu următoarele setări:
|
Configurați profilul SIP pentru trunchiul gateway local
Creați un profil SIP dedicat trunchiului gateway local cu următoarele setări:
|
Creați un spațiu de căutare pentru apeluri din Webex
Creați un spațiu de căutare pentru apeluri care provin din Webex cu următoarele setări:
|
Configurați un trunchi SIP la și de la Webex
Creați un trunchi SIP pentru apelurile către și de la Webex prin gateway-ul local cu următoarele setări:
|
Configurați grupul de rutare pentru Webex
Creați un grup de rute cu următoarele setări:
|
Configurați lista de rutare pentru Webex
Creați o listă de rute cu următoarele setări:
|
Creați o partiție pentru Webex Destinations
Creați o partiție pentru destinațiile Webex cu următoarele setări:
|
Ce este de făcut în continuare
Asigurați-vă că adăugați această partiție în toate spațiile de căutare prin apelare care ar trebui să aibă acces la destinațiile Webex. Trebuie să adăugați această partiție în mod specific în spațiul de căutare pentru apelare utilizat ca spațiu de căutare pentru apelare de intrare pe trunchiurile PSTN, astfel încât apelurile din PSTN către Webex să poată fi direcționate.
Configurați modelele de rută pentru destinațiile Webex
Configurați modelele de rute pentru fiecare interval DID pe Webex cu următoarele setări:
|
Configurați standardizarea abreviată a apelurilor intersite pentru Webex
Dacă apelarea inter-site abreviată este necesară pentru Webex, configurați modelele de normalizare a apelării pentru fiecare interval ESN din Webex cu următoarele setări:
|
Configurați un grup de hunt
Grupurile de hunt direcționează apelurile primite către un grup de utilizatori sau către spații de lucru. Puteți chiar să configurați un model pentru a ruta către un întreg grup.
Pentru mai multe informații despre configurarea unui grup de hunt, consultați Grupuri de vânătoare în Cisco Webex Control Hub .
Creați o coadă de apeluri
Puteți configura o coadă de apeluri astfel încât, atunci când apelurile clienților nu pot fi preluate, aceștia să beneficieze de un răspuns automat, mesaje de confort și muzică în așteptare până când cineva își poate răspunde la apel.
Pentru mai multe informații despre configurarea și gestionarea unei secvențe de apeluri, consultați Gestionați cozile de apeluri în Cisco Webex Control Hub .
Creați un client recepționer
Ajutați-vă să susțineți nevoile personalului de la biroul din față. Puteți configura utilizatorii ca însoțitori telefonici, astfel încât aceștia să poată filtra apelurile primite către anumite persoane din organizația dvs.
Pentru informații despre configurarea și vizualizarea clienților recepționeri, consultați Clienți-recepționeri în Cisco Webex Control Hub .
Creați și gestionați operatorii automati
Puteți să adăugați mesaje de felicitare, să configurați meniuri și să dirijare apeluri către un serviciu telefonic, un grup de hunt, o căsuță poștă vocală sau o persoană reală. Creați un program de 24 de ore pe zi sau oferiți diferite opțiuni atunci când afacerea dvs. este deschisă sau închisă.
Pentru informații despre crearea și gestionarea operatorilor automati, consultați Gestionați operatorii automati în Cisco Webex Control Hub .
Configurați un grup de difuzare
Apelarea de grup permite unui utilizator să efectueze un apel unidirecțional sau o pagină de grup către până la 75 de utilizatori și spații de lucru țintă prin formarea unui număr sau a unui interior alocat unui anumit grup de difuzare.
Pentru informații despre configurarea și editarea grupurilor de difuzare, consultați Configurați un grup de difuzare în Cisco Webex Control Hub .
Configurați preluarea apelurilor
Îmbunătățiți munca în echipă și colaborarea prin crearea unui grup de preluare apel, astfel încât utilizatorii să își poată răspunde reciproc la apelurile. Când adăugați utilizatori într-un grup de preluare apel și un membru al grupului este absent sau ocupat, un alt membru poate răspunde la apelurile acestora.
Pentru informații despre configurarea unui grup de preluare apel, consultați Preluare apeluri în Cisco Webex Control Hub .
Configurați parcarea apelurilor
Parcarea apelurilor permite unui grup definit de utilizatori să parcheze apelurile împotriva altor membri disponibili ai unui grup de parcare a apelurilor. Apelurile parcate pot fi preluate de alți membri ai grupului pe telefonul lor.
Pentru mai multe informații despre configurarea parcării apelurilor, consultați Parcare apel în Cisco Webex Control Hub .
Activați barge-in pentru utilizatori
1 | Din vizualizarea clientului din , accesați Apelarea > locații.https://admin.webex.com |
2 | Selectați un utilizator și faceți clic pe Apelare. |
3 | Accesați secțiunea Permisiuni între utilizatori , apoi selectați Barge. |
4 | Activați comutatorul pentru a permite altor utilizatori să se adauge la apelul în curs al acestui utilizator. |
5 | Verificați Redați un ton atunci când acest utilizator intră într-un apel dacă doriți să redați un ton altor persoane atunci când acest utilizator intră în apel. |
6 | Faceți clic pe Salvați. |
Activați confidențialitatea pentru un utilizator
1 | Conectați-vă la Control Hub și accesați . | ||
2 | Alegeți un utilizator și faceți clic pe Apelare. | ||
3 | Accesați zona Permisiuni între utilizatori și apoi alegeți Confidențialitate. | ||
4 | Alegeți cel adecvat Confidențialitate operator automat setări pentru acest utilizator.
| ||
5 | Verificați Activați Confidențialitate casetă de selectare. Apoi, puteți decide să blocați pe toată lumea, nealegând membri din lista derulantă. Alternativ, puteți alege utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei acestui utilizator. Dacă sunteți administrator de locație, în lista derulantă apar numai utilizatorii, spațiile de lucru și liniile virtuale referitoare la locațiile atribuite. Debifați caseta de selectare Activare confidențialitate pentru a permite tuturor să monitorizeze starea liniei. | ||
6 | Verificați Confidențialitatea impunerii pentru preluarea apelurilor direcționate și caseta de selectare pentru înscriere pentru a activa confidențialitatea pentru preluarea apelurilor direcționate și înscriere.
| ||
7 | Din Adăugați membru după nume, alegeți utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei telefonice și pot invoca preluarea apelurilor direcționate și intrarea în rețea. | ||
8 | Pentru a filtra membrii pe care îi selectați, utilizați filtrul după nume, număr sau câmp text. | ||
9 | Faceți clic pe Eliminare toate pentru a elimina toți membrii selectați.
| ||
10 | Faceți clic pe Salvați. |
Configurați monitorizarea
Numărul maxim de linii monitorizate pentru un utilizator este de 50. Cu toate acestea, în timp ce configurați lista de monitorizare, luați în considerare numărul de mesaje care afectează lățimea de bandă dintre Webex Calling și rețeaua dvs. De asemenea, determinați liniile maxime monitorizate de numărul de butoane de linie de pe telefonul utilizatorului.
1 | Din vizualizarea clientului din https://admin.webex.com, accesați Management și apoi faceți clic pe Utilizatori. | ||||
2 | Selectați utilizatorul pe care doriți să îl modificați și faceți clic Apelare . | ||||
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Monitorizare. | ||||
4 | Alegeți dintre următoarele:
Puteți include o linie virtuală în lista Adăugare linie monitorizată pentru monitorizarea utilizatorului. | ||||
5 | Alegeți dacă doriți să notificați acest utilizator despre apelurile parcate, căutați persoana sau extensia de parcare a apelurilor care urmează să fie monitorizată, apoi faceți clic pe Salvare.
|
Activați tonul de avertizare prin punte de apel pentru utilizatori
Înainte de a începe
1 | Conectați-vă la Control Hub și accesați . | ||
2 | Selectați un utilizator și faceți clic pe fila Apelare. | ||
3 | Accesați Permisiuni între utilizatori și faceți clic pe Call Bridging Warning Tone. | ||
4 | Porniți Ton de avertizare pentru trecerea apelurilor , apoi faceți clic Salvați .
Pentru mai multe informații despre conectarea la apel pe o linie MPP partajată, consultați liniile partajate de pe telefonul dvs. de birou pentru mai multe platforme. Pentru mai multe informații despre conectarea apelurilor pe o linie partajată a aplicației Webex, consultați aspectul liniei partajate pentru WebexApp. |
Activați hotelizarea pentru un utilizator
1 | Din vizualizarea clientului înhttps://admin.webex.com , accesați Management și selectați Utilizatori . | ||
2 | Selectați un utilizator și faceți clic pe fila Apelare. | ||
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Hoteling și activați comutatorul. | ||
4 | Introduceți numele sau numărul gazdei hotelului în câmpul de căutare Hotel Location și alegeți gazda hotelului pe care doriți să o alocați utilizatorului. Poate fi selectată o singură gazdă hotelieră. Dacă alegeți o altă gazdă hotelieră, prima este ștearsă.
| ||
5 | Pentru a limita timpul în care un utilizator poate fi asociat cu gazda hotelului, alegeți numărul de ore pe care utilizatorul le poate utiliza gazda hotelului din lista derulantă Limit Association Period . Utilizatorul va fi deconectat automat după ora aleasă.
| ||
6 | Faceți clic pe Salvați.
|
Vizualizați rapoartele privind apelurile
Puteți utiliza pagina Analytics în Control Hub pentru a obține o perspectivă asupra modului în care oamenii utilizează Webex Calling și Webex aplicație (implicare) și calitatea experienței lor media de apel. Pentru a accesa Webex Calling analytics, conectați-vă la Control Hub , apoi accesați Analytics și selectați Apelare filă.
1 | Pentru rapoarte detaliate privind istoricul apelurilor, conectați-vă la Control Hub , apoi accesați Analytics > Apelare . |
2 | Selectați Istoric detaliat apeluri . Pentru informații despre apelurile care utilizează Instanța dedicată, consultați Analiză de instanță dedicată . |
3 | Pentru a accesa date de calitate media, conectați-vă la Control Hub , apoi accesați Analytics și apoi selectați Apelare . Pentru mai multe informații, consultați Statistici pentru portofoliul dvs. de colaborare în cloud.
|
Rulați instrumentul CScan
CScan este un instrument de pregătire a rețelei, conceput pentru a vă testa conexiune la rețea Webex Calling .
Pentru mai multe informații, consultați Utilizați CScan pentru a testa calitatea rețelei Webex Calling . |
Pregătiți mediul dvs.
Condiţii generale
Înainte de a configura un gateway local pentru Webex Calling, asigurați-vă că:
-
Dețineți cunoștințe de bază despre principiile VoIP
-
Aveți cunoștințe de lucru de bază despre conceptele de voce Cisco IOS-XE și IOS-XE
-
Să înțelegeți de bază Protocolul de inițiere sesiuni (SIP)
-
Aveți o înțelegere de bază a Cisco Unified Communications Manager (Unified CM) dacă modelul de implementare include Unified CM
Consultați Ghidul de configurare Enterprise Cisco Unified Border Element (CUBE) pentru detalii.
Cerințe hardware și software pentru Gateway-ul local
Asigurați-vă că implementarea dvs. are una sau mai multe dintre gateway-urile locale, cum ar fi:
-
Cisco CUBE pentru conectivitate bazată pe IP
-
Gateway Cisco IOS pentru conectivitate bazată pe TDM
Gateway-ul local vă ajută să migrați la Webex Calling în ritmul propriu. Gateway-ul local integrează implementarea locală existentă cu Webex Calling. De asemenea, puteți utiliza conexiunea PSTN existentă. Consultați Începeți cu gateway-ul local
Cerințe de licență pentru gateway-urile locale
Licențele de apelare CUBE trebuie să fie instalate pe gateway-ul local. Pentru mai multe informații, consultați Ghidulde configurare a elementelor de frontieră unificate Cisco.
Certificat și cerințe de securitate pentru Gateway-ul local
Apelarea Webex necesită semnalizare securizată și suport media. Gateway-ul local efectuează criptarea și trebuie stabilită o conexiune TLS de ieșire în cloud cu următorii pași:
-
LGW trebuie să fie actualizate cu ca root bundle de la Cisco PKI
-
Un set de acreditări SIP digest din pagina de configurare PortBagaj Control Hub sunt utilizate pentru a configura LGW (pașii fac parte din configurația care urmează)
-
Ca root bundle validează certificatul prezentat
-
Solicitat acreditări (SIP digest furnizate)
-
Cloud-ul identifică gateway-ul local care este înregistrat în siguranță
Cerințe de optimizare a firewall-ului, NAT Traversal și a căii media pentru Gateway-ul local
În majoritatea cazurilor, gateway-ul local și punctele finale se pot afla în rețeaua internă de clienți, utilizând adrese IP private cu NAT. Paravanul de protecție de întreprindere trebuie să permită traficul de ieșire (SIP, RTP/UDP, HTTP) la anumite adrese IP/porturi, acoperite în Informații de referință port.
Dacă doriți să utilizați Optimizarea căilor media cu ICE, interfața orientată Webex Calling a gateway-ului local trebuie să aibă o cale directă de rețea către și de la punctele finale webex Calling. Dacă punctele finale se află într-o locație diferită și nu există o cale de rețea directă între punctele finale și interfața webex calling a gateway-ului local, atunci gateway-ul local trebuie să aibă o adresă IP publică atribuită interfeței cu care se confruntă Apelarea Webex pentru apeluri între gateway-ul local și punctele finale pentru a utiliza optimizarea căii media. În plus, trebuie să ruleze IOS-XE versiunea 16.12.5.
Configurați Webex Calling pentru organizația dvs.
Primul pas pentru a vă pune în funcțiune serviciile de apelare Webex este să finalizați Expertul de configurare pentru prima dată (FTSW). Odată ce FTSW este finalizat pentru prima locație, nu trebuie să fie finalizat pentru locații suplimentare.
1 |
Faceți clic pe linkul Introducere din e-mailul de bun venit pe care îl primiți. Adresa de e-mail a administratorului este utilizată automat pentru a vă conecta la Control Hub, unde vi se va solicita să creați parola de administrator. După ce vă conectați, expertul de configurare pornește automat. |
2 |
Revizuiți și acceptați termenii serviciului. |
3 |
Revizuiți-vă planul, apoi faceți clic pe Introducere. Managerul de cont este responsabil pentru activarea primilor pași pentru FTSW. Contactați managerul de cont dacă primiți o notificare "Imposibil de configurat apelul", atunci când selectați Începeți. |
4 |
Selectați țara în care ar trebui să se mapeze centrul de date și introduceți informațiile despre persoana de contact a clientului și adresa clientului. |
5 |
Faceți clic pe Următorul: Locație implicită. |
6 |
Alegeți dintre următoarele opțiuni:
După ce terminați expertul de configurare, asigurați-vă că adăugați un număr principal la locația pe care o creați. |
7 |
Efectuați următoarele selecții pentru a vă aplica la această locație:
|
8 |
Faceți clic pe Următorul. |
9 |
Introduceți o adresă CISCO Webex SIP disponibilă și faceți clic pe Următorul și selectați Terminare . |
Înainte de a începe
Pentru a crea o locație nouă, pregătiți următoarele informații:
-
Adresa locației
-
Numerele de telefon dorite (opțional)
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . O nouă locație va fi găzduită în centrul regional de date care corespunde țării pe care ați selectat-o utilizând Asistentul pentru prima configurare. |
2 |
Configurați setările locației:
|
3 |
Faceți clic pe Salvare , apoi alegeți Da/ Nu pentru a adăuga numere la locație acum sau o versiune ulterioară. |
4 |
Dacă ați făcut clic pe Da, alegeți una dintre următoarele opțiuni:
Alegerea opțiunii PSTN este la fiecare nivel de locație (fiecare locație are o singură opțiune PSTN). Puteți să amestecați și să potriviți oricâte opțiuni doriți pentru implementare, dar fiecare locație va avea o singură opțiune. După ce ați selectat și furnizat o opțiune PSTN, o puteți modifica făcând clic pe Gestionare în locația proprietăți PSTN. Cu toate acestea, este posibil ca unele opțiuni, cum ar fi Cisco PSTN, să nu fie disponibile după ce a fost atribuită o altă opțiune. Deschideți un caz de asistență pentru îndrumare. |
5 |
Alegeți dacă doriți să activați numerele acum sau o versiune ulterioară. |
6 |
Dacă ați selectat PSTN neintegrat ccp sau local, introduceți numere de telefon ca valori separate prin virgulă, apoi faceți clic pe Validare. Numerele sunt adăugate pentru locația specifică. Intrările valide se mută în câmpul Numere validate, iar intrările nevalide rămân în câmpul Adăugare numere însoțite de un mesaj de eroare. În funcție de țara locației, numerele sunt formatate în funcție de cerințele locale de apelare. De exemplu, dacă este necesar un cod de țară, puteți introduce numere cu sau fără cod și codul este prependat. |
7 |
Faceți clic pe Salvați. |
Ce este de făcut în continuare
După ce creați o locație, puteți activa serviciile 911 de urgență pentru locația respectivă. Consultați Serviciul RedSky Emergency 911 pentru Webex Apelarea pentru mai multe informații.
Înainte de a începe
Obțineți o listă cu utilizatorii și spațiile de lucru asociate cu o locație: Accesați ștergeți acei utilizatori și spații de lucru înainte de a șterge locația.
și, din meniul vertical, selectați locația care trebuie ștearsă. Trebuie săRețineți că orice numere asociate cu această locație vor fi lansate înapoi la furnizorul pstn; nu veți mai deține aceste numere.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 |
Faceți clic |
3 |
Alegeți Ștergere locațieși confirmați că doriți să ștergeți locația respectivă. De obicei durează câteva minute pentru ca locația să fie ștearsă definitiv, dar ar putea dura până la o oră. Puteți verifica starea făcând clic pe lângă numele locației și selectând Stareștergere. |
Puteți modifica configurarea PSTN, numele, fusul orar și limba unei locații după ce este creată. Reține însă că noua limbă se aplică doar utilizatorilor și dispozitivelor noi. Utilizatorii și dispozitivele existente continuă să utilizeze vechea limbă.
Pentru locațiile existente, puteți activa serviciile de urgență 911. Consultați Serviciul RedSky Emergency 911 pentru Webex Apelarea pentru mai multe informații.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . Dacă vedeți un simbol Atenție lângă o locație, înseamnă că nu ați configurat încă un număr de telefon pentru locația respectivă. Nu puteți efectua sau primi apeluri până când nu configurați acel număr. |
2 |
(Opțional) Sub ConexiunePSTN, selectați PSTN conectat în cloud sau PSTN bazat pe sediu (gateway local), în funcție de cel pe care l-ați configurat deja. Faceți clic pe Gestionare pentru a modifica configurația respectivă, apoi confirmați riscurile asociate selectând Continuare. Apoi, alegeți una dintre următoarele opțiuni și faceți clic pe Salvare:
|
3 |
Pentru locație, selectați Numărul principal din lista derulantă pentru a permite utilizatorilor din locația respectivă să efectueze și să primească apeluri. Numărul principal poate fi atribuit operatorului automat, astfel încât apelanții externi să poată contacta utilizatorii Webex Calling din acea locație. Utilizatorii Webex Calling din acea locație pot utiliza, de asemenea, acest număr ca ID-ul de apelant extern atunci când efectuează apeluri. |
4 |
(Opțional) Sub Apelarede urgență, puteți selecta Identificator de locație de urgență pe care să îl atribuiți acestei locații. Această setare este opțională și se aplică numai țărilor care o solicită. În unele țări (Exemplu: Franța), există cerințe de reglementare pentru sistemele radio celulare pentru a stabili identitatea celulei atunci când efectuați un apel de urgență și este pus la dispoziția autorităților de urgență. Alte țări, cum ar fi S.U.A. și Canada, implementează determinarea locației folosind alte metode. Pentru mai multe informații, consultați Apelareade urgență îmbunătățită. Este posibil ca furnizorul de apeluri de urgență să aibă nevoie de informații despre rețeaua de acces și se realizează prin definirea unui nou antet de extensie SIP privat, P-Access-Network-Info. Antetul conține informații referitoare la rețeaua de acces. Atunci când setați identificatorul de locație de urgență pentru o locație, valoarea locației este trimisă furnizorului ca parte a mesajului SIP. Contactați furnizorul de apeluri de urgență pentru a vedea dacă aveți nevoie de această setare și utilizați valoarea furnizată de furnizorul de apeluri de urgență." |
5 |
Selectați Numărul de poștă vocală pe care utilizatorii îl pot apela pentru a-și verifica mesageria vocală pentru această locație. |
6 |
(Opțional) Faceți clic pe pictograma creion din partea de sus a paginii Locație pentru a modifica numele locației , limbaanunțului, limbade e-mail, fusul orarsau adresa , după cum este necesar, apoi faceți clic pe Salvare. Modificarea limbii de anunț intră în vigoare imediat pentru orice utilizatori și caracteristici noi adăugate la această locație. Dacă utilizatorii și/sau caracteristicile existente ar trebui, de asemenea, să li se modifice limba de anunțare, atunci când vi se solicită, selectați Modificare pentru utilizatorii și spațiile de lucru existente sau Modificare pentru caracteristicileexistente. Faceți clic pe Se aplică. Puteți vizualiza progresul pe pagina Activități . Nu mai puteți face modificări până când acest lucru nu este finalizat. Modificarea fusului orar pentru o locație nu actualizează fusurile orare ale caracteristicilor asociate locației. Pentru a edita fusurile orare pentru caracteristici precum operator automat, grup de vânătoare și coadă de apeluri, accesați zona Setări generale a caracteristicii specifice pentru care doriți să actualizați fusul orar și editați și salvați acolo. |
Aceste setări sunt pentru apelare internă și sunt, de asemenea, disponibile în expertul de configurare pentru prima dată. Pe măsură ce modificați planul de apelare, numerele de exemplu din actualizarea Control Hub pentru a afișa aceste modificări.
Puteți configura permisiunile de apelare la ieșire pentru o locație. Consultați acești pași pentru a configura permisiunile de apelare la ieșire.
1 |
Conectați-vă la Control Hub, accesați , apoi defilați la Apelare internă. |
2 |
Configurați următoarele preferințe opționale de apelare, după cum este necesar:
|
3 |
Specificați apelarea internă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea internă după cum este necesar: , selectați o locație din listă și faceți clic pe
|
4 |
Specificați apelarea externă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea externă după cum este necesar: , selectați o locație din listă și faceți clic pe
Impactul asupra utilizatorilor:
|
Dacă sunteți reseller cu valoare adăugată, puteți utiliza acești pași pentru a porni configurarea gateway-ului local în Control Hub. Atunci când acest gateway este înregistrat în cloud, îl puteți utiliza în una sau mai multe dintre locațiile webex Calling pentru a furniza rutare către un furnizor de servicii PSTN de întreprindere.
O locație care are un gateway local nu poate fi ștearsă atunci când gateway-ul local este utilizat pentru alte locații.
Înainte de a începe
-
Odată ce o locație este adăugată și înainte de a configura PSTN bazat pe premise pentru o locație, trebuie să creați un trunchi.
-
Creați orice locații și setări și numere specifice pentru fiecare dintre ele. Locațiile trebuie să existe înainte de a putea adăuga un PSTN bazat pe premise.
-
Înțelegeți cerințele PSTN (gateway local) bazate pe premise pentru apelareaWebex.
-
Nu puteți alege mai mult de un portbagaj pentru o locație cu PSTN bazat pe premise, dar puteți alege același portbagaj pentru mai multe locații.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați , și selectați Adăugare trunchiuri. |
2 |
Selectați o locație. |
3 |
Denumiți trunchiul și faceți clic pe Salvare. Numele nu poate fi mai mare de 24 de caractere. |
Ce trebuie să faceți în continuare
Informațiile despre trunchi apar pe ecranul Registru domeniu, Trunk Group OTG/DTG, Linie/Portși Adresăproxy de ieșire.
Vă recomandăm să copiați aceste informații din Control Hub și să le lipiți într-un fișier text local sau într-un document local, astfel încât să puteți face referire la acestea atunci când sunteți gata să configurați PSTN bazat pe premise.
Dacă pierdeți acreditările, trebuie să le generați din ecranul de informații portbagaj în Control Hub. Faceți clic pe Regăsire nume de utilizator și reinițializare parolă pentru a genera un nou set de acreditări de autentificare de utilizat pe trunchi.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 |
Selectați o locație de modificat și faceți clic pe Gestionare. |
3 |
Selectați PSTN bazat pe premise și faceți clic pe Următorul. |
4 |
Alegeți un trunchi din meniul vertical. Vizitați pagina portbagajului pentru a gestiona opțiunile grupului de trunchiuri. |
5 |
Faceți clic pe notificarea de confirmare, apoi faceți clic pe Salvare. |
Ce trebuie să faceți în continuare
Trebuie să luați informațiile de configurare pe care Control Hub le-a generat și să mapați parametrii în gateway-ul local (de exemplu, pe un CISCO CUBE care se află la fața locului). Acest articol vă plimbă prin acest proces. Ca referință, consultați următoarea diagramă pentru un exemplu despre modul în care informațiile de configurare ale Hubului de control (din stânga) se mapează pe parametrii din CUBE (în dreapta):
După ce ați finalizat cu succes configurarea pe gateway-ul în sine, puteți reveni la
din Control Hub, iar gateway-ul pe care l-ați creat va fi listat în cardul de locație la care l-ați alocat cu un punct verde în partea stângă a numelui. Această stare indică faptul că gateway-ul este înregistrat în siguranță în cloud-ul apelant și servește ca gateway PSTN activ pentru locație.Puteți vizualiza, activa, elimina și adăuga cu ușurință numere de telefon pentru organizația dvs. în Control Hub. Pentru mai multe informații, consultați Gestionarea numerelor de telefon în Control Hub.
Dacă încercați serviciile Webex și doriți să convertiți versiunea de încercare într-un abonament plătit, puteți trimite o solicitare prin e-mail partenerului.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, selectați pictograma de construcție |
2 |
Selectați fila Abonamente , apoi faceți clic pe Achiziție acum. Un e-mail este trimis partenerului prin care îi anunță că sunteți interesat să vă convertiți la un abonament plătit. |
Puteți utiliza Control Hub pentru a seta prioritatea opțiunilor de apelare disponibile pe care utilizatorii le văd în Webex App. De asemenea, le puteți activa pentru un singur clic și apel. Pentru mai multe informații, consultați: Setați opțiuni de apelare pentru utilizatorii Aplicației Webex.
Puteți controla ce se deschide aplicația de apelare atunci când utilizatorii efectuează apeluri. Puteți configura setările clientului de apelare, inclusiv implementarea în mod mixt pentru organizațiile cu utilizatori cu drepturi Unified CM sau Webex Calling și utilizatori fără servicii de apelare plătite de la Cisco. Pentru mai multe informații, consultați: Configurați comportamentul de apelare.
Configurați gateway-ul local în Cisco IOS XE pentru Webex Calling
Prezentare generală
Webex Calling currently supports two versions of Local Gateway:
-
Gateway local
-
Local Gateway for Webex for Government
-
Before you begin, understand the premises-based Public Switched Telephone Network (PSTN) and Local Gateway (LGW) requirements for Webex Calling. Consultați Arhitectura preferată Cisco pentru Apelarea Webex pentru mai multe informații.
-
Acest articol presupune că o platformă dedicată Local Gateway este în loc cu nici o configurație de voce existente. If you modify an existing PSTN gateway or CUBE Enterprise deployment to use as the Local Gateway function for Webex Calling, then pay careful attention to the configuration. Ensure that you don't interrupt the existing call flows and functionality because of the changes that you make.
For information on the supported third-party SBCs, refer to the respective product reference documentation.
Există două opțiuni pentru a configura Gateway-ul local pentru trunchiul de apelare Webex:
-
Portbagaj pe bază de înregistrare
-
Portbagaj pe bază de certificat
Use the task flow either under the Registration-based Local Gateway or Certificate-based Local Gateway to configure Local Gateway for your Webex Calling trunk.
See Get started with Local Gateway for more information on different trunk types. Efectuați următorii pași pe Gateway-ul local în sine, utilizând interfața liniei de comandă (CLI). We use Session Initiation Protocol (SIP) and Transport Layer Security (TLS) transport to secure the trunk and Secure Real Time Protocol (SRTP) to secure the media between the Local Gateway and Webex Calling.
-
Select CUBE as your Local Gateway. Webex for Government doesn’t currently support any third-party Session Border Controllers (SBCs). To review the latest list, see Get started with Local Gateway.
- Install Cisco IOS XE Dublin 17.12.1a or later versions for all Webex for Government Local Gateways.
-
To review the list of root Certificate Authorities (CAs) that Webex for Government support, see Root certificate authorities for Webex for Government.
-
For details on the external port ranges for Local Gateway in Webex for Government, see Network requirements for Webex for Government (FedRAMP).
Local Gateway for Webex for Government doesn’t support the following:
-
STUN/ICE-Lite for media path optimization
-
Fax (T.38)
To configure Local Gateway for your Webex Calling trunk in Webex for Government, use the following option:
-
Portbagaj pe bază de certificat
Use the task flow under the Certificate-based Local Gateway to configure the Local Gateway for your Webex Calling trunk. For more details on how to configure a certificate-based Local Gateway, see Configure Webex Calling certificate-based trunk.
It’s mandatory to configure FIPS-compliant GCM ciphers to support Local Gateway for Webex for Government. If not, the call setup fails. For configuration details, see Configure Webex Calling certificate-based trunk.
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using a registering SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The image below highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Pasul 1: Configure router baseline connectivity and security
-
Pasul 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Pasul 3: Configure Local Gateway with SIP PSTN trunk
-
Pasul 4: Configure Local Gateway with existing Unified CM environment
Sau:
-
Pasul 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All registration-based Local Gateway deployments require Cisco IOS XE 17.6.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Advantage licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
Acls
-
User authentication and remote access
-
DNS
-
Rutare IP
-
IP addresses
-
-
The network toward Webex Calling must use an IPv4 address.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configurare
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:
|
3 |
Create a placeholder PKI trustpoint. Requires this trustpoint to configure TLS later. For registration-based trunks, this trustpoint doesn't require a certificate - as would be required for a certificate-based trunk. |
4 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands. Transport parameters should also be updated to ensure a reliable secure connection for registration: The cn-san-validate server command ensures that the Local Gateway permits a connection if the host name configured in tenant 200 is included in either the CN or SAN fields of the certificate received from the outbound proxy.
|
5 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a registration based PSTN trunk for an existing location in Control Hub. Make a note of the trunk information that is provided once the trunk has been created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Iată o explicație a câmpurilor pentru configurație:
Enables Cisco Unified Border Element (CUBE) features on the platform. media statisticsPermite monitorizarea media pe Gateway-ul local. media bulk-statsPermite planului de control să sondeze planul de date pentru statisticile apelurilor în bloc. For more information on these commands, see Media. allow-connections sip to sipEnable CUBE basic SIP back-to-back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. |
3 |
Configure voice class codec 100 filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Iată o explicație a câmpurilor pentru configurație: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. Iată o explicație a câmpurilor pentru configurație: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams |
5 |
Configure the media encryption policy for Webex traffic. Iată o explicație a câmpurilor pentru configurație: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination trunk parameter: Iată o explicație a câmpurilor pentru configurație: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use dtg= followed by the Trunk OTG/DTG value provided in Control Hub when the trunk was created. For more information, see voice class uri. |
7 |
Configure sip profile 100, which will be used to modify SIP messages before they are sent to Webex Calling.
Iată o explicație a câmpurilor pentru configurație:
|
8 |
Configure Webex Calling trunk: |
After you define tenant 100 and configure a SIP VoIP dial-peer, the gateway initiates a TLS connection toward Webex Calling. At this point the access SBC presents its certificate to the Local Gateway. The Local Gateway validates the Webex Calling access SBC certificate using the CA root bundle that was updated earlier. If the certificate is recognised, a persistent TLS session is established between the Local Gateway and Webex Calling access SBC. The Local Gateway is then able to use this secure connection to register with the Webex access SBC. When the registration is challenged for authentication:
-
The username, password, and realm parameters from the credentials configuration is used in the response.
-
The modification rules in sip profile 100 are used to convert SIPS URL back to SIP.
Registration is successful when a 200 OK is received from the access SBC.
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Iată o explicație a câmpurilor pentru configurație: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifică faptul că dial-peer 200 gestionează picioarele de apel SIP. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite segmentul de apel. Ținta sesiunii aici este adresa IP a ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN a IP. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. For more information, see DTMF Relay (Voice over IP). no vadDezactivează detectarea activității vocale. For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Iată o explicație a câmpurilor pentru configurație: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Iată o explicație a câmpurilor pentru configurație: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vadDezactivează detectarea activității vocale. For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
When creating the Webex Calling trunk in Unified CM, ensure that you configure the incoming port in the SIP Trunk Security Profile settings to 5065. This allows incoming messages on port 5065 and populate the VIA header with this value when sending messages to the Local Gateway.
1 |
Configurați următoarele URL-uri de clasă de voce: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Iată o explicație a câmpurilor pentru configurație: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. De exemplu: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
Semnăturile de diagnosticare (DS) detectează proactiv problemele observate frecvent în Gateway-ul local bazat pe IOS XE și generează e-mail, syslog sau notificare de mesaje terminale ale evenimentului. You can also install the DS to automate diagnostics data collection and transfer-collected data to the Cisco TAC case to accelerate resolution time.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele care declanșează probleme și acțiunile care trebuie întreprinse pentru a informa, a depana și a remedia problema. You can define the problem detection logic using syslog messages, SNMP events and through periodic monitoring of specific show command outputs.
Tipurile de acțiuni includ colectarea ieșirilor de comandă afișare:
-
Generarea unui fișier jurnal consolidat
-
Uploading the file to a user-provided network location such as HTTPS, SCP, FTP server.
Inginerii TAC autor fișierele DS și îl semnează digital pentru protecția integrității. Fiecare fișier DS are un ID numeric unic atribuit de sistem. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Înainte de a începe:
-
Nu editați fișierul DS pe care îl descărcați de la DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
-
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
-
Asigurați-vă că Gateway-ul local execută IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Local Gateway running IOS XE 17.6.1a or higher
-
Semnăturile de diagnosticare sunt activate în mod implicit.
-
Configure the secure email server to be used to send proactive notification if the device is running Cisco IOS XE 17.6.1a or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
-
Configure the environment variable ds_email with the email address of the administrator to notify you.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1a or higher to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
We recommend you to use the Cisco IOS XE Bengaluru 17.6.x or later versions.
call-home mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls diagnostic-signature environment ds_email "tacfaststart@gmail.com"
Un Gateway local care rulează pe Cisco IOS XE Software nu este un client Gmail tipic bazat pe web care acceptă OAuth, deci trebuie să configurăm o anumită setare de cont Gmail și să oferim permisiunea specifică de a avea e-mailul de pe dispozitiv procesat corect:
-
Go to Less secure app access setting.
and turn on the -
Răspundeți la "Da, am fost eu" atunci când primiți un e-mail de la Gmail în care se menționează "Google a împiedicat pe cineva să se conecteze la contul dvs., folosind o aplicație non-Google".
Instalarea semnăturilor de diagnosticare pentru monitorizare proactivă
Monitorizarea utilizării ridicate a procesorului
This DS tracks CPU utilization for five seconds using the SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea ajunge la 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare care sunt instalate în Gateway-ul local. Urmați acești pași de mai jos pentru a instala semnătura.
-
Use the show snmp command to enable SNMP. If you do not enable, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: activat
-
Descărcați DS 64224 utilizând următoarele opțiuni verticale din Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Copiați fișierul DS XML în blițul Local Gateway.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe Gateway-ul local.
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)
-
Instalați fișierul DS XML în Gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare ar trebui să aibă o valoare "înregistrată".
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
Descarca DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv pe sine. If necessary, reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
Monitorizarea înregistrării portbagajului SIP
Acest DS verifică anularea înregistrării unui portbagaj SIP Local Gateway cu cloud webex Calling la fiecare 60 de secunde. Once the unregistration event is detected, it generates an email and syslog notification and uninstalls itself after two unregistration occurrences. Use the steps below to install the signature:
-
Descărcați DS 64117 utilizând următoarele opțiuni verticale din Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
SIP-SIP
Tip de problemă
SIP Trunk Unregistration cu notificare prin e-mail.
-
Copiați fișierul DS XML în Gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
Monitorizarea deconectărilor anormale ale apelurilor
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Use the show snmp command to check whether SNMP is enabled. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: activat
-
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
SIP anormale apel deconectați de detectare cu e-mail și Syslog notificare.
-
Copiați fișierul DS XML în Gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
Instalarea semnăturilor de diagnosticare pentru a depana o problemă
Utilizați semnături de diagnosticare (DS) pentru a rezolva rapid problemele. Cisco TAC ingineri au creat mai multe semnături care permit depanare necesare, care sunt necesare pentru a depana o anumită problemă, detecta apariția problemei, colecta dreptul de set de date de diagnosticare și transferul automat de date la cisco TAC caz. Diagnostic Signatures (DS) eliminate the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva singur o problemă dată sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția "%VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și automatizați colectarea datelor de diagnosticare utilizând următorii pași:
-
Configure an additional DS environment variable ds_fsurl_prefix which is the Cisco TAC file server path (cxd.cisco.com) to which the collected diagnostics data are uploaded. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager in the following command. The file upload token can be generated in the Attachments section of the Support Case Manager, as needed.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Ensure that SNMP is enabled using the show snmp command. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end
-
Asigurați-vă că instalați monitorizarea ridicată a procesorului DS 64224 ca o măsură proactivă pentru a dezactiva toate semnăturile de depanare și diagnosticare în timpul utilizării ridicate a procesorului. Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Syslogs
Tip de problemă
Syslog - %VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0
-
Copiați fișierele DS XML pe Gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
-
Instalați fișierul DS 64224 de monitorizare a procesorului înalt și apoi DS 65095 XML în Gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
-
Verify that the signature is successfully installed using the show call-home diagnostic-signature command. Coloana de stare trebuie să aibă o valoare "înregistrată".
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
DescarcaT DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscris
2020-11-08
Verificarea executării semnăturilor de diagnosticare
In the following command, the “Status” column of the show call-home diagnostic-signature command changes to “running” while the Local Gateway executes the action defined within the signature. Rezultatul statisticilor de diagnosticare a semnăturii de apel la domiciliu este cea mai bună modalitate de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și execută acțiunea. Coloana "Triggered/Max/Deinstall" indică de câte ori semnătura dată a declanșat un eveniment, numărul maxim de ori este definit pentru a detecta un eveniment și dacă semnătura se deinstalează după detectarea numărului maxim de evenimente declanșate.
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
DescarcaT DSes:
ID-ul DS |
Numele DS |
Revizie |
Stare |
Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Înscris |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișarea statisticilor privind semnătura de diagnosticare a apelurilor la domiciliu
ID-ul DS |
Numele DS |
Triggered/Max/Deinstall |
Timp mediu de rulare (secunde) |
Timp maxim de rulare (secunde) |
---|---|---|---|---|
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 |
E-mailul de notificare care este trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația care rulează și afișarea ieșirilor de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalarea semnăturilor de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemelor. If you want to uninstall a signature manually, retrieve the DS ID from the output of the show call-home diagnostic-signature command and run the following command:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor care sunt frecvent observate în implementări. TAC în prezent nu acceptă solicitările de creare de noi semnături particularizate.
For better management of Cisco IOS XE Gateways, we recommend that you enroll and manage the gateways through the Control Hub. It is an optional configuration. When enrolled, you can use the configuration validation option in the Control Hub to validate your Local Gateway configuration and identify any configuration issues. Currently, only registration-based trunks support this functionality.
For more information, refer the following:
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using certificate-based mutual TLS (mTLS) SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The following image highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used. Options are provided for public or private (behind NAT) addressing. SRV DNS records are optional, unless load balancing across multiple CUBE instances.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Pasul 1: Configure router baseline connectivity and security
-
Pasul 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Pasul 3: Configure Local Gateway with SIP PSTN trunk
-
Pasul 4: Configure Local Gateway with existing Unified CM environment
Sau:
-
Pasul 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All certificate-based Local Gateway deployments require Cisco IOS XE 17.9.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Essentials licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
For high-capacity requirements, you may also require a High Security (HSEC) license and additional throughput entitlement.
Refer to Authorization Codes for further details.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
Acls
-
User authentication and remote access
-
DNS
-
Rutare IP
-
IP addresses
-
-
The network toward Webex Calling must use a IPv4 address. Local Gateway Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
All SIP and media ports on the Local Gateway interface facing Webex must be accessible from the internet, either directly or via static NAT. Ensure that you update your firewall accordingly.
-
Install a signed certificate on the Local Gateway (the following provides detailed configuration steps).
-
A public Certificate Authority (CA) as detailed in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? must sign the device certificate.
-
The FQDN configured in the Control Hub when creating a trunk must be the Common Name (CN) or Subject Alternate Name (SAN) certificate of the router. De exemplu:
-
If a configured trunk in the Control Hub of your organization has cube1.lgw.com:5061 as FQDN of the Local Gateway, then the CN or SAN in the router certificate must contain cube1.lgw.com.
-
If a configured trunk in the Control Hub of your organization has lgws.lgw.com as the SRV address of the Local Gateway(s) reachable from the trunk, then the CN or SAN in the router certificate must contain lgws.lgw.com. Înregistrările la care se rezolvă adresa SRV (CNAME, O înregistrare sau adresă IP) sunt opționale în SAN.
-
Whether you use an FQDN or SRV for the trunk, the contact address for all new SIP dialogs from your Local Gateway uses the name configured in the Control Hub.
-
-
-
Asigurați-vă că certificatele sunt semnate pentru utilizarea clientului și a serverului.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configurare
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows: |
3 |
Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA). |
4 |
Authenticate your new certificate using your intermediate (or root) CA certificate, then import the certificate (Step 4). Enter the following exec or configuration command:
|
5 |
Import a signed host certificate using the following exec or configuration command:
|
6 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:
|
7 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a CUBE certificate-based PSTN trunk for an existing location in Control Hub. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. Make a note of the trunk information that is provided once the trunk is created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Iată o explicație a câmpurilor pentru configurație:
Enables Cisco Unified Border Element (CUBE) features on the platform. allow-connections sip to sipEnable CUBE basic SIP back to back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally. These global stun commands are only required when deploying your Local Gateway behind NAT.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. sip-profiles inboundEnables CUBE to use SIP profiles to modify messages as they are received. Profiles are applied via dial-peers or tenants. |
3 |
Configure voice class codec 100 codec filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Iată o explicație a câmpurilor pentru configurație: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. (This step is not applicable for Webex for Government) Iată o explicație a câmpurilor pentru configurație: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. The stun usage firewall-traversal flowdata command is only required when deploying your Local Gateway behind NAT. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams. |
5 |
Configure the media encryption policy for Webex traffic. (This step is not applicable for Webex for Government) Iată o explicație a câmpurilor pentru configurație: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure FIPS-compliant GCM ciphers (This step is applicable only for Webex for Government). Iată o explicație a câmpurilor pentru configurație: voice class srtp-crypto 100Specifies GCM as the cipher-suite that CUBE offers. It is mandatory to configure GCM ciphers for Local Gateway for Webex for Government. |
7 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination FQDN or SRV: Iată o explicație a câmpurilor pentru configurație: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use LGW FQDN or SRV configured in Control Hub while creating a trunk. |
8 |
Configure SIP message manipulation profiles. If your gateway is configured with a public IP address, configure a profile as follows or skip to the next step if you are using NAT. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway and "198.51.100.1" is the public IP address of the Local Gateway interface facing Webex Calling: Iată o explicație a câmpurilor pentru configurație: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. Skip the next step if you have configured your Local Gateway with public IP addresses. |
9 |
If your gateway is configured with a private IP address behind static NAT, configure inbound and outbound SIP profiles as follows. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway, "10.80.13.12" is the interface IP address facing Webex Calling and "192.65.79.20" is the NAT public IP address. SIP profiles for outbound messages to Webex Calling
Iată o explicație a câmpurilor pentru configurație: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. rules 30 to 81Convert private address references to the external public address for the site, allowing Webex to correctly interpret and route subsequent messages. SIP profile for inbound messages from Webex Calling Iată o explicație a câmpurilor pentru configurație: rules 10 to 80Convert public address references to the configured private address, allowing messages from Webex to be correctly processed by CUBE. For more information, see voice class sip-profiles. |
10 |
Configure a SIP Options keepalive with header modification profile. Iată o explicație a câmpurilor pentru configurație: voice class sip-options-keepalive 100Configures a keepalive profile and enters voice class configuration mode. You can configure the time (in seconds) at which an SIP Out of Dialog Options Ping is sent to the dial-target when the heartbeat connection to the endpoint is in UP or Down status. This keepalive profile is triggered from the dial-peer configured towards Webex. To ensure that the contact headers include the SBC fully qualified domain name, SIP profile 115 is used. Rules 30, 40, and 50 are required only when the SBC is configured behind static NAT. In this example, cube1.lgw.com is the FQDN selected for the Local Gateway and if static NAT is used, "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. |
11 |
Configure Webex Calling trunk: |
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Iată o explicație a câmpurilor pentru configurație: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifică faptul că dial-peer 200 gestionează picioarele de apel SIP. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite segmentul de apel. Ținta sesiunii aici este adresa IP a ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN a IP. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. For more information, see DTMF Relay (Voice over IP). no vadDezactivează detectarea activității vocale. For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Iată o explicație a câmpurilor pentru configurație: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Iată o explicație a câmpurilor pentru configurație: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vadDezactivează detectarea activității vocale. For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
1 |
Configurați următoarele URL-uri de clasă de voce: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Iată o explicație a câmpurilor pentru configurație: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. De exemplu: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
Semnăturile de diagnosticare (DS) detectează proactiv problemele observate frecvent în Gateway-ul local bazat pe Cisco IOS XE și generează notificări prin e-mail, syslog sau mesaje terminale ale evenimentului. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în cazul Cisco TAC pentru a accelera timpul de rezoluție.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele și acțiunile de declanșare a problemei pentru a informa, depana și remedia problema. Utilizați mesaje syslog, snmp evenimente și prin monitorizarea periodică a ieșirilor specifice de comandă spectacol pentru a defini logica de detectare a problemelor. Tipurile de acțiuni includ:
-
Colectarea ieșirilor de comandă arată
-
Generarea unui fișier jurnal consolidat
-
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP
Inginerii TAC autor fișiere DS și semnează digital pentru protecția integrității. Fiecare fișier DS are ID-ul numeric unic atribuit de sistem. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Înainte de a începe:
-
Nu editați fișierul DS pe care îl descărcați de la DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
-
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
-
Asigurați-vă că Gateway-ul local execută IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway local care rulează IOS XE 17.6.1 sau o versiune ulterioară
-
Semnăturile de diagnosticare sunt activate în mod implicit.
-
Configure the secure email server that you use to send proactive notification if the device is running IOS XE 17.6.1 or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
-
Configurați variabila ds_email de mediu cu adresa de e-mail a administratorului pentru a vă notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Instalarea semnăturilor de diagnosticare pentru monitorizare proactivă
Monitorizarea utilizării ridicate a procesorului
Acest DS urmărește utilizarea procesorului de 5 secunde folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea ajunge la 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare pe care le instalați în Gateway-ul local. Urmați acești pași de mai jos pentru a instala semnătura.
-
Asigurați-vă că ați activat SNMP utilizând comanda arată snmp. If SNMP is not enabled, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: activat
Descărcați DS 64224 utilizând următoarele opțiuni verticale din Instrumentulde căutare semnături de diagnosticare:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Produs
CUBE Enterprise in Webex Calling solution
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail
-
Copiați fișierul DS XML în blițul Local Gateway.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe Gateway-ul local.
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)
-
Instalați fișierul DS XML în Gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
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
Descarca DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv pe sine. Dacă este necesar, reinstalați DS 64224 pentru a continua monitorizarea utilizării ridicate a procesorului pe Gateway-ul local.
Monitorizarea deconectărilor anormale ale apelurilor
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Asigurați-vă că SNMP este activat utilizând comanda arată snmp. If SNMP is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: activat
-
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
SIP anormale apel deconectați de detectare cu e-mail și Syslog notificare.
-
Copiați fișierul DS XML în Gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
Use the command show call-home diagnostic-signature to verify that the signature is successfully installed. Coloana de stare ar trebui să aibă o valoare „înregistrată”.
Instalați semnături de diagnosticare pentru a depana o problemă
De asemenea, puteți utiliza Semnături de diagnosticare (DS) pentru a rezolva rapid problemele. Cisco TAC ingineri au creat mai multe semnături care permit depanare necesare, care sunt necesare pentru a depana o anumită problemă, detecta apariția problemei, colecta dreptul de set de date de diagnosticare și transferul automat de date la cisco TAC caz. Acest lucru elimină necesitatea de a verifica manual apariția problemei și face rezolvarea problemelor intermitente și tranzitorii mult mai ușoară.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția "%VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și automatizați colectarea datelor de diagnosticare utilizând următorii pași:
Configure another DS environment variable ds_fsurl_prefix as the Cisco TAC file server path (cxd.cisco.com) to upload the diagnostics data. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager as shown in the following. The file upload token can be generated in the Attachments section of the Support Case Manager, as required.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Asigurați-vă că SNMP este activat utilizând comanda arată snmp. If SNMP not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end
-
Vă recomandăm să instalați monitorizarea înaltă a procesorului DS 64224 ca măsură proactivă pentru a dezactiva toate semnăturile de depanare și diagnosticare în timpul utilizării ridicate a procesorului. Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Syslogs
Tip de problemă
Syslog - %VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0
-
Copiați fișierele DS XML pe Gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
-
Install the high CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
-
Verificați dacă semnătura este instalată cu succes utilizând afișarea semnăturiide diagnosticare la domiciliu a apelului. Coloana de stare ar trebui să aibă o valoare "înregistrată".
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
DescarcaT DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscris
2020-11-08:00:12:53
Verificarea executării semnăturilor de diagnosticare
În următoarea comandă, coloana "Stare" a comenzii afișează modificările semnăturii de diagnosticare la domiciliu apel la "rulare", în timp ce Gateway-ul local execută acțiunea definită în semnătură. Rezultatul statisticilor de diagnosticare a semnăturii de apel la domiciliu este cea mai bună modalitate de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și a executat acțiunea. Coloana "Triggered/Max/Deinstall" indică de câte ori semnătura dată a declanșat un eveniment, numărul maxim de ori este definit pentru a detecta un eveniment și dacă semnătura se deinstalează după detectarea numărului maxim de evenimente declanșate.
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
DescarcaT DSes:
ID-ul DS |
Numele DS |
Revizie |
Stare |
Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Înscris |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișarea statisticilor privind semnătura de diagnosticare a apelurilor la domiciliu
ID-ul DS |
Numele DS |
Triggered/Max/Deinstall |
Timp mediu de rulare (secunde) |
Timp maxim de rulare (secunde) |
---|---|---|---|---|
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 |
E-mailul de notificare care este trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația care rulează și afișează ieșirile de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalarea semnăturilor de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemelor. Dacă doriți să dezinstalați manual o semnătură, regăsiți ID-ul DS de la ieșirea de afișare a semnăturii de diagnosticare la domiciliu a apelului și executați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor observate în implementări. TAC în prezent nu acceptă solicitările de creare de noi semnături particularizate.
Implementați disponibilitatea ridicată a CUBE ca gateway local
Fundamentele
Cerințe preliminare
Înainte de a implementa CUBE HA ca gateway local pentru apelarea Webex, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
-
Redundanță box-to-box de la nivelul 2 cu CUBE Enterprise pentru conservarea apelurilor impunătoare
Liniile directoare de configurare furnizate în acest articol presupune o platformă gateway local dedicat cu nici o configurație de voce existente. Dacă o implementare existentă CUBE enterprise este modificată pentru a utiliza, de asemenea, funcția gateway local pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri și funcționalitățile existente nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită IOS-XE versiunea 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și LGW.
Comenzile arată și jurnalele din acest articol se bazează pe lansarea software-ul minim de Cisco IOS-XE 16.12.2 puse în aplicare pe un vCUBE (CSR1000v).
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diverse platforme:
-
Seria ISR 4K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
RSC 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Arhitectura preferată Cisco pentru Apelarea Cisco Webex— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Prezentare generală a soluției de apelare Webex
Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud cu mai multe entități găzduite la serviciul de telefonie PBX local, cu mai multe opțiuni PSTN pentru clienți.
Implementarea Local Gateway (reprezentată mai jos) este punctul central al acestui articol. Portbagajul gateway-ului local (PSTN bazat pe premise) din Webex Calling permite conectivitatea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare IP PBX locală, cum ar fi Cisco Unified CM. Toate comunicațiile către și de la cloud sunt securizate utilizând tls transport pentru SIP și SRTP pentru mass-media.
Figura de mai jos afișează o implementare Webex Calling fără niciun PBX IP existent și se aplică unei implementări unice sau multi-site. Configurația descrisă în acest articol se bazează pe această implementare.
Redundanță de la cutie la nivel 2
Redundanța box-to-box CUBE HA layer 2 utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) în interfețele lor respective și schimbă continuu mesajele de stare. Cube informații sesiune este check-pointed peste perechea de routere care să permită router standby pentru a lua toate responsabilitățile CUBE apel de procesare peste imediat în cazul în care router-ul activ iese din serviciu, rezultând în păstrarea statuos de semnalizare și mass-media.
Indicația de verificare este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt marcate (de exemplu, o stare de încercare sau de apel).
În acest articol, CUBE HA se va referi la cube high availability (HA) Layer 2 Box-to-box (B2B) redundanță pentru conservarea apelurilor impunătoare
Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca gateway local pentru implementările trunchiului de apelare Cisco Webex (PSTN bazat pe premise) și vom acoperi considerațiile și configurațiile de proiectare din acest articol. Această cifră afișează o configurare tipică CUBE HA ca Gateway local pentru o implementare a trunchiului Cisco Webex Calling.
Componenta infra a grupului de redundanță
Componenta Infra a grupului de redundanță (RG) oferă suportul pentru infrastructura de comunicații box-to-box între cele două CUBEs și negociază starea finală de redundanță stabilă. Această componentă oferă, de asemenea:
-
Un protocol de tip HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și salut între cele două CUBEs (prin interfața de control) - GigabitEthernet3 în figura de mai sus.
-
Un mecanism de transport pentru punctarea semnalizării și a stării media pentru fiecare apel de la routerul activ la cel standby (prin interfața de date) — GigabitEthernet3 în figura de mai sus.
-
Configurarea și gestionarea interfeței IP virtual (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie să fie configurat special pentru a accepta voce B2B HA.
Gestionarea adreselor IP virtual (VIP) atât pentru semnalizare, cât și pentru mass-media
B2B HA se bazează pe VIP pentru a obține redundanță. Vip-ul și interfețele fizice asociate pe ambele CUBEs din perechea CUBE HA trebuie să se afle pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație de voce (SIP) sunt obligatorii pentru suportul vocal B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling access SBC, furnizorul de servicii sau proxy-ul, utilizează VIP ca adresă IP de destinație pentru apelurile care traversează routerele CUBE HA. Prin urmare, din punct de vedere webex Calling, perechile CUBE HA acționează ca un singur gateway local.
Informațiile despre semnalizarea apelurilor și sesiunea RTP a apelurilor stabilite sunt punctate de la routerul activ la routerul standby. Când routerul activ coboară, routerul Standby preia controlul și continuă să redirecționeze fluxul RTP care a fost anterior direcționat de primul router.
Apelurile într-o stare tranzitorie în momentul nereușitei nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt încă pe deplin stabilite sau sunt în curs de a fi modificate cu o funcție de transfer sau reținere. Apelurile stabilite pot fi deconectate după comutare.
Există următoarele cerințe pentru utilizarea CUBE HA ca gateway local pentru reluarea impunătoare a apelurilor:
-
CUBE HA nu poate avea TDM sau interfețe analogice co-localizate
-
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP / RTP), iar Gig3 este redundanță Grup (RG) Control / interfață de date
-
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu de nivel 2, unul cu id-ul grupului 1 și celălalt cu id-ul grupului 2. Dacă configurați 2 perechi HA cu același ID de grup, interfețele RG Control/Data trebuie să aparțină unor domenii de nivel 2 diferite (vlan, comutator separat)
-
Canalul de port este acceptat atât pentru interfețele de control/date RG, cât și pentru interfețele de trafic
-
Toate de semnalizare / mass-media este provenind de la / la adresa IP virtuală
-
Ori de câte ori o platformă este reîncărcată într-o relație CUBE-HA, aceasta pornește întotdeauna ca Standby
-
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
-
Identificatorul interfeței de redundanță, rii ar trebui să fie unic pentru o combinație pereche/interfață pe același Strat 2
-
Configurația pe ambele CUBEs trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
-
Interfețe loopback nu pot fi utilizate ca se leagă, deoarece acestea sunt întotdeauna în sus
-
Interfețele cu trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea urmăririi interfeței
-
CUBE-HA nu este acceptat printr-o conexiune prin cablu crossover pentru RG-control/link-ul de date (Gig3)
-
Ambele platforme trebuie să fie identice și să fie conectate printr-un switch fizic între toate interfețele de referință pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
-
Nu poate avea WAN reziliat pe cubes direct sau de date HA pe fiecare parte
-
Ambele Active/Standby trebuie să fie în același centru de date
-
Este obligatorie utilizarea interfeței L3 separate pentru redundanță (RG Control/data, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea ha și punctul de control
-
În caz de nereușită, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media
Configurarea redundanței pe ambele CUB-uri
Trebuie să configurați redundanța box-to-box de la nivelul 2 la ambele CUBEs destinate a fi utilizate într-o pereche HA pentru a aduce IP-uri virtuale.
1 |
Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât ruta activă va avea un rol destul de activ după ce interfața de trafic este în jos. | ||
2 |
Configurați un RG pentru utilizare cu VoIP HA sub-modul de redundanță a aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
3 |
Activați redundanța box-to-box pentru aplicația CUBE. Configure the RG from the previous step under
redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. Vom reîncărca platformele după ce s-a aplicat toată configurația. | ||
4 |
Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, așa cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
5 |
Salvați configurația primului CUBE și reîncărcați-l. Platforma pentru a reîncărca ultima este întotdeauna standby.
După ce VCUBE-1 pornește complet, salvați configurația VCUBE-2 și reîncărcați-o.
| ||
6 |
Verificați că configurația box-to-box funcționează așa cum vă așteptați. Rezultatele relevante sunt evidențiate cu caractere aldine. Am reîncărcat VCUBE-2 ultima și ca pe considerente de proiectare; platforma pentru a reîncărca ultima va fi întotdeauna standby. |
Configurarea unui gateway local pe ambele CUB-uri
În configurația noastră exemplu, folosim următoarele informații trunchi din Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt după cum urmează:
-
Nume utilizator: Hussain1076_LGU
-
Parolă: lOV12MEaZx
1 |
Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditări sau secrete partajate. Parolele de tip 6 sunt criptate folosind cifrul AES și această cheie de configurare definită de utilizator.
Iată configurația Local Gateway care se va aplica ambelor platforme pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. SIP Digest credentials from Control Hub are highlighted in bold.
Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând din VCUBE-1 CUBUL standby și VCUBE-2 CUBUL activ |
2 |
În orice moment, o singură platformă va menține o înregistrare activă ca Gateway local cu SBC-ul de acces webex Calling. Aruncați o privire la ieșirea următoarelor comenzi de afișare. prezintă grupul de cereri de redundanță 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
3 |
Acum activați următoarele depanări pe VCUBE-1
|
4 |
Simulați reluarea prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.
Trecerea de la ACTIVE la STANDBY LGW are loc în următorul scenariu, precum și în afară de CLI enumerate mai sus
|
5 |
Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling access SBC. VCUBE-2 ar fi reîncărcat până acum.
VCUBE-1 este acum LGW activ. |
6 |
Uitați-vă la jurnalul de depanare relevant pe VCUBE-1 trimițând un REGISTRU SIP la Webex Apelând prin IP-ul virtual și primind un OK 200.
|
Configurați Unified CM pentru Webex Calling
Configurarea SIP Trunk profil de securitate pentru Trunk la Local Gateway
În cazurile în care Local Gateway și PSTN gateway se află pe același dispozitiv, Unified CM trebuie să fie activat pentru a diferenția între două tipuri diferite de trafic (apeluri de la Webex și de la PSTN) care provin de pe același dispozitiv și pentru a aplica o clasă diferențiată de servicii acestor tipuri de apeluri. Acest tratament de apel diferențiat se realizează prin asigurarea a două trunchiuri între Unified CM și gateway-ul local combinat și pstn gateway dispozitiv care necesită porturi diferite de ascultare SIP pentru cele două trunchiuri.
Creați un profil de securitate dedicat SIP Trunk pentru trunchiul Local Gateway cu următoarele setări:
|
Configurarea profilului SIP pentru trunchiul gateway-ului local
Creați un profil SIP dedicat pentru trunchiul Local Gateway cu următoarele setări:
|
Crearea unui spațiu de căutare a apelurilor pentru apelurile de la Webex
Creați un spațiu de căutare a apelurilor pentru apelurile care provin de la Webex cu următoarele setări:
Ultima partiție onNetRemote este utilizată numai într-un mediu multi-cluster în care informațiile de rutare sunt schimbate între clustere CM unificate utilizând Intercluster Lookup Service (ILS) sau Global Dialplan Replication (GDPR). |
Configurarea unui trunchi SIP către și de la Webex
Creați un trunchi SIP pentru apelurile către și de la Webex prin Gateway-ul local cu următoarele setări:
|
Configurarea Grupului de rute pentru Webex
Creați un grup de rute cu următoarele setări:
|
Configurarea listei de rute pentru Webex
Creați o listă de rute cu următoarele setări:
|
Crearea unei partiții pentru destinații webex
Creați o partiție pentru destinațiile Webex cu următoarele setări:
|
Ce trebuie să faceți în continuare
Asigurați-vă că adăugați această partiție la toate spațiile de căutare apelante care ar trebui să aibă acces la destinații webex. Trebuie să adăugați această partiție în mod specific la spațiul de căutare apelant care este utilizat ca spațiu de căutare de apelare la intrare pe trunchiurile PSTN, astfel încât apelurile de la PSTN la Webex să poată fi direcționate.
Configurarea modelelor de rute pentru destinațiile Webex
Configurați modelele de rute pentru fiecare interval DID de pe Webex cu următoarele setări:
|
Configurarea normalizării abreviate a apelării intersite pentru Webex
Dacă webex este necesară apelarea prescurtată între site-uri, configurați modelele de normalizare a apelului pentru fiecare interval ESN de pe Webex cu următoarele setări:
|
Configurați funcțiile dvs. Webex Calling
Configurarea unui grup de vânătoare
Grupurile de vânătoare direcționează apelurile primite către un grup de utilizatori sau spații de lucru. Puteți configura chiar și un model pentru a ruta la un grup întreg.
Pentru mai multe informații despre cum să configurați un grup de vânătoare, consultați Grupuri de vânătoare în Cisco Webex Control Hub.
Crearea unei cozi de apel
Puteți configura o coadă de apeluri, astfel încât, atunci când apelurile clienților nu pot fi răspunse, să li se ofere un răspuns automat, mesaje de confort și muzică în așteptare până când cineva poate răspunde la apel.
Pentru mai multe informații despre cum să configurați și să gestionați o coadă de apel, consultați Gestionarea cozilor de apeluri în Cisco Webex Control Hub.
Crearea unui client recepționer
Ajutați-vă să susțineți nevoile personalului din front-office. Puteți configura utilizatorii ca însoțitori de telefon, astfel încât să poată filtra apelurile primite către anumite persoane din cadrul organizației dvs.
Pentru informații despre cum să configurați și să vizualizați clienții recepționer, consultați Clienții recepționer din Cisco Webex Control Hub.
Crearea și gestionarea operatorilor automați
Puteți să adăugați felicitări, să configurați meniuri și să direcționați apelurile către un serviciu de răspuns, un grup de vânătoare, o casetă de mesagerie vocală sau o persoană reală. Creează un program de 24 de ore sau oferă opțiuni diferite atunci când afacerea ta este deschisă sau închisă.
Pentru informații despre cum să creați și să gestionați operatorii automați, consultați Gestionarea operatorilor automați în Cisco Webex Control Hub.
Configurarea unui grup de paginare
Paginarea în grup permite unui utilizator să plaseze o pagină de apel sau de grup unidirecțională la până la 75 de utilizatori și spații de lucru țintă, formând un număr sau o extensie atribuită unui anumit grup de paginare.
Pentru informații despre configurarea și editarea grupurilor de paginare, consultați Configurarea unui grup de paginare în Cisco Webex Control Hub.
Configurarea preluării apelurilor
Îmbunătățiți munca în echipă și colaborarea prin crearea unui grup de preluare a apelurilor, astfel încât utilizatorii să poată răspunde reciproc la apeluri. Când adăugați utilizatori la un grup de preluare a apelurilor și un membru al grupului este plecat sau ocupat, un alt membru poate răspunde la apelurile lor.
Pentru informații despre cum să configurați un grup de preluare a apelurilor, consultați Preluarea apelurilor în Cisco Webex Control Hub.
Configurarea parcului de apeluri
Call park permite unui grup definit de utilizatori să parcheze apelurile împotriva altor membri disponibili ai unui grup de call park. Apelurile parcate pot fi preluate de alți membri ai grupului pe telefonul lor.
Pentru mai multe informații despre cum să configurați parcul de apeluri, consultați Call Park în Cisco Webex Control Hub.
Activați barge-in pentru utilizatori
1 |
Din vizualizarea clientului din https://admin.webex.com, accesați . |
2 |
Selectați un utilizator și faceți clic pe Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizatori , apoi selectați Barge. |
4 |
Activați comutatorul pentru a permite altor utilizatori să se adauge la apelul în curs al acestui utilizator. |
5 |
Verificați Redați un ton atunci când acest utilizator intră într-un apel dacă doriți să redați un ton altor persoane atunci când acest utilizator intră în apel. Tonul Redați un ton atunci când acest utilizator intră într-o setare de apeluri nu se aplică funcționalității de tip barge-in a supervizorului Experience Basic și Essentials. Chiar dacă activați această opțiune pentru un supraveghetor, sistemul nu redă tonul de notificare agentului atunci când un supraveghetor intră în apelul din coada de apeluri. Dacă doriți să redați un ton unui agent atunci când un supraveghetor intră în apel, îl puteți activa prin setările „Ton de notificare pentru agenți”. Pentru mai multe informații, consultați secțiunea Creare coadă din Webex Customer Experience Basic sau Webex Customer Experience Essentials. |
6 |
Faceți clic pe Salvați. |
Activați confidențialitatea pentru un utilizator
1 |
Conectați-vă la Control Hub și accesați . |
2 |
Alegeți un utilizator și faceți clic pe Apelare. |
3 |
Accesați zona Permisiuni între utilizatori și apoi alegeți Confidențialitate. |
4 |
Alegeți setările de confidențialitate ale Operatorului automat corespunzătoare pentru acest utilizator.
|
5 |
Bifați caseta de selectare Activare confidențialitate . Apoi, puteți decide să blocați pe toată lumea, nealegând membri din lista derulantă. Alternativ, puteți alege utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei acestui utilizator. Dacă sunteți administrator de locație, în lista derulantă apar numai utilizatorii, spațiile de lucru și liniile virtuale referitoare la locațiile atribuite. Debifați caseta de selectare Activare confidențialitate pentru a permite tuturor să monitorizeze starea liniei. |
6 |
Verificați Confidențialitatea impunerii pentru preluarea apelurilor direcționate și caseta de selectare pentru înscriere pentru a activa confidențialitatea pentru preluarea apelurilor direcționate și înscriere.
|
7 |
Din Adăugați membru după nume, alegeți utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei telefonice și pot invoca preluarea apelurilor direcționate și intrarea în rețea. |
8 |
Pentru a filtra membrii pe care îi selectați, utilizați filtrul după nume, număr sau câmp text. |
9 |
Faceți clic pe Eliminare toate pentru a elimina toți membrii selectați. Pentru a elimina un membru individual, faceți clic pe Ștergere de lângă numele membrului. |
10 |
Faceți clic pe Salvați. |
Configurați monitorizarea
Numărul maxim de linii monitorizate pentru un utilizator este de 50. Cu toate acestea, în timp ce configurați lista de monitorizare, luați în considerare numărul de mesaje care afectează lățimea de bandă dintre Webex Calling și rețeaua dvs. De asemenea, determinați liniile maxime monitorizate de numărul de butoane de linie de pe telefonul utilizatorului.
1 |
Din vizualizarea clientului din https://admin.webex.com, accesați Management și apoi faceți clic pe Utilizatori. |
2 |
Selectați utilizatorul pe care doriți să-l modificați și faceți clic pe Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizatori și selectați Monitorizare. |
4 |
Alegeți dintre următoarele:
Puteți include o linie virtuală în lista Adăugare linie monitorizată pentru monitorizarea utilizatorului. |
5 |
Alegeți dacă doriți să notificați acest utilizator despre apelurile parcate, căutați persoana sau extensia de parcare a apelurilor care urmează să fie monitorizată, apoi faceți clic pe Salvare. Lista de linii monitorizate din Control Hub corespunde ordinii liniilor monitorizate care se afișează pe dispozitivul utilizatorului. Puteți reordona lista liniilor monitorizate în orice moment. Numele care apare pentru linia monitorizată este numele introdus în câmpurile Nume și prenume ID apelant pentru utilizator, spațiu de lucru și linie virtuală. |
Activați tonul de avertizare prin punte de apel pentru utilizatori
Înainte de a începe
1 |
Conectați-vă la Control Hub și accesați . |
2 |
Selectați un utilizator și faceți clic pe fila Apelare. |
3 |
Accesați Permisiuni între utilizatori și faceți clic pe Call Bridging Warning Tone. |
4 |
Activați funcția Call Bridging Warning Tone, apoi faceți clic pe Save. În mod implicit, această funcție este activată. Pentru mai multe informații despre conectarea la apel pe o linie MPP partajată, consultați liniile partajate de pe telefonul dvs. de birou pentru mai multe platforme. Pentru mai multe informații despre conectarea apelurilor pe o linie partajată a aplicației Webex, consultați aspectul liniei partajate pentru WebexApp. |
Activarea hoteling-ului pentru un utilizator
1 |
Din vizualizarea clientului din https://admin.webex.com, accesați Management și selectați Utilizatori. |
2 |
Selectați un utilizator și faceți clic pe fila Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizatori și selectați Hoteling și activați comutatorul. |
4 |
Introduceți numele sau numărul gazdei hotelului în câmpul de căutare Hotel Location și alegeți gazda hotelului pe care doriți să o alocați utilizatorului. Se poate selecta doar o singură gazdă hotelieră. Dacă alegeți o altă gazdă hotelieră, prima este ștearsă. Dacă sunteți administrator de locație, puteți aloca numai gazda hotelului referitoare la locațiile alocate. |
5 |
Pentru a limita timpul în care un utilizator poate fi asociat cu gazda hotelului, alegeți numărul de ore pe care utilizatorul le poate utiliza gazda hotelului din lista derulantă Limit Association Period . Utilizatorul se va deconecta automat după ora aleasă. În ecran se afișează un mesaj de eroare dacă perioada limită de asociere specificată pentru utilizator depășește perioada limită de asociere a gazdei alese pentru hotel. De exemplu, dacă gazda hotelului are o perioadă limită de asociere de 12 ore, iar perioada limită de asociere a utilizatorului este de 24 de ore, se afișează un mesaj de eroare. În astfel de cazuri, trebuie să extindeți perioada de asociere limită a gazdei hotelului dacă este nevoie de mai mult timp pentru utilizator. |
6 |
Faceți clic pe Salvați. De asemenea, un utilizator poate căuta și localiza gazda de hotel pe care dorește să o utilizeze din Hubul utilizatorului. Pentru mai multe informații, consultați Accesați profilul de apelare de oriunde. |
Tendințe de adopție și rapoarte de utilizare pentru Webex Calling
Vizualizați rapoartele de apelare
Puteți utiliza pagina Analytics din Control Hub pentru a obține informații despre modul în care utilizatorii utilizează apelarea Webex și aplicația Webex (interacțiune), precum și prepelița experienței lor media de apel. Pentru a accesa analizele Webex Calling, conectați-vă la Control Hub, apoi accesați Analytics și selectați fila Apelare .
1 |
Pentru rapoarte detaliate privind istoricul apelurilor, conectați-vă la Control Hub, apoi accesați . |
2 |
Selectați istoricul detaliat al apelurilor. Pentru informații despre apelurile care utilizează instanță dedicată, consultați Analiza instanțelor dedicate. |
3 |
Pentru a accesa date de calitate media, conectați-vă la Control Hub, apoi accesați Statistici și apoi selectați Apelare. Pentru mai multe informații, consultați Analytics pentru portofoliul de colaborare în cloud.
|
Rulați instrumentul CScan
CScan este un instrument de pregătire a rețelei conceput pentru a testa conexiunea la rețea la Apelarea Webex.
Pentru mai multe informații, consultați Utilizarea CScan pentru a testa calitatearețelei de apelare Webex. |
Pregătiți mediul dvs.
Condiţii generale
Înainte de a configura un gateway local pentru Webex Calling, asigurați-vă că:
Cunoașterea de bază a principiilor VoIP
Cunoașterea de bază a conceptelor de voce Cisco IOS-XE și IOS-XE
Să înțelegeți de bază Protocolul de inițiere sesiuni (SIP)
Aveți o înțelegere de bază a Cisco Unified Communications Manager (Unified CM) dacă modelul dvs. de implementare include Unified CM
Consultați Ghidul de configurare Enterprise Cisco Unified Border Element (CUBE) pentru detalii.
Cerințe hardware și software pentru gateway-ul local
Asigurați-vă că implementarea are una sau mai multe dintre gateway-urile locale, cum ar fi:
Cisco CUBE pentru conectivitate bazată pe IP
Gateway Cisco IOS pentru conectivitate bazată pe TDM
Gateway-ul local vă ajută să migrați la Webex Calling în ritmul propriu. Gateway-ul local integrează implementarea locală existentă cu Webex Calling. De asemenea, puteți utiliza conexiunea PSTN existentă. Consultați Începeți cu gateway-ul local
Cerințe de licență pentru gateway-urile locale
Licențele de apelare CUBE trebuie instalate pe gateway-ul local. Pentru mai multe informații, consultați Ghidul de configurare a elementului de frontieră Cisco Unified.
Cerințe de certificare și securitate pentru gateway-ul local
Webex Calling necesită semnalizare și media securizate. Gateway-ul local efectuează criptarea, iar o conexiune TLS trebuie să fie stabilită la ieșirea din cloud cu următorii pași:
LGW trebuie actualizat cu pachetul rădăcină CA de la Cisco PKI
Se utilizează un set de date de autentificare SIP digest din pagina de configurare trunchiuri a Control Hub pentru a configura LGW (pașii fac parte din configurația care urmează)
Validează pachetul rădăcină CA prezentat certificat
Solicitată pentru datele de autentificare (SIP Digest furnizat)
Cloud-ul identifică care gateway-ul local este înregistrat în siguranță
Firewall, NAT Traversal și cerințele de optimizare a căilor media pentru gateway-ul local
În cele mai multe cazuri, gateway-ul local și punctele finale pot locui în rețeaua de clienți interni, folosind adrese IP private cu NAT. Firewall-ul întreprinderii trebuie să permită traficul de ieșire (SIP, RTP/UDP, HTTP) către anumite adrese IP/porturi, acoperite de informațiile de referință portuare.
Dacă doriți să utilizați Optimizarea căilor media cu ICE, interfața cu care se confruntă Webex Calling a gateway-ului local trebuie să aibă o cale de rețea directă către și de la punctele finale Webex Calling. Dacă punctele finale se află într-o locație diferită și nu există o cale de rețea directă între punctele finale și interfața Webex Calling cu care se confruntă gateway-ul local, atunci gateway-ul local trebuie să aibă o adresă IP publică atribuită interfeței cu care se confruntă Webex Calling pentru apeluri între gateway-ul local și punctele finale pentru a utiliza optimizarea căii media. În plus, trebuie să fie rulează iOS-XE versiunea 16.12.5.
Configurați Webex Calling pentru organizația dvs.
Primul pas pentru a vă pune în funcțiune serviciile Webex Calling este finalizarea Asistentului pentru prima configurare (FTSW). După ce FTSW este finalizat pentru prima locație, nu trebuie să fie finalizat pentru locații suplimentare.
1 | Faceți clic pe linkul Noțiuni introductive din e-mailul de bun venit pe care îl primiți. Adresa de e-mail a administratorului este utilizată automat pentru a vă conecta la Control Hub, unde vi se va solicita să creați parola administratorului. După ce vă conectați, expertul de configurare începe automat. |
2 | Revizuiți și acceptați condițiile de furnizare a serviciilor. |
3 | Revizuiți planul și apoi faceți clic pe Get Started. Managerul contului dvs. este responsabil pentru activarea primilor pași pentru FTSW. Contactați managerul contului dvs. dacă primiți o notificare de „Nu puteți configura apelul”, atunci când selectați Începeți. |
4 | Selectați țara pe care centrul dvs. de date ar trebui să o hărțuiască și introduceți informațiile de contact ale clientului și adresa clientului. |
5 | Faceți clic pe Înainte: Locație implicită. |
6 | Alegeți din următoarele opțiuni:
După ce finalizați expertul de configurare, asigurați-vă că adăugați un număr principal la locația pe care o creați. |
7 | Efectuați următoarele selecții pentru a aplica în această locație:
|
8 | Faceți clic pe Înainte. |
9 | Introduceți o adresă SIP Cisco Webex disponibilă și faceți clic pe Înainte și selectați Finalizare. |
Înainte de a începe
Pentru a crea o nouă locație, pregătiți următoarele informații:
adresă Locație
Numere de telefon dorite (opțional)
1 | Conectați-vă la Control Hub la https://admin.webex.com, accesați . O nouă locație va fi găzduită în centrul de date regional care corespunde țării pe care ați selectat-o utilizând Asistentul pentru prima configurare. |
2 | Configurați setările locației:
|
3 | Faceți clic pe Salvare și apoi alegeți Da/ Nu pentru a adăuga numere la locație acum sau mai târziu. |
4 | Dacă ați făcut clic pe Da, alegeți una dintre următoarele opțiuni:
Alegerea opțiunii PSTN este la fiecare nivel de locație (fiecare locație are doar o singură opțiune PSTN). Puteți să combinați și să potriviți cât mai multe opțiuni doriți pentru implementarea dvs., dar fiecare locație va avea o singură opțiune. După ce ați selectat și ați configurat o opțiune PSTN, o puteți modifica făcând clic pe Gestionare în proprietățile PSTN ale locației. Cu toate acestea, este posibil ca unele opțiuni, cum ar fi Cisco PSTN, să nu fie disponibile după alocarea unei alte opțiuni. Deschideți un caz de asistență pentru îndrumare. |
5 | Alegeți dacă doriți să activați numerele acum sau mai târziu. |
6 | Dacă ați selectat CCP neintegrat sau PSTN local, introduceți Numerele de telefon ca valori separate prin virgulă, apoi faceți clic pe Validare. Numerele sunt adăugate pentru locația specifică. Intrările valide se mută în câmpul Numere validate și intrările nevalide rămân în câmpul Adăugare numere însoțit de un mesaj de eroare. În funcție de țara locației, numerele sunt formatate în funcție de cerințele locale de apelare. De exemplu, dacă este necesar un cod de țară, puteți introduce numere cu sau fără cod și codul este prependat. |
7 | Faceți clic pe Salvați. |
Ce este de făcut în continuare
După ce creați o locație, puteți activa serviciile de urgență 911 pentru acea locație. Consultați Serviciul RedSky Emergency 911 pentru Webex Calling pentru mai multe informații.
Înainte de a începe
Obțineți o listă cu utilizatorii și spațiile de lucru asociate cu o locație: Accesați ștergeți acei utilizatori și spații de lucru înainte de a șterge locația.
şi din meniul derulant, selectaţi locaţia care urmează să fie ştearsă. Trebuie săRețineți că orice numere asociate cu această locație vor fi eliberate înapoi la furnizorul dvs. PSTN; nu veți mai deține aceste numere.
1 | Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 | Clic |
3 | Alegeți Ștergeți locația și confirmați că doriți să ștergeți locația respectivă. De obicei, este nevoie de câteva minute pentru ca locația să fie ștearsă definitiv, dar ar putea dura până la o oră. Puteți verifica starea făcând clic lângă numele locației și selectând Starea de ștergere. |
Puteți schimba configurarea PSTN, numele, fusul orar și limba unei locații după ce a fost creată. Rețineți totuși că noua limbă se aplică numai noilor utilizatori și dispozitive. Utilizatorii și dispozitivele existente continuă să utilizeze vechea limbă.
Pentru locațiile existente, puteți activa serviciile de urgență 911. Consultați Serviciul RedSky Emergency 911 pentru Webex Calling pentru mai multe informații.
1 | Conectați-vă la Control Hub la https://admin.webex.com, accesați . Dacă vedeți un simbol precauție lângă o locație, înseamnă că nu ați configurat încă un număr de telefon pentru acea locație. Nu puteți efectua sau primi apeluri până când nu configurați acel număr. |
2 | (Opțional) În conformitate cu PSTN Connection, selectați fie Cloud Connected PSTN , fie PSTN local (gateway local), în funcție de care ați configurat deja. Faceți clic pe Gestionare pentru a modifica această configurație, apoi recunoașteți riscurile asociate selectând Continuare. Apoi, alegeți una dintre următoarele opțiuni și faceți clic pe Salvare:
|
3 | Pentru locație, selectați Numărul principal din lista derulantă pentru a permite utilizatorilor din locația respectivă să efectueze și să primească apeluri. Numărul principal poate fi atribuit operatorului automat, astfel încât apelanții externi să poată contacta utilizatorii Webex Calling din locația respectivă. Utilizatorii Webex Calling din acea locație pot utiliza, de asemenea, acest număr ca ID-ul de apelant extern atunci când efectuează apeluri. |
4 | (Opțional) La Apelarea de urgență, puteți selecta Identificatorul locației de urgență pentru a-l aloca acestei locații. Această setare este opțională și se aplică numai țărilor care au nevoie de ea. În unele țări (Exemplu: Franța), există cerințe de reglementare pentru ca sistemele radio celulare să stabilească identitatea celulei atunci când efectuați un apel de urgență și să fie puse la dispoziția autorităților de urgență. Alte țări, cum ar fi S.U.A. și Canada, implementează determinarea locației folosind alte metode. Pentru mai multe informații, consultați Apelarea de urgență îmbunătățită. Furnizorul dvs. de apeluri de urgență poate avea nevoie de informații despre rețeaua de acces și este realizat prin definirea unui nou antet de extensie SIP privat, P-Access-Network-Info. Titlul conține informații referitoare la rețeaua de acces. Când setați Identificatorul locației de urgență pentru o locație, valoarea locației este trimisă furnizorului ca parte a mesajului SIP. Contactați furnizorul dvs. de apeluri de urgență pentru a vedea dacă aveți nevoie de această setare și pentru a utiliza valoarea furnizată de furnizorul dvs. de apeluri de urgență.” |
5 | Selectați numărul de mesagerie vocală pe care utilizatorii îl pot apela pentru a-și verifica mesageria vocală pentru această locație. |
6 | (Opțional) Faceți clic pe pictograma creion din partea de sus a paginii Locație pentru a schimba numele locației, limba anunțului, limba e-mail, fusul orar sau adresa după cum este necesar, apoi faceți clic pe Salvare. Schimbarea limbii de anunț are efect imediat pentru toți utilizatorii noi și pentru funcțiile adăugate în această locație. Dacă utilizatorii și/sau funcțiile existente trebuie, de asemenea, să-și schimbe limba de anunț, atunci când vi se solicită, selectați Change pentru utilizatorii și spațiile de lucru existente sau Change pentru funcțiile existente. Faceți clic pe Aplicare. Puteți vizualiza progresul pe pagina Operațiuni . Nu puteți face alte modificări până când acest lucru nu este finalizat. Modificarea fusului orar pentru o locație nu actualizează fusurile orare ale funcțiilor asociate locației. Pentru a edita fusurile orare pentru funcții precum operatorul automat, grupul de hunt și coada de apeluri, accesați fusul Setări generale al caracteristicii specifice pentru care doriți să actualizați fusul orar și să îl editați și să îl salvați acolo. |
Aceste setări sunt pentru apelare internă și sunt, de asemenea, disponibile în expertul de configurare pentru prima dată. Pe măsură ce modificați planul de apelare, numerele de exemplu din actualizarea Control Hub pentru a afișa aceste modificări.
Puteți configura permisiunile de apelare de ieșire pentru o locație. Consultați acești pași pentru a configura permisiunile de apelare de ieșire.
1 | Conectați-vă la Control Hub, accesați , apoi defilați la apelare internă. |
2 | Configurați următoarele preferințe opționale de apelare, după cum este necesar:
|
3 | Specificați apelarea internă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea internă după cum este necesar: , selectați o locație din listă și faceți clic pe
|
4 | Specificați apelarea externă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea externă după cum este necesar: , selectați o locație din listă și faceți clic pe
Impactul asupra utilizatorilor:
|
Dacă sunteți un reseller cu valoare adăugată, puteți utiliza acești pași pentru a începe configurarea gateway-ului local în Control Hub. Când acest gateway este înregistrat în cloud, îl puteți utiliza într-una sau mai multe dintre locațiile dvs. Webex Calling pentru a oferi rutarea către un furnizor de servicii PSTN pentru întreprinderi.
O locație care are un gateway local nu poate fi ștearsă atunci când gateway-ul local este utilizat pentru alte locații.
Înainte de a începe
Odată ce o locație este adăugată și înainte de a configura PSTN-ul local pentru o locație, trebuie să creați un trunchi.
Creați fiecare locație și setări și numere specifice. Locațiile trebuie să existe înainte de a putea adăuga un PSTN local.
Înțelegeți cerințele locale PSTN (gateway local) pentru Webex Calling.
Nu puteți alege mai mult de un trunchi pentru o locație cu PSTN local, dar puteți alege același trunchi pentru mai multe locații.
1 | Conectați-vă la Control Hub la https://admin.webex.com, accesați și selectați Adăugare trunchiuri. |
2 | Selectați o locație. |
3 | Denumiți trunchiul și faceți clic pe Salvare. Numele nu poate fi mai mare de 24 de caractere. |
Ce este de făcut în continuare
Informații trunchiuri apar pe ecran Register Domain, Trunk Group OTG/DTG, Line/Port, și Outbound Proxy Address.
Vă recomandăm să copiați aceste informații din Control Hub și să le lipiți într-un fișier text local sau într-un document, astfel încât să le puteți consulta atunci când sunteți gata să configurați PSTN-ul local.
Dacă pierdeți acreditările, trebuie să le generați din ecranul cu informații despre trunchiuri din Control Hub. Faceți clic pe Recuperare nume de utilizator și resetare parolă pentru a genera un nou set de acreditări de autentificare pe care să le utilizați pe trunchi.
1 | Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 | Selectați o locație pentru a o modifica și faceți clic pe Gestionare. |
3 | Selectați PSTN local și faceți clic pe Înainte. |
4 | Alegeți un trunchi din meniul derulant. Vizitați pagina trunchiurilor pentru a gestiona opțiunile grupului de trunchiuri. |
5 | Faceți clic pe notificarea de confirmare, apoi faceți clic pe Salvare. |
Ce este de făcut în continuare
Trebuie să luați informațiile de configurare pe care le-a generat Control Hub și să mapați parametrii în gateway-ul local (de exemplu, pe un Cisco CUBE care se află la sediu). Acest articol vă plimbă prin acest proces. Ca referință, consultați următoarea diagramă pentru un exemplu al modului în care informațiile de configurare Control Hub (din stânga) se afișează pe parametrii din CUBE (din dreapta):
După ce ați finalizat cu succes configurația de pe gateway în sine, puteți reveni la
în Control Hub și gateway-ul pe care l-ați creat vor fi listate în cardul de locație la care l-ați alocat cu un punct verde în partea stângă a numelui. Această stare indică faptul că gateway-ul este înregistrat în siguranță în cloud-ul de apelare și servește ca gateway-ul PSTN activ pentru locație.Puteți vizualiza, activa, elimina și adăuga cu ușurință numere de telefon pentru organizația dvs. în Control Hub. Pentru mai multe informații, consultați Gestionați numerele de telefon în Control Hub.
Dacă încercați serviciile Webex și doriți să convertiți procesul dvs. într-un abonament plătit, puteți trimite o solicitare de e-mail partenerului dvs.
1 | Conectați-vă la Control Hub la https://admin.webex.com, selectați pictograma de construcție |
2 | Selectați fila Abonamente , apoi faceți clic pe Cumpărare acum. Un e-mail este trimis partenerului dvs., anunțându-i că sunteți interesat să convertiți la un abonament plătit. |
Puteți utiliza Control Hub pentru a stabili prioritatea opțiunilor de apelare disponibile pe care utilizatorii le văd în Aplicația Webex. De asemenea, le puteți activa pentru un singur clic-pentru-apel. Pentru mai multe informații, consultați: Setați opțiuni de apelare pentru utilizatorii Aplicației Webex.
Puteți controla ce se deschide aplicația de apelare atunci când utilizatorii efectuează apeluri. Puteți configura setările clientului de apelare, inclusiv implementarea în mod mixt pentru organizațiile cu utilizatori cu drepturi Unified CM sau Webex Calling și utilizatori fără servicii de apelare plătite de la Cisco. Pentru mai multe informații, consultați: Configurați comportamentul de apelare.
Configurați gateway-ul local în Cisco IOS XE pentru Webex Calling
Prezentare generală
Webex Calling acceptă în prezent două versiuni ale gateway-ului local:
Gateway local
Gateway local pentru Webex for Government
Înainte de a începe, înțelegeți cerințele locale privind rețeaua de telefonie publică comutată (PSTN) și gateway-ul local (LGW) pentru Webex Calling. Consultați Arhitectura preferată Cisco pentru Webex Calling pentru mai multe informații.
Acest articol presupune că există o platformă locală dedicată Gateway, fără o configurație vocală existentă. Dacă modificați un gateway PSTN existent sau implementarea CUBE Enterprise pentru a-l utiliza ca funcție a gateway-ului local pentru Webex Calling, acordați o atenție deosebită configurației. Asigurați-vă că nu întrerupeți fluxurile de apeluri existente și funcționalitatea din cauza modificărilor pe care le efectuați.
Pentru informații privind SBC-urile terță parte acceptate, consultați documentația de referință a produsului respectivă.
Există două opțiuni pentru configurarea gateway-ului local pentru trunchiul dvs. Webex Calling:
trunk bazat pe înregistrare
trunk bazat pe certificat
Utilizați fluxul de activități fie sub gateway-ul local bazat pe înregistrare , fie gateway-ul local bazat pe certificat pentru a configura gateway-ul local pentru trunchiul Webex Calling.
Consultați Începeți cu gateway-ul local pentru mai multe informații despre diferite tipuri de trunchiuri. Efectuați următorii pași pe gateway-ul local în sine, folosind interfața linie de comandă (CLI). Utilizăm protocolul de inițiere sesiuni (SIP) și transportul de securitate a stratului de transport (TLS) pentru a securiza trunchiul și protocolul în timp real securizat (SRTP) pentru a securiza media între gateway-ul local și Webex Calling.
Selectați CUBE ca Gateway local. Webex for Government nu acceptă în prezent niciun controler de frontieră pentru sesiune terță (SBC). Pentru a revizui cea mai recentă listă, consultați Începeți cu gateway-ul local.
- Instalați versiunile Cisco IOS XE Dublin 17.12.1a sau versiuni ulterioare pentru toate gateway-urile locale Webex for Government.
Pentru a revizui lista autorităților de certificare rădăcină (AC) care acceptă Webex for Government, consultați autoritățile de certificare rădăcină pentru Webex for Government.
Pentru detalii despre intervalele de porturi externe pentru gateway-ul local din Webex for Government, consultați cerințele rețelei pentru Webex for Government (FedRAMP).
Gateway-ul local pentru Webex for Government nu acceptă următoarele:
STUN/ICE-Lite pentru optimizarea căii media
Fax (T.38)
Pentru a configura gateway-ul local pentru trunchiul dvs. Webex Calling în Webex for Government, utilizați următoarea opțiune:
trunk bazat pe certificat
Utilizați fluxul de activități din cadrul gateway-ului local bazat pe certificat pentru a configura gateway-ul local pentru trunchiul Webex Calling. Pentru mai multe detalii despre modul de configurare a unui gateway local bazat pe certificate, consultați Configurați trunchiul bazat pe certificate Webex Calling.
Este obligatoriu să configurați cifrele GCM conforme cu FIPS pentru a sprijini gateway-ul local pentru Webex for Government. Dacă nu, configurarea apelului eșuează. Pentru detalii de configurare, consultați Configurați trunchiul bazat pe certificatul Webex Calling.
Această secțiune descrie modul de configurare a unui element de frontieră Cisco Unified (CUBE) ca gateway local pentru Webex Calling, utilizând un trunchi SIP de înregistrare. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Imaginea de mai jos evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
ofertanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup dial-peer: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
În timp ce IP și SIP au devenit protocoalele implicite pentru trunchiurile PSTN, circuitele ISDN TDM (Time Division Multiplexing) sunt încă utilizate pe scară largă și sunt acceptate cu trunchiurile Webex Calling. Pentru a permite optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, este necesar în prezent să se utilizeze un proces de rutare a apelurilor cu două componente. Această abordare modifică configurația de rutare a apelurilor afișată mai sus, introducând un set de colegi de apelare interni cu buclă inversă între trunchiurile Webex Calling și PSTN, după cum se arată în imaginea de mai jos.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe înregistrare necesită versiuni Cisco IOS XE 17.6.1a sau ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe pentru tehnologia de securitate.
Routerele din seria Catalyst Edge 8000, dotate cu carduri vocale sau DSPs, necesită acordarea licenței DNA Advantage. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
ntp
LAC-uri
Autentificare utilizator și acces la distanță
DNS
dirijare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
|
2 | Protejați acreditările de înregistrare și STUN pe router prin criptare simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
|
3 | Creați un punct de încredere PKI pentru titularul plasamentului. Necesită acest punct de încredere pentru a configura TLS mai târziu. Pentru trunchiurile bazate pe înregistrare, acest punct de încredere nu necesită un certificat - așa cum ar fi necesar pentru un trunchi bazat pe certificat.
|
4 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare. Parametrii de transport ar trebui, de asemenea, să fie actualizați pentru a asigura o conexiune sigură și fiabilă pentru înregistrare: Comanda server validată de cn-san asigură că gateway-ul local permite o conexiune dacă numele de gazdă configurat în clientul 200 este inclus în câmpurile CN sau SAN ale certificatului primit de la proxy-ul de ieșire.
|
5 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate: Dacă trebuie să utilizați un proxy pentru a accesa internetul utilizând HTTPS, adăugați următoarea configurație înainte de a importa pachetul CA: IP http client proxy-server yourproxy.com port proxy 80
|
1 | Creați un trunchi PSTN bazat pe înregistrare pentru o locație existentă în Control Hub. Notaţi informaţiile trunchiului care sunt furnizate după ce trunchiul a fost creat. Aceste detalii, așa cum se evidențiază în ilustrația următoare, vor fi utilizate în etapele de configurare din acest ghid. Pentru mai multe informații, consultați Configurați trunchiurile, grupurile de rutare și planurile de apelare pentru Webex Calling. |
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. statistici mediaPermite monitorizarea media pe gateway-ul local. stări colective mediaPermite avionului de control să sondeze planul de date pentru statisticile privind apelurile în masă. Pentru mai multe informații despre aceste comenzi, consultați Media. permite conexiuni sip la sipActivați funcționalitatea de bază a agentului de utilizator SIP back-to-back CUBE. Pentru mai multe informații, consultați Permite conexiuni. În mod implicit, transportul prin fax T.38 este activat. Pentru mai multe informații, consultați protocolul de fax t38 (serviciu vocal). Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata partajate-secret. sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcina utilă asimetrică. ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați oferta timpurie. |
3 | Configurare codec clasă vocală 100 filtru pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codecul clasei de voce. Codec-ul Opus este acceptat numai pentru trunchiurile PSTN bazate pe SIP. Dacă trunchiul PSTN utilizează o conexiune vocală T1/E1 sau analogică FXO, excludeți preferință codec 1 opusul din partea codec clasă vocală 100 configurare . |
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling.
Iată o explicație a câmpurilor pentru configurare: lită de gheață de utilizare stunUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați clasa vocală utilizare stun și lite gheață utilizare stun. Aveți nevoie de utilizarea ICE-lite pentru fluxurile de apeluri prin optimizarea căii media. Pentru a oferi optimizarea media pentru un gateway SIP la TDM, configurați un dial-peer loopback cu ICE-Lite activat pe piciorul IP-IP. Pentru mai multe detalii tehnice, contactați echipele din Cont sau TAC |
5 | Configurați politica de criptare media pentru traficul Webex.
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1_80. Pentru mai multe informații, consultați clasa vocală srtp-crypto. |
6 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza parametrului trunchiului de destinație:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați dtg= urmat de valoarea Trunk OTG/DTG furnizată în Control Hub atunci când trunchiul a fost creat. Pentru mai multe informații, consultați clasa vocală uri. |
7 | Configurare profil sip 100, care va fi utilizat pentru a modifica mesajele SIP înainte de a fi trimise către Webex Calling.
Iată o explicație a câmpurilor pentru configurare:
|
8 | Configurați trunchiul Webex Calling: |
După ce definiți entitatea găzduită 100 și configurați un peer de apelare SIP VoIP, gateway-ul inițiază o conexiune TLS către Webex Calling. În acest moment, SBC de acces își prezintă certificatul la gateway-ul local. Gateway-ul local validează certificatul SBC de acces Webex Calling utilizând pachetul rădăcină CA care a fost actualizat mai devreme. Dacă certificatul este recunoscut, se stabilește o sesiune TLS persistentă între gateway-ul local și accesul Webex Calling SBC. Gateway-ul local este apoi capabil să utilizeze această conexiune securizată pentru a se înregistra la SBC de acces Webex. Când înregistrarea este contestată pentru autentificare:
În răspuns se utilizează numele de utilizator, parola și parametrii domeniului din configurația de acreditări .
Regulile de modificare din profilul sip 100 sunt utilizate pentru a converti URL-ul SIPS înapoi la SIP.
Înscrierea este reușită atunci când un 200 OK este primit de la SBC de acces.
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE.
Dacă utilizați un trunchi TDM / ISDN PSTN, treceți la secțiunea următoare Configurați gateway-ul local cu trunchiul TDM PSTN.
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI.
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește o pereche de apelare VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). sipv2 protocol de sesiuneSpecifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocolul sesiunii (dial peer). țintă sesiune ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite piesa de apel. Ținta sesiunii aici este adresa IP a ITSP. Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec-ul de clasă vocală. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca capacitate DTMF așteptată pe partea de apelare. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
După ce ați construit un trunchi către Webex Calling, utilizați următoarea configurație pentru a crea un trunchi TDM pentru serviciul dvs. PSTN cu rutare de apelare cu buclă inversă pentru a permite optimizarea media pe partea de apelare Webex.
1 | Configurația dial-peer buclă-spate utilizează grupuri dial-peer și etichete de rutare a apelurilor pentru a se asigura că apelurile trec corect între Webex și PSTN, fără a crea bucle de rutare a apelurilor. Configurați următoarele reguli de traducere care vor fi utilizate pentru a adăuga și elimina etichetele de rutare a apelurilor:
Iată o explicație a câmpurilor pentru configurare: regulă de traducere vocalăUtilizează expresii regulate definite în reguli pentru a adăuga sau elimina etichete de rutare a apelurilor. Cifrele de peste zece ani („A”) sunt utilizate pentru a adăuga claritate pentru depanare. În această configurație, eticheta adăugată prin profilul de traducere 100 este utilizată pentru a ghida apelurile de la Webex Calling către PSTN prin intermediul perechilor de apelare loopback. În mod similar, eticheta adăugată prin profilul de traducere 200 este utilizată pentru a ghida apelurile din PSTN către Webex Calling. Profilurile de traducere 11 și 12 elimină aceste etichete înainte de a efectua apeluri către trunchiurile Webex și, respectiv, PSTN. Acest exemplu presupune că numerele apelate din Webex Calling sunt prezentate în format +E.164. Articolul 100 elimină conducerea + pentru a menține un număr de apelare valid. Articolul 12 adaugă apoi o cifră (cifre) de rutare națională sau internațională la eliminarea etichetei. Utilizați cifre care se potrivesc cu planul de apelare național ISDN local. Dacă Webex Calling prezintă numere în format național, ajustați regulile 100 și 12 pentru a adăuga și a elimina pur și simplu eticheta de rutare. Pentru mai multe informații, consultați profilul de traducere vocală și regula de traducere vocală. |
2 | Configurați porturile interfeței vocale TDM conform cerințelor tipului de trunchi și protocolului utilizat. Pentru mai multe informații, consultați Configurarea ISDN PRI. De exemplu, configurația de bază a unei interfețe ISDN cu Rata primară instalată în slotul NIM 2 al unui dispozitiv poate include următoarele:
|
3 | Configurați următorul dial-peer TDM PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește o pereche de apelare VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). profil de traducere 200Atribuiți profilul de traducere care va adăuga o etichetă de rutare a apelurilor la numărul apelat de intrare. apelare directă spre interiorRutează apelul fără a furniza un ton de apel secundar. Pentru mai multe informații, consultați apelare directă. port 0/2/0:15Portul vocal fizic asociat cu acest dial-peer. |
4 | Pentru a permite optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, puteți modifica rutarea apelurilor introducând un set de colegi de apelare interni cu buclă inversă între trunchiurile Webex Calling și PSTN. Configurați următoarele perechi de apelare buclă-spate. În acest caz, toate apelurile primite vor fi dirijate inițial către dial-peer 10 și de acolo către dial-peer 11 sau 12, pe baza etichetei de rutare aplicate. După îndepărtarea etichetei de rutare, apelurile vor fi direcționate către trunchiul de ieșire utilizând grupuri de apelare-pereche.
Iată o explicație a câmpurilor pentru configurare:
Definește o linie de apelare VoIP și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. profil de traducere care sosește 11Se aplică profilul de traducere definit anterior pentru a elimina eticheta de rutare a apelurilor înainte de a trece la trunchiul de ieșire. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). sipv2 protocol de sesiuneSpecifică faptul că acest dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul sesiunii (dial peer). țintă sesiune 192.168.80.14Specifică adresa locală a interfeței routerului ca țintă a apelului pentru buclă de rezervă. Pentru mai multe informații, consultați ținta sesiunii (voip dial peer). Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise prin buclă de rezervă. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mass-media trimisă prin buclă de rezervă. Pentru mai multe informații, consultați legătura. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca capacitate DTMF așteptată pe partea de apelare. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). codec g711alaw Forțează toate apelurile PSTN să utilizeze G.711. Selectați a-law sau u-law pentru a se potrivi cu metoda de constrângere utilizată de serviciul ISDN. nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
5 | Adăugați următoarea configurație de rutare a apelurilor: Acest lucru încheie configurația gateway-ului local. Salvați configurația și reîncărcați platforma dacă aceasta este prima dată când sunt configurate caracteristicile CUBE.
|
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
Atunci când creați trunchiul Webex Calling în Unified CM, asigurați-vă că configurați portul de intrare în setările profilului de securitate al trunchiului SIP la 5065. Acest lucru permite mesajele de intrare pe portul 5065 și populează antetul VIA cu această valoare atunci când trimiteți mesaje către gateway-ul local.
1 | Configurați următoarele URI de clasă vocală: |
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM: IOS XE utilizează aceste înregistrări pentru determinarea locală a gazdelor și porturilor țintă UCM. Cu această configurație, nu este necesar să configurați înregistrări în sistemul DNS. Dacă preferați să utilizați DNS-ul, atunci aceste configurații locale nu sunt necesare.
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. |
3 | Configurați următorii colegi de apelare: |
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe IOS XE și generează notificarea prin e-mail, jurnal de sistem sau mesaj terminal a evenimentului. De asemenea, puteți instala DS-ul pentru a automatiza colectarea datelor de diagnosticare și transferul datelor colectate în cazul Cisco TAC pentru a accelera timpul de rezoluție.
Semnături de diagnosticare (DS) sunt fișiere XML care conțin informații despre declanșarea problemelor evenimente și acțiuni care urmează să fie luate pentru a informa, depanare, și remedia problema. Puteți defini logica de detectare a problemei prin utilizarea mesajelor syslog, a evenimentelor SNMP și prin monitorizarea periodică a ieșirilor specifice ale comenzii de afișare.
Tipurile de acțiune includ colectarea rezultatelor comenzii afișate:
Generarea unui fișier jurnal consolidat
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP.
Inginerii TAC autentifică fișierele DS și o semnează digital pentru protecția integrității. Fiecare fișier DS are un ID numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o singură sursă pentru a găsi semnăturile aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS pe care îl descărcați de pe DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau mai mare dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway-ul local care rulează IOS XE 17.6.1a sau mai mare
Semnăturile de diagnosticare sunt activate în mod implicit.
Configurați serverul de e-mail securizat pentru a fi utilizat pentru a trimite o notificare proactivă dacă dispozitivul rulează Cisco IOS XE 17.6.1a sau o versiune ulterioară.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediu ds_email cu adresa de e-mail a administratorului pentru a vă notifica.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Următoarele afișează un exemplu de configurare a unui gateway local care rulează pe Cisco IOS XE 17.6.1a sau mai mare pentru a trimite notificările proactive către tacfaststart @gmail.com utilizarea Gmail ca server SMTP securizat:
Vă recomandăm să utilizați versiunile Cisco IOS XE Bengaluru 17.6.x sau versiuni ulterioare.
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway local care rulează pe Cisco IOS XE Software nu este un client tipic Gmail bazat pe web care acceptă OAuth, așa că trebuie să configurăm o anumită setare de cont Gmail și să oferim permisiunea specifică de a avea e-mailul de pe dispozitiv procesat corect:
Accesați la aplicație mai puțin securizată.
și activați setarea de accesRăspuns “Da, am fost eu” atunci când primiți un e-mail de la Gmail care spune “Google a împiedicat pe cineva să se conecteze la contul dvs. folosind o aplicație non-Google.”
Instalați semnăturile de diagnosticare pentru monitorizarea proactivă
Monitorizarea utilizării CPU ridicate
Acest DS urmărește utilizarea CPU timp de cinci secunde folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea atinge 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare care sunt instalate în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a activa SNMP. Dacă nu activați, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Seria Cisco 4300, seria ISR 4400 sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Performanță
Tip problemă
Utilizare CPU ridicată cu notificare prin e-mail.
Copiați fișierul XML DS în Flash-ul gateway local.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de la un server FTP la gateway-ul local.
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)
Instalați fișierul XML DS în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișarea semnăturii de diagnosticare la domiciliu comandă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare „înregistrată”.
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
Descărcați DSes:
d.
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate SD-urile care rulează, inclusiv pe cont propriu. Dacă este necesar, reinstalați DS 64224 pentru a continua monitorizarea utilizării ridicate a procesorului pe gateway-ul local.
Monitorizarea înregistrării trunchiurilor SIP
Acest DS verifică anularea înregistrării unui trunchi SIP al gateway-ului local cu cloud Webex Calling la fiecare 60 de secunde. După detectarea evenimentului de neînregistrare, acesta generează o notificare prin e-mail și syslog și se dezinstalează după două evenimente de neînregistrare. Utilizați pașii de mai jos pentru a instala semnătura:
Descărcați DS 64117 utilizând următoarele opțiuni derulante din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Seria Cisco 4300, seria ISR 4400 sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
sip-sip
Tip problemă
Anularea înregistrării trunchiurilor SIP cu notificare prin e-mail.
Copiați fișierul XML DS la gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
Instalați fișierul XML DS în gateway-ul local.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
Utilizați afișarea semnăturii de diagnosticare la domiciliu comandă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare „înregistrată”.
Se deconectează funcția de monitorizare a apelului anormal
Acest DS utilizează sondajul SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erori SIP 403, 488 și 503. Dacă creșterea numărului de erori este mai mare sau egală cu 5 din ultimul sondaj, aceasta generează o notificare syslog și e-mail. Utilizați pașii de mai jos pentru a instala semnătura.
Utilizați afișare snmp comandă pentru a verifica dacă SNMP este activat. Dacă nu este activată, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Seria Cisco 4300, seria ISR 4400 sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Performanță
Tip problemă
Detectarea anormală a deconectării apelurilor SIP cu notificarea prin e-mail și Syslog.
Copiați fișierul XML DS la gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișierul XML DS în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați afișarea semnăturii de diagnosticare la domiciliu comandă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare „înregistrată”.
Instalați semnăturile de diagnosticare pentru a depana o problemă
Utilizați semnăturile de diagnosticare (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au autentificat mai multe semnături care permit depanările necesare care sunt necesare pentru a rezolva o anumită problemă, pentru a detecta apariția problemei, pentru a colecta setul corect de date de diagnosticare și pentru a transfera automat datele în cazul Cisco TAC. Semnăturile de diagnosticare (DS) elimină necesitatea de a verifica manual apariția problemei și facilitează mult soluționarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a se rezolva o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_IEC-3-GW: Cefalee: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare utilizând următorii pași:
Configurați o variabilă suplimentară de mediu DS ds_fsurl_prefix care este calea serverului de fișiere Cisco TAC (cxd.cisco.com) la care sunt încărcate datele de diagnosticare colectate. Numele de utilizator din calea fișierului este numărul de caz, iar parola este tokenul de încărcare a fișierului care poate fi preluat de la Support Case Manager în următoarea comandă. Tokenul de încărcare a fișierului poate fi generat în secțiunea Atașamente a managerului de caz al asistenței, după cum este necesar.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând afișare snmp comandă . Dacă nu este activată, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Asigurați-vă că pentru a instala High CPU de monitorizare DS 64224 ca o măsură proactivă pentru a dezactiva toate depanările și semnăturile de diagnosticare în timpul utilizării CPU mare. Descărcați DS 64224 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Performanță
Tip problemă
Utilizare CPU ridicată cu notificare prin e-mail.
Descărcați DS 65095 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau seria Cisco CSR 1000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Jurnale de sistem
Tip problemă
Syslog - %VOICE_IEC-3-GW: Cefalee: Eroare internă (prag al indicatorului de apel): iec=1. 1. 181. 1. 29. 0
Copiați fișierele XML DS la gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișierul XML de monitorizare DS 64224 și apoi DS 65095 în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând afișarea semnăturii de diagnosticare la domiciliu comandă . Coloana de stare trebuie să aibă o valoare „înregistrată”.
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
Descărcat DSes:
d.
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscriși
2020-11-08
Verificați executarea semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a afișarea semnăturii de diagnosticare la domiciliu comanda se modifică pentru a „rula” în timp ce gateway-ul local execută acțiunea definită în cadrul semnăturii. Emiterea afișarea statisticilor privind semnătura diagnosticului la domiciliu este cel mai bun mod de a verifica dacă o semnătură de diagnostic detectează un eveniment de interes și execută acțiunea. Coloana „Triggered/Max/Deinstall” indică numărul de ori pe care semnătura dată l-a declanșat un eveniment, numărul maxim de ori pe care este definit pentru a detecta un eveniment și dacă semnătura se instalează după detectarea numărului maxim de evenimente declanșate.
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
Descărcat DSes:
d. | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0.0.10 | Înscriși | 2020-11-08 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | Rulare | 2020-11-08 00:12:53 |
afișarea statisticilor semnăturii diagnostice la domiciliu
d. | Nume DS | Dezactivată/Max/Dezactivare | Timp mediu de rulare (secunde) | Timpul maxim de rulare (secunde) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0/0/n | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/ŞI | 23.053 | 23.053 |
E-mailul de notificare trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația de funcționare și afișarea ieșirilor de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizați semnăturile de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor evenimente de probleme. Dacă doriți să dezinstalați manual o semnătură, recuperați ID-ul DS de la ieșirea din afișarea semnăturii de diagnosticare la domiciliu comandă și executați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor care sunt frecvent observate în implementări. TAC nu acceptă în prezent solicitări pentru a crea noi semnături personalizate.
Pentru o mai bună gestionare a gateway-urilor Cisco IOS XE, vă recomandăm să vă înscrieți și să gestionați gateway-urile prin Control Hub. Este o configurație opțională. Când sunteți înscris(ă), puteți utiliza opțiunea de validare a configurației din Control Hub pentru a valida configurația gateway-ului local și pentru a identifica orice probleme de configurare. În prezent, numai trunchiurile bazate pe înregistrare acceptă această funcționalitate.
Pentru mai multe informații, consultați următoarele:
Această secțiune descrie modul de configurare a unui element de frontieră Unified Cisco (CUBE) ca gateway local pentru Webex Calling, utilizând trunchiul SIP TLS (mTLS) bazat pe certificate. Prima parte a acestui document ilustrează modul de configurare a unui gateway PSTN simplu. În acest caz, toate apelurile din PSTN sunt direcționate către Webex Calling și toate apelurile din Webex Calling sunt direcționate către PSTN. Următoarea imagine evidențiază această soluție și configurația de rutare a apelurilor la nivel înalt care va fi urmată.
În acest design se utilizează următoarele configurații principale:
cursanți de clasă vocală: Utilizat pentru a crea configurații specifice trunchiului.
clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
peer apelare de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup dial-peer.
grup peer-dial: Definește colegii de apelare de ieșire utilizați pentru rutarea continuă a apelurilor.
peer apelare de ieșire: Oferă tratament pentru mesajele SIP de ieșire și le trasează la ținta necesară.
În timp ce IP și SIP au devenit protocoalele implicite pentru trunchiurile PSTN, circuitele ISDN TDM (Time Division Multiplexing) sunt încă utilizate pe scară largă și sunt acceptate cu trunchiurile Webex Calling. Pentru a permite optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, este necesar în prezent să se utilizeze un proces de rutare a apelurilor cu două componente. Această abordare modifică configurația de rutare a apelurilor afișată mai sus, introducând un set de colegi de apelare interni cu buclă inversă între trunchiurile Webex Calling și PSTN, după cum se arată în imaginea de mai jos.
Atunci când conectați o soluție locală Cisco Unified Communications Manager cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca bază pentru construirea soluției ilustrate în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratare centralizată a tuturor apelurilor PSTN și Webex Calling.
Pe parcursul acestui document se utilizează numele gazdei, adresele IP și interfețele ilustrate în următoarea imagine. Opțiunile sunt prevăzute pentru abordarea publică sau privată (în spatele NAT). Înregistrările DNS SRV sunt opționale, cu excepția cazului în care sarcina este echilibrată în mai multe instanțe CUBE.
Utilizați ghidurile de configurare din restul acestui document pentru a finaliza configurația gateway-ului local după cum urmează:
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați fie:
Pasul 3: Configurați gateway-ul local cu trunchiul SIP PSTN
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
configurație Inițială
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este construirea unei configurații de bază care să vă securizeze platforma și să vă stabilească conectivitatea.
Toate implementările gateway locale bazate pe certificate necesită versiuni Cisco IOS XE 17.9.1a sau versiuni ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerate .
Routerele din seria ISR4000 trebuie configurate atât cu licențe Unified Communications, cât și cu licențe pentru tehnologia de securitate.
Routerele din seria Catalyst Edge 8000 echipate cu carduri vocale sau DSPs necesită licențiere ADN Essentials. Routere fără carduri vocale sau DSPs necesită un minim de licențiere ADN Essentials.
Pentru cerințele de înaltă capacitate, puteți solicita, de asemenea, o licență de înaltă securitate (HSEC) și un drept suplimentar de tranzit.
Consultați Codurile de autorizare pentru detalii suplimentare.
Construiți o configurație de bază pentru platforma dvs. care să respecte politicile dvs. de afaceri. În special, configurați următoarele și verificați funcționarea:
ntp
LAC-uri
Autentificare utilizator și acces la distanță
DNS
dirijare IP
Adrese IP
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4. Adresa locală Gateway Nume domeniu complet calificat (FQDN) sau Înregistrare serviciu (SRV) trebuie să se rezolve la o adresă IPv4 publică pe internet.
Toate porturile SIP și media de pe interfața gateway locală cu care se confruntă Webex trebuie să fie accesibile de pe internet, fie direct, fie prin NAT static. Asigurați-vă că actualizați firewall-ul în mod corespunzător.
Instalați un certificat semnat pe gateway-ul local (următorul oferă pașii de configurare detaliați).
O autoritate publică de certificare (CA), așa cum este detaliată în Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platformele audio și video Cisco Webex? trebuie să semneze certificatul dispozitivului.
FQDN configurat în Control Hub atunci când se creează un trunchi trebuie să fie numele comun (CN) sau certificatul de nume alternativ al subiectului (SAN) al routerului. De exemplu:
Dacă un trunchi configurat în Control Hub al organizației dvs. are cube1.lgw.com:5061 ca FQDN al gateway-ului local, atunci CN sau SAN din certificatul router trebuie să conțină cube1.lgw.com.
Dacă un trunchi configurat în Control Hub al organizației dvs. are lgws.lgw.com ca adresa SRV a gateway-ului (gateway-urilor) local care poate fi accesată din trunchi, atunci CN sau SAN din certificatul router trebuie să conțină lgws.lgw.com. Înregistrările la care se rezolvă adresa SRV (CNAME, O Înregistrare sau o Adresă IP) sunt opționale în SAN.
Indiferent dacă utilizați un FQDN sau un SRV pentru trunchi, adresa de contact pentru toate dialogurile SIP noi din gateway-ul local utilizează numele configurat în Control Hub.
Asigurați-vă că certificatele sunt semnate pentru utilizarea clientului și a serverului.
Încărcați pachetul CA rădăcină Cisco la gateway-ul local.
Configurare
1 | Asigurați-vă că atribuiți adrese IP valide și rutabile oricăror interfețe din stratul 3, de exemplu:
|
2 | Protejați acreditările STUN pe router utilizând criptarea simetrică. Configurați cheia de criptare primară și tipul de criptare după cum urmează:
|
3 | Creați un punct de încredere pentru criptare cu un certificat semnat de autoritatea de certificare preferată (CA). |
4 | Autentificați-vă noul certificat utilizând certificatul CA intermediar (sau rădăcină), apoi importați certificatul (Pasul 4). Introduceți următoarea comandă de exec sau configurare:
|
5 | Importați un certificat de gazdă semnat utilizând următoarea comandă exec sau de configurare:
|
6 | Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare:
|
7 | Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați crypto pki trustpool import URL curat comandă pentru a descărca pachetul CA rădăcină din URL-ul specificat și pentru a șterge trustpool-ul CA actual, apoi instalați noul pachet de certificate: Dacă trebuie să utilizați un proxy pentru a accesa internetul utilizând HTTPS, adăugați următoarea configurație înainte de a importa pachetul CA: IP http client proxy-server yourproxy.com port proxy 80
|
1 | Creați un trunchi PSTN bazat pe certificat CUBE pentru o locație existentă în Control Hub. Pentru mai multe informații, consultați Configurați trunchiurile, grupurile de rutare și planurile de apelare pentru Webex Calling. Notaţi informaţiile trunchiului care sunt furnizate odată ce trunchiul este creat. Aceste detalii, așa cum se evidențiază în ilustrația următoare, vor fi utilizate în etapele de configurare din acest ghid. |
2 | Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling:
Iată o explicație a câmpurilor pentru configurare:
Activați funcțiile elementului de frontieră Cisco Unified (CUBE) de pe platformă. permite conexiuni sip la sipActivați CUBE SIP de bază înapoi la funcționalitatea de agent de utilizator înapoi. Pentru mai multe informații, consultați Permite conexiuni. În mod implicit, transportul prin fax T.38 este activat. Pentru mai multe informații, consultați protocolul de fax t38 (serviciu vocal). Permite STUN (Sesiune Traversală a UDP prin NAT) la nivel global. Aceste comenzi de stun globale sunt necesare numai atunci când implementați gateway-ul local din spatele NAT.
Pentru mai multe informații, consultați stun flowdata agent-id și stun flowdata partajate-secret. sarcină utilă asimetrică completăConfigurează suportul de sarcină utilă asimetric SIP atât pentru DTMF, cât și pentru sarcinile de plată codec dinamice. Pentru mai multe informații despre această comandă, consultați sarcina utilă asimetrică. ofertă timpurie forțatăForțează Gateway-ul Local să trimită informații SDP în mesajul INVITE inițial în loc să aștepte recunoașterea de la partenerul vecin. Pentru mai multe informații despre această comandă, consultați oferta timpurie. intrare profiluri sipPermite CUBE să utilizeze profiluri SIP pentru a modifica mesajele pe măsură ce acestea sunt primite. Profilurile sunt aplicate prin intermediul asociaților de apelare sau al chiriașilor. |
3 | Configurare codec clasă vocală 100 filtru codec pentru trunchi. În acest exemplu, același filtru codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis.
Iată o explicație a câmpurilor pentru configurare: codec clasă vocală 100Utilizat pentru a permite numai codec-uri preferate pentru apeluri prin trunchiuri SIP. Pentru mai multe informații, consultați codecul clasei de voce. Codec-ul Opus este acceptat numai pentru trunchiurile PSTN bazate pe SIP. Dacă trunchiul PSTN utilizează o conexiune vocală T1/E1 sau analogică FXO, excludeți preferință codec 1 opusul din partea codec clasă vocală 100 configurare . |
4 | Configurare utilizare sunet de clasă vocală 100 pentru a activa ICE pe trunchiul Webex Calling. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: lită de gheață de utilizare stunUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare cu care se confruntă Webex Calling pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați clasa vocală utilizare stun și lite gheață utilizare stun. date flux paravan de utilizare transversală comanda este necesară numai la implementarea gateway-ului local din spatele NAT. Aveți nevoie de utilizarea ICE-lite pentru fluxurile de apeluri prin optimizarea căii media. Pentru a oferi optimizarea media pentru un gateway SIP la TDM, configurați un dial-peer loopback cu ICE-Lite activat pe piciorul IP-IP. Pentru mai multe detalii tehnice, contactați echipele din Cont sau TAC. |
5 | Configurați politica de criptare media pentru traficul Webex. (Acest pas nu se aplică pentru Webex for Government)
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte SRTP cipher-suite CUBE din SDP în mesaje de ofertă și răspuns. Webex Calling acceptă numai SHA1_80. Pentru mai multe informații, consultați clasa vocală srtp-crypto. |
6 | Configurați cifrele GCM conforme cu FIPS (Acest pas se aplică numai pentru Webex for Government).
Iată o explicație a câmpurilor pentru configurare: clasă vocală srtp-crypto 100Specifică GCM ca suita cipher pe care CUBE o oferă. Este obligatorie configurarea criptelor GCM pentru gateway-ul local pentru Webex for Government. |
7 | Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza destinației sale FQDN sau SRV:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 100 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați FQDN sau SRV LGW configurat în Control Hub în timp ce creați un trunchi. |
8 | Configurați profilurile de manipulare a mesajelor SIP. Dacă gateway-ul dvs. este configurat cu o adresă IP publică, configurați un profil după cum urmează sau treceți la pasul următor dacă utilizați NAT. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local și „198.51.100.1” este adresa IP publică a interfeței gateway-ului local care se confruntă cu Webex Calling:
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive. Treceți la pasul următor dacă ați configurat gateway-ul local cu adrese IP publice. |
9 | Dacă gateway-ul dvs. este configurat cu o adresă IP privată în spatele NAT statică, configurați profilurile SIP de intrare și de ieșire după cum urmează. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local, „10.80.13.12” este adresa IP de interfață cu care se confruntă Webex Calling și „192.65.79.20” este adresa IP publică NAT. Profiluri SIP pentru mesajele de ieșire în Webex Calling
Iată o explicație a câmpurilor pentru configurare: Normele 10 și 20Pentru a permite Webex să autentifice mesajele din gateway-ul local, antetul „Contact” din cererea SIP și mesajele de răspuns trebuie să conțină valoarea setată pentru trunchi în Control Hub. Aceasta va fi fie FQDN-ul unei singure gazde, fie numele domeniului SRV utilizat pentru un cluster de dispozitive. normele 30-81Convertiți referințele adresei private la adresa publică externă a site-ului, permițând Webex să interpreteze corect și să dirijeze mesajele ulterioare. Profil SIP pentru mesajele de intrare din Webex Calling
Iată o explicație a câmpurilor pentru configurare: normele 10-80Convertiți referințele adresei publice la adresa privată configurată, permițând procesarea corectă a mesajelor din Webex de către CUBE. Pentru mai multe informații, consultați profilurile sip de clasă vocală. |
10 | Configurați un SIP Opțiuni în viață cu profilul de modificare a antetului.
Iată o explicație a câmpurilor pentru configurare: clasă vocală sip-opțiuni-keepalive 100Configurează un profil keepalive și intră în modul de configurare a clasei vocale. Puteți configura timpul (în secunde) la care un Ping SIP Out of Dialog Options este trimis către ținta de apelare atunci când conexiunea bătăilor inimii la punctul final este în stare în sus sau în jos. Acest profil Keepalive este declanșat din dial-peer-ul configurat către Webex. Pentru a vă asigura că antetele de contact includ numele de domeniu complet calificat SBC, se utilizează profilul SIP 115. Regulile 30, 40 și 50 sunt necesare numai atunci când SBC este configurat în spatele NAT statice. În acest exemplu, cube1.lgw.com este FQDN selectat pentru gateway-ul local și dacă se utilizează NAT static, „10.80.13.12” este adresa IP a interfeței SBC către Webex Calling și „192.65.79.20” este adresa IP publică NAT. |
11 | Configurați trunchiul Webex Calling: |
După ce ați construit un trunchi către Webex Calling de mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă Furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară detaliată mai sus pentru trunchiul Webex Calling. Rutarea sigură a apelurilor este acceptată de CUBE.
Dacă utilizați un trunchi TDM / ISDN PSTN, treceți la secțiunea următoare Configurați gateway-ul local cu trunchiul TDM PSTN.
Pentru a configura interfețe TDM pentru segmente de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI.
1 | Configurați următoarea clasă de voce uri pentru a identifica apelurile de intrare din trunchiul PSTN:
Iată o explicație a câmpurilor pentru configurare: clasă vocală uri 200 sipDefinește un model pentru a se potrivi unei invitații SIP de intrare la un peer de apelare trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului PSTN IP. Pentru mai multe informații, consultați clasa vocală uri. |
2 | Configurați următoarea linie de apelare IP PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește o pereche de apelare VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). sipv2 protocol de sesiuneSpecifică faptul că dial-peer 200 gestionează segmente de apel SIP. Pentru mai multe informații, consultați protocolul sesiunii (dial peer). țintă sesiune ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite piesa de apel. Ținta sesiunii aici este adresa IP a ITSP. Pentru mai multe informații, consultați ținta sesiunii (peer apelare VoIP). intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN. Se potrivește tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați url-ul de intrare. Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurați interfața sursă și adresa IP asociată pentru mass-media trimisă în PSTN. Pentru mai multe informații, consultați legătura. codec de clasă vocală 100Configurați dial-peer-ul pentru a utiliza lista de filtrare codec comună 100. Pentru mai multe informații, consultați codec-ul de clasă vocală. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca capacitate DTMF așteptată pe partea de apelare. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 | Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de rutare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
După ce ați construit un trunchi către Webex Calling, utilizați următoarea configurație pentru a crea un trunchi TDM pentru serviciul dvs. PSTN cu rutare de apelare cu buclă inversă pentru a permite optimizarea media pe partea de apelare Webex.
1 | Configurația dial-peer buclă-spate utilizează grupuri dial-peer și etichete de rutare a apelurilor pentru a se asigura că apelurile trec corect între Webex și PSTN, fără a crea bucle de rutare a apelurilor. Configurați următoarele reguli de traducere care vor fi utilizate pentru a adăuga și elimina etichetele de rutare a apelurilor:
Iată o explicație a câmpurilor pentru configurare: regulă de traducere vocalăUtilizează expresii regulate definite în reguli pentru a adăuga sau elimina etichete de rutare a apelurilor. Cifrele de peste zece ani („A”) sunt utilizate pentru a adăuga claritate pentru depanare. În această configurație, eticheta adăugată prin profilul de traducere 100 este utilizată pentru a ghida apelurile de la Webex Calling către PSTN prin intermediul perechilor de apelare loopback. În mod similar, eticheta adăugată prin profilul de traducere 200 este utilizată pentru a ghida apelurile din PSTN către Webex Calling. Profilurile de traducere 11 și 12 elimină aceste etichete înainte de a efectua apeluri către trunchiurile Webex și, respectiv, PSTN. Acest exemplu presupune că numerele apelate din Webex Calling sunt prezentate în format +E.164. Articolul 100 elimină conducerea + pentru a menține un număr de apelare valid. Articolul 12 adaugă apoi o cifră (cifre) de rutare națională sau internațională la eliminarea etichetei. Utilizați cifre care se potrivesc cu planul de apelare național ISDN local. Dacă Webex Calling prezintă numere în format național, ajustați regulile 100 și 12 pentru a adăuga și a elimina pur și simplu eticheta de rutare. Pentru mai multe informații, consultați profilul de traducere vocală și regula de traducere vocală. |
2 | Configurați porturile interfeței vocale TDM conform cerințelor tipului de trunchi și protocolului utilizat. Pentru mai multe informații, consultați Configurarea ISDN PRI. De exemplu, configurația de bază a unei interfețe ISDN cu Rata primară instalată în slotul NIM 2 al unui dispozitiv poate include următoarele:
|
3 | Configurați următorul dial-peer TDM PSTN:
Iată o explicație a câmpurilor pentru configurare:
Definește o pereche de apelare VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). profil de traducere 200Atribuiți profilul de traducere care va adăuga o etichetă de rutare a apelurilor la numărul apelat de intrare. apelare directă spre interiorRutează apelul fără a furniza un ton de apel secundar. Pentru mai multe informații, consultați apelare directă. port 0/2/0:15Portul vocal fizic asociat cu acest dial-peer. |
4 | Pentru a permite optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, puteți modifica rutarea apelurilor introducând un set de colegi de apelare interni cu buclă inversă între trunchiurile Webex Calling și PSTN. Configurați următoarele perechi de apelare buclă-spate. În acest caz, toate apelurile primite vor fi dirijate inițial către dial-peer 10 și de acolo către dial-peer 11 sau 12, pe baza etichetei de rutare aplicate. După îndepărtarea etichetei de rutare, apelurile vor fi direcționate către trunchiul de ieșire utilizând grupuri de apelare-pereche.
Iată o explicație a câmpurilor pentru configurare:
Definește o linie de apelare VoIP și oferă o descriere semnificativă pentru ușurința de gestionare și depanare. Pentru mai multe informații, consultați vocea dial-peer. profil de traducere care sosește 11Se aplică profilul de traducere definit anterior pentru a elimina eticheta de rutare a apelurilor înainte de a trece la trunchiul de ieșire. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup de apelare de intrare. Pentru mai multe informații, consultați modelul de destinație (interfață). sipv2 protocol de sesiuneSpecifică faptul că acest dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul sesiunii (dial peer). țintă sesiune 192.168.80.14Specifică adresa locală a interfeței routerului ca țintă a apelului pentru buclă de rezervă. Pentru mai multe informații, consultați ținta sesiunii (voip dial peer). Bandă de control interfață sursă GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise prin buclă de rezervă. Pentru mai multe informații, consultați legătura. leagă interfața sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mass-media trimisă prin buclă de rezervă. Pentru mai multe informații, consultați legătura. dtmf-relay rtp-nteDefinește RTP-NTE (RFC2833) ca capacitate DTMF așteptată pe partea de apelare. Pentru mai multe informații, consultați DTMF Relay (Voice over IP). codec g711alaw Forțează toate apelurile PSTN să utilizeze G.711. Selectați a-law sau u-law pentru a se potrivi cu metoda de constrângere utilizată de serviciul ISDN. nu vădDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
5 | Adăugați următoarea configurație de rutare a apelurilor: Acest lucru încheie configurația gateway-ului local. Salvați configurația și reîncărcați platforma dacă aceasta este prima dată când sunt configurate caracteristicile CUBE.
|
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt dirijate prin Unified CM. Apelurile din UCM din portul 5060 sunt direcționate către PSTN și apelurile din portul 5065 sunt direcționate către Webex Calling. Următoarele configurații incrementale pot fi adăugate pentru a include acest scenariu de apelare.
1 | Configurați următoarele URI de clasă vocală: |
2 | Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM: IOS XE utilizează aceste înregistrări pentru determinarea locală a gazdelor și porturilor țintă UCM. Cu această configurație, nu este necesar să configurați înregistrări în sistemul DNS. Dacă preferați să utilizați DNS-ul, atunci aceste configurații locale nu sunt necesare.
Iată o explicație a câmpurilor pentru configurare: Următoarea comandă creează o înregistrare de resurse DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Greutatea record a resursei SRV 5060: Numărul portului pe care trebuie să-l utilizați pentru gazda țintă în această înregistrare de resurse ucmsub5.mydomain.com: Gazda țintă înregistrare resursă Pentru a rezolva numele de gazdă țintă a înregistrării resurselor, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 gazdă IP: Creează o înregistrare în baza de date IOS XE locală. ucmsub5.mydomain.com: Numele de gazdă A înregistrării. 192.168.80.65: Adresa IP a gazdei. Creați evidențele resurselor SRV și A pentru a reflecta mediul UCM și strategia preferată de distribuție a apelurilor. |
3 | Configurați următorii colegi de apelare: |
4 | Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează în mod proactiv problemele observate frecvent în gateway-ul local bazat pe Cisco IOS XE și generează notificarea prin e-mail, jurnal de sistem sau mesaj terminal a evenimentului. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și transferul datelor colectate în cazul Cisco TAC pentru a accelera timpul de rezoluție.
Semnături de diagnosticare (DS) sunt fișiere XML care conțin informații despre declanșarea problemelor evenimente și acțiuni pentru a informa, depanare și remedia problema. Utilizați mesaje syslog, evenimente SNMP și prin monitorizarea periodică a ieșirilor specifice ale comenzii de afișare pentru a defini logica de detectare a problemei. Tipurile de acțiuni includ:
Colectarea ieșirilor de comandă ale afișării
Generarea unui fișier jurnal consolidat
Încărcarea fișierului către o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP
Inginerii TAC autentifică fișierele DS și o semnează digital pentru protecția integrității. Fiecare fișier DS are ID-ul numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o singură sursă pentru a găsi semnăturile aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
Nu editați fișierul DS pe care îl descărcați de pe DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
Asigurați-vă că gateway-ul local rulează IOS XE 17.6.1 sau mai mare dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway-ul local care rulează IOS XE 17.6.1 sau mai mare
Semnăturile de diagnosticare sunt activate în mod implicit.
Configurați serverul de e-mail securizat pe care îl utilizați pentru a trimite o notificare proactivă dacă dispozitivul rulează IOS XE 17.6.1 sau mai mare.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurați variabila de mediu ds_email cu adresa de e-mail a administratorului pentru a vă notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Instalați semnăturile de diagnosticare pentru monitorizarea proactivă
Monitorizarea utilizării CPU ridicate
Acest DS urmărește 5 secunde de utilizare a CPU folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea atinge 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare pe care le instalați în gateway-ul local. Utilizați acești pași de mai jos pentru a instala semnătura.
Asigurați-vă că ați activat SNMP utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 64224 utilizând următoarele opțiuni derulante din Instrumentul de căutare a semnăturilor de diagnosticare:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge Catalyst 8000V
Produs
CUBE Enterprise în soluție Webex Calling
Domeniu de aplicare al problemei
Performanță
Tip problemă
Utilizare CPU ridicată cu notificare prin e-mail
Copiați fișierul XML DS în Flash-ul gateway local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de la un server FTP la gateway-ul local.
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)
Instalați fișierul XML DS în gateway-ul local.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
Utilizați afișarea semnăturii de diagnosticare la domiciliu comandă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare „înregistrată”.
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
Descărcați DSes:
d.
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate SD-urile care rulează, inclusiv pe cont propriu. Dacă este necesar, vă rugăm să reinstalați DS 64224 pentru a continua monitorizarea utilizării CPU ridicat pe gateway-ul local.
Se deconectează funcția de monitorizare a apelului anormal
Acest DS utilizează sondajul SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor cu erori SIP 403, 488 și 503. Dacă creșterea numărului de erori este mai mare sau egală cu 5 din ultimul sondaj, aceasta generează o notificare syslog și e-mail. Utilizați pașii de mai jos pentru a instala semnătura.
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
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
Descărcați DS 65221 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge Catalyst 8000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Performanță
Tip problemă
Detectarea anormală a deconectării apelurilor SIP cu notificarea prin e-mail și Syslog.
Copiați fișierul XML DS la gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
Instalați fișierul XML DS în gateway-ul local.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
Utilizați comanda afișarea semnăturii de diagnosticare la domiciliu pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare „înregistrată”.
Instalați semnăturile de diagnosticare pentru a depana o problemă
De asemenea, puteți utiliza Semnături de Diagnostic (DS) pentru a rezolva rapid problemele. Inginerii Cisco TAC au autentificat mai multe semnături care permit depanările necesare care sunt necesare pentru a rezolva o anumită problemă, pentru a detecta apariția problemei, pentru a colecta setul corect de date de diagnosticare și pentru a transfera automat datele în cazul Cisco TAC. Acest lucru elimină necesitatea de a verifica manual apariția problemei și facilitează mult soluționarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și pentru a le instala pentru a rezolva o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția „%VOICE_IEC-3-GW: Cefalee: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și colectarea automată a datelor de diagnosticare utilizând următorii pași:
Configurați o altă variabilă de mediu DS ds_fsurl_prefix ca cale de server de fișiere Cisco TAC (cxd.cisco.com) pentru a încărca datele de diagnosticare. Numele de utilizator din calea fișierului este numărul de caz, iar parola este tokenul de încărcare a fișierului care poate fi preluat de la Support Case Manager , după cum se arată în cele ce urmează. Tokenul de încărcare a fișierului poate fi generat în secțiunea Atașamente a managerului de caz al asistenței, după cum este necesar.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Exemplu:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp. Dacă SNMP nu este activat, configurați manager server snmp comandă .
show snmp %SNMP agent not enabled config t snmp-server manager end
Vă recomandăm instalarea monitorizării CPU ridicat DS 64224 ca o măsură proactivă pentru a dezactiva toate depanările și semnăturile de diagnosticare în timpul utilizării CPU ridicat. Descărcați DS 64224 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge Catalyst 8000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Performanță
Tip problemă
Utilizare CPU ridicată cu notificare prin e-mail.
Descărcați DS 65095 utilizând următoarele opțiuni din Instrumentul de căutare a semnăturilor de diagnosticare:
Nume câmp
Valoare câmp
Platformă
Cisco 4300, seria ISR 4400 sau software-ul Edge Catalyst 8000V
Produs
CUBE Enterprise în Webex Calling Solution
Domeniu de aplicare al problemei
Jurnale de sistem
Tip problemă
Syslog - %VOICE_IEC-3-GW: Cefalee: Eroare internă (prag al indicatorului de apel): iec=1. 1. 181. 1. 29. 0
Copiați fișierele XML DS la gateway-ul local.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Instalați fișierul XML de monitorizare DS 64224 și apoi DS 65095 în gateway-ul local.
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
Verificați dacă semnătura a fost instalată cu succes utilizând afișarea semnăturii de diagnosticare la domiciliu. Coloana de stare trebuie să aibă o valoare „înregistrată”.
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
Descărcat DSes:
d.
Nume DS
Revizuire
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscriși
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Înscriși
2020-11-08:00:12:53
Verificați executarea semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a comenzii afișarea semnăturii de diagnosticare la domiciliu modifică modul de „rulare” în timp ce gateway-ul local execută acțiunea definită în cadrul semnăturii. Emiterea afișarea statisticilor privind semnătura diagnosticului la domiciliu este cel mai bun mod de a verifica dacă o semnătură de diagnostic detectează un eveniment de interes și execută acțiunea. Coloana „Triggered/Max/Deinstall” indică numărul de ori pe care semnătura dată l-a declanșat un eveniment, numărul maxim de ori pe care este definit pentru a detecta un eveniment și dacă semnătura se instalează după detectarea numărului maxim de evenimente declanșate.
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
Descărcat DSes:
d. | Nume DS | Revizuire | Stare | Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0.0.10 |
Înscriși |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișarea statisticilor semnăturii diagnostice la domiciliu
d. | Nume DS | Dezactivată/Max/Dezactivare | Timp mediu de rulare (secunde) | Timpul maxim de rulare (secunde) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/n |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/ŞI |
23.053 |
23.053 |
E-mailul de notificare trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația de funcționare și afișarea ieșirilor de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalați semnăturile de diagnosticare
Utilizați semnăturile de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor evenimente de probleme. Dacă doriți să dezinstalați manual o semnătură, recuperați ID-ul DS de la ieșirea din afișarea semnăturii de diagnosticare la domiciliu și executați următoarea comandă:
call-home diagnostic-signature deinstall <DS ID>
Exemplu:
call-home diagnostic-signature deinstall 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor care sunt observate în implementări. TAC nu acceptă în prezent solicitări pentru a crea noi semnături personalizate.
Implementați disponibilitatea ridicată CUBE ca gateway local
Fundamentale
Cerințe preliminare
Înainte de a implementa CUBE HA ca gateway local pentru Webex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
Layer 2 redundanță box-to-box cu CUBE Enterprise pentru păstrarea constantă a apelurilor
Orientările de configurare prevăzute în acest articol presupun o platformă locală de gateway dedicată, fără o configurație vocală existentă. Dacă o implementare CUBE existentă a întreprinderii este modificată pentru a utiliza și funcția gateway locală pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri existente și funcționalitățile nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită versiunea IOS-XE 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și funcțiile LGW.
Comenzile și jurnalele spectacolului din acest articol se bazează pe versiunea minimă de software a Cisco IOS-XE 16.12.2 implementată pe un vCUBE (CSR1000v).
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diferite platforme:
Seria ISR 4K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE) — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Arhitectură preferată Cisco pentru Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Prezentare generală Soluție Webex Calling
Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud multi-tenant la serviciul de telefonie PBX prestabilit, cu mai multe opțiuni PSTN pentru clienți.
Implementarea gateway-ului local (reprezentată mai jos) se află în centrul acestui articol. Trunchiul gateway-ului local (PSTN local) din Webex Calling permite conectivitatea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare IP PBX locală, cum ar fi Cisco Unified CM. Toate comunicațiile către și din cloud sunt securizate prin intermediul transportului TLS pentru SIP și SRTP pentru mass-media.
Figura de mai jos afișează o implementare Webex Calling fără niciun PBX IP existent și se aplică unei implementări unice sau multi-site. Configurația prezentată în acest articol se bazează pe această implementare.
Nivelul 2 Redundanță Box-to-Box
Redundanța CUBE HA strat 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) pe interfețele respective și face schimb continuu de mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate de-a lungul perechii de routere care permit routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE în cazul în care routerul activ iese din serviciu, ceea ce duce la păstrarea constantă a semnalului și a mass-mediei.
Verificarea punctajului este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt bifate (de exemplu, o stare de încercare sau de apel).
În acest articol, CUBE HA se va referi la CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundanță pentru păstrarea constantă a apelurilor
Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca un gateway local pentru implementările trunchiului Cisco Webex Calling (PSTN local) și vom acoperi considerațiile de proiectare și configurațiile din acest articol. Această cifră afișează o configurare tipică CUBE HA ca gateway local pentru o implementare trunchi Cisco Webex Calling.
Componentă Intra Grup de redundanță
Componenta Infra a Grupului de Redundanță (RG) oferă suport pentru infrastructura de comunicare box-to-box între cele două CUB-uri și negociază starea finală stabilă de redundanță. Această componentă oferă, de asemenea:
Un protocol de tip HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și salut între cele două CUBEs (prin interfața de control) - GigabitEthernet3 în figura de mai sus.
Un mecanism de transport pentru verificarea stării de semnalizare și media pentru fiecare apel de la router-ul activ la router-ul standby (prin interfața de date) - GigabitEthernet3 în figura de mai sus.
Configurarea și gestionarea interfeței Virtual IP (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie configurată special pentru a sprijini vocea B2B HA.
Gestionarea adreselor IP virtuale (VIP) atât pentru semnalizare, cât și pentru media
B2B HA se bazează pe VIP pentru a obține redundanță. Interfețele fizice VIP și asociate pe ambele CUBE din perechea CUBE HA trebuie să reziste pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație vocală (SIP) sunt obligatorii pentru asistența vocală B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling Access SBC, furnizorul de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care trec prin routerele CUBE HA. Prin urmare, din punct de vedere Webex Calling, perechile CUBE HA acționează ca un singur gateway local.
Semnalizarea apelurilor și informațiile despre sesiunea RTP ale apelurilor stabilite sunt verificate de la routerul activ la routerul standby. Când routerul Activ coboară, routerul Standby preia și continuă să redirecționeze fluxul RTP care a fost direcționat anterior de primul router.
Apelurile într-o stare tranzitorie în momentul nereușitei nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt pe deplin stabilite încă sau sunt în curs de modificare cu o funcție de transfer sau de menținere. Apelurile configurate pot fi deconectate după comutare.
Următoarele cerințe există pentru utilizarea CUBE HA ca gateway local pentru defalcarea statică a apelurilor:
CUBE HA nu poate avea interfețe TDM sau analogice co-localizate
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP/RTP) și Gig3 este Redundancy Group (RG) Control/interfață de date
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu strat 2, unul cu id de grup 1 și celălalt cu id de grup 2. Dacă configurați 2 perechi HA cu același id de grup, interfețele RG Control/Date trebuie să aparțină diferitelor domenii din stratul 2 (vlan, comutator separat)
Canalul portuar este acceptat atât pentru controlul RG/date, cât și pentru interfețele de trafic
Toate semnalele/mass-media sunt obținute de la/la adresa IP virtuală
Oricând o platformă este reîncărcată într-o relație CUBE-HA, ea începe întotdeauna ca Standby
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
Identificatorul interfeței de redundanță, rii trebuie să fie unic pentru o combinație pereche/interfață în același strat 2
Configurația pe ambele CUBEs trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
Interfețele Loopback nu pot fi utilizate ca legături, deoarece acestea sunt întotdeauna în sus
Interfețele de trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea monitorizării interfeței
CUBE-HA nu este acceptată printr-o conexiune prin cablu încrucișată pentru link-ul RG-control/date (Gig3)
Ambele platforme trebuie să fie identice și să fie conectate printr-o Comutator fizic pe toate interfețele pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
Nu se poate termina WAN pe CUBEs direct sau Data HA pe nici o parte
Ambele active/standby trebuie să fie în același centru de date
Este obligatoriu să se utilizeze o interfață L3 separată pentru redundanță (RG Control/date, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru keepalives HA și puncte de control
După eșec, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media
Configurați redundanța pe Ambele CUBE-uri
Trebuie să configurați redundanța de la 2 la 2 pe ambele CUBEs destinate utilizării într-o pereche HA pentru a aduce IPs virtuale.
1 | Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât traseul activ va juca destul de rolul său activ după ce interfața de trafic este în jos. | ||
2 | Configurați un RG pentru utilizare cu VoIP HA în submodul de redundanță al aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
3 | Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG din pasul anterior de mai jos
redundanță-grup 1—Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să intre în vigoare. Vom reîncărca platformele după ce toate configurațiile au fost aplicate. | ||
4 | Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, după cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
5 | Salvați configurația primului CUBE și reîncărcați-l. Platforma pentru a reîncărca ultima este întotdeauna standby.
După ce VCUBE-1 cizme complet, salvați configurația VCUBE-2 și reîncărcați-l.
| ||
6 | Verificați dacă configurația cutie-la-cutie funcționează conform așteptărilor. Ieșirea relevantă este evidențiată în îndrăzneală. Am reîncărcat ultimul VCUBE-2 și conform considerațiilor de proiectare; platforma de reîncărcare va fi întotdeauna în așteptare.
|
Configurați un gateway local pe Ambele CUBE-uri
În configurația exemplului nostru, folosim următoarele informații despre trunchiuri din Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt următoarele:
Nume utilizator: Hussain1076_LGU
Parolă: lOV12MEaZx
1 | Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditările sau secretele partajate. Parolele de tip 6 sunt criptate folosind AES cipher și această cheie de configurare definită de utilizator.
Iată configurația gateway-ului local care se va aplica ambelor platforme pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. Datele de autentificare SIP Digest din Control Hub sunt evidențiate în mod îndrăzneț.
Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând VCUBE-1 standby-ul CUBE și VCUBE-2 CUBE activ |
2 | În orice moment dat, o singură platformă va menține o înregistrare activă ca gateway local cu accesul Webex Calling SBC. Aruncați o privire la ieșirea din următoarele comenzi spectacol. afișați grupul de aplicații de redundanță 1 afișați starea înregistrării sip-ua
Din ieșirea de mai sus, puteți vedea că VCUBE-2 este LGW-ul activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea „afișează starea de înregistrare sip-ua” este necompletată în VCUBE-1 |
3 | Acum activați următoarele depanări pe VCUBE-1
|
4 | Simulați eșecul prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.
Trecerea de la ACTIVE la STANDBY LGW are loc în scenariul următor, precum și în afara CLI enumerate mai sus
|
5 | Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling Access SBC. VCUBE-2 s-ar fi reîncărcat până acum.
VCUBE-1 este acum LGW-ul activ. |
6 | Uitați-vă la jurnalul de depanare relevant din VCUBE-1 care trimite un ÎNREGISTRATOR SIP către Webex Calling PRIN IP-ul virtual și primește un OK 200.
|
Configurați Unified CM pentru Webex Calling
Configurați profilul de securitate al trunchiurilor SIP pentru trunchiuri la gateway-ul local
În cazurile în care gateway-ul local și gateway-ul PSTN se află pe același dispozitiv, Unified CM trebuie să fie activat pentru a diferenția între două tipuri diferite de trafic (apeluri de la Webex și de la PSTN) care provin de la același dispozitiv și aplică o clasă de servicii diferențiată pentru aceste tipuri de apeluri. Acest tratament diferențiat al apelurilor se realizează prin asigurarea a două trunchiuri între Unified CM și gateway-ul local combinat și gateway-ul PSTN, care necesită diferite porturi SIP de ascultare pentru cele două trunchiuri.
Creați un profil de securitate dedicat trunchiului SIP pentru trunchiul gateway local cu următoarele setări:
|
Configurați profilul SIP pentru trunchiul gateway local
Creați un profil SIP dedicat trunchiului gateway local cu următoarele setări:
|
Creați un spațiu de căutare pentru apeluri din Webex
Creați un spațiu de căutare pentru apeluri care provin din Webex cu următoarele setări:
Ultima partiție onNetRemote este utilizată numai într-un mediu multi-cluster în care informațiile de rutare sunt schimbate între clusterele Unified CM utilizând Intercluster Lookup Service (ILS) sau Global Dialplan Replication (GDPR). |
Configurați un trunchi SIP la și de la Webex
Creați un trunchi SIP pentru apelurile către și de la Webex prin gateway-ul local cu următoarele setări:
|
Configurați grupul de rutare pentru Webex
Creați un grup de rute cu următoarele setări:
|
Configurați lista de rutare pentru Webex
Creați o listă de rute cu următoarele setări:
|
Creați o partiție pentru Webex Destinations
Creați o partiție pentru destinațiile Webex cu următoarele setări:
|
Ce este de făcut în continuare
Asigurați-vă că adăugați această partiție în toate spațiile de căutare prin apelare care ar trebui să aibă acces la destinațiile Webex. Trebuie să adăugați această partiție în mod specific în spațiul de căutare pentru apelare utilizat ca spațiu de căutare pentru apelare de intrare pe trunchiurile PSTN, astfel încât apelurile din PSTN către Webex să poată fi direcționate.
Configurați modelele de rută pentru destinațiile Webex
Configurați modelele de rute pentru fiecare interval DID pe Webex cu următoarele setări:
|
Configurați standardizarea abreviată a apelurilor intersite pentru Webex
Dacă apelarea inter-site abreviată este necesară pentru Webex, configurați modelele de normalizare a apelării pentru fiecare interval ESN din Webex cu următoarele setări:
|
Configurați funcțiile dvs. Webex Calling
Configurați un grup de hunt
Grupurile de hunt rutează apelurile de intrare către un grup de utilizatori sau spații de lucru. Puteți chiar să configurați un model pentru a direcționa către un întreg grup.
Pentru mai multe informații despre modul de configurare a unui grup de hunt, consultați Grupurile de hunt din Cisco Webex Control Hub.
Creați o coadă de apeluri
Puteți configura o coadă de apeluri, astfel încât atunci când apelurile clienților nu pot fi răspunse, să li se ofere un răspuns automat, mesaje de confort și muzică în așteptare până când cineva le poate răspunde la apel.
Pentru mai multe informații despre modul de configurare și gestionare a unei cozi de apeluri, consultați Gestionarea cozilor de apeluri în Cisco Webex Control Hub.
Creați un client recepționer
Ajutați-vă să susțineți nevoile personalului de la biroul din față. Puteți configura utilizatorii ca participanți la telefon, astfel încât aceștia să poată selecta apelurile primite către anumite persoane din organizația dvs.
Pentru informații despre modul de configurare și vizualizare a clienților dvs. recepționeri, consultați Clienții recepționeri din Cisco Webex Control Hub.
Creați și gestionați participanți automați
Puteți adăuga salutări, puteți configura meniuri și puteți direcționa apelurile către un serviciu de răspuns, un grup de hunt, o căsuță de poștă vocală sau o persoană reală. Creați un program de 24 de ore sau oferiți opțiuni diferite atunci când afacerea dvs. este deschisă sau închisă.
Pentru informații despre modul de creare și gestionare a participanților automați, consultați Gestionați participanții automați în Cisco Webex Control Hub.
Configurați un grup de paginare
Paging-ul de grup permite unui utilizator să plaseze un apel sau o pagină de grup într-un singur mod până la 75 de utilizatori și spații de lucru vizate, apelând un număr sau o extensie atribuită unui anumit grup de paging.
Pentru informații despre modul de configurare și editare a grupurilor de difuzare, consultați Configurarea unui grup de difuzare în Cisco Webex Control Hub.
Configurați preluarea apelului
Îmbunătățiți munca în echipă și colaborarea prin crearea unui grup de preluare a apelurilor, astfel încât utilizatorii să poată răspunde reciproc la apeluri. Când adăugați utilizatori într-un grup de preluare a apelurilor și un membru al grupului este plecat sau ocupat, un alt membru își poate răspunde la apeluri.
Pentru informații despre modul de configurare a unui grup de preluare a apelurilor, consultați Preluarea apelurilor în Cisco Webex Control Hub.
Configurați parcul de apeluri
Parcarea apelurilor permite unui grup definit de utilizatori să parcheze apeluri împotriva altor membri disponibili ai unui grup de parcare a apelurilor. Apelurile parcate pot fi preluate de alți membri ai grupului pe telefonul lor.
Pentru mai multe informații despre modul de configurare a parcului de apeluri, consultați Call Park în Cisco Webex Control Hub.
Activați barge-in pentru utilizatori
1 | Din vizualizarea clientului în https://admin.webex.com, accesați . |
2 | Selectați un utilizator și faceți clic pe Apelare. |
3 | Accesați secțiunea Permisiuni între utilizatori , apoi selectați Barge. |
4 | Activați comutatorul pentru a permite altor utilizatori să se adauge la apelul în curs al acestui utilizator. |
5 | Verificați Redați un ton atunci când acest utilizator intră într-un apel dacă doriți să redați un ton altor persoane atunci când acest utilizator intră în apel. Tonul Redați un ton atunci când acest utilizator intră într-o setare de apeluri nu se aplică funcționalității de tip barge-in a supervizorului Experience Basic și Essentials. Chiar dacă activați această opțiune pentru un supraveghetor, sistemul nu redă tonul de notificare agentului atunci când un supraveghetor intră în apelul din coada de apeluri. Dacă doriți să redați un ton unui agent atunci când un supraveghetor intră în apel, îl puteți activa prin setările „Ton de notificare pentru agenți”. Pentru mai multe informații, consultați secțiunea Creare coadă din Webex Customer Experience Basic sau Webex Customer Experience Essentials. |
6 | Faceți clic pe Salvați. |
Activați confidențialitatea pentru un utilizator
1 | Conectați-vă la Control Hub și accesați . |
2 | Alegeți un utilizator și faceți clic pe Apelare. |
3 | Accesați zona Permisiuni între utilizatori și apoi alegeți Confidențialitate. |
4 | Alegeți setările corespunzătoare de confidențialitate ale operatorului automat pentru acest utilizator.
|
5 | Bifați caseta de selectare Activare confidențialitate . Apoi, puteți decide să blocați pe toată lumea, nealegând membri din lista derulantă. Alternativ, puteți alege utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei acestui utilizator. Dacă sunteți administrator de locație, în lista derulantă apar numai utilizatorii, spațiile de lucru și liniile virtuale referitoare la locațiile atribuite. Debifați caseta de selectare Activare confidențialitate pentru a permite tuturor să monitorizeze starea liniei. |
6 | Verificați Confidențialitatea impunerii pentru preluarea apelurilor direcționate și caseta de selectare pentru înscriere pentru a activa confidențialitatea pentru preluarea apelurilor direcționate și înscriere.
|
7 | Din Adăugați membru după nume, alegeți utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei telefonice și pot invoca preluarea apelurilor direcționate și intrarea în rețea. |
8 | Pentru a filtra membrii pe care îi selectați, utilizați filtrul după nume, număr sau câmp text. |
9 | Faceți clic pe Eliminare toate pentru a elimina toți membrii selectați. Pentru a elimina un membru individual, faceți clic pe Ștergere de lângă numele membrului. |
10 | Faceți clic pe Salvați. |
Configurați monitorizarea
Numărul maxim de linii monitorizate pentru un utilizator este de 50. Cu toate acestea, în timp ce configurați lista de monitorizare, luați în considerare numărul de mesaje care afectează lățimea de bandă dintre Webex Calling și rețeaua dvs. De asemenea, determinați liniile maxime monitorizate de numărul de butoane de linie de pe telefonul utilizatorului.
1 | Din vizualizarea clientului din https://admin.webex.com, accesați Management și apoi faceți clic pe Utilizatori. |
2 | Selectați utilizatorul pe care doriți să îl modificați și faceți clic pe Apelare. |
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Monitorizare. |
4 | Alegeți din următoarele:
Puteți include o linie virtuală în lista Adăugare linie monitorizată pentru monitorizarea utilizatorului. |
5 | Alegeți dacă doriți să notificați acest utilizator despre apelurile parcate, căutați persoana sau extensia de parcare a apelurilor care urmează să fie monitorizată, apoi faceți clic pe Salvare. Lista de linii monitorizate din Control Hub corespunde cu ordinea liniilor monitorizate care apar pe dispozitivul utilizatorului. Puteți reordona lista liniilor monitorizate în orice moment. Numele care apare pentru linia monitorizată este numele introdus în câmpurile Nume și prenume ID apelant pentru utilizator, spațiu de lucru și linie virtuală. |
Activați tonul de avertizare prin punte de apel pentru utilizatori
Înainte de a începe
1 | Conectați-vă la Control Hub și accesați . |
2 | Selectați un utilizator și faceți clic pe fila Apelare. |
3 | Accesați Permisiuni între utilizatori și faceți clic pe Call Bridging Warning Tone. |
4 | Activați funcția Call Bridging Warning Tone, apoi faceți clic pe Save. În mod implicit, această funcție este activată. Pentru mai multe informații despre conectarea la apel pe o linie MPP partajată, consultați liniile partajate de pe telefonul dvs. de birou pe mai multe platforme. Pentru mai multe informații despre conectarea apelurilor pe o linie partajată a aplicației Webex, consultați aspectul liniei partajate pentru WebexApp. |
Activați hotelurile pentru un utilizator
1 | Din vizualizarea clientului din https://admin.webex.com, accesați Management și selectați Utilizatori. |
2 | Selectați un utilizator și faceți clic pe fila Apelare. |
3 | Accesați secțiunea Permisiuni între utilizatori și selectați Hoteling și activați comutatorul. |
4 | Introduceți numele sau numărul gazdei hotelului în câmpul de căutare Hotel Location și alegeți gazda hotelului pe care doriți să o alocați utilizatorului. Se poate selecta doar o singură gazdă hotelieră. Dacă alegeți o altă gazdă hotelieră, prima este ștearsă. Dacă sunteți administrator de locație, puteți aloca numai gazda hotelului referitoare la locațiile alocate. |
5 | Pentru a limita timpul în care un utilizator poate fi asociat cu gazda hotelului, alegeți numărul de ore pe care utilizatorul le poate utiliza gazda hotelului din lista derulantă Limit Association Period . Utilizatorul se va deconecta automat după ora aleasă. În ecran este afișat un mesaj de eroare dacă perioada limită de asociere specificată pentru utilizator depășește perioada limită de asociere a gazdei alese pentru hotel. De exemplu, dacă gazda hotelului are o perioadă limită de asociere de 12 ore, iar perioada limită de asociere a utilizatorului este de 24 de ore, se afișează un mesaj de eroare. În astfel de cazuri, trebuie să extindeți perioada de asociere limită a gazdei hotelului dacă este nevoie de mai mult timp pentru utilizator. |
6 | Faceți clic pe Salvați. De asemenea, un utilizator poate căuta și localiza gazda de hotel pe care dorește să o utilizeze din Hubul utilizatorului. Pentru mai multe informații, consultați Accesați profilul de apelare de oriunde. |
Rapoarte privind tendințele de adoptare și utilizare pentru Webex Calling
Vizualizați rapoartele de apelare
Puteți utiliza pagina Statistici din Control Hub pentru a obține informații despre modul în care persoanele utilizează Webex Calling și aplicația Webex (implicare), precum și despre rapiditatea experienței lor media de apelare. Pentru a accesa analizele Webex Calling, conectați-vă la Control Hub, apoi accesați Analytics și selectați fila Apelare .
1 | Pentru rapoarte detaliate privind istoricul apelurilor, conectați-vă la Control Hub, apoi accesați . |
2 | Selectați istoricul detaliat al apelurilor. Pentru informații despre apelurile care utilizează instanța dedicată, consultați Analizele instanței dedicate. |
3 | Pentru a accesa date de calitate media, conectați-vă la Control Hub, apoi accesați Statistici și apoi selectați Apelare. Pentru mai multe informații, consultați Statistici pentru portofoliul dvs. de colaborare în cloud.
|
Rulați instrumentul CScan
CScan este un instrument de pregătire a rețelei conceput pentru a testa conexiunea la rețea la Webex Calling.
Pentru mai multe informații, consultați Utilizarea CScan pentru a testa calitatea rețelei Webex Calling. |
Pregătiți mediul dvs.
Condiţii generale
Înainte de a configura un gateway local pentru Webex Calling, asigurați-vă că:
-
Dețineți cunoștințe de bază despre principiile VoIP
-
Aveți cunoștințe de lucru de bază despre conceptele de voce Cisco IOS-XE și IOS-XE
-
Să înțelegeți de bază Protocolul de inițiere sesiuni (SIP)
-
Aveți o înțelegere de bază a Cisco Unified Communications Manager (Unified CM) dacă modelul de implementare include Unified CM
Consultați Ghidul de configurare Enterprise Cisco Unified Border Element (CUBE ) pentru detalii.
Cerințe hardware și software pentru Gateway-ul local
Asigurați-vă că implementarea are una sau mai multe dintre gateway-urile locale, cum ar fi:
-
Cisco CUBE pentru conectivitate bazată pe IP
-
Gateway Cisco IOS pentru conectivitate bazată pe TDM
Gateway-ul local vă ajută să migrați la Webex Calling în ritmul propriu. Gateway-ul local integrează implementarea locală existentă cu Webex Calling. De asemenea, puteți utiliza conexiunea PSTN existentă. Consultați Începeți cu gateway-ul local
Cerințe de licență pentru gateway-urile locale
Licențele de apelare CUBE trebuie să fie instalate pe gateway-ul local. Pentru mai multe informații, consultați Ghidulde configurare a elementelor de frontieră unificate Cisco.
Certificat și cerințe de securitate pentru Gateway-ul local
Apelarea Webex necesită semnalizare securizată și suport media. Gateway-ul local efectuează criptarea și trebuie stabilită o conexiune TLS de ieșire în cloud cu următorii pași:
-
LGW trebuie să fie actualizate cu ca root bundle de la Cisco PKI
-
Un set de acreditări SIP digest din pagina de configurare PortBagaj Control Hub sunt utilizate pentru a configura LGW (pașii fac parte din configurația care urmează)
-
Ca root bundle validează certificatul prezentat
-
Solicitat acreditări (SIP digest furnizate)
-
Cloud-ul identifică gateway-ul local care este înregistrat în siguranță
Cerințe de optimizare a firewall-ului, NAT Traversal și a căii media pentru Gateway-ul local
În majoritatea cazurilor, gateway-ul local și punctele finale se pot afla în rețeaua internă de clienți, utilizând adrese IP private cu NAT. Paravanul de protecție de întreprindere trebuie să permită traficul de ieșire (SIP, RTP/UDP, HTTP) la anumite adrese IP/porturi, acoperite în Informații de referință port.
Dacă doriți să utilizați Optimizarea căilor media cu ICE, interfața orientată Webex Calling a gateway-ului local trebuie să aibă o cale directă de rețea către și de la punctele finale webex Calling. Dacă punctele finale se află într-o locație diferită și nu există o cale de rețea directă între punctele finale și interfața webex calling a gateway-ului local, atunci gateway-ul local trebuie să aibă o adresă IP publică atribuită interfeței cu care se confruntă Apelarea Webex pentru apeluri între gateway-ul local și punctele finale pentru a utiliza optimizarea căii media. În plus, trebuie să ruleze IOS-XE versiunea 16.12.5.
Configurați Webex Calling pentru organizația dvs.
Primul pas pentru a vă pune în funcțiune serviciile de apelare Webex este să finalizați Expertul de configurare pentru prima dată (FTSW). Odată ce FTSW este finalizat pentru prima locație, nu trebuie să fie finalizat pentru locații suplimentare.
1 |
Faceți clic pe linkul Introducere din e-mailul de bun venit pe care îl primiți. Adresa de e-mail a administratorului este utilizată automat pentru a vă conecta la Control Hub, unde vi se va solicita să creați parola de administrator. După ce vă conectați, expertul de configurare pornește automat. |
2 |
Revizuiți și acceptați termenii serviciului. |
3 |
Revizuiți-vă planul, apoi faceți clic pe Introducere. Managerul de cont este responsabil pentru activarea primilor pași pentru FTSW. Contactați managerul de cont dacă primiți o notificare "Imposibil de configurat apelul", atunci când selectați Începeți. |
4 |
Selectați țara în care ar trebui să se mapeze centrul de date și introduceți informațiile despre persoana de contact a clientului și adresa clientului. |
5 |
Faceți clic pe Următorul: Locație implicită. |
6 |
Alegeți dintre următoarele opțiuni:
După ce terminați expertul de configurare, asigurați-vă că adăugați un număr principal la locația pe care o creați. |
7 |
Efectuați următoarele selecții pentru a vă aplica la această locație:
|
8 |
Faceți clic pe Următorul. |
9 |
Introduceți o adresă CISCO Webex SIP disponibilă și faceți clic pe Următorul și selectați Terminare . |
Înainte de a începe
Pentru a crea o locație nouă, pregătiți următoarele informații:
-
Adresa locației
-
Numerele de telefon dorite (opțional)
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . O nouă locație va fi găzduită în centrul regional de date care corespunde țării pe care ați selectat-o utilizând Asistentul pentru prima configurare. |
2 |
Configurați setările locației:
|
3 |
Faceți clic pe Salvare , apoi alegeți Da/ Nu pentru a adăuga numere la locație acum sau o versiune ulterioară. |
4 |
Dacă ați făcut clic pe Da, alegeți una dintre următoarele opțiuni:
Alegerea opțiunii PSTN este la fiecare nivel de locație (fiecare locație are o singură opțiune PSTN). Puteți să amestecați și să potriviți oricâte opțiuni doriți pentru implementare, dar fiecare locație va avea o singură opțiune. După ce ați selectat și furnizat o opțiune PSTN, o puteți modifica făcând clic pe Gestionare în locația proprietăți PSTN. Cu toate acestea, este posibil ca unele opțiuni, cum ar fi Cisco PSTN, să nu fie disponibile după ce a fost atribuită o altă opțiune. Deschideți un caz de asistență pentru îndrumare. |
5 |
Alegeți dacă doriți să activați numerele acum sau o versiune ulterioară. |
6 |
Dacă ați selectat PSTN neintegrat ccp sau local, introduceți numere de telefon ca valori separate prin virgulă, apoi faceți clic pe Validare. Numerele sunt adăugate pentru locația specifică. Intrările valide se mută în câmpul Numere validate, iar intrările nevalide rămân în câmpul Adăugare numere însoțite de un mesaj de eroare. În funcție de țara locației, numerele sunt formatate în funcție de cerințele locale de apelare. De exemplu, dacă este necesar un cod de țară, puteți introduce numere cu sau fără cod și codul este prependat. |
7 |
Faceți clic pe Salvați. |
Ce este de făcut în continuare
După ce creați o locație, puteți activa serviciile 911 de urgență pentru locația respectivă. Consultați Serviciul RedSky Emergency 911 pentru Webex Apelarea pentru mai multe informații.
Înainte de a începe
Obțineți o listă cu utilizatorii și spațiile de lucru asociate cu o locație: Accesați ștergeți acei utilizatori și spații de lucru înainte de a șterge locația.
și, din meniul vertical, selectați locația care trebuie ștearsă. Trebuie săRețineți că orice numere asociate cu această locație vor fi lansate înapoi la furnizorul pstn; nu veți mai deține aceste numere.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 |
Faceți clic |
3 |
Alegeți Ștergere locațieși confirmați că doriți să ștergeți locația respectivă. De obicei durează câteva minute pentru ca locația să fie ștearsă definitiv, dar ar putea dura până la o oră. Puteți verifica starea făcând clic pe lângă numele locației și selectând Stareștergere. |
Puteți modifica configurarea PSTN, numele, fusul orar și limba unei locații după ce este creată. Reține însă că noua limbă se aplică doar utilizatorilor și dispozitivelor noi. Utilizatorii și dispozitivele existente continuă să utilizeze vechea limbă.
Pentru locațiile existente, puteți activa serviciile de urgență 911. Consultați Serviciul RedSky Emergency 911 pentru Webex Apelarea pentru mai multe informații.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . Dacă vedeți un simbol Atenție lângă o locație, înseamnă că nu ați configurat încă un număr de telefon pentru locația respectivă. Nu puteți efectua sau primi apeluri până când nu configurați acel număr. |
2 |
(Opțional) Sub ConexiunePSTN, selectați PSTN conectat în cloud sau PSTN bazat pe sediu (gateway local), în funcție de cel pe care l-ați configurat deja. Faceți clic pe Gestionare pentru a modifica configurația respectivă, apoi confirmați riscurile asociate selectând Continuare. Apoi, alegeți una dintre următoarele opțiuni și faceți clic pe Salvare:
|
3 |
Pentru locație, selectați Numărul principal din lista derulantă pentru a permite utilizatorilor din locația respectivă să efectueze și să primească apeluri. Numărul principal poate fi atribuit operatorului automat, astfel încât apelanții externi să poată contacta utilizatorii Webex Calling din locația respectivă. Utilizatorii Webex Calling din acea locație pot utiliza, de asemenea, acest număr ca ID-ul de apelant extern atunci când efectuează apeluri. |
4 |
(Opțional) Sub Apelarede urgență, puteți selecta Identificator de locație de urgență pe care să îl atribuiți acestei locații. Această setare este opțională și se aplică numai țărilor care o solicită. În unele țări (Exemplu: Franța), există cerințe de reglementare pentru sistemele radio celulare pentru a stabili identitatea celulei atunci când efectuați un apel de urgență și este pus la dispoziția autorităților de urgență. Alte țări, cum ar fi S.U.A. și Canada, implementează determinarea locației folosind alte metode. Pentru mai multe informații, consultați Apelareade urgență îmbunătățită. Este posibil ca furnizorul de apeluri de urgență să aibă nevoie de informații despre rețeaua de acces și se realizează prin definirea unui nou antet de extensie SIP privat, P-Access-Network-Info. Antetul conține informații referitoare la rețeaua de acces. Atunci când setați identificatorul de locație de urgență pentru o locație, valoarea locației este trimisă furnizorului ca parte a mesajului SIP. Contactați furnizorul de apeluri de urgență pentru a vedea dacă aveți nevoie de această setare și utilizați valoarea furnizată de furnizorul de apeluri de urgență." |
5 |
Selectați Numărul de poștă vocală pe care utilizatorii îl pot apela pentru a-și verifica mesageria vocală pentru această locație. |
6 |
(Opțional) Faceți clic pe pictograma creion din partea de sus a paginii Locație pentru a modifica numele locației , limbaanunțului, limbade e-mail, fusul orarsau adresa , după cum este necesar, apoi faceți clic pe Salvare. Modificarea limbii de anunț intră în vigoare imediat pentru orice utilizatori și caracteristici noi adăugate la această locație. Dacă utilizatorii și/sau caracteristicile existente ar trebui, de asemenea, să li se modifice limba de anunțare, atunci când vi se solicită, selectați Modificare pentru utilizatorii și spațiile de lucru existente sau Modificare pentru caracteristicileexistente. Faceți clic pe Se aplică. Puteți vizualiza progresul pe pagina Activități . Nu mai puteți face modificări până când acest lucru nu este finalizat. Modificarea fusului orar pentru o locație nu actualizează fusurile orare ale caracteristicilor asociate locației. Pentru a edita fusurile orare pentru caracteristici precum operator automat, grup de vânătoare și coadă de apeluri, accesați zona Setări generale a caracteristicii specifice pentru care doriți să actualizați fusul orar și editați și salvați acolo. |
Aceste setări sunt pentru apelare internă și sunt, de asemenea, disponibile în expertul de configurare pentru prima dată. Pe măsură ce modificați planul de apelare, numerele de exemplu din actualizarea Control Hub pentru a afișa aceste modificări.
Puteți configura permisiunile de apelare la ieșire pentru o locație. Consultați acești pași pentru a configura permisiunile de apelare la ieșire.
1 |
Conectați-vă la Control Hub, accesați , apoi defilați la Apelare internă. |
2 |
Configurați următoarele preferințe opționale de apelare, după cum este necesar:
|
3 |
Specificați apelarea internă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea internă după cum este necesar: , selectați o locație din listă și faceți clic pe
|
4 |
Specificați apelarea externă pentru anumite locații. Accesați Apelare. Derulați la apelare, apoi schimbați apelarea externă după cum este necesar: , selectați o locație din listă și faceți clic pe
Impactul asupra utilizatorilor:
|
Dacă sunteți reseller cu valoare adăugată, puteți utiliza acești pași pentru a porni configurarea gateway-ului local în Control Hub. Atunci când acest gateway este înregistrat în cloud, îl puteți utiliza în una sau mai multe dintre locațiile webex Calling pentru a furniza rutare către un furnizor de servicii PSTN de întreprindere.
O locație care are un gateway local nu poate fi ștearsă atunci când gateway-ul local este utilizat pentru alte locații.
Înainte de a începe
-
Odată ce o locație este adăugată și înainte de a configura PSTN bazat pe premise pentru o locație, trebuie să creați un trunchi.
-
Creați orice locații și setări și numere specifice pentru fiecare dintre ele. Locațiile trebuie să existe înainte de a putea adăuga un PSTN bazat pe premise.
-
Înțelegeți cerințele PSTN (gateway local) bazate pe premise pentru apelareaWebex.
-
Nu puteți alege mai mult de un portbagaj pentru o locație cu PSTN bazat pe premise, dar puteți alege același portbagaj pentru mai multe locații.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați , și selectați Adăugare trunchiuri. |
2 |
Selectați o locație. |
3 |
Denumiți trunchiul și faceți clic pe Salvare. Numele nu poate fi mai mare de 24 de caractere. |
Ce trebuie să faceți în continuare
Informațiile despre trunchi apar pe ecranul Registru domeniu, Trunk Group OTG/DTG, Linie/Portși Adresăproxy de ieșire.
Vă recomandăm să copiați aceste informații din Control Hub și să le lipiți într-un fișier text local sau într-un document local, astfel încât să puteți face referire la acestea atunci când sunteți gata să configurați PSTN bazat pe premise.
Dacă pierdeți acreditările, trebuie să le generați din ecranul de informații portbagaj în Control Hub. Faceți clic pe Regăsire nume de utilizator și reinițializare parolă pentru a genera un nou set de acreditări de autentificare de utilizat pe trunchi.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, accesați . |
2 |
Selectați o locație de modificat și faceți clic pe Gestionare. |
3 |
Selectați PSTN bazat pe premise și faceți clic pe Următorul. |
4 |
Alegeți un trunchi din meniul vertical. Vizitați pagina portbagajului pentru a gestiona opțiunile grupului de trunchiuri. |
5 |
Faceți clic pe notificarea de confirmare, apoi faceți clic pe Salvare. |
Ce trebuie să faceți în continuare
Trebuie să luați informațiile de configurare pe care Control Hub le-a generat și să mapați parametrii în gateway-ul local (de exemplu, pe un CISCO CUBE care se află la fața locului). Acest articol vă plimbă prin acest proces. Ca referință, consultați următoarea diagramă pentru un exemplu despre modul în care informațiile de configurare ale Hubului de control (din stânga) se mapează pe parametrii din CUBE (în dreapta):
După ce ați finalizat cu succes configurarea pe gateway-ul în sine, puteți reveni la
din Control Hub, iar gateway-ul pe care l-ați creat va fi listat în cardul de locație la care l-ați alocat cu un punct verde în partea stângă a numelui. Această stare indică faptul că gateway-ul este înregistrat în siguranță în cloud-ul apelant și servește ca gateway PSTN activ pentru locație.Puteți vizualiza, activa, elimina și adăuga cu ușurință numere de telefon pentru organizația dvs. în Control Hub. Pentru mai multe informații, consultați Gestionarea numerelor de telefon în Control Hub.
Dacă încercați serviciile Webex și doriți să convertiți versiunea de încercare într-un abonament plătit, puteți trimite o solicitare prin e-mail partenerului.
1 |
Conectați-vă la Control Hub la https://admin.webex.com, selectați pictograma de construcție |
2 |
Selectați fila Abonamente , apoi faceți clic pe Achiziție acum. Un e-mail este trimis partenerului prin care îi anunță că sunteți interesat să vă convertiți la un abonament plătit. |
Puteți utiliza Control Hub pentru a seta prioritatea opțiunilor de apelare disponibile pe care utilizatorii le văd în Webex App. De asemenea, le puteți activa pentru un singur clic și apel. Pentru mai multe informații, consultați: Setați opțiuni de apelare pentru utilizatorii Aplicației Webex.
Puteți controla ce se deschide aplicația de apelare atunci când utilizatorii efectuează apeluri. Puteți configura setările clientului de apelare, inclusiv implementarea în mod mixt pentru organizațiile cu utilizatori cu drepturi Unified CM sau Webex Calling și utilizatori fără servicii de apelare plătite de la Cisco. Pentru mai multe informații, consultați: Configurați comportamentul de apelare.
Configurați gateway-ul local în Cisco IOS XE pentru Webex Calling
Prezentare generală
Webex Calling acceptă în prezent două versiuni ale gateway-ului local:
-
Gateway local
-
Gateway local pentru Webex for Government
-
Înainte de a începe, înțelegeți cerințele pentru rețeaua de telefonie publică (PSTN) și gateway-ul local (LGW) de la nivel local pentru Webex Calling. Consultați Arhitectura preferată Cisco pentru Apelarea Webex pentru mai multe informații.
-
Acest articol presupune că o platformă dedicată Local Gateway este în loc cu nici o configurație de voce existente. Dacă modificați un gateway PSTN existent sau o implementare CUBE Enterprise pentru a fi utilizată ca funcție gateway local pentru Webex Calling, acordați o atenție deosebită configurației. Asigurați-vă că nu întrerupeți fluxurile de apeluri și funcționalitatea existente din cauza modificărilor pe care le efectuați.
Pentru informații despre SBC-urile terțe acceptate, consultați documentația de referință a produsului respectivă.
Există două opțiuni pentru a configura Gateway-ul local pentru trunchiul de apelare Webex:
-
Portbagaj pe bază de înregistrare
-
Portbagaj pe bază de certificat
Utilizați fluxul de activități fie din gatewayul local pe bază de înregistrar e, fie din gatewayul local pe bază de certifica t pentru a configura gatewayul local pentru trunchiul Webex Calling.
Consultați Începeți să utilizați gatewayul loca l pentru mai multe informații despre diferite tipuri de trunchiuri. Efectuați următorii pași pe Gateway-ul local în sine, utilizând interfața liniei de comandă (CLI). Utilizăm protocolul de inițiere a sesiunii (SIP) și transportul Transport Layer Security (TLS) pentru a securiza trunchiul și protocolul securizat în timp real (SRTP) pentru a securiza conținutul media între gateway-ul local și Webex Calling.
-
Selectați CUBE ca gateway local. Webex for Government nu acceptă în prezent controlori de frontieră de sesiune (SBC) terți. Pentru a revizui cea mai recentă listă, consultați Începeți să utilizați gateway-ul local.
- Instalați Cisco IOS XE Dublin 17.12.1a sau versiunile ulterioare pentru toate gateway-urile locale Webex for Government.
-
Pentru a examina lista autorităților de certificare rădăcină (CA) acceptate de Webex for Government, consultați Autorități de certificare rădăcină pentru Webex for Government.
-
Pentru detalii despre intervalele de porturi externe pentru gateway-ul local din Webex for Government, consultați Cerințe de rețea pentru Webex for Government (FedRAMP).
Gateway local pentru Webex for Government nu acceptă următoarele:
-
STUN/ICE-Lite pentru optimizarea căii media
-
Fax (T.38)
Pentru a configura gateway-ul local pentru trunchiul Webex Calling în Webex for Government, utilizați următoarea opțiune:
-
Portbagaj pe bază de certificat
Utilizați fluxul de activități din gatewayul local pe bază de certifica t pentru a configura gatewayul local pentru trunchiul Webex Calling. Pentru mai multe detalii despre cum să configurați un gateway local pe bază de certificat, consultați Configurați trunchiul pe bază de certificat Webex Calling.
Este obligatoriu să configurați cifruri GCM compatibile FIPS pentru a accepta gateway-ul local pentru Webex for Government. Dacă nu, configurarea apelurilor nu reușește. Pentru detalii de configurare, consultați Configurați trunchiul bazat pe certificat Webex Calling.
Această secțiune descrie cum se configurează un Cisco Unified Border Element (CUBE) ca gateway local pentru Webex Calling, utilizând un trunchi SIP care înregistrează. Prima parte a acestui document ilustrează modul în care se configurează un gateway PSTN simplu. În acest caz, toate apelurile de la PSTN sunt rutate către Webex Calling și toate apelurile de la Webex Calling sunt rutate către PSTN. Imaginea de mai jos evidențiază această soluție și configurația de rutare a apelurilor de nivel înalt care va fi urmată.
În acest design, sunt utilizate următoarele configurații principale:
-
entități găzduite din clasa vocală: Utilizat pentru a crea configurații specifice trunchiului.
-
uri clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
-
dial-peer de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup de dial-peer.
-
grup de tip dial-peer: Definește colegii de apelare de ieșire utilizați pentru rutarea ulterioară a apelurilor.
-
apelare peer de ieșire: Oferă tratament pentru mesajele SIP de ieșire și direcționează-le către ținta necesară.
În timp ce IP și SIP au devenit protocoalele implicite pentru trunchiurile PSTN, circuitele ISDN TDM (Time Division Multiplexing) sunt încă utilizate pe scară largă și sunt acceptate cu trunchiurile Webex Calling. Pentru a activa optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, în prezent este necesar să utilizați un proces de rutare a apelurilor pe două niveluri. Această abordare modifică configurația de rutare a apelurilor prezentată mai sus, prin introducerea unui set de colegi de apelare internă cu buclă inversă între Webex Calling și trunchiurile PSTN, după cum se ilustrează în imaginea de mai jos.
Când conectați o soluție Cisco Unified Communications Manager locală cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca referință pentru construirea soluției ilustrată în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratament centralizat pentru toate apelurile PSTN și Webex Calling.
Pe parcursul acestui document sunt utilizate numele gazdelor, adresele IP și interfețele ilustrate în imaginea următoare.
Utilizați îndrumările de configurare din restul acestui document pentru a finaliza configurarea gateway-ului local după cum urmează:
-
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
-
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați oricare dintre următoarele:
-
Pasul 3: Configurați gateway-ul local cu trunchiul PSTN SIP
-
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
-
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
Configurație de bază
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este crearea unei configurații de bază care să vă securizeze platforma și să stabilească conectivitatea.
-
Toate implementările de gateway local bazate pe înscriere necesită Cisco IOS XE 17.6.1a sau versiuni ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerat e.
-
Routerele din seria ISR4000 trebuie să fie configurate atât cu licențe pentru tehnologia de comunicații unificate, cât și cu licențe pentru tehnologia de securitate.
-
Routerele Catalyst Edge din seria 8000 echipate cu carduri vocale sau DSP-uri necesită licențierea DNA Advantage. Routerele fără carduri vocale sau DSP necesită un nivel minim de autorizare DNA Essentials.
-
-
Creați o configurație de bază pentru platforma dvs., care să respecte politicile de afaceri. În special, configurați următoarele și verificați funcționarea:
-
ntp
-
Acls
-
Autentificare utilizator și acces de la distanță
-
DNS
-
Rutare IP
-
Adrese IP
-
-
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4.
-
Încărcați pachetul CA rădăcină Cisco pe gateway-ul local.
Configurare
1 |
Asigurați-vă că atribuiți adrese IP valide și rutabile oricărei interfețe din stratul 3, de exemplu:
|
2 |
Protejați datele de înregistrare și acreditările STUN pe router utilizând criptarea simetrică. Configurați cheia de criptare principală și tipul de criptare după cum urmează:
|
3 |
Creați un punct de încredere PKI înlocuitor. Necesită acest punct de încredere pentru a configura TLS mai târziu. Pentru trunchiurile pe bază de înregistrare, acest punct de încredere nu necesită un certificat - la fel ca în cazul unui trunchi pe bază de certificat. |
4 |
Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare. Parametrii de transport ar trebui, de asemenea, actualizați pentru a asigura o conexiune sigură și fiabilă pentru înregistrare: Comanda de server cn-san-validate asigură faptul că gateway-ul local permite o conexiune dacă numele de gazdă configurat în entitatea găzduită 200 este inclus fie în câmpurile CN, fie în SAN ale certificatului primit de la proxy-ul de ieșire.
|
5 |
Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați comanda crypto pki trustpool importare URL curat pentru a descărca pachetul de certificate de certificare rădăcină de la URL-ul specificat și pentru a șterge pachetul actual de certificate de certificare, apoi instalați noul pachet de certificate: Dacă trebuie să utilizați un proxy pentru acces la internet utilizând HTTPS, adăugați următoarea configurație înainte de a importa pachetul CA: http client proxy-server yourproxy.com proxy-port 80 |
1 |
Creați un trunchi PSTN bazat pe înregistrare pentru o locație existentă în Control Hub. Notați informațiile despre trunchi care sunt furnizate după crearea trunchiului. Aceste detalii, așa cum sunt evidențiate în ilustrația următoare, vor fi utilizate în pașii de configurare din acest ghid. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling. |
2 |
Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling: Iată o explicație a câmpurilor pentru configurație:
Activează funcțiile Cisco Unified Border Element (CUBE) pe platformă. statistici mediaPermite monitorizarea media pe Gateway-ul local. statistici în bloc privind fișierele mediaPermite planului de control să sondeze planul de date pentru statisticile apelurilor în bloc. Pentru mai multe informații despre aceste comenzi, consultați Media. permiteți-conexiuni sip la sipActivați funcționalitatea de bază CUBE back-to-back a agentului utilizator. Pentru mai multe informații, consultați Permiteți conexiunile. În mod implicit, transportul fax T.38 este activat. Pentru mai multe informații, consultați protocolul de fax t38 (serviciul de voce). Activează STUN (Sesiune de traversare a UDP prin NAT) la nivel global.
Pentru mai multe informații, consultați id-ul agentului stun flowdat a și stun flowdata partajate în secret. sarcină utilă asimetrică plinăConfigurează suportul pentru sarcina utilă asimetrică SIP atât pentru sarcinile utile DTMF, cât și pentru cele dinamice ale codecului. Pentru mai multe informații despre această comandă, consultați sarcina utilă asimetrică. ofertă timpurie forțatăForțează gateway-ul local să trimită informații SDP în mesajul inițial de INVITAȚIE, în loc să aștepte confirmarea celuilalt partener. Pentru mai multe informații despre această comandă, consultați oferta din timp. |
3 |
Configurați filtrul codec clasa vocală 100 pentru trunchi. În acest exemplu, același filtru de codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis. Iată o explicație a câmpurilor pentru configurație: codec clasă vocală 100Utilizat pentru a permite doar codecuri preferate pentru apeluri prin intermediul trunchiurilor SIP. Pentru mai multe informații, consultați codec-ul clasei vocale. Codec opus este acceptat numai pentru trunchiurile PSTN bazate pe SIP. Dacă trunchiul PSTN utilizează o conexiune de voce T1/E1 sau FXO analogică, excludeți preferințele pentru codec 1 opus din configurația codec-ului clasei de voce 100 . |
4 |
Configurați utilizarea stun-class a clasei de voce 100 pentru a activa ICE pe trunchiul Webex Calling. Iată o explicație a câmpurilor pentru configurație: lită de gheață de utilizare stunUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare care se confruntă cu Webex Calling, pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stun-urilor de voc e și utilizarea stun-urilor de gheață lite. Aveți nevoie de utilizarea stun a ICE-lite pentru fluxurile de apeluri utilizând optimizarea căii media. Pentru a asigura optimizarea media pentru un gateway SIP la TDM, configurați un dial-peer loopback cu ICE-Lite activat pe segmentul IP-IP. Pentru detalii tehnice suplimentare, contactați Contul sau echipele TAC |
5 |
Configurați politica de criptare media pentru traficul Webex. Iată o explicație a câmpurilor pentru configurație: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte de cifru-suită SRTP CUBE în SDP în mesajele de ofertă și de răspuns. Webex Calling acceptă doar SHA1_80. Pentru mai multe informații, consultați srtp-crypto clasa vocală. |
6 |
Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local pe baza parametrului trunchiului de destinație: Iată o explicație a câmpurilor pentru configurație: uri clasă vocală 100 sipDefinește un model care să corespundă unei invitații SIP de intrare cu un dial-peer trunchi de intrare. Când introduceți acest model, utilizați dtg= urmat de valoarea Trunk OTG/DTG furnizată în Control Hub atunci când trunchiul a fost creat. Pentru mai multe informații, consultați URI-ul clasei de voce. |
7 |
Configurați profilul sip 100, care va fi utilizat pentru a modifica mesajele SIP înainte de a fi trimise către Webex Calling.
Iată o explicație a câmpurilor pentru configurație:
|
8 |
Configurați trunchiul Webex Calling: |
După ce definiți entitatea găzduită 100 și configurați un dial-peer SIP VoIP, gatewayul inițiază o conexiune TLS către Webex Calling. În acest moment, SBC de acces prezintă certificatul său gateway-ului local. Gateway-ul local validează certificatul SBC de acces Webex Calling utilizând pachetul rădăcină CA, care a fost actualizat anterior. Dacă certificatul este recunoscut, se stabilește o sesiune TLS persistentă între gateway-ul local și accesul Webex Calling SBC. Gateway-ul local poate apoi să utilizeze această conexiune securizată pentru a se înregistra la SBC cu acces Webex. Când înregistrarea este contestată pentru autentificare:
-
Parametrii nume de utilizator, parol ă și domeni u din configurația acreditărilo r sunt utilizați în răspuns.
-
Regulile de modificare din profilul sip 100 sunt utilizate pentru a converti URL-ul SIPS înapoi în SIP.
Înscrierea este reușită atunci când este primit un OK 200 de la accesul SBC.
După ce ați construit un trunchi către Webex Calling mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară celei detaliate mai sus pentru trunchiul Webex Calling. Direcționarea apelurilor securizate este acceptată de CUBE.
Dacă utilizați un trunchi TDM/ISDN PSTN, treceți la următoarea secțiune Configurați gateway-ul local cu trunchiul TDM PSTN.
Pentru a configura interfețele TDM pentru segmentele de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI.
1 |
Configurați următorul URI pentru clasa vocală pentru a identifica apelurile de intrare de la trunchiul PSTN: Iată o explicație a câmpurilor pentru configurație: uri clasă vocală 200 sipDefinește un model care să corespundă unei invitații SIP de intrare cu un dial-peer trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului dvs. IP PSTN. Pentru mai multe informații, consultați URI-ul clasei de voce. |
2 |
Configurați următorul dial-peer IP PSTN: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru o gestionare ușoară și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). protocol sesiune sipv2Specifică faptul că 20 0 de tip dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul de sesiune (dial peer). țintă sesiune ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite segmentul de apel. Ținta sesiunii aici este adresa IP a ITSP. Pentru mai multe informații, consultați ținta sesiunii (peer dial VoIP). URI de intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN a IP. Corespunde tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați URL-ul de intrare. legătură sursă-interfață de control GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați bind. legarea interfeței sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru conținutul media trimis către PSTN. Pentru mai multe informații, consultați bind. codec clasă vocală 100Configurează dial-peer pentru a utiliza lista de filtrare comună 100 de codec. Pentru mai multe informații, consultați codec pentru clasa vocală. dtmf- relay rtp- nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. Pentru mai multe informații, consultați Releu DTMF (Voice over IP). nu vadDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 |
Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de dirijare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
După ce ați construit un trunchi către Webex Calling, utilizați următoarea configurație pentru a crea un trunchi TDM pentru serviciul dvs. PSTN cu rutare apel în buclă pentru a permite optimizarea media în segmentul de apel Webex.
1 |
Configurația dial-peer în buclă inversă utilizează grupuri dial-peer și etichete de rutare a apelurilor pentru a se asigura că apelurile trec corect între Webex și PSTN, fără a crea bucle de rutare a apelurilor. Configurați următoarele reguli de traducere care vor fi utilizate pentru a adăuga și elimina etichetele de rutare a apelurilor: Iată o explicație a câmpurilor pentru configurație: regulă de traducere vocalăUtilizează expresii regulate definite în reguli pentru a adăuga sau a elimina etichete de rutare a apelurilor. Cifrele supra-divizate („A”) sunt utilizate pentru a adăuga claritate în scopul soluționării problemelor. În această configurație, eticheta adăugată de profilul de traducere 100 este utilizată pentru a ghida apelurile de la Webex Calling către PSTN prin intermediul colegilor de apelare cu loopback. În mod similar, eticheta adăugată de profilul de traducere 200 este utilizată pentru a ghida apelurile de la PSTN către Webex Calling. Profilurile de translatare 11 și 12 elimină aceste etichete înainte de a livra apeluri către trunchiurile Webex și, respectiv, către trunchiurile PSTN. Acest exemplu presupune că numerele apelate din Webex Calling sunt prezentate în format +E.164. Regula 100 elimină caracterul + din față pentru a menține un număr apelat valid. Regula 12 adaugă apoi o cifră (cifre) națională (naționale) de rutare atunci când se elimină eticheta. Utilizați cifre care se potrivesc cu planul dvs. de apelare național ISDN local. Dacă Webex Calling prezintă numerele în format național, ajustați regulile 100 și 12 pentru a adăuga și a elimina pur și simplu eticheta de rutare. Pentru mai multe informații, consultați profilul de traducere vocal ă și regula de traducere vocală. |
2 |
Configurați porturile interfeței vocale TDM conform cerințelor de tipul de trunchi și protocolului utilizat. Pentru mai multe informații, consultați Configurarea ISDN PRI. De exemplu, configurația de bază a unei interfețe ISDN cu rată primară instalată în slotul NIM 2 al unui dispozitiv poate include următoarele: |
3 |
Configurați următorul dial-peer TDM PSTN: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru o gestionare ușoară și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). profil traducere primite 200Atribuie profilul de translatare care va adăuga o etichetă de rutare a apelurilor la numărul apelat primit. apelare directă spre interiorRutează apelul fără a furniza un ton de apel secundar. Pentru mai multe informații, consultați apelare directă în interior. portul 0/2/0:15Portul de voce fizic asociat cu acest dial-peer. |
4 |
Pentru a activa optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, puteți modifica rutarea apelurilor prin introducerea unui set de colegi interni de apelare în buclă inversă între Webex Calling și trunchiurile PSTN. Configurați următorii colegi de apelare în buclă inversă. În acest caz, toate apelurile primite vor fi rutate inițial către dial-peer 10 și de acolo către dial-peer 11 sau 12 pe baza etichetei de rutare aplicate. După eliminarea etichetei de rutare, apelurile vor fi rutate către trunchiul de ieșire utilizând grupuri de tip dial-peer. Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP și oferă o descriere semnificativă pentru a facilita gestionarea și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. profil traducere de intrare 11Aplică profilul de translatare definit anterior pentru a elimina eticheta de rutare a apelurilor înainte de a trece la trunchiul de ieșire. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). protocol sesiune sipv2Specifică faptul că acest dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul de sesiune (dial peer). țintă sesiune 192.168.80.14Specifică adresa interfeței routerului local ca destinație a apelului în buclă inversă. Pentru mai multe informații, consultați țintă sesiune (coleg de apelare voip). legătură sursă-interfață de control GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise prin buclă inversă. Pentru mai multe informații, consultați bind. legarea interfeței sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru conținutul media trimis prin buclă inversă. Pentru mai multe informații, consultați bind. dtmf- relay rtp- nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. Pentru mai multe informații, consultați Releu DTMF (Voice over IP). codec g711alaw Forțează toate apelurile PSTN să utilizeze G.711. Selectați A-law sau u-law pentru a corespunde metodei de compandare utilizate de serviciul ISDN. nu vadDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
5 |
Adăugați următoarea configurație de rutare a apelurilor: Astfel, se încheie configurația gateway-ului local. Salvați configurația și reîncărcați platforma dacă aceasta este prima dată când sunt configurate caracteristici CUBE.
|
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt rutate prin Unified CM. Apelurile de la UCM de la portul 5060 sunt rutate către PSTN, iar apelurile de la portul 5065 sunt rutate către Webex Calling. Se pot adăuga următoarele configurații incrementale pentru a include acest scenariu de apelare.
Atunci când creați trunchiul Webex Calling în Unified CM, asigurați-vă că configurați portul de intrare în setările profilului de securitate trunchi SIP la 5065. Acest lucru permite mesajele de intrare pe portul 5065 și populați antetul VIA cu această valoare atunci când trimiteți mesaje către gateway-ul local.
1 |
Configurați următoarele URL-uri de clasă de voce: |
2 |
Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM: IOS XE utilizează aceste înregistrări pentru determinarea locală a gazdelor și porturilor UCM țintă. Cu această configurație, nu este necesar să configurați înregistrări în sistemul DNS. Dacă preferați să utilizați DNS, atunci aceste configurații locale nu sunt necesare. Iată o explicație a câmpurilor pentru configurație: Următoarea comandă creează o înregistrare a resursei DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: gazdă ip _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Ponderea înregistrată a resursei SRV 5060: Numărul portului care se va utiliza pentru gazda țintă în înregistrarea acestei resurse ucmsub5.mydomain.com: Gazda țintă pentru înregistrarea resursei Pentru a rezolva numele gazdelor țintă pentru înregistrarea resursei, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 Gazdă IP: Creează o înregistrare în baza de date locală IOS XE. ucmsub5.mydomain.com: Numele gazdei înregistrării A. 192.168.80.65: Adresa IP a gazdei. Creați înregistrările resurselor SRV și înregistrările A pentru a reflecta mediul UCM și strategia preferată de distribuire a apelurilor. |
3 |
Configurați următorii colegi de apelare: |
4 |
Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează proactiv problemele observate frecvent în Gateway-ul local bazat pe IOS XE și generează e-mail, syslog sau notificare de mesaje terminale ale evenimentului. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și transferul datelor colectate în cazul Cisco TAC pentru a accelera timpul de rezoluție.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele care declanșează probleme și acțiunile care trebuie întreprinse pentru a informa, a depana și a remedia problema. Puteți defini logica de detectare a problemelor folosind mesaje syslog, evenimente SNMP și prin monitorizarea periodică a ieșirilor specifice ale comenzilor de afișare.
Tipurile de acțiuni includ colectarea ieșirilor de comandă afișare:
-
Generarea unui fișier jurnal consolidat
-
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, FTP.
Inginerii TAC autor fișierele DS și îl semnează digital pentru protecția integrității. Fiecare fișier DS are un ID numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o singură sursă pentru găsirea semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
-
Nu editați fișierul DS pe care îl descărcați de la DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
-
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
-
Asigurați-vă că Gateway-ul local execută IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway local care rulează IOS XE 17.6.1a sau o versiune ulterioară
-
Semnăturile de diagnosticare sunt activate în mod implicit.
-
Configurați serverul de e-mail securizat care se va utiliza pentru a trimite notificări proactive dacă dispozitivul rulează Cisco IOS XE 17.6.1a sau o versiune ulterioară.
configurați serverul de e-mail terminal de apelare la domiciliu :@ prioritate 1 end tls securizat
-
Configurați variabila de mediu ds_email cu adresa de e-mail a administratorului pentru a vă notifica.
configurați mediul de semnătură de diagnosticare-apel-acasă terminal ds_email sfârșit
Următorul prezintă un exemplu de configurare a unui gateway local care rulează pe Cisco IOS XE 17.6.1a sau o versiune ulterioară pentru a trimite notificările proactive la tacfaststart@gmail.com utilizând Gmail ca server SMTP securizat:
Vă recomandăm să utilizați Cisco IOS XE Bengaluru 17.6.x sau versiunile ulterioare.
server de e-mail call-home tacfaststart:password@smtp.gmail.com prioritate 1 mediu securizat de semnătură de diagnosticare ds_email „tacfaststart@gmail.com”
Un Gateway local care rulează pe Cisco IOS XE Software nu este un client Gmail tipic bazat pe web care acceptă OAuth, deci trebuie să configurăm o anumită setare de cont Gmail și să oferim permisiunea specifică de a avea e-mailul de pe dispozitiv procesat corect:
-
Accesați Acces la aplicație mai puțin sigur .
și activați setarea -
Răspundeți la "Da, am fost eu" atunci când primiți un e-mail de la Gmail în care se menționează "Google a împiedicat pe cineva să se conecteze la contul dvs., folosind o aplicație non-Google".
Instalarea semnăturilor de diagnosticare pentru monitorizare proactivă
Monitorizarea utilizării ridicate a procesorului
Acest DS urmărește utilizarea procesorului timp de cinci secunde utilizând SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea ajunge la 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare care sunt instalate în Gateway-ul local. Urmați acești pași de mai jos pentru a instala semnătura.
-
Utilizați comanda afișare snmp pentru a activa SNMP. Dacă nu activați această opțiune, configurați comanda snmp-server manager .
afișare snmp %agent SNMP neactivat config t snmp-server manager sfârșit afișare snmp Șasiu: intrare pachete SNMP ABCDEFGHIGK 149655 0 Erori de versiune Bad SNMP 1 Nume comunitate necunoscută 0 Operațiune ilegală pentru numele comunității furnizată 0 Eroare de codificare 37763 Număr de variabile solicitate 2 Număr de variabile modificate 34560 PDU-uri Get-request 138 PDU-uri Get-next 2 PDU-uri de setare a solicitării 0 picături pachet coadă de intrare (dimensiunea maximă a cozii 1000) 158277 pachete SNMP de ieșire 0 Erori prea mari (dimensiunea maximă a pachetului 1500) 20 Nu există astfel de erori de nume 0 Valori greșite 0 Erori generale 7998 PDU-uri de răspuns 10280 Pachete PDU-uri de urmărire în prezent în coada de intrare a procesului SNMP: 0 SNMP capcana globală: activate
-
Descărcați DS 64224 utilizând următoarele opțiuni verticale din Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco seria 4300, 4400 ISR sau Cisco CSR seria 1000V
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Copiați fișierul DS XML în blițul Local Gateway.
LocalGateway# copiere ftp://nume utilizator:parolă@/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe Gateway-ul local.
copiați ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Se accesează ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 biți] 3571 biți copiați în 0,064 sec (55797 biți/sec)
-
Instalați fișierul DS XML în Gateway-ul local.
Încărcare semnătură diagnostic-apel acasă DS_64224.xml Încărcare fișier DS_64224.xml cu succes
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare ar trebui să aibă o valoare "înregistrată".
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: username@gmail.com
Descarca DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv pe sine. Dacă este necesar, reinstalați DS 64224 pentru a continua să monitorizați utilizarea ridicată a CPU pe gateway-ul local.
Monitorizarea înregistrării portbagajului SIP
Acest DS verifică anularea înregistrării unui portbagaj SIP Local Gateway cu cloud webex Calling la fiecare 60 de secunde. După ce este detectat evenimentul de anulare a înscrierii, acesta generează o notificare prin e-mail și syslog și se dezinstalează după două apariții de anulare a înscrierii. Utilizați pașii de mai jos pentru a instala semnătura:
-
Descărcați DS 64117 utilizând următoarele opțiuni verticale din Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
SIP-SIP
Tip de problemă
SIP Trunk Unregistration cu notificare prin e-mail.
-
Copiați fișierul DS XML în Gateway-ul local.
copiați ftp://nume utilizator:password@/DS_64117.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
Încărcare semnătură diagnostic-apel acasă DS_64117.xml Încărcare fișier DS_64117.xml reușită Gateway local#
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează sondajul SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor, cu erori SIP 403, 488 și 503. Dacă creșterea numărului de erori este mai mare sau egală cu 5 de la ultimul sondaj, se generează o notificare syslog și prin e-mail. Utilizați pașii de mai jos pentru a instala semnătura.
-
Utilizați comanda afișare snmp pentru a verifica dacă SNMP este activat. Dacă nu este activată, configurați comanda snmp-server manager .
afișare snmp %agent SNMP neactivat config t snmp-server manager sfârșit afișare snmp Șasiu: intrare pachete SNMP ABCDEFGHIGK 149655 0 Erori de versiune Bad SNMP 1 Nume comunitate necunoscută 0 Operațiune ilegală pentru numele comunității furnizată 0 Eroare de codificare 37763 Număr de variabile solicitate 2 Număr de variabile modificate 34560 PDU-uri Get-request 138 PDU-uri Get-next 2 PDU-uri de setare a solicitării 0 picături pachet coadă de intrare (dimensiunea maximă a cozii 1000) 158277 pachete SNMP de ieșire 0 Erori prea mari (dimensiunea maximă a pachetului 1500) 20 Nu există astfel de erori de nume 0 Valori greșite 0 Erori generale 7998 PDU-uri de răspuns 10280 Pachete PDU-uri de urmărire în prezent în coada de intrare a procesului SNMP: 0 SNMP capcana globală: activate
-
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
SIP anormale apel deconectați de detectare cu e-mail și Syslog notificare.
-
Copiați fișierul DS XML în Gateway-ul local.
copiați ftp://nume utilizator:password@/DS_65221.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
încărcare semnătură diagnostic-apel acasă DS_65221.xml Încărcare fișier DS_65221.xml cu succes
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
Instalarea semnăturilor de diagnosticare pentru a depana o problemă
Utilizați semnături de diagnosticare (DS) pentru a rezolva rapid problemele. Cisco TAC ingineri au creat mai multe semnături care permit depanare necesare, care sunt necesare pentru a depana o anumită problemă, detecta apariția problemei, colecta dreptul de set de date de diagnosticare și transferul automat de date la cisco TAC caz. Semnăturile de diagnosticare (DS) elimină necesitatea de a verifica manual apariția problemei și facilitează mult soluționarea problemelor intermitente și tranzitorii.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva singur o problemă dată sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția "%VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și automatizați colectarea datelor de diagnosticare utilizând următorii pași:
-
Configurați o variabilă suplimentară a mediului DSds_fsurl_prefix , care este calea serverului de fișiere Cisco TAC (cxd.cisco.com) la care sunt încărcate datele de diagnosticare colectate. Numele de utilizator din calea fișierului este numărul de caz, iar parola este tokenul de încărcare a fișierului care poate fi preluat de la Support Case Manager din următoarea comandă. Tokenul de încărcare a fișierului poate fi generat în secțiunea Atașamente din Support Case Manager, după cum este necesar.
configurați terminalul call-home diagnostic-semnătură LocalGateway(cfg-call-home-diag-sign) mediu ds_fsurl_prefix „scp://:@cxd.cisco.com” end
Exemplu:
apel-acasă diagnostic-semnătură mediu ds_fsurl_prefix " mediu ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Asigurați-vă că SNMP este activat utilizând comanda afișare snmp . Dacă nu este activată, configurați comanda snmp-server manager .
afișare agent snmp %SNMP neactivat config t sfârșit manager snmp-server
-
Asigurați-vă că instalați monitorizarea ridicată a procesorului DS 64224 ca o măsură proactivă pentru a dezactiva toate semnăturile de depanare și diagnosticare în timpul utilizării ridicate a procesorului. Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Cisco 4300, 4400 ISR Series sau Cisco CSR 1000V Series
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Syslogs
Tip de problemă
Syslog - %VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0
-
Copiați fișierele DS XML pe Gateway-ul local.
copiați ftp://nume utilizator:password@/DS_64224.xml bootflash: copiați ftp://nume utilizator:password@/DS_65095.xml bootflash:
-
Instalați fișierul DS 64224 de monitorizare a procesorului înalt și apoi DS 65095 XML în Gateway-ul local.
Încărcare semnătură diagnostic-apel acasă DS_64224.xml Încărcare fișier DS_64224.xml succes apel-acasă diagnostic-semnătură DS_65095.xml Încărcare fișier DS_65095.xml succes
-
Verificați dacă semnătura este instalată cu succes folosind comanda afișare semnătură de diagnosticare acasă . Coloana de stare trebuie să aibă o valoare "înregistrată".
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DescarcaT DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-08
65095
00:12:53
LGWIECC___all_spike_threshold
0.0.12
Înscris
2020-11-08
Verificarea executării semnăturilor de diagnosticare
În următoarea comandă, coloana „Stare” a comenzii Afișare semnătură diagnostic apel-acasă se schimbă la „rulare” în timp ce gatewayul local execută acțiunea definită în cadrul semnăturii. Rezultatul statisticilor de diagnosticare a semnăturii de apel la domiciliu este cea mai bună modalitate de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și execută acțiunea. Coloana "Triggered/Max/Deinstall" indică de câte ori semnătura dată a declanșat un eveniment, numărul maxim de ori este definit pentru a detecta un eveniment și dacă semnătura se deinstalează după detectarea numărului maxim de evenimente declanșate.
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DescarcaT DSes:
ID-ul DS |
Numele DS |
Revizie |
Stare |
Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Înscris |
2020-11-08 00:07:45 |
65095 |
LGWIECC___all_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișarea statisticilor privind semnătura de diagnosticare a apelurilor la domiciliu
ID-ul DS |
Numele DS |
Declanșat/max/dezinstalare |
Timp mediu de rulare (secunde) |
Timp maxim de rulare (secunde) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
LGWIECC___all_spike_threshold |
1/20/Y |
23.053 |
23.053 |
E-mailul de notificare care este trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația care rulează și afișarea ieșirilor de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalarea semnăturilor de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemelor. Dacă doriți să dezinstalați manual o semnătură, recuperați ID-ul DS din rezultatul comenzii afișare semnătură diagnostic apel-acasă și executați următoarea comandă:
dezinstalare semnătură diagnosticare-apel acasă
Exemplu:
dezinstalare semnătură diagnosticare acasă 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor care sunt frecvent observate în implementări. TAC în prezent nu acceptă solicitările de creare de noi semnături particularizate.
Pentru o mai bună gestionare a gateway-urilor Cisco IOS XE, vă recomandăm să înscrieți și să gestionați gateway-urile prin intermediul Control Hub. Este o configurație opțională. Când sunteți înscris, puteți utiliza opțiunea de validare a configurației din Control Hub pentru a valida configurația gateway-ului local și pentru a identifica orice probleme de configurare. În prezent, această funcționalitate este acceptată numai de trunchiurile pe bază de înregistrare.
Pentru mai multe informații, consultați următoarele:
Această secțiune descrie cum se configurează un Cisco Unified Border Element (CUBE) ca gateway local pentru Webex Calling, utilizând trunchiul SIP TLS reciproc (mTLS) bazat pe certificat. Prima parte a acestui document ilustrează modul în care se configurează un gateway PSTN simplu. În acest caz, toate apelurile de la PSTN sunt rutate către Webex Calling și toate apelurile de la Webex Calling sunt rutate către PSTN. Imaginea următoare evidențiază această soluție și configurația de dirijare a apelurilor de nivel înalt care va fi urmărită.
În acest design, sunt utilizate următoarele configurații principale:
-
entități găzduite ale clasei de voce: Utilizate pentru a crea configurații specifice trunchiurilor.
-
uri clasă vocală: Utilizat pentru a clasifica mesajele SIP pentru selectarea unui dial-peer de intrare.
-
dial-peer de intrare: Oferă tratament pentru mesajele SIP de intrare și determină ruta de ieșire cu un grup de dial-peer.
-
grup de tip dial-peer: Definește colegii de apelare de ieșire utilizați pentru rutarea ulterioară a apelurilor.
-
apelare peer de ieșire: Oferă tratament pentru mesajele SIP de ieșire și direcționează-le către ținta necesară.
În timp ce IP și SIP au devenit protocoalele implicite pentru trunchiurile PSTN, circuitele ISDN TDM (Time Division Multiplexing) sunt încă utilizate pe scară largă și sunt acceptate cu trunchiurile Webex Calling. Pentru a activa optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, în prezent este necesar să utilizați un proces de rutare a apelurilor pe două niveluri. Această abordare modifică configurația de rutare a apelurilor prezentată mai sus, prin introducerea unui set de colegi de apelare internă cu buclă inversă între Webex Calling și trunchiurile PSTN, după cum se ilustrează în imaginea de mai jos.
Când conectați o soluție Cisco Unified Communications Manager locală cu Webex Calling, puteți utiliza configurația simplă a gateway-ului PSTN ca referință pentru construirea soluției ilustrată în următoarea diagramă. În acest caz, Unified Communications Manager oferă rutare și tratament centralizat pentru toate apelurile PSTN și Webex Calling.
Pe parcursul acestui document sunt utilizate numele gazdelor, adresele IP și interfețele ilustrate în imaginea următoare. Sunt prevăzute opțiuni pentru abordarea publică sau privată (în urma NAT). Înregistrările DNS SRV sunt opționale, cu excepția cazului în care echilibrarea sarcinii pe mai multe instanțe CUBE.
Utilizați îndrumările de configurare din restul acestui document pentru a finaliza configurarea gateway-ului local după cum urmează:
-
Pasul 1: Configurați conectivitatea și securitatea de bază a routerului
-
Pasul 2: Configurați trunchiul Webex Calling
În funcție de arhitectura necesară, urmați oricare dintre următoarele:
-
Pasul 3: Configurați gateway-ul local cu trunchiul PSTN SIP
-
Pasul 4: Configurați gateway-ul local cu mediul Unified CM existent
Sau:
-
Pasul 3: Configurați gateway-ul local cu trunchiul TDM PSTN
Configurație de bază
Primul pas în pregătirea routerului Cisco ca gateway local pentru Webex Calling este crearea unei configurații de bază care să vă securizeze platforma și să stabilească conectivitatea.
-
Toate implementările de gateway local pe bază de certificat necesită Cisco IOS XE 17.9.1a sau versiuni ulterioare. Pentru versiunile recomandate, consultați pagina Cisco Software Research . Căutați platforma și selectați una dintre versiunile sugerat e.
-
Routerele din seria ISR4000 trebuie să fie configurate atât cu licențe pentru tehnologia de comunicații unificate, cât și cu licențe pentru tehnologia de securitate.
-
Routerele Catalyst Edge din seria 8000 echipate cu carduri vocale sau DSP-uri necesită autorizarea DNA Essentials. Routerele fără carduri vocale sau DSP necesită un nivel minim de autorizare DNA Essentials.
-
Pentru cerințele de mare capacitate, puteți solicita, de asemenea, o licență High Security (HSEC) și drepturi suplimentare privind fluxul.
Consultați Coduri de autorizar e pentru mai multe detalii.
-
-
Creați o configurație de bază pentru platforma dvs., care să respecte politicile de afaceri. În special, configurați următoarele și verificați funcționarea:
-
ntp
-
Acls
-
Autentificare utilizator și acces de la distanță
-
DNS
-
Rutare IP
-
Adrese IP
-
-
Rețeaua către Webex Calling trebuie să utilizeze o adresă IPv4. Numele de domeniu complet calificat (FQDN) sau adresele de înregistrare a serviciului (SRV) ale gateway-ului local trebuie să corespundă cu o adresă IPv4 publică de pe internet.
-
Toate porturile SIP și media de pe interfața gateway local cu fața la Webex trebuie să fie accesibile de la internet, fie direct, fie prin NAT static. Asigurați-vă că actualizați firewall-ul în consecință.
-
Instalați un certificat semnat pe gateway-ul local (următorii prezintă pașii de configurare detaliați).
-
O Autoritate de certificare publică (CA), așa cum este detaliat în secțiunea Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platformele audio și video Cisco Webex ?, trebuie să semneze certificatul dispozitivului.
-
FQDN configurat în Control Hub la crearea unui trunchi trebuie să fie certificatul Nume comun (CN) sau Nume alternativ subiect (SAN) al routerului. De exemplu:
-
Dacă un trunchi configurat în Control Hub al organizației dvs. are cube1.lgw.com:5061 ca FQDN al gateway-ului local, atunci CN sau SAN din certificatul routerului trebuie să conțină cube1.lgw.com.
-
Dacă un trunchi configurat în Control Hub al organizației dvs. are lgws.lgw.com ca adresă SRV a gatewayului sau gatewayurilor locale accesibile din trunchi, atunci CN sau SAN din certificatul de router trebuie să conțină lgws.lgw.com. Înregistrările la care se rezolvă adresa SRV (CNAME, O înregistrare sau adresă IP) sunt opționale în SAN.
-
Indiferent dacă utilizați un FQDN sau SRV pentru trunchi, adresa de contact pentru toate dialogurile SIP noi din gatewayul local utilizează numele configurat în Control Hub.
-
-
-
Asigurați-vă că certificatele sunt semnate pentru utilizarea clientului și a serverului.
-
Încărcați pachetul CA rădăcină Cisco pe gateway-ul local.
Configurare
1 |
Asigurați-vă că atribuiți adrese IP valide și rutabile oricărei interfețe din stratul 3, de exemplu:
|
2 |
Protejați acreditările STUN pe router utilizând criptarea simetrică. Configurați cheia de criptare principală și tipul de criptare după cum urmează: |
3 |
Creați un punct de încredere pentru criptare cu un certificat semnat de Certificate Authority (CA) preferat. |
4 |
Autentificați-vă noul certificat utilizând certificatul CA intermediar (sau rădăcină), apoi importați certificatul (Pasul 4). Introduceți următoarea comandă de execuție sau de configurare:
|
5 |
Importați un certificat de gazdă semnat utilizând următoarea comandă de execuție sau de configurare:
|
6 |
Activați exclusivitatea TLS1.2 și specificați punctul de încredere implicit utilizând următoarele comenzi de configurare:
|
7 |
Instalați pachetul CA rădăcină Cisco, care include certificatul CA DigiCert utilizat de Webex Calling. Utilizați comanda crypto pki trustpool importare URL curat pentru a descărca pachetul de certificate de certificare rădăcină de la URL-ul specificat și pentru a șterge pachetul actual de certificate de certificare, apoi instalați noul pachet de certificate: Dacă trebuie să utilizați un proxy pentru acces la internet utilizând HTTPS, adăugați următoarea configurație înainte de a importa pachetul CA: http client proxy-server yourproxy.com proxy-port 80 |
1 |
Creați un trunchi PSTN bazat pe certificat CUBE pentru o locație existentă în Control Hub. Pentru mai multe informații, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling. Notați informațiile despre trunchi care sunt furnizate odată ce trunchiul este creat. Aceste detalii, așa cum sunt evidențiate în ilustrația următoare, vor fi utilizate în pașii de configurare din acest ghid. |
2 |
Introduceți următoarele comenzi pentru a configura CUBE ca gateway local Webex Calling: Iată o explicație a câmpurilor pentru configurație:
Activează funcțiile Cisco Unified Border Element (CUBE) pe platformă. permiteți-conexiuni sip la sipActivați SIP de bază CUBE înapoi la înapoi funcționalitatea agentului utilizator. Pentru mai multe informații, consultați Permiteți conexiunile. În mod implicit, transportul fax T.38 este activat. Pentru mai multe informații, consultați protocolul de fax t38 (serviciul de voce). Activează STUN (Sesiune de traversare a UDP prin NAT) la nivel global. Aceste comenzi globale stun sunt necesare numai atunci când implementați gateway-ul local în spatele NAT.
Pentru mai multe informații, consultați id agent stun flowdata și stun flowdata partajate în secret. sarcină utilă asimetrică plinăConfigurează suportul pentru sarcina utilă asimetrică SIP atât pentru sarcinile utile DTMF, cât și pentru cele dinamice ale codecului. Pentru mai multe informații despre această comandă, consultați sarcina utilă asimetrică. ofertă timpurie forțatăForțează gateway-ul local să trimită informații SDP în mesajul inițial de INVITAȚIE, în loc să aștepte confirmarea celuilalt partener. Pentru mai multe informații despre această comandă, consultați oferta din timp. Primite profiluri SIPPermite CUBE să utilizeze profiluri SIP pentru a modifica mesajele pe măsură ce acestea sunt primite. Profilurile sunt aplicate prin intermediul colegilor de apelare sau al entităților găzduite. |
3 |
Configurați filtrul codec pentru clasa vocală 100 pentru trunchi. În acest exemplu, același filtru de codec este utilizat pentru toate trunchiurile. Puteți configura filtre pentru fiecare trunchi pentru un control precis. Iată o explicație a câmpurilor pentru configurație: codec clasă vocală 100Utilizat pentru a permite doar codecuri preferate pentru apeluri prin intermediul trunchiurilor SIP. Pentru mai multe informații, consultați codec-ul clasei vocale. Codec opus este acceptat numai pentru trunchiurile PSTN bazate pe SIP. Dacă trunchiul PSTN utilizează o conexiune de voce T1/E1 sau FXO analogică, excludeți preferințele pentru codec 1 opus din configurația codec-ului clasei de voce 100 . |
4 |
Configurați utilizarea stun-class a clasei de voce 100 pentru a activa ICE pe trunchiul Webex Calling. (Acest pas nu se aplică pentru Webex for Government) Iată o explicație a câmpurilor pentru configurație: lită de gheață de utilizare stunUtilizat pentru a activa ICE-Lite pentru toți colegii de apelare care se confruntă cu Webex Calling, pentru a permite optimizarea media ori de câte ori este posibil. Pentru mai multe informații, consultați utilizarea stun-urilor de voc e și utilizarea stun-urilor de gheață lite. Comanda date de flux de traversare firewall cu utilizare stun este necesară numai atunci când implementați gatewayul local în spatele NAT. Aveți nevoie de utilizarea stun a ICE-lite pentru fluxurile de apeluri utilizând optimizarea căii media. Pentru a asigura optimizarea media pentru un gateway SIP la TDM, configurați un dial-peer loopback cu ICE-Lite activat pe segmentul IP-IP. Pentru detalii tehnice suplimentare, contactați Contul sau echipele TAC. |
5 |
Configurați politica de criptare media pentru traficul Webex. (Acest pas nu se aplică pentru Webex for Government) Iată o explicație a câmpurilor pentru configurație: clasă vocală srtp-crypto 100Specifică SHA1_80 ca singurele oferte de cifru-suită SRTP CUBE în SDP în mesajele de ofertă și de răspuns. Webex Calling acceptă doar SHA1_80. Pentru mai multe informații, consultați srtp-crypto clasa vocală. |
6 |
Configurați cifruri GCM compatibile FIPS (Acest pas este aplicabil numai pentru Webex for Government). Iată o explicație a câmpurilor pentru configurație: clasă vocală srtp-crypto 100Specifică GCM ca suită de cifruri pe care le oferă CUBE. Configurarea cifrurilor GCM pentru gateway-ul local este obligatorie pentru Webex for Government. |
7 |
Configurați un model pentru a identifica în mod unic apelurile către un trunchi de gateway local, pe baza FQDN-ului sau a SRV-ului destinației: Iată o explicație a câmpurilor pentru configurație: uri clasă vocală 100 sipDefinește un model care să corespundă unei invitații SIP de intrare cu un dial-peer trunchi de intrare. Când introduceți acest model, utilizați LGW FQDN sau SRV configurate în Control Hub în timp ce creați un trunchi. |
8 |
Configurați profiluri de manipulare a mesajelor SIP. Dacă gateway-ul este configurat cu o adresă IP publică, configurați un profil după cum urmează sau treceți la pasul următor dacă utilizați NAT. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local și „198.51.100.1” este adresa IP publică a interfeței gateway-ului local cu care se confruntă Webex Calling: Iată o explicație a câmpurilor pentru configurație: regulile 10 și 20Pentru a permite Webex să autentifice mesajele de la gateway-ul dvs. local, antetul „Contact” din mesajele de solicitare SIP și de răspuns trebuie să conțină valoarea configurată pentru trunchi în Control Hub. Acesta va fi fie FQDN-ul unei singure gazde, fie numele de domeniu SRV utilizat pentru un cluster de dispozitive. Omiteți pasul următor dacă ați configurat gateway-ul local cu adrese IP publice. |
9 |
În cazul în care gateway-ul este configurat cu o adresă IP privată în spatele NAT static, configurați profilurile SIP de intrare și de ieșire după cum urmează. În acest exemplu, cube1.lgw.com este FQDN configurat pentru gateway-ul local, „10.80.13.12” este adresa IP a interfeței cu Webex Calling și „192.65.79.20” este adresa IP publică NAT. Profilurile SIP pentru mesaje de ieșire către Webex Calling
Iată o explicație a câmpurilor pentru configurație: regulile 10 și 20Pentru a permite Webex să autentifice mesajele de la gateway-ul dvs. local, antetul „Contact” din mesajele de solicitare SIP și de răspuns trebuie să conțină valoarea configurată pentru trunchi în Control Hub. Acesta va fi fie FQDN-ul unei singure gazde, fie numele de domeniu SRV utilizat pentru un cluster de dispozitive. regulile 30-81Convertiți adresele private referințele la adresa publică externă pentru site, permițând Webex să interpreteze și să ruteze corect mesajele ulterioare. Profilul SIP pentru mesaje de intrare din profiluri de clasă vocală sip Webex Calling Iată o explicație a câmpurilor pentru configurație: regulile 10-80Convertiți adresa publică referințe la adresa privată configurată, permițând ca mesajele de la Webex să fie procesate corect de către CUBE. Pentru mai multe informații, consultați profiluri SIP pentru clasa vocală. |
10 |
Configurați o opțiune SIP păstrată în viață cu profilul de modificare a antetului. Iată o explicație a câmpurilor pentru configurație: sip-options-keepalive clasă voce 100Configurează un profil keepalive și intră în modul de configurare a clasei de voce. Puteți configura timpul (în secunde) în care un SIP În afara opțiunilor de dialog Ping este trimis la ținta de apelare atunci când conexiunea bătăilor inimii la punctul final este în stare SUS sau În jos. Acest profil keepalive este declanșat din dial-peer configurat către Webex. Pentru a vă asigura că antetele de contact includ numele de domeniu complet calificat al SBC, se utilizează profilul SIP 115. Regulile 30, 40 și 50 sunt necesare numai atunci când SBC este configurat în spatele NAT static. În acest exemplu, cube1.lgw.com este FQDN selectat pentru gateway-ul local și dacă se utilizează NAT static, „10.80.13.12” este adresa IP a interfeței SBC către Webex Calling și „192.65.79.20” este adresa IP publică NAT. |
11 |
Configurați trunchiul Webex Calling: |
După ce ați construit un trunchi către Webex Calling mai sus, utilizați următoarea configurație pentru a crea un trunchi necriptat către un furnizor PSTN bazat pe SIP:
Dacă furnizorul dvs. de servicii oferă un trunchi PSTN securizat, puteți urma o configurație similară celei detaliate mai sus pentru trunchiul Webex Calling. Direcționarea apelurilor securizate este acceptată de CUBE.
Dacă utilizați un trunchi TDM/ISDN PSTN, treceți la următoarea secțiune Configurați gateway-ul local cu trunchiul TDM PSTN.
Pentru a configura interfețele TDM pentru segmentele de apel PSTN pe gateway-urile Cisco TDM-SIP, consultați Configurarea ISDN PRI.
1 |
Configurați următorul URI pentru clasa vocală pentru a identifica apelurile de intrare de la trunchiul PSTN: Iată o explicație a câmpurilor pentru configurație: uri clasă vocală 200 sipDefinește un model care să corespundă unei invitații SIP de intrare cu un dial-peer trunchi de intrare. Când introduceți acest model, utilizați adresa IP a gateway-ului dvs. IP PSTN. Pentru mai multe informații, consultați URI-ul clasei de voce. |
2 |
Configurați următorul dial-peer IP PSTN: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru o gestionare ușoară și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). protocol sesiune sipv2Specifică faptul că 20 0 de tip dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul de sesiune (dial peer). țintă sesiune ipv4:192.168.80.13Indică adresa IPv4 țintă a destinației pentru a trimite segmentul de apel. Ținta sesiunii aici este adresa IP a ITSP. Pentru mai multe informații, consultați ținta sesiunii (peer dial VoIP). URI de intrare prin 200Definește un criteriu de potrivire pentru antetul VIA cu adresa IP PSTN a IP. Corespunde tuturor segmentelor de apel IP PSTN de intrare de pe gateway-ul local cu dial-peer 200. Pentru mai multe informații, consultați URL-ul de intrare. legătură sursă-interfață de control GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise către PSTN. Pentru mai multe informații, consultați bind. legarea interfeței sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru conținutul media trimis către PSTN. Pentru mai multe informații, consultați bind. codec clasă vocală 100Configurează dial-peer pentru a utiliza lista de filtrare comună 100 de codec. Pentru mai multe informații, consultați codec pentru clasa vocală. dtmf- relay rtp- nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. Pentru mai multe informații, consultați Releu DTMF (Voice over IP). nu vadDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
3 |
Dacă configurați gateway-ul local pentru a dirija numai apelurile între Webex Calling și PSTN, adăugați următoarea configurație de dirijare a apelurilor. Dacă configurați gateway-ul local cu o platformă Unified Communications Manager, treceți la următoarea secțiune. |
După ce ați construit un trunchi către Webex Calling, utilizați următoarea configurație pentru a crea un trunchi TDM pentru serviciul dvs. PSTN cu rutare apel în buclă pentru a permite optimizarea media în segmentul de apel Webex.
1 |
Configurația dial-peer în buclă inversă utilizează grupuri dial-peer și etichete de rutare a apelurilor pentru a se asigura că apelurile trec corect între Webex și PSTN, fără a crea bucle de rutare a apelurilor. Configurați următoarele reguli de traducere care vor fi utilizate pentru a adăuga și elimina etichetele de rutare a apelurilor: Iată o explicație a câmpurilor pentru configurație: regulă de traducere vocalăUtilizează expresii regulate definite în reguli pentru a adăuga sau a elimina etichete de rutare a apelurilor. Cifrele supra-divizate („A”) sunt utilizate pentru a adăuga claritate în scopul soluționării problemelor. În această configurație, eticheta adăugată de profilul de traducere 100 este utilizată pentru a ghida apelurile de la Webex Calling către PSTN prin intermediul colegilor de apelare cu loopback. În mod similar, eticheta adăugată de profilul de traducere 200 este utilizată pentru a ghida apelurile de la PSTN către Webex Calling. Profilurile de translatare 11 și 12 elimină aceste etichete înainte de a livra apeluri către trunchiurile Webex și, respectiv, către trunchiurile PSTN. Acest exemplu presupune că numerele apelate din Webex Calling sunt prezentate în format +E.164. Regula 100 elimină caracterul + din față pentru a menține un număr apelat valid. Regula 12 adaugă apoi o cifră (cifre) națională (naționale) de rutare atunci când se elimină eticheta. Utilizați cifre care se potrivesc cu planul dvs. de apelare național ISDN local. Dacă Webex Calling prezintă numerele în format național, ajustați regulile 100 și 12 pentru a adăuga și a elimina pur și simplu eticheta de rutare. Pentru mai multe informații, consultați profilul de traducere vocal ă și regula de traducere vocală. |
2 |
Configurați porturile interfeței vocale TDM conform cerințelor de tipul de trunchi și protocolului utilizat. Pentru mai multe informații, consultați Configurarea ISDN PRI. De exemplu, configurația de bază a unei interfețe ISDN cu rată primară instalată în slotul NIM 2 al unui dispozitiv poate include următoarele: |
3 |
Configurați următorul dial-peer TDM PSTN: Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP cu o etichetă de 200 și oferă o descriere semnificativă pentru o gestionare ușoară și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). profil traducere primite 200Atribuie profilul de translatare care va adăuga o etichetă de rutare a apelurilor la numărul apelat primit. apelare directă spre interiorRutează apelul fără a furniza un ton de apel secundar. Pentru mai multe informații, consultați apelare directă în interior. portul 0/2/0:15Portul de voce fizic asociat cu acest dial-peer. |
4 |
Pentru a activa optimizarea media a căilor IP pentru gateway-urile locale cu fluxuri de apeluri TDM-IP, puteți modifica rutarea apelurilor prin introducerea unui set de colegi interni de apelare în buclă inversă între Webex Calling și trunchiurile PSTN. Configurați următorii colegi de apelare în buclă inversă. În acest caz, toate apelurile primite vor fi rutate inițial către dial-peer 10 și de acolo către dial-peer 11 sau 12 pe baza etichetei de rutare aplicate. După eliminarea etichetei de rutare, apelurile vor fi rutate către trunchiul de ieșire utilizând grupuri de tip dial-peer. Iată o explicație a câmpurilor pentru configurație: Definește un dial-peer VoIP și oferă o descriere semnificativă pentru a facilita gestionarea și soluționarea problemelor. Pentru mai multe informații, consultați Voce dial-peer. profil traducere de intrare 11Aplică profilul de translatare definit anterior pentru a elimina eticheta de rutare a apelurilor înainte de a trece la trunchiul de ieșire. șablon destinație BAD.BADEste necesar un model de destinație fictiv atunci când rutați apelurile de ieșire utilizând un grup dial-peer de intrare. Pentru mai multe informații, consultați modelul destinației (interfață). protocol sesiune sipv2Specifică faptul că acest dial-peer gestionează segmentele de apel SIP. Pentru mai multe informații, consultați protocolul de sesiune (dial peer). țintă sesiune 192.168.80.14Specifică adresa interfeței routerului local ca destinație a apelului în buclă inversă. Pentru mai multe informații, consultați țintă sesiune (coleg de apelare voip). legătură sursă-interfață de control GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru mesajele trimise prin buclă inversă. Pentru mai multe informații, consultați bind. legarea interfeței sursă media GigabitEthernet0/0/0Configurează interfața sursă și adresa IP asociată pentru conținutul media trimis prin buclă inversă. Pentru mai multe informații, consultați bind. dtmf- relay rtp- nteDefinește RTP-NTE (RFC2833) ca fiind capacitatea DTMF așteptată pe piciorul apelului. Pentru mai multe informații, consultați Releu DTMF (Voice over IP). codec g711alaw Forțează toate apelurile PSTN să utilizeze G.711. Selectați A-law sau u-law pentru a corespunde metodei de compandare utilizate de serviciul ISDN. nu vadDezactivează detectarea activității vocale. Pentru mai multe informații, consultați vad (dial peer). |
5 |
Adăugați următoarea configurație de rutare a apelurilor: Astfel, se încheie configurația gateway-ului local. Salvați configurația și reîncărcați platforma dacă aceasta este prima dată când sunt configurate caracteristici CUBE.
|
Configurația PSTN-Webex Calling din secțiunile anterioare poate fi modificată pentru a include trunchiuri suplimentare într-un cluster Cisco Unified Communications Manager (UCM). În acest caz, toate apelurile sunt rutate prin Unified CM. Apelurile de la UCM de la portul 5060 sunt rutate către PSTN, iar apelurile de la portul 5065 sunt rutate către Webex Calling. Se pot adăuga următoarele configurații incrementale pentru a include acest scenariu de apelare.
1 |
Configurați următoarele URL-uri de clasă de voce: |
2 |
Configurați următoarele înregistrări DNS pentru a specifica rutarea SRV către gazdele Unified CM: IOS XE utilizează aceste înregistrări pentru determinarea locală a gazdelor și porturilor UCM țintă. Cu această configurație, nu este necesar să configurați înregistrări în sistemul DNS. Dacă preferați să utilizați DNS, atunci aceste configurații locale nu sunt necesare. Iată o explicație a câmpurilor pentru configurație: Următoarea comandă creează o înregistrare a resursei DNS SRV. Creați o înregistrare pentru fiecare gazdă și trunchi UCM: gazdă ip _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nume înregistrare resursă SRV 2: Prioritatea de înregistrare a resurselor SRV 1: Ponderea înregistrată a resursei SRV 5060: Numărul portului care se va utiliza pentru gazda țintă în înregistrarea acestei resurse ucmsub5.mydomain.com: Gazda țintă pentru înregistrarea resursei Pentru a rezolva numele gazdelor țintă pentru înregistrarea resursei, creați înregistrări DNS A locale. De exemplu: gazdă ip ucmsub5.mydomain.com 192.168.80.65 Gazdă IP: Creează o înregistrare în baza de date locală IOS XE. ucmsub5.mydomain.com: Numele gazdei înregistrării A. 192.168.80.65: Adresa IP a gazdei. Creați înregistrările resurselor SRV și înregistrările A pentru a reflecta mediul UCM și strategia preferată de distribuire a apelurilor. |
3 |
Configurați următorii colegi de apelare: |
4 |
Adăugați rutarea apelurilor utilizând următoarele configurații: |
Semnăturile de diagnosticare (DS) detectează proactiv problemele observate frecvent în Gateway-ul local bazat pe Cisco IOS XE și generează notificări prin e-mail, syslog sau mesaje terminale ale evenimentului. De asemenea, puteți instala DS pentru a automatiza colectarea datelor de diagnosticare și pentru a transfera datele colectate în cazul Cisco TAC pentru a accelera timpul de rezoluție.
Semnăturile de diagnosticare (DS) sunt fișiere XML care conțin informații despre evenimentele și acțiunile de declanșare a problemei pentru a informa, depana și remedia problema. Utilizați mesaje syslog, snmp evenimente și prin monitorizarea periodică a ieșirilor specifice de comandă spectacol pentru a defini logica de detectare a problemelor. Tipurile de acțiuni includ:
-
Colectarea ieșirilor de comandă arată
-
Generarea unui fișier jurnal consolidat
-
Încărcarea fișierului într-o locație de rețea furnizată de utilizator, cum ar fi HTTPS, SCP, server FTP
Inginerii TAC autor fișiere DS și semnează digital pentru protecția integrității. Fiecare fișier DS are ID-ul numeric unic atribuit de sistem. Instrumentul de căutare a semnăturilor de diagnosticare (DSLT) este o singură sursă pentru găsirea semnăturilor aplicabile pentru monitorizarea și depanarea diferitelor probleme.
Înainte de a începe:
-
Nu editați fișierul DS pe care îl descărcați de la DSLT. Fișierele pe care le modificați nu reușesc instalarea din cauza erorii de verificare a integrității.
-
Un server Simple Mail Transfer Protocol (SMTP) de care aveți nevoie pentru ca Gateway-ul local să trimită notificări prin e-mail.
-
Asigurați-vă că Gateway-ul local execută IOS XE 17.6.1 sau o versiune ulterioară dacă doriți să utilizați serverul SMTP securizat pentru notificări prin e-mail.
Cerințe preliminare
Gateway local care rulează IOS XE 17.6.1 sau o versiune ulterioară
-
Semnăturile de diagnosticare sunt activate în mod implicit.
-
Configurați serverul de e-mail securizat pe care îl utilizați pentru a trimite notificări proactive dacă dispozitivul rulează IOS XE 17.6.1 sau o versiune ulterioară.
configurați serverul de e-mail terminal pentru apelare acasă :@ prioritatea 1 end securizat tls
-
Configurați variabila ds_email de mediu cu adresa de e-mail a administratorului pentru a vă notifica.
configurați terminalul de diagnosticare-semnătură LocalGateway(cfg-call-home-diag-sign)mediu ds_email sfârșit
Instalarea semnăturilor de diagnosticare pentru monitorizare proactivă
Monitorizarea utilizării ridicate a procesorului
Acest DS urmărește utilizarea procesorului de 5 secunde folosind SNMP OID 1.3.6.1.4.1.9.2.1.56. Când utilizarea ajunge la 75% sau mai mult, dezactivează toate depanările și dezinstalează toate semnăturile de diagnosticare pe care le instalați în Gateway-ul local. Urmați acești pași de mai jos pentru a instala semnătura.
-
Asigurați-vă că ați activat SNMP utilizând comanda arată snmp. Dacă SNMP nu este activat, configurați comanda snmp-server manager .
afișare snmp %agent SNMP neactivat config t snmp-server manager sfârșit afișare snmp Șasiu: intrare pachete SNMP ABCDEFGHIGK 149655 0 Erori de versiune Bad SNMP 1 Nume comunitate necunoscută 0 Operațiune ilegală pentru numele comunității furnizată 0 Eroare de codificare 37763 Număr de variabile solicitate 2 Număr de variabile modificate 34560 PDU-uri Get-request 138 PDU-uri Get-next 2 PDU-uri de setare a solicitării 0 picături pachet coadă de intrare (dimensiunea maximă a cozii 1000) 158277 pachete SNMP de ieșire 0 Erori prea mari (dimensiunea maximă a pachetului 1500) 20 Nu există astfel de erori de nume 0 Valori greșite 0 Erori generale 7998 PDU-uri de răspuns 10280 Pachete PDU-uri de urmărire în prezent în coada de intrare a procesului SNMP: 0 SNMP capcana globală: activate
Descărcați DS 64224 utilizând următoarele opțiuni verticale din Instrumentulde căutare semnături de diagnosticare:
copiați ftp://nume utilizator:password@/DS_64224.xml bootflash:
Nume câmp
Valoarea câmpului
Platformă
Software Cisco seria 4300, seria 4400 ISR sau Catalyst 8000V Edge
Produs
CUBE Enterprise în soluția Webex Calling
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail
-
Copiați fișierul DS XML în blițul Local Gateway.
copiați ftp://nume utilizator:password@/DS_64224.xml bootflash:
Următorul exemplu arată copierea fișierului de pe un server FTP pe Gateway-ul local.
copiați ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Se accesează ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 biți] 3571 biți copiați în 0,064 sec (55797 biți/sec)
-
Instalați fișierul DS XML în Gateway-ul local.
încărcare semnătură diagnostic-apel acasă DS_64224.xml Încărcare fișier DS_64224.xml cu succes
-
Utilizați comanda afișare semnătură de diagnosticare apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare trebuie să aibă o valoare "înregistrată".
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: username@gmail.com
Descarca DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-07 22:05:33
Când este declanșată, această semnătură dezinstalează toate DS-urile care rulează, inclusiv pe sine. Dacă este necesar, reinstalați DS 64224 pentru a continua monitorizarea utilizării ridicate a procesorului pe Gateway-ul local.
Monitorizarea deconectărilor anormale ale apelurilor
Acest DS utilizează sondajul SNMP la fiecare 10 minute pentru a detecta deconectarea anormală a apelurilor, cu erori SIP 403, 488 și 503. Dacă creșterea numărului de erori este mai mare sau egală cu 5 de la ultimul sondaj, se generează o notificare syslog și prin e-mail. Utilizați pașii de mai jos pentru a instala semnătura.
-
Asigurați-vă că SNMP este activat utilizând comanda arată snmp. Dacă SNMP nu este activat, configurați comanda snmp-server manager .
afișare snmp %agent SNMP neactivat config t snmp-server manager sfârșit afișare snmp Șasiu: intrare pachete SNMP ABCDEFGHIGK 149655 0 Erori de versiune Bad SNMP 1 Nume comunitate necunoscută 0 Operațiune ilegală pentru numele comunității furnizată 0 Eroare de codificare 37763 Număr de variabile solicitate 2 Număr de variabile modificate 34560 PDU-uri Get-request 138 PDU-uri Get-next 2 PDU-uri de setare a solicitării 0 picături pachet coadă de intrare (dimensiunea maximă a cozii 1000) 158277 pachete SNMP de ieșire 0 Erori prea mari (dimensiunea maximă a pachetului 1500) 20 Nu există astfel de erori de nume 0 Valori greșite 0 Erori generale 7998 PDU-uri de răspuns 10280 Pachete PDU-uri de urmărire în prezent în coada de intrare a procesului SNMP: 0 SNMP capcana globală: activate
-
Descărcați DS 65221 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Software Cisco seria 4300, seria 4400 ISR sau Catalyst 8000V Edge
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
SIP anormale apel deconectați de detectare cu e-mail și Syslog notificare.
-
Copiați fișierul DS XML în Gateway-ul local.
copiați ftp://nume utilizator:password@/DS_65221.xml bootflash:
-
Instalați fișierul DS XML în Gateway-ul local.
încărcare semnătură diagnostic-apel acasă DS_65221.xml Încărcare fișier DS_65221.xml cu succes
-
Utilizați comanda afișare semnătură diagnostic apel-acasă pentru a verifica dacă semnătura este instalată cu succes. Coloana de stare ar trebui să aibă o valoare „înregistrată”.
Instalați semnături de diagnosticare pentru a depana o problemă
De asemenea, puteți utiliza Semnături de diagnosticare (DS) pentru a rezolva rapid problemele. Cisco TAC ingineri au creat mai multe semnături care permit depanare necesare, care sunt necesare pentru a depana o anumită problemă, detecta apariția problemei, colecta dreptul de set de date de diagnosticare și transferul automat de date la cisco TAC caz. Acest lucru elimină necesitatea de a verifica manual apariția problemei și face rezolvarea problemelor intermitente și tranzitorii mult mai ușoară.
Puteți utiliza Instrumentul de căutare a semnăturilor de diagnosticare pentru a găsi semnăturile aplicabile și a le instala pentru a rezolva automat o anumită problemă sau puteți instala semnătura recomandată de inginerul TAC ca parte a angajamentului de asistență.
Iată un exemplu despre cum să găsiți și să instalați un DS pentru a detecta apariția "%VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0" syslog și automatizați colectarea datelor de diagnosticare utilizând următorii pași:
Configurați o altă variabilă de mediu DS ds_fsurl_prefix ca cale a serverului de fișiere Cisco TAC (cxd.cisco.com) pentru a încărca datele de diagnosticare. Numele de utilizator din calea fișierului este numărul de caz, iar parola este tokenul de încărcare a fișierului care poate fi preluat de la Managerul de cazuri de asistență , după cum se arată în continuare. Tokenul de încărcare a fișierului poate fi generat în secțiunea Atașamente din Managerul de cazuri de asistență, după cum este necesar.
configurați terminalul call-home diagnostic-semnătură LocalGateway(cfg-call-home-diag-sign) mediu ds_fsurl_prefix „scp://:@cxd.cisco.com” end
Exemplu:
apel-acasă diagnostic-semnătură mediu ds_fsurl_prefix " mediu ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Asigurați-vă că SNMP este activat utilizând comanda arată snmp. Dacă SNMP nu este activat, configurați comanda snmp-server manager .
afișare agent snmp %SNMP neactivat config t sfârșit manager snmp-server
-
Vă recomandăm să instalați monitorizarea înaltă a procesorului DS 64224 ca măsură proactivă pentru a dezactiva toate semnăturile de depanare și diagnosticare în timpul utilizării ridicate a procesorului. Descărcați DS 64224 utilizând următoarele opțiuni în Instrumentul de căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Software Cisco seria 4300, seria 4400 ISR sau Catalyst 8000V Edge
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Performanță
Tip de problemă
Utilizare ridicată a procesorului cu notificare prin e-mail.
-
Descărcați DS 65095 utilizând următoarele opțiuni în Instrumentulde căutare semnături de diagnosticare:
Nume câmp
Valoarea câmpului
Platformă
Software Cisco seria 4300, seria 4400 ISR sau Catalyst 8000V Edge
Produs
CUBE Enterprise în soluția de apelare Webex
Domeniul de aplicare al problemei
Syslogs
Tip de problemă
Syslog - %VOICE_IEC-3-GW: CCAPI: Eroare internă (prag de vârf al apelului): IEC=1.1.181.1.29.0
-
Copiați fișierele DS XML pe Gateway-ul local.
copiați fișierul ftp://nume utilizator:password@/DS_64224.xml bootflash: copiați ftp://nume utilizator:password@/DS_65095.xml bootflash:
-
Instalați monitorizarea ridicată a CPU DS 64224 și apoi fișierul XML DS 65095 pe gateway-ul local.
încărcare semnătură diagnostic-apel acasă DS_64224.xml Încărcare fișier DS_64224.xml succes apel-acasă diagnostic-semnătură DS_65095.xml Încărcare fișier DS_65095.xml succes
-
Verificați dacă semnătura este instalată cu succes utilizând afișarea semnăturiide diagnosticare la domiciliu a apelului. Coloana de stare ar trebui să aibă o valoare "înregistrată".
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DescarcaT DSes:
ID-ul DS
Numele DS
Revizie
Stare
Ultima actualizare (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Înscris
2020-11-08:00:07:45
65095
00:12:53
LGWIECC___all_spike_threshold
0.0.12
Înscris
2020-11-08:00:12:53
Verificarea executării semnăturilor de diagnosticare
În următoarea comandă, coloana "Stare" a comenzii afișează modificările semnăturii de diagnosticare la domiciliu apel la "rulare", în timp ce Gateway-ul local execută acțiunea definită în semnătură. Rezultatul statisticilor de diagnosticare a semnăturii de apel la domiciliu este cea mai bună modalitate de a verifica dacă o semnătură de diagnosticare detectează un eveniment de interes și a executat acțiunea. Coloana "Triggered/Max/Deinstall" indică de câte ori semnătura dată a declanșat un eveniment, numărul maxim de ori este definit pentru a detecta un eveniment și dacă semnătura se deinstalează după detectarea numărului maxim de evenimente declanșate.
afișați semnătura de diagnosticare-apel-acasă Setări actuale de semnătură de diagnosticare: Semnătură diagnosticare: Profil activat: CiscoTAC-1 (stare: ACTIV) Descărcare URL(uri): https://tools.cisco.com/its/service/oddce/services/DDCEService Variabilă mediu: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
DescarcaT DSes:
ID-ul DS |
Numele DS |
Revizie |
Stare |
Ultima actualizare (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Înscris |
2020-11-08 00:07:45 |
65095 |
LGWIECC___all_spike_threshold |
0.0.12 |
Rulare |
2020-11-08 00:12:53 |
afișarea statisticilor privind semnătura de diagnosticare a apelurilor la domiciliu
ID-ul DS |
Numele DS |
Declanșat/max/dezinstalare |
Timp mediu de rulare (secunde) |
Timp maxim de rulare (secunde) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
LGWIECC___all_spike_threshold |
1/20/Y |
23.053 |
23.053 |
E-mailul de notificare care este trimis în timpul executării semnăturii de diagnosticare conține informații cheie, cum ar fi tipul de problemă, detaliile dispozitivului, versiunea software, configurația care rulează și afișează ieșirile de comandă care sunt relevante pentru depanarea problemei date.
Dezinstalarea semnăturilor de diagnosticare
Utilizarea semnăturilor de diagnosticare în scopuri de depanare sunt de obicei definite pentru a dezinstala după detectarea unor apariții ale problemelor. Dacă doriți să dezinstalați manual o semnătură, regăsiți ID-ul DS de la ieșirea de afișare a semnăturii de diagnosticare la domiciliu a apelului și executați următoarea comandă:
dezinstalare semnătură diagnosticare-apel acasă
Exemplu:
dezinstalare semnătură diagnosticare acasă 64224
Semnăturile noi sunt adăugate periodic la Instrumentul de căutare a semnăturilor de diagnosticare, pe baza problemelor observate în implementări. TAC în prezent nu acceptă solicitările de creare de noi semnături particularizate.
Implementați disponibilitatea ridicată a CUBE ca gateway local
Fundamentele
Cerințe preliminare
Înainte de a implementa CUBE HA ca gateway local pentru apelarea Webex, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
-
Redundanță box-to-box de la nivelul 2 cu CUBE Enterprise pentru conservarea apelurilor impunătoare
Liniile directoare de configurare furnizate în acest articol presupune o platformă gateway local dedicat cu nici o configurație de voce existente. Dacă o implementare existentă CUBE enterprise este modificată pentru a utiliza, de asemenea, funcția gateway local pentru Cisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri și funcționalitățile existente nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită IOS-XE versiunea 16.12.2 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și LGW.
Comenzile arată și jurnalele din acest articol se bazează pe lansarea software-ul minim de Cisco IOS-XE 16.12.2 puse în aplicare pe un vCUBE (CSR1000v).
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diverse platforme:
-
Seria ISR 4K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
RSC 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Arhitectura preferată Cisco pentru Apelarea Cisco Webex— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Prezentare generală a soluției de apelare Webex
Cisco Webex Calling este o ofertă de colaborare care oferă o alternativă bazată pe cloud cu mai multe entități găzduite la serviciul de telefonie PBX local, cu mai multe opțiuni PSTN pentru clienți.
Implementarea Local Gateway (reprezentată mai jos) este punctul central al acestui articol. Portbagajul gateway-ului local (PSTN bazat pe premise) din Webex Calling permite conectivitatea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare IP PBX locală, cum ar fi Cisco Unified CM. Toate comunicațiile către și de la cloud sunt securizate utilizând tls transport pentru SIP și SRTP pentru mass-media.
Figura de mai jos afișează o implementare Webex Calling fără niciun PBX IP existent și se aplică unei implementări unice sau multi-site. Configurația descrisă în acest articol se bazează pe această implementare.
Redundanță de la cutie la nivel 2
Redundanța box-to-box CUBE HA layer 2 utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche activă/standby de routere. Această pereche partajează aceeași adresă IP virtuală (VIP) în interfețele lor respective și schimbă continuu mesajele de stare. Cube informații sesiune este check-pointed peste perechea de routere care să permită router standby pentru a lua toate responsabilitățile CUBE apel de procesare peste imediat în cazul în care router-ul activ iese din serviciu, rezultând în păstrarea statuos de semnalizare și mass-media.
Indicația de verificare este limitată la apelurile conectate cu pachete media. Apelurile în tranzit nu sunt marcate (de exemplu, o stare de încercare sau de apel).
În acest articol, CUBE HA se va referi la cube high availability (HA) Layer 2 Box-to-box (B2B) redundanță pentru conservarea apelurilor impunătoare
Începând cu IOS-XE 16.12.2, CUBE HA poate fi implementat ca gateway local pentru implementările trunchiului de apelare Cisco Webex (PSTN bazat pe premise) și vom acoperi considerațiile și configurațiile de proiectare din acest articol. Această cifră afișează o configurare tipică CUBE HA ca Gateway local pentru o implementare a trunchiului Cisco Webex Calling.
Componenta infra a grupului de redundanță
Componenta Infra a grupului de redundanță (RG) oferă suportul pentru infrastructura de comunicații box-to-box între cele două CUBEs și negociază starea finală de redundanță stabilă. Această componentă oferă, de asemenea:
-
Un protocol de tip HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și salut între cele două CUBEs (prin interfața de control) - GigabitEthernet3 în figura de mai sus.
-
Un mecanism de transport pentru punctarea semnalizării și a stării media pentru fiecare apel de la routerul activ la cel standby (prin interfața de date) — GigabitEthernet3 în figura de mai sus.
-
Configurarea și gestionarea interfeței IP virtual (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) – GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie să fie configurat special pentru a accepta voce B2B HA.
Gestionarea adreselor IP virtual (VIP) atât pentru semnalizare, cât și pentru mass-media
B2B HA se bazează pe VIP pentru a obține redundanță. Vip-ul și interfețele fizice asociate pe ambele CUBEs din perechea CUBE HA trebuie să se afle pe aceeași subrețea LAN. Configurarea VIP-ului și legarea interfeței VIP la o anumită aplicație de voce (SIP) sunt obligatorii pentru suportul vocal B2B HA. Dispozitivele externe, cum ar fi Unified CM, Webex Calling access SBC, furnizorul de servicii sau proxy-ul, utilizează VIP ca adresă IP de destinație pentru apelurile care traversează routerele CUBE HA. Prin urmare, din punct de vedere webex Calling, perechile CUBE HA acționează ca un singur gateway local.
Informațiile despre semnalizarea apelurilor și sesiunea RTP a apelurilor stabilite sunt punctate de la routerul activ la routerul standby. Când routerul activ coboară, routerul Standby preia controlul și continuă să redirecționeze fluxul RTP care a fost anterior direcționat de primul router.
Apelurile într-o stare tranzitorie în momentul nereușitei nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt încă pe deplin stabilite sau sunt în curs de a fi modificate cu o funcție de transfer sau reținere. Apelurile stabilite pot fi deconectate după comutare.
Există următoarele cerințe pentru utilizarea CUBE HA ca gateway local pentru reluarea impunătoare a apelurilor:
-
CUBE HA nu poate avea TDM sau interfețe analogice co-localizate
-
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP / RTP), iar Gig3 este redundanță Grup (RG) Control / interfață de date
-
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu de nivel 2, unul cu id-ul grupului 1 și celălalt cu id-ul grupului 2. Dacă configurați 2 perechi HA cu același ID de grup, interfețele RG Control/Data trebuie să aparțină unor domenii de nivel 2 diferite (vlan, comutator separat)
-
Canalul de port este acceptat atât pentru interfețele de control/date RG, cât și pentru interfețele de trafic
-
Toate de semnalizare / mass-media este provenind de la / la adresa IP virtuală
-
Ori de câte ori o platformă este reîncărcată într-o relație CUBE-HA, aceasta pornește întotdeauna ca Standby
-
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
-
Identificatorul interfeței de redundanță, rii ar trebui să fie unic pentru o combinație pereche/interfață pe același Strat 2
-
Configurația pe ambele CUBEs trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
-
Interfețe loopback nu pot fi utilizate ca se leagă, deoarece acestea sunt întotdeauna în sus
-
Interfețele cu trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea urmăririi interfeței
-
CUBE-HA nu este acceptat printr-o conexiune prin cablu crossover pentru RG-control/link-ul de date (Gig3)
-
Ambele platforme trebuie să fie identice și să fie conectate printr-un switch fizic între toate interfețele de referință pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
-
Nu poate avea WAN reziliat pe cubes direct sau de date HA pe fiecare parte
-
Ambele Active/Standby trebuie să fie în același centru de date
-
Este obligatorie utilizarea interfeței L3 separate pentru redundanță (RG Control/data, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea ha și punctul de control
-
În caz de nereușită, CUBE-ul activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mass-media
Configurarea redundanței pe ambele CUB-uri
Trebuie să configurați redundanța box-to-box de la nivelul 2 la ambele CUBEs destinate a fi utilizate într-o pereche HA pentru a aduce IP-uri virtuale.
1 |
Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței de trafic de voce, astfel încât ruta activă va avea un rol destul de activ după ce interfața de trafic este în jos. | ||
2 |
Configurați un RG pentru utilizare cu VoIP HA sub-modul de redundanță a aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
3 |
Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG de la pasul anterior în
redundanță-grup 1—Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să intre în vigoare. Vom reîncărca platformele după ce s-a aplicat toată configurația. | ||
4 |
Configurați interfețele Gig1 și Gig2 cu IP-urile lor virtuale respective, așa cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
5 |
Salvați configurația primului CUBE și reîncărcați-l. Platforma pentru a reîncărca ultima este întotdeauna standby.
După ce VCUBE-1 pornește complet, salvați configurația VCUBE-2 și reîncărcați-o.
| ||
6 |
Verificați că configurația box-to-box funcționează așa cum vă așteptați. Rezultatele relevante sunt evidențiate cu caractere aldine. Am reîncărcat VCUBE-2 ultima și ca pe considerente de proiectare; platforma pentru a reîncărca ultima va fi întotdeauna standby. |
Configurarea unui gateway local pe ambele CUB-uri
În configurația noastră exemplu, folosim următoarele informații trunchi din Control Hub pentru a construi configurația Local Gateway pe ambele platforme, VCUBE-1 și VCUBE-2. Numele de utilizator și parola pentru această configurare sunt după cum urmează:
-
Nume utilizator: Hussain1076LGU_
-
Parolă: lOV12MEaZx
1 |
Asigurați-vă că este creată o cheie de configurare pentru parolă, cu comenzile afișate mai jos, înainte de a putea fi utilizată în acreditări sau secrete partajate. Parolele de tip 6 sunt criptate folosind cifrul AES și această cheie de configurare definită de utilizator.
Iată configurația Local Gateway care se va aplica ambelor platforme pe baza parametrilor Control Hub afișați mai sus, salvați și reîncărcați. Datele de autentificare SIP Digest din Control Hub sunt evidențiate în mod îndrăzneț.
Pentru a afișa ieșirea comenzii de afișare, am reîncărcat VCUBE-2 urmat de VCUBE-1, făcând din VCUBE-1 CUBUL standby și VCUBE-2 CUBUL activ |
2 |
În orice moment, o singură platformă va menține o înregistrare activă ca Gateway local cu SBC-ul de acces webex Calling. Aruncați o privire la ieșirea următoarelor comenzi de afișare. prezintă grupul de cereri de redundanță 1 afișați starea înregistrării sip-ua
Din ieșirea de mai sus, puteți vedea că VCUBE- 2 este LGW-ul activ care menține înregistrarea cu acces Webex Calling SBC, în timp ce ieșirea „afișează starea de înregistrare sip-ua” este necompletată în VCUBE-1 |
3 |
Acum activați următoarele depanări pe VCUBE-1
|
4 |
Simulați reluarea prin emiterea următoarei comenzi pe LGW activ, VCUBE-2 în acest caz.
Trecerea de la ACTIVE la STANDBY LGW are loc în următorul scenariu, precum și în afară de CLI enumerate mai sus
|
5 |
Verificați dacă VCUBE-1 s-a înregistrat cu Webex Calling access SBC. VCUBE-2 ar fi reîncărcat până acum.
VCUBE-1 este acum LGW activ. |
6 |
Uitați-vă la jurnalul de depanare relevant pe VCUBE-1 trimițând un REGISTRU SIP la Webex Apelând prin IP-ul virtual și primind un OK 200.
|
Configurați Unified CM pentru Webex Calling
Configurarea SIP Trunk profil de securitate pentru Trunk la Local Gateway
În cazurile în care Local Gateway și PSTN gateway se află pe același dispozitiv, Unified CM trebuie să fie activat pentru a diferenția între două tipuri diferite de trafic (apeluri de la Webex și de la PSTN) care provin de pe același dispozitiv și pentru a aplica o clasă diferențiată de servicii acestor tipuri de apeluri. Acest tratament de apel diferențiat se realizează prin asigurarea a două trunchiuri între Unified CM și gateway-ul local combinat și pstn gateway dispozitiv care necesită porturi diferite de ascultare SIP pentru cele două trunchiuri.
Creați un profil de securitate dedicat SIP Trunk pentru trunchiul Local Gateway cu următoarele setări:
|
Configurarea profilului SIP pentru trunchiul gateway-ului local
Creați un profil SIP dedicat pentru trunchiul Local Gateway cu următoarele setări:
|
Crearea unui spațiu de căutare a apelurilor pentru apelurile de la Webex
Creați un spațiu de căutare a apelurilor pentru apelurile care provin de la Webex cu următoarele setări:
Ultima partiție onNetRemote este utilizată numai într-un mediu multi-cluster în care informațiile de rutare sunt schimbate între clustere CM unificate utilizând Intercluster Lookup Service (ILS) sau Global Dialplan Replication (GDPR). |
Configurarea unui trunchi SIP către și de la Webex
Creați un trunchi SIP pentru apelurile către și de la Webex prin Gateway-ul local cu următoarele setări:
|
Configurarea Grupului de rute pentru Webex
Creați un grup de rute cu următoarele setări:
|
Configurarea listei de rute pentru Webex
Creați o listă de rute cu următoarele setări:
|
Crearea unei partiții pentru destinații webex
Creați o partiție pentru destinațiile Webex cu următoarele setări:
|
Ce trebuie să faceți în continuare
Asigurați-vă că adăugați această partiție la toate spațiile de căutare apelante care ar trebui să aibă acces la destinații webex. Trebuie să adăugați această partiție în mod specific la spațiul de căutare apelant care este utilizat ca spațiu de căutare de apelare la intrare pe trunchiurile PSTN, astfel încât apelurile de la PSTN la Webex să poată fi direcționate.
Configurarea modelelor de rute pentru destinațiile Webex
Configurați modelele de rute pentru fiecare interval DID de pe Webex cu următoarele setări:
|
Configurarea normalizării abreviate a apelării intersite pentru Webex
Dacă webex este necesară apelarea prescurtată între site-uri, configurați modelele de normalizare a apelului pentru fiecare interval ESN de pe Webex cu următoarele setări:
|
Configurați funcțiile dvs. Webex Calling
Configurarea unui grup de vânătoare
Grupurile de vânătoare direcționează apelurile primite către un grup de utilizatori sau spații de lucru. Puteți configura chiar și un model pentru a ruta la un grup întreg.
Pentru mai multe informații despre cum să configurați un grup de vânătoare, consultați Grupuri de vânătoare în Cisco Webex Control Hub.
Crearea unei cozi de apel
Puteți configura o coadă de apeluri, astfel încât, atunci când apelurile clienților nu pot fi răspunse, să li se ofere un răspuns automat, mesaje de confort și muzică în așteptare până când cineva poate răspunde la apel.
Pentru mai multe informații despre cum să configurați și să gestionați o coadă de apel, consultați Gestionarea cozilor de apeluri în Cisco Webex Control Hub.
Crearea unui client recepționer
Ajutați-vă să susțineți nevoile personalului din front-office. Puteți configura utilizatorii ca însoțitori de telefon, astfel încât să poată filtra apelurile primite către anumite persoane din cadrul organizației dvs.
Pentru informații despre cum să configurați și să vizualizați clienții recepționer, consultați Clienții recepționer din Cisco Webex Control Hub.
Crearea și gestionarea operatorilor automați
Puteți să adăugați felicitări, să configurați meniuri și să direcționați apelurile către un serviciu de răspuns, un grup de vânătoare, o casetă de mesagerie vocală sau o persoană reală. Creează un program de 24 de ore sau oferă opțiuni diferite atunci când afacerea ta este deschisă sau închisă.
Pentru informații despre cum să creați și să gestionați operatorii automați, consultați Gestionarea operatorilor automați în Cisco Webex Control Hub.
Configurarea unui grup de paginare
Paginarea în grup permite unui utilizator să plaseze o pagină de apel sau de grup unidirecțională la până la 75 de utilizatori și spații de lucru țintă, formând un număr sau o extensie atribuită unui anumit grup de paginare.
Pentru informații despre configurarea și editarea grupurilor de paginare, consultați Configurarea unui grup de paginare în Cisco Webex Control Hub.
Configurarea preluării apelurilor
Îmbunătățiți munca în echipă și colaborarea prin crearea unui grup de preluare a apelurilor, astfel încât utilizatorii să poată răspunde reciproc la apeluri. Când adăugați utilizatori la un grup de preluare a apelurilor și un membru al grupului este plecat sau ocupat, un alt membru poate răspunde la apelurile lor.
Pentru informații despre cum să configurați un grup de preluare a apelurilor, consultați Preluarea apelurilor în Cisco Webex Control Hub.
Configurarea parcului de apeluri
Call park permite unui grup definit de utilizatori să parcheze apelurile împotriva altor membri disponibili ai unui grup de call park. Apelurile parcate pot fi preluate de alți membri ai grupului pe telefonul lor.
Pentru mai multe informații despre cum să configurați parcul de apeluri, consultați Call Park în Cisco Webex Control Hub.
Activați barge-in pentru utilizatori
1 |
Din vizualizarea clientului din https://admin.webex.com, accesați . |
2 |
Selectați un utilizator și faceți clic pe Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizator i , apoi selectați Barge. |
4 |
Activați comutatorul pentru a permite altor utilizatori să se adauge la apelul în curs al acestui utilizator. |
5 |
Verificați Redați un ton atunci când acest utilizator intră într-un ape l dacă doriți să redați un ton altor persoane atunci când acest utilizator intră în apel. Setarea Redați un ton când acest utilizator intră Inopinat într-un apel nu se aplică funcționalității de apelare inopinată a supervizorului Customer Experience Basic și Essentials. Chiar dacă activați această opțiune pentru un supervizor, sistemul nu redă tonul de notificare către agent atunci când un supervizor intră inopinat în apelul din coada de apeluri. Dacă doriți să redați un ton unui agent atunci când un supraveghetor intră în apel, îl puteți activa prin setările „Ton de notificare pentru agenți”. Pentru mai multe informații, consultați secțiunea Creare coad ă din Webex Customer Experience Basi c sau Webex Customer Experience Essentials. |
6 |
Faceți clic pe Salvați. |
Activați confidențialitatea pentru un utilizator
1 |
Conectați-vă la Control Hub și accesați . |
2 |
Alegeți un utilizator și faceți clic pe Apelare. |
3 |
Accesați zona Permisiuni între utilizator i și apoi alegeți Confidențialitate. |
4 |
Alegeți setările de confidențialitate ale Operatorului automat corespunzătoare pentru acest utilizator.
|
5 |
Bifați caseta de selectare Activare confidențialitate . Apoi, puteți decide să blocați pe toată lumea, nealegând membri din lista derulantă. Alternativ, puteți alege utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei acestui utilizator. Dacă sunteți administrator de locație, în lista derulantă apar numai utilizatorii, spațiile de lucru și liniile virtuale care aparțin locațiilor alocate. Debifați caseta de selectare Activare confidențialitat e pentru a permite tuturor să monitorizeze starea liniei. |
6 |
Verificați Confidențialitatea impunerii pentru preluarea apelurilor direcționate și caseta de selectar e pentru înscriere pentru a activa confidențialitatea pentru preluarea apelurilor direcționate și înscriere.
|
7 |
Din Adăugați membru după nume, alegeți utilizatorii, spațiile de lucru și liniile virtuale care pot monitoriza starea liniei telefonice și pot invoca preluarea apelurilor direcționate și intrarea în rețea. |
8 |
Pentru a filtra membrii pe care îi selectați, utilizați filtrul după nume, număr sa u câmp text. |
9 |
Faceți clic pe Eliminare toat e pentru a elimina toți membrii selectați. Pentru a elimina un membru individual, faceți clic pe Ștergere lângă numele membrului. |
10 |
Faceți clic pe Salvați. |
Configurați monitorizarea
Numărul maxim de linii monitorizate pentru un utilizator este de 50. Cu toate acestea, în timp ce configurați lista de monitorizare, luați în considerare numărul de mesaje care afectează lățimea de bandă dintre Webex Calling și rețeaua dvs. De asemenea, determinați liniile maxime monitorizate de numărul de butoane de linie de pe telefonul utilizatorului.
1 |
Din vizualizarea clientului din https://admin.webex.com , accesați Management și apoi faceți clic pe Utilizatori. |
2 |
Selectați utilizatorul pe care doriți să-l modificați și faceți clic pe Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizator i și selectați Monitorizare. |
4 |
Alegeți dintre următoarele:
Puteți include o linie virtuală în lista Adăugare linie monitorizat ă pentru monitorizarea utilizatorului. |
5 |
Alegeți dacă doriți să notificați acest utilizator despre apelurile parcate, căutați persoana sau extensia de parcare a apelurilor care urmează să fie monitorizată, apoi faceți clic pe Salvare. Lista de linii monitorizate din Control Hub corespunde ordinii liniilor monitorizate care se afișează pe dispozitivul utilizatorului. Puteți reordona lista liniilor monitorizate în orice moment. Numele care apare pentru linia monitorizată este numele introdus în câmpurile Nume și prenume ID apelant pentru utilizator, spațiu de lucru și linie virtuală. |
Activați tonul de avertizare prin punte de apel pentru utilizatori
Înainte de a începe
1 |
Conectați-vă la Control Hub și accesați . |
2 |
Selectați un utilizator și faceți clic pe fila Apelare. |
3 |
Accesați Permisiuni între utilizatori și faceți clic pe Call Bridging Warning Tone. |
4 |
Activați funcția Call Bridging Warning Tone, apoi faceți clic pe Save. În mod implicit, această funcție este activată. Pentru mai multe informații despre conectarea la apel pe o linie MPP partajată, consultați liniile partajate de pe telefonul dvs. de birou pe mai multe platforme. Pentru mai multe informații despre conectarea apelurilor pe o linie partajată a aplicației Webex, consultați aspectul liniei partajate pentru WebexApp. |
Activarea hoteling-ului pentru un utilizator
1 |
Din vizualizarea clientului din https://admin.webex.com , accesați Management și selectați Utilizatori. |
2 |
Selectați un utilizator și faceți clic pe fila Apelare. |
3 |
Accesați secțiunea Permisiuni între utilizator i și selectați Hotelin g și activați comutatorul. |
4 |
Introduceți numele sau numărul gazdei hotelului în câmpul de căutare Hotel Locatio n și alegeți gazda hotelului pe care doriți să o alocați utilizatorului. Se poate selecta doar o singură gazdă hotelieră. Dacă alegeți o altă gazdă hotelieră, prima este ștearsă. Dacă sunteți administrator de locație, puteți aloca numai gazda de închiriere care aparține locațiilor alocate. |
5 |
Pentru a limita timpul în care un utilizator poate fi asociat cu gazda hotelului, alegeți numărul de ore pe care utilizatorul le poate utiliza gazda hotelului din lista derulantă Limit Association Perio d . Utilizatorul se va deconecta automat după ora aleasă. În ecran este afișat un mesaj de eroare dacă perioada limită de asociere specificată pentru utilizator depășește perioada limită de asociere a gazdei alese pentru hotel. De exemplu, dacă gazda de închiriere are o perioadă de asociere limită de 12 ore, iar perioada de asociere limită a utilizatorului este de 24 de ore, se afișează un mesaj de eroare. În astfel de cazuri, trebuie să extindeți perioada de asociere limită a gazdei hotelului dacă este nevoie de mai mult timp pentru utilizator. |
6 |
Faceți clic pe Salvați. De asemenea, un utilizator poate căuta și localiza gazda de hotel pe care dorește să o utilizeze din Hubul utilizatorului. Pentru mai multe informații, consultați Accesați profilul de apelare de oriunde. |
Tendințe de adoptare și rapoarte de utilizare pentru Webex Calling
Vizualizați rapoartele de apelare
Puteți utiliza pagina Analytics din Control Hub pentru a obține informații despre modul în care utilizatorii utilizează apelarea Webex și aplicația Webex (interacțiune), precum și prepelița experienței lor media de apel. Pentru a accesa analizele Webex Calling, conectați-vă la Control Hub, apoi accesați Analytic s și selectați fila Apelar e .
1 |
Pentru rapoarte detaliate privind istoricul apelurilor, conectați-vă la Control Hub, apoi accesați . |
2 |
Selectați istoricul detaliat al apelurilor. Pentru informații despre apelurile care utilizează instanță dedicată, consultați Analiza instanțelor dedicate. |
3 |
Pentru a accesa date de calitate media, conectați-vă la Control Hub, apoi accesați Statistic i și apoi selectați Apelare. Pentru mai multe informații, consultați Analytics pentru portofoliul de colaborare în cloud.
|
Rulați instrumentul CScan
CScan este un instrument de pregătire a rețelei conceput pentru a testa conexiunea la rețea la Apelarea Webex.
Pentru mai multe informații, consultați Utilizarea CScan pentru a testa calitatearețelei de apelare Webex. |