G722 als einziger Codec?

[nvindice]

Hallo zusammen, wir haben Probleme mit unserer Yeastar S20 im Telekom-Netz - weitergeleitete Gespräche zwischen 2 externen T-Mobile-Geräten sind einseitig stumm, scheinbar da der Codec nicht ordentlich ausgehandelt wird. Das Problem tritt nicht auf, wenn wir der Yeastar S20 nur einen einzigen Codec erlauben.

Meine Frage: Kann man problemlos in Deutschland G722 als einzigen Codec anbieten? Oder muss ich auf aLaw zurückgreifen? Gibt es noch aktive Anschlüsse / Geräte / Provider etc, die G722 nicht unterstützen?

 

[Joe_57]

Das hat doch nur nebensächlich mit den Anbietern zu tun.
Viel wichtiger ist es doch, dass dann auch alle beteiligten Endgeräte den G.722-Standard untersützen müssten, da sonst eine Rückschaltung auf G.711 unvermeidbar ist.

 

[koyaanisqatsi]

Moinsen

Gibt es noch aktive Anschlüsse / Geräte / Provider etc, die G722 nicht unterstützen?

Ja.
Beispiel Fax, wird mit G.711 ( aLAW, uLAW, PCMA, PCMU ) übertragen.
Beispiel Anrufbeantworter, ich kenn keinen der G.722 unterstützt, so dass transkodiert werden muss, was den Sound nicht besser macht.
Also immer die Kompatibelsten (G.711) mit in die Prioritätsliste, wenn auch nicht an erster Stelle, in die Konfig nehmen.

 

[nvindice]

Beispiel Fax, wird mit G.711 ( aLAW, uLAW, PCMA, PCMU ) übertragen.

Fax ist egal, das ist ein anderer Trunk, den kann ich auf G711 laufen lassen.

Beispiel Anrufbeantworter, ich kenn keinen der G.722 unterstützt, so dass transkodiert werden muss, was den Sound nicht besser macht.

Was passiert denn in der Praxis, wenn ich auf einen AB spreche, der G722 nicht unterstützt? Kodiert der dann automatisch um oder gibt es einfach gar keinen Stream?

Also immer die Kompatibelsten (G.711) mit in die Prioritätsliste, wenn auch nicht an erster Stelle, in die Konfig nehmen.

Genau das kann ich leider nicht - sobald ich G711 und G722 gemeinsam in der Liste habe, kann ich keine Anrufe Mobil -> TK-Anlage -> Mobil mehr weiterleiten.

 

[sunnyman]

Meine Frage: Kann man problemlos in Deutschland G722 als einzigen Codec anbieten?

Definitiv Nein. Es gibt SIP-Trunk-Provider die nur G.711 durchlassen bzw. insbesondere keine transparente Codec-Aushandlung.
Und selbst wenn es die gäbe, ein S0- oder analoges Endgerät hinter der Fritzbox kann auch nur G.711.

Davon ab sind auch in Deutschland immer noch ISDN-Interconnects zwischen den Provdern aktiv. ISDN-Amtsanschlüsse gibts auch immer noch. Obwohl ISDN sehr wohl G.722 könnte, wird davon aber nie Gebrauch gemacht.

Mit anderen Worten: Mit dieser "Lösung" schießt man sich selbst ins Knie.

Aber ihr beseitigt damit bestenfalls das Auftreten eines Symptoms und nicht die Ursache.

Glücklicherweise muss man aber auch nicht "vermuten" sondern kann das hier gescheit tracen.

"Einseitig stumm" klingt klassisch nach NAT-Problematik.

Also: Wireshark anschmeißen und prüfen, welche Codecs wann ausgehandelt werden und wann wo welche Streams landen. Da die Yeastar vermutlich nicht direkt am Netz hängt, auch am Router tracen und gucken ob der Stream da zwar ankommt aber nicht durchgeroutet wird.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Was passiert denn in der Praxis, wenn ich auf einen AB spreche, der G722 nicht unterstützt? Kodiert der dann automatisch um oder gibt es einfach gar keinen Stream?

Das lässt sich nicht vorhersehen. Der Codec wird zwischen den beiden SIP-Endpunkten ausgehandelt und du kannst nie wissen, wie sich die Gegenstelle verhält. Wenn die Schnittmenge verfügbarer Codecs leer ist, kommt das Gespräch nicht zustande, so einfach ist das.

 

[koyaanisqatsi]

Genau das kann ich leider nicht - sobald ich G711 und G722 gemeinsam in der Liste habe, kann ich keine Anrufe Mobil -> TK-Anlage -> Mobil mehr weiterleiten.

Wäre für mich ein Umtauschgrund: Fehlkauf

 

[nvindice]

Danke für die vielen schnellen Rückmeldungen.

Glücklicherweise muss man aber auch nicht "vermuten" sondern kann das hier gescheit tracen.

"Einseitig stumm" klingt klassisch nach NAT-Problematik.

NAT haben wir auch lange im Verdacht gehabt, aber alle Pakete kommen in der TK an und werden laut PCAP-Trace auch rausgegeben. Und mit erzwungenem G711 oder G722 funktioniert ja auch alles zuverlässig.

Bin offen für alle Vorschläge oder Hinweise, wie ich dem Problem auf die Spur kommen kann.

 

[sunnyman]

NAT haben wir auch lange im Verdacht gehabt, aber alle Pakete kommen in der TK an und werden laut PCAP-Trace auch rausgegeben. Und mit erzwungenem G711 oder G722 funktioniert ja auch alles zuverlässig.

Ich würde mir dennoch mal genau angucken, wie die SDP-Bodys aussehen, insbesondere ob die Yeastar ihre RFC1918-IP reinsetzt oder die WAN-IP.

Bin offen für alle Vorschläge oder Hinweise, wie ich dem Problem auf die Spur kommen kann.

Ob wirklich "der Codec nicht ordentlich ausgehandelt wird" lässt sich ja ebenfalls per Trace feststellen. Sollte dem so sein, wäre der Support von Yealink die nächste Anlaufstelle.

 

[nvindice]

Zum Thema Codecs: "nicht richtig ausgehandelt" ist vielleicht eine falsche Formulierung. Fakt ist: wenn ich G722 und G711 beide in der Liste habe, läuft der erste Anruf (Mobil1 -> TK) auf G722 und der zweite Anruf (TK -> Mobil2) auf G711. Beide Anrufe für sich genommen funktionieren, aber bei einem Transfer (bzw. automatische Rufweiterleitung, Transfer ist aber analog) hört Mobil1 nichts. Wenn ich einen von beiden Codes rausnehme, verwenden beide Anrufe den gleichen Codec und alles funktioniert.

Ehrlicherweise muss ich zugeben, kein SIP-Profi zu sein. Folgende SDP Pakete des zweiten Rufaufbaus sehen für mich korrekt aus:

INVITE (TK -> Mobile2)

Spoiler

<7N¥hôµIö¶+E`D{ÿ@@¹
Ù ÄÄ0E(INVITE sip:0151********@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 79.215.45.***:5060;rport;branch=z9hG4bKPjb54bf1f7-f405-4ebe-b484-2e3e562ee3ce
From: "+492682******" <sip:+492682******@tel.t-online.de>;tag=68ede7fa-ebf2-4767-a4c9-0d3e5ea0aeea
To: <sip:0151********@tel.t-online.de>
Contact: <sip:+492682******@79.215.45.***:5060>
Call-ID: 606bfb32-9304-4508-a953-d257da15d822
CSeq: 5866 INVITE
Allow: OPTIONS, NOTIFY, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, REFER, MESSAGE, REGISTER
Supported: timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Diversion: "+492682******" <sip:+492682******@tel.t-online.de>
Max-Forwards: 70
User-Agent: Yeastar S20-30.14.0.127
Proxy-Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="4160C436FE473761000000001608B971", uri="sip:0151********@tel.t-online.de", response="6b2a628078450ec4c1e0fe4fc3b16b99", algorithm=MD5, cnonce="4b307b60-9f0c-4f24-97a4-179ea89703a9", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length: 259

v=0
o=- 1583299539 1583299539 IN IP4 10.1.0.15
s=Asterisk
c=IN IP4 79.215.45.***
t=0 0
m=audio 11658 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

180 Ringing (Mobile2 -> TK)

Spoiler

ôµIö¶+<7N¥hE¸îÑ@7mýÙ
ÄÄÚénSIP/2.0 180 Ringing
Via: SIP/2.0/UDP 79.215.45.***:5060;received=79.215.45.***;rport=5060;branch=z9hG4bKPjb54bf1f7-f405-4ebe-b484-2e3e562ee3ce
To: <sip:0151********@tel.t-online.de>;tag=h7g4Esbg_p65540t1631012851m778610c23281s1_3316091941-327846478
From: "+492682******" <sip:+492682******@tel.t-online.de>;tag=68ede7fa-ebf2-4767-a4c9-0d3e5ea0aeea
Call-ID: 606bfb32-9304-4508-a953-d257da15d822
CSeq: 5866 INVITE
Contact: <sip:[email protected];transport=udp>
Record-Route: <sip:217.0.28.160;transport=udp;lr>
P-Early-Media: sendrecv, gated
Content-Type: application/sdp
Content-Length: 275
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=ccs-6-301-12 6298121884243629 476046678 IN IP4 217.0.28.160
s=-
c=IN IP4 217.0.6.181
t=0 0
m=audio 14292 RTP/AVP 8 101
a=maxptime:30
a=ptime:20
a=msi:[email protected]
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

200 OK (Mobile2 -> TK)

Spoiler

ôµIö¶+<7N¥hE¸uÑ@7luÙ
ÄÄa´SIP/2.0 200 OK
Via: SIP/2.0/UDP 79.215.45.***:5060;received=79.215.45.***;rport=5060;branch=z9hG4bKPjb54bf1f7-f405-4ebe-b484-2e3e562ee3ce
To: <sip:0151********@tel.t-online.de>;tag=h7g4Esbg_p65540t1631012851m778610c23281s1_3316091941-327846478
From: "+492682******" <sip:+492682******@tel.t-online.de>;tag=68ede7fa-ebf2-4767-a4c9-0d3e5ea0aeea
Call-ID: 606bfb32-9304-4508-a953-d257da15d822
CSeq: 5866 INVITE
Contact: <sip:[email protected];transport=udp>;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;+g.3gpp.mid-call;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.28.160;transport=udp;lr>
Require: timer
Session-Expires: 1800;refresher=uas
Supported: norefersub
Supported: histinfo
Supported: 100rel
Supported: timer
Content-Type: application/sdp
Content-Length: 275
Session-ID: bd2a5a186a3f59c6bb9c9b782bfbdccb
Authentication-Info: qop=auth,rspauth="65f3b948feb4d864434e550289fd92ff",cnonce="4b307b60-9f0c-4f24-97a4-179ea89703a9",nc=00000001
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=ccs-6-301-12 6298121884243629 476046678 IN IP4 217.0.28.160
s=-
c=IN IP4 217.0.6.181
t=0 0
m=audio 14292 RTP/AVP 8 101
a=maxptime:30
a=ptime:20
a=msi:[email protected]
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

Die interne IP der TK (10.1.0.15) kommt nur einmal beim INVITE (owner address) vor - müsste das hier auch die Public IP sein?

 

[koyaanisqatsi]

Mich wundert erstmal...

ôµIö¶+<7N¥hE¸uÑ@7luÙ
ÄÄa´SIP/2.0 200 OK

...wo/wieso/warum ist das so zerhackt?

Das erste INVITE kommt noch zum zum Verhandeln vorbei (9=G722, 8=PCMA(alaw)).
...und 9=G722 ist beim RINGING schon nicht mehr dabei.
Ich vermute mal ganz stark, dass in der Peerconfig vom Mobile nur alaw erlaubt ist (allow=!all,alaw).
Im [general] Teil der (sip/pjsip?).conf: allow=!all,g722,alaw ?
Mich persönlich würde auch interessieren, was das hier...
a=msi:[email protected]
( Komischer Benutzername at nichterreichbare IP als Codec? )
...ist. Sprachqualitätskontrolle?

Mit jeweils allow=!all,g722,alaw,ulaw für [general] und in einer [Peer/User] Konfiguration bekommt der Peer/User auch immer was zum Verhandeln...
Beispiel: Einfach nur mal bis zum Timeout "klingeln" lassen

[Sep  8 11:55:52] <--- SIP read from UDP:192.168.188.1:5060 --->
[Sep  8 11:55:52] SIP/2.0 180 Ringing
[Sep  8 11:55:52] Via: SIP/2.0/UDP 192.168.188.9:5060;branch=<hash>
[Sep  8 11:55:52] From: "FRITZ!Fax Gateway" <sip:[email protected]>;tag=<hash>
[Sep  8 11:55:52] To: <sip:[email protected];uniq=<hash>>;tag=<hash>                                                                                     
[Sep  8 11:55:52] Call-ID: <hash>@192.168.188.9:5060
[Sep  8 11:55:52] CSeq: 102 INVITE
[Sep  8 11:55:52] Contact: <sip:[email protected];uniq=<hash>>
[Sep  8 11:55:52] User-Agent: AVM FRITZ!Box 7590 (UI) 154.07.28 (Jul 8 2021)
[Sep  8 11:55:52] Content-Length: 0
[Sep  8 11:55:52]
[Sep  8 11:55:52] <------------->
[Sep  8 11:55:52] --- (9 headers 0 lines) ---
[Sep  8 11:55:52] sip_route_dump: route/path hop: <sip:[email protected];uniq=<hash>>                                                                              
[Sep  8 11:55:52]     -- SIP/1000-00000055 is ringing
[Sep  8 11:56:52] Audio is at 50016
[Sep  8 11:56:52] Adding codec g722 to SDP
[Sep  8 11:56:52] Adding codec alaw to SDP
[Sep  8 11:56:52] Adding codec ulaw to SDP
[Sep  8 11:56:52] Adding non-codec 0x1 (telephone-event) to SDP
[Sep  8 11:56:52]
[Sep  8 11:56:52] <--- Transmitting (no NAT) to 192.168.188.1:5060 --->
[Sep  8 11:56:52] SIP/2.0 183 Session Progress
[Sep  8 11:56:52] Via: SIP/2.0/UDP 192.168.188.1:5060;branch=<hash>;received=192.168.188.1;rport=5060
[Sep  8 11:56:52] From: <sip:[email protected]>;tag=<hash>
[Sep  8 11:56:52] To: <sip:[email protected]>;tag=<hash>
[Sep  8 11:56:52] Call-ID: <hash>@192.168.188.1
[Sep  8 11:56:52] CSeq: 32 INVITE
[Sep  8 11:56:52] Server: PiBX
[Sep  8 11:56:52] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
[Sep  8 11:56:52] Supported: replaces, timer
[Sep  8 11:56:52] Contact: <sip:[email protected]:5060>
[Sep  8 11:56:52] Content-Type: application/sdp
[Sep  8 11:56:52] Content-Length: 286
[Sep  8 11:56:52]
[Sep  8 11:56:52] v=0
[Sep  8 11:56:52] o=root 1781832395 1781832396 IN IP4 192.168.188.9
[Sep  8 11:56:52] s=PiBX
[Sep  8 11:56:52] c=IN IP4 192.168.188.9
[Sep  8 11:56:52] t=0 0
[Sep  8 11:56:52] m=audio 50016 RTP/AVP 9 8 0 101
[Sep  8 11:56:52] a=rtpmap:9 G722/8000
[Sep  8 11:56:52] a=rtpmap:8 PCMA/8000
[Sep  8 11:56:52] a=rtpmap:0 PCMU/8000
[Sep  8 11:56:52] a=rtpmap:101 telephone-event/8000
[Sep  8 11:56:52] a=fmtp:101 0-16
[Sep  8 11:56:52] a=ptime:30
[Sep  8 11:56:52] a=maxptime:150
[Sep  8 11:56:52] a=sendrecv
[Sep  8 11:56:52]
[Sep  8 11:56:52] <------------>

 

[nvindice]

Mich wundert erstmal...

ôµIö¶+<7N¥hE¸uÑ@7luÙ
ÄÄa´SIP/2.0 200 OK

...wo/wieso/warum ist das so zerhackt?

Sorry, ist der UDP Header, hätte ich wegschneiden können.

Das erste INVITE kommt noch zum zum Verhandeln vorbei (9=G722, 8=PCMA(alaw)).
...und 9=G722 ist beim RINGING schon nicht mehr dabei.
Ich vermute mal ganz stark, dass in der Peerconfig vom Mobile nur alaw erlaubt ist (allow=!all,alaw).
Im [general] Teil der (sip/pjsip?).conf: allow=!all,g722,alaw ?
Mich persönlich würde auch interessieren, was das hier...
a=msi:[email protected]
( Komischer Benutzername at nichterreichbare IP als Codec? )
...ist. Sprachqualitätskontrolle?

Mit jeweils allow=!all,g722,alaw,ulaw für [general] und in einer [Peer/User] Konfiguration bekommt der Peer/User auch immer was zum Verhandeln...

Ja, aber diese Konfiguration liegt doch beim Provider der Mobiles (hier: Telekom) bzw. beim Endgerät, oder? Da habe ich ja keinen Einfluss drauf.

 

[sonyKatze]

Kann man problemlos in Deutschland G722 als einzigen Codec anbieten? Oder muss ich auf aLaw zurückgreifen?

Gute Frage, wobei die Frage etwas anders herum ist: Mit Telekom Deutschland bist Du in einem IMS. Das hat zur Folge, dass die Gegenseite bei Dir direkt mit ihren Audio-Codecs aufschlägt. Die Frage ist, ob die Telekom Deutschland hier bei eingehenden Anrufen immer G.722 ergänzt. Und die Frage ist, ob die Telekom Deutschland abgehend erkennt, wenn Du nur G.722 bietest – und das dann transkodiert.

bei einem Transfer (bzw. automatische Rufweiterleitung, Transfer ist aber analog

Wie löst Du diesen Transfer genau aus, SIP-Status 302 oder durch einen zweiten Anruf? Klingt so, als würde der Yeastar S20 einen zweiten Anruf starten, dann aber nicht intern „transkodieren“. Das würde ich an Deiner Stelle in der Yeastar-Community fragen.

 

[wari1957]

@nvindice
Nur G.722 ist eine schlechte Wahl.
Ruf mal die Zeitansage 040428990 an, die kann nur G.711a.
Ich an deiner Stelle würde nur G.711a verwenden.
Hatte ich noch nie Probleme mit.

 

[nvindice]

Ruf mal die Zeitansage 040428990 an, die kann nur G.711a.
Ich an deiner Stelle würde nur G.711a verwenden.
Hatte ich noch nie Probleme mit.

Coole Idee, danke. Funktioniert nicht (488 Not Acceptable Here). Damit transkodiert die Telekom offenbar nicht intern. G711a ist halt qualitativ deutlich unter G722...

Wie löst Du diesen Transfer genau aus, SIP-Status 302 oder durch einen zweiten Anruf? Klingt so, als würde der Yeastar S20 einen zweiten Anruf starten, dann aber nicht intern „transkodieren“. Das würde ich an Deiner Stelle in der Yeastar-Community fragen.

Durch einen zweiten Anruf. Würde das viel lieber mit 302 machen (alleine schon um die Leitungen frei zu haben), aber ich finde dafür keine Einstellungsmöglichkeit in der Yeastar TK (allerdings ein Feature Request von 2019 )

Mittlerweile habe ich das Problem auch mit dem Yeastar Support durchgekaspert. Ich zitiere:

It is a known issue, there is a bug on yeastar software, which may improved on the future version

Schade! Bis hierher hatte ich mit den Yeastar S-Modellen nur gute Erfahrungen gemacht.

 

[wari1957]

G711a ist halt qualitativ deutlich unter G722.

MOS 4,4 zu MOS 4,5.
Fast kein Unterschied.

SIP302 wird nur beim SIP-Trunk unterstützt.

 

[koyaanisqatsi]

Ich möchte noch anmerken, dass G.722 HD einen Riesenunterschied ausmacht, wenn Mikrofon, Hörerlautsprecher und Freisprechlautsprecher auch für diese Qualität gefertigt sind.
Bei "Quäken", die zwar den Codec, nicht aber die Hardware dafür mitbringen, bleibt es auch: "quäkig".
Viele Leute erwarten anscheinend viel zu viel, gerade bei Smartfons und Tablets und Klapprechner ohne "Harman Kardon" Hardware.
Selbst für SNOMs musste mal ein "klarVoice" Hörer zusätzlich beschafft werden, für das...
"Als wenn der Gesprächspartner neben einen sitzt."
...Gefühl.

 

[sonyKatze]

MOS 4,4 zu MOS 4,5

G.722 ist HD-Voice, also ein anderer Frequenzumfang. Daher sind G.711 und G.722 nicht durch die selbe MOS-Skala vergleichbar. Man muss sich eine neue Skala einfallen lassen. Was die Quelle dieser Werte genau gemacht hat, bleibt daher unklar. Vermutlich hat die Quelle, worauf Du Dich beziehst, G.722 ohne HD-Mikrofon bzw. HD-Lautsprecher genutzt … oder einfach nur ohne Erläuterung das woanders abgeschrieben.

mit dem Yeastar Support durchgekaspert

Hast Du das auch mal öffentlich in deren Community besprochen? Yeastar basiert auf Digium Asterisk. Und Transkodieren ist einer der Stärken an Asterisk. Das Szenario geht schon seit über einem Jahrzehnt sauber. Entweder hat Yeastar ein Modul nicht eingebaut oder irgendwas ist ver-konfiguriert. Vielleicht das wer in deren Community schon gelöst. Auf jeden Fall sollest Du das in deren Community öffentlich machen. Nicht das man Dich einfach abgewimmelt hat … „Fall zu kompliziert, ich erzähle dem Kunden das Märchen, das er hören will“.

 

[nvindice]

Ich möchte noch anmerken, dass G.722 HD einen Riesenunterschied ausmacht, wenn Mikrofon, Hörerlautsprecher und Freisprechlautsprecher auch für diese Qualität gefertigt sind.

Guter Hinweis, wir haben aber vernünftige Hardware im Einsatz und merken den Unterschied deutlich.

G.722 ist HD-Voice, also ein anderer Frequenzumfang. Daher sind G.711 und G.722 nicht durch die selbe MOS-Skala vergleichbar. Man muss sich eine neue Skala einfallen lassen. Was die Quelle dieser Werte genau gemacht hat, bleibt daher unklar. Vermutlich hat die Quelle, worauf Du Dich beziehst, G.722 ohne HD-Mikrofon bzw. HD-Lautsprecher genutzt … oder einfach nur ohne Erläuterung das woanders abgeschrieben.

Jep. Den Unterschied zwischen G.722 und G.711 finde ich (subjektiv) enorm. Haben das hier bei uns getestet und jeder hört sofort die deutliche Verbesserung durch G.722.

Hast Du das auch mal öffentlich in deren Community besprochen? Yeastar basiert auf Digium Asterisk. Und Transkodieren ist einer der Stärken an Asterisk. Das Szenario geht schon seit über einem Jahrzehnt sauber. Entweder hat Yeastar ein Modul nicht eingebaut oder irgendwas ist ver-konfiguriert. Vielleicht das wer in deren Community schon gelöst. Auf jeden Fall sollest Du das in deren Community öffentlich machen. Nicht das man Dich einfach abgewimmelt hat … „Fall zu kompliziert, ich erzähle dem Kunden das Märchen, das er hören will“.

Das kann natürlich auch sein, guter Hinweis. Habe mal einen Thread dafür aufgemacht, mal schauen was passiert. Die Yeastar-Community scheint nicht so wahnsinnig lebendig zu sein.

Danke für alle Hilfe!

Update 15.09.2021: Ein Yeastar-Mitarbeiter hat mir auf meinen Bug Report angekündigt, dass "bald" eine "temporäre Firmware" verfügbar sein soll, die das Problem löst. Wir bleiben gespannt!

 

[sonyKatze]

Was mich interessieren würde, was die wirkliche Ursache ist. Klingt so, als hätte Yeastar lediglich die Shared-Library codecs/codec_g722.so vergessen mitzuliefern. Hintergrund: In Asterisk kann man viele Audio-Codecs aktivieren. Fehlt aber das Transkodierungs-Modul, dann müssen beide Seiten, beide Call-Legs, denselben Audio-Codec nutzen – ansonsten hören die Gesprächspartner sich nicht. Seit Asterisk 10 erkannte Asterisk nicht, wenn das Transkodierungs-Modul fehlt. Das wurde erst letzt gefixt … die Frage ist, auf welcher Asterisk-Version Yeastar basiert und ob die den Channel-Driver chan_sip oder chan_pjsip nehmen.

 

[nvindice]

Unnötiges Vollzitat von darüber gemäß Boardregeln entfernt by stoney

Ich hab' SSH-Zugriff auf die Box, falls du irgendne Info haben willst, müsstest du mir nur sagen, wo ich sie finde. Habe absolut keine Ahnung von Asterisk.