G722 als einziger Codec?

sonyKatze

IPPF-Promi
Mitglied seit
6 Aug 2009
Beiträge
3,542
Punkte für Reaktionen
328
Punkte
83
… 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

Neuer User
Mitglied seit
9 Nov 2017
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
@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

IPPF-Promi
Mitglied seit
6 Aug 2009
Beiträge
3,542
Punkte für Reaktionen
328
Punkte
83
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

Neuer User
Mitglied seit
9 Nov 2017
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
@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

IPPF-Promi
Mitglied seit
6 Aug 2009
Beiträge
3,542
Punkte für Reaktionen
328
Punkte
83
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

Neuer User
Mitglied seit
9 Nov 2017
Beiträge
12
Punkte für Reaktionen
1
Punkte
3
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

Mitglied
Mitglied seit
13 Jan 2006
Beiträge
592
Punkte für Reaktionen
57
Punkte
28
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?
 
3CX

Neueste Beiträge

Statistik des Forums

Themen
239,170
Beiträge
2,123,303
Mitglieder
362,350
Neuestes Mitglied
Feeds

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via

IPPF im Überblick

Neueste Beiträge

Website-Sponsoren


Kontaktieren Sie uns bei Interesse