Automatischer Statuswechsel problem

Dann wird es wohl so gehen:

$ crontab -e

und dann die # davor eintragen.

#* * * * * /usr/bin/pwsh -File 3cx-powershell-example.ps1 >/dev/null 2>&1
danach neustart vom Job

sudo service cron reload
 
Dann wird es wohl so gehen:

$ crontab -e

und dann die # davor eintragen.

#* * * * * /usr/bin/pwsh -File 3cx-powershell-example.ps1 >/dev/null 2>&1
danach neustart vom Job

sudo service cron reload
ja

Wenn sich durch Mehrfachanmeldung das Programm (nicht das Skript sondern die durch das Skript benutzte Wrapper DLL 3cxpscomcpp2.dll) aufgehängt hat, dann etwas warten bis zum Timeout (was hoffentlich kommt) oder die 3CX neu starten (mit hoffentlich nur einem solchen cron Job sonst passiert das gleich wieder).
 
  • Like
Reaktionen: Ben04
Alles klar. Laufen lassen und wenn es am tage sich aufhängt, abwarten und abends dann spätestens einmal die 3CX neu starten. Alles klar. Danke
 
  • Like
Reaktionen: Ben04
Ja ich lasse es eh laufen und mache als einzige Aktion, das Skript stoppen, aber erst, wenn das Problem wirklich weg und identifiziert ist. Da niemand anderes auf dem Linux was macht, außer mir, bin ich die einzige Person und ich lasse es wie gesagt laufen :)
 
  • Like
Reaktionen: fxbastler
Aber mal wirklich, was sind denn da für Geräte an diese NSt. angebunden, dass die laut Log wie du hier schreibst den Status alle 1 sek. neu setzen wollen? Passiert das den ganzen Tag lang?
 
An dem User ist nur 1 Snom D865 angebunden. Das ist als SBC-Router eingerichtet.
Ganz normal via Autoprov. und dem zweiten Nutzerkonto für das ECSTA.
Mehr ist da nicht. Es passiert auch nur sehr sporadisch das ganze und ist auch im Log nicht den ganzen Tag zu sehen.

Es gibt noch ein zweites Smartphone, welches aber kein Router-Telefon ist und direkt angebunden ist.
Die 3CX ist bei uns lokal im selben Netz. Unsere Router-Telefone sind nur selbständig für Testzewecke als Router-Telefon.
 
Ganz normal via Autoprov. und dem zweiten Nutzerkonto für das ECSTA.
aha, deine Bastelei, soso

Jetzt, nach 3 Seiten Forenposts wird so eine entscheidende Geschichte das erste mal angesprochen.
 
Das ECSTA-Konto agiert nur im Hintergrund und hat keinen Zugriff auf 3CX. Dann würde das Problem ja bei anderen auch teils auftauchen. Und anders, kann man die 3CX ja nicht mit CTI wie ProCall z.B verbinden. Dafür gibt es ja diese Lösung.
 
... klar doch, nur am Endgerät, das hat keine Auswirkung an einem Router Phone, das macht nichts, das will nur spielen ...

  1. Wir würden das nicht machen.
  2. Wenn ich so etwas irgendwo vorfinden würde, von wem auch immer, und müsste mich um das Problem kümmern, dann hätte ich vor einem ersten Post deswegen hier im Forum alle Endgeräte des Nutzers auf ein von einer 3CX unterstütztes Szenario zurückgesetzt (Werksreset) und wenigstens das ausgiebig probiert. Ungeachte dessen hätte ich diese doch wesentlichen Fakten erwähnt und nicht darauf vertraut, dass mich jemand gezielt danach fragt weil er es irgendwie erahnen könnte.
 
Hatte ich hier auch schonmal Publiziert:
Ja, das habe ich dort letztens schon gelesen und meinen Senf dazugegeben. Da taucht auch das entscheidende Wort repräsentativ auf.

Nur zur Revue: woher soll irgend jemand hier wissen, dass es ein Telefon an dieser 3CX ist? Noch dazu so ein frisiertes an dieser 3CX. Noch dazu so ein frisiertes eines anderen Typs (mit einigen bekannten Problemen bzgl. Routerphonie). Die meisten, die hier schreiben, haben nicht nur eine 3CX.

