Cauzele jitterului
Cauza bruiaj poate fi factori diferiți care au determinat caracteristicile de transmitere a datelor în rețelele de pachete: este o sarcină mare de comutare noduri, în cazul în care pachetele sunt coada de așteptare și așteaptă să fie trimise la următorul punct de agregare și de rutare a traficului de rețea, această diversificare a pachetului de rute (pachete care au urmat unul după celălalt la sursă, pot fi transmise prin diferite căi către destinatar și, prin urmare, și probabil prelucrate de un număr diferit de noduri de rețea, fiecare contribuind cu întârziere proprie, aleatorie Pachetul Botko).
Având în vedere criticitatea efectului bruiajului asupra calității reproducerii sunetului, în diferite implementări [VoIP], se folosesc diferite tehnici și tehnologii pentru eliminarea sau dezlipirea traficului media de rețea. Aproape toate implementările se aruncă spre folosirea așa-numitului tampon jitter-tampon.
JB către Asterisk
Pentru a înțelege cum funcționează JB în Asterisk, trebuie să înțelegeți mai bine conceptul de organizare a canalelor în Asterisk. Canalul din Asterisk are loc când vine apelul. Și pentru apelantul prin Asterisk, această chemare va fi expediată, iar pentru Asterisk - de intrare. Mai mult, apelul primit este plasat în planul de procesare a apelurilor. Dacă canalul generat pornește aplicația Dial (), atunci este creat un al doilea canal (ieșind din punctul de vedere Asterisk) pentru a efectua un apel către cel aferent. Dacă este răspunsul celui de-al doilea canal de ieșire, Asterisk leagă aceste două canale la pod. Două canale vă permit să transferați voce între ele: cadrele de voce recepționate într-un canal sunt transmise unui alt canal cu ajutorul unui pod.
Exemplu 1. Luați în considerare scriptul de apel atunci când clientul de sipare apelează canalul zap al interfeței PSTN:
Canal 1 - SIP / muzică (primit) Canal 2 - Zap / 1 (ieșire)
SIP || Podul || ZAP
- Channel2 pentru SIP / myphone (incoming)
SIP || Podul || ZAP
Aici este necesar să se aplice de-jittering. Datorită faptului că ZAP-canal nu poate trimite pachete de voce la bruiaj (care va duce la o deteriorare a calității vorbirii reproduse în Zap-canal), este în zap-canal trebuie să fie aplicat de dzhittirovanie. Aceasta se face în setările din zapata.conf (chan_dahdi.conf) prin activarea opțiunii jbenable = yes. Această opțiune spune: "Pentru traficul care intră în canalul zap, activează JB."
Trebuie amintit faptul că funcționează numai pentru JB în canalele de pod (sip => zap etc.), în care unul dintre canalele ar trebui să fie probabilitatea de apariție a jitter și al doilea canal de bruiaj pod este nevalid. Implementarea acestuia în canalul de intrare (sip => aplicația Meetme ()) este permisă numai în versiunea 1.6 sau prin patch-uri și prin apelarea aplicației prin intermediul canalului local.
Din cele de mai sus, se poate concluziona că bruiajul poate apărea numai într-un canal cu comutare de pachete. Utilizare de dzhittirovanie (de buffer-jitter) numai atunci când canalele sunt în pod, în plus, o JB includere condiție ar trebui să fie faptul că unul dintre canalele din pod bruiaj de lucru inacceptabilă (numai într-un canal cu comutare de canal). JB va fi practicat doar pe canalul de ieșire (în termeni sreniya Asterisk, Tx), în care bruiaj este aspectul inacceptabil (de exemplu, zap - canal).
Sectiuni de magazin
Trimiteți-le prietenilor: