UCM6204+GxP2170 teilweise Gesprächsaufbau bis zu 7-8sek

[TCmChristian]

Hallo,

ich habe ein Phänomen bei einem Kunden dem ich nicht Herr werden will. Habe eine Grandstream UCM6204 mit 18 Gxp2170 aufgebaut. Betrieben wird die UCM hinter einer IPfire-Firewall und verbunden mit Ubnt-POE-Switche.

Die Einstellung mit Telekom-Anlagenanschluss funktioniert soweit (Probleme mit der DNS auflösung gehabt und behoben)
Der Kunde ist eine Stadtverwaltung, sodass ich nicht ohne weiteres einen Mitschnitt des Fehlers veröffentlichen kann. Ich weiß das heißt wieder Glaskugel befragen, aber vllt. hatte jemand schon ein ähnliches Phänomen.

Zwischenzeitlich gab es Probleme mit der DTMF-Übertragung (TFS-Universal plus),sodass ich mit versch. Foren die verw. Codecs begrenzt hab auf PCMA/PCMU und zusätzlich vor Weihnachten, wegen meinem derzeitigen Problem, das
722 Codec.

Laut meinen Informationen bauen sich teilweise (nicht jedes, aber auch nicht jedes 100.) erst nach 5-7sekunden auf, d.h. der Anrufer hört nach wie vor, in der Zeit, den Klingelton, der Angerufene hat aber schon längst abgenommen. Erst nach diesen
5-7 sekunden können die Parteien miteinander sprechen. Gesprächsqualität ist Topp, wenn die Verbindung steht.


Ich hoffe jemand kann mir da noch Tipps geben an was es noch liegen könnte.

Mit freundlichen Grüßen

 

[pw2812]

Hallo @TCmChristian,

willkommen im IPPF.

Eins gleich vorneweg. Ich habe leider keinen Lösungsvorschlag für dich. Aber beim Lesen deiner Fehlerbeschreibung entsann ich mich an ein Thema hier im IPPF, welches mit einem recht ähnlichen Problem und unter einer ebenfalls ähnlichen Konfiguration auftrat. Vielleicht willst du dich dort mal "einlesen". Siehe dazu hier:

Link: https://www.ip-phone-forum.de/threads/gesprächsbeginn-manchmal-einige-sekunden-verzögert.303960/

Dort ging es um eine GS UCM 6202 und nicht um eine UCM 6204 und anstelle eines IPfire-Systems kam eine Securepoint UTM v11-Lösung zum Einsatz.

Der Fehler mit der Gesprächsverzögerung nach dem Verbindungsaufbau wird zwar etwas anders geschildert als von dir aber auch dort trat das Problem nur sporadisch auf.

Leider hat der Themenersteller (Arzt in eigener Praxis) sich nicht wieder zurückgemeldet. Es war wohl noch ein Dienstleister mit im Spiel. Evtl. hat der ja das Problem vor Ort beheben können. Mglw. bringt es ja was, wenn du in dem verlinkten Thema mal nachfragst. Wenn der Themenersteller sein Thema noch abonniert hat, erlangt er somit vielleicht Kenntnis davon und gibt eine Rückmeldung.

 

[TCmChristian]

Hi,

Danke für die Antwort. Habe den Thread gelesen, ich denke auf diesen stieß ich schon früher. Die dort beschriebenen Maßnahmen haben bei mir nicht zu Erfolg geführt.

In Absprache mit dem Kunden habe ich heut ein Capture erstellen können (Simuliert ohne "sensible" Gespräche) und habe es an Grandstream Ticket gesendet.. Ich werde hier
schreiben wenn ich was näheres weiß.

Zusätzlich hab ich einen der beiden UBNT-POE-Switche gegen einen Netgear ausgetauscht.

Für weitere Ideen bin ich weiter offen.

Danke & MfG

 

[TCmChristian]

Hi,
hat etwas länger gedauert aber ich denke das der Fehler nun behoben ist.
Zwei Mitschnitte der UCM, die den Fehlerfall darstellen sollen wurden zu Grandstream Support geschickt, es konnte aber kein Fehler festgestellt werden. Laut Diagramm wurden alle
Gespräche innerhalb spät. 2sekunden verbunden.

Nachdem ich die komplette Konfig der UCM neu eingetippt habe (kein Erfolg), habe ich angefangen die Telefone Zurückzusetzen und neu einzustellen.

Das hat vorerst auch nicht geholfen. Auffällig war bis dahin das der Fehler mit Iphones zu 100% reproduzierbar war.
Habe dann die Einstellung "Codec Negotiation Priority" von Callee auf Caller gestellt und siehe da... der Fehler ist weg... zum. jetzt beim Iphone. (Wer kauft den Mist?)

MfG