Diploma - WWW - Tocilar

Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.
Implementarea interfatei VoIP pe o centrala telefonica digitala
CAPITOLUL 1. Tehnologia “Voice over IP”

De ce VoIP ?
Referinţe bibliografice: [1], [8], [17]
Modul de transmisie a vocii prin intermediul telefoniei tradiţionale a atins o adevarată

plafonare, privit din punctul de vedere al inovaţiilor, al uşurinţei de manevrare şi, mai ales, al
preţurilor scăzute la care se poate realiza. Componentele de bază ale telefoniei clasice –
terminalul telefonic, centralele de tip PABX, reţeaua de comutaţie – se străduiesc să ţină
pasul cu accelerata rată de inovaţii care au la bază Internet-ul. Chiar şi serviciile îmbunătăţite,
dintre care amintim “call forwarding”, “call waiting”, “call ID”, nu pot furniza cerinţele
actuale, ale erei “e-commerce”.
În zilele noastre, utilizatorul de telefonie foloseşte telefonul pentru a realiza sau primi
apeluri sau pentru a-şi asculta mesajele vocale. Dar, în acelaşi timp, ar dori ca, în acelaşi
terminal telefonic, să aibă integrate şi facilităţi de navigare pe Internet, verificarea “e-mail”-
ului, etc. Telefoanele clasice de astăzi nu pot furniza aceste facilităţi. În contrast cu toate
aceste limitări, comunicaţiile bazate pe Web au revoluţionat modul de viaţă al fiecăruia dintre
noi. Fiecare poate avea prin intermediul Internet-ului acces la servicii de date, multimedia,
video, etc. Numai in ultimii ani, Internet-ul a generat mai multe inovaţii şi soluţii de
comunicare decât reţeaua telefonică tradiţională în întreaga sa existenţă. Următorul pas pe
care trebuie să-l facem este ca acelaşi ritm de inovaţii să-l aplicăm şi în telefonie şi în modul
de transmisie a vocii.
Reţelele de tip IP ( Internet Protocol ) devin din ce în ce mai atractive pentru a fi
folosite drept suport pentru transportul de voce. S-a avut in vedere pentru luarea acestei
decizii mai ales preţul în continuă scădere al transportului de date. Ne aflăm aşadar în faţa
unui pas important către convergenţa vocii, video şi comunicaţiilor de date prin Internet. S-a
demonstrat fezabilitatea transportului de voce si semnalizării prin Internet, însă furnizarea de
servicii publice şi produse de înaltă calitate, dar mai ales convingerea şi atragerea publicului
către noua tehnologie sunt de-abia la început.
Pagina 1 din 133

VoIP ( Voice over IP ) poate fi definită ca posibilitatea de a realiza apeluri telefonice

şi de a trimie facsimile folosind reţeaua de date IP, cu o calitate sporită şi un raport ridicat
calitate/preţ. Introducerea VoIP pe scară largă poate fi privită ca o
fereastră deschisă pentru producătorii care se vor afla într-o continuă competiţie,
pentru furnizorii de servicii, care vor beneficia de sporirea volumului de trafic transportat, cât
şi pentru utilizatorii finali care sunt interesaţi de integrarea aplicaţiilor de voce şi date în
scopul reducerii cheltuielilor.
Producătorii de tehnologie VoIP sunt conştienţi că nu vor reuşi să înlocuiască
telefonia clasică, nici măcar să realizeze o schimbare dramatică în scurt timp. Scopul lor
imediat ar fi acela de a reproduce calităţile oferite la momentul actual de PSTN ( Public
Switched Telephone Network ) la un preţ semnificativ mai scăzut şi de a oferi o alternativă
viabilă acesteia. Prima măsură de succes pentru VoIP ar putea fi reducerea costurilor
convorbirilor realizate pe distanţe mari.
O altă aplicaţie imediată pentru telefonia IP este transmisia facsimilelor în timp real.
Până acum, serviciile de transmitere de facsimile foloseau în mod obişnuit conexiuni PSTN
de dial-up, la viteze de 14.4 Kbps. Calitatea transmisiilor prin intermediul fax-ului era
afectată de întârzierea prin reţea, compatibilitatea maşinilor şi calitatea semnalului analogic.
Pentru trimiterea fax-urilor prin intermediul reţelelor de pachete, o unitate de interfaţă va
trebui să realizeze pachetizarea datelor de transmis, conversia de semnalizări şi protocoalele
de control şi să se ocupe de asigurarea transferului complet al datelor scanate. Pierderea de
pachete şi întârzierea capăt-la-capăt au o importanţă negativă mult mai mare decât în
aplicaţiile de voce.
Majoritatea aplicaţiilor pe suport VoIP sunt considerate de timp real. Se aşteaptă
totuşi şi implementare serviciilor de voce de tip store-and-forward. Un exemplu ar fi acela de
prelucrare a mesajelor de voce local, care apoi să fie trimise către o căsuţă poştală de mesaje
vocale prin intermediul Intranet-ului sau al serviciilor Internet. Documentele însoţite de
mesaje vocale, fişiere multimedia, etc. nu vor mai reprezenta un lucru ieşit din comun în
viitorul apropiat folosind tehnologia VoIP.
Creşterea pieţei de desfacere a aplicaţiilor bazate pe serviciile VoIP se aşteaptă să fie
considerabilă în următoarea perioadă datorită unor mari avantaje. În general, acestea se pot
împărţi în mai multe categorii:
Pagina 2 din 133

Reducerea costurilor – Se pot realiza mari reduceri de cheltuieli în cazul convorbirilor

pe distanţe mari, lucru care este foarte important pentru multe companii, mai ales pentru cele
cu piaţa de desfacere internaţională.
Simplitate – Integrarea serviciilor de voce şi date într-o unică reţea de transport

permite reducerea numărului de echipamente complementare.
Aplicaţii avansate – Avantajele pe termen lung ar fi acelea că VoIP include suportul
pentru aplicaţiile multimedia şi multiserviciu (e-commerce, etc.), aplicaţii care astăzi nu pot fi
realizate prin intermediul sistemului telefonic.
Câteva exemple de aplicaţii VoIP care vor fi dezvoltate ar fi:
PSTN gateway – realizează interconectarea dintre PSTN şi reţeaua IP. Acest
dispozitiv poate fi integrat în PABX, sau poate funcţiona ca un dispozitiv de sine stătător.
Telefoane Internet – telefoanele obişnuite pot fi îmbunătăţite pentru a putea fi aparate
cu acces Internet, alături de serviciile obişnuite pe care le furnizează.
Legăturile inter-office folosind reţeaua privată de date Intranet – Se pot înlocui
legăturile pe liniile telefonice prin intermediul reţelei private, realizându-se economii
financiare substanţiale.
Acces la distanţă – Un mic birou poate avea acces la serviciile de date, voce, facsimil
folosind Intranet-ul.
Apeluri telefonice realizate de la un PC mobil prin intermediul Internet-ului , etc.
Obiectivul numărul 1 al proiectanţilor în domeniul VoIP este destul de simplu:
adăugarea facilităţilor ce ţin de telefonia clasică ( voce şi semnalizări ) reţelelor bazate pe
tehnologia IP şi interconectarea acestora atât cu reţeaua telefonică publică, cât şi cu reţelele
telefonice private. Se urmăreşte de asemenea menţinerea actualelor standarde de calitate ale
convorbirilor telefonice.
Fig. 1.1.1. Arhitectura VoIP. [16]
Provocările cărora proiectanţii trebuie să le

găsească soluţii sunt:
Pagina 3 din 133

Calitatea convorbirilor realizate peste reţeaua IP trebuie să fie dacă nu mai mare, cel
puţin ca cea oferită de reţeaua telefonică publică PSTN, în ciuda faptului că se pot străbate
reţele cu un QoS ( Quality of Service ) variabil.
Reţeaua suport IP trebuie să aibă stricte criterii de performanţă, incluzând aici un cât
mai mic număr de convorbiri rejectate, pachete pierdute; întârzierea prin reţea trebuie să fie
cât mai mică, iar apelurile pierdute datorită problemelor reţelei cât mai puţine.
Controlul apelului din reţeaua IP trebuie să fie transparent semnalizărilor telefonice,
astel încât utilizatorului să nu-i pese pe baza cărei tehnologii se realizează conexiunea.
Serviciile de interconectarea PSTN/VoIP implică utilizarea de “gateway”-uri între
reţeaua de voce şi reţeaua IP.
Cursa având ca scop producerea de echipamente VoIP care să acopere o cât mai mare
paletă de cereri venite din partea beneficiarilor este în plină desfăşurare. Este nevoie de
adoptarea şi implementarea multor standarde, iar actualelor reţele le este necesară
implementarea QoS-ului. Adoptarea VoIP-ului trebuie să fie o alternativă viabilă chiar în
contextul scăderii pronunţate şi constante a preţurilor la telefonie.
Asigurarea unui nivel calitativ cel puţin egal cu al serviciilor PSTN este privită ca o
cerinţă de bază, în ciuda argumentelor venite din partea anumitor producatori potrivit cărora
problema cost-funcţionalitate-calitate ar fi prioritară. Deşi QoS se referă în principal la
fidelitatea de a transmite voce şi facsimil, se poate de asemenea aplica şi la disponibilitatea
reţelei la facilităţi ale reţelei telefonice ( conferinţă, afişarea numărului apelantului, etc. ) şi
scalabilitate.
Una dintre cele mai importante evoluţii oferite de VoIP este pre-procesarea software a
conversaţiilor de voce. S-a ajuns la concluzia ca 50 – 60 % din discursul telefonic dintre 2
persoane este de fapt … pauză. De accea, inginerii au găsit o metodă contra acestui neajuns:
suprimarea pauzelor. Poate cea mai mare facilitate a VoIP-ului este aceea că, astfel, de acum
încolo plata se va face conform cu volumul de trafic generat, nu ca până acum ca produs de
bandă x timp, produs ce duce la o irosire a resurselor reţelei.
1.2. Probleme şi constrângeri

Referinţe bibliografice: [1], [8], [9], [13], [17], [18]
Pagina 4 din 133

Implementările tehnologiei Voice over IP (VoIP) permit utilizatorilor să transporte

traficul de voce folosind o reţea de tip IP ( Internet Protocol ). 3 mari motive au dus la
dezvoltarea şi evoluţia accelerată a pieţei în domeniul VoIP:
Costurile reduse ale convorbirilor telefonice.
Integrarea serviciilor.
Integrarea infrastructurilor de oferire a serviciilor de voce si date.
Internet Protocol este un protocol de nivel 3, corespunzător stivei OSI, fără conexiune
în care pachetele pot urma diferite rute pe drumul lor spre destinaţie. Aceste rute sunt în
acelaşi timp încărcate cu trafic aferent atâtor altor comunicaţii. Protocolul permite alocarea
eficientă a resurselor reţelei, pe măsură ce pachetele sunt îndrumate pe diferite căi mai puţin
congestionate.
Evoluţia tehnologiei Voice over IP a avut şi are o mulţime de obstacole datorate
suportului de transmisie a pachetelor de voce, am numit aici reţelele de tip Internet Protocol
(IP). Acestea, fiind de tipul “best-effort”, nu garantează serviciile oferite. Datele pot ajunge la
recepţie în ordine schimbată faţă de cea de la emisie, pachetele pot urma diferite rute prin
reţea, cu diferite încărcări ale link-urilor, sau pot fi, în cazul cel mai grav, pierdute în situaţii
de congestie. Timpul de traversare a reţelelor este variabil în limite foarte largi. Pentru a
corecta şi a masca nivelelor superioare aceste neajunsuri ale reţelei se folosesc la nivel
“transport” protocoalele TCP şi/sau UDP, în funcţie de aplicaţia dorită.
Aparent, toate aceste “defecte” ale reţelelor de tip IP fac imposibilă dezvoltarea
aplicaţiilor de timp real, în general, şi a celor de voce, video, multimedia, în special, aplicaţii
care sunt în mod critic dependente de timp şi care au nevoie de asigurarea unui QoS destul de
ridicat din partea reţelei suport. În general, în acest tip de aplicaţii nu se foloseşte protocolul
de transport TCP pentru că deşi el garanteaza furnizarea la nivelele superioare a
secvenţialităţii pachetelor, tehnicile lui de control de congentie, control de flux, dar mai ales
control al erorilor prin retransmisie folosind timere nu numai că nu ajută în problema de faţă,
dar încurcă teribil fluxul de date de timp real.
Menţinerea unei calităţi acceptabile, în ciuda problemelor legate de variaţia

performanţei reţelei este reuşită prin folosirea mai multor tehnici: compresia, eliminarea
pauzelor din vorbirea umană şi implementarea QoS-ului în reţelele de transport. Evoluţia
accelerată a componentelor hardware din ultima vreme a făcut posibile multe dintre aceste
tehnici folosite.
Pagina 5 din 133

Problemele specifice trasportului de voce venite din partea reţelei, cărora proiectanţii
au trebuit să le găsească soluţii ar putea lua următoarele aspecte:
Întârzierea capăt-la-capăt – este una dintre cele mai neplăcute probleme care apar în
cazul transportului vocii pachetizate peste o reţea IP. Ea este la originea a 2 probleme: ecoul
şi suprapunerea parţială a discursului telefonic.
Ecoul este cauzat de reflexia vocii celui care vorbeşte, produsă la celălalt capăt al
convorbirii telefonice, care ajunge la urechea vorbitorului. Ecoul devine o mare problemă
atunci când întârzierea dus-întors are o valoare mai mare de 50 milisecunde. În condiţiile în
care ecoul este considerat o mare limitare a calităţii, transmiterea vocii peste o reţea de
pachete trebuie să ţină seama de controlul ecoului, dar mai ales de modalităţi de reducere a
lui.
Suprapunerea discursului devine semnificativă dacă întârzierea într-un singur sens
depăşeşte 250 milisecunde.
Sursele de generare a întârzierii capăt-la-capăt, în cazul unui apel având ca suport o
reţea de pachete, sunt:
Întârzierea de acumulare – uneori numită şi întârzierea algoritmică, ea este cauzată de
nevoia de a colecta mai multe eşantioane de voce pentru a fi procesate de către codor.
Aceasta depinde de tipul de codor de voce folosit şi poate ajunge de la peioada de eşantionare
( 0.125 ms ) la câteva milisecunde. O listă reprezentativă de codoare de voce folosite este:
G.726 – ADPCM – 16, 24, 32, 40 kb/s – 0.125 ms
G.728 LD – CELP – 16 kb/s – 2.5 ms
G.729 CS – ACELP- 8 kb/s – 10 ms
G.723.1 – Codor multirată – 5.3, 6.3 kb/s – 30 ms.
Întârzierea de procesare – este cauzată de procesele de codare si colectare a
eşantioanelor de voce, codate deja, pentru a fi “împachetate” şi trimise în reţeaua IP.
Întârzierea de codare – depinde în egală măsură de timpul de execuţie al procesului şi

de tipul algoritmului folosit. De obicei, sunt colectate mai multe cadre de voce codată într-un
singur pachet de date, pentru a reduce overhead-ul în reţeaua de pachete. Spre exemplu, 3
cadre de voce codată cu G.729, însemnând 30 milisecunde de discurs, pot fi adunate şi
incluse într-un singur pachet.
Pagina 6 din 133

Întârzierea în reţea – are drept cauze timpul de propagare pe mediul fizic,

protocoalele folosite pentru transmisia pachetelor de date materializate prin întârzierile
datorate procesărilor în routerele intermediare şi buffer-ele folosite pentru înlăturarea jitter-
ului pachetelor în partea de recepţie. Timpul de întârziere este funcţie de capacitatea link-
urilor de date de pe drumul parcurs de pachete şi de întârzierile care apar în procesarea lor pe
măsură ce traversează reţeaua IP. Buffer-ele care ajută la eliminarea jitter-ului ( variaţiile
momentelor la care pachetele ar fi trebuit să sosească, dacă n-ar fi fost afectate de întârzierea
prin reţea ) adaugă întârziere. Această întârziere ar putea avea o importantă contribuţie la
întârzierea totală, pe măsură ce variaţia întârzierii pachetelor în reţea poate avea valori între
70-100 ms, în anumite reţele IP.
Figura 1.2.1. Întârzierea în reţea datorată procesării în nodurile traversate şi în “jitter
buffer”-ul de
recepţie. [17]
Figura 1.2.2. Întârzierea totală de transmisie. [17].
Pagina 7 din 133

Jitter-ul – reprezintă variaţia momentelor la care pachetele ar fi trebuit să sosească la

recepţie, în cazul în care nu ar fi fost afectate de întârzierea traversării reţelei.
Figura 1.2.3. Jitter-ul
– variaţia momentelor de
sosire a pachetelor IP. [17].
Problema reducerii
întârzierii totale include şi
necesitatea eliminării acestui jitter. Acest lucru presupune adunarea pachetelor şi menţinerea
lor suficient de mult, permiţând astfel şi celui mai lent, celui mai afectat de reţea, să ajungă la
recepţie în timp util pentru a fi redat în secvenţa corectă.
Cele 2 scopuri urmărite, de minimizere a întârzierii şi de înlăturare a jitter-ului, au
produs diverse scheme de adaptare a buffer-ului de recepţie pentru a corespunde cerinţelor
variabile în timp ale înlăturării jitter-ului. Această adaptare are atât scopul explicit de a
minimiza dimensiunea şi întârzierea buffer-ului pentru eliminarea jitter-ului, cât şi prevenirea
golirii buffer-ului.
În cele ce urmează, vom prezenta 2 soluţii de adaptare a dimensiunii “jitter buffer”-
ului. Ele au o mare dependenţă de reţeaua de pachete care este folosită drept suport de
transmisie.
Prima variantă ar fi măsurarea variaţiei nivelului de pachete din “jitter buffer” de-a
lungul unei perioade de timp şi adaptarea prin creştere a dimensiunii buffer-ului pentru a se
potrivi jitter-ului calculat. Această soluţie dă cele mai bune rezultate în cazul reţelelor care
cauzează un jitter consistent de-a lungul timpului, spre exemplu reţelele ATM.
A doua variantă este de a contoriza numărul de pachete care sosesc cu întârziere şi de
a raporta numărul acestor pachete la numărul de pachete corect procesate. Această proporţie
poate fi apoi folosită la ajustarea “jitter buffer”-ului, care să poată face faţă în cazul unei
predeterminate rate
permise a pachetelor sosite cu întârziere. Soluţia are mare utilizare în cazul reţelelor
cu variaţie foarte mare a intervalelor de sosire a pachetelor. Este cazul aici şi al reţelelor de
tip IP.
Trebuie totuşi menţionat că, pe lângă aceste tehnici descrise, reţeaua, de orice tip ar fi
ea, trebuie configurată şi gestionată pentru a furniza întârzierea şi jitter minime, permiţând
astfel un QoS consistent.
Pagina 8 din 133

Compensarea pachetelor pierdute în reţea – pierderea pachetelor conţinând

eşantioanele codate, sau necodate de voce poate fi o şi mai severă problemă, în funcţie de
tipul de reţea folosit. Din cauza faptului că reţeaua IP este o reţea care nu garantează
serviciile oferite de ea, pachetele de voce sunt expuse la un risc de pierdere mult mai mare
decât în cazul altor reţele. În momentul de faţă, reţelele IP tratează pachetele de voce ca pe
nişte obişnuite pachete de date. În situaţia apariţiei încărcării excesive cu trafic, sau a
congestiei, cadrele de voce vor fi înlăturate la fel ca orice alt pachet de date. Însă, cadrele de
date nu sunt sub presiunea timpului, iar înlăturarea lor poate fi corectată prin procese de
retransmisie, spre deosebire de pachetele de voce care nu pot fi tratate în această manieră.
Câteva modalităţi de a rezista în faţa pericolului pierderii pachetelor de voce datorat
reţelelor IP ar fi:
Interpolarea pachetelor de voce pierdute – se realizează prin redarea pe perioada în
care pachetul pierdut ar fi trebuit redat, a ultimului pachet recepţionat. Aceasta este o soluţie
simplă care are menirea de a ocupa cumva timpul dintre cadrele neconsecutive de voce
recepţionate. Funcţionează destul de bine în situaţia în care riscul de pierdere al pachetelor
este mic, dar rezultatele ei sunt foarte slabe atunci când pachetele sunt pierdute în rafale.
Trimiterea de informaţie redundantă, în schimbul utilizării benzii – aceasta abordare
transmite o replică a celui de-al “n”-lea pachet de voce împreună cu cel de-al “n+1”-lea. Are
avantajul că este posibil de corectat pierderea exactă a pachetelor. Oricum, marele dezavantaj
al acestei metode este că utilizează mai multă bandă şi generează o mai mare întârziere.
Folosirea unei tehnici intermediare – care să folosească mult mai puţină bandă, iar
codorul să furnizeze informaţie redundantă transportată în cel de-al “n+1”-lea pachet. Aceasta
reduce problema folosirii de bandă suplimentară cerută, dar nu rezolvă adaosul de întârziere.
Compensarea ecoului – Într-o reţea telefonică, ecoul este cauzat de reflexia

semnalului, care are loc în circuitul de trecere de la 4 fire ( câte o pereche pentru fiecare sens
de transmitere a semnalului telefonic ) la 2 fire ( o singură pereche pe care se realizează
ambele sensuri ). Vocea celui care vorbeşte este auzită datorită reflexiei tot de către el.
a. b.
Pagina 9 din 133

Figura 1.2.4. Ecoul – locul şi motivul apariţiei [18].

a. Trecerea de la 2 la 4 fire în care impedanţa trebuie să fie aceeaşi la ambele capete.
b. Nepotrivirea celor 2 impedanţe – cauza ecoului.
Ecoul se întâlneşte în reţeaua telefonică bazată pe comutaţia de circuite, însă acolo

este cu mult mai puţin deranjant, întrucât întârzierea dus-întors prin reţea este mai mică de 50
milisecunde.
În reţelele de pachete, ecoul devine o problemă datorită întârzierii dus-întors prin
reţea, care este în mod obişnuit mai mare de 50 ms. De aceea, eliminarea lui este mereu
folosită. Standardul ITU-T G.165 defineşte cerinţele de performanţă urmărite de dispozitivele
de eliminare de ecou. ITU-T defineşte chiar cerinţe de performanţă mult mai drastice în
specificaţiile G.IEC.
Ecoul este generat către reţeaua de pachete de către reţeaua telefonică. Modulul
pentru eliminarea ecoului compară datele sub formă de voce primite de la reţeaua de pachete
cu datele de voce trimise reţelei. Ecoul produs este rejectat prin intermediul unui filtru digital,
pe calea de transmisie în reţeaua de pachete.
Figura 1.2.5. Eliminarea ecoului prin intermediul unui filtru digital [17].
Pentru a ascunde şi a repara câteva din neajunsurile reţelei IP, care au un impact
foarte grav asupra comunicaţiilor de timp real pe acest suport, se folosesc tehnici ca:
Prioritizarea – are o strânsă legătură cu QoS-ul. Se foloseşte pentru aceasta protocolul
RSVP ( Resourse Reservation Protocol ), care permite sursei de trafic să ceară anumite
Pagina 10 din 133

caracteristici ale serviciului de transport. Din păcate acest protocol nu a avut un foarte mare
succes şi de aceea răspândirea lui este destul de limitată. Specialiştii IETF (Internet
Engineering Task Force) au abordat o altă soluţie, mai simplă şi mai promiţătoare:
DiffServ( Differentiated Services Model ) care foloseşte câmpul ToS ( Type of Service ) din
antetul IPv6 al fiecărui pachet, pe baza căruia clasifică traficul la graniţa dintre client şi ISP.
În ciuda acestor proiecte, în reţeaua IP nu se poate încă vorbi de un QoS viabil.
Fragmentarea IP este realizată în acelaşi mod ca şi la Frame Relay. Deşi cerută pentru
a reduce întârzierea globală a traficului de voce, fragmentarea realizează totuşi adăugarea
unui overhead mare, datorită headerului destul de mare al pachetelor IP. S-a constatat că
traficul de voce pe suport IP consumă din această cauză resursele WAN cu până la 50% mai
mult decât traficul de voce pe suport Frame Relay. Se speră totuşi că pe măsură ce IP-ul se
maturizează, compresia headerului si îmbunătăţirea performanţelor routerelor să elimine
aceste neajunsuri.
Compresia de voce este vitală tehnologiei VoIP datorită faptului că traficul

traversează adesea porţiuni de viteze mai mici. Companii de dimensiuni mici sau mijlocii, de
exemplu, pot fi conectate la VPN ( Virtual Private Network – reţea virtuală privată ) prin
intermediul unor link-uri de doar 28.8 kbps.
Soluţia de eliminare a pauzelor de vorbire, eliminarea ecoului – S-a constatat că până
la 50% dintr-o convorbire telefonică obişnuită este reprezentat de fapt de linişte ( doar unul
din interlocutori vorbeşte, pauze dintre cuvinte, etc ). Din acest motiv, o mare parte din
capacitatea de transfer a conexiunii de tip full-duplex se iroseşte.
1.3. Arhitectura sistemelor VoIP

