dst im CDR setzen

[chrizzz]

Hallo! Habe hier ein kleines Problem, bei dem Ihr mir vielleicht helfen könntet!?

Ich habe ein Makro im Dialplan (ael). Z.B. das hier zum Raustelefonieren:

macro dialLine( fromext, toext){
        SET(CDR(dest)=toext);
        Dial(SIP/${toext}@12345);
        Hangup();
        return;
};

und rufe es hiermit auf:

_00[1-9]. => {
                &dialLine(CALLERID(num),${EXTEN:1});
        };

Funktioniert auch alles gut, nur habe ich danach im CDR im Feld "dst" nur ein "s" und nicht die anzurufende Nummer. Wo ist der Fehler? Gibt es einen anderen Weg, als das "SET(CDR(dest)=toext);"? Danke im Voraus für eure Hilfe

Christian

 

[rentier-s]

Hallo Christian,

das Feld heißt dst, nicht dest. Außerdem musst Du die Variable als solche kennzeichnen.

Also wenn dann so:

SET(CDR(dst)=${toext});

Aber mal ne andere blöde Frage, das Feld sollte doch eigentlich standardmäßig beschrieben werden, warum willst Du das überhaupt selbst setzen?

Svenja

 

[chrizzz]

Hi Svenja, danke für den Tipp mit der Variablen :spocht:

Ich habe einen Realtime-Asterisk mit MySQL-Anbindung und 'dst' wurde früher immer automatisch (richtig) gesetzt. Seit dem Umstieg auf AEL steht da immer "s" drin, egal ob ein- oder auswählend. Deshalb lag die Vermutung nahe, dass es an den Makros liegt...

Mit dem Set gehts auch nicht, ich bekomme ein

ERROR[26969]: cdr.c:311 ast_cdr_setvar: Attempt to set the 'dst' read-only variable!.

Hat vielleicht jemand eine Idee:
- Warum da ein "s" drinsteht
- Wie man das behebt?

Danke und Gruß

Christian

 

[abw1oim]

Leider fehlt Deine Signatur, aber ich würde tippen, dass Du Asterisk 1.6.x nutzt.
Und das führt in Verbindung mit Macros (in AEL) zu eben diesem von Dir beschriebenen Verhalten.

Es gibt nun (ausgehend von 1.6 und folgenden) mehrere alternative Möglichkeiten:

1. Macro aus AEL in conf-Style (also in die extensions.conf) überführen (das Verhalten sollte dann wie gewünscht/gewohnt aussehen)
2. Statt ein Macro einen Gosub verwenden (die ab 1.6 preferierte Methode), dabei dann das entsprechende Pattern für die EXTEN verwenden
3. Eine zusätzliche CDR-Variable kreieren (z.B.: CDR(mydest)) und mit dem gewünschten Wert belegen. Je nach gewünschtem CDR-Backend muss dafür noch die entsprechende Config bzw. DB angepasst werden, damit das Feld auch geschrieben wird

Was nicht funktioniert, ist das Setzen von CDR(dest), da es eine von vielen CDR-Variablen ist, die Read-Only sind, d.h. vom Dialplan aus nicht überschrieben werden können.

 

[chrizzz]

Hallo! Hab meine Signatur mal angepasst und mich an deiner orientiert :bier:

Also das GoSub würde ich so interpretieren:

context dialLine {

        _X. => {
                Dial(SIP/${ARG1}@whatever);
                Hangup();
                return;
        };
};

context fromInternal {
        _00[1-9]. => {
                Gosub(dialLine,${EXTEN:1},1(${EXTEN:1}));
        };
};

Juhu, damit funktionierts ganz gut! Leider gibts noch eine Warning im Log:

[Oct 11 23:44:01] WARNING[27439]: ael/pval.c:2522 check_pval_item: Warning: file /etc/asterisk/extensions.ael, line 54-54: application call to Gosub affects flow of control, and needs to be re-written using AEL if, while, goto, etc. keywords instead!

Ist das GoSub in AEL nun doch nicht Willkommen?

Christian

 

[abw1oim]

Im Kern war das so gemeint.
Das passt aber noch nicht ganz, so wird es richtiger:

context dialLine {

        _X. => {
                Dial(SIP/${EXTEN}@whatever);
                Hangup();
                return;
        };
};

context fromInternal {
        _00[1-9]. => {
                Gosub(dialLine,${EXTEN:1},1);
        };
};

Ich habe das hier gerade selbst noch einmal nachgestellt, und in dem Aufbau ist dst korrekt, also hier mit der Rufnummer verkürzt um die erste 0 (die ja auch nicht mitgewählt wird)

Ergänzug:
Diese Warnung beim Laden der extensions.ael ist ein uralter Streit, da sie aus Sicht mehrerer Leute da nicht hingehört: Entweder will man Subroutinen mit Return (statt Macros=, dann ist eine Warning Blödsinn, oder man will sie nicht. Dann darf man die Funktionalität aber nicht einbauen. Leider befindet sich die Entwicklergemeinde da immer noch in einer Unentschieden-Situation. Im Prinzip kann man die Warning aber einfach ignorieren.