Modul 96_SIP

[Wzut]

dann wäre es eleganter das mit Perls kill Funktion zu machen

Mensch sag das doch gleich, mein Motto ist doch eh "es muß nicht unbedingt funktionieren aber gut aussehen"
Auf dem Test Raspi läuft dein Vorschlag, werde das so für das nächste Update (und mein MPD Modul) übernehmen !
Vielen Dank und du darfst dir gerne noch den Rest des Moduls anschauen und nach weiteren hässlichen Stellen suchen

[Papaloewe]

Vielen Dank für das SIP Modul!

Doch jetzt zu meiner Frage:
Ist es möglich zu verifizieren, ob ein ausgehender Anruf des SIP-Muduls beim Empfänger angenommen wurde?.
Bzw. noch ein wenig weiter gedacht, wäre es möglich eine Art Bestätigung durch Senden einer DTMF-Tons (z.B.: Ziffer 1=Ja und Ziffer 2=Nein) zu erreichen?

[Wzut]

a., ja schau dir die Readings mit call_ an , bsp von heute eines ausgehenden Anrufes der nicht angenommen wurde (no answer , gibt aber noch mehr)  :

Code Auswählen Erweitern


2019-08-10 15:58:28   call            done
2019-08-10 15:58:28   call_state      no answer
2019-08-10 15:58:28   call_success    0
2019-08-10 15:58:28   call_time       0
und so sieht es z.B. bei Erfolg aus :

Code Auswählen Erweitern


2019-08-10 19:55:35   call            done
2019-08-10 19:55:35   call_state      ok
2019-08-10 19:55:35   call_success    1
2019-08-10 19:55:35   call_time       10

b. verstehe ich nicht ganz, der Angerufene soll eine Taste als Quittung drücken ?
Diese Funktion ist so nicht im Modul vorhanden, müsste ich mich (oder plin) mal schlau machen ob man die DTMF Erkennung auch bei ausgehenden Rufen aktivieren kann, denn die ist z.Z. nur im listen mode DTMF aktiv

[Papaloewe]

a: Prima das hilft mir schon weiter.
b: Ja, da hast du mich richtig verstanden. Innerhalb eines Rufs, quasi auf eine abgespielte Frage eine Rückmeldung zu geben und das von jedem normalen Telefon aus. Ganz ohne App, oder sonst was...

Zur Zeit hätte ich dafür folgenden Anwendungsfall:
Meine Mutter, 84 Jhre, wohnt noch alleine. Klar, hat sie einen Hausnotruf von den Malteser, aber für Kleinigkeiten will sie den natürlich nicht beutzen....so sind sie halt.
Daher habe ich alle meine DashButtons wild in der Wohnung verteilt und alarmiere dann nach einer Liste, bzw. deren Anwensenheit im WLAN, direkt die Zielpersonen per Sip call.
Falls jetzt jemand den Ruf nicht annimmt, kommt der Nächste dran. Soviel zur Frage Teil a.

Noch weiter optimiert, könnte die angerufene Person eine Rückmeldung geben (Frage Teil b), ob es ihr möglich in kurzer Zeit meiner Mutter zu helfen.
Falls eine Absage kommt würde die nächste Zielperson angerufen.

Noch eine Anwendung aus meinem beruflichem Umfeld, der Feuerwehr:
Das Szenario nennt sich Hausalarm, dann wenn ein größeres Ereignis bewältigt werden muss und alle Kräfte, auch die sich zu Hause befinden, alarmiert werden und gebeten werden zur Wache zu kommen. Hier könnte jetzt auch, per Rückmeldung sofort erfasst werden, wer in der Lage ist zu kommen und wer nicht. Somit hätte der Einsatzleiter innerhalb kürzester Zeit eine Zahl mit wie vielen zusätzlichen Kräften er rechnen kann.

Na klar, solche Systeme gibt es bereits am Markt. Für richtig viel Geld natürlich. Freiwillige Feuuerwehren können dann nur davon träumen....

[Papaloewe]

Die Kür wäre dann auch noch eine sogenannte strukturierte Notrufabfrage, aber jetzt bin ich schon etwas weit abgehoben....

[plin]

@Papaloewe: wenn Du viele komplizierte Dinge mit dem Telefon tun möchtest bietet sich asterisk an. Das gibts mittlerweile auch als docker image.

[Wzut]

also bei a. kann man den Ruf annehmen, bis zum timeout ausklingeln lassen oder wegdrücken. Das Wegdrücken könnte eine Option sein die du auswerten kannst.
Sicher Asterisk ist mächtig, aber trotzdem werde ich mal schauen ob man nicht in der Richtung Quittung auf Frage mit DTMF etwas machen kann.
Ala Sip Call mit Text2Speach Nachricht "Kannst du heute Abend kommen, drücke  1-4 für ja oder andere Taste für nein". Normalerweise würde nach Ende
der Nachricht sofort auflegt werden. D.h. hier wäre entweder noch eine zusätzliche Wartezeit nötig um die Rückmeldung überhaupt erfassen zu können oder man lässt die Nachricht x mal wiederholen und schafft sich so die Antwort Zeit. Das wäre allerdings auch ne Variante die du heute schon nutzen kannst, man kann auswerten ob die Nachricht vollständig gehört wurde oder der Anrufer während der Ansage aufgelegt hat.   

