Enumlookup

[PURtel.com]

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.

Das sehe ich auch so. Die Gesamtarchitektur ist nicht glücklich gewählt ind wird sich für die Zukunft als untauglich erweisen.

Nur mal als gut gemeinter Tipp: Ich würde diese Architektur als Testversuch einmotten. Das kann man nämlich wirklich eleganter lösen.

 

[betateilchen]

Volker - wenn wir von Dir einen guten Rat brauchen, dann fragen wir Dich.
Bis zu diesem Zeitpunkt (an dem Ostern und Weihnachten mal gleichzeitig auf 1 Tag fällt), fordere ich Dich auf, Dich hier komplett rauszuhalten :!:

Die ganze Entwicklung dieses Skriptes ist nämlich nur deshalb notwendig geworden, weil Du ein Versprechen nicht eingehalten hast. Das ist genau das gleiche wie mit Deinen tollen Ankündigungen, die dann zu 90% sowieso nie das Licht der Welt erblicken.

Deshalb lassen wir uns dieses Skript von Dir auch nicht schlechtreden.

Ende der Durchsage :!:

 

[portunity.net]

@puretel: So hart wollte ich es nicht direkt formulieren ;-)

Man muß sehen: Das jetzige Script ist ja vermutlich auch nicht als die "Ultimative Lösung" entstanden, sondern als Versuch zur Selbsthilfe und vermutlich um erstmal zu schauen ob man es so überhaupt lösen kann (so war es zumindest bei uns als wir das lösen wollten).

Und die Jungs haben es soweit ja auch funktionsfähig hinbekommen - mehr noch, sie haben es veröffentlicht und anderen zugänglich gemacht. Das verdient erst einmal Respekt und Anerkennung.

Ich sehe das einmal als Version 1.0 - nur jetzt muß halt überlegt werden ob es überhaupt weiter gehen soll und man da auch mittelfristig noch am Ball bleiben will, welches Ziel man damit verfolgt und dann wie man das mit welcher Architektur am besten lösen will.

Für eine Version 2.0 sollte der Weitblick ein wenig erweitert werden (mehr wollen wir glaube ich ja gar nicht kommunizieren, nicht dass die Jungs uns das jetzt übel nehmen und keine Lust mehr haben ;-)).

Ist ja auch überhaupt die Frage, ob man das ganze nicht sogar besser in C als richtigen AGI-Befehl (z.B. EnumLookup2) implementiert und dem Asterisk-Projekt insgesamt besteuert oder man das weiterhin als AGI läst (und was ist, wenn dann mal ein EnumLookup2 von anderer Seite kommt ?).

Ich schlage deshalb wie gesagt vor, in das jetzige Script für die Unterstützung gleicher Prioritäten Lösungsansatz 2 zu implementieren (dann haben wir erstmal eine Lösung und die dürfte sich meiner Einschätzung nach noch am schnellsten umsetzen lassen) und dann einen vorläufigen Hacken an Version 1 zu machen (einmotten hört sich so böse an) und in aller Ruhe gemeinsam zu überlegen, wie Version 2 aussehen könnte.

 

[PURtel.com]

Bis zu diesem Zeitpunkt (an dem Ostern und Weihnachten mal gleichzeitig auf 1 Tag fällt), fordere ich Dich auf, Dich hier komplett rauszuhalten :!:

Fordern is´nich´!!!

Noch ein Tipp: Mal die Aussagen von Portunity.net beherzigen, - denn euer Ansatz ist für die Zukunft schlicht schlecht, - und mit dieser Meinung stehe ich ja nicht alleine da, - ich sags halt nur etwas offener...

Man kann das wirklich eleganter lösen...

 

[betateilchen]

[align=justify:dc5ab2d80d]
Information über neue Features - ok. Aber bitte keine "Vorschriften" - schon gar nicht, wenn uns da unsere eigenen Lösungsansätze empfohlen werden :!:

