Bandbreite berechnen bei Codecs

[Stefan_B]

Hi,

ich hab eigentlich eine ganz einfache Frage..

Wie ist der mathematische Weg um die Bandbreiten bei Codecs zu berechnen?

z.B. G.711 oder G.729 ?

Weitergehend dann auch mit der Veränderung von Payload und einem anderen Header, z.B. Frame-Relay 6 Byte und cRTP 2byte?

Ich hab das nich so ganz geschnallt..

Ich habe mich bis jetzt dran festgehalten und auswendig gehabt, G.729 = 8kb/s, aber wie kommt man darauf?
Und wie gehts weiter wenn ich nun G.729 habe, dazu aber 40 Byte Payload, cRTP ohne CRC + Frame-Relay?

 

[rmh]

Hi und willkommen im Forum,

dazu gibt es bereits zahlreiche Beitrag hier im Forum (bitte die Suchfunktion verwenden) und auch eine recht gute Übersicht im Wiki.
Zur Berechnung verwende ich meistens diesen Bandwidth Calculator.

 

[Stefan_B]

Hallo rmh,

diese Beiträge habe ich schon entdeckt.

Was ich aber suche ist eine Aufschlüsselung der Formel, die dahintersteckt. Das ist leider nicht im Wiki und auch Tante Google hat mir da irgendwie nicht so richtig die Ergebnisse geliefert die ich suche..

 

[rmh]

Wiki: Codecs und Bandbreitenanforderungen

Dabei wurde für die Bandbreitenberechnung ein Ethernet-Overhead von 58 Bytes berücksichtigt (18 Bytes Ethernet Header, 20 Bytes IP-Header, 8 Bytes UDP-Header, 12 Bytes RTP-Header).

 

[Stefan_B]

Die Aufgabe ist dass ich eine gewisse Bandbreite noch zur Verfügung habe, und man möchte wissen: Wie viele G.729 calls sind möglich, wenn die Sample Payload auf 40 ms erhöht wurde, cRTP Header und Frame-Relay Header hinzukommen.
Ich weiß dass cRTP 4 bzw. 2byte ohne crc hat. und frame-relay 6,
aber wie kann ich nun errechnen welche bandbreite das pro sekunde in anspruch nimmt zusätzlich?

ich habe gelesen, dass G.729 50 pakete pro sekunde verschickt. da es normalerweise 20ms sprache überträgt in 1 paket.
Ein sample (also 10ms) haben 80 bit. da 2 samples übertragen werden komme ich direkt mit 50 * 80 * 2 = 8000
Rechne ich da jetzt einfach nochmal weitere 20ms payload + crtp header + frame-relay * 50 hinzu?

 

[gandalf94305]

Das habe ich doch im Wiki eigentlich komplett erklärt, oder? Der Link steht oben schon...

Es wird alles dazugerechnet, was an Overhead notwendig ist. Deine Rechnung stimmt so, wenn Du einen Datenstrom hast. Wenn es zwei oder mehr Datenströme gibt, können sich diese beeinflussen und es kann durch Wettbewerb um Bandbreite zu Jitter oder weiteren Latenzen kommen. Außerdem können Pakete verworfen werden.

Hat also ein G.729 zwei Samples zu 10 ms in je 80 bits, wäre der Payload 160 Bits je 20 ms, d.h. 50 Pakete je Sekunde, d.h. ein Payload von 1000 Bytes/s zu betrachten. Für jedes Paket kommen noch die Protokollheader hinzu, d.h. Frame-Relay 6-8 Bytes und cRTP (ca. 6 Bytes). Dazu kommt ggf. noch etwas Session Control über SIP.

--gandalf.

 

[woprr]

Wenn es zwei oder mehr Datenströme gibt, können sich diese beeinflussen und es kann durch Wettbewerb um Bandbreite zu Jitter oder weiteren Latenzen kommen. Außerdem können Pakete verworfen werden.

Nur wenn die Bandbreitengrenze der Leitung erreicht wird und im Netz können UDP-Pakete verloren gehen oder wer verwirft sie?

 

[Novize]

Jedes Datenpaket, dass parallel zu dem UDP-Datenstrom über die selbe Leitung transportiert wird, kann die einzelnen UDP-Datenpakete einige ms nach hinten werfen, denn es handelt sich ja immerhin noch um eine serielle Datenübertragung.
Und genau dann hat man den Jitter bzw bei vielen andauernden parallelen Datenübertragungen auch die entsprechende Latenz. VoIP-UDP-Datenpakete werden nicht per Definition bevorzugt behandelt und unterliegen den selben Maßstäben einer Leitungsausnutzung, wie andere Pakete auch. Bei einer ausschließlichen Ausnutzung der Verbindung für VoIP ist das Thema Priorisierung eh Mumpitz. Das solltest Du auch wissen.
Nebenbei: Wann ein UDP-Datenpaket verworfen wird (zu große Latenz / zu großer Jitter), ist auch nicht gerade erst definiert worden. Auch das ist ein alter Hut. Verwerfen tut sie nebenbei das Endgerät...