Nichtsdestotrotz: du kannst jetzt Powershell auf einer 3CX, hast ein gutes und funktionierendes Gerüst was auch noch als cron job läuft, es gibt eine brandneue funktionierende Anleitung im Forum und Andere haben auch etwas davon. Das ist doch schon was :)

Halte uns mal bitte auf dem Laufenden was dabei rauskommt und evtl. ob die Probleme in einer von 3CX empfohlenen und supporteten Umgebung und Nutzung bestehen bleiben ;)
 
  • Like
Reaktionen: Ben04
Ja hast du auch wieder recht.

Ich war jetzt heute wieder in der Lage, das Phänomen kurzzeitig mitzubekommen, da ich unter anderen auch 3 Tage auf Fortbildung war + Feiertag gestern in NDS.

Ausgaben aus dem Cronjob:

2024-11-01_07-51_Freitag Custom 1
2024-11-01_07-52_Freitag Available

Bemerkt:
Um 8:22 Uhr heute morgen.
Habe mir jetzt die ganzen Daten gezogen und versuche zu forschen, weshalb das passiert.

UpdateEdit:
Was mir wieder ins Auge fällt ist folgendes:
Er fängt urplötzlich an, den Status vom Telefon abzufragen und sagt dabei, es ist auf DND und gibt somit den Befehl, DND auszuschalten.
Das hatte ich letztes mal auch schon gelesen bei den ungefähren Uhrzeiten, wo das passierte.

Code:
01.11.2024 07:51:29.635    Extn:40: Synch devices to dndOFF
01.11.2024 07:51:29.304    Extn:40: DND change request to dndOFF is ignored - same state is charged already
01.11.2024 07:51:29.304    Extn:40: Starting DND change transaction to dndOFF requested from configuration
01.11.2024 07:51:29.304    Settings of Extn:40 has been updated
01.11.2024 07:51:29.304    Extn:40: Profile is set to dndOFF
01.11.2024 07:51:29.304    Extn:40 belongs to groups 32,33,
01.11.2024 07:51:29.304    DN:40 belong to groups: 32{GRP0000},33,, primary group: 'GRP0000'
01.11.2024 07:51:29.304    Extn:40 belongs to groups [32{GRP0000},33,]
01.11.2024 07:51:29.304    Settings of Extn:40 has been updated
01.11.2024 07:51:29.304    Extn:40: Profile is set to dndOFF
01.11.2024 07:51:29.304    Extn:40 belongs to groups 32,33,
01.11.2024 07:51:29.304    DN:40 belong to groups: 32{GRP0000},33,, primary group: 'GRP0000'
01.11.2024 07:51:29.304    Extn:40 belongs to groups [32{GRP0000},33,]
01.11.2024 07:51:29.292    Extn:40: Switch profile to dndOFF
01.11.2024 07:51:29.205    Endpoint Extn:40 has refreshed contact <sip:[email protected]:42527/UDP>
01.11.2024 07:51:28.961    Extn:40: Starting DND change transaction to dndOFF requested from a device
01.11.2024 07:51:28.961    Device's (<sip:[email protected]:42527/UDP>) requested DND state is dndOFF for Extn:40

Im LogView finde ich bisher leider nichts. Da hab ich den Filter für die DN gefunden, also DN 40, aber da ist dann der letzte gefilterte Log von 1:40 Uhr.. Edit2: -> Man sollte auch die hübschen Pfeile oben Links beachten :D Nun bin auch bei 7:5XXXXX Uhr angekommen und finde dort reichlich mehr informationen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: fxbastler
Weiteres Update, was das Ganze sehr kurios aussehen lässt.

Das SKIP mit dem Statusprüfen läuft auf die DN 97. Die 97 wird angerufen, um zu checken, welcher Status es ist. (angemeldet oder abgemeldet). Gibt dann die Option, das Gegenteil einzustellen.

Jetzt kommt die Kuriosität in Person: Nach dem Anruf geht es für eine sichtbare Sekunde in den DND-Modus und dann direkt in den verfügbaren.

