[Problem] Gesprächsbeginn manchmal einige Sekunden verzögert

bhoenscheid

Neuer User
Mitglied seit
4 Sep 2016
Beiträge
21
Punkte für Reaktionen
0
Punkte
1
Hallo! Ich betreibe im Büro drei interne Fritzbox-SIP-Konten auf einer 7490, dahinter hängt als Telefonzentrale eine Grandstream UCM6202 PXB und fünf Nebenstellen alle Grandstream GXP2170. Ich habe mich intensiv mit der Materie beschäftigt und alles gut ans Laufen bekommen. Genutzt wird "nur" eingehende und ausgehende Telefonie auf maximal gleichzeitigen zwei Leitungen sowie interne Gespräch und internes Vermitteln mit Warteschlange. Sonst kein "Schnickschnack" (also keine Weiterleitungen, Mailboxsysteme, Aufzeichungen oder Anrufbeantworter).
Der Alltagsbetrieb klappt nun reibungslos seit 2 Wochen ohne Neustart.
Es gibt nur gelegentlich mal das Problem, dass NUR bei einkommenden Gesprächen nach dem Abheben an einer Nebenstelle alles erst einmal "tot" ist, d.h. man hört das eingehende Gespräch nicht, der andere einen aber auch nicht. Nach einer relativ langen Latenz (geschätzt 1-4 Sekunden) klappt dann alles und das Gespräch kann in normaler Qualität zu Ende geführt werden. Auch auftreten tut das Phänomen manchmal beim Vermitteln eines externen Gesprächs an eine interne Nebenstelle. Erst kurz tot, dann hört man den internen Partner nach einigen Sekunden, das Gespräch kann normal vermittelt und geführt werden. Für mich hört sich das an, als würde hier die angerufene Nebenstelle aus irgendeinem "standby" erst einmal aufgeweckt.....?
Kann mir da spontan jemand einen Tipp geben? Beim googlen habe ich bisher noch nichts gefunden, das mir geholfen hat.
Super vielen Dank schon mal, wenn mir jemand helfen kann, die Anlage macht in der Konstellation nämlich sonst einen sehr soliden Eindruck.

Gruß, bhoenscheid
 
Bei "verzögerter Gesprächsbeginn" muss ich immer zuerst an HD-Telefonie aktiv ja/nein denken.

Im Zusammenspiel Fritzbox und HD-fähige DECT-Mobilteile hat das deaktivieren von HD-Voice schon oft geholfen. Du benutzt zwar hier kein DECT aber die Grandstream Geräte sind doch vermutlich auch HD-Voice fähig.

Da sich bei der Aushandlung des verwendeten Codecs immer alle beteiligten Komponenten "einig" werden müssen, betrifft das beide Gesprächspartner. Deshalb tritt dieses Problem meist auch nur gelegentlich und nur i.V.m. einigen Gegenstellen/Gesprächspartnern auf.

Hast du schon einmal testweise versucht bei der UCM und/oder den GXP den Standardcodec auf PCMA (G711a) zu setzen?
 
Danke für die Antwort! Ich habe aktuell alle Gesprächscodecs in der UCM aktiviert, die auch von der FirtzBox beherrscht werden...
Das sind konkret diese fünf: PCMA, PCMU, AAL2-G.726-32, G.722, iLBC.
Schlägst Du nun vor, vier davon zu deaktivieren und nur PCMA bestehen zu lassen?
Gruß bhoenscheid
 
Man kann in den "Audio Settings" der GXPs (und wahrscheinlich auch der UCM) die Reihenfolge der verwendbaren Codecs (Preferred vocoder) einstellen. Wenn dort an allen Stellen PCMA (=G.711a) steht und beide Seiten diesen Codec "sprechen", sollte dieser erzwungen werden. Ich denke, dass die deutschen VOIP-Provider alle G.711a unterstützen sollten.
 
bietet die höchste planetare Kompatibilität

Das klingt klasse! Planetare Kompatibilität. „May the force be with you.“ Obwohl dann wäre es ja genau genommen interplanetare Kompatibilität.

@bhoenscheid

Wenn es der tägliche "Bürobetrieb" zulässt und deine Mitarbeiter (falls vorhanden) "kooperieren", könnte man auch mal versuchen, die betroffenen Gegenstellen zu ermitteln. Du schreibst ja, dass die Verzögerung nur manchmal zu beobachten ist und eventuell zeigt sich dann, dass es sich immer nur um den/die selben Anrufer handelt. Wie bereits oben geschrieben, muss die Ursache für das Problem ja nicht zwangsläufig auf deiner Seite liegen.
 
