Nach Cloud-Umzug und Upgrade häufige Abbrüche/Nichterreichbarkeit

Hallo Pascom,

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.

SIP- und RTP-Priorisierung ist auch eingerichtet:

Habt ihr noch weitere Tipps für die Fehlereingrenzung für mich oder muss ich wieder zurück auf eine Onsite-Installation?

DAnke
Ulf

Hallo Ulf,

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.

Grüße,
Steve

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

Hallo Steve,

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.

hier schon mal der CLI-Auszug:
NSt16pjsipEndpoint.txt (6,4 KB)

PS: wie lässt sich eigentlich etwas in die CLI rein kopieren?

Hier noch die Daten drumherum:

  • Telekom SIP Trunk als Anschluss
  • Lancom 1781VA als Internet-Router

Die Firmware für das 760 ist auch die letzte, die ich bei SNOM herunterladen konnte.

Leider sind die Telefone schon EoL, ich kann leider nicht ausschließen das es an der alten Firmware liegt.

Ich habe gerade ein D385 bestellt und werde es damit gegentesten.

Als die Nebenstelle nicht erreichbar (weder intern, noch extern) habe ich diesen CLI-Auszug gezogen:
NSt16NichtErreichbar.txt (13,6 KB)

Ansonsten bin ich für jeden Tipp dankbar.

Ulf

Also Gespräche, die immer zur selben Zeit abbrechen:
Ich tippe auf UDP-Timeout. Wie sieht es denn da in den Firewalls aus bei euch?

Also so wie unter Deutschlan Lan-IP hinter Lancom registrieren - #6 by Jens1 beschrieben, ist das Timeout bei mir auf dem Standardwert von 20 Sekunden:
grafik

Welcher Wert wäre hier sinnvoll?

Ich hab mal was von 120-180 gelesen.
Ich setze selber immer 180 für meine VoIP-Regeln und habe da keine Probleme mehr mit.

Ich kann das Timeout meines Wissens auf dem Lancom nur global setzen, nicht für die VoIP-Regeln (-Verbindungen). Wie machst Du das bei Dir?

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?

Nein, für SRTP wird auch UDP verwendet: https://www.pascom.net/doc/de/server/cloud/#telefonieren-und-chatten

Hallo @Steve,

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?

Danke
Ulf

Hallo @ulf.kosack,

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?

Grüße,
Steve

Hallo @Steve,

Syslog habe ich jetzt aktiviert und warte auf die Abbruch-Meldung des Kunden.

Ein beschriebener Vorfall ist der folgende:

  • externer Anruf wurde von der 12 angenommen
  • Anrufer wurde zur 16 übergeben
  • die 16 hat nichts mehr gehört, so dass sie aufgelegt haben
  • die 16 hat die externe Nummer angerufen und dann 10 Minuten telefoniert


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.

Danke
Ulf

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.

Hallo @Steve,

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:

“sip show endpoint” für NSt. 16 zeigt folgendes:
NSt16pjsipEndpoint.20200406.txt (6,5 KB)

Zusätzlich hat heute früh an einer Nebenstelle das BLF nicht funktioniert, so dass ein Anruf nicht übernommen werden konnte.

Danke
Ulf

Hallo Ulf,

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?

Grüße,
Steve

Hallo @Steve,

beim Kunden ist 19.05 in der Cloud im Einsatz, bei mir 18.12 onSite in einer Proxmox-VM.

Die Konfiguration der Telefone ist die mit der 19.05 ausgelieferte Standard-Snom-Konfiguration, erweitert um ein paar Funktionstasten

<fkey idx="0" context="active" label="Zentrale" perm="R">blf {{{setting sys.asterisk.pickup.prefix.snom}}}20{{{009ext_extension}}}</fkey>
<fkey idx="1" context="active" label="Anrufbeantw." perm="R">blf 2{{{009ext_extension}}}</fkey>
<fkey idx="3" context="active" label="Nachtschaltung" perm="R">blf sip:201@{{{cs_domain}}}|{{{setting sys.asterisk.pickup.prefix.snom}}}</fkey>
<fkey idx="4" context="active" label="Vorzimmer" perm="R">blf sip:11@{{{cs_domain}}}|{{{setting sys.asterisk.pickup.prefix.snom}}}</fkey>

ergibt dann auf dem Telefon:

fkey0=blf *82016
fkey1=blf 216
fkey2=blf *44#
fkey3=blf sip:201@telefonsystem|*8

und die folgenden OPtionen:

    {{!-- Custom --}}
    <goto_monitor_state_on_line_activity perm="R">on</goto_monitor_state_on_line_activity>
    <line_info_at_idle perm="R">on</line_info_at_idle>
    <syslog_server perm="R">10.1.1.5</syslog_server> 

Wo soll die Option 100rel gesetzt sein? In den SIP Optionen des Gerätes?

Im Amt habe ich in der Cloud-INstanz nur die letzte Zeile hinzugefügt, damit die Durchwahlen angezeigt werden:

transport=tcp
endpoint/disallow=all
endpoint/allow=alaw
; session-timers=refuse
endpoint/user_eq_phone=yes
endpoint/from_user=

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)

Danke
Ulf

Ist es eigentlich korrekt, dass im sip show endpoint der Transport auf Port 5060 steht?

 Endpoint:  3PLJlOtly712e94                                      Not in use    0 of 1
   InAuth:  3PLJlOtly712e94-iauth/3PLJlOtly712e94
      Aor:  3PLJlOtly712e94                                    1
  Contact:  3PLJlOtly712e94/sip:3PLJlOtly712e94@10.1.6 ffe1085d3b Avail        61.161
Transport:  tcp                       tcp      3     96  0.0.0.0:5060

Hallo Ulf,

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}}}

richtiges Beispiel:
blf sip:11@{{{cs_domain}}}|{{{setting sys.asterisk.pickup.prefix.snom}}}

Grüße,
Steve