Sprachverständlichkeit Null

[pingping]

Hallo,

@ Kudde:

wer nimmt denn auch die g.726? und volumen gibt es doch auch preiswert.

Jeder der das Volumen gar nicht bekommen kann, und kein VoIP-Endgerät hat, an dem die Codecs explizit ausgewählt werden können oder er nicht in der Lage ist dieses entsprechend zu modden


@starbright

Wie kann man denn den ausgehandelten Codectyp beeinflussen?

Das kommt ganz auf das verwendete Endgerät, den VoIP-Provider (bzw. dessen Plattform) und die verfügbare Bandbreite an. Bei der FritzBox kannst du "Immer komprimieren" auswählen. Dann bietet die FritzBox bei gehenden Gesprächen im SDP der INVITE die komprimierenden Codecs in folgender Reihenfolge an:
- G.726-32
- G.726-40
- G.726-24
- iLBC
Je nachdem welche Codecs von der Plattform des VoIP-Providers unterstützt werden antwortet diese mit dem/den entsprechenden Codecs.
Bei manchen Endgeräten ist es möglich die angebotenen Codecs selbst festzulegen (ich meine dass es da auch eine Mod für FritzBoxen gibt/gegeben hat).

Antwort von Sipgate: .....

Die habe ich heute auch bekommen.


Gruss pingping

 

[chillen]

Hiho,

habe heute Mittag auch mal eine Anfrage an den sipgate Support gestellt und dazu folgende Antwort erhalten:

Sehr geehrter Herr XY,

vielen Dank für Ihre Anfrage.

Es gibt für den Codec G.726 zwei Möglichkeiten der Paketierung - also der Art, wie die Sprachdaten in die RTP-Pakete "gepackt" werden. Eine geschieht nach RfC3551, die andere nach AAL2-Standard. Beide haben gemeinsam, dass jeweils zwei 4-Bit-Audio-Schnipsel in
ein Byte gepackt wird. Unterschiedlich ist nur die Reihenfolge: 2-1 bei RfC3551, 1-2 bei AAL2.

Bei einem Gesprächsaufbau übermittelt das Endgerät unserem Server die Codecs, die es versteht. Dabei steht das Codewort G726-32 für die Paketierung nach RfC3551, das Codewort AAL2-G726-32 für Paketierung nach AAL2. Anscheinend ist es jedoch verbreitet, dass dieser Codec nicht korrekt implementiert wird bzw. die Zuordnung zwischen Paketierung und passendem Codewort nicht korrekt gesetzt wird. Verschiedene Endgeräte (AVM-Geräte, Grandstream-Geräte) geben beim Gesprächsaufbau nun G726-32 an, senden dann aber RTP-Pakete, die nach AAL2-Standard gefüllt worden sind. Dies hat dann zur Folge, dass es extrem verzerrt klingt. Dass überhaupt noch etwas zu
verstehen ist, liegt daran, dass jeweils immer nur zwei Schnipsel "vertauscht" sind, die grobe Reihenfolge der Audiodaten aber korrekt bleibt.

Die Lösung für das Problem wäre, dass die Hersteller Ihre Codecs korrekt beim Gesprächsaufbau deklarieren. Leider ist dies derzeit nur bei wenigen Geräten der Fall, bspw. bei Siemens-Geräten. Deshalb - vor allem aufgrund der großen Verbreitung von AVM-Geräten - haben wir uns dazu entschlossen, unsere Gateways anzuweisen, bei
Aushandlung des "Standard-G.726-Codecs" immer anzunehmen, dass die
falsche Paketierung gewünscht ist. Somit sollten die meisten Geräte
G.726 wieder in vernünftiger Audioqualität verwenden können,
standardkonforme Geräte werden nun jedoch die Qualitätsprobleme zu spüren bekommen.


Mit freundlichen Grüßen

XYZ


Für mich klingt das ganz stark danach, das sipgate bisher was falsch gemacht hat und dies korrigiert hat und nun alle anderen (Hersteller, andere VoIP Anbieter) die das noch nicht korrigiert haben nun auf dem Schlauch stehen. Ich werde dies auch direkt an AVM mailen, damit auch die Entwickler dort Bescheid wissen.



Es grüßt
chillen

 

[SmilingBoy]

Wow - eine hochkompetente Antwort! Nicht schlecht.

 

[starbright]

AVM hat mir ne Anleitung geschickt, wie man man imWireshark-Protokoll mitschneiden kann.
Ich kann das zwar nicht recht deuten, vielleicht kann mir jemand den entscheidenden Unterschied nennen, bzw in welcher Zeile tatsächlich der Codec ausgewählt wird.
In m= wird wohl die Auswahl angegeben, aber welcher wird gewählt?
BTW - wie groß sind da die Datenraten?

Ohne Kompression kommt:

v=0
o=user yyyyyyy yyyyyyy IN IP4 xx.xx.xxx.xx
s=session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 7078 RTP/AVP 8 0 97 111 112 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:111 G726-32/8000
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=sendrecv
a=rtcp:7079

Mit Kompression kommt:

v=0
o=user zzzzzzz zzzzzzz IN IP4 xx.xx.xxx.xx
s=session
c=IN IP4 xx.xx.xxx.xx
t=0 0
m=audio 7078 RTP/AVP 111 97 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:111 G726-32/8000
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=sendrecv
a=rtcp:7079

Aber, offensichtlich hat Sipgate gehandelt - es geht nämlich wieder.
Bleibt dahingestellt wer nun wirklich den schwarzen Peter hat.
Ich bin erst mal froh.

Steffen

 

[Digga]

In der Zeile, die mit m=audio anfängt, wird die Priorität der Codecs festgelegt. In Deinem oberen Beispiel also soll zuerst G711 (unkomprimiert) in europäischer und amerikanischer Weise verwendet werden, danach dann ILBC und dann G726. Beim unteren Beispiel wird zuerst G726 und dann ILBC, danach erst G711 gewünscht.