kurze erste Rückmeldung: Eintragen NUR des PCMA sowohl bei den Telefonen als auch der UCM brachte noch nicht die Lösung, ein internes Gespräch "hing" gerade wieder einige Sekunden, bis es zustande kam...
bhoenscheid
[Edit Novize: Beiträge gemäß den Forumsregeln zusammengeführt]
Hallo!

@pw2812


Das sind unterschiedliche Gegenstellen und es tritt auch mal bei rein internen Gesprächen auf, manchmal aber auch bei Vermittlung von extern (während das Gespräch geparkt ist (Warteschleife, HOLD-Music))!
bhoenscheid
 
Zuletzt bearbeitet von einem Moderator:
Nee, das wäre zum Beispiel...
Erde <--> Mars
...und erst wenn quantenverschränkte Informationsübertragung ( QIÜ ) Gang und Gebe ist, auch in Echtzeit ( RTP :D ).
 
Zuletzt bearbeitet:
ich hatte das Problem bei internen Telefonaten wenn HD bevorzugt oder automatisch eingestellt war ... und es unterschiedliche DECT Telefone waren .... daher habe ich nun zwei Gigaset CL660 HX und dann darf man auch nur die interne Gegenstelle aus dem Fritzbox Telefonbuch wählen ....wenn man aber die Gegenstelle über **610 anruft ....dann kann es bis zu 20 Sek dauern bis das Gespräch zustande kommt ....

Lösung: Deaktivieren von HD Telefonie bei den Telefonen
 
Zuletzt bearbeitet:
@bhoenscheid

Du schreibst im Eingangsbeitrag, dass du fünf GXP2170 hinter der UCM6202 einsetzt.

Tritt das Problem bei allen GXP auf oder nur bei einigen bestimmten?

Sind die UCM und die GXPs auf dem aktuellen Firmwarestand?

Die UCM hat ja keine fünf LAN-Ports. Über welchen managed/unmanaged Switch sind die GXPs an die UCM angebunden?

Sind alle GXPs identisch konfiguriert?

Welche Werte sind bei den Session Timeouts eingetragen?

@koyaanisqatsi

