Nebenstelle nicht angemeldet abfragen

suessmilch

Silver Partner
Mitglied seit
7. Dezember 2020
Beiträge
27
Guten Tag,

ich programmiere gerade für einen Kunden einen Call Flow der verschiedene Szenarien abdeckt:
- Nebenstelle telefoniert (über GetExtensionStatus1.IsInCall leicht zu programmieren)
- Nebenstelle STATUS NICHT verfügbar (auch über GetExtensionStatus1.CurrentProfileName einfach umzusetzen)
- Nebenstelle ist SOFTPHONE / DESKTOP APP / WEBCLIENT NICHT angemeldet / Erreichbar (also keine Verbindung zur PBX, egal welcher Status (verfügbar, abwesend etc.) eingestellt ist).

Und bei diesen Punkt hängt es. Ich bekomme diese Abfrage nicht hin.
GetExtensionStatus1.CurrentProfileName gibt den STATUSNAMEN (verfügbar, dnd etc.) zurück( egal, ob die Nebenstelle online oder offline ist).
Welche Möglichkeiten bestehen sonst noch für diese Abfrage? Der Kunde hat bei verschiedenen Status unterschiedliche Weiterleitungsregeln. Möchte aber bei OFFLINE gesonderte Ziele haben und nicht die im jeweiligen Status hinterlegten Ziele. Es ist also nicht einfach möglich, die Abfrage zu ignorieren und an die Nebenstelle zu verbinden, wo dann die Weiterleitung für nicht erreichbar/besetzt greift. Zumal bei „Besetzt“ im Status „Verfügbar“ ein definiertes Ziel (zentrales Telefon) gewählt werden soll. Bei „nicht erreichbar“ bei „verfügbar“ soll aber an eine Rufgruppe weitergeleitet werden.

Kurzübersicht: (Nur Externe Anrufe)

Nebenstelle Verfügbar, Nicht im Gespräch, Online ==> Verbinden zur Nebenstelle
Nebenstelle Verfügbar, im Gespräch, Online ==> Verbinden zur Zentrale
Nebenstelle Verfügbar, - , Offline ==> Verbinden zur Rufgruppe
Nebenstelle DND, Online ==> Verbinden zur Zentrale
Nebenstelle DND, Offline ==> Verbinden zur Rufgruppe
 
Welche Möglichkeiten bestehen sonst noch für diese Abfrage?
mit einem CFD Baustein vom Typ Execute C# Code und folgendem Inhalt:
C#:
return ((Extension)PhoneSystem.Root.GetDNByNumber(extnr))?.IsRegistered ?? false;
wobei dem CFD Baustein mit der Variable extnr vom Typ String die Nummer der abzufragenden Nebenstelle übergeben wird oder ein String mit der Nummer der Nebenstelle (z.B. "200") fest eingebaut wird.

Nur wenn die Nummer wirklich eine Nebenstelle ist und ein Gerät daran aktiv registriert ist (das wäre die korrekte Bezeichnung), dann kommt true zurück - sonst false.

Wenn du wissen willst wo man so etwas findet, dann siehe die akt. offizielle 3CX v20 Dokumentation zur API Programmierung auf der 3CX (speziell in dieser Datei) unter TCX.Configuration / Interface: Extension / Properties.

Hinweise zum Verständnis:
  1. Auch im Status Custom 1 werden direkte Gespräche angenommen, also ggf. diesen auch berücksichtigen.
  2. Wenn Gespräche von einer RG bzw. WS an die NSt. geroutet werden, dann entscheiden in jedem möglichen Status die Optionen 'Anrufe von Rufgruppen annehmen' bzw. 'Abmelden von Warteschleifen' grds. über Annahme oder nicht. Den Stand dieser Optionen im jew. Status kann man auch wieder nur mit einem kleinen C# Code Schnipsel abfragen. Siehe in der oben verlinkten Doku unter TCX.Configuration / Interface Extension / Property: CurrentProfile / FwdProfile / Properties: DisableRingGroupCalls (Typ bool) bzw. ForceQueueStatus (Typ int32).
  3. Es können Ausnahmen in den Weiterleitungsregeln eingerichtet sein.
  4. Eine CFD App nimmt Anrufe immer an. Damit funktionieren evtl. einige Konstrukte nicht mehr.
    Die Ausnahme: ein reines C# Anrufskript was auf dem SIP Trunk triggert.
 
Zuletzt bearbeitet:
Vielen Dank fxbastler,

das scheint mir nach Kontrolle genau das zu sein, was ich gesucht habe. Und anscheinend sogar einfacher umzusetzen, als ich anfangs dachte. Testen bzw. Implementieren kann ich das leider erst morgen. Aber nach der Beschreibung tut die Abfrage genau das, was sie machen soll.
 
ich habe das jetzt umgesetzt und getestet, das verhalten ist wie gewünscht.
jedoch braucht die abfrage anscheind sehr lange zum verarbeiten.