Edit: Identität 2 für CSTA deaktiviert, Phänomen tritt nicht mehr auf. Nun testen, weshalb es nur bei dem User passiert.
Code:
01.11.2024 10:25:55:660 | 11 | CSTA: on info: CSTA Recv Req INFO from 127.0.0.1:5080 tid=-5v0fqxg3ygb7 Call-ID=KGSHC7WblWhByTRiSdmCnA..:
INFO sip:[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK-524287-2----5v0fqxg3ygb7;rport=5080
Via: SIP/2.0/UDP 185.35.133.44:37631;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=sbc.a4502e25
Via: SIP/2.0/UDP 10.0.0.34:42527;branch=z9hG4bK-5v0fqxg3ygb7;rport=42527
Max-Forwards: 68
Record-Route: <sip:[email protected]:5080;user=proxy;uri=sbc.a4502e25>
Record-Route: <sip:[email protected]:5060;user=proxy;tnlid=sbc.a4502e25>
Contact: "USER" <sip:[email protected]:42527;line=m26jh0b0>;reg-id=1
To: <sip:40@3cx>;tag=5ed5fc55
From: "USER"<sip:[email protected]:42527;line=m26jh0b0>;tag=3speo7s0nq
Call-ID: KGSHC7WblWhByTRiSdmCnA..
CSeq: 236 INFO
Content-Type: application/csta+xml
Proxy-Authorization: Digest username="e0FiVF5j8v",realm="3CXPhoneSystem",nonce="414d535967249e9b24:acfb17d3ca6240e1ce881806ddb57586",uri="sip:[email protected]:5060;user=proxy;tnlid=sbc.a4502e25",response="6d36849dbc5bbff6d11cd21c2e01a684",algorithm=MD5
User-Agent: snomD865/10.1.175.16 000413C13BE8
Mac: 000413C13BE8
Content-Length: 332

<?xml version="1.0" encoding="utf-8"?>
<DoNotDisturbEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed5">
  <monitorCrossRefID>62</monitorCrossRefID>
  <device>
    <deviceIdentifier>sip:40@3cx:5060</deviceIdentifier>
  </device>
  <doNotDisturbOn>false</doNotDisturbOn>
</DoNotDisturbEvent>
01.11.2024 10:25:55:661 | 11 | CSTA: onReadyToSend: CSTA Send 200/INFO from 0.0.0.0:0 tid=-5v0fqxg3ygb7 Call-ID=KGSHC7WblWhByTRiSdmCnA..:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK-524287-2----5v0fqxg3ygb7;rport=5080
Via: SIP/2.0/UDP 185.35.133.44:37631;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=sbc.a4502e25
Via: SIP/2.0/UDP 10.0.0.34:42527;branch=z9hG4bK-5v0fqxg3ygb7;rport=42527
Record-Route: <sip:[email protected]:5080;user=proxy;uri=sbc.a4502e25>
Record-Route: <sip:[email protected]:5060;user=proxy;tnlid=sbc.a4502e25>
Contact: <sip:40>
To: <sip:40@3cx>;tag=5ed5fc55
From: "USER"<sip:[email protected]:42527;line=m26jh0b0>;tag=3speo7s0nq
Call-ID: KGSHC7WblWhByTRiSdmCnA..
CSeq: 236 INFO
User-Agent: 3CXPhoneSystem 20.0.3.806 (806)
Content-Length: 0


01.11.2024 10:25:55:661 | 11 | Processing CSTA event from "USER" <sip:[email protected]:42527>
01.11.2024 10:25:55:661 | 11 | Parsing XML: <?xml version="1.0" encoding="utf-8"?>
<DoNotDisturbEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed5">
  <monitorCrossRefID>62</monitorCrossRefID>
  <device>
    <deviceIdentifier>sip:40@3CX:5060</deviceIdentifier>
  </device>
  <doNotDisturbOn>false</doNotDisturbOn>
</DoNotDisturbEvent>
01.11.2024 10:25:55:661 | 11 | Device's (<sip:[email protected]:42527/UDP>) requested DND state is dndOFF for Extn:40
01.11.2024 10:25:55:661 | 11 | Extn:40: Starting DND change transaction to dndOFF requested from a device
 
Zuletzt bearbeitet:
Das SKIP mit dem Statusprüfen läuft auf die DN 97
Das verstehe ich nicht. Was ist SKIP? Was wird wie wozu angerufen und macht was? Was hat das mit dem Statuswechsel Problem der NSt. 40 zu tun?
Jetzt kommt die Kuriosität in Person: Nach dem Anruf geht es für eine sichtbare Sekunde in den DND-Modus und dann direkt in den verfügbaren.
Nach dem Anruf an die NSt. 97? Welche NSt. wechselt den Status in DND und wieder in Verfügbar?

Noch zur 40:
Das Log ist im Prinzip das Gleiche wie das von dir hier im Post, nur diesmal bestätigt durch ein Protokoll.
Ich hätte da schon längst die Reißleine gezogen:
Lösche das Telefon aus der 3CX Verwaltung, setze die NSt. komplett zurück (kompletter Passwort Reset), setze das Endgerät (Snom D865 als Router Phone?) auf Werkeinstellungen zurück, binde es neu an die 3CX an NSt. 40 an so wie es von 3CX vorgesehen ist und nichts anderes und belasse es dabei und lasse auch keine Skripte über die NSt. oder sonst. Anbindungen an dem Telefon laufen. Wenigstens für einige Zeit. Ich gehe davon aus, das Problem tritt anschl. nicht mehr auf. Sonst berichte bitte.
 
Skript sollte es heißen.
Das Skirpt ist einfach nur um den Status zu wechseln und dabei eine Rückmeldung zu haben, ob man angemeldet ist oder nicht. Um sich am Telefon die Rückfragen zu geben. Somit melden wir uns alle An/Ab (Verfügbar/Custom1).
Das ist ein normales Skript, welches ja erst angerufen werden muss.

Nach dem Anruf an die NSt. 97? Welche NSt. wechselt den Status in DND und wieder in Verfügbar?
Die NSt. 40.
Also Identität 2 ist an und per Identität 1 wird das Skript mit der 97 Angerufen. Danach wechselt der Status der NSt. 40 für 1 Sekunde in DND und dann sofort auf Verfügbar. Alles für die NSt. 40.
Ohne Identität 2, trat das problem gerade nicht auf.
Wir schauen weiter, wo das sein könnte. Denn der CSTA Startet irgdendwie ein Event:

01.11.2024 10:25:55:661 | 11 | Processing CSTA event from "USER" <sip:[email protected]:42527>
01.11.2024 10:25:55:661 | 11 | Parsing XML: <?xml version="1.0" encoding="utf-8"?>
<DoNotDisturbEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed5">
<monitorCrossRefID>62</monitorCrossRefID>
<device>
<deviceIdentifier>sip:40@3cx:5060</deviceIdentifier>
</device>
<doNotDisturbOn>false</doNotDisturbOn>
</DoNotDisturbEvent>


 
Das Skirpt ist einfach nur um den Status zu wechseln und dabei eine Rückmeldung zu haben, ob man angemeldet ist oder nicht. Um sich am Telefon die Rückfragen zu geben. Somit melden wir uns alle An/Ab (Verfügbar/Custom1).
Das ist ein normales Skript, welches ja erst angerufen werden muss.
Aha, die 97 ist also eine CFD App die hoffentlich nie eigenständig agiert.

Nochmal zum Thema zweite Identität:
... klar doch, nur am Endgerät, das hat keine Auswirkung an einem Router Phone, das macht nichts, das will nur spielen ...
In all solchen Fällen sind Probleme vorhersehbar.
 
Aha, die 97 ist also eine CFD App die hoffentlich nie eigenständig agiert.
Ja genau, die wird aber nur per 97 angesprochen. Keinerlei Automatismus über Ecken und Kanten. Gewöhnliches Skript. Kann ich gern zeigen bei Bedarf.

Habe hier für den test auch mal die DW 73 genommen, aber das gleich Ergebnis. Das Skript hat keinerlei Probleme.
Nochmal zum Thema zweite Identität:
Lynche mich ruhig, habe damit gerechnet nach meinem Fund.;)

Aber dennoch bleibt es komisch, dass es beim Zweiten nicht passiert. Bin mittlerweile in der tiefen Forschung beim CSTA, aber auch da leider kein direkter Hinweis, bis auf dass das Skript von allen genutzt wird.
 
Aber dennoch bleibt es komisch, dass es beim Zweiten nicht passiert.
Zufall, Glück, viel Optimismus, wir haben noch Herbst, Position und Menge der Sonnenflecken - kein Ahnung warum das funktioniert, such dir was aus ;)
 
  • Like
Reaktionen: Ben04

Statistik des Forums

Themen
44.413
Beiträge
232.713
Mitglieder
78.328
Neuestes Mitglied
as7h