Im Gegensatz zu portunity.net und PURtel.com, die seit Monaten nämlich nur über die Lösung des ENUM-Problems reden und "man müßte mal" und "man sollte mal" und "man könnte mal" :motz: hat Benno sich auf einen Start-Tipp hin einfach mal ans Werk gemacht und sich was ausgedacht.

[schild=11 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]Benno MacGyver ist SUPER ![/schild]

Und unsere gemeinsame Lösung funktioniert wenigstens :!: - ganz im Gegensatz zum Intelligenten :?: :lach: ENUM von PURtel, das nämlich bis zum heutigen Tage überhaupt nicht richtig funktioniert ! Und obwohl dieser Mangel dort schon länger bekannt ist, ist bis heute kein Bestreben erkennbar, daß in diesem Punkt Abhilfe geschaffen werden soll.

Es ist auch bestimmt nicht die Intention des "enumlookup.agi" für irgendwelche kommerziellen Provider eine Lösung zu basteln, die denen "gefällt" oder deren "Pflichtenheft" entspricht.
[/align:dc5ab2d80d]

 

[PURtel.com]

@Udo:

bitte nicht aufregen.

Man kann an der Evolution teilhaben, oder die Evolution an sich vorüberziehen lassen.

Noch ein kostenloser (nicht kommerzieller) Tipp:

Wenn ich während einer Entwicklung erkenne, dass eine Architektur nicht geglückt ist, dann verwerfe ich diese und überlege mir eine bessere (angepasstere) Architektur.

Bitte als positive und konstruktive Kritik verstehen, und nicht gleich wieder ausrasten, denn wenn schon 2 unabhängige Entwickler ähnliche Aussagen treffen, dann sollte das zumindest zum Nachdenken anregen!

 

[betateilchen]

Alles was ich jetzt auf diesen Schwachsinn antworten könnte, wäre persönlich und angreifend - und wahrscheinlich mit meinem Ausschluß aus dem Forum verbunden. Deshalb schreibe ich einfach gar nix dazu.

 

[PURtel.com]

Alles was ich jetzt auf diesen Schwachsinn antworten könnte, wäre persönlich und angreifend - und wahrscheinlich mit meinem Ausschluß aus dem Forum verbunden. Deshalb schreibe ich einfach gar nix dazu.

Nein, das glaube ich nicht. Versuche doch einfach eine sachliche Ausdrucksweise zu finden. Die emotionellen Sachen kannst Du mir ja per PN, Email oder Telefon zustellen...

Jetzt mal im Ernst: Das Script an sich ist ganz nett, - doch sowohl Portunity.net, als auch ich beraten euch sicher nicht schlecht, mal eine andere Architektür in Betracht zu ziehen. Der Lösungsansatz mit dem "C-Modul" ist übrigens ganz schön heiß...

 

[betateilchen]

Ok - 4-5 Tassen Kaffee später - versuchen wir es nochmal sachlich.
[align=justify:f07153b13c]
Daß mir gerade eben in einer ( mit nachweislichen Lügen vollgestopften ) persönlichen Mail "unfaires Verhalten" gegenüber Providern vorgeworfen wurde, lassen wir jetzt einfach mal außer acht.

In diesem Thread hat portunity.net am 01.08.2004 folgendes geschrieben:
[/align:f07153b13c]

@all:

Wer mehr als einen Service-Eintrag aus einer ENUM-Zone per Asterisk in korrekter Reihenfolge auswerten und nacheinander anwählen will muß dazu "selbst hand anlegen" und darf nicht den integrierten ENUMLookup-Befehl verwenden.

"selbst hand anlegen" bedeuted hier ein kleines AGI-Script schreiben was per dig den Request selbst macht (wie oben bereits von jemanden geposted), auswertet und mehrere Variablen an Asterisk zurückgibt die dann per Goto entsprechend ausgewerted werden können (alternativ die Priorität verändert).