Ich bin mir über die Bedeutung der lateinischen Vorsilbe inter bewusst. Aber leider kenne ich mich so gar nicht mit Star Wars und Co. aus. Das ist nicht mein Genre (ich kenne nur das Filmzitat aus Beitrag #6). Aber spielt das nicht auch in einer (oder mehreren) Galaxien, in der/denen es verschiedene Planeten gibt?
 
Hallo @pw2812

die UCM ist an der FritzBox angemeldet und hat eine IP von 192.168.178.* eine GXP auch an der Fritz, die anderen im Büronetz, das im Bereich 192.168.1.* definiert ist, jedoch haben alle GXP Zugang zum UCM und zum Fritz sowie auch zum Internet (Wetter, Uhrzeit klappt) und sind normal registriert. Gespräche und Signalisierungen untereinander funktionieren ja auch problemlos. Die GXP sind alle völlig gleich konfiguriert...
Wo finde ich die Session Timeout Einstellungen?

Gruß bhoenscheid
 
Hallo @bhoenscheid

Danke für die zusätzlichen Informationen, aber du hast leider noch nicht alle Fragen aus Beitrag #10 beantwortet.

Tritt das Problem bei allen GXP auf oder nur bei einigen bestimmten?

Sind die UCM und die GXPs auf dem aktuellen Firmwarestand?



die anderen im Büronetz

In diesem Zusammenhang (Büronetz?) bitte noch diese Frage beantworten:

Über welchen managed/unmanaged Switch sind die GXPs an die UCM angebunden?

Die Timeouts werden unter Konto x --> SIP-Einstellungen --> Basiseinstellungen festgelegt.
 
Hallo nochmal

@pw2812

Das Problem tritt bei allen GXP auf. Unabhängig z.B. vom Netzwerkbereich.

Die Timeouts sind im Anhang zu sehen:

Screenshot_20190726-171002_Microsoft Remote Desktop.jpg
[Edit Novize: Bild gemäß den Forumsregeln zur Vorschau geschrumpft]

bhoenscheid
 
Zuletzt bearbeitet von einem Moderator:
Hallo Bastian,

wenn meine Kurzrecherche stimmt, sollte dir der Begriff "Anamnese" geläufig sein.

Sowas in der Art versuche ich hier auch gerade. Daher die Fragen in Beitrag #10. Da die Timeout-Settings nur ein Schuss ins Blaue sind, und vielleicht etwas mit deinem Problem zu tun haben könnten (vielleicht aber eben auch nicht), macht es in meinen Augen wenig Sinn da jetzt dran rumzuschrauben, solange du nicht die nachgefragten Informationen bereitstellst.

In deiner "IPPF-Patientenakte" habe ich was zu deiner Vorgeschichte gefunden (ich hoffe, du erlaubst mir diese Analogie zu deiner beruflichen Tätigkeit). Du schreibst am 26. März 2019 hier:

3. Idee: irgendeine VOIP-Anlage (Asterisk? Fertiglösung ohne großen Programmieraufwand? Oder Grandstream-Anlage? Oder andere Anlage - welche?) ans Internet hinter die Fritzbox, dann per DLAN die VOIP-Tischgeräte in die einzelnen Büroräume (alles eine Etage, keine großen Entfernungen, gleicher Stromkreis) dahinter hängen?

das du es in Betracht ziehst die "VOIP-Tischgeräte" per DLAN mit der TK-Anlage zu verbinden. Ist das so geschehen? Gibt es also möglicherweise gar keinen Switch?

Ich will hier eigentlich nicht wild rumraten müssen. Deshalb die Fragen.

Off-topic: DLAN in Praxisräumen von Ärzten halte ich persönlich für keine gute Wahl. Wenn ich da nur an die Geräte denke, welche zu Diagnosezwecken zum Einsatz kommen können, halte ich das durchaus für problematisch.
 
Hallo!


das du es in Betracht ziehst die "VOIP-Tischgeräte" per DLAN mit der TK-Anlage zu verbinden. Ist das so geschehen? Gibt es also möglicherweise gar keinen Switch?

Völlig okay, dass Du soweit recherchiert hast. Eine "Anamnese" sollte möglichst gründlich und vollständig sein! Damit kennst Du nun auch meinen "Background" und weißt, dass ich weder Informatik studiert habe noch spezielle Ahnung von VOIP-Technik oder Netzwerken habe. Ich habe mich da "hobbymäßig" etwas eingearbeitet.

Da ich auch eine Firma habe, die die Software und das Netzwerk "pflegt", hatte ich da im Vorfeld auch nachgefragt. Von der Lösung mit den DLANs wurde mir auch abgeraten. Da die Grandstream-Geräte integrierte Hubs haben und mir der Netzwerk-Techniker sagte, ich könne die problemlos ins vorhandene LAN einbinden, habe ich das dann auch so gemacht. Dabei entstand aber das Problem mit dem zweiten IP-Bereich, da nur das Router-nahe Telefon aus örtlichen Gründen ans 192.168.178.* er Netz geschaltet werden konnte/musste. Die anderen hängen am internen Netz (switch), das noch einen Router (Securepoint UTM v11) dazwischen hängen hat, der auch als Firewall und VPN-Router ins Internet dient. Hier hatte mir aber der Netzwerk-Techniker versichert, dass alle "internen" Adressen und Ports im Bereich 192.168.1.* untereinander verfügbar seien. Und -wie bereits beschrieben- es funktioniert ja, dass sich alle Geräte untereinander richtig "finden"...

Wie kann ich nun das Problem näher eingrenzen? Gibt's da Logdateien in der UCM, in denen evtl. die Verzögerung nachvollziehbar ist?


Off-topic: DLAN in Praxisräumen von Ärzten halte ich persönlich für keine gute Wahl. Wenn ich da nur an die Geräte denke, welche zu Diagnosezwecken zum Einsatz kommen können, halte ich das durchaus für problematisch.

Dieses Problem hat sich ja dank meiner vorherigen Recherchen erledigt!

Nochmal Danke für die bisherigen Tipps und Grüße,

Bastian
 
Ich habe mich da "hobbymäßig" etwas eingearbeitet.

Das finde ich wirklich gut! Das nötigt mir immer Respekt ab, wenn Menschen versuchen sich in ein für sie eher "unbekanntes Gebiet" (Neuland) "reinzufitzen".

Wir nähern uns langsam an. Bitte überprüfe und aktualisiere falls nötig noch die Firmware der UCM und aller GXPs. Die neueste FW findest du hier:


Hat das GXP, welches direkt an der Fritzbox hängt auch die Probleme mit der Verzögerung? Ist dieser Apparat evtl. das Gerät "am Empfang"? Und wird dann viel von diesem GXP intern an die anderen vermittelt? Tritt die Stille am Gesprächsbeginn auch bei rein interner Vermittlung/Telefonie zwischen den vier GXPs auf, welche hinter der UCM hängen (IP-Bereich 192.168.1.*)?

Ich kenne das Securepoint UTM v11 nicht. Daher kann ich zu diesen Einstellungen nichts sagen.
 
@pw2812

Die Firmware ist bei allen Geräten einschl. UCM aktuell, das hatte ich vor der Konfiguration schon gemacht!
Das Problem mit der Verzögerung ist bei allen Geräten aufgetreten. Jedoch nicht reproduzierbar. Es gibt aber immer wieder Zeiten, wo alles reibungslos klappt... Es tritt sowohl bei reinen internen Gesprächen auf (man wählt z.B. von Nebenstelle x zu y, dort klingelt es, y, nimmt ab, hört x aber erst nach 2-5 Sekunden und umgekehrt) oder auch bei externen Gesprächen (Anrufer ext ruft an, Nebenstelle xyz nimmt an, hört aber erst nach 2-5 Sek. den Anrufer ext, der auch wenige Sekunden eine "tote" Leitung hatte. Der weitere Gesprächsverlauf ist immer reibungslos. Gespräche nach extern hatten bisher nie Probleme gemacht.
Ich hatte auch schon überlegt, ob es an der Auslastung im Netzwerk liegen kann, aber es trat auch auf, wenn keine größeren Netzwerkaktionen oder Downloads liefen und nur ein einziges internes Gespräch geführt werden sollte.

Gruß Bastian
 
Kannst du bitte mal etwas genauer auf die IP-Konfiguration der einzelnen Geräte eingehen?

In den GXPs kann man doch nur eine IP-Adresse hinterlegen. Wie ist das gelöst, dass sich die GXPs mit beiden Netzen, also 192.168.178.* und 192.168.1.* gleichzeitig verbinden? Das ist mir nicht ganz klar.

Wie sind die UCM und die GXPs in Bezug auf die IP-Adressvergabe konfiguriert? Dynamisch (DHCP), statisch (feste IP)?

Gibt's da Logdateien in der UCM, in denen evtl. die Verzögerung nachvollziehbar ist?

Die Auswertung der Log-Files bzw. das Mitschneiden des Netzwerkverkehrs kann evtl. Aufschluss über das Problem geben.

Wie das bei den GXPs funktioniert ist im von KunterBunter verlinkten Administration Guide (Beitrag #12) auf Seite 92 "Maintenance --> Syslog" und auf Seite 95 "Maintenance --> Packet Capture" erklärt.

Für die UCM steht es im Handbuch ab Seite 418 geschrieben.

Link: http://www.grandstream.com/sites/default/files/Resources/ucm62xx_usermanual.pdf

Die Paketmitschnitte wären dann natürlich besonders für die Gespräche (extern und intern) interessant, bei denen der Fehler auftritt.

Falls du dich dazu entschließen solltest diese hier zu posten, achte auf jeden Fall darauf, dass du sie anonymisierst (z.B. Rufnummern). Es gibt hier im Forum Nutzer, die diese traces gut "lesen" und anhand dessen durchaus Unregelmäßigkeiten feststellen können.
 
Das ist so: die FritzBox stellt die Internetverbindung (DSL) her und registriert die VoIP-Rufnummern (Anbieter: Telekom). Sie ist unter der "Standard"-Adresse 192.168.178.1 erreichbar. An dieser sind die UCM (192.168.178.31) sowie ein GXP (192.168.178.33) per DHCP registriert. Die UCM stellt nun die PBX mit den SIP-Accounts für die GXPs bereit. Hinter der FritzBox ist das Securepoint UTM v11 (192.168.178.254), das den Adressraum 192.168.1.* bereitstellt und an dem die übrigen GXPs auch per DHCP registriert sind (konkret 192.168.1.141/142/143/144).
Alle GXPs sind somit an der UCM angemeldet.
Also alles DHCP, keine statischen IP's. Nach einem Neustart aller Geräte wurden die gleichen IP's aber bisher immer wieder genauso vergeben.

Das mit den Mitschnitten / Logfiles kann ich frühestens am Montag im Alltagsbetrieb machen, bis dahin komme ich nur per VPN drauf.


Gruß,
Bastian
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

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.