Wir möchten Sie darüber informieren, dass wir Änderungen an den Asterisk Dialplan Befehlen vornehmen. Der Befehl “System” kann potenziell für Angriffe missbraucht werden, weshalb wir Maßnahmen ergreifen, um die Sicherheit unserer Systeme zu gewährleisten.
Ab dem 1. April 2024 werden wir den Dialplan Befehl “System” entfernen. Dieses Kommando wurde hauptsächlich in den Kombinationen “System(mail)” oder “System(curl)” benutzt. Um etwa automatisch eine Benachrichtigung per E-Mail zu versenden oder REST Anfragen an Dritt-Systeme weiterzugeben.
Als Ersatz für Ihre selbst angepassten Skripte oder Inline-Skripte empfehlen wir:
Nutzen Sie das Notification Feature in den Aktionen, welches eine sichere und effiziente Benachrichtigungsalternative bietet.
Ersetzen Sie “System(curl)” Aufrufe durch den Asterisk curl() Funktionsaufruf.
Sie müssen nichts unternehmen, falls Sie die Skriptfunktion nicht nutzen.
Am Tag der Deaktivierung wird der generelle Anrufverlauf nicht beeinträchtigt. Ihre Telefonanlage wird auch nicht abstürzen und es hat auch keine Auswirkungen auf alle unsere Standardfunktionen.
Wir empfehlen Ihnen, frühzeitig zu reagieren und gegebenenfalls erforderliche Anpassungen an Anrufverläufen vorzunehmen.
Prima, dass die Änderungen so frühzeitig kommuniziert werden. Das hilft sehr.
Zwei Gedanken dazu:
Die Notification Features sind für einfache Benachrichtigungen per E-Mail an den Benutzer oder ein Team gut, weil einfach einzurichten und in vielen Fällen mag das reichen Ein wirklich vollwertiger Ersatz sind sie so wie beisher umgesetzt allerdings auf keinen Fall. Das scheitert schon daran, dass man die E-Mail-Adresse für die Benachrichtigung nicht frei wählen kann. Vom Inhalt der Benachrichtigungen mal ganz zu schweigen.
Ein Anwendungsfall ist beispielsweise, dass Benachrichtigungen über verpasste Anrufe an ein Ticket-System geschickt oder anderweitig automatisiert verarbeitet werden sollen. Die E-Mail-Adresse des Ticket-Systems oder eines E-Mail-Parsers weicht aber in der Regel von der Adresse des Teams oder Benutzers ab.
Soweit ich das feststellen durfte, unterscheiden sich die Aufrufe zwischen System(curl) und Asterisk(curl) teilweise doch sehr, zum Beispiel was die Header für eine Authentifizierung oder den Post von Daten in einem bestimmen Formal angeht. Manche Dinge scheinen auch einfach überhaupt nicht machbar zu sein mit Asteriks(curl) oder es ist einfach nur wahnsinnig schlecht dokumentiert.
Daher fände ich Beispiele gut, die erläutern, wie man den Aufruf denn dann mit Asterisk(curl) macht. So scheint man für einen spezifischen Header anscheinend zusätzlich neben curl auch curlopt zu benötigen (das klassische Curl verwendet ja -H für diesen Zweck usw. Auch die Dokumentation der Pascom REST-API mit den CURL-Beispielen hilft dann ja nur noch bedingt, wenn man davon etwas innerhalb der Anlage verwenden möchte.
Durch diesen - aus Gründen der Sicherheit absolut nachvollziehbaren - Schritt wird die Möglichkeit, Webhooks aufrufen zu können, somit nun noch wichtiger. Schließlich gibt es immer mehr Web/Cloud-Anwendungen, die miteinander interagieren sollen und müssen. Es war bisher schon umständlich, das wird zukünftig dann wohl noch schwieriger werden, solange es keine adäquaten Alternativen gibt.
Dann bitte die Benachrichtigung per E-Mail noch ausbauen, dass man diese auf einen bestimmten Benutzer legen kann oder auch im IVR-System nutzen kann. Denn sonst fehlt uns eine wichtige Funktion!
könnte jemand so freundlich sein und mir erklären, was ich ändern muss. Aktuell habe ich: System(/bin/echo “${CALLERID(num):1}” | mail -s “Rückrufvermerk” test@test.de) als Inline Skript in der Warteschleife, was muss ich wie machen, damit es weiter funktioniert…?
Beste Grüße Ralph
Ich sehe das ähnlich Problematisch wie Michael, ich habe mit dem Support Wochen für einen API-Aufruf gebraucht, da Header nicht geklappt haben, und wir sind dann auf …${SHELL(/usr/bin/curl -m 1 https:/… umgestiegen. Das wird jetzt wohl nicht mehr klappen.
Ich würde mich auch über Beispiele freuen, wie man während des Anruf auf Externe API-s zugreifen kann, damit Labels richtig gefüllt werden.
Dort kann man die Warteschlange bzw. den Benutzer wählen, an den die Benachrichtigung verschickt wird.
Es wird dann eine generisch gehaltene E-Mail an die beim Team bzw Benutzer hinterlegte E-Mail-Adresse verschickt. Somit können die bisherigen Skripte im Prinzip entfallen.
Auf die Einschränkungen bin ich ja schon mal weiter oben ein wenig eingegangen.
Bzgl. der Möglichkeit, eine individuelle E-Mail-Adresse eintragen zu können, haben ich einen Workaround gefunden, der darin besteht, für diesen Zweck einen gesonderten Benutzer anzulegen und dort die E-Mail-Adresse zu hinterlegen, an welche eine Benachrichtigung geschickt werden soll.
Und damit dieser Nutzer sonst nirgends auftaucht, einfach über angepasste Rollen im Client ausblenden, nicht besonders schön, aber zumindest besser als nix.
Ich kann dazu gerne ein Video machen, falls das hilfreich und gewünscht ist.
So doof das klingen mag, ich habe die Funktion in Vorher, das hatte z.B. den Vorteil, dass ich auch bei den Kunden, die mal warten mussten, sehen konnte, dass diese angerufen haben bzw. in der Warteschleife waren. @Pascom, könnten ihr das da einbauen?
Wir rufen stellenweise im Dialplan die pascom REST-API auf und erhalten natürlich JSON-Daten, die wir dann mit jq aufbereiten. Kann man nach der Abschaltung die JSON-Daten Daten direkt im Dialplan verwenden?
Würde mich auch interessieren wie das jetzt gehen sollte. Habe auch Kunden wo das Script bei extern/vorher mit Verbindung eines Durchwahlschalters hinterlegt ist!
ich kann leider nicht sagen was alles noch eingebaut wird um die weggefallenen System aufrufe zu kompensieren, denke aber mal die Aktion auch an anderer Stelle verfügbar zu machen sollte kein Problem sein (natürlich meinerseits unverbindlich ).
In deinem Fall möchtest du ja auf verpasste Anrufe aufmerksam machen, wenn ich das richtig verstehe. Die “gelesen” Funtion im Client Journal zu den verpassten Anrufen ist hierfür bei euch nicht brauchbar?
Habe auch Kunden wo das Script bei extern/vorher mit Verbindung eines Durchwahlschalters hinterlegt ist!
@evoxic was passiert hier im weiteren Verlauf wenn der Durchwahlschalter aktiv ist?
Wenn der Anruf dann auch nicht mehr dem Team zugestellt wird, könnte man auf ein “Dummy-Team” (z.B. mit Namen nichtBesetzt oder was hier den Grund grob wiederspiegeln würde) abwerfen, ohne Mitglieder und “verlassen wenn leer” (müsste glaube ich der default sein). Dort kann man das dann in das Nachher packen (mit allen anderen gewünschten Aktionen).
Nicht unbedingt schön, aber würde erstmal wieder die Funktionalität bewahren.
Wir rufen stellenweise im Dialplan die pascom REST-API auf und erhalten natürlich JSON-Daten, die wir dann mit jq aufbereiten. Kann man nach der Abschaltung die JSON-Daten Daten direkt im Dialplan verwenden?
@Kai-Uwe die CURL() Funktion ist natürlich weiterhin nutzbar, jq steht dann aber nicht mehr zur Verfügung. Aber auch hier wäre die Frage was genau erreicht werden will und je nachdem ob dies anders von der PBX umsetzbar ist oder ggf gar nicht “von der PBX” verarbeitet werden sollte sondern an anderer Stelle.
@Steve Der Durchwahlschalter spielt nur eine Ansage ab und legt dann auf, aber der Kunde möchte hier eine Benachrichtigung per Mail. Das mit dem Team ist mir auch schon eingefallen und wurde schon getestet, ist ein bisschen umständlich - schön ist es nicht nein. Vorerst muss ich es dann halt so lösen.
Mir ist gerade aufgefallen, dass ich die Durchwahlschalter auch bei allen Benutzer hinterlegt habe! Das ist ein mega sch**** - sry
Feature Voting
Es wäre super wenn man die Aktionen Benachrichtigung noch im extern/vorher Kontext einbauen könnte.
Ja das ist mir bewusst.
Ich glaube du hast das jetzt nicht richtig verstanden, um was es hier geht.
Der Durchwahlschalter ist beim Benutzer bewusst hinterlegt, hier steuert er den AB wenn er auf Urlaub ist, es wird eine Ansage abgespielt und der User bekommt mittels Script einen E-Mailbenachrichtigung per Mail.
).