Enumlookup

[wrrdlbrrmpft]

Version 0.16-beta1:

- Reguläre Ausdrücke in NAPTR records sollten nun funktionieren

- SIPPEER und IAXPEER wurden durch neue Variablen ersetzt, siehe ChangeLog

- Man kann nun auch Prioritäten bis 999999999 vergeben, wenn das überhaupt möglich ist. Vielleicht kann da jemand anders was zu sagen.

Für Testergebnisse vielen Dank im Voraus!
Benno

 

[speedy1980]

Klasse, funktioniert! Zumindest die regulären Ausdrücke gehen, ich mache jetzt mal weitere Tests.

Noch eine Frage: Auf
http://www.voip-info.org/tiki-index.php?page=Asterisk+and+multiple+ENUM+entries
steht, dass die einzelnen Einträge in ${ENUMENTRY1},${ENUMENTRY2} und so weiter stehen würden. Bei mir sind jedoch alle Einträge in der ersten Variable. Hab ich meine Prioritäten im DNS falsch drin oder muss das im Script so? Ich hab mich an http://www.ietf.org/rfc/rfc3761.txt gehalten, unter 4.1 gibts ein Beispiel.

 

[wrrdlbrrmpft]

Bei mir sind jedoch alle Einträge in der ersten Variable. Hab ich meine Prioritäten im DNS falsch drin oder muss das im Script so?

Das Skript wertet das fünfte Feld aus der dig-Abfrage aus, also das, was hinter NAPTR kommt. So werden die Prioritäten jedenfalls zur Zeit bei portunity.net gesetzt. In der Domain, die ich von dir bekommen habe, waren beide Einträge auf 10 gesetzt. Daher werden sie vom Skript in einem Eintrag zurückgeliefert (Ausnahme: mailto).

rfc2915 beschreibt das fünfte Feld wie folgt:

Order
A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field).

Damit ist dann wohl auch die Frage geklärt, ob 999999999 ausreicht. In der nächsten Version wird der Wert dann wieder auf 99999 verkleinert. Preferences (sechstes Feld) werden (noch) nicht ausgewertet.
Wenn du Einträge mit unterschiedlichen Preferences gerne in unterschiedlichen Einträgen haben möchtest, kann ich das auch noch anpassen. Das ist subtrivial (7 Zeichen zusätzlich).

EDIT: Ach, was solls? Einfach diesen patch einspielen!

 

[thorsten.gehrig]

Hi
wofür sind nochmal die preferences?
Danke im vorraus.
Gruß
Thorsten

 

[speedy1980]

Ja ist richtig, da steht aber auch:

The preference field specifies the order in which records SHOULD
be processed when multiple NAPTR records have the same value of
"order".

Außerdem: http://enum-center.de/article16785.html (RFC 3761 ersetzt 2916)
Deswegen hatte ich mich an das Beispiel im letzteren RFC gehalten, und da war das Beispiel so drin. Gut, ich hab mich wohl nicht genug damit beschäftigt ....
Naja ich hab testweise meine DNS Einträge mal umgestellt damit es auf jeden Fall funktoniert, soll heißen das "Order" Feld hab ich angepasst.
Den Patch teste ich gleich mal aus.
Danke für die schnellen Reaktionen!


EDIT: Klasse, jetzt macht das AGI es so wie ich es wollte
Einen kleinen Schönheitsfehler hats dann aber noch: Ich hab einen Eintrag für IAX und einen für IAX2 im DNS drin. Im Script wird aus IAX aber IAX2, steht auch in /tmp/debug so drin. Ist das gewollt?

 

[speedy1980]

Hi
wofür sind nochmal die preferences?
Danke im vorraus.
Gruß
Thorsten

