Enumlookup

[wrrdlbrrmpft]

Ja, funktioniert auch mit älteren.

Version 0.13 wird noch eine Änderung beinhalten:
- /etc/asterisk/enum.conf wird nun ausgewertet. Das heißt, dass dort etwas in der Art

search => e164.arpa
search => e164.org

stehen muss. Wenn Fragen dazu bestehen, bitte melden!

 

[betateilchen]

Also das Skript 0.13.beta läuft auch auf "alten" Asterisk-Versionen - prima

Das mit der enum.conf ist eine gute Idee !

Aber dazu hätte ich gleich noch eine Anregung:

1.) aus den Einträgen bitte kein "MUSS" machen - wenn dort kein "search" zu finden ist, dann sollte eben "e164.arpa" angenommen werden. Das ist bei vielen Asterisk-Konfigs so - es ist ein Standardwert im Source definiert, der ggf. mit einem "gefundenen" Wert aus der conf-Datei überschrieben wird

2.) die Variablen ENUMDNS und ENUMSEPARATETEL ( und meine ENUMALLOWTEL :wink: ) könnte man evtl. auch dort mit reinpacken.

3.) es wäre zu überlegen, ob die Datei wirklich "enum.conf" sein sollte (denn die ist ja nun per se schon definiert) oder ob man nicht eine neue "enumagi.conf" einsetzt.

Alles nur Ideen, die mir dazu einfallen. Die 0.13beta läuft jedenfalls prima.

 

[wrrdlbrrmpft]

Ja gut, dann warte noch einen Moment!

 

[betateilchen]

ich gehe jetzt erstmal frühstücken bis später !

PS: kannst die "beta" wieder rausnehmen. Und heute Nacht gibts wahrscheinlich auch neue "Dialpläne"

 

[wrrdlbrrmpft]

Lass dir dein Frühstück schmecken!

Ich habe mich entschieden, zunächst nur ENUMDNS in die enumagi.conf zu verlagern, um die Flexibilität der anderen beiden Variablen nicht unnötig einzuschränken. Es kann ja durchaus vorkommen, dass der eine die tel-Einträge separat, der andere lieber mit sip, iax und mail vermischt haben möchte.

Ich hatte bisher noch keine Gelegenheit für großartige Tests. Feedback von freiwilligen Testern ist mir daher sehr willkommen.

 

[betateilchen]

Getestet und für gut befunden

Den Wiki-Beitrag http://www.voip-info.org/tiki-index.php?page=Asterisk+and+multiple+ENUM+entries habe ich bereits entsprechend überarbeitet und die 0.13 auf die Download-Seite gepackt.

Im Wiki-Beitrag sind auch die aktualisierten Dial-Pläne (Vorschläge) für die extensions.conf enthalten - da muß ich die nicht 2 Mal posten. Wer sich dafür interessiert, bitte dort nachschauen.

 

[betateilchen]

Der bisher fehlende und versprochene Dialplan für den Script-Aufruf mit "ENUMSEPARATETEL=yes"

Sobald es hierzu grundlegende Änderungen gibt, werden diese nur noch im Wiki veröffentlicht, damit ich nicht 2 Versionen "pflegen" muß.

[enum]
exten => _**.,1,SetVar(ENUMEXTEN=49${EXTEN:3})
exten => _**.,n,agi,enumlookup.agi
exten => _**.,n,GotoIf($[${ENUMENTRIES}]?11:4)
exten => _**.,n,GotoIf($[${ENUMTELENTRIES}]?31:91)

exten => _**.,11,SetVar(EINTRAG=1)
exten => _**.,n,GotoIf($[$[${ENUMENTRY${EINTRAG}:0:3} = SIP] | $[${ENUMENTRY${EINTRAG}:0:3} = IAX]]?13:21)
exten => _**.,n,Dial(${ENUMENTRY${EINTRAG}},10,r)
exten => _**.,n,SetVar(EINTRAG=$[${EINTRAG} + 1])
exten => _**.,n,GotoIf($[${EINTRAG} <= ${ENUMENTRIES}]?12:31)

exten => _**.,21,GotoIf($[$(ENUMENTRY${EINTRAG}:0:4} = MAIL]?22:31)
exten => _**.,n,SetVar(EINTRAG=$[${EINTRAG} + 1])
exten => _**.,n,GotoIf($[${EINTRAG} <= ${ENUMENTRIES}]?12:31)

