[Frage] sipsak, XML-Info und andere Ideen :)

Du willst es den Leuten aber komfortabel machen
Mir ist keine Möglichkeit bekannt das so umzusetzen. Ich würde eine Warteschlange (Queue) mit einer anderen Strategie als "ringall" machen, ganz nach Belieben. Dann klingelt es nicht immer bei allen gleichzeitig. http://www.voip-info.org/wiki/index.php?page=Asterisk+config+queues.conf

Na großartig. In den letzten Wochen meditiere ich ganz ähnliches. Hier bei uns geht es um Snom320, aber mein Anliegen ist dasselbe.

Es gibt diverse Threads hier im Forum, die Snom, BLF (d.h. blinkende LEDs), Pickup und Namensanzeige behandeln, leider häufig für Snom360/370. BLF und Pickup funtioniert wohl recht gut, die Namensanzeige nur selten. Noch viel seltener sind die Anzeigen auch korrekt.

Meine Idee ist, sipsak zu nutzen um an alle betroffenen Telefone genau die Information "12345678 > 11" zu schicken, falls 12345678 die 11 anruft. Mittels normalem Pickup soll der Anruf dann geholt werden können.

Betroffen in obigem Sinne ist ein Telefon, wenn in der sip.conf in seinem Kontext in pickupgroup eine Nummer auftaucht, die beim angerufenen Telefon als callgroup steht, was ebenfalls in der sip.conf definiert ist.

Um nun die Nachricht an betroffene Telefone zu schicken, muss ich blitzartig die IPs aller betroffenen Telefone wissen. Die IPs erhalte ich sehr schnell aus der AstDB. Offen ist, schnell alle betroffenen Nebenstellen zu ermitteln.

Vor den Dial müssen einmal die Nachrichten rausgehen, bei Rufannahme dann die zweiten Nachrichten, die leer sind, zum Zurücksetzen der Anzeigen.

Bis jetzt kann ich manuell per sipsak an ein Telefon eine Textnachricht schicken, allerdings nur ohne XML. Ich habe es noch nicht versucht, aber bezweifle, dass ein AGI-Skript derart performant ist, dass es die Textnachrichten schnell genug rausschickt. Wenn ja, wäre das erste Sahne, denn das wäre praktisch völlig versions- und patch-unabhängig(!!!).

Die zweite Möglichkeit, da das ja bei bristuff-ed Asterisken schon mit den LEDs funktioniert, wäre, direkt dort im Quellcode rumzufrickeln("Extension Changed XX new state Ringing for Notify User YY" oder "Extension Changed XX new state InUse for Notify User YY" oder "Extension Changed XX new state Idlefor Notify User YY"). Ich denke, dass der pkempgen-Patch genau das oder etwas Ähnliches tut. Ist aber alles irre aufwändig.

sisko-m schrieb:

Also erstmal zum Thema sipsak. Ich wäre ja schon fröh wenn ich dem Display des SNOM300 eine Anzeige meiner sipsak message abringen könnte. Wie hast Du es denn geschafft das hinzubekommen? Dann wär ich ja schon einen Schritt weiter.

Zum Vergrößern anklicken....

Das führt jetzt aber wirklich von XML weg, aber wenn's hilft... Ich habe hier - ohne XML und hier - mit XML rumgespielt. Bei ersterem war ich erfolgreich, nachdem ich, ich habe sipsak von der Kommandozeile der Asterisk-Servers gestartet, mittels -H noch die IP des Asterisk-Servers mitgeliefert hatte. Als SIP-Adresse war sip:NN@IPort anzugeben, wobei NN die Extension des Telefons war, das die Nachricht zeigen soll, IP dessen IP-Adresse und Port die Portnummer, unter der das Telefon mit dem Asterisk-Server spricht. Im zweiten Fall bin ich auch nicht weitergekommen. Die genauen Parameter für den Aufruf sind allerdings bis kommenden Donnerstag im Büro, aber vielleicht hilft Dir das jetzt schon.

sisko-m schrieb:

Ansonsten von der Idee her ist das ja im Prinzip genau das gleiche was ich vorhatte. Meine Überlegung war das ganze als freepbx Modul zu realisieren und dann als macro im dialplan einzubinden. Ich denke nicht das es da zu Performanceproblemen kommt. Einfach mit TrySystem das sipsak aufrufen und fertig. Müsste man aber erstmal testen.

