G722 als einziger Codec?

[sonyKatze]

… und ich nicht von Yeastar. Irgendwo im Dateiverzeichnis müsste eine codec_ulaw.so herumliegen. Dort müsste auch eine codec_g722.so sein. In einem Debian-basierten Linux liegt das unter /usr/lib/asterisk/modules. Wenn Du find und Root-Rechte hast, kannst Du auch direkt danach suchen: find / -name codec_ulaw.so.

 

[nvindice]

@sonyKatze Leider wurde bei der S-Serie der root-Zugang eingeschränkt, das Passwort für den echten root-User konnte ich im Netz leider nicht finden. Mit dem "offiziellen" support-User habe ich nicht genug Rechte, um auf die interessanten Bereiche des Dateisystems zu kommen.

 

[sonyKatze]

Aber vielleicht helfen diese Infos, dass Du den Support fragen kannst, was genau die Ursache ist. Vielleicht findet sich in der Community wer, der die Antworten weiß.

Kann nämlich sein, dass Du nur Hingehalten wirst und die Lösungen viele Jahre, vielleicht nie kommt. Wenn das Transkodierungsmodule für G.711 vorhanden ist, aber das für G.722 fehlt, war das nur Schusseligkeit. Dann hast Du gute Chance. Wenn Yeastar meint generell nicht zu transkodieren (warum auch immer, z.B. um den Prozessor nicht zu überlasten), müsstest Du wissen, ob Yeastar bereits auf Asterisk 16 LTS bzw. 18 LTS basiert. Dann hättest Du eine Chance auf baldigen Fix. Wenn Yeastar auf Asterisk 13 LTS basiert, dann müsste Yeastar dem im Issue-Report enthaltenen Patch bei sich einpflegen – manche nennen das Backporten, wobei es in dem Fall nicht stimmt, weil bereit ge-back-ported. In diesem letzteren Fall muss Yeastar von seinem Glück wissen. Denn ich glaube nicht, dass die den Issue-Report überhaupt kennen.

 

[nvindice]

@sonyKatze Passt denn diese Theorie zum One-Way-Audio? Die eine Seite hört den Gesprächspartner ja. Meinem naiven Verständnis nach müsste also eigentlich grundsätzlich transcodiert werden, oder?

Auf der S20 ist laut einem Internet-Eintrag zumindest ursprünglich Asterisk 13 LTS (vermute mal, dass die eher keine Versionssprünge über Updates verteilen?).

 

[sonyKatze]

Du hast dann tatsächlich One-Way-Audio.

Der zweite Call-Leg schickt G.711 zurück, was Asterisk einfach durchreicht. Die erste Call-Leg schickt aber G.722. Asterisk will das transkodieren, kann es aber nicht. Oder anders ausgedrückt: Der ursprüngliche Anrufer hört den entgültigen Anrufer. Letzter hört nix. Richtig? Das Ganze kommt daher, weil SIP/RTP nicht auf ein Medien-Format festgenagelt ist. Der Anrufer bietet einen Strauß an Medien-Formaten und Dein Asterisk kann während des Anrufs mit allen diesen Medien-Formaten antworten – genauer mit denen Medien-Formaten aus dem SDP-Answer des Asterisk an den ersten Anrufer. Aber der zweite Call-Leg wird auf G.711 ausgehandelt. Asterisk müsste umkodieren, weil es nur G.722 vorliegen hat. Kann das aber nicht.

Anders formuliert: Asterisk müsste ein re-INVITE an den ersten Call-Leg schicken, dass G.722 einfach Quatsch ist. Aber das kann Asterisk nicht, wüsste jedenfalls wie das geht. Mit directmedia=yes (chan_sip) bzw. direct_media=yes (chan_pjsip) könnte das vielleicht gehen. Asterisk erhält vom ersten Call-Leg G.722. Muss es transkodieren, aber es geht nicht. Vom zweiten Call-Leg kommt G.711. Das ist auf dem ersten Call-Leg erlaubt, also leitet Asterisk das durch.

keine Versionssprünge über Updates

Was meinst Du? Einfach nochmal formulieren. Für Asterisk 13 LTS ist das ebenfalls ge-fix-ed. Aber dafür müsste Yeastar den Patch aus dem Issue anwenden und kann nicht einfach die neuste Version nutzen. Wenn es denn das Issue ist. In Asterisk 16 LTS bzw. Asterisk 18 LTS ist das direkt gefixed. Das sind beide andere „Branches“.

 

[nvindice]

Wir haben eine Test-Firmware bekommen, bei der der Fehler behoben ist! Danke euch allen für die Unterstützung.

Eine andere Kleinigkeit habe ich noch (Sorry, ist etwas off topic): Bei manchen externen Warteschleifen höre ich die Music on Hold nicht. Es ist einfach still, bis ein Mitarbeiter das Gespräch übernimmt. Hat jemand eine Idee, nach welcher Einstellung ich da Ausschau halten kann? Sonst muss ich nach meinem Urlaub noch mal ein SIP Trace machen...

 

[sunnyman]

Möglicherweise auch Codec-Probleme. Die MoH muss prinzipiell auch in den entspr. Codecs vorliegen. Um welche MoH geht es denn? Ist da eine spezielle drauf oder die Asterisk Default?

 

[sonyKatze]

Bei manchen externen Warteschleifen höre ich die Music on Hold nicht. Es ist einfach still, bis ein Mitarbeiter das Gespräch übernimmt.

Würde gleich SIP tracen. Kann nämlich leider alles Unmögliche sein, siehe auch diesen Thread …