nachdem ich gestern einen Kunden in die Cloud umgezogen habe, alle Telefone (Snom 760 IP) auf FW 8.9.3.80 aktualisiert, auf Werkseinstellungen zurückgesetzt, per Cloud-URL provisioniert habe, brechen jetzt die Gespräche (tls. nach einer Minute) ab und danach ist das Gerät in der Geräteliste offline.
Alle Telefone hängen in einem eigenen Subnetz, aus dem SIP, RTP, HTTP(S), 8884 und XMPP zu den Pascom-IPs freigegeben ist. Bei einigen Gespräche werden hohe Jitter-Werte angezeigt, nicht aber bei den abgebrochenen Gesprächen. Diese sehen in der Analytics grün aus.
das Problem tritt bei “internen” Gesprächen vermutlich in gleicher wiese auf oder?
Könntest du bitte mal bereitstellen was dir in der Asterisk CLI angezeigt wird wenn du für das SIP Peer pjsip show endpoint {sippeer}
eingibst?
Leider sind die Telefone schon EoL, ich kann leider nicht ausschließen das es an der alten Firmware liegt.
Ich hänge mich hier mal dran. Ein Cloud-Kunde (19.05) von mir schrieb mir gerade, dass er das Problem mit dem Pascom-Client auf dem Mac hat nach ca. 10 MIn. und bei Gesprächen über ein Tischtelefon (in dem Fall ein aktuelles SNOM D385) nach ca. 30 Minuten. Denkbar ist ja vielleicht auch Router oder Internetgateway.
In meinem Fall eine Digitalsierungsbox Premium. Provider Telekom DeutschlandLAN-IP
intern wird dort so gut wie gar nicht telefoniert, da kaum aus dem Homeoffice gearbeitet wird und das Büro besetzt ist. Allerdings war heute Mittag, als ich es versucht habe, die Nebenstelle sowohl extern, als auch intern kurz nicht erreichbar. Als sie wieder erreichbar war und ich mit dem Mitarbeiter gesprochen habe, ist mir zwei Mal das Gespräch abgebrochen.
Wir setzen nur Sonicwalls ein. Da kann man es pro Regel definieren.
Dann solltest du es mal global hochsetzen. In deinem Link steht ja auch was von 120.
Dann mal schauen, wie es sich verhält
Ich habe das jetzt bei mir mal auf 120 global erhöht. Aber für’s Verständnis. Es geht ja auch um abgebrochene Gespräche. Da die über SRTP laufen, ist das ja TCP, oder?
beim Kunden wurde jetzt das UDP-Timeout global auf 120 hochgesetzt und an einer Nebenstelle wurde ein D385 eingerichtet. Die Abbrüche sind weiterhin vorhanden.
Habt ihr noch weitere Tipps? Oder wäre hier ein Downgrade auf 18 besser?
wie @Rippi angemerkt hat läut der (wenn auch verschlüsselte) Medienstream auch bei SRTP über eine UDP Connection. Solange aber keiner den anderen Teilnehmer auf halten setzt läuft dieser in beide Richtungen und es sollte zu keinem Timeout kommen. Laut Snom scheint das 760 auch aktuelle Cipher-Suites/Verschlüsselungsverfahren noch zu unterstützen (im Gegensatz zu den 3x0er Telefonen) und mit dem 385 hattest du ja bewiesen das es daran auch nicht liegt.
Was verbleibt also noch als mögliche Ursache?
Ggf griff vorher ein SIP (ALG) Mechanismus der längere UDP Streams erlaubte und jetzt nicht mehr greift (weil er die SIP TLS Verbindung nicht mehr mitlesen kann). Wenn man seine Mailbox (*100) anruft ist vermtulich nach 2 Minuten oder wann die Abbrüche auftreten auch Schluss, es scheint also an den UDP Streams von/zur pascom.cloud zu liegen. Sieht man in der WebCLI außer dem Hangup irgendetwas in der Art wie “due to lack of RTP aktivity”?
Ggf. spricht das syslog der Telefone etwas hilfreiches.
Wenn der Lancom keine Sonderkonfiguration hat sollte er nicht die Ursache sein, dieser kommt häufig zum Einsatz. Die Internetverbindung ist stabil?
Helfen die Analytic-Details (Call flow) zu den vier Zeilen? Darin sind aber alle Anzeigen grün.
Die Internetverbindung ist seit zwei Tagen online und auch nur deswegen so kurz, weil ich an dem Tag an der Stromversorgung des Routers arbeiten musste.
Das Problem existiert aber nicht nur bei vermittelten Anrufen oder? Die Call Quality Statistiken helfen im wesentlich zu erkennen wenn mangels QoS / Bandbreite Sprachqualitätsprobleme aufreten. Wenn ein Anruf von beginn an keinen Ton hat oder Unvermittelt abbricht, bekommt man hierher nicht umbedingt die notwendigen Informationen.
nachdem ich am Wochende noch einmal ausführlich RTFM betrieben habe, hatte ich noch den Fehler gefunden, dass nur Port 5060, nicht aber 5061 ins Internet freigegeben war. Nach der Anpassung habe ich auch drei parallele 10-Minuten-Verbindungen geführt. Daher habe ich auf PebKaC getippt.
Leider wollte der Kunde mich gerade anrufen, es hat geklingelt und danach war er nicht zu hören. Bei einem Rückruf kam dann temporarily not availabe. So sah die Geräteliste zu dem Zeitpunkt aus:
ist hier 19.05 oder ggf noch etwas älteres im Einsatz?
100rel : yes sollte in 19.05 nicht für Endgeräte gesetzt sein, du kannst es mal mit einem endpoint/100rel=no
in den Endgeräte Optionen probieren, aber bei Systembasiskonfig und 19.05 sollte das wie erwähnt off sein.
Bezüglich BLF, sind die Tasten wie hier beschrieben konfiguriert? https://www.pascom.net/doc/de/endpoints/snom/#blf-tasten-konfigurieren-über-die-basis-konfiguration
Also als Typ BLF und mit |*8 hinten dran?
Gerade hat der Kunde mit zwei Nebenstellen parallel telefoniert und bei beiden hat die Sprachübertragung fast zeitgleich aufgehört. Die Gegenstelle konnte den Kunden noch hören, aber umgekehrt nicht mehr. 202004406_cli-Auszug_UnterbrechungNSt14.txt (116,9 KB)
das mit den Basiskonfigurationen war etwas irreführend endschuldige. Hier ging es mir Primär um SIP/RTP Relevante Einstellungen die nicht von unseren Vorschlägen abweichen sollte.
100rel ist eine asterisk seitige Peer einstellung, diese könnte nur durch Änderung an den Systemeinstellungen oder EndgeräteOptionen erwirklt werden. In den ersten 19er Versionen wurde das glaube ich von uns im default aktiviert, da dadurch wohl Probleme bezüglich Halten beispielsweise auftraten wurde das dann wieder rausgenommen. Wenn die Abrüche aber nicht bei “Halteaktionen” oder nach vielfachen von 15 Minuten (+30 Sekunden) auftreten ist das nicht die Ursache.
Die CLI ist hier nicht das geeigneteste Medium, aber es scheint als sei mind. 1 Gespräch abgebrochen weil die Verbindung zum Endgerät verloren ging (würde ja auch für das “fast zeitgleich” sprechen). Wenn am Router kein WAN Verbindungsabbruch registriert wurde kann es natürlich an CRC Fehlern/Paketloss oder ähnlichen liegen die man nun mal zu aller erst bei Echtzeitanwendungen feststellt:
== Endpoint sWrLGYMRJ71143d is now Reachable (war also mal unreachable)
– Channel PJSIP/mdc_trunk_conf-1-00000361 left ‘simple_bridge’ basic-bridge <1a623a65-00c3-45a5-9978-c6ef071a49dd>
– Channel PJSIP/sWrLGYMRJ71143d-00000360 left ‘simple_bridge’ basic-bridge <1a623a65-00c3-45a5-9978-c6ef071a49dd>
Der Transport zwischen asterisk und Kamailio findet über TCP 5060 steht, das ist richtig und gewollt.
Bei den BLF ist euch wohl leider ein Fehler unterlaufen, Falschbeispiel: blf {{{setting sys.asterisk.pickup.prefix.snom}}}20{{{009ext_extension}}}