Zum Vergrößern anklicken....

Von FreePBX verstehe ich nichts, daher arbeite ich "eine Etage weiter unten". Meine Idee ist, nachts aus der sip.conf per Skript einen persistenten Hash (gibt's in Perl) anzulegen, wo ich die angerufene Extension als Eingabeparameter nehme und eine Liste mit den betroffenen Extensions wieder rauskommt. Das AGI-Skript soll also diesen Hash benutzen um an die Liste der betroffenen Extensions zu kommen. Per AstManager dann schnell die IPs und Ports geholft, dann per Systemaufruf die Nachrichten, deren Text der zweite Eingabeparameter ist, verschickt und fertig. Zeitkritisch ist sicher der Systemaufruf, d.h. der eigentliche Aufruf von sipsak.

sisko-m schrieb:

Was den pkempgen patch angeht... Das geht aber meines Wissens eben nur dann wenn jemand per subscription eine oder mehrere extensions überwacht.

Zum Vergrößern anklicken....

Das hatte ich in meinem Vorposting vergessen: ja, ich habe diese Überwachung mittels Subsciption eingestellt.

sisko-m schrieb:

Ich dachte eben im ersten step daran das es doch jemanden geben muss der das Problem schonmal hatte und u.U. eine Lösung dafür parat hat

Zum Vergrößern anklicken....

Ich denke, wenn wir das performant und korrekt und am besten versionsunabhängig, ohne Quelltextgefummel hinbekommen, sind wir schon gar nicht so schlecht ;-). Die Bristuffer arbeiten ja auch an der Weiterentwicklung (vergl. das CHANGELOG des aktuell empfohlenen bristuff-patches 0.3.0-PRE-1y-p, wobei die am Transfer arbeiten.

Meine Überlegung dazu: kleine Server-App, die am Manager-IF des Asterisk "lauscht" und den Anruf dann an den entsprechenden Endgeräten signalisiert.

Die Zuordnung der Anrufe (wie beim Pickup) zu den Endgeräten würde in einer Datenbank der Server-App vorgenommen (beim Start der App sollte diese Tabelle geladen werden um nicht durch die Ausführungsgeschwindigkeit der Datenbank-Abfragen je Anruf ausgebremst zu werden).

Die App schickt dann (wie von euch beschrieben) UDP-Pakete zu den Snom-Endgeräten, und stellt dann Text im Display dar, oder signalisiert einen Pickup an einer Taste des Snom-Endgerätes wie im Snom-WIKI beschrieben.

SIPSAK skaliert bei einer grösseren Anzahl "zu bedienender" Endgeräte nicht gut, daher würde was benötigt, was direkt UDP-Pakete versenden kann (z.B. Java).

Von mir nochmal ein Versuch mit Hausmitteln: Auf jedem Telefon einen zweiten Account einrichten, in Snom Sprache also eine Identität. Bei dieser den Klingelton auf lautlos stellen. Im Asterisk eine Ringgroup machen mit genau diesen "Zweitidentitäten". Vor Anruf auf diese Ringgroup im Asterisk ein Set(CALLERID(name)=Achtung-${CALLERID(num)}) oder ähnliches machen. Jedenfalls irgendwie den Anruf markieren, damit er im Display von den Snoms erkannt wird.

OK, gestern habe ich meinen Ansatz teilweise umgesetzt: ein AGI-Skript, das einen persistenten Hash einliest, mit dem Managerinterface die jew. Telefon-IP mit Port abfragt und dann per sipsak eine entspr. Textnachricht an die betroffenen Telefone schickt. Da ich nur jeweils 5-8 Telefone informieren möchte, habe ich es in der kleinen beschriebenen Variante belassen. Zur Performancesteigerung ist der Erweierungsvorschlag von Foschi zu bedenken (Serverprogramm, Java für schnelle UDP-Pakete). Speedy1980s Vorschlag klingt auch interessant.

Abgesehen von den üblichen syntaktischen Kinderkrankheiten funktioniert es erstmal eigentlich. Merkwürdig ist, dass das Managerinterface manchmal "hängt".

Die nächsten Schritte wären, diese Kinderkrankheiten zu beseitigen und den persistenten Hash automatisch aus der sip.conf zu erzeugen. (Für meine Tests habe ich ihn manuell angelegt, aber eben dann als Datei persistent gespeichert.)

Anmerkung: die Textnachricht setze ich mittels ab, wobei $SIP von der Form "sip:$EXT@$IP:$Port" ($EXT=Extension, d.h. Identität des Telefons, das die Meldung erhalten soll, $IP= IP des Telefons, $Port=Port, unter dem sich Server und Telefon unterhalten) und $IP-Asterisk-Server die IP-Adresse des Asterisk-Servers ist. Vielleicht gelingt es so auch, Texte auf Snom300 abzusetzen.

@sisko-m:
Bist Du mit dem Verschicken von Textnachrichten weitergekommen?

generell:
Ich habe im zweiten Versuch Foschis Anregung aufgegriffen: eine Serverapplikation, die einen persistenten Hash einliest. In dem Hash steht, welches Telefon informiert werden möchte, wenn auf einer Durchwahl ein Gespräch ankommt. Des weiteren sind auch die IP-Adressen der Telefone in der Form "sip:NN@IP-Telefonort" hinterlegt. Diese Information wird benutzt, um sipsak zu bedienen. Leider musste ich das tun, weil das Manager-Interface manchmal so "hängt". Der Hash wird aus der sip.conf erzeugt und die IP-Adresse aus dem Manager-Interface. Die Erstellung ist damit nicht mehr zeitkritisch.

Der Server wird von einem Client gefordert, den ich in der extensions.conf in den Dialplan eingebunden habe. Das ist auch frickelig: vor dem Klingeln setzen, bei erfolgreichem Abnehmen löschen, bei Pickup durch jemand anderen löschen, bei Voicmail löschen. Das klappte bisher auch fast immer.

Es läuft bei mir momentan im "Lasttest", obwohl ich jeweils nur zwei bis sieben Telefone informieren muss. (Hat mehr eigentlich Sinn?) Ich beobachte das mal noch ein paar Tage und melde mich dann wieder. Bis jetzt sieht der zweite Ansatz aber vielversprechend aus. Ohne Patchen und ohne Versionsabhängigkeit.

Reichlich aufwendig, und wie gesagt, sipsak skaliert nicht sauber, wenn Du damit mal an 30-100 Endgeräten ein Besetztlampenfeld oder eine Displayanzeige realisieren magst ;-)

Natürlich macht es Sinn, dieses Konzept für mehrere Endgeräte , z.B. Server-übergreifend umzusetzen. Es gibt einige Betriebszustände im Asterisk, die Asterisk ansich zum Anhalten bringen (hohe Anzahl SIP-Subscriptions). Um ohne diese dann eine saubere Implementierung von Funktionen hinzubekommen ist mein Applikationsvorschlag dann gedacht...

Für das Manager-IF gäbe es dann noch den AstMan Proxy.

@sisko-m: Bei meinem Arbeitgeber haben wir die von mir oben beschriebene Funktionalität (als Besetztlampenfeld) für Kundeninstallationen bereits realisiert; der code entstand allerdings im Rahmen eines Werkvertrages.

Wenn ich mir mal anschaue was hier umgesetzt wurde, dann könnte das etwas sein was man als Arbeitsgrundlage nutzen kann (Voraussetzung, man kann in Java programmieren).

Mir scheint, dass die Diskussion langsam ins Unterforum Asterisk/Skripte abdriftet, aber egal.

@foschi:
Ich gebe Dir völlig recht, dass ich einen "Riesenaufwand" betreibe: doppelte Datenhaltung, schlechte Skalierung wg. Einsatz von sipsak, Perl ist nie so richtig schnell und revisionssicher und was weiß ich noch.

Aber hatte ich Dich mit Deinem Applikationsvorschlag falsch verstanden? Ich dachte Du meinst, dass ein Serverprogramm die - nennen wir sie - Notify-Anforderungen eines AGI-Skripts (=Client) entgegennimmt und an die betroffenen Telefone verschickt: eine Textnachricht oder ein Umsetzen des LED-Status. Schlecht, wenn per sipsak. (Noch schlechter, wenn, wie in meinem Fall, per Text und nicht per XML, aber mit XML habe ich's noch nicht hinbekommen.)

Ich sehe auch noch einige Verbesserungsmöglichkeiten bei meinem Ansatz:
- Versand von UDP-Paketen direkt (ohne sipsak), aber da fehlt mir das Wissen, wie das gehen soll
- Integration von AstManProxy, damit ich zumindest die Information über die Ziele (sip:[email protected]:5060) direkt aus der AstDB holen kann
- überhaupt: Integration in Asterisk

ABER: im Moment (ca. 20 Nebenstellen, wo jedesmal zwei bis fünf informiert werden müssen) tut das Ding (toi, toi, toi). Sowohl die LEDs blinken, dank bristuff und subscriptions als auch die Displays zeigen 123456 > 11, solange 123456 bei 11 anruft und es dort lediglich klingelt.

Lasst es mich noch eine Weile testen und verschlimmbessern, dann kann man ja weitersehen.

mögliche Weiterentwicklungen:
- Umleitungsfunktionalität in den Asterisk zu verlegen, dafür dann "Uml. zu: NN" im Display anzuzeigen. Das geht firmwaremäßig (7.1.30) in den snom360, nicht aber snom320.
- Ich habe im snom.wiki gelesen, dass wenn man mit der Textnachricht dem Telefon die Gesprächs-ID mitgibt, es auch während des Gesprächs Textnachrichten einblenden könnte. Dann könnte ich auch "*8", was nach Pickup angezeigt wird, durch die Original-Caller-ID ersetzen. Und dann wäre ich fertig und würde *nie* mehr updaten ;-)

anhalter42 schrieb:

- Versand von UDP-Paketen direkt (ohne sipsak), aber da fehlt mir das Wissen, wie das gehen soll
- Integration von AstManProxy, damit ich zumindest die Information über die Ziele (sip:[email protected]:5060) direkt aus der AstDB holen kann
- Sowohl die LEDs blinken, dank bristuff und subscriptions als auch die Displays zeigen 123456 > 11, solange 123456 bei 11 anruft und es dort lediglich klingelt.
- Umleitungsfunktionalität in den Asterisk zu verlegen, dafür dann "Uml. zu: NN" im Display anzuzeigen. Das geht firmwaremäßig (7.1.30) in den snom360, nicht aber snom320.
- Ich habe im snom.wiki gelesen, dass wenn man mit der Textnachricht dem Telefon die Gesprächs-ID mitgibt, es auch während des Gesprächs Textnachrichten einblenden könnte. Dann könnte ich auch "*8", was nach Pickup angezeigt wird, durch die Original-Caller-ID ersetzen. Und dann wäre ich fertig und würde *nie* mehr updaten

Zum Vergrößern anklicken....

Ich werde das Gefühl nicht los, daß du das Rad neu erfinden willst.

Guard-X schrieb:

Ich werde das Gefühl nicht los, daß du das Rad neu erfinden willst.

Zum Vergrößern anklicken....

Ich sparte mir auch viel lieber die Zeit, wenn ich wüsste, wo ich ein passendes und rundlaufendes Rad für Asterisk finde.

Und nun sagt nicht, dass ich nicht im Forum recherchiert hätte: es gibt div. Threads zu Snom, Pickup und LED. Pickup und LED funktioniert sehr häufig - auch dank Bristuff-Patch (auch wenn der, s. oben, nicht ordentlich skaliert). Aber in vielen Konstellationen geht eben diese Anzeige nicht oder nicht korrekt. In klassischen Anlagen geht es und mit denen muss ich, der ich Asterisk favorisiert habe (und es eigentlich auch nicht bereue), die Installation vergleichen lassen. Am Asterisk kann ich mangels C++-Kenntnissen, mangels ordentlichen Testsystems und Zeit nichts ändern.

Kurz: wenn jemand da was passendes und rundlaufendes hat: her damit.

anhalter42 schrieb:

- Versand von UDP-Paketen direkt (ohne sipsak), aber da fehlt mir das Wissen, wie das gehen soll

Zum Vergrößern anklicken....

Hier gibt's ein Beispiel in Java: http://www.sipcenter.com/sip.nsf/html/Compliance+Engine

Hinweis: falls die von mir oben genannte Applikation für jemanden interessant sein sollte (da fertig und im Produktivbetrieb) so bitte email an foschi (at) ip-phone-forum (.) de.

Die Applikation ist allerdings nur kommerziell verfügbar, da im Rahmen eines Kundenprojektes entstanden.