Wir haben dies in unserer Firmen-Asterisk erfolgreich implementiert, der Aufwand ist aber mit "nicht mal eben" zu beziffern und erfordert auch entsprechende Programmierkenntnisse.

Für's erste einfach Routing und für die ersten Gehversuche mit ENUM sollte der bestehende Lookup von Asterisk aber ausreichen. Ansonsten bleibt nur auf eine Erweiterung des bestehenden Asterisk-ENUMLookup-Cmds zu hoffen.

[align=justify:f07153b13c]
Das von Benno entwickelte Skript ist also exakt das, was ein

denn wenn schon 2 unabhängige Entwickler

Entwickler vorgeschlagen und als Vorgehensweise empfohlen hat.

Und genau dieser Entwickler versucht hier nun klarzumachen, daß wir das Skript in die Tonne treten sollen, weil es künftig nix taugt.

Da verzichte doch dankend auf weitere "gute Ratschläge" und mache mir meine eigenen Gedanken über die weitere Vorgehensweise. Wobei natürlich grundlegende Veränderungen bei Anbietern schon mit berücksichtigt werden.

Ich hoffe, daß durch diese Erläuterungen einigermaßen verständlich wird, worin sich mein hier geäußerter Ärger begründet. Es geht nicht darum, jemanden persönlich oder durch unsachliche Bemerkungen anzugreifen. Aber wenn man die Entwicklung und die eigentliche Notwendigkeit der Erarbeitung des Skriptes hier im Forum verfolgt, ist es schon verwunderlich, daß sich jetzt ausgerechnet die beiden professionellen, die sich in Sachen ENUM bis jetzt am weitesten mit zum Teil leeren Worthülsen aus dem Fenster gehangen haben, hier auftreten und die Sache in Grund und Boden schimpfen.

Im übrigen will ich noch anmerken, daß meine Äußerungen in den letzten Postings in diesem Thread ausschließlich meine eigene Meinung waren und ich selbstverständlich nicht für Benno sprechen kann & will. Für mich jedenfalls macht das Skript auf meinen beiden Servern exakt das, was es soll und ist die perfekte Lösung nach der ich seit über 2 Monaten gesucht hatte.
[/align:f07153b13c]

 

[wrrdlbrrmpft]

Die Gesamtarchitektur ist nicht glücklich gewählt ind wird sich für die Zukunft als untauglich erweisen.

Ist gut möglich.

Nur mal als gut gemeinter Tipp: Ich würde diese Architektur als Testversuch einmotten.

Zum jetzigen Zeitpunkt werd ich es weiterhin verwenden, da ich keine bessere Alternative kenne. Das originale EnumLookup wird sicher irgendwann weiterentwickelt. Zum jetzigen Zeitpunkt ist es jedoch kaum zu gebrauchen. Sollte es mal was Besseres von anderer Seite geben, ist mir das nur Recht.

Der Lösungsansatz mit dem "C-Modul" ist übrigens ganz schön heiß.

Das sollen andere machen. Ich baue meine Skripte nach eigenen Vorlieben während eines kleinen Teils meiner Freizeit. Für meine Zwecke ist Shell-Programmierung sehr gut geeignet.

Auf die Streitereien möchte ich nicht weiter eingehen. Es soll jeder das benutzen, was ihm gefällt. Das ist auf einer Open Source Plattform selbstverständlich.

@ purtel und portunity.net: Wenn ihr Alternativen zu meinem Skript habt, immer raus damit. Das interessiert mich auch.

@ betateilchen: Wenn ich was Neues hab, melde ich mich. Zur Zeit bin ich wie gesagt noch anderweitig stark eingebunden.

 

[wrrdlbrrmpft]

Hier gibt es eine neue Testversion. Wenn sie sich als brauchbar erweist, werd ichs nach vorne schieben.

Das ist neu:

- Telefon-Einträge mit gleicher Priorität werden in einer einzigen Variablen ENUMENTRYn zurückgeliefert und durch & verknüpft.

