Proszę o wytłumaczenie (zajętość pasma przez kodeki)

Problemy związane z Unified Communications
Wiadomość
Autor
Awatar użytkownika
szyna
wannabe
wannabe
Posty: 60
Rejestracja: 17 sty 2007, 21:54

Proszę o wytłumaczenie (zajętość pasma przez kodeki)

#1

#1 Post autor: szyna »

Witam

Ostatnio trochu zacząłem czytać o VoIP (kodeki i takie tam) i natknąłem się na takie cóś :

"Przykładowe zapotrzebowanie dla niektórych kodeków i w zależności od ilości ramek czasowych na pakiet:
G.711 - ok. 99 kbit/s (10ms/pakiet)
G.711 - ok. 82 kbit/s (20ms/pakiet)
G.729 - ok. 43 kbit/s (10ms/pakiet)
G.729 - ok. 26 kbit/s (20ms/pakiet)
G.729 - ok. 20 kbit/s (30ms/pakiet)
G.723.1 5.3kbit/s - ok. 17 kbit/s (30ms/pakiet)"

Nie bardzo to rozumiem. W G.729 im więcej "mowy" wsadzimy w pakiet to jest mniejsze zapotrzebowanie na pasmo ? hmm dziwne

shh
wannabe
wannabe
Posty: 129
Rejestracja: 24 lis 2005, 00:10
Lokalizacja: Warszawa

#2

#2 Post autor: shh »

Im cześciej wysyłamy mniejsze pakiety (krótsza próbka głosu) tym większa suma wysłanych bajtów samego nagłówka.

Przykład: mamy do wysłanie 60ms głosu. Nagłówiek RTP/UDP/IP = 40bajtów.
- próbki 10msekundowe - 6 pakietów - suma nagłówków = 240bajtów
- próbki 20msekundowe - 3 pakiety - suma nagłówków = 120bajtów
- próbki 30msekundowe - 2 pakiety - suma nagłówków = 80bajtów

Awatar użytkownika
balam
wannabe
wannabe
Posty: 977
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#3

#3 Post autor: balam »

TU masz fajnego linka do poczytania.

Co do zapotrzebowania na pasmo przy samplach 20ms i 30ms to musisz pamietac ze dla sampla 20ms jest 50 pakietow na skunde, a dla 30ms jest to juz tylko 33/34 pakiety.
Sama wielkosc paczki glosowej dla 729 20ms bedzie 20bytes, a dla 30ms bedzie 30bytes wiec de facto mniejsze zapotrzebowanie na bandwidth jesli doliczysz overhead.
Somewhere back in time.

Awatar użytkownika
szyna
wannabe
wannabe
Posty: 60
Rejestracja: 17 sty 2007, 21:54

#4

#4 Post autor: szyna »

dzięki za szybką odpowiedź. poczytam

czyli prędkość kodowania dźwięku G.729 wynosi 1 milisekunda w 1 bajcie ?

Awatar użytkownika
FrozenShadoow
wannabe
wannabe
Posty: 203
Rejestracja: 06 paź 2005, 23:06

#5

#5 Post autor: FrozenShadoow »

Powiem tak, dobranie kodeka wcale nie jest prostym zadaniem.....musisz wziąć wiele czynników pod uwagę np nie tylko pasmo ale wg mnie najważniejszy Jitter bo ten parametr ma kluczowe znaczenie w QoS VoIP tzn ma dużą wagę na R-Value (generalnie jak poniżej 81,5 to jest żle), jak i również Packet Loss i tu przykład np G.711 potrzebuje duże pasmo ale często wysyła ruch RTP wiec jak nastąpi utrata pakietu to nie jest to az tak straszne np jak w wypadku G.729. Rozumiem ze będzie ruch po sieci Wan (bo w przypadku Lan to chyba nie ma problemu z wyborem :)) i wtedy kodek najlepiej dobrać do SLA prowaidera. Każdy z trojki TP, Dialog, Netia ma swoje własne ustalenia i rożne poziomy SLA zależne od pakietu, rożne AF itp więc dochodzi Ci do tego jeszcze remarkowanie a wiec opóżnienie...jak widzisz temat rzeka..sam siedzę już 6 miechów i jeszcze do końca nie wiem czy dobrałem dobre parametry do łączy...no ale przy porównywalnych cenach najlepszy Dialog, Netia a najgorsza TP no chyba ze klasa Biznes po FR ale to już spore koszta. Wiec zostaje metoda MOS ale musi być duża grupa badanych bo inaczej nie bedzie obiektywnie. Jak masz jakies pytanie do wal smiało..zjadłem na tym zęby:)
i na 256kbit/s przy 4 fonach i kompach na łączu i da sie porozmawiać a MOS 3,9 wiec maksa kodeka no chyba ze ułożylem tendencyjne pytania na ankiecie:)
Nie wyrażaj małej rzeczy w wielu słowach, lecz wielką w niewielu

Awatar użytkownika
szyna
wannabe
wannabe
Posty: 60
Rejestracja: 17 sty 2007, 21:54

#6

#6 Post autor: szyna »

ooo takiego majstra szukam :-)
to powiedz mi co to za wymysł U-RDP ? i po kiego to ?

