Telefonie Prin Internet Voice Over Ip

Telefonie prin Internet

Voice over IP

Cuprins

Întroducere

Generalități

1. Transportul de voce în rețele IP

1.1. Arhitectură sistemului VoIP

1.2. Modelul TCP/IP

1.3. Transportul de voce pește TCP/IP

1.4. Protocoale în timp real pentru aplicații VoIP

1.4.1. RTP (RFC 1889

1.4.2. RTCP (RFC 1889

1.4.3. RTSP (RFC 2326

2. Protocoale VoIP

2.1. Setul de protocoale H.323

2.1.1. Componente H.323

2.1.2. Semnalizarea în H.323

2.2. SIP-Protocolul de Inițiere a Sesiunii

2.2.1. Entitățile SIP și definiții

2.2.2. Mesajele SIP

2.2.2. Interconectarea SIP si H.323

3. Calitatea vocii în rețele de date

3.1. Factori care influențează trasnsmisia

4. Aplicație

4.1.Topologie rețea

4.3. Funcționalități

Concluzii

Bibliografie

Întroducere

Generalități

Lucrarea de fata își propune să prezinte principalele aspecte teoretice și practice ale tehnologiei Voice over IP (VoIP) sau Telefonia prin Internet care fără îndoială este un instrument de comunicare puternic și inovator bazat pe metoda care-i permite trasmiterea de voce și de date printr-o singură rețea folosind un standard universal, Internet Protocol (IP) .

Conținutul lucrării prezintă funcționalitatea tehnologiei Voice over IP cât și implementarea unei astfel de rețele în mediul de laborator Paket Trecer, fiind cuprins din patru capitole.

În acest sens primul capitol abordează aspectele transportului de date peste rețelele IP, arhitectura unei rețele VoIP cât și caractericticile protocoalelor în reale time. În capitolul al doilea este realizată descrierea și compartia celor mai importante protocoale care contribuie la semanizarea în rețele VoIP: H.323 și Șip .Capitolul trei expune factorii care impacteaza calitatea în serviciile de telefonie pe internet. În capitolul patru este prezentată rețeaua de telefonie pe internet și configurările în mediul Paket Trecer.

Capitolul 1 -Transportul de voce în rețele IP

Arhitectura Sistemului VoIP

Conectarea apartelor și centralelor telefonice la o rețea de calculatoare impune transferul semnalelor de convorbire și al celor de semnalizare precum și adaptarea formatului acestora la rețeaua de trasmisie a vocii.

Sistemul VoIP include patru module software (fig .1);

Arhitetctura Sitemelor VoIP Fig.1

1. Modulul de procesare al vocii și al pachetelor vocale (VPM-Voice Packet Module) convertește eșantioanele de voce în pachete generice și invers. Suplimentar, acest modul implementat cu un procesor digital de semnale cu interfața PCM efectuează operații de suprimare ecouri (G.165) pentru transmisii duplex, compresiea vocii prin detecția perioadelor de activitate vocală și suprimarea perioadelor de “liniște”, generarea tonului, diferențierea pachetelor de voce și date, eliminarea jiterului, sincronizarea de bit și de cadru, reordonarea fragmentelor din pachețele recepționate, redarea vocii în mod continuu din eșantioanele stocate în buffere de tip FIFO (First În, First Ouț).

2. Module de semnalizare telefonice (TSM-Telephony Signaling Module) interpretează semnalizările de pe linia telefonică (SS7 –Signaling System7) relativ la schimbările stării sistemului.

3. Modulul protocolului de rețea (NPM- Network Protocol Module) configurează conexiunile în rețea pe baza comenzilor date de TSM, formează pachetele de voce și de semnalizare cu antete specifice dependente de protocol. Semnalizarea în rețeaua de calculatoare se realizează pe baza diferitelor standarde, de exemplu Q.933 pentru semnalizări în sisteme VoFR.

4. Modulul de management al rețelei (NMM-Network Management Module) gestionează resursele sistemuli VoIP, conform standardului (ANSI). L compatibil cu (SNMP). Vl său conform unor standarde de firmă.

1.1. Modelul TCP/IP

Multe persoane sunt încântate de idea că modalitatea clasică de a efectua apeluri telefonice poate fi înlocuită de o tehnologie care în esență funcționează pe o rețea de calculatoare. De asemenea, sunt intrigați de multitudinea de opțiuni interesante ce vin împreună cu VoIP. În orice caz, oamenii încă își pun întrebări referitor la modalitatea în care VoIP funcționează și sunt oarecum suspicioși în privința capabilității VoIP de a face fața tuturor cererilor.

Răspunsul poate fi găsit în acealasi model care stă la baza rețelelor simple de date de la începutul internetului de acum mai bine de 25 de ani: modelul TCP/IP.

Modelul funcționează pe baza a 5 nivele (layers), TCP/IP este adaptat să activeze și să susțină VoIP, TCP/IP s-a dovedit a fi eficient cu “împachetarea” telefoniei așa cum a fost atâția ani cu împachetarea datelor informatice.

Pentru a înțelege pe deplin Voip, este important să înțelegem bazele tehnice care îl fac să funcționeze într-o rețea. Mai departe voi descrie nivelele (layers) modelului TCP/IP în relație cu rețelele de calculatoare. TCP/IP este primul și cel mai important grup de protocoale de rețea. Protocoalele sunt regulile care guvernează modalitatea prin care traficul dintr-o rețea este împachetat pentru a fi transmis către o alta. Unele protocoale TCP/IP sunt utilizate strict pentru date, altele exclusiv pentru telefonia VoIP, iar altele sunt folosite în ambele scopuri.

TCP asigura livrarea în siguranță și fără erori a pachetelor de date. Când sunt transmise pachete de date multiple se asigura că toate ajung la destinație și sunt prezentate în ordinea corectă către aplicație. UDP este un protocol mai simplu care vizeza în principiu tranzacțiile singulare, unde un pachet este trimis iar alt răspuns este primit. Nu include secvențe și funcțiuni de retransmisie. Deasupra TCP și UDP găsim diferite aplicații și servicii, aplicația său serviciu în sine determina dacă va fi utilizat TCP sau UDP. Având în vedere aceste aspect figura 2-4 evidențiază cum apare un pachet IP când este transmis dintr-un nod de rețea în alta. Datele aplicației sunt transferate mai jos către nivelul de transport.

Stuctura Pachet Figura 1

Fiecare protocol corespunde unuia dintre cele 5 nivele (layers) care alcătuiesc modelul TCP/IP:

Application: există protocoale speciale la acest nivel care asigură calitatea și livrarea pachetelor VoIP

Transport: Ușer Datagram Protocol (UDP) la acest nivel se asigura transportul pachetelor VoIP de la inițiere până la terminare, adică de la apelant până la apelat și invers

Internetwork: la acest nivel adresa IP este adugata pachetului. Fiecare telefon VoIP său calculator acționează ca un telefon VoIP va primi o adresă IP unică care rutează pachetele voip între apelant și apelat și vice versa.

Network interface: La acest nivel adresa MAC este adăugată pachetului. Adresa MAC este oferită de NIC cerut de toate componentele rețelei.

Physical: La acest nivel toate pachetele sunt convertite în semnale electro sau electo-optice pentru a fi transmise prin rețeaua locală sau externă.

Fiecare nivel (layer) este asociat cu unul sau mai multe protocoale. Un pachet trebuie să traverseze toate cele 5 nivele, de fiecare dată când un pachet este trimis și din nou când un pachet este primit. În principiu pachetele VoIP pleacă împreună cu apelul inițiat. Pachetul traversează în jos cele 5 nivele din rețeaua apelantului și sunt împachetate cu protocoalele corecte, aferente fiecărui nivel. Când pachetul a ajuns la ultimul nivel, nivelul fizic, este trimis prin rețea către destinație. Când pachetul ajunge la destinație urcă pe aceleași nivele în rețeaua celui care recepționează mesajul, fiind de data aceasta despachetat la fiecare nivel. Când ajunge la nivelul aplicației, pachetul este tradus într-un semnal vocal pe care destinatarul îl aude.

Transportul de voce peste TCP/IP

Diferența între implementarea VoIP și TCP IP este la nivel de straturi. În timpul unui apel de tip VoIP cererea de la nivel de aplicație utilizează următoarele trei tipuri de protocoale

NTP: Network Time Protocol Acest protocol permite sincronizarea și asigură faptul că semnalele sunt trimise și primite într-un interval de timp pentru a asigura calitatea.

RTP: Real Time Protocol. Acest protocol oferă funcții end-to-end de transport în rețea pentru semanle vocale digitale încapsulate în pachetul VoIP

RTCP: Real-time transport control protocol. Acest protocol monitorizează livrarea mesajului vocal și oferă un minim control al funcțiilor necesare pentru livrarea pachetelor.

Transportul de date -VoIP și TCP/IP

TCP are o viteză mai mică decât UDP, dar oferă o garanție a livrării pachetelor. Viteza este măsurată în nanosecunde. Deși timpul de livrare al pachetelor către destinație este mai mare și TCP asigura livrarea.

Pentru ca vocea este o aplicație real-time, este mult mai important că pachetele de voce să ajungă la destinație cât se poate de repede. De aceea UDP este de departe favorit pentru a asigura nivelul de transport pentru rețelele VoIP.

1.4. Protocoale real time pentru aplicații VoIP

Rețelele de calculatoare furnizează diferite servicii de rețea și aplicații diverse.

Pe lângă trasferul de date, un rol aparte în rețele îl au aplicațiile în timp real, cu transmisii vocale, audio sau video, bazate pe urmatorarele protocoale real time: RTP, RTCP, RTSP.

1.4.1. RTP (Real Time Protocol)

Scopul acestui protocol este de a oferi servicii cerute de conferințele multimedia interactive, ca sincronizare a redării informațiilor primite, de multiplexare, identificarea tipului de mediu folosit pentru transmisie și identificarea participanților activi. Totuși, nu numai aplicațiile pentru conferințe multimedia pot beneficia de RTP, ci și stocarea de date continue, distribuția interactivă de date cu formate multimedia, simulări realizate în paralel pe mai multe terminale și aplicațiile de măsură și control pot profita de avantajele aduse de RTP. Scopul proiectării RTP a fost obținerea unui protocol cu următoarele caracteristici:

Flexibil. RTP nu trebuie să fie limitat numai pentru conferințe audio și video;

Extensibil. RTP trebuie să permită implementarea de noi servicii;

Independent față de protocoalele inferioare. RTP ar trebui să lucreze cu UDP, TCP, ATM și altele;

Capabil să combine mai multe fluxuri media într-unul singur și să-l transmită cu alt tip de codare;

Eficient din punct de vedere al benzii. Dimensiunea antetului în cazul pachetelor mici de voce poate fi chiar cât dimensiunea informațiilor propriu-zise.

Internațional. Protocolul trebuie să includă codări de tipul legea A, legea μ dar și seturi de caractere non ASCII.

Eficient din punct de vedere al procesării. Și cele mai mari intervale de timp conținute în pachete creează o rată de 40 de pachete pe secundă pentru un singur canal de voce.

Implementabil imediat. Protocolul poate să nu aibă o viață îndelungată și de aceea trebuie să fie posibil să fie implementat având la dispoziție software-ul și hardware-ul curent.

Protocolul pentru transportul în timp real (RTP) a fost proiectat pentru a permite receptoarelor compensarea problemelor cauzate de jitter și sosirea într-o altă ordine a pachetelor decât cea în care au fost transmise.

RTP poate fi folosit pentru orice flux de date în timp real, de exemplu pentru voce și pentru video. RTP include o modalitate de a identifica pachetele IP ce transportă informații izocrone prin următoarele informați incluse în antet:

Informații referitoare la tipul datelor transportate;

Informații referitoare la tipul la care au fost emise (timestamps);

Numere de secvență.

Pachetul RTP conține întotdeauna toate câmpurile până la lista CSRC. Această listă există numai după ce pachetul trece de un mixer. Câmpurile sunt:

2 biți sunt rezervați pentru versiunea folosită de RTP.

Un bit ce indică adăugarea de biți în plus din considerente de aliniere. Dacă pachetul a fost modificat (P=1), atunci ultimul octet al câmpului ne indică tipul datelor transportate, indică mai precis câți octeți au fost adăugați.

Câmpul de 4 biți CC indpachetele IP ce transportă informații izocrone prin următoarele informați incluse în antet:

Informații referitoare la tipul datelor transportate;

Informații referitoare la tipul la care au fost emise (timestamps);

Numere de secvență.

Pachetul RTP conține întotdeauna toate câmpurile până la lista CSRC. Această listă există numai după ce pachetul trece de un mixer. Câmpurile sunt:

2 biți sunt rezervați pentru versiunea folosită de RTP.

Un bit ce indică adăugarea de biți în plus din considerente de aliniere. Dacă pachetul a fost modificat (P=1), atunci ultimul octet al câmpului ne indică tipul datelor transportate, indică mai precis câți octeți au fost adăugați.

Câmpul de 4 biți CC indică numărul de CSRC-uri ce urmează după antetul fix.

Bit de marcaj (M). Interpretarea acestui bit este definită de un alt document ce vine odată cu aplicația folosită și numit profil RTP.

Tipul informației transportate (PT). Are 7 biți și identifică forma informației transportate și determină interpretarea acesteia de către aplicație.

Numărul de secvență (16 biți). Numărul de secvență este incrementat pentru fiecare pachet RTP trimis și poate fi folosit de receptor pentru a detecta pierderea pachetelor și a reface ordinea pachetelor. Valoarea inițială a numărului este aleatorie pentru a face atacurile asupra fluxurilor codate mai dificile

1.4.2. RTCP (Real time control protocol)

Protocolul pentru controlul RTP-ului este bazat pe transmisia periodică a pachetelor de control către toți participanții unei sesiuni particulare. Pachetele de control sunt distribuite în același mod ca și pachetele de date. Fiecare pachet RTCP include un raport al transmițătorului și/sau un raport al receptorului care prezintă statistici cum ar fi numărul de pachete trimise, numărul de pachete pierdute, jitterul, întârzierea fată de ultimul raport, timpul de emisie al ultimului raport, etc, utile aplicațiilor. RTCP are patru funcții separate:

Funcția principală este de a furniza feedback cu privire la calitatea distribuției de date. Informațiile primite prin această cale putând fi folosite la controlul unei codări adaptive (codec adaptiv). Experimentele folosind multiplexarea IP au arătat că feedback-ul este critic pentru diagnosticul greșelilor în distribuție. Această funcție este realizată prin folosirea a două rapoarte: raportul transmițătorului și raportul receptorului.

RTCP identifică toți participanți unei sesiuni. Acest protocol face acest lucru prin transportul unui identificator de nivel transport al fiecărei surse numit nume canonic (CNAME) („canonical name”) și al unui identificator de sursă de sincronizare (SSRC). SSRC-ul se poate schimba într-o sesiune. Identificatorul CNAME este de asemenea folosit pentru sincronizarea fluxurilor multimedia multiple. Când un participant părăsește conferința este trimis un pachet RTCP BYE.

Pachetele protocolului sunt trimise pentru a îndeplini primele două funcții, de aceea rata cu care sunt trimise pachetele este de asemenea controlată. Acest control al ratei este realizat de RTCP. Numărul de participanți observat este folosit pentru determinarea valorii acestei rate. Cu cât numărul participanților este mai mare cu atât rata cu care se trimite pachete de către fiecare participant este mai mică.

A patra funcție (opțională) este de a transporta minimum de informație de control a sesiunii, pentru, ca exemplu, să se poată face identificarea participanților în interfața grafică.

Toți participanții trebuie să trimită pachete RTCP, fapt ce poate crea probleme pentru conferințele pe bază de multicast de mari dimensiuni deoarece traficul RTCP va crește liniar cu creșterea numărului de participanți. Această problemă nu există cu fluxurile RTP în conferințele audio ce folosesc suprimarea pauzelor, deoarece oameni nu vorbesc de regulă în același timp.

Deoarece numărul de participanți este cunoscut tuturor ce ascultă rapoartele RTCP, fiecare dintre aceștia își poate controla rata cu care trimite aceste rapoarte. Acest fapt este folosit pentru a limita banda folosită de RTCP la o valoare rezonabilă, de obicei nu mai mult de 5% din banda alocată sesiunii. Această bandă trebuie împărțită de toți participanții. În „standarde” se stipulează că transmițătorilor activi le revine un sfert din această bandă deoarece informațiile conținute în rapoartele transmițătorilor sunt foarte importante pentru receptori. Ceea ce rămâne se împarte între receptori.

Sunt mai multe tipuri de pachete RTCP, unul pentru fiecare tip de informație:

SR: reprezintă raportul transmițătorului și conține informațiile de transmisie și recepție despre transmițătorii activi;

RR: reprezintă raportul receptorului și conține informațiile despre ascultătorii ce nu sunt și transmițători activi;

SDES: reprezintă descrierea sursei și conține numeroși parametrii referitori la sursă, incluzând și CNAME;

BYE: reprezintă raportul trimis atunci când un participant părăsește conferința;

APP: prezintă funcțiile specifice unei aplicații.

RTP-translator

Câteva pachete RTCP pot fi incluse într-un singur pachet al protocolului de transport. Fiecare mesaj RTCP conține destule informații pentru a fi decodat fără probleme dacă mai multe asemenea mesaje sunt încapsulate în același pachet UDP. Acest mod de folosire este folositor pentru a transmite eficient informația, ținând cont de dimensiunile antetului protocolului de transport.

1.4.3. RTSP (Real Time Streaming Protocol – RFC 2326).

Protocolul pentru fluxurile în timp real sau RTSP este un protocol de nivel aplicație pentru controlul livrării datelor cu proprietăți de timp real. RTSP furnizează o bază extensibilă pentru a permite transportul controlat, la cerere, al datelor de timp real, cum ar fi cele audio și video. Sursele de date pot fi atât aparatele ce captează în momentul transmisiei ca și date stocate. Acest protocol este proiectat pentru a controla multiple sesiuni de transfer de date, pentru a furniza mijloacele prin care se aleg canalele de transport, cum ar fi UDP, multicast UDP sau TCP și pentru a furniza mijloacele pentru alegerea mecanismelor de transport bazate pe RTP.

RTSP stabilește și controlează unul sau mai multe fluxuri sincronizate de date continue cum ar fi audio sau video. În mod normal nu transportă el însuși aceste fluxuri, cu toate că interpunerea fluxurilor media cu fluxul de control este posibilă. Cu alte cuvinte, RTSP propune un control la distanță prin rețea al serverelor multimedia.

Fluxurile controlate de RTSP pot folosi RTP, dar modul de funcționare al protocolului prezentat nu depinde de mecanismul de transport folosit pentru a duce datele în timp real. Protocolul este intenționat asemănător în sintaxă și mod de operare cu HTTP versiunea 1.1. HTTP adică Hypertext Transfer Protocol este un protocol de nivel aplicație pentru sistemele aflate la distanță și care comunică între ele. Este un protocol generic, fără stări. Acesta a fost folosit de către inițiativa globală informatică „World Wide Web” încă din 1990. Prima versiune HTTP/0.9 a fost un simplu protocol pentru transferul datelor neprelucrate prin Internet. Versiunea 1.0, cum a fost definită în RFC-ul 1495, a îmbunătățit protocolul prin faptul că a permis mesajelor să aibă un format asemănător cu formatul MIME (Multipurpose Internet Mail Extensions), mesaje ce conțineau informații despre datele transportate și modificatori ai semanticii mesajelor de cerere și răspuns.

Versiunea 1.1 include cerințe mai dure decât versiunea anterioară cu scopul de a furniza implementări sigure a caracteristicilor acestui protocol. HTTP asigură un set de metode și antete ce indică scopul unei cereri. Acesta este construit pe disciplina referințelor furnizate de „Uniform Resource Identifier” (URÎ), ca locație URL sau ca nume URN, pentru a indica resursa pentru care se va aplica metoda. Mesajele sunt trimise într-un format similar cu cel folosit în sistemele de poștă electronică din Internet definit în documentul „Multipurpose Internet Mail Extensions” (MIME). HTTP este de altfel folosit și ca protocol de comunicație între agentul utilizatorului (aplicația care rulează la cererea utilizatorului), gateway-uri sau proxy-uri și alte sisteme din Internet, incluzând și pe acelea ce suportă protocoalele FTP și SMTP. În acest mod HTTP

Protocolul RTSP se diferențiază de HTTP/1.1 prin următoarele aspecte:

introduce un număr de noi metode și are un identificator de protocol diferit;

un server RTSP trebuie să mențină o stare în toate cazurile, spre deosebire de natura fără stări a HTTP-ului.

și clientul și serverul pot emite cereri.

datele sunt transportate de către un alt protocol.

setul de caractere folosite în compunerea mesajelor este altul.

identificatorul resursei URI este în cadrul unei cereri întotdeauna absolut.

Aceste modificări duc la implementarea mai ușoară a unor situații în care există mai multe ierarhii de directoare pe o singură gazdă cu o singură adresă IP.

Protocolul permite următoarele operații:

– Obținerea de informații de la un server. Clientul poate cere o descriere a prezentărilor prin HTTP sau altă metodă. Dacă prezentarea este trimisă în mod multicast atunci descrierea conține adresa de multicast și porturile utilizate pentru fluxurile media. Dacă doar acest client este vizat de prezentare, adică numai el va primi fluxurile media prin unicast atunci clientul va oferi destinația din motive de securitate.

– Invitarea unui server media la o conferință. Un server media poate fi invitat la o conferință, fie pentru a reda fișiere multimedia, fie pentru a înregistra toată sau o parte din conferință. Această operație este foarte utilă pentru aplicațiile de învățământ la distanță.

– Informarea utilizatorilor despre tipurile de date în timp real disponibile pentru o prezentare existentă deja. În special pentru prezentările în timp real, este util să se informeze pe cei care participă de către server ce tipuri de date în timp real au devenit disponibile.

RTSP este identificat printr-un URL al protocolului RTSP, care indică spre server-ul ce prelucrează acel flux și poartă numele ori a fluxului ori a server-ului. Mai multe fluxuri media pot fi localizate pe servere diferite; de exemplu, fluxurile audio și video pot fi împărțite pe mai multe servere pentru că încărcarea acestora să fie echitabilă. Descrierea enumeră și ce metode de transport poate folosi un server.

Capitolul 2. Protocoale VoIP

Semnalizarea reprezintă procesul ce permite inițializarea și controlul unei conversații între două sau mai multe persoane. În cazul telefoniei prin Internet de acest lucru se ocupă protocoalele de semnalizare. Acestea sunt folosite pentru a stabili și controla sesiunile sau apelurile multimedia. Aceste sesiuni includ conferințe multimedia, telefonie, învățământ la distanță și alte astfel de aplicații. Protocoalele de semnalizare peste IP sunt folosite să interconecteze clienți software și hardware prin rețele locale (LAN) sau prin Internet.

Principalele funcții ale acestui tip de protocoale sunt: căutarea unui utilizator, translația de adrese și nume, stabilirea unei conexiuni, negocierea parametrilor unui apel, schimbul parametrilor specifici aparatelor folosite în conversație, întreruperea unui apel și managementul participanților la o conversație cum ar fi invitarea de noi participanți. Alte servicii, cum ar fi securitatea, tarifarea, anunțarea sesiunilor pot fi incluse în aceste protocoale. Semnalizarea este foarte strâns legată de transmisia fluxurilor de date, dar aceasta nu face parte din semnalizare.

Astăzi două protocoale de semnalizare există pe piață: H.323 și SIP. Aceste două protocoale reprezintă două abordări diferite asupra aceleiași probleme: semnalizarea și controlul conferințelor multimedia.

2.1. Setul de Protocoale H.323

H.323 este un standard „umbrelă” de la „Internațional Telecommunications Union” (ITU) pentru comunicații multimedia peste rețele locale (LAN-uri) care nu furnizează nici un fel de garanție privind calitatea serviciilor. H.323 face parte dintr-o serie mai mare de standarde pentru comunicații numită seria H.32x, ce conține standarde pentru conferințe multimedia peste tipuri diferite de rețele, incluzând ISDN și PSTN. Specificația H.323 a fost aprobată în 1996, dar primele standarde din seria H.32x au fost aprobate încă din 1990. Versiunea 2 a standardului se referă la conferințele peste rețelele de mari dimensiuni de tipul WAN („Wide Area Networks”) și a fost aprobat în 1998. Această versiune a adăugat și specificații pentru comunicația între rețelele de pachete și cele de circuite. Versiunea 3 a fost aprobată în anul 2000 și conține specificații pentru transmisia fax-urilor peste rețelele de pachete, pentru comunicația între managerii de apeluri și pentru mecanisme mai rapide pentru stabilirea conexiunii telefonice. H.323 reprezintă o abordare tradițională folosind tehnicile telefoniei prin rețelele de circuite, bazate pe protocolul de semnalizare ISDN Q.931.

H.323 este folosit în mod curent în tehnologia VoIP precum și în video conferințe bazate pe IP, inițial a fost creat pentru transportul aplicațiilor media în relele LAN, însă între timp a evoluat și a ajuns să acopere majoritatea nevoilor VoIP.

2.1.1. Componente H.323

Părțile componente ale unei rețele VoIP bazate pe protocoalele H.323 sunt următoarele: terminale, gateway-ul, gatekeeper-ul și MCU (Mulți Controller Units)

Componente H.323

Obiectivul general al H.323 este de a permite schimbul de fluxuri media, în timp real, intre puncte terminale H.323 în cazul în care în punct final exista un terminal H.323, gateway sau un MCU.

Terminal este un dispozitiv de comunicare pentru utilizatorii finali care suporta cel puțin un codec audio (coder/decodor) și opțional și alte codec-uri audio și/sau video.

Cele mai întâlnite codecuri folosite de terminale sunt: ITU-T G.711 (PCM), G723 (MP-MLQ), G.729A (CA-ACELP) și GSM. Terminalele trebuie să suporte și funcții de semnalizare.

Configurația terminalului

Gateway-ul este un punct final H.323 care oferă servicii de translatare (traducere)

Între rețeaua H.323 și un alt tip de rețea, cum ar fi o rețea integrată de servicii digitale (ISDN) sau rețeaua de telefonie obișnuit. (PSTN). Gateway-ul realizează funcția de translație și între diferite formate de transmisie cu ar fi H.225 în H.221. De asemenea, mai poate face translația intre codecuri audio și video. Într-o rețea simplă LAN, în care terminalele comunica direct între ele Gateway-urile sunt opționale. Atunci când terminalele dintr-o rețea comunica între ele, gateway-urile sunt opționale.

Gatekeeper-ul îndeplinește funcțiile de translatare a adreselor, controlul admisiei, semnalizării apelului, autorizarea apelului, managementul lățimii de banda, managementul apelului. Gatekeeper-ul este răspunzător pentru realizarea conexiunilor H.323 într-o rețea orientată pe comutație de pachete. Acesta poate, de asemenea, interzice accesul sau să limiteze numărul de conexiuni simultane pentru a evita aglomerația rețelei.

MCU poate implementa ambele funcții atât ale MP cât și ale MC, caz în care este denumit MCU centralizat. Dacă MCU este descentralizat implementează doar funcțiile MC, lăsând funcția de MP pentru terminalele participante. MCU poate fi un echipament de sine stătător sau poate fi integrat într-un terminal sau gatekeeper.

2.1.2. Semnalizarea în H.323

Standardul H.323 include trei protocoale de control H225/Q.931 Call Signaling, H.225.0 RAS și H.245 Media Control, H.225/Q931 este folosit împreună cu H.323 și oferă semnalizare pentru controlul apelului. Pentru stabilirea unui apel de la o sursă la un destinatar, este folosit canalul H.224 RAS (Registration, Admission and Signaling). După ce s-a stabilit legătura, H245 este folosit pentru a negocia fluxurile media.

Canalul RAS este folosit pentru comunicația intre terminale și gatekeper. Deoarece mesajele RAS sunt transmise peste UDP se recomanda monitorizări ale timpului de transmisie și dacă este cazul, reincercari de transmitere a mesajelor. Procedurile definite de canalul RAS sunt următoarele:

– Determinarea Gatekeeper-ului este procesul prin care un terminal îl folosește pentru a descoperi gatekeeper-ul care îl va folosi. În mod normal, terminalul transmite o cerere către Gatekeeper (GRQ-Gatekeeper Reguest Message). Unul sau mai multe gatekeeper-uri pot răspunde cu un mesaj de confirmare (GCF-Gatekeeper Confirmation Message) prin care își exprima disponibilitatea de a prelua terminalul respectiv. Acest răspuns include adresa de transport a canalului RÂS al gatekeeper-ului. Gatekeeper-urile care nu doresc să-și înregistreze terminalul pot trimite un mesaj de respingere cu GRJ- Gatekeeper reject Message). Dacă mai mult de un Gatekeeper răspunde cu GCF, atunci gatekeeper-ul poate fi ales de către terminal. Dacă nici un gatekeeper nu răspunde într-un anumit interval de timp, terminalul poate retransmite mesajul GRQ.

– Înregistrarea gatekeeper-ului este procesul prin care un terminal se alătura unei zone și informează gatekeeper-ul de adresa sa de transport și de alias. Toate terminalele se înregistrează la gatekeeper-ul care a fost identifcat în urma procesului gatekeeper discovery și folosește canalul RAS TSAP. Gatekeeper-ul rebuie să se asigure că fiecare adresă alias translatează în mod unic către o singură adresa de transport. Un terminal poate să-și anuleze înregistrarea unui terminal trimițând un mesaj unregister Request (URQ) către terminal. Terminalul ar trebui să răspundă cu un mesaj UnregisterConfirmation (UCF).

– Un terminal sau un gatekeeper care are o adresă alias pentru un terminal și ar dori să determine informații referitoare la contacul acestuia, poate transmite un mesaj Location Request (LRQ). Gatekeeper-ul la care este înregistrat terminalul răspunde cu un mesaj Location Confirm (LCF care conține informații de contact ale terminalului sau ale gatekeeper-ului. Toate gatekeeper-ele care nu au înregistrat terminalul respectiv și au primit mesajul LRQ pe canalul RAS vor răspunde cu un mesaj Location Reject (LRJ).

– Canalul RAS este folosit de asemenea pentru trasmiterea admisiei, schimbării lățimii de banda, a statusului și dezactivării prin intermediul mesajelor. Aceste mesaje care sunt schimbate intre terminale și gatekeeper-uri sunt folosite pentu a oferi controlul admisiei și funcții de management al lățimii de ganda. Mesajele Admission Request (ARQ) specifică lățimea de banda necesară apelului. Gatekeeper-ul poate reduce lățimea de banda cerută prin mesajul ACF. Un terminal sau chiar gatekeeper-ul poate încerca să modifice lățimea de bandă în timpul apelului printr-un mesaj Bandwidth Change Request (BRQ).

Canalul de semnalizare este folosit pentru a transporta mesaje de control H.255. În rețelele care nu conțin un gatekeeper, mesajele de semnalizare a apelului sunt direcționate intre terminalele sursă și destinație folosind Call Signaling Transport Addresses. Se presupune că terminalul sursa cunoaște adresa terminlului apelat, și de aceea poate comunica în mod direct. În rețelele care conțin gatekeeper, schimbul de mesaje de admisie are loc între terminalul apelat și gatekeeper-ul care folosește adresa RAS a canalului de transport. Semnalizarea apelului este efectuată utilizând TCP (canal singur).

Mesajele de semnalizare pot fi împărțite în două categorii. Prima categorie cuprinde mesaje de semnalizare care sunt rutate prin gatekeeper printre terminale. Cealaltă alternativă reprezintă mesajele care sunt transmise direct la terminale. Mesajele de admisie sunt schimbate de gatekeeper folosind canalul RAS urmat de un schimb de mesaje de semnalizare.

Când este folosit apelul de semnalizare, sunt două metode de a ruta Canalul de Control H.245: prima alternativă stabilește canalul H.245 direct între terminale, iar în al doilea caz, stabilirea canalului de control H.245 se face prin gatekeeper.

2.2. SIP – Protocolul de Inițiere a Sesiunii (RFC 3261).

Protocolul denumit „Session Initiation Protocol” pe scurt SIP este dezvoltat de grupul de lucru „Multiparty Multimedia Session Control” (MMUSIC) ce face parte din „Internet Engineering Task Force” (IETF). Acest protocol este mai puțin cunoscut decât H.323 și de aceea va fi dezbătut pe larg în următoarele pagini. SIP este un protocol mai simplu și se bazează pe protocolul HTTP. El a fost proiectat inițial pentru conferințele multimedia ce folosesc Internetul.

SIP este definit în RFC-ul 3261 din iunie 2002, document ce ia locul RFC-ului 2543 din martie 1999. Protocolul de Inițializare al Sesiunii (SIP) a fost gândit pentru a se asigura un mod avansat de control al începerii, terminării și administrării modului în care se transmit datele într-o rețea. La dezvoltarea protocolului s-a ținut cont de faptul că acesta va trebui să ruleze eficient pe diverse variante de servicii multimedia.

Cu ajutorul SIP se pot localiza într-o manieră scalabilă resursele dintr-o rețea și, indiferent de localizarea fizică a acestora, se pot iniția și negocia caracteristicile sesiunii de comunicare. Câteva dintre domeniile care suporta acest protocol sunt aplicațiile de telefonie IP și videoconferință. După cum se observă și din denumire, Protocolul de Inițializare al Sesiunii inițializează, administrează și termină o sesiune de comunicație într-o rețea.

Session Initiation Protocol face parte din arhitectura promovată de câțiva ani de Internet Engineering Task Force, care mai cuprinde Real-Time Transport Protocol (RTP) – protocolul de transport pentru date audio, video, sau alte date sensibile în ceea ce privește timpul de transfer prin rețea, Real-Time Streaming Protocol (RTSP) – pentru controlul fluxurilor multimedia la cerere, Session Description Protocol (SDP) – pentru descrierea sesiunilor multimedia, Session Announcement Protocol (SAP) – pentru anunțarea sesiunilor de comunicare de la un singur emițător la mai mulți receptori, Telephony Routing over IP (TRIP) – pentru localizarea celei mai bune căi de transmisie între Internet și rețeaua de telefonie publică.

În principal SIP este destinat pentru asigurarea sesiunilor de comunicație intre utilizatori identificați prin identificatori de tip e-mail sau număr de telefon. Orice echipament care are asignat un nume de gazdă într-o rețea poate lua parte la o sesiune SIP. Procesul de creare al unei legături SIP începe cu descoperirea unui utilizator indiferent de localizarea acestuia în rețea, pentru că descrierea sesiunii să poată fi trimisă utilizatorului.

Atribuirea acestui identificator unui utilizator va fi realizată de către furnizorul serviciului de conectare în rețea sau compania telefonică. În plus, identitatea unui singur utilizator poate fi reprezentată simultan de un număr de terminale conectate la rețea. În funcție de elementele logice prezente în elementele de rețea SIP, se pot trimite cereri de realizare a comunicației către oricare dintre terminalele care recunosc același identificator (unul, mai multe sau chiar toate).

Inițierea sesiunii depinde și de abilitatea parții apelate de a determina cantitatea de informații necesare despre sesiunea în sine, astfel încât aceasta să poată decide în ceea ce privește participarea sau nu la comunicația care ar urma să aibă loc. Ca urmare, un mesaj SIP include informații despre apelant, motivul pentru care se dorește deschiderea unei sesiuni, cât de urgentă este realizarea legăturii și informații despre parametrii sesiunii de comunicare.

2.2.1. Entitățile SIP și definiții.

SIP reprezintă standardul IETF pentru stabilirea conexiunilor VoIP. Protocolul de Inițializare al Sesiunilor este un protocol de control la nivel aplicație (de semnalizare) pentru crearea, modificarea și închiderea sesiunilor cu unul sau mai mulți participanți. Aceste sesiuni includ conferințe multimedia prin Internet, apeluri telefonice prin Internet și distribuții multimedia. Participanții într-o sesiune pot comunica prin multicast, printr-o rețea de canale unicast sau printr-o combinație a acestor două moduri.

Arhitectura SIP este similară cu aceea a protocolului HTTP. Cererile sunt generate de către client și trimise serverului. Acesta procesează cererile și trimite un răspuns clientului. O cerere și răspunsul corespunzător formează o tranzacție. SIP are mesajele INVITE și ACK care definesc procesele de deschidere de canale sigure prin care mesajele de control ale apelului pot fi trimise. Protocolul face foarte puține presupuneri cu privire la protocolul de transport. El însuși asigură siguranța transportului și nu se bazează pe TCP pentru aceasta.

SIP se bazează de SDP (Protocolul de Descriere al Sesiunilor) pentru negocierea codecurilor disponibile. Protocolul de Inițializare al Sesiunilor folosește descrieri de sesiuni pentru a permite participanților punerea de acord asupra unor tipuri de media compatibile. Acest protocol sprijină mobilitatea utilizatorului prin existența funcțiilor de tip proxy și de îndrumare a răspunsurilor spre locația curentă a utilizatorului. SIP asigură următoarele faze din stabilirea și închiderea unei comunicații (RFC 3261) [9]:

Găsirea utilizatorului: determinarea terminalului care va fi folosit pentru comunicație;

Determinarea stării utilizatorului: protocolul poate determina dacă un utilizator este disponibil să răspundă la un apel sau nu;

Determinarea capacităților de comunicare: poate afla care sunt tipurile de media și proprietățile acestora, ce pot fi folosite în timpul comunicației.

Stabilirea sesiunii: anunțarea parților participante și stabilirea parametrilor la ambele capete ale sesiunii;

Managementul sesiunii: include transferul și închiderea sesiunii, modificarea parametrilor și invocarea de servicii.

Așa cum am mai spus SIP nu este un sistem de comunicație complet. Acesta este mai degrabă o componentă care poate fi folosită împreună cu alte protocoale IETF pentru a forma o arhitectură multimedia completă. În mod normal această arhitectură va cuprinde protocoale ca RTP (RFC 1889) pentru transportul datelor de timp real și pentru a furniza un feedback în privința calității serviciilor, RTSP (RFC 2326) pentru controlul transportului fluxurilor media, Protocolul pentru controlul gateway-urilor media (MEGACO – Media Gateway Control Protocol RFC 3015) pentru controlul gateway-urilor ce sunt la marginea rețelelor de pachete și fac legătura cu rețelele cu comutație de circuite și SDP (RFC 2327) pentru descrierea sesiunilor multimedia. De aceea, SIP trebuie folosit în conjuncție cu alte protocoale pentru a furniza servicii complete utilizatorilor. Totuși, funcționarea protocolului nu depinde de niciun protocol.

SIP nu furnizează servicii. În schimb, SIP folosește primitive care pot fi folosite pentru a implementa diferite servicii. De exemplu SIP poate localiza un utilizator și trimite la acea locație câteva pachete de date. Dacă această primitivă este folosită pentru a trimite o descriere de sesiune, atunci, de exemplu, cele două terminale pot conveni asupra parametrilor sesiunii. Dacă aceeași primitivă este folosită pentru a trimite o fotografie a apelantului în același mod că descrierea sesiunii, atunci un serviciu de identificare al apelantului poate fi ușor de implementat. Cum a arătat acest exemplu, o singură primitivă este folosită pentru a furniza diferite servicii.

SIP nu oferă servicii de control a conferințelor cum ar fi controlul vorbitorului curent (” floor control”) sau votare și nu indică cum ar trebui „condusă” o conferință. Acest protocol poate fi folosit pentru a iniția o sesiune care folosește un alt protocol de control al conferințelor. Deoarece mesajele SIP și sesiunile stabilite cu acestea nu pot trece prin rețele complet diferite, SIP nu poate și nu oferă nici o modalitate prin care să se asigure rezervare de resurse.

Din cauza naturii informațiilor transmise siguranța acestora este importantă. În acest scop, protocolul poate fi folosit pentru a se implementa servicii de securitate ce includ prevenirea atacurilor de tip DoS (” denial-of-service”), autentificarea, protecția integrității și codarea.

Înainte de a prezenta entitățile și modul de operare al protocolului este necesară precizarea unor noțiuni:

Client: un program aplicație care trimite cereri SIP. Clienții pot sau nu pot interacționa cu un utilizator uman.

Server: Un server este un program aplicație care acceptă cereri pentru a le prelucra și trimite înapoi răspunsuri la aceste cereri.

Apel: un apel constă din toți participanții dintr-o conferință invitați de o sursă comună. Un apel SIP este identificat de către un identificator unic. Astfel, dacă un utilizator este invitat la aceeași sesiune multicast de către persoane diferite, fiecare dintre aceste invitații este un apel unic. O conversație telefonică prin Internet punct la punct reprezintă un singur apel SIP.

Conexiune: o conexiune ce servește o conversație este identificată printr-o combinație de câmpuri: identificatorul apelului, adresele participanților și valorile câmpurilor „From” (De la) și „To” (Spre). Având același identificator al apelului, cererile ce au câmpurile cu valorile „Spre” A și „De la” B aparțin aceleiași conexiuni ca și cererile ce au câmpurile cu valorile „Spre” B și „De la” A, din direcție opusă.

Sesiune: în specificația SDP o sesiune multimedia reprezintă un set de transmițători și receptori și fluxurile de date ce sunt între aceștia. O conferință multimedia este un exemplu de sesiune. După cum s-a mai spus, un apelat poate fi invitat la aceeași sesiune de mai multe ori. Dacă se folosește SDP, o sesiune este definită de concatenarea numelui utilizatorului, identificatorul sesiunii, tipul rețelei, tipul adresei și elementele de adresă din câmpul „Origine” din antet.

Tranzacție SIP: are loc între un client și un server și conține toate mesajele de la prima cerere trimisă de client server-ului până la ultimul răspuns trimis de server către client. O tranzacție este identificată, într-o conexiune, de numărul de secvență „Cseq”.

Componentele arhitecturii SIP sunt:

Agentul utilizatorului: este o aplicație ce conține atât un agent client cât și un agent server. Clientul este agentul ce trimite apelurile iar serverul este cel care le primește.

Server proxy: este un program intermediar ce funcționează atât ca server cât și ca client cu scopul de a face sau retrimite cereri din partea altor clienți.

Server de îndrumare: reprezintă server-ul care acceptă o cerere SIP și asociază unui client mai multe adrese la care poate fi găsit. Spre deosebire de server-ul proxy, acesta nu trimite mesajul mai departe. În schimb, trimite noua adresă găsită clientului cerându-i acestuia să retrimită mesajul acolo.

Server de localizare: este folosit de către un server proxy sau de îndrumare pentru a obține informații despre locațiile posibile ale unui apelant.

Proxy „outbound”: este proxy-ul ce este localizat aproape de originea unei cereri. Primește toate cererile unui agent client, incluzând și acelea care nu îi sunt adresate. Proxy-ul trimite aceste cereri, după procesări locale, la adresele din antete.

Registrator: este un server ce acceptă cererile de înregistrare „REGISTER”. Monitorizează utilizatorii în interiorul domeniului de rețea asignat. Este în mod tipic pus în aceeași locație cu un server proxy sau de îndrumare și poate face ca informațiile ce le deține să fie disponibile.

Acestea sunt elemente separate logic și nu sunt implementări fizice distincte. Nu este deloc un fenomen neobișnuit de a găsi servere proxy, de îndrumare și registratori care rulează în cadrul unei singure conversații.

2.2.2. Mesajele SIP.

Așa cum am mai spus mai devreme SIP este un protocol bazat pe text. Sintaxa mesajelor și câmpurile din antet sunt identice cu specificația HHTP/1.1. Un mesaj SIP este sau o cerere sau un răspuns. O cerere este generată de un client și un răspuns este generat de un server. Mesajele cerere și răspuns folosesc formatul mesajului generic din RFC-ul 822 pentru transferul corpului unui mesaj. Ambele tipuri de mesaje constau dintr-o linie de start, una sau mai multe linii de antet, o linie goală (adică o linie ce nu are nimic înaintea caracterului CRLF ce indică terminarea unei linii) ce avertizează că s-au terminat liniile din antet și opțional corpul mesajului.

Formatul mesajului cerere este expus în continuare:

Cerere: linie de cerere

*(antet general | antet cerere | antet corp mesaj)

CRLF

[corpul mesajului]

Unde linia de cerere este formată din câmpurile:

Linie de cerere: metoda SP identificatorul de tip URI al sursei SP Versiunea SIP CRLF

Cu următoarele semnificații:

Câmpul metoda poate avea următoarele valori: „INVITE” | „ACK” | „OPTIONS” | „BYE” | „CANCEL” | „REGISTER” | metodă extinsă

Câmpul versiunea SIP: „SIP/2.0”

Câmpul SP: „” (spațiu liber)

Mesajele SIP folosesc câmpurile antetului pentru a specifica diferite informații despre participanți, calea de urmat și altele. Aceste câmpuri sunt asemănătoare cu cele de la HTTP în sintaxă și semantică. Ordinea în care apar nu are în general nicio importanță, cu excepția câmpurilor ce sunt introduse între servere. Unele câmpuri din antet sunt folosite în toate mesajele și altele doar când sunt necesare. O aplicație ce implementează SIP nu trebuie să înțeleagă toate câmpurile, dar ar fi de dorit să o poate face. Dacă un participant SIP nu înțelege un antet îl poate ignora. Numărul total de câmpuri în antetul SIP este de 44 și pot fi împărțite în patru grupuri:

Câmpurile antetului general ce există și în cereri și în răspunsuri.

Câmpurile antetului corp mesaj ce definesc informația despre corpul mesajului său dacă acesta nu este prezent atunci despre resursa identificată de cerere.

Câmpurile antetului cerere ce permit clientului să trimită informații în plus despre cerere și despre el însuși, server-ului.

Câmpurile antetului răspuns ce conțin informațiile despre server și despre accesul la resursa identificată de URI din cerere.

În cadrul antetului general se află următoarele câmpuri mai importante:

Call-ID (identificatorul de apel; de exemplu CallID:[anonimizat]) este folosit în multe scopuri. În cadrul cererilor de înregistrare și de obținere a parametrilor unui server este folosit pentru a recunoaște răspunsurile corespunzătoare cererilor. Pentru cererile de invitare și de înregistrare este folosit și pentru a detecta copiile acestor cereri. Cererile INVITE succesive cu același CallID dar cu parametrii diferiți pot fi folosite pentru a schimba în mod dinamic parametri într-o conferință. Prima parte din identificator trebuie să fie unică pentru fiecare gazdă iar ultima parte, un domeniu sau o adresă IP a gazdei, îl face unic în toată rețeaua. Un nou CallID trebuie generat pentru fiecare nou apel.

Cseq („Command Sequence”, de exemplu Cseq: 1234 INVITE) trebuie să existe în fiecare cerere. Este format din un număr de secvență fără semn și numele metodei. Într-un apel, numărul de secvență este incrementat cu fiecare nouă cerere (cu excepția situației în care cererea este retransmisia unei alte cereri) și are la început o valoare aleatoare. Server-ul trebuie să copieze valoarea acestui câmp în toate răspunsurile ce sunt determinate de cererea ce îl conține.

From (de exemplu From: popescu<sip: [anonimizat]>). Acest câmp trebuie să fie prezent în toate cererile și răspunsurile. Conține numele utilizatorului ce poate fi afișat în interfața grafică (parte ce poate să lipsească) și adresa de unde a plecat cererea. Informații în plus pot fi adăugate. Trebuie spus că acest câmp este copiat în răspunsuri și astfel câmpul: From din răspuns nu-l indică pe cel ce la trimis.

To (de exemplu To: ionescu<sip: [anonimizat]>; tag=287747). Acest câmp trebuie să fie prezent și în cereri și în răspunsuri și indică destinația dorită a cererii. Este copiat în răspuns. Valoarea câmpului „tag” identifică destinația în cazul în care un identificator URI SIP indică mai multe terminale posibile. În cazul acestei situații în răspunsuri se introduce acest câmp „tag” cu o valoare aleatoare pentru a se putea distinge între mai multe terminale.

Via (de exemplu Via: SIP/2.0/UDP/PXY1. Furnizor.ro; received 10.0.0.3). Câmpul Via este folosit pentru a înregistra ruta urmată de către o cerere, pentru a permite serverelor SIP intermediare să trimită răspunsurile pe aceeași rută. Pentru a realiza acest lucru fiecare server proxy adaugă în antet un nou câmp Via la cele existente. Receptorul unei cereri poate adăuga parametri opționali (Ex: pentru a indica că a primit o cerere de la o adresă care nu se află în ultimul câmp Via). Folosind această informație un server proxy poate trimite răspunsul către transmițătorul original, chiar dacă pe ruta dintre ei se află un dispozitiv NAT ce translatează adresele de rețea. Când parametrul „maddr” ce indică existența unei adrese multicast este prezent în câmpul Via, răspunsul este trimis folosind o transmisie multicast la adresa specificată după „maddr” și timpul de viață este stocat în parametrul ttl. Existența acestui câmp arată că SIP a fost proiectat având în vedere problemele IP.

Encryption (de exemplu: Encryption: PGP version=2.6.2, encoding=ascii). Acest câmp arată că în corpul mesajului și posibil anumite mesaje din antet sunt codate.

Antetul ce se referă la corpul mesajului conține următoarele câmpuri:

Content-Type (de exemplu Content-Type: application/sdp). Acesta descrie tipul informației din corpul mesajului. În exemplul dat, antetul este urmat de o descriere a unei sesiuni în format SDP. Un alt exemplu de valoare posibilă este text/html.

Content-length. Indică numărul de octeți al corpului mesajului.

Câmpurile ce apar numai în mesajele de cerere sunt conținute în antetul cerere și au următoarea semnificație:

Accept (de exemplu Accept: application/sdp, text/html). Acest câmp opțional indică ce tipuri de informații sunt permise în răspuns. Sintaxa este specificată în RFC-ul 1288.

Accept-Language (de exemplu Accept-Language: fr, en-gb; q=0.8, en; q=0.7). Acesta indică în ce preferă apelantul să se vorbească. Sintaxa este de asemenea prezentată în RFC 1288.

Expires (folosit la mesajele INVITE și REGISTER; de exemplu Expires: Thu, 01 Dec 2004 16:00:00 GMT sau Expires: în 5 secunde). Pentru un mesaj de înregistrare, acest câmp indică pentru cât timp înregistrarea va fi validă. Înregistratorul poate scurta această perioadă în răspunsul său. Pentru un mesaj de invitare, acest câmp poate fi folosit pentru limitarea duratei de căutare.

Priority (de exemplu Priority: emergency). Valorile posibile sunt cele indicate în RFC 2076 plus „emergency”.

Record Route (folosit de asemenea și în mesajele de răspuns; de exemplu Record Route: sip: centrală. Home.ro; maddr=192.190.123.234; sip: facturare. Firma.ro; maddr=192.194.126.23). Unele servere proxy pot adăuga elemente noi la acest câmp dacă vor să fie pe calea urmată de semnalizări. În exemplul dat cererea a trecut printr-un proxy de facturare și apoi printr-o centrală. Asemenea entități trebuie să monitorizeze starea apelurilor pentru a-și îndeplini scopul.

Subject (de exemplu Subject: Conferință despre SIP). Acesta conține un text fără o sintaxă bine definită și are ca scop informarea apelatului despre ce va fi vorba în apel.

Metodele SIP sunt listate mai jos:

INVITE: o cerere INVITE invită un utilizator sau un serviciu să participe într-o sesiune. Corpul mesajului conține o descriere a mesajului.

ACK: cererea ACK confirmă că apelantul a primit un răspuns final la o cerere INVITE, confirmă un răspuns afirmativ.

OPTIONS: această metodă se ocupă cu informațiile privind caracteristicile participanților și află caracteristicile receptorului.

BYE: cererea BYE închide un apel sau termină o cerere de apel, putând fi trimisă și de apelant și de apelat.

CANCEL: cererea CANCEL termină o cerere de apel nerezolvată dar nu afectează apelurile ce sunt în desfășurare.

REGISTER: metoda REGISTER este folosită pentru a înregistra locația curentă a utilizatorului. Această metodă este folosită și atunci când sunt mai multe server-e SIP pe un singur calculator. În acest caz doar un singur server poate folosi portul asociat SIP.

INFO: reprezintă informația din timpul apelării cum ar fi tonurile DTMF.

PRACK: este o confirmare provizorie.

Alte metode ar mai putea fi COMET, SUBSCRIBE și NOTIFY. Metodele care nu sunt recunoscute de server-ele proxy sau de îndrumare sunt tratate ca fiind metoda OPTIONS și trimise ca atare. Metodele care nu sunt recunoscute de un agent server sau un registrator provoacă un răspuns de tipul 501 Server Failure (eroare server).

Antetul poate fi urmat de un corp al mesajului separat de acesta printr-o linie goală (albă). Pentru cererile ACK, INVITE și OPTIONS corpul este mereu o descriere a unei sesiuni. Câmpul Content-Type trebuie să conțină tipul informației. În exemplele date tipul corpului mesajului este de tip S.D.P. (Session Description Protocol).

După ce a primit și a interpretat mesajul, sistemul răspunde cu un mesaj de răspuns SIP. Linia de stare a acestuia este formată din versiunea SIP, codul ce indică răspunsul și o frază de motivare a răspunsului. Această frază este o descriere textuală scurtă a codului. Formatul răspunsului este arătat în continuare:

Răspuns: linie de stare

*(antet general | antet răspuns | antet al corpului mesajului)

CRLF

[corpul mesajului]

Linie de stare= versiunea SIP SP codul SP frază de motivare CRLF

Codul= Informațional | Succes | Îndrumare către alte adrese| Eroare client | Eroare server | Eroare globală | Cod extins (3 cifre)

Frază de motivare= text codat UTF-8, fără CR, LF

Codul este un număr întreg format din trei cifre, prima cifră indicând tipul răspunsului:

1XX: Informațional: indică faptul că s-a primit cererea și procesarea acesteia continuă. Acesta nu este un răspuns definitiv spre deosebire de restul. Exemplu: 180 RINGING (Sună).

2XX: Succes: răspunsul arată că s-a primit cererea, a fost înțeleasă și acceptată. Exemplu: 200 OK.

3XX: Îndrumare către alte adrese: trebuie să se facă operații în plus pentru ca cererea să fie îndeplinită. Exemplu: 302 MOVED TEMPORARILY (mutat temporar).

4XX: Eroare client: cererea conține greșeli de sintaxă sau nu poate fi îndeplinită la acest server. Exemplu: 404 NOT FOUND (nu s-a găsit destinația dorită).

5XX: Eroare server: serverul nu poate să îndeplinească o cerere ce pare validă. Exemplu: 501 NOT IMPLEMENTED (nu este implementată acțiunea cerută)

6XX: Eroare globală: Cererea nu s-a putu îndeplini la nici un server. Exemplu: 600 BUSY EVERYWHERE (ocupat peste tot).

Acest mod de clasificare permite adăugarea de noi coduri foarte ușor. Când un terminal mai vechi primește un răspuns ce are un cod CXX pe care nu-l cunoaște, acesta îl tratează ca fiind C00. Astfel și cele mai vechi terminale pot reacționa inteligent atunci când se confruntă cu coduri necunoscute. Acestea pot da informații adiționale utilizatorului dacă frază de motivare este prezentă.

2.3. Interconectarea SIP – H323.

Cele două protocoale se ocupă cu inițierea, controlul și terminarea conversațiilor multimedia. Deoarece fiecare dintre acestea au o arhitectură separată și mesaje distincte care numai în aceste arhitecturi funcționează, pentru legarea unei rețele SIP cu o rețea H.323 este nevoie de un echipament numit „gateway” ce trebuie să implementeze cele două protocoale, pentru a face schimbul de informații între cele două rețele. Acest echipament poate juca următoarele roluri:

pe partea cu rețeaua H.323 joacă rolul de terminal H.323 și pe partea cu rețeaua SIP joacă rolul de agent server sau client;

pe partea cu H.323 joacă rolul unui Gatekeeper iar pe partea cu SIP a unui registrator și/sau server proxy.

O imagine a unei interconectări simple între cele două rețele este prezentată în figură următoare

Figura I.16 Interconectarea rețelelor SIP și H.323

Deoarece H.323 folosește în semnalizare mesaje din mai multe protocoale (de exemplu RAS, H.255 și H.245) și în mai multe etape, timpul de inițializare a apelurilor este mare în comparație cu SIP. Dacă se folosește modul de semnalizare denumit „FastStart” acest timp se reduce ajungând comparativ cu cel al protocolului cu care este în competiție.

Folosind acest mod în tabelul următor se prezintă mesajele ce sunt folosite pentru inițializarea unei sesiuni și cum sunt ele transformate din mesaje de semnalizare H.323 în mesaje SIP.

Pentru deschiderea unui nou flux de date se folosesc mesajele ce urmează

Capitolul 4. Calitatea vocii în rețele de date

Calitatea reprezintă un factor important în diferențierea rețelelor noi apărute ce oferă servicii VoIP (voce peste rețele de pachete de date), dar și a echipamentelor folosite.

De aceea măsurarea calității vocii într-un mod obiectiv, sigur și ieftin devine foarte importantă. Calitatea poate însemna mai multe lucruri din mai multe de puncte de vedere. Pe de o parte, calitatea vocii este un mod de a descrie și a evalua fidelitatea vocii, inteligibilitatea și caracteristicile semnalului vocal analog. Pe de altă parte, calitatea vocii poate descrie performanțele mecanismului de transport folosit.

Rețeaua PSTN tradițională a rezolvat problema calității prin optimizarea circuitelor pentru banda folosită de voce și pentru ritmul conversației. Această rețea a ajuns să furnizeze servicii de bună calitate pentru aplicații în timp real ce au nevoie de întârzieri mici, jitter mic și bandă constantă dar mică. Cu toate că PSTN nu prezintă o calitate a vocii excepțională, utilizatorii s-au obișnuit cu acesta și compară celelalte servicii folosind PSTN ca reper.

Spre deosebire de rețeaua de telefonie tradițională, rețele IP au fost proiectate să ofere servicii aplicațiilor ce nu au cerințe de timp real, cum ar fi transferul fișierelor sau e-mail. Aceste aplicații creează un trafic în rafale și uneori cer bandă însemnată, dar nu sunt afectate de întârzieri sau variația acestora. Pentru a putea folosi aplicațiile de timp real, rețelele IP trebuie să aibă și mecanisme care să asigure calitatea serviciilor (QoS) necesară pentru transportul datelor. Utilizatorii PSTN s-au obișnuit cu o calitate foarte bună a vocii. Furnizând o calitate comparabilă a serviciilor va duce la acceptarea și succesul aplicațiilor de voce prin rețelele de pachete.

VoIP, prin introducerea de codecuri neliniare și prin impunerea de termeni privind livrarea pachetelor unor rețele ce nu au fost proiectate pentru cerințe de acest gen, face ca menținerea calități vocii dificilă. Transmisia, folosind acest tip de rețele, care nu pune nici o problemă traficului de date care nu este în timp real poate pune probleme serioase traficului în timp real.

4.1. Factorii care influențează trasnsmisia

Transmisia este afectată de: bandă în timp real, întârzierile datorate proceselor din “gateway-uri”, pierderea pachetelor, întârzierile și codecurile neliniare.

Multe tipuri de rețele de date nu pot să asigure banda necesară pentru transportul vocii. Rețele de date nu asigură o întârziere mică și nici măcar constantă. Introducerea semnalului vocal în aceste rețele necesită folosirea de metode care să asigure transportul în timp real, calitatea vocii putând avea de suferit dacă aceste metode nu funcționează cum trebuie. Cu toate că vocea în timp real necesită o bandă rezonabilă, necesarul efectiv este ori o bandă constantă pentru codecurile liniare ori o bandă oarecare pentru codecurile cu rată mică. Cu toate că furnizorii de servicii asigură o bandă suficientă pentru aplicațiile de voce fără a afecta traficul de date obișnuit, se folosesc și tehnici de compresie în particular pentru traficul în timp real ce are ca destinație un calculator personal. Compresia neliniară poate fi o cauză majoră pentru scăderea calități vocii.

Rețele VoIP se bazează pe procesele care de multe ori sunt realizate în “gateway-uri” pentru prevenirea unor probleme de calitate. De exemplu, eliminarea perioadelor de liniște poate preveni crearea și transmiterea de pachete pe perioadele dintre frazele vorbite. La fel, suprimătoarele de ecou sunt necesare pentru a elimina ecoul atunci când devine perceptibil atunci când rețeaua introduce întârzieri. Dacă procesele de acest timp nu funcționează cum trebuie calitatea vocii are de suferit.

Aplicațiile compensează pierderea pachetelor prin retransmiterea pachetelor pierdute folosind TCP. Aplicațiile de date cum ar fi transferul de fișiere și e-mail sunt mai puțin afectate de timpul în care această retransmisie are loc, dar traficul de voce în timp real nu poate accepta această întârziere. În plus VoIP folosește UDP care nu garantează livrarea pachetelor. Pachetele pierdute înseamnă informație pierdută.

Întârzierea percepută de către utilizator poate fi proveni din timpul în care sistemul său rețeaua transformă semnalul analog în semnal digital, creează pachetele, transmite, rutează și stochează într-un buffer un semnal de voce. Această întârziere poate să creeze probleme într-o conversație și poate să mărească impactul provocat de alte probleme cum ar fi ecoul.

Un motiv important pentru măsurarea calități vocii este dezvoltarea și folosirea codecurilor neliniare ce comprimă vocea astfel încât se transmite informația importantă fără a se transmite tot semnalul vocal. Cu alte cuvinte aceste codecuri conservă cum sună vocea fără a păstra toate frecvențele semnalului.

În general, se poate exprima și măsura calitatea vocii în funcție de ascultătorul și vorbitorul ce au luat parte la conversație. Calitatea trebuie măsurată capăt la capăt. Adică indiferent de sisteme, aparate și metode de transmisie, acesta trebuie examinată din punctul de vedere al utilizatorului. Dar natura subiectivă a acestui tip de evaluare calitativă însoțește orice aspect al calități vocii.

O definiție clară a calității vocii este necesară înainte de a discuta caracteristicile și componentele acesteia. Mulți factori influențează percepția calități unui apel telefonic – de la ușurința cu care acesta este efectuat până la calitatea sunetului din receptor. La un nivel mai ridicat calitatea unui apel este compusă din calitatea serviciului, calitatea sunetului și calitatea conversației. Acestea sunt interdependente atunci când un utilizator trebuie să-și spună părerea despre calitatea unui apel. De exemplu, acesta poate tolera, ignora sau poate să nu observe o calitate mai proastă a sunetului atunci când calitatea serviciilor este foarte bună. Utilizatorii telefoanelor mobile sau cei care poartă conversații prin satelit la mare distanță pot tolera sau ignora problemele de sunet din cauza avantajelor aduse de apel. Un alt exemplu este și calitatea conversației. Când există o întârziere perceptibilă între frazele ascultătorului și ale vorbitorului, mulți utilizatori percep această situație ca o problemă de calitate a serviciului sau a sunetului.

Multe aspecte ale calități serviciilor sunt strâns legate de problemele și deciziile luate de furnizorul de servicii și mai puțin legate de performanța rețelei și funcționarea echipamentelor de rețea. Totuși, calitatea sunetului și a conversației par strâns legate de dispunerea rețelei și performanța acesteia. Din această cauză, calitatea vocii este rezultatul măsurării calitative și cantitative a calități sunetului și a conversației.

Voi face în continuare o prezentare mai detaliată a principalelor factorii care au impact în calitate: pierderea pachetelor; întârzierile; jitterul

Pierderea de pachetelor, este un lucru comun în rețelele cu comutație de pachete, deoarece pe măsură ce rutele devin congestionate, cozile de așteptare în elementele de rutare devin neîncăpătoare și nu va mai fi loc pentru alte pachete și acestea vor fi “aruncate”. Pierderea de pachete poate duce la degradarea calității vocii. Fiecare pachet conține între 20 – 80ms, în funcție de codecul folosit, din semnalul captat de microfon. Când sunt doar câteva pachete pierdute, creierul uman este capabil să reconstruiască zonele pierdute, dar dacă numărul pachetelor este mare vocea redată este neinteligibilă. În continuare sunt prezentate tehnicile prin care se poate rezolva problema pierderii pachetelor:

Îmbunătățirea rețelei. Deoarece fenomenul de aruncare a pachetelor este strâns legat de banda insuficientă a conexiunilor și de viteză de procesare a elementelor de rutare, îmbunătățirea rețelei poate fi o soluție pentru această problemă.

Înlocuirea cu pauze. La destinație conținutul pachetelor este redat, apărând probleme atunci când pachetele a căror informație trebuia redată nu mai sosesc fiind întârziate sau pierdute. Înlocuirea cu pauze rezolvă această problemă prin redarea de liniște în locul informației din pachețele pierdute. Din păcate, dacă rata de pierdere a pachetelor este prea mare sau pachetele sunt prea mari (adică conțin fragmente mari de semnalul captat) în semnalul redat apar frânturi din semnalul original, lucru ce deteriorează semnificativ calitatea vocii.

Înlocuirea cu zgomot. Această metodă înlocuiește zonele fără informație cu zgomot. Studiile arată că se obțin performanțe mai bune decât metoda precedentă.

Repetarea pachetelor. Redarea informației din ultimul pachet recepționat corect, atunci când un pachet lipsește este o altă metodă de a recupera din pagubele produse de pierderea de pachete.

Interpolarea pachetelor. Folosește caracteristicile vocii din pachețele învecinate pentru a estima informația audio ce s-a pierdut. Sunt câteva tehnici de interpolare și studiile în această privință au arătat că această metodă poate avea performanțe mai bune decât cele menționate mai sus.

Întrețeserea eșantioanelor audio pe mai multe pachete (“frame interleaving”). În rețelele cu comutație de pachete fenomenul de pierdere a pachetelor este corelat și astfel nu numai un pachet este pierdut în cazul congestiei ci mai multe pachete consecutive. Acest fapt degradează calitatea vocii considerabil. Întrețeserea eșantioanelor audio pe mai multe pachete poate reduce acest efect. Dezavantajul multor eșantioane pentru a le întrețesa.

Transmisie redundantă. Informația dintr-un pachet este în mod redundant transmisă în pachete consecutive. În cazul în care pachetul original este pierdut, acesta poate fi refăcut din pachețele următoare.

Întârzierea pachetelor provoacă intrarea participanților la o conversație într-un mod de comunicație half-duplex, adică unul dintre ei vorbește și ceilalți așteaptă un timp pentru ca să fie siguri că vorbitorul a terminat ce are de zis. Dacă timpul de așteptare este ales în mod eronat, pot exista doi sau mai mulți vorbitori în același timp. Întârzierile de lungă durată au un efect păgubos și din cauza ecoului care face ca vorbitorul să își audă propria sa voce după un timp după ce a terminat de vorbit. Cerințele exacte în privința întârzieri nu pot fi date din cauză că este un fenomen subiectiv, dar există anumite limite. Se spune că o redare a vocii interlocutorului cu 150ms decalată față de momentul când vorbește, este acceptabilă pentru cele mai multe aplicații. Pe măsură ce întârzierea crește interlocutorii încep să vorbească în același timp sau se confruntă cu un ecou deranjant, adică calitatea convorbirii este foarte scăzută. Totuși, întârzieri între 150 și 400ms sunt acceptate pentru convorbiri între persoane aflate la mare distanță. Întârzierea este una din cele mai mari probleme cu care se confruntă telefonia prin Internet. În rețelele cu comutație de pachete factorii cauzatori sunt:

Întârzierea produsă de codecuri. Funcția principală a unui codec este de a digitaliza semnalul vocal analog, dar și de a realiza o compresie pentru a reduce necesarul de bandă. Ratele mari de compresie pot fi obținute cu ajutorul unor algoritmi ce au ca dezavantaj timpul de procesare destul de mare. Întârzierea este compusă din timpul necesar prelucrării eșantioanelor ce intră într-un singur pachet și din timpul necesar observării eșantioanelor următoare pentru a exploata anumite corelații ce ar putea apare. Timpul necesar decodării este de obicei jumate din timpul necesar codării deci la recepție întârzierea produsă este mai mică decât cea produsă la transmisie.

Întârzierea din cauza transmisiei. Reprezintă timpul necesar pentru a pune un pachet pe linia de transmisiune și este determinat de viteza liniei și de mărimea pachetului.

Întârzierile produse de cozile de așteptare. Acest timp pierdut reprezintă problema cea mai important introdusă de rețelele cu comutație de pachete. Depinde de numărul de pachete ce așteaptă în coadă și variază enorm de la un pachet la altul. Întârzierea produsă de cozile de așteptare este principala problemă pentru aplicațiile în timp real deoarece este o sursă pentru jitter.

Întârzierile cauzate de propagare. Reprezintă timpul necesar pentru că semnalul să ajungă de la un punct al rețelei la celălalt și este determinată de viteza lumini. Acest timp devine important dacă distanțele între puncte este mare cum ar fi cazul legăturilor prin satelit.

Jitterul reprezintă variația duratei de timp între pachetele primite la recepție. Mai poate fi definit ca variația întârzierilor la care sunt supuse pachetelor. Acest fenomen este o problemă importantă ce trebuie depășită în comunicațiile prin voce. Jitterul apare mai ales din cauza întârzierilor produse de cozile de așteptare, dar poate proveni și din faptul că pachetele pot parcurge trasee diferite. Pentru a-l compensa, la recepție, se folosește un buffer în care sunt ținute primele pachetele sosite pentru o durată de timp definită înainte ca informația conținută să fie redată. Întârzierea produsă de acest buffer se adaugă la întârzierea totală deci pentru a avea o comunicație de calitate trebuie să avem de asemenea un jitter mic. În mod ideal, dimensiunea buffer-ului este aleasă în mod dinamic în concordanță cu situația rețelei. De obicei dimensiunea buffer-ului este de 50 – 100ms.

Capitolul 4. Aplicația Voice over IP

4.1. Topografiea rețea

Aplicația practica a fost realizată în Paket Trecer și este compusă din trei rețele locale conectate prin interfețe seriale care au capacitatea de a transporta servicii de voce și date indiferent de locație. Acest model de rețea poate fi folosit într-o societate care are trei locații distincte, cu sediile în trei orașe diferite.

Cele trei rețele locale au o topologie asemănătoare și au fost denumite “LOCAȚII _A, B și C”. Componentele unei singure rețele locale sunt următoarele:

Router tip Cisco 2811

Switch tip Cisco 2950T

IP Phone tip Cisco

Calculatoare

Packert Trecer este o aplicație care simulează vizual echipamentele și procesele de rețea

Corespondete adreselor IP și VLAN-urile associate pentu cele trei rețele sunt următoarele:

LOCAȚIA_A

VLAN-10-Voice-192.168.10.0/24

VLAN-20-Data – 192.168.20.0/24

Interfața serial – 200.1.1.1/24

Număr Ip Phone alocat: 1001, 1002, 1003, 1004

LOCAȚIA_B

VLAN-30-Voice-192.168.30.0/24

VLAN-40-Data – 192.168.40.0/24

Interfața serial – 200.1.1.0/24

Interfața serial IP -99.99.99.99

Număr Ip Phone alocat: 2001, 2002, 2003, 2004

LOCAȚIA_C

VLAN-50-Voice-192.168.50.0/24

VLAN-60-Data -192.168.60.0/24

Interfața serial – 99.99.99.97/24

Număr Ip Phone alocat: 3001, 3002, 3003, 3004

După s-au selectate în Paket Trecer toate componentele necesare aplicației sau făcut legăturile între interfețe și apoi a început configurarea Switch-urilor și Ruterelor

Fiecare Switch s-a configurat separat din modul CLI începând cu asocierea de VLAN-uri distincte pentru de voce dar și pentru date. VLAN (rețea locală virtuală) reprezintă gruparea logică a componenteleor unei rețele locale fără a ține cont de gruparea lor fizică Fiecare VLAN reprezintă un domeniu de broadcast independent, ceea ce permite reducerea încărcării rețelei prin difuzarea de mesaje către toți utilizatorii. VLAN-urile lucrează pe nivele OSI 2 și 3 iar comunicarea se face prin rutare, deci pe nivelul de rețea prin intermediul unui router sau al unui switch la nivelul 3.

Implementarea VLAN-urilor se face pe baza porturilor fizice prin asociere cu anumite porturi din switch/router. Fiecărei rețele virtuale I se aloca o adresă de rețea, acestea adrese sunt incluse în tabelul de rutare. Routerul interconectează VLAN-urile și dirijeza pachetele spre VLAN-ul corespunzător, în interiorul aceluiași VLAN sau între VLAN-uri distincte. Vlan-urile pot împărți același spațiu de adrese, de exemplu adresa IP de rețea sau de subretea

Pentru SwitchA am făcut următoarele configurări la nivel de Command Line Interface:

VLAN Voice 10

VLAN Date 20

Interfața f0/5 mode trunk.

După alocarea VLAN-urilor, s-au definit adresele de rețea aociate VLAN-urilor create mai sus, realizându-se în același timp comanda specifică de encapsulare a adreselor pentru transportul de voce și date prin următoarele comenzi de configurare în Paket Trecer:

Router (config-subif) #encapsulation dot1Q 10

Router (config-subif) #ip address 192.168.10.1 255.255.255.0

Router (config-subif) #exit

Router (config) #int f0/0.20

Router (config-subif) #

Router (config-subif) #encapsulation dot1Q 20

Router (config-subif) #ip address 192.168.20.1 255.255.255.0

Router (config-subif) #exit

Router (config) #ip dhcp excluded-address 192.168.50.1 192.168.50.10

Router (config) #ip dhcp excluded-address 192.168.60.1 192.168.60.10

Router (config) #exit

În acest moment avem configurate adresele IP pentru echipamentele de date, verificând calculatorele din rețeaua locală în tabul Desktop să fie setat pe mod DHCP pentru IP address.

Tot în router la nivelul CLI urmeza configurarea echipamentelor de voce prin alocarea adreselor și liniilor associate. În cazul nostru avem patru telefoane pe o rețea prin urmare comanda de configurare este:

Router (config) #telephony-service

Router (config-telephony) #max-dn 4

Router (config-telephony) #max-ephones 4

Router (config-telephony) #ip source-address 192.168.10.1 port 2000

Router (config-telephony) #exit

După ce am configurat numărul maxim de telefoane și adresa Ip urmează configurarea fiecărui număr de telefon IP:

Router (config) #ephone-dn 1

Router (config-ephone-dn) #%LINK-3-UPDOWN: Int ephone_dsp DN 1.1, changed state to up

Router (config-ephone-dn) #number 1001

Router (config-ephone-dn) #exit

Router (config) #ephone-dn 2

Router (config-ephone-dn) #%LINK-3-UPDOWN: Int ephone_dsp DN 2.1, changed state to up

Router (config-ephone-dn) #number 1002

Router (config-ephone-dn) #exit

Router (config) #ephone-dn 3

Router (config-ephone-dn) #%LINK-3-UPDOWN: Int ephone_dsp DN 3.1, changed state to up

Router (config-ephone-dn) #number 1003

Router (config-ephone-dn) #exit

Router (config) #ephone-dn 4

Router (config-ephone-dn) #%LINK-3-UPDOWN: Inte ephone_dsp DN 4.1, changed state to up

Router (config-ephone-dn) #number 1004

Router (config-ephone-dn) #exit

Pasul final în configurarea telefonelor IP se face prin alocarea liniilor associate pentru fiecare terminal și în anumite situații trebuie configurat inclusiv MAC-address-ul și device type, comenzile de configurare sunt următoarele:

Router (config) #ephone 1

Router (config-ephone) #button 1:1ephone-1 IP:192.168.10.13 Socket:2 DeviceType: Phone hâș registered.

Router (config-ephone) #exit

Router (config) #ephone 2

Router (config-ephone) #button 1:2: ephone-2 IP:192.168.10.12 Socket:2 DeviceType: Phone hâș registered.

Router (config-ephone) #exit

Router (config) #ephone 3

Router (config-ephone) #button 1:3: ephone-3 IP:192.168.10.14 Socket:2 DeviceType: Phone hâș registered.

Router (config-ephone) #exit

Router (config) #ephone 4

Router (config-ephone) #button 1:4: ephone-4 IP:192.168.30.11 Socket:2 DeviceType: Phone hâș registered.

Router (config-ephone) #exit

Router (config) #exit

Configurarea rețelelor locale este funcțională atât pentru voce cât și pentru date.

Concluzii.

Pe piață există echipamente ce suportă H.323 sau SIP dar puține știu să folosească ambele protocoale. În prezent echipamentele ce lucrează cu H.323 sunt mai numeroase decât cele ce folosesc SIP.

În practică, vor exista companii ce vor produce echipamente ce vor folosi unul din cele două protocoale până va fi sigur că unul dintre acestea va dispărea sau până se vor uni într-un alt protocol. Dacă se dorește o funcționare stabilă cu alte implementări atunci se pot alege echipamente ce folosesc H.323 deoarece acest protocol este mai stabil din punct de vedere al standardelor decât SIP. Altfel, cele două protocoale furnizează aceleași servicii. Singura zonă în care se observă o diferență, este inițializarea conferințelor. Deoarece SIP poate fi folosit pentru a invita mai multe persoane să se alăture la un apel, conferințele pot fi inițiate fără existența în mod obligatoriu a unui server pentru conferințe. În practică totuși, dacă aceste amănunte sunt avantaje sau nu depinde de soluția implementată de vânzătorul echipamentului și nu de protocoalele ce sunt folosite.