Die preferences regeln die Priorität zwischen Einträgen mit gleicher order-Priorität. Beispiel:
10 10 --> IAX2
10 20 --> IAX
20 10 --> SIP
In dem Beispiel würde für IAX/IAX2 die gleiche Priorität im order-Feld haben, aber unterschiedliche Prioritäten im preferences-Feld. Die RFC besagt, dass die Reihenfolge im order-Feld eingehalten werden MUSS, die Reihenfolge im preferences jedoch nur ein SOLLTE (eingehalten werden) ist.
Ein Client könnte jetzt also IAX2 und IAX als gleiche Priorität erkennen und den Eintrag seiner Wahl zuerst versuchen. Danach wird der SIP-Eintrag dann abgearbeitet. Implementiert er jedoch die RFC vollständig, so sollte er erst IAX2, dann IAX, und als letztes SIP versuchen.

 

[wrrdlbrrmpft]

Entschuldigung! Ich hatte die falsche Datei gepatcht. Ich hab den patch nun ausgetauscht. Man kann sich aber auch gleich Version 0.16 ziehen. Da hab ich das dann übernommen.

Einen kleinen Schönheitsfehler hats dann aber noch: Ich hab einen Eintrag für IAX und einen für IAX2 im DNS drin. Im Script wird aus IAX aber IAX2, steht auch in /tmp/debug so drin. Ist das gewollt?

Das hab ich deshalb so gemacht, weil man bei portunity.net übers web-interface keine iax2-Einträge anlegen kann. Mal sehen, was man da noch machen kann.
In Version 0.16 kann man ausnutzen, dass es zwei Variablen ENUMIAXPREFIX und ENUMIAX2PREFIX gibt. Wenn hier nichts explizit angegeben wird, wird ENUMIAXPREFIX der Wert IAX/ und ENUMIAX2PREFIX der Wert IAX2/ zugewiesen. Ich werde für mich zunächst ENUMIAXPREFIX ebenfalls auf IAX2/ setzen.

 

[speedy1980]

Entschuldigung! Ich hatte die falsche Datei gepatcht. Ich hab den patch nun ausgetauscht. Man kann sich aber auch gleich Version 0.16 ziehen. Da hab ich das dann übernommen.

Ich hatte es eh per Hand gepatcht, deswegen funktionierte es bei mir. Hab dann aber jetzt die Version 0.16 neu runter geladen.

In Version 0.16 kann man ausnutzen, dass es zwei Variablen ENUMIAXPREFIX und ENUMIAX2PREFIX gibt. Wenn hier nichts explizit angegeben wird, wird ENUMIAXPREFIX der Wert IAX/ und ENUMIAX2PREFIX der Wert IAX2/ zugewiesen. Ich werde für mich zunächst ENUMIAXPREFIX ebenfalls auf IAX2/ setzen.

Feine Sache, bei mir funktioniert das jetzt so. Ich hätte dann soweit keine Verbesserungsvorschläge... Ich beschäftige mich in den nächsten Tagen mal mit den "mailto" Einträgen im Wählplan, im Thread hier war ja schon ein Denkansatz drin. Mal sehen wann das bei mir "in Produktion" gehen kann damit die Nutzer auf meinem Asterisk die Funktionalität nutzen können.

 

[wrrdlbrrmpft]

Zum mailen benutze ich sowas hier:

exten => _50.,21,GotoIf($[${ENUMENTRY${EINTRAG}:0:6} = mailto]?22:31)
exten => _50.,22,Playback(vm-nobodyavail)
exten => _50.,23,Playback(vm-intro)
exten => _50.,24,Playback(beep)
exten => _50.,25,Monitor(wav,/tmp/nachricht)
exten => _50.,26,MeetMe(20,pqs)
exten => _50.,27,System(nail -a /tmp/nachricht-in.wav -s Voicemail ${ENUMENTRY${EINTRAG}:7} < /dev/null)

Dazu muss man natürlich auch einen entsprechenden Konferenzraum eingerichtet haben, aber das ist ja überhaupt kein Problem.

 

[speedy1980]

Ja genau an so eine Lösung hatte ich gedacht. Nur noch etwas verfeinert, z.B. mehrere Konferenzräume, damit nicht 2 gleichzeitige Anrufer im gleichen landen etc, eventuell Text in der e-mail.
Dann überleg ich noch, ob ich URL's von http Einträgen im DNS vorlesen lasse, aber das ist vielleicht schon wieder zuviel. Na mal sehen.

 

[wrrdlbrrmpft]