[Wzut]

Sodle , das hat mir doch keine Ruhe gelassen .... eine kleine Änderung an der Call Funktion und schon kann man DTMF auch bei ausgehendem Ruf empfangen.
Getestet habe ich es mit sip_dtmf_size = 1 und einem Call ala
set mySIP call **611 60 !Tastentest, drücke bitte eine Taste *5
Die 60 als Sicherheit , die *5 damit ich nach dem Text genug Zeit hatte eine Taste zu drücken, aktualisiert wird dabei das Reading dtmf_event (meine gedrückte Taste)
Aber ganz rund ist das halt so noch nicht, es fehlt IMHO noch eine lange Pause nach dem Text statt den ständig zu wiederholen, das sollte aber kein großes Problem sein.
Leider bekommt man als Angerufener aber keine Quittung das der Tastendruck erfolgreich erkannt wurde, mal schauen ob da noch was zu machen ist.

[plin]

Ala Sip Call mit Text2Speach Nachricht "Kannst du heute Abend kommen, drücke  1-4 für ja oder andere Taste für nein".

@wzut, bei listen_dtmf haben wir bereits das Wechselspiel aus DTMF erfragen und Quittungston. Man müsste die Reihenfolge rumdrehen und aus dem Quittungston ein längeres Audiofile machen.

[Wzut]

wieso rumdrehen , soweit ich es verstehe müsste eine Kopie der while ($dmf_loop) Schleife nach dem senden des Text2Speach Audiofiles aufgerufen werden.
Bzw das Audiofile kann eigentlich auch gleich den Platz von $msg1 einnehmen, im unteren Teil entfällt die Schleife mit loop = once.
Er müsste sich nur zwei Audiofiles anlegen ( ja / nein oder halt noch mehr ) die nach Auswertung des DTMF Events den Platz von $msg2 einnehmen.
Klingt doch alles recht simpel , der Haken ist nur das du damals das ganze Konstrukt der diversen geschachtelten Loops und ihrer jeweiligen Abbruch Bedingungen in viel Kleinarbeit erarbeitet hast und ich mich nie richtig intensiv damit beschäftigt habe, vllt jetzt mal ein guter Zeitpunkt noch was  dazu zu lernen
Etwas mehr Kopfschmerzen macht mir eher wie man das ganze Userfreundlich bzw. überhaupt verständlich/händelbar umsetzen soll.
Mir fällt da spontan ein :
a. die Attribute noch weiter aufbohren. Vorteil: schnell gemacht. Nachteil: müssten für diverse Situationen eventuell immer wieder geändert werden
b. als Parameter beim set call anhängen. Vorteil: sehr flexibel. Nachteil: das ist jetzt schon ein Krampf mit force, Wiederholen , etc
c. config Datei. Vorteil: extrem flexibel und in belieber Anzahl für verschiedene Situationen machbar, erstellen und editieren mit dem FHEM interen Editor unter Edit files. Nachteil: etwas FHEM unüblich, sieht man von Ausnahmen wie DBLog oder configDB mal ab.
Ich würde c. bevorzugen auch wenn die jeweilige Datei nicht mal eben schnell zusammengeklickt ist. Die Anzahl der möglichen Nutzer wird eh klein sein und die müssen sich dann halt etwas intensiver mit der Materie beschäftigen      

[plin]

Was hältst Du von einem eigenständigen, einfach gestrickten Modul das das SIP-Modul aufruft, die Readings ausliest und in einer Liste von Readings das Ergebnis darstellt?

Vorgabe: die Rufnummernliste, am Besten pro Rufnummer ein Attribut mit Nummer_Name, Nummer_Status (Bereitschaft, frei).

Resultate als Readings, eins pro Nummer z.B. Nummer_Status

Über eine Readingsgroup kann man die Ergebnisse leicht gruppieren, um einen Überblick zu erhalten.

Dazu ein Reading pro Status ja/nein damit man's leicht auswerten kann.

All das ins SIP-Module einzubauen würde es unübersichtlich machen. Ein separates Modul macht aus meiner Sicht das Leben einfacher und übersichtlicher.

Ciao, plin

[Wzut]

Das wäre natürlich auch ne Idee , quasi ein Client Modul das das SIP Modul als IODev benutzt.
Im ersten Schritt muß ich aber mal schauen den eigentlichen Logik Part zum Laufen zu bekommen mit hart ins Modul geschrieben Parametern.

[netbus]

Hallo,
ist es möglich mit diesem Client direkt zu einem anderen Client zu sprechen?
Ich habe keine PBX und keine Fritzbox aber Voip unterstützt ja auch P2P-SIP

[Wzut]

Ich denke der Unterbau NET::SIP unterstützt kein P2P-SIP.
Wenn allerdings der Autor Steffen Ullrich das einbauen würde könnte man bestimmt das SIP Modul entsprechend anpassen.
Kannst ihn ja mal anschreiben unter Steffen_Ullrich@genua.de

[netbus]

Danke, habe ihm mal geschrieben.
vG netbus