System Engineer
gabriel.dumitru@alef.com
Cisco Webex Calling este serviciul de telefonie în cloud (UCaaS) din suita Webex, gestionat centralizat din Control Hub. Migrarea către cloud rareori se face într-un singur pas: multe organizații au deja contracte active cu un operator de telefonie, numere alocate, trunchiuri SIP sau circuite ISDN PRI, plus o centrală locală (de exemplu Cisco Unified Communications Manager).
Local Gateway (LGW) este componenta care rezolvă această situație. Potrivit documentației Cisco, Local Gateway îți permite să migrezi către Webex Calling în ritmul tău, integrând infrastructura locală existentă cu Webex Calling și păstrând conexiunea PSTN actuală. În practică, LGW este un Session Border Controller (SBC) plasat în rețeaua ta, care face legătura între trei medii: provider-ul de telefonie (PSTN), cloud-ul Webex Calling și, opțional, centrala locală.
În Control Hub, opțiunea poartă numele de Premises-based PSTN (Local Gateway). Alegerea modelului PSTN se face la nivel de locație, iar fiecare locație poate avea o singură opțiune PSTN: fie Cloud Connected PSTN, fie Premises-based PSTN.
Fluxul arată astfel:
Arhitectura Local Gateway · PSTN, CUBE, Webex Calling, CUCM opțional
Principii de bază, conform documentației Cisco:
Cisco oferă două modele de trunchi între LGW și Webex Calling. Funcționalitatea este similară, dar diferă scalarea și dispozitivele suportate.
|
Criteriu |
Registration-based |
Certificate-based |
|
Apeluri simultane |
Până la 250 per trunchi |
Peste 250 per trunchi |
|
Dispozitive |
Doar Cisco CUBE |
CUBE și SBC-uri terțe validate (Oracle, AudioCodes, Ribbon, anynode, Italtel) |
|
Autentificare |
Digest (utilizator și parolă partajate) |
Certificat, cu verificarea FQDN-ului LGW |
|
Rețea / NAT |
Orice NAT sau IP public; NAT dinamic este preferat |
IP public sau NAT static, accesibil din internet |
|
DNS public |
Nu necesită configurări speciale |
Domeniu revendicat în Control Hub; înregistrare A sau SRV publică |
|
Certificate |
Bundle-ul CA Cisco încărcat pe LGW |
Certificat semnat de un CA public suportat; fără wildcard |
|
Validare din Control Hub |
Da (gateway gestionat) |
Nu |
Pentru dimensionare, Cisco indică orientativ: până la 250 de apeluri simultane (aprox. 2.500 de utilizatori) cu trunchi registration-based; între 250 și 2.000 de apeluri (aprox. 20.000 de utilizatori) cu trunchi certificate-based, inclusiv peste internet (OTT); iar pentru 2.000–6.500 de apeluri se recomandă certificate-based cu conectivitate dedicată (interconnect). Pentru calitatea apelurilor, conexiunea dintre LGW și Webex Calling ar trebui să respecte: latență unidirecțională de maximum 100 ms, jitter de maximum 10 ms și pierderi de pachete de maximum 0,5%.
Înainte de a începe configurarea:
O companie cu sediul central la București și două filiale are aproximativ 180 de utilizatori, un trunchi SIP la un operator local de telefonie și numere DID existente. Compania vrea să treacă la Webex Calling fără să renunțe la numere și fără să schimbe contractul cu operatorul, iar un vârf de trafic de aproximativ 60–80 de apeluri simultane.
Decizie de design: Cisco CUBE ca Local Gateway, cu trunchi registration-based (capacitatea este sub limita de 250 de apeluri, iar configurarea este mai simplă, inclusiv în spatele unui NAT dinamic). Apelurile din PSTN sunt rutate către Webex Calling, iar apelurile utilizatorilor Webex pleacă spre operator prin același gateway. Dacă mai târziu compania depășește 250 de apeluri sau vrea un SBC terț, poate trece la modelul certificate-based.
Dacă un gateway deservește mai multe trunchiuri (de exemplu în modelul partner-hosted), Cisco impune un FQDN unic pentru fiecare trunchi și recomandă o combinație unică de IP și port pentru fiecare conexiune, deoarece partajarea acestora poate afecta capacitatea apelurilor.
Exemplu simplificat, cu valori de substituit de tine (interfețe, parole, adrese):
! Interfața dinspre PSTN și/sau CUCM interface GigabitEthernet0/0/0 description Spre PSTN / CUCM ip address! ! Interfața dinspre Webex Calling interface GigabitEthernet0/0/1 description Spre Webex Calling ip address ! ! Criptarea credențialelor stocate pe router key config-key password-encrypt password encryption aes ! ! Trustpoint de rezervă (la trunchiul registration-based nu necesită certificat) crypto pki trustpoint EmptyTP revocation-check none ! ! TLS 1.2 exclusiv sip-ua timers connection establish tls 5 transport tcp tls v1.2 crypto signaling default trustpoint EmptyTP cn-san-validate server tcp-retry 1000 ! ! Importul bundle-ului CA Cisco ip http client source-interface GigabitEthernet0/0/1 crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Apoi se activează funcțiile CUBE la nivel global:
voice service voip ip address trusted list ipv4ipv4 mode border-element allow-connections sip to sip no supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 sip asymmetric payload full early-offer forced
Ce face fiecare element important:
Pentru codec și criptarea media:
voice class codec 100 codec preference 1 g711ulaw codec preference 2 g711alaw ! voice class stun-usage 100 stun usage firewall-traversal flowdata stun usage ice lite ! voice class srtp-crypto 100 crypto 1 AES_CM_128_HMAC_SHA1_80
Rețineți: Webex Calling suportă doar suita AES_CM_128_HMAC_SHA1_80 pentru SRTP, iar ICE-Lite permite optimizarea căii media oriunde este posibil (nu și când apelul necesită servicii media din cloud, cum ar fi înregistrarea).
Pentru trunchiul registration-based, configurația se grupează într-un voice class tenant, iar dial-peer-ul moștenește setările acestuia. Structura (cu valori din Control Hub ca substituenți):
voice class uri 100 sip pattern dtg= ! voice class tenant 100 registrar dns: scheme sips expires 240 refresh-ratio 50 tcp tls credentials number username password 0 realm BroadWorks authentication username password 0 realm BroadWorks authentication username password 0 realm no remote-party-id sip-server dns: connection-reuse srtp-crypto 100 session transport tcp tls no session refresh url sips error-passthru rel1xx disable asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 sip-profiles 100 outbound-proxy dns: privacy-policy passthru ! dial-peer voice 100 voip description Inbound/Outbound Webex Calling max-conn 250 destination-pattern BAD.BAD session protocol sipv2 session target sip-server incoming uri request 100 voice-class codec 100 dtmf-relay rtp-nte voice-class stun-usage 100 no voice-class sip localhost voice-class sip tenant 100 srtp no vad
Puncte de atenție:
La trunchiul certificate-based se schimbă în special partea de identitate și de certificate:
Aceasta este partea care păstrează conexiunea existentă cu operatorul. Există două scenarii.
Se definesc un voice class uri pentru identificarea apelurilor venite de la provider și un dial-peer dedicat:
voice class uri 200 sip host ipv4:! dial-peer voice 200 voip description Inbound/Outbound IP PSTN trunk destination-pattern BAD.BAD session protocol sipv2 session target ipv4: incoming uri via 200 voice-class sip asserted-id pai voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad
Rutarea între cele două trunchiuri se face cu dial-peer groups:
voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 200 description Route calls to PSTN dial-peer 200 ! dial-peer voice 100 destination dpg 200 ! apeluri din Webex către PSTN dial-peer voice 200 destination dpg 100 ! apeluri din PSTN către Webex
Dacă provider-ul oferă un trunchi securizat, configurația poate urma același model ca la trunchiul spre Webex, deoarece CUBE suportă rutarea apelurilor securizate.
Pentru circuite ISDN se configurează controller-ul E1/T1 și un dial-peer POTS pe portul de voce. Dacă vrei optimizarea media prin ICE pe partea Webex, Cisco recomandă un design cu două segmente de apel (loop-back): dial-peer-uri VoIP interne între trunchiul Webex și cel PSTN, cu etichete de rutare adăugate și eliminate prin reguli de traducere (voice translation-rule). Dacă nu ai nevoie de optimizarea căii media, folosești direct un dial-peer POTS în locul celui VoIP de PSTN.
Varianta TDM · loop-back între PRI și Webex Calling
La un apel din PSTN, dial-peer-ul POTS adaugă eticheta A1A, apelul parcurge bucla internă (dial-peer 10) și revine prin dial-peer 11, care scoate eticheta înainte de trunchiul Webex. În sens invers, eticheta A2A ghidează apelul prin dial-peer 12 spre circuitul PRI. Cele două segmente IP permit optimizarea media cu ICE.
În ambele scenarii, atenția la formatul numerelor este critică: apelurile dinspre Webex Calling sosesc de regulă în format +E.164 (de exemplu +40…), iar provider-ul sau circuitul ISDN poate aștepta un format național sau un prefix de acces. Translațiile se ajustează la planul de numerotație al operatorului.
Dacă organizația are deja CUCM, LGW poate deveni punctul central de rutare:
Astfel, apelurile interne între utilizatorii on-premises și cei din cloud, precum și ieșirea în PSTN, rămân sub o politică de rutare unitară pe durata migrării.
Status în Control Hub. La Services > PSTN & Routing > Gateway configurations > Trunk > Trunk Info vezi starea trunchiului: Online (conexiune reușită cu toate proxy-urile edge Webex), Offline, Impaired (cel puțin un proxy edge nu se conectează) sau Unknown (conexiune în curs de stabilire pentru un gateway recent adăugat). Poți configura și alerte pentru trunchiuri în Alerts center.
Gateway gestionat. Pentru trunchiurile registration-based, Cisco recomandă înrolarea gateway-ului IOS XE în Control Hub. Astfel poți folosi opțiunea de validare a configurației, care identifică erori de configurare. Funcționalitatea nu este disponibilă pentru trunchiurile certificate-based.
Diagnostic Signatures (DS). La gateway-urile registration-based, fișierele DS semnate de Cisco TAC pot detecta probleme frecvente și pot notifica prin e-mail sau syslog. Exemple documentate: monitorizarea utilizării ridicate a CPU (prag de 75%), a dezînregistrării trunchiului SIP (verificare la fiecare 60 de secunde) și a deconectărilor anormale de apel cu erori SIP 403, 488 și 503. Semnăturile se descarcă din Diagnostic Signatures Lookup Tool, se copiază în bootflash și se încarcă cu call-home diagnostic-signature load.
Probleme TLS. Dacă handshake-ul TLS eșuează după reînnoirea unui certificat, verifică dacă SBC-ul impune validarea extensiei Client Authentication EKU. Webex Calling nu o impune, dar unele SBC-uri terțe o pot cere.
Pentru medii critice, Cisco documentează implementarea CUBE High Availability ca Local Gateway, cu perechi active/standby și failover cu păstrarea stării apelurilor active. Configurarea implică redundanță de nivel 2 „box-to-box” pe ambele CUBE-uri, grupuri de redundanță a aplicației și IP-uri virtuale. La fiecare gateway, Webex atribuie două puncte media (Media PoP) geografic separate din aceeași regiune, prin înregistrări DNS SRV, pentru redundanță la nivelul cloud-ului.
Varianta HA: pereche CUBE active/standby
Varianta HA · pereche CUBE active/standby ca Local Gateway
Cele două CUBE-uri formează o pereche active/standby cu redundanță de nivel 2 „box-to-box”, care ridică IP-urile virtuale folosite în fața Webex Calling și a provider-ului. Configurația cere un grup de redundanță a aplicației, o interfață pentru control și date și urmărirea interfețelor (track) care declanșează failover-ul. Se aplică pe ambele CUBE-uri, iar pe primul se salvează configurația și se face reload. Failover-ul este stateful: apelurile active se păstrează.
Pentru detalii suplimentare despre proiectarea și implementarea Webex Calling cu Local Gateway, contactează echipa ALEF prin formularul de mai jos.
Notă: adresele IP, parolele și denumirile din exemplele de configurare sunt simbolice și trebuie înlocuite cu valorile din mediul tău. Configurațiile sunt simplificate; înainte de implementare consultă ghidurile Cisco la zi.