@ betateilchen: Ich habe dein wiki editiert. Ich hoffe, das geht in Ordnung.

Viele Grüße!
Benno

 

[wrrdlbrrmpft]

Version 0.22 ist draußen. Kann es leider nicht selber testen.

Viele Grüße!
Benno

 

[speedy1980]

Schön dass es immer noch weiter geht. Bei mir läuft das Agi ohne Probleme. Danke und weiter so!

PS: Auf der Mailingliste zu Asterisk oder um Bugtracker hab ich was von einem ENUMLookup-Patch gelesen. Vielleicht kann Asterisk ja demnächst selbst mit mehreren Einträgen umgehen. So flexibel wie das Agi hier wirds aber wohl so schnell nicht werden.

EDIT: Habs gefunden, weiss aber nicht was draus geworden ist: http://lists.digium.com/pipermail/asterisk-dev/2005-February/009415.html

 

[wrrdlbrrmpft]

Ich bin schon seit vielen Monaten nicht mehr auf dem aktuellen Stand, hätte nun aber vermutet, dass enumlookup.agi längst überflüssig geworden ist. So viel scheint sich in der Zeit aber dann doch nicht getan zu haben.

Bei mir läuft das Agi ohne Probleme.

Das freut mich zu hören. Version 0.21 konnte nicht mit geschweiften Klammern in regulären Ausdrücken umgehen. Das sollte nun behoben sein. Der Bugfix ist nicht von mir.
Dann ist mir noch aufgefallen, dass die Variablen ENUMH323PREFIX und ENUMMAILTOPREFIX möglicherweise nicht korrekt ausgewertet wurden.
Mein Asterisk Projekt ist leider vorerst auf Eis gelegt. Deshalb kann ich es selber momentan nicht ausprobieren. Wenn man mich mit Fehlerberichten oder neuen Ideen versorgt, bin ich aber trotzdem bereit weiterzumachen.

Vielleicht kann Asterisk ja demnächst selbst mit mehreren Einträgen umgehen. So flexibel wie das Agi hier wirds aber wohl so schnell nicht werden.

Früher oder später wird sich wohl jemand finden, der den Asterisk dementsprechend anpasst, wenn ENUM mal Erfolg haben sollte. Ein Vorteil von unserem Skript ist natürlich, dass sich sehr gezielt Nummern sperren lassen. Vielleicht wird man auch diese Idee übernehmen wollen.

Ich wünsche allen hier noch frohe Ostern und niedrige Telefonrechnungen!
Benno

 

[lo4dro]

Hallo.

Leider versteh ich nicht, wie das script die enum werte abfrägt.
Ich nutz die Österreichiche Testnummer. Mit den Asterisk Boardmittel funktionierts.
mit dem agi-script nicht.

Nun hab ich versuch das Script zu verstehen.
Allerdings Versteh ich nicht wie die DNS Abfrage realisiert wurde.
Vielleicht hat ja jemand einen Tipp

 

[betateilchen]

es kommt darauf an, auf welcher E164.domain die Nummer registriert ist. Soweit ich das in erinnerung habe, kann man das in /etc/asterisk/enumagi.conf einstellen, welche DNS-Server abgefragt werden.

Die Abfrage an sich erfolgt über den Befehl "dig"

 

[lo4dro]

Danke betateilchen.
Wenn ich das richtig verstehe gibt es ein Programm das "dig" heist.
Ich hab auf meinem Debian System und Google nach diesem Programm gesuch.
Kannst du mir verraten was man installiren muss?

 

[betateilchen]

das dürfte in den "bind-utils" sein, wenn ich mich recht erinnere

 

[lo4dro]

Hab es gefunden.
Das teil heist "dnsutils"
Jetzt gleich mal das enum-script testen

 

[lo4dro]

So ich muss das hier noch mal aufwärmen.

Ich bekomm meine echte Tel-Nummer die ich hinterlegt habe nicht angezeigt.
Also per "dig 5.6.5 .... .e164.arpa naptr" wird mir unter anderem
"E2U+tel" "!^.*$!tel:+4978.....!" angezeigt.
Im /tmp/enumdebug fehlt diese Nummer.
Woran könnte das liegen?