- Mailto-Einträge mit gleicher Priorität werden in der Form
mailto:user1@domain1,user2@domain2,...
zurückgeliefert

- Das tel: Prefix entfällt. Es wird nur noch die Nummer zurückgeliefert, es sei denn man definiert eine Variable ENUMTELPREFIX, z. B. folgende Definition könnte sinnvoll sein:

SetVar(ENUMTELPREFIX=CAPI/msn/:B)

- Es gibt noch zwei neue Variablen ENUMIAXPEER und ENUMSIPPEER. Wenn diese Variablen definiert werden, dann werden IAX- bzw. SIP-Einträge in der Form
IAX2/${ENUMIAXPEER}/IAX-Eintrag
bzw.
SIP/${ENUMSIPPEER}/SIP-Eintrag
zurückgeliefert. Damit kann man festlegen, über welchen Provider (oder Account) man telefonieren möchte.

- h323-Untersützung wurde implementiert, allerdings hab ich damit keine Erfahrung. Da müsste mir nochmal jemand einen Tipp geben, wie ein h323-Dial-Kommando typischerweise aussieht.

- mailto-Einträge werden immer so behandelt, als hätten sie eine niedrigere Priorität als die iax-, sip-, h323- oder tel-Einträge mit der gleichen Priorität. Das heißt, dass mailto-Einträge nicht mit Einträgen zum Telefonieren verknüpft werden. Damit kann man verhindern, dass mailto-Einträge im Dial-Kommando auftauchen.

- Vorwahlnummern (Mehrwertnummern) können in enumagi.conf gesperrt werden.

Ich bitte wiedermal um Tests.

Danke!
Benno

EDIT: Vielleicht interessiert sich noch jemand für meinen Dialplan. Ich hab leider keine Kommentare drin, dafür vielleicht den einen oder anderen Fehler. Voicemail wurde implementiert.

exten => _50.,1,SetVar(ENUMEXTEN=49${EXTEN:2})
exten => _50.,2,SetVar(ENUMSEPARATETEL=YES)
exten => _50.,3,SetVar(ENUMSIPPEER=mysippeer)
exten => _50.,4,agi,enumlookup.agi
exten => _50.,5,GotoIf($[${ENUMENTRIES}]?6:31)

exten => _50.,6,SetVar(EINTRAG=1)
exten => _50.,7,Goto(11)

exten => _50.,11,GotoIf($[$[${ENUMENTRY${EINTRAG}:0:3} = IAX] | $[${ENUMENTRY${EINTRAG}:0:3} = SIP]]?
12:31)
exten => _50.,12,Dial(${ENUMENTRY${EINTRAG}},,T)
exten => _50.,13,SetVar(EINTRAG=$[${EINTRAG} + 1])
exten => _50.,14,GotoIf($[${EINTRAG} <= ${ENUMENTRIES}]?11:31)
exten => _50.,15,Hangup

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)

exten => _50.,31,GotoIf($[${ENUMTELENTRIES}]?32:51)
exten => _50.,32,SetVar(EINTRAG=1)
exten => _50.,33,SetVar(COUNT=2)
exten => _50.,34,BackGround(beep)
exten => _50.,35,BackGround(0)
exten => _50.,36,BackGround(${ENUMTELENTRY${EINTRAG}:${COUNT}:1})
exten => _50.,37,SetVar(COUNT=$[${COUNT} + 1])
exten => _50.,38,GotoIf($[${LEN($ENUMTELENTRY${EINTRAG})} - ${COUNT}]?36:33)

exten => _50.,51,Playback(beep)
exten => _50.,52,Macro(callwithvoip,SIP/,mysippeer/,${EXTEN:1},mysipid)