exten => _**.,31,SetVar(EINTRAG=1)
exten => _**.,n,GotoIf($[$[${ENUMALLOWTEL} = yes] & $[${ENUMTELENTRIES}]]?33:99)
exten => _**.,n,Playback(beep)
exten => _**.,n,Wait,3
exten => _**.,n,Dial(SIP/${ENUMTELENTRY${EINTRAG}:4}@sipprovider,10,r)
exten => _**.,n,SetVar(EINTRAG=$[${EINTRAG} + 1])
exten => _**.,n,GotoIf($[${EINTRAG} <= ${ENUMTELENTRIES}]?33:99)

exten => _**.,91,GotoIf($[${ENUMALLOWTEL} = yes]?92:99) ; sind Telefonanrufe zugelassen ? Wenn Nein -> Auflegen in 99
exten => _**.,n,Playback(beep)
exten => _**.,n,Wait,3
exten => _**.,n,Dial(SIP/${ENUMEXTEN}@sipprovider,30,r)

exten => _**.,99,Hangup

 

[wrrdlbrrmpft]

:cry: Heute gibts keine neue Version. :cry:

@betateilchen: Wenn du heute Nacht nicht schlafen kannst, liegts nicht an mir.

 

[betateilchen]

Heute gibts keine neue Version.

Die 0.13 ist schon so gut, daß da nicht mehr viel zu machen ist - komm wir gehen ein :bier: trinken

 

[wrrdlbrrmpft]

Gute Idee! Prost!

 

[portunity.net]

Die 0.13 ist schon so gut, daß da nicht mehr viel zu machen ist - komm wir gehen ein trinken

@betateilchen: so schnell seid ihr jetzt aber noch nicht fertig *g*

Wir waren zwischenzeitlich auch nicht ganz tatenlos. Seit heute gibt es in unserem Webinterface im Produktivbetrieb für die DNS-Zone die Möglichkeit, mehreren Services auch die gleiche Priorität zu vergeben. Wir haben dies über eine Checkbox geregelt, wird diese aktiviert, erhält der jeweilige Service die Priorität des jeweils vorherigen Services ! Man kann damit natürlich auch drei oder vier Services "zusammenschalten".

Eine bessere Variante ist uns adhoc nicht eingefallen, Feedback und Vorschläge sind aber gerne welcome (evt. aber besser einen eigenen Thread unter ENUM).

Damit sollte nun zumindest von unserer Seite die Voraussetzung da sein, z.B. zwei oder drei SIP-Adressen gleicher Priorität abzulegen (z.B. Büro und Home-Nummer) die dann (bei entsprechender Unterstützung Eures AGIs) dazu verwendet werden können, dass alle drei Zieladressen (auch SIP, IAX usw. gemischt sollte möglich sein !) gleichzeitig klingeln (im Asterisk Dialplan einfach mit & aneinanderhängen) - wer als erster abnimmt hat dann das Gespräch...

Auf geht's ;-)

 

[betateilchen]

Damit sollte nun zumindest von unserer Seite die Voraussetzung da sein, z.B. zwei oder drei SIP-Adressen gleicher Priorität abzulegen (z.B. Büro und Home-Nummer) die dann (bei entsprechender Unterstützung Eures AGIs) dazu verwendet werden können, dass alle drei Zieladressen (auch SIP, IAX usw. gemischt sollte möglich sein !) gleichzeitig klingeln (im Asterisk Dialplan einfach mit & aneinanderhängen) - wer als erster abnimmt hat dann das Gespräch...

Heute ist :bier: Abend - wir werden auch dafür noch eine Lösung finden :wink:

Richtig umständlich wird es allerdings, wenn auch noch einer einen tel: Eintrag auf die gleiche Priorität legt :-(

 

[portunity.net]

Richtig umständlich wird es allerdings, wenn auch noch einer einen tel: Eintrag auf die gleiche Priorität legt

Aber möglich ist dies lt. Protokoll ja - ich will Euch ja nicht den Spass verderben, aber "Richtig umständlich" kommt erst noch danach, denn es gibt neben der Priorität ja dann auch noch die Gewichtung (setzen wir aber jetzt auch erstmal immer gleich).

Wobei mir auch noch nicht ganz klar ist, wie man die dann umsetzen will. :gruebel: Das eine Ziel-Telefon etwas mehr oder lauter klingeln lassen als das andere geht ja schlecht ;-)

