bug? - Prioritätserhöhung falsch bei asterisk 1.2.0?

[rob]

Hallo,

bis 1.2 0rc2 gingen folgende Zeilen problemlos:

[macro-stdexten]
exten => s,1,DBget(TARGET=CallForward/${MACRO_EXTEN})
exten => s,2,Goto(500)
exten => s,102,Dial(${ARG1},20)

exten => 500, ...

seit dem update auf 1.2.0 springt er aber immer in Prio 2 (und damit auch in die 500), egal, ob er den Wert in der Datenbank findet oder nicht. In die 102 geht er gar nicht. Im Moment lasse ich keine Weiterleitungen zu und springe interims-mäßig direkt in die 102 per Goto.

Hat jn. n ähnliches Problem?

 

[rbaer]

  -= Info about application 'DBget' =-

[Synopsis]
Retrieve a value from the database

[Description]
  DBget(varname=family/key[|options]): This application will retrieve a value
from the Asterisk database and store it in the given variable.
  Options:
    j - Jump to priority n+101 if the requested family/key isn't found.
  This application sets the following channel variable upon completion:
    DBGETSTATUS - This variable will contain the status of the attempt
                  FOUND | NOTFOUND
  This application has been deprecated in favor of the DB function.

In TFOT Seite 114 findest du ein Beistpiel wie man es jetzt machen sollte

exten => 678,1,Set(COUNT=${DB(test/count)})

Mit der alten Syntax musst du halt die Option j anhängen damit er springt.

Gruß,
Robert

 

[betateilchen]

Du kannst auch im [general] Kontext der extensions.conf mit dem Eintrag "priorityjumping=yes" das alte Springverhalten im gesamten Dialplan erzwingen.

New in Asterisk v1.2.0: If you don't want to modify options on each app that used to have jumping behavior, you can set "priorityjumping=yes" in the [general] section of extensions.conf which will enforce the old behavior globally. As far as the Dial() application is concerned you can control the behavior with the 'j' option (see below).

 

[rbaer]

@betateilchen

Interessant, woher stammt dein Zitat?

 

[betateilchen]

http://voip-info.org/wiki/index.php?page=Asterisk+cmd+Dial

 

[rob]

Ihr seid klasse - wollte gerade posten, dass das nicht nur DBGet betrifft, sondern den ganzen Dialplan - und schon war die Antwort da. Funzt jetzt wieder mit "priorityjumping=yes".

BTW:
Wie sind die jumps dann unter 1.2.0 realisiert, wenn der dialplan nicht auf priorityjumping=yes gesetzt ist?

Kann ich für Set mit der DB-Function dann auch ein priority jumping machen? Hat bei mir nicht geklappt (für: wenn nicht in DB vorhanden, dann n+101 oder so was ähnliches).

P.S.: ich änder mal den Titel, weil es ja das gesamte Priority jumping betrifft.

Gruß,

Rob

 

[betateilchen]

Man kann nach dem Ausführen von Befehlen einen Status abfragen, anhand dessen man testen kann, wie der Befehl geendet hat.

dazu gibt es zum Beispiel nach einem Dial() eine Variable ${DIALSTATUS}

Übrigens gibt es in den Asterisk-Sourcen unter /doc/UPDATES.txt (ich glaub so war der Name) eine Auflistung, was sich alles grundsätzlich geändert hat. Da sind auch einige Dinge dabei, die nicht abwärtskompatibel zu alten Dialplänen sind.

 

[rob]

Die updates.txt hatte ich mir angeschaut, aber von Veränderungen im jump-Verhalten hatte ich da nichts gesehen, zumal's mich wundert - mit dem rc2 hatte das alles noch wunderbar getan.

Gruß,

rob

 

[betateilchen]

Ich weiß nicht, ob das mit dem priorityjumping da drin steht, aber es haben sich noch ein paar andere Dinge geändert. Deshalb war das eher als allgemeiner Hinweis gedacht, falls noch jemand merkwürdige Phänomene an seinem Asterisk feststellt :wink:

 

[rbaer]

Wenngleich das mit dem "priorityjumping=yes" momentan dein Problem löst, solltest du nicht vergessen, dass ein deprecated darauf hindeutet, dass es die Applikation in Zukunft nicht mehr geben wird. Deshalb ist es meiner Meinung nach empfehlenswert, eine Umstellung des Dialplans auf die neue Syntax zumindest nicht aus dem Gedächtnis zu streichen. Umsomehr als es etliche neue Features gibt, welche die Arbeit erleichtern, so z.B der Wegfall der fortlaufenden Nummerierung. Dies dürfte auch die Ursache für das geänderte Jump Verhalten sein.

Gruß,
Robert .

 

[betateilchen]

Deshalb ist es meiner Meinung nach empfehlenswert, eine Umstellung des Dialplans auf die neue Syntax zumindest nicht aus dem Gedächtnis zu streichen.

Jepp - aber als "Sofortmaßnahme" wenn nach einem Update erstmal nix mehr so tut wie es soll, ist der Schalter schon ganz nützlich :wink:

 

[rob]

Hi,

danke Euch beiden.

Was ich jetzt noch bräuchte, wär n Beispiel/Template oder ne entsprechende Anleitung für den Aufbau eines Dialplans unter 1.2.0, v.a. was das Jumpverhalten angeht. Hab leider dazu noch nichts gefunden (zugegeben: ich hab nicht ewig gesucht). Habt Ihr so was?

 

[rbaer]

Meine erste Antwort enthält einen Link auf TFOT. Kapitel 6 sollte deine Fragen beantworten.

 

[betateilchen]

wär n Beispiel/Template oder ne entsprechende Anleitung für den Aufbau eines Dialplans unter 1.2.0

Schau Dir die extensions.conf.sample an, die mit den aktuellen Sourcen mitkommt.

 

[Guard-X]

Und wie soll das mit MySQL Realtime funktionieren, wenn ich überall die Prio "n" benutze?

 

[betateilchen]

Und wie soll das mit MySQL Realtime funktionieren, wenn ich überall die Prio "n" benutze?

gar nicht.

 

[Guard-X]

Also muss man mit Realtime weiterhin 1,2,3 weiterzählen...

 

[betateilchen]

ja - anders ist das nicht lösbar. Du kannst ja die Einträge in beliebiger Reihenfolge in die Tabelle schreiben, und beim Auslesen werden sie nach Context, Extension und Priority sortiert

Übrigens nicht nur bei MySQL so. Auch wenn Du den neuen LDAP-Treiber für die RT-Konfiguration verwendest, müssen die prios in der Datenbank eindeutig nummeriert sein.