exten => *1,1,SetVar(EINTRAG=1)
exten => *1,2,Goto(_50.,33)
exten => *4,1,SetVar(EINTRAG=$[${EINTRAG} - 1])
exten => *4,2,Goto(_50.,33)
exten => *5,1,Macro(callwithvoip,SIP/,mysippeer/,0${ENUMTELENTRY${EINTRAG}:2},mysipid)
exten => *6,1,Goto(_50.,37)
exten => i,1,Playback(invalid)
exten => i,2,Hangup

Wer genaueres dazu wissen möchte, der frage mich.

 

[betateilchen]

Test läuft bereits ...

 

[wrrdlbrrmpft]

Durch den Ausfall ist hier meine letzte fehlerhafte beta-Version verloren gegangen. Dann poste ich einfach mal meine neueste, die hoffentlich nun das tut, was sie soll.

 

[thorsten.gehrig]

Hi
zu euer obigen diskussion muss ich euch mal ein lob aussprechen
ich persönlich finde die scripts toll, genial, super, geil.

da für mich keine anderen möglichketen zur verfügung stehen finde ich das "gelaber" von wegen schlechter ansatz usw. einfach mist.
Wenn "jemand" einen besseren Ansatz public macht wird es einen "fairen" Wettbewerb geben - der Anwender wird entscheiden....

Die Punkte "Gewichtung" und ähnlichen schnick schnack sind vielleicht mal in 5 Jahren interessant - wenn VoIP auch mal verbreitet ist. Derzeit ist die paralellwahl von mehrern Nummern mit selber Prio schon deluxe - und mehr als die meisten brauchen werden (und dann noch in relation zu den wenigen enum-nutzern überhaupt).,

Zur umsetzung im Script (ich hab das aktuelle noch nicht getestet): für meinen teil mache ich ein Enum-Lookup und wenn dieser erfolglos war wähle ich direkt (bisher eigentlich zu 100% meiner Zielrufnummern).
Bei erfolgreichem Enum-Lookup sollte die Enum-Inteligenz eures scripts greifen - evtl. mit Ansage. Die Idee mit der Sperrung der Sonderrufnummern im AGI ist im übrigen auch genial - Enum auf eine teurere Nummer wird niemand brauchen (wenn sowas Aufkommt wird das eher als Inovationsbremse angenommen werden).

Zum schluss nochmal ein dreifaches
Hip-Hip-Hura Hip-Hip-Hura Hip-Hip-Hura
für eure Arbeit!

Gruß
Thorsten

 

[wrrdlbrrmpft]

Schön, dass es doch Leute (außer betateilchen natürlich) gibt, die mit meinem Skript was anfangen können.

Wenn "jemand" einen besseren Ansatz public macht wird es einen "fairen" Wettbewerb geben

In wieweit kann man bei Open Source überhaupt von "Wettbewerb" reden? "Wettbewerb" aus Spaß an der Freude lasse ich selbstverständlich gelten.

Nun möchte ich doch noch was zu den negativen Kritiken loswerden:

1. Im Gegensatz zu poortel.com bin ich der Meinung, dass sich die Architektur (Shell-Skript) für diese Aufgabe als äußerst günstig erweist. Mit C hätte ich den Funktionsumfang aus dem Stehgreif nicht hinbekommen, schon gar nicht mit 179 Zeilen.

2. Zitat aus http://www.ip-phone-forum.de/forum/viewtopic.php?t=2358

Tipp kam von PURtel.com : "Frag doch mal ENUMLOOKUP mehrmals hintereinander ab !"

Wenn das das Geheimnis von "Intelligent ENUM" ist, dann gebe ich diesen kostenlosen (nicht kommerziellen Tipp):
Ich würde diese Architektur als Testversuch einmotten. Das kann man nämlich wirklich eleganter lösen.

So, dabei belass ich es aber auch. Eigentlich wollte ich nur sagen, dass ich mit meinen Testläufen fertig bin und Version 0.14 freigebe. Fehlerberichte und Erfolgsmeldungen bitte mir nicht vorenthalten!
Wer mit den Neuerungen nichts anzufangen weiß, kann mich selbstverständlich fragen. Ich denke aber, dass das meiste klar sein dürfte.

Gute Nacht!
wrrdlbrrmpft

 

[wrrdlbrrmpft]

ENUMTELPREFIX war in 0.14 wirkungslos, hatte ich vergessen zu implementieren.
Version 0.15 behebt dieses Problem.

Zum Testen kann man nun auch eine debug-Option in extensions.conf setzen. Diese wird einfach hinter den agi-Aufruf eingefügt mit dem Pipe-Symbol als Trennzeichen, etwa so:

exten => _50.,4,agi,enumlookup.agi|debug

Dadurch werden die ENUM-Einträge Zeile für Zeile in /tmp/debug geschrieben. Das ist zum Ausprobieren ganz nützlich, da man dann alle zurückgelieferten Einträge auf einen Blick hat.

 

[speedy1980]

Kurze Vorgeschichte: Asterisk als Gateway für SIP, IAX, H323, ISDN und ENUM an einer Fachhochschule. Kein separater SIP-Proxy (wie z.B. SER) für die SIP-Clients, aber das nur nebenbei. ENUM-Domains laufen, alle FH-Nummern sind da per Platzhalter drin. Auszug aus einer Bind9-Zonendatei (hab die Nummern und die Domain unkenntlich gemacht, wer es zu Testzwecken wissen will möge sich melden):

* NAPTR 10 10 "u" "E2U+iax2" "!^\\+49xxxxx(.*)$!iax2:[email protected]/\\1!" .
* NAPTR 10 20 "u" "E2U+sip" "!^\\+49xxxxx(.*)$!sip:\\[email protected]!" .

Mit diesen 2 Zeilen sind alle Nummern der Domain per IAX2 und SIP erreichbar. Asterisks ENUMLOOKUP kommt mit den Platzhaltern klar und wählt korrekt, Telefonate von sipgate.de auf die Nummern funktionieren auch.
Allerdings kommt das AGI-Script in Version 0.15 hier damit nicht klar. Die Platzhalter werden nicht vernünftig ausgewertet. In /tmp/debug erscheinen unter anderem folgende Zeilen:

ENUMENTRIES:
IAX2/[email protected]/\1&SIP/\[email protected]

Das kann man sicher ändern, oder? Ich bin nicht gerade der Shell-Script Crack, eher PHP
Tja sagt mir wie ich helfen kann das Problem zu lösen. Machbar ist es ja sicher.

 

[wrrdlbrrmpft]

Hallo speedy1980,

die Platzhalter werden zur Zeit noch nicht ausgewertet. Wenn ich die Domain per PN zugeschickt bekäme, würde mir das weiterhelfen. Ich würde die Daten auch nicht weitergeben.
Allerdings kann ich nicht versprechen, dass ich das Problem in absehbarer Zeit beheben kann. Ich habe momentan wenig Zeit für dieses kleine Skript und möchte mich daher mit Versprechen nicht zu weit aus dem Fenster lehnen.

Vielen Dank für die Unterstützung!
Benno

 

[betateilchen]

So - heute nacht habe ich vielleicht mal Zeit, das Skript "nach" der Version 0.13 endlich mal ausgiebig zu testen - wenn ich Dich richtig verstehe, muß ich die 0.14 nicht weiter berücksichtigen :wink:

 

[wrrdlbrrmpft]

@betateilchen: Ja, 0.14 kann man eigentlich vergessen.
Für die allow und disallow in enumagi.conf sollte man auch Bereiche, z. B. [0-9] auswählen können. Alternativ kann man X für [0-9], Z für [1-9] und N für [2-9] verwenden, wie bei den extensions. Du findest dich da sicherlich zurecht. Der debug-Parameter ist sicherlich ganz hilfreich. Hab ich ja weiter oben schon geschrieben.

Also dann viel Spaß und gute Nacht!
Ich hau mich jetzt gleich aufs Ohr.