Einzige Lösung bei einer unterschiedlichen Gewichtung wäre, in Abhängigkeit der prozentualen Unterschiede die Anrufe zwar gleichzeitig, aber zeitversetzt ablaufen zu lassen (also wenn Gewichtung unterschiedlich, dann erste SIP-Adresse mit höchster Gewichtung geht sofort, zweite setzt nach 3 Sekunden parallel ein usw.).... soviel zum Thema "Richtig umständlich" :twisted:

Vielleicht ist jetzt verständlich, warum wir die "Intelligenz" vom Dialplan in das Script verlagern wollten und unsere Lösung bislang nicht Public gemacht hatten... - wir wollten halt alles auf einmal ;-).

 

[betateilchen]

und wir wollen das Ding so halten, daß auch der normale Anwender noch schrittweise nachvollziehen kann, wie es grundsätzlich funktioniert und dann Schritt für Schritt weiterlernen kann.

Eine nochmalige Diskussion wie zu Anfang der ENUM-Geschichte, in der überhaupt niemand wußte, was das ist und wozu das überhaupt gut ist, sollte man auf jeden Fall vermeiden. Deshalb macht eine "Überfrachtung" gleich zu Anfang einer Anwendung keinen Sinn.

 

[portunity.net]

und wir wollen das Ding so halten, daß auch der normale Anwender noch schrittweise nachvollziehen kann, wie es grundsätzlich funktioniert und dann Schritt für Schritt weiterlernen kann.

Wie gesagt: Wir haben genau diese Überlegungskette bereits hinter uns ;-) Wir sind zum Schluss gekommen, dass eben aus dem Dialplan rauszunehmen und ins Script zu verlagern und lediglich noch über ein paar Parameter zu steuern. Bei einigen Asterisk-Befehlen weiß man ja auch nicht mehr so genau, wie diese im Detail genau funktioniert und programmiert sind (interessiert auch nicht wirklich), und man setzt die trotzdem ein. Ich denke hier reicht dem Anwender doch "input rein und mach mal".

Wobei Eure Lösung und Ansatz ja deshalb jetzt nicht schlecht ist - im Gegenteil. Hauptsache es tut sich was und es geht vorwärts.

Eine nochmalige Diskussion wie zu Anfang der ENUM-Geschichte, in der überhaupt niemand wußte, was das ist und wozu das überhaupt gut ist, sollte man auf jeden Fall vermeiden. Deshalb macht eine "Überfrachtung" gleich zu Anfang einer Anwendung keinen Sinn.

Das sehen wir auch so. Wobei man auch sagen muß, dass ein Teil der Diskussion ja eben wegen mangelnder Unterstützung der Service-Prioritäten entstanden ist (hätten alle die Prioritäten von Anfang an laut RFC implementiert, hätte es zumindest einen Teil der Diskussion rund um die Prioritäten gar nicht erst gegeben).

Aber der vorherige Beitrag bzgl. der Unterstützung der Gewichtung war, auch wenn es technisch diese wirklich gibt, nicht als ultimative Aufforderung gedacht (sonst müssten wir das ja auch noch implementieren ), sondern eher als Teil zur Unterhaltung und kleiner Ausblick was noch theoretisch so in ENUM steckt...

Ich denke eine Unterstützung gleicher Prioritäten in Eurem Script / Dialplan macht schon noch Sinn (auch für den Anwender, weil er wirklich Zeit spart bzw. es so eine neue Möglichkeit darstellt !) und die Gewichtung sollte man erstmal in der Tat weglassen. Wäre auf jeden Fall sehr schön wenn Ihr das noch hinbekommen würdet...

 

[thorsten.gehrig]

Hi
der vorschlag mit dem paralellklingeln ist wirklich nicht schlecht.
Ich habe z.B. in meinem Dialplan es so eingerichtet:
anruf von extern (auf meiner ISDN-Nummer)
-> ruf an allen internen Telefonen (eine SIP, 4 ISDN-BRISTUFF-Nebenstellen)
-> gleichzeitig ruf an mein Mobiltelefon (über spezielle MSN - so sehe ich dass es ein "weitergeleiteter" anruf ist)
-> ruf an externe SIP (im Büro)

wer zuerst rangeht hat das gespräch - kann aber natürlich auf die anderen nummern vermitteln :-D

Allerdings: wenn ich mir das so überlege - wenn mich ein "anderer" gleichzeitig per SIP (büro+zuhause) und ISDN (zuhause) und auf dem Mobile anruft wird es zumindest zuhause schwer das kostenlose SIP gespräch entgegen zu nehmen - (woran soll ich das erkennen)....

