Hallo.
Wir haben seit Wochen das Problem, dass wir Anrufer oft nicht hören können. Bisher hat kein Tipp, wie z.B. Ports freigeben, geholfen.
Heute mache ich Home-Office und testete eben über Festnetz und mobil Anrufe in die Firma, nachdem ich wieder Meldungen von Kollegen erhielt.
Ergebnis: Verständigung in alle Richtungen einwandfrei. Ich bin bei der Telekom sowohl fest als auch mobil.
Mein Kollege testete es sofort danach mobil und hörte nichts. Er ist bei Vodafone.
Wir selbst haben einen Glasfaseranschluss bei einem kleineren Anbieter. SIP-Trunk von Easybell.
Ist es denkbar, dass die Probleme nur bei bestimmten Providern auftreten? Und wenn ja, woran liegt es und wie kann man es beheben?
Ich lehne mich mal aus dem Fenster und sage eher unwahrscheinlich. Vielmehr könnten deine RTP-Ports nicht mit der Config der pascom übereinstimmen oder die Ports werden anderweitig genutzt (letzteres sollte die Firewall aber normalerweise hinbekommen).
Wir haben mittlerweile weitere Tests durchgeführt und sind zu dem Ergebnis gekommen, dass Anrufe aus dem Telekom-Netz sowohl fest als auch mobil (T-Mobile und Congstar) störungsfrei verlaufen. Anrufer z.B. aus dem Netz von Vodafone sind nicht zu hören und hören auch uns nicht. Bei Rückrufen gibt es keine Probleme.
Wieso sollten die RTP-Ports nur bei Nicht-Telekom-Providern Probleme machen? Zumal sie alle freigegeben sind und auch in der PASCOM eingetragen.
Die Probleme sind aktuell jederzeit reproduzierbar.
Die Verbindung wird von der pascom doch nur zum Easybell-Server aufgebaut, ob Telekom, Vodafone oder andere Anbieter.
Evtl. kann Easybell dazu mehr sagen? - Aktuelle Störungen sind keine angezeigt.
Raustelefonieren klappt ja auch problemlos. Nur eingehende Anrufe machen Probleme, und das nahezu seit Inbetriebnahme der PASCOM alle paar Tage.
Ich habe ein Ticket bei Easybell geöffnet.
Ursache könnte auch Fragmentierung von zu großen Paketen sein, dann sollte sich der Anruf jedoch gar nicht aufbauen. Man könnte mal transport=tcp diesbezüglich versuchen.
Wenn der Anruf aber aufgebaut wird halte ich auch Codec am wahrscheinlichsten.
Vielen Dank @Linuxuser und @Steve.
Das mit dem Eintrag hat zumindest für Vodafone das Problem gelöst, für den Rest warte ich auf Feedback. Was hat es mit G722 auf sich? Wird der standardmäßig nicht unterstützt? Oder habe ich ihn jetzt deaktiviert?
Standardmäßig ist es (noch) aktiv. allow=!all,alaw heißt erlaube nichts außer alaw. An sich sollte es einfach kein g722 aushandeln wenn es beide Seiten nicht unterstützen, das scheint aber nicht in allen Fällen/Konstellationen vernünftig zu klappen. Deswegen nehmen wir vermutlich bald g722 aus dem Standard erstmal wieder raus, so das man es bewusst aktivieren muss.
Danke @Steve. Damit habe ich das Problem nach 2 Monaten endlich lösen können. Es liegt also eine Art Handshake-Problem zwischen Endstellen mit dem G.722 Codec vor.
Hallo in Runde,
wir haben wohl das selbe Problem , wo genau kann ich die Einstellungen vornehmen?
ich finde dies " Account Optionen im Amt " leider nicht.
Hallo @freddi0808,
du musst dazu das Template unter “Vorlage wechseln” auf “Generisches SIP-Amt” umstellen. Allerdings wird das bei einem Update wieder auf peoplefone gewechselt.
Hallo würde das bei einer Instanz auch gerne testen, wo wir ähnliche Probleme haben. Ist das mittlerweile im Template bereits immer geändert, wie weiter oben angekündigt.
Alternativ tue ich mich etwas schwer die entsprechende Stelle zu finden, zumal oben auch von P19 gesprochen wird, ich nehme an es soll eine Angabe der Position sein, aber ich habe unter Optionen nach der Umschaltung vom Template auf Generisch unter Optionen keinerlei Einträge stehen.
Dort einfach nur : endpoint/allow=!all,alaw eintragen ?
Brachte bei mir keine Verbesserung oder Änderung.
Was ich festgestellt hab ist das die Probleme hauptsächlich bei Kollegen mit DSL-Lite IPV6 Anschlüssen auftritt.
nein es muss nicht in eine Zeile geschrieben werden, dein Zweizeiler bewirkt genau das gleiche. Ich finde es nur schöner und es gab in der Vergangenheit für kurze Zeit mal ein Problem, bei der irgendein Interpeter die Zeile “disallow=all” zuletzt verbeitet hatte was dazu führte, dass kein Codec angeboten wurde. Das Problem gibt es aber nicht mehr.
Ich vermute also mal, dass deine Probleme nicht am Codec liegen, falls diese noch vorhanden sind (du hattest dann ja schon vorher auf alaw eingeschränkt)
