ich verwende die pascom V16.00 mit einem SNOM-DECT-Gatway M700 FW 03.55/B0025. Das DECT-Gateway hatte ich unter der mobydick Version 7.13 eingerichtet und es lief mit den verwendeten M65 (FW355.22) problemlos auch nach den pascom-Updates auf V15.01 und V16.00.
Seitdem ich nun einen Benutzer in der Anlage geändert hatte (Name, Benutzername und E-Mail-Adresse usw…) und die Änderungen durch ein “Provisionierung” des DECT-Gateways auch an das zugewiesene Mobilteil erfolgreich übertragen hatte (neuer Name erschien im Display), besteht das Problem, dass alle SIP-Peers der Mobilteile ununterbrochen zwischen “reachable” und “unreachable” wechseln im Abstand von 60 bis 200 Sekunden. In der Regel zeigen die Peers eine Antwortzeit von ~50ms wenn sie online sind und wenn sie “unreachable” werden, steht bei “Last qualify” meistens auch eine Wert in diesem Bereich, teilweise aber auch Werte im Bereich von 1500 bis 1900.
Sind die Peers online/reachable kann auch telefoniert werden und die Verfügbarkeit wird ordnungsgemäß im WebUi > Benutzer-/Geräte-Liste und dem pascom-Client angezeigt.
In der M700 werden die Mobilteile kontinuierlich mit Status OK und erfolgreicher SIP-Registrierung angezeigt (SIP registriert@RPN00) auch in der Zeit während die Peers offline/unreachable sind. Im Bereich “SIP Log” ist allerdings zusehen dass die Verbindung “abreißt”:
Ich habe bereits die M700 in den Auslieferungszustand zurück gesetzt, vorher alle Mobilteile in der pascom gelöscht und anschließend alles neu angelegt und provisioniert, mit dem selben Ergebnis. Da das Problem erst auftrat als ich das DECT-Gateway unter V16.00 neu provisioniert hatte, vermute ich, dass es evtl. damit zusammen hängen könnte. Ich habe auch noch Sicherungen von V15.01 allerdings nicht von V7.13.xx, unter der ich das DECT-Gateway zuvor als letztes provisioniert hatte. Deshalb bin ich den Schritt auf eine vorherige Version zurück zugehen noch nicht gegangen, da ich es nicht überprüfen kann falls in V15.01 das selbe Phänomen auftritt.
Falls jemand weitere Ideen hat oder das Problem kennt und evtl. schon beseitigt hat, wäre ich über eine Rückmeldung dankbar.
ich hatte das Problem auch schon und bei mir lag es daran das die Verbindung nicht mehr über UDP sondern über TCP läuft (Einstellbar unter Dienste).
Das wird bei einem Update (ich glaube auf pascom 15) umgestellt.
Als ich das wieder umgestellt habe auf UDP lief alles wieder normal.
danke für deinen Hinweis. Ich habe auf UDP umgestellt und sehe auch in den Protokollen dass es verwendet wird aber leider löst die Umstellung das Problem in meinem Fall nicht.
das ist wirklich seltsam, ein ping von der PBX zum Sender läuft unterbreichungsfrei durch während die Registierung flöten geht?
Das von Tobias beschriebene Problem mit TCP trat bei dem Update auf, bei dem der Asterisk per default auch unter TCP läuft, im nächsten Hotfix wurde aber die Basiskonfig um ein
<keepalive_interval idx=“1”>off</keepalive_interval>
ergänzt, denn das Problem ist das Verhalten der Sender bezüglich der Keepalive Pakete, die werden dort einfach gesammelt und an den Anfang der nächsten SIP Message gesetzt und “deformieren” es somit. Mit dem deaktivierten Keepalive geht aus auch unter TCP.
wenn das Gateway wirklich unter UDP läuft (ich weiß du hattest das gecheckt, aber bitte nochmal auf der Weboberfläche des Senders gegenprüfen), und sich sonst nichts an den Switchen usw. geändert hat, dann kann es eigentlich nur ein Hardware defekt sein.
Man könnte u.U. noch das Debug logging aktivieren und auf die Anlage loggen lassen, u.U. kann man da etwas erkennen. Um alles auszuschließen, solltest du auch die Handsetfirmware auf den Stand der Sender bringen (v355b25).
Du hast recht Steve, der Sender hat nicht wirklich UDP für den Transport verwendet. Nachdem ich nochmal umgestellt und neugestartet hatte, läuft es über UDP und die Peer-Registrierung bleibt erhalten.
Jetzt muss ich mal auf dieses Thema zurückkommen. Seid Ihr sicher dass in der neuen B4xx Firmware das Problem beim Keep Alive so noch besteht. Snom empfiehlt ausdrücklick Keep Alive zu aktivieren (in jedem Falle) und im Moment scheinen wir Probleme zu wälzen die hier in Zusammenhang stehen. Im Testlab konnten wir bei aktiviertem Keep-Alive bis jetzt weiter keine Probleme feststellen.
