Mecanica rutării în VoIP

În graba lor de a configura diverse funcții pe telefoanele IP, cei care încearcă sa învețe despre VoIP sar peste un pas foarte important în procesul de construire al unei unei rețele robuste de telefonie modernă: cel al înţelegerii unui concept adesea trecut cu vederea – rutarea.

Din punct de vedere al rețelelor standard de date, rutarea pare un proces destul de simplu: iei un pachet, verifici adresa destinație, trimiți mai departe daca găsești o rută corespunzătoare sau arunci pachetul în caz contrar. Chiar dacă rutarea pare simplă la prima vedere, nu este. Însă nu vom insista pe acest aspect, întrucât suntem interesaţi momentan de mecanica rutării în VoIP. Desigur, avem nevoie de rutarea datelor pentru a putea vorbi despre componenta asemănătoare din voce, însă voi considera că acest concept este înțeles în cele ce urmează.

Datorită dependenței rutării în voce de cea de date pornim de la premisa ca rutarea în voce prezintă un factor mai mare de dificultate. Să începem totuși cu lucruri simple cum ar fi însăși rutele:

Router: IP route 192.168.1.0 255.255.255.0 172.16.1.1

sau

Router: IP route 192.168.1.0 255.255.255.0 fa 0/0

sau

Voice gateway: destination-pattern 1...
session target ipv4:172.16.1.1

sau

CUCM: route pattern 1XXX
route list sau gateway sau trunk

 

Indiferent de tipul rutei observăm de fiecare dată aceleași componente: destinație și modul în care se ajunge la destinație (next hop sau exit interface sunt variantele pentru oricare din tipurile de rute). Toți cei care înțeleg procesul de rutare al datelor știu că este nevoie de o rută dus și de una întors pentru a permite funcționarea corectă a rețelei.

În mod obișnuit, în VoIP nu este necesară o cale de întoarcere definită pentru voce deoarece rutarea în voce se ocupă doar de componenta de semnalizare iar pachetele ce conțin insăși vocea sunt purtate pe baza principiilor rutării de date. Există însă situații în care avem nevoie neapărat de definirea unei rute de întoarcere. Un exemplu ar fi atunci când gateway-ul își asumă rolul de proxy pentru pachetele de voce sau, mai nou în IOS 15, gateway-ul se folosește de dial-peer pentru a autentifica telefoanele care au voie să poarte o conversație.

Mergem mai departe către ceva mai dificil. Nu am găsit cuvinte suficient de bune pentru această componentă așa că îi vom spune “ce intră și ce nu intră în tabela de rutare”. Pe gateway orice intră în tabela de rutare este obligat sa iasă din tabela de rutare. Pe Call Manager există elemente care permit revenirea în tabela de rutare după un match pe o rută. Translation-pattern este elementul responsabil pentru această acțiune. De ce oare am vrea să ne întoarcem în tabela de rutare după un match? Există anumite situații în care vrem să parcurgem tabela de rutare după ce aducem alterări adresei destinație sau poate a privilegiilor pe care cel care a originat apelul le avea. Ce nu parcurge tabela de rutare? Translațiile, profilele de translație, forward digits, num-exp, etc. pe gateway, respectiv transformation de diverse tipuri, external-phone mask pe CUCM. În cazul acestora acțiunea se petrece fie înainte să intrăm în tabelă, fie după ce s-a executat deja rutarea.

Ultimul element de care ar trebui sa ținem cont la capitolul rutare ar fi privilegiile și restricțiile. În mod normal, când vorbim de rutare nu ne ducem cu gândul la access-list-uri, însă pe Call Manager restricțiile ne ajută la “învârtirea” apelurilor. CSS-urile sunt un element pe cât de simplu, pe atât de util în direcționarea apelurilor. Putem controla rutarea exact în felul în care dorim prin cuplarea translation-pattern cu CSS și partiții.

Să recapitulăm informațiile prezentate prin intermediul unui suport grafic.

 

1.Voice gateway

2. Call manager