gruß
thorsten

 

[wrrdlbrrmpft]

Ich hab das jetzt nur mal kurz überflogen, da ich im Moment anderweitig beschäftigt bin. Das Skript lässt sich natürlich leicht anpassen. Ich werd mich die nächsten Tage nochmal melden.

wrrdlbrrmpft

 

[wrrdlbrrmpft]

Also, mehrere Einträge mit gleicher Priorität sind kein Problem. Wie sollte das denn aussehen. Ich hätte folgende Vorschläge:

i) Die Priorität wird vor den ENUM-Eintrag gehängt. Die zurückgelieferten Variablen ENUMENTRYn könnten dann z. B. so aussehen:
001/IAX2/user@host/extension
Vorteil: sehr flexibel, übersichtlich
Nachteil: evtl. etwas mehr Aufwand im Dialplan

ii) Eine andere Möglichkeit wäre, dass man einzelne Einträge schon in enumlookup.agi zusammenfasst. Die Priorität müsste dann nicht mit zurück geliefert werden.
Vorteil: evtl. relativ einfache Realisierung im Dialplan
Nachteil: Werden, abhängig vom Eintrag, bestimmte zusätzliche Parameter benötigt, wird es sehr kompliziert und unübersichtlich.

iii) Als letztes hätte ich einen weiteren Parameter (ENUMSHOWPRIO) in enumagi.conf anzubieten. Wird der auf YES gesetzt, dann gilt i), ansonsten ii).
Vorteil: sehr flexibel
Nachteil: Dokumentation wächst beträchtlich. Das wirkt abschreckend auf potentielle Anwender, ich weiß das.

Falls jemand bessere Vorschläge hat, immer her damit. Ich tendiere momentan zu i).

Was die Gewichtung betrifft, da warte ich erstmal ab.

 

[betateilchen]

Benno, ich denke seit ein paar Tagen darüber nach, wo und wie das am besten "vorzusortieren" ist. Sobald ich mal meine Gedanken dazu geordnet habe, kriegst Du ne email von mir. Die letzten Tage hatte ich auch paar andere Dinge zu tun und konnte mich nicht so intensiv mit der Aufgabenstellung befassen.

 

[portunity.net]

Gewichtung solltet Ihr auch erstmal weglassen. Wird zumindest von unserem Webinterface eh noch nicht unterstützt und der praktische Nutzen ist noch nicht ganz einzuschätzen.

Wir hatten in unserer PHP-Lösung in einer ersten Version auch mit Lösungsansatz II gearbeitet, was besseres war uns auch nicht eingefallen.

I+III wären die Hölle geworden wenn man das für alle Protokolle usw. und für beliebig viele Eintrage gleicher Priorität usw. implementieren will (vor allem bei späteren Änderungen usw.).

Sofern Ihr das Gesamtkonzept (einfaches AGI-Script, Fallunterscheidungen usw. dafür im Dialplan, für Nutzer noch nachvollziehbar) vorläufig so aufrechterhalten wollt, werdet Ihr um Lösung II nicht drum herumkommen.

Andere Lösung wäre eben (da waren wir akt. bei unserer PHP-Lösung dran), im Dialplan nur noch den AGI-Aufruf einzusetzen und die Gesprächsanwahl (bei gleicher Prio gleichzeitig, dann nacheinander usw.) usw. vom AGI-Script aus zu initieren. Damit sind dann I, II und III obsolet und wegsubstituiert und man hat dafür in seiner verwendeten Programmiersprache es ein wenig einfacher, mehr Möglichkeiten usw. (wobei unser Script auch bereits ~2000 Zeilen sind mitlerweile).

Ein anderes Problem ist, dass mit den zurückgelieferten Ergebnis Eures Script im Moment jeder mehr oder weniger seinen eigenen individuellen Dialplan baut. Ich denke dies wird langfristig zu einem Problem. Wenn Ihr ein neues Feature In Euer Script einbaut (Unterstützung z.B. mal für H323, SMS, FAX usw.... denkt mal weiter !) - wie wollt Ihr die User dazu bewegen immer wieder am Diaplan rumzuschrauben ? Ich glaube das wird langfristig nichts, weil die Masser zu träge sein wird (vor allem wenn ein Stand erreicht ist, wo es für den User halbwegs funktioniert) und es wäre besser da zu zentralisieren. Nur das Script updaten, dass macht die Masse noch so gerade mit.