Awatar użytkownika
FrozenShadoow
wannabe
wannabe
Posty: 203
Rejestracja: 06 paź 2005, 23:06

#7

#7 Post autor: FrozenShadoow »

No jeśli U-RDP to chyba http://www.ihrc.umn.edu/research/vitrag ... c2766.html

A tak na poważnie to chyba http://www.icann.org/en/udrp/ w każdym bądź razie rozwiń skrót bo chyba jest błędny.
Nie wyrażaj małej rzeczy w wielu słowach, lecz wielką w niewielu

Awatar użytkownika
szyna
wannabe
wannabe
Posty: 60
Rejestracja: 17 sty 2007, 21:54

#8

#8 Post autor: szyna »

w jakiejś mądrej książce czytałem, że Reliable User Data Protocol wysyła kilka razy ten sam pakiet i że stacja odbiorcza odrzuca zbędne (powtarzające się) pakiety

Awatar użytkownika
FrozenShadoow
wannabe
wannabe
Posty: 203
Rejestracja: 06 paź 2005, 23:06

#9

#9 Post autor: FrozenShadoow »

:) no i mowilem ze cos ze skrótem zamotałes :)....RUDP jest to sposób ale wtedy trzeba dobrać odpowiedni kodek....czyli tak jak wczesniej pisałem wszystko zależy czym dysponujemy.
Nie wyrażaj małej rzeczy w wielu słowach, lecz wielką w niewielu

Awatar użytkownika
balam
wannabe
wannabe
Posty: 977
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#10

#10 Post autor: balam »

FrozenShadoow pisze:Packet Loss i tu przykład np G.711 potrzebuje duże pasmo ale często wysyła ruch RTP wiec jak nastąpi utrata pakietu to nie jest to az tak straszne np jak w wypadku G.729.
Jaka jest roznica utraty pakietu G711 a G729 wedlug Ciebie, bo ja szczerze nie widze za duzej?
Somewhere back in time.

Awatar użytkownika
FrozenShadoow
wannabe
wannabe
Posty: 203
Rejestracja: 06 paź 2005, 23:06

#11

#11 Post autor: FrozenShadoow »

balam pisze:
FrozenShadoow pisze:Packet Loss i tu przykład np G.711 potrzebuje duże pasmo ale często wysyła ruch RTP wiec jak nastąpi utrata pakietu to nie jest to az tak straszne np jak w wypadku G.729.
Jaka jest roznica utraty pakietu G711 a G729 wedlug Ciebie, bo ja szczerze nie widze za duzej?


Utrata mniejszego pakietu danych w tym wypadku strumienia RTP jest mniej widoczna dla użytkownika, a wiec lepsza jakość......

G.711 - ok. 99 kbit/s (10ms/pakiet)
G.729 - ok. 20 kbit/s (30ms/pakiet)
Nie wyrażaj małej rzeczy w wielu słowach, lecz wielką w niewielu

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#12

#12 Post autor: Seba »

Przy roznych wielkosciach Voice Payload Size (ms), to rzeczywiscie strata pakietu moze byc roznie "odczuwalna", ale przy zalozeniu, ze Voice Payload Size jest taki sam (powiedzmy 20ms), to przenoszona informacja w pojedynczym pakiecie jest taka sama bez wzgledu na zastosowany kodek.
Domyslnie, jesli nic sie jakos ostatnio nie zmienilo, to Voice Payload Size jest ustawiony w Cisco na 20ms bez wzgledu na kodek.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

Awatar użytkownika
FrozenShadoow
wannabe
wannabe
Posty: 203
Rejestracja: 06 paź 2005, 23:06

#13

#13 Post autor: FrozenShadoow »

Seba pisze:Przy roznych wielkosciach Voice Payload Size (ms), to rzeczywiscie strata pakietu moze byc roznie "odczuwalna", ale przy zalozeniu, ze Voice Payload Size jest taki sam (powiedzmy 20ms), to przenoszona informacja w pojedynczym pakiecie jest taka sama bez wzgledu na zastosowany kodek.
Domyslnie, jesli nic sie jakos ostatnio nie zmienilo, to Voice Payload Size jest ustawiony w Cisco na 20ms bez wzgledu na kodek.
Zgodze sie z Toba ale akurat moim srodwiskiem jest Hipatch4000 a tam możliwosci wyboru kodeków i VPS jest pełny i stąd te moje wywody :)
Nie wyrażaj małej rzeczy w wielu słowach, lecz wielką w niewielu

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#14

#14 Post autor: Seba »

No, ale na Cisco tez mozesz ustawiac i kodeki, i VPS ;)
Bardziej chodzilo mi o to, ze ciezko porownywac wplyw straty pakietu(ow) dla roznych kodekow, przy roznych parametrach, m.in. takich jak VPS. Jakies elementy musza byc takie same, aby dalo sie cokolwiek porownac.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

Awatar użytkownika
balam
wannabe
wannabe
Posty: 977
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#15

#15 Post autor: balam »

Mozna tylko dodac ze telefony Cisco do 30ms moga odtworzyc dzwiek po stracie jesli dobrze pamietam.
Somewhere back in time.

ODPOWIEDZ