CallerID auf anderem Telefon anzeigen mit GS idle Screen

[dasgute]

Hallo,

habe hier zwei GXP2020 Telefone an einem Asterisk Server. Seit Firmware 1.1.6.44 soll ja das dynamisierte Anzeigen des GS Idle Screen gehen.

Ich möchte folgendes erreichen. Wenn Telefon 1 angerufen wird dann soll auf dem Telefon 2 auch die Nummer des anrufenden im Diplay eingeblendet werden bis Telefon 1 abhebt.

Die Dokumentation von Grandstream ist ja wie immer eher dürftig. Nirgendwo kann ich was dazu finden. Am besten wäre irgend ein Beispiel wie sowas zu implementieren ist.

Mit Firmware 1.1.6.46 soll das ganze um mehrere Parameter erweitert worden sein und besser funktionieren.

Hat das schon mal wer versucht und kann mir nen Tipp geben? Ich weiß nicht wo ich anfangen soll.

Über Invite hab ich das schon versucht aber das ist nicht optimal.

Display CallerID from remote phones on GS idle screen ist das was ich brauche.

Vielen Dank für jeden Tipp...

 

[Chaotux]

Ich möchte folgendes erreichen. Wenn Telefon 1 angerufen wird dann soll auf dem Telefon 2 auch die Nummer des anrufenden im Diplay eingeblendet werden bis Telefon 1 abhebt.

Also das Telefon ist erstmal recht "dumm". Es kann nur ein SIP NOTIFY entgegennehmen und holt sich dann einen neuen Idle-Screen ab. Den musst Du dann irgendwie dynamisch per PHP oder sonstwie erstellen.

In /etc/asterisk/sip_notify.conf musst Du folgende Zeilen hinzufuegen:

[grandstream-idle-screen-refresh]
Event=>x-gs-screen
Content-Length=>0

An der Asterisk Commando-Zeile kannst Du dann mit "sip notify grandstream-idle-screen-refresh sipname1 sipname2" die Telefone sipname1 und sipname2 dazu anweisen sich einen neuen Idle-Screen zu holen. Das geht natuerlich auch per AMI. Dazu muss die ganze Zeit ein Daemon laufen, der die AMI-Events beobachtet und wenn es klingelt halt die entsprechenden Nachbartelefone benachrichtigt.

Die Dokumentation von Grandstream ist ja wie immer eher dürftig. Nirgendwo kann ich was dazu finden. Am besten wäre irgend ein Beispiel wie sowas zu implementieren ist.

