Prioritäten bei mehreren Matches

[IEEE]

Hallo,

Ich beobachte gerade das Verhalten bei mehreren matchenden Patterns. Mir war das bisher nicht so 100% klar und auch die Dokus und Bücher gehen da für meinen Geschmack nicht viel darauf ein (oder ich habs nicht kapiert).

Jedenfalls bemerke ich folgendes Verhalten.

Beispiel (nicht besonders elegant, aber hilfreich um mein Anliegen darzustellen):

[beliebiger-kontext]
exten => _test123.,1,SipAddHeader(Remote-Party-ID: <sip:nur-zum-testen@hostname>)

exten => _test1234,1,noop(daswirdausgefuehrt)
exten => _test1234,2,noop(daswirdausgefuehrt2)

Laut show diaplan (hab hier eine Asterisk 1.2 Version) wird _test123. vor _test1234 priorisiert.
Wenn nun jemand test1234 anruft, dann werden diese beiden extensions quasi zusammengeführt. Nachdem die erste Priorität von _test123. ausgeführt wurde, wird in die zweite Priorität von _test1234 gesprungen. Die Priorität 1 von _test1234 wird nicht ausgeführt. Sieht dann so aus:

-- Executing SIPAddHeader("SIP/10-b5a05130", "Remote-Party-ID: <sip:nur-zum-testen@hostname>") in new stack
-- Executing NoOp("SIP/10-b5a05130", "daswirdausgefuehrt2") in new stack

Was ich mich nun frage:

- Kann man davon ausgehen, dass man sich auf dieses Verhalten verlassen kann? Also auch in künftigen Versionen?
- Ist es sinnvoll mit diesem Verhalten zu taktieren? Zum Beispiel könnte man allen möglichen extensions sicherheitshalber ein paar "NoOp Prioritäten" voranstellen, um dann später mittels _. oder _X. mal so eben etwas einzufügen (Sipaddheader ist da eh ein gutes Beispiel).

Freu mich auf eure Meinungen und hoffe die Fragen sind nicht allzu blöd.

 

[rentier-s]

Hallo IEEE,

das Thema ist zwar schon ein paar Tage alt, aber ich bin über was Ähnliches gestolpert. Ich finde die Stelle nicht mehr, aber irgendwo in den Changelogs meine ich gelesen zu haben, dass sich das Verhalten ab einer der 1.4 (?) Versionen geändert hat. Die Patterns werden nicht mehr der Reihe nach abgearbeitet, bis eine passt, sondern Asterisk sucht nach der größtmöglichen Übereinstimmung.

Ein Anruf auf 1234 mit

exten => _1.,bla,blub
exten => _12.,dies,jenes
exten => _123.,nichts,weiter

wird demnach höchst wahrscheinlich in der _123. landen. Wenn ich Zeit finde, probier ich das mal aus.

Das Verhalten, das Dein Asterisk an den Tag legt, kommt mir jedenfalls seltsam vor.

Svenja

 

[Deleted member 193577]

Die Patterns werden nicht mehr der Reihe nach abgearbeitet, bis eine passt, sondern Asterisk sucht nach der größtmöglichen Übereinstimmung.

Ja, so ist das jedenfalls bei *1.6. Das Thema hat mich kürzlich ebenfalls beschäftigt. Nachgelesen habe ich hier.

Das Verhalten, das Dein Asterisk an den Tag legt, kommt mir jedenfalls seltsam vor.

Auf den ersten Blick seltsam, aber auf den zweiten Blick aber durchaus denkbar. Die erste passende Übereinstimmung ist

test123.

Asterisk 1.2 entscheidet sich - laut Asterisk-Buch - immer für die erste passende extension. Nachdem die Priorität 1 verwendet wurde, springt Asterisk zur Priorität 2. Scheinbar ist dieser Sprung in *1.2 zulässig, vermutlich weil das pattern

test1234

immer noch passt. Ein wenig seltsam ist das aber schon.
Das ist aber nur eine Vermutung, so interpretiere ich dieses Beispiel jedenfalls. Leider kann ich das mangels *1.2 nicht nachstellen.

Bei 1.6 kann man sich darauf verlassen, dass zunächst ein Kontext komplett eingelesen wird und die größtmögliche Übereinstimmung Anwendung findet.


Gruß
R.

 

[ViennaAustria]

Wir arbeiten überall mit Asterisk 1.4. Dort ist es so, dass der "longest match" zieht, also das Pattern mit den meisten übereinstimmenden Stellen. Beim Beispiel mit

_1
_12
_123

halt der unterste _123. Wichtig ist aber, dass man den Block nach Erledigung terminiert. Also z.B. ein Hangup() oder so. Vorsicht: auch ein Dial() kehrt zurück, wenn der angerufene auflegt!

Terminiert man einen Block nicht, verzweigt die Asterisk nach Abarbeiten vom _123 Zweig in den _12 und dann in den _1. Ich weiss keine Anwendung, wo das Sinn machen würde.