vor den script hat der call flow ca. 4 sekunden gebraucht bis eine nebenstelle klingelt, mit den skript dauert das jetzt über 20 sekunden.
 
jedoch braucht die abfrage anscheind sehr lange zum verarbeiten.
Nicht wirklich. Diese eine Zeile C# Code als Abfrage dauert wenige ms.

vor den script hat der call flow ca. 4 sekunden gebraucht bis eine nebenstelle klingelt, mit den skript dauert das jetzt über 20 sekunden.
Dann war das Programm vorher schon suboptimal und wurde nicht besser. Keine Ahnung was du da gebaut hast, aber 4 Sekunden waren schon zu lang.
Eine CFD App die rein auf der 3CX läuft, ohne Audio, ohne künstliche Verzögerung und ohne externe oder Nutzerabfragen läuft i.d.R. immer weit weniger lange.

Anonymisisere das komplette CFD Projekt wenn nötig, packe das gesamte Projektverzeichnis und poste es bitte hier.
 
Ansich war das Skript nicht komplex.
Call Flow Log angehängt.

callflow$.DIDcut ==>
RIGHT(session.did,3)
(Assaign as Varible)


1769007214531.png
 

Anhänge

Zuletzt bearbeitet:
Hier das Projekt einmal.
Die Module werden noch später in Komponenten gepackt, ich hatte das zwecks fehlerquelle auseinandergezogen gehabt nochmal.
 

Anhänge

Hab das Skript grade in meiner Freizeit neu hochgezogen.
Was soll ich sagen jetzt läuft es. Ich habe im Kaputten CFD "E-Mail send" als Kontrollen drin, da scheint iwas das Skript zu killen obwohl überall nur ein "Kontrollpunkt: Verfügbar JA" als Subjekt steht.

Jedenfalls funktioniert die C# Abfrage wie gewünscht. Ich bedanke mich nochmals. Ohne den Hinweis das solche Skripte nur paar Bruchteile brauchen dürfen wäre ich nicht auf die Idee gekommen vom neuprogrammieren.
 
Hier das Projekt einmal.
Oje, ich glaube du hast da etwas falsch verstanden. Ich habe mir das angeschaut und:
Ich habe im Kaputten CFD "E-Mail send" als Kontrollen drin
das geht so gar nicht. Das macht man anders (s.u.), sonst passiert das:
da scheint iwas das Skript zu killen

Das
obwohl überall nur ein "Kontrollpunkt: Verfügbar JA" als Subjekt steht
ist bei dieser Menge an E-Mails und Verhandlungen mit dem E-Mail Server egal.

Hättest du das kpl. Projekt eher geschickt, dann hätte ich dir das schon eher geschrieben. Aber dann wäre dir das komplette Neuschreiben der CFD App entgangen ;)

Beim effektivem Verfolgen des Ablaufs von CFD Apps läuft es anfangs auf folgendes hinaus:
  1. zeitweiliges erhöhen der Protokollierungsstufe des 3CX Aktivitätenprotokoll:
    Admin / Systemübersicht / Aktivitätsprotokolle / Optionen / auf Ausführlich stellen
  2. das Protokoll verfolgen:
    1. verfolgen des 3CXCallFlow.log in Echtzeit im Betriebssystem, unter Linux:
      tail -f /var/lib/3cxpbx/Instance1/Data/Logs/3CXCallFlow.log
      unter Windows z.B. mit Notepad++ die Datei öffnen und unter Ansicht / Überwachen (tail -f) wählen (Alternativ in der Symbolleiste das Symbol Auge anklicken) oder etwas wie z.B. Baretail nutzen
      - ODER (z.B. bei gehostet) -
    2. Download der gesamten Logs der 3CX unter Admin / Systemübersicht / Suportinformationen, die SupportInfo.zip Datei entpacken und dort im Ordner Logs liegt ebenfalls die Datei 3CXCallFlow.log
Zusätzlich oder alternativ - je nach Einstellung und Bedarf - die CFD Komponente Logger einbauen und individuelle Texte in das Log schreiben lassen (an Stelle deiner E-Mails). Dazu gern auch die Funktion CONCATENATE nutzen und Strings und Variablen verketten.
Im Logger Level Info werden nur Zeilen in's Log geschrieben wenn die 3CX Protokollierungsstufe auf Maximum steht. Im Level Error werden immer noch Einträge in die Log Datei geschrieben auch wenn die Protokollierungsstufe nur auf Niedrig steht (so kann man das Log klein halten und nur wenige gezielte Ausgaben erzeugen).
Bei Verwendung des CFD Baustein Logger aufpassen: diese Bausteine in der produktiven Version oder zwischendurch deaktivieren um den Code schneller laufen zu lassen wenn man wirklich keine Ausgabe braucht (indbes. im Level Error).

Das ist der Weg.

Auch da gibt es noch Steigerungen.
 

Statistik des Forums

Themen
44.754
Beiträge
233.661
Mitglieder
78.497
Neuestes Mitglied
Support IDMC