Fuer eine Beispiel-Implementierung kannst Du Dir ja mal den Quelltext von meinem GS/* Phonebook holen: http://www.almosthappy.de/gsphonebook

Der Daemon, der das AMI ueberwacht ist in Python geschrieben und der Idle-Screen wird von der PHP-Datei gsget.php generiert.

Mit Firmware 1.1.6.46 soll das ganze um mehrere Parameter erweitert worden sein und besser funktionieren.

Mehr Parameter wuesste ich jetzt nicht, aber in 1.1.6.44 ist ein Bug. Die Telefone ignorieren das SIP NOTIFY, wenn sie nicht Idle sind, d.h. man muss den Telefonen dann das NOTIFY erst schicken, wenn sie wieder aufgeleget haben, was die ganze Handhabung etwas verkompliziert. Das muss man mit 1.1.6.46 nicht mehr machen.

Hat das schon mal wer versucht und kann mir nen Tipp geben? Ich weiß nicht wo ich anfangen soll.

Wie gesagt, kannst Du Dir ja den Code von GS/* Phonebook anschauen. Die Version auf der Webseite arbeitet noch mit 1.1.6.44 zusammen und ist also etwas komplizierter, als es sein muesste. Eine neue Version kann ich Dir auf Wunsch zukommen lassen. Aber wenn Du sowieso das selbst implementieren willst, dann sollte das so als Beispiel vielleicht ausreichen.

Tschuess,
Lars

 

[dasgute]

Hallo,

den Code vom gsphonebook habe ich mir schon angesehen und versucht nachzuvollziehen. Einige Informationen konnte ich auch bei Voipinfo.org erhalten was den Idle-Screen-Refresh angeht. Ich kann nur sagen absoluter Respekt!

Würde das ganze gerne testweise implementieren. Jedoch arbeitet mein System mit einer MySql-Datenbank auf einem externen Server (Im moment nur für CDR und Telefonbuch Reversesuche).

Könnte man den IDLE-Screen auch eventuell mit AGI oder Shellscript dynamisch erzeugen? Da könnte ma ja dann direkt im Dialplan entsprechende Variablen übergeben. Oder ist diese Idee aussichtslos?

 

[Chaotux]

Würde das ganze gerne testweise implementieren. Jedoch arbeitet mein System mit einer MySql-Datenbank auf einem externen Server (Im moment nur für CDR und Telefonbuch Reversesuche).

Also ob ne Datenbank auf dem gleichen oder einem anderen Rechner laeuft ist ja relativ wurscht. Evtl. kann man die Datenbank auch in dem Code soweit abstrahieren, dass es egal ist, ob da MySQL, PostgreSQL oder sonstwas laeuft. Ich war fuer meinen Teil bisher immer nur zu faul, da PostgreSQL ja sowieso besser ist

Könnte man den IDLE-Screen auch eventuell mit AGI oder Shellscript dynamisch erzeugen? Da könnte ma ja dann direkt im Dialplan entsprechende Variablen übergeben. Oder ist diese Idee aussichtslos?

Also Du brauchst auf jeden Fall einen HTTP oder TFTP-Server, da das Telefon sich die Daten per HTTP oder TFTP besorgt und vom Asterisk nur den Request bekommt, dass es sich nen neuen IdleScreen holen soll.

Theoretisch waere es aber sicher machbar die Idlescreen-Datei fuer jedes Telefon im Dialplan (per externem Script oder so) zu generieren und in einer seperaten Datei abzuspeichern. Wenn die Generierung fertig ist, muss halt das SIP NOTIFY rausgeschickt werden, was nur sehr haesslich im Dialplan zu erledigen. Per System() "asterisk -rx sip notify gs-idle-screen-refresh sipphone1" oder so ausfuehren. Die ganze Prozedur musst Du einmal vor dem Waehlen (also beim Klingeln) und dann noch per M()-Macro im Dial-Befehl starten, damit der Idlescreen wieder zurueckgesetzt wird, wenn das Gespraech angenommen wird.
Der HTTP- oder TFTP-Server gibt dem Telefon dann halt diese entsprechende Datei.
"Huebsch" ist das ganze aber sicher nicht.

Aber was spricht dagegen die Datenbank zu benutzen, wenn sowieso eine schon vorhanden ist?

Lars

 

[dasgute]

So wie ich die Sache einschätze wird es wohl das beste sein das GS-Phonebook zu nutzen - ganz klar. Das werde ich testen. Mir kam aber noch eine Idee und ich weiß nicht ob diese besonders blöd ist.
Könnte man einen IDLE Screen Refresh in dem Zusammenhang eventuell über Hints realisieren? Das heißt eine ähnliche Technik wie für die blinkenden LEDs einsetzen? Prinzipiell verhält sich doch der Daemon des Phonebooks ähnlich wenn ich das richtig verstehe. Er lauscht und gneriert dann den Idle Screen.

 

[Chaotux]

So wie ich die Sache einschätze wird es wohl das beste sein das GS-Phonebook zu nutzen - ganz klar. Das werde ich testen. Mir kam aber noch eine Idee und ich weiß nicht ob diese besonders blöd ist.

So. Habe mal ein neues Release gemacht. Extra nur fuer Dich Die Idle Screen Generierung ist bei der neuen Version flexibler geloest.

Könnte man einen IDLE Screen Refresh in dem Zusammenhang eventuell über Hints realisieren? Das heißt eine ähnliche Technik wie für die blinkenden LEDs einsetzen? Prinzipiell verhält sich doch der Daemon des Phonebooks ähnlich wenn ich das richtig verstehe. Er lauscht und gneriert dann den Idle Screen.

Aeh. Das verstehe ich nicht.

Also der Daemon lauscht am AMI und benachrichtigt Telefone, dass sie nen neuen Idle Screen holen sollen, wenn ein Nachbartelefon klingelt oder nicht mehr klingelt. (Sofern das Telefon beim Nachbartelefon freigeschaltet ist.) Irgendwelche Daten werden da nicht uebermittelt. Das Telefon holt dann nen neuen Idle Screen und der wird vom PHP Script gs_screen.xml.php generiert. Dort werden dann die CallerID des Anrufers etc. eingetragen.

Wie stellst Du dir das denn Hint-gleich vor?

Lars

 

[dasgute]

Das ist natürlcich absolut top mit dem Release und ich muß das unbedingt testen.

Aber ich möchte nochmal auf das obige Gedankenspiel zurückkommen. Mittels Hint Gruppen kann man doch an anderen Telefonen verschiedene Stati signalisieren, ob ein Anruf eingeht u.s.w.

Bei mir z.B sieht das so in der extensions.conf aus:

[BLF_Group_1]
exten=>432,hint,SIP/432
exten=>433,hint,SIP/433
exten=>434,hint,SIP/434
exten=>452,hint,SIP/452
exten=>453,hint,SIP/453
exten=>456,hint,SIP/456

Auf dem CLI kommt dann dieses wenn ich von meinem Apparat 452 die 456 anwähle und dann (in diesem Fall) wieder auflege:

    -- SIP/456-08276248 is ringing
 Extension Changed 456[BLF_Group_1] new state Ringing for Notify User 432 
 Extension Changed 456[BLF_Group_1] new state Ringing for Notify User 434 
 Extension Changed 456[BLF_Group_1] new state Ringing for Notify User chris 
    -- Stopped music on hold on SIP/452-b6653498
  == Spawn extension (internal, 456, 9) exited non-zero on 'SIP/452-b6653498'
    -- Executing [h@internal:1] Hangup("SIP/452-b6653498", "") in new stack
  == Spawn extension (internal, h, 1) exited non-zero on 'SIP/452-b6653498'
 Extension Changed 456[BLF_Group_1] new state Idle for Notify User 432 
 Extension Changed 456[BLF_Group_1] new state Idle for Notify User 434 
 Extension Changed 456[BLF_Group_1] new state Idle for Notify User chris

Könnte man diese Events evtl für eine IDLE-Screen Erzeugung verwenden das man z.B. Über das Event an die in der Hint-Gruppe befindlichen Geräte mit einem dynamisch erzeugten IDLE-Screen mit der Caller-ID des anrufenden versorgt? Mir ist natürlich klar das der AMI Daemon aus dem GS-Phonebook ähnliches leistet / zum Ziel hat (wenn ich das richtig verstehe).

Wenn man das auswerten würde, könnte man ja über Skript einen Idle-Screen bauen und dann bereitstellen.

Das hört sich alles ziemlich theoretisch an, aber was ich damit meine ist das man dafür keine zusätzliche Software (Datenbank, Webserver) benötigen würde. Freilich wäre das alles dann sehr "mechanisch" gelöst.

Ein weiterer Vorteil wäre doch das man das Endgeräteunabhängig bekommen würde, sodaß man auch geräte anderer Hersteller (Snom) über die "hints" einbeziehen könnte und dann auch diese mit gerätespezifischen IDLE-Screens versorgen könnte. Klar lässt sich das sicher auch mit dem gs-phonebook einbauen (Ich habe nur GXPs).

 

[Chaotux]

Könnte man diese Events evtl für eine IDLE-Screen Erzeugung verwenden das man z.B. Über das Event an die in der Hint-Gruppe befindlichen Geräte mit einem dynamisch erzeugten IDLE-Screen mit der Caller-ID des anrufenden versorgt? Mir ist natürlich klar das der AMI Daemon aus dem GS-Phonebook ähnliches leistet / zum Ziel hat (wenn ich das richtig verstehe).

Ah. Jetzt verstehe ich, glaube ich, was Du meinst. Du willst die Hint-Statusaenderungen im Dialplan abfangen, um dann einen neuen Idle-Screen zu generieren und dann einen Request ans Telefon schicken, dass die sich doch bitte einen neuen Idle-Screen holen sollen.

Mir waere jetzt keine direkte Moeglichkeit bewusst, wie man im Dialplan feststellen kann, dass sich der Status von einem Hint aendert. Der Hint-Syntax sieht zwar so schoen Dialplan-esque aus, ist aber eine ziemlich feste Konstruktion ohne Moeglichkeiten da irgendwelche Tricks reinzupacken. Also prinzipiell koennte man sicherlich versuchen mit ein bisschen Dialplan-Magic soetwas anzunaehern. Vor jedem Dial-Statement koennte man ja eine Routine fuer's Klingeln aufrufen und dann im Dial-Statement ein M()- oder G()-Macro, damit man weiss, wann abgehoben wurde. Und eine "h"-Extension brauchst Du auch noch, wenn jemand auflegt. Erscheint mir insgesamt sehr aufwendig und unschoen. Aber vielleicht machbar.

Das hört sich alles ziemlich theoretisch an, aber was ich damit meine ist das man dafür keine zusätzliche Software (Datenbank, Webserver) benötigen würde. Freilich wäre das alles dann sehr "mechanisch" gelöst.

Um den Webserver kommst Du auf keinen Fall umher. Die Datenbank koenntest Du evtl. einsparen.

Nur mal interessehalber: Wo ist das Problem ne Datenbank zu installieren/laufen zu lassen? Der Asterisk-Server muss ja sowieso auch durchlaufen.

Ein weiterer Vorteil wäre doch das man das Endgeräteunabhängig bekommen würde, sodaß man auch geräte anderer Hersteller (Snom) über die "hints" einbeziehen könnte und dann auch diese mit gerätespezifischen IDLE-Screens versorgen könnte. Klar lässt sich das sicher auch mit dem gs-phonebook einbauen (Ich habe nur GXPs).

Also an der verwendeten Methode ist nix Geraetespezifisches dran. Nur der SIP NOTIFY-Request. Wenn andere Hersteller ebenfalls eine Methode anbieten, den Idlescreen auf ihren Telefonen zu aktualisieren (keine Ahnung, ob sie das tun), dann sollte das eigentlich kein Thema sein das zu intergrieren. Egal bei welcher Loesung.

 

[dasgute]

o.k. jetz musses raus

Der Grund für meine Bedenken ist der. Ich setze als Linux Disri FLI4L mit dem Asterisk OPT von Holger Hornung (wird leider nicht mehr weiterentwickelt) ein welche Bristuffed Unterstützung bietet. Das ist ein modulares Linux-Routersystem was ich schon seit langem sehr erfolgreich einsetze. In dem Zusammenhang komme ich einfach nicht drumrum die entsprechenden sogenannten OPT-Pakete zu erzeugen. Das heißt im Klartext ich muß die entsprechende Postgre Unterstützung und den Apache erst in den Router integrieren, was prinzipiell kein Problem dastellen sollte. Jedoch ist das Router-OS so abgespeckt das sehr viele Sachen einfach fehlen.

Dummerweise gibt es diese OPT-Module nicht (gab es jedoch schon) da die Entwickler darauf beharren das ein SQL-Server und ein Webserver auf einem Router nix zu suchen haben. Ich bevorzuge aber die all-in-one Lösung.

Da gehts los mit ner speziellen Buildrootumgebung für Entwickler, es gibt nur alte (weil kleine) Libaries u.s.w.. Da solche Sachen wie Apache und MYSQL, Postgre zum laufen zu bringen ist echt ne Herausforderung.

Klar könnte ich einfach ein Linux aufsetzen aber das wäre der letzte Ausweg.

Ich werde mich also ans Werk machen und die entsprechenden Paket erstellen und da werde ich dann gerne das gs-phonebook einsetzen

Mal sehen ob das was wird...

 

[Chaotux]

Wenn Du so ein Minimal-OS benutzt, dann koenntest Du den Webserver durch einen TFTP-Server ersetzen. Sowas sollte doch erhaeltlich sein? Wenn die Idlescreens extern im Dialplan mit einer eigenen Loesung erstellen solltest, so dass der TFTP-Server nur noch Dateien ausliefern muss, sollte das gehen. Aber diese Loesung geht nur mit relativ Arbeit im Dialplan.

 

[dasgute]

Gute Idee, TFTP geht auf dem Mini-OS auch und ein Mini-Http-Server ist auch drauf. Aber ehrlich gesagt würde ich lieber das gs-phonebook einsetzen da das genau das ist was ich brauche.

Ich muß Apache/Perl zur Verfügung haben den dann hätte ich erweiterte Script-Möglichkeiten. Diese Hürde muß ich sowieso nehmen also muß ich das zuerst lösen.

 

[dasgute]

Gute Idee, TFTP geht auf dem Mini-OS auch und ein Mini-Http-Server ist auch drauf. Aber ehrlich gesagt würde ich lieber das gs-phonebook einsetzen da das genau das ist was ich brauche.

Ich muß Apache/Perl zur Verfügung haben den dann hätte ich erweiterte Script-Möglichkeiten. Diese Hürde muß ich sowieso nehmen also muß ich das zuerst lösen.

 

[www.keng.de]

Warum nicht viel einfacher?

Man kann das Problem natürlich auch viel einfacher lösen: Das Grandstream-Telefon unterstützt doch mehrere SIP-Konten. Also legt man zwei zusätzliche Konten im Asterisk an. Diese legt man dann in eine Rufgruppe, die immer mitklingelt. An den Telefonen konfiguriert man diese Rufnummern zusätzlich, eventuell ohne klingeln und schon ist das Problem gelöst.

 

[dasgute]

was soll ich sagen, diese einfache Lösung ist genau das was ich suchte. beängstigend ...

 

[dasgute]

Hab das nun mal ausprobiert. Habe das zusätzliche Profil am Grandstream angelegt -wunderbar. Das funktioniert gut hat aber Schönheitsfehler. Wenn ich die Anrufgruppe definiere wird brav die Nummer angezeigt aber es klingelt mein Apparat immer mit. In der Konfiguration finde ich keine Einstellung "silent" oder so.

Kann man beim Grandstream ein Silent Profil einstellen oder kann man das irgendwie hinbekommen? Habe leider nix gefunden. Oder vielleicht gibt es ja einen "Silent" Klingelton den ich in das Gerät einspielen kann?

 

[Chaotux]

Es gibt ein Tool auf der Webseite von Grandstream, mit dem man sich Klingeltoene selber erstellen kann. Eine "leere" WAV-Datei einer bestimmten Laenge, die Du dann in einen Klingelton umwandeln kannst, kannst Du z.B. mit Audacity (http://audacity.sourceforge.net/?lang=de) relativ leicht generieren. Einfach im "Generate"-Menu "Silence" auswaehlen und die gewuenschte Laenge angeben.