.titleBar { margin-bottom: 5px!important; }

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

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von rob, 21 Nov. 2005.

  1. rob

    rob Mitglied

    Registriert seit:
    15 Feb. 2005
    Beiträge:
    399
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  2. rbaer

    rbaer Mitglied

    Registriert seit:
    7 Okt. 2004
    Beiträge:
    280
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    Code:
      -= 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
     
  3. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Du kannst auch im [general] Kontext der extensions.conf mit dem Eintrag "priorityjumping=yes" das alte Springverhalten im gesamten Dialplan erzwingen.

     
  4. rbaer

    rbaer Mitglied

    Registriert seit:
    7 Okt. 2004
    Beiträge:
    280
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    @betateilchen

    Interessant, woher stammt dein Zitat?
     
  5. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
  6. rob

    rob Mitglied

    Registriert seit:
    15 Feb. 2005
    Beiträge:
    399
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  7. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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.
     
  8. rob

    rob Mitglied

    Registriert seit:
    15 Feb. 2005
    Beiträge:
    399
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  9. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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:
     
  10. rbaer

    rbaer Mitglied

    Registriert seit:
    7 Okt. 2004
    Beiträge:
    280
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    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 .
     
  11. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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:
     
  12. rob

    rob Mitglied

    Registriert seit:
    15 Feb. 2005
    Beiträge:
    399
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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?
     
  13. rbaer

    rbaer Mitglied

    Registriert seit:
    7 Okt. 2004
    Beiträge:
    280
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    München
    Meine erste Antwort enthält einen Link auf TFOT. Kapitel 6 sollte deine Fragen beantworten.
     
  14. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Schau Dir die extensions.conf.sample an, die mit den aktuellen Sourcen mitkommt.
     
  15. Guard-X

    Guard-X Aktives Mitglied

    Registriert seit:
    14 Mai 2005
    Beiträge:
    2,497
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Aurich
    Und wie soll das mit MySQL Realtime funktionieren, wenn ich überall die Prio "n" benutze?
     
  16. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    gar nicht.
     
  17. Guard-X

    Guard-X Aktives Mitglied

    Registriert seit:
    14 Mai 2005
    Beiträge:
    2,497
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Aurich
    Also muss man mit Realtime weiterhin 1,2,3 weiterzählen...
     
  18. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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.