“Voice over IP” este o tehnologie nouă, care vine să ofere o alternativă modului de
transmisie a vocii, în special, şi a altor servicii oferite de reţeaua de comutaţie de circuite. Ca
orice inovaţie, care vine să revoluţioneze realmente modul de transmisie a poate celui mai
vechi şi încetăţenit mod de comunicare verbală la distanţă între oameni, am numit aici
telefonia clasică, s-a lovit încă din prima clipă de suspiciunea utilizatorilor, problemele
Pagina 11 din 133

reţelelor de tip IP, noul suport de transmisie a vocii, dar, poate cel mai important obstacol,
nivelul uriaş al investiţiilor făcute în reţeaua de telefonie deja dezvoltată.
În tot acest context, VoIP a trebuit să-şi facă loc pe piaţă, oferind cel puţin la fel de
ieftin aceleaşi calitate a serviciilor de voce, să se integreze în sistemul de comunicaţie şi să-şi
pună la punct metode de colaborare, în principal, tocmai cu reţeaua telefonică, ale cărei
servicii i le concurează şi cărora le oferă alternativă. Acest lucru trebuie realizat datorită
faptului că, oricât de mare va fi amploarea dezvoltării VoIP, nu va reuşi să înlocuiască
serviciile de telefonie clasică.
Obiectivele de realizat pentru o bună funcţionare ar fi:
Controlul apelului şi al semnalizărilor diferite în cele 2 reţele de transport, astfel încât
utilizatorului obişnuit să-i fie indiferent pe ce suport se transmite semnalul vocal.
Intercomunicarea şi interoperabilitatea echipamentelor celor 2 reţele, PSTN (Reţeaua
telefonică de telefonie publică cu comutare de circuite) şi reţeaua de pachete, de tip IP. Acest
lucru implică folosirea unor punţi ( gateway ), care au rolul de a realiaza trecerea de la modul
diferit de trasmisie a datelor în cele 2 reţele.
Managementul sistemelor, adresarea, securitatea şi permisiunea de acces care trebuie
asigurate din ambele părţi.
Odată începută cursa de proiectare şi implementare de produse VoIP, care să se
muleze pe o mare varietate configuraţii deja existente, au trebuit concepute şi publicate o
multitudine de noi standarde care aveau în vedere mai ales noua tehnologie apărută. Toate
acestea au făcut ca sistemele VoIP să conţină mai multe plane funcţionale.
Aceste plane nu fac altceva decât să aducă soluţii structurate transportului de voce şi
interoperabilităţii cu celelalte reţele de date.
Figura 1.3.1. Arhitectura structurii

funcţionale a sistemelor “Voice over IP“ [16].
Pagina 12 din 133

Despre planul transportului de voce, incluzând aici vocea propriu-zisă, reprezentarea

şi codarea ei, şi controlul apelului telefonic, ne vom referi mai pe larg în subcapitolele
următoare.
La nivelul interopareabilităţii dintre PSTN şi reţeaua de pachete IP, trebuie manevrate
2 mari tipuri de informaţii: vocea propriu-zisă, pe de o parte, şi informaţiile de semnalizare,
pe de altă parte.
Figura următoare reliefează modul în care componentele software a unui sistem VoIP,
localizate uzual în componentele hardware indicate, interfaţează cu ambele fluxuri de
informaţie şi le transformă într-unul singur, transmis reţelei de pachete. Aceste funcţii
software se împart în 4 mari categorii:
M e s a je
SNM P
M o d u lu l d e
S e m n a liz ã ri m anagem ent
a l re te le i
M o d u lu l d e
s e m n a liz a r e
te le fo n ic ã
P a c h e te
de voce
Voce M o d u lu l d e M o d u lu l d e
p a c h e tiz a re a a p r o to c o a le d e
v o c ii re te a
DSP
M IC R O P R O C E S O R
Figura 1.3.2. Arhitectura software a unui sistem VoIP [13]
Modulul de pachetizare a vocii – cunoscut şi sub numele de modulul de procesare a

vocii, funcţionează de regulă într-un DSP ( Digital Signal Processor ), pregăteşte eşantioanle
de voce pentru transmisia în reţeaua IP. Funcţiile sale realizează şi eliminarea ecoului,
compresia de voce, detecţia pauzelor în discursul telefonic, eliminarea jitter-ului,
sincronizarea ceasului şi pachetizarea vocii.
Modulul de realizare a semnalizării telefonice – interacţionează cu echipamentele
telefonice, translatând semnalizările telefonice în schimbări de stare, folosite de către
modulul de protocoale de reţea pentru stabilirea, menţinerea şi eliberarea conexiunilor.
Schimbările de stare sunt ridicare de receptor, terminare apel, etc. Acest software suportă de
Pagina 13 din 133

regulă semnalizări E&M de tipul I, II, III, IV, V, FXO, FXS, ISDN acces de bază şi acces
primar.
Modulul de protocoale de reţea – procesează informaţiile de semnalizare şi le
converteşte din semnalizări specifice reţelei telefonice în protocoale de semnalizare în mod
pachet, folosite la stabilirea conexiunilor în reţeaua IP ( ex: Q.933 ). De asemenea, adaugă
headere pacheteleor de voce şi de semnalizare înainte de a fi transmise.
Modulul de management a reţelei – asigură interfaţa de gestiune a vocii, pentru
menţinerea şi configurarea celorlalte module ale sistemului. Toate informaţiile de gestiune
sunt definite în ANSI.1 şi sunt compatibile cu sintaxa protocolului SNMP v.1 ( Signalling
network-management protocol ).
Pachetul software este partiţionat pentru a asigura o bine definită interfaţă către
aplicaţia ce rulează în DSP, utilizabilă pentru mai multe aplicaţii şi protocoale de pachetizare.
DSP-ul procesează eşantioanele de voce şi pasează pachetele de voce microprocesorului
însoţite de header-ele generice de voce.
Microprocesorul este responsabil de transferul pachetelor şi adaptarea header-elor
generice în header-ele specifice protocolului de transport în timp real al pachetelor de voce
( ex: Real Time Protocol - RTP ). De asemenea, tot microprocesorul realizează şi procesarea
informaţiilor de semnalizare şi le converteşte din protocoalele de semnalizare telefonică în
protocoale de semnalizare în reţeaua de pachete ( ex: H.323 ).
Partiţionarea oferă o interfaţă clară între funcţiile generice de procesare de voce, de

exemplu compresie, eliminare de ecou şi detecţia de activitate vocală, şi semnalizările
specifice aplicaţiei şi procesările protocoalelor de voce.
1.3.1. Modulul de procesare a vocii

Referinţe bibliografice: [1], [8], [13], [17], [18]
După cum şi titlul anuţă, acest modul al arhitecturii software a unui sistem VoIP are în
principal rolul de a procesa eşantioanele de voce. De obicei, aceste funcţiuni sunt realizate cu
ajutorul unui DSP ( Digital Signal Processor ). Raportul calitate/preţ al acestor dispozitive a
înregistrat o evoluţie vertiginoasă în ultima vreme, performanţele sale, dar mai ales preţul în
Pagina 14 din 133

continuă scădere transformîndu-l într-o componentă ideală pentru arhitectură hardware a

sistemelor de procesare a eşantioanelor de voce.
Pentru o mai bună structurare a funcţiunilor şi sarcinilor pe care le are de îndeplinit,
modulul de procesare de voce este la rândul lui împărţit în mai multe submodule:
Interfaţa PCM – are sarcina de a recepţiona eşantioanele de voce, modulate folosind
modulaţia impulsurilor în cod, de pe fluxul PCM digital şi de a le direcţiona către modululele
software din DSP-urile responsabile de procesarea lor. Apoi le transmite interfeţei digitale şi
continuă etapa de reeşantionare a cadrelor de ieşire către interfaţa analogică.
Generatorul de tonuri – generează tonuri DTMF ( Dual Tone Multifrequency ) şi
tonuri specifice apelului telefonic sub comanda sistemului de operare folosit în echipamentul
respectiv ( ex: telefon, fax, modem, PABX ). Este configurabil pentru funcţionarea în mai
multe sisteme de standardizare.
Eliminarea ecoului – realizează suprimarea parametrizabilă a ecoului în cazul
trasmisiilor de voce în modul full-duplex, conform cu specificaţiile ITU G.165, G.168.
Detectorul de activitate vocală şi măsurare a nivelului de zgomot – Monitorizează
semnalul recepţionat pentru a fi detectată activitatea vocală în discursul telefonic. Atunci
când se detectează linişte pe o perioada de timp a cărei durată se poate parametriza, software-
ul informează protocolul de pachetizare a vocii. Aceasta previne ca informaţiile de la ieşirea
codorului să fie transportate de-a lungul reţelei în momentele de pauză, fără ca să existe
informaţie utilă de transmis, lucru ce duce la reducerea utilizării inutile resurselor reţelei.
Software-ul realizează de asemenea şi o măsurare a nivelului de zgomot în starea de

pauză a interfeţei telefonice, iar apoi raportează aceste informaţii protocolului de pachetizare
a vocii din terminalul distant pentru a tine cont la redare de perioadele de linişte detectate.
Detectorul de tonuri – detectează recepţia tonurilor DTMF şi a tonurilor specifice
stabilirii apelului telefonic. Aceste detecţii sunt raportate sistemului de operare pentru
activarea a diverse funcţii specifice.
Modulul de codare a vocii – are rolul de a coda vocea inainte de a fi transmisă în
reţeaua IP. Este capabilă de numeroase rate de compresie folosind diverşi algoritmi de
codare.
Fax software – realizează funcţiunile secifice de trimitere de facsimile prin
demodularea datelor PCM, extragerea informaţiilor relevante, împachetarea şi transmiterea
Pagina 15 din 133

pe reţeaua IP. Prin această procedură se produc reduceri semnificative ale benzii inutil
utilizate.
Unitatea de redare a vocii – buffer-ează pachetele de voce sosite din reţea şi le trimite
codorului de voce pentru redare. Asigură în acelaşi timp:
un buffer de tip FIFO ( First In, First Out ) care menţine eşantioanele de voce înainte
ca să fie realizată înlăturarea jitter-ului datorat reţelei.
un mecanism de măsurare a jitter-ului care permite un control adaptiv al întârzierii de
tip FIFO.
Protocoalele de pachetizare a vocii folosesc un câmp ce conţine numere de secvenţă
în interiorul fluxului de pachete pentru menţinerea temporară a integrităţii vocii de-a lungul
redării. Folosind această metodă, transmiţătorul inserează în fiecare pachet conţinutul unui
contor ce evoluează modulo 216, permiţând receptorului să detecteze pierderea de pachete şi
să reproducă intervalele de linişte într-o redare corectă.
Protocolul de pachete de voce – este în care se încapsulează vocea compresată şi
datele de fax pentru a fi transmise celuilalt capăt pe suportul reţelei de date.
Controlol interfeţei – coordonează schimbul de informaţii de monitorizare şi control
dintre DSP şi sistemul gazdă, prin intermediul unui mecanism de cutie
poştală. Informaţiile interschimbate includ date de configurare, rapoarte de stare, etc.

Mediul intern de funcţionare în timp real – asigură mediul de operare al software-ului
funcţional în DSP. Furnizează funcţii de sincronizare, gestiunea task-urilor şi a memoriei,
controlul timer-ilor.
Figura următoare sintetizează arhitectura software-ului care rulează într-un DSP. El
procesează eşantioanele de voce de pe flux PCM şi le converteşte într-un format digital
potrivit transmiterii în reţeaua de pachete IP.
Pagina 16 din 133

D e te c to r d e
to n u ri U n ita te a
DTM F d e re d a re
a d a p tiv ã
G e s tiu n e a
C o n tr o lu l
p a c h e te lo r
c â s tig u lu i p ie r d u te
C o d o re
voce
G .7 1 1
In te rfa ta D e te c tia
G .7 2 2
PC M E lim in a r e e c o u G .7 2 8
a c t iv itã tii P r o to c o a le
G .1 6 5 /G .1 6 8 G .7 2 3
v o c a le G .7 2 9 de pachet
G e n e r a to r
d e to n u r i c ã tre
D TM F A s a m b la r e m ic ro p ro c e s o r
G e n e r a to r D e z a s a m b la r e
to n d e p a u z ã
R e e s a n tio n a r e S e c v e n ta re
VO C E
In te r fa ta s e r v ic iilo r d e fa x
M odem
V .2 1 P ro to c o l
V .2 2 D r iv e r
d e fa x
V .1 7 re te a P ro cesarea
T .3 0
V .2 9 m e s a je lo r
Figura 1.3.1.1. Structura modulului de procesare a vocii. [13].
1.3.2. Modulul de semnalizare şi management

Referinţe bibliografice: [1], [8], [13], [17], [18]
Software-ul sistemelor VoIP asigură buna funcţionare a semnalizării telefonice,

pentru a detecta prezenţa unui nou apel şi a cifrelor reprezentând adresa sa, folosite de sistem
la rutarea către portul destinaţie. Sunt suportate o mare varietate de protocoale de
semnalizare, specifice reţelei telefonice. De regulă, software-ul şi datele de configurare
pentru cartelele de voce pot fi încărcate de la un sistem de management, pentru a permite
instalare rapidă şi uşoară, îmbunătăţiri făcute de la distanţă.
Modulul software interacţionează cu DSP-ul pentru detecţia şi generarea tonurilor
DTMF şi interacţionează cu interfaţa telefonică pentru funcţiunile de semnalizare. El are, de
asemenea, rolul de a recepţiona datele de configurare de un agent de gestiune a reţelei şi de a
utiliza serviciile oferite de sistemul de operare.
Pagina 17 din 133

Modulul de transfer a semnalizării telefonice – are, după cum ne-am obişnuit, o

arhitectură structurată pe blocuri funcţionale.
Software-ul pentru interfaţa telefonică – monitorizează, de obicei, interfaţa de
semnalizare a modulului.
Unitatea de protocol de semnalizare – este constituită din maşina de stări, care
realizează buna funcţionare a protocoalelor de semnalizare ( ex: E&M ).
Modulul de control al reţelei – realizează transferul semnalizărilor telefonice într-un
format adecvat protocoalelor de stabilire de sesiune pentru comunicaţia de voce pachetizată.
Translaţia adreselor – realizează corespondenţa dintre planul de adresaree telefonică,
descris de recomandările E.164, în adrese care pot fi folosite în reţeaua de pachete ( ex:
adrese IP sau DLCI (Data Link Connection Identifier), în cazul reţelelor Frame Relay ).
Driverul pentru interfaţa cu DSP-ul – facilitează transferul de informaţii între
microprocesorul gazdă al sistemului şi DSP-uri.
Modulul pentru protocolul de reţea – are submodule obligatorii:

Stiva de semnalizare IP – presupune controlul apelului şi al transportului, folosind
specificaţiile H.323, incluzând H.225, H.245, RTP/RTCP , TCP, UDP şi IP. La toate aceste
soluţii software ne vom referi mai pe larg în subcapitolele ce urmează.
Stiva de protocoale de semnalizare ATM.
Stiva de protocoale Frame Relay.
Modulul de management a reţelei – constă în 3 mari servicii:
Interfaţa fizică către terminalul telefonic.
Serviciul oferit canalului de voce – are ca funcţiuni următoarele:
procesarea semanlului pe canalul vocal.
Conversia eşantioanelor PCM în pachete de voce compresată.
Serviciul de control al apelului pentru analiza informaţiilor de control apel şi stabilirea
convorbirilor între terminalele telefonice.
1.4. Tipuri de conexiuni

Referinţe bibliografice: [1], [9], [12], [14]
Pagina 18 din 133

În ciuda inconvenienţelor de ordin tehnic în faţa cărora s-a aflat, datorită problemelor
de asigurare a QoS-ului de către reţelele IP, tehnologia VoIP a avut o mare şi rapidă
dezvoltare. Ea are rolul de a integra serviciile de transport de voce în reţelele de tip IP şi de a
realiza o bună comunicare cu reţeaua publică de telefonie PSTN.
Figura 1.4.1:
Integrarea serviciilor de
voce în reţelele IP. [14].
În modul
tradiţional de funcţionare
al serviciilor de telefonie publică, până acum apelurile aveau se realizau prin stabilirea unor
canale virtuale comunicaţie de-a lungul reţelei de comutaţei de circuite, care erau apoi
folosite pentru transmiterea vocii. Semnalul vocal urma acelaşi traseu stabilit în faza de
iniţializare a apelului, traseu virtual care la sfârşitul comunicaţiei este eliminat din
funcţionarea sistemului.
Noua tehnologie VoIP, datorită tendinţei de integrare şi necesităţilor de comunicare,
oferă mai multe modalităţi de conexiune pentru realizarea apelului şi transferului de voce.
Figura următoare prezintă variantele de realizare conexiunilor amintite. Ele pot fi:
PC–PC – legătură telefonică între 2 calculatoare echipate cu software adecvat
comunicaţiilor de voce în timp real (ex: Microsoft NetMeeting) şi cu hardware specializat
pentru comunicaţii de voce ( placă de sunet, microfon, căşti audiţie ). Conexiunea se poate
realiza folosind numai Intranet-ul privat al companiei, sau reţeaua publică de pachete IP.
PC–Telefon – legătură telefonică între un calculator multimedia şi un post telefonic

obişnuit, abonat al reţelei publice. Comunicarea se face în mod pachet folosind reţeaua
Intranet, ieşind
apoi în reţeaua publică IP, iar apoi, prin intermediul dispozitivelor de
intercomunicaţie (gateway), datele reprezentând vocea sunt transferate reţelei telefonice cu
comutare de circuite şi apoi postului telefonic dorit.
Pagina 19 din 133

Telefon–telefon – legătură telefonică între 2 posturi telefonice normale. Diferenţa este

că legătura de comunicaţie se realizează astfel încât semnalele de voce traversează o reţea
publică sau privată IP şi revin apoi în reţeaua telefonică, pe traseul lor către destinaţie.
M u lt im e d ia P C
M u l t im e d i a P C
In t r a n e t
In t r a n e t
PBX
R e te a p u b lic ã IP F u n c tie d e
in te rc o n e c ta re
F u n c tie d e
in te rc o n e c ta re
V o IP G a t e w a y
P S T N /IS D N
V o IP G a t e w a y
P S T N /IS D N
PBX
Figura 1.4.2. Tipuri de conexiuni VoIP
1.5. Protocoale şi soluţii software

În dinamica muncă de proiectare şi producţie, în dorinţa de a scoate cât mai repede

ceva cât mai bun pe piaţă, fiecare mare producator a adoptat o soluţie proprietară care să-l
mulţumească pe el şi care să-i accelereze procesul de dezvoltare. De aceea, în tot acest cadru
a fost nevoie de o autoritate care să aducă şi să impună anumite standarde ce trebuie urmate
pentru o bună intercomunicare. Prima măsură a fost înfiinţarea “VoIP Forum”, unde fiecare
mare producător care avea câte un cuvânt de spus s-a înscris. Marile grupuri de standardizare
şi grupuri decizionale, ITU-T, IETF, ETSI, etc., s-au grăbit de asemenea să adopte propriile
Pagina 20 din 133

standarde. Totul a culminat însă, în 1996 cu apariţia primei versiuni a specificaţiilor H.323.
Au urmat apoi în 1998 versiunea 2, în 2000 versiunea 3, actualmente funcţionând versiunea
4.
Intitulate generic “Audiovisual and multimedia systems”, H.323 reprezintă un
standard care specifică protocoalele, componentele şi procedurile care furnizează serviciile de
comunicare multimedia – audio, video şi date în timp real, peste o reţea de pachete bazată pe
protocolul IP. H.323 este parte a recomandărilor ITU-T, denumite generic H.32x care descriu
funcţionarea comunicaţiilor peste diverse tipuri de reţele de pachete.
R e te a d e p a c h e te
(e x : IP )
H .3 2 3
T e rm in a l H .3 2 3 T e r m in a l H .3 2 3
Figura 1.5.1. Funcţionalitatea H.323.

Reţelele bazate pe transmisia de pachete fac parte LAN-urile (local area network) IP
sau IPX (Internet packet exchange), reţelele private de instituţie, reţelele metropolitane
(MAN) şi cele de intindere mare (WAN). H.323 poate fi funcţiona într-o mare varietate de
aplicaţii: numai audio(telefonie prin Internet), audio şi video (videofonie), audio şi date,
video şi date. H.323 poate fi, de asemenea, aplicat comunicaţiilor multimedia de tip
multipunct.
Specificaţiile H.323 v.1 emise de către ITU-T Study Group 16 în octombrie 1996
aveau ca obiect sistemele de tip video-telefon şi echipamente pentru reţelele LAN care să
furnizeze un QoS negarantat. Rapiditatea dezvotării aplicaţiilor VoIP şi a telefoniei prin
Internet a pavat drumul spre o revizuire a specificaţiilor H.323. Inconsistenţa standardelor
deja adoptate a fost scoasă la lumină de produsele oferite care erau incompatibile. Odată cu
evoluţia VoIP, noi cerinţe au apărut la orizont, ca, de exemplu, asigurarea comunicaţiei între
un multimedia-PC (terminal H.323) şi un telefon obişnuit funcţionând în reţeaua PSTN.
Aceste cerinţe au dus la necesitatea unui standard pentru telefonia prin Internet. Astfel, în
ianuarie 1998 a fost publicată versiunea 2 H.323-ului – sisteme de comunicaţie multimedia
bazate pe comutaţia de pachete.
Pagina 21 din 133

Completări referitoare la transmiterea fax-ului peste o reţea de pachete, comunicarea

gatekeeper-gatekeeper şi mecanisme de conectare rapidă au forţat apariţia îmbunătăţită a
specificaţiilot H.323 versiunea 3 în anul 2000.
Unul dintre obiectivele dezvoltării standardelor H.323 este interoperabilitatea cu alte
reţele de pachete ce oferă servicii multimedia. Acest lucru se face prin folosirea “gateway”-
urilor care realizează translaţia semnalelor de date şi a semnalizărilor cerute pentru o bună
conlucrare.
Standardul H.323 specifică 4 tipuri de componente, care legate între ele, asigură buna
funcţionare a serviciilor multimedia punct-la-punct sau multipunct. Aceste componente ar fi:
Terminale
Gateway-uri
Gatekeepere
MCU (multipoint control units) – ajută controlul comunicaţiilor de tip multipoint.
Figura 1.5.2. Arhitectura şi componentele reţelei H.323. [14].

Terminalul
Folosit pentru comunicaţiile multimedia bidirecţionale, de timp real, ca terminal poate
fi folosit un calculator personal (PC), sau un dispozitiv de sine stătător, care pot rula aplicaţii
multimedia şi stiva H.323. El suportă comunicaţii audio şi opţional video sau de date. Pentru
că serviciul de bază oferit de un terminal H.323 este acela de comunicaţii audio, el joacă un
rol cheie în serviciile de telefonie IP.
Gateway
Are rolul de a conecta 2 reţele diferite. Un gateway H.323 realizează
intercomunicarea între o reţea H.323 şi reţele de alt tip. Conectivitatea între diferite reţele este
Pagina 22 din 133

realizată prin translaţia protocoalelor pentru efectuarea şi eliberarea apelului, conversia

formatelor datelor şi transferarea informaţiilor din reţelele conectate de gateway.
Gatekeeper
Poate fi considerat creierul reţelelor H.323, întrucât este punctul în care se
concentrează realizezea tuturor apelurilor. În ciuda faptului că nu sunt necesare, ele asigură
buna funcţionare a unor importante servicii: adresarea, autorizarea şi autentificarea
terminalelor şi a gateway-urilor; gestiunea lăţimii de bandă folosită; controlul taxării, etc. Pot
de asemenea asigura servicii de rutarea a apelului.
MCU – Multipoint Control Unit
Furnizează suportul pentru comunicaţii de tip multipunct între 3 sau mai multe
terminale H.323. Toate terminalele realizează câte o conexiune cu MCU. El gestionează
resursele conferinţei, negociază cu terminalele în scopul determinării
codorului audio/video ce urmează a fi folosit şi poate manevra fluxul de date. Deşi

gateway-urile, gatekeeper-ele şi MCU sunt componente separate, pot însă fi implementate în
aceeaşi maşină, ca un singur dispozitiv fizic.
O zonă H.323 este colecţia tuturor terminalelor, gateway-urilor şi MCU-urilor
gestionate de un singur gatekeeper. Poate exista cel puţin un terminal şi poate include
gateway-uri sau MCU, dar cu siguranţă un singur gatekeeper. O zonă poate fi independentă
de topologia reţelei, sau poate fi constituită din mai multe segmente conectate prin routere,
sau alte dispozitive.
Protocoalele specificate de standardul H.323, clasificate pe structura funcţională sunt
prezentate în figura următoare şi descrise mai jos:
Codoare şi decodoare audio (audio codec).
Codoare şi decodoare video (video codec).
H.225 - registration, admision, status (RAS).
H.225 - semnalizarea apelului.
H.245 - semnalizarea controlului.
RTP – Real-time Transfer Protocol – protocol pentru transmiterea datelor de timp-
real.
RTCP – Real-time Control Protocol – protocol pentru controlul transmiterii datelor de
timp-real.
Pagina 23 din 133

A p lic a tii A p lic a t ii

M a n a g e m e n t a p e l în te r m in a l
a u d io v id e o
G .7 1 1
H .2 6 1
G .7 2 9
H .2 6 3 H .2 2 5 H .2 4 5
G .7 2 3 .1 H .2 2 5
RTCP s e m n a liz a r e s e m n a liz a re T .1 2 0
RAS apel c o n tro l
RTP
P r o t o c o a le d e tr a n s p o r t s i in te r f a t ã c u r e t e a u a
Figura 1.5.3. Stiva H.323 [10].
Audio CODEC – are rolul de a coda pentru transmisie semnalului audio de la

microfon, la terminalul emiţător. La terminalul receptor, va decoda semnalul primit ce va fi
trimis spre redare. Întrucât serviciile audio sunt minimul oferit de standardul H.323, toate
terminalele trebuie să aibă suport pentru cel puţin un codec audio, aşa cum este specificat în
recomandarea ITU-T G.711 (codare decodare audio 64 kbs). Pot fi folosite alte codec-uri
audio: G.722 (64, 56, 48 kbs), G.723.1 (5.3 şi 6.3 kbs), G.728(16 kbs) şi G.729(8kbs).
Video CODEC – codează imaginile primite de la camera de luat vederi pentru
transmisie, în cazul terminalului H.323 emiţător şi decodează imaginile recepţionate pentru a
le trimite apoi la dispozitivul de vizualizare, la terminalul receptor. Pentru că serviciile video
sunt opţionale conform specificaţiilor H.323, suportul pentru codecii video este opţional, de
asemenea. Totuşi, orice terminal ce asigură comunicaţii video trebuie să suporte codare-
decodare video, conform specificaţiilor ITU-T H.261.
H.225. Registration, Admission and Status – este un protocol ce funcţionează între
terminale, sau gateway-uri, pe de o parte şi gatekeepere, pe de altă
Pagina 24 din 133

parte. Este folosit pentru a realiza înregistrarea, controlul accesului, schimbările în

lăţimea de bandă şi a stării dispozitivelor terminale şi gatekeepere. Mesajele de tip RAS sunt
schimbate folosind un canal de comunicaţie RAS, deschis între terminal şi gatekeeper înainte
de deschiderea oricărui alt canal de comunicaţie.
H.225 Semnalizarea apelului – protocol folosit pentru stabilirea unei conexiuni între
cele 2 dispozitive terminale. Acest lucru este realizat prin schimbarea de mesaje de tip H.225
prin intermediul canalului de semnalizare. Acesta se poate deschide între 2 terminale H.323,
sau între un terminal şi un gatekeeper.
H.245 Semnalizarea de control – se foloseşte pentru a schimba mesaje de control de
tip capăt-la-capăt menite să controleze funcţiunile terminalului H.323. Aceste mesaje
transportă informaţii referitoare la:
capacităţile de comunicare.
Deschiderea şi închiderea canalelor logice folosite pentru transportul fluxului de date.
Mesaje de control al transmisiei.
Comenzi generale şi indicaţii.
RTP – Real-time transport protocol – asigură serviciile de livrare capăt-la-capăt a
fluxurilor audio şi video de timp-real. În majoritatea cazurilor în care RTP-ul este folosit
pentru transportul de date în reţelele de pachete IP, el funcţionează având ca protocol de
transport UDP-ul (User Datagram Protocol). Împreună în acest context, asigură funcţiunile
unui protocol de nivel transport. RTP-ul oferă identificarea tipului de date transportat, numere
de secvenţă, amprente de timp şi monitorizarea pachetelor sosite. UDP oferă multiplexarea şi
serviciul de sume de control. RTP poate fi însă folosit şi în combinaţie cu alte protocoale de
nivel transport.
RTCP – Real-time Transport Control Protocol – folosit de regulă alături de RTP, are
menirea de a asigura serviciile de control în cele 2 terminale ale transportului pachetelor.
Principala sarcină a RTCP-ului este de a asigura un “feedback” al calităţii transportului
datelor. Pe lângă acest lucru, RTCP-ul mai are rolul de a transporta un identificator al
nivelului transport al unei surse RTP, folosit de receptoare pentru sincronizarea audio şi
video.
1.5.1 Funcţiunile componentelor H.323

Pagina 25 din 133

Am enumerat în subcapitolul anterior componentele pentru asigurarea serviciilor de

comunicaţie multimedia pe suportul unei reţele de pachete IP. Figura următoare are, pe lângă
rolul de a le reaminti, şi rolul de a prezenta modalitatea lor de interconectare şi
intercomunicare.
Figura 1.5.1.1. Componentele şi integrarea lor in reţeaua H.323 [14].

Terminalul H.323 – trebuie să asigure următoarele funcţiuni:
H.245 pentru crearea canalelor de transmitere a datelor multimedia şi pentru schimbul
Terminal Terminal
H.323 H.323
Terminal H.323
de informaţii referitoare la disponibilităţile tehnice ale terminalelor.

H.225 pentru stabilirea apelurilor şi realizarea semnalizării telefonice.
RAS, pentru schimbul cu gatekeeper-ul al informaţiilor de înregistrare şi control al
accesului.
RTP/RTCP pentru secvenţarea şi amprentele de timp adăugate pachetelor audio şi/sau
video.
Terminalele compatibile H.323 trebuie să asigure codare/decodare G.711. Opţional,

mai pot lucra componente de codare/decodare video, protocoale pentru conferinţă T.120, sau
funcţiuni de MCU.
Pagina 26 din 133

Gateway – asigură translaţia protocoalelor pentru stabilirea şi eliberarea apelului,

conversia formatelor de date între diferite reţele şi transferul de informaţii între reţelele de tip
H.323 şi non-H.323.
S e r v ic ii d e
ta x a re
C o n tr o lu l a p e lu lu i
G e s tiu n e a p e lu r i g a te w a y S e m n a liz a r e P S T N
C o n tro lu l a p e lu lu i
(e x . Q .9 3 1 )
H .2 2 5 .0 H .2 2 5 .0 H .2 4 5
RTCP RTCP RAS s e m n a liz a r e s e m n a liz a re S e m n a liz a r e P S T N
(c lie n t) apel c o n tro l C o n t r o lu l le g ã t u r ii
(e x . L A P D )
P r o to c o a le d e tr a n s p o r t s i in t e r f a t a c u S e m n a liz a r e P S T N
re te a u a In te r fa ta f iz ic ã
Figura 1.5.1.2. Stiva de protocoale a unui gateway H.323-SCN. [10].
În partea aplicaţiilor H.323, un gateway rulează H.245 pentru schimbarea

informaţiilor privitoare la disponibilităţile tehnice, H.225 “call signalling” pentru stabilirea şi
eliberarea apelurilor şi H.225 RAS pentru înregistrare, acces şi stare în raport cu gatekeeper-
ul. Înspre reţeaua cu comutaţie de circuite, sunt funcţionale componente specifice reţelelor
SCN (Switched Circuit Network)(ex. ISDN, SS7).
Terminalele comunică cu gateway-ul folosind protocolul H.245 de control al
semnalizării şi H.225 pentru semnalizarea apelului. Gateway-ul translatează transparent
aceste informaţii către reţeaua non-H.323 corespondentă şi invers. Transferul formatelor
informaţiilor audio, video, sau de date poate fi realizat tot de către gateway. Pot exista situaţii
în care acest transfer audio sau video nu este necesar, în cazul în care cele 2 terminale
folosesc moduri de comunicare identice. Un exemplu îl poate constitui un gateway către o
reţea ISDN, mai precis către un terminal H.320. Ambele terminale necesită G.711 audio şi
H.261 video, deci un mod comun. Gateway-ul are caracteristici pentru ambele terminale,
H.323 şi non-H.323. El este totuşi o componentă logică ce poate asigura mai multe convorbiri
simultane şi poate fi implementat ca o parte a unui gatekeeper sau MCU.
Gatekeeper (GK) – asigură serviciile de control al apelurilor pentru terminale, ca
translaţia adreselor, managementul benzii. Existenţa şi folosirea lor în reţelele H.323 este
opţională. Dacă sunt prezente totuşi, terminalele şi gateway-urile trebuie să folosească
Pagina 27 din 133

serviciile oferite de ele. Standardele H.323 specifică serviciile precise care trebuie asigurate şi
alte funcţionalităţi opţionale ce pot fi asigurate.
O facilitate opţională este rutarea semnalizării apelului. Terminalele trimit mesaje
pentru semnalizare apel gatekeepr-ului, iar acesta le rutează către celălalt terminal. O altă
variantă ar fi ca acest lucru să se facă fără tranzitarea gatekeeper-ului. Această funcţie este cu
atât mai valoroasă cu cât monitorizarea apelurilor de către gatekeeper asigură un control mai
bun al apelurilor din reţea, de vreme ce deciziile de rutare luate de GK sunt bazate pe o mare
varietate de factori.
Figura 1.5.1.3 Funcţiunile GK. [10].

Un GK ese opţional într-un sistem H.323. Serviciile oferite de el sunt definite de către
RAS şi includ translaţia adreselor, controlul accesului, managementul zonei H.323. Reţelele
H.323 care nu au implementate GK, nu beneficiază de asemenea facilităţi, însă este
recomandat ca acolo unde există gateway-uri de telefonie IP să existe si GK, care să
M a n a g e m e n e tu l G K
S e rv ic ii d e ta x a r e
H .2 2 5 .0 H .2 2 5 .0 H .2 4 5
RAS S e r v ic ii d ir e c to a r e
s e m n a liz a r e s e m n a liz a r e
(s e rv e r) apel c o n tro l
S e r v ic ii d e
s e c u rita te
P r o to c o a le d e tr a n s p o rt s i M a n a g e m e n tu l
in te r fa ta c u r e te a u a p o litic ii/a p e lu lu i
translateze adresele telefonice E.164 în adrese de transport din reţeaua IP. Ca şi gateway-ul,
este o componentă logică, iar ea poate fi implementată ca parte a unui gateway, sau MCU.
1.5.2 Sarcini obligatorii ale unui gatekeeper

Un gatekeeper are o prezenţă opţională în reţeaua H.323. În situaţia în care se

foloseşte, vine să mărească controlul asupra apelurilor efectuate şi, conform standardului
H.323, trebuie să îndeplinească anumite funcţiuni obligatorii.
Pagina 28 din 133

Translaţia adreselor – Apelurile efectuate din interiorul reţelei H.323 pot folosi un
înlocuitor al adresei terminalului destinaţie, în timp ce apelurile realizate din afara reţelei
H.323 şi primite de un gateway pot folosi numere de telefon conform specificaţiei E.164
asupra numerotaţiei PSTN, pentru a adresa un terminal. Gatekeeper-ul este cel care
translatează numerele de telefon E.164, sau înlocuitorii lor în adrese de reţea (ex:
205.255.195.89:5004 pentru o reţea IP) pentru terminalele destinaţie.
Controlul accesului – GK poate controla accesul terminalelor în reţeaua H.323. El
foloseşte pentru aceasta mesaje RAS, cereri de admisie(ARQ), confirmări(ACF) şi respingeri
(ARJ). Un caz simplu ar fi ca controlul admisiei să fie o funcţie nulă, care să admită toate
terminalele din reţeaua H.323.
Controlul lăţimii de bandă – GK asigură suport pentru controlul benzii prin
intermediul folosirii mesajelor de tip RAS, cereri de alocare de bandă(BRQ),
confirmări(BCF) şi refuzuri(BRJ). Spre exemplu, dacă un gestionar de reţea semnalizează o
depăşire a unui număr de comunicaţii simultane în reţeaua H.323, gatekeeper-ul poate refuza
ulterioare conexiuni odată atins un prag. Rezultatul este limitarea benzii totale alocate la o
anumită fracţiune din banda disponibilă. La fel ca şi în cazul anterior, controlul benzii poate
fi o funcţie nulă ce acceptă toate cererile de bandă.
Managementul zonei – gatekeeper-ul are rolul de a asigura funcţiile mai sus amintite
pentru terminalele, gateway-urile şi unităţile MCU ce se găsesc în zona sa de control.
Semnalizarea de control a apelului – GK poate ruta mesajele de semnalizare a
apelului dintre terminale. Într-o comunicaţie punct-la-punct, GK poate procesa
mesaje H.225 de semnalizare a apelului. Alternativ, GK poate permite terminalelor

să-şi trimită direct, unul celuilalt mesaje de semnalizare a apelului H.225.
Autorizarea apelului – Atunci când un terminal trimite mesaje H.225 de semnalizare a
apelului către GK, acesta din urmă poate accepta sau respinge apelul, potrivit specificaţiilor
H.225. Motivele refuzului pot avea în vedeere restricţii de acces sau de timp către sau de la
un gateway.
Gestiunea apelului – GK-ul poate avea şi menţine informaţii despre toate apelurile
H.323. Astfel poate controla zona sa prin furnizarea informaţiilor proprii funcţiei de gestiune
a benzii, sau, prin rerutarea apelurilor către terminale pentru a obţine traficul echilibrat.
Pagina 29 din 133

CAPITOLUL 2. Arhitectura centralei telefonice digitale “TOPEX 1000D”
2.1. Prezentare generală

Referinţe bibliografice: [6], [7]
Centrala TOPEX 1000D este o centrală telefonică digitală cu o capacitate maximă de

1536 abonaţi locali şi 120 joncţiuni. Ea este concepută într-o arhitecură modulară ce permite
configurarea într-o gamă foarte diversă. Centrala este realizată cu componente electronice
moderne, specializate pentru comunicaţii digitale.
Centrala are o arhitectură ierarhizată pe mai multe nivele de comandă. La alegerea
arhitecturii s-a avut în vedere dublarea elementelor de comandă şi a câmpului de comutaţie.
În proiectarea centralei s-a avut în vedere împingerea inteligenţei spre periferie în
scopul diminuării efortului de calcul al unităţii centrale şi, implicit, simplificarea programelor
executate la acest nivel, dar, pe de altă parte, creşterea calităţii serviciului.
Asigurarea fiabilităţii se face prin duplicare în regim de divizare de trafic la nivel
central sau reconfigurări de grup, în sensul că o unitate are disponibilităţi pentru a prelua
încărcarea unităţii vecine în cazul defectării acesteia.
Figura următoare prezintă principalele module componente ale centralei:
Figura 2.1.1. Blocurile componente ale centralei TOPEX 1000D
Unitatea centrală este realizată cu două procesoare care lucrează paralel, tratarea
apelurilor fiind distribuită în mod egal între ele. În cazul defectării unuia dintre procesoare,
Pagina 30 din 133

procesorul rămas în funcţiune va prelua tratarea tuturor apelurilor. Aceasta va duce la

scăderea capacităţii de trafic a centralei, dar nu duce la ieşirea din funcţionare a acesteia.
Rolul unităţii centrale este de a identifica portul de destinaţie pe baza informaţiei de
numerotaţie primită de la unitatea de grup şi de a stabili o legătură prin reţeaua de
comunicaţie între unitatea de grup sursă şi unitatea de grup căreia îi aparţine portului
destinaţie. Grupul destinaţie va fi fie un grup de abonaţi locali, fie un grup de trunchiuri.
Identificarea se va face de către procesul de rutare pe baza tabelei cu identificatori telefonici
(număr de apel telefonic) ai porturilor centralei.
Câmpul de comutaţie este realizat cu matrici de comutaţie spaţio-temporale format
din două subcâmpuri echivalente cu o structură Kloss pătrată 512 x 512. Cele două plane
funcţionează în paralel. În cazul defectării unuia din ele, celălalt poate prelua tot traficul din
centrală.
Unităţile de grup de abonaţi conţin interfeţele de abonaţi locali, modulul de test şi
procesorul de grup de abonaţi. Interfeţele sunt realizate pe module de opt abonaţi. O unitate
de grup de abonaţi are capacitatea de 128 linii şi este controlată de procesorul de grup.
Unităţile de joncţiuni analogice conţin interfeţele de joncţiuni care pot fi de tip E&M
la 4/6 fire sau joncţiuni de curent continuu , modul de test şi procesorul de grup de joncţiuni
analogice.
Unitatea de grup trunchi digital conţine două interfeţe de trunchi digital conforme
specificaţiilor G.701 şi un procesor de grup.
Unităţile de grup sunt interconectate două câte două printr-o magistrală de control.
Acest lucru face posibil ca în cazul defectării unui procesor de grup, procesorul celeilalte
unităţii să preia şi abonaţii procesorului defect.
Unităţile de grup sunt conectate la unitatea centrală prin fluxuri PCM prin care se
asigură transmiterea vocii cât şi comunicarea între procesoarele de gup şi unitatea centrală.
Unităţile de grup sunt echipate de asemenea cu generator de apel.
Tensiunile necesare alimentării unităţii centrale şi a unităţilor de grup sunt obţinute cu

ajutorul unor convertoare DC/DC care sunt alimentate la -48V şi care furnizează tensiunile de
± 5Vcc.
Sursele de alimentare şi generatorul de apel sunt dublate: au două secţiuni identice,
una activă şi una de rezervă.
Pagina 31 din 133

Blocul de alimentare conţine un filtru de separare a tensiunii de -48V în -48V

analogic pentru alimentarea buclei şi -48V digital pentru alimentarea convertorilor DC/DC.
De asemenea mai conţine siguranţe pentru fiecare unitate de grup.
Blocul de alimentare conţine redresorul de -48V şi bateriile.
Taxarea este asigurată de către procesorul de administrare şi taxare, informaţia de
taxare fiind memorată pe harddisk şi trimisă la centrul de supraveghere.
Ca facilităţi de abonat, centrala asigură serviciile standard pentru o centrală digitală:
apel de urmărire, apel programat, semnalizare apel în aşteptare, restricţionare acces cu parolă,
numerotaţie automată.
2.2. Arhitectura hardware

Schema bloc a centralei telefonice care evidenţiază şi a structura arhitecturii hardware

este prezentată în figura de mai jos:
Pagina 32 din 133

Figura 2.2.1: Arhitectura hardware a centralei telefonice TOPEX 1000D
Abrevierile din figură au următoarele semnificaţii:

PCTA - Procesor Central de Tratare Apeluri;
UA - Unitate de Abonaţi;
UTD - Unitate de Trunchi Digital
Procesorul de mentenanţă şi administrare este realizat pe un calculator compatibil
IBM-PC. Procesorul de mentenanţă gestionează baza de date cu configutraţia centralei, baza
de date de taxare şi testarea periodică a centralei. Comunicaţia cu procesoarele centrale se
face serial.
Pagina 33 din 133

Procesorul Central de Tratare Apeluri ( PCTA ) este cel care gestionează resursele
centralei. Procesoarele de grup sunt interogate periodic de către procesoarele centrale asupra
stării liniilor. La iniţierea unui apel procesorul central stabileşte conexiunea prin câmpul de
comutaţie şi asigură sincronizarea proceselor ce cooperează la tratarea apelului. Tot
procesorul central asigură taxarea convorbirilor.
Procesoarele de grup ( PG ) gestionează abonaţii locali şi trunchiurile. Ele comunică
procesorului central informaţii privind starea liniilor şi gestionează resurele locale care permit
accesul la câmpul de comutaţie central. Procesoarele de grup comunică cu Unitaăţile de
Abonat (UA) şi cu Unităţile de Trunchi Digital (UTD) pe o magistrală serială. Fiecare
procesor de grup gestionează două magistrale seriale (Bus0 şi Bus1). Bus0 este folosită
pentru a comunica cu unitaţile de abonat proprii, iar Bus1 este folosit pentru a prelua unităţile
de abonat ale unui procesor de grup defect.
Unităţile de abonat ( UA )conţin opt interfeţe de linie de abonat. Acestea sunt
supravegheate de un procesor local care comunică procesorului de grup evenimentele apărute
pe linie.
Unităţile de trunchi digital ( UTD ) conţin o interfaţă de trunchi digital. Aceasta este
controlată de un procesor local care comunică procesorului de grup evenimentele de pe
fiecare canal.
Comunicaţia între procesoarele centrale şi procesoarle de grup se relizează prin
fluxurile PCM pe două canale rezervate pentru comunicaţie.
Fiecare procesor de grup este conectat printr-un flux PCM la fiecare din cele două
procesoare centrale. În funcţionarea normală apelurile sunt tratate alternativ de un PCTA sau
de altul. Dacă unul din procesoarele centrale se defectează atunci procesorul rămas funcţional
va prelua tratarea tuturor apelurilor, capacitatea de realizare a convorbirilor înjumătăţindu-se.
2.2.1 Procesorul Central de Tratare Apeluri

Procesorul Central de Tratare Apeluri este cel care gestionează activitatea întregii
centrale.
Pagina 34 din 133

Principalele funcţii ale acestuia sunt:

tratarea tuturor cererilor de apel;
gestiunea conexiunilor prin câmpul de comutaţie;
comunicaţia cu procesoarele de grup;
generarea taxării;
iniţierea programelor de test la nivelul procesoarelor de grup;
detectarea configuraţiei centralei.
Datorită importanţei procesorului central acesta este dublat. În funcţionare normală,

tratarea apelurilor este distribuită uniform între ambele procesoare centrale. În cazul
defectării unuia dintre ele, toate apelurile vor fi tratate de procesorul rămas funcţional.
Evident că aceasta va duce la o scădere a capacităţii de trafic, dar centrala va continua să
funcţioneze. Defectarea unuia din procesoarele centrale se alarmează la terminalul de
administrare şi mentenanţă.
Figura următoare prezintă principalele elemente componete ale procesorului central
de tratare apeluri:
Pagina 35 din 133

Figura 2.2.1.1 - Schema bloc a Procesorului Central de Tratare Apeluri
Interfaţa de bus asigură amplificarea semnalelor de adrese, date şi control, generează

semnale de selecţie pentru accesul la câmpul de comutaţie şi sincronizează funcţionarea
procesorului cu cea a câmpului de comutaţie pe timpul acceselor la acesta din urmă.
Câmpul de comutaţie este realizat cu 4 comutatoare spaţio-temporale interconectate
ca în figura următoare. Se obţine un comutator spaţio-temporal cu 16 fluxuri PCM de intrare
şi 16 fluxuri PCM ieşire. Un grup de abonaţi este conectat la câmpul de comutaţie printr-o
pereche intrare/ieşire realizându-se o concentrare de 4 la 1 ( 128 abonaţi la 32 canale
temporale ). Deoarece arhitectura centralei prevede dublarea câmpului de comutaţie, în
funcţionare normală se realizează o concentrare 2 la 1. Prin câmpul de comtaţie se face şi
comunicaţia cu procesoarele de grup. Fluxurile PCM sunt trimise şi recepţionate prin
amplificatori diferenţiali cea ce oferă o imunitate mai mare la perturbaţii.
Pagina 36 din 133

Figura 2.2.1.2. - Schema bloc a câmpului de comutaţie
Generatorul de ceas generează semnalele de sincronizare pentru întreaga centrală. Se

generează semnalul de sincronizare de cadru F0 şi un ceas de 4MHz. Semnalele sunt trimise
diferenţial prin amplificatoarele de emisie. Pe centrală există două generatoare de ceas (câte
unul pe fiecare procesor central), la un moment dat centrala lucrând cu semnalele generate
numai de unul dintre ele. În caz că dispar semnalele de sicnronizare de la un generator de
ceas se comută automat pe semnalele de la celălalt generator.
Selecţia semnalelor de sincronizare şi generarea semnalelor locale se face cu circuitul
bază de timp.
Generatorul de întreruperi divide semnalul F0 şi generează cereri de întrerupere care
activează procesul de comunicaţie cu procesoarele de grup.
2.2.2 Procesorul de grup
Pagina 37 din 133

Procesorul de grup se află pe nivelul ierarhic numărul 2 si are rolul de asigura

supravegherea abonaţilor ( pentru grupurile de abonaţi ) şi a joncţiunilor ( pentru grupurile de
trunchi digital ), gestionează canalele temporale de pe fluxurile PCM locale şi controlează
accesul la fluxurile PCM spre câmpul de comutaţie.
Schema bloc a Procesorului de Grup este prezentată în figura de mai jos:
Figura 2.2.2.1 . Procesorul de Grup – schema bloc
Comutatorul spaţio-temporal este folosit pentru a dirija canalele din fluxurile PCM
locale grupului spre fluxurile PCM care merg la câmpul de comutaţie. În afară de funcţia de
comutaţie, comutatorul spaţio-temporal mai asigură comunicaţia cu procesoarele centrale.
Fluxurile PCM 0 la 3 sunt folosite local pentru semnalele de convorbire de la abonaţi.
Pagina 38 din 133

Fluxurile PCM 4 şi 5 sunt folosite pentru generarea tonurilor şi a semnalelor multifrecvenţă.

Fluxurile PCM 6 şi 7 se utilizează pentru legătura cu câmpul de comutaţie.
Pentru grupurile de abonaţi locali procesorul de grup se echipează cu circuite
emiţătoare/receptoare DTMF. Pentru grupurile de trunchiuri se echipează cu circuite de
semnalizarea multifrecvenţă R2 (MFR2). Atât blocul DTMF cât şi cel MFR2 sunt relizate cu
procesoare digitale de semnal.
Blocul MFR2 conţine 8 perechi de regiştri înainte/înapoi. Un procesor de grup pentru
trunchi digital poate controla 2 trunchiuri digitale ceea ce înseamnă 8 perechi de regiştri la 30
de joncţiuni.
Blocul DTMF conţine 12 perechi de emiţători / receptori pentru 128 abonaţi.
Baza de timp primeşte semnalele de sincronizare de la unul din generatoarele de ceas
şi generează semnalele locale de sincronizare asigurând relaţiile de fază corecte. Sunt
generate C4 - 4,096 MHz necesar comutatorului spaţio-temproal, C2 2,048 MHz - ceasul de
bit pentru fluxurile PCM şi F0 - semnalul de sincronizare de cadru. Semnalul de ceas C2 şi
semnalul de sincronizare de cadru sunt trimise şi spre unităţile de abonaţi prin amplificatoare
diferenţiale.
Logica de sincronizare generează, pornind de la C2 şi F0, semnalele de sincronizarea
a emisiei (FSx) şi a recepţiei (FSr), pentru generatorul de tonuri şi blocurile DTMF sau
MFR2. Această logică conţine un circuit de tip TSAC (Time Slot Assignment Circuit) şi
logica de comandă a acestuia de către microprocesor.
Generatorul de întreruperi divide semnalul de sincronizare de cadru F0 şi generează
cereri de întrerupere pentru comunicaţia cu procesoarele centrale.
Microprocesorul are două interfeţe seriale. Ambele sunt folosite pentru comunicaţia
cu unităţile de abonaţi.
Toate semnalele sunt emise şi recepţionate prin amplificatori diferenţiali ceea ce
asigură o imunitate sporită la perturbaţii.
2.2.3 Unitatea de abonaţi

Unitatea de abonat conţine 8 interfeţe analogice de linie. Unitatea este controlată de

un microprocesor care supraveghează starea fiecărei linii şi trimite spre procesorul de grup
mesaje de notificare. Schema bloc a unităţii de abonat este prezentată în figura de mai jos:
Pagina 39 din 133

Figura 2.2.3.1 – Unitatea de Abonaţi – schema bloc
O interfaţă foloseşte acelaşi canal temporal atât pentru emisie cât şi pentru recepţie.
Circuitul de sincronizare este realizat cu un circuit integrat specializat de tip TSAC şi este
comandat de către microprocesor prin doi biţi ai unui port de ieşire.
În cadrul unui grup fiecare unitate de abonat are o adresă unică codificată pe 5 biţi.
Această adresă este folosită pentru identificare în cadrul comunicaţiei cu procesorul de grup.
Adresa este cablată pe fundul de sertar şi este citită prin circuitul de citire a adresei.
Rolul UCP de pe unitatea de abonat este de a degreva procesorul de grup de
prelucrarea evenimentelor rapide care apar pe linia de abonat. UCP detectează închiderea şi
deschiderea telefonului precum şi cifrele formate în mod puls şi trimite spre procesorul de
Pagina 40 din 133

grup mesaje de notificare. La comanda procesorului de grup UCP poate conecta o interfaţă la
un canal temporal şi poate trimite curent de sonerie.
Unitatea de abonat este interogată periodic de către procesorul de grup pe una din
magistralele seriale 0 şi răspunde cu evenimentele apărute. Dacă unitatea nu primeşte mesaj
de interogare un anumit timp va selecta automat cealaltă magistrală pe care este interogată de
alt procesor de grup.
În figura 2.2.3.2 este prezentată schema bloc a unei interfeţe de linie analogică.
Interfaţa conţine 3 relee: releu pentru testul liniei de abonat, releu pentru testul interfeţei de
abonat şi reşeu de apel. În figură releele sunt desenate în poziţia normală de funcţionare.
Linia este alimentată în curent continuu prin două generatoare de curent care au o impedanţă
mare în curent alternativ. Semnalul de convorbire este aplicat printr-un transformator unui
circuit de trecere de la 2 la 4 fire şi apoi spre CODEC. Rolul circuitului de trecere de la 2 la 4
fire este de a separa calea de emisie de cea de recepţie.
Figura 2.2.3.2 - Schema bloc a unei interfeţe de linie analogică
Pagina 41 din 133

Detectorul de curent este folosit pentru a detecta starea telefonului.

Pentru testul liniei de abonat se comandă atragerea releului de test al liniei. Linia de
abonat va fi pusă prin contactele acestui releu pe o linie de test care este conectată la un
echipament de test.
Pentru testul interfeţei de abonat se comandă atragerea releului de test al interfeţei.
Prin contactele acestui releu interfaţa este conectată la o linie din echipamentul de test al
interfeţei de abonat.
Pentru a genera curent de sonerie se comandă atragerea releului de apel. Cadenţarea
apelului se face din releu.
2.2.4. Unitatea de trunchi digital

Unitatea de trunchi digital conţine o interfaţă de trunchi digital. Schema bloc a uităţii
de trunchi digital este cea din figura 12. Interfaţa de trunchi este controlată de unitatea
centrală de prelucrare realizată în jurul unui microprocesor din familia Intel 8051.
Pagina 42 din 133

Figura 2.2.4.1 - Schema bloc a uităţii de trunchi digital
Logica de interfaţă asigură interfaţarea microprocesorului cu comutatorul spaţio-

temporal. Comutatorul este folosit pentru controlul interfeţei de trunchi digital şi pentru
conecatrea acesteia la fluxurile PCM ale grupului.
Comunicaţia cu procesorul din grup se face pe fluxul PCM.
Interfaţa serială este folosită în faza de test al unităţii de trunchi digital.
Interfaţa propriu-zisă de trunchi digital este realizată cu un circuit hibrid specializat
pentru interfaţa CEPT de trunchi digital, conform cu recomandările CCITT G.704 pentru
PCM30 . Are facilităţi ca: inserarea şi detectarea semnalelor de sincronizare, codeare şi
decodare HDB3, atenuare programabilă şi CRC opţional.
Conform specificaţiilor interfeţei CEPT cadrele PCM sunt grupate în multicadre
( vezi figura 2.2.4.2). Un multicadru este format din 16 cadre. Într-un cadru PCM se folosesc
Pagina 43 din 133

numai 30 de canale temporale pentru canale telefonice ( canalele 1-15 şi canalele 17-31 )
rămânând două canale folosite unul pentru semnalele de sincronizare de cadru şi multicadru
(canalul temporal 0) şi altul pentru semnalizare de linie pentru canalele telefonice ( canalul
temporal 16 ).
Figura 2.2.4.2 - Interfaţa CEPT
Semnalul de sincronizare de cadru se trimite în canalul temporal 0 în cadrele pare.

Semnalul de sincronizare de cadru conţin un 0 pe poziţia bitului 2. Bitul 1 este rezervat
pentru utilizare internaţională, bitul 3 este 0 iar biţii 4, 5, 6, 7 şi 8 au valorile 11011. În
cadrele impare canalul temporal 0 este folosit pentru a indica alarme. În acest caz bitul 2 este
1, bitul 3 este folosit ca indicator de alarmă către echipamentul PCM distan iar biţii 4, 5 , 6, 7
şi 8 au semnificaţie naţională.
Semnalele pentru semnalizarea de linie a canalelor telefonice (A,B,C şi D ) sunt
trimise în canalele temporale 16 ale cadrelor 1-15. În cadrul 1 se trimit semnalizarile pentru
canalul telefonic 1 şi 17, în cadrul semnalizările pentru canelele telefonice 2 şi 18, ş.a.m.d.
Semnalizarea de linie se face conform protocolului R2 digital. În cadrul acestui
protocol se utilizează două căi de semnalizare, înainte şi înapoi, pentru fiecare folosindu-se
câte 2 biţi af şi bf pentru sensul înainte ab şi bb pentru sensul înapoi..
2.3. Arhitectura software
Pagina 44 din 133

La realizarea software-lui s-au avut în vedere următoarele obiective:

modularitate
extensibilitate atât a hardware-ului cât şi a software-ului
siguranţă în funcţionare
întreţinere comodă
adaptare la structura distribuită a sistemului
independenţă cât mai mare în raport cu hardware-ul
Prinicipalele caracteristici ale software-ului sunt:
arhitectură modulară, ierarhizată, distribuită
diviziune funcţională pentru componentele software
distribuire optimă între procesoarele sistemului - sarcinile complexe care nu necesită
un răspuns critic în timp la nivel central: - sarcinile de timp real la nivel periferic
organizare stratificată
Arhitectura software-ului este schiţată în figura 2.3.1:
Figura 2.3.1 - Arhitectura software a centralei TOPEX 1000D
Componenta OAM - Operare, mentenanţă, administrare
Pagina 45 din 133

Are ca scop comunicaţia om-maşină, întreţinerea bazelor de date pe disc, sistem de

alarme, comunicaţie cu centrul de supraveghere, modificarea configuraţiei, gestiunea
resurselor. Funcţiile realizate de acest modul sunt:
Operare, administrare, acestea includ:
măsurători de trafic şi performanţe
gestiunea centralei
modificări de date semipermanente ( plan numerotaţie, categorii, rutare, tarife )
gestiunea reţelei - analiza situaţiilor de congestie internă/externă, rapoarte, modificări
de alocare la comanda operatorului
Mentenanţă
lansare de teste pentru linii, trunchiuri, circuite auxiliare
interacţiune a operatorului cu sistemul de alarme
Componenta IS - întreţinere şi siguranţă

Are ca scop menţinerea stării de funcţionare a centralei prin teste periodeic de
ansamblu şi interacţiunea sistemului de operare pentru reconfigurări. Această componentă
softare este cea care asigură la nivel software comutarea componentelor dublate.
Are ca funcţii:
localizarea defectelor l anivelul UA, PG sau PCTA
reiniţializarea modulelor software şi hardware
efectuarea testelor şi tratarea erorilor
comanda reconfigurărilor, prin interacţiune cu sistemul de operare
comanda alarmelor
reîncărcări de software
Componenta TA - tratarea apelurilor

Tratarea apelurilor la nivel logic are ca scop tratarea apelurilor locale, de ieşire şi de
intrare, independent de sistemul de semnalizări şi de hardware.
Are ca funcţii:
stabilirea / menţinerea/ eliberarea apelurilor normale
identificarea linie şi a tipului de apel
determinarea restricţiilor/drepturilor
achiziţia adresei-destinaţie ( de la sofftware-ul de semnalizare şi suport )
Pagina 46 din 133

taxare
comanda conexiunilor
eliberarea ressurselor
stabilirea/menţinerea/eliberarea apelurilor cu cereri de servicii adiţionale
Idependenţa faţă de sistemul de semnalizări şi de hardware este realizată de software-
ul de semnalizare şi suport.
Acesta realizeză:
tratarea semnalizărilor
detecţia evenimentelor de semnalizare
virtualizarea evenimentelor ( independenţa de harware-ul de semnalizare)
translatarea evenimentelor de semnalizare în mesaje cu semnificaţie telefonică.
alocarea/eliberarea resurselor de semnalizare
- gestiunea şi alocarea resurselor pentru apel
comanda interfeţelor telefonice
Componenta SO + BD - Sistem de operare, baza de date

Are ca scop:
gestiunea resurselor hardware şi software ale sistemului
interfaţarea cu hardware-ul
tratarea erorilor şi reconfigurarea sistemului ( prin inreacţiune cu componenata IS )
furnizarea unui suport de comunicaţie între procese
gestionarea bazei de date
Funcţiile realizate sunt:
- nucleu, care asigură:
planificarea în timp real a proceselor
gestiunea / protecţia memoriei
control temporizări
control întreruperi
intrări/ieşiri la nivel fizic
- program de comunicaţie de mesaje între procese
- iniţializare / reconfigurare
- gestiunea bazei de date
Modul de distribuire a componentelor software descrise mai sus la nivelul
procesoarelor este arătat în figura 2.3.2:
Pagina 47 din 133

Figura 2.3.2 - Distribuţia componentelor software în procesoare
Capitolul 3 “VoIP card” – VoIP gateway
3.1 Prezentare generală
Până la îndeplinirea uneia din marile dorinţe în privinţa realizării comunicaţiilor, am

numit aici integrarea serviciilor, mai este mult timp, datorită unor variate motive: probleme
specifice fiecărui tip de reţea, nivelul investiţiilor în infrastructura deja existentă, etc. Din
acest motiv, pentru buna intercomunicare între diferitele reţele ce au fiecare particularităţile
sale (formatul datelor, semnalizări, etc.), se folosesc dispozitivele numite gateway.
Un gateway se află la graniţa dintre 2 reţele diferite şi are rolul de a realiza
interconectarea acestora. El trebuie să aibă module de funcţionare specifice celor 2 reţele şi
trebuie să realizeze translaţia semnalizărilor şi formatelor diferite de date cu care se lucrează.
Gateway-ul H.323 este o componentă esenţială bunei intercomunicări a reţelei H.323
cu celelalte reţele telecom fiind una din cele 4 componente ale unei reţele H.323, iar alături
de terminale, el are un caracter obligatoriu.
“VoIP card” este un gateway de voce, o poartă de ieşire pentru transportul vocii
folosind ca suport reţeaua IP. Ca orice gateway, sunt obligatorii implementările
Pagina 48 din 133

funcţionalităţilor pentru compatibilitatea cu reţeaua PSTN şi reţeaua de pachete IP şi cea

pentru translaţia formatelor diferite de transmisie a datelor.
“VoIP card” funcţionează în arhitectura generală a centralei telefonice publice
TOPEX 1000D şi reprezintă calea de ieşire pentru transportul vocii peste o reţea pachete de
tip IP.
Pagina 49 din 133

3.2 Amplasarea cartelei în arhitectura

funcţională a centralei
Proiectarea şi implementarea funcţională a centralei telefonice publice TOPEX 1000D

s-a realizat avându-se în vedere obiective ca: modularitate, extensibilitate atât a hardware-
ului, cât şi a software-ului, independenţă cât mai mare în raport cu hardware-ul, împingerea
“inteligenţei” cât mai aproape periferia funcţionalităţilor. Toate acestea au dus la obţinerea
unei arhitecturi ierarhizate şi distribuite, organizare stratificată şi posibilităţi de dezvoltare
ulterioară a diversor aplicaţii.
“VoIP card” este o aplicaţie care trebuie să se integreze foarte bine în arhitectura
funcţională (hardware şi software) deja construită a centralei telefonice, mai ales că are rolul
de a realiza comunicarea centralei telefonice cu alt tip de reţea de transport, bazată pe
comutaţia de pachete IP, total diferită de comutaţia de circuite.
În urma analizei celei mai bune poziţionări a cartelei în arhitectura generală a
centralei, analiză care a avut în vedere diverşi factori de decizie, s-a decis folosirea ei pe
ultimul nivel ierarhic, cel al nivelul Unităţii de Abonaţi (UA).
Figura 3.2.1. ilustrează amplasarea cartelei în arhitectura structurală a centralei
telefonice:
Pagina 50 din 133

A m p la s a r e a c a r te le i în a r h ite c tu r a s tr u c tu r a lã a c e n tr a le i
M e n te n a n tã s i
P ro c e s o r c e n tra l d e P ro c e s o r c e n tra l d e
a d m in is tr a r e
tr a ta r e a p e lu r i tr a ta re a p e lu r i
16 x 16 16 x 16
Gen
Gen
ceas
ceas
0 1 ... 1 4 1 5 0 1 ... 1 4 1 5
U A U A U A U A
par im p a r par im p a r
P CM 0
0
P r o c e s o r1 PCM 1
Sbus0
g ru p Sbus1
a b o n a ti 2
3
0
P ro c e s o r1
g ru p S
S
b
b
u s1
u s0
a b o n a ti 2 P C M 1
P C M 0
3
U A U A U A
im p a r par im p a r
R etea IP V o IP G a te w a y
F ig u r a 3 . 2 . 1
Pagina 51 din 133

3.3 “VoIP card” – extensie a funcţionalităţilor centralei telefonice
Dezvoltarea structurată a arhitecturii centralei telefonice TOPEX 1000D şi

împingerea “inteligenţei” până aproape de periferie în scopul diminuării efortului de calcul al
unităţii centrale de calcul, au permis proiectarea destul de facilă a unui gateway H.323, care
să realizeze puntea de legătură pentru transportul semnalelor de voce pe suportul constituit de
o reţea de pachete IP.
Anunţam în subcapitolul precedent faptul că în urma analizei privitoare la cea mai
bună amplasare a cartelei în arhitectura funcţională a centralei telefonice, aceasta va fi pe
ultimul nivel al ierarhiei structurale.
Întrucât cartela funcţionează pe acelaşi ultim nivel, ca şi Unitatea de Abonaţi, în
raport cu ansamblul structural ea intercomunică în aceeaşi manieră ca şi cartela UA. Un rol
foarte important în această situaţie îl are componenta hardware de adaptare la “fundul de
sertar”, fiind poarta de intrare sau/şi de ieşire a semnalelor prin intermediul cărora cartela
interacţionează cu sistemul (semnale de ceas, alimentare, fluxuri PCM, etc.).
Gateway-ul “VoIP card” poate fi privit ca un periferic de tip “slave” al Procesorului
de Grup(PG) şi ca o joncţiune de intrare/ieşire a sistemului.
Fiind un subordonat direct al Procesorului de Grup (PG), la fel ca şi în cazul UA-ului,
se folosesc aceleaşi modalităţi de comunicare cu “VoIP card”. Comunicaţia de voce se
realizează prin intermediul celor 2 fluxuri PCM folosite pentru abonaţii aferenţi lui, pe care le
primeşte folosind adaptorul de fund de sertar, iar comunicaţia de semnalizare se face folosind
o reţea de comutaţie de mesaje, prin protocoale de acces multiplu cu arbitraj centralizat,
arbitrul aflându-se în PG:
Din punctul de vedere al posibilităţii de realizare a apelurilor, trebuie amintit că,
întrucât, în principiu, gateway-ul este o poartă de transfer între 2 reţele de tip diferit, nu se
poate vorbi despre satisfacerea unor apeluri locale folosind “VoIP card”. Pot fi însă cu
succes îndeplinite apeluri de intrare sau apeluri de ieşire ale centralei telefonice în
reţeaua H.323.
Pagina 52 din 133

La stabilirea unui apel telefonic de către un abonat local, acesta va fi pus în faţa
următoarelor variante, iar în funcţie de opţiunea abonatului telefonic, are loc în Unitatea
Centrală analiza şi decizia asupra interfeţei de ieşire a apelului:
Unitatea de Abonat (UA), pentru apeluri locale.
Joncţiune digitală, pentru apeluri de ieşire prin reţeaua telefonică.
VoIP card, pentru apeluri de ieşire prin reţeaua IP.
Prezintă interes varianta în care opţiunea abonatului este de a folosi ca poartă de ieşire
a apelului gateway-ul VoIP. În această situaţie, prima măsură ce va fi luată este de a
semnaliza PG-ului intenţia de realizare a unui apel. Cel din urmă îi va aloca pe fluxul TDM
de comunicare cu UA-urile un canal temporal pentru transmiterea eşantioanelor de voce. În
acelaşi timp va anunţa gateway-ul de opţiunea de efectuare a unui apel şi va aloca de
asemenea un canal temporal pe fluxul PCM cu care comunică cu gateway-ul, canal pe care în
PG vor fi comutate apoi eşantionalele de voce. “VoIP card”-ul, prin modulul său ce
realizează interfaţarea şi comunicarea cu reţeaua telefonică va prelua conţinutul canalului
corespunzător şi buffer-a în memoria sistemului. De acolo, vor intra în sarcina modulului de
procesare a vocii, iar modulul de interfaţă şi comunicare cu reţeaua H.323 va iniţia şi stabilii
funcţionarea unui apel în reţeaua de pachete.
În cazul apelurilor de intrare, detectate de către modulul de interfaţă şi comunicare cu
reţeaua H.323 al “VoIP card”, celălalt modul de interfaţă cu reţeaua telefonică semnalizează
operaţia PG-ului, care alocă un canal temporal pe fluxul TDM prin intermediul căruia
comunică. Acest canal va permite transportul eşantioanelor recuperate, furnizate de către
modulul de procesare a vocii, către PG, locul unde vor fi comutate către un abonat local, sau
pe flux PCM la PCTA şi apoi către joncţiunea digitală de ieşire, în cazul unui apel de tranzit.
Pagina 53 din 133

Capitolul 4. VoIP card”–Implementare software

4.1 Scurtă prezentare hardware
Evoluţia spectaculoasă a tehnologiei de producere a circuitelor integrate a dus la

obţinerea unor performanţe deosebite din partea lor, dar mai ales un raport performanţă/preţ
foarte ridicat. Dintre acestea, DSP-urile au avut un mare salt calitativ, lucru care le-a
transformat în componente aproape ideale pentru multe aplicaţii de timp real, un exemplu
fiind şi cea de faţă.
Cartela VoIP are o structură hardware care să permită dezvotarea şi funcţionarea
modulară a unui gateway VoIP, structură prezentată în capitolul 1. Echipată cu 4 DSP-uri
Analog Devices AD2181, poate realiza preluarea, compresia şi transferul către procesorul
gazdă a 16 canale PCM 64 kbs. Principalele sale blocuri hardware componente sunt:
Adaptor de fund de sertar.
Matrice de comutaţie spaţio-temporală.
DSPk, k=1,4.
Logică de interfaţă
Host PC.
Adaptorul de fund de sertar – deşi nu are o foarte academică denumire, este foarte
important pentru buna comunicare a cartelei cu centrala telefonică. El are rolul de a-i asigura
plăcii accesul la alimentarea electrică ( -48V, -5V, GND, +5V), semnalele de sincronizare de
bit şi de cadru, venite de la Procesorul Central de Tratare Apeluri şi, nu în ultimul rând
fluxurile PCM de 2 Mbs de comunicare cu PCTA şi PG.
Matricea de comutaţie spaţio-temporală – construit în jurul unui chip MT 8980, blocul
are rolul de a comuta spaţio-temporal canalele temporale a 8 fluxuri PCM de 2 Mbs.
DSPk – cartela conţine 4 DSP-uri de tip Analog Devices AD2181. Acestea au o mare
putere de lucru şi sunt potrivite aplicaţiilor de pachetizare şi transmisie a vocii.
DSP-ul AD2181 are un spaţiu de memorie internă de 16Kx24 biţi memorie de
program de tip RAM şi 16Kx16 biţi pentru memoria de date, nefiind permis accesul
decât pe 16 biţi în acest spaţiu,. El mai poate folosi insă alte 4 zone de memorie
externe: de date, de program, I/O şi byte memory. Pentru lucrul cu aceste zone de memorie,
sunt furnizate semnale de selecţie a fiecăreia din cele 4 zone.
Pagina 54 din 133

În aplicaţia de faţă nu este folosită decât memoria de octeţi (“byte memory”), ca zonă
de memorie externă. Deşi volumul de memorie ce poate fi adresat şi folosit de DSP ca
memorie de octeţi este de 4Mbytes, ce sunt organizaţi în 256 pagini a câte 16Kx8 biţi, se
foloseşte doar un singur chip de memorie de 512Kx8 biţi.
Pentru o bună comunicare cu procesorul gazdă, AD2181 are 4 porturi: [5]
2 porturi seriale, configurabile prin intermediul unor regiştrii interni de control.
Portulul de acces BDMA (Byte-memory Direct Memory Access), ce poate fi folosit
pentru “boot”-are şi acces pe 8 biţi la memoria externă.
Portul IDMA(Internal Direct Memory Access) – port paralel ce poate fi folosit pentru
“boot”-are, sau accese din partea procesorului gazdă. DSP-ul asigură 6 pini de control pentru
buna funcţionare a portului IDMA.
Host PC [19]– este folosit un embedded PC/104 cu un procesor de 40MHz,
compatibil 386SX şi 8Mb memorie RAM. Pentru interfaţa cu reţeaua Ethernet lucrează un
chipset Realtek 8139 şi portul fizic compatibil 10Base-T NE2000.
Pentru stocarea datelor, suportul fizic este un DiskOnChip cu capacitatea de 2 Mb,
existând porturi pentru legătură cu HDD şi FDD.
Pe lângă portul de reţea, placa mai beneficiază de 4 porturi seriale, port paralel şi,
poate cel mai important, mai ales privit din direcţia comunicaţiei cu “VoIP card”, portul ISA,
cu 104 pini. Aceştia furnizează semnalele de control, bus-ul de date, bus-ul de adrese,
semnalul de ceas ISA (8MHz), cererile de întrerupere venite din partea DSP-urilor.
Logica de interfaţă – alcătuită dintr-o multitudine de componente digitale, are rolul a
realiza decodificarea adreselor, obţinerea unor semnale de control, cererea de întrerupere de 2
ms şi interfaţa de acces la DSP-urile şi procesorul gazdă, PC/104.
Schema hardware de principiu a “VoIP card” care prezintă componentele mai sus
amintite şi modul lor de intercomunicare este prezentată în figura 4.1.1:
Pagina 55 din 133

A d a p to r fu n d d e s e rta r
M a tr ic e c o m u ta tie s p a tio -te m p o r a lã
DSP 0 DSP 2
DSP 1 DSP 3
Date, adrese, comenzi, IRQ
D a te D a te
A d re s e A d re s e
C om enzi C om enzi
L O G IC Ã D E IN T E R F A T Ã
Em bedded PC 104
E th e rn e t
Figura 4.1.1. Schema hardware de principiu a “VoIP card”
Pagina 56 din 133

4.2 Software-ul aplicaţiei

Datorită complexităţii unui gateway, de orice fel ar fi el, trebuie să aibă mai multe
plane de funcţionare, unele specifice celor 2 reţele la graniţa cărora se doreşte acţiunea sa şi
unul de translaţie a celor 2 formate diferite de date cu care se lucrează.
F u n c tii
C o n v e r s ie d e
s p e c ific e F u n c tii
p r o to c o a le s i tra n z la tia SCN
unui s p e c ific e
fo r m a te lo r d e
te r m in a l r e te le i S C N
tr a n s m is ie
H .3 2 3
PSTN
C o m p u te r
T e le fo n
Figura 4.2.1 Gateway IP/PSTN

Un gateway de voce nu este cu nimic diferit acestui principiu, iar funcţiunile lui se pot
împărţi în 4 module de activitate:
Modulul de pachetizare a vocii. – cunoscut şi sub numele de modulul de procesare a
vocii, funcţionează de regulă într-un DSP ( Digital Signal Processor ), datorită puterii sale
ridicate de calcul.
Modulul de realizare a semnalizării telefonice – interacţionează cu echipamentele
telefonice, translatând semnalizările telefonice în schimbări de stare, folosite de către
modulul de protocoale de reţea pentru stabilirea, menţinerea şi eliberarea conexiunilor.
Modulul de protocoale de reţea – procesează informaţiile de semnalizare şi le
converteşte din semnalizări specifice reţelei telefonice în protocoale de semnalizare în mod
pachet, folosite la stabilirea conexiunilor în reţeaua IP ( ex: Q.933 ).
Modulul de management a reţelei – asigură interfaţa de gestiune a vocii, pentru

menţinerea şi configurarea celorlalte module ale sistemului.
Pagina 57 din 133

Folosind hardware-ul mai înainte prezentat pe scurt, aplicaţia urmăreşte să

implementeze cele 4 module.
După cum am văzut în figura 1.3.2, cele 4 module ale software-ului rulează practic în
cele 2 unităţi de prelucrare a datelor, am numit aici procesorul gazdă, reprezentat de PC/104
şi cele 4 DSP-uri.
În cele 4 DSP-uri rulează modulul de procesare a vocii, implementat prin programe
care urmăresc:
Preluarea fluxurilor PCM de 2 Mbs de la PG (Procesorul de Grup).
Selectarea şi preluarea în buffer-ele de recepţie a canalelor temporale corespunzătoare
conexiunilor telefonice care se doresc a fi transportate pe suportul reprezentat de reţeaua IP.
Realizarea codării, conform specificaţiilor G.711, G.722, G.723.1, G.728.
Plasarea lor în zona de date, reprezentată de 2 buffer-e de unde procesorul gazdă le va
prelua. DSP-ul semnalizează din care buffer trebuie citit.
Buffer-ează pachetele de voce primite de la host, recepţionate din reţea.
Preluarea lor din zonele de memorie, reprezentate de asemenea de 2 buffer-e.
Decodarea acestora conform aceloraşi specificaţii mai sus amintite.
Alocarea pe fluxul PCM de comunicare cu PG-ul a canalelor temporale.
Inserarea în aceste canale a eşantioanelor de voce refăcute, de transmis către
terminalul telefonic.
Generează cererea de întrerupere către host.
Codul sursă pentru compilare, care apoi va fi încărcat prin IDMA şi rulat în DSP-uri
este scris atât în limbajul C++, cât şi în limbaj de asamblare specific AD2181.
Software-ul care rulează în procesorul gazdă, am numit aici modulul PC/104, are rolul
de a implementa celelalte 3 module ale structurii aplicaţiilor de voce: modulul de realizare a
semnalizării telefonice, modulul de protocoale de reţea, modulul de management a reţelei. Pe
lângă acestea, tot in PC/104 trebuie implementată şi buna comunicare cu DSP-urile.
4.2.1 Suportul dezvotării aplicaţiei în PC/104

Referinţe bibliografice: [2], [3], [4], [5], [19], [20], [21]
Modulul PC/104 ( [19] ) este un minicalculator integrat compatibil 386SX, cu 4MB

memorie RAM. Este foarte util în aplicaţiile de control şi comunicare cu alte dispozitive
periferice datorită portului ISA de 104 pini, punând la dispoziţie BUS-ul de adrese, BUS-ul
Pagina 58 din 133

de date, semnale de control, cereri de întrerupere, etc. Nu este obligatorie folosirea tuturor
acestora, acest lucru rămânând la latitudinea proiectantului.
Toate aceste facilităţi mai sus amintite îl fac foarte potrivit pentru sarcina sa de
procesor gazdă în cazul aplicaţiei noastre, unde pe lângă cele 3 module trebuiesc
implementate controlul şi gestiunea celor 4 DSP-uri şi a matricii de comutaţie.
Întreg software-ul aplicaţiei se află stocat pe un DiskOnChip cu capacitatea de 2MB.
S-a folosit un sistem de operare Microsoft DOS 6.22, care, deşi nu conţine stivă
TCP/IP, este de mici dimensiuni şi reprezintă un bun suport al aplicaţiilor implementate în
limbajul C++, mai ales celor dezvoltate cu mediul Borland C++ 3.1.
Inconvenientul reprezentat de lipsa suportului de comunicare cu reţeaua IP a fost
înlăturat prin folosirea stivei TCP/IP “WATTCP” ( [4], [20] ) folosibilă în aplicaţii de
comunicare, chiar şi de timp real, sub sistemul de operare MS-DOS. Dacă ar trebui să o
raportam la nivelul OSI, atunci trebuie spus că funcţionează la nivelele 3 şi oferă interfaţa
pentru funcţii specifice nivelului 4 (sockeţi, porturi, etc.)
Pentru funcţionarea stivei WATTCP trebuie mai întâi încărcat “packet driver”-ul
specific fiecărui chip-set de reţea. Acesta este furnizat de către producătorul NIC-ului
(Network Interface Card – placa de reţea) şi reprezintă interfaţa dintre stiva software şi
mediul fizic de transmitere a pachetelor de date(nivel 2 OSI simplificat). În aplicaţia de faţă,
“packet driver”-ul este conţinut în fisierul “pktdrv.com” şi este încărcat la pornirea hardware-
ului printr-un instrucţiunea “c:\pktdrv.com 0x60”, aflată în fisierul “autoexec.bat”.
Odată încărcat driverul, care instalează o întrerupere de DOS pentru lucrul cu placa de
reţea, utilizarea software-ului TCP/IP se face posibilă prin copierea a 7 fişiere
de tip header (“*.h”) în directorul “include” al mediului de dezvoltare Borland C++

3.1 şi includerea lui “tcp.h” în fişierul conţinând codul sursă al aplicaţiei dorite. În afară de
aceasta, mai trebuie inclus în proiectul de lucru un fişier de tip “.lib”, “wattcp.lib”, în funcţie
de modelul de lucru utilizat: small, large, huge.
Dacă până acum nu am vorbit decât despre modul de folosire a stivei WATTCP,
trebuie spus că pentru configurarea informaţiilor de reţea IP sunt 2 modalităţi. Prima este cea
în care aflarea lor se face prin BOOTP, în cazul în care în subreţeaua locală se află un server
dedicat acestor tranzacţii. În cel de-a 2-a situaţie, aceste informaţii trebuiesc introduse
manual, iar pentru aceasta trebuie ca în directorul în care se află executabilul aplicaţiei să
Pagina 59 din 133

existe un fişier de configurare cu numele “Wattcp.cfg”. Acesta, scris în mod text, trebuie să
aibă următoarea formă:
print="Packet-driver incărcat…"
my_ip=194.156.176.99
netmask=255.255.254.0
nameserver=194.156.176.1
gateway=194.156.176.1
domainslist="topex.rdsnet.ro"
Ca un sprijin al folosirii stivei Wattcp în aplicaţia de faţă, trebuie spus că ea reprezintă
principalul mijloc al realizării comunicaţiilor în reţelele de tip IP pentru sistemele ce folosesc
DOS-ul ca sistem de operare şi, poate şi datorită distribuirii ei gratuite, este la baza unei
multitudini de aplicaţii utilitare de tip telnet, ssh, client ftp, client POP3, web browsing, etc.,
de asemenea accesibile gratuit.
Aplicaţiile de voce, indiferent pe ce suport de transport, sau sistem de operare în care
rulează sunt aplicaţii de timp real. O implementare secvenţială, cu un singur fir de execuţie
(single thread) nu este suficientă unor situaţii în care timpul reprezintă un factor esenţial în
buna lor funcţionare. De aceea am preferat folosirea unui kernel de timp real, numit (/COS II
(MicroController Operating System, versiunea 2). ( [3], [21] ).
(/COS II, evoluţie a lui (/COS, este un “sistem de operare” cu kernel de timp-real
destinat aplicaţiilor integrate. Cea mai mare parte a lui este scrisă în ANSI-C, iar anumite
componente, dorite cât mai puţine datorită dorinţei de portabilitate, sunt scrise în limbajul de
asamblare dedicat microprocesorului folosit.
(/COS II poate fi portat pe o mare varietate de procesoare, cu condiţia ca ele să
asigure “stack pointer” şi regiştrii CPU, care pot fi introduşi şi scoşi din stivă. De asemenea,
compilatorul C trebuie să permită scrierea de scrierea de porţiuni de cod în limbaj de
asamblare. (/COS II poate rula pe cele mai multe procesoare de 8, 16 32, sau 64 de biţi,
microprocesoare şi DSP-uri.
µ /COS II este o soluţie foarte scalabilă, această reflectându-se în posibilitatea de a
alege doar acele servicii care sunt necesare aplicaţiei proiectate, lucru care reduce volumul de
Pagina 60 din 133

memorie RAM/ROM ce urmează a fi folosit. Scalabilitatea este implementată prin

intermediul unor variabile configurabile ce includ la compilare doar secţiunile de cod
(serviciile) dorite.
La fel ca majoritatea kernel-urilor de timp-real, µ /COS II este de tip preemptiv
(programatorul kernel-ului lansează în execuţie mereu task-ul cu prioritatea cea mai mare).
µ /COS II-ul poate gestiona un număr de 64 task-uri. Dintre acestea, 8 sunt folosite de
sistem, lucru ce face posibilă utilizatorului folosirea a 56. Fiecare task necesită propria sa
stivă de lucru, configurabilă din punctul de vedere al volumului de memorie alocat, pentru
reducerea necesarului de memorie RAM al aplicaţiei.
Câteva din serviciile oferite de µ /COS II sunt: mailbox-urile, cozi, semafoare, funcţii
de gestiune a timpului, etc. De asemenea, pot fi folosite întreruperi organizate pe 255 de
nivele, care pot suspenda execuţia unui task.
Calităţile de mai sus amintite, adaugate celor omise fac µ /COS II-ul un foarte bun
sistem de operare de timp-real, care, datorită programării task-urilor cu care el lucrează,
permit dezvoltarea în bune condiţii a aplicaţiilor real-time, “multi-thread”.
Figura 4.3.1.1 prezintă componentele software care vor reprezenta stratificat suportul
de dezvoltare al aplicaţiei.
A p lic a tia d e tim p -r e a l
M ic r o C o n tr o lle r
S o ftw a r e T C P /IP
O p e ra tin g S y s te m
"W A TTC P "
v .2
P a c k e t D r iv e r
M S -D O S 6 .2 2 ( c :\p k td r v .c o m
0x60 )
P ro c e s a re C o m u n ic a r e
Pagina 61 din 133

Figura 4.2.1.1 Componentele care ajută la buna dezvoltare şi funcţionare a aplicaţiei.
4.2.2 Funcţionarea software a PC/104

Referinţe bibliografice: [2], [3], [4], [5], [19], [20], [21], [22]
După ce a fost încărcat “packet driver”-ul, modulul hardware PC/104 este pregătit
pentru rularea aplicaţiei. Se lansează în execuţie executabilul rezultat în urma compilării
proiectului “rtp_ucos.prj”. Pentru dezvoltarea şi compilarea acestuia s-a folosit mediul
Borland C++ 3.1, iar codul sursă a fost scris în limbajul C++ cea mai mare parte a sa,
anumite fragmente fiind scrise în limbaj de asamblare 8086.
Fişierul “rtp_ucos.prj” se va încărca la deschiderea mediului de dezvoltare în
directorul ce conţine aplicaţia, iar el conţine fişierele care vor fi compilate, create legăturile,
rezultând fişierul executabil. Proiectul ce va fi compilat conţine următoarele:
Fişiere pentru funcţionarea µ /COS II-ului. [3].
Ucos_II.c – include la compilare codul sursă pentru asigurarea tuturor serviciilor
oferite de µ C/OS II(mailbox, semafoare, gestiunea task-urilor şi a timpului, etc.), servicii
care în funcţie de valorile atribuite variabilelor din fişierul de configurare “OS_cfg.h” sunt
sau nu incluse în aplicaţia dorită.
OS_Cpu_C.c – defineşte o funcţie de creare a stivei de lucru a fiecărui task şi funcţii
ce sunt apelate la crearea unui task, la ştergerea lui, la schimbarea de context, sau la fiecare
tick.
Pc.c – defineşte funcţii legate de interfaţa de afişare şi folosirea tastaturii, salvarea
contextului DOS la pornirea µ C/OS II-ului, restabilirea sistemului de operare la finalul
aplicaţiei µ C/OS, instalarea de noi vectori de întrerupere şi stabilirea frecvenţei de “tick”.
OS_Cpu_A.asm – scris în întregime în limbaj de asamblare, conţine funcţii privitoare
la punerea în funcţiune a task-ului cu prioritatea cea mai mare în momentul pornirii µ C/OS-
ului, efectuarea de “task switch”, servirea întreruperii de “tick”.
Wattcphg.lib – este compilat împreună cu celelalte fişiere ale proiectului şi realizează
interfaţa dintre funcţiile de bibliotecă ale stivei WATTCP şi “packet driver”, pentru
asigurarea suportului de comunicaţie în reţeaua IP. Este
Pagina 62 din 133

dependent de modelul folosit în dezvoltarea aplicaţiei, în situaţia de faţă utilizându-se

modelul “huge”.
Fişiere pentru gestiunea şi intercomunicarea cu DSP-urile. [5].
Exe2idma.c – conţine funcţia de încărcare a programului în DSP prin portul de
IDMA.
Interrs.c – instalează noi rutine de întrerupere folosite în aplicaţie, dupe ce în prealabil
au fost salvate cele iniţiale, pentru a putea fi restabilite la ieşirea din aplicaţie.
2181.c – funcţii de interfaţă cu DSP-ul: instalare, scriere prin IDMA, citire prin
IDMA, resetare, rutină de întrerupere.
Mat.c – funcţii de interfaţă cu matricea de comutaţie
DSP.c – conţine funcţii pentru controlul şi transferul prin portul IDMA.
Fişiere pentru dezvoltarea task-urilor de lucru. [3], [4], [22].
Tks_com.c – funcţii de creare a task-urilor, control transmisiei şi recepţiei şi
transmisiei de pachete RTP, etc.
Rtp_ucos.c – are rolul de a integra şi lansa în execuţie toate funcţionalităţile aplicaţiei,
mai sus amintite.
În afară de fişierele mai sus enumerate, în directorul de lucru mai sunt fişiere de tip
header (“*.h”) care conţin declaraţii de funcţii şi variabile, incluse în fişierele cu extensia
“*.C”. Nu trebuie uitate fişierele “wattcp.cfg”, ce conţine informaţiile de configurare pentru
comunicarea în reţeaua IP (adresa IP, DNS server, gateway, etc.) şi fişierul “ts2181.dat” care
conţine programul compilat care va fi încărcat în DSP.
Fişierul Rtp_ucos.c este cel care conţine funcţia “main( )” şi el este cel care apelează
celelalte funcţii şi macrouri pentru dezvoltarea aplicaţiei. El include toate fişierele de tip
header din directorul curent.
Prima lui sarcină este să efectueze etapa de iniţializare, iar pentru aceasta apelează
funcţia “sock_init( )” care are rolul de a iniţializa modulul şi stiva TCP/IP de comunicare,
după care se iniţializează cele 4 DSP-uri, prin intermediul procedurii “init_dsps ( )”. Aceasta
resetează DSP-urile, dezactivează întreruperile şi citeşte 2 din cele 3 flaguri ale fiecăruia.
Ultima iniţializare are în vedere matricea de comutaţie.
A 2-a etapă o constituie încărcarea programelor în DSP-uri. Boot-area DSP-urilor

poate fi făcută în 2 moduri, iar pentru selecţia unuia dintre ele se folosesc 2 pini: BMODE şi
MMAP. Cele 2 moduri de încărcare a programelor sunt: prin portul BDMA, sau prin portul
Pagina 63 din 133

IDMA. Toate cele 4 DSP-uri de pe placă sunt configurate pentru boot-area prin IDMA. În
secvenţa de boot-are, DSP-ul opreşte execuţia până când procesorul gazdă încarcă Program
Memory folosind portul IDMA. Execuţia programului începe în momentul în care, la sfârşitul
încărcării, este scrisă şi locaţia PM 0x0000.
Portul de IDMA (Internal DMA) ( [5] ) este un port paralel de intrare/ieşire, care
permite citirea/scrierea memoriei interne, mai puţin direct regiştrii interni, de către un
procesor gazdă. DSP-ul asigură 5 pini pentru controlul transferului prin IDMA.
Citirea/scrierea din/în memoria internă se face în 2 paşi: întâi se face înscrierea în
IDMA Control Register a adresei din memoria de date/program la/de la care se va realiza
transferul, iar apoi, prin folosirea pinilor de control se comandă scrierea sau citirea la/de la
adresa mai inainte încărcată.
Încărcarea programelor în DSP-uri se face apelând funcţia “dsp_install( )”, definită în
fişierul “2181.c”. Ea efectuează următoarele operaţii: resetează chipul şi dezactivează
întreruperile pentru a salva pointerul către funcţia dată ca argument la apelare. După
eliberarea semnalului reset şi activarea întreruperilor se apelează funcţia “load_prg( )” care
este descrisă în fişierul “exe2idma.c” şi care are ca argumente adresa unui port de ieşire
corespunzator DSP-ului în care se face încărcarea şi numele fişierului ce conţine programul
compilat, cu extensia “.dat”. După înscrierea prin portul de IDMA a anumitor linii din fişierul
respectiv în zona de memorie de program PM a DSP-ului (Program memory), nu toate având
semnificaţie utilă, este înscrisă apoi la adresa PM 0x0000 adresa de la care DSP-ul să înceapă
rularea programului.
Urmează operaţia de instalare a noilor întreruperi, efectuată de
“instalare_intreruperi( )”, care este descrisă în “Interrs.c”. Această funcţie, după ce apelează
alte 3 funcţii ce descriu în limbaj de asamblare rutina de execuţie a noilor întreruperi dorite
(întreruperea de DSP, de 2 ms şi int_arb), salvează vechii vectorii de întrerupere pentru a
putea fi restabiliţi la ieşirea din program şi instalează noile întreruperi pe IRQ 7, IRQ 5 şi
IRQ 15.
Dacă până acum s-au efectuat etapele de iniţializare, încărcare a programelor în DSP-
uri şi instalare a noilor întreruperi, generic spus punerea în funcţiune a cartelei, în cele ce
urmează are loc iniţializarea µ C/OS –ului.
Pagina 64 din 133

µ C/OS II-ul este un kernel de timp-real care, deşi lucrează în MS-DOS, pe durata
funcţionării aplicaţiilor sale, salvează contextul acestuia, urmând ca la revenirea din aplicaţie
să fie restabilit.
El se constituie dintr-un programator de procese (task-uri), conform anumitor
priorităţi. Datorită scalabilităţii sale, permite includerea la compilare doar a anumitor servicii,
în funcţie de dorinţă utilizatorului. Aceasta se realizează prin setarea anumitor variabile în
fişierul de configurare “Ucos_cfg.h” [3] (numărul de task-uri dorite, prioritatea minimă,
includerea serviciilor de semafor, mailbox, facilitatea de creare de task-uri, de distrugere sau
suspendare a lor, de schimbare a priorităţilor, etc.).
Ca orice programator de procese, µ C/OS-ul la rândul lui are un IdleTask, un task pus
în execuţie atunci când nici un altul nu este în starea “ready to run” (“gata de execuţie”). În
cazul faţă, el se numeşte “OSTaskIdle( )” ( [3] ), este setat pe prioritatea minimă
(OS_LOWEST_PRIO) şi nu face altceva decât să incrementeze un contor de 32 de biţi,
OSIdleCtr, care este folosit de un alt task,OSTaskStat( ), la determinarea încărcării
procesorului. OSIdleTask nu poate fi niciodată şters de către o aplicaţie sotfware.
(C/OS II-ul conţine un task ce asigură statistici de-a lungul funcţionării. Numit
“OSTaskStat( )” ( [3] ), el este folosit dacă variabila OS_TASK_STAT_EN este setată pe
valoarea 1, în fişierul OS_Cfg.h. Acest task se execută la fiecare secundă şi determină
încărcarea procesorului, iar prioritatea sa este OS_LOWEST_PRIO-1.
Revenind la aplicaţia noastră, după etapa de iniţializare este apelată funcţia
“OSInit( )”, care are pe lângă rolul de a iniţializa funcţionarea µ C/OS II-ului, rolul de a crea
cele 2 task-uri mai sus descrise: OSTaskStat( ) şi OSTaskIdle( ).
Următorul pas este acela de salvare a contextului de lucru al sistemului de operare,
MS-DOS, prin apelarea “PC_DOSSaveReturn( )”, pentru a putea fi reinstalat la ieşirea din
aplicaţie, urmat de instalarea unui vector în tabela de întreruperi
a rutinei de tratare a “OSCtxSw” ( contorizează numărul de schimbări de context

petrecute într-o secundă în funcţionarea (C/OS II-ului ).
În acest moment, (C/OS-ul este initializat, cele 2 task-uri create şi contextul DOS
salvat. Pentru punerea lui în funcţiune trebuie creat “TaskStart( )”, un task care va fi primul
rulat de (C/OS, avea prioritatea maximă pe toată perioada de funcţionare a aplicaţiei şi care
va crea celelalte task-uri dorite. Odată cu apelarea funcţiei “OSStart( )”, funcţia “main( )” se
Pagina 65 din 133

încheie, punând în funcţiune kernelul (C/OS-ului, întreaga gestiune a proceselor fiind lăsată
în seama lui.
“TaskStart( )”-ul are ca primă sarcină dezactivarea întreruperilor pentru a instala
rutina de întrerupere pentru “clock tick” şi de a seta valoarea frecvenţei sale de apariţie la
OS_TICK_PER_SEC, valoare modificabilă în fişierul de configurare “Os_cfg.h”. Sunt
activate apoi întreruperile şi apelată OSStatInit( ), funcţia de punere în funcţiune a
TaskStat( ).
Din punctul de vedere al programatorului, un task este o buclă infinită care este pusă
în execuţie în funcţie de politica trasată ( prioritate, perioadă de suspendare, autosuspendare,
etc. ). El poate fi suspendat, se poate autosuspenda, i se poate schimba prioritatea, poate fi
şters, etc. În aplicaţia de faţă, TaskStart( ) are rolul de a crea task-urile de comunicare
(trimitere, recepţie de pachete, etc.), după care, partea sa repetitivă este constituită din
afişarea pe ecran a numărului de task-uri funcţionale, a numărului de schimbări de context ce
au loc în fiecare secundă, a procentului de încărcare a procesorului şi a verificării dacă nu s-a
manifestat dorinţa de oprire a aplicaţiei, ce se poate realiza prin apăsarea tastei “Esc”. După
îndeplinirea acestor sarcini, “TaskStart( )”-ul este suspendat o secundă, de către programator
datorită apelului “OSTimeDlyHMSH(0,0,1,0)”.
În situaţia opririi aplicaţiei, sunt efectuate toate operaţiile de revenire în starea iniţială
a sistemului. Acestea sunt închiderea tuturor socket-ilor deschişi de procesele de trimitere şi
recepţie de pachete IP( “RTPclose( )” ), restabilirea vechilor vectori de întrerupere
( “revenire_intreruperi_initiale( )” ), “dezinstalarea” celor 2 DSP-uri folosite
( “dsp_unistall( )” ) şi restabilirea contextului de lucru al MS-DOS, salvat la începutul
funcţionării µ C/OS-ului (“PC_DOSReturn( )”).
Înainte de a intra în secţiunea repetitivă, sunt create celelalte task-uri, prin apelul
funcţiei “initiere_comunicare( )”.
Task-urile vor fi create în funcţie de anumite variabile de configurare ce se găsesc în
fişierul “Ts_cfg.h”. De-a lungul dezvoltării aplicaţiei până în stadiul actual, s-au realizat teste
de transmisie şi recepţie de pachete de tip RTP cu 3 maşini pereche: o maşină aflată în
reţeaua IP locală, o alta în reţeaua ISP-ului (RDSnet) (IP: 193.231.233.156), iar cea de-a 3-a
din Internet (IP: 193.41.127.218), toate rulând un sistem de operare Linux. Din această cauză,
în fişierul mai sus amintit sunt definite 3 variabile, pentru fiecare adresă IP cu care se doreşte
comunicare. În funcţie de valorile lor ( 0/1 ), se crează sau nu câte o pereche de task-uri, de
Pagina 66 din 133

recepţie şi trimitere de pachete RTP. Tot pentru configurarea task-urilor pe care le va

gestiona (C/OS-ul, în acelaşi fişier mai poate fi modificată încă o variabilă
(TCP_TICK_ON_OFF), de care va depinde crearea sau nu a task-ului ”Task_tcpTick( )”.
Fişierul de configurare, “Ts_cfg.h”, mai cuprinde prioritatea fiecărui task ce urmează
a fi creat, porturile locale şi ale maşinilor distante. Întrucăt standardul H.323, indiferent ce
versiune ar fi el, nu specifică porturi dedicate transferului RTP/RTCP, de aceea au fost alese
numere de porturi care să nu fie specifice altor tipuri de comunicaţii (“well-known ports”).
Presupunând că în momentul compilării proiectului, cel puţin una din variabilele de
configurare a comunicaţiei au valoarea “1”, iar TCP_TICK_ON_OFF este “1”, funcţia
“initiere_comunicare( )” are următoarele funcţiuni: deschide câte un fişier pentru salvarea
tuturor evenimentelor (primire/recepţie de pachete, etc.) care au loc pe parcursul comunicării
cu fiecare maşină-pereche, după care se apelează funcţia “RTPInit( )” ce are rolul de a afla
adresa IP a maşinii distante folosind DNS-ul, în cazul în care aceasta nu este astfel
identificată de la început, deschiderea “socket”-ilor pe portul local folosit şi, în sfârşit,
salvarea în fişierul specificat ca parametru a rezultatului operaţiei. Este apelată apoi
“sock_recv_init( )”. Funcţie specifică stivei WATTCP, ea iniţiază procesul de recepţie de
pachete IP, pe un socket şi într-un buffer specificate ca parametrii la apelare. După realizarea
cu succes a etapelor anterioare, este în sfârşit creată perechea de task-uri de
transmitere/recepţie de pachete RTP, prin apelul “OSTaskCreate( )”, ce are ca parametrii
numele task-ului creat, stiva proprie fiecăruia şi prioritatea iniţială.
4.2.2.1 Task-ul de transmitere de pachete RTP
Task-ul cu numele generic “Task_send_XXX” realizează complet operaţia de

trimitere de pachete RTP, către maşina pereche (protocol de preluare în buffer-ul de trasmisie
a eşantioanelor de voce din memoria de date a DSP-ului, “împachetarea” loc în structuri de
tip RTP, transmiterea în reţeaua IP).
Pachetele RTP sunt definite în fişierul “Tks_com.h” prin intermediul structurii de mai
jos:
typedef struct {
unsigned char cc:4;
unsigned char extension:1;
unsigned char padding:1;
Pagina 67 din 133

unsigned char version:2;

unsigned char payloadtype:7;
unsigned char marker:1;
unsigned short seqnum;
unsigned long timestamp;
unsigned long ssrc;
unsigned char data[RTP_MAXPACKETSIZE];
} RTPpacket;
Câmpurile structurii sunt identice cu ale pachetelor RTP, conform RFC 1889 [22].
Întrucât fiecărei maşini pereche îi corespunde un task de transmitere de pachete RTP,
înainte de a intra în partea sa repetitivă, sunt iniţializate cu valori aleatoare pe 16, respectiv 32
de biţi 2 variabile locale, folositoare apoi la completarea câmpurilor structurii RTP.
După intrarea în ciclul funcţional, pentru umplerea zonei de date utile a pachetelor
RTP se foloseşte transferul eşantioanlelor de voce prin portul de IDMA din memoria de date
internă a DSP-ului.
Datorită staţionarităţii semnalului vocal, se vor împacheta în structuri RTP secvenţe
de voce de 20 ms. Întrucât sunt preluate de pe flux PCM canale de voce eşantionată cu
frecvenţa de 8 KHz (perioada de eşantionare de 125 µ s), cele 20 ms dorite sunt reprezentate
160 eşantioane de 8 biţi.
La fiecare început de ciclu al task-ului de transmitere de pachete, prima sarcină este
de a verifica completitudinea transferului anterior prin portul de IDMA. Aceasta se realizează
prin apelul funcţiei “poll(dsp_no)”, descrisă în fişierul “dsp.c”. Ea testează
pentru DSP-ul cu numărul dsp_no de pe placă pinul IACK\, ce indică transfer IDMA
complet. În cazul în care funcţia întoarce valoarea “0”, task-ul apelează
“OSTimeDlyHMSM(0,0,0,5)”, iar programatorul suspendă execuţia sa pentru 5 milisecunde.
La reprogramarea task-ului, acesta revine în starea de test şi, presupunând că procesorul
gazdă poate de această dată avea acces la memoria internă a DSP-ului prin portul de IDMA,
începe etapa de preluare de eşantioane. Prima măsură este aceea de a opri funcţionarea
programatorului de timp-real al task-urilor, pentru a evita o posibilă situaţie în care, în timpul
preluării eşantioanelor din memoria DSP-ului, task-ul de preluare să fie suspendat şi pus în
funcţiune altul mai prioritar, care să intervină în zona de interes şi căreia să-i schimbe
Pagina 68 din 133

conţinutul. Suspendarea programatorului se realizează prin apelul funcţiei

“OSSchedLock( )”.
Mecanismul de preluare a eşantioanelor presupune existenţa a 2 buffere în DM
(memoria internă de date a DSP-ului). Amândouă au câte 160 de locaţii de 16 biţi, nefiind
permise accesele pe 8 biţi în DM. La o locaţie de memorie, tot din DM, pe care procesorul
gazdă o verifică în momentul începerii operaţiei de preluare de eşantioane, DSP-ul
semnalizează buffer-ul în care momentan scrie. Astfel, dacă de la anterioara citire nu s-a
modificat conţinutul locaţiei de semnalizare, nici o operaţie nu este efectuată de către
procesorul gazdă, în caz contrar preluându-se în buffer-ul de recepţie din host cele 160 de
locaţii de 16 biţi din DM. Toate transferurile de date din memoria internă a DSP-ului sunt
realizate folosind portul de IDMA.
Întrucât fiecare din cele 2 DSP-uri instalate în aplicaţia de faţă realizează preluarea a
câte 4 canale temporale de pe flux PCM, adresele din memoria internă ale celor 2 buffer-e şi
a locaţiei din DM folosită pentru semnalizarea unuia dintre ele, folosite la preluarea de către
host a eşantioanelor de voce, sunt indicate în tabelul 4.2.3.1.
Astfel funcţionând protocolul pentru preluarea eşantioanelor, execuţia task-ului de
trimitere de pachete RTP implementează printre altele acest mecanism.
După ce funcţionarea programatorului a fost oprită, este verificată locaţia de memorie
folosită pentru indicarea buffer-ului de preluare, operaţie realizată de “dsp_rdbloc( )”, căreia i
se indică ca argumente “dsp_no” şi adresa locaţiei de semnalizare aferentă canalului dorit.
Dacă de la anterioara ei sondare nu s-au înregistrat
modificări, programatorul este repus în funcţiune, iar task-ul suspendat pentru 5ms,
după care este reluată partea sa repetitivă. În cazul în care între locaţia citită acum şi cea
anterior citită sunt modificări, înseamnă că DSP-ul a completat cele 160 de locaţii ale unui
buffer, iar ele pot fi preluate prin portul de IDMA în buffer-ul de recepţie a lor din “host”,
folosind funcţia “dsp_rdbloc( )”, căreia i se dau ca argumente de acestă dată adresa de început
a buffer-ului din DM ce se doreşte transferat corespunzător canalului de voce transmis,
numărul de citiri prin IDMA (160) şi “dsp_no”.
La sfârşitul transferului prin IDMA al eşantioanlelor de voce din DM, programatorul
µ C/OS-ului este deblocat şi repus în funcţiune de funcţia “OSSchedUnlock( )”. Pentru
transmiterea lor în reţeaua IP se apelează mai întâi funcţiile “initializare_packet_rtp( )” şi
Pagina 69 din 133

“RTPpacket_data( )”. Prima dintre ele completează câmpurile headerului pachetului RTP
care va fi transmis, iar cea de-a doua completează câmpul de date al pachetului, după ce
înainte va fi păstrată doar partea mai puţin semnificativă a conţinutului locaţiilor de 16 biţi
transferate din memoria DM. Odată completate câmpurile structurii, pentru transmiterea
pachetului se apelează “sock_fastwrite( )”, funcţie specifică stivei WATTCP.
Înainte de a termina partea repetitivă a task-ului, este incrementat modulo 216 un
contor care va completa numărul de secvenţă al pachetului RTP următor ce va fi transmis,
după care task-ul este suspendat pentru 14 ms.
4.2.2.2. Task-ul de recepţie a pachetelor RTP
Pentru fiecare maşină pereche de comunicare se crează în urma apelului funcţiei

“initiere_comunicare( )” câte un task cu numele generic “Task_recv_XXX( )”de recepţie a
pachetelor RTP. El este responsabil cu recepţia pachetelor de tip RTP sosite pe socket-ul
corespunzător, gestionarea lor şi transmiterea blocurilor de câte 160 eşantioane către DSP-ul
corespunzător. În general, recepţia şi redarea blocurilor de eşantioane primite de la maşina
pereche, reprezentând semnalele de voce ale celuilalt interlocutor, sunt mai delicate. Cauza o
constituie reţeaua IP, cu problemele sale de transport prezentate mai pe larg în anterioarele
capitole, reţea care poate întârzia sosirea pachetelor RTP, poate schimba secvenţialitatea
datelor datorită protocolului de transport folosit. De aceea, în maşina de recepţie trebuie luate
măsuri de buffer-are şi reordonare a pachetelor recepţionate.
Fiecare task de recepţie are rolul de a primi din reţea şi de a transmite către DSP
eşantioanele de voce. Apelul se identifică prin zona de memorie din DSP-ul cu care se
lucrează şi numărul portului pe care se va face recepţia.
Recepţia pachetelor se face prin apelul funcţiei specifice stivei WATTCP “sock_recv(
)” , căreia i se dau ca parametrii socket-ul deschis pe portul corespunzător şi buffer-ul de
recepţie. Pentru buna funcţionare a recepţiei de pachete IP pe socket-ul respectiv, înainte de
crearea task-urilor, în corpul funcţiei “initiere_comunicare( )”, a fost apelată, pentru fiecare
maşină pereche de comunicaţie, “sock_recv_init( )”, funcţie ce are rolul de a prelua într-un
buffer de dimensiune 64 KB pachetele recepţionate pe socket-ul deschis pe portul local
dedicat primirii pachetelor, dat ca parametru, până în momentul citirii lor cu ”sock_recv( )”.
Pagina 70 din 133

Odată funcţia “Task_recv_XXX( )” intrată în ciclul ei repetitiv, la fiecare programare

a task-ului, acesta citeşte într-un ciclu “while” prin intermediul “sock_recv( )”, funcţie care
întoarce numărul de pachete citite din buffer-ul de recepţie, toate pachetele primite de la
anterioara apelare. Ele sunt preluate într-un tablou de structuri de tip “RTPpacket”.
Pachetelor RTP, datorită problemelor de transport ale reţelei IP, descrise în capitolul I
al lucrării, pot sosi în altă ordine decât la emiterea lor. De aceea, după ieşirea
din ciclu “while”, odată cu terminarea preluării, acestea sunt transferate într-un buffer
cu 64 locaţii, reprezentate de structuri de genul:
typedef struct{
unsigned short indicator_locatie;
unsigned short seq_num;
char es_voce[160];
} LocatieBuffer;
Acest buffer “LocatieBuffer buffer[64];“ este folosit ca un buffer circular, în fiecare
locaţie memorându-se un indicator de ocupare, numărul de secvenţă al pachetului RTP în
care a fost primit blocul de eşantioane şi datele propriu-zise. El are un “pointer” de citire
(următoarea locaţie de unde va fi trimis la DSP-ul corespunzător un bloc de 160 de
eşantioane ) şi unul de scriere care reprezintă următoarea locaţie liberă în care se poate pune
un bloc, în funcţie şi de numărul de secvenţă al pachetului RTP din care provine, dar mai ales
de ordinea pachetelor primite.
Primul ciclu efectuat de tesk-ul “Task_recv_XXX( )” preia din buffer-ul de recepţie al
“sock_recv( )” pachetele primite, iniţializează buffer-ul circular, completează un număr de
locaţii egal cu numărul de pachete primite şi se autosuspendă pentru 80 ms.
Următoarele 3 parcurgeri ale ciclului au rolul de a prelua la rândul lor din acelaşi
buffer de recepţie pachetele primite şi completate noi locaţii din tabloul de structuri de tip
“LocatieBuffer”, după care task-ul se autosuspendă tot câte 80ms.
Mecanismul de completare a locaţiilor are, pe lângă rolul de a reface secvenţialitatea
pachetelor RTP primite, şi rolul de a permite reintegrarea în fluxul de date a pachetelor
întârziate. Buffer-ul va conţine blocurile de eşantioane, într-o strânsă legătură cu numărul de
secvenţă al pachetelor RTP în care au fost transportate. Astfel pachetele care au sosit înaintea
celor aşteptate, dar nu mai mult decăt o limită stabilită, sunt introduse în buffer. La fel se
Pagina 71 din 133

întâmplă cu cele întârziate în cazul în care poziţia în care ar trebui introduse în bufferul
circular ar fi ulterioară pointerului de citire.
După cele 4 parcurgeri ale ciclului de lucru, parcurgeri în care nu s-a realizat altceva
decât completarea unor locaţii din buffer-ul circular, are loc procesul de iniţializare. El
urmăreşte să detecteze locaţia corespunzătoare numărului minim de secvenţă al unui pachet
RTP primit, care reprezintă începutul unei secvenţe de
“MIN_SEQ” pachete. Se iniţializează pointerul de citire din buffer cu indicele locaţiei

mai sus amintite, se transmite DSP-ului corespunzător blocul de 160 eşantioane, după ce în
prealabil ele au fost incluse ca partea mai putin semnificativă a unor cuvinte de 16 biţi pentru
transferul în DSP’s DM şi task-ul se autosuspendă pentru 18 ms datorită apelului
“OSTimeDlyHMSH(0, 0, 0, 18)”.
La fiecare parcurgere ulterioară a ciclului funcţiei, după ce sunt completate locaţii din
memoria buffer-ului cu pachetele recepţionate, conform mecanismului mai sus prezentat, este
transferat în memoria DM a DSP-ului prin portul de IDMA un bloc de 160 de eşantioane,
folosind apelul funcţiei “dsp_wrbloc( )”, având ca parametrii indicatorul DSP-ului, numărul
de scrieri, 160, adresa din memoria DM.Odată transferul încheiat, este incrementat pointerul
de citire şi task-ul se sutosuspendă 18 ms.
În situaţia în care pointerul de citire “ajunge“ din urmă pointerul de scriere în buffer,
s-a detectat lipsa unui bloc de eşantioane, lipsă datorată pierderii pachetului RTP aferent. Se
trimite în această situaţie DSP-ului informaţia de lipsă eşantioane, urmănd a se reda “linişte”.
Zonele din memoria internă DM a DSPK-ului, atât cele folosite la transferul către
DSP al blocurilor de eşantioane, cât şi indicatorul buffer-ului utilizat, corespunzătoare celor 4
canale de voce procesate de fiecare, sunt prezentate în tabelul 4.2.3.1. În cele mai sus descrise
este folosit un singur buffer dinDM, însă dezvoltarea ulterioară a aplicaţiei va necesita 4, cu
indicator de buffer pentru scriere.
4.2.3 Zone de memorie folosite pentru preluarea pachetelor de eşantioane
Referinţe bibliografice: [5]
Pagina 72 din 133

Am prezentat în subcapitolul precedent mecanismele funcţionale atât pentru preluarea

de către PC/104 a eşantioanelor de voce din memoria DM internă a DSP-ului, cât şi pentru
“livrarea” celor primite prin intermediul pachetelor de tip RTP din reţeaua IP. Pentru buna
manevrare a lor şi succesul transferului sunt folosite anumite zone din DM, memoria internă
a DSP-ului.
Modelul AD2181 dispune de o memorie internă de date de 16Kx16 biţi, folosibili
exclusiv zona superioară de date rezervată regiştrilor de control mapp-aţi în memorie, aflaţi
între 0x3FDF – 0x3FFF. Nu sunt permise însă accesele pe 8 biţi la locaţiile din memoria DM.
Fiecare DSP este folosit în aplicaţia de faţă pentru preluarea şi transmiterea către host
a 4 canale temporale, preluate de pe fluxul PCM de comunicare cu PG-ul, corespunzătoare a
4 apeluri solicitate, fie de intrare, venite via gateway, fie de ieşire, caz în care un abonat şi-a
manifestat opţiunea de transport a vocii folosind reţeaua H.323.
Pentru transmiterea eşantioanlor de la DSP la host se folosesc 2 buffer-e de memorie
de 160 locaţii şi încă o locaţie verificată în permanenţă pentru indicarea celui din care se
poate citi.
Pentru transmiterea către DSP a eşantioanelor despachetate din structurile de date de
tip RTP venite din reţeaua IP, sunt folosite un număr de 4 buffer-e de 160 locaţii în memoria
internă a DSP-ului şi o alta pentru semnalizarea buffer-ului din care se pot citi datele.
Pentru sintetizarea şi detalierea locaţiilor din memoria DSP-ului, s-a întocmit tabelul
4.2.3.1:
Pagina 73 din 133

DSPk Transmiterea eşantioanelor de la Transmiterea eşantioanelor de la

DSPk →host host → DSPk
Buferr Indicator Buferr Indicator
buffer buffer
canal 0 0. 0x1000 – 0x109F 0x3FCF 0x1400 – 0x149F 0x3FCE
1. 0x10A0 – 0x113F 0x14A0 – 0x153F
0x1540 – 0x15DF
0x15E0 – 0x167F
canal 1 0. 0x1800 – 0x189F 0x3FCD 0x1C00 – 0x1C9F 0x3FCC
1. 0x18A0 – 0x193F 0x1CA0 – 0x1D3F
0x1D40 – 0x1DDF
0x1DE0 – 0x1E7F
canal 2 0. 0x2000 – 0x209F 0x3FCB 0x 2400 – 0x249F 0x3FCA
1. 0x20A0 – 0x213F 0x24A0 – 0x253F
0x2540 – 0x25DF
0x25E0 – 0x267F
canal 3 0. 0x2800 – 0x289FF 0x3FC9 0x2C00 – 0x2C9F 0x3FC8
1. 0x28A0 – 0x293F 0x2CA0 – 0x2D3F
0x2D40 – 0x2DDF
0x2DE0 – 0x2E7F
Tabelul 4.2.3.1 Zonele de memorie din DM DSP pentru transferul eşantioanelor DSP
↔ host.
Concluzii
La momentul apariţiei sale, VoIP a fost o tehnologie care pe toată lumea a încântat, a
atras atenţia tuturor proiectanţilor şi marilor producători de echipamente de telecom, dar mai
ales furnizorilor de servicii de telecomunicaţii, în general, şi telefonie în special. În condiţiile
în care Internet-ul şi era “e-commerce” sunt într-o nebănuit de vertiginoasă ascensiune, iar
reţelele de pachete de tip IP par că vor reprezenta suportul telecomunicaţiilor de “mâine”,
ideea de a transporta una din cele mai vechi şi încetăţenite modalităţi de comunicare între
Pagina 74 din 133

oameni oferite de operatorii telecom folosind suportul reprezentat de reţelele de pachete a dat
mari speranţe tuturor celor interesaţi.
Tehnologia s-a lovit încă de la început de o ostilitate destul de mare din partea unora,
iar acest lucru s-a datorat în cea mai mare măsură nivelului uriaş de investiţii care au fost
realizate în reţeaua pentru telefonia clasică, bazată pe comutaţia de circuite. Un al doilea
motiv ar fi acela de “refuz” venit din partea utilizatorului obişnuit de telefon clasic, care era
destul de reticent în a se familiariza cu noua tehnologie.
Marii proiectanţi şi producători de echipamente au investit sume considerabile în
dezvoltarea de produse care să aibă la bază noua tehnologie. Ei au demarat proiecte ample,
folosind soluţii proprietare care să ajute la evoluţia rapidă a produselor. În tot acest cadru,
organismele internaţionale pentru standardizare au intervenit pentru aducerea la un numitor
comun a caracteristilor funcţionale.
Însă, odată început lucrul, s-a ajuns la concluzia că problemele de transport prezentate
în capitolul I, datorate suportului de comunicaţie, am numit aici reţeaua de pachete IP
(Intranet, MAN, WAN, Internet), sunt destul de serioase şi împiedică dezvolarea rapidă care
era anunţată.
Au apărut o mulţime de protocoale mulate pe cererile venite din partea transportului
de date de timp real, în general, şi de voce în particular, şi care au rezolvat într-o măsură mai
mare sau mai mică problemele. În ciuda lor, deşi la început se anunţa o mare revoluţie în
transportul serviciilor, s-a ajuns la concluzia că mai este destul de mult de lucru până la
obţinerea unor produse performante.
Una din cele mai mari probleme a fost realizarea intercomunicaţiei cu reţeaua PSTN
deja existentă, pe care, în nici un caz nu o poate înlocui. Pentru asta au fost create porţi de
transfer de la reţeaua H.323 la PSTN sau orice alt tip de reţea transportoare de voce.
“VoIPcard” face parte din entuziastmul reprezentat de VoIP. Ca şi în cazul altor
producători şi s-a confruntat cu rezolvarea problemelor specifice de care am tot vorbit pe
larg. “VoIP card” este un gateway şi reprezintă poarta de ieşire a vocii pentru transportul
peste o reţea de pachete IP. Dezvoltarea unui gateway de voce trebuie să aibă în vedere atât o
mulţime de probleme specifice celor 2 reţele între care realizează comunicaţia, cât şi să
respecte standardele de translaţie a formatelor diferite de date.
Procesul de dezvoltare a unui astfel de echipament este destul de îndelungat şi
necesită un anumit grad de experienţă.
Pagina 75 din 133

Dezvoltarea unui gateway implică implementarea celor 4 module, care rulează atât în
procesorul gazdă, cât şi în DSP-uri. Aplicaţia prezentată în capitolul 4 a fost dezvoltată pe
parcursul unui semestru, iar pentru realizarea unei etape de test este necesară şi dezvoltarea
software-ului pentru rularea în DSP-uri. Timpul necesar s-a dovedit a fi insuficient şi
experienţa avută în proiectare destul de mică. Am încercat să-mi focalizez atenţia spre o
anumită porţiune, care să poată fi continuată ulterior, chiar şi de către altcineva care n-a
participat la proiectarea iniţială.
Rezultatul de până acum a fost prezentat pe larg în capitolele 3 şi 4, însă această a fost
doar temelia pentru dezvoltarea ulterioară. Aplicaţia a fost dezvoltată în urma unei munci de
documentare asupra componentelor folosite şi a tehnologiei VoIP. Materialele folosite pentru
aceasta sunt prezentate în bibliografie.
Cu speranţa aprecierii muncii depuse şi a prezentării generale efectuate, vom prezenta
în cele ce urmează o parte din codul sursă al aplicaţiei descrise în capitolul 4.
Pagina 76 din 133

ANEXE
A
N
E
X
A
A
.
D
i
c
ţ
i
o
n
a
r
d
e
a
c
r
o
n
i
m
e
A
AAA Authentication Authorization and Accounting
AAL2 ATM Adaptation Layer type 2
Pagina 77 din 133

ADPCM Adaptive PCM

ADSL Asymmetric Digital Subscriber Line
AI Artificial Intelligence
ANSI American National Standards Institution
API Application Programming Interface
ARP Address Resolution Protocol
ARQ Automatic Request for retransmission
AS Application Server
ATM Asynchronous Transfer Mode
AUI Attachment Unit Interface
B
BER Bit Error Rate
B-ISDN Broadband ISDN
BNC British Naval Connector
BRI Basic Rate Interface (2B+D)
BSC Base Station Controller
BSS Base Station Subsistem
BTS Base Transceiver Subsystem
C
CBR Constant Bit Rate
CEPT Conference Europeene des Administrations des Postes et des
Telecomunications
CERT Computer Emergency Response Team
CES Circuit Emulation Services
CHAP Challenge Handshake Authentication Protocol
CLI Command Line Interface
CLP Connectionless Protocol
CODEC Coder & Decoder
COP Connection-oriented Protocol
CPU Central Processing Unit
CRC Cyclic Redundancy Code
CSPDN Circuit Switched Public Data Network
CSU Channel Service Unit
Pagina 78 din 133

CTI Computer Telephony Intergation
D
DCE Data Communications Equipment
DES Digital Encryption Standard
DiffServ Differrentiated Services
DLC Data Layer Control
DNS Domain Name Server
DSU Data Service Unit
DTE Data Terminal Equipment
DTMF Dual Tone Multifrequency
DVB-T Digital Video Broadcasting
E
EN Enterprise Network
ETSI European Telecommunications Standards Institute
F
FAXoIP Fax over IP
FCS Frame Check Sequence
FDDI Fiber Distributed Data Interface
FDT Formal Description Technique
FIFO First In First Out
G
GSM Global System for Mobile
GSTN General Switched Telephone Network
GUI Graphical User Interface
H
HDLC High-level Data Link Control
HDSL High bit-rate Digital Subscriber Line
HTTP Hypertext Transfer Protocol (RFC2068)
Pagina 79 din 133

IANA Internet Assigned Numbers Authority

ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineering
IETF Internet Engineering Task Force
IGMP Internet Group Message Protocol
IN Intelligent Network
IOS Internetwork Operating System
IP Internet Protocol
IPX Internetwork Packet Exchange
ISDN Integrated Services Digital Network
ISO International Standard Organization
ISP Internet Service Provider
ITU International Telecommunication Union
IWF InterWorking Function
K
KBPS KiloBytes Per Second
L
LAN Local Area Network
LANE LAN Emulation
LCP Link Control Protocol (a component from PPP)
LIFO Last In-First Out
LLC Logical Link Connection
LMI Local Management Interface
LSB Less Significant Bit
M
MAC 1. Medium Access Control 2. Message Authentication Code
MAN Metropolitan Area Network
MCU Multipoint Control Unit
MGCP Media Gateway Control Protocol
MHz MegaHertzs
MIB Management Information Base
Pagina 80 din 133

MPLS Multi-Protocol Label Switching

MS Mobile Station
MSB Most Significant Bit
MSC 1. Message Sequence Chart; 2. Mobil Switching Center;
MTU Maximum Transmission Unit
N
NEBS Network Equipment Building Standards
NIST National Institute of Standards and Technology
O
OAM Operations, Administration and Maintenance
OMS Operation and Maintenance Subsystem
OSI Open Systems Interconnection
OUI Organizationally Unique Identifier
O&M Operations And Maintenance
P
PABX Private Automatic Branch eXchange
PC Personal Computer
PCM Pulse Code Modulation
PCTA Procesor Central de Tratare Apeluri
PDC Personal Digital Communication
PDCP Packet Data Convergence Protocol
PDH Plesiochronous Digital Hierarchy
PDN Packet Data Network
PDU Protocol Data Unit
PG Procesor de Grup
PID Process IDentifier
PLMN Public Land Mobile Network
POTS Plain Old Telephone Service
PRI Primary Rate Interface
PSPDN Packet Switched Public Data Network
PSTN Public Switched Telephone Network
PVC Permanent Virtual Circuit
Pagina 81 din 133

Q
QoS Quality of Service
R
RAND RANDom number
RAS 1. Registration, Admisions, and Status; 2. Remote Access Server;
RSVP Resource Reservation Protocol
RTCP Real Time Control Protocol
RTP Real Time Protocol
RTSP Real Time Stream Protocol
RTT Round Trip Time
S
SAP 1. Session Announciament Protocol; 2. Services Access Point
SAR Segmentation & Reassembling
SCCP Signaling Connection Control Part (ITU-T Q.711-714)
SCN Switched Circuit Network
SCTP Stream Control Transmission Protocol
SDH Synchronous Digital Hierarchy
SDLC Synchronous Data Link Control
SGMP Simple Gateway Control Protocol
SID Security ID
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SLIP Serial Line Internet Protocol
SMTP Simple Mail Transfer Protocol
SNA Serial Number Arithmetic (RFC 1982)
SNMP Simple Network Management Protocol
SOHO Small Office Home Office
SONET Synchronous Optical Network
SPID Service Profile IDentifier
SS7 Signaling System Number 7
SSH Secure SHell
SSL Secure Socket Layer
Pagina 82 din 133

SSP Service Switching Point

STP Signaling Transfer Point
SVC Switched Virtual Circuit
T
TCAP Transactional Capabilities Application Part
TCP Transmission Control Protocol
TDMA Time Division Multiple Access
TE Terminal Equipment
TMN Telecommunications Management Network
TOS Type Of Service
TTL Time To Live
TUP Telephone User Part
U
UA Unitate Abonaţi
UBR Unspecified Bit Rate
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunication System
UNI User-Network Interface
URL Universal Resource Locator
UTD Unitate de Trunchi Digital
V
VCC Virtual Channel Connection
VLAN Virtual LAN
VoD Video on Demand
VoFR Voice over Frame Relay
VoIP Voice over IP
VON Voice On the Network
VPC Virtual Path Connection
VPN Virtual Private Network
VToA Voice Telephony over ATM
Pagina 83 din 133

WAN Wide Area Network

WATM Wireless ATM
WLAN Wireless LAN
WLL Wireless Local Loop
ANEXA B. Software-ul aplicaţiei

ANEXA B1. Fişiere header (.h)
Includes.h
/************************** MASTER INCLUDE FILE
**************************/
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#include <stdlib.h>
#include <conio.h>
#include <dos.h>
#include <setjmp.h>
#include <tcp.h>
#include "Ts_Cfg.H"
#include "os_cpu.h"
#include "os_cfg.h"
#include "pc.h"
#include "ucos_ii.h"
OS_cfg.h
/****************************** uC/OS-II The Real-Time Kernel
***************
uC/OS-II CONFIGURATION
*********************************************************************
*******/
Pagina 84 din 133

#define OS_MAX_EVENTS 5 //Max. number of event control blocks in your

//application.MUST be >= 2
#define OS_MAX_MEM_PART 5 //Max. number of memory partitions. MUST be
>= 2
#define OS_MAX_QS 3 // Max. number of queue control blocks in your
//application.MUST be >= 2
#define OS_MAX_TASKS 15 // Max. number of tasks in your application ... //MUST
be >= 2
#define OS_LOWEST_PRIO 15 // Defines the lowest priority that can be

//assigned.MUST NEVER be higher than 63!
#define OS_TASK_IDLE_STK_SIZE 512 // Idle task stack size (# of 16-bit //wide

entries)
#define OS_TASK_STAT_EN 1 // Enable (1) or Disable(0) the //statistics task

#define OS_TASK_STAT_STK_SIZE 512 // Statistics task stack size (# of 16-//bit
wide entries)
#define OS_CPU_HOOKS_EN 1 // uC/OS-II hooks are found in the processor port

files
#define OS_MBOX_EN 0 // Include code for MAILBOXES
#define OS_MEM_EN 1 // Include code for MEMORY MANAGER (fixed //sized
memory blocks)
#define OS_Q_EN 0 // Include code for QUEUES
#define OS_SEM_EN 1 // Include code for SEMAPHORES
#define OS_TASK_CHANGE_PRIO_EN 0 // Include code for OSTaskChangePrio()
#define OS_TASK_CREATE_EN 1 // Include code for OSTaskCreate()
#define OS_TASK_CREATE_EXT_EN 0 // Include code for OSTaskCreateExt()
#define OS_TASK_DEL_EN 1 // Include code for OSTaskDel()
#define OS_TASK_SUSPEND_EN 1 // Include code for OSTaskSuspend() and
//OSTaskResume()
Pagina 85 din 133

#define OS_TICKS_PER_SEC 100 // Set the number of ticks in one second
RTP_Ucos.h
#include <stdio.h>
#include <tcp.h>
//Initiere conexiune RTP

int RTPinit( char *localip, char *remoteip, word RTP_PORT_DIST, word\
RTP_PORT_LOCAL, udp_Socket *socket, char buff_adresa[], FILE *fisier );
Stacks.h
#include "os_cpu.h"
extern OS_STK TaskStk_tcpTick[2048];

extern OS_STK TaskStk_send_FServ[TASK_STK_SIZE];
extern OS_STK TaskStk_recv_FServ[TASK_STK_SIZE];
extern OS_STK TaskStk_send_INC[TASK_STK_SIZE];
extern OS_STK TaskStk_recv_INC[TASK_STK_SIZE];
extern OS_STK TaskStk_send_ONIX[TASK_STK_SIZE];
extern OS_STK TaskStk_recv_ONIX[TASK_STK_SIZE];
extern OS_STK TaskStartStk[TASK_STK_SIZE]; // TaskStart stack
Targtype.h
#ifndef __TARGET_TYPES_H__
#define __TARGET_TYPES_H__
#define u_char unsigned char

#define int16 int
#define u_int16 unsigned int
#define int32 long
#define u_int32 unsigned long
Pagina 86 din 133

#endif
Ts_cfg.h
//variabile de configurare a task-urilor...
#define COMUNIC_INCREMENTAL 1
#define COMUNIC_ONIX 1
#define COMUNIC_FServ 1
#define TCP_TICK_ON_OFF 1
//prioritati task-uri
#define TASK_TICK_PRIO 7
#define TASK_RECV_INC_PRIO 1
#define TASK_RECV_ONIX_PRIO 2
#define TASK_RECV_FServ_PRIO 3
#define TASK_SEND_ONIX_PRIO 4
#define TASK_SEND_INC_PRIO 5
#define TASK_SEND_FServ_PRIO 6
//adrese IP masini distante

#define LOCALIP "192.168.1.99"
#define REMOTEIP_FServ "192.168.1.201" //server "FileServer"
#define REMOTEIP_INC "193.231.233.156" //server "incremental.ro"
#define REMOTEIP_ONIX "193.41.127.218" // server Onix la Valcea...
//porturi masini distante

#define RTP_LOCALPORT_INC 8901
#define RTP_LOCALPORT_ONIX 8902
#define RTP_LOCALPORT_FServ 8903
#define RTP_PORT_INC 8801
#define RTP_PORT_ONIX 8802
#define RTP_PORT_FServ 8803
Pagina 87 din 133

#define TASK_STK_SIZE 1024 // Size of each task's stacks (# of WORDs)

#define RTP_MAXPACKETSIZE 256
#define ERR_CONECTARE -1
#define ERR_DESCH_FISIER -2
#define ERR_NO_TASKS -10
#define INIT_OK 99
2181.h
#include "dsptargt.h"
typedef void (*ISR_FP)(u_int16 w);

typedef void* (*FPTR)(int ndx, u_int16 event);
int dsp_install(int ndx,char *fname,ISR_FP fp);

void dsp_uninstall(int ndx);
void dsp_reset(int ndx);
int dsp_swdchk(int ndx);
int dsp_rdbloc(int ndx,u_int16 *bb,int cnt,u_int16 adr);

int dsp_wrbloc(int ndx,u_int16 *bb,int cnt,u_int16 adr);
void dsp_isr(void);
void init_dsps(void);
DSP.h
#include <stdio.h>
#include <conio.h>
#include "2181.h"
#include "mat.h"
#define MAXDSP 4
typedef void* (*FPTR)(int ndx,u_int16 event);
Pagina 88 din 133

void trt_dsp0(u_int16 w);

void trt_dsp1(u_int16 w);
int poll(int ndx);

int blk2bmcmd(int ndx,u_int16 bmadr,u_int16 page,u_int16 mode,u_int16 len);
DSPtargt.h
#include <dos.h>
#include "targtype.h"
#define IDMA_ADDR(port,val) outport(port,val)

#define IDMA_WR(port,val) outport(port+2,val)
#define IDMA_RD(port) inport(port+2)
#define set5c0(w) outportb(0x5c0,w)

#define read5c0() (inportb(0x5c0))
Interrs.h
#include <conio.h>
#include <stdio.h>
#include "mat.h"
#include "2181.h"
#define ERR_INT_2MS -1
#define ERR_INT_ARG -2
#define ERR_INT_DSP -3
void instalare_intreruperi(void);
void revenire_intreruperi_initiale(void);
void interrupt int2ms(void);

void interrupt int_arb(void);
Pagina 89 din 133

void interrupt irqdsp(void);
Tks_com.h
#include <stdio.h>
#include <tcp.h>
#include "ts_cfg.h"
#define DSP_0 0
#define DSP_1 1
#define DSP_2 2
#define DSP_3 3
extern FILE *fisier_inc,*fisier_onix, *fisier_FServ;
//packet RTP
typedef struct {
unsigned char cc:4; // CSRC count
unsigned char extension:1; // header extension flag
unsigned char padding:1; // padding flag
unsigned char version:2; // protocol version, de obicei 2
unsigned char payloadtype:7; // payload type
unsigned char marker:1; // marker bit
unsigned short seqnum; // sequence number
unsigned long timestamp; // timestamp
unsigned long ssrc; // synchronization source
unsigned char data[RTP_MAXPACKETSIZE]; // date efective.
} RTPpacket;
typedef struct{
unsigned short indicator_locatie;
unsigned short seq_num;
char es_voce[160];
Pagina 90 din 133

}LocatieBuffer;
int initiere_comunicare(void);
void RTPclose();
void initializare_packet_rtp( RTPpacket *pck, unsigned int seq_num, unsigned long

timestamp );
void RTPpacket_data( RTPpacket* pck, unsigned int payload[160]);
void ordonare_packete_receptionate(RTPpacket* pck_receptionate[], int nr_pckt);
void Task_tcpTick(void *data); // Function prototypes of tasks

void Task_recv_INC(void *data);//Task de receptie a packetelor incremental.ro
void Task_send_INC(void *data); //Task de trimitere de packete incremental.ro
void Task_recv_ONIX(void *data); //Task de receptie a packetelor Onix
void Task_send_ONIX(void *data); //Task de trimitere de packete Onix
void Task_recv_FServ(void *data); //Task de receptie a packetelor FileServer
void Task_send_FServ(void *data); //Task de trimitere de packete FileServer
Pagina 91 din 133

ANEXA B2. Fişiere sursă (.C)
Rtp_UCOS.C
/******************************** uC/OS-II
********************************/
#include "includes.h"
#include "Tks_com.h"
#include "Rtp.h"
#include "Interrs.h"
#include "Dsp.h"
#include "Stacks.h"
#include "Dsptargt.h"
/******************************* VARIABILE
********************************/
OS_EVENT *RandomSem;
struct time ora_curenta;

int dspno=0, dspno1=1;
//adrese masini de comunicare

longword masina_dist, masina_locala;
/*************************** FUNCTION PROTOTYPES
***************************/
void TaskStart(void *data); // Startup task
void RTPclose(void); // Inchidere socketi
/****************************** MAIN
***************************************/
int main (void)
{
int prg_len, i, j, err;
char timp_curent[25];
u_int32 cntciclu, cnterr;
Pagina 92 din 133

static FPTR fp[MAXDSP];
//initializare stiva comunicatie...

sock_init();
//initializare DSP-uri...
init_dsps();
//validare bufferi simetrici
asm{
mov dx, 0x5e0;
mov al, 0x5f;
out dx, al;
}
//incarcarea programelor in DSP-uri...

prg_len=dsp_install( dspno, "ts81.dat", trt_dsp0 ); //incarcare program DSP 0...
printf( "prg_len[%d]=%04X\n", dspno, prg_len );
prg_len=dsp_install( dspno1, "ts81.dat", trt_dsp1 ); //incarcare program DSP1...

printf( "prg_len[%d]=%04X\n", dspno1, prg_len );
//salvarea, modificarea, setarea noilor vectori de intrerupere pe IRQ 5,7,15

instalare_intreruperi();
PC_DispClrScr(DISP_FGND_WHITE + DISP_BGND_BLACK); // Clear the screen

OSInit(); // Initialize uC/OS-II
PC_DOSSaveReturn(); // Save environment to return to DOS
PC_VectSet(uCOS, OSCtxSw); // Install uC/OS-II's context switch vector
RandomSem = OSSemCreate(1); // Random number semaphore
OSTaskCreate(TaskStart, (void *)0, (void *)&TaskStartStk[TASK_STK_SIZE - 1],
0);
OSStart(); // Start multitasking
Pagina 93 din 133

return 0;
}
/*************************** STARTUP TASK

**********************************/
void TaskStart (void *data)
{
UBYTE i, err;
WORD key;
char s[100];
data = data; // Prevent compiler warning
OS_ENTER_CRITICAL();
PC_VectSet(0x08, OSTickISR); // Install uC/OS-II's clock tick ISR
PC_SetTickRate(OS_TICKS_PER_SEC); // Reprogram tick rate
OS_EXIT_CRITICAL();
OSStatInit(); // Initialize uC/OS-II's statistics
PC_DispStr(26, 0, "uC/OS-II, The Real-Time Kernel", DISP_FGND_WHITE +

DISP_BGND_RED + DISP_BLINK);
initiere_comunicare();
PC_DispStr( 0, 23, "#Tasks : xxxxx CPU Usage: xxx #Task switch/sec: xxxxx ",
DISP_FGND_WHITE);
PC_DispStr(28, 24, "<-PRESS 'ESC' TO QUIT->", DISP_FGND_WHITE +
DISP_BLINK);
for (;;) {
sprintf(s, "%5d", OSTaskCtr); // Display #tasks running
PC_DispStr(17, 23, s, DISP_FGND_BLUE + DISP_BGND_CYAN);
sprintf(s, "%3d", OSCPUUsage); // Display CPU usage in %
Pagina 94 din 133


sprintf(s, "%5d", OSCtxSwCtr); // Display #context switches per second
OSCtxSwCtr = 0;
PC_GetDateTime(timp_curent); // Get and display date and time

PC_DispStr(0, 24, timp_curent, DISP_FGND_BLUE + DISP_BGND_CYAN);
fprintf( fisier_inc, "TaskStart \n");

fprintf( fisier_FServ, "TaskStart \n");
fprintf( fisier_onix, "TaskStart \n");
if (PC_GetKey(&key) == TRUE)
{ // See if key has been pressed
if (key == 0x1B)
{ // Yes, see if it's the ESCAPE key PC_DispStr(35, 15, "Ma opresc...",
DISP_FGND_BLUE + DISP_BGND_CYAN);
RTPclose();//inchiderea socketilor...
revenire_intreruperi_initiale();
//dezinstalarea celor 2 DSP-uri...
dsp_uninstall(dspno);
dsp_uninstall(dspno1);
OSTimeDlyHMSM( 0, 0, 0, 250 );
PC_DOSReturn(); // Return to DOS }
}
OSTimeDlyHMSM(0, 0, 1, 0); // Wait one second
}
}
Pagina 95 din 133

/******************************** TASKS
************************************/
//Afiseaza in coltul din stanga-jos a ecranului ceasul curent...
void AfisareCeas_Task( void *data )
{
UBYTE err;
static char timp_curent[25];
data=data;
for(;;)
{
PC_GetDateTime(timp_curent); // Get and display date and time
PC_DispStr(0, 24, timp_curent, DISP_FGND_BLUE + DISP_BGND_CYAN);
OSTimeDly( OS_TICKS_PER_SEC);
}
}
// Deschidere si conectare socketi pentru RTP ...

int RTPinit(char *localip, char *remoteip, word RTP_PORT_DIST, word
RTP_PORT_LOCAL, udp_Socket *socket, char buff_adresa[25], FILE *fisier )
{
localip=localip;
//Aflare adresa IP masina distanta...DNS querry
if( !(masina_dist=resolve( remoteip ) ) )
{
printf("Nu s-a putut afla adresa IP a '%s'...\n", remoteip);
return 1;
}
printf("Adresa masinii distante este %s...\n", inet_ntoa( buff_adresa, masina_dist ) );
if( !udp_open( socket, RTP_PORT_LOCAL, masina_dist, RTP_PORT_DIST, NULL
) ) return ERR_CONECTARE;
fprintf( fisier, "Deschidere socket %d\n", udp_open( socket, RTP_LOCALPORT,
masina_dist, RTP_REMOTEPORT, NULL ) );
Pagina 96 din 133

fprintf( fisier, "Masinile s-au conectat cu succes...\n" );

return 0;
}
Pagina 97 din 133

2181.C
#include <stdio.h>
#include <conio.h>
#include "2181.h"
#include "mat.h"
#include "dsp.h"
FPTR fp[MAXDSP];
u_int16 far bb1[0x400],bb2[0x400];
u_int16 far bb1_[MAXDSP][0x400],bb2_[MAXDSP][0x400];
u_int16 bstart[MAXDSP],page[MAXDSP];
u_int16 flag[MAXDSP];
void trt_dsp0(u_int16 w)
{
flag[0]=1;
flag[2]=1;
#pragma argsused
} //trt_dsp0
void trt_dsp1(u_int16 w)
{
flag[1]=1;
flag[3]=1;
#pragma argsused
} //trt_dsp0
int poll(int ndx) //verifica existenta transferului prin IDMA...

{
u_int16 tmp;
tmp=0;
dsp_rdbloc(ndx,&tmp,1,0x7400);
return tmp;
} //poll
Pagina 98 din 133

int blk2bmcmd(int ndx,u_int16 bmadr,u_int16 page,u_int16 mode,u_int16 len)

{
u_int16 cc[4];
if(poll(ndx)) return 0;
if(len>0x400) return 0;
cc[0]=1;
cc[1]=bmadr&0x3fff;
cc[2]=(page<<8)|(mode&0x07);
cc[3]=len;
dsp_wrbloc(ndx,cc,4,0x7400);
return 1;
} //blk2bmcmd
Exe2IDMA.C
#include <stdio.h>
#include "dsptargt.h"
static u_int16 addr,w1,w2,_w1,_w2;
static char line[90];
int load_prg(u_int16 port,char *fname)

{
FILE *prg_file;
int state;
u_int16 prg_len,crt_addr;
state=0;
_w1=0x1800;
_w2=0x000F;
prg_file=fopen(fname,"r");
if(!prg_file)
Pagina 99 din 133

{
IDMA_ADDR(port,0);
IDMA_WR(port,_w1);
IDMA_WR(port,_w2);
return 0;
} //endif
prg_len=0;
crt_addr=0;
while(fgets(line,80,prg_file))
{
switch(state){
case 0:
trt_state0:
if(line[0]!='@')
{
//unrecognized line
fputs(line,stderr);
break;
} //endif
if(line[1]=='P')
{
state=1;
break;
} //endif
if(line[1]=='D')
{
state=2;
break;
} //endif
break;
case 1:
if(!sscanf(line,"%04X",&addr))
Pagina 100 din 133

{
state=0;
break;
} //endif
addr&=0x3fff;
if(!addr)
{
state=5;
break;
} //endif
IDMA_ADDR(port,addr);
crt_addr=addr;
state=3;
break;
case 2:
if(!sscanf(line,"%04X",&addr))
{
state=0;
break;
} //endif
addr&=0x3fff;
addr|=0x4000;
IDMA_ADDR(port,addr);
crt_addr=0;
state=4;
break;
case 3:
if(!sscanf(line,"%04X%02X",&w1,&w2)) goto trt_state0;
IDMA_WR(port,w1);
IDMA_WR(port,w2);
crt_addr++;
break;
case 4:
if(!sscanf(line,"%04X",&w1)) goto trt_state0;
Pagina 101 din 133

IDMA_WR(port,w1);
break;
case 5:
if(!sscanf(line,"%04X%02X",&_w1,&_w2)) goto trt_state0;
IDMA_ADDR(port,1);
state=3;
break;
default:
state=0;
break;
} //endswitch
if(crt_addr>prg_len) prg_len=crt_addr;
line[0]=0;
} //endwhile
fclose(prg_file);
IDMA_ADDR(port,0);
IDMA_WR(port,_w1);
IDMA_WR(port,_w2);
return prg_len;
} //load_prg
Interrs.C
//acest fisier continele rutinele de tratare a intreruperilor

#include <stdio.h>
#include <conio.h>
#include "mat.h"
#include "2181.h"
Pagina 102 din 133

#define INT2ms
#define INT_arg
#define INT_dsp
u_int16 flag2ms, flag_arb;

u_int16 xmsg[8],rmsg[8];
void interrupt (*oldvect0d)();

void interrupt (*oldvect0f)();
void interrupt (*oldvect77)();
void instalare_intreruperi();
void revenire_intreruperi_initiale();
void interrupt int2ms() //IRQ5

{
int i;
asm{
mov dx,0x5F8;
mov al,0;
out dx,al;
}
flag2ms=1;
for(i=0;i<8;i++)
{
MATWR(CML,i<<5,xmsg[i]);
rmsg[i]=MATRD(DMEM,i<<5);
} //endfor i
//EOI
asm{
Pagina 103 din 133

mov al,0x20;
//out 0xA0,al; //necesar pt IRQ8..IRQ15
out 0x20,al;
}
} //int2ms
void interrupt int_arb() //IRQ15

{
int i;
asm{
mov dx,0x5F8;
mov al,0;
out dx,al;
}
flag_arb=1;
//EOI
asm{
mov al,0x20;
out 0xA0,al; //necesar pt IRQ8..IRQ15
out 0x20,al;
}
} //int_arb
void interrupt irqdsp() //IRQ7

{
dsp_isr();
//EOI
asm{
mov al,0x20;
Pagina 104 din 133

//out 0xA0,al; //necesar pt IRQ8..IRQ15

out 0x20,al;
}
} //irqdsp
void instalare_intreruperi()
{
#ifdef INT2ms
oldvect0d=getvect(0x0d);
setvect(0x0d, int2ms); //instaleaza intreruperea de 2ms pe INT5
asm{
cli;
}
outport( 0x21, inport( 0x21 ) & 0xDF ); //porneste interuperea
asm{
sti;
}
#endif
#ifdef INT_arg
oldvect0f=getvect(0x0f);
setvect( 0x0f, irqdsp); //instaleaza intreruperea de DSP pe INT7
asm{
cli;
}
outport( 0x21, inport(0x21)&0x7F ); //porneste interuperea
asm{
sti;
}
#endif
#ifdef INT_dsp
oldvect77=getvect(0x77);
setvect( 0x77, int_arb ); //instaleaza intreruperea int_arb pe INT15
Pagina 105 din 133

asm{
cli;
}
outport( 0xA1, inport(0xA1) & 0x7F ); //porneste interuperea
asm{
sti;
}
#endif
} //instalare_intreruperi
void revenire_intreruperi_initiale()
{
#ifdef INT2ms
outport( 0xA1, inport(0xA1)|0x80 );
setvect( 0x77, oldvect77 );
#endif
#ifdef INT_arg
outport( 0x21, inport(0x21)|0x80 );
setvect( 0x0F, oldvect0f );
#endif
#ifdef INT_dsp
outport( 0x21, inport(0x21)|0x20 );
setvect( 0x0D, oldvect0d );
#endif
}
Ucos_II.C
#define OS_GLOBALS
#include "includes.h"
Pagina 106 din 133

#define OS_MASTER_FILE //Prevent the following files frm including includes.h

#include "os_core.c"
#include "os_mbox.c"
#include "os_mem.c"
#include "os_q.c"
#include "os_sem.c"
#include "os_task.c"
#include "os_time.c"
Tks_com.C
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <conio.h>
#include <dos.h>
#include <time.h>
#include <tcp.h>
#include "Tks_com.h"
#include "Ts_cfg.h"
#include "os_cpu.h"
#include "os_cfg.h"
#include "ucos_ii.h"
#include "pc.h"
#include "RTP_Ucos.h"
#include "Stacks.h"
#include "Dsp.h"
#include "Rtp.h"
FILE *fisier_inc, *fisier_onix, *fisier_FServ;
char timp_curent[25];
Pagina 107 din 133

udp_Socket RTPsocket_inc, RTPsocket_onix, RTPsocket_FServ;

char buf_adresa_inc[48], buf_adresa_onix[48], buf_adresa_FServ[48];
int rtp_ret_inc, rtp_ret_onix, rtp_ret_FServ;
//buffere de preluare esantioane din DSP de unde se vor impacheta...

unsigned int buffer_dspread[MAXDSP][160];
unsigned int buffer[4][4]={\

0x5400, 0x54A0, 0x5540, 0x55E0,\
0x5C00, 0x5CA0, 0x5D40, 0x5DE0,\
0x6400, 0x64A0, 0x6540, 0x65E0,\
0x6C00, 0x6C2F, 0x6D40, 0x6DE0,\
}; //adresele celor 4 buffere coresp. fiecarui canal...
//buffere de receptie a packetelor

unsigned char far buf_inc[0xFFFF];
unsigned char far buf_onix[0xFFFF];
unsigned char far buf_FServ[0xFFFF];
//surse de pachete RTP...

source Incr_source, Onix_source, FServ_source;
//stacks
OS_STK TaskStk_tcpTick[2048];
OS_STK TaskStk_send_FServ[TASK_STK_SIZE];
OS_STK TaskStk_recv_FServ[TASK_STK_SIZE];
OS_STK TaskStk_send_INC[TASK_STK_SIZE];
OS_STK TaskStk_recv_INC[TASK_STK_SIZE];
OS_STK TaskStk_send_ONIX[TASK_STK_SIZE];
OS_STK TaskStk_recv_ONIX[TASK_STK_SIZE];
OS_STK TaskStartStk[TASK_STK_SIZE]; // TaskStart stack
Pagina 108 din 133

void initializare_packet_rtp( RTPpacket* pck, unsigned int seq_num, unsigned

long timestamp )
{
pck->cc=0;
pck->extension=0;
pck->padding=0;
pck->version=2;
pck->payloadtype=8; //PCM legea A, 8KHz...
pck->marker=0;
pck->seqnum=htons( seq_num );
pck->timestamp=htonl( timestamp );
pck->ssrc=htonl( 0 );
}
//functie ce umple zona utila de date a pachetului RTP...

void RTPpacket_data( RTPpacket* pck, unsigned int payload[160])
{
static int i;
for(i=0;i<160;i++)
{
pck->data[i]=(char)(0x00FF & payload[i]);
}
}
unsigned int ordonare_packete_recept(RTPpacket* pck_recep[],int nr_pckt)

{
int poz, cnt;
unsigned int minim;
RTPpacket* pck_temp;
poz=0;
while(poz<nr_pckt)
Pagina 109 din 133

{
minim=pck_recep[poz]->seqnum;
for(cnt=poz;cnt<nr_pckt;cnt++){
if(minim>pck_recep[cnt]->seqnum)
{
minim=pck_recep[cnt]->seqnum;
pck_temp=pck_recep[poz];
pck_recep[poz]=pck_recep[cnt];
pck_recep[cnt]=pck_temp;
}
}
poz++;
}
return minim;
}
void completare_locatieBuffer(RTPpacket* pck, LocatieBuffer* locatie)

{
int k;
locatie->indicator_locatie=1; //locatie ocupata...
locatie->seq_num=pck->seqnum;
for(k=0;k<160;k++) locatie->es_voce[k]=pck->data[k];
}
int initializare_sursa(source *s, RTPpacket* pck[], unsigned int cnt)

{
static int i=1;
while(s->probation)
{
if(cnt-i>0)
if(pck[i]->seqnum==s->max_seq+1)
{
s->probation--;
s->max_seq=pck[i]->seqnum;
Pagina 110 din 133

i+=1;
}
printf("Sursa nu poate fi initializata !\n");
OSTimeDly(10);
return NO_INIT;
}
init_seq(s, pck[i]->seqnum);
return SEQ_INIT_OK;
}
void Task_send_INC (void *data)

{
//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal
//indicator de stare la adresa 3FCF din DataMemory
//bufferi de preluare de pachete la adresele 0x1000 si 0x10A0 din DSP_0 DM...
INT16S lun_pack;
unsigned int i,j;
static unsigned int indic_buffer_citire;

static unsigned int seq_num;
static unsigned int indic_buffer_citire_anterioara=0;
static unsigned long time_stamp;
static RTPpacket pck;
data=data;
randomize();
//initializarea random a numarului de secventa si timestamp-ului
seq_num=random( 0x10000 );
time_stamp=random( 0x10000 );
for(;;)
{
while( poll(DSP_0) ) OSTimeDlyHMSM(0,0,0,5);
OSSchedLock();//suspenda functionarea programatorului...
Pagina 111 din 133

dsp_rdbloc(DSP_0, &indic_buffer_citire, 1, 0x7FCF);
//verifica daca s-a mai citit din buferul indicat

if(indic_buffer_citire!=indic_buffer_citire_anterioara)
{
if (indic_buffer_citire==0x0000 )
dsp_rdbloc( DSP_0, buffer_dspread[DSP_0], 160, 0x5000 );
else
dsp_rdbloc( DSP_0, buffer_dspread[DSP_0], 160, 0x50A0 );
indic_buffer_citire_anterioara=indic_buffer_citire;
OSSchedUnlock();//repune in functiune programatorul..
initializare_packet_rtp(&pck, seq_num, time_stamp);

RTPpacket_data(&pck, buffer_dspread[DSP_0] );
lun_pack=12+160;
fprintf( fisier_inc, "\t\t\tTrimis %d\tSeq# %d: %s\n",

sock_fastwrite( &RTPsocket_inc, &pck, lun_pack ), seq_num, pck.data );
seq_num=(seq_num+1)&0xFFFF;
time_stamp=(time_stamp+160)&0xFFFF;
OSTimeDlyHMSM(0,0,0,14);
}
else {
}
}
}
void Task_recv_INC (void *data)

{
Pagina 112 din 133

short nr_rulari, cnt;

LocatieBuffer buffer[64];
short pointer_scriere, pointer_citire;
short i,j,k;
short dif_seqnum, seqnum_exp;
short nr_pcks_consec, indic_loc, gasit;
RTPpacket packete_recept[10];
data=data;
gasit=0;indic_loc=0;
pointer_scriere=10;
nr_rulari=0;
for(;;)
{
cnt=0;
while( sock_recv( &RTPsocket_inc, &packete_recept[cnt] ,sizeof( RTPpacket ), 0 )
>0 )
{
fprintf( fisier_inc, "Primit \tsecv %d\n", ntohs(packete_recept[cnt].seqnum) );
cnt+=1;
}
if(cnt>0) {
if( nr_rulari==0) {
ordonare_packete_recept(packete_recept, cnt);
completare_locatieBuffer(&packete_recept[0], &buffer[pointer_scriere]);
pointer_scriere+=1;
seqnum_exp=packete_recept[0].seqnum;
for(i=1;i<cnt;i++)
{
Pagina 113 din 133

dif_seqnum=(packete_recept[i].seqnum-seqnum_exp);
if(dif_seqnum>0)
{
if (dif_seqnum==1)
{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare0;
}
if(dif_seqnum<MAX_DROPOUT)
{
completare0:
completare_locatieBuffer(&packete_recept[i],\
&buffer[pointer_scriere+dif_seqnum]);
}
} //dif_seqnum>0...
else //dif_seqnum<0...pachete intarziate
{
if( (-10)<dif_seqnum<0 )
}
}//for
nr_rulari+=1;
OSTimeDly(8);//suspenda pe 8 ticks
}//nr_rulari=0...
if(nr_rulari<4)
{
for(i=0;i<cnt;i++)
{
if(dif_seqnum>0)
Pagina 114 din 133

{
if (dif_seqnum==1)
{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare;
}
completare:
{
}
}//dif_seqnum>0...
else //dif_seqnum<0 pachete intarziate...
{
completare_locatieBuffer(&packete_recept[i], &buffer[pointer_scriere+dif_seqnum]);
}
}//for
nr_rulari+=1;
}//nr_rulari<4
//"locatii" pline dupa 4 rulari...

//initializare sursa...inceputul celei de-a 4-a rulari
if(nr_rulari==4)
{
for(k=0;k<10;k++)
if(buffer[k].indicator_locatie==1)
{
indic_loc=k;
gasit=1;
break;
Pagina 115 din 133

}
if(gasit==0) indic_loc=10;
pointer_citire=indic_loc;
while(nr_pcks_consec<MIN_SEQ)
{
if(buffer[indic_loc+1].indicator_locatie==1)
{
nr_pcks_consec+=1;
indic_loc+=1;
}
else//detectie gaura in secventa
{
nr_pcks_consec=0;
for(i=0;;i++)
if(buffer[indic_loc+i].indicator_locatie==1)
{
indic_loc+=i;
break;
}
}
}//while... detectat secv de MIN_SEQ pcks...
goto trs_pkt;
}//initializare la a 4-a rulare...
trs_pkt: //transmitere bloc 160 esantioane al DSP
if(pointer_scriere<=pointer_citire)
{
while(poll(dsp_0)) OSTimeDlyHMSM(0,0,0,5);
OSSchedLock();
dsp_wrbloc(dsp_0, &buffer[pointer_scriere], 160, 0x5400);
OSSchedUnlock();
OSTimeDlyHMSH(0,0,0,17);
Pagina 116 din 133

}
else //pointer citire ajunge din urma pointer scriere
{
dsp_wrbloc(dsp_0, &buffer_liniste, 160, 0x5400);
}
}//if cnt=0...
else OSTimeDly( 4 );//nu s-au primit packete...
}
void Task_send_ONIX (void *data)

{
//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal
//indicator de stare la adresa 3FCE din DataMemory
//bufferi de preluare de pachete la adresele 0x1800 si 0x18A0 din DSP_0's DM
INT16S temp_cnt, lun_pack;
unsigned int i,j;

data=data;
randomize();
for(;;)
{
Pagina 117 din 133

dsp_rdbloc(DSP_0, &indic_buffer_citire, 1, 0x7FCD);

{
else

lun_pack=12+160;

}
else OSTimeDlyHMSM(0,0,0,5);
}
void Task_recv_ONIX (void *data)

{
Pagina 118 din 133

short i,j,k;
data=data;
pointer_scriere=10;
nr_rulari=0;
//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;
for(;;)
{
cnt=0;
>0 )
{
cnt+=1;
}
if(cnt>0) {
if( nr_rulari==0) {
completare_locatieBuffer(&packete_recept[0], &buffer[pointer_scriere]);
pointer_scriere+=1;
for(i=1;i<cnt;i++)
{
Pagina 119 din 133

if(dif_seqnum>0)
{
if (dif_seqnum==1)
{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare0;
}
{
completare0:
}
} //dif_seqnum>0...
{
}
}//for
nr_rulari+=1;
}//nr_rulari=0...
if(nr_rulari<4)
{
for(i=0;i<cnt;i++)
{
if(dif_seqnum>0)
{
Pagina 120 din 133

if (dif_seqnum==1)
{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare;
}
completare:
{
}
}//dif_seqnum>0...
{
}
}//for
nr_rulari+=1;
}//nr_rulari<4

if(nr_rulari==4)
{
for(k=0;k<10;k++)
{
indic_loc=k;
gasit=1;
break;
}
Pagina 121 din 133

{
{
nr_pcks_consec+=1;
indic_loc+=1;
}
{
nr_pcks_consec=0;
for(i=0;;i++)
{
indic_loc+=i;
break;
}
}
goto trs_pkt;

{
OSSchedLock();
dsp_wrbloc(dsp_0, &buffer[pointer_scriere], 160, 0x5C00);
OSSchedUnlock();
Pagina 122 din 133

}
{
dsp_wrbloc(dsp_0, &buffer_liniste, 160, 0x5C00);
}
}//if cnt=0...
}
}
void Task_send_FServ (void *data)

{
//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal din DSP_1
//indicator de stare la adresa 3FCF din DataMemory
//bufferi de preluare de pachete la adresele 0x1000 si 0x10A0 din DSP_1's DM
INT16S lun_pack;
unsigned int i,j;

data=data;
randomize();
//initializarea random a numarului de secventa si timestamp-ului
for(;;)
{
Pagina 123 din 133

dsp_rdbloc(DSP_1, &indic_buffer_citire, 1, 0x7FCF);

{
else

lun_pack=12+160;

}
else OSTimeDlyHMSM(0,0,0,5);
}
}
void Task_recv_FServ (void *data)

{
short i,j,k;
Pagina 124 din 133


data=data;
pointer_scriere=10;
nr_rulari=0;
//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;
for(;;)
{
cnt=0;
>0 )
{
cnt+=1;
}
if(cnt>0) {
if( nr_rulari==0) {
completare_locatieBuffer(&packete_recept[0],\ &buffer[pointer_scriere]);
pointer_scriere+=1;
for(i=1;i<cnt;i++)
{
if(dif_seqnum>0)
Pagina 125 din 133

{
if (dif_seqnum==1)
{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare0;
}
{
completare0:
}
} //dif_seqnum>0...
{
}
}//for
nr_rulari+=1;
}//nr_rulari=0...
if(nr_rulari<4)
{
for(i=0;i<cnt;i++)
{
if(dif_seqnum>0)
{
if (dif_seqnum==1)
Pagina 126 din 133

{
pointer_scriere+=1;
seqnum_exp+=1;
goto completare;
}
completare:
{
}
}//dif_seqnum>0...
{
}
}//for
nr_rulari+=1;
}//nr_rulari<4

if(nr_rulari==4)
{
for(k=0;k<10;k++)
{
indic_loc=k;
gasit=1;
break;
}
Pagina 127 din 133

{
{
nr_pcks_consec+=1;
indic_loc+=1;
}
{
nr_pcks_consec=0;
for(i=0;;i++)
{
indic_loc+=i;
break;
}
}
goto trs_pkt;

{
OSSchedLock();
dsp_wrbloc(dsp_1, &buffer[pointer_scriere], 160, 0x5400);
OSSchedUnlock();
}
Pagina 128 din 133


{
dsp_wrbloc(dsp_1, &buffer_liniste, 160, 0x5400);
}
}//if cnt=0...
}
}
//task care face tcp_tick() si ca urmare raspunde la ping...

void Task_tcpTick (void *data)
{
data=data;
for(;;)
{
tcp_tick( NULL );
OSTimeDly( 5 );
}
}
int initiere_comunicare(void)
{
if( COMUNIC_INCREMENTAL ){
PC_GetDateTime( timp_curent );
fisier_inc = fopen( "rez_incr.txt", "wt" );
if( !fisier_inc )
{
printf("Nu s-a putut deschide fisierul 'rez_inc.txt' pentru salvarea rezultatelor...\n");
goto com_onix;
}
fprintf(fisier_inc,"Fisier deschis cu succes...la ora %s\n", timp_curent);
rtp_ret_inc=RTPinit( LOCALIP,REMOTEIP_INC, RTP_PORT_INC,
RTP_LOCALPORT_INC, &RTPsocket_inc, buf_adresa_inc, fisier_inc );
fprintf( fisier_inc, "RTPinit=%d\nLet's begin...\n", rtp_ret_inc);
Pagina 129 din 133

fprintf(fisier_inc,"Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\

sock_recv_init( &RTPsocket_inc, buf_inc, sizeof( buf_inc ) ), sizeof( buf_inc ),
sizeof( RTPpacket ) );
OSTaskCreate(Task_recv_INC, (void *)0, (void
*)&TaskStk_recv_INC[TASK_STK_SIZE - 1], TASK_RECV_INC_PRIO );
OSTaskCreate(Task_send_INC, (void *)0, (void
*)&TaskStk_send_INC[TASK_STK_SIZE - 1], TASK_SEND_INC_PRIO );
}
else
{
printf("Nu s-a dorit comunicatie cu Incremental...\n");
goto com_onix;
}
com_onix:
if( COMUNIC_ONIX ){
fisier_onix = fopen( "rez_onix.txt", "wt" );
if( !fisier_onix )
{
printf("Nu s-a putut deschide fisierul 'rez_onix.txt' pentru salvarea rezultatelor...\n");
goto com_FServ;
}
fprintf(fisier_onix,"Fisier deschis cu succes...la ora %s\n", timp_curent);
rtp_ret_onix=RTPinit( LOCALIP,REMOTEIP_ONIX, RTP_PORT_ONIX,
RTP_LOCALPORT_ONIX, &RTPsocket_onix, buf_adresa_onix, fisier_onix );
fprintf( fisier_onix, "RTPinit=%d\nLet's begin...\n", rtp_ret_onix);
fprintf(fisier_onix,"Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\
sock_recv_init( &RTPsocket_onix, buf_onix, sizeof( buf_onix ) ), sizeof( buf_onix ),
sizeof( RTPpacket ) );
OSTaskCreate(Task_recv_ONIX, (void *)0, (void
*)&TaskStk_recv_ONIX[TASK_STK_SIZE - 1], TASK_RECV_ONIX_PRIO );
OSTaskCreate(Task_send_ONIX, (void *)0, (void
*)&TaskStk_send_ONIX[TASK_STK_SIZE - 1], TASK_SEND_ONIX_PRIO );
Pagina 130 din 133

}
else
{
printf("Nu s-a dorit comunicatie cu Onix...\n");
goto com_FServ;
}
com_FServ:
if( COMUNIC_FServ ){
fisier_FServ = fopen( "rez_FServ.txt", "wt" );
if( !fisier_FServ )
{
printf("Nu s-a putut deschide fisierul 'rez_FServ.txt' pentru salvarea rezultatelor...\n");
goto tcp_tick;
}
fprintf(fisier_FServ,"Fisier deschis cu succes...la ora %s\n", timp_curent);
rtp_ret_FServ=RTPinit( LOCALIP,REMOTEIP_FServ, RTP_PORT_FServ,
RTP_LOCALPORT_FServ,&RTPsocket_FServ, buf_adresa_FServ, fisier_FServ );
fprintf( fisier_FServ, "RTPinit=%d\nLet's begin...\n", rtp_ret_FServ);
fprintf(fisier_FServ, "Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\
sock_recv_init( &RTPsocket_FServ, buf_FServ, sizeof(buf_FServ) ),
sizeof(buf_FServ), sizeof(RTPpacket) );
OSTaskCreate(Task_recv_FServ, (void *)0, (void
*)&TaskStk_recv_FServ[TASK_STK_SIZE - 1], TASK_RECV_FServ_PRIO );
OSTaskCreate(Task_send_FServ, (void *)0, (void
*)&TaskStk_send_FServ[TASK_STK_SIZE - 1], TASK_SEND_FServ_PRIO );
}
else
{
printf("Nu se doreste comunicatie de nici un fel...\n");
tcp_tick:
if(TCP_TICK_ON_OFF)
Pagina 131 din 133

OSTaskCreate(Task_tcpTick, (void *)0,

(void*)&TaskStk_tcpTick[TASK_STK_SIZE - 1], TASK_TICK_PRIO );
return ERR_NO_TASKS;
}
return INIT_OK;
}
void RTPclose(void)
{
sock_close(&RTPsocket_inc);
sock_close(&RTPsocket_onix);
sock_close(&RTPsocket_FServ);
}
Pagina 132 din 133

ANEXA B3. Fişierul “Wattcp.cfg”
print="Packet driver incarcat…"

my_ip=192.168.1.99
netmask=255.255.255.0
gateway=192.168.1.1
domainslist="topex.rdsnet.ro"
Pagina 133 din 133

Diploma - WWW - Tocilar

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Diploma - WWW - Tocilar

Încărcat de

Drepturi de autor:

Formate disponibile

Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.

Implementarea interfatei VoIP pe o centrala telefonica digitala

CAPITOLUL 1. Tehnologia “Voice over IP”

Modul de transmisie a vocii prin intermediul telefoniei tradiţionale a atins o adevarată

Pagina 1 din 133

VoIP ( Voice over IP ) poate fi definită ca posibilitatea de a realiza apeluri telefonice

Pagina 2 din 133

Reducerea costurilor – Se pot realiza mari reduceri de cheltuieli în cazul convorbirilor

Simplitate – Integrarea serviciilor de voce şi date într-o unică reţea de transport

Fig. 1.1.1. Arhitectura VoIP. [16]

Provocările cărora proiectanţii trebuie să le

Pagina 3 din 133

1.2. Probleme şi constrângeri

Pagina 4 din 133

Implementările tehnologiei Voice over IP (VoIP) permit utilizatorilor să transporte

Menţinerea unei calităţi acceptabile, în ciuda problemelor legate de variaţia

Pagina 5 din 133

Întârzierea de codare – depinde în egală măsură de timpul de execuţie al procesului şi

Pagina 6 din 133

Întârzierea în reţea – are drept cauze timpul de propagare pe mediul fizic,

Figura 1.2.2. Întârzierea totală de transmisie. [17].

Pagina 7 din 133

Jitter-ul – reprezintă variaţia momentelor la care pachetele ar fi trebuit să sosească la

Pagina 8 din 133

Compensarea pachetelor pierdute în reţea – pierderea pachetelor conţinând

Compensarea ecoului – Într-o reţea telefonică, ecoul este cauzat de reflexia

Pagina 9 din 133

Figura 1.2.4. Ecoul – locul şi motivul apariţiei [18].

Ecoul se întâlneşte în reţeaua telefonică bazată pe comutaţia de circuite, însă acolo

Pagina 10 din 133

Compresia de voce este vitală tehnologiei VoIP datorită faptului că traficul

1.3. Arhitectura sistemelor VoIP

Pagina 11 din 133

Figura 1.3.1. Arhitectura structurii

Pagina 12 din 133

Despre planul transportului de voce, incluzând aici vocea propriu-zisă, reprezentarea

Figura 1.3.2. Arhitectura software a unui sistem VoIP [13]

Modulul de pachetizare a vocii – cunoscut şi sub numele de modulul de procesare a

Pagina 13 din 133

Partiţionarea oferă o interfaţă clară între funcţiile generice de procesare de voce, de

1.3.1. Modulul de procesare a vocii

Pagina 14 din 133

continuă scădere transformîndu-l într-o componentă ideală pentru arhitectură hardware a

Software-ul realizează de asemenea şi o măsurare a nivelului de zgomot în starea de

Pagina 15 din 133

poştală. Informaţiile interschimbate includ date de configurare, rapoarte de stare, etc.

Pagina 16 din 133

Figura 1.3.1.1. Structura modulului de procesare a vocii. [13].

1.3.2. Modulul de semnalizare şi management

Software-ul sistemelor VoIP asigură buna funcţionare a semnalizării telefonice,

Pagina 17 din 133

Modulul de transfer a semnalizării telefonice – are, după cum ne-am obişnuit, o

Modulul pentru protocolul de reţea – are submodule obligatorii:

1.4. Tipuri de conexiuni

Pagina 18 din 133

PC–Telefon – legătură telefonică între un calculator multimedia şi un post telefonic

Pagina 19 din 133

Telefon–telefon – legătură telefonică între 2 posturi telefonice normale. Diferenţa este

Figura 1.4.2. Tipuri de conexiuni VoIP

1.5. Protocoale şi soluţii software

În dinamica muncă de proiectare şi producţie, în dorinţa de a scoate cât mai repede

Pagina 20 din 133

Figura 1.5.1. Funcţionalitatea H.323.