Es gibt ein neues Modul SIP.
Vorgeschichte
Im August 2015 stellte wmeiners unter Neues Modul FB_SIP.pm, ein SIP-Client die erste Version eines Moduls FB_Sip im Forum vor.
( Ref -> https://forum.fhem.de/index.php/topic,40219.0.html)
Obwohl sich die Funktion auf anrufen und auflegen beschränkte, fand das Modul doch reges Interesse. Im August 2016 entstand daraus die Urversion von 96_SIP.pm, die mittlerweile alle im Thread diskutierten Features enthält.
Funktion
Das Modul kann
Anrufe tätigen und ein Audio-File abspielen
Anrufe tätigen und DTMF-Töne übertragen
Anrufe entgegennehmen und die übertragenen DTMF-Töne als Reading speichern
Über eingehende Anrufe informieren und diese gezielt annehmen
Voraussetzungen
Die perl-Library Net::SIP muss installiert sein.
(Jessie User -> sudo apt-get install libnet-sip-perl , installiert z.Z. die Version 0.687)
Es muss ein Account für den Client eingerichtet sein (Fritzbox, Asterisk etc.)
Wie geht's?
'update all' und 'restart'
Telefoniegrät in der Fritzbox einrichten
define <name> SIP
Attribute an die eigene Umgebung anpassen
erster Test : set <name> call <anzurufende Rufnummer>
Alle Details könnt ihr dem Wiki (SIP-Client (https://wiki.fhem.de/wiki/SIP-Client)) oder der command.ref entnehmen.
Nachtrag : Vielen Dank an plin für die Wiki Seite , die command.ref und einige Verbesserungen/Ideen am Modul.
Hast Du das tatsächlich mal gegen einen echten SIP Server wie Asterisk oder einen professionellen SIP Telefonieanbieter getestet?
Mir fehlen dazu die Möglichkeiten, aber plin hat das für sein Dooline Projekt zusammen mit Asterisk laufen.
naja, ich sag mal so: Ich hab mir das Modul grade mal angesehen. Da sind ein paar wirklich grobe Schwachstellen in Bezug auf die Benutzung des SIP Protokolls enthalten. Das Modul würde ich an Deiner Stelle lieber in contrib einchecken als innerhalb der offiziellen FHEM Auslieferung. Alleine schon aus Sicherheitsgründen. SIP ist nicht so ganz trivial, wie manche Leute sich das denken. Umso mehr, wenn man beim Entwickeln nur eine Fritzkotz als Gegenspieler zum Testen hat(te).
Zitat von: betateilchen am 19 Februar 2017, 19:52:30
naja, ich sag mal so: Ich hab mir das Modul grade mal angesehen. Da sind ein paar wirklich grobe Schwachstellen in Bezug auf die Benutzung des SIP Protokolls enthalten. Das Modul würde ich an Deiner Stelle lieber in contrib einchecken als innerhalb der offiziellen FHEM Auslieferung. Alleine schon aus Sicherheitsgründen. SIP ist nicht so ganz trivial, wie manche Leute sich das denken. Umso mehr, wenn man beim Entwickeln nur eine Fritzkotz als Gegenspieler zum Testen hat(te).
Ich verstehe die negativen Anmerkungen nicht. So ein Modul ist nicht von heute auf morgen fertig, das weiß jeder der sich mit Programmierung beruflich oder hobbymäßig beschäftigt.
Zum Thema richtige Telefonanlage kann ich sagen, dass das Modul (Stand 12.02.17) gut und ohne Probleme mit Astersik bzw. FreePBX zusammen arbeitet.
Die "groben" Schwachstellen sollten sicher behoben werden, da wir hier aber keine Atomkraftwerke über SIP steuern sehe ich das halb so wild.
Gruß Tobias
contrib hatte ich zuerst auch im Hinterkopf, schade halt nur das es beim Update nicht aktualisiert wird. Aber Anyway,
Udo, es wäre sehr schön wenn du die groben Schwachstellen aufzeigen würdest damit man etwas dagegen tun kann ( wenn sie nicht direkt im Net::Sip sind)
Hallo,
wie/wo binde ich die *.pm Datei ein?
--> erledigt, habe es nachgelesen
Macht was Ihr meint. Da ich hier aufgrund einer Rückfrage schon wieder blöd angemacht werde, bin ich hier raus.
Zitat von: Tobbi am 19 Februar 2017, 20:00:58
So ein Modul ist nicht von heute auf morgen fertig, das weiß jeder der sich mit Programmierung beruflich oder hobbymäßig beschäftigt.
Bei mir ist das "Beschäftigen nicht "beruflich oder hobbymäßig", sondern beruflich (seit über 30 Jahren) UND hobbymäßig (seit fast 40 Jahren).
Meine Anmerkungen waren nicht "negativ", sondern ernst gemeint.
Zitat von: betateilchen am 19 Februar 2017, 20:10:59
Macht was Ihr meint. Da ich hier aufgrund einer Rückfrage schon wieder blöd angemacht werde, bin ich hier raus.
Bei mir ist das "Beschäftigen nicht "beruflich oder hobbymäßig", sondern beruflich (seit über 30 Jahren) UND hobbymäßig (seit fast 40 Jahren).
Meine Anmerkungen waren nicht "negativ", sondern ernst gemeint.
Das blöde Anmachen kann ich hier in keinster Weise finden. Ich habe nie gemeint, dass die Hinweise nicht ernst gemeint waren. Sicherheitslücken sollte man schließen aber die Gemeinschaft ist eben nur stark, wenn jeder sein Zutun dazu gibt.
Aus diesem Grund kannst du doch bitte deine jahrelange Berufserfahrung mit einfließen lassen, vorallem wenn du Fehler entdeckt hast. So hat jeder was davon.
Gruß Tobias
Hallo Wzut,
prima Sache, Dein neues Modul. Habe da sponten eine gute Verwendung dafür: ich öffne mein Hoftor + Garage über einen Anruf von meinem Handy auf eine, in der FB keinem Endgerät zugeordnete Rufnummer (dabei teste ich, ob der Anruff von meiner Handynummer kommt). Bisher kommt eine Ansage, das der Teilnehmer nicht zu erreichen ist. Mit Deinem Modul kann ich den Anruf kurz annehmen und automatisch auflegen oder eine freundliche Begrüßung abspielen. Damit die Ansage aber nicht die Telefonterroristen von allen möglichen Callcentern zu hören bekommen (die meine alten Dienstnummer irgenwie kennen), meine Frage: Kannst Du einbauen, das SIP nur bestimmte Nummern annimmt?
Das kannst aber auch mit Bordmitteln machen.
Stelle das attr sip_listen auf wfp und setze ein set reset ab. Der Status sollte dann auf listen_for_wfp gehen.
Lege dir nun ein Notify an das auf das Reading caller und deine Handy Nr. triggert.
Wenn es dein Handy ist setze das Kommando set fetch ab, erst jetzt nimmt das Modul den Anruf an.
Oder du verwendest statt wfp dtmf , dann nimmt das Modul zwar sofort den Anruf an, du must aber noch # und zwei unterschiedliche Zahlen senden um die Aktion auszulösen.
Hallo Wzut,
klasse, dass das neue Modul jetzt mir dem Update eingespielt werden kann. Beim Testen habe ich folgendes feststellen müssen:
1. set mysip call **610 => funktioniert. Call wird ausgeführt und die Testtöne abgespielt.
2. set mysip call **610 -#10 => kein Anruf, sofortige Änderung im STATE: unknow call done (tatsächlich ohne das "n" bei unknown.
3. set mysip call **610 10 /pfad/test.wav => funktioniert, Datei wird abgespielt und Modul legt auf.
Irgendwie scheint das Abspielen der DTMF Töne nicht so zu funktionieren, wie im Wiki unter "Anruf tätigen und DTMF Töne senden" beschrieben: https://wiki.fhem.de/wiki/SIP-Client
Zitat von: hdiessner am 20 Februar 2017, 19:13:31
2. set mysip call **610 -#10 => kein Anruf, sofortige Änderung im STATE: unknow call done (tatsächlich ohne das "n" bei unknown.
Da fehlt als zweiter Parameter die Ringtime , richtig wäre :
set mysip call **610 5 -#10
Da muss das Wiki angepasst werden , der Call erlaubt :
1. set mysip call **610 ( Ringtime wird aus dem attr sip_ringtime genommen und zu hören bekommt man ein paar DTMF Signale)
2. set mysip call **610 30 ( statt attr sip_ringtime wird nun 30 Sekunden geklingelt und zu hören bekommt man ein paar DTMF Signale)
3. set mysip call **610 20 Datei/Signale ( statt attr sip_ringtime wird nun 20 Sekunden geklingelt und zu hören bekommt man die übergebene Datei oder DTMF Signale)
da fehlte noch ein anderes "n" , ist beim nächsten Update morgen drin :)
Hallo,
bei mir kommt im Log:
registration failed: Failed with error 110 at ./FHEM/96_SIP.pm line 209.
PERL WARNING: "my" variable $my_action masks earlier declaration in same scope at ./FHEM/96_SIP.pm line 495, <$fh> line 456.
--> Da ich der Programmierung nicht so wirklich mächtig bin, sagt mir die Zeile im Code leider nicht so viel.
So sieht das Modul in FHEM aus:
define mySIP SIP
attr mySIP group Anrufe,Fritzbox
attr mySIP room Actions,Anrufe
attr mySIP sip_audiofile none
attr mySIP sip_from sip:628@fritz.box
attr mySIP sip_ip 192.168.0.49
attr mySIP sip_password ...
attr mySIP sip_port 5060
attr mySIP sip_registar fritz.box
attr mySIP sip_ringtime 10
attr mySIP sip_user 628
attr mySIP sip_waittime 10
Mit der 628 und der Fon-App von AVM kann ich mich mit den Zugangsdaten anmelden. Ein Update und restart habe ich schon vorgenommen.
Wer könnte mir da weiterhelfen?
Die Perl Warning kannst Du erstmal ignorieren, das ist kein Fehler, sondern unsaubere Programmierung.
attr mySIP sip_registar fritz.box
Hast Du da wirklich registar stehen statt registrar?
(Verdacht: Da hat wohl mal wieder jemand direkt in der fhem.cfg rumgepfuscht)
Zitat von: betateilchen am 20 Februar 2017, 20:35:22
(Verdacht: Da hat wohl mal wieder jemand direkt in der fhem.cfg rumgepfuscht)
Nein , hat er nicht aber er benutzt eine alte Version aus dem FB Thread aktuell ist der Tippfehler nur noch in der command.ref.
Auch der my Fehler ist schon einige Zeit gefixt.
@tklein : update ist dein Freund :)
danke, dann werde ich morgen auf 5.8 updaten und hoffen dass Alexa und Siri noch mit meinem Server sprechen. :-)
Hinweis oben rechts habe ich ja gelesen. :-)
Muss ich das dann noch manuell auf registrar ändern?
Zitat von: tklein am 20 Februar 2017, 21:00:20
Muss ich das dann noch manuell auf registrar ändern?
Nein , das richtige Attribut taucht von alleine auf , inklusive einer Fehlermeldung das es das attr mit dem fehlenden r nicht gibt.
Tipp : man muss nicht immer ein komplettes Update via update machen (siehe command.ref)
oder man kann sich auch direkt aus dem svn bedienen : https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/96_SIP.pm
Hallo,
bei update all bekomme ich folgende Meldung im logfile:
2017.02.21 07:24:39 1: UPD FHEM/96_SIP.pm
2017.02.21 07:24:39 1: open .//FHEM/96_SIP.pm failed: Permission denied, trying to restore the previous version and aborting the update
2017.02.21 07:24:39 1:
2017.02.21 07:24:39 1: fhemabfall
2017.02.21 07:24:39 1: nothing to do...
2017.02.21 07:24:39 1: Calling /usr/bin/perl .//contrib/commandref_join.pl -noWarnings, this may take a while
Kann mir jemand sagen, was ich jetzt tun sollte?
Ist damit nur dieses Modul vom update ausgeschlossen oder die evtl. nachfolgenden auch?
Ergänzung:
Das Modul gehörte dem user pi:pi, warum ??
Ich hab den Benutzer auf fhem:dialout geändert, und die Berechtigungen auf -rw-rw-rw-.
Damit läuft das upate durch.
Viele Grüße Gisbert
Zitat von: Gisbert am 21 Februar 2017, 07:49:58
Das Modul gehörte dem user pi:pi, warum ??
Hattest es zuvor einmal aus dem FB Thread heruntergeladen und von Hand nach FHEM kopiert ?
Wenn ja , dann hast du damals nicht die Rechte angepasst und der fhem User kann heute die alte Version via Update nicht überschreiben.
Zitat von: Wzut am 21 Februar 2017, 08:53:00
Hattest es zuvor einmal aus dem FB Thread heruntergeladen und von Hand nach FHEM kopiert ?
Wenn ja , dann hast du damals nicht die Rechte angepasst und der fhem User kann heute die alte Version via Update nicht überschreiben.
Gut möglich und eine naheliegende Erklärung, ich kann es aber nicht mit Sicherheit sagen.
Erstaunlich ist aber, dass
alle Updates damit blockiert werden; ich hab das Update insgesamt 3mal durchgeführt, mit dem Resultat, dass keines der anderen Module erneuert wurden.
Zitat von: Gisbert am 21 Februar 2017, 09:27:43
Gut möglich und eine naheliegende Erklärung, ich kann es aber nicht mit Sicherheit sagen.
Erstaunlich ist aber, dass alle Updates damit blockiert werden; ich hab das Update insgesamt 3mal durchgeführt, mit dem Resultat, dass keines der anderen Module erneuert wurden.
Das ist so. Da auch Abhängigkeiten bestehen wir bei einem Fehler im Update ein komplette roll back durchgeführt. Somit wird Fhem vor inkonsistenten Updates geschützt.
Grüße Jörg
Hallo,
bin einen kleinen Schritt weiter. Habe die Version rüberkopiert (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/96_SIP.pm) mit einem Reload aktualisiert. Hinweis bezüglich der registrars kam auch.
Neustart gemacht. Allerding kann ich immer noch nicht anrufen.
Eventlog:
SIP mySIP calling **626
..
SIP mySIP call fail
SIP mySIP last_error: CallRegister: Failed with error 110
Mit SIPCMD via Konsole kann ich zumindest intern anrufen: ./sipcmd -P sip -u 628 -c xyzxaz -w 192.168.0.1 -x 'c**626w5000'
Verzweifelte Grüße
Ich bekomme es ums Verrecken nicht installiert:
The following packages have unmet dependencies:
libnet-sip-perl : Depends: libnet-dns-perl but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
sudo apt-get update
sudo apt-get dist-upgrade
habe ich auch gemacht.
Aber leider alles ohne Erfolg...
@tklein,
attr mySIP verbose 4 , dann nochmal testen , ins Log schauen, kopieren und posten.
@YellowBall,
schon sudo apt-get install libnet-dns-perl versucht ? bzw. mit welchem System bist denn unterwegs , Jessie ?
Zitat von: Wzut am 21 Februar 2017, 16:11:53
@YellowBall,
schon sudo apt-get install libnet-dns-perl versucht ? bzw. mit welchem System bist denn unterwegs , Jessie ?
Ja, habe ich auch gemacht:
The following packages have unmet dependencies:
libnet-dns-perl : Depends: perlapi-5.20.2
E: Unable to correct problems, you have held broken packages.
kaum Veränderung.
Hier der Eventmonitor:
mySIP, calling **626, ringtime: 10
mySIP, CALLDone -> mySIP|0|CallRegister: Failed with error 110
Darf Caller (siehe screen) leer sein?
Zitat von: Wzut am 20 Februar 2017, 08:48:50
Das kannst aber auch mit Bordmitteln machen.
Stelle das attr sip_listen auf wfp und setze ein set reset ab. Der Status sollte dann auf listen_for_wfp gehen.
Lege dir nun ein Notify an das auf das Reading caller und deine Handy Nr. triggert.
Wenn es dein Handy ist setze das Kommando set fetch ab, erst jetzt nimmt das Modul den Anruf an.
Danke, so gemacht und seit dem heutigen Update funktioniert nun auch das automatische Auflegen. Ziel erreicht!
Zitat von: tklein am 21 Februar 2017, 16:22:12
mySIP, CALLDone -> mySIP|0|CallRegister: Failed with error 110
error 110 bekomme ich wenn der registrar nicht aufgelöst werden kann.
Setz mal dein attr sip_registrar auf die IP der FB statt auf fritz.box, bei deinem SIPCMD verwendest du ja auch die 192.168.0.1
@det. , freut mich mal ne postive Rückmeldung zu lesen :)
Zitat von: betateilchen am 19 Februar 2017, 19:28:48
Hast Du das tatsächlich mal gegen einen echten SIP Server wie Asterisk oder einen professionellen SIP Telefonieanbieter getestet?
Hallo betateilchen, habe ich gestern Abend mit dem dann gültigen Stand durchgespielt und mein Asterisk hat nicht gezuckt, wohl aber alle erforderlichen Verbindungen wunschgemäß durchgeroutet.
VG plin
@tklein,
die Registrierungsprobleme hatte ich am Anfang auch, deshalb habe ich denen im Wiki schon einen eigenen Abschnitt gegönnt.
ich habe heute auch mal ein update gemacht.
grundsätzlich funktioniert das sip modul bei mir weiterhin als virtuelle sip-türsprechanlage. allerdings liefert der state nun am ende der verbindung ein "FAIL call done". ein log sieht so aus:
2017.02.21 14:32:46.292 4: triggerLiveCam, calling 7, ringtime: 15
2017.02.21 14:32:46.304 5: triggerLiveCam, call has pid 18852
2017.02.21 14:32:46.392 4: triggerLiveCam, register new expire : Tue Feb 21 14:37:46 2017
2017.02.21 14:32:46.448 4: triggerLiveCam, DTMF : ABCD*#123--4567890
2017.02.21 14:33:02.775 4: triggerLiveCam, CALLDone -> triggerLiveCam|1|FAIL|HASH(0x37a8bf0)
etwas irritierend, aber das livebild wird korrekt am fritzfon ein- und wieder ausgeschaltet.
@Wzut
Besten Dank!! Hat jetzt geklappt. :D
Jetzt kann ich mich dem eigentlichen Problem widmen:
Per Sip/Fhem die interne Türsprechanlage in einer Auerswald (per S0 and die FB angeschlossen) anrufen, um dann mit ##R7 den Türöffner zu aktivieren.
Zitat von: plin am 21 Februar 2017, 18:38:28
die Registrierungsprobleme hatte ich am Anfang auch,
Nur mal so zur Info: Das SIP Protokoll verlangt keine vorherige Registrierung, um einen abgehenden Anruf tätigen zu können. Die Registrierung ist eigentlich nur dafür notwendig, dass der SIP Server weiß, wohin er einen eingehenden Anruf zustellen soll.
@betateilchen: Es waren "Registrierungsprobleme" beim listen-Start, weil die sip_Parameter nicht passten :-(
Als gebranntes Kind weiß man dann direkt was man unter "bekannte Probleme" schreiben könnte.
Zitat von: frank am 21 Februar 2017, 18:50:14
2017.02.21 14:33:02.775 4: triggerLiveCam, CALLDone -> triggerLiveCam|1|FAIL|HASH(0x37a8bf0)
Dem Thema Türsprechanlage und Livebild von der Webcam werde ich mich die nächsten Tage widmen, konnte die letzten Wochen etwas Erfahrung sammeln beim Testen von pahs Doorpi Projekts. Mal schauen ob ich den Fehler auch so hinbekomme und dann gleich noch den HASH in lesbare Bestandteile zerlege.
So, habe heute endlich mal wieder getestet, nachdem ihr hier ja mächtig viel geleistet habt. Danke!
Meine Umgebung: RaspberryPi und FritzBox; 96_SIP.pm 13479 2017-02-21.
- Lokal (FritzFon) hat das Abspielen von DTMF funktioniert, beim Anruf auf mein iPhone habe ich nur Klackgeräusche gehört, aber kein DTMF.
- Die Eingabe von DTMF am Telefon hat nur einmal am FritzFon funktioniert; nachfolgende Versuche führten zwar zu einer Verbindung, aber das Reading "dtmf" hat sich nicht mehr geändert.
- Das Attribut ringtime in "set <name> call <nummer> [<ringtime>] [<nachricht>]" ist unklar. Die commandref spricht auch in der Erklärung nur von Ringtime, was ich mal als maximale Dauer des Klingelns (also vor Zustandekommen der Verbindung) interpretieren würde. Im wiki wird bei den Anwendungsbeispielen dieser Parameter dann umdefiniert in <dauer> und bezeichnet die Anrufdauer, also die Dauer für die das zustandegekommene Gespräch gehalten wird. Was stimmt?
- Aus der Beschreibung geht hervor, dass die Angabe des Parameters "ringtime" bei "set <name> call <nummer> [<ringtime>] [<nachricht>]" nicht optional sei, wenn eine Nachricht als Audiofile ausgegeben werden soll. Im wiki steht unter "Anruf tätigen und DTMF-Töne senden", dass eine Nachricht in Form von DTMF-Tönen ohne "ringtime" erfolgen muss ("**1 -#23). Klingt irgendwie inkonsistent bzw. widersprüchlich.
- In der commandref wird das nötige Format des Audiofiles nicht beschrieben. Im wiki wird das Format zumindest in den Anwendungsbeispielen genannt: PCM/8000. Ein Hinweis auf die Installation von sox per "sudo apt-get install sox" wäre hilfreich.
- Bei einem set ... reset" hätte ich erwartet, dass das SIP-Device zurück gesetzt wird und ein eventuell vorhandener listen-Prozess gestoppt wird. Aber wenn ich nach einem "set ... reset" ein "set ... listen" mache, dann bekomme ich die Info, dass der listen-Prozess noch läuft. Ist das so beabsichtigt?
- Im Logfile habe ich später zwei Meldungen gefunden: "Timeout for SIP_ListenStart reached, terminated process 5395"
- Wenn ich das Attribut "sip_listen" auf "wfp" ändere, ändert sich das Reading state erst einmal nicht, erst nach einem "set ... reset" ändert es sich in "listen_for_wfp". Aber der Listen-Prozess bekommt davon wohl nichts mit. Er nimmt bei einem nachfolgenden Anruf die Verbindung sofort an und wartet nicht auf ein "fetch".
- Ich fände es schön, wenn das "sip_password" nicht im Klartext als Attribut gespeichert wäre, sondern wie bei etlichen anderen FHEM-Modulen versteckt wäre.
Alle Verbindungsaufbauten an sich haben einwandfrei geklappt. Sehr schön.
Was mir vorschwebt: FHEM baut für mich eine Telefonverbindung etwa zum Hausmeister auf. Also ich gebe das Kommando auf das ein notify triggered und damit dann ruft das SIP-Device erst mich auf einem internen Handy an. Ich nehme die Verbindung an und bekomme die Sprachansage: "Nun baue ich die gewünschte Verbindung zum Hausmeister auf". Dann ruft SIP den Hausmeister an und verbindet mich sofort. Wie könnte man das hinbekommen?
@hartenthaler: Danke fürs Feedback
Das Modul ist nicht recht jung und erfährt derzeit sein "Feintuning". Die Doku hinkt dann im Ping-Pong hinterher. Mal liegt das Wiki vorn, mal die command.ref. Inkosistenzen aufzeigen und die eigene Erwartungshaltung posten hilft uns aber das Ding rund zu kriegen.
Bzgl. der Nutzung des SIP-Clients als Telefonvermittlung sehe ich schwarz, dass ist das eher ein Fall für Asterisk.
Hallihallo,
habe heute mit Begeisterung dieses neue Modul installiert und konfiguriert. Ich würde es, neben der Funktion, dass FHEM damit Statusmeldungen per Audiofile abspielen kann, auch zum Ausführen von Befehlen in Abhängigkeit von DTMF Codes nutzen wollen. Leider funktioniert es aber nicht, mit # gefolgt von 2 Ziffern das Reading DTMF zu befüllen. Es erscheint gar nicht. Der Caller wird angezeigt und der State steht auf "listen_for_dtmf".
Ausgehende Anrufe funktionieren tadellos.
Hardware: FHEM auf Cubietruck; Fritzbox 7390 mit OS 7.80 --> 96_SIP.pm 13479 2017-02-21 06:38:37Z
...ausserdem habe ich jetzt im Logfile alle paar Minuten folgende Einträge:
2017.02.22 19:27:08.327 4: FB_SIP, register new expire : Wed Feb 22 19:32:08 2017
2017.02.22 19:29:38.438 4: FB_SIP, register new expire : Wed Feb 22 19:34:38 2017
2017.02.22 19:32:08.548 4: FB_SIP, register new expire : Wed Feb 22 19:37:08 2017
2017.02.22 19:34:38.658 4: FB_SIP, register new expire : Wed Feb 22 19:39:38 2017
Zitat von: hartenthaler am 22 Februar 2017, 18:39:06
- Lokal (FritzFon) hat das Abspielen von DTMF funktioniert, beim Anruf auf mein iPhone habe ich nur Klackgeräusche gehört, aber kein DTMF.
werde ich testen
- Die Eingabe von DTMF am Telefon hat nur einmal am FritzFon funktioniert; nachfolgende Versuche führten zwar zu einer Verbindung, aber das Reading "dtmf" hat sich nicht mehr geändert.
verbose auf 5 und Log beobachten, wichtig : # ist das Starkommando , danach müssen zwei unterschiedliche Tasten gedrückt werden , d.h. in Summe sind immer drei Tasten zu drücken.
- Bei einem set ... reset" hätte ich erwartet, dass das SIP-Device zurück gesetzt wird und ein eventuell vorhandener listen-Prozess gestoppt wird. Aber wenn ich nach einem "set ... reset" ein "set ... listen" mache, dann bekomme ich die Info, dass der listen-Prozess noch läuft. Ist das so beabsichtigt?
ja denn er läuft nicht noch sondern schon wieder , siehe dein Log (geänderte PID)
Ändert mal allerdings das attr sip_listen zuvor auf none dann ist wirklich kein Prozess aktiv nach dem reset.
- Im Logfile habe ich später zwei Meldungen gefunden: "Timeout for SIP_ListenStart reached, terminated process 5395"
siehe oben
- Wenn ich das Attribut "sip_listen" auf "wfp" ändere, ändert sich das Reading state erst einmal nicht, erst nach einem "set ... reset" ändert es sich in "listen_for_wfp". Aber der Listen-Prozess bekommt davon wohl nichts mit. Er nimmt bei einem nachfolgenden Anruf die Verbindung sofort an und wartet nicht auf ein "fetch".
Wenn du bei einem laufenden Listen das attr änderst bekommt der Listen das nicht mit richtig. Dazu muss er erst gestoppt und wieder neu gestartet werden -> set reset. state sollte eigentlich immer die aktuelle Betriebsart des Listen Prozess anzeigen. Werde nochmal die Wechsel im laufendne Betrieb testen.
- Ich fände es schön, wenn das "sip_password" nicht im Klartext als Attribut gespeichert wäre, sondern wie bei etlichen anderen FHEM-Modulen versteckt wäre.
kommt auf die ToDo
meine Anmerkungen im Zitat in
kurisv@Der Tom , dtmf : siehe meine Antwort oben , verbose auf 5 , danach aber wieder auf 3 dann gibt es auch keine bew expire Meldungen mehr im Log :)
Nachtrag, wer Probleme mit DTMF hat : welche Version des Moduls benutzt ihr ?
Die erste Version vom Sonntag hatte da einen Fehler den ich gestern Morgen noch vor 7:45 Uhr gefixt habe.
Ich werde aber heute Abend noch eine neuere Version einchecken die dann bei verbose 5 zum Thema DTMF noch etwas mehr Infos liefert.
Hallo,
beim Listening kommt bei den dmft-Readings fast nie etwas an (bei 40 Versuchen vielleicht 1 x).
Im Log steht nur:
fritz_call, listen prozess 3900 found
Beim Call erscheint im Log:
2017.02.22 19:59:22 4: fritz_call, calling **611, ringtime: 10
2017.02.22 19:59:22 4: fritz_call, register new expire : Wed Feb 22 20:04:22 2017
2017.02.22 19:59:22 4: fritz_call, DTMF : ABCD*#123--4567890
2017.02.22 19:59:32 4: fritz_call, CALLDone -> fritz_call|1|FAIL|HASH(0x3ea2240)
Konfiguration:
define fritz_call SIP
attr fritz_call sip_from sip:621@fritz.box
attr fritz_call sip_ip 192.168.188.30
attr fritz_call sip_listen dtmf
attr fritz_call sip_password my_password
attr fritz_call sip_port 5060
attr fritz_call sip_registrar fritz.box
attr fritz_call sip_ringtime 10
attr fritz_call sip_user 621
attr fritz_call verbose 5
Hardware: Pi 2 mit Jessie, Fritzbox 7390 + Fritzbox 7490
Hat jemand eine Idee?
Gruß,
OnkelTom
Du bist auf dem Holzweg, wenn in dem Reading etwas stehen soll dann must du FHEM anrufen und nicht mit set call ein anders Telefon.
Ansonst : Lies bitte mal was ich direkt vor dir gepostet habe.
@Wzut: Danke für Deine Analyse. Den Fehler warum ich bei der Eingabe von DTMF-Tönen am Handy keine Änderung im Reading beobachten konnte, habe ich wohl gefunden. Ich hatte erst auf dem Testsystem eine Installation, und als das zumindest stabil lief, habe ich auf dem Produktivsystem nachgezogen und hatte damit zwei Clients mit identischen Einstellungen am laufen. Eigenartigerweise habe ich dennoch keine Fehlermeldungen und keine nicht zustande kommenden Verbindungen beobachtet. Aber seit ich die Testinstallation ausgeschaltet habe, funktioniert die DTMF-Erkennung einwandfrei.
In der commandref und im wiki müsste noch erwähnt werden: Es müssen auf dem anrufenden Telefon genau drei Tasten gedrückt werden:
- 1. #
- 2. und 3.: zwei verschiedene Zifferntasten
also #12 oder #13 oder ... #21 oder #23 oder ... oder #98.
Zitat von: hartenthaler am 22 Februar 2017, 20:57:19
- 2. und 3.: zwei verschiedene Zifferntasten
also #12 oder #13 oder ... #21 oder #23 oder ... oder #98.
ein klares jein :) ... der * und die Null dürfen auch benutzt werden , nur # ist immer das Startzeichen.
Hintergrund : Ich hatte massive doppel und dreifach Tasten erkannt, die eleganteste Lösung war für mich das die beiden Zeichen dann unbedingt unterschiedlich sein müssen.
Zitat von: Wzut am 22 Februar 2017, 20:56:19
Du bist auf dem Holzweg, wenn in dem Reading etwas stehen soll dann must du FHEM anrufen und nicht mit set call ein anders Telefon.
Ansonst : Lies bitte mal was ich direkt vor dir gepostet habe.
Das ist mir klar, habe mich aber wohl nicht eindeutig ausgedrückt.
Der erste Log-Auszug stammt von einem Anruf an FHEM.
Den zweiten vom Call an einem anderen Telefon hatte ich nur informativ angehängt.
Ich hatte kurz vor dem Post upgedatet, sodass ich die aktuelle Version haben sollte.
Deinen Post oben hatte ich auch bereits schon gelesen.
Leider funktioniert es trotzdem nicht.
Gruß,
Thomas
Habe gerade die neue Version hochgeladen also wenn es schnell gehen soll sofort direkt aus dem svn holen oder bis morgen um 8:00 warten und dann mit update.
Vielen Dank,
ich werde es morgen früh testen und Dir dann eine Rückmeldung geben.
Gruß,
Thomad
Hallo,
das Update ist installiert.
Leider funktioniert es bei mir nicht reproduzierbar.
Hier hat es nach etlichen Versuchen funktioniert:
Zitat2017.02.23 09:58:33 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=4E6DF6D8710E44D2 | b:Net::SIP::Request=HASH(0x3cd15a0)
2017.02.23 09:59:00 5: fritz_call : DTMF Event : #
2017.02.23 09:59:01 5: fritz_call : DTMF Event : 4
2017.02.23 09:59:01 5: fritz_call : DTMF Total: 4 , Anz: 2
2017.02.23 09:59:02 5: fritz_call : DTMF Event : 1
2017.02.23 09:59:02 5: fritz_call : DTMF Total: 41 , Anz: 3
2017.02.23 09:59:02 5: fritz_call, telnet : set fritz_call dtmf_event 41
2017.02.23 09:59:22 5: fritz_call, listen prozess 18913 found
2017.02.23 09:59:31 5: fritz_call, SIP_bye : HASH(0x30004a8)
2017.02.23 09:59:31 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit
Hier wird zwar registriert, dass die DTMF-Sequenz mit # anfängt, die zwei unterschiedlichen Zahlen, die darauf fogen, werden aber nicht registriert:
Zitat2017.02.23 10:24:07 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=DD6E733ABF5018DA | b:Net::SIP::Request=HASH(0x40c3e00)
2017.02.23 10:24:12 5: fritz_call : DTMF Event : #
2017.02.23 10:25:25 5: fritz_call, listen prozess 1241 found
2017.02.23 10:25:36 5: fritz_call, SIP_bye : HASH(0x40e2168)
2017.02.23 10:25:36 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit
Hier wird gar nicht reagiert:
Zitat2017.02.23 10:28:29 5: fritz_call, SIP_filter : a:"Privat" <sip:**611@fritz.box>;tag=AA8813B385439C74 | b:Net::SIP::Request=HASH(0x40e1b60)
2017.02.23 10:29:48 5: fritz_call, SIP_bye : HASH(0x40e1428)
2017.02.23 10:29:48 5: fritz_call, telnet : set fritz_call caller none
set fritz_call caller_state hangup
exit
Ich hoffe, diese Infos helfen.
Gruß,
Thomas
hmm, nun wird es schwer. Du versucht es immer mit dem gleichen Telefon ?
Was ist das für ein Gerät ( DECT? , FritzPhone ? ) ?
Hast du die Möglichkeit es mal mit einem anderen Telefon zu testen oder sogar von extern ?
Zitat von: Wzut am 23 Februar 2017, 11:08:06
hmm, nun wird es schwer. Du versucht es immer mit dem gleichen Telefon ?
Was ist das für ein Gerät ( DECT? , FritzPhone ? ) ?
Hast du die Möglichkeit es mal mit einem anderen Telefon zu testen oder sogar von extern ?
Hallo,
ich habe es bereits mit Fritz!Fon C5, Fritz!Fon MT-F, Fritz!App Fon und soeben von extern (Smartphone) probiert.
Das Ergebnis ist leider identisch.
Gruß,
Thomas
Auf meinem Raspi2 läuft die DTMF-Erkennung auch noch nicht ganz rund. Sowohl mit der Fritzfon-App als auch einem Gigaset-DECT-Telefon kann ich DTMF-Töne senden, aber vozugsweise in der Kurzform anwählen->#nm->auflegen. Wenn man nach dem ersten Reading weitere #nm's absetzen will steigt die Fehlerquote deutlich.
VG plin
Hi,
Danke, dass sich jemand um dieses Modul kümmert. Ich warte ja schon sehr lange auf die Möglichkeit mit diesem Modul auch DTMF-Sequenzen übertragen zu können. Ich habe mir bis dato mit einem "System-Aufruf" von linphone beholfen. Schöner wäre das natürlich über ein fhem-Modul.
Leider kann ich aber die "DTMF senden" Funktion des Moduls (noch) nicht für meine Zwecke nutzen, da die DTMF-Sequenz zu schnell nach dem Antworten/Abheben der Gegenstelle abgefeuert wird. Ich befürchte, dass dies einige Geräte wie z.B. Telefonschaltgeräte nicht mögen, da sie sich wie ein Telefax zuerst mit einem "Bestätigungston" melden.
Könnte man hier irgendwo eine Pause (sleep ?) im Modul einbauen oder vielleicht sogar als Attribut vorgeben?
Wenn mir jemand sagt wo, würde ich das sogar händisch in 96_SIP.pm eintragen ;)
Ich bedank mich mal sicherheitshalber im Voraus!!!
SG
Fred
Zitat von: plin am 23 Februar 2017, 18:46:23
Auf meinem Raspi2 läuft die DTMF-Erkennung auch noch nicht ganz rund. Sowohl mit der Fritzfon-App als auch einem Gigaset-DECT-Telefon kann ich DTMF-Töne senden, aber vozugsweise in der Kurzform anwählen->#nm->auflegen. Wenn man nach dem ersten Reading weitere #nm's absetzen will steigt die Fehlerquote deutlich.
beim pi3 kann ich stundenlang, ohne aufzulegen, fehlerfrei dtmf erkennen (aktuelle version). :)
registriert als türsprecheinrichtung in fb7490 mit MTF und C4.
beim attr sip_ip muss ich unbedingt die ip als zahl eingeben, sonst geht gar nichts.
bei sip_registrar und sip_from funktioniert auch fritz.box.
noch 2 hinweise:
1. das modul könnte noch eine versions ID vertragen.
2. im set-call-eingabefeld erscheint nach einem "set call x" immer der inhalt des readings call. also erst die rufnummer und zum schluss ein done.
Zitat von: fred2412 am 23 Februar 2017, 20:10:35
Könnte man hier irgendwo eine Pause (sleep ?) im Modul einbauen oder vielleicht sogar als Attribut vorgeben?
die passende Stelle ist irgendwo in den Tiefen von Net::Sip vergraben :( , aber vllt lässt sich auch das wieder nur mit Bordmitteln lösen :
Die DTMF Zeichenfolge kennt noch das Minuszeichen (-) hier wird eine Pause von einem Ton gemacht. Versuche doch einfach mal deinen DTMF String statt nur einem Minus (das ist die Starterkennung ) mit 10 oder noch mehr beginnen zu lasssen und ggf. auch Pausen zwischen den Zeichen
set mySIP call 0815 10 -----------0-1--2---3
Zitat von: frank am 23 Februar 2017, 20:22:07
beim attr sip_ip muss ich unbedingt die ip als zahl eingeben, sonst geht gar nichts.
bei sip_registrar und sip_from funktioniert auch fritz.box.
1. das modul könnte noch eine versions ID vertragen.
2. im set-call-eingabefeld erscheint nach einem "set call x" immer der inhalt des readings call. also erst die rufnummer und zum schluss ein done.
a. ja, Net::Sip will an dieser Stelle unbedingt die IP des passenden Interfaces (Bsp eth0) , Joker ala 0.0.0.0 wie z.B. beim Apache für beliebige Schnittstellen sind nicht zulässig !
b. das sollte so sein wenn der FHEM Server sein DNS im Griff hat
1. kommt auf die ToDo
2. ein Punkt der mich auch schon bei anderen Modulen gestört hat und seine Ursache wohl in fhemweb hat. Immer wenn ein set Befehl genauso heist wie ein Reading wird einem der aktuelle Wert des Readings vorgelegt. Abhilfe würde z.B. schaffen den set call in set makecall zu ändern, aber ich denke doch das zu mehr als 90% der set call via Skript oder notify benutzt wird und nicht von Hand im Web Frontend.
Zitat von: Wzut am 24 Februar 2017, 11:01:20
a. ja, Net::Sip will an dieser Stelle unbedingt die IP des passenden Interfaces (Bsp eth0) , Joker ala 0.0.0.0 wie z.B. beim Apache für beliebige Schnittstellen sind nicht zulässig !
b. das sollte so sein wenn der FHEM Server sein DNS im Griff hat
ich hatte bei a. den hostnamen vom fhemserver probiert, da er über wlan/dhcp angebunden wird. zwar angeblich immer mit derselben ip, aber ich traue meinem wlan zur zeit nicht wirklich. sollte eigentlich nur ein deutlicher hinweis für die mitstreiter sein, die gerade probleme bei ihrer inbetriebnahme des sipdevices haben.
Zitat2. ein Punkt der mich auch schon bei anderen Modulen gestört hat und seine Ursache wohl in fhemweb hat. Immer wenn ein set Befehl genauso heist wie ein Reading wird einem der aktuelle Wert des Readings vorgelegt. Abhilfe würde z.B. schaffen den set call in set makecall zu ändern, aber ich denke doch das zu mehr als 90% der set call via Skript oder notify benutzt wird und nicht von Hand im Web Frontend.
das kannte ich noch nicht, ist dann aber auch ok so.
gruss frank
Zitat von: Wzut am 22 Februar 2017, 20:34:56
@Der Tom , dtmf : siehe meine Antwort oben , verbose auf 5 , danach aber wieder auf 3 dann gibt es auch keine bew expire Meldungen mehr im Log :)
Ganz so einfach war es nicht. Nach einem Verbose auf 3 (oder delete) kamen die Einträge immernoch. Nach einem Restart dann nicht mehr...
Habe mittlerweile auch ein Update gemacht, bekomme aber weiterhin kein DTMF Reading...weder bei einem Anruf von extern (Handy) noch intern (MT-F oder C4). Reading "state" steht immernoch auf "listen_for_dtmf".
Auch gibt es ja jetzt das Reading "caller_state" allerdings hat die immer nur den Wert "hangup". Dieser wird immer wieder aktualsiert, wenn der Anruf aufgelegt wird. Einen anderen Wert sehe ich nie.
Im Log sehe ich bei verbose 5 nur die folgenden Einträge:
2017.02.25 10:23:37.253 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=DBEC537E93AB3E25 | b:Net::SIP::Request=HASH(0x4c4d3c0)
2017.02.25 10:23:40.821 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:41.876 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:46.555 5: FB_SIP, SIP_bye : HASH(0x56d57d8)
2017.02.25 10:23:46.555 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
Und damit keine Missverständnisse aufkommen: Ich habe nur einmal die Taste # gedrückt. Erkannt werden aber meist 2 oder sogar auch mal 3 mal #...
Von extern wird immer nur einmal die Taste # erkannt, weitere aber nicht...
2017.02.25 10:25:37.837 5: FB_SIP, SIP_filter : a:"xxx" <sip:xxxx@fritz.box>;tag=DBD7D0FFA96578BB | b:Net::SIP::Request=HASH(0x5747db8)
2017.02.25 10:25:46.971 5: FB_SIP : DTMF Event : #
2017.02.25 10:25:48.529 5: FB_SIP, SIP_bye : HASH(0x587d1b8)
2017.02.25 10:25:48.530 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
Hallo,
mein FHEM läuft unter auf Rpi 2 (wheezy). Eine Verbindung soll zu einer Auerswald-Türsprechstelle via FB 7490 (FRITZ!OS: 06.80) hergestellt werden
Installation des SIP Modul hat geklappt, client wurde auf FB unter 621 registriert, Anruf (intern) wird auch in fhem caller_state:ringing bzw caller_state:hangup signalisiert. Eine Verbindung wird aber nicht aufgebaut.
Der Versuch über set call eine Verbindung (intern oder extern) herzustellen, scheitert allerdings. Eintrag im Logfile (verbose 5:)
Can't use string ("**611") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
2017.02.25 12:39:40 4: SIP, DTMF : ABCD*#123--4567890
2017.02.25 12:39:40 4: SIP, register new expire : Sat Feb 25 12:44:40 2017
2017.02.25 12:39:38 5: SIP, call has pid 3737
2017.02.25 12:39:38 4: SIP, calling **611, ringtime: 10
Bin mit meinem Latein zu Ende...
LG
Jorge
Zitat von: jorge am 25 Februar 2017, 12:43:58
mein FHEM läuft unter auf Rpi 2 (wheezy).
hast dir mal den Ur Thread https://forum.fhem.de/index.php/topic,40219.0.html durchgelesen ?
Wheezy installiert mit apt-get install eine uralte Version von Net::Sip die eigentlich bei allen immer nur Probleme machte.
Daher wurde damals meist das Paket direkt mit cpan installiert. (Ist im FB Thread beschrieben)
Zitat von: DerTom am 25 Februar 2017, 10:27:08
Nach einem Verbose auf 3 (oder delete) kamen die Einträge immernoch. Nach einem Restart dann nicht mehr...
klar weil der Listen Prozess noch immer 5 hatte , ein set FB_SIP reset hätte es auch getan
Zitat von: DerTom am 25 Februar 2017, 10:27:08
Reading "state" steht immernoch auf "listen_for_dtmf".
Das soll auch so sein :)
2017.02.25 10:23:37.253 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=DBEC537E93AB3E25 | b:Net::SIP::Request=HASH(0x4c4d3c0)
2017.02.25 10:23:40.821 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:41.876 5: FB_SIP : DTMF Event : #
2017.02.25 10:23:46.555 5: FB_SIP, SIP_bye : HASH(0x56d57d8)
Das Startzeichen wurde schon mal erkannt - gut. Das es gedoppelt hat kommt vor ist aber nicht tragisch da wie ich schon schrieb diese Wiederholungen verworfen werden. Tipp : Ich sehe das du recht schnell ( 5 Sekunden ) aufgegeben hast. Nimm dir mal etwas mehr Zeit, setzte attr_ringtime auf z.B. 30 und drücke nach dem Anruf bzw dem # ruhig mal alle Zahlentasten langsam durch, ist ein event im Event Monitor erschienen , wieder mit dem # beginnen und probieren. (natürlich wieder mit verbose 5) Das Modul trennt dir erst die Verbindung wenn ringtime abgelaufen ist , hast also viel Zeit zum Tasten drücken.
ich habe auch versucht im Netz etwas mehr Hintergrundinfos zu DTMF zu bekommen. Fragen :
a. gibt es die Probleme auch beim Anrufen con Call Centern wo man div Tasten drücken muss um durch die Menüs zu kommen ?
b. läuft der Anschlus zum Provider auch via VoIP -VDSL oder noch DSL, ISDN, analog ?
Hallo
mußte es auch so installieren wie von YellowBall geschrieben
Zitat
2. Die Datei Net-SIP-0.687.tar.gz herunterladen und in ein Verzeichnis auf dem Pi ablegen
3. Entpacken mit sudo gunzip Net-SIP-0.687.tar.gz
4. tar-ball entpacken mit sudo tar -xvf Net-SIP-0.687.tar.gz
5. in das enstandene Verzeichnis Net-SIP-0.687 wechseln
5. folgende Befehle nacheinander eingeben
sudo perl Makefile.PL
sudo make
sudo make test
sudo make install
sync
sudo reboot
6. Nach dem Reboot sollte es funzen - so war es jedenfalls bei mir
Gruß Bernd
Zitat von: Bastelbernd am 25 Februar 2017, 14:18:15
Hallo
mußte es auch so installieren wie von YellowBall geschrieben
Gruß Bernd
@ Bastelbernd Mußte ich auch. Dann ging es. Hatte leider den alten Thread nicht gelesen, sonst wär ich wohl selber darauf gekommen.
@ Wzut Danke für den gedulidigen Hinweis.
Bin gespannt, was da noch kommt...
LG Jorge
Zitat von: jorge am 25 Februar 2017, 15:00:05
Bin gespannt, was da noch kommt...
och , plin und ich haben da schon noch ein paar offene Punkte auf unsere Liste .....
Läuft auf Anhieb - spitze!
Hat schon jemand eine Sprachausgabe dazu gebastelt? Ich fände interessant, wenn FHEM mich mit dynamisch generierten Texten über Ereignisse informieren würde...
Hallo Wzut,
Zitat von: Wzut am 25 Februar 2017, 13:53:53
Das Startzeichen wurde schon mal erkannt - gut. Das es gedoppelt hat kommt vor ist aber nicht tragisch da wie ich schon schrieb diese Wiederholungen verworfen werden. Tipp : Ich sehe das du recht schnell ( 5 Sekunden ) aufgegeben hast. Nimm dir mal etwas mehr Zeit, setzte attr_ringtime auf z.B. 30 und drücke nach dem Anruf bzw dem # ruhig mal alle Zahlentasten langsam durch, ist ein event im Event Monitor erschienen , wieder mit dem # beginnen und probieren. (natürlich wieder mit verbose 5) Das Modul trennt dir erst die Verbindung wenn ringtime abgelaufen ist , hast also viel Zeit zum Tasten drücken.
Ich habe das Attr. ringtime auf 30 gesetzt. Getrennt wird da aber nichts. Habe sogar mehrfach versucht mal ne Minute oder auch 2 auf die Testen zu drücken. Bei einem mal kam dann folgendes raus...
2017.02.25 19:20:13.234 5: FB_SIP, SIP_filter : a:"xxxxxx" <sip:yyyyyy@fritz.box>;tag=251CF4EE518145DE | b:Net::SIP::Request=HASH(0x4d71e78)
2017.02.25 19:20:25.289 5: FB_SIP : DTMF Event : #
2017.02.25 19:20:25.939 5: FB_SIP : DTMF Event : 6
2017.02.25 19:20:25.940 5: FB_SIP : DTMF Total: 66 , Anz: 2
2017.02.25 19:20:27.275 5: FB_SIP, listen prozess 14799 found
2017.02.25 19:20:32.359 5: FB_SIP : DTMF Event : 9
2017.02.25 19:20:32.360 5: FB_SIP : DTMF Total: 669 , Anz: 3
2017.02.25 19:20:32.360 5: FB_SIP, telnet : set FB_SIP dtmf_event 669
2017.02.25 19:20:43.607 5: FB_SIP : DTMF Event : 6
2017.02.25 19:20:56.574 5: FB_SIP : DTMF Event : 6
2017.02.25 19:21:01.658 5: FB_SIP, SIP_bye : HASH(0x5574928)
2017.02.25 19:21:01.659 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
bei den anderen manchmal nur ein "#", machmal auch gar nichts oder nur eine 6 oder eine 9 ...
Lustig ist ja, daß immer nur die 6 und die 9 erkannt wird, auch wenn ich die gar nicht drücke!!
2017.02.25 19:29:30.824 5: FB_SIP, SIP_filter : a:"xxxx" <sip:yyyyy@fritz.box>;tag=B5AA4F89FAB08532 | b:Net::SIP::Request=HASH(0x56ccd88)
2017.02.25 19:29:40.658 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:41.779 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:43.852 5: FB_SIP : DTMF Event : 6
2017.02.25 19:29:43.853 5: FB_SIP : DTMF Total: 66 , Anz: 2
2017.02.25 19:29:44.106 5: FB_SIP : DTMF Event : #
2017.02.25 19:29:53.824 5: FB_SIP, SIP_bye : HASH(0x5841680)
2017.02.25 19:29:53.825 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
Bei diesem Beispiel habe ich die Zahlenfolge #12#35#12#23#34#45# gedrückt. ... weder eine noch 2 mal die 6. Ist doch eher komisch, oder?
Zitat
ich habe auch versucht im Netz etwas mehr Hintergrundinfos zu DTMF zu bekommen. Fragen :
a. gibt es die Probleme auch beim Anrufen con Call Centern wo man div Tasten drücken muss um durch die Menüs zu kommen ?
b. läuft der Anschlus zum Provider auch via VoIP -VDSL oder noch DSL, ISDN, analog ?
zu a: nein
zu b: Ich habe hier einen Magenta Tarif, was ja ein VoIP Anschluss ist (in meinem Fall VDSL).
Nebenbei: Kann es sein, daß der CallMonitor, der bei mir parallel dazu läuft, Probleme verursacht?
Zitat von: f-zappa am 25 Februar 2017, 18:24:19
Hat schon jemand eine Sprachausgabe dazu gebastelt? Ich fände interessant, wenn FHEM mich mit dynamisch generierten Texten über Ereignisse informieren würde...
ich hatte bisher nie Bedarf für Sprachausgabe. Wenn ich die command.ref zu Text2Speech richtig verstehe, geht das Audiofile immer direkt zum Alsadevice via mplayer.
Wenn es aber einen Weg gibt das zu unterdrücken und die mp3 unter einem definierten Namen abzuspeichern könnte man die vermutlich on-the-fly mit sox konvertieren und dem call Befehl übergeben. Dafür müsste mir aber jemand Nachhilfestunden in Sachen TTS geben.
@DerTom, z.Z. stehe ich da auch auf dem Schlauch. Bis jetzt ist mir nur klar das es für DTMF zwei verschiedene Übertragungsarten gibt (rfc2833 & audio).
Fritzbox User können da Parameter ändern , siehe :
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/361_Fernsteuerung-von-Telefoniegeraeten-und-Sprachcomputern-nicht-moeglich/
da ich kein VoIP Anschluss habe kann ich da auch nichts ändern und testen. Ich habe auch keine Ahnung ob die Änderungen dann nur für externe Übertragungen gelten oder auch im eigenen Netz.
Zitat von: Wzut am 25 Februar 2017, 19:45:43
@DerTom, z.Z. stehe ich da auch auf dem Schlauch. Bis jetzt ist mir nur klar das es für DTMF zwei verschiedene Übertragungsarten gibt (rfc2833 & audio).
Fritzbox User können da Parameter ändern , siehe :
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/361_Fernsteuerung-von-Telefoniegeraeten-und-Sprachcomputern-nicht-moeglich/
Ich gehe davon aus, daß dies maximal die ausgehenden DTMF-Töne beeinflusst, nicht die eingehenden. Jegliche Änderung der Einstellungen in meiner FB bringt keinen Unterschied im Ergebnis.
Zitat
da ich kein VoIP Anschluss habe kann ich da auch nichts ändern und testen.
Nun, das wird sich ändern, da ja bekanntlich bis Ende 2018 alle Anschlüsse auf IP umgestellt werden. ISDN - basierte Anschlüsse gehören dann der Vergangenheit an.
Zitat
Ich habe auch keine Ahnung ob die Änderungen dann nur für externe Übertragungen gelten oder auch im eigenen Netz.
Wenn man Einstellungen bei der Registriegung der Internrufnummer in der FB macht, können diese ja nur extern gelten. Da es intern bei mir allerdings auch nicht geht, liegt es vermutlich nicht an der Fritzbox oder zumindest an den Einstellungen, die im KB Artikel von AVM genannt sind.
Auf jeden Fall, vielen Dank für die Idee und die bisherige Umsetzung, auch wenn sie derzeit für micht nichts bringt, da es weiterhin nicht funktioniert...Schade.
@DerTom
probiere doch mal die registrierung als sip türsprecheinrichtung in der fritzbox.
damit komme ich auf 100% erkennung.
in der fritzbox habe ich unter dect-monitor einen bitfehlertest. hast du dort auffälligkeiten?
@frank:
Vielen Dank für den Tipp. Allerdings habe ich ein Problem. Ich kann ja keine Türsprechanlage anrufen...Ich will ja die DTMF-Töne in FHEM auswerten und damit Aktionen auslösen. Nicht umgekehrt, also FHEM DTMF-Töne senden lassen.
Da Du es ja scheinbar erfolgreich eingerichtet hast, kannst Du mir erklären wie? Von extern geht es meiner Meinung nach nicht, da die IP-Türsprechanlage keine externe Nummer für Anrufe von Aussen haben kann. Oder sehe ich das falsch?
Der Bitfehlertest zeigt keinerlei Probleme an.
ich habe auch keine physische türsprecheinrichtung, nur das sip-device als solche registriert. sozusagen eine virtuelle.
telefonie -> telefoniegeräte -> neues gerät einrichten -> türsprechanlage -> weiter -> lan/wlan -> weiter
benutzer und passwort (wie im sipdevice) -> weiter -> weiter -> übernehmen. fertig.
unter telefoniegeräte siehst du dann die interne nummer.
ZitatVon extern geht es meiner Meinung nach nicht, da die IP-Türsprechanlage keine externe Nummer für Anrufe von Aussen haben kann. Oder sehe ich das falsch?
das stimmt wohl.
aber vielleicht mal einen versuch wert, ob es einen unterschied macht.
Also ich habs jetzt intern probiert. die interne Nummer ist jetzt wieder die **620. Kann ich von meinen Telefonen (MT-F und C4) anrufen. OK soweit. Allerdings gibt es auch hier die gleichen Probleme, wie der Anruf von extern. Von ca. 10 Versuchen hat es nur ein mal funktioniert, die eigegebene Zeichenfolge in das DTMF-Reading zu übergeben.
2017.02.26 16:05:57.230 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=8406EB7AFA155E65 | b:Net::SIP::Request=HASH(0x588c430)
2017.02.26 16:06:03.233 5: FB_SIP : DTMF Event : #
2017.02.26 16:06:13.135 5: FB_SIP : DTMF Event : 2
2017.02.26 16:06:13.136 5: FB_SIP : DTMF Total: 2 , Anz: 2
2017.02.26 16:06:13.226 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:06:43.492 2: HMCCU: Received no events from CCU since 300 seconds
2017.02.26 16:07:05.467 5: FB_SIP : DTMF Event : #
2017.02.26 16:07:12.022 5: FB_SIP : DTMF Event : 7
2017.02.26 16:07:12.022 5: FB_SIP : DTMF Total: 27 , Anz: 2
2017.02.26 16:07:13.294 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:07:28.382 5: FB_SIP : DTMF Event : 4
2017.02.26 16:07:28.382 5: FB_SIP : DTMF Total: 274 , Anz: 3
2017.02.26 16:07:28.383 5: FB_SIP, telnet : set FB_SIP dtmf_event 274 --> HIER HATTE ICH MEHRFACH #27 PROBIERT - ABER NIEMALS DIE 4
2017.02.26 16:07:45.409 5: FB_SIP : DTMF Event : 7
2017.02.26 16:07:54.359 5: FB_SIP : DTMF Event : 1
2017.02.26 16:08:09.188 5: FB_SIP : DTMF Event : #
2017.02.26 16:08:13.362 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:08:37.373 5: FB_SIP : DTMF Event : 5
2017.02.26 16:08:37.373 5: FB_SIP : DTMF Total: 5 , Anz: 2
2017.02.26 16:08:53.415 5: FB_SIP : DTMF Event : 8
2017.02.26 16:08:53.416 5: FB_SIP : DTMF Total: 58 , Anz: 3
2017.02.26 16:08:53.416 5: FB_SIP, telnet : set FB_SIP dtmf_event 58 --> HIER HATTE ICH NICHT 58 GETIPPT, SONDERN ###555888
2017.02.26 16:09:13.429 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:09:26.020 5: FB_SIP, SIP_bye : HASH(0x588e018)
2017.02.26 16:09:26.021 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
2017.02.26 16:09:26.156 4: FB_SIP, register new expire : Sun Feb 26 16:14:26 2017
2017.02.26 16:09:43.120 5: FB_SIP, telnet : set FB_SIP caller Mobilteil_1 sip:**610@fritz.box
exit
2017.02.26 16:09:43.123 5: FB_SIP, SIP_filter : a:"Mobilteil_1" <sip:**610@fritz.box>;tag=2646A33E08AA71DA | b:Net::SIP::Request=HASH(0x31b77a8)
2017.02.26 16:09:48.629 5: FB_SIP : DTMF Event : #
2017.02.26 16:09:52.484 5: FB_SIP : DTMF Event : 4
2017.02.26 16:09:52.485 5: FB_SIP : DTMF Total: 4 , Anz: 2
2017.02.26 16:09:52.659 5: FB_SIP : DTMF Event : 5
2017.02.26 16:09:52.659 5: FB_SIP : DTMF Total: 45 , Anz: 3
2017.02.26 16:09:52.660 5: FB_SIP, telnet : set FB_SIP dtmf_event 45 --> HIER HATTE ICH #45 GETIPPT , DAS EINZIGE MAL, DAß ES FUNKTIONIERT HAT...
2017.02.26 16:10:13.496 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:10:27.034 5: FB_SIP : DTMF Event : 8
2017.02.26 16:10:48.145 5: FB_SIP : DTMF Event : 7
2017.02.26 16:11:13.566 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:11:16.468 5: FB_SIP, SIP_bye : HASH(0x56d51a8)
2017.02.26 16:11:16.469 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
Es ist einfach zu instabil...warum auch immer.
Mir will auch nicht in den Kopf, warum er manchmal 3 Ziffern in das DTMF Reading schreibt, es aber eigentlich laut Beschreibung nur 2 Ziffern sein sollen...Im nachfolgenden Beispiel habe ich immer nur 2 Ziffern gesendet immer getrennt mit #. Und niemals 2 gleiche Ziffern hintereinander.
2017.02.26 16:22:03.238 5: FB_SIP, SIP_filter : a:"Mobilteil_2" <sip:**612@fritz.box>;tag=E06C8C6E87C985B6 | b:Net::SIP::Request=HASH(0x588d560)
2017.02.26 16:22:10.423 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:14.563 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:22:27.185 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:27.717 5: FB_SIP : DTMF Event : 5
2017.02.26 16:22:35.206 5: FB_SIP : DTMF Event : #
2017.02.26 16:22:36.965 5: FB_SIP : DTMF Event : 2
2017.02.26 16:22:36.966 5: FB_SIP : DTMF Total: 2 , Anz: 2
2017.02.26 16:22:38.332 5: FB_SIP : DTMF Event : 5
2017.02.26 16:22:38.333 5: FB_SIP : DTMF Total: 25 , Anz: 3
2017.02.26 16:22:38.333 5: FB_SIP, telnet : set FB_SIP dtmf_event 25
2017.02.26 16:22:50.968 5: FB_SIP : DTMF Event : 1
2017.02.26 16:22:58.795 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:00.541 5: FB_SIP : DTMF Event : 1
2017.02.26 16:23:00.542 5: FB_SIP : DTMF Total: 1 , Anz: 2
2017.02.26 16:23:09.534 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:11.543 5: FB_SIP : DTMF Event : 1
2017.02.26 16:23:11.543 5: FB_SIP : DTMF Total: 11 , Anz: 2
2017.02.26 16:23:13.399 5: FB_SIP : DTMF Event : 4
2017.02.26 16:23:13.399 5: FB_SIP : DTMF Total: 114 , Anz: 3
2017.02.26 16:23:13.400 5: FB_SIP, telnet : set FB_SIP dtmf_event 114
2017.02.26 16:23:14.631 5: FB_SIP, listen prozess 20272 found
2017.02.26 16:23:27.691 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:31.983 5: FB_SIP : DTMF Event : 7
2017.02.26 16:23:31.983 5: FB_SIP : DTMF Total: 7 , Anz: 2
2017.02.26 16:23:41.435 5: FB_SIP : DTMF Event : #
2017.02.26 16:23:43.674 5: FB_SIP : DTMF Event : 6
2017.02.26 16:23:43.675 5: FB_SIP : DTMF Total: 76 , Anz: 2
2017.02.26 16:24:03.135 5: FB_SIP : DTMF Event : 9
2017.02.26 16:24:03.136 5: FB_SIP : DTMF Total: 769 , Anz: 3
2017.02.26 16:24:03.136 5: FB_SIP, telnet : set FB_SIP dtmf_event 769
Zitat von: DerTom am 26 Februar 2017, 13:30:38
Allerdings habe ich ein Problem. Ich kann ja keine Türsprechanlage anrufen...
Ich habe es wie Frank eingerichtet. Intern kann ich die Türsprechstelle **628 anrufen. Und von extern geht es duch eine Rufumleitung auch. Ich habe eine externe MSN dafür hergenommen und diese in der Fritzbox auf die 628 umgeleitet. Damit ist FHEM von extern anrufbar und empfängt die DTMF, die ich dann per notify auswerte.
Zumindest im Prinzip. Manchmal, so wie gerade eben, bekomme ich bei der Eingabe von #89 als Reading 898. Ich vermute mal ein Problem mit dem Echo. Wenn ich die 8 drücke höre ich einige Zeit später ein Echo dieses Tastendrucks. Wahrscheinlich dringt das dann wieder zum Empfänger durch und wird gleich nochmal ausgewertet. Kann man diesen Bestätigungston unterdrücken? Oder kann man die Erkennung so programmieren, dass nach zwei verschiedenen erkannten Zahlen generell Schluß ist und das Reading gesetzt wird, d.h. dass das Reading garantiert immer aus genau zwei verschiedenen Ziffern besteht. Diese Vielfalt sollte ja erst mal reichen.
Um die Liste der wünschenswerten Dinge zu erweitern: wie wäre es mit einem Sprachdialogsystem? Also man ruft FHEM an, bekommt eine Begrüßung per Sprache und ein paar Menüpunkte: Wählen Sie eine 1 für Lichtsteuerung, eine 2 um die Haustür zu öffnen, etc. Natürlich nur nachdem man sich authentifiziert hat (per PIN-Code, per Stimmmuster, Geheimwort, ...). Und dann eben die zweite Stufe des Dialogs: "Wählen Sie eine 1 für die Deckenlampe, eine 2 für den Deckenfluter, ...".
Oder gleich wie bei Alexa: man ruft FHEM/SIP an sagt "mache das Licht im Wohnzimmer an." Dieses Sprachkommando wird, sobald man eine Pause macht, an den Alexa-Voice-Service geschickt, dort bearbeitet und löst dann die gewünschte die Aktion aus. Die Antwort/Qittung wird dann wieder in die Telefonverbindung eingespielt, so dass man als Anrufer weiß, dass man verstanden worden ist.
Ja, OK. Ne Rufumleitung geht. Hier habe ich aber die gleichen Probleme wie intern...
Allerdings würde ich mich freuen, wenn es nur manchmal nicht funktioniert. Bei mir ist es der Regelfall. Was mache ich denn anders als Ihr? Habe mich strikt an das Wiki und die Commandref gehalten...
Internals:
LPID 21119
NAME FB_SIP
NR 606
STATE listen_for_dtmf
TYPE SIP
Readings:
2017-02-25 13:17:05 call done
2017-02-25 13:17:05 call_state ok
2017-02-26 17:08:10 caller none
2017-02-26 17:08:10 caller_state hangup
2017-02-26 16:44:40 dtmf 5823
2017-02-26 16:30:30 state listen_for_dtmf
Helper:
Listen_pid:
abortArg
abortFn
arg FB_SIP
bc_pid 4054
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 21119
timeout
Attributes:
room Fritzbox
sip_from sip:620@fritz.box
sip_ip 192.168.xxx.zzz
sip_listen dtmf
sip_password <password>
sip_port 5060
sip_registrar 192.168.xxx.yyy
sip_ringtime 30
sip_user 620
verbose 5
Zitat von: hartenthaler am 26 Februar 2017, 16:41:56
Kann man diesen Bestätigungston unterdrücken? Oder kann man die Erkennung so programmieren, dass nach zwei verschiedenen erkannten Zahlen generell Schluß ist und das Reading gesetzt wird, d.h. dass das Reading garantiert immer aus genau zwei verschiedenen Ziffern besteht. Diese Vielfalt sollte ja erst mal reichen.
Kann man ? Ja, Mann kann fast alles :)
Im Ernst : meine aktuelle Version hat ein neues Attr dtmf_size (Bereich von 1 bis 4) damit lege ich fest ab wann der Event erzeugt werden soll.
In der aktuellen Version ist die Abfrage auf größer 2 (der # wird mit gerechnet) , daher kann es zum oben beschrieben Effekt mit den drei Ziffern kommen.
Ich muss mal schauen was passiert wenn ich das Echo rausnehme.
Zitat von: DerTom am 26 Februar 2017, 17:15:34
Was mache ich denn anders als Ihr?
Vermutlich nichts , die Frage ist vllt welches FB Modell mit welcher Firmware du benutzt.
Bzw. auf welchem Unterbau läuft das SIP Modul und welche Version von Net::Sip ?
Zitat von: Wzut am 25 Februar 2017, 19:45:43
ich hatte bisher nie Bedarf für Sprachausgabe. Wenn ich die command.ref zu Text2Speech richtig verstehe, geht das Audiofile immer direkt zum Alsadevice via mplayer.
Wenn es aber einen Weg gibt das zu unterdrücken und die mp3 unter einem definierten Namen abzuspeichern könnte man die vermutlich on-the-fly mit sox konvertieren und dem call Befehl übergeben. Dafür müsste mir aber jemand Nachhilfestunden in Sachen TTS geben.
Vielleicht wäre es einfacher und universeller, wenn man statt Files und DTMF-Tönen als weitere Möglichkeit einbaut, dass ein externes Programm die Audioausgabe erzeugt.
Dazu könnte man ein weiteres Präfix einführen (z.B. "+") und das externe Kommando könnte in ein Attribut (z.B. "sip_outputcmd = /usr/local/bin/mein_tts_script.sh"). Wenn die Nachricht in "set<name> call <nummer> [<ringtime>] [<nachricht>" mit dem Präfix beginnt, würde das hinterlegte Script (mit dem Rest von <nachricht> als Argument) ausgeführt und dessen Output (statt eines fixen Files) abgespielt.
Damit könnte sich jeder seine bevorzugte eigene TTS einbinden - oder auch andere Spielereien umsetzen, z.B. Musik abspielen.
Hallo,
kurzer Zwischenstand zum Thema listen_for_dtmf auf einem Raspi2: Bei mir kommt auch kaum ein Tastendruck durch. Die FHEM-Instanz auf meinem Server mit Intel-CPU hat keine Probleme jeden einzelnen Tastendruck zu erkennen. htop hat mir dann gezeigt, dass der erste der 4 Cores des Raspi2 auf 100% geht, sobald FHEM den listen_for_dtmf-Anruf entgegen genommen hat. Wenn man aber schnell genug ist (anrufen, #23 absetzen, auflegen) klappt's.
Ist vielleicht doch etwas viel für die kleine Kiste.
VG plin
P.S. Auf beiden ist Net:SIP 0.808 installiert und ein aktuelles FHEM. Die Rahmenbedingungen sind also identisch.
Ankündigung
Ab morgen früh wird es eine neue Version geben.
Die wichtigste Änderung : Das Attribut sip_password wurde entfernt !
Um das das Passwort des SIP Users zu setzen muss einmalig der Befehl set <name> password <das_SIP_Passwort> ausgeführt werden.
(Nutzer des 72_FRITZBOX Moduls sollten das Verfahren zum Passwort speichern schon kennen)
Neu :
Attribut sip_dtmf_size , ( Wert 1 - 4 , default 2) damit ist der DTMF Empfang nicht mehr zwingend an 2 Zeichen gebunden.
Verbessertes Reading call_state, bei einem ausgehenden Anruf via set call kann nun in call_state angezeigt werden ob die Nachricht vollständig übertragen wurde (ok),
ob die Gegenseite den Ruf abgewiesen hat (canceled) oder gar nicht erst angenommen hat (no answer)
Hallo,
ich habe die "alte" Version jetzt ein paar Tage getestet und finde es bisher sehr gelungen.
Angebunden habe ich FHEM an meine Asterisk-Telefonanlage als eigene Nebenstelle die sicherheitshalber keine Amtberechtigung hat.
Nutzen die ich es derzeit als Wecker, habe einfach einen call Befehl der mein schnurgebundes Nachttischtelefon klingeln läßt und mir ein
dieses ist ihr Weckruf gelaber wie im Hotel ansagt.
Zusätzlich nutze ich die Funktion mit der dtmf-Erkennung um mit der ich einige Geräte steuern kann ohne vom Sofa aufstehen zu müssen...
Ein notify guckt wenn dtmf gekommen ist..
Notify_DEV: sip_160:dtmf:.* {dtmf_read()}
und startet ein sub zum auswerten.
sub
dtmf_read
{
my $dtmf = ReadingsVal('sip_160','dtmf','');
#Deckenlampen
if ($dtmf == 01){{fhem ("set LS_Esstisch toggle")}}
# Heizung
if ($dtmf == 50){{fhem ("set Heizungsmodus OFF")}}
if ($dtmf == 51){{fhem ("set Heizungsmodus MIN")}}
if ($dtmf == 52){{fhem ("set Heizungsmodus ECO")}}
if ($dtmf == 53){{fhem ("set Heizungsmodus COMFORT")}}
if ($dtmf == 53){{fhem ("set Heizungsmodus MAX")}}
}
Ist zur Zeit noch etwas einfach gestrickt aber ich kann mit einem Anruf mehrere Geräte schalten. Kann man aber definitiv noch ausbauen.
Ein Fehler ist mir allerdings im dtmf aufgefallen aus irgendeinem Grund funktioniert es nicht wenn ich 2 gleiche Zahlen benutzte z.B. 11 / 22 / usw... hier wird der Wert nicht übernommen.
Außerdem wäre ein Ton welche die übernahme der Werte bestätigt total geil.
Gruß
Patrick
Zitat von: neo_owl am 27 Februar 2017, 20:21:06
Ein Fehler ist mir allerdings im dtmf aufgefallen aus irgendeinem Grund funktioniert es nicht wenn ich 2 gleiche Zahlen benutzte z.B. 11 / 22 / usw... hier wird der Wert nicht übernommen.
Außerdem wäre ein Ton welche die übernahme der Werte bestätigt total geil.
Wär's ein Fehler wär's nicht im Wiki beschrieben;-)
Spaß beiseite. Wenn wir die Tastenentprellung beherrschen gibt's zu Weihnachten auch zweimal die gleiche Ziffer. Aktuell müssen es zwei unterschiedliche sein, damit die zweite eindeutig erkannt wird.
konnte schon jemand erfolgreich das password setzen? ich schaff es nicht.
"set triggerLiveCam password test" ergibt:
SIP user password successfully saved in FhemUtils/uniqueID Key SIP_triggerLiveCam_passwd
fhem.log:
2017.02.28 17:34:50.424 1: PERL WARNING: Use of uninitialized value $password in split at ./FHEM/96_SIP.pm line 810.
2017.02.28 17:34:50.425 1: stacktrace:
2017.02.28 17:34:50.425 1: main::__ANON__ called by ./FHEM/96_SIP.pm (810)
2017.02.28 17:34:50.425 1: main::SIP_storePassword called by ./FHEM/96_SIP.pm (478)
2017.02.28 17:34:50.425 1: main::SIP_Set called by fhem.pl (3296)
2017.02.28 17:34:50.425 1: main::CallFn called by fhem.pl (1649)
2017.02.28 17:34:50.426 1: main::DoSet called by fhem.pl (1681)
2017.02.28 17:34:50.426 1: main::CommandSet called by fhem.pl (1106)
2017.02.28 17:34:50.426 1: main::AnalyzeCommand called by fhem.pl (975)
2017.02.28 17:34:50.426 1: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2346)
2017.02.28 17:34:50.426 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (845)
2017.02.28 17:34:50.426 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (509)
2017.02.28 17:34:50.427 1: main::FW_Read called by fhem.pl (3301)
2017.02.28 17:34:50.427 1: main::CallFn called by fhem.pl (673)
im file steht nur:
SIP_triggerLiveCam_passwd:
-rw-r--r-- 1 fhem dialout 180 Feb 28 17:34 uniqueID
edit:
zeile 478: wenn ich das richtig sehe, wurde bis hier $subcmd noch nicht initialisiert.
return SIP_storePassword($name,$subcmd);
bei mir leider dto.
der Platz im Passwordfile nach SIP_TELEFON_passwd: ist leer
Abhilfe schafft die $subcmd = -... Zeile
...
elsif ($cmd eq "password")
{
$subcmd = (defined($a[2])) ? $a[2] : "";
return SIP_storePassword($name,$subcmd);
}
...
VG plin
ok, password funktioniert nun.
dtmf 4 stellen werden auch sauber erkannt. sehr geil. :)
allerdings muss nach dem ändern von sip_dtmf_size unbedingt ein set reset erfolgen, sonst ist weiterhin die alte einstellung wirksam.
Zitat von: frank am 28 Februar 2017, 17:45:00
zeile 478: wenn ich das richtig sehe, wurde bis hier $subcmd noch nicht initialisiert.
ja , sorry mein Fehler, der Password Teil sollte eigentlich ein Stück tiefer stehen. Habe es eben gefixt und eingecheckt
Zitat von: frank am 28 Februar 2017, 20:51:54
allerdings muss nach dem ändern von sip_dtmf_size unbedingt ein set reset erfolgen, sonst ist weiterhin die alte einstellung wirksam.
ja und das trifft auch noch auf Änderungen an anderen Attributen zu.
Ein bereits laufender Listen Prozess hat keinen Zugriff auf die geänderten Attrbute, dazu muss er gestoppt und neu gestartet werden.
ok, dann fände ich es aber besser, wenn das bei einer solchen Attribut-Änderung automatisch passieren würde. Hat zwar ggf. auch Nebenwirkungen falls gerade eine Erkennung läuft, aber das fände ich nicht tragisch, denn ich will ja aus irgendeiner Absicht heraus ein Attribut ändern.
Zitat von: Wzut am 26 Februar 2017, 17:25:46
Vermutlich nichts , die Frage ist vllt welches FB Modell mit welcher Firmware du benutzt.
Bzw. auf welchem Unterbau läuft das SIP Modul und welche Version von Net::Sip ?
Ich nutze auf meinem Cubietruck unter Debian jessie (8.7) derzeit die V 0.687-1. Meine Fritzbox ist eine 7390 mit der aktuellen 6.80 FW.
Habe eben ein Update von FHEM gemacht und nutze also das Modul:
96_SIP.pm 13552 2017-02-28 21:04:02Z Wzut
Die Probleme waren bis auf den allerersten Versuch (und ich hab mich schon gefreut) allesamt nicht zufriedenstellend. Es werden Tasten erkannt, die ich gar nicht gedrückt habe oder es werden welche ausgelassen (oder übersprungen) und zu guter Letzt wird, obwohl ich (im Beispiel unten) eine Länge von 4 Zeichen eingegeben habe und schon mittendrin 4 Tasten erkannt wurden (dtmf Total: 2129) 5 Zeichen in das Reading geschrieben, weil er danach noch was erkannt hat...
Vorher hatte ich schon mal 2 Zeichen eingestellt, da hat er auch schon 3 ins Reading geschrieben...
2017.03.01 16:57:49.758 5: FB_SIP, SIP_filter : a:"Mobilteil_2" <sip:**612@fritz.box>;tag=37B597BB50E3C75A | b:Net::SIP::Request=HASH(0x1db05b0)
2017.03.01 16:57:56.707 5: FB_SIP : DTMF Event : #
2017.03.01 16:57:57.509 5: FB_SIP : DTMF Event : 2
2017.03.01 16:57:57.509 5: FB_SIP : DTMF Total: 2 , Anz: 2
2017.03.01 16:58:14.913 5: FB_SIP : DTMF Event : #
2017.03.01 16:58:22.157 5: FB_SIP : DTMF Event : 1
2017.03.01 16:58:22.158 5: FB_SIP : DTMF Total: 21 , Anz: 2
2017.03.01 16:58:22.644 5: FB_SIP : DTMF Event : 1
2017.03.01 16:58:23.060 5: FB_SIP : DTMF Event : 1
2017.03.01 16:58:28.588 5: FB_SIP : DTMF Event : 2
2017.03.01 16:58:28.588 5: FB_SIP : DTMF Total: 212 , Anz: 3
2017.03.01 16:58:35.004 2: HMCCU: Received no events from CCU since 300 seconds
2017.03.01 16:58:37.444 5: FB_SIP, listen prozess 4096 found
2017.03.01 16:59:03.117 5: FB_SIP : DTMF Event : 9
2017.03.01 16:59:03.117 5: FB_SIP : DTMF Total: 2129 , Anz: 4
2017.03.01 16:59:03.349 5: FB_SIP : DTMF Event : 9
2017.03.01 16:59:04.189 5: FB_SIP : DTMF Event : 8
2017.03.01 16:59:04.189 5: FB_SIP : DTMF Total: 21298 , Anz: 5
2017.03.01 16:59:04.190 5: FB_SIP, telnet : set FB_SIP dtmf_event 21298
2017.03.01 16:59:37.509 5: FB_SIP, listen prozess 4096 found
2017.03.01 16:59:40.292 5: FB_SIP, SIP_bye : HASH(0x4b46ad0)
2017.03.01 16:59:40.292 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
Hat jemand eine Idee?
Hast du dir mal die CPU-Auslastung deines Cubietruck während des Anrufes angeschaut?
Oha! Laut top geht die Auslastung von fhem auf 100%...das ist doch mal ein Ansatz. Wie kommt das?
Gute Frage. Bei meinem Raspi2 habe ich das gleiche Problem. Vielleicht hat Wzut noch eine Idee. Ansonsten müssen wir's der Net:SIP in die Schuhe schieben.
habt ihr eventuell viele fhem instanzen (forks) parallel am laufen.
Nee, auf meinem Raspi2 läuft nur eine. Die CPU-Auslastung eines Cores geht auf 100% wenn listen_for_dtmf einen Anruf angenommen hat und auf Töne wartet.
Also bei mir laufen insgesamt 5 Instanzen. Habe aber keine richtige Ahnung, warum. Scheint aber normal zu sein... Wenn ein Anruf angenommen wird, geht aber nur eine Instanz davon auf um die 100% oder kurz darüber. Eine weitere läuft so ca. immer mit 3 - 10 %, und die anderen dümpeln so mit < 1 % rum...
root@raspberrypi:/home/pi# cpan -D Net::SIP
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 01 Mar 2017 17:29:03 GMT
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.808.tar.gz
/usr/local/share/perl/5.20.2/Net/SIP.pm
Installed: 0.687
CPAN: 0.808 Not up to date
Steffen Ullrich (SULLR)
Steffen_Ullrich@genua.de
root@raspberrypi:/home/pi# apt-get changelog libnet-sip-perl
Get:1 Changelog for libnet-sip-perl (http://packages.debian.org/changelogs/pool/main/libn/libnet-sip-perl/libnet-sip-perl_0.687-1/changelog) [11.9 kB]
ich habe ja scheinbar die selbe sip version 0.687.
zuerst hatte ich sip aus cpan installiert, kurze zeit später dann mit apt-get das paket libnet-sip installiert, welches nun wohl auch übriggeblieben ist.
da bei mir damit alles perfekt funktioniert, kann es eigentlich nicht an sip liegen, oder?
ständig 5 instanzen ist eher "sportlich" als normal, würde ich sagen.
Zitat von: frank am 01 März 2017, 19:28:44
ständig 5 instanzen ist eher "sportlich" als normal, würde ich sagen.
Die Frage ist ja, warum da 5 Instanzen laufen. Wie bekomme ich das denn raus? Wobei ja, wenn kein Anruf erfolgt, alle Instanzen zusammen mit nicht mehr als 5-10 % CPU laufen. Und das klingt für mich alles andere als "sportlich"... ;)
Egal, da ja aber bei plin nur eine Instanz läuft und er das gleiche Problem hat...
nur 5 ? bei mir sind es ein paar mehr ..... :)
Anyway, das hängt einfach davon ab welche Module man aktiv nutzt und welche Gebrauch von BlockingCall machen.
Mein MPD Modul ist da z.B. so eines oder auch sehr beliebt PRESENCE, aber back to Topic :
@Der Tom , schönes Log so mag ich das. Aber wie bereits geschrieben kann ich Tastenprellen abfangen, aber gegen falsch erkannte Tasten sind wir jetzt fast machtlos.
Fast bedeutdet das plin da noch eine Idee hat für die wir aber mehr Userdaten brauchen, d.h. die nächste Version wird noch etwas mehr loggen und hoffentlich finden wir dann einen Weg die falschen Tasten zu erkennen.
Zitatnur 5 ? bei mir sind es ein paar mehr ..... :)
bei mir ist der listen-prozess der erste permanente fork.
Ich möchte das Thema Text2Speech nochmal aufgreifen. Ich hatte letzte Woche Tobias den Maintainer des Text2Speech Modul angeschrieben mit der Bitte um Anpassungen für die Zusammenarbeit mit SIP :
Wer mal reinschauen möchte :
https://forum.fhem.de/index.php/topic,18481.msg598169.html#msg598169
Ich denke mit ein paar kleinen Ergänzungen am SIP Modul müsste nächste Woche sowas möglich sein :
set mySIP call **611 30 'moin, moin, hier ist dein FHEM. Mach endlich das Klofenster wieder zu'
Zitat von: Wzut am 03 März 2017, 13:14:28
Ich denke mit ein paar kleinen Ergänzungen am SIP Modul müsste nächste Woche sowas möglich sein :
set mySIP call **611 30 'moin, moin, hier ist dein FHEM. Mach endlich das Klofenster wieder zu'
Super. Danke!!!
Ein Supermodul! Danke und ein großes Lob!
Eingerichtet und läuft sofort (OK: nach der Installation der lib-sip-perl und sox und der Einrichtung auf der FritzBox).
Allerdings fiel mir auf, dass der listen_for_dtmf-Modus nicht mehr auf DTMF-Töne wartet, sobald ein Audiofile als Attribut hinterlegt wurde.
Im WPF-Modus wird die eingestellte waittime gewartet, dann das File abgespielt und aufgelegt. Sehr schön!
Im DTMF-Modus wird allerdings ebenfalls - und zwar sofort - das File abgespielt und aufgelegt. Keine Chance, da noch Tonwahltöne abzusetzen... Weniger schön!
Es werden auch während des Audiofile-Abspielens zwar Wahltöne erkannt, aber leider nicht korrekt...
Ein Löschen des Attributs "sip_audiofile" löst das Problem, aber das ist ja nicht Sinn der Sache. Man will ja eher einfach zwischen den beiden Modi hin- und herschalten (mit anschließendem reset halt noch) und nicht jedesmal auch noch das sip_audiofile-Attribut löschen oder neu einpflegen.
Sind wahrscheinlich nur wenige Stellen im Code zu korrigieren - und wäre mir wichtiger als 'Moin, moin, hier ist Dein FHEM...'
Hallo, habe mir gerade mal das Modul zum testen eingerichtet. Leider bekomme ich bei einem set call:
ZitatCallRegister: Failed with code 404
Password ist gesetzt, ein list von mySIP
Internals:
CFGFN
NAME mySIP
NR 10087
STATE initialized
TYPE SIP
VERSION V1.31 / 28.02.17
Readings:
2017-03-03 19:21:32 call done
2017-03-03 19:21:32 call_state fail
2017-03-03 19:21:32 last_error CallRegister: Failed with code 404
2017-03-03 18:57:06 state initialized
Helper:
Attributes:
room Telefon
sip_dtmf_size 2
sip_from sip:622@fritz.box
sip_ip 192.168.2.66
sip_listen none
sip_port 5060
sip_registrar 192.168.2.1
sip_ringtime 4
sip_user 622
In der Fritzbox:
Zitatfhem LAN/WLAN xxxxxxx xxxxxxx **622
fhem ist hierbei der Name des Telefoniegerätes
VG
Frank
hm , den Fehler 401 kenne ich wenn User und Passwort nicht zusammen passen.
laut Net:Sip::Request.pm 404 => 'Not Found' , 401 => 'Unauthorized'
Gute Frage was wurde bei dir nicht gefunden 192.168.2.1 ist die IP deiner FB ?
Ja, die 192.168.2.1 ist die Fritte habe es schon mit sip_registrar fritz.box und mit der IP versucht.
Probier mal sip_port 5070
Nö, da will das device auch nicht :(
Das Password für den user fhem in der Fritzbox enspricht dem Password welches in dem SIP device in fhem hinterlegt ist. Der Name des Telefoniegerätes in der Fritte lautet fhem und die interne Nummer steht auf **622, Anschluss steht auf LAN/WLAN.
Mmh...
dem Screenshot nach hast du ja bereits zwei SIP Phones am laufen (620 & 621)
Da ich davon ausgehe das du mit diesen beiden schon Erfolg hattest nimm doch mal einen dieser beiden User und dessen Passwort oder
umgekehrt wenn du einem deiner Apple Geräte die 623 gibst kann es dann telefonieren ?
Die andere Frage ist: kann das Device sich beim listen an der Fritzbox anmelden?
Zitatdem Screenshot nach hast du ja bereits zwei SIP Phones am laufen (620 & 621)
Die beiden SIP devices bekommen das PW von der Fritte, siehe Screenshot
ZitatDie andere Frage ist: kann das Device sich beim listen an der Fritzbox anmelden?
Nein, bekomme ich auch einen ERRORDas scheint zu funktionieren, nur leider klingelt bei einem Anruf jetzt kein Telefon mehr?
VG
Frank
Habe das SIP device erst mal wieder gelöscht da bei Anrufen keins der DECT Telefone mehr geklingelt hat, der callmonitor in fhem zeigte die Anrufe jedoch an. Die Fritzbox musste ich kurz vom Netz nehmen um wieder bei anrufen ein klingeln zu höhren
;)
VG
Frank
Zitat von: franky08 am 03 März 2017, 21:28:43
Das scheint zu funktionieren, nur leider klingelt bei einem Anruf jetzt kein Telefon mehr?
Vermutlich weil der SIP-Client den anderen den Anruf sofort wegschnappt. User und Passwort scheinen also zu passen.
@Wzut: sitze auf der Couch und kann nicht ins Coding reinschauen ...
Joh, teste ich später noch mal aber mit sip_listen none, brauchte die SIP Funktion in fhem eigentlich nur für einen Call beim auslösen der Alarmanlage, da man ein klingeln ehr wahrnimmt als eine SMS oder Push-Nachricht.
VG
Frank
Ach, man kann´s ja nicht lassen ;) Habe eben noch einmal ein SIP device eingerichtet aber mit sip_listen none. Wenn ich nun versuche mit set call... einen Anruf zu machen, bleibt call_state bei invite.
VG
Frank
Jetzt mal im Log gesucht:
<h1>Software error:</h1>
<pre>Can't use string ("Telefonnummer") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
</p>
[Fri Mar 3 22:28:09 2017] fhem.pl: Can't use string ("Telefonnummer") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
<h1>Software error:</h1>
<pre>Can't use string ("Telefonnummer") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error
"Telefonnummer" ist natürlich die Nummer die ich anrufen wollte ;)
Hat dein Anruf die Syntax
set mysip call 10 Telefonnummer soundfile
?
Handelt es sich um eine interne oder externe Nummer?
Kannst du interne Nummern anrufen?
Hab es nur mit set mySIP call <Nummer> probiert, sip_ringtime steht in den Attributen auf 5 und sollte somit verwendet werden, ist eine externe Nummer (mein Handy), interne hab ich noch nicht getestet.
VG
Frank
mmmh, bei mir steht in
/usr/share/perl5/Net/SIP/Simple.pm line 379
ein "else"-Statement.
Welche Net::SIP-Version hast du (cpan -D Net::SIP)? Meine ist die 0.808
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.808.tar.gz
/usr/lib/perl5/site_perl/5.18.2/Net/SIP.pm
Installed: 0.808
CPAN: 0.808 up to date
Steffen Ullrich (SULLR)
Steffen_Ullrich@genua.de
Zitat von: franky08 am 03 März 2017, 22:56:47
Can't use string ("Telefonnummer") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
und aus deiner Sig :
ZitatDebian Wheezy
ergibt eine alte Version von Net::Sip , bitte mal meine Antwort #60 , Seite 5 erster Beitrag hier im Thread lesen
Ja, hatte mit apt-get installiert, nicht über cpan. cpan hab ich auf meinem System nicht installiert.
es geht auch ohne intstalliertes cpan, hole dir direkt hier http://search.cpan.org/~sullr/Net-SIP-0.808/ mit dem Download Link http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/Net-SIP-0.808.tar.gz die aktuelle Version. Auf der cpan Seite ist auch ein Link INSTALL , der Inhalt :
This module can be installed on perl5.8 if you add Net::DNS.
It was not tested on older versions but it might work if you add
Storable, List::Util, Hash::Util, Time::HiRes, Digest::MD5
and IO::Socket.
The module itself is pure perl, so if the prerequisites are
fullfilled no C-Compiler is necessary.
For installation do the usual
perl Makefile.PL
make
make test
make install
Zitat von: Wzut am 04 März 2017, 13:27:36
es geht auch ohne intstalliertes cpan, hole dir direkt hier http://search.cpan.org/~sullr/Net-SIP-0.808/ mit dem Download Link http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/Net-SIP-0.808.tar.gz die aktuelle Version. Auf der cpan Seite ist auch ein Link INSTALL , der Inhalt :
...
Super, ich hatte das gleiche Problem. Habe mich den ganzen Abend rumgeärgert und nun hat es geklappt. Ich war eigentlich der Meinung, dass sudo cpanm install Net::SIP aus dem Wiki bei mir problemlos durchlief, naja. Bin auch auf Wheezy unterwegs.
Eine kurze Frage noch: Gibt es eine Möglichkeit, dem DECT Telefon auf dem Bildschirm eine Nachricht mitzugeben? Benötige den Anruf als Alarm und es wäre cool, wenn man ihm wenigstens ein Wort mitgeben könnte.
Zitates geht auch ohne intstalliertes cpan
Joh, der Tipp war Gold wert...
Hallo floflo
Für eine Fritzbox mit dem Fon MT-F ist es im WIKI beschrieben.
https://wiki.fhem.de/wiki/FRITZFON (https://wiki.fhem.de/wiki/FRITZFON)
Da kann man dann zu bestimmten Terminen das Bild ändern - läuft bei mir als Abfallbenachrichtigung wenn die Tonne raus muss.
Gruß
Gigafix
Habe eben mal die Version von Net::SIP auf die aktuelle V 0.808 angehoben. Hat aber nichts gebracht. Ein fhem-Prozess geht nach einem Anruf immernoch auf 100% und blockiert die Tastenerkennung. Wenn ich es schaffe, die DTMF-Töne sehr schnell abzusetzen, kommen diese an, werden aber doppelt oder mehrfach interpretiert:
2017.03.05 11:13:25.088 5: FB_SIP, SIP_filter : a:"Mobilteil_2" <sip:**612@fritz.box>;tag=B0A966B994E3B151 | b:Net::SIP::Request=HASH(0x5436640)
2017.03.05 11:13:26.922 5: FB_SIP : DTMF Event : #
2017.03.05 11:13:27.521 5: FB_SIP : DTMF Event : 7
2017.03.05 11:13:27.521 5: FB_SIP : DTMF Total: 7 , Anz: 2
2017.03.05 11:13:27.771 5: FB_SIP : DTMF Event : 8
2017.03.05 11:13:27.771 5: FB_SIP : DTMF Total: 78 , Anz: 3
2017.03.05 11:13:27.994 5: FB_SIP : DTMF Event : 8
2017.03.05 11:13:28.390 5: FB_SIP : DTMF Event : 7
2017.03.05 11:13:28.391 5: FB_SIP : DTMF Total: 787 , Anz: 4
2017.03.05 11:13:28.716 5: FB_SIP : DTMF Event : 8
2017.03.05 11:13:28.716 5: FB_SIP : DTMF Total: 7878 , Anz: 5
2017.03.05 11:13:28.717 5: FB_SIP, telnet : set FB_SIP dtmf_event 7878
2017.03.05 11:13:30.342 5: FB_SIP, SIP_bye : HASH(0x559a940)
2017.03.05 11:13:30.343 5: FB_SIP, telnet : set FB_SIP caller none
set FB_SIP caller_state hangup
exit
In diesem Beispiel habe ich nur folgendes gedrückt:
#78
mehr nicht...
Ich habe da auch noch ein Problemchen. Nachdem das Modul nun funktioniert, habe ich mit
Zitatsox <file>.wav -t raw -r 8000 -c 1 -e a-law <file>.alaw
ein Audiofile im raw Format angelegt und unter /opt/<File> angelegt. Benutzer/Gruppe auf fhem:dialout angepast. Wenn ich jetzt mit:
set mySIP call <Nummer> 10 /opt/alarm1.alaw
einen Anruf starte, dann klingelt das angerufene Handy leider nur zwei mal (obwohl 10 eingestellt sind) und vom Audiofile werden nur ca. die ersten zwei,drei Sekunden abgespielt und das SIP Modul legt auf.
ein list:
Internals:
NAME mySIP
NR 2228
STATE initialized
TYPE SIP
VERSION V1.31 / 28.02.17
Readings:
2017-03-05 11:53:40 call done
2017-03-05 11:53:40 call_state unknown
2017-03-04 23:58:36 state initialized
Helper:
Attributes:
disabled 0
room Telefon
sip_audiofile /opt/alarm1.alaw
sip_dtmf_size 2
sip_from sip:622@fritz.box
sip_ip 192.168.2.66
sip_listen none
sip_port 5070
sip_registrar 192.168.2.1
sip_ringtime 10
sip_user 622
VG
Frank
Zitat von: franky08 am 05 März 2017, 12:01:11
dann klingelt das angerufene Handy leider nur zwei mal (obwohl 10 eingestellt sind) und vom Audiofile werden nur ca. die ersten zwei,drei Sekunden abgespielt und das SIP Modul legt auf.
Denkfehler , die ringtime von 10 ist in Wahrheit die max Gesamtdauer des kompletten Vorgangs. Ist diese Zeit erreicht bricht das Modul ab, egal ob sich niemand meldet oder das File schon am abspielen ist !
Setze entweder ringtime gleich auf 30 oder gib es als Wert beim set call mit an.
In der nächsten Version des Moduls wird ringtime bei ausgehenden Anrufen gar nicht mehr verwendet !
Alles klar, dachte es bezieht sich nur auf das klingeln. :)
VG
Frank
Zitat von: floflo am 04 März 2017, 23:01:19
Eine kurze Frage noch: Gibt es eine Möglichkeit, dem DECT Telefon auf dem Bildschirm eine Nachricht mitzugeben? Benötige den Anruf als Alarm und es wäre cool, wenn man ihm wenigstens ein Wort mitgeben könnte.
https://forum.fhem.de/index.php/topic,40219.msg580884.html#msg580884 (https://forum.fhem.de/index.php/topic,40219.msg580884.html#msg580884)
Ich hatte am WE etwas Zeit um weiter am SIP Modul zu schrauben, aktuell habe ich jetzt Text2Speech erfolgreich eingebunden. Ich möchte die Version allerdings noch nicht einchecken da plin z.Z. noch an einer anderen Baustelle arbeitet und ich gerne beides zusammen veröffentlichen würde.
Aber jetzt ist für Euch ein guter Zeitpunkt in das Thema Text2Speech schon mal einzusteigen.
- neue Version von Text2Speech via update installieren oder von hier holen -> https://forum.fhem.de/index.php/topic,18481.msg598169.html#msg598169
- SoX installieren ( sudo apt-get install sox )
- mp3 Ünterstützung für SoX installieren ( sudo apt-get install libsox-fmt-mp3 )
- T2S als Server Device an legen : define<name> text2speech none
- zum testen mal irgendeinen Satz in audio wandeln lassen : set <name> tts Das ist der erste Test
- sich den Inhalt des Readings lastFilename anschauen
- auf der Shell in das cache dir wechseln ( /opt/fhem/cache )
- mit sox die eben erzeugte Datei von .mp3 nach .alaw wandeln und ggf. gleich umbenennen :
sox file_aus_dem_lastFilename_Reading.mp3 -t raw -r 8000 -c 1 -e a-law DideT.alaw
Nun den ersten Anruf machen und dabei das neue File abspielen : set mySIP call Nummer 30 cache/DideT.alaw
Auf die Art und Weise könnt ihr euch schon jetzt einen Vorrat an Audio Text Dateien anlegen und nutzen
Mit der neuen Version wird es dann etwas einfacher, da der Text dann direkt dem set call übergeben werden kann,
allerdings auch nur wenn T2S und SoX bereits installiert sind.
Wow ich bin begeistert.
Super Arbeit.
Eine Frage oder Anregung habe ich noch.
Wenn ich einen eingehenden Anruf mit fetch annehme, kann ich dann auch eine Audio Datei oder einen Text fürs T2S übergeben?
Gruß
Max
Zitat von: MadMax am 07 März 2017, 19:23:39
Wenn ich einen eingehenden Anruf mit fetch annehme, kann ich dann auch eine Audio Datei oder einen Text fürs T2S übergeben?
im ersten Fall befragen wir mal das Wiki und da steht :
Zitat von: Wiki link=https://wiki.fhem.de/wiki/SIP-ClientAttribute
sip_audiofile
Audiofile das nach dem Command fetch abgespielt wird.
also ein klares JA
der zweite Fall eigene Texte dort auszugeben ist z.Z. noch nicht umgesetzt und hatte ich bisher auch nicht auf dem Radar.
Hallo,
Das man ein vordefinierte Abspielen kann hab ich gesehen.
Ich meinte auch das ich beim fetch eins mit hinten anhängen kann.
Aber das ist sicher saß selbe wie mit dem Text.
Nur so als Anregung, währe ne super Funktion wenn das gehen würde.
Gruß
Max
Ich bin gerade am Installieren des Moduls. Es sieht soweit recht gut aus, jedoch erhalte ich folgende Fehlermeldung:
2017.03.10 21:22:20 4: FritzSIP, CallStart DTMF : ABCD*#123--4567890
Can't use string ("07000000") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Dir Rufnummer habe ich hier verändert.
Hat jemand eine Idee, was hier falsch läuft?
Viele Grüße
Rainer
na klar , Seite 5 erster Beitrag #60 -> https://forum.fhem.de/index.php/topic,67443.msg593547.html#msg593547
= alte Net::Sip Version
@Wzut
Danke für die Info. Da darf man mal wieder nichts glauben "libnet-sip-perl is already the newest version." >:(
ZitatDie Datei Net-SIP-0.687.tar.gz herunterladen
Beim Suchen habe ich die "Net-SIP-0.807.tar.gz" gefunden. Soll ich nun explizit die 0.6 installieren oder die neue 0.8...?
Viele Grüße
Rainer
die 0.808 solle OK sein , siehe Seite 8 # 119 -> https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836
@Wzut,
Danke fürs Vorlesen des Rundmails ;D. Ich hatte es zwar gelesen, jedoch nicht verstanden ;) -> Frei nach unserem Bundestrainer "Hennr s Rundmail gläsa? ähä... Hennrs au verstanda? HÄHA" ;D
Ja, jetzt funzt es super.
Viele Grüße
Rainer
Hallo,
beim aufrufen von Fhem bekomme ich immer folgende Meldung:
Messages collected while initializing FHEM:
./log/fhem.save: Please define SIP_Tel first
Please define SIP_Tel first
Please define SIP_Tel first
Ich habe folgendes in meiner Konfiguration stehen:
define SIP_Tel SIP
attr SIP_Tel sip_audiofile none
attr SIP_Tel sip_dtmf_size 2
attr SIP_Tel sip_from sip:74@192.168.1.10
attr SIP_Tel sip_ip 192.168.1.34
attr SIP_Tel sip_listen wfp
attr SIP_Tel sip_port 5060
attr SIP_Tel sip_registrar 192.168.1.10
attr SIP_Tel sip_ringtime 10
attr SIP_Tel sip_user 74
attr SIP_Tel sip_waittime 10
sonst funktioniert das Modul
@Medel: Tritt die Meldung nach einem save config und shutdown restart immer noch auf?
Hallo,
hatte schon mehrfach einen Neustart versucht und auch die Konfiguration gespeichert. Allerdings vielleicht nicht kurz nacheinander.
Habe es jetzt mit save config und shutdown restart versucht und es ist seit her nicht mehr aufgetreten.
Zitat von: Medel am 12 März 2017, 10:32:35
attr SIP_Tel sip_audiofile none
Das Attribut sip_audiofile kannst du löschen da none keinen Sinn ergibt bzw. eh es kein gültiges alaw audio File ist.
Die neue Version 1.4 ist fertig , da wir z.Z. aber stark mit der command.ref und dem Wiki zurückhängen und sich intern einiges geändert hat checke ich sie noch nicht sofort ein, sonderm hänge sie hier an zum Betatesten und wir bitten im Feedback :)
Was ist neu ?
1. Direkte Unterstützung für Text2Speech
Vorbereitung :
a. SoX installieren ( sudo apt-get install sox )
b. mp3 Ünterstützung für SoX installieren ( sudo apt-get install libsox-fmt-mp3 )
c. Text2Speech als Server Device anlegen -> define <name z.B myT2S> text2speech none
d. beim SIP Device dieses Server Device im Attribut T2S_Device eintragen
erster Test :
set <name> call <rufnummer> <maximale Dauer> !Das ist ein Test
Das Telefon <rufnummer> sollte klingeln und nach dem abheben der Text zu höhren sein
Zur Unterscheidung von Dateien und DTMF Signalen muss der auszugebende Text immer mit einem ! beginnen.
Alternativ kann der Text auch im neuen Attribut sip_audiofile_call hinterlegt werden ( mit Ausrufezeichen )
dann geht es auch über die kurze Version "set <name> call <rufnummer>"
2. Änderungen bei listen_for_dtmf
a. das Attribut sip_ringtime legt nun fest wie lange das Modul warten soll bis es den Anruf annimmt.
Defaultwert ist 2 , das entspricht bei mir in etwa 1x Klingeln.
b. attr sip_audiofile_dtmf -> Dieses File wird abgespielt wenn das Modul den Anruf annimmt.
Ist kein File angegeben hört man ein (nicht sehr schönes) Geräusch.
c. attr sip_dtmf_loop legt fest ob nur einmal ein DTMF Code eingeben werden soll
( default once ), das Modul beendet in diesem Fall den Anruf und legt auf oder
ob ihr mehrfach Codes schicken wollt. D.h ihr müsst selbst irgendwann auflegen (loop).
d. attr sip_audiofile_ok , dieses File wird abgespielt wenn ein DTMF Code (1-4 Tasten) erkannt wurde
3. Änderungen bei listen_wfp
a. attr sip_ringtime -> wie bei listen_for_dtmf
b. attr sip_audiofile_wfp -> entspricht dem bisherigen sip_audiofile
4. Das Attribut sip_audiofile gibt es nicht mehr, an seiner Stelle stehen nun die vier sip_audiofile Attribute.
Achtung : bei den drei Audiofiles für listen darf noch kein Text2Speech Text eingetragen werden !
Dies ist bis jetzt nur für das Attribut sip_audiofile_call zulässig.
5. Bei set call wird das attribut sip_ringtime nicht mehr verwendet. Wird keine maximale Zeit angegeben so wird
der Default Wert von 30 Sekunden verwendet.
EDIT : als V1.41 ab morgen früh via update verfügbar
Habs mal schnell mit sip call getestet und funzt perfekt!
Handynummer wird angerufen und Text wird ohne verzögerung gesprochen!
Na ist ja verdächtig ruhig hier .... :)
Update :
Die Version die ab morgen verfügbar ist unterstützt direkte Text2Speech Texte in allen vier sip_audofile Attributen.
Hallo Wzut,
ja, gerade beim Brötchenverdienen ;-).
Morgen Abend wird getestet.
Viele Grüße
Rainer
Zitat von: Wzut am 15 März 2017, 20:18:03
Na ist ja verdächtig ruhig hier .... :)
Update :
Die Version die ab morgen verfügbar ist unterstützt direkte Text2Speech Texte in allen vier sip_audofile Attributen.
Na ja, was soll es hier auch an Kritik geben, wo das so gut funktioniert? Außerdem sind die Erwartungen verschieden. Meine Tore gehen bei Anruf perfekt auf, der Handyanruf welcher das auslöst wird vom SIP Modul angenommen und automatisch beendet. Heute hörte ich zum ersten Mal den Piepton, den ich als Antwort Sound konvertiert hatte. Sobald das geht würde ich da eine freundliche Begrüßung abhängig von Frau oder mir selbst und Tageszeit hören wollen. Damit wären meine Erwartungen an das Modul voll erfüllt. Vielen Dank für Deine hervorragende Entwicklungsarbeit.
Zitat von: det. am 15 März 2017, 21:04:01
würde ich da eine freundliche Begrüßung abhängig von Frau oder mir selbst und Tageszeit hören wollen.
zumindest die Begrüßung kannst du relativ einfach mit der Text2Speech Unterstützung umsetzen, wenn du das allerdings noch vom Anrufer und sogar der Tageszeit abhängig machen möchtest wirst du z.Z. um ein selbst gebasteltes notify (oder DOIF) nicht herumkommen.
Zitat von: det. am 15 März 2017, 21:04:01
Vielen Dank für Deine hervorragende Entwicklungsarbeit.
Ahh , das sind doch genau die Worte die man hier in der Regel nicht so oft liest. Ich sag mal artig Danke , wobei ich mir den Schuh nur teilweise anziehe,
denn wenn plin nicht die eine oder andere Nuß geknackt hätte oder Tobias so schnell sein T2S Modul angepasst hätte sähe das hier noch ganz anderes aus :)
@det. , dein Wunsch nach Rufnummer Filter ist nicht vergessen
Hallo Wzut,
vielen Dank für dich und deine Unterstützer für dieses Modul.
Meine Rückmeldungen:
Ich hab den Punkt Nr. 1 Direkte Unterstützung für Text2Speech getestet; funktioniert problemlos.
Es fehlte noch das Attribut audio_converter, das ich auf sox gesetzt habe. Ist das richtig so? Zumindest damit hat es funktioniert.
Die Punkte 2. bis 4. hab ich nicht getestet, da ich noch keine Anwendung dafür habe.
Der Punkt 5. attribut sip_ringtime verstehe ich nicht.
Heißt das, dass dieses Attribut im Grunde genommen überflüssig ist?
Es ist entweder ohne Angabe per default 30 sec. oder es erfolgt eine Angabe mit einem davon verschiedenen Wert bei set call?
Viele Grüße Gisbert
Zitat von: Gisbert am 16 März 2017, 09:35:38
Es fehlte noch das Attribut audio_converter, das ich auf sox gesetzt habe. Ist das richtig so? Zumindest damit hat es funktioniert.
--- snipp ---
Der Punkt 5. attribut sip_ringtime verstehe ich nicht.
wenn du sox installiert hast ist sox auch richtig (wird bei der Mehrzahl der User zutreffen) nur wer unbedingt ffmpeg zur Konvertierung von mp3 nach a-law nutzen will oder muß der sollte auf ffmpeg umstellen.
sip_ringtime ist z.Z. einzig und allein bei der Betriebsart listen_for_dtmf wichtig (die du ja aber gar nicht nutzt)
Bei ausgehenden Anrufen via set <name> call ist die maximale Zeit anzugeben (default 30 Sekunden) , da sonst ja das andere Telefon quasi unendlich lange klingeln würde.
Zitat von: Wzut am 15 März 2017, 20:18:03
Na ist ja verdächtig ruhig hier .... :)
Wir können ja noch ein "random"-Attribut einführen das dazu führt, dass die Wörter des angegebenen Textes in zufälliger Reihenfolge vorliest. Was meinst du wieviel Feedback dann hier erscheint :-)
Hallo,
habe jetzt Net::SIP mit cpan neu installiert und bekomme auf 2 RPi mit aktuellem wheezy folgende Fehlermeldung:
[Thu Mar 16 21:06:45 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.
Der Aufruf erfolgt mit: set FritzSip call **611 30 cache/DideT.alaw
Wenn ich den Ruf annehme erhalte ich nur eine Abfolge von Tönen, als wenn noch gewählt würde.
Grüße Jörg
PS: Hier noch das List
Internals:
AC /usr/bin/sox
CFGFN
NAME FritzSip
NOTIFYDEV myT2S
NR 125
NTFY_ORDER 50-FritzSip
STATE initialized
TYPE SIP
VERSION V1.42 / 15.03.17
Readings:
2017-03-16 21:06:50 call done
2017-03-16 21:06:50 call_state unknown peer hangup
address
2017-03-16 21:06:50 state initialized
Helper:
Attributes:
T2S_Device myT2S
T2S_Timeout 30
audio_converter sox
room Telefon
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_from sip:626@fritz.box
sip_ip xxx.xxx.x.xx
sip_listen none
sip_port 5090
sip_registrar fritz.box
sip_ringtime 10
sip_user 626
verbose 5
Die Abfolge von Tönen die du hörst ist ein Fallback damit man überhaupt etwas hört, da ist schon ok.
Nicht ok ist allerdings warum das Modul dir die Datei nicht vorspielt. Du hast verbose auf 5 stehen, d.h. in deinem Log File sollte eigentlich jeder einzelne Schritt nachvollziehbar sein. Poste doch bitte mal das Stück vom Beginn des Calls bis zum Ende.
Welche Version des Sip::Net Paketes hast du installiert ?
In meiner Version ist in Zeile 115 des Eventloop.pm kein größer/kleiner Vergleich, aber in der Ecke wird bei mir gewartet ob die Maximal Zeit abgelaufen ist.
Danach musste die Eventloop Zeile bei dir auch auftauchen wenn du ganz ohne Parameter einen Call absetzt :
set FritzSip call **611
wichtig ist allerdings das du nach wie vor das attr Sip_audiofile_call nicht setzt.
Edit : was mich noch intressiert ist wo kommt der Teil "30M-BM- " her ?
Edit 2 : Ich denke ich habe deinen Fehler :
2017.03.17 08:07:12 1: PERL WARNING: Argument "test.alaw" isn't numeric in numeric lt (<) at /usr/lib/perl5/Net/SIP/Dispatcher/Eventloop.pm line 79.
passiert wenn die Max Zeit weggelassen wird und an deren Stelle das Audiofile steht
Zitat von: det. am 15 März 2017, 21:04:01
Na ja, was soll es hier auch an Kritik geben, wo das so gut funktioniert?
Nun ja...
Zitat von: Wzut am 17 März 2017, 07:46:26
Welche Version des Sip::Net Paketes hast du installiert ?
In meiner Version ist in Zeile 115 des Eventloop.pm kein größer/kleiner Vergleich, aber in der Ecke wird bei mir gewartet ob die Maximal Zeit abgelaufen ist.
Danach musste die Eventloop Zeile bei dir auch auftauchen wenn du ganz ohne Parameter einen Call absetzt :
set FritzSip call **611
wichtig ist allerdings das du nach wie vor das attr Sip_audiofile_call nicht setzt.
Edit : was mich noch intressiert ist wo kommt der Teil "30M-BM- " her ?
Edit 2 : Ich denke ich habe deinen Fehler :
2017.03.17 08:07:12 1: PERL WARNING: Argument "test.alaw" isn't numeric in numeric lt (<) at /usr/lib/perl5/Net/SIP/Dispatcher/Eventloop.pm line 79.
passiert wenn die Max Zeit weggelassen wird und an deren Stelle das Audiofile steht
Log mit verbose 5
2017.03.17 09:25:17 4: FritzSip, CALLDone -> FritzSip|1|unknown peer hangup
2017.03.17 09:25:17 5: FritzSip, Hangup : HASH(0x2dac0a0)
2017.03.17 09:25:17 5: FritzSip, RTP done : 0
[Fri Mar 17 09:25:12 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.
2017.03.17 09:25:12 4: FritzSip, calling : **610
exit
2017.03.17 09:25:12 5: FritzSip, telnet : set FritzSip call_state calling **610
2017.03.17 09:25:12 4: FritzSip, CallStart DTMF : ABCD*#123--4567890
exit
2017.03.17 09:25:12 5: FritzSip, telnet : set FritzSip state calling
2017.03.17 09:25:12 4: FritzSip, register new expire : Fri Mar 17 09:30:12 2017
2017.03.17 09:25:09 5: FritzSip, call has pid 18570
2017.03.17 09:25:09 4: FritzSip, calling **610, ringtime: 30 cache/DideT.alaw , no message
2017.03.17 09:23:32 4: FritzSip, CALLDone -> FritzSip|1|unknown peer hangup
2017.03.17 09:23:32 5: FritzSip, Hangup : HASH(0x2d967b0)
2017.03.17 09:23:32 5: FritzSip, RTP done : 0
[Fri Mar 17 09:23:26 2017] fhem.pl: Argument "30M-BM- cache/DideT.alaw" isn't numeric in numeric lt (<) at /usr/local/share/perl/5.14.2/Net/SIP/Dispatcher/Eventloop.pm line 115.
2017.03.17 09:23:26 4: FritzSip, calling : **610
exit
2017.03.17 09:23:26 5: FritzSip, telnet : set FritzSip call_state calling **610
2017.03.17 09:23:26 4: FritzSip, CallStart DTMF : ABCD*#123--4567890
exit
2017.03.17 09:23:26 5: FritzSip, telnet : set FritzSip state calling
2017.03.17 09:23:26 4: FritzSip, register new expire : Fri Mar 17 09:28:26 2017
2017.03.17 09:23:23 5: FritzSip, call has pid 18501
2017.03.17 09:23:23 4: FritzSip, calling **610, ringtime: 30 cache/DideT.alaw , no message
Installiert ist: Net-SIP-0.807
ich habe mal folgendes Log in die sub SIP_Set($@) eingebaut:
if ($cmd eq "call")
{
Log3 $name, 4, $name.", params from set: a[2] = $a[2], a[3] = $a[3], a[4] = $a[4]";
und bekomme:
2017.03.17 09:56:54 4: FritzSip, params from set: a[2] = **610, a[3] = 30 cache/DideT.alaw, a[4] =
Und was ist die Lösung: Ein Leerzeichen im: set FritzSip call **610 30 cache/DideT.alaw war kein Leerzeichen sondern ein hex a0 zwischen 30 und cache/DideT.alaw.
Und bitte nicht frage wie das dahin gekommen ist >:(
Grüße Jörg
Und da soll man drauf kommen....
Zitat von: JoWiemann am 17 März 2017, 10:06:42
Und da soll man drauf kommen....
:)
find ich aber gut das dir das passiert ist, das hat gezeigt das in der nächsten Version unbedingt eine Überprüfung auf nummerisch mit rein muß, ala :
return "invalid max time : $ringtime" unless $ringtime =~ m/^\d+$/;
Hallo,
ich habe noch einen Fehler in Text2Speech gefunden. Auf einem meiner RPi läuft Fhem aus historischen Gründen unter /usr/share/fhem. Ich hatte zunächst vergessen TTS_CacheFileDir zu setzen. Als folge läuft Text2Speech auf einen Fehler in der sub Text2Speech_DoIt($) bei:
unless(-e $TTS_CacheFileDir or mkdir $TTS_CacheFileDir) {
#Verzeichnis anlegen gescheitert
Log3 $hash->{NAME}, 2, "Text2Speech: Angegebenes Verzeichnis $TTS_CacheFileDir konnte erstmalig nicht angelegt werden.";
return undef;
}
Dadurch wird $hash->{helper}{RUNNING_PID} nicht gelöscht und Text2Speech funktioniert erst wieder, wenn Fhem neu gestartet wird.
Grüße Jörg
@Jörg, poste das bitte unter https://forum.fhem.de/index.php/topic,18481.0.html
da es ein reines T2S Problem ist und ich nicht sicher bin ob Tobias hier überhaupt mitliest.
Danke für den Hinweis und erledigt.
Grüße Jörg
Zitat von: DerTom am 17 März 2017, 09:12:39
Nun ja...
Ist mir schon klar das du unzufrieden bist weil bei dir die DTMF Erkennung nicht so läuft wie gewünscht.
Da du auch geschrieben hast das bei dir 5 FHEM Prozesse laufen und du dir im Unklaren bist warum, versuche doch bitte mal folgendes und in dieser Reihenfolge :
1. ändere das Attribut sip_listen auf none und speichere mit fhem save.
2. starte dein System komplett neu ( also nicht nur fhem)
3. Wieviele Prozesse laufen nun ?
4a. ändere das Attribut verbose auf 5 , falls es kleiner ist
4b. ändere das Attribut sip_listen von none auf dtmf
5. wenn du eine aktuelle Version des SIP Moduls hast sollte nun sofort der Listen Prozess starten
( Internals checken nach LPID , logfile ) wenn nein mit set <name> listen von Hand starten.
6. läuft nun ein Prozess mehr als unter Punkt 3. ?
7. jetzt wechsele auf deine Fritzbox und lege dort einen weiteren SIP User komplett an
8. richte ein weiteres SIP Device unter fhem ein ( define testSIP SIP )
passe die Attribute des neuen Device an (sip_listen auf none oder leer und sip_dtmf_send auf audio) und setze das Passwort.
9. du solltest jetzt in der Lage sein mit diesem testSIP den ersten Client anzurufen :
set testSIP call Nummer-des-listen-Device
10. wenn der Anruf beendet ist ändere das Attribut sip_dtmf_send von audio auf rfc2833
11. rufe wieder die Nr1. an via set testSIP call Nummer-des-listen-Device
12. poste den kompletten Log Abschnit von Schritt 9 bis 11
@DerTom und @Wzut:
Ich darf noch mal an die Hardware erinnern: "Cubietruck unter Debian jessie (8.7)".
Bei mir läuft listen_for_dtmf weder auf dem BananaPi noch auf dem Raspi2. Der Cubietruck ist leistungsfähiger, hat aber auch einen ARM-Prozessor. Meine FHEM-Instanz für IP-basierte Aktivitäten läuft auf einem Intel-Server. listen_for_dtmf erzeugt dort ca. 10% CPU-Auslastung eines Cores, während auf meinem Raspi2 ein Core binnen 1-2 Sekunden auf 100% hochgeht und dann bis zum Auflegen da hängen bleibt.
Ich stelle mir die Frage, ob die DTMF-Erkennung der Net::SIP ein Problem mit der Prozessorarchitektur ARM hat.
Hat jemand einen Raspi3 auf man mal testen könnte?
ja ja , ich wollte das ja auch mal testen.
Normal läuft bei mir FHEM als auch die ganzen Tests auf einem Intel Board. Wenn der Prozess in die DTMF Erkennung geht steigt die Last,
zwar nicht auf 100% aber doch deutlich. Jetzt habe ich mal einen sehr alten RasPi aus der Bastelkiste geholt , Single Core mit 512 MB
OS : Jessie via NAS. Da das gesammte Filesystem auf dem NAS liegt ist er zwar kein Rennpferd aber meine DoorPi Testinstallation inkluse FHEM läuft eigentlich recht ordenlich.
Test :
- Doorpi Prozess gestoppt (linphone)
- dem FHEM Prozess sein SIP Device spendiert und listen_for_dtmf angeworfen und siehe da ...
Ich höre nicht mal das Zirpgeräusch wenn der Client abnimmt :(
Es wird keine einzige Taste erkannt !
Lege ich am Telefon auf erfolgt auch keinerlei Log Eintrag zum Thema bye
Fazit : So ist ist das Ding für listen_for_dtmf auf keinen Fall zu gebrauchen.
Wenn ich die nächste Woche etwas Zeit finde werde ich auf dem Ding wieder anfangen mit den mini Scripten zu testen, mal schaun ob ich da schlauer werde.
Ich checke jetzt noch eine neue Version des Moduls ein, habe ein paar Kleinigkeiten beim Logging angepasst und ein neues Attribut sip_filter.
sip_filter ist eine Komma getrennte Liste von Rufnummern oder Rufnummernteilen die festlegen ob der Client bei listen überhaupt abheben soll.
Bsp : attr mySIP sip_filter **61,123
**61 = alle DECT Telefone der Fritzbox (610 -619 )
123 = alle Rufnummern in denen die Folge 123 enthalten ist.
Zitat von: Wzut am 17 März 2017, 20:58:38
...Ich checke jetzt noch eine neue Version des Moduls ein, habe ein paar Kleinigkeiten beim Logging angepasst und ein neues Attribut sip_filter.
sip_filter ist eine Komma getrennte Liste von Rufnummern oder Rufnummernteilen die festlegen ob der Client bei listen überhaupt abheben soll.
Bsp : attr mySIP sip_filter **61,123
**61 = alle DECT Telefone der Fritzbox (610 -619 )
123 = alle Rufnummern in denen die Folge 123 enthalten ist.
Vielen Dank, darauf hatte ich noch gewartet. die Text2speech Funktion geht prima, habe auch ein Intel (NUK) System. Das ist zwangsläufig, wenn man schon ca. 7 Jahre Fhem im Einsatz hat.
Hatte leider heute das Problem, das FHEM beim Neustart hängen blieb mit dieser letzten Zeile im LOG:
Undefined subroutine &main::SIP_watchdog_t2s called at fhem.pl line 2907.
nach Auskommentieren des T2S geht es wieder, anschließendes wieder Reinnehmen des T2S funktioniert auch ???
@det, danke für die Info. SIP_watchdog_t2s ist falsch es muss SIP_watchdog_T2S sein. Werde ich gleich fixen
Performance auf Raspi@Wzut:
Ich war gerade mal so kühn und habe in .../Net/SIP/DTMF.pm (v 0.808, Zeile 385) folgende Änderung vorgenommen:
<snip>
sub _dtmf_xtc_audio {
return;
};
sub xxx_dtmf_xtc_audio {
_init_audio_processing() if !@costab;
</snip>
Dadurch wird vermutlich die Frequenz-Erkennung und daraus Ableitung von DTMF-Tönen ausgeschaltet. Ohne diese Routine läuft's auch auf dem Raspi.
SIP-Client war meine Analyse-Script (peter30.pl). Ich kann von meiner FritzFon-App aus anrufen, es werden Tastendrücke empfangen und korrekt erkannt. Ist aber vermutlich nur RFC2833 und kein klassisches piep-piep-DTMF-Audio.
Was nun? Man müsste in die
_dtmf_xtc_audio einsteigen und vermutlich deren Vorgehensweise ändern:
- feststellen, ob so etwas wie DTMF-Audio in der payload enthalten ist
- nein => nix wie raus hier und keine CPU-Last erzeugen
- ja => payload analysieren was evtl. DTMF-Events auslöst
Mit dem Ansatz ließe sich vielleicht die CPU-Auslastung reduzieren.
Oder man nimmt die Sub komplett auseinander und schreibt eine performantere Fassung.
Zitat von: plin am 18 März 2017, 09:37:24
Oder man nimmt die Sub komplett auseinander und schreibt eine performantere Fassung.
mmh, wäre doch mal eine schöne Übung für pah's Studenten :-) ? Ein Wettbewerb???
Hallo,
ich würde gerne mehrere Anrufe nacheinander tätigen. Beim folgendem Aufruf denke ich allerdings, dass es zu einem Konflikt kommen wird:
fhem("set FritzSip call 491...6 60 !Hallo Sohn"."$EventHeute");
fhem("set FritzSip call 491...7 60 !Hallo Tochter"."$EventHeute");
Am Besten wäre eine Erweiterung von
set <name> call <number> [<maxtime>] [<message>]
auf
set <name> call <number>[,<number>,...] [<maxtime>] [<message>,...] bzw. die Übergabe eines Arrays als Alternative zu den drei Parametern.
Oder habt ihr eine bessere Lösung?
Grüße Jörg
Zitat von: JoWiemann am 18 März 2017, 13:17:49
Beim folgendem Aufruf denke ich allerdings, dass es zu einem Konflikt kommen wird:
ja das wird schief gehen denn wenn der erste Anruf noch abgearbeitet wird sollte die Nummer 2 eine Fehlermeldung ala
"there is already a call activ with pid" produzieren. D.h. man müsste im Modul ein FIFO einbauen das die Anrufe nach und nach abarbeitet.
_dtmf_xtc_audio: offenbar kann man (lt.DTMF.pod) die audio-Erkennung ausschalten ... es fehlt aber wieder mal an passenden Beispielen
Hab das erst mal mit versetzten at gelöst. Aber das mit dem FiFo wäre schon schön. Und nun die Frage: Wer baut es ein? [emoji23]
Grüße Jörg
Gesendet von iPhone mit Tapatalk
_dtmf_xtc_audio
Nachdem ich keinen konkreten Aufruf für die _dtmf_xtc_audio bzw. dtmf_extractor gefunden habe (obwohl sie durchlaufen werden), habe ich die These aufgestellt: geht's auch ohne sie? Ein Test mit der Fritz!App-Fon sowie einem ISDN-Telefon (schaltet automatisch auf hörbare Tonwahl um, sobald der Angerufene abnimmt) zeigt, dass in beiden Fällen die Tasten korrekt erkannt werden. Und das auf einem Raspi2.
Bils zum Beweis des Gegenteils (bzw. einer fehlenden Funktion) lautet der Fix für ARM-Prozessoren:
diff DTMF.pm DTMF.pm.orig
386,389d385
< return;
< };
<
< sub xxx_dtmf_xtc_audio {
Unter jessie z.B. im Verzeichnis /usr/local/share/perl/5.20.2/Net/SIP zu finden.
Ich habe bisher nur den Positiv-Test durchgeführt, evtl. Wechselwirkungen mit anderen Funktionen sind daher nicht ausgeschlossen. Falls ihr Probleme feststellt bitte posten.
@Wzut
Zitatund 5 steht nicht für die Anzahl klingeln (siehe https://wiki.fhem.de/wiki/SIP-Client)
Im Wiki steht:
set <name> call <nummer> [<ringtime>] [<nachricht>]
Startet einen Anruf an die angegebene Nummer.
Optional kann die ringtime angegeben werden. Wird keine angegeben zieht das Attribut sip_ringtime. Default ist 10.Ich versteh das so das ich die Zeit mitgeben kann wie lange das Telefon klingeln soll. (lasse mich gerne eines besseren belehren)
Wie gesagt ich möchte einfach nur ein Telefon intern 3-4 klingekn lassen und wieder auflegen.
Gruß Andreas
ZitatHallo,
ich möchte das Modul als Türklingel nutzen und rufe intern von meinem Fhemserver (alles aktuell) die Fritzbox (6490 mit 6.5) mit "set mySIP call **610 5" an.
Das Dect Telefon klingelt wie es soll. Allerdings habe ich erwartet das nach 4 mal klingeln aufgelegt wird, was nicht funktioniert.
Habt ihr da eine Idee?
Hallo Atze,
die Betonung liegt auf ringtime. Das ist nicht die Anzahl. Du musst mal ausprobieren mit welcher Dauer du auf 4 mal klingeln kommst. Bei mir ist es 08.
VG plin
ja ich habe das im Wiki auch schon mal geändert , das Wort Ringtime hält sich verdammt hartnäckig , genau wie der falsche Defaultwert 10
Zitat von: JoWiemann am 19 März 2017, 09:37:47
Und nun die Frage: Wer baut es ein? [emoji23]
Und nun die Antwort : Ich , morgen via update verfügbar :)
Aber ACHTUNG :
Was nicht geht ist zb :
set mySip call **611 20 !Test 1
set mySip call **611 20 !Test 2
set mySip call **611 20 !Test 3
Selbst wenn man den ersten Ruf annimt, folgt Ruf Nr 2 so schnell das mein FritzPhone nicht reagiert. Nach dem Timeout von Nr. 2 kommt dann aber Nr. 3 wieder an.
Den Test wiederholt mit :
set mySip call **611 20 !Test 1
set mySip call **613 20 !Test 2
set mySip call **611 20 !Test 3
führt zum Erfolg. Ich denke das passt so für deine ersten Versuche. Wenn es so OK ist werde ich noch eine Prüfung der Ziel Rufnummern einbauen und
Anrufe die das gleiche Ziel haben wie der direkte Vorgänger in der Queue verwerfen.
Zitat von: Wzut am 19 März 2017, 18:50:46
Und nun die Antwort : Ich , morgen via update verfügbar :)
Hi, danke und werde ich morgen testen.
Grüße Jörg
PS: Und mal sehen, wie der Nachwuchs auf den Anruf reagiert, wenn das Haus die Mülltonne nach vorne gestellt haben will :)
Hallo, habe einen kurzen Test durchgeführt, funktioniert soweit super, gute Arbeit.
Könntest du noch eine kleine Verzögerung rein machen wenn man einen Anruf absetzt bist das Audio File oder das Gerede losgeht?
Gruß
Max
Hallo,
bis vor ca. zwei Wochen war es noch so, dass nach dem Abspielen der Audiodatei (Mode: listen_wfp) die Verbindung von der fhem-Seite automatisch wieder beendet wurde.
So ist es auch im Wiki beschrieben. Leider bleibt aber seit einiger Zeit die Verbindung bestehen und muss vom Anrufer aktiv beendet werden.
Ist das Absicht (was ich nicht hoffe, da es eher unpraktisch ist) bzw. lässt sich das wieder fixen?
Danke und viele Grüße
Klaus
PS: Von diesem kleinen Manko abgesehen ist es ein echt tolles Modul! Danke dafür.
Zitat von: MadMax am 20 März 2017, 17:35:25
Könntest du noch eine kleine Verzögerung rein machen wenn man einen Anruf absetzt bist das Audio File oder das Gerede losgeht?
Bildlich gesprochen , die Zeit die man benötigt um den Hörer abzunehmen und bis zum Ohr zu führen ? 0,5 - 1 Sekunde ?
@plin, bekommt man das mit nem sleep an der richtigen Stelle in den Griff ?
Zitat von: Laserhelge am 20 März 2017, 18:33:19
Leider bleibt aber seit einiger Zeit die Verbindung bestehen und muss vom Anrufer aktiv beendet werden.
Das soll so nicht sein :(
@plin, ist wohl beim DTMF Umbau unter die Räder gekommen ....
@Wutz, genau das meine ich, also etwa 1s sleep
Zitat von: Wzut am 20 März 2017, 19:39:30
Das soll so nicht sein :(
@plin, ist wohl beim DTMF Umbau unter die Räder gekommen ....
Hallo wzut,
danke für das Modul - funktioniert bei mir größtenteils schon sehr gut.
Habe aber auch bemerkt, daß beim Erkennen von DTMF Tönen nicht immer von alleine aufgelegt wird. Das funktioniert korrekt, wenn während eines Anrufs die erwartete Anzahl (sip_dtmf_size) unterschiedlicher DTMF Töne erkannt wird.
Kommt allerdings vor Erreichen der Anzahl ein Hangup gefolgt von einem neuen Anruf, wird der "Anzahl"-Counter offenbar nicht neu initialisiert.
Siehe hier mit verbose=5:
2017.03.20 10:13:32 5: mySIP[7922], telnet : set mySIP caller Tobi sip:017xxxxxxx@fritz.box
exit
2017.03.20 10:13:32 5: mySIP[7922], telnet : set mySIP caller_state ringing
exit
2017.03.20 10:13:35 5: mySIP[7922], telnet : set mySIP caller_state established
exit
2017.03.20 10:13:42 5: mySIP[7922], DTMF Event: # - 19 ms
2017.03.20 10:13:43 5: mySIP[7922], DTMF Event: # - 388 ms
2017.03.20 10:13:44 5: mySIP[7922], DTMF Event: 5 - 19 ms
2017.03.20 10:13:45 5: mySIP[7922], DTMF Event: 5 - 268 ms
2017.03.20 10:13:45 5: mySIP[7922], DTMF: 5 , Anz: 2
2017.03.20 10:13:45 5: mySIP[7922], DTMF Event: 8 - 19 ms
2017.03.20 10:13:46 5: mySIP[7922], DTMF Event: 8 - 88 ms
2017.03.20 10:13:49 5: mySIP[7922], SIP_bye : HASH(0x2a6c958)
2017.03.20 10:13:49 5: mySIP[7922], telnet : set mySIP caller none
set mySIP caller_state hangup
exit
2017.03.20 10:13:59 5: mySIP, listen prozess 7922 found
2017.03.20 10:14:19 5: mySIP[7922], SIP_filter : a:"Tobi" <sip:017xxxxxxxx@fritz.box>;tag=C4AA49B8D3385564 | b:Net::SIP::Request=HASH(0x2b72720)
2017.03.20 10:14:19 5: mySIP[7922], telnet : set mySIP caller Tobi sip:017xxxxxxx@fritz.box
exit
2017.03.20 10:14:19 5: mySIP[7922], telnet : set mySIP caller_state ringing
exit
2017.03.20 10:14:22 5: mySIP[7922], telnet : set mySIP caller_state established
exit
2017.03.20 10:14:32 5: mySIP[7922], DTMF Event: # - 20 ms
2017.03.20 10:14:33 5: mySIP[7922], DTMF Event: # - 248 ms
2017.03.20 10:14:33 5: mySIP[7922], DTMF: 5# , Anz: 3
2017.03.20 10:14:33 5: mySIP[7922], telnet : set mySIP dtmf_event 5#
2017.03.20 10:14:33 5: mySIP[7922], DTMF Event: 9 - 19 ms
2017.03.20 10:14:34 5: mySIP[7922], DTMF Event: 9 - 88 ms
2017.03.20 10:14:36 5: mySIP[7922], DTMF Event: 8 - 69 ms
2017.03.20 10:14:40 5: mySIP[7922], SIP_bye : HASH(0x2a8c350)
2017.03.20 10:14:40 5: mySIP[7922], telnet : set mySIP caller none
set mySIP caller_state hangup
exit
Hier noch zum Vergleich ein list von meinem SIP Device:
Internals:
LPID 21523
NAME mySIP
NR 98
NTFY_ORDER 50-mySIP
STATE listen_dtmf
TYPE SIP
VERSION V1.45 / 19.03.17
Readings:
2017-03-20 15:26:52 caller none
2017-03-20 15:26:52 caller_state hangup
2017-03-20 15:26:51 dtmf 0*
2017-03-20 10:12:01 last_error ListenRegister: Failed with code 401
2017-03-21 15:49:24 state listen_dtmf
Helper:
Listen_pid:
abortArg
abortFn
arg mySIP
bc_pid 2
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 21523
timeout
Attributes:
room SIP
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_from sip:620@fritz.box
sip_ip 192.168.8.46
sip_listen dtmf
sip_port 5060
sip_registrar fritz.box
sip_ringtime 1
sip_user 620
Gruß
Tobias
Danke fürs Feedback, schau ich mir nochmal genau an.
Stutzig macht mich allerdings diese Zeile :
2017.03.20 10:14:33 5: mySIP[7922], telnet : set mySIP dtmf_event 5#
der # dürfte nie als Event rausgehen sondern sollte immer wieder als Startzeichen erkannt werden.
Hallo,
wollte mich heute auch mal am SIP-Modul versuchen, doch leider schießt es mir FHEM schon beim define ab:
define fhemSIP SIP
FHEM muss ich dann manuell neu starten. Im Log sehe ich dann folgendes:
2017.03.21 20:41:59 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 109.
Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 109.
Net::SIP habe ich über cpan installiert, es ist die Version 0.808
Eine Idee, was hier schief läuft?
Gruß
Olly
ja , bei dire klappt die Feststellung der eigenen IP nicht.
Bis ich da eine Umgehung gebaut habe kannst du dir damit behelfen die Zeile 109 von Hand zu ändern :
my $addr = "0.0.0.0"; bzw. statt 0.0.0.0 deine echte IP des FHEM Servers.
Ab morgen früh gibt es wieder ein Update :
FIX : das Modul legt wieder auf bei wfp
Neu
neues Attribut sip_call_audio_delay , gültige Werte 0 - 3 in 0.25 (1/4) Sekunden Schritten.
Damit wird festgelegt wie lange bei einem Call mit dem abspielen des Audiofiles gewartet werden soll nachdem man den Anruf angenommen hat (Vorschlag MadMax)
neue Funktion Call force
Ihr wollt sicherstellen da ein bestimmter ausgehender Anruf auch wirklich ankommt / angenommen wird ?
Wenn ein normaler Anruf nicht "zugestellt" werden kann (besetzt, nicht erreichbar, etc) ist er verloren. Die Lösung : solange wiederholen bis er erfolgreich angenommen wurde.
Dazu ist dem set call am Ende ein & mitzugeben , Bsp :
set mySIP call 01601234567 30 !Rauchmelder Keller ausgelöst &
set mySIP call **611 20 ./tada.alaw &
WICHTIG : wählt die maxtime groß genug damit das Audiofile auch wirklich komplett abgespielt werden kann , bzw. hört s euch auch bis zum Ende an !
Immer wenn so ein Anruf endet mit quasi NOK wird ein temp at mit dem Namen at_forecall_<teile der Rufnummer> und der Zeitdauer von 1 Minute erstellt.
Ist diese eine Minute abgelaufen wird der Anruf wiederholt, und zwar so lange bis er erfolgreich war. Wollt Ihr den Ablauf stoppen bitte einfach das at löschen,
es befindet sich im gleichen Raum wie euer SIP Device. Z.Z ist diese 1 Minute noch fix, wenn es bei euch sauber läuft werde ich dafür ein neues Attribut spendieren.
Hallo Wzut,
perfekt! Eintragen der Server-IP in der SIP.pm hat geholfen.
Werde dann mal schauen, dass ich weiter komme.
vielen Dank
Gruß
Olly
Hallo Wzut,
ich möchte mich bei Dir an diese Stelle besonders bedanken!
Deine Entwicklungsarbeit ist genial! Du reagierst sehr schnell und stellst Parameter zur Verfügung, die für die individuelle Lösungssuche ideal einsetzbar sind. Man kommt mit dem Testen und einbauen der Parameter fast nicht nach ;D.
Ich setze dein Modul für die Feuerwehralarmierung ein. Falls mal der Feuerwehrmelder in der Wohnung nicht gehört wird, meldet der HM-MOD-EM-8 daß ein Einsatzalarm vorliegt und dann gehts rund in FHEM :-). Alarmierung unserer Jungs auf allen verfügbaren Kanälen.
Der Anruf über Dein Modul ist schneller als das FritzBox Modul.
Viele Grüße
Rainer
Zitat von: Heuberg am 21 März 2017, 23:19:31
Man kommt mit dem Testen und einbauen der Parameter fast nicht nach ;D.
BIG THX, aber das hat auch seinen Preis, ich/wir hängen mit der Doku in der command.ref furchtbar zurück :(
Hallo,
ein schönes Modul. Ich bin gerade dabei, meine Anbindung der Türsprechanlage damit zu realisieren. Dabei hätte ich einen Wunsch: Ich möchte gerne einen Anruf erkennen (ringing), ihn dann aber nicht annehmen, sondern abweisen. Das könnte man doch bestimmt einbauen. Oder habe ich was übersehen und das geht schon?
Gruß
Otto
Zitat von: Wzut am 22 März 2017, 06:58:04
BIG THX, aber das hat auch seinen Preis, ich/wir hängen mit der Doku in der command.ref furchtbar zurück :(
Vor vielen, vielen Jahren hat mein Chef mal gesagt: Die beste Doku ist der Source und wer ihn lesen kann, versteht auch wirklich was passiert :)
Grüße Jörg
Zitat von: Olly am 21 März 2017, 22:55:53
perfekt! Eintragen der Server-IP in der SIP.pm hat geholfen.
gut , bei dir geht FQDN Auflösung schief. Ich möchte mein Testsystem nicht unnötig verbiegen und kann daher das nicht nachstellen. Könntest du bitte mal bei dir folgendes versuchen :
1. ändere im Modul die Zeile
use Net::Domain qw( hostfqdn );
in
use Net::Domain qw( hostfqdn hostname);
dann weiter unten (ohne die böse Zeile 109 ) ab my $addr=
my $addr = "0.0.0.0";
unless (exists($attr{$name}{sip_ip}))
{
eval { $addr = inet_ntoa(scalar(gethostbyname(hostfqdn()))); };
if ($@)
{
Log3 $name,2,"$name, please check your FQDN hostname -> $@";
eval { $addr = inet_ntoa(scalar(gethostbyname(hostname()))); };
Log3 $name,2,"$name, please check your hostname -> ".$@ if ($@);
}
$attr{$name}{sip_ip} = $addr;
}
2. Das vorhande attribut sip_ip löschen
3. fhem save
4. shutdown restart
FHEM sollte starten ohne hängen zu bleiben. Bitte ins Log schauen die die ggf. vorhanden "please check your" hier posten.
Zitat von: knodono am 22 März 2017, 09:02:09
Oder habe ich was übersehen und das geht schon?
2x ja :) setze sip_filter auf irgend etwas was auf keine deiner Telefonnummern passt z.B. 0000
Das Modul wird nun nur noch abheben wenn in der Quell Rufnummer 0000 vorhanden ist.
D.h. es wird ihn nicht direkt abweisen sondern nur einfach nicht ran gehen, zusammen mit sip_ringtime (kleiner Wert bsp 2) ist es aber recht schnell wieder bereit für den nächsten Anruf
Zitat von: Wzut am 22 März 2017, 09:54:30
2x ja :) setze sip_filter auf irgend etwas was auf keine deiner Telefonnummern passt z.B. 0000
Das Modul wird nun nur noch abheben wenn in der Quell Rufnummer 0000 vorhanden ist.
D.h. es wird ihn nicht direkt abweisen sondern nur einfach nicht ran gehen, zusammen mit sip_ringtime (kleiner Wert bsp 2) ist es aber recht schnell wieder bereit für den nächsten Anruf
Danke, aber so ganz wie ich mir das vorstelle, funktioniert das noch nicht. Nur "caller" reagiert auf den Anruf, "caller_state" bleibt aber unverändert. Außerdem ruft das anrufende Telefon munter weiter, der Ruf wird also nicht abgewiesen.
Gruß Otto
Zitat von: Wzut am 22 März 2017, 09:54:30
gut , bei dir geht FQDN Auflösung schief. Ich möchte mein Testsystem nicht unnötig verbiegen und kann daher das nicht nachstellen. Könntest du bitte mal bei dir folgendes versuchen :
1. ändere im Modul die Zeile
use Net::Domain qw( hostfqdn );
in
use Net::Domain qw( hostfqdn hostname);
dann weiter unten (ohne die böse Zeile 109 ) ab my $addr=
my $addr = "0.0.0.0";
unless (exists($attr{$name}{sip_ip}))
{
eval { $addr = inet_ntoa(scalar(gethostbyname(hostfqdn()))); };
if ($@)
{
Log3 $name,2,"$name, please check your FQDN hostname -> $@";
eval { $addr = inet_ntoa(scalar(gethostbyname(hostname()))); };
Log3 $name,2,"$name, please check your hostname -> ".$@ if ($@);
}
$attr{$name}{sip_ip} = $addr;
}
2. Das vorhande attribut sip_ip löschen
3. fhem save
4. shutdown restart
FHEM sollte starten ohne hängen zu bleiben. Bitte ins Log schauen die die ggf. vorhanden "please check your" hier posten.
Ok, das kann ich mal testen.
Kann es ggf. auch einfach daran liegen, dass ich gar keinen FQDN hinterlegt habe? Bin mir nicht ganz sicher, aber habe ggf. nur den Hostname eingetragen.
Ich teste das heute Abend mal....
Gruß
Olly
Zitat von: knodono am 22 März 2017, 10:20:32
Danke, aber so ganz wie ich mir das vorstelle, funktioniert das noch nicht.
Nun gut, ich habe halt Probleme mir deine Config direkt anzuschauen ..... daher könnten wir den Posting Ping-Pong vermutlich erheblich verkürzen wenn du a. mal ein List von deinem SIP Device postest und b. mir exakt erklärst wie der Ablauf denn sein sollte. Entscheidend ist auf jeden Fall schon mal in welchem listen Modus du arbeitest, ich würde wfp empfehlen und eine sehr kleine sip_waittime BTW : Wiki https://wiki.fhem.de/wiki/SIP-Client hast du gelesen ?
Zitat von: Olly am 22 März 2017, 13:27:40
Bin mir nicht ganz sicher, aber habe ggf. nur den Hostname eingetragen.
schön, das sollte dann mit der Änderung auch gehen. Letztendlich ist nur wichtig das beim ersten Start ohne gesetztes sip_ip Attribut eine relative plausible IP Adresse heraus kommt. Nachdem die config einmal mit dem Attribut gespeichert wurde wird sie eh nicht mehr durchlaufen.
ZitatNun gut, ich habe halt Probleme mir deine Config direkt anzuschauen ..... daher könnten wir den Posting Ping-Pong vermutlich erheblich verkürzen wenn du a. mal ein List von deinem SIP Device postest und b. mir exakt erklärst wie der Ablauf denn sein sollte.
Danke für Deine Mühe. Hier das Listing:
Internals:
LPID 32074
NAME sip1
NOTIFYDEV babbel
NR 468
NTFY_ORDER 50-sip1
STATE listen_wfp
TYPE SIP
VERSION V1.46 / 21.03.17
Readings:
2017-03-22 09:49:07 call done
2017-03-22 09:49:07 call_state ok
2017-03-22 15:35:40 caller Mobilteil 4 sip:**613@fritz.box
2017-03-22 15:32:58 caller_state hangup
2017-03-22 15:31:13 last_error ListenRegister: Failed with code 401
2017-03-22 15:35:05 state listen_wfp
Helper:
Listen_pid:
abortArg
abortFn
arg sip1
bc_pid 1
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 32074
timeout
Attributes:
T2S_Device babbel
room Haustuer
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_filter 0000
sip_from sip:620@fritz.box
sip_ip 10.0.0.52
sip_listen wfp
sip_port 5060
sip_registrar fritz.box
sip_ringtime 2
sip_user 620
Das Wiki habe ich schon gelesen, was nicht heißt, dass ich nichts übersehen haben könnte.
Was ich erreichen will: Ich möchte durch einen Anruf eine Aktion in fhem auslösen, z.B. über ein DOIF. Dabei soll der Anruf nur erkannt und dann abgewiesen werden. Das hat z.B. den Vorteil, dass bei einem Anruf von außen (Handy) dabei keine Kosten anfallen. Im Moment habe ich eine solche Anwendung (als Türöffner über Handy-Anruf) mit Asterisk realisiert, fände es aber schön, wenn der Asterisk-Server, der nur dafür läuft, wegfallen könnte.
Gruß Otto
Versuch mal bei sip_registrar fritz.box die IP-Adresse der FritzBox einzutragen und den sip_port 5070 zu nehmen.
Zitat von: knodono am 22 März 2017, 15:48:24
Dabei soll der Anruf nur erkannt und dann abgewiesen werden. Das hat z.B. den Vorteil, dass bei einem Anruf von außen (Handy) dabei keine Kosten anfallen. Im Moment habe ich eine solche Anwendung (als Türöffner über Handy-Anruf)
Also Türöffner nur mit Anruf auf die Zielrufnr , das lasse ich jetzt mal unkommentiert. Mit Rufnr Prüfung + DTMF Code wäre mir zwar auch noch zu unsicher, aber jeder wie er mag.
Wie ich schon schrieb abweisen geht nicht , einzige Alternative : gar nicht abheben.
listen auf wfp ist schon mal gut, da bekommst du die passenden Events, allerdings must du sip_filter dann auch ganz löschen oder ihm einen Wert geben der zu deiner Quelle passt, sonst gibt es keine Events mit caller_state.
Setze die sip_waittime auf einen großen Wert , Bsp 60 oder 120 dann hast du genug Zeit rechtzeitig mit dem Handy aufzulegen ohne Kosten zu verursachen.
Nachteil ist halt das du für die nächste Aktion wieder warten mußt bis diese Zeit komplett abgelaufen ist. So schaut das z.B. dann bei mir im Event Monitor aus :
2017-03-22 17:19:37 SIP mySIP caller: Büro sip:**611@fritz.box
2017-03-22 17:19:37 SIP mySIP caller_state: ringing
2017-03-22 17:21:38 SIP mySIP caller: none
2017-03-22 17:21:38 SIP mySIP caller_state: waiting
2017-03-22 17:21:38 SIP mySIP caller: none
2017-03-22 17:21:38 SIP mySIP caller_state: hangup
so könntest du dein notify auf zb mySIP:caller_state:ringing triggern um die Aktion auszulösen
ZitatAlso Türöffner nur mit Anruf auf die Zielrufnr , das lasse ich jetzt mal unkommentiert. Mit Rufnr Prüfung + DTMF Code wäre mir zwar auch noch zu unsicher, aber jeder wie er mag.
:) Na ja, eine Rufnummern-Prüfung ist natürlich drin, das macht schon die Fritzbox. Außerdem ist das bei mir nicht ganz so sicherheitsrelevant. Aber das ist ja nicht das Thema.
Prinzipiell funktioniert dein Vorschlag. Ob ich damit meine bestehende Lösung ablösen möchte, weiß ich noch nicht.
Ideal wäre es, wenn du so was wie ein "set mysip reject" einbauen könntest, mit dem ein eingehender Anruf abgewiesen wird. Sollte eigentlich technisch möglich sein, über Asterisk mache ich genau das.
Jedenfalls vielen Dank für deine Hilfe, mal sehen, was ich draus mache
Otto
Zitat von: knodono am 22 März 2017, 17:54:00
Sollte eigentlich technisch möglich sein, über Asterisk mache ich genau das.
Wenn Net::SIP doch nur so gut dokumentiert wäre wie Asterisk ...
Zitat von: Wzut am 22 März 2017, 09:54:30
gut , bei dir geht FQDN Auflösung schief. Ich möchte mein Testsystem nicht unnötig verbiegen und kann daher das nicht nachstellen. Könntest du bitte mal bei dir folgendes versuchen :
1. ändere im Modul die Zeile
use Net::Domain qw( hostfqdn );
in
use Net::Domain qw( hostfqdn hostname);
dann weiter unten (ohne die böse Zeile 109 ) ab my $addr=
my $addr = "0.0.0.0";
unless (exists($attr{$name}{sip_ip}))
{
eval { $addr = inet_ntoa(scalar(gethostbyname(hostfqdn()))); };
if ($@)
{
Log3 $name,2,"$name, please check your FQDN hostname -> $@";
eval { $addr = inet_ntoa(scalar(gethostbyname(hostname()))); };
Log3 $name,2,"$name, please check your hostname -> ".$@ if ($@);
}
$attr{$name}{sip_ip} = $addr;
}
2. Das vorhande attribut sip_ip löschen
3. fhem save
4. shutdown restart
FHEM sollte starten ohne hängen zu bleiben. Bitte ins Log schauen die die ggf. vorhanden "please check your" hier posten.
So, hab das mal getestet.
Folgendes erscheint im Logfile:
2017.03.22 20:54:34 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 112.
2017.03.22 20:54:34 2: fhemSIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 112.
Ich habe daraufhin mal in meiner /etc/hosts einen entsprechenden Eintrag mit IP-Adresse und FQDN hinterlegt. Aber auch hiermit bleibt die Meldung im Log gleich.
Mit dem erweiterten Code in der 96_SIP.pm wird dann aber richtig meine IP in SIP_IP übernommen.
Gruß
Olly
Zitat von: knodono am 22 März 2017, 17:54:00
Sollte eigentlich technisch möglich sein,
klar schick mir einen Patch und ich baue es ein :)
Zitat von: Olly am 22 März 2017, 21:03:47
Mit dem erweiterten Code in der 96_SIP.pm wird dann aber richtig meine IP in SIP_IP übernommen.
THX fürs testen, dann kommt das so in die nächste Version. Hauptsache FHEM läuft beim Start durch.
Zitat von: Wzut am 23 März 2017, 07:16:09
THX fürs testen, dann kommt das so in die nächste Version. Hauptsache FHEM läuft beim Start durch.
Ja, FHEM startet damit dann bei mir.
Gruß
Olly
Zitat von: knodono am 22 März 2017, 09:02:09
Ich möchte gerne einen Anruf erkennen (ringing), ihn dann aber nicht annehmen, sondern abweisen.
Ich möchte auf diesen Punkt nochmal eingehen. Es wird die Tage (spätestens Montag) eine neue Version mit dem neuen Attribut sip_blocking geben. Da dieses Attribut eng mit dem bereits bestehenden Attribut sip_filter zusammen hängt, sind ein paar Grundregeln bei ihrem Einsatz zu beachten :
sip_filter = ich nenne sie jetzt mal die Liste der "Guten" oder Whitelist, definiert man sie muss man unbedingt dafür sorgen das auch wirklich jede mögliche Telefonnummer abgedeckt ist auf die man später reagieren möchte. Ein Joker in der Form .* gibt es
nicht , möchte man wirklich alle Rufnummern zulassen so ist sip_filter entweder leer zu lassen oder erst gar nicht zu definieren.
sip_blocking = die Liste der "Bösen" oder Blacklist, hier werden Rufnummern (bzw. deren Teile) definiert, auf die man in der Art reagieren möchte das man sie nicht einfach nur nicht beachtet, sondern aktiv den Ruf quasi "wegdrückt".
D.h. jede Rufnummer die so behandelt werden soll muss zuerst erfolgreich durch sip_filter und kann danach erst aktiv geblockt werden. Die Syntax ist die gleiche wie bei sip_filter, allerdings gibt es hier den Joker .* Ist dieser gesetzt wird
jede ankommende Rufnummer geblockt.
Auf meinem Testsystem läuft das z.Z. schon recht gut, ich bin allerdings noch dabei etwas an den caller Stati zu schrauben, da sie mir teilweise noch nicht so recht gefallen.
Hallo, habe heute mal, nach längerer Zeit, ein update gemacht und bekomme nun beim Start von fhem:
Messages collected while initializing FHEM:
configfile: mySIP: unknown attribute sip_audiofile. Type 'attr mySIP ?' for a detailed list.
Was hat sich denn da geändert und wie korrigiere ich das wieder?
P.S. erledigt ;)
VG
Frank
Zitat von: Wzut am 24 März 2017, 09:21:13
sip_blocking = die Liste der "Bösen" oder Blacklist, hier werden Rufnummern (bzw. deren Teile) definiert, auf die man in der Art reagieren möchte das man sie nicht einfach nur nicht beachtet, sondern aktiv den Ruf quasi "wegdrückt".
Das klingt gut! Ich werde es testen, sobald es verfügbar ist.
Verfügbar ist es ab morgen 7:45
plin hatte aber noch eine gute Idee:
Im Modus listen_wfp muss man das nicht unbedingt fix über sip_blocking machen. Bei wfp hat man sowieso schon die waittime um mittels notify/DOIF auf den Anruf zu reagieren. Bisher gab es da nur das Kommando set <name> fetch, ich habe jetzt noch set <name> reject hinzugefügt.
D.h. solange wfp die waittime hochzählt kann man mit set reject den Anruf noch abwieisen.
@knodono , du kannst also entweder waittime klein setzen (1) und sip_blocking benutzen oder
waittime etwas größer (10) wählen, sip_blocking leer lassen und mit set reject den Anruf innerhalb dieser Zeit abweisen.
Hallo Wzut,
irgend etwas hakt bei mir noch:
Folgender Ablauf:
DOIF ([sip1:caller_state] eq "ringing_1")
(set sip1 reject)
(set sip1 call **621 30 ---#9)
zwischen den einzelnen Kommandos sind 5s Pause eingestellt.
Erster Versuch:
Anruf geht ein, wird abgewiesen, Ruf geht raus, alles gut. Fritzbox meldet "Declined (603)" wie es sein soll.
Zweiter Versuch: Anruf geht ein, fhem sagt, er wird abgewiesen, aber Fritzbox merkt es nicht, ruft weiter. fhem sagt, Ruf geht raus, scheint manchmal auch zu klappen, aber nicht zuverlässig.
Ab diesem Zeitpunkt ignoriert die Fritzbox ein "set call reject" dauerhaft. Erst ein Neustart der Fritzbox (7490, OS 6.83) behebt das Problem.
Hier das Logfile:
############## 1. Versuch
2017.03.25 15:57:06 5: sip1[13662], SIP_filter : a:"Otto Büro" <sip:**2@fritz.box>;tag=7EC41FA09BB483FD | b:Net::SIP::Request=HASH(0x33ada18)
2017.03.25 15:57:06 5: sip1[13662], telnet : set sip1 caller Otto Büro sip:**2@fritz.box
exit
2017.03.25 15:57:06 4: sip1[13662], SIP_invite -> ringing 1
2017.03.25 15:57:06 5: sip1[13662], telnet : set sip1 caller_state ringing_1
exit
2017.03.25 15:57:07 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:57:07 4: sip1[13662], SIP_invite -> ringing 2
2017.03.25 15:57:07 5: sip1[13662], telnet : set sip1 caller_state ringing_2
exit
2017.03.25 15:57:08 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:57:08 4: sip1[13662], SIP_invite -> ringing 3
2017.03.25 15:57:08 5: sip1[13662], telnet : set sip1 caller_state ringing_3
exit
2017.03.25 15:57:09 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:57:09 4: sip1[13662], SIP_invite -> ringing 4
2017.03.25 15:57:09 5: sip1[13662], telnet : set sip1 caller_state ringing_4
exit
2017.03.25 15:57:10 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:57:10 4: sip1[13662], SIP_invite -> ringing 5
2017.03.25 15:57:10 5: sip1[13662], telnet : set sip1 caller_state ringing_5
exit
2017.03.25 15:57:11 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:57:11 4: sip1[13662], SIP_invite block !
2017.03.25 15:57:11 5: sip1[13662], telnet : set sip1 caller_state rejected
exit
2017.03.25 15:57:16 4: sip1, message DTMF = ---#9
2017.03.25 15:57:16 5: sip1, call has pid 13671
2017.03.25 15:57:17 5: sip1[13671], my parent is 13546
2017.03.25 15:57:17 4: sip1[13671], register new expire : Sat Mar 25 16:02:17 2017
2017.03.25 15:57:17 5: sip1[13671], telnet : set sip1 state calling
exit
2017.03.25 15:57:18 4: sip1, CallStart DTMF : --#9
2017.03.25 15:57:18 5: sip1[13671], telnet : set sip1 call_state calling **621
exit
2017.03.25 15:57:18 4: sip1[13671], calling : **621
2017.03.25 15:57:21 5: sip1[13671], RTP done : OK
2017.03.25 15:57:21 5: sip1[13671], Stopvar : HASH(0x2bc1188)
2017.03.25 15:57:21 4: sip1, CALLDone -> sip1|1|ok|
2017.03.25 15:57:29 5: sip1, listen prozess 13662 found
######### 2. Versuch
2017.03.25 15:58:10 5: sip1[13662], SIP_filter : a:"Otto Büro" <sip:**2@fritz.box>;tag=6E459BBC290F6066 | b:Net::SIP::Request=HASH(0x334ffc0)
2017.03.25 15:58:10 5: sip1[13662], telnet : set sip1 caller Otto Büro sip:**2@fritz.box
exit
2017.03.25 15:58:10 4: sip1[13662], SIP_invite -> ringing 1
2017.03.25 15:58:10 5: sip1[13662], telnet : set sip1 caller_state ringing_1
exit
2017.03.25 15:58:11 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:58:11 4: sip1[13662], SIP_invite -> ringing 2
2017.03.25 15:58:11 5: sip1[13662], telnet : set sip1 caller_state ringing_2
exit
2017.03.25 15:58:12 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:58:12 4: sip1[13662], SIP_invite -> ringing 3
2017.03.25 15:58:12 5: sip1[13662], telnet : set sip1 caller_state ringing_3
exit
2017.03.25 15:58:13 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:58:13 4: sip1[13662], SIP_invite -> ringing 4
2017.03.25 15:58:13 5: sip1[13662], telnet : set sip1 caller_state ringing_4
exit
2017.03.25 15:58:14 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:58:14 4: sip1[13662], SIP_invite -> ringing 5
2017.03.25 15:58:14 5: sip1[13662], telnet : set sip1 caller_state ringing_5
exit
2017.03.25 15:58:15 5: sip1[13662], telnet : get sip1 caller
2017.03.25 15:58:15 4: sip1[13662], SIP_invite block !
2017.03.25 15:58:15 5: sip1[13662], telnet : set sip1 caller_state rejected
exit
2017.03.25 15:58:20 4: sip1, message DTMF = ---#9
2017.03.25 15:58:20 5: sip1, call has pid 13683
2017.03.25 15:58:21 5: sip1[13683], my parent is 13546
2017.03.25 15:58:21 4: sip1[13683], register new expire : Sat Mar 25 16:03:21 2017
2017.03.25 15:58:21 5: sip1[13683], telnet : set sip1 state calling
exit
2017.03.25 15:58:21 4: sip1, CallStart DTMF : --#9
2017.03.25 15:58:21 5: sip1[13683], telnet : set sip1 call_state calling **621
exit
2017.03.25 15:58:21 4: sip1[13683], calling : **621
2017.03.25 15:58:25 5: sip1[13683], RTP done : OK
2017.03.25 15:58:25 5: sip1[13683], Stopvar : HASH(0x2bc1188)
2017.03.25 15:58:25 4: sip1, CALLDone -> sip1|1|ok|
2017.03.25 15:58:29 5: sip1, listen prozess 13662 found
2017.03.25 15:59:00 5: sip1[13662], my parent is 13546
2017.03.25 15:59:00 4: sip1[13662], register new expire : Sat Mar 25 16:04:00 2017
2017.03.25 15:59:00 5: sip1[13662], telnet : set sip1 state listen_wfp
exit
2017.03.25 15:59:11 4: sip1, Listen Kill PID : 13662
2017.03.25 15:59:11 1: Timeout for SIP_ListenStart reached, terminated process 13662
2017.03.25 15:59:11 4: sip1, Reset Listen done
2017.03.25 15:59:11 4: sip1, Listen new PID : 13700
2017.03.25 15:59:11 3: sip1[13700], my parent is 13546
2017.03.25 15:59:12 5: sip1[13700], my parent is 13546
2017.03.25 15:59:12 4: sip1[13700], register new expire : Sat Mar 25 16:04:12 2017
2017.03.25 15:59:12 5: sip1[13700], telnet : set sip1 state listen_wfp
exit
Die Variante mit sip_blocking funktioniert, die Rufe werden abgewiesen. Allerdings weiß ich nicht, auf was ich triggern könnte, denn caller_state bleibt nach dem ersten geblockten Anruf beständig auf dem Wert "blocking".
Gruß und schönes Wochenende noch!
Otto
Das mit dem FB Reset tut mir leid, meine hat sich da nicht so zickig benommen. Aber OK schieben wir das mal etwas nach hinten.
Das bei der Varinate 2 der caller_state nicht wechselt ist meine Schuld, ich habe da gestern ne Kleinigkeit vergessen :(
Wenn du es dir zutraust, such mal nach der Zeile 910 die sollte so aussehen :
SIP_telnet($hash, "set $name caller none\nset $name caller_state waiting\nexit\n") if ($i>$waittime);
ändere sie in
SIP_telnet($hash, "set $name caller none\nset $name caller_state waiting\nexit\n") if (($i>$waittime) || $block_it);
damit bekommst du sehr schnell einen Wechsel von blocking zu waiting.
Ich check heute noch ein Update ein, ich schrieb gestern das wenn du über sip_blocking gehst du sip_waittime recht klein machen kannst.
Die Version morgen früh wird sip_waittime als Verzögerungstimer zwichen dem caller_state blockiing und waiting nutzen.
D.h. wenn die Varinate oben zu schnell ist kannst du dann das Tempo des Wechsels selbst bestimmen.
Hallo,
also die Zeile habe ich geändert, das funktioniert. caller_state ändert sich und wird vom DOIF zuverlässig erkannt.
Das Problem mit der Fritzbox zeigt sich aber auch hier:
Der erste Anruf funktioniert wie erwartet, der Ruf wird abgewiesen, Fritzbox sagt "Declined (603).
Ab dem zweiten Anruf wird der von fhem zwar auch erkannt, DOIF wird getriggert und der Ruf geht raus. Das anrufende Telefon bleibt aber stumm, kein Rufzeichen, kein "besetzt" oder "abgewiesen", nichts. Im Log der Fritzbox steht auch nichts.
Gruß Otto
Nachtrag: nach einer längeren Wartezeit (auf jeden Fall mehrere Minuten) scheint die FB auch ohne Reboot wieder normal zu funktionieren.
Da stimmt aber bei noch etwas anderes nicht. 603 gibt es nur wenn manuell mit set <name> reject der Anruf abgewiesen wird.
Wenn sip_blocking den richtigen Abschnitt deiner Quellruf Nr hat sollte es 487 sein
Auch das Log mit verbose 4 sollte den Blocking Vorgang zeigen ala blocking NR found on xxx
Schon die 701, 486 oder 487 probiert?
Zitat von: Wzut am 25 März 2017, 19:22:12
Da stimmt aber bei noch etwas anderes nicht. 603 gibt es nur wenn manuell mit set <name> reject der Anruf abgewiesen wird.
Wenn sip_blocking den richtigen Abschnitt deiner Quellruf Nr hat sollte es 487 sein
Auch das Log mit verbose 4 sollte den Blocking Vorgang zeigen ala blocking NR found on xxx
Das mit dem 603 kann ich nicht reproduzieren, da habe ich anscheinend was verwechselt. Im Log der FB steht gar nichts.
Das fhem Logfile mit verbose 5 sieht so aus (wieder 2 Versuche, der erste verhält sich wie er sollte, beim zweiten bleibt das anrufende Telefon stumm):
2017.03.26 07:57:09 5: sip1[23504], SIP_filter : a:"Otto Büro" <sip:**2@fritz.box>;tag=8A6D54CF8E32B7FF | b:Net::SIP::Request=HASH(0x2d45310)
2017.03.26 07:57:09 5: sip1[23504], telnet : set sip1 caller Otto Büro sip:**2@fritz.box
exit
2017.03.26 07:57:09 5: sip1[23504], telnet : set sip1 caller_state blocking
exit
2017.03.26 07:57:09 4: sip1[23504], blocking Otto Büro sip:**2 found on .*
2017.03.26 07:57:09 5: sip1[23504], telnet : set sip1 caller none
set sip1 caller_state waiting
exit
2017.03.26 07:57:14 4: sip1, message DTMF = ---#9
2017.03.26 07:57:14 5: sip1, call has pid 23513
2017.03.26 07:57:15 5: sip1[23513], my parent is 23405
2017.03.26 07:57:15 4: sip1[23513], register new expire : Sun Mar 26 08:02:15 2017
2017.03.26 07:57:15 5: sip1[23513], telnet : set sip1 state calling
exit
2017.03.26 07:57:16 4: sip1, CallStart DTMF : --#9
2017.03.26 07:57:16 5: sip1[23513], telnet : set sip1 call_state calling **621
exit
2017.03.26 07:57:16 4: sip1[23513], calling : **621
2017.03.26 07:57:19 5: sip1, listen prozess 23504 found
2017.03.26 07:57:19 5: sip1[23513], RTP done : OK
2017.03.26 07:57:19 5: sip1[23513], Stopvar : HASH(0x256ac30)
2017.03.26 07:57:19 4: sip1, CALLDone -> sip1|1|ok|
2017.03.26 07:57:31 5: sip1[23504], SIP_filter : a:"Otto Büro" <sip:**2@fritz.box>;tag=7396D24776AA9D8B | b:Net::SIP::Request=HASH(0x2d4a4f8)
2017.03.26 07:57:31 5: sip1[23504], telnet : set sip1 caller Otto Büro sip:**2@fritz.box
exit
2017.03.26 07:57:31 5: sip1[23504], telnet : set sip1 caller_state blocking
exit
2017.03.26 07:57:31 4: sip1[23504], blocking Otto Büro sip:**2 found on .*
2017.03.26 07:57:31 5: sip1[23504], telnet : set sip1 caller none
set sip1 caller_state waiting
exit
2017.03.26 07:57:36 4: sip1, message DTMF = ---#9
2017.03.26 07:57:36 5: sip1, call has pid 23520
2017.03.26 07:57:37 5: sip1[23520], my parent is 23405
2017.03.26 07:57:37 4: sip1[23520], register new expire : Sun Mar 26 08:02:37 2017
2017.03.26 07:57:37 5: sip1[23520], telnet : set sip1 state calling
exit
2017.03.26 07:57:37 4: sip1, CallStart DTMF : --#9
2017.03.26 07:57:38 5: sip1[23520], telnet : set sip1 call_state calling **621
exit
2017.03.26 07:57:38 4: sip1[23520], calling : **621
2017.03.26 07:57:41 5: sip1[23520], RTP done : OK
2017.03.26 07:57:41 5: sip1[23520], Stopvar : HASH(0x256ac30)
2017.03.26 07:57:41 4: sip1, CALLDone -> sip1|1|ok|
hmm, da bin ich im Moment (fast) ratlos.
Ich arbeite bei meinen ganzen Test immer mit 2 SIP Clients/Devices. Der erste wickelt alle ankommenden Rufe ab und der zweite die ausgehenden.
Lege dir doch zum Test in deiner FB auch einen weiteren SIP User an und dann damit auch ein zweites Device in FHEM.
Gib dem zweiten Device aber eine Portnummer die bei dir frei ist (Bsp 5000). Das Device für ausgehende Anrufe bekommt sip_listen none.
Hallo,
mit 2 verschiedenen SIP Devices funktioniert es einwandfrei! Problem also zumindest umgangen.
An dieser Stelle nochmal Dir (und plin) vielen Dank für das nützliche Modul.
Gruß Otto
tja,
- ein FHEM Restart löst das Problem nicht
- ein Raspi-Restart löst das Problem auch nicht (also ist Net::SIP raus)
- also scheint sich die Fritzbox den Status des Clients zu merken
- übliche timeout-Ansätze (5 Min., 15 Min.) lösen das Problem auch nicht
Müssen wir den Call als Client evtl. explizit beenden, damit die Fritzbox das mitkriegt?
Ein $call->Bye an der richtigen Stelle (ich weiß, immer diese einfachen Fragen :-)? Korrektur: Wir sind noch in der invite-Phase. Wenn man den Anruf nicht annimmt kann man ihn auch nicht beenden.
Also schauen wir mal was uns Asterisk im Verbose-Modus verrät ...
Das Problem scheint durch einen Call ausgelöst zu werden. Die reine listen_wfp-Schleife mit einem set ... reject läuft problemlos.
Setzt man irgendwann über dasselbe Device einen Call ab, ist es aus.
Nach einem "register new expire : Sun Mar 26 15:30:35 2017" geht's dann wieder weiter.
Nun gut (oder auch nicht) kein Mensch würde sich zwei Telefone auf den Tisch stellen um eines nur zum anrufen zu nutzen und das andere um angerufen zu werden ...
Anyway, ich geh mal davon aus das nur wenige User das Bedürfnis haben das Modul innerhalb von FHEM für beide Richtungen zu nutzen.
Man könnte natürlich auch den listen Prozess mit Gewalt beenden bevor ein Call raus geht und danach automatisch wieder neu starten.
Mal schauen ob ich die nächste Woche dazu komme sowas als Testversion zu erstellen.
@knodono liest du noch mit und würdest du dann so eine geänderte Version nochmal durchtesten ?
Zitat@knodono liest du noch mit und würdest du dann so eine geänderte Version nochmal durchtesten ?
Ich lese mit und würde natürlich wieder testen.
Hallo Leute,
ich bekomme das Modul bei mir leider nicht zum ticken. "CallRegister: Failed with code 404" ist das Einzige, was bei einem "set call" passiert.
Fritzbox 7490 OS6.83 / Modulversion 1.48
Im Wiki steht ja, dass für den sip_user die Durchwahl (bei mir 624) angegeben werden soll. Das lässt die Fritz aber nicht zu, da hier min. 8 Stellen für User und Passwort gefordert sind. Kann das die Ursache sein? Es sieht für mich jedenfalls danach aus, das der Account nicht gefunden wird. Auch Versuche mit bewusst falschem Passwort führen nicht zu einer anderen Fehlermeldung.
Log (verbose 5):
2017.03.29 09:30:49 4: sip, calling **614, ringtime: 30 , no message
2017.03.29 09:30:49 5: sip, call has pid 6155
2017.03.29 09:30:49 4: sip, CALLDone -> sip|0|CallRegister: Failed with code 404
Hat vielleicht jemand irgendwelche Ideen?
Bitte poste mal ein vollständiges list von deinem SIP Device !
Ich kenn als User nur die dreistellige Nr, beginnt bei 620 mit dem ersten IP Device. Poste doch hier bitte mal welchen SIP User du da hinterlegt hast.
Da du keine Sig hast kann ich auch nur raten auf welcher Plattform du es probierst und welche OS Version, ebenso fehlt die Info welche Version von Net:Sip du einsetzt.
Als nächstes wenn du als sip_registrar fritz.box stehen hast versuche es statt dessen mal mit der IP der FB.
Hallo,
erst mal danke für die Antwort! Das scheint ja genau das Problem zu sein, dass ich in der Fritz keinen IP-Tel-Account mit einem 3-stelligen User anlegen kann. Interessanterweise ist bei den anderen IP-Accounts (Fritz!Fon) der User tatsächlich 3-stellig. Wie auch immer:
Mein Device-Listing:
Internals:
AC /usr/bin/sox
CALL sip|**614|30||
NAME sip
NOTIFYDEV txtToSpeech
NR 269
NTFY_ORDER 50-sip
STATE initialized
TYPE SIP
VERSION V1.48 / 25.03.17
Readings:
2017-03-29 09:30:49 call done
2017-03-29 09:30:49 call_state fail
2017-03-29 09:30:49 last_error CallRegister: Failed with code 404
2017-03-29 09:30:49 state initialized
Helper:
Attributes:
T2S_Device txtToSpeech
T2S_Timeout 15
audio_converter sox
room Internals
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_from sip:Fhem-700@192.168.123.253
sip_ip 192.168.123.56
sip_listen none
sip_port 5060
sip_registrar 192.168.123.253
sip_ringtime 3
sip_user Fhem-700
verbose 5
sip_user, sip_from, password und registrar habe ich in allen möglichen Kombinationen ausprobiert.
Mein Fhem (frischeste Version) läuft auf einem Pi3 unter Jessie; Net:Sip 0.809
BTW: Ich will das Modul z.Z. ausschließlich für ausgehende Calls einsetzen.
Hoffe, die Infos helfen irgendwie weiter...
Zitat von: Prostetnik am 29 März 2017, 13:15:23
Hallo,
erst mal danke für die Antwort! Das scheint ja genau das Problem zu sein, dass ich in der Fritz keinen IP-Tel-Account mit einem 3-stelligen User anlegen kann.
das kann ich aber nicht bestätigen.
bei meiner 7490 mit fw 06.80/83 ist die länge des users beliebig. nur das passwort muss mindestens 8 zeichen haben. sorry, ist doch so. aber doch eigentlich auch egal.
@Prostetnik,
was du da gepostet hast sieht erst einmal gut aus.
die IP 192.168.123.56 ist die IP deines FHEM ?
Ich denke du bist beim einrichten des SIP Telefons nach dieser Anleitung vorgegangen :
https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/42_IP-Telefon-an-FRITZ-Box-anmelden-und-einrichten/
zumindest wird dort auch geschrieben das der User jetzt 8 Zeichen haben muss (Punkt 3.6)
Auf jeden Fall must du diesen dann auch unter sip_user verwenden. (Punkt 4 Benutzername)
sip_from wird ist normal sip:nr@registrar , daher der default sip:620@fritz.box , würde ich wieder so setzen allerdings statt der 620 deine echte interne Rufnummer ohne die beiden **
Fehler 404 hatten wir schonmal auf Seite 7 -> https://forum.fhem.de/index.php/topic,67443.msg598436.html#msg598436
nur werde ich da nicht schlau draus wie er das wirklich gelöst hat.
Als Alternative kannst du natürlich noch versuchen das SIP Telefon statt als Telefon als Türsprechstelle einzurichten :
https://forum.fhem.de/index.php/topic,67443.msg594257.html#msg594257
Hallo Wzut und plin,
erstmal danke Euch für das tolle Modul, klappt wirklich super.
Zum Benutzernamen hätte ich auch noch was beizutragen:
Auch ich mußte in der Fritzbox einen längeren Benutzernamen eingeben. Ich denke, das hängt mit dem aktuellsten update 6.8 oder 6.81 zusammen. Bei meiner Fritzbox zuhause (die habe ich noch vor dem Update mit dem SIP-Modul eingerichtet) steht noch ein die 620 als Benutzer drin.
Obwohl die interne Nummer jetzt hier auf meiner zweiten Installation auch 620 für das SIP-Telefon ist, mußte ich bei
sip_from sip:Benutzername@fritz.box angeben.
Mit der internen Nummer hat es nicht funktioniert.
Liebe Grüße
Reinhard
THX Reinhard für die Info. @ plin, sollten wir unbedingt im Wiki festhalten
Hallo nochmal,
ich habe noch mal etwas herumprobiert. Wenn ich einen meiner vorhandenen Accounts verwende, bekomme ich tatsächlich erwartungsgemäß den Fehler 401 (Unauthorized) zurück. ist auch klar, kenne ja das Passwort nicht. Damit ist aber auch relativ klar, dass es nicht an meiner Umgebung liegt.
Könnte sein, dass AVM was geändert hat. Wäre nett, wenn jemand mit dem aktuellen FritzOS 6.83 das mal testen könnte. Also: neuen Account anlegen und dann probieren...
Als Türsprechanlage funktioniert es übrigens auch nicht. Gleicher Fehler.
Hallo Leute: Problem gelöst!!!
Ich kann es kaum glauben: Nur wenn man ein Passwort vergibt, das von der Box als mindestens "gut" eingestuft wird, funktioniert es! 8)
Manchmal ist es schon seltsam... ;-)
Hi,
Richtig mit dem Uodate muss ein Passwort mindestens 8 Zeichen haben!
Quelle: https://avm.de/service/downloads/update-news/download/show/18492/
"Neue und verbesserte Funktionen in FRITZ!OS 6.80 [...] Sicherheit: NEU - Das Kennwort für die Anmeldung eines IP-Telefons an der FRITZ!Box muss mindestens achtstellig sein. IP-Telefone mit kürzerem Kennwort werden beim Update deaktiviert."
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
@raspiLED
Ich hab mich vielleicht nicht klar genug ausgedrückt: Das mit den 8 Stellen war klar. Kürzere PW kann man gar nicht mehr eingeben. Es reicht aber nicht das es 8 Zeichen hat, sondern muss ein starkes PW sein. Sonst akzeptiert die Box es bei der Eingabe, aber die Registrierung des Moduls funktioniert trotzdem nicht (Fehler 404)
@Prostetnik, schön das es jetzt geht und danke für die Info wie man den Fehler 404 los wird,
das muß auch unbedingt mit ins Wiki
Zitat von: Prostetnik am 29 März 2017, 20:54:15
@raspiLED
Ich hab mich vielleicht nicht klar genug ausgedrückt: Das mit den 8 Stellen war klar. Kürzere PW kann man gar nicht mehr eingeben. Es reicht aber nicht das es 8 Zeichen hat, sondern muss ein starkes PW sein. Sonst akzeptiert die Box es bei der Eingabe, aber die Registrierung des Moduls funktioniert trotzdem nicht (Fehler 404)
Bei mir war es so, dass ich zuerst ein starkes PW mit Buchstaben, Ziffern und Sonderzeichen vergeben hatte. Damit bekam ich keine Verbindung zur Fritzbox. Dann habe ich ein PW ohne Sonderzeichen genommen - damit ging es. Die FB sagt bei beidem "Grün"/stark.
Ansonsten bin ich völlig begeistert, was aus diesem ursprünglich "nur anklingel"- Modul geworden ist. Vielen Dank an die Entwickler und Tester! Ich nutze es bisher für eine Benachrichtigung mit Ansage.
Übrigens hat bei mir die Net:SIP Version über "apt-get inst." nicht funktioniert (Debian 7). Dann hatte ich die Inst. per CPAN (ohne m) und auch per "wget -> entpacken -> make..." also "zu Fuß" probiert. Beide Male kam ich so zur derzeit neuesten Version, die auch prompt funktioniert hat.
Gruß
Frank
Nachdem sich bei mir die Werbeanrufe häufen, habe ich noch einen Wunsch:
init_media => $ua->rtp( 'recv_echo',undef,0 ),
Die Rufnummernsperre in der Fritzbox ist zwar ganz schön, es wird die Anrufer aber mehr nerven wenn sie ihr eigenes Echo hören :-)
Das wäre dann der dritte listen-Modus echo.
@Wzut
Jupp. Muss ins Wiki. Jetzt tut alles wie es (bei mir) soll. Auch die. Ansagen per textToSpeech. Alles gut i.M.
@fieddel
Sonderzeichen allgemein können es nicht sein. Ich benutze z.B. $ und %. Die machen keine Probleme. Vielleicht macht sich irgendjemand die Mühe und findet raus was an Zeichen geht und was nicht...
So Männer nicht das ihr denkt ich wäre hier eingeschlafen, am WE gibt es die nächste Version.
Eigentlich wollte ich am letzten WE nur mal schnell ein neues Attribut einführen um einen Listen Prozess zu beenden wenn ein aktiver Call raus soll. Beim Durchtesten ist mir aber aufgefallen das das vor einiger Zeit eingeführte Attribut sip_call_audio_delay leider nicht so funktioniert wie ich mir das ursprünglich gedacht hatte. Diese Korrektur hat mir wieder ein paar neue graue Haare eingebracht :( und euch eine neue Funktion :)
FIX
sip_call_audio_delay funktioniert nun wie es so
NEW
a. Neues Attribut sip_elbc (End Listen Befor Call ) Werte : no & yes , default : no
Mit diesem Attribut kann festgelegt werden ob ein laufender Listen Prozess beenden werden soll bevor ein Call raus geht.
Der Listen Prozess wird nach Ende des Call automatisch wieder neu gestartet. Dieses Verhalten entspricht quasi einem normalen Telefon das ja auch nicht gleichzeitig anrufen und angerufen werden kann.
b. neues Attribut sip_force_interval
Die Force Option (&) verwendete bisher fest eine Minute als Wiederholzeit.
Mit dem neuen Attribut kann eine beliebige Zeit in Sekunden vorgegeben werden.
c. Durch den Fix von sip_call_audio_delay musste ich mich mit den Problem beschäftigen mehr als ein Audiofile abzuspielen. Dies habe ich genutzt um eine repeat (Wiederhol) Funktion für Audiofiles/Textnachrichten einzubauen.
Aufruf bei einem Call :
set <name> call 08154711 30 ./tada.alaw *3 <--- der Stern * ist das Schlüsselwort , 3 die Anzahl der Wiederholungen
D.h. das Audiofile wird also in Summe 4 mal abgespielt 1 mal direkt plus 3 Wiederholungen.
oder set <name> call **611 20 !Hier ist dein FHEM Server *2 &
Aber ACHTUNG :
Wenn ihr diese Funktion nutzt behaltet die Gesamtdauer bzw. die Zeitüberwachung des Call im Auge. Durch die Wiederholungen läuft man relativ schnell in den Timeout wenn man die Zeit zu knapp wählt.
Viele Wiederholungen sind zwar schön, aber wenn man sich diese nicht wirklich bis ganz zu Ende anhört endet der Call auch mit einem Fehler da der Client ja seine Audioschleife nicht zu 100% erfolgreich abgearbeitet hat.
Das kann zur unschönen Überraschung werden falls der Call als Forcecall (&) gestartet wurde und man ständig durch das at wieder angerufen wird.
>Das kann zur unschönen Überraschung werden falls der Call als Forcecall (&) gestartet wurde und man ständig durch das at wieder angerufen wird.
Was natürlich wieder mal zu einer Idee führt: via DTMF ausschalten während der Call läuft (Ich weiß wie schlimm dieser Vorschlag ist ...)
Hallo Zusammen,
ich habe ein Problem, den richtigen PORT zu finden und einzutragen.
Meine Konfiguration sieht folgendermaßen aus:
ZitatReadings
call done 2017-03-31 12:18:26
call_state fail 2017-03-31 12:18:26
caller none 2017-03-31 12:17:44
caller_state waitting 2017-03-31 12:17:44
last_error ListenRegister: cannot open port 5070 or 5080 at 192.168.188.34: Address already in use 2017-03-31 12:23:21
state error 2017-03-31 12:23:21
Zitat
T2S_Device myT2S
audio_converter sox
room 00_Alarmanlage,Keller
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc no
sip_from sip:620@fritz.box
sip_ip 192.168.188.34
sip_listen dtmf
sip_port 5060
sip_registrar fritz.box
sip_ringtime 3
sip_user 620
verbose 5
wenn ich nun ein
set SIP_Telefon call 0123456789 30 !Hallo Martin
eingebe, erhalte ich .... nichts. :(
Ein Blick in den Log-File zeigt:
Zitat2017.03.31 12:30:03 1: SIP_Telefon :set repeat 0
2017.03.31 12:30:03 4: SIP_Telefon, wait_for_t2s file : cache/c7ec495110830339faa63a4d89bb9cb0.mp3
2017.03.31 12:30:03 4: SIP_Telefon, new T2S file cache/c7ec495110830339faa63a4d89bb9cb0.mp3
2017.03.31 12:30:03 5: SIP_Telefon, not converted using cache/c7ec495110830339faa63a4d89bb9cb0.alaw from cache
2017.03.31 12:30:03 1: SIP_Telefon, Test : SIP_Telefon call 0123456789 30 cache/c7ec495110830339faa63a4d89bb9cb0.alaw *0
2017.03.31 12:30:03 4: SIP_Telefon, message cache/c7ec495110830339faa63a4d89bb9cb0.alaw found
2017.03.31 12:30:03 4: SIP_Telefon, call -> SIP_Telefon|0123456789|30|cache/c7ec495110830339faa63a4d89bb9cb0.alaw|0|0
2017.03.31 12:30:03 5: SIP_Telefon, call has pid 24893
2017.03.31 12:30:03 4: SIP_Telefon[24893], my parent is 24729
2017.03.31 12:30:03 2: SIP_Telefon[24893], cannot open port 5060 at 192.168.188.34: Address already in use
2017.03.31 12:30:03 4: SIP_Telefon, CALLDone -> SIP_Telefon|0|CallRegister: cannot open port 5060 or 5070 at 192.168.188.34: Address already in use
2017.03.31 12:30:03 5: SIP_Telefon, fifo is empty
2017.03.31 12:30:03 5: SIP_Telefon, no elbc
2017.03.31 12:30:07 1: DEBUG>description :Conflict: terminated by other long poll or webhook:
Könnt Ihr mir einen Hinweis geben, was ich wohl falsch mache?
Ach ja. Wenn ich die FHEM-zugewiesene Rufnummer anrufe, kommt nach 2 Freizeichen ein schreckliches Geräusch, dass ich mit einem
#13
abstellen kann.
Der Log sieht wie folgt aus:
Zitat2017.03.31 12:33:52 1: DEBUG>description :Conflict: terminated by other long poll or webhook:
2017.03.31 12:33:54 5: SIP_Telefon, listen prozess 24277 found
2017.03.31 12:34:54 5: SIP_Telefon, listen prozess 24277 found
2017.03.31 12:34:57 1: DEBUG>description :Conflict: terminated by other long poll or webhook:
2017.03.31 12:35:18 5: SIP_Telefon[24277], SIP_filter : a:"Martin-72" <sip:0123456789@fritz.box>;tag=70966A5091694E7F | b:Net::SIP::Request=HASH(0x2a3a4c8)
2017.03.31 12:35:18 5: SIP_Telefon[24277], telnet : set SIP_Telefon caller Martin-72 sip:0123456789@fritz.box
exit
2017.03.31 12:35:18 4: SIP_Telefon[24277], cb_create : INVITE
2017.03.31 12:35:18 5: SIP_Telefon[24277], telnet : set SIP_Telefon caller_state ringing
exit
2017.03.31 12:35:21 5: SIP_Telefon[24277], telnet : set SIP_Telefon caller_state established
exit
2017.03.31 12:35:21 5: SIP_Telefon[24277], my parent is 11617
2017.03.31 12:35:21 4: SIP_Telefon[24277], register new expire : Fri Mar 31 12:40:21 2017
2017.03.31 12:35:21 5: SIP_Telefon[24277], telnet : set SIP_Telefon state listen_dtmf
exit
2017.03.31 12:35:21 5: SIP_Telefon[24277], telnet : set SIP_Telefon caller none
set SIP_Telefon caller_state waitting
exit
2017.03.31 12:35:34 5: SIP_Telefon[24277], SIP_bye : HASH(0x2a3a8d0)
2017.03.31 12:35:34 5: SIP_Telefon[24277], telnet : set SIP_Telefon caller none
set SIP_Telefon caller_state hangup
exit
Vielen Dank für Eure Hilfe.
Martin
Ach ja. Unmittelbar vor dem Post und den Versuchen dazu habe ich ein update gemacht. fheminfo sieht so aus:
ZitatFhem info:
Release : 5.8 FeatureLevel: 5.8
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
uniqueID : 664b8dd94e19251b2e031e1a44817582
upTime : 00:21:25
Defined modules:
Alarm : 1
CUL : 3
CUL_HM : 137
DOIF : 2
ECMD : 1
ECMDDevice : 1
FB_CALLLIST : 2
FB_CALLMONITOR : 1
FHEMWEB : 3
FileLog : 3
HMLAN : 1
HMinfo : 1
IPCAM : 1
IT : 14
PROPLANTA : 1
SIP : 1
SVG : 2
THRESHOLD : 1
TelegramBot : 1
Text2Speech : 1
Twilight : 1
allowed : 5
at : 10
autocreate : 1
dummy : 1
eventTypes : 1
monitoring : 1
notify : 20
readingsGroup : 2
telnet : 1
watchdog : 1
weblink : 4
Defined models per module:
CUL : CUL
CUL_HM : ActionDetector,CCU-FHEM,HM-CC-RT-DN,HM-Dis-WM55,HM-ES-PMSw1-Pl,HM-LC-Dim1T-Pl-3,HM-LC-SW4-DR,HM-LC-SW4-WM,HM-LC-Sw1PBU-FM,HM-PB-6-WM55,HM-RC-Key4-2,HM-SEC-SCo,HM-SEC-SD-2,HM-SEC-WDS-2,HM-TC-IT-WM-W-EU,virtual_1
IT : itswitch
Transmitting this information during an update: yes
You can change this via the global attribute sendStatistics
Was möchtest du denn in erster Linie Anrufe absetzen oder annehmen ?
setze dir entweder das neue Attribut sip_elbc auf yes oder setze sip_listen auf none.
Speichere mit fhem save und reboote dein System.
Das hässliche Geräusch ist gewollt bis du dir etwas nettes aussuchst :)
Zitat von: Wzut am 31 März 2017, 12:52:00
Was möchtest du denn in erster Linie Anrufe absetzen oder annehmen ?
setze dir entweder das neue Attribut sip_elbc auf yes oder setze sip_listen auf none.
Speichere mit fhem save und reboote dein System.
Hallo Wzut,
danke für Deine Bemühungen. Eigentlich werde ich beides wollen. Jetzt starte ich mit dem angerufen werden. :)
Also habe ich
sip_elbc auf yes gesetzt und
sip_listen auf dtmf gelassen...
Leider finde ich in specific help und in der commandref nicht wirklich ausführliche Hinweise was die Abkürzungen jeweils bedeuten... ;(
Ergebnis ist: kein Anruf und folgendes Log:
Zitat2017.03.31 14:14:35 1: SIP_Telefon :set repeat 0
2017.03.31 14:14:35 4: SIP_Telefon, wait_for_t2s file : cache/71ce4185214eb43202358604a63cdcab.mp3
2017.03.31 14:14:35 4: SIP_Telefon, new T2S file cache/71ce4185214eb43202358604a63cdcab.mp3
2017.03.31 14:14:35 5: SIP_Telefon, not converted using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2017.03.31 14:14:35 1: SIP_Telefon, Test : SIP_Telefon call 0123456789 30 cache/71ce4185214eb43202358604a63cdcab.alaw *0
2017.03.31 14:14:35 4: SIP_Telefon, message cache/71ce4185214eb43202358604a63cdcab.alaw found
2017.03.31 14:14:35 4: SIP_Telefon, call -> SIP_Telefon|023456789|30|cache/71ce4185214eb43202358604a63cdcab.alaw|0|0
2017.03.31 14:14:35 5: SIP_Telefon, call has pid 26000
2017.03.31 14:14:35 4: SIP_Telefon[26000], my parent is 25986
2017.03.31 14:14:35 2: SIP_Telefon[26000], cannot open port 5060 at 192.168.188.34: Address already in use
2017.03.31 14:14:35 4: SIP_Telefon, CALLDone -> SIP_Telefon|0|CallRegister: cannot open port 5060 or 5070 at 192.168.188.34: Address already in use
2017.03.31 14:14:35 5: SIP_Telefon, fifo is empty
2017.03.31 14:14:35 5: SIP_Telefon, no elbc
Zitat von: Wzut am 31 März 2017, 12:52:00Das hässliche Geräusch ist gewollt bis du dir etwas nettes aussuchst :)
Davon ging ich auch. Da es aber vielfach "try and error" ist bei mir, habe ich mir angewöhnt einzelne Schritte zu gehen und nicht gleich mit den Profis zum Marathon aufzubrechen... ;)
Martin
PS: um Hinweisen zu entgehen. Die zu wählende Rufnummer ist nicht die 0123456789. Aber ich habe die in diesem Format angegeben...
Ich fang mal mit der Doku an : https://wiki.fhem.de/wiki/SIP-Client hat einen sehr guten Stand.
Da steht noch nicht was elbc bedeutet da diese Funktion erst seite heute verfügbar ist, ich habe sie aber zwei Postings vor deinem ersten angekündigt und versucht zu erklären.
Ich lese aus deinen Logs das ein Listen Prozess gestartet werden konnte, ein Call jedoch nicht, da weder der primäre noch der sekundäre Port frei ist . D.h. der sekundäre wurde vermutlich durch den laufenden Listen Prozess belegt, sollte aber dem Call zur Verfügung stehen wenn sip_elbc auf yes ist. Noch besser für die ersten Test wäre allerdings du setzt sip_listen erst einmal auf none und nicht auf dtmf ! Und bitte reboote dein System, ein fhem shutdown restart alleine reicht nicht, denn bei dir scheinen einige Zombies im System zu sein die die Ports noch blockieren. Vor dem reboot kannst ja mal auf der shell mit "ps x | grep fhem" nachschauen wieviele das aktuell sind.
Kurze Rückmeldung: Gerade mal mit der neuen version probiert. Audiodelay geht jetzt, die Wiederholung bei t2s aber leider nicht.
Zitat von: Prostetnik am 31 März 2017, 15:03:00
die Wiederholung bei t2s aber leider nicht.
Log mit verbose 5 ?
Sorry:
2017.03.31 16:25:44 4: sip, msg will be repeat 3 times
2017.03.31 16:25:44 1: sip :set repeat 3
2017.03.31 16:25:44 4: sip, wait_for_t2s file : cache/23d0bcad6eafd75ed9f2c664c60d1fa1.mp3
2017.03.31 16:25:44 4: sip, new T2S file cache/23d0bcad6eafd75ed9f2c664c60d1fa1.mp3
2017.03.31 16:25:44 5: sip, not converted using cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw from cache
2017.03.31 16:25:44 1: sip, Test : sip call **614 30 cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw *3
2017.03.31 16:25:44 4: sip, message cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw found
2017.03.31 16:25:44 4: sip, call -> sip|**614|30|cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw|0|0
2017.03.31 16:25:44 5: sip, call has pid 12146
2017.03.31 16:25:44 4: sip[12146], my parent is 4056
2017.03.31 16:25:45 4: sip[12146], register new expire : Fri Mar 31 16:30:45 2017
2017.03.31 16:25:45 5: sip[12146], telnet : set sip state calling exit
2017.03.31 16:25:45 4: sip[12146], CallStart with 2 files - first file : CODE(0x2abe870) - PCMA/8000 , repeat 0
2017.03.31 16:25:45 4: sip[12146], calling : **614
2017.03.31 16:25:45 5: sip[12146], telnet : set sip call_state calling **614 exit
2017.03.31 16:25:45 4: sip[12146], cb_final - status : FAIL - final : 481
2017.03.31 16:25:45 5: sip[12146], telnet : set sip call_state ringing exit
2017.03.31 16:25:48 4: sip[12146], cb_final - status : OK
2017.03.31 16:25:48 4: sip[12146], call established
2017.03.31 16:25:48 5: sip[12146], telnet : set sip call_state established exit
2017.03.31 16:25:49 5: sip[12146], 0. Ende des ersten Loops
2017.03.31 16:25:49 5: sip[12146], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4c04520)
2017.03.31 16:25:49 5: sip[12146], 2. fi : 0
2017.03.31 16:25:49 5: sip[12146], 3. timeout : 0
2017.03.31 16:25:49 4: sip[12146], next file : cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw
2017.03.31 16:25:49 4: sip[12146], cb_final - status : OK
2017.03.31 16:25:50 5: sip[12146], RTP done : Net::SIP::Simple::Call=HASH(0x4c04520)
2017.03.31 16:25:50 5: sip[12146], Timeout : 0
2017.03.31 16:25:50 4: sip, CALLDone -> sip|1|ok
2017.03.31 16:25:50 5: sip, fifo is empty
2017.03.31 16:25:50 5: sip, no elbc
Zitat2017.03.31 16:25:44 1: sip, Test : sip call **614 30 cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw *3
2017.03.31 16:25:44 4: sip, message cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw found
2017.03.31 16:25:44 4: sip, call -> sip|**614|30|cache/23d0bcad6eafd75ed9f2c664c60d1fa1.alaw|0|0
hmm , innerhalb von zwei Log Einträgen ist aus repeat 3 eine 0 geworden :(
Ist mir auch schon aufgefallen... ;-)
Der Fehler ist gefunden und tritt nur bei Textnachrichten auf und auch nur wenn diese ohne Force Option angegeben werden.
Ist im nächsten Update gefixt
Cool! :)
Ich stand heute vor dem Problem einen bestimmten Call eine andere Force Intervall Zeit mit zu geben als default 60 Sekunden oder den Wert von sip_force_interval.
Lösung : neue Version (1.52) , dem Force (&) kann nun eine beliebige Zeit in Sekunden angehängt werden.
Bsp :
set call **611 30 !Das ist ein Test & <-- wird im Fehlerfall nach 60 Sekunden wiederholt oder nach sip_force_interval wenn vorhanden.
set call **611 30 !Das ist ein Test &300 <-- wiederholt im Fehlerfall nach 5 Minuten egal welchen Wert sip_force_interval hat.
Hallo Wzut,
ZitatAufruf bei einem Call :
set <name> call 08154711 30 ./tada.alaw *3 <--- der Stern * ist das Schlüsselwort , 3 die Anzahl der Wiederholungen
D.h. das Audiofile wird also in Summe 4 mal abgespielt 1 mal direkt plus 3 Wiederholungen.
oder set <name> call **611 20 !Hier ist dein FHEM Server *2 &
Ich habe folgendes Problem:
Wenn ich "call **611 20 !Hier ist dein FHEM Server *2 &" absetze, liest mir die Tante vom Amt :D den Text vor mit "Stern Zwei".
Ich habe die Version: "96_SIP.pm 13872 2017-04-01 17:28:10Z Wzut" im Einsatz.
Ich verstehe die Beschreibung so, daß ich mit "*2" den Text zweimal (dreimal) vorlesen lassen kann.
Habe ich einen Fehler in der Funktion gefunden oder in meinem Verständnis?
Viele Grüße
Rainer
Nein das siehst du schon richtig
Teste doch bitte nochmal mit der V1.52 (die sollte ja in knapp einer halben Stunde ausgeliefert werden)
Hallo Wzut,
ein Traum, das Problem ist beseitigt ;D.
Danke und viele Grüße
Rainer
ja für dich ein Traum, für mich an manchen Tagen eher ein Alptraum ....
Ich habe meine eigene ToDo Liste nun fast abgearbeitet, es gibt nur noch einen Punkt der mich etwas stört :
Wie ich vor ein paar Tagen geschrieben habe muss man bei Wiederholungen (mit *) warten bis alle Wiederholungen abgespielt wurden und erst danach auflegen, sonst ist der Client der Meinung der Anruf sei nicht erfolgreich gewesen.
Das mag aus seiner Sicht stimmen, ich dagegen bin der Meinung wenn ich die Nachricht einmal komplett gehört habe ist die Information bei mir erfolgreich angekommen und ich muß mir jetzt nicht noch unbedingt fünf Wiederholungen anhören.
Mal schauen ob ich das mit einem zusätzlichen Attribut an/aus schalten kann.
Hallo Wzut,
mach langsam! Ein durch Alpträume verschreckter Developer hilft uns nichts :D. Nur ein ausgeschlafener Developer ;D.
Du hast hier schon eine ordentliche Geschwindigkeit vorgelegt! Alle Achtung.
Viele Grüße
Rainer
Das Tempo war reines Glück. Meine Termine & Verpflichtungen in den nächsten Wochen und Monaten verlangen leider das ich FHEM seitig von Warp auf Impulsantrieb runterschalten muß.
Anyway, ich denke für das Problem der Wiederholungen habe ich eine brauchbare Lösung gefunden.
Ab der nächsten Version darf die Wiederholungsanzahl auch negativ sein.
Bsp : set call **611 30 !Das ist eine Test *-2
Die Nachricht wird zwar genau wie bei *2 dreimal abgespielt, allerdings erlaubt das - vor der 2 das die Nachricht nur einmal vollständig übertragen werden muß. Der call_state nach dem Call hätte dann z.B. den Wert "ok peer hangup",
also eine Mischung aus OK und eigentlichem Fehler. Um das alles in einem notify/DOIF besser auswerten zu können gibt es auch ein neues Reading : call_success -> mögliche Werte 0 oder 1
0 = call_state ist ungleich ok , 1 = call_state ist gleich ok
Auf das Repeat Beispiel übertragen bedeutet das eine 0 wenn die Wiederholungszahl positiv ist und die tatsächliche Anzahl nicht erreicht wurde, aber eine 1 bei call_state "ok peer hangup"
Neuerdings erscheint folgende Meldung:
ZitatCallRegister: this is the IP address of your registrar , not your FHEM !
Nun läuft auf meinem FHEM-Server u.a. auch Asterisk. Lässt sich da was machen?
Gruß Jens
ja da fallen mir spontan mehere Optionen ein:
a. kommentiere die Zeile 310 (und auch vllt. auch noch 311) in 96_SIP.pm aus.
b. damit sip_ip ungleich sip_registrar ist trage bei einem deine IP ein und bei dem anderen den Hostnamen.
Vielen Dank!
Lösung a funktionierte sofort.
Hab mich aber trotzdem für Lösung b entschieden. In der Konstellation sip_ip=hostname und sip_registrar=IP funktioniert es jetzt auch. Andersherum lief es nicht.
Gruß Jens :)
Stichwort
WerbeanrufeIm Wiki hatte ich ja angeregt über die Erfahrungen mit dem Modus listen_
echo hier im Thread zu berichten.
Meine Vermutung: Zur Effizienzsteigerung in den Callcentern werden Wählcomputer eingesetzt, die parallel mehrere Rufnummern anwählen. Geht ein Angerufener dran wird er zu einem Agenten durchgestellt. Wenn die Caller-Id in der Fritzbox gesperrt wird versucht es der eine oder andere Wählcomputer trotzdem durchaus 10 Mal in 2 Minuten.
Ich habe mit dem SIP-Client folgendes getestet
- listen_echo: Das Vorspielen des eigenen Tons wird von den Callcentern anscheinend nicht als gewollte Aktion verstanden, sondern vermutlich als technischer Effekt. Jedenfalls riefen mich (bzw. meinen SIP-Client) 2 Callcenter danach noch mal an.
- listen_wfp: Nachdem ich auf den Text "Willkommen in der Warteschleife für Werbeanrufer" (3 Mal hintereinander vorgelesen) umgestellt hatte ging es dann deutlich besser. Das Callcenter ruft einmal an, versteht die Nachricht und streicht meine Rufnummer von deren Liste.
:)
Hallo
Ich habe beim anlegen des Moduls Fehler 110
Internals:
.oldstate error
.reset 0
.triggerUsed 0
AC /usr/bin/sox
LPID 18979
NAME anrufe
NOTIFYDEV MyTTS
NR 781
NTFY_ORDER 50-anrufe
STATE error
TYPE SIP
VERSION V1.54 / 07.04.17
Readings:
2017-05-06 20:31:08 call done
2017-05-06 20:31:08 call_state fail
2017-05-06 20:31:08 call_success 0
2017-05-06 20:31:08 call_time 62.071585893631
2017-05-06 20:32:10 last_error ListenRegister: Failed with error 110
2017-05-06 20:32:10 state error
Helper:
Listen_pid:
abortArg
abortFn
arg anrufe
bc_pid 3301
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 18979
timeout
Attributes:
T2S_Device MyTTS
audio_converter sox
room flur
sip_call_audio_delay 0.5
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:inesa394@fritz.box
sip_ip 192.168.178.108
sip_listen dtmf
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 5
sip_user inesa394
verbose 5
User ist in Fritzbox angelegt und Passwort wurde gesetzt
Was sagt mir Fehler 110
Zitat von: inesa394 am 06 Mai 2017, 20:45:44
Was sagt mir Fehler 110
Nun, mir zumindest nichts. Die Meldung kommt irgendwo aus dem Net::SIP Packet. ( In meinem gibt es keine 110 )
D.h. du wirst mehr Infos liefern müssen :
Auf welchem System nutzt du das Modul , welche Version von Net::SIP ?
Und auch bitte mal den passenden Log Abschnitt posten mit verbose 5
Net:Sip habe ich diese also die letzte aktuelle wie er sagt
(no description)
S/SU/SULLR/Net-SIP-0.809.tar.gz
/usr/local/share/perl/5.24.1/Net/SIP.pm
Installed: 0.809
CPAN: 0.809 up to date
Steffen Ullrich (SULLR)
Steffen_Ullrich@genua.de
System ist bei mir Ubuntu 17.04 aktuelles System letzte woche aktualisiert
Auf der FritzBox 7490 ist Firmware 6.83 drauf
dort habe ich unter Telefonie User Inesa394 angelegt
mit Passwort "Almigurt111" wird wieder geändert
Außerdem habe ich proberweise mal ein zweites Gerät in der Fritz und Fhem angelegt
mit dem gleichen Fehler.
Es hat ja mal funktioniert nur kann ich nicht mehr sagen wann das war.
Größere Änderungen waren Fritzbox auf 6.83 und ubuntu auf 17.04
in dieser Zeit.
Hier noch mein log
2017.05.07 13:13:02 5: anrufe, fifo is empty
2017.05.07 13:13:02 5: anrufe, no elbc
2017.05.07 13:16:13 4: anrufe, wait_for_t2s file : cache/1bb4733521b9a03a164427d512018a0c.mp3
2017.05.07 13:16:13 4: anrufe, new T2S file cache/1bb4733521b9a03a164427d512018a0c.mp3
2017.05.07 13:16:13 5: anrufe, /usr/bin/sox cache/1bb4733521b9a03a164427d512018a0c.mp3 -t raw -r 8000 -c 1 -e a-law cache/1bb4733521b9a03a164427d512018a0c.alaw
2017.05.07 13:16:14 4: anrufe, audio file cache/1bb4733521b9a03a164427d512018a0c.alaw found
2017.05.07 13:16:14 4: anrufe, anrufe|9399320|20|cache/1bb4733521b9a03a164427d512018a0c.alaw|0
2017.05.07 13:16:14 4: anrufe, call -> anrufe|xxxxxxxx|20|cache/1bb4733521b9a03a164427d512018a0c.alaw|0|0
2017.05.07 13:16:14 5: anrufe, call has pid 2886
2017.05.07 13:16:14 4: anrufe[2886], my parent is 1259
2017.05.07 13:17:18 4: anrufe, CALLDone -> anrufe|0|CallRegister: Failed with error 110
2017.05.07 13:17:18 5: anrufe, fifo is empty
2017.05.07 13:17:18 5: anrufe, no elbc
2017.05.07 13:28:49 2: anrufe, cant find listen prozess 2446 in process list !
2017.05.07 13:28:50 5: anrufe, ListenDone -> anrufe|ListenRegister: Failed with error 110
2017.05.07 13:28:50 3: anrufe, listen error -> ListenRegister: Failed with error 110
2017.05.07 13:28:52 4: anrufe, Listen new PID : 2669
2017.05.07 13:28:52 4: anrufe[2669], my parent is 1303
2017.05.07 13:29:53 4: anrufe, Listen new PID : 2669
2017.05.07 13:29:56 5: anrufe, ListenDone -> anrufe|ListenRegister: Failed with error 110
2017.05.07 13:29:56 3: anrufe, listen error -> ListenRegister: Failed with error 110
2017.05.07 13:30:28 4: anrufe, wait_for_t2s file : cache/cb7162b073b1717265d4e796bc02ebe5.mp3
2017.05.07 13:30:28 4: anrufe, new T2S file cache/cb7162b073b1717265d4e796bc02ebe5.mp3
2017.05.07 13:30:28 5: anrufe, /usr/bin/sox cache/cb7162b073b1717265d4e796bc02ebe5.mp3 -t raw -r 8000 -c 1 -e a-law cache/cb7162b073b1717265d4e796bc02ebe5.alaw
2017.05.07 13:30:29 4: anrufe, audio file cache/cb7162b073b1717265d4e796bc02ebe5.alaw found
2017.05.07 13:30:29 4: anrufe, anrufe|93900000|30|cache/cb7162b073b1717265d4e796bc02ebe5.alaw|0
2017.05.07 13:30:29 4: anrufe, call -> anrufe|9399320|30|cache/cb7162b073b1717265d4e796bc02ebe5.alaw|0|0
2017.05.07 13:30:29 5: anrufe, call has pid 2881
2017.05.07 13:30:29 4: anrufe[2881], my parent is 1303
2017.05.07 13:31:33 5: anrufe, fifo is empty
2017.05.07 13:31:33 5: anrufe, no elbc
Danke Ines
hmm, ich habe das Net::SIP 0.809 durchsucht, auch da wird der Fehler 110 nicht direkt erzeugt, kann daher nur bedeuten er kommt direkt von der Fritte.
Wenn du hier auf Seite 15 zurück gehst gab es mit den neuen FB Versionen ab 6.8x einige Probleme, allerdings hatten wir damals 400er Fehlermeldungen.
Aber auf jeden Fall must du inzwischen einen User mit 8 Zeichen verwenden -> inesa394 sollte also eigentlich passen.
Passwort "Almigurt111" : Wird das als stark und grün in der FB angezeigt ? ( Sonderzeichen hat es keine, also kann es das auch nicht sein )
Bekommst du eine andere Fehlernummer , wenn du
a. sip_user inesa394 auf einen User setzt den es in der FB gar nicht gibt ?
b. dem User inesa394 als PW im Modul ein falsches PW setzt (set anrufe password irgendetwas) ?
Edit habe es nun endlich mit vielen Versuchen auch geschafft :
2017.05.07 19:36:11 4: mySIP, CALLDone -> mySIP|0|CallRegister: Failed with error 110
ich habe als sip_registrar eine Adresse aus meinem Netz verwendet die zwar erreichbar ist aber keinen SIP Dienst zur Verfügung stellt.
ich hatte auch versucht mit falschen passwort oder registrar der Fehler bleibt
zumindest bei mir immer der 110
sip_registrar ist bei mir 192.168.178.1 die ip der fritte
Was könnte denn da rein damit es paßt ?
Das passwort wird von der Fritz als gut bewertet
Ich habe dann heute noch mal NET:SIP per cpan gelöscht und
per apt-get eine 0.808 eingespielt der Fehler ist leider geblieben.
Ines
Wenn ich sip_listen auf wfp stelle ist der fehler wegund ich werde angerufen...wieder auf dtmf zurück und der Fehler
ist wieder da
sorry, aber das kann ich leider ganz und gar nicht nachvollziehen. Es gibt nur einen Abschnitt Register und da muss so wohl dtmf als auch wfp vorher durch. D.h. dem Abschnitt Register ist es völlig wurscht auf was Listen später wartet.
Aber ok, brauchst du denn überhaupt einen aktiven Listen Prozess ?
In deinem Log sehe ich das du u.a. TTS Nachrichten versendest. Wenn das deine primäre Anwendung des Moduls ist, würde ich sip_listen auf none stellen. Damit ist zwar das eigentliche Rätsel nicht gelöst, aber zumindest hättest du ein brauchbares Provisorium.
Das Net::SIP Paket hat ein internes Debugging, ich muss mal schauen ob man das zur Fehlersuche nicht zusätzlich mit nutzen kann.
Siehe hier
Internals:
.oldstate listen_wfp
.reset 0
AC /usr/bin/sox
LPID 25547
NAME anrufe
NOTIFYDEV MyTTS
NR 760
NTFY_ORDER 50-anrufe
STATE listen_wfp
TYPE SIP
VERSION V1.54 / 07.04.17
Readings:
2017-05-08 13:26:24 call done
2017-05-08 13:26:24 call_state ok
2017-05-08 13:26:24 call_success 1
2017-05-08 13:26:24 call_time 17.0946588516235
2017-05-07 18:17:17 last_error CallRegister: Failed with error 110
2017-05-08 13:28:54 state listen_wfp
Helper:
Listen_pid:
abortArg
abortFn
arg anrufe
bc_pid 8737
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 25547
timeout
Attributes:
T2S_Device MyTTS
audio_converter sox
room flur
sip_call_audio_delay 0.5
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:inesa394@fritz.box
sip_ip 192.168.178.108
sip_listen wfp
sip_port 5060
sip_registrar fritz.box
sip_ringtime 3
sip_user inesa394
verbose 5
Zur zeit ist meine primäre anwendung tts Nachrichten zu versenden,wollte aber später etwas mit dtmf spielen ist jetzt aber nicht
so wichtig hauptsache tts geht wieder. :)
Übrigens ist dieses Device in der Fritzbox als Türsprechanlage eingerichtet weil ich das hier im Thread so rausgelesen hatte.
Ines
OK, ich bin inzwischen auch etwas schlauer geworden. Die Gesuchte 110 werden wir niemals finden da das keine SIP Protokoll Fehler Nr ist sondern die I/O Fehlercodes ( Kennt noch jemand aus der DOS Zeit die Nr 2 "Datei nicht gefunden" ? )
Ich muss mal schauen die in einem der nächsten Updates als Klartext auszugeben. Wer es vorher genau wissen will :
sudo apt-get install errno
und dann einfach auf der Konsole "errno 110"
Da ich inzwischen auch die aktuelle FW auf der Fritte habe kann ich das mit der Türsprechstelle auch einmal testen.
Zwingend ist es nicht, aber als Türsprechstelle kann man auf ein Fritz DECT Phone schön einfach eine Grafik als Hintergrund beim Rufaufbau setzen.
Ich habe es jetzt hinbekommen lag an der Fritz dort kann man unter Telefon/Eigene Rufnummern/bearbeiten/andere Anbieter/dtmf übertragung die richtige Einstellung setzen damit es funktioniert. Wird dann autmatisch mit übernommen wenn man auf ok geht. :)
Hallo zusammen,
ich habe das SIP-Modul bei mir aktiviert und es funktioniert auch soweit. Aber was muss ich unter call angeben, wenn ich Tastencodes der Fritzbox senden will? z. B. für #883** (Wecker 3 ein)
Oder geht das grundsätzlich nicht? Im Thread bin ich dazu nicht fündig geworden, oder ich hab's übersehen.
Gruß Heiko
schau mal ins Wiki rein: https://wiki.fhem.de/wiki/SIP-Client#Anwendungsbeispiele
Hallo plin,
das habe ich schon gelesen, aber bringt mich nicht weiter. Wenn ich den Wecker aktivieren oder deaktivieren will, habe ich keine Zielrufnummer, oder stehe ich auf dem Schlauch?
Was habe ich bereits ergebnislos versucht:
set mySip call **612 10 -#883** => NSt 612 wird angerufen, aber der Wecker wird nicht aktiviert
set mySip call #883** => call_state canceled Logfile: Cmd: >{SIP_CALLDone('mySIP|1|canceled')}<
set mySip call -#883** => call_state canceled Logfile: Cmd: >{SIP_CALLDone('mySIP|1|canceled')}<
Vielleicht hätte jemand den entscheidenden Tipp für mich. Danke schön.
Gruß Heiko
Zitat von: matschig4711 am 25 Mai 2017, 21:23:49
Wenn ich den Wecker aktivieren oder deaktivieren will, habe ich keine Zielrufnummer, oder stehe ich auf dem Schlauch?
Ich war bisher der Meinung Tastenkommandos direkt an die FB schicken geht nur mit einem analogen oder ISDN/DECT Telefon.
Der erste Stolperstein dürfte schon mal sein das die eigentliche Zielrufnummern dann ja fehlt. Wenn ich am WE etwas Zeit finde werde ich das mal mit dem FritzPhone auf dem Smartphone testen. Wenn das nicht klappt sehe ich schwarz es mit dem SIP Modul zu machen.
Oh, vielen Dank. Vielleicht findet sich eine Lösung. 8)
Ergänzung:
Ich habe für mich eine Lösung gefunden. Über das SIP-Modul kam ich leider nicht weiter. Daher habe ich das FRITZBOX-Modul bemüht. Dort kann man TR064 nutzen. So kann ich den Wecker 3 einschalten:
get Fritzbox tr064Command X_VoIP:1 x_voip X_AVM-DE_DialNumber NewX_AVM-DE_PhoneNumber #883**
und auch wieder ausschalten: get Fritzbox tr064Command X_VoIP:1 x_voip X_AVM-DE_DialNumber NewX_AVM-DE_PhoneNumber #883#
Vielleicht hilft das auch jemand anderem, denn ein einfaches "set Fritzbox call #883**" über das FRITZBOX-Modul brachte mich auch nicht weiter.
Hallo,
ich habe seit einigen Tagen folgende Problemstellung:
Das FHEM ist nicht mehr erreichbar. Nach einem "FHEM STOP" und einem "FHEM Start" läuft es wieder.
Das Problem trat auf, nachdem ich das Raspbian und FHEM auf den neuesten Stand gebracht habe.
Folgende Logeinträge sind noch vorhanden:
2017.05.26 05:27:04 1: sendEmail returned: May 26 05:27:04 raspberrypi sendEmail[14411]: Email was sent successfully!
Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.
2017.05.26 05:29:08 1: FritzSIP[2292], can´t find my parent 2115 in process list !
Died at ./FHEM/96_SIP.pm line 353.
Hinweis: Zu dieser Uhrzeit bekam ich eine neue IP Adresse (Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.)
Hat jemand eine Idee, an was dies liegen kann?
Viele Grüße
Rainer
Zitat von: Heuberg am 26 Mai 2017, 08:25:08
Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.
Keine Ahnung welches Modul Carp.pm nutzt, aber vermutlich führt der Fehler dazu das dein FHEM Hauptprozess stirbt !
Als Folge davon dann :
Zitat von: Heuberg am 26 Mai 2017, 08:25:08
2017.05.26 05:29:08 1: FritzSIP[2292], can´t find my parent 2115 in process list !
Died at ./FHEM/96_SIP.pm line 353.
Der (Kind) Listen Prozess 2292 findet seinen Haupt (Eltern) Prozess 2115 nicht mehr (vermutlich weil er gerade wegen Carp gestorben ist) und beendet sich nun selbst, da er als armes Waisenkind nutzlos geworden ist.
Hallo,
die Ursache für den Fehler:
ZitatBizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.
ist gefunden. Es liegt am Modul 32_mailcheck.pm.
Identisch:
https://forum.fhem.de/index.php/topic,47457.msg391777.html#msg391777 (https://forum.fhem.de/index.php/topic,47457.msg391777.html#msg391777)
Viele Grüße
Rainer
Zitat von: matschig4711 am 26 Mai 2017, 07:56:48
Vielleicht hilft das auch jemand anderem, denn ein einfaches "set Fritzbox call #883**" über das FRITZBOX-Modul brachte mich auch nicht weiter.
Ja, das hatte ich befürchtet. Mit der Smartphone App klappt es auch nicht den Wecker so ein oder aus zu schalten.
D.h. Das SIP Modul hat kein Problem mit den Rufnummern #881** oder #881# , die FB mag das aber wohl nur von Festnetz oder DECT Telefonen :(
Hallo, ich wundere mich warum bei mir die Anrufe machmal nach 12 s beendet werden und ok zurückgemeldet wird, obwohl die Textmeldung 2mal wiederholt werden soll. der angerufene hört nur noch das Anrufende wenn er schnell genug dran geht:
2017.06.09 21:04:18 3: mySIP, force call
2017.06.09 21:04:18 4: mySIP, msg will be repeat -2 times
2017.06.09 21:04:18 4: mySIP, audio file cache/b478fa7d0c514de07c2fa071a807ab88.alaw found
2017.06.09 21:04:18 4: mySIP, mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2
2017.06.09 21:04:18 4: mySIP, call -> mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2|&60
2017.06.09 21:04:18 5: mySIP, call has pid 1744
2017.06.09 21:04:18 4: mySIP[1744], my parent is 10863
2017.06.09 21:04:18 4: mySIP[1744], using random port 44425
2017.06.09 21:04:18 4: mySIP[1744], register new expire : Fri Jun 9 21:09:18 2017
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP state calling exit
2017.06.09 21:04:18 4: mySIP[1744], CallStart with 3 files - first file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw - PCMA/8000 , repeat 2
2017.06.09 21:04:18 4: mySIP[1744], calling : xxxx
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state calling xxxx exit
2017.06.09 21:04:18 4: mySIP[1744], cb_final - status : FAIL - final : 481
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state ringing exit
2017.06.09 21:04:25 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:25 4: mySIP[1744], call established
2017.06.09 21:04:25 5: mySIP[1744], telnet : set mySIP call_state established exit
2017.06.09 21:04:26 5: mySIP[1744], 0. Ende des ersten Loops
2017.06.09 21:04:26 5: mySIP[1744], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:26 5: mySIP[1744], 2. fi : 0
2017.06.09 21:04:26 5: mySIP[1744], 3. timeout : 0
2017.06.09 21:04:26 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:26 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:28 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:28 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:28 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:30 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], RTP done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], Timeout : 0
2017.06.09 21:04:30 5: mySIP[1744], while : 2
2017.06.09 21:04:30 5: mySIP[1744], Status : OK
2017.06.09 21:04:30 4: mySIP, CALLDone -> mySIP|1|ok
2017.06.09 21:04:30 5: mySIP, fifo is empty
2017.06.09 21:04:30 5: mySIP, no elbc
Hat jemand ne idee?
Hallo,
Ich habe mit dem Sip-Client eine Funktion realisiert, dass das Klingeln der Türe auch das Telefon klingeln lässt. schalten. Nun habe ich noch realisiert, dass ich durch Anrufen des Sip-Clients die Funktion ein und ausschalte indem ich über einen notify einen Dummy schalte. Was mir nun noch fehlt ist ein Feedback, ob ich gerade ein oder ausgeschalten habe. Das würde ich gerne per Text2Speech realisieren. Kann mir jemand einen Hinweis geben, wie ich das realisieren könnten, dass der SIP-Client beim angerufen werden abhängig vom Status eines Dummys etwas anders per Text2Speech antwortet?
Vielen Dank schon mal
Florian
@Tomk, dein Log sieht gut aus und lässt sich in fünf Abschnitte einteilen :
1. Schritt , Übergabe der Parameter und klingeln des Telefons
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state ringing exit
2. Schritt , es klingelte 7 Sekunden dann wurde der Hörer abgenommen :
2017.06.09 21:04:25 5: mySIP[1744], telnet : set mySIP call_state established exit
die nächsten drei Schritte sind in 5 Sekunden durch und dort wird 3x mal deine Audio Datei abgespielt :
cache/b478fa7d0c514de07c2fa071a807ab88.alaw
D.h. alles wie es sein soll. Wenn du allerdings die Nachricht nur bei der zweiten Wiederholung und davon auch nur das Ende hörst, dann vergeht dir zuviel Zeit vom abheben des Hörers bis zum heranführen ans Ohr. Abhilfe laut Wiki -> https://wiki.fhem.de/wiki/SIP-Client
Zitatsip_call_audio_delay
Damit wird festgelegt wie lange bei einem Call mit dem abspielen des Audiofiles gewartet werden soll nachdem man den Anruf angenommen hat. Gültige Werte sind 0 - 3 in 0.25 (1/4) Sekunden Schritten.
@Wzut: danke für die Erklärung. Ich finde auch das das log file sehr gut aussieht, allerdings passt das Verhalten nicht zu dem was ich erlebe. Ich habe den Hörer gar nicht rechtzeitig abgenommen. D.h. es klingelt dreimal und bevor ich zum abheben komme ist es auch schon vorbei.
Woran kann das liegen? Es hatte auch vor einigen Wochen schon mal funktioniert.
Gesendet von iPad mit Tapatalk
Das klingt nach Rufumleitung , Rufgruppe oder AB der nach 3x Klingeln abhebt, also irgendwas nimmt bei dir den Ruf tatsächlich an.
K.A. wie dein Gesammtaufbau aussieht.
Nur so als Tipp : Ich hatte beim proggen auch oft mehere Instanzen des Moduls laufen und irgendwann kamen die Beschwerden das der Sammelruf **9 nicht mehr ginge.
Ursache war eine Insatanz die immer sofort abgehoben hat so das die anderen Telefone nicht mehr klingelten.
Ich rufe mein Handy an. Wenn der Anrufbeantworter abheben würde bekäme ich ja einen Nachricht das was auf dem ab ist. Kann es an der Multisim liegen? Ich habe noch eine SIM im Auto mit der gleichen Nummer, aber die reagiert ja auch nicht wenn das Auto aus ist...
Wenn ich mein Handy normal Anrufe kann ich ewig klingeln lassen ohne das ein ab oder sonst was abhebt. Ich denke das Modul erkennt fälschlicherweise das die Verbindung aufgebaut ist.
Wie funktioniert denn die Erkennung ob jemand abgehoben hat?
Zitat von: F.R. am 10 Juni 2017, 08:03:49
Hallo,
Ich habe mit dem Sip-Client eine Funktion realisiert, dass das Klingeln der Türe auch das Telefon klingeln lässt. schalten. Nun habe ich noch realisiert, dass ich durch Anrufen des Sip-Clients die Funktion ein und ausschalte indem ich über einen notify einen Dummy schalte. Was mir nun noch fehlt ist ein Feedback, ob ich gerade ein oder ausgeschalten habe. Das würde ich gerne per Text2Speech realisieren. Kann mir jemand einen Hinweis geben, wie ich das realisieren könnten, dass der SIP-Client beim angerufen werden abhängig vom Status eines Dummys etwas anders per Text2Speech antwortet?
Vielen Dank schon mal
Florian
Hallo,
Ich habe inzwischen weiter rumprobiert und folgenden Absatz gefunden, der leider noch nicht funktioniert:
Ich habe mit Text2Speech zwei Dateien erstellt, die dir gewünschten Ansagen enthalten. Nun habe ich ein notify erstellt, das auf das caller Reading triggert und dann zunächst den eigentlichen Schaltbefehl ausführt, dann das Attribut sip_audiofile_wfp auf die entsprechende Datei ändert und dann den Anruf entgegen nimmt. Leider bleibt der SIP-Client auf "fetching" stehen und ich höre am Telefon gar nichts.
So sieht das notify aus:
define Klingel_An_Aus_notify notify SIPClient:caller:.* IF ([Klingel_Umleitung:state] eq "off") (set Klingel_Umleitung on,attr SIPClient sip_audiofile_wfp cache/KlingelAN.alaw,Set SIPClient fetch) ELSE (set Klingel_Umleitung off,attr SIPClient sip_audiofile_wfp cache/KlingelAUS.alaw,set SIPClient fetch)
Folgendes sehe ich im Eventmonitor:
2017-06-11 20:13:59 SIP SIPClient listen_wfp
2017-06-11 20:14:08 dummy Klingel_Umleitung off
2017-06-11 20:14:08 Global global ATTR SIPClient sip_audiofile_wfp cache/KlingelAUS.alaw
2017-06-11 20:14:08 SIP SIPClient caller: Telefon sip:**1@fritz.box
2017-06-11 20:14:08 SIP SIPClient caller: fetch
2017-06-11 20:14:08 SIP SIPClient caller_state: ringing_1
2017-06-11 20:14:09 SIP SIPClient caller_state: fetching
2017-06-11 20:14:09 SIP SIPClient listen_wfp
Und so sieht das Log mit verbose 5 aus:
2017.06.11 20:14:09 4: BlockingCall (SIP_ListenStart): created child (3024), uses telnetPort to connect back
2017.06.11 20:14:09 4: SIPClient, Listen new PID : 3024
2017.06.11 20:14:09 4: SIPClient[3024], my parent is 2962
2017.06.11 20:14:09 4: SIPClient[3024], register new expire : Sun Jun 11 20:19:09 2017
2017.06.11 20:14:09 5: SIPClient[3024], telnet : set SIPClient state listen_wfp exit
2017.06.11 20:14:09 4: Connection accepted from telnetPort_127.0.0.1_51316
2017.06.11 20:14:09 5: Cmd: >set SIPClient state listen_wfp<
2017.06.11 20:14:09 5: Starting notify loop for SIPClient, 1 event(s), first is listen_wfp
Notify.266 Notification of 'SIPClient' received. Device not monitored.
2017.06.11 20:14:09 5: End notify loop for SIPClient
2017.06.11 20:14:09 5: Cmd: >exit<
2017.06.11 20:14:09 4: SIPClient[3024], using cache/KlingelAUS.alaw for audio_wfp
2017.06.11 20:14:12 4: Connection
Hat jemand eine Idee, was hier nicht stimmt?
Das Problem ist der asynchrone listen-Prozess. Beim Start holt er sich einmalig die Informationen aus den Attributen. Du müsstest also eine Art "Audiofile vom Dienst" angeben und je nach Situation das erste oder zweite Audiofile auf dieses File kopieren. Wenn der SIP-Client dann abhebt wird das "Audiofile vom Dienst" mit dem aktuellen Inhalt abgespielt.
Puh, das klingt kompliziert. Hast du eine Idee wie ich das umsetzen könnte?
habe gerade mal nach "fhem system command" gegoogelt und einen Hinweis auf
{system ("/fhem/elro_1_on.sh &")}
gefunden.
Also müsstest du mit
{system ("cp /fhem/..../file1 /fhem/..../actfile")}
das jeweilige File kopieren können.
Zitat von: Tomk am 11 Juni 2017, 09:11:49
Ich denke das Modul erkennt fälschlicherweise das die Verbindung aufgebaut ist.
Wie funktioniert denn die Erkennung ob jemand abgehoben hat?
Das denke ich nicht :) Das Modul ist "dumm" was gerade Sache ist bekommt es vom SIP Server ( FritzBox ?) gesagt.
D.h. da würde ich ansetzen mit der Suche, bzw. ruf doch mal ein internes Telefon oder das Handy von jemand ganz andrem an zum Test.
@F.R. du hast zwei Alternativen :
a. die schwere , Attribut im notify ändern und den Client restten. FHEM wird dir aber die Attribut Änderung mit dem roten Fragezeichen danken.
b. die einfache Variante : zwei SIP Clients im SIP Server und FHEM definieren. Client 1 mit dem Attribut der Nachricht 1 und Client 2 mit er anderen Nachricht. Im notify dann einfach entscheiden ob Client 1 oder 2 aktiv werden soll.
Hallo,
vielen Dank für die Tipps. Ich habe es jetzt wie von Wzut vorgeschlagen mit den zwei SIP-Clients hinbekommen. Es kann so einfach sein, wenn man nur drauf kommt :D
Vielen Dank!
Zitat von: Wzut am 12 Juni 2017, 19:40:59
Das denke ich nicht :) Das Modul ist "dumm" was gerade Sache ist bekommt es vom SIP Server ( FritzBox ?) gesagt.
D.h. da würde ich ansetzen mit der Suche, bzw. ruf doch mal ein internes Telefon oder das Handy von jemand ganz andrem an zum Test.
Hallo Wzut,
ich habe nochmal probiert. Bei einem Anruf auf ein anderes internes Telefon verhält sich das SIP Modul wie erwartet. Nur beim Anruf auf mein Handy scheint er irgendwie von einem vermeintlich erfolgreich aufgebauten Anruf auszugehen. Eine Anrufweiterleitung auf den AB o.ä. sind nicht eingerichtet.
Sonst eine IDee?
Danke und Gruß
Tomk
Ich kann es drehen und wenden wie ich möchte, aber ich bekomme es NICHT hin das das Telefone nicht weniger als 10 mal klingelt.
set Klingel_Telefon **610 01 -> minimum 10 x klingeln
set Klingel_Telefon **610 1 -> minimum 10 x klingeln
set Klingel_Telefon **610 5 -> dito
Raspi3 mit Fritzbox 7490 und Gigaset Dect
ein Log Auszug mit verbose 5 für set Klingel_Telefon **610 1 könnte da eventuell etwas Licht ins Dunkel bringen :)
So, hier dann der Logauszug:
2017.06.24 13:26:47 4: WEB_192.168.0.2_63596 POST /fhem?cmd.setKlingel_Telefon%3Dset%20Klingel_Telefon%20call%20**610%201&XHR=1&fwcsrf=hallodu77&fw_id=2297; BUFLEN:0
2017.06.24 13:26:47 5: Cmd: >set Klingel_Telefon call **610 1<
2017.06.24 13:26:47 4: Klingel_Telefon, calling **610, ringtime: 1 , no message
2017.06.24 13:26:47 4: Klingel_Telefon, Klingel_Telefon|**610|1||0
2017.06.24 13:26:47 4: BlockingCall (SIP_CALLStart): created child (2491), uses telnetPort to connect back
2017.06.24 13:26:47 4: Klingel_Telefon, call -> Klingel_Telefon|**610|1||0|0
2017.06.24 13:26:47 5: Klingel_Telefon, call has pid 2491
2017.06.24 13:26:47 5: Starting notify loop for Klingel_Telefon, 2 event(s), first is call_state: invite
2017.06.24 13:26:47 5: ABFALL_Notify(Abfallleerung) - Device: Klingel_Telefon
2017.06.24 13:26:47 4: Klingel_Telefon[2491], my parent is 2364
2017.06.24 13:26:47 4: Klingel_Telefon[2491], using random port 44169
2017.06.24 13:26:47 5: End notify loop for Klingel_Telefon
2017.06.24 13:26:47 4: WEB: /fhem?cmd.setKlingel_Telefon%3Dset%20Klingel_Telefon%20call%20**610%201&XHR=1&fwcsrf=XXXXXXXXX&fw_id=2297 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.06.24 13:26:47 4: Klingel_Telefon[2491], register new expire : Sat Jun 24 13:31:47 2017
2017.06.24 13:26:47 5: Klingel_Telefon[2491], telnet : set Klingel_Telefon state calling exit
2017.06.24 13:26:47 4: Connection accepted from telnetPort_127.0.0.1_51580
2017.06.24 13:26:47 5: Cmd: >set Klingel_Telefon state calling<
2017.06.24 13:26:47 5: Starting notify loop for Klingel_Telefon, 1 event(s), first is calling
2017.06.24 13:26:47 5: ABFALL_Notify(Abfallleerung) - Device: Klingel_Telefon
2017.06.24 13:26:47 4: Klingel_Telefon[2491], CallStart DTMF : ABCD*#123--4567890
2017.06.24 13:26:47 4: Klingel_Telefon[2491], calling : **610
2017.06.24 13:26:47 5: Klingel_Telefon[2491], telnet : set Klingel_Telefon call_state calling **610 exit
2017.06.24 13:26:47 5: battStatus: not on any display, ignoring notify
2017.06.24 13:26:47 5: End notify loop for Klingel_Telefon
2017.06.24 13:26:47 5: Cmd: >exit<
2017.06.24 13:26:47 4: Connection accepted from telnetPort_127.0.0.1_51582
2017.06.24 13:26:47 5: Cmd: >set Klingel_Telefon call_state calling **610<
2017.06.24 13:26:47 5: Starting notify loop for Klingel_Telefon, 1 event(s), first is call_state: calling **610
2017.06.24 13:26:47 4: Klingel_Telefon[2491], cb_final - status : FAIL - final : 481
2017.06.24 13:26:47 5: Klingel_Telefon[2491], telnet : set Klingel_Telefon call_state ringing exit
2017.06.24 13:26:47 5: ABFALL_Notify(Abfallleerung) - Device: Klingel_Telefon
2017.06.24 13:26:47 5: battStatus: not on any display, ignoring notify
2017.06.24 13:26:47 5: End notify loop for Klingel_Telefon
2017.06.24 13:26:47 5: Cmd: >exit<
2017.06.24 13:26:47 4: Connection accepted from telnetPort_127.0.0.1_51584
2017.06.24 13:26:47 5: Cmd: >set Klingel_Telefon call_state ringing<
2017.06.24 13:26:47 5: Starting notify loop for Klingel_Telefon, 1 event(s), first is call_state: ringing
2017.06.24 13:26:47 5: ABFALL_Notify(Abfallleerung) - Device: Klingel_Telefon
2017.06.24 13:26:47 5: End notify loop for Klingel_Telefon
2017.06.24 13:26:47 5: Cmd: >exit<
2017.06.24 13:26:48 5: Klingel_Telefon[2491], 0. Ende des ersten Loops
2017.06.24 13:26:48 5: Klingel_Telefon[2491], 1. rtp_done : 0
2017.06.24 13:26:48 5: Klingel_Telefon[2491], 2. fi : 0
2017.06.24 13:26:48 5: Klingel_Telefon[2491], 3. timeout : 1
2017.06.24 13:26:48 4: Klingel_Telefon[2491], cb_final - status : FAIL - final : 487
2017.06.24 13:26:48 5: Klingel_Telefon[2491], RTP done : 0
2017.06.24 13:26:48 5: Klingel_Telefon[2491], Timeout : 1
2017.06.24 13:26:48 5: Klingel_Telefon[2491], Final : 487
2017.06.24 13:26:48 5: Klingel_Telefon[2491], while : 0
2017.06.24 13:26:48 5: Cmd: >{BlockingStart('12')}<
2017.06.24 13:26:48 5: Cmd: >{SIP_CALLDone('Klingel_Telefon|1|no answer')}<
2017.06.24 13:26:48 4: Klingel_Telefon, CALLDone -> Klingel_Telefon|1|no answer
2017.06.24 13:26:48 5: Starting notify loop for Klingel_Telefon, 5 event(s), first is call: done
2017.06.24 13:26:48 5: ABFALL_Notify(Abfallleerung) - Device: Klingel_Telefon
2017.06.24 13:26:48 5: End notify loop for Klingel_Telefon
2017.06.24 13:26:48 5: Klingel_Telefon, fifo is empty
2017.06.24 13:26:48 5: Klingel_Telefon, no elbc
Ich versuche gerade mein SIP Konto bei PBXes einzurichten über das Modul, aber irgendwie endet jeder anruf-Versuch mit Error 110. Benutzername und Passwort stimmen auf jeden Fall.
Zitat von: RitterSport am 24 Juni 2017, 13:43:55
So, hier dann der Logauszug:
Der schaut zwar nach einem global verbose 5 aus , aber betrachten wir mal rein den Anfang und das Ende :
2017.06.24 13:26:47 4: Klingel_Telefon[2491], register new expire : Sat Jun 24 13:31:47 2017
--snipp--
2017.06.24 13:26:48 4: Klingel_Telefon, CALLDone -> Klingel_Telefon|1|no answer
2017.06.24 13:26:48 5: Klingel_Telefon, fifo is empty
2017.06.24 13:26:48 5: Klingel_Telefon, no elbc
das ganze beginnt um13:26:47 ist ist um 13:26:48 auch schon wieder zu Ende , d.h. genau wie es sein soll bei einem Timeout von nur 1 Sekunde !
Wie es ausschaut reagiert dein SIP Server nicht darauf das das Modul die Verbindung bereits wieder getrennt hat und läst das Telefon munter weiter bimmeln.
Welchen SIP Server benutzt du ?
Danke schonmal.
Global Verbose 5...stimmt....ich bastel gerade an 1-Wire und musste sowieso etwas nachsehen.
Als Sipserver nutze ich die Fritzbox.
Behelfsweise ruft 96_Sip nun mit einer Sip Nummer eine andere Sip Nummer des gleichen Anbieters an (kostenlos untereinander) sowie die Fritzbox geht nach 5 Sekunden mit einem Extra Anrufbeantworter ran: Voila es klingelt nur 2 mal....
Hallo, nach anfänglichen Schwierigkeiten, rennt SIP jetzt auch bei mir. Nachdem ich ein wenig mit dem Modul "gespielt" habe, habe ich eine Frage:
Ist es möglich, nachdem eine Ansage abgespielt wurde, per DTMF eine Aktion auszulösen? Habe schon ein wenig probiert, aber entweder empfängt SIP DTMF oder es wird die Ansage abgespielt...
Beste Grüße
Jürgen K.
Zitat von: RitterSport am 24 Juni 2017, 19:00:34
Voila es klingelt nur 2 mal....
schön das du noch eine Lösung gefunden hast, das Modul war eigentlich nicht als primitiver Klingel Only Client gedacht ( das konnte man schon immer mit dem Fritzbox Modul), daher habe ich auch bei meinen ganzen Tests das nicht wirklich auf dem Radar gehabt. Mal schauen ob ich Anfang Juli Zeit finde in der Richtung nochmal aktiv zu werden.
Zitat von: juergen012 am 25 Juni 2017, 16:18:47
Ist es möglich, nachdem eine Ansage abgespielt wurde, per DTMF eine Aktion auszulösen?
ja der Client muss im Listen Modus DTMF sein -> Attribut sip_listen dtmf und für das Ansage File davor ist sip_audiofile_dtmf zuständig
Habe gerade dieses interessante Modul gefunden.
Die Installation mit cpan install Net::SIP ist durchgelaufen.
Alles konfiguriert. STATE=initialized
Wenn ich jedoch einen Anruf mit
set FritzSip call **610 10
versuche, klingelt das Telefon nicht.
Im Log steht:
cannot create resolver: Net::DNS not available?: Can't locate Net/DNS.pm in @INC
Ist da etwas bei der Installation schiefgelaufen ?
Hat jemand eine Idee, was man da tun kann ?
Danke schon mal
Was sagt ein
cpan install Net::DNS
?
Hallo plin,
das "cpan install Net::DNS" bedeutet -> installiere Net::DNS
Weiteres kannst Du hier nachlesen: https://www.thoughtco.com/installing-perl-modules-from-cpan-2641120 (https://www.thoughtco.com/installing-perl-modules-from-cpan-2641120)
Viele Grüße
Rainer
Zitat von: Tomk am 09 Juni 2017, 21:09:51
Hallo, ich wundere mich warum bei mir die Anrufe machmal nach 12 s beendet werden und ok zurückgemeldet wird, obwohl die Textmeldung 2mal wiederholt werden soll. der angerufene hört nur noch das Anrufende wenn er schnell genug dran geht:
2017.06.09 21:04:18 3: mySIP, force call
2017.06.09 21:04:18 4: mySIP, msg will be repeat -2 times
2017.06.09 21:04:18 4: mySIP, audio file cache/b478fa7d0c514de07c2fa071a807ab88.alaw found
2017.06.09 21:04:18 4: mySIP, mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2
2017.06.09 21:04:18 4: mySIP, call -> mySIP|xxxx|45|cache/b478fa7d0c514de07c2fa071a807ab88.alaw|-2|&60
2017.06.09 21:04:18 5: mySIP, call has pid 1744
2017.06.09 21:04:18 4: mySIP[1744], my parent is 10863
2017.06.09 21:04:18 4: mySIP[1744], using random port 44425
2017.06.09 21:04:18 4: mySIP[1744], register new expire : Fri Jun 9 21:09:18 2017
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP state calling exit
2017.06.09 21:04:18 4: mySIP[1744], CallStart with 3 files - first file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw - PCMA/8000 , repeat 2
2017.06.09 21:04:18 4: mySIP[1744], calling : xxxx
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state calling xxxx exit
2017.06.09 21:04:18 4: mySIP[1744], cb_final - status : FAIL - final : 481
2017.06.09 21:04:18 5: mySIP[1744], telnet : set mySIP call_state ringing exit
2017.06.09 21:04:25 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:25 4: mySIP[1744], call established
2017.06.09 21:04:25 5: mySIP[1744], telnet : set mySIP call_state established exit
2017.06.09 21:04:26 5: mySIP[1744], 0. Ende des ersten Loops
2017.06.09 21:04:26 5: mySIP[1744], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:26 5: mySIP[1744], 2. fi : 0
2017.06.09 21:04:26 5: mySIP[1744], 3. timeout : 0
2017.06.09 21:04:26 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:26 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:28 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:28 4: mySIP[1744], next file : cache/b478fa7d0c514de07c2fa071a807ab88.alaw
2017.06.09 21:04:28 4: mySIP[1744], cb_final - status : OK
2017.06.09 21:04:30 4: mySIP[1744], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], RTP done : Net::SIP::Simple::Call=HASH(0x4d70c68)
2017.06.09 21:04:30 5: mySIP[1744], Timeout : 0
2017.06.09 21:04:30 5: mySIP[1744], while : 2
2017.06.09 21:04:30 5: mySIP[1744], Status : OK
2017.06.09 21:04:30 4: mySIP, CALLDone -> mySIP|1|ok
2017.06.09 21:04:30 5: mySIP, fifo is empty
2017.06.09 21:04:30 5: mySIP, no elbc
Hat jemand ne idee?
Also, es scheint wirklich nur bei der Handynummer mit Multisim das Problem zu geben das FHEM signalisiert das Gespräch wäre erfolgreich aufgebaut, obwohl man nicht abgehoben hat. Und dort auch nur wenn die Anrufe ganz normal über das Mobilnetz laufen. Wenn ich das gleiche Handy im WLAN habe (mit Wifi Calling aktiv) dann funktionierst. Scheint so als würde der Netzbetreiber den Anruf per default annehmen und dann an die Multisim Teilnehmer weiterleiten. Ich befürchte ich kann das Verhalten nicht beeinflussen... schade.
@plin
nach cpan install Net::DNS war die Fehlermeldung weg.
Hab dann noch etwas mit den Anmelde-Attributen spielen müssen.
Jetzt läuft's !
Danke für die Info
Zitat von: Heuberg am 27 Juni 2017, 23:10:39
Hallo plin,
das "cpan install Net::DNS" bedeutet -> installiere Net::DNS
Weiteres kannst Du hier nachlesen: https://www.thoughtco.com/installing-perl-modules-from-cpan-2641120 (https://www.thoughtco.com/installing-perl-modules-from-cpan-2641120)
Viele Grüße
Rainer
Das ist mir klar. Die Antwort auf die Eingabe des Commands lautet entweder "ist schon vorhanden" oder "installiere ...". Scheinbar war's die zweite Antwort :-)
Hallo, ich habe nochmal eine andere Frage: bei einem speziellen Event möchte ich zwei Telefone anrufen. Es wird im log file auch zweimal ein forcecall angezeigt, es wird aber nur die zweite Nummer angerufen. Sollte hier nicht der zweite Anrufwunsch gespeichert werden und die Anrufe nacheinander abgearbeitet werden?
ich verstehe nicht so ganz was du möchtest. Zwei Telefonummern gleichzeitig anrufen ? Das geht nicht , Tipp : Rufgruppe in der FB definieren und diese anrufen.
Zwei Nummern in einem zeitlichen Abstand ? Wenn ja bitte etwas mehr Code und verbose 5 Log posten.
Sorry, war vielleicht wirklich wenig detail in meiner Anfrage. Das Szenario ist folgendes: Einbruch Alarm wird erkannt. Darauf hin werden zwei notifys aktiv, welche zwei unterschiedliche Nummern anrufen sollen (eine Mobil und eine im Schlafzimmer (also intern)).
Ich dachte irgendwo gelesen zu haben das die Anrufe gecached werden wenn ein zweiter Anruf gestartet wird und der erste noch nicht abgeschossen ist. Wenn das nicht so ist könnte ich einfach eine Pause vor dem zweiten Anruf einbauen, oder?
Eine Rufgruppe mit externen Teilnehmern geht nicht, richtig?
ahh jettzt ja :)
Nein das Modul hat keinen Cache , die zweite Nr. überschreibt die erste.
Was aber geht ist in der FB zwei SIP Telefone anzulegen und in FHEM auch zwei. Bsp Sip_int und Sip_ext oder halt mit einem at den zweiten Anruf verzögern.
Hallo,
ich bekomme es leider nicht hin.
Ich habe SIP in FHEM wie folgt angelegt.
define RasPi_Fon SIP
attr RasPi_Fon room Wohnzimmer
attr RasPi_Fon sip_dtmf_loop once
attr RasPi_Fon sip_dtmf_send audio
attr RasPi_Fon sip_dtmf_size 2
attr RasPi_Fon sip_elbc yes
attr RasPi_Fon sip_from sip:621@fritz.box # 621 Interne NR. laut FB
attr RasPi_Fon sip_ip 192.168.178.81 #IP FHEM bzw SIP Client
attr RasPi_Fon sip_listen none
attr RasPi_Fon sip_port 5070
attr RasPi_Fon sip_registrar 192.168.178.1 #IP der Fritzbox
attr RasPi_Fon sip_ringtime 3
attr RasPi_Fon sip_user RasPi_Fon # RasPi_Fon = USER auf der FB
attr RasPi_Fon verbose 5
Das Password habe ich über
set RasPi_Fon password xx_xx_xx_xx
im Eingabefeld in der Browser Oberflache festgelegt und wird mit
SIP user password successfully saved in FhemUtils/uniqueID Key SIP_RasPi_Fon_passwd
von FHEM quittiert.
Es ist Länger als 8 Zeichen und wurde von der FB-Oberflche als GUT bewertert.
Setze ich nun ein
set RasPi_Fon call **610 30
ab, erhalte ich
CallRegister: Failed with code 404
Laut https://de.wikipedia.org/wiki/SIP-Status-Codes (https://de.wikipedia.org/wiki/SIP-Status-Codes) bedeutet dieser CODE "Die Gegenstelle wurde nicht gefunden oder existiert nicht."
Bei der SIP einrichtung wollte die FB das ich auf dem Telefon einen #123456 Code eingebe bzw. das Gerät per Knopfdrück an der FB bestätigt wird. Letztere habe ich gemacht.
Was kann ich tun? Danke vor ab!
Zitat von: teitesmars am 31 Juli 2017, 13:54:12
attr RasPi_Fon sip_from sip:621@fritz.box # 621 Interne NR. laut FB
attr RasPi_Fon sip_user RasPi_Fon # RasPi_Fon = USER auf der FB
Teste mal stat der Rufnummer 621 den echten User:
attr RasPi_Fon sip_from sip:RasPi_Fon@fritz.box
und check bitte auch mal auf der Konsole ob dein FHEM Server fritz.box auch richtig auflösen kann zu 192.168.178.1 ,
wenn nein mach einen manuellen Eintrag in der Datei /etc/hosts
ZitatTeste mal stat der Rufnummer 621 den echten User:
Code: [Auswählen]
attr RasPi_Fon sip_from sip:RasPi_Fon@fritz.box
Danke DAS hat es gebracht. Aber der interesse halber was meinst du mit
Zitatcheck bitte auch mal auf der Konsole ob dein FHEM Server fritz.box auch richtig auflösen kann zu 192.168.178.1 ,
ja ja die neuen FB Firmware Versionen , müssen wir unbedingt um Wiki vermerken ich habe das in sechs Monaten auch wieder vergessen ....
Zitat von: teitesmars am 31 Juli 2017, 16:14:08
der interesse halber was meinst du
na z.B. ein simples ping fritz.box und ob dann der Name richtig in eine FB IP umgesetzt wird, ist jetzt aber wurscht da das Problem ja der from war.
Edit : Das Wiki war schon auf dem aktuellen Stand :
ZitatBasics & Allgemeines
sip_from
Meine SIP-Client-Info. Default ist sip:620@fritz.box für ältere Fritz!OS-Versionen. Ab 6.8 ist das Format sip:Benutzername@fritz.box.
Zitat von: Wzut am 31 Juli 2017, 17:32:18
Edit : Das Wiki war schon auf dem aktuellen Stand :
Puh ... ::)
Hallo Teilnehmer! ;)
Ich wollte mich mal sehr bei Allen bedanken, die das rudimentäre aber von der Idee her geniale Modul von wmeiners auf den heutigen Stand gebracht haben, der einfach keine Wünsche mehr offen lässt!
Ich habe heute mal probiert einen Anruf mit Ansage in Textform über TTS und sox abzusetzen. Was soll ich sagen: Es geht auf Anhieb, es geht schnell und es geht perfekt! Wenn man sich mal vorstellt, was bei diesem - mit dem Modul jetzt total einfach zu realisierenden - Vorgang alles im Hintergrund passiert. 1. Hut ab und zwar ganz lange! Und 2. Da können andere (auch kostenpflichtige) SmartHome- Lösungen vermutlich einpacken. Für FHEM geistert mir sowieso schon lange der Slogan "All you can dream" im Kopf herum... :)
Vielen Dank sagt
Frank
:) :) siehste das ist halt das schöne an FHEM , alles ein bischen wie Lego. Die Steine sind da was man daraus baut ist jedem selbst überlassen.
Allerdings steckt IMHO der wirkliche Gehirnschmalz nicht im Modul direkt sondern im Unterbau NET::SIP von Steffen Ullrich. Was mir echt gut bei diesem Projekt gefallen hat war das letztendlich einfache Zusammenspiel mit Text2Speech, was aber auch nur möglich war weil Tobias quasi auf Zuruf umgesetzt hat was gebraucht wurde.
Und hätte plin nicht so mühevolle Basistests gemacht gäbe es das Modul in der heutigen Form nicht, ganz zu schweigen von seinem tollen Wiki.
Hallo,
ich habe heute eine wenig mit dem Modul getestet. Leider ohne Erfolg.
2017.08.22 23:00:35 4: SIP_fhem_neu, Listen new PID : 7745
2017.08.22 23:00:35 4: SIP_fhem_neu[7745], my parent is 24685
2017.08.22 23:00:35 4: SIP_fhem_neu[7745], using random port 44767
2017.08.22 23:00:35 2: SIP_fhem_neu[7745], cannot open port 44767 at 192.168.2.110: Cannot assign requested address
2017.08.22 23:00:35 5: SIP_fhem_neu, ListenDone -> SIP_fhem_neu|ListenRegister: can't open port 44767 or 44777 at 192.168.2.110: Cannot assign requested address
2017.08.22 23:00:35 3: SIP_fhem_neu, listen error -> ListenRegister: can't open port 44767 or 44777 at 192.168.2.110: Cannot assign requested address
2017.08.22 23:00:35 4: SIP_fhem_neu, Listen new PID : 7746
2017.08.22 23:00:35 4: SIP_fhem_neu[7746], my parent is 24685
2017.08.22 23:00:35 4: SIP_fhem_neu[7746], using random port 44702
2017.08.22 23:00:35 2: SIP_fhem_neu[7746], cannot open port 44702 at 192.168.2.110: Cannot assign requested address
2017.08.22 23:00:35 5: SIP_fhem_neu, ListenDone -> SIP_fhem_neu|ListenRegister: can't open port 44702 or 44712 at 192.168.2.110: Cannot assign requested address
2017.08.22 23:00:35 3: SIP_fhem_neu, listen error -> ListenRegister: can't open port 44702 or 44712 at 192.168.2.110: Cannot assign requested address
Die Einstellungen habe ich wie im WIKI gemacht. 192.168.2.110 ist meine Box. Fhem läuft in einem Docker-Container, folglich geNATed.
Kann dies das Problem sein?
Gruß
sweetie-pie
Den Fall hatte ich zwar noch nicht aber ich würde sagen : ja
Wenn 192.168.2.110 die IP ist unter der FHEM von "aussen" erreichbar ist. Trage doch mal im Attribut für die eigene IP sip_ip die echte IP ein, also das was man überlicherweise unter ifconfig auf der Konsole zu sehen bekommt.
Gibt es dann bei einem Docker Image ausser dem Nating noch Firewall Regeln ?
Wenn ja wirst dich unter sip_sip Port für einen festen wie z.B. 5060 entscheiden müssen und die Freigaberegeln für diesen und seinen Bruder 5070 auch anpassen.
Edit : gerade gefunden , was sagt denn
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name_or_id
@Jürgen, ja ich habe den Vortrag letztens Karlsruhe gehalten.
Macht hier das SIP Modul einen eigenen Port auf? Wenn ja muss dieser beim starten des Containers exposed werden, sonst ist der nur lokal innerhalb des Containers verfügbar aber nicht von außen erreichbar.
Wenn man nun in dem Modul den Port 5060 und 5070 eintragen kann als feste Ports und die IP des Wirtrechners (z.B. 192.168.2.110) dann sollte der FHEM Container zusätzlich zu den Webports noch -p 5060:5060 -p 5070:5070 als Startparameter bekommen um die Ports zu exposen.
Was normalerweise gehen sollte ich das ein Docker Container nach außen in die freie Welt funken darf. Sprich die FritzBox sollte erreichbar sein. Aber auch hier kann es Ausnahmen geben.
Ich hab heute nochmal diverses probiert. War wohl eine Gemengelage aus mindestens zwei Problemen:
Eines davon konnte ich wie folgt lösen:
Mit dem letzten Update hat AVM die Passwortanforderungen geändert. Ich hatte schon die Passwörter entsprechend angepasst, aber die Fritzbox hat sie nicht richtig übernommen, auch nicht nach einem Neustart.
Die Lösung hierfür war: Alle IP-Telefone löschen, Fritzbox neu starten, Accounts wieder anlegen. Dann habe ich die neuen Accounts mit CSipSimple überprüft.
Als nächsten Test hatte ich nochmal den Vorgänger FB_SIP eingrichtet. Die Anmeldung klappt ohne Probleme, auch aus dem Docker-Container heraus. Portweiterleitungen habe ich dafür nicht extra angelegt...
Nach den ganzen Konfig Versuchen von gestern, habe ich das neue SIP-Device nochmal gelöscht und neu definiert:
defmod SIP_fhem_neu SIP
attr SIP_fhem_neu sip_dtmf_loop once
attr SIP_fhem_neu sip_dtmf_send audio
attr SIP_fhem_neu sip_dtmf_size 2
attr SIP_fhem_neu sip_elbc yes
attr SIP_fhem_neu sip_from sip:625@192.168.2.110
attr SIP_fhem_neu sip_ip 172.17.0.3
attr SIP_fhem_neu sip_listen wfp
attr SIP_fhem_neu sip_registrar 192.168.2.110
attr SIP_fhem_neu sip_ringtime 3
attr SIP_fhem_neu sip_user iptelefon6
setstate SIP_fhem_neu error
setstate SIP_fhem_neu 2017-08-23 22:57:03 last_error ListenRegister: Failed with error 110
setstate SIP_fhem_neu 2017-08-23 22:57:03 state error
Die IP der Dockermaschine ist geNATed, sie lautet:root@automation-nuc:~# docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 41d4c569db12
172.17.0.3
Die Fehlermeldung ist nun eine andere. Braucht das Modul denn zwingend eine Portweiterleitung? Die Verbindung wird doch von innen nach außen aufgebaut. Ich kein VoiP Spezi, was passiert denn bei einem LISTEN?
2017.08.23 23:07:22 4: SIP_fhem_neu, Listen new PID : 13982
2017.08.23 23:07:22 4: SIP_fhem_neu[13982], my parent is 24685
2017.08.23 23:07:22 4: SIP_fhem_neu[13982], using random port 44864
2017.08.23 23:07:22 5: SIP_fhem_neu, ListenDone -> SIP_fhem_neu|ListenRegister: Failed with code 404
2017.08.23 23:07:22 3: SIP_fhem_neu, listen error -> ListenRegister: Failed with code 404
Macht der Prozess 13982 einen lokalen Port 44864 auf den sich dann die Fritzbox verbinden müsste? TCP oder UDP? Random klingt dann ja irgendwie doof. Muss ich also attr sip_port fest setzen und dann den Portforward in den Container machen? Wofür/Was passiert da?
Gruß
sweetie-pie
Hi,
wenn ich mich recht erinnere baut der SIP-Client eine Verbindung zur FB auf, registriert sich dort mit seinem Listener-Port und baut dann die Verbindung wieder ab. Will die FB den SIP-Client kontaktieren, spricht sie den registrierten Port an.
VG plin
Zitat von: sweetie-pie am 23 August 2017, 23:17:43
Macht der Prozess 13982 einen lokalen Port 44864 auf den sich dann die Fritzbox verbinden müsste?
ja und der Pot ist per Zufall ausgewählt da manche User Probleme mit dem fixen Ports 5060 und 5070 hatten. Du solltest aber sip_port fest auf 5060 setzen und bitte die Anmerkung von sbiermann auf der vorherigen Seite beachten und Port 5060 und 5070 übergeben
Zitat von: sbiermann am 23 August 2017, 18:26:45
Macht hier das SIP Modul einen eigenen Port auf? Wenn ja muss dieser beim starten des Containers exposed werden, sonst ist der nur lokal innerhalb des Containers verfügbar aber nicht von außen erreichbar.
Wenn man nun in dem Modul den Port 5060 und 5070 eintragen kann als feste Ports und die IP des Wirtrechners (z.B. 192.168.2.110) dann sollte der FHEM Container zusätzlich zu den Webports noch -p 5060:5060 -p 5070:5070 als Startparameter bekommen um die Ports zu exposen.
Teste das bitte mal mit beiden IPs unter sip_ip und
GANZ WICHTIG ändere bitte sip_from da du eine neue FB OS Version benutzt (steht so auch im Wiki ) :
Zitat
sip_from
Default ist sip:620@fritz.box für ältere Fritz!OS-Versionen. Ab 6.8 ist das Format sip:Benutzername@fritz.box.
Hallo zusammen,
hab gestern mit etwas Krampf auch das SIP Modul auf meinem Raspberry mit Fritzbox soweit ans laufen bekommen. Aber ein Problem habe ich noch.
Wenn ich in FHEM ein "set siptest call telenr 30" absetze, klingelt das gewünschte Telefon. Wenn ich dran gehe höre ich ca. 5 Sekunden diverse Pieptöne und dann wird das Gespräch beendet. Ich möchte aber das das "Gespräch" 30 Sekunden aufrecht erhalten wird. Jemand eine Idee warum die Verbindung getrennt wird und wo die Pieptöne herkommen?
Danke und Gruß
Julia
ja das steht so alles im Wiki https://wiki.fhem.de/wiki/SIP-Client
Wenn du Hilfe brauchst must du schon etwas konkreter werden was du mit dem Modul wirklich anstellen willst
OK, hatte das Wiki glaube ich fehlinterpretiert. Mit "Dauer" dachte ich es wäre die Gesprächsdauer gemeint. Aber wenn ich es richtig sehe ist es die Dauer wie lange es klingeln soll?
Ich möchte eine meiner Nummern anrufen, 30 Sekunden die Verbindung aufrechterhalten und die Verbindung wieder trennen. Gibt es eine Möglichkeit die "Gesprächsdauer" anzugeben ganz unabhängig von Texten/Tönen/Soundfiles?
Danke und Gruß
Julia
Zitat von: juliar am 26 August 2017, 09:28:54
wenn ich es richtig sehe ist es die Dauer wie lange es klingeln soll?
Nein , es ist die Überwachungszeit wie lange der ganze Vorgang max. dauern darf bis es als erfolgloser Versuch abgebrochen wird.
Mir erschliesst sich noch immer nicht der Sinn deines Vorhabens. Normalerweise lässt man sich vom Modul anrufen um entweder eine bestimmte Sound Datei sich vorspielen zu lassen oder eine gesprochene Textnachricht. Was bringt es wenn das Telefon klingelt, man abnimmt und dann 30 Sekunden Stille hört bis die Gegenstelle wieder auflegt ? Kannst natürlich machen , erzeuge dir 30 Sekunden "Sound of Silence" als alaw und übergebe die dem Call.
Hallo Wzut,
OK, Danke. Jetzt habe ich verstanden wozu "Dauer" gedacht ist. 8)
Mit dem 30 Sekunden Stille File ist eine gute Idee. Auch hierfür Danke. Werde ich mal so testen.
Eine ganz andere Frage hätte ich noch: Wenn ich eine Nummer anrufen möchte die nach Abheben eine Pin-Eingabe benötigt, gibt es da eine Möglichkeit das mit dem SIP Modul zu übergeben? Beim Handy klappt das z.B. mit einem "P" zwischen Nummer und Pin (also z.B.: 03012345P1111). Das "p" scheint für pause zu stehen. Aber beim Test über das Modul schien mir das nicht zu klappen. Wobei ich nicht weiß ob es am Modul, an der Fritzbox, oder an meiner Unfähigkeit liegt. ;)
Gruß
Julia
ja das geht und hast du auch schon im ersten Versuch gemacht als du die Töne beim annehmen gehört hast.
Übergeben wird diese Codefolge nicht mit P1234 sondern wie im Wiki :) beschrieben mit
Zitatals DTMF-Sequenz angegeben werden. Diese mit einem Prefix '-' versehen werden, also z.B. -#47.
https://wiki.fhem.de/wiki/SIP-Client#Anruf_t.C3.A4tigen_und_DTMF-T.C3.B6ne_senden
wichtig wird dabei das Attribut sip_dtmf_send
ZitatBestimmt die Übertragungsart der angegebenen DTMF-Töne und bietet folgende Möglichkeiten:
'audio': Es werden Audiotöne übermittelt
'rfc2833': Es erfolgt eine Übertragung nach RFC2833 (für das menschliche Ohr weniger ansprechend)
Ehrlich gesagt hatte mich das Wiki wieder etwas verwirrt. Erst heißt es "set <device> call <nummer> <dauer> <-tastenkombination>", Zeile drunter steht dann "Die Tastenkombination muss mit einem Minus (-) nach der Zielnummer folgen". Einmal also vor der Dauer und einmal soll es dahinter sein. Aber ich denke ich habe es hinbekommen.
Danke und Gruß
Julia
Hallo,
ich kann mit dem Modul bei einem ausgehenden Ruf DTMF Töne senden, ein Audiofile abspielen oder eine Text-zu-Sprache Nachricht ausgeben. Funktioniert alles gut. Was ich jetzt gerne hätte, wäre eine Kombination, also z.B. erst ein Audiofile abspielen und direkt anschließend DTMF Töne.
Ich würde das so gerne für meinen Türöffner einsetzen: erst eine "Begrüßungsmelodie" über die Sprechanlage und dann DTMF für den Türöffner.
Wenn ich nichts übersehen habe, ist das so bisher noch nicht möglich.
Gruß
Otto
Richtig und es hat auch einen einfachen Grund : Es gab bisher einfach keine Anforderung dafür.
I.d.R. geht doch der eigentliche Rufaubau recht flott. Hast du mal versucht einfach zwei getrennte Aktionen direkt hintereinander auszuführen ? D.h. Audio File senden und dann mittels notify Auswertung des call end direkt danach die DTMF Sequenz. Würde mich mal interessieren ob die Pause zwischen den beiden Aktionen überhaupt auffällt.
Das funktioniert so ohne weiteres leider nicht. Der Grund ist vermutlich, dass die Türsprechanlage das Auflegen nicht schnell genug erkennt bzw. nicht schnell genug selbst auflegt.
Wechselt die Tastenkombination? Vermutlich nein, wenn es sich um um die Kombination für den Türöffner handelt. Folglich ist alles Audio.
Also nehme den Text für die Willkommenansage auf, zeichen die DTMF-Töne auf und kopiere alles in ein Audiofile. Das kannst du dann abspielen.
VG plin
Hallo zusammen, ich meine ich habe alles zu TTS und SIP hier im Thread gelesen. Funktioniert soweit prima.
Aber, gibt es eine Möglichkeit eine Variable an den TTS zu übergeben? Dann könnte man Ansagen entsprechend dynamisieren.
z.B.
set MySIPNr call **610 30 !Achtung es wurde der Bewegungsmelder $DYNAMISCHER_TEXT ausgelöst.
Es könnte aber dann auch ein Reading ausgegeben werden.
set MySIPNr call **610 30 !Achtung die Kesseltemperatur beträgt nur noch [HM_403B31_T2.temperature] Grad.
Geht so was?
jein, d.h. direkt auf der Kommandozeile nicht, aber T2S will Text und ob dieser Text nun komplett von Hand geschrieben ist oder via Perl erst aus Teilen zusammen gebaut wird ist vollkommen wurscht.
Versuchs doch mal in einem notify ala
define n_test_call notify HM_403B31_T2:temperature:.* {fhem("set MySIPNr call **610 30 !Achtung die Kesseltemperatur beträgt nur noch ".$EVTPART1." Grad");}
Zitat von: plin am 21 September 2017, 18:42:23
Wechselt die Tastenkombination? Vermutlich nein, wenn es sich um um die Kombination für den Türöffner handelt. Folglich ist alles Audio.
Also nehme den Text für die Willkommenansage auf, zeichen die DTMF-Töne auf und kopiere alles in ein Audiofile. Das kannst du dann abspielen.
VG plin
Hallo plin,
an die Lösung habe ich auch schon gedacht. Ist zwar nicht so elegant und flexibel, sollte aber funktionieren.
Zitat von: Wzut am 22 September 2017, 15:41:25
jein, d.h. direkt auf der Kommandozeile nicht, aber T2S will Text und ob dieser Text nun komplett von Hand geschrieben ist oder via Perl erst aus Teilen zusammen gebaut wird ist vollkommen wurscht.
Versuchs doch mal in einem notify ala
define n_test_call notify HM_403B31_T2:temperature:.* {fhem("set MySIPNr call **610 30 !Achtung die Kesseltemperatur beträgt nur noch ".$EVTPART1." Grad");}
Danke, da hätte ich, wenn ich mich mit Perl mehr auseinandersetzen würde und nicht inzwischen zur DOIF-Fraktion gehören würde, auch drauf kommen können... :'(
moin,
ich stelle bei mir von zeit zu zeit ein "kommunikationsproblem" des moduls zum listen prozess fest. dieser fehler tritt allerdings äusserst selten auf. mit verbose 5 sieht es folgendermassen aus:
2017.10.09 15:09:44.196 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:09:53.111 4: triggerLiveCam[737], register new expire : Mon Oct 9 15:14:53 2017
2017.10.09 15:09:53.111 5: triggerLiveCam[737], telnet : set triggerLiveCam state listen_dtmf exit
2017.10.09 15:10:47.226 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:11:50.256 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:12:23.136 4: triggerLiveCam[737], register new expire : Mon Oct 9 15:17:23 2017
2017.10.09 15:12:23.137 5: triggerLiveCam[737], telnet : set triggerLiveCam state listen_dtmf exit
2017.10.09 15:12:53.288 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:13:56.326 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:14:56.363 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:15:59.396 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:17:02.429 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:17:53.153 1: ----- SIP-ERROR ----- -> no more events
2017.10.09 15:18:05.466 5: triggerLiveCam, listen prozess 737 found
2017.10.09 15:19:08.496 5: triggerLiveCam, listen prozess 737 found
der prozess scheint noch vorhanden zu sein, aber reagiert dann nicht mehr. normalerweise wird alle 2,5 minuten das state-event "listen_dtmf" erzeugt, welches dann plötzlich nicht mehr kommt. weitere fehlermeldungen werden leider nicht gemeldet. erst mit einem "set reset" kann die funktionalität wieder hergestellt werden. mit einem watchdog auf dieses event lasse ich mir nun den fehler anzeigen, um anschliessend den reset auszulösen.
das modul ist bei mir als virtuelle türsprecheinrichtung an der fritzbox registriert. im fehlerfall lässt sich die türsprecheinrichtung nicht mehr intern anrufen. auch in der fritzbox kann ich dann keine infos über einen fehler erkennen.
wäre es nicht sinnvoll, dass das sip-modul dieses "kommunikationsproblem" selber feststellt, eine fehlermeldung erzeugt und eventuell auch automatisch einen reset durchführt?
hier noch ein list des funktionierenden moduls. wenn es zum "hänger" kommt, sind die daten im prinzip gleich.
Internals:
.oldstate listen_dtmf
.reset 0
LPID 26879
NAME triggerLiveCam
NOTIFYDEV global
NR 607
NTFY_ORDER 50-triggerLiveCam
STATE listen_dtmf
TYPE SIP
VERSION V1.54 / 07.04.17
READINGS:
2017-10-10 01:11:44 call done
2017-10-10 01:11:44 call_state no answer
2017-07-12 02:08:43 call_success 0
2017-10-10 01:11:44 call_time 30.1616358757019
2017-10-08 19:59:14 caller none
2017-10-08 19:59:14 caller_state waitting
2017-10-08 19:59:14 caller_time 20.0788230895996
2017-10-08 19:59:07 dtmf 12
2017-08-10 15:12:41 last_error CallRegister: can't open port 5070 or 5080 at 192.168.1.22: Address already in use
2017-10-10 11:46:30 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg triggerLiveCam
bc_pid 3966
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 26879
timeout
Attributes:
event-on-change-reading .*
event-on-update-reading state,dtmf
group fon
room 01_ALARM,Wetter-Unwetter
sip_dtmf_loop loop
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc no
sip_from sip:621@192.168.1.1
sip_ip 192.168.1.22
sip_listen dtmf
sip_port 5070
sip_registrar 192.168.1.1
sip_ringtime 1
sip_user 621
timestamp-on-change-reading .*
verbose 5
gruss frank
hmmm ...... ich hatte bei der Entwicklung des Moduls oft das Problem das mir durch meine Fehler der listen Prozess einfach gestorben ist, aus dem Grund hatte ich dann irgendwann dessen Überwachung eingeführt. Klar die Überwachung sagt jetzt nur aus das es den Prozess noch gibt, aber halt nicht das er noch macht was er auch soll. In der Beziehung ist dein Ansatz wesentlich besser mit der Überwachung des new expire .
Ich muss mir nochmal in Ruhe anschauen was es für Gründe für das Schweigen des Child Prozess geben könnte.
Bei mir läuft auf dem aktiven FHEM auch ein listen_echo und das schon seit Monaten ohne diesen Hänger.
hallo wzut,
eventuell habe ich den auslöser des "hängers" gefunden, zumindestens kann ich den fehler provozieren.
mein pi3 mit fhem ist über wlan mit der fritzbox verbunden. im syslog habe ich gesehen, dass ca. 8 sek vor dem fehlenden "new expire" die wlan verbindung abgebrochen war:
Oct 09 15:14:45 raspberrypi dhcpcd[661]: wlan0: carrier lost
zum testen habe ich gerade mal das wlan an der fritzbox für ca 5 min ausgeschaltet. seit dem hängt der child prozess und das verbose 5 log sieht genauso aus, wie bereits gepostet.
ahh DHCP ... da wäre ich nicht so schnell drauf gekommen. Mal ganz unabhängig vom aktuellen Problem, hier liegt noch eine andere Tretmine ! Wenn sich durch Ablauf der DHCP Lease Time die IP das FHEM Clients ändert. Wurde im DHCP Server für FHEM eine fixe IP gesetzt besteht das Problem nicht.
Aber back to Topic : Ich habe mir das gestern Abend nochmal angeschaut und auf die Schnelle mit ein paar zusätzlichen Zeilen den Timestamp von state überwacht, klappt soweit gut, allerdings gefällt mir diese quick & dirty Lösung nicht sonderlich gut, da sich der Zeitstempel von state auch durch mögliche Fehlermeldungen ändern könnte. Ich werde dem Modul ein neues Reading spendieren das exklusiv vom Child Prozess frisch gehalten wird, bleibt diese Aktualisierung für 3 Minuten aus wird der Prozess gekillt und versucht einen Neuen zu starten.
Ich war bisher der Meinung das hätte ich direkt in der $sub_register erschlagen, aber das ist wohl ein Irrtum :(
Mein return "registration failed" greift nur beim ersten Aufruf , jedoch nicht beim zyklischen erneuern. Mal schauen ob mir da auch noch etwas Elegantes dazu einfällt, das wäre mir sogar noch lieber als die ständige Überwachung durch den Hauptprozess. Aber im Zweifelsfall halte ich mich an das Motto "doppelt genäht hält besser" :)
@frank, kannst du bitte mal die angehängte Version testen bevor ich sie einchecke ?
Sie hat zwei neue Readings : expire und listen_alive
Wenn das attribut sip_watch_listen nicht gesetzt ist (default 60) oder größer als 0 ist wird zyklisch der Timestamp von listen_alive und seinem Wert "yes" geprüft. Nach 180 Sekunden (3 Minuten) ohne Aktivität vom Child Prozess wird dieser gekillt und neu gestartet.
Edit : Anhang gelöscht , diese Version ist jetzt via update zu beziehen
danke, aber ich kann leider erst kommende woche testen.
gruss frank
Hi,
ich habe das Problem, dass die Anrufe nach extern (egal ob Festnetznummer oder Handynummer) "zu kurz" geraten. Es ist mir nicht gelungen, rechtzeitig abzuheben bzw. kommt es oft nicht einmal zu einem Rufzeichen. Die Änderung für sip_ringtime von 30 auf 90 bringt nichts!
Auf das interne Analogtelefon am Anschluss FON1 der Fritzbox 7490 funktioniert es problemlos, nach dem Abheben wird das eingestellte Audiofile abgespielt.
Seltsamerweise sehen die Logs gleich aus:
set mySIP1 call **1 (Intern)
2017.10.12 21:20:53 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.12 21:20:53 4: mySIP1, mySIP1|**1|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.12 21:20:53 4: mySIP1, call -> mySIP1|**1|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.12 21:20:53 5: mySIP1, call has pid 11513
2017.10.12 21:20:53 4: mySIP1[11513], my parent is 10545
2017.10.12 21:20:53 4: mySIP1[11513], using random port 44358
2017.10.12 21:20:54 4: mySIP1[11513], register new expire : Thu Oct 12 21:25:54 2017
2017.10.12 21:20:54 5: mySIP1[11513], telnet : set mySIP1 state calling exit
2017.10.12 21:20:54 4: mySIP1[11513], CallStart with 2 files - first file : CODE(0x44e1ae8) - PCMA/8000 , repeat 0
2017.10.12 21:20:54 4: mySIP1[11513], calling : **1
2017.10.12 21:20:54 5: mySIP1[11513], telnet : set mySIP1 call_state calling **1 exit
2017.10.12 21:20:54 4: mySIP1[11513], cb_final - status : FAIL - final : 481
2017.10.12 21:20:54 5: mySIP1[11513], telnet : set mySIP1 call_state ringing exit
2017.10.12 21:20:56 4: mySIP1[11513], cb_final - status : OK
2017.10.12 21:20:56 4: mySIP1[11513], call established
2017.10.12 21:20:56 5: mySIP1[11513], telnet : set mySIP1 call_state established exit
2017.10.12 21:20:59 5: mySIP1[11513], 0. Ende des ersten Loops
2017.10.12 21:20:59 5: mySIP1[11513], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4572d58)
2017.10.12 21:20:59 5: mySIP1[11513], 2. fi : 0
2017.10.12 21:20:59 5: mySIP1[11513], 3. timeout : 0
2017.10.12 21:20:59 4: mySIP1[11513], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.12 21:20:59 4: mySIP1[11513], cb_final - status : OK
2017.10.12 21:21:01 4: mySIP1[11513], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4572d58)
2017.10.12 21:21:01 5: mySIP1[11513], RTP done : Net::SIP::Simple::Call=HASH(0x4572d58)
2017.10.12 21:21:01 5: mySIP1[11513], Timeout : 0
2017.10.12 21:21:01 5: mySIP1[11513], while : 0
2017.10.12 21:21:01 5: mySIP1[11513], Status : OK
2017.10.12 21:21:01 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.12 21:21:01 5: mySIP1, fifo is empty
2017.10.12 21:21:01 5: mySIP1, no elbc
set mySIP1 call 0176555XXXXX (Extern)
2017.10.12 21:18:13 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.12 21:18:13 4: mySIP1, mySIP1|017655534962|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.12 21:18:13 4: mySIP1, call -> mySIP1|0176555XXXXX|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.12 21:18:13 5: mySIP1, call has pid 11366
2017.10.12 21:18:13 4: mySIP1[11366], my parent is 10545
2017.10.12 21:18:13 4: mySIP1[11366], using random port 44354
2017.10.12 21:18:13 4: mySIP1[11366], register new expire : Thu Oct 12 21:23:13 2017
2017.10.12 21:18:13 5: mySIP1[11366], telnet : set mySIP1 state calling exit
2017.10.12 21:18:13 4: mySIP1[11366], CallStart with 2 files - first file : CODE(0x478fca0) - PCMA/8000 , repeat 0
2017.10.12 21:18:13 4: mySIP1[11366], calling : 017655534962
2017.10.12 21:18:13 5: mySIP1[11366], telnet : set mySIP1 call_state calling 017655534962 exit
2017.10.12 21:18:13 4: mySIP1[11366], cb_final - status : FAIL - final : 481
2017.10.12 21:18:13 5: mySIP1[11366], telnet : set mySIP1 call_state ringing exit
2017.10.12 21:18:23 4: mySIP1[11366], cb_final - status : OK
2017.10.12 21:18:23 4: mySIP1[11366], call established
2017.10.12 21:18:23 5: mySIP1[11366], telnet : set mySIP1 call_state established exit
2017.10.12 21:18:26 5: mySIP1[11366], 0. Ende des ersten Loops
2017.10.12 21:18:26 5: mySIP1[11366], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x484ea38)
2017.10.12 21:18:26 5: mySIP1[11366], 2. fi : 0
2017.10.12 21:18:26 5: mySIP1[11366], 3. timeout : 0
2017.10.12 21:18:26 4: mySIP1[11366], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.12 21:18:26 4: mySIP1[11366], cb_final - status : OK
2017.10.12 21:18:27 4: mySIP1[11366], loop rtp_done : Net::SIP::Simple::Call=HASH(0x484ea38)
2017.10.12 21:18:27 5: mySIP1[11366], RTP done : Net::SIP::Simple::Call=HASH(0x484ea38)
2017.10.12 21:18:27 5: mySIP1[11366], Timeout : 0
2017.10.12 21:18:27 5: mySIP1[11366], while : 0
2017.10.12 21:18:27 5: mySIP1[11366], Status : OK
2017.10.12 21:18:27 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.12 21:18:27 5: mySIP1, fifo is empty
2017.10.12 21:18:27 5: mySIP1, no elbc
list mySIP1
Internals:
NAME mySIP1
NOTIFYDEV myT2S
NR 639
NTFY_ORDER 50-mySIP1
STATE initialized
TYPE SIP
VERSION V1.54 / 07.04.17
READINGS:
2017-10-12 21:21:01 call done
2017-10-12 21:21:01 call_state ok
2017-10-12 21:21:01 call_success 1
2017-10-12 21:21:01 call_time 8
2017-10-17 19:28:57 state initialized
Attributes:
T2S_Device myT2S
room System
sip_audiofile_call /opt/fhem/SonosSpeak/Test.alaw
sip_call_audio_delay 3
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:IP-Telefon1@fritz.box
sip_ip 192.168.1.201
sip_listen none
sip_registrar fritz.box
sip_ringtime 90
sip_user IP-Telefon1
verbose 5
Hat jemand eine Idee?
Gruß moewe
Zitat von: moeweflieg am 17 Oktober 2017, 21:37:34
Die Änderung für sip_ringtime von 30 auf 90 bringt nichts!
Das glaube ich gern , denn sip_ringtime spielt für ausgehende Anrufe auch gar keine Rolle
Zitat von: command.refsip_ringtime
Ringtime for incomming calls (dtmf &wfp)
Entscheident ist die Zeit maxtime die du direkt beim Aufruf des Calls mitgibst
Zitat von: command.refset <name> call <number> [<maxtime>] [<message>]
Start a call to the given number.
Optionally you can supply a max time. Default is 30.
Bei deinem Call auf 0176555XXXXX war die Zeit vom Rufaufbau bis zum Abnehmen 10 Sekunden (21:18:13 - 21:18:23) danach wurde doch von dir abgehoben ???
Denn laut log wurde ja die Datei /opt/fhem/SonosSpeak/Test.alaw vollständig abgespielt und danach von dir aufgelegt.
D.h. nach diesem Log ist alles so abgelaufen wie es sein soll.
BTW: in deinem 0176555XXXXX log steht mehrfach noch deine vollständige Handynr......
Zitat von: Wzut am 12 Oktober 2017, 14:05:17
@frank, kannst du bitte mal die angehängte Version testen bevor ich sie einchecke ?
Sie hat zwei neue Readings : expire und listen_alive
Wenn das attribut sip_watch_listen nicht gesetzt ist (default 60) oder größer als 0 ist wird zyklisch der Timestamp von listen_alive und seinem Wert "yes" geprüft. Nach 180 Sekunden (3 Minuten) ohne Aktivität vom Child Prozess wird dieser gekillt und neu gestartet.
grundsätzlich scheint es zu funktionieren.
sip_watch_listen habe ich auf 90 gesetzt.
laut syslog, war das wlan während dieser zeit unterbrochen:
Oct 19 12:27:16 raspberrypi dhcpcd[701]: wlan0: carrier lost
Oct 19 12:31:42 raspberrypi dhcpcd[701]: wlan0: no IPv6 Routers available
fhem.log sieht dann so aus:
(der 2 min freeze von fhem wurde wohl durch das modul mailcheck wegen fehlendem wlan verursacht)
2017.10.19 12:25:28.508 4: triggerLiveCam[6144], register new expire : 2017-10-19 12:30:28
2017.10.19 12:25:28.508 5: triggerLiveCam[6144], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive yes set triggerLiveCam expire 2017-10-19 12:30:28 exit
2017.10.19 12:26:01.561 5: triggerLiveCam, listen process 6144 found
2017.10.19 12:27:01.599 5: triggerLiveCam, listen process 6144 found
2017.10.19 12:28:01.638 5: triggerLiveCam, listen process 6144 found
2017.10.19 12:29:01.677 2: triggerLiveCam, expire timestamp is 213 seconds old, restarting listen process
2017.10.19 12:29:01.702 1: Timeout for SIP_ListenStart reached, terminated process 6144
2017.10.19 12:29:03.719 4: triggerLiveCam, Listen new PID : 17784
2017.10.19 12:29:03.733 4: triggerLiveCam[17784], my parent is 3298
2017.10.19 12:29:03.739 2: triggerLiveCam[17784], cannot open port 5080 at 192.168.1.22: Cannot assign requested address
2017.10.19 12:29:03.750 5: triggerLiveCam, ListenDone -> triggerLiveCam|ListenRegister: can't open port 5080 or 5090 at 192.168.1.22: Cannot assign requested address
2017.10.19 12:29:03.767 3: triggerLiveCam, listen error -> ListenRegister: can't open port 5080 or 5090 at 192.168.1.22: Cannot assign requested address
2017.10.19 12:32:31.056 1: Perfmon: possible freeze starting at 12:30:27, delay is 124.056
2017.10.19 12:32:31.072 4: triggerLiveCam, Listen new PID : 17906
2017.10.19 12:32:31.087 4: triggerLiveCam[17906], my parent is 3298
2017.10.19 12:32:31.170 4: triggerLiveCam[17906], register new expire : 2017-10-19 12:37:31
2017.10.19 12:32:31.170 5: triggerLiveCam[17906], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive yes set triggerLiveCam expire 2017-10-19 12:37:31 exit
2017.10.19 12:32:31.210 5: triggerLiveCam[17906], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
2017.10.19 12:34:01.112 5: triggerLiveCam, listen process 17906 found
2017.10.19 12:35:01.155 5: triggerLiveCam, listen process 17906 found
2017.10.19 12:35:01.195 4: triggerLiveCam[17906], register new expire : 2017-10-19 12:40:01
2017.10.19 12:35:01.196 5: triggerLiveCam[17906], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive yes set triggerLiveCam expire 2017-10-19 12:40:01 exit
2017.10.19 12:36:01.193 5: triggerLiveCam, listen process 17906 found
mir ist allerdings noch nicht ganz klar, wo ich die 90s von sip_watch_listen erkennen kann.
Zitat von: frank am 19 Oktober 2017, 13:57:38
mir ist allerdings noch nicht ganz klar, wo ich die 90s von sip_watch_listen erkennen kann.
Ich sehe in deinem log auch nur 60 Sekunden und keine 90 :
2017.10.19 12:26:01.561 5: triggerLiveCam, listen process 6144 found
2017.10.19 12:27:01.599 5: triggerLiveCam, listen process 6144 found
2017.10.19 12:28:01.638 5: triggerLiveCam, listen process 6144 found
Hallo Wzut,
ich komme garnicht zum Abheben, es klingelt einmal und dann ist es vorbei!
Hab's mehrmals probiert, diesmal mit:
set mySIP1 call 0176555XXXXX 90
Keine Änderung im Zeitverhalten - als maxtime scheint trotzdem 30 verwendet zu werden (siehe log)!
2017.10.19 21:28:59 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.19 21:28:59 4: mySIP1, mySIP1|01765553496XXXXXX|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.19 21:28:59 4: mySIP1, call -> mySIP1|0176555XXXXX|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.19 21:28:59 5: mySIP1, call has pid 10849
2017.10.19 21:28:59 4: mySIP1[10849], my parent is 1319
2017.10.19 21:28:59 4: mySIP1[10849], using random port 44252
2017.10.19 21:28:59 4: mySIP1[10849], register new expire : Thu Oct 19 21:33:59 2017
2017.10.19 21:28:59 5: mySIP1[10849], telnet : set mySIP1 state calling exit
2017.10.19 21:28:59 4: mySIP1[10849], CallStart with 2 files - first file : CODE(0x4572a48) - PCMA/8000 , repeat 0
2017.10.19 21:28:59 4: mySIP1[10849], calling : 0176555XXXXX
2017.10.19 21:28:59 5: mySIP1[10849], telnet : set mySIP1 call_state calling 0176555XXXXX exit
2017.10.19 21:28:59 4: mySIP1[10849], cb_final - status : FAIL - final : 481
2017.10.19 21:28:59 5: mySIP1[10849], telnet : set mySIP1 call_state ringing exit
2017.10.19 21:29:09 4: mySIP1[10849], cb_final - status : OK
2017.10.19 21:29:09 4: mySIP1[10849], call established
2017.10.19 21:29:09 5: mySIP1[10849], telnet : set mySIP1 call_state established exit
2017.10.19 21:29:12 5: mySIP1[10849], 0. Ende des ersten Loops
2017.10.19 21:29:12 5: mySIP1[10849], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x146c680)
2017.10.19 21:29:12 5: mySIP1[10849], 2. fi : 0
2017.10.19 21:29:12 5: mySIP1[10849], 3. timeout : 0
2017.10.19 21:29:12 4: mySIP1[10849], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.19 21:29:12 4: mySIP1[10849], cb_final - status : OK
2017.10.19 21:29:13 4: mySIP1[10849], loop rtp_done : Net::SIP::Simple::Call=HASH(0x146c680)
2017.10.19 21:29:13 5: mySIP1[10849], RTP done : Net::SIP::Simple::Call=HASH(0x146c680)
2017.10.19 21:29:13 5: mySIP1[10849], Timeout : 0
2017.10.19 21:29:13 5: mySIP1[10849], while : 0
2017.10.19 21:29:13 5: mySIP1[10849], Status : OK
2017.10.19 21:29:13 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.19 21:29:13 5: mySIP1, fifo is empty
2017.10.19 21:29:13 5: mySIP1, no elbc
Gruß moewe
Guten Abend zusammen,
ich hätte da mal eine Frage da ich bis jetzt im Forum und Wiki und der commandref nichts zu meinem Problem gefunden habe.
In der FritzBox habe ich drei IP-Telefone angelegt. Jedes IP-Telefon hat eine eigene Nummer. Im FHEM habe ich auch drei SIP Clients definiert mit unterschiedlichen Anmeldenamen und Passwörter.
In FHEM kann ich mit dem Kommando:
set FB_SIP_client_1 0160123456
set FB_SIP_client_2 0160123456
set FB_SIP_client_3 0160123456
mein Handy anrufen und es wird auch die richtige Nummer angezeigt.
Soweit so gut, vielen Dank für diese Modul es funktioniert prima!!!
Wenn ich mir nun im FHEM die drei SIP-Clients angucke, haben zwei den state listen_echo und der dritte:
state error
last_error ListenRegister: can't open port 5070 or 5080 at 192.168.178.1: Address already in use
SIP_Client 1 und 2 dagegen:
state listen_echo
last_error ListenRegister: can't open port 5070 or 5080 at 192.168.178.1: Address already in use
Nun stellt sich mir die Frage, darf ich nur einen SIP-Client anlegen oder brauche ich für jeden SIP-Client einen eigenen Port?
Beste Grüße
Mikka
PS.: Meine definitionen sehen so aus:
define FB_SIP_client_1 SIP
attr FB_SIP_client_1 room System
attr FB_SIP_client_1 sip_dtmf_loop once
attr FB_SIP_client_1 sip_dtmf_send audio
attr FB_SIP_client_1 sip_dtmf_size 2
attr FB_SIP_client_1 sip_elbc yes
attr FB_SIP_client_1 sip_from sip:IP-Telefon-1@192.168.178.1
attr FB_SIP_client_1 sip_ip 192.168.1.2
attr FB_SIP_client_1 sip_listen echo
attr FB_SIP_client_1 sip_port 5060
attr FB_SIP_client_1 sip_registrar 192.168.178.1
attr FB_SIP_client_1 sip_ringtime 3
attr FB_SIP_client_1 sip_user IP-Telefon-1
define FB_SIP_client_2 SIP
attr FB_SIP_client_2 room System
attr FB_SIP_client_2 sip_dtmf_loop once
attr FB_SIP_client_2 sip_dtmf_send audio
attr FB_SIP_client_2 sip_dtmf_size 2
attr FB_SIP_client_2 sip_elbc yes
attr FB_SIP_client_2 sip_from sip:IP-Telefon-2@192.168.178.1
attr FB_SIP_client_2 sip_ip 192.168.1.2
attr FB_SIP_client_2 sip_listen echo
attr FB_SIP_client_2 sip_port 5060
attr FB_SIP_client_2 sip_registrar 192.168.178.1
attr FB_SIP_client_2 sip_ringtime 3
attr FB_SIP_client_2 sip_user IP-Telefon-2
define FB_SIP_client_3 SIP
attr FB_SIP_client_3 room System
attr FB_SIP_client_3 sip_dtmf_loop once
attr FB_SIP_client_3 sip_dtmf_send audio
attr FB_SIP_client_3 sip_dtmf_size 2
attr FB_SIP_client_3 sip_elbc yes
attr FB_SIP_client_3 sip_from sip:IP-Telefon-3@192.168.178.1
attr FB_SIP_client_3 sip_ip 192.168.1.2
attr FB_SIP_client_3 sip_listen echo
attr FB_SIP_client_3 sip_port 5060
attr FB_SIP_client_3 sip_registrar 192.168.178.1
attr FB_SIP_client_3 sip_ringtime 3
attr FB_SIP_client_3 sip_user IP-Telefon-3
Zitat von: moeweflieg am 19 Oktober 2017, 21:43:16
ich komme garnicht zum Abheben, es klingelt einmal und dann ist es vorbei!
Hab's mehrmals probiert, diesmal mit:
set mySIP1 call 0176555XXXXX 90
Keine Änderung im Zeitverhalten - als maxtime scheint trotzdem 30 verwendet zu werden (siehe log)!
a. das es nur 1x klingelt verstehe ich nicht zumal es nicht zum log passt :
2017.10.19 21:28:59 5: mySIP1[10849], telnet : set mySIP1 call_state ringing exit
2017.10.19 21:29:09 4: mySIP1[10849], cb_final - status : OK
D.h. laut log klingelte es 10 Sekunden und danach wurde abgenommen. Bist du ganz sicher das da nicht eine Art AB oder Rufumleitung greift ? Hast du mal versucht irgendeine andere Handy oder Festnetznummer anzurufen ?
b. warum im Log steht
2017.10.19 21:28:59 4: mySIP1, mySIP1|0176X|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.19 21:28:59 4: mySIP1, call -> mySIP1|0176X|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
wenn der Aufruf tatsächlich set mySIP1 call 0176X 90 war . Demnach hätte das Modul die 90 ignoriert und dein /opt/fhem/SonosSpeak/Test.alaw dazugepackt weil es im Attribut als default steht. Versuche doch bitte mal im set Befehl alles anzugeben :
set mySIP1 call 0176X 90 /opt/fhem/SonosSpeak/Test.alaw
Zitat von: Mikka am 19 Oktober 2017, 21:43:49
Nun stellt sich mir die Frage, darf ich nur einen SIP-Client anlegen oder brauche ich für jeden SIP-Client einen eigenen Port?
Kurze Antwort : nein & ja :)
Lange Antwort : Generell sind mehr als ein Client kein Problem allerdings benötigt jeder seinen Port bzw sogar zwei wenn auch listen aktiv ist. D.h. dein Fehler liegt im attr sip_port dort hast du bei jedem 5060 eingetragen. Entweder du änderst das in zb
5060 für den ersten , 5080 für den zweiten , 6000 für den dritten oder du löschst das Attribut komplett und überläßt dem Modul eine dynamische Port Zuteilung oberhalb von 44000 - siehe commandref
Zitatsip_port
Optinale Portnummer die vom Modul benutzt wird.
Wenn dem Attribut kein Wert zugewiesen wurde verwendet das Modul eine zufällige Portnummer zwichen 44000 und 45000
Im Allgemeinen solltest du dir aber überlegen ob es wirklich sinnvoll und nötig ist drei Clients und damit drei extra Prozesse gleichzeitig laufen zu lassen. OK ich hatte das bei der Modul Entwicklung auch damit ich nicht ständig Parameter anpassen musste, aber im täglichen Betrieb ? Zumal jetzt schon zwei nur im Modus listen_echo laufen.
Vllt. beschreibst ja mal deinen Anwendungsfall und warum es drei Clients sein müssen, ggf findet sich da auch eine elegantere Lösung.
Hallo Wzut,
es ist ganz sicher kein AB oder Rufumleitung im Spiel!
Mit folgenden Aufrufen auf Festnetz oder andere Handynummer gleiches (1xKlingeln):
set mySIP1 call 068X 90 /opt/fhem/SonosSpeak/Test.alaw
bzw. ähnliches Verhalten (kurzes Klingeln, auch mal kein Klingeln und kein Protokolleintrag im Handy):
set mySIP1 call 017624XXXXX 90 /opt/fhem/SonosSpeak/Test.alaw
2017.10.21 08:39:27 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.21 08:39:27 4: mySIP1, mySIP1|017624XXXXX|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.21 08:39:27 4: mySIP1, call -> mySIP1|017624XXXXX|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.21 08:39:27 5: mySIP1, call has pid 8090
2017.10.21 08:39:27 4: mySIP1[8090], my parent is 1319
2017.10.21 08:39:27 4: mySIP1[8090], using random port 44480
2017.10.21 08:39:27 4: mySIP1[8090], register new expire : Sat Oct 21 08:44:27 2017
2017.10.21 08:39:27 5: mySIP1[8090], telnet : set mySIP1 state calling exit
2017.10.21 08:39:28 4: mySIP1[8090], CallStart with 2 files - first file : CODE(0x44d0590) - PCMA/8000 , repeat 0
2017.10.21 08:39:28 4: mySIP1[8090], calling : 017624XXXXX
2017.10.21 08:39:28 5: mySIP1[8090], telnet : set mySIP1 call_state calling 017624XXXXX exit
2017.10.21 08:39:28 4: mySIP1[8090], cb_final - status : FAIL - final : 481
2017.10.21 08:39:28 5: mySIP1[8090], telnet : set mySIP1 call_state ringing exit
2017.10.21 08:39:37 4: mySIP1[8090], cb_final - status : OK
2017.10.21 08:39:37 4: mySIP1[8090], call established
2017.10.21 08:39:37 5: mySIP1[8090], telnet : set mySIP1 call_state established exit
2017.10.21 08:39:40 5: mySIP1[8090], 0. Ende des ersten Loops
2017.10.21 08:39:40 5: mySIP1[8090], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x40d2b68)
2017.10.21 08:39:40 5: mySIP1[8090], 2. fi : 0
2017.10.21 08:39:40 5: mySIP1[8090], 3. timeout : 0
2017.10.21 08:39:40 4: mySIP1[8090], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.21 08:39:40 4: mySIP1[8090], cb_final - status : OK
2017.10.21 08:39:42 4: mySIP1[8090], loop rtp_done : Net::SIP::Simple::Call=HASH(0x40d2b68)
2017.10.21 08:39:42 5: mySIP1[8090], RTP done : Net::SIP::Simple::Call=HASH(0x40d2b68)
2017.10.21 08:39:42 5: mySIP1[8090], Timeout : 0
2017.10.21 08:39:42 5: mySIP1[8090], while : 0
2017.10.21 08:39:42 5: mySIP1[8090], Status : OK
2017.10.21 08:39:42 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.21 08:39:42 5: mySIP1, fifo is empty
2017.10.21 08:39:42 5: mySIP1, no elbc
2017.10.21 08:26:21 4: mySIP1, mySIP1|068X|30|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.21 08:26:21 4: mySIP1, call -> mySIP1|068X|30|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.21 08:26:21 5: mySIP1, call has pid 7046
2017.10.21 08:26:21 4: mySIP1[7046], my parent is 1319
2017.10.21 08:26:21 4: mySIP1[7046], using random port 44421
2017.10.21 08:26:21 4: mySIP1[7046], register new expire : Sat Oct 21 08:31:21 2017
2017.10.21 08:26:21 5: mySIP1[7046], telnet : set mySIP1 state calling exit
2017.10.21 08:26:21 4: mySIP1[7046], CallStart with 2 files - first file : CODE(0x448a988) - PCMA/8000 , repeat 0
2017.10.21 08:26:21 4: mySIP1[7046], calling : 068X
2017.10.21 08:26:21 5: mySIP1[7046], telnet : set mySIP1 call_state calling 068X exit
2017.10.21 08:26:21 4: mySIP1[7046], cb_final - status : FAIL - final : 481
2017.10.21 08:26:21 5: mySIP1[7046], telnet : set mySIP1 call_state ringing exit
2017.10.21 08:26:31 4: mySIP1[7046], cb_final - status : OK
2017.10.21 08:26:31 4: mySIP1[7046], call established
2017.10.21 08:26:31 5: mySIP1[7046], telnet : set mySIP1 call_state established exit
2017.10.21 08:26:34 5: mySIP1[7046], 0. Ende des ersten Loops
2017.10.21 08:26:34 5: mySIP1[7046], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x40dc210)
2017.10.21 08:26:34 5: mySIP1[7046], 2. fi : 0
2017.10.21 08:26:34 5: mySIP1[7046], 3. timeout : 0
2017.10.21 08:26:34 4: mySIP1[7046], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.21 08:26:34 4: mySIP1[7046], cb_final - status : OK
2017.10.21 08:26:35 4: mySIP1[7046], loop rtp_done : Net::SIP::Simple::Call=HASH(0x40dc210)
2017.10.21 08:26:35 5: mySIP1[7046], RTP done : Net::SIP::Simple::Call=HASH(0x40dc210)
2017.10.21 08:26:35 5: mySIP1[7046], Timeout : 0
2017.10.21 08:26:35 5: mySIP1[7046], while : 0
2017.10.21 08:26:35 5: mySIP1[7046], Status : OK
2017.10.21 08:26:35 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.21 08:26:35 5: mySIP1, fifo is empty
2017.10.21 08:26:35 5: mySIP1, no elbc
Gruß moewe
Hallo Wzut,
kurzer Nachtrag und Sorry, dass ich Dich auf ein falsche Fährte geschickt habe.
Ich hatte im Modul 96_SIP.pm aus einem vorherigen Test noch $ringtime = 30; gesetzt, weil nach
set mySIP1 call 068X 90 !Hier ist dein FHEM Server
immer folgende Fehlermeldung kommt:
invalid max time : 90 !Hier
705 return "missing target call number" if (!$nr);
706 #return "invalid max time : $ringtime" unless $ringtime =~ m/^\d+$/;
707 $ringtime = 30;
Das Verhalten bleibt ohne diese Code-Änderung aber das gleiche:
2017.10.21 08:55:09 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.21 08:55:09 4: mySIP1, mySIP1|068X|90|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.21 08:55:09 4: mySIP1, call -> mySIP1|068X|90|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.21 08:55:09 5: mySIP1, call has pid 9453
2017.10.21 08:55:09 4: mySIP1[9453], my parent is 9243
2017.10.21 08:55:09 4: mySIP1[9453], using random port 44432
2017.10.21 08:55:09 4: mySIP1[9453], register new expire : Sat Oct 21 09:00:09 2017
2017.10.21 08:55:09 5: mySIP1[9453], telnet : set mySIP1 state calling exit
2017.10.21 08:55:09 4: mySIP1[9453], CallStart with 2 files - first file : CODE(0x4a9f2d0) - PCMA/8000 , repeat 0
2017.10.21 08:55:09 4: mySIP1[9453], calling : 068X
2017.10.21 08:55:09 5: mySIP1[9453], telnet : set mySIP1 call_state calling 06806989421 exit
2017.10.21 08:55:09 4: mySIP1[9453], cb_final - status : FAIL - final : 481
2017.10.21 08:55:09 5: mySIP1[9453], telnet : set mySIP1 call_state ringing exit
2017.10.21 08:55:19 4: mySIP1[9453], cb_final - status : OK
2017.10.21 08:55:19 4: mySIP1[9453], call established
2017.10.21 08:55:19 5: mySIP1[9453], telnet : set mySIP1 call_state established exit
2017.10.21 08:55:22 5: mySIP1[9453], 0. Ende des ersten Loops
2017.10.21 08:55:22 5: mySIP1[9453], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x4d1ae58)
2017.10.21 08:55:22 5: mySIP1[9453], 2. fi : 0
2017.10.21 08:55:22 5: mySIP1[9453], 3. timeout : 0
2017.10.21 08:55:22 4: mySIP1[9453], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.21 08:55:22 4: mySIP1[9453], cb_final - status : OK
2017.10.21 08:55:23 4: mySIP1[9453], loop rtp_done : Net::SIP::Simple::Call=HASH(0x4d1ae58)
2017.10.21 08:55:23 5: mySIP1[9453], RTP done : Net::SIP::Simple::Call=HASH(0x4d1ae58)
2017.10.21 08:55:23 5: mySIP1[9453], Timeout : 0
2017.10.21 08:55:23 5: mySIP1[9453], while : 0
2017.10.21 08:55:23 5: mySIP1[9453], Status : OK
2017.10.21 08:55:23 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.21 08:55:23 5: mySIP1, fifo is empty
2017.10.21 08:55:23 5: mySIP1, no elbc
Gruß moewe
Zitat von: Wzut am 20 Oktober 2017, 09:13:43
Kurze Antwort : nein & ja :)
Lange Antwort : Generell sind mehr als ein Client kein Problem allerdings benötigt jeder seinen Port bzw sogar zwei wenn auch listen aktiv ist. D.h. dein Fehler liegt im attr sip_port dort hast du bei jedem 5060 eingetragen. Entweder du änderst das in zb
5060 für den ersten , 5080 für den zweiten , 6000 für den dritten oder du löschst das Attribut komplett und überläßt dem Modul eine dynamische Port Zuteilung oberhalb von 44000 - siehe commandref
Danke für die Aufklärung :-) Die dynamische Port Zuteilung klappt und alle drei Clients haben den state listen_echo.
Zitat von: Wzut am 20 Oktober 2017, 09:13:43
Im Allgemeinen solltest du dir aber überlegen ob es wirklich sinnvoll und nötig ist drei Clients und damit drei extra Prozesse gleichzeitig laufen zu lassen. OK ich hatte das bei der Modul Entwicklung auch damit ich nicht ständig Parameter anpassen musste, aber im täglichen Betrieb ? Zumal jetzt schon zwei nur im Modus listen_echo laufen.
Vllt. beschreibst ja mal deinen Anwendungsfall und warum es drei Clients sein müssen, ggf findet sich da auch eine elegantere Lösung.
Eigentlich würde ich gerne nur einen Client nutzen. Mein Anwendungsfall ist der folgende:
Ich habe mehrere Geräte die einen Alarm melden z. B. Rauchmelder, Klingel, Wasser-Leck-Sensor, Raumluftqualität. Wenn ein Rauchmelder anschlägt möchte ich benachrichtigt werden. Telegram ist zwar eine super Lösung, doch wenn man z. B. in Deutschlands Wäldern oder Ausland unterwegs ist, hat man nicht unbedingt einen Datenempfang. Mobilfunk dagegen schon etwas mehr. Der Fritzbox kann ich jedem Fall eine eigene Nummer zuweisen. FHEM würde dann über den den entsprechenden SIP-Client einen Anruf ausgehend mit einer eigenen Telefonnummer ausführen.
Wenn ich mit einem SIP-Client mit unterschiedlichen Rufnummern ausgehend telefonieren kann, bin ich um jeden Tipp dankbar!
Mikka
Zitat von: moeweflieg am 21 Oktober 2017, 09:14:23
set mySIP1 call 068X 90 !Hier ist dein FHEM Server
immer folgende Fehlermeldung kommt:
invalid max time : 90 !Hier
Hmm auch komisch das in deinem Fall das Leerzeichen zwischen der 0 und dem ! nicht als solches erkannt wird, in dem Fall schlägt doch auch alles was nachfolgt fehl.
D.h. Die Textnachricht kann nicht mehr als solche erkannt werden dir ihr das ! als Startzeichen fehlt.
Aber anyway zu deinem eigentlichen Problem gehen mir langsam die Ideen aus, zumal bis jetzt noch niemand von ähnlichen Problemen berichtet hat.
Zitat von: Mikka am 21 Oktober 2017, 11:00:02
Wenn ich mit einem SIP-Client mit unterschiedlichen Rufnummern ausgehend telefonieren kann, bin ich um jeden Tipp dankbar!
Sorry aber das habe ich Modulseitig nicht in der Hand das macht die Fritte (bzw die PBX)
Aber verstehe ich das richtig dir kommt es bei der Art von Alamierung nur auf die QuellrufNr an, was die Quelle dann eigentlich so von sich gibt darauf achtetst du gar nicht. Ich würde es halt mit nur einer Rufnummer machen und dafür die Texte dynamisch. Ok, must du selbst am besten wissen, aber warum dann noch bei jedem Client das Attribut sip_listen auf echo setzen und nicht auf none ? Hier liegt IMHO die Ressource Verschwendung wegen der ständig laufenden drei extra Prozesse.
Zitat von: Wzut am 21 Oktober 2017, 13:47:14
Sorry aber das habe ich Modulseitig nicht in der Hand das macht die Fritte (bzw die PBX)
Das habe ich vermutet :(
Zitat von: Wzut am 21 Oktober 2017, 13:47:14
Aber verstehe ich das richtig dir kommt es bei der Art von Alamierung nur auf die QuellrufNr an, was die Quelle dann eigentlich so von sich gibt darauf achtetst du gar nicht.
Ja, da ich beliebig viele Nummern anlegen kann.
Zitat von: Wzut am 21 Oktober 2017, 13:47:14
Ich würde es halt mit nur einer Rufnummer machen und dafür die Texte dynamisch. Ok, must du selbst am besten wissen, aber warum dann noch bei jedem Client das Attribut sip_listen auf echo setzen und nicht auf none ? Hier liegt IMHO die Ressource Verschwendung wegen der ständig laufenden drei extra Prozesse.
Das ist ein guter Tipp mit den Texten. Du meinst die Texte die dann auf die Mailbox gesprochen werden?
Und ja das ist Ressourcen Verschwendung, werde ich auf none stellen. War auf echo da ich damit angefangen habe zu probieren was so alles möglich ist, auch in die andere Richtung ;-)
Danke dir für die schnelle Hilfe Wzut und wünsche ein schönes WE!
Mikka
Zitat von: Mikka am 21 Oktober 2017, 14:57:02
Du meinst die Texte die dann auf die Mailbox gesprochen werden?
ja genau - ich habe z.B. im täglichen Einsatz "Waschmaschine ist fertig" , "Trockner ist fertig" an interne RufNr. und allle Rauchmelder jeweils mit ihrem Namen und dem force Zusatz aufs Handy. Diverse Wassermelder und anderer Kleinkram fehlen zwar noch, aber das ist halt bei mir wie bei dem Schuster der ja bekanntlich auch die schlechtesten Schuhe hat ....
Zitat von: Wzut am 21 Oktober 2017, 15:54:12
ja genau - ich habe z.B. im täglichen Einsatz "Waschmaschine ist fertig" , "Trockner ist fertig" an interne RufNr. und allle Rauchmelder jeweils mit ihrem Namen und dem force Zusatz aufs Handy. Diverse Wassermelder und anderer Kleinkram fehlen zwar noch, aber das ist halt bei mir wie bei dem Schuster der ja bekanntlich auch die schlechtesten Schuhe hat ....
Hallo Wzut,
werde ich mal testen. Das Problem mit dem Schuster kenne ich nur all zu gut ... ;)
Mikka
Zitat von: Wzut am 21 Oktober 2017, 13:47:14
Hmm auch komisch das in deinem Fall das Leerzeichen zwischen der 0 und dem ! nicht als solches erkannt wird, in dem Fall schlägt doch auch alles was nachfolgt fehl.
D.h. Die Textnachricht kann nicht mehr als solche erkannt werden dir ihr das ! als Startzeichen fehlt.
Dazu fällt mir ein "Schatz, es ist nicht das wonach es aussieht". Vielleicht ist das Blank das du siehst gar kein ordinäres Blank (0x20). Hast du mal versucht den Set-String im Editor zu erfassen (neu eintippen!) und dann in die FHEM-Command-Zeile zu kopieren?
Hallo Wzut,
kann es sein, dass das Fehlverhalten auf meinen Telefonprovider (VSEnet) zurückzuführen ist?
Zu Hause habe ich 1und1 als Provider und dort funktioniert es bei sonst gleichen Einstellungen und Fritzbox mit gleicher Firmware.
Allerdings bleibt der Ruf nicht die angegenen 90sek, sondern höchstens 10sek anstehen - und die Logs unterscheiden sich nicht, egal ob ich abhebe und die Nachricht abhöre oder nicht!
Werde demnächst am zu überwachenden Standort auch auf 1und1 umstellen!
Gruß moewe
keine Ahnung , aber wie jetzt zu Hause mit 1&1 geht alles wie es soll oder klingelt es da auch bei der Gegenstelle nur 10 Sekunden ??
Ich kapiere halt nicht warum bei dir das Net::SIP Modul der Meinung ist die Gegenstelle hätte das Gespräch angnommen.
@frank, da von dir keine negativ Meldung kam, habe ich die geänderte Version als V1.6 jetzt eingecheckt - verfügbar morgen via Update
Zitat von: Wzut link=topic=67443.msg702917#msg702917
Ich kapiere halt nicht warum bei dir das Net::SIP Modul der Meinung ist die Gegenstelle hätte das Gespräch angnommen.
/quote]
Hallo, ich hatte ja ein paar Seiten vorher das gleiche Verhalten schonmal geschildert. Bei mir ist es mein Handy...
Gesendet von iPhone mit Tapatalk
Hallo Wzut,
hier die Logs:
Anruf ohne Abheben: (Es klingelt etwa 10 Sekunden)
2017.10.22 15:03:55 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.22 15:03:55 4: mySIP1, mySIP1|0176XXXXXXXX|90|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.22 15:03:55 4: mySIP1, call -> mySIP1|0176XXXXXXXX|90|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.22 15:03:55 5: mySIP1, call has pid 14996
2017.10.22 15:03:55 4: mySIP1[14996], my parent is 14122
2017.10.22 15:03:55 4: mySIP1[14996], using random port 44361
2017.10.22 15:03:55 4: mySIP1[14996], register new expire : Sun Oct 22 15:08:55 2017
2017.10.22 15:03:55 5: mySIP1[14996], telnet : set mySIP1 state calling exit
2017.10.22 15:03:55 4: mySIP1[14996], CallStart with 2 files - first file : CODE(0x2e286f0) - PCMA/8000 , repeat 0
2017.10.22 15:03:55 4: mySIP1[14996], calling : 0176XXXXXXXX
2017.10.22 15:03:55 5: mySIP1[14996], telnet : set mySIP1 call_state calling 0176XXXXXXXX exit
2017.10.22 15:03:55 4: mySIP1[14996], cb_final - status : FAIL - final : 481
2017.10.22 15:03:55 5: mySIP1[14996], telnet : set mySIP1 call_state ringing exit
2017.10.22 15:04:16 4: mySIP1[14996], cb_final - status : OK
2017.10.22 15:04:16 4: mySIP1[14996], call established
2017.10.22 15:04:16 5: mySIP1[14996], telnet : set mySIP1 call_state established exit
2017.10.22 15:04:19 5: mySIP1[14996], 0. Ende des ersten Loops
2017.10.22 15:04:19 5: mySIP1[14996], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x61375f0)
2017.10.22 15:04:19 5: mySIP1[14996], 2. fi : 0
2017.10.22 15:04:19 5: mySIP1[14996], 3. timeout : 0
2017.10.22 15:04:19 4: mySIP1[14996], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.22 15:04:19 4: mySIP1[14996], cb_final - status : OK
2017.10.22 15:04:20 4: mySIP1[14996], loop rtp_done : Net::SIP::Simple::Call=HASH(0x61375f0)
2017.10.22 15:04:20 5: mySIP1[14996], RTP done : Net::SIP::Simple::Call=HASH(0x61375f0)
2017.10.22 15:04:20 5: mySIP1[14996], Timeout : 0
2017.10.22 15:04:20 5: mySIP1[14996], while : 0
2017.10.22 15:04:20 5: mySIP1[14996], Status : OK
2017.10.22 15:04:20 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.22 15:04:20 5: mySIP1, fifo is empty
2017.10.22 15:04:20 5: mySIP1, no elbc
Anruf mit Abheben: (Audiofile wird abgespielt)
2017.10.22 15:04:27 4: mySIP1, audio file /opt/fhem/SonosSpeak/Test.alaw found
2017.10.22 15:04:27 4: mySIP1, mySIP1|0176XXXXXXXX|90|/opt/fhem/SonosSpeak/Test.alaw|0
2017.10.22 15:04:27 4: mySIP1, call -> mySIP1|0176XXXXXXXX|90|/opt/fhem/SonosSpeak/Test.alaw|0|0
2017.10.22 15:04:27 5: mySIP1, call has pid 15077
2017.10.22 15:04:27 4: mySIP1[15077], my parent is 14122
2017.10.22 15:04:27 4: mySIP1[15077], using random port 44128
2017.10.22 15:04:27 4: mySIP1[15077], register new expire : Sun Oct 22 15:09:27 2017
2017.10.22 15:04:27 5: mySIP1[15077], telnet : set mySIP1 state calling exit
2017.10.22 15:04:27 4: mySIP1[15077], CallStart with 2 files - first file : CODE(0x5eefe28) - PCMA/8000 , repeat 0
2017.10.22 15:04:27 4: mySIP1[15077], calling : 0176XXXXXXXX
2017.10.22 15:04:27 5: mySIP1[15077], telnet : set mySIP1 call_state calling 0176XXXXXXXX exit
2017.10.22 15:04:27 4: mySIP1[15077], cb_final - status : FAIL - final : 481
2017.10.22 15:04:27 5: mySIP1[15077], telnet : set mySIP1 call_state ringing exit
2017.10.22 15:04:37 4: mySIP1[15077], cb_final - status : OK
2017.10.22 15:04:37 4: mySIP1[15077], call established
2017.10.22 15:04:37 5: mySIP1[15077], telnet : set mySIP1 call_state established exit
2017.10.22 15:04:40 5: mySIP1[15077], 0. Ende des ersten Loops
2017.10.22 15:04:40 5: mySIP1[15077], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x6181528)
2017.10.22 15:04:40 5: mySIP1[15077], 2. fi : 0
2017.10.22 15:04:40 5: mySIP1[15077], 3. timeout : 0
2017.10.22 15:04:40 4: mySIP1[15077], next file : /opt/fhem/SonosSpeak/Test.alaw
2017.10.22 15:04:40 4: mySIP1[15077], cb_final - status : OK
2017.10.22 15:04:41 4: mySIP1[15077], loop rtp_done : Net::SIP::Simple::Call=HASH(0x6181528)
2017.10.22 15:04:41 5: mySIP1[15077], RTP done : Net::SIP::Simple::Call=HASH(0x6181528)
2017.10.22 15:04:41 5: mySIP1[15077], Timeout : 0
2017.10.22 15:04:41 5: mySIP1[15077], while : 0
2017.10.22 15:04:41 5: mySIP1[15077], Status : OK
2017.10.22 15:04:41 4: mySIP1, CALLDone -> mySIP1|1|ok
2017.10.22 15:04:41 5: mySIP1, fifo is empty
2017.10.22 15:04:41 5: mySIP1, no elbc
Gruß moewe
Das meine ich doch , bei dir sehen die Logs an der entscheidenden Stelle immer gleich aus :
2017.10.22 15:03:55 4: mySIP1[14996], cb_final - status : FAIL - final : 481
2017.10.22 15:03:55 5: mySIP1[14996], telnet : set mySIP1 call_state ringing exit
2017.10.22 15:04:16 4: mySIP1[14996], cb_final - status : OK
2017.10.22 15:04:16 4: mySIP1[14996], call established
um 15:03:55 status : FAIL - final : 481 , bedeutet der Ruf wurde aufgebaut aber ein Gespräch ist noch nicht zustande gekommen = FAIL , der Fehlercode 481 bedeutet ringing , d.h. es klingelt ab jetzt bei der Gegenstelle.
21 Sekunden später : cb_final - status : OK & call established
Die Gegenstelle hat den Hörer abgenommen und nun wird mit dem abspielen der Audiofiles begonnen, zuerst ein paar Sekunden lang Stille ( Sound of Silence , enstpricht dem Attribut sip_call_audio_delay) danach dein Test.alaw und das alles ohne Fehler. Wenn ich bei mir einen ankommenden Ruf abweise oder ganz schnell abnehme und wieder auflege sehen die Log ganz anders aus.
Zitat von: Wzut am 22 Oktober 2017, 19:31:44
@frank, da von dir keine negativ Meldung kam, habe ich die geänderte Version als V1.6 jetzt eingecheckt - verfügbar morgen via Update
prima, ist installiert und steht unter beobachtung.
allerdings bleibt weiterhin mit sip_watch_listen=90 die zeitdifferenz bei 60s.
2017.10.26 21:37:45.439 5 : triggerLiveCam, listen process 29040 found
2017.10.26 21:38:45.480 5 : triggerLiveCam, listen process 29040 found
2017.10.26 21:39:45.521 5 : triggerLiveCam, listen process 29040 found
ist aber kein problem, da ich die einstellmöglichkeit zur zeit nicht benötige. bei bedarf werde ich mir mal den code anschauen.
edit:
es sieht so aus, dass die zeit sip_watch_listen nur beim ersten mal wirkt. also zwischen "listen new pid xy" und dem folgenden "listen prozes xy found". bei allen weiteren wiederholungen wird immer 60s genutzt.
2017-10-26 21:54:24.188 Global global ATTR triggerLiveCam sip_watch_listen 95
2017.10.26 21:54:25.177 4 : triggerLiveCam, Listen Kill PID : 29040
2017.10.26 21:54:25.191 1 : Timeout for SIP_ListenStart reached, terminated process 29040
2017.10.26 21:54:25.194 4 : triggerLiveCam, Reset Listen done
2017.10.26 21:54:25.206 4 : triggerLiveCam, Listen new PID : 12073
2017-10-26 21:54:25.326 SIP triggerLiveCam listen_dtmf
2017-10-26 21:54:25.340 SIP triggerLiveCam expire: 2017-10-26 21:59:25
2017-10-26 21:54:25.357 SIP triggerLiveCam caller_state: waitting
2017.10.26 21:56:00.249 5 : triggerLiveCam, listen process 12073 found
017-10-26 21:56:55.341 SIP triggerLiveCam listen_dtmf
2017-10-26 21:56:55.354 SIP triggerLiveCam expire: 2017-10-26 22:01:55
2017.10.26 21:57:00.289 5 : triggerLiveCam, listen process 12073 found
2017.10.26 21:58:00.329 5 : triggerLiveCam, listen process 12073 found
2017.10.26 21:59:00.369 5 : triggerLiveCam, listen process 12073 found
2017-10-26 21:59:25.368 SIP triggerLiveCam listen_dtmf
2017-10-26 21:59:25.380 SIP triggerLiveCam expire: 2017-10-26 22:04:25
2017.10.26 22:00:00.409 5 : triggerLiveCam, listen process 12073 found
2017.10.26 22:00:14.684 5 : triggerLiveCam , SIP_Attr : reset
2017-10-26 22:00:14.696 Global global ATTR triggerLiveCam sip_watch_listen 40
2017.10.26 22:00:15.686 4 : triggerLiveCam, Listen Kill PID : 12073
2017.10.26 22:00:15.686 1 : Timeout for SIP_ListenStart reached, terminated process 12073
2017.10.26 22:00:15.690 4 : triggerLiveCam, Reset Listen done
2017.10.26 22:00:15.703 4 : triggerLiveCam, Listen new PID : 12270
2017-10-26 22:00:15.821 SIP triggerLiveCam listen_dtmf
2017-10-26 22:00:15.835 SIP triggerLiveCam expire: 2017-10-26 22:05:15
2017.10.26 22:00:55.747 5 : triggerLiveCam, listen process 12270 found
2017.10.26 22:01:55.787 5 : triggerLiveCam, listen process 12270 found
2017-10-26 22:02:45.838 SIP triggerLiveCam listen_dtmf
2017-10-26 22:02:45.851 SIP triggerLiveCam expire: 2017-10-26 22:07:45
2017.10.26 22:02:55.827 5 : triggerLiveCam, listen process 12270 found
gruss frank
Zitat von: frank am 26 Oktober 2017, 22:24:35
allerdings bleibt weiterhin mit sip_watch_listen=90 die zeitdifferenz bei 60s.
Ja ist ein uralt Fehler von mir, an der entsprechenden Stelle ist noch eine feste 60 drin statt der zuständigen Variable.
Ich habe jetzt auch noch einen Schönheitsfehler gefunden mit den beiden neuen Readings, diese werden beim einem ausgehenden Ruf auch aktualisiert bzw. angelegt. Beides wird im nächsten Update (vermutlich am WE ) gefixt sein.
Zitat von: Wzut am 27 Oktober 2017, 11:11:57
Beides wird im nächsten Update (vermutlich am WE ) gefixt sein.
könntest du dann eventuell noch das reading listen_alive mit der aktuellen pid des listenprocesses ergänzen?
dann könnte man bei gesetztem event-on-change/timestamp-on-change sofort den letzten reset erkennen.
wenns scheeee macht ... :P dann ersetze ich das yes durch die PID
Hallo zusammen
Ich möchte das SIP Module nur als "Anrufliste" nutzen, das heisst keine abgehende Call's und bei ankommenden Anrufen, soll das Device nicht abnehmen. Jedoch bin ich mir nicht sicher, ob ich die entsprechenden Atrribute richtig gesetzt habe für diesen Zweck, da ich im Log immer wieder folgende Einträge finde:
2017.10.29 11:05:10 1: Timeout for SIP_ListenStart reached, terminated process 16803
2017.10.29 11:05:10 2: FHEM_Phone, expire timestamp is 181 seconds old, restarting listen process
Ein List sieht bei mir wie folgt aus:
Internals:
LPID 18530
NAME FHEM_Phone
NOTIFYDEV global
NR 1315
NTFY_ORDER 50-FHEM_Phone
STATE listen_wfp
TYPE SIP
VERSION V1.6 / 22.10.17
READINGS:
2017-10-29 08:39:33 caller none
2017-10-29 08:39:33 caller_state hangup
2017-10-29 08:39:33 caller_time 1509262773.0154
2017-10-29 11:16:26 expire 2017-10-29 11:31:25
2017-10-29 11:16:26 listen_alive yes
2017-10-29 11:16:26 state listen_wfp
helper:
LISTEN_PID:
abortArg
abortFn
arg FHEM_Phone
bc_pid 42
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 18530
timeout
Attributes:
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:220@192.168.1.1
sip_ip 192.168.1.12
sip_listen wfp
sip_port 5060
sip_registrar 192.168.1.1
sip_ringtime 3
sip_user username
sip_waittime 60
verbose 0
Ist das so richtig für meinen Zweck "Anrufliste"?
Danke
Das darfst du nicht zusammen in einenTopf werfen , also der Reihe nach :
Das Modul soll nie abnehmen - kein Problem. Damit es aber überhaupt mitbekommt das es angerufen wurde muß zwingend eine Art des Listen Prozess laufen.
Du hast dich für listen_wfp entschieden. Soweit gut, solltest aber ein Auge auf sip_waittime habe da das die Zeit ist nach der das Modul den Ruf automatisch annimmt.
Deine 60 Sekunden erscheinen mit dafür ausreichend, kannst aber bei Bedarf den Wert noch größer machen falls du mal feststellst das es doch vorkommt das das Gespräch angenommen wird (was du ja nicht willst)
Die Aufgabenstellung lässt sich allerdings auch mit einer anderen Art von listen lösen , z.B mit listen_echo. Um nun zu verhindern das das Gespräch angenommen wird muss man mit dem Attribut sip_filter arbeiten in dem man es z.B. auf einen Wert (bzw. Teil einer Telefon Nr ) setzt der nie erfüllt wird , z.B. 00000
D.h. das Gespräch würde jetzt nur angenommen werden wenn in der Quellrufnummer die Kombination 00000 vorkommt.
Welche der beiden Versionen du nun nimmst ist eine reine Geschmacksfrage :)
Kommen wir damit zum ersten Teil deiner Frage, die Meldungen im Log. Sind ja recht neu da ich diese Art der Überwachung erst letzte Woche dazugenommen habe.
Wenn ein listen Prozess läuft (und das muss bei dir unbedingt sein) meldet der sich ca. alle 150 Sekunden bei seinem Sip Server (z.B. FritzBox) was mit gut bei einem Log mit min verbose 4 verfolgen kann. Ist bei dem Meldeversuch der Sip Server nicht erreichbar (siehe das Problem von frank mit seinem Wlan) beendet das Hauptprogramm diesen Listen Prozess und startet ihn neu. Laut deinem Log ist das nach 181 Sekunden passiert, d.h. die positve Rückmeldung war 31 Sekunden über der Zeit. Starte doch mal ein Log mit min verbose 4 oder besser 5 eventuell sieht man dann mehr was bei dir schief läuft.
Hallo Wzut
Danke! Ich habe mich für deine zweite Variante entschieden mit listen_echo und die Attribute wie folgt gesetzt:
Attributes:
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_filter 00000000
sip_from sip:220@192.168.1.1
sip_ip 192.168.1.12
sip_listen echo
sip_port 5060
sip_registrar 192.168.1.1
sip_ringtime 3
sip_user username
verbose 5
Im Log mit Verbose 5 habe ich dann immer die folgenden Einträge:
2017.10.29 18:14:47 5: FHEM_Phone[4203], telnet : set FHEM_Phone state listen_echo set FHEM_Phone listen_alive yes set FHEM_Phone expire 2017-10-29 18:29:47 exit
2017.10.29 18:14:47 4: FHEM_Phone[4203], register new expire : 2017-10-29 18:29:47
2017.10.29 18:14:46 4: FHEM_Phone[4203], my parent is 782
2017.10.29 18:14:46 4: FHEM_Phone, Listen new PID : 4203
2017.10.29 18:14:44 1: Timeout for SIP_ListenStart reached, terminated process 3830
2017.10.29 18:14:44 2: FHEM_Phone, expire timestamp is 181 seconds old, restarting listen process
2017.10.29 18:13:44 5: FHEM_Phone, listen process 3830 found
2017.10.29 18:12:43 5: FHEM_Phone, listen process 3830 found
2017.10.29 18:11:42 5: FHEM_Phone[3830], telnet : set FHEM_Phone state listen_echo set FHEM_Phone listen_alive yes set FHEM_Phone expire 2017-10-29 18:26:42 exit
2017.10.29 18:11:42 4: FHEM_Phone[3830], register new expire : 2017-10-29 18:26:42
2017.10.29 18:11:42 4: FHEM_Phone[3830], my parent is 782
2017.10.29 18:11:42 4: FHEM_Phone, Listen new PID : 3830
2017.10.29 18:11:39 1: Timeout for SIP_ListenStart reached, terminated process 3456
2017.10.29 18:11:39 2: FHEM_Phone, expire timestamp is 182 seconds old, restarting listen process
2017.10.29 18:10:38 5: FHEM_Phone, listen process 3456 found
2017.10.29 18:09:38 5: FHEM_Phone, listen process 3456 found
2017.10.29 18:08:37 5: FHEM_Phone[3456], telnet : set FHEM_Phone state listen_echo set FHEM_Phone listen_alive yes set FHEM_Phone expire 2017-10-29 18:23:37 exit
2017.10.29 18:08:37 4: FHEM_Phone[3456], register new expire : 2017-10-29 18:23:37
2017.10.29 18:08:37 4: FHEM_Phone[3456], my parent is 782
2017.10.29 18:08:37 4: FHEM_Phone, Listen new PID : 3456
2017.10.29 18:08:35 1: Timeout for SIP_ListenStart reached, terminated process 2969
2017.10.29 18:08:35 2: FHEM_Phone, expire timestamp is 241 seconds old, restarting listen process
2017.10.29 18:07:34 5: FHEM_Phone, listen process 2969 found
2017.10.29 18:06:34 5: FHEM_Phone, listen process 2969 found
2017.10.29 18:04:32 1: Timeout for SIP_ListenStart reached, terminated process 2583
2017.10.29 18:01:27 1: Timeout for SIP_ListenStart reached, terminated process 2190
2017.10.29 17:58:23 1: Timeout for SIP_ListenStart reached, terminated process 1813
2017.10.29 17:55:20 1: Timeout for SIP_ListenStart reached, terminated process 1320
2017.10.29 17:51:16 1: Timeout for SIP_ListenStart reached, terminated process 826
2017.10.29 17:47:12 1: Timeout for SIP_ListenStart reached, terminated process 456
Dazu sagen muss ich noch, dass ich keine Fritzbox einsetze, sondern den Standard-Router meines Internet-Provider.
Danke vielmals und Grüsse Dani
ahh alles klar :) Ich bin bisher dvon ausgegangen diese Wiederholzeit von expire/ 2 = 150 Sekunden sei statisch. In Wahrheit scheint sie aber vom verwendeteten SIP Server abhängig zu sein. D.h in deinem Fall keine 5 Minuten sondern 15 :
2017.10.29 18:08:37 4: FHEM_Phone[3456], register new expire : 2017-10-29 18:23:37
18:23:37 - 18:08:37 = 15 , folglich wird die Wiederholung erst nach 7,5 Minuten stattfinden und nicht nach 2,5
Ich muss hier nochmal nachbessern, in der Zwischenzeit such mal im Modul 19_SIP.pm diese Zeile :
if (($age >180) && ($alive eq "yes")) # nach max 150 Sekunden sollte sich der listen Prozess erneut melden
müsste so bei Zeile 1420 sein. Ändere da die 180 in 500 oder 450 und lade das Modul neu.
Zitat von: Wzut am 29 Oktober 2017, 18:58:39
if (($age >180) && ($alive eq "yes")) # nach max 150 Sekunden sollte sich der listen Prozess erneut melden
müsste so bei Zeile 1420 sein. Ändere da die 180 in 500 oder 450 und lade das Modul neu.
Das hat geholfen! Keine entsprechenden Logeinträge mehr vorhanden.
Nochmals Danke und Gruss Dani
OK, ich habe eben eine Version hochgeladen , Kennung "V1.61 / 30.10.17"
Fix : expire Zeiten != 300 Sekunden werden berücksichtigt
Zitat von: Wzut am 30 Oktober 2017, 14:45:16
OK, ich habe eben eine Version hochgeladen , Kennung "V1.61 / 30.10.17"
Fix : expire Zeiten != 300 Sekunden werden berücksichtigt
die version hat leider noch ein problemchen:
2017.10.30 15:48:33.659 2: triggerLiveCam, expire timestamp is 562 seconds old, restarting listen process
2017.10.30 15:48:33.682 1: Timeout for SIP_ListenStart reached, terminated process 12705
2017.10.30 15:48:35.699 4: triggerLiveCam, Listen new PID : 12746
2017.10.30 15:48:35.714 4: triggerLiveCam[12746], my parent is 12330
2017.10.30 15:48:35.799 4: triggerLiveCam[12746], register new expire : 2017-10-30 15:53:35
2017.10.30 15:48:35.800 5: triggerLiveCam[12746], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive PID_12746 set triggerLiveCam expire 300 exit
2017.10.30 15:48:35.838 5: triggerLiveCam[12746], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
2017.10.30 15:49:35.743 2: triggerLiveCam, expire timestamp is 624 seconds old, restarting listen process
2017.10.30 15:49:35.762 1: Timeout for SIP_ListenStart reached, terminated process 12746
2017.10.30 15:49:37.780 4: triggerLiveCam, Listen new PID : 12788
2017.10.30 15:49:37.794 4: triggerLiveCam[12788], my parent is 12330
2017.10.30 15:49:37.878 4: triggerLiveCam[12788], register new expire : 2017-10-30 15:54:37
2017.10.30 15:49:37.878 5: triggerLiveCam[12788], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive PID_12788 set triggerLiveCam expire 300 exit
2017.10.30 15:49:37.915 5: triggerLiveCam[12788], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
2017.10.30 15:50:37.824 2: triggerLiveCam, expire timestamp is 686 seconds old, restarting listen process
2017.10.30 15:50:37.850 1: Timeout for SIP_ListenStart reached, terminated process 12788
2017.10.30 15:50:39.868 4: triggerLiveCam, Listen new PID : 12829
2017.10.30 15:50:39.882 4: triggerLiveCam[12829], my parent is 12330
2017.10.30 15:50:39.969 4: triggerLiveCam[12829], register new expire : 2017-10-30 15:55:39
2017.10.30 15:50:39.970 5: triggerLiveCam[12829], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive PID_12829 set triggerLiveCam expire 300 exit
2017.10.30 15:50:40.006 5: triggerLiveCam[12829], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
2017.10.30 15:51:39.912 2: triggerLiveCam, expire timestamp is 748 seconds old, restarting listen process
2017.10.30 15:51:39.927 1: Timeout for SIP_ListenStart reached, terminated process 12829
2017.10.30 15:51:41.946 4: triggerLiveCam, Listen new PID : 12872
2017.10.30 15:51:41.960 4: triggerLiveCam[12872], my parent is 12330
2017.10.30 15:51:42.050 4: triggerLiveCam[12872], register new expire : 2017-10-30 15:56:42
2017.10.30 15:51:42.051 5: triggerLiveCam[12872], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive PID_12872 set triggerLiveCam expire 300 exit
2017.10.30 15:51:42.087 5: triggerLiveCam[12872], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
2017.10.30 15:52:41.990 2: triggerLiveCam, expire timestamp is 810 seconds old, restarting listen process
2017.10.30 15:52:42.012 1: Timeout for SIP_ListenStart reached, terminated process 12872
2017.10.30 15:52:44.030 4: triggerLiveCam, Listen new PID : 12915
2017.10.30 15:52:44.044 4: triggerLiveCam[12915], my parent is 12330
2017.10.30 15:52:44.128 4: triggerLiveCam[12915], register new expire : 2017-10-30 15:57:44
2017.10.30 15:52:44.128 5: triggerLiveCam[12915], telnet : set triggerLiveCam state listen_dtmf set triggerLiveCam listen_alive PID_12915 set triggerLiveCam expire 300 exit
2017.10.30 15:52:44.166 5: triggerLiveCam[12915], telnet : set triggerLiveCam caller none set triggerLiveCam caller_state waitting exit
das alter des expire_timestamps steigt seit fhem neustart kontinuirlich an.
edit:
es liegt wohl an meinen attributen, da bei mir das reading expire keinen neuen timestamp bekommt (event-on-change/timestamp-on-change). mit event-on-update für expire läuft es.
Hallo,
leider habe ich keine FritzBox, sondern einen DrayTek Vigor2760Vn und die Telekom als VoIP-Provider.
FHEM läuft bei mir auf einem Raspberry Pi und von dort möchte ich bei einem Alarm mein Handy anrufen.
Im Router kann ich keine virtuellen Telefone erstellen, deshalb meine Frage:
Kann ich mit dem SIP-Modul die Telekom auch direkt zum Anrufen bewegen ?,
oder benötige ich zwingend eine Fritzbox, oder Telefonanlage die das kann.
Zudem würde mich interessieren, ob das SIP-Modul nonblocking läuft.
1. Das Modul sollte eigentlich mit jeder Art von SIP Server klar kommen. Wenn du hier mal etwas liest findest ausser FB Nutzer auch Vertreter von Asterisk oder externen SIP Providern ( eventuell schau dir mal www.sipgate.de an )
2. ja Nonblocking beide beide Richtungen, d.h. der Listen Prozess für ankommende Rufe läuft eigenständig, ebenso ein Call für abgehende.
Hallo Wzut,
ich muss noch erwähnen, dass mein Vigor-Router bereits als SIP-Client konfiguriert ist,
also mein analoges Telefon daran angeschlossen ist.
In der Router-Konfiguration musste ich für die Telekom-Voip-Einrichtung einen STUN-Server angeben,
im SIP-Modul vermisse ich vergleichbare Einstellmöglichkeiten.
STUN kommt im verwendeten Net::SIP von Steffen Ullrich nicht vor, daher gibt es auch am Modul dazu keinen Parameter.
Laut Wiki ( bzw. so wie ich es verstanden habe , man möge mich bitte verbessern ) -> https://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
wird mit Hilfe des STUN Server ermittelt wie dein SIP Client zum Ziel bzw. durch deine Firewall kommt.
Teste doch mal mit einem sip_port ungleich 5060/5070 und einem Portforwarding auf deinem Router.
Hallo zusammen,
bei einem Anruf erkennt mein SIP device zwar den Anrufer, aber erkennt das auflegen vom Anrufer nicht. Eigentlich sollte caller_state irgendwann mal hangup anzeigen, Dies geschieht bei mir aber nie.
Dieses list obelix ist nach dem auflegen entstanden. Der Client hängt an einem Asterisk.
Internals:
AC /usr/bin/sox
LPID 32706
NAME obelix
NOTIFYDEV T2S
NR 809
NTFY_ORDER 50-obelix
STATE listen_wfp
TYPE SIP
VERSION V1.61 / 30.10.17
READINGS:
2017-11-04 14:07:16 call done
2017-11-04 14:07:16 call_state peer hangup
2017-11-04 14:07:16 call_success 0
2017-11-04 14:07:16 call_time 3
2017-11-04 15:33:52 caller casi sip:001766***@192.168.2.200
2017-11-04 15:35:13 caller_state ringing_81
2017-10-24 12:32:37 caller_time 1508841157.05653
2017-11-04 15:29:47 expire 900
2017-10-31 11:00:41 last_error ListenRegister: can't open port 44844 or 44854 at 192.168.2.247: Die angeforderte Adresse kann nicht zugewiesen werden
2017-11-04 15:29:47 listen_alive PID_32706
2017-11-04 15:29:47 state listen_wfp
helper:
LISTEN_PID:
abortArg
abortFn
arg obelix
bc_pid 2771
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 32706
timeout
Attributes:
T2S_Device T2S
audio_converter sox
room 99 System
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:obelixSIP@192.168.2.200
sip_ip 192.168.2.247
sip_listen wfp
sip_registrar 192.168.2.200
sip_ringtime 3
sip_user obelixSIP
sip_waittime 3000
hat jemand eine Idee für mich ?
Gruß und danke für die Hilfe
spontan fällt mir da auf :
sip_listen wfp
sip_waittime 3000
D.h. du nutzt den Mode wfp und 3000 Sekunden bis das Gespräch angenommen werden soll.
Was passiert denn wenn die 50 Minuten um sind ?
Wie schaut denn deine Anwendung aus ? Sicher das wfp für dich die richtige Betriebsart ist ?
Je nachdem was passieren soll ist eine Kombination aus sip_filter/sip_blocking evtl. zielführend.
Auch von mir erst einmal einen fettes Daumen hoch für diese Modul.
Zitat von: RitterSport am 23 Juni 2017, 16:26:02
Ich kann es drehen und wenden wie ich möchte, aber ich bekomme es NICHT hin das das Telefone nicht weniger als 10 mal klingelt.
set Klingel_Telefon **610 01 -> minimum 10 x klingeln
set Klingel_Telefon **610 1 -> minimum 10 x klingeln
set Klingel_Telefon **610 5 -> dito
Genau das Problem habe ich auch. Da ich ansatzweise das SIP-Protokoll verstehe, habe ich neben dem Log mal einen tcpdump auf dem FHEM-System gemacht und das finde ich nicht schön.
Zwar ist es bei Digest Authentication normal, dass ein Register als unauthorized abgelehnt wird und dann neu versucht wird, aber das in dem Spiel das Modul am Ende bereits 6 Bindings zur Fritte hat sollte eher nicht so sein. Genauso verrückt sieht der Rufaufbau aus: Zuerst ein Invite, dass wird mit Unauthorizied abgelehnt und dann aber doch ein ACK und dann ein neues Invite und die Fritte wählt los. Und das alles auf der gleichen CallID.. Das mag ja alles legitim sein, aber ich finde es auf jeden Fall spannend.
Ähnlich sieht es auch am gewünschten Rufende aus: FHEM schickt ein Bye, Fritte sagt erst Cancelled, dann ok und klingelt munter weiter.
Da scheint das Net::SIP doch einige Schwächen, oder zumindest Meinungsverschiedenheiten mit Onkel Fritz zu haben, denn mit anderen SIPClients gibt es an der Fritte keine Probleme.
getracte Grüße
Niels
Zitat von: Wzut am 04 November 2017, 17:42:08
spontan fällt mir da auf :
sip_listen wfp
sip_waittime 3000
D.h. du nutzt den Mode wfp und 3000 Sekunden bis das Gespräch angenommen werden soll.
Was passiert denn wenn die 50 Minuten um sind ?
Wie schaut denn deine Anwendung aus ? Sicher das wfp für dich die richtige Betriebsart ist ?
der Client schaltet bisher die Anrufweiterschaltung der Telefonanlage und soll keine Anrufe an nehmen.
Nun ist sip_waittime 3 & attr obelix sip_ringtime 300 eingestellt. das löst aber mein Problem nicht.
Bei sip_listen none wird ein Anruf ja garnicht war genommen. Ich möchte aber bei einem Anruf eine Hue blinken lassen, aber nur bis zum auflegen also caller_state waitting.
Gruß und danke für deine Fragen :)
Zitat von: Muschelpuster am 05 November 2017, 10:33:47
Auch von mir erst einmal einen fettes Daumen hoch für diese Modul.
Danke :)
Zitat von: Muschelpuster am 05 November 2017, 10:33:47
scheint das Net::SIP doch einige Schwächen, oder zumindest Meinungsverschiedenheiten mit Onkel Fritz zu haben
Wenn du schon solche Erkentnisse hast und auch noch offensichtlich das entsprechendes SIP KnowHow wäre es dann nicht sinnvoll du würdest mal Kontakt mit Steffen Ullrich aufnehmen ? Ich denke er entwickelt sein Net::SIP noch immer weiter und wenn dort Bugs beseitigt werden kommt uns das doch allen wieder zu Gute.
Zitat von: geiercasi am 05 November 2017, 11:38:32
Ich möchte aber bei einem Anruf eine Hue blinken lassen, aber nur bis zum auflegen also caller_state waitting.
ja wie beim letzten Fall, reine Anklingel Maschine. IMHO müsste da ein extra Listen Modus her um diese Fälle elegant abzudecken. Ich habe da bei mir auch so einen Einsatzfall im Hinterkopf, mal schauen wie die nächste Zeit Luft ist um mir über das Thema mal ein paar Gedanken zu machen.
Zitat von: Wzut am 05 November 2017, 13:06:43
ja wie beim letzten Fall, reine Anklingel Maschine. IMHO müsste da ein extra Listen Modus her um diese Fälle elegant abzudecken. Ich habe da bei mir auch so einen Einsatzfall im Hinterkopf, mal schauen wie die nächste Zeit Luft ist um mir über das Thema mal ein paar Gedanken zu machen.
@wzut: Denk an sip_filter/sip_blocking. Die hatten wir denke ich für genau so einen Fall vorgesehen. Statuseinzeige der SIP-Connection aber der Client soll nicht drangehen. Ist aber auch schon eine Weile her. Die Konstellation müsste ich auch erst noch mal durchspielen.
Hallo Wzut,
Zitat von: Wzut am 03 November 2017, 11:46:48
1. Das Modul sollte eigentlich mit jeder Art von SIP Server klar kommen. Wenn du hier mal etwas liest findest ausser FB Nutzer auch Vertreter von Asterisk oder externen SIP Providern ( eventuell schau dir mal www.sipgate.de an )
Port-Forwarding habe ich eingerichtet.
Die Attribute vom SIP-Module sind:
T2S_Device: myT2S
sip_dtmf_loop: once
sip_dtmf_send: audio
sip_dtmf_size: 2
sip_elbc: yes
sip_from: sip:+491111111@tel.t-online.de
sip_ip: 192.168.1.16
sip_listen: none
sip_port: 5080
sip_registrar: tel.t-online.de
sip_ringtime: 3
sip_user: X.yyyyyy@t-online.de
verbose: 5
Telefonnummer habe ich hier auf 111111 geändert.
Die "sip_ip" ist die meines Raspberry auf dem fhem läuft.
Leider weis ich nicht so recht was ich unter "sip_from" eingeben soll,
die Beispiele die ich bisher gesehen habe beziehen sich alle auf eine FB
Wenn ich jetzt anrufen versuche erscheint folgendes im Log:
2017.11.05 16:22:25 4: TelefonAnruf, calling 01111111, ringtime: 30 , no message
2017.11.05 16:22:25 4: TelefonAnruf, TelefonAnruf|01111111|30||0
2017.11.05 16:22:25 4: TelefonAnruf, call -> TelefonAnruf|01111111|30||0|0
2017.11.05 16:22:25 5: TelefonAnruf, call has pid 21245
2017.11.05 16:22:25 4: TelefonAnruf[21245], my parent is 2206
2017.11.05 16:22:26 4: TelefonAnruf[21245], register new expire : Sun Nov 5 16:33:26 2017
2017.11.05 16:22:26 5: TelefonAnruf[21245], telnet : set TelefonAnruf state calling exit
2017.11.05 16:22:26 4: TelefonAnruf[21245], CallStart DTMF : ABCD*#123--4567890
Can't use string ("01111111") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Telefonnummer hier wieder ausgetauscht.
Ich habe mich mal bei sipgate.de angemeldet und versuch es nach Freischaltung auch damit.
Zitat von: sojos am 05 November 2017, 16:48:11
Can't use string ("01111111") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Da müssen wir zuerst ansetzen, der Fehler findet sich hier und im alten im Fred recht oft : zu alte Version von Net::SIP !
Am besten via CPAN das altuelle Net::SIP installieren -> sudo cpan install Net::SIP
@plin , ja da war was ... aber bedingt duch mein Alter hab ich es schon wieder vergessen und muss wieder im Quelltext suchen,
wenn du es nicht für mich zum einfachen nachlesen ins Wiki schreibst :)
Zitat von: Wzut am 05 November 2017, 13:06:43Wenn du schon solche Erkentnisse hast und auch noch offensichtlich das entsprechendes SIP KnowHow wäre es dann nicht sinnvoll du würdest mal Kontakt mit Steffen Ullrich aufnehmen ? Ich denke er entwickelt sein Net::SIP noch immer weiter und wenn dort Bugs beseitigt werden kommt uns das doch allen wieder zu Gute.
Da bin ich mir nicht ganz so sicher, wenn ich unter https://metacpan.org/pod/distribution/Net-SIP/lib/Net/SIP.pod#COPYRIGHT schaue:
ZitatThis module and are modules in the Net::SIP Hierarchy distributed together with this module are copyright (c) 2006-2013, Steffen Ullrich. All Rights Reserved.
Wobei ich die aktuelle Version 0.810 wohl vom 08.08.17 ist, wenn ich die Seite richtig deute.
Wie geschrieben verstehe ich als gelernter Telefoner ansatzweise SIP, aber grundsätzlich ist SIP IMHO schon recht schwierig. Der Erfolg beruht keineswegs darauf, dass SIP das perfekte Protokoll ist, sondern einfach nur, dass es als textbasiertes Protokoll relativ leicht zu programmieren ist. Dafür verbraucht es aber z.B. viel mehr Protokolloverhead sowie Rechenleistung zum Parsen des Protokolls gegenüber z.B. H.323, was HEX-kodiert arbeitet. In unserem Umfeld kein Thema, im Enterprise-Sektor schon. Zudem ist SIP aber eben nur 'weich' über eine RFC definiert, was immer Interpretationsspielraum zulässt und so auch mein täglich Sorgenkind ist. Sei es, dass Devices und Anlagen da Meinungsverschiedenheiten haben oder eben die Anlagen mit den Providern - irgendetwas klemmt im SIP immer :(
Nun müsste ich aber zuerst einmal mein Net::SIP auf diese Version bekommen (Debian Stretch liefert derzeit über apt die 0.808 aus). Dazu habe ich schon etwas gelesen, am Ende aber die Aussage gefunden, dass es keine gute Idee ist, mit apt installierte Perl-Module mittels CPAN zu aktualisieren. Da fehlt mir im Moment noch etwas know how, aber ich werde nochmal eine Studienreise in's Netz der Netze machen ;)
inaktuelle Grüße
Niels
Zitat von: Muschelpuster am 05 November 2017, 18:02:10
Nun müsste ich aber zuerst einmal mein Net::SIP auf diese Version bekommen (Debian Stretch liefert derzeit über apt die 0.808 aus). Dazu habe ich schon etwas gelesen, am Ende aber die Aussage gefunden, dass es keine gute Idee ist, mit apt installierte Perl-Module mittels CPAN zu aktualisieren. Da fehlt mir im Moment noch etwas know how
Die 0.808 ist zumindest eine Version die läuft und konnte recht einfach installiert werden auch wenn man mit cpan nicht so vertraut ist bzw.
cpan zu viel meckert und dann doch nicht installiert. Inzwischen gibt es zwar schon 0.810 aber der Weg den ich hier https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836 beschrieben habe sollte auch für 0.810 noch gültig sein.
Zitat von: plin am 05 November 2017, 16:16:45
@wzut: Denk an sip_filter/sip_blocking. Die hatten wir denke ich für genau so einen Fall vorgesehen. Statuseinzeige der SIP-Connection aber der Client soll nicht drangehen. Ist aber auch schon eine Weile her. Die Konstellation müsste ich auch erst noch mal durchspielen.
Hab's gerade noch mal ausprobiert. Bei sip_filter = 12345 erkennt er den Anruf und ignoriert ihn. Bei sip_blocking = .* registriert er den Anruf und drückt ihn direkt weg. Also beides keine Lösung.
@geiercasi: Wie wär's denn mit einem simplen Fritzbox-Client? Der zeigt mir die Anrufe im CallMonitor an.
@plin, meine Oma hätte jetzt gesagt "zwei Dumme ein Gedanke" :) Ich habe das gestern Abend auch so mal durchprobiert.
Sicher der Call Monitor ist da die bessere Wahl, allerdings halt nur wenn man auch eine FB hat. Ich bin mir immer noch unsicher ob Net::SIP das nicht doch könnte.
Hallo
Wie bereits geschrieben, nutze ich das SIP-Modul (besten Dank dafür) um ankommende Anrufe zu signalisieren. Da ich früher eine Fritzbox im Einsatz hatte, konnte ich das Modul FB_Calllist http://www.fhem.de/commandref.html#FB_CALLLIST (http://www.fhem.de/commandref.html#FB_CALLLIST) nutzen, um Anrufe zu speichern. Wie könnte man das mit dem SIP-Modul machen, dass es ebenfalls als Call-History-Liste in FHEM integriert wird? Habt ihr eine Idee?
Danke und Gruss Eppi
Zitat von: eppi am 07 November 2017, 18:35:21
Hallo
Wie bereits geschrieben, nutze ich das SIP-Modul (besten Dank dafür) um ankommende Anrufe zu signalisieren. Da ich früher eine Fritzbox im Einsatz hatte, konnte ich das Modul FB_Calllist http://www.fhem.de/commandref.html#FB_CALLLIST (http://www.fhem.de/commandref.html#FB_CALLLIST) nutzen, um Anrufe zu speichern. Wie könnte man das mit dem SIP-Modul machen, dass es ebenfalls als Call-History-Liste in FHEM integriert wird? Habt ihr eine Idee?
Danke und Gruss Eppi
Wie wäre es mit einem FileLog?
Zitat von: Wzut am 07 November 2017, 09:38:34
Ich habe das gestern Abend auch so mal durchprobiert.
Das "mal durchprobieren" wurde bei mir eine längere Aktion bis hin zur Ergänzung des Wiki. Mein Test-SIP-Account konnte sich mit den altbekannten Einstellungen nicht anmelden (FritzOS 6.90).
Zitat von: plin am 07 November 2017, 18:50:45
Wie wäre es mit einem FileLog?
Danke. Ja, mit FileLog ist das schon möglich, aber danach es grafisch sauber in FHEM zu definieren macht mir probleme. Ich habe es auch schon mit ReadingsHistory versucht, aber das ist nicht so hübsch wie man es von ReadingsGroup oder der FB-Calllist kennt...
Zitat von: Wzut am 07 November 2017, 09:38:34
@plin, meine Oma hätte jetzt gesagt "zwei Dumme ein Gedanke" :) Ich habe das gestern Abend auch so mal durchprobiert.
Sicher der Call Monitor ist da die bessere Wahl, allerdings halt nur wenn man auch eine FB hat. Ich bin mir immer noch unsicher ob Net::SIP das nicht doch könnte.
Da war doch mal was ... das sah damals bei meinen ersten Versuchen in der extensions.conf meines Asterisk so aus:
[fritzbox]
exten => s,1,Wait(1) ; Wait a second, just for fun
exten => s,n,Verbose(2,call from ${CALLERID(num)})
exten => s,n,System(/home/scripts/fhemsetring.pl ${CALLERID(num)})
exten => s,n,Wait(100) ; Wait a second, just for fun
exten => h,1,Log(VERBOSE,Caller ${CALLERID(all)} hung up.)
exten => h,n,System(/home/scripts/fhemsetring.pl none)
exten => h,n,Hangup()
Die Script /home/scripts/fhemsetring.pl könnte z.B. via telnet in FHEM den Status des Hue-Devices setzen.
#!/usr/bin/perl -w
# in FHEM den Status der Tuerklingel auf 'ring' setzen
# Always use strict and warnings
use strict;
use warnings;
use Net::Telnet ();
# Declare all
my $callerid = shift;
my $machinename = "192.168.0.47";
my $t_net;
my @Result;
my $cmd;
# Start Code
$t_net = new Net::Telnet (Timeout => 60, Port => 7072 ) or die "Failed to create Telnet instance!";
$t_net->open($machinename);
#@Result = $t_net->cmd("set HaustuerStatusVar ring; set AsteriskCall624 $callerid; exit");
$cmd = "set HaustuerStatusVar ring; ";
$cmd = "";
if ( $callerid eq "none" ) {
$cmd = $cmd."set AsteriskCall624 listen; ";
} else {
$cmd = $cmd."set AsteriskCall624 ring; ";
}
$cmd = $cmd."setreading AsteriskCall624 caller $callerid; ";
$cmd = $cmd."exit";
$t_net->prompt("//");
@Result = $t_net->cmd($cmd);
Guten Abend,
ersteinmal ein herzlicher Dank an die Entwickler dieses Moduls.
Ich habe nur ein "kleines" Problem. Das Klingeln an der Tür löst zwar über die Fritzbox und ein eingerichtetes Telefoniegerät einen Anruf bei der eingestellten Nummer aus, lässt das Telefon aber trotz eingesteller "ringtime 1" klingeln, bis es nach ca. 9 mal Klingeln von selbst aufhört bzw. vorher am Telefon manuell "aufgelegt" wird.
Auszug aus der fhem.cfg:
#was tun, wenn es klingelt
define FB_Klingel SIP
attr FB_Klingel sip_dtmf_loop once
attr FB_Klingel sip_dtmf_send audio
attr FB_Klingel sip_dtmf_size 2
attr FB_Klingel sip_elbc yes
attr FB_Klingel sip_from sip:622@fritz.box
attr FB_Klingel sip_ip 192.168.180.21
attr FB_Klingel sip_listen none
attr FB_Klingel sip_registrar fritz.box
attr FB_Klingel sip_ringtime 1
attr FB_Klingel sip_user 622
define Klingel notify FS20_50e000:on set FB_Klingel call **613 1
Auszug aus dem logfile:
2017.11.14 18:42:00 5: CUL/RAW: /F50E000110A
2017.11.14 18:42:00 4: CUL_Parse: CUL_0 F50E000110A -69
2017.11.14 18:42:00 5: CUL_0: dispatch 810b04xx0101a00150e0000011
2017.11.14 18:42:02 4: FS20 FS20_50e000 on
2017.11.14 18:42:02 5: Starting notify loop for FS20_50e000, 1 event(s), first is on
2017.11.14 18:42:02 5: createNotifyHash
2017.11.14 18:42:02 5: Triggering Klingel
2017.11.14 18:42:02 4: Klingel exec set FB_Klingel call **613 1
2017.11.14 18:42:02 5: Cmd: >set FB_Klingel call **613 1<
2017.11.14 18:42:02 4: FB_Klingel, calling **613, ringtime: 1 , no message
2017.11.14 18:42:02 4: FB_Klingel, FB_Klingel|**613|1||0
2017.11.14 18:42:02 4: BlockingCall (SIP_CALLStart): created child (931), uses telnetForBlockingFn_1510680489 to connect back
2017.11.14 18:42:02 4: FB_Klingel, call -> FB_Klingel|**613|1||0|0
2017.11.14 18:42:02 5: FB_Klingel, call has pid 931
2017.11.14 18:42:02 5: Starting notify loop for FB_Klingel, 2 event(s), first is call_state: invite
2017.11.14 18:42:02 4: FB_Klingel[931], my parent is 918
2017.11.14 18:42:02 5: End notify loop for FB_Klingel
2017.11.14 18:42:02 5: End notify loop for FS20_50e000
2017.11.14 18:42:02 4: FB_Klingel[931], using random port 44443
2017.11.14 18:42:03 5: CUL/RAW: /F50E0000009
2017.11.14 18:42:03 4: CUL_Parse: CUL_0 F50E0000009 -69.5
2017.11.14 18:42:03 5: CUL_0: dispatch 810b04xx0101a00150e0000000
2017.11.14 18:42:03 4: FS20 FS20_50e000 off
2017.11.14 18:42:03 5: Starting notify loop for FS20_50e000, 1 event(s), first is off
2017.11.14 18:42:03 5: End notify loop for FS20_50e000
2017.11.14 18:42:04 4: FB_Klingel[931], register new expire : 2017-11-14 18:47:04
2017.11.14 18:42:04 5: FB_Klingel[931], telnet : set FB_Klingel state calling exit
2017.11.14 18:42:04 4: Connection accepted from telnetForBlockingFn_1510680489_127.0.0.1_40440
2017.11.14 18:42:04 5: Cmd: >set FB_Klingel state calling<
2017.11.14 18:42:04 5: Starting notify loop for FB_Klingel, 1 event(s), first is calling
2017.11.14 18:42:04 5: End notify loop for FB_Klingel
2017.11.14 18:42:04 5: Cmd: >exit<
2017.11.14 18:42:04 4: FB_Klingel[931], CallStart DTMF : ABCD*#123--4567890
2017.11.14 18:42:04 4: FB_Klingel[931], calling : **613
2017.11.14 18:42:04 5: FB_Klingel[931], telnet : set FB_Klingel call_state calling **613 exit
2017.11.14 18:42:04 4: Connection accepted from telnetForBlockingFn_1510680489_127.0.0.1_40442
2017.11.14 18:42:04 5: Cmd: >set FB_Klingel call_state calling **613<
2017.11.14 18:42:04 5: Starting notify loop for FB_Klingel, 1 event(s), first is call_state: calling **613
2017.11.14 18:42:04 5: End notify loop for FB_Klingel
2017.11.14 18:42:05 5: Cmd: >exit<
2017.11.14 18:42:05 5: FB_Klingel[931], 0. Ende des ersten Loops
2017.11.14 18:42:05 5: FB_Klingel[931], 1. rtp_done : 0
2017.11.14 18:42:05 5: FB_Klingel[931], 2. fi : 0
2017.11.14 18:42:05 5: FB_Klingel[931], 3. timeout : 1
2017.11.14 18:42:06 4: FB_Klingel[931], cb_final - status : FAIL - final : 487
2017.11.14 18:42:06 5: FB_Klingel[931], RTP done : 0
2017.11.14 18:42:06 5: FB_Klingel[931], Timeout : 1
2017.11.14 18:42:06 5: FB_Klingel[931], Final : 487
2017.11.14 18:42:06 5: FB_Klingel[931], while : 0
2017.11.14 18:42:06 4: Connection accepted from telnetForBlockingFn_1510680489_127.0.0.1_40444
2017.11.14 18:42:06 5: Cmd: >{BlockingStart('3')}<
2017.11.14 18:42:06 5: Cmd: >{SIP_CALLDone('FB_Klingel|1|no answer')}<
2017.11.14 18:42:06 4: FB_Klingel, CALLDone -> FB_Klingel|1|no answer
2017.11.14 18:42:06 5: Starting notify loop for FB_Klingel, 5 event(s), first is call: done
2017.11.14 18:42:06 5: End notify loop for FB_Klingel
2017.11.14 18:42:06 5: FB_Klingel, fifo is empty
2017.11.14 18:42:06 5: FB_Klingel, no elbc
Was kann ich tun, damit nach 1 mal Klingeln der Anruf endet?
Ich bedanke mich im Voraus für eure Hilfe
Gruß Heiner
Hallo Heiner,
meine Lösung sieht so aus: https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden (https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden) und funktioniert.
Wenn du in der FB die Türklingel auf eine Liste von Telefoniegeräten leitest und diese auf direkte Anrufannahme eingestellt hast (also abheben und du sprichst mit dem Menschen an der Tür), ist die Default-Klingeldauer 30 Sekunden. Diese Zeit kannst du auch nicht ändern.
Die im Wiki dargestellte Lösung funktioniert auch in diesem Szenario.
VG plin
Hallo
Vielleicht kann mir einer weiterhelfen. Habe alles wie im Ski beschrieben installiert und getestet. Der erste Versuch eines Anrufs dauerte ca. 20 Sekunden danach funktionierten die weiteren Anrufe direkt. Dann stellte ich fest, dass fhem nicht mehr funktionierte. Ein shutdown restart brachte keinen Erfolg. Danach habe ich den Raspi 3 (mit Raspian Stretch) neu gestartet und hem funktionierte wieder. Nur das SIP Modul ging nicht mehr. Im Log finde ich folgendes:
###### Die Zeilen kommen immer wieder
2017.11.15 11:14:53 2: mySIP, cant find listen process 29707 in process list !
failed to bind to 192.168.10.212:44609: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
2017.11.15 11:15:55 2: mySIP, cant find listen process 29737 in process list !
failed to bind to 192.168.10.212:44671: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
2017.11.15 11:16:57 2: mySIP, cant find listen process 29767 in process list !
failed to bind to 192.168.10.212:44893: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
failed to bind to 192.168.10.212:44472: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
#### Hier habe ich einen Reset gemacht
2017.11.15 11:19:07 4: mySIP, CALL Kill PID : 29832
2017.11.15 11:19:07 4: mySIP, Reset Call done
2017.11.15 11:19:07 4: mySIP, Listen new PID : 29892
#### Hier einen neuen Call initiiert
2017.11.15 11:19:07 4: mySIP[29892], my parent is 1552
2017.11.15 11:19:07 4: mySIP[29892], using random port 44596
failed to bind to 192.168.10.212:44596: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
Hier ein List
Internals:
CALL mySIP|**611|30||0|0
LPID 30290
NAME mySIP
NOTIFYDEV myT2S
NR 367
NTFY_ORDER 50-mySIP
STATE listen_dtmf
TYPE SIP
VERSION V1.61 / 30.10.17
lastnr **611
READINGS:
2017-11-15 11:17:07 call **611
2017-11-15 11:17:07 call_state invite
2017-11-14 17:47:29 caller none
2017-11-14 17:47:29 caller_state waitting
2017-11-14 17:47:29 expire 300
2017-11-15 11:17:07 listen_alive no
2017-11-14 17:47:29 state listen_dtmf
helper:
CALL_START 1510741027.93616
LISTEN_PID:
abortArg
abortFn
arg mySIP
bc_pid 2098
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 30290
timeout
Attributes:
T2S_Device myT2S
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:12345678@192.168.10.1
sip_ip 192.168.10.212
sip_listen dtmf
sip_registrar 192.168.10.1
sip_ringtime 3
sip_user 12345678
verbose 5
Ein Update von Net::SIP auf 08.10. hat auch nicht gebracht.
Eine Verbindung zur Fritzbox kommt anscheinend garnicht mehr zustande, da das Modul meint dass alle Port Adressen bereits in Benutzung sind. Eine Änderung von sip_port ändert auch nichts.
Für einen Hinweis wäre ich sehr dankbar.
Gruß Horst
Hallo Plin,
herzlichen Dank für deinen Tipp in Antwort 393, mir fehlen aber ausreichende Kenntnisse von FHEM, ihn umzusetzen. Wo kann ich speziell zu diesem Tipp irgendwelche Hilfe bekommen?
Gruß Heiner
Zitat von: heinerwm am 15 November 2017, 16:38:50
Hallo Plin,
herzlichen Dank für deinen Tipp in Antwort 393, mir fehlen aber ausreichende Kenntnisse von FHEM, ihn umzusetzen. Wo kann ich speziell zu diesem Tipp irgendwelche Hilfe bekommen?
Gruß Heiner
Hallo Heiner,
welche Komponenten hast du denn im Einsatz (FB, Doorline, Tür-/Fensterkontakte, ...) und wie spielen die zusammen?
VG plin
Zitat von: Horst_T am 15 November 2017, 11:38:29
Eine Verbindung zur Fritzbox kommt anscheinend garnicht mehr zustande, da das Modul meint dass alle Port Adressen bereits in Benutzung sind. Eine Änderung von sip_port ändert auch nichts.
Hallo Horst,
hast du es mal mit dem sip_port 5070 versucht?
VG plin
Zitat von: plin am 15 November 2017, 17:19:06
Hallo Heiner,
welche Komponenten hast du denn im Einsatz (FB, Doorline, Tür-/Fensterkontakte, ...) und wie spielen die zusammen?
VG plin
Hallo plin,
ich habe nur eine einfache Türklingel, die über einen CUL ein Signal, dass sie gedrückt worden ist, an FHEM sendet (siehe meine fhem.cfg in Antwort 392).
Gruß Heiner
Hallo plin
Vielen Dank für die Antwort. Port 5070 habe ich auch versucht:
2017.11.15 17:30:36 4: mySIP, calling **611, ringtime: 30 , no message
2017.11.15 17:30:36 4: mySIP, mySIP|**611|30||0
2017.11.15 17:30:36 4: mySIP, call -> mySIP|**611|30||0|0
2017.11.15 17:30:36 5: mySIP, call has pid 7346
2017.11.15 17:30:36 4: mySIP[7346], my parent is 31159
failed to bind to 192.168.10.212:5070: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
Gleiches Verhalten-
Horst
Zitat von: heinerwm am 14 November 2017, 19:16:54...löst zwar über die Fritzbox und ein eingerichtetes Telefoniegerät einen Anruf bei der eingestellten Nummer aus, lässt das Telefon aber trotz eingesteller "ringtime 1" klingeln, bis es nach ca. 9 mal Klingeln von selbst aufhört bzw. vorher am Telefon manuell "aufgelegt" wird...
Das Problem habe ich auch und es schon etwas weiter oben (https://forum.fhem.de/index.php/topic,67443.msg710124.html#msg710124) beschrieben. SIP ist da ja von Natur aus (Definition 'nur' über RFC) dehnbar. Und so gibt es zig unterschiedliche 'Dialekte' im Protokoll. Und mit dem verwendeten Perl-SIP-Modul und der FritzBox treffen sich wohl ein Urbayer und ein Ur-Norddeutscher und 'reden' etwas aneinander vorbei. Eine genauere Diagnose liegt gerade noch auf meiner ToDo-Liste, aber der alltägliche Wahnsinn hat da noch keine Zeit zu gelassen. Ich denke, hier muss im Perl-Modul geschraubt werden, denn AVM wird man da sicher nicht von einem Fehlverhalten überzeugen können.
gehetzte Grüße
Niels
Zitat von: Muschelpuster am 15 November 2017, 18:50:48
Das Problem habe ich auch und es schon etwas weiter oben (https://forum.fhem.de/index.php/topic,67443.msg710124.html#msg710124) beschrieben. SIP ist da ja von Natur aus (Definition 'nur' über RFC) dehnbar. Und so gibt es zig unterschiedliche 'Dialekte' im Protokoll. Und mit dem verwendeten Perl-SIP-Modul und der FritzBox treffen sich wohl ein Urbayer und ein Ur-Norddeutscher und 'reden' etwas aneinander vorbei. Eine genauere Diagnose liegt gerade noch auf meiner ToDo-Liste, aber der alltägliche Wahnsinn hat da noch keine Zeit zu gelassen. Ich denke, hier muss im Perl-Modul geschraubt werden, denn AVM wird man da sicher nicht von einem Fehlverhalten überzeugen können.
gehetzte Grüße
Niels
Hallo Niels,
ich glaube "noch" nicht, dass es an einem perl-modul liegt. Ich hatte auf meinem raspberry für einen Anruf das modul 96_FB_SIP genutzt, muss aber auf Grund eines Neuaufsatzes des raspberrys jetzt 96_SIP nutzen, weil 96_FB_SIP nicht mehr verfügbar ist. Und: mit 96_FB_SIP funktionierte das "Auflegen" zuverlässig: das Telefon klingelte bei "define Klingel notify FS20_50e000:on set FB_Klingel call **613 1" auch wirklich nur 1mal! Ich denke, dass da in 96_SIP noch geschraubt werden könnte.
VG Heiner
Zitat von: heinerwm am 15 November 2017, 19:37:40
das Telefon klingelte bei "define Klingel notify FS20_50e000:on set FB_Klingel call **613 1" auch wirklich nur 1mal!
Ich hab's gerade mit meiner Test-Installation nachgestellt.
Bei set call **622 1 (Nebenstelle FritzFon App) klingelt die einmal.
Bei set call **611 1 (Nebenstelle DECT Telefon) reagiert das nicht. Mit set call **611
2 klappt's bei mir.
Im Gegensatz zu 96_FB_SIP ist beim 96_SIP der Parameter hinter der Nebenstelle die Dauer in Sekunden (und nichzt die Anzahl des Klingelns). Die eine Sekunde ist wohl zu knapp bemessen. Das Auflegen klappt bei mir danach sauber.
VG plin
So, ich habe mir jetzt einfach mal die Zeit genommen. Zum Net:SIP gibt es etwas Sample-Code und ich habe da mal die invite_and_recv.pl (https://github.com/noxxi/p5-net-sip/blob/master/samples/invite_and_recv.pl) genutzt. Nachdem ich den Aufruf-Syntax hin gefriemelt hatte, klingelte auch mein Ziel, jedoch flog das Script mit einem Fehler ab:
niels@debian:~$ perl invite_and_recv.pl -T10 -P fritz.box:5060 -L 172.30.1.222 --username 624 --password Test123 sip:624\@172.30.1.1 sip:\*\*611\@172.30.1.1
invite failed(call): Failed with error 22 code=481 at testcall.pl line 153.
Im Trace kann ich genau das schon beschriebene Verhalten beobachten. Ich habe das mal dem Entwickler zukommen lassen, mal sehen ob er eine Idee hat.
Zitat von: plin am 15 November 2017, 20:13:14
Bei set call **611 1 (Nebenstelle DECT Telefon) reagiert das nicht. Mit set call **611 2 klappt's bei mir.
Hier stellt sich natürlich noch die Frage nach der FritzBox-Version. Deinen Ausführungen zum Thema Benutzer und Passwort entnehme ich, dass Du recht aktuell bist. ich habe die 06.66, was für eine Kabel-Deutschland-Fritte derzeit der letzte Schrei sein soll. Ich werde das auch noch mal auf der Büchse meiner Mutter testen, die ist aktueller und hat auch schon die Usernamen für SIP. Vielleicht hat AVM da ja auch etwas sein SIP-Verhalten angepasst.
getestete Grüße
Niels
Zitat von: plin am 15 November 2017, 20:13:14
Ich hab's gerade mit meiner Test-Installation nachgestellt.
Bei set call **622 1 (Nebenstelle FritzFon App) klingelt die einmal.
Bei set call **611 1 (Nebenstelle DECT Telefon) reagiert das nicht. Mit set call **611 2 klappt's bei mir.
Im Gegensatz zu 96_FB_SIP ist beim 96_SIP der Parameter hinter der Nebenstelle die Dauer in Sekunden (und nichzt die Anzahl des Klingelns). Die eine Sekunde ist wohl zu knapp bemessen. Das Auflegen klappt bei mir danach sauber.
VG plin
Hallo plin,
bei meiner Fitzbox ergibt sich Folgendes:
Bei set call **623 1 oder 2 (Nebenstelle FritzFon App) klingelt es viele Mal
Bei set call **613 1 oder 2 oder 3 (Nebenstelle DECT Telefon - FritzFon C5) klingelt es mindestens 9mal
Was ist zu tun?
Herzliche Grüße
Heiner
Moin Heiner,
Welche Version hat Deine Fritte?
neugierige Grüße
Niels
Zitat von: Muschelpuster am 16 November 2017, 06:57:47
Moin Heiner,
Welche Version hat Deine Fritte?
neugierige Grüße
Niels
Hallo Niels, Fritz!box 7390 mit Fritz!OS 6.83 (steht auch in meiner Signatur)
Gruß Heiner
Zitat von: heinerwm am 16 November 2017, 09:00:24
Hallo Niels, Fritz!box 7390 mit Fritz!OS 6.83 (steht auch in meiner Signatur)
Tja, wer lesen kann ist immer wieder klar im Vorteil ;-)
Da hätte ich das Problem jetzt nicht mehr erwartet - Schade eigentlich.
blinde Grüße
Niels
und meine Fritte hat Version 6.92
Hallo,
nach einem Providerwechsel habe ich nun (auch) eine Fritzbox und bin gleich über das SIP-Modul "gestolpert"...
Wirklich SUPER!!!
Jetzt kann ich mir eine Nachricht mit dem Anrufer schicken lassen, wenn ich nicht da bin... :)
Funktioniert auch so weit...
Folgende Einstellungen:
listen wfp
Wobei ich ja nicht annehmen und was abspielen will aber irgendeinen "listen" brauche ich ja, um den Anruf(er) mitzukriegen, oder liege ich da falsch?
Wie gesagt es funktioniert, also notify und dann Sub-Aufruf und Nachricht...
Allerdings bekomme ich folgenden Eintrag im Log:
PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/96_SIP.pm line 1162.
Ich hab mir die Zeile mal angesehen:
my $calltime = int(time()-$hash->{CALL_START});
So wie ich das sehe habe ich aus irgendeinem Grund keine CALL_START...
D.h. bei mir ist dann "caller_time" immer die aktuelle Zeit des Ende des Anrufes (time() )...
Auch nicht schlimm, da ich es nicht brauche...
...also die Anrufdauer.
Sieht halt im Log nicht schön aus, noch dazu wo ich StackTrace aktiv habe und dann gleich noch mehr Einträge folgen... :-|
Mache ich irgendwas falsch?
Irgendwas falsch konfiguriert?
Wie gesagt ich nehme nicht/nie ab mit dem Sip-Client, ich will nur mitbekommen wenn ein Anruf eingeht...
Hier noch ein list des SIP-Device:
Internals:
LPID 19983
NAME SipPhone
NOTIFYDEV global
NR 357
NTFY_ORDER 50-SipPhone
STATE listen_wfp
TYPE SIP
VERSION V1.61 / 30.10.17
READINGS:
2017-11-17 00:22:11 caller none
2017-11-17 00:22:11 caller_state hangup
2017-11-17 00:22:11 caller_time 1510874531
2017-11-17 00:21:17 expire 300
2017-11-16 23:22:01 last_error ListenRegister: can't open port 44702 or 44712 at 192.168.1.81: Cannot assign requested address
2017-11-17 00:21:17 listen_alive PID_19983
2017-11-17 00:21:17 state listen_wfp
helper:
LISTEN_PID:
abortArg
abortFn
arg SipPhone
bc_pid 5
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 19983
timeout
Attributes:
icon it_telephone
room Eingang
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:sip-fhem@fritz.box
sip_ip 192.168.1.123
sip_listen wfp
sip_registrar 192.168.178.1
sip_ringtime 25
sip_user sip-fhem
Der Fehler kam, weil ich das SIP-Device von meinem Testsystem umgezogen habe, da stand (am Anfang) noch die IP des Testsystems drin... ;)
2017-11-16 23:22:01 last_error ListenRegister: can't open port 44702 or 44712 at 192.168.1.81: Cannot assign requested address
Hier noch die Versionsinfos:
Latest Revision: 15414
File Rev Last Change
fhem.pl 15377 2017-11-01 16:59:23Z rudolfkoenig
90_at.pm 14995 2017-09-03 14:23:14Z rudolfkoenig
98_autocreate.pm 15377 2017-11-01 16:59:23Z rudolfkoenig
No Id found for 70_BOTVAC.pm
10_CUL_HM.pm 15399 2017-11-05 17:42:40Z martinp876
37_dash_dhcp.pm 12926 2017-01-01 13:07:33Z justme1968
98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876
98_dummy.pm 12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_fheminfo.pm 14839 2017-08-02 17:37:28Z betateilchen
01_FHEMWEB.pm 15328 2017-10-27 10:51:17Z rudolfkoenig
92_FileLog.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
No Id found for 98_FireTV.pm
98_HMinfo.pm 14608 2017-07-01 04:53:04Z martinp876
00_HMLAN.pm 14073 2017-04-22 13:45:25Z martinp876
95_holiday.pm 15042 2017-09-10 13:59:16Z rudolfkoenig
98_HTTPMOD.pm 15035 2017-09-09 12:02:21Z StefanStrobel
30_HUEBridge.pm 15123 2017-09-23 17:20:38Z justme1968
31_HUEDevice.pm 15247 2017-10-13 19:18:21Z justme1968
# $Id: 99_joUtils.pm 1.2 2015-01-02 Joachim Scharnagl $ #
91_notify.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
No Id found for 99_perfmon.pm
73_PRESENCE.pm 15302 2017-10-22 11:32:19Z markusbloch
33_readingsGroup.pm 15100 2017-09-19 21:21:27Z justme1968
96_SIP.pm 15354 2017-10-30 13:41:59Z Wzut
98_statistics.pm 12218 2016-09-27 19:25:42Z grompo
99_SUNRISE_EL.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_SVG.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
42_SYSMON.pm 15378 2017-11-01 20:36:57Z hexenmeister
50_TelegramBot.pm 15131 2017-09-24 19:37:07Z viegener
98_telnet.pm 15006 2017-09-05 09:37:33Z rudolfkoenig
98_TRAFFIC.pm 14094 2017-04-24 08:09:22Z jmike
98_update.pm 15377 2017-11-01 16:59:23Z rudolfkoenig
99_Utils.pm 13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
59_Weather.pm 12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
# $Id: 72_XiaomiDevice.pm 00000 2017-10-18 $$$
74_XiaomiFlowerSens.pm 15371 2017-11-01 06:37:56Z CoolTux
10_ZWave.pm 15295 2017-10-20 07:03:57Z rudolfkoenig
00_ZWDongle.pm 15181 2017-10-03 10:33:02Z rudolfkoenig
No Id found for 74_ZyAuraCO2.pm
Blocking.pm 15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
DevIo.pm 14933 2017-08-20 14:21:58Z rudolfkoenig
HMConfig.pm 15337 2017-10-29 06:43:02Z martinp876
HttpUtils.pm 15284 2017-10-18 19:46:13Z rudolfkoenig
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm 14862 2017-08-07 15:16:03Z rudolfkoenig
YahooWeatherAPI.pm 12465 2016-10-29 09:01:31Z borisneubert
ZWLib.pm 12651 2016-11-25 15:12:14Z rudolfkoenig
fhemweb.js 15228 2017-10-10 17:34:56Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Wie gesagt kein großes Problem aber halt unschön...
Achja: PI3 Raspbian Stretch lite...
Installation nach: debian.fhem.de automatische Installation. Nur SIP-Perl-Modul installiert (ich will ja nichts abspielen etc.)
FB: 7412 (1&1)
FB-Version: 137.06.83
Danke schon mal, Joachim
@ MadMax-FHEM
Was fällt mir ein/auf:
sip_ip 192.168.1.123
sip_registrar 192.168.178.1
hast du wirklich ein Class B-Netz? Die 192.168.1.123 und 192.168.178.1 haben nur bei 192.168.0.0/16 ein gemeinsames Netzwerk.
Die willst Dir eine "Nachricht" schicken: Als Anruf oder mittels Mail, Telegram etc?
Der Aufruf der Dial-Funktion riecht nach "Anruf". Hast Du Dich an die CommandSyntax lt. Wiki gehalten?
set <name> call <nummer> [<maxtime>] [<nachricht>] [*nn] [&][nn]
Mein Verdacht ist, dass die Nachricht als maxtime interpretiert wird und dann das "-" stört. Probier mal mit 10 als maxtime.
VG plin
Zitat von: plin am 17 November 2017, 15:22:29
@ MadMax-FHEM
Was fällt mir ein/auf:
sip_ip 192.168.1.123
sip_registrar 192.168.178.1
hast du wirklich ein Class B-Netz? Die 192.168.1.123 und 192.168.178.1 haben nur bei 192.168.0.0/16 ein gemeinsames Netzwerk.
/quote]
Quasi ja.
Also ich habe einen WLAN-Accesspoint mit dem ich mein ganzes Netz steuere: 192.168.1.0/24
Den habe ich zum einen wegen ausrecihender Funkabdeckung und ich habe (immer schon) ein DSL-Modem.
Jetzt habe ich den Provider gewechselt und der hat mir eine Fritzbox gegeben ohne WLAN (war Wunsch, da ich ja mein eigentliches Netz nicht ändern wollte).
Die Fritzbox hat eben die 192.168.178.1 und hängt am WAN-Port des Routers...
...also Fritzbox erreichen ist nicht das Problem.
Anrufe erkennen, wenn ich auf listen bin auch nicht.
Zitat von: plin am 17 November 2017, 15:22:29
Die willst Dir eine "Nachricht" schicken: Als Anruf oder mittels Mail, Telegram etc?
Jep per Telegram.
D.h. ein Anruf kommt an, dann wird mir ja die Nummer als Reading angezeigt "call" (glaube ich, bin grad nicht zuhause und kann nicht schauen, daher "aus dem Kopf"), ein Notify reagiert darauf und schickt die Nacricht mit der Nummer.
Das funktioniert auch alles.
Wie gesagt es steht dann eben nur die genannte Warning im Log zusammen mit den anderen Meldungen wegen StrackTrace aktiv...
...also es geht aber ist halt "unschön"...
Die Fritzbox bietet zwar auch sowas aber halt "nur" Mail...
Zitat von: plin am 17 November 2017, 15:22:29
Der Aufruf der Dial-Funktion riecht nach "Anruf". Hast Du Dich an die CommandSyntax lt. Wiki gehalten?
set <name> call <nummer> [<maxtime>] [<nachricht>] [*nn] [&][nn]
Mein Verdacht ist, dass die Nachricht als maxtime interpretiert wird und dann das "-" stört. Probier mal mit 10 als maxtime.
Hmmm verstehe ich nicht so ganz.
Also ich will ja nicht rausrufen, sondern nur eben einen ankommenden Anruf mitbekommen...
Ich will weder das Gespräch annehmen noch soll automatisch angenommen werden.
Daher ja ein entsprechend hoher "Warte-Eintrag", dass mein Anrufbeantworter (nicht der der Fritzbox, sondern echtes Telefon ;) ) dran geht...
...ich will aber eine Nachricht bekommen...
Ich hatte auch schon den Standardwert 3 (falls ich den richtigen Wert meine) also den "Wait-Klingel-Time"...
...dann hatte ich 10 und nun halt noch höher, um sicherzustellen, dass nichts automatisch passiert (gespräch annehmen oder so).
Wie gesagt: es ist nur eine "Warning", unschöner wird das halt dadurch, dass StackTrace aktiv ist...
Gruß, Joachim
Zitat von: plin am 16 November 2017, 17:20:51
und meine Fritte hat Version 6.92
Mhh, die 7360 meiner Mutter sagt, dass sie mit 6.83 aktuell ist und verhält sich ebenso merkwürdig wie ich das schon an meiner Büchse festgestellt habe. Ist ja echt spannend mit den unterschiedlichen Versionen. Oder ist die 6.92 aus dem Labor?
versionierte Grüße
Niels
Zitat von: Muschelpuster am 19 November 2017, 14:58:13
Mhh, die 7360 meiner Mutter sagt, dass sie mit 6.83 aktuell ist und verhält sich ebenso merkwürdig wie ich das schon an meiner Büchse festgestellt habe. Ist ja echt spannend mit den unterschiedlichen Versionen. Oder ist die 6.92 aus dem Labor?
versionierte Grüße
Niels
nee, ich hab' 'ne 7490
Ich lese hier etwas lückenhaft mit da ich z.Z. leider 4000km von meiner Testinstallation getrennt in der Sonne sitze .... aber einen Punkt habe ich zu dem Thema das angeblich jeder Port bereits belegt ist :
Das ist kein Problem des oder der Ports sondern da stimmt die FHEM eigene IP im Attribut nicht !
Zitat von: Wzut am 19 November 2017, 15:56:09
Ich lese hier etwas lückenhaft mit da ich z.Z. leider 4000km von meiner Testinstallation getrennt in der Sonne sitze .... aber einen Punkt habe ich zu dem Thema das angeblich jeder Port bereits belegt ist :
Das ist kein Problem des oder der Ports sondern da stimmt die FHEM eigene IP im Attribut nicht !
gut erkannt ... die Sonne scheint dir gut zu tun :-)
Zitat von: Wzut am 19 November 2017, 15:56:09
Ich lese hier etwas lückenhaft mit da ich z.Z. leider 4000km von meiner Testinstallation getrennt in der Sonne sitze .... aber einen Punkt habe ich zu dem Thema das angeblich jeder Port bereits belegt ist :
Das ist kein Problem des oder der Ports sondern da stimmt die FHEM eigene IP im Attribut nicht !
Wenn sich das auf das:
2017-11-16 23:22:01 last_error ListenRegister: can't open port 44702 or 44712 at 192.168.1.81: Cannot assign requested address
bezieht, dann:
wie bereits geschrieben (und richtig erkannt ;) ), das war weil ich die Config von meinem Testsystem (IP: 81) auf mein Hauptsystem (IP: 123) umgezogen habe...
Bis ich das dann umgestellt hatte wurde klar dieser Fehler erkannt und angezeigt...
...leider nach erfolgreicher Änderung nicht mehr "gelöscht"...
Ich experimentiere einfach weiter...
...da es ja nur eine Warning ist (und auch nicht täglich tausend Leute anrufen) kann ich (erst mal) damit leben...
Schönen Sonnenschein noch!
Gruß, Joachim
Zitat von: MadMax-FHEM am 19 November 2017, 18:37:29
Wenn sich das auf das:
bezieht, dann:
Nein dir traue ich zu so Kleinkram selbst zu finden, mir ging es um Heiner_T auf der Seite davor mit Posting #394
Zitat von: Wzut am 20 November 2017, 17:24:33
Nein dir traue ich zu so Kleinkram selbst zu finden, mir ging es um Heiner_T auf der Seite davor mit Posting #394
Ah, ok.
DANKE! :)
Gruß, Joachim
Ich hatte auch den Fehler 404 und die Lösung ist, dass der
sip_from sip:623@fritz.box
nicht heißen darf sondern der Nutzername muss drin stehen:
sip_from sip:FHEMFHEM@fritz.box
und der muss seit dem letzten Update der fritzbox mindestens 8 Stellen haben!!!!
Elektrolurch
Hallo,
wollte eben auch das Modul 96_SIP testen und hänge da schon einige Stunden an folgender Fehlermeldung im LOG (Verbose 5).
2017.11.26 16:30:07 4: SIP_TelefonClient, listen process 3221 must be killed befor we start a new call !
2017.11.26 16:30:07 4: SIP_TelefonClient, calling 7319, ringtime: 30 , no message
2017.11.26 16:30:07 4: SIP_TelefonClient, SIP_TelefonClient|7319|30||0
2017.11.26 16:30:07 4: SIP_TelefonClient, call -> SIP_TelefonClient|7319|30||0|0
2017.11.26 16:30:07 5: SIP_TelefonClient, call has pid 3222
2017.11.26 16:30:07 4: SIP_TelefonClient[3222], my parent is 2044
failed to bind to 192.168.1.33:5060: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Ich habe eine Fritz!Box 7390 mit Firmware 6.83 und Fhem ist auf einem Raspi 3 installiert, alles hängt am LAN an der Fritz!Box.
Egal welchen Port ich unter SIP_PORT einstelle, die Fehlermeldung bleibt gleich, nur halt mit der anderen Portnummer.
Angelegt habe ich das Modul, wie im Wiki unter https://wiki.fhem.de/wiki/SIP-Client (https://wiki.fhem.de/wiki/SIP-Client) beschrieben, jedoch zunächst mal ohne Text2Speech unterstützung.
Meine Konfiguration in Fhem sieht derzeit wie folgt aus:
Internals:
CALL SIP_TelefonClient|7319|30||0|0
CPID 3222
NAME SIP_TelefonClient
NOTIFYDEV global
NR 300
NTFY_ORDER 50-SIP_TelefonClient
STATE initialized
TYPE SIP
VERSION V1.61 / 30.10.17
lastnr 7319
READINGS:
2017-11-26 16:30:07 call 7319
2017-11-26 16:30:07 call_state invite
2017-11-26 15:15:11 caller reject
2017-11-26 16:30:07 listen_alive no
2017-11-26 16:14:30 state initialized
helper:
CALL_START 1511710207.38715
CALL_PID:
abortArg
abortFn
arg SIP_TelefonClient|7319|30||0
bc_pid 204
finishFn SIP_CALLDone
fn SIP_CALLStart
pid DEAD:3222
timeout
Attributes:
DbLogExclude .*
room Kommunikation
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:Anschluss621@fritz.box
sip_ip 192.168.1.33
sip_listen none
sip_port 5060
sip_registrar 192.168.1.13
sip_ringtime 3
sip_user Anschluss621
verbose 5
So wie ich die Fehlermeldung interpretiere, kommt es bei mir überhaupt nicht zu einer Kommunikation zur Fritz!Box.
Habe ich da noch etwas übersehen?
Das Passwort habe ich (mehrmals) mit "set SIP_TelefonClient password Geheim" gesetzt.
Meine Einstellungen zu den Telefoniegeräten in der Fritz!Box sind wie folgt:
- Zugeteilte Rufnummer 621
- IP Telefon auf alle Rufnummern reagieren
- Registrar "fritz.box" oder "192.168.1.13"
- Benutzername "Anschluss621"
- Kennwort "Geheim"
- Anmeldung aus dem Internet erlauben ist aktiv, funktioniert aber auch inaktiv nicht
Die Suche in Fhem Forum und im Internet bringt mich hier wirklich nicht weiter, Shutdown restart (Fhem und Raspi) ist auch schon mehrmals erfolgt.
Warscheinlich ist es nur eine Kleinigkeit, bei welcher ich hier hänge.
Ich hoffe ihr habt den entscheidenden Tipp für mich.
Gruß Reinhard.
Zitat von: Rewe2000 am 26 November 2017, 17:04:54
failed to bind to 192.168.1.33:5060: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Ich habe mit dem Port 5070 gute Erfahrungen gemacht.
Vorsorglich noch mal die Verifikation der IP-Adressen:
- Dein Raspi 3 hat die 192.168.1.33
- Deine Fritzbox tatsächlich die 192.168.1.13 wie in der Meldung ausgegeben (ich hätte eher eine 192.168.1.1 erwartet).
VG plin
Hallo plin,
ja die Angabe der IP-Adressen stimmt, die Fritz!Box hat bei mir die 192.168.1.13 und der Raspi die 192.168.1.33.
Egal welchen Port ich hier unter sip_port angebe, oder ob ich das attr. komplett lösche, es kommt immer zu der gleichen Fehlermeldung:
failed to bind to 192.168.1.33:????: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Auch mit netstat habe ich (Achtung Linux Anfänger) schon auf dem Raspi geprüft, mir wird auch unter root der in der Fehlermeldung genannte Port nicht angezeigt.
Ist es bei dir auch so, dass auch nach einem "set <device> reset" die vorher eingetragene Rufnummer noch im Eingabefeld von "set <device> call" angezeigt wird?
Im Raspi oder in der Fritz!Box muss ich doch keine Portfreigaben einrichten, da ich ja nicht von aussen erreichbar sein will?
Ich verwende noch "Janrufmonitor" auf meinem Windows PC, um die Anrufliste der Fritz!Box zu lesen, auch dieses habe ich derzeit komplett beendet. Aber so wie ich es sehe liegt mein Problem eher beim Raspi als woanders.
Gruß Reinhard
Zitat von: Rewe2000 am 26 November 2017, 18:05:59
Egal welchen Port ich hier unter sip_port angebe, oder ob ich das attr. komplett lösche, es kommt immer zu der gleichen Fehlermeldung:
Versuch's mal mit sip_port = 0
Dann wird der "Standardport" verwendet, welcher auch beim entfernen des Attributs sip_port benutzt wird.
Hier die Meldungen im Log bei sip_port 0, unter Verbose 5
2017.11.26 18:51:56 4: SIP_TelefonClient, listen process 1593 must be killed befor we start a new call !
2017.11.26 18:51:56 4: SIP_TelefonClient, calling 7319, ringtime: 30 , no message
2017.11.26 18:51:56 4: SIP_TelefonClient, SIP_TelefonClient|7319|30||0
2017.11.26 18:51:56 4: SIP_TelefonClient, call -> SIP_TelefonClient|7319|30||0|0
2017.11.26 18:51:56 5: SIP_TelefonClient, call has pid 1594
2017.11.26 18:51:56 4: SIP_TelefonClient[1594], my parent is 647
2017.11.26 18:51:56 4: SIP_TelefonClient[1594], using random port 44114
failed to bind to 192.168.1.33:44114: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Irgendwie meine ich fast, es wäre 2 Mal gestartet und verwendet gleichzeitig den gleichen Port.
Hab mal in fhem.cfg nach SIP gesucht, finde das Device aber nur einmal (man klammert sich ja an jeden Strohhalm :)
Da lieg ich doch nicht falsch, wenn ich bei meiner Konfiguration eine Rufnummer mit "set <Devicename> call <Rufnummer> (ohne irgendwelche weitere Zusätze) rufen will? Das sollte doch funktionieren!
Hinweis:
Habe eben das Modul FBAHAHTTP installiert, es schaltet alle meine Fritz Smart Home Geräte, welche an der Fritz!Box hängen Problemlos.
Bin absolut Ratlos weshalb das Modul 96_SIP bei mir nicht geht.
Gruß Reinhard
Zitat von: Rewe2000 am 26 November 2017, 19:09:40
Dann wird der "Standardport" verwendet, welcher auch beim entfernen des Attributs sip_port benutzt wird.
Ach ja, da war ja noch was: Kannst du es bitte mal ohne einen laufenden listen testen. Also sip_listen auf "none", ein reset und dann den Call absetzen. Ggf. auch mit der Syntax
set <Devicename> call <Rufnummer>Call 5 -123
VG plin
Hallo plin,
anbei meine Versuche, diesmal nur über die Fhem Eingabezeile und die entsprechenden Logeinträge.
Hab ich da etwas falsch verstanden, aber nach dem call sollte doch nur die Angabe der Rufnummer ausreichen?
Aus deiner Vorgabe "set <Devicename> call <Rufnummer>Call 5 -123" habe ich das 2. Call entfernt.
Alle Versuche immer vorher mit reset und sip_port 5070 und sip_line none:
Fhem Befehl "set SIP_TelefonClient call 7319 5 -123":
2017.11.26 20:41:46 4: SIP_TelefonClient, CALL Kill PID : 2316
2017.11.26 20:41:46 4: SIP_TelefonClient, Reset Call done
2017.11.26 20:42:03 4: SIP_TelefonClient, message DTMF = -123
2017.11.26 20:42:03 4: SIP_TelefonClient, SIP_TelefonClient|7319|5|-123|0
2017.11.26 20:42:03 4: SIP_TelefonClient, call -> SIP_TelefonClient|7319|5|-123|0|0
2017.11.26 20:42:03 5: SIP_TelefonClient, call has pid 2321
2017.11.26 20:42:03 4: SIP_TelefonClient[2321], my parent is 647
failed to bind to 192.168.1.33:5070: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Fhem Befehl "set SIP_TelefonClient call 7319 5":
2017.11.26 20:43:08 4: SIP_TelefonClient, CALL Kill PID : 2321
2017.11.26 20:43:08 4: SIP_TelefonClient, Reset Call done
2017.11.26 20:43:14 4: SIP_TelefonClient, calling 7319, ringtime: 5 , no message
2017.11.26 20:43:14 4: SIP_TelefonClient, SIP_TelefonClient|7319|5||0
2017.11.26 20:43:14 4: SIP_TelefonClient, call -> SIP_TelefonClient|7319|5||0|0
2017.11.26 20:43:14 5: SIP_TelefonClient, call has pid 2325
2017.11.26 20:43:14 4: SIP_TelefonClient[2325], my parent is 647
failed to bind to 192.168.1.33:5070: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Fhem Befehl "set SIP_TelefonClient call 7319":
2017.11.26 20:44:18 4: SIP_TelefonClient, CALL Kill PID : 2325
2017.11.26 20:44:18 4: SIP_TelefonClient, Reset Call done
2017.11.26 20:46:51 4: SIP_TelefonClient, calling 09604408787, ringtime: 30 , no message
2017.11.26 20:46:51 4: SIP_TelefonClient, SIP_TelefonClient|09604408787|30||0
2017.11.26 20:46:51 4: SIP_TelefonClient, call -> SIP_TelefonClient|09604408787|30||0|0
2017.11.26 20:46:51 5: SIP_TelefonClient, call has pid 2364
2017.11.26 20:46:51 4: SIP_TelefonClient[2364], my parent is 647
failed to bind to 192.168.1.33:5070: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Danke für deine Hilfe bei der Fehlersuche.
Gruß Reinhard
Zitat2017.11.26 18:51:56 4: SIP_TelefonClient[1594], using random port 44114
failed to bind to 192.168.1.33:44114: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153
Solange es diese Meldung im Log gibt wird es keinen Erfolg geben !
Bisher war es immer so das die eigene FHEM IP nicht stimmte wenn sogar Random Port scheiterte.
Da sich der Fehler in letzter Zeit hier zu häufen scheint : Welches OS bzw Version ist auf dem Raspi installiert und welche Version von Net::SIP ?
Hallo Wzut,
habe den Rapberry Pi 3 am Wochenende komplett neu aufgesetzt, mit Debian Stretch.
Linux-Distribution und -Release:
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
Linux-Kernel-Version:
Linux raspberrypi 4.9.65-v7+ #1056 SMP Fri Nov 24 13:58:07 GMT 2017 armv7l GNU/Linux
Firmware-Version des Raspberry Pi:
Nov 17 2017 15:19:00
Copyright (c) 2012 Broadcom
version 2c2faa4c5e38cc04d01245905b8338e8fc55ee0d (clean) (release)
Modulversionen:
libnet-sip-perl 0.808-1 all framework for SIP modules
Ich habe das Modul mit "sudo apt-get install libnet-sip-perl" Installiert und nicht mit "sudo cpan install Net::SIP"
Habe eben noch ein Linux Update (apt-get dist-upgrade) am Raspi und ein Fhem Update all gemacht, jedoch keine Änderung.
In einem älteren Beitrag habe ich gelesen, dass nur cpan die neueste Version installiert, ist dies jetzt auch noch so?
Mit cpan hatte ich in der Vergangenheit keinen großen Erfolg, deshalb installiere ich jetzt auf anraten einiger Mitglieder im Fhem Forum nur mit apt-get install ...
Ich hoffe es sind alle Infos dabei, welche du benötigst.
Wenn es hilft, ich habe noch eine Speicherkarte von meinem Raspi mit Jessy und Update auf Stretch da, ich könnte das SIP Modul hier mal testen. Aber grundsätzlich läuft es ja auch bei anderen Usern.
Gruß Reinhard
Hallo Reinhard,
Zitat von: Rewe2000 am 27 November 2017, 18:45:57
libnet-sip-perl 0.808-1 all framework for SIP modules
die aktuellste Version ist die 0.812 und die kriegst du nur über cpan.
VG plin
Hallo Plin,
habe es auch schon gesehen, wollte nur sehr ungern über cpan installieren.
Wenn ich tatsächlich eine neuere Version installieren muss, geht dies auch wie unter dem Tip von
@Wzut https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836 (https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836) beschrieben?
Habe dies aber noch nie gemacht, wenn ich die Beschreibung dazu lese, sind das für einen nicht geübten Linux Anwender lauter "Böhmische Dörfer". Ohne tatkräftige Unterstützung wird dies sicher bei mir im Desaster enden.
Verwenden denn alle anderen Anwender die SIP nutzen die neueste Version, läuft es mit der Version 0.808-1 sicher nicht?
Wenn ja, dann werde ich mal einen Versuch wagen, mit Imagebackup meines relativ neuen Systems.
Gruß Reinhard
Hallo Reinhard,
Zitat von: Rewe2000 am 27 November 2017, 19:55:50
Wenn ich tatsächlich eine neuere Version installieren muss, geht dies auch wie unter dem Tip von
@Wzut https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836 (https://forum.fhem.de/index.php/topic,67443.msg598836.html#msg598836) beschrieben?
Das ist der Hardcore-Weg. cpan ist da deutlich einfacher. Die Empfehlung ist allgemein die cpan-Version zu installieren. Erst vor kurzem gab es in der noch eine Verbesserung. Also
sudo cpan install Net::SIP
VG plin
Hallo Plin,
ich habe es getan:
pi@raspberrypi:~ $ sudo cpan install Net::SIP
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 27 Nov 2017 19:53:48 GMT
Net::SIP is up to date (0.812).
Aber wenn ich mit "dpkg --list" nachsehe, wird mir immer noch:
ii libnet-sip-perl 0.808-1 all framework for SIP modules
als geladen angezeigt.
Wie sage ich meinem Raspi welches von den Modulen er nun verwenden soll?
Muss ich das Modul "libnet-sip-perl" entfernen? Und wenn ja wie?
Ich denke ich habs gefunden!
"sudo apt-get purge libnet-sip-perl"
hat das "alte" Modul entfernt.
Aber geändert hat sich nach einen shutdown des Raspi nichts:
2017.11.27 21:46:03 4: SIP_TelefonClient, calling 7319, ringtime: 30 , no message
2017.11.27 21:46:03 4: SIP_TelefonClient, SIP_TelefonClient|0xxxxxxxxxx19|30||0
2017.11.27 21:46:03 4: SIP_TelefonClient, call -> SIP_TelefonClient|7319|30||0|0
2017.11.27 21:46:03 5: SIP_TelefonClient, call has pid 900
2017.11.27 21:46:03 4: SIP_TelefonClient[900], my parent is 656
2017.11.27 21:46:03 4: SIP_TelefonClient[900], using random port 44446
failed to bind to 192.168.1.33:44446: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
Auch nach der Installation mit cpan habe ich noch den gleichen Fehler.
Ich habe auch mal das SIP Device in Fhem gelöscht und unter anderem Namen wieder
angelegt, auch hier ändert sich absolut nichts!
Bin echt am Verzweifeln, hab keinen Dunst mehr was ich da noch machen könnte.
Kann das Problem auch an meinen Raspi liegen (Portfreigabe etc.), muss ich da noch extra was konfigurieren oder freischalten was im WIKI nicht steht?
Gruß Reinhard
Zitat von: Rewe2000 am 27 November 2017, 21:34:40Aber wenn ich mit "dpkg --list" nachsehe, wird mir immer noch:
ii libnet-sip-perl 0.808-1 all framework for SIP modules
Ich denke mal, das ist der Grund, warum man nicht mit apt installierte Perl-Module mit CPAN aktualisieren soll. dpkg schaut IMHO nicht auf das Modul, sondern nur in seine Datenbank. Zuverlässiger ist wohl die Abfrage mit
cpan -D Net::SIP
Zitat von: Rewe2000 am 27 November 2017, 21:34:40
Aber geändert hat sich nach einen shutdown des Raspi nichts:
:
:
failed to bind to 192.168.1.33:44446: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
Interessant ist doch erst einmal was ss (Ersatz für netstat auf Stretch) sagt:
ss -t |grep 44446
Wenn nichts kommt, dann poste auch gerne mal die Ausgabe von ss ohne das grep.
abgefragende Grüße
Niels
Zitat von: heinerwm am 15 November 2017, 22:27:26
Hallo plin,
bei meiner Fitzbox ergibt sich Folgendes:
Bei set call **623 1 oder 2 (Nebenstelle FritzFon App) klingelt es viele Mal
Bei set call **613 1 oder 2 oder 3 (Nebenstelle DECT Telefon - FritzFon C5) klingelt es mindestens 9mal
Was ist zu tun?
Hallo plin,
mir ist es jetzt gelungen, mit dem modul FRITZBOX meine Telefone mit der eingestellten Klingelzeit klingeln zu lassen. Dieses modul ist zwar etwas langsamer als das SIP, aber es funktioniert.
Mein Verdacht bleibt also, dass das Problem im modul SIP liegt und nicht in PERL.
Viele Grüße
Heiner
Hallo Niels,
die Installation des Moduls scheint geklappt zu haben, zumindest wird mir das so angezeigt:
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.812.tar.gz
/usr/local/share/perl/5.24.1/Net/SIP.pm
Installed: 0.812
CPAN: 0.812 up to date
Mit dpkg --list wird dagegen das Modul libnet-sip-perl nicht mehr angezeigt.
Der Blick nach den Ports ergibt (meiner Meinung nach) absolut nichts auffälliges, "ss -t" bringt:
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 64 192.168.1.33:ssh 192.168.1.26:60860
FIN-WAIT-2 0 0 192.168.1.33:7420 192.168.1.32:60949
ESTAB 0 0 192.168.1.33:39682 192.168.1.30:502
ESTAB 0 0 192.168.1.33:8083 192.168.1.27:35210
ESTAB 0 0 192.168.1.33:8083 192.168.1.26:60846
Nach Ausführen einer Nummernwahl über das SIP-Device kommt die Meldung "Port 44175 alredy in use" eine Ausgabe mit "ss -t" ergibt:
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 64 192.168.1.33:ssh 192.168.1.26:60860
ESTAB 0 0 192.168.1.33:8083 192.168.1.26:61125
ESTAB 0 0 192.168.1.33:8083 192.168.1.26:61124
ESTAB 0 0 192.168.1.33:7420 192.168.1.32:33902
ESTAB 0 0 192.168.1.33:39682 192.168.1.30:502
ESTAB 0 0 192.168.1.33:8083 192.168.1.27:35210
ESTAB 0 0 192.168.1.33:8083 192.168.1.26:61126
ESTAB 0 0 192.168.1.33:8083 192.168.1.26:61123
Auch ist es anscheinend völlig egal, welchen Port ich unter sip_port eintrage, jeder Port wird mir als belegt angezeigt. Ich hatte gestern schon mal mit netstat -a geprüft, in der Ausgabe habe ich niemals den von SIP verwendeten Port gefunden.
Wo vermuten die Profis den Fehler?
- Fhem SIP-Device
- Debian SIP-Modul#
- Linux meines Raspis 3
- oder vor dem Bildschirm :)
Vielen Dank von meiner Seite an alle Helfer, ich alleine wäre absolut hilflos diesen Fehler zu finden.
Gruß Reinhard
Hallo Reinhard,
ich hab jetzt nicht alles im Detail verfolgt...
Aber ich habe/hatte das SIP Modul auch in Betrieb.
Ich habe einen PI3 mit Stretch light relativ aktuell weil vor ca. 3-4 Wochen aufgesetzt und sicher inzwischen mind. 1x update/upgrade ausgeführt.
Ich hatte das SIP-Perl paket mittels apt-get installiert sonst nichts, da ich eigentlich nicht telefonieren (lassen) wollte sondern nur mitbekommen, wenn ich angerufen werde und nicht zuhause bin -> Nachricht per Telegram.
Aktuell habe ich es wieder runter, da das FBCALLMONITOR-Modul genau leistet was ich wollte...
...aber mal sehen, evtl. rüste ich auch wieder auf... ;)
Ab hier sieht man meine Config:
https://forum.fhem.de/index.php/topic,67443.msg716892.html#msg716892
fhem war/ist auch neu/aktuell, da ich eben dabei bin mein (etwas) betagtes Testsystem (Wheezy und mittlerweile total "kaputt installiert") neu aufzusetzen...
Da ich gerade am Anfang des Neu-Aufsetzens war/bin habe ich noch kaum/keine anderen Perl Module installiert, außer was beim Installieren von fhem per debian.fhem.de so mitkommt...
Ich weiß, keine Lösung für das Problem...
...aber du siehst zumindest, dass es unter Stretch light mit SIP-Modul per apt-get läuft/laufen kann...
Gruß, Joachim
Hallo Joachim,
die Situation bei dir ist ähnlich wie bei mir, ich habe auch Stretch komplett neu aufgesetzt, meine MySQL Datenbank aus einer Sicherung wieder zurückgeschrieben und dann mein Fhem Backup vom alten Raspi (Jessy mit Update auf Stretch) in den neu mit Stretch Lite aufgesetzten Raspi eingelesen.
Einige Besonderheiten:
Das SIP Device und auch kein anderes Modul für die Fritz!Box war im Update enthalten, ich habe dieses erst dann als Device in Fhem angelegt, nachdem mein "neuer" Raspi mit Fhem fehlerfrei gelaufen ist. Anfänglich habe ich auch kein Text2Speach installiert, dachte aber irgendwann, eventuell mit diesem könnte mein Fehler verschwunden sein.
Folgende Module habe ich, neben der Fhem Standardinstallation noch hinzugefügt:
apt-get install apache2 -y
apt-get -y install libdatetime-format-strptime-perl
apt-get update && sudo apt-get install -y librpc-xml-perl
apt-get update && apt-get install mysql-server mysql-client libdbd-mysql libdbd-mysql-perl
aptitude install libdbi-perl
apt-get -y install libclass-dbi-mysql-perl
apt-get install libforks-perl libthread-queue-any-perl libtime-hires-perl
apt-get install libnet-sip-perl ### wieder entfernt und mit cpan install Net::SIP neuere Version installiert
apt-get install sox
apt-get install libsox-fmt-mp3
Danke Joachim für das feedback, es tut gur zu hören, dass es bei anderen Usern klappt. Dies gibt mir wieder Mut um an meinem Problem dranzubleiben.
@Wzut
Könnte die Ursache mit dem Einspielen des Fhem Backups, auf einen neu aufgesetzten Raspi zusammenhängen?
Zitat.... Thema das angeblich jeder Port bereits belegt ist :
Das ist kein Problem des oder der Ports sondern da stimmt die FHEM eigene IP im Attribut nicht !
Die Frage stellt sich mir, kann ich die Fhem eigene IP im Attribut irgendwie prüfen?
Gibt es für mich die Möglichkeit diese IP wieder richtigzustellen?
Ich dachte durch löschen des SIP-Device und neuanlegen unter einem anderen Namen wird auch die IP wieder neu vergeben, hat aber bei mir nicht geholfen.
Ich hoffe nur ihr habt noch einige Ideen
Gruß Reinhard
Hallo Reinhard,
dann fangen wir doch mal bei Adam und Eva an. Besorg dir mal
https://github.com/noxxi/p5-net-sip/blob/master/samples/invite_and_recv.pl
speichere es auf deinem Raspi ab und mache executable.
Dann kannst du mit
./invite_and_recv.pl --username Anschluss621 --password 'deinpasswort' -R 192.168.1.13:5060 -L 192.168.1.33 -T 5 sip:Anschluss621@fritz.box 7319
testen, ob das Net::SIP in deinem Umfeld funktioniert. Wenn ja müssen wir das Problem im FHEM-Umfeld suchen, wenn nein müssen wir schauen was im System verbogen ist.
VG plin
Hallo plin,
ich wollte dies gerade testen, aber ich denke hier brauche ich noch etwas Hilfe.
Bisher habe ich noch nie selbst ein script in Linux erstellt und ich denke hier liegt auch mein Fehler:
1. Verzeichnis auf dem raspi mit "mkdir /opt/fhem/temp/" erstellt.
2. Scriptdatei mit "sudo nano /opt/fhem/temp/invite_and_recv.pl" erstellt und den Scripttext https://github.com/noxxi/p5-net-sip/blob/master/samples/invite_and_recv.pl (https://github.com/noxxi/p5-net-sip/blob/master/samples/invite_and_recv.pl) hineinkopiert.
3. executable gemacht mit "sudo chmod +x /opt/fhem/temp/invite_and_recv.pl"
4. Versucht das Script wie folgt auszuführen:
pi@raspberrypi:/opt/fhem/temp $ sudo ./invite_and_recv.pl --username Anschluss621 --password 'Geheim' -R 192.168.1.13:5060 -L 192.168.1.33 -T 5 sip:Anschluss621@fritz.box 7319
./invite_and_recv.pl: 10: ./invite_and_recv.pl: use: not found
./invite_and_recv.pl: 11: ./invite_and_recv.pl: use: not found
./invite_and_recv.pl: 12: ./invite_and_recv.pl: use: not found
./invite_and_recv.pl: 13: ./invite_and_recv.pl: Syntax error: "(" unexpected
So wie ich es vermute wird das Script ausgeführt, aber irgend etwas habe ich mit der "Installation" falsch gemacht.
Mit welchen Interpreter sollte dies eigentlich ausgeführt werden?
Prügelt mich bitte nicht, für mein Unwissen, ich lese mich auch gerne ein, aber so auf die Schnelle klappt das bei mir nicht.
Gruß Reinhard
Du hättest verm. das Script auch einfach mit wget holen können... ;)
Vermutlich .pl -> perl, also vielleicht so:
sudo perl invite_and_recv.pl --username Anschluss621 --password 'Geheim' -R 192.168.1.13:5060 -L 192.168.1.33 -T 5 sip:Anschluss621@fritz.box 7319
Kurz, da Handy...
Gruß, Joachim
Hallo Joachim,
danke für die vielen hilfreichen Tipps, mit
sudo wget https://raw.githubusercontent.com/noxxi/p5-net-sip/master/samples/invite_and_recv.pl
hat der Download nun (auf dem richtigen Weg) geklappt.
Das script rufe ich nun wie folgt auf:
sudo perl ./invite_and_recv.pl --username Anschluss621 --password 'Geheim' -R 192.168.1.13:5060 -L 192.168.1.33 -T 5 sip:Anschluss621@fritz.box 7319
Als Fehler wird mir folgendes angezeigt:
cannot create resolver:
Net::DNS not available?:
Can't locate Net/DNS.pm in @INC (you may need to install the Net::DNS module)
(@INC contains: /etc/perl
/usr/local/lib/arm-linux-gnueabihf/perl/5.24.1
/usr/local/share/perl/5.24.1
/usr/lib/arm-linux-gnueabihf/perl5/5.24
/usr/share/perl5
/usr/lib/arm-linux-gnueabihf/perl/5.24
/usr/share/perl/5.24
/usr/local/lib/site_perl
/usr/lib/arm-linux-gnueabihf/perl-base)
at /usr/local/share/perl/5.24.1/Net/SIP/Dispatcher.pm line 1164.
Ich habe verstanden, ich muss mir noch NET::DNS holen, nachdem ich dieses installiert hatte, ging mein Ruf vom Raspi raus ;D ;D ;D
Nun kommt der Versuch über das SIP Device von Fhem:
2017.11.29 18:05:11 4: TelefonClient[23238], using random port 44437
failed to bind to 192.168.1.33:44437: Address already in use at /usr/local/share/perl/5.24.1/Net/SIP/Leg.pm line 153.
Immer noch der gleiche Fehler wie eh und jeh, selbst nach einem Shutdown -r des Raspi. :(
Somit müsste mein Problem bei Fhem liegen, das habe ich nun verstanden.
Ich versuch es jetzt mal auf die brachiale Art:
Ersatzraspi mit Image von Stretch Lite, Fhem Grundinstallation nur mit den nötigsten Modulen und nur mit dem SIP-Device.
Ich melde mich wieder.
######### Ergebnis mit neu aufgesetztem Raspi ################
So, es ist geschafft, der neue Raspi 3 läuft mit Stretch Lite und Fhem in einer Minimalkonfiguration ohne COC und MariaDB, als einziges Device neben den Standard Devices ist SIP installiert. Die Module habe ich nicht mit cpan sondern mit apt-get install
geladen.
In dieser Konfiguration läuft das SIP Device bei mir problemlos so wie es soll.
Ich werde nun weiter "aufrüsten" bis ich Probleme bekomme, anders kann ich den Fehler nicht eingrenzen.
Gruß Reinhard
Zitat von: f-zappa am 29 November 2017, 15:54:39
Können wir das so übernehmen? :)
Falscher Thread , das hat nichts mit 96_SIP zu tun sondern sind T2S internas !
@Reinhard, schön :) Ich werd mir am WE mal den Bereich im Leg.pm anschauen, ob ich für den Fall eine Vorabprüfung einbauen kann.
Würde mich jetzt aber echt interessieren was bei deiner ersten Insatllation schief läuft. BTW : Klar bekommt man mit apt-get nicht die allerletzte Version von Net::SIP,
aber was seit Wheezy ausgeliefert wird ist eigentlich brauchbar - bei Jessy sah das damals noch ganz anders aus, da musste unbedingt mittels cpan nachgebessert werden.
Strech habe ich aktiv noch nicht am Laufen, mal schauen wenn Zeit ist müsste ich mein Testsystem auch mal auf diesen Stand heben.
Zitat von: Wzut am 30 November 2017, 08:11:30
Strech habe ich aktiv noch nicht am Laufen, mal schauen wenn Zeit ist müsste ich mein Testsystem auch mal auf diesen Stand heben.
Selber probieren schadet nie ;)
Ich habe/hatte das SIP Modul auf Stretch lite laufen.
Installation "nur" mittels apt-get...
Allerdings keine "aktiven" calls, sondern "nur" listener...
Wollte ja "nur" Anrufe mitbekommen und eine Nachricht schicken bei Abwesenheit...
Gruß, Joachim
Zitat von: MadMax-FHEM am 17 November 2017, 00:30:16
my $calltime = int(time()-$hash->{CALL_START});
So wie ich das sehe habe ich aus irgendeinem Grund keine CALL_START...
Ich habe mir die Stelle jetzt mal angeschaut, ja es gibt die Möglichkeit das CALL_START gar nicht definiert ist.
Werde ich im nächsten Update fixen.
Zitat von: Wzut am 30 November 2017, 16:16:01
Ich habe mir die Stelle jetzt mal angeschaut, ja es gibt die Möglichkeit das CALL_START gar nicht definiert ist.
Werde ich im nächsten Update fixen.
Ok, danke!
Gruß, Joachim
Zitat von: MadMax-FHEM am 30 November 2017, 10:40:49
Selber probieren schadet nie ;)
Also meine Test-Instanz läuft auf einem Raspi3 unter stretch ... und ich habe keine Probleme.
P.S. Einige Nutzer haben aber Probleme die die aktuellste Net::SIP-Version erfordern, deshalb habe ich mittels cpan die 0.812 installiert.
Hallo,
nach einigen Stunden Neuinstallation hier nun mein Bericht und meine Vermutung.
Ich habe nun Stretch Lite auf einem Raspi 3 mit "COC" und einer Fhem Minimalkonfiguration nur mir dem SIP und dem Text2Speach Device aufgesetzt (ohne cpan).
Das SIP Modul läuft im Zusammenspiel mit Text2Speach problemlos :)
Erst wenn ich mein Fhem Backup einspiele, funktioniert SIP wieder nicht mehr >:(
Somit gibt es eine eindeutige Erkenntnis, es muss eindeutig (bei mir an meiner Fhem Konfiguration/Installation) liegen.
2017.11.30 22:32:47 1: PERL WARNING: Argument "*52" isn't numeric in preincrement (++) at ./FHEM/96_SIP.pm line 738.
2017.11.30 22:32:47 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.11.30 22:32:47 4: TelefonClient, TelefonClient|**52|30||0
2017.11.30 22:32:47 4: TelefonClient, call -> TelefonClient|**52|30||0|0
2017.11.30 22:32:47 5: TelefonClient, call has pid 1275
2017.11.30 22:32:47 4: TelefonClient[1275], my parent is 1170
2017.11.30 22:32:47 4: TelefonClient[1275], using random port 44221
failed to bind to 192.168.1.33:44221: Address already in use at /usr/share/perl5/Net/SIP/Leg.pm line 153.
Mir fallen 2 Dinge auf:
Seitdem ich das Fhem Restore gemacht habe, werden keine Rufnummern mit "**" mehr akzeptiert, es kommt eine Meldung ...at ./FHEM/96_SIP.pm line 738 (siehe Fehlerlog). In der Minimalkonfiguration gingen solche internen Rufnummern noch Problemlos.
Desweiteren war das SIP Modul in der Minimalkonfig von Fhem am Ende der fhem.cfg, nur mein COC Modul kam noch danach.
define COC CUL /dev/ttyAMA0@38400 1234
attr COC rfmode HomeMatic
In der nicht funktionierenden fhem Konfiguration ist das SIP Device ganz am Ende, vor diesem Device kommen HMCCU, HMCCURPC, VCCU_CUL und dann einige HmIP-Device.
Spielt die Position in der fhem.cfg Datei für das SIP Device eine Rolle?
Der nächste Schritt wäre nun alle Device in Fhem zu löschen und dann mit RAW definition wieder einzufügen, bis der Fehler wieder kommt.
Außer es gibt noch andere (weniger mühsamere) Vorschläge.
Gruß Reinhard
Zitat von: Rewe2000 am 30 November 2017, 23:01:17
Seitdem ich das Fhem Restore gemacht habe, werden keine Rufnummern mit "**" mehr akzeptiert, es kommt eine Meldung ...at ./FHEM/96_SIP.pm line 738 (siehe Fehlerlog). In der Minimalkonfiguration gingen solche internen Rufnummern noch Problemlos.
Doch deine **52 wird als Rufnummer angenommen, steht auch so im Log :
2017.11.30 22:32:47 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.11.30 22:32:47 4: TelefonClient, TelefonClient|**52|30||0
2017.11.30 22:32:47 4: TelefonClient, call -> TelefonClient|**52|30||0|0
ABER : der * (Stern) kann auch am Ende des Strings für Wiederholungen benutzt werden , z.B. *3
Bei deiner Fehlermeldung wurde die **53 als Wiederholung ausgewertet, also lediglich ein Schönheistfehler der i.d.R. (zumndest bei mir) nicht auftritt.
Zitat von: Rewe2000 am 30 November 2017, 23:01:17
Spielt die Position in der fhem.cfg Datei für das SIP Device eine Rolle?
Nein, denn das Modul hat keine direkten Abhängikeiten zu anderen IO Modulen.
@Rewe2000 bzw. Reinhard , ich habe noch zwei Punkte für dich :
1. Das Gemecker wegen den ** Nummern passiert , wenn
a. stacktrace aktiv ist und b. nur die Rufnummer übergeben wird ohne jeden weiteren Parameter.
Den Fall habe ich im nächsten Update gefixt, ist wie gesagt aber lediglich ein Schönheitsfehler
2. Nimm dir nochmal die Version vor die immer wegen dem Port in Leg.pm stirbt. Suche dann im 96_SIP.pm den Abschnit :
# create new agent
$ua = Net::SIP::Simple->new(
registrar => $registrar,
domain => $registrar,
leg => $leg,
from => $from,
auth => [ $user , SIP_readPassword($name) ]);
# Register agent
(müsste so um die Zeile 340 sein)
ändere dort die Zeile leg => $leg, in leg => $ip, und lade das Modul mit "reload 96_SIP" neu.
Mit dieser Änderung legst zu meine vorab Prüfung ob der Port frei ist komplett lahm und überlässt es Leg.pm einen freien Port zu finden.
Läuft es dann bei dir ohne Fehler hätte ich zumindest mal ne Richtung in der ich suchen könnte.
Hallo Wzut,
ich teste heute noch sofort die von dir vorgeschlagenen Änderungen und berichte.
Ich habe jetzt den Störenfried ausgemacht, welcher (bei mir) mit SIP nicht kann oder will:
Stelle ich den HMCCURPC Server ab (HMCCU ohne ext. RPC Server), so kommt jeder Ruf (mit intern **52 gestestet) an.
Schalte ich diesen wieder ein, so kommt immer die Meldung mit dem belegten Port.
Was ich mir jedoch nicht erklären kann, der Ruf geht raus, ich höre aber DMTF Töne obwohl ich nur eine Nummer "set TelefonClient call **52 30" wählen will.
Im Log steht folgendes:
2017.12.01 20:42:14 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.12.01 20:42:14 4: TelefonClient, TelefonClient|**52|30||0
2017.12.01 20:42:14 4: TelefonClient, call -> TelefonClient|**52|30||0|0
2017.12.01 20:42:14 5: TelefonClient, call has pid 2573
2017.12.01 20:42:14 4: TelefonClient[2573], my parent is 2513
2017.12.01 20:42:14 4: TelefonClient[2573], using random port 44372
2017.12.01 20:42:15 4: TelefonClient[2573], register new expire : 2017-12-01 20:47:15
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient state calling exit
2017.12.01 20:42:15 4: TelefonClient[2573], CallStart DTMF : ABCD*#123--4567890
2017.12.01 20:42:15 4: TelefonClient[2573], calling : **52
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient call_state calling **52 exit
2017.12.01 20:42:15 4: TelefonClient[2573], cb_final - status : FAIL - final : 481
2017.12.01 20:42:15 5: TelefonClient[2573], telnet : set TelefonClient call_state ringing exit
2017.12.01 20:42:19 4: TelefonClient[2573], cb_final - Status : OK
2017.12.01 20:42:19 4: TelefonClient[2573], call established
2017.12.01 20:42:19 5: TelefonClient[2573], telnet : set TelefonClient call_state established exit
2017.12.01 20:42:29 5: TelefonClient[2573], 0. Ende des ersten Loops
2017.12.01 20:42:29 5: TelefonClient[2573], 1. rtp_done : OK
2017.12.01 20:42:29 5: TelefonClient[2573], 2. fi : 0
2017.12.01 20:42:29 5: TelefonClient[2573], 3. timeout : 0
2017.12.01 20:42:29 5: TelefonClient[2573], RTP done : OK
2017.12.01 20:42:29 5: TelefonClient[2573], Timeout : 0
2017.12.01 20:42:29 5: TelefonClient[2573], while : 0
2017.12.01 20:42:29 4: TelefonClient, CALLDone -> TelefonClient|1|ok
2017.12.01 20:42:29 5: TelefonClient, fifo is empty
2017.12.01 20:42:29 5: TelefonClient, no elbc
Hänge ich dagegen eine Textansage an, so höre ich nichts auch keine DMTF Töne und auch keinen Text. Logauszug gerne wenn du ihn brauchst.
Ich hoffe du kannst mit der Eingrenzung des Fehlers etwas anfangen, leider kann ich mangels guten Perl Kentnissen bei der Fehlersuche nicht viel helfen.
Danke und Gruß
Reinhard
Hallo Wzut,
anbei meine, von dir vorgeschlagenen Versuche:
zu 1.
ZitatDas Gemecker wegen den ** Nummern passiert .....
Irgendwie ist bei mir alles komisch, momentan finde ich die gestern beschriebene Meldung nicht mehr im Log!
Warscheinlich habe ich gestern Nacht nur davon geträumt, nach der endlosen Suche des kuriosen Fehlers. ;)
zu 2.
Zitatändere dort die Zeile leg => $leg, in leg => $ip, und lade das Modul mit "reload 96_SIP" neu.
Jeder Ruf geht raus, es werden aber immer DMTF Töne angehängt, genau wie von mir beschrieben. https://forum.fhem.de/index.php/topic,67443.msg724470.html#msg724470 (https://forum.fhem.de/index.php/topic,67443.msg724470.html#msg724470)
Auch das Log sieht nahezu identisch aus. Kann mir nicht erklären, woher der DMTF Anhang
"ABCD*#123--4567890" kommt.
2017.12.01 21:11:52 4: TelefonClient, calling **52, ringtime: 30 , no message
2017.12.01 21:11:52 4: TelefonClient, TelefonClient|**52|30||0
2017.12.01 21:11:52 4: TelefonClient, call -> TelefonClient|**52|30||0|0
2017.12.01 21:11:52 5: TelefonClient, call has pid 2795
2017.12.01 21:11:52 4: TelefonClient[2795], my parent is 2513
2017.12.01 21:11:52 4: TelefonClient[2795], using random port 44031
2017.12.01 21:11:52 4: TelefonClient[2795], register new expire : 2017-12-01 21:16:52
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient state calling exit
2017.12.01 21:11:52 4: TelefonClient[2795], CallStart DTMF : ABCD*#123--4567890
2017.12.01 21:11:52 4: TelefonClient[2795], calling : **52
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient call_state calling **52 exit
2017.12.01 21:11:52 4: TelefonClient[2795], cb_final - status : FAIL - final : 481
2017.12.01 21:11:52 5: TelefonClient[2795], telnet : set TelefonClient call_state ringing exit
2017.12.01 21:11:58 4: TelefonClient[2795], cb_final - Status : OK
2017.12.01 21:11:58 4: TelefonClient[2795], call established
2017.12.01 21:11:58 5: TelefonClient[2795], telnet : set TelefonClient call_state established exit
2017.12.01 21:12:08 5: TelefonClient[2795], 0. Ende des ersten Loops
2017.12.01 21:12:08 5: TelefonClient[2795], 1. rtp_done : OK
2017.12.01 21:12:08 5: TelefonClient[2795], 2. fi : 0
2017.12.01 21:12:08 5: TelefonClient[2795], 3. timeout : 0
2017.12.01 21:12:08 5: TelefonClient[2795], RTP done : OK
2017.12.01 21:12:08 5: TelefonClient[2795], Timeout : 0
2017.12.01 21:12:08 5: TelefonClient[2795], while : 0
2017.12.01 21:12:08 4: TelefonClient, CALLDone -> TelefonClient|1|ok
2017.12.01 21:12:08 5: TelefonClient, fifo is empty
2017.12.01 21:12:08 5: TelefonClient, no elbc
Zu meiner Fhem Konfiguration:
Ich verwende viele HmIP Komponenten, die Anbindung an den Raspi zu Fhem erfolgt hier über eine CCU2 über ein HMCCU-Device und wegen der deutlich schnelleren Datenverbindung zur CCU2 habe ich den externen RPC-Server (HMCCURPC-Device) eingerichtet.
Ich kann diese jederzeit aktiv oder passiv schalten, ohne Beeinträchtigung der Funktion.
Wenn ich noch was testen soll, gerne.
Gruß Reinhard
die ABCD*#123--4567890 sind hardgecodet im Modul, denn irgendetwas muss gesendet werden wenn der User schon so geizig ist und nichts übergibt !
Aber jetzt läuft auch dein Problemkind mit dem ändern von $leg auf $ip ????
Edit :
ZitatStelle ich den HMCCURPC Server ab (HMCCU ohne ext. RPC Server), so kommt jeder Ruf (mit intern **52 gestestet) an.
Schalte ich diesen wieder ein, so kommt immer die Meldung mit dem belegten Port.
hatte ich übersehen !!! THX
Zitat von: Rewe2000 am 01 Dezember 2017, 21:04:04
Hänge ich dagegen eine Textansage an, so höre ich nichts auch keine DMTF Töne und auch keinen Text. Logauszug gerne wenn du ihn brauchst.
Wie schaut denn dein Aufruf mit Textnachricht aus ? und ja Log hilft ungemein
Hallo Wzut,
ich wollte gestern nicht das gesamte Forum mit irgend welchen ewig langen Loganhängen zumüllen, aber ohne grundlegende Infos kann kein Fehler gefunden werden, deshalb wollte ich eben verschiedene Versuche machen und dir die Fehlerlogs übermitteln.
Es ist aber Absolut kurios, jetzt geht SIP so wie er soll. >:(
Ein Text im Anhang wird brav vorgelesen, DTMF im Anhang wird korrekt vorgespielt. Ich versteh die Welt nicht mehr, gestern war alles anders so wie ich es in meinen gestrigen Beitrag auch geschrieben habe.
Befehl: "set TelefonClient call **52 30"
In der aktuellen Konfiguration mit "leg => $ip" klingelt der Apparat und SIP spielt mir ungewollt die DMTF Töne vor.
Das mit den angehängten DTMF Tönen im obigen Ruf ist das von dir so gewollt?
Ich bin mir absolut sicher, dass in der Fhem Minimalkonfiguration nur das Telefon geklingelt und dann hat SIP nach dem abheben sofort wieder aufgelegt. So habe ich es auch gemäß des sehr gut und ausführlich geschriebenen Wiki-Beitrags auch erwartet.
Damit könnte ich aber prima leben, denn irgend eine Message soll ja durch einen Anruf übermittelt werden.
Ich habe schon fast die Vermutung das HMCCURPC Modul blockiert sporadisch irgend welche Ports für SIP, denn im meiner gestrigen Versuchsreihe, als ich Device um Device aus Fhem entfernt hatte, kamen auch sporadisch mal einzelne Rufe an. Erst als ich das HMCCURPC Device abgeschaltet (nicht gelöscht) hatte, kam zuverlässig jeder Ruf an, wenn auch mit den geschilderten Abweichungen bei den Anhängen.
Ich beobachte die Situation bei mir und melde mich wieder (mit Logauszügen) wenn die Fehler erneut auftreten sollten.
Bei dir und allen Helfern im Forum möchte ich mich für die Unterstützung bei der Fehlersuche bedanken.
Gruß Reinhard
Zitat von: Rewe2000 am 02 Dezember 2017, 11:49:46
Es ist aber Absolut kurios, jetzt geht SIP so wie er soll. >:(
Ein Text im Anhang wird brav vorgelesen, DTMF im Anhang wird korrekt vorgespielt. Ich versteh die Welt nicht mehr, gestern war alles anders so wie ich es in meinen gestrigen Beitrag auch geschrieben habe.
tja, ein Kollege nennt so etwas EDPM - electronic data processing mysteries
Zitat von: Rewe2000 am 02 Dezember 2017, 11:49:46
Das mit den angehängten DTMF Tönen im obigen Ruf ist das von dir so gewollt?
Ich bin mir absolut sicher, dass in der Fhem Minimalkonfiguration nur das Telefon geklingelt und dann hat SIP nach dem abheben sofort wieder aufgelegt. So habe ich es auch gemäß des sehr gut und ausführlich geschriebenen Wiki-Beitrags auch erwartet.
Wie oben bereits geschrieben, ja das ist so gewollt ! damit der User direkt nach dem Einrichten einen Schnellschuss ala "set mySIP call Nummer" machen kann.
Im Wiki stand IMHO auch mal ein Satz wie "dann hört man ein Geräusch" inzwischen finde ich aber nur noch diese Stelle
ZitatWird kein Audiofile angegeben, wird nur die Verbindung hergestellt und nach der Anrufdauer wieder unterbrochen.
und das ist in der Tat etwas irreführend, denn einen Call ganz ohne alles gibt es nicht. D.h. entweder DTMF oder Soundatei.
Hallo,
nachdem nun meine größeren Startschwirigkeiten beseitigt sind, komme ich endlich dazu, das Device zu testen.
Ich muss echt sagen, ich bin begeistert was sich damit alles machen lässt.
Ich werde es derzeit nutzen, mich bei Störungen anrufen zu lassen, mangels des sehr schlechten GSM-Empfangs in der Arbeit geht Pushover nicht, was nutzt mir, wenn ich 10 Meldungen aufs Handy bekomme, wenn ich endlich mal wieder Netzempfang habe. Ein Anruf kommt eher an und es gibt ja auch noch Festnetztelefone.
Habe mal das sehr gut dokumentierte Wiki zum SIP-Device gelesen und einiges getestet (ohne einen einzigen Fehler) :) :) :),
da stellt sich mir schon die erste Frage.
Es gibt im Device die Möglichkeit einen Anruf ein einziges Mal abzusenden oder diesen mit dem Anhang "&" als wichtig zu kennzeichnen. Setze ich nun das Attribut sip_force auf z.B. 300, wird der Anruf endlos (alle 5 Minuten) wiederholt, bis dieser angenommen wird.
Gibt es irgend eine Möglichkeit anzugeben, wie oft ein Anrufversuch unternommen werden soll, wenn der Anruf nicht angenommen wird?
Hintergrund:
Ich will mich über einen internen Rundruf, über die Fritz!Box, vor bei Kälte zu lang geöffneten Fenster warnen lassen. Da kann es schon mal beim Staubsaugen vorkommen, dass der Anruf im Lärm untergeht.
Die nächste "Eskalationsstufe" wäre der Anhang "&", wenn ich dann Tagsüber bei milderen Temperaturen ein gekipptes Fenster vergesse zu schließen, steinigen mich die Nachbarn wegen Telefonterror, wenn ich abends heimkomme.
Schön wäre da die Angabe, bei Nichterreichbarkeit nur x mal zu klingeln.
Ich denke aber das wird sich mit der "at" lösung im Modul nur sehr schwer umsetzen lassen.
Wenn es hier keine Möglichkeit mit SIP gibt, könnte ich dies auch Fhem intern umsetzen, indem ich die Readings von SIP auswerte und entsprechend reagiere.
Ich will euch mal fragen, bevor ich mir hier unnötige Arbeit mache.
Grundsätzlich sind ja aufgrund von Faulheit die besten Erfindungen entstanden. :D
Gruß Reinhard
Zitat von: Rewe2000 am 02 Dezember 2017, 20:21:44
Grundsätzlich sind ja aufgrund von Faulheit die besten Erfindungen entstanden. :D
OT on
Ich war früher in der Instandhaltung und da hatten wir den Spruch das ein guter Instandhalter grundsätzlich faul sein muß, denn dann kümmert er sich so um seine Anlagen das er möglichst viel seine Ruhe vor ihnen hat :)
OT off
Das Thema Force kam hier noch nicht oft vor, daher habe ich auch keine Ahnung wie und wie oft es überhaupt bei den Usern zum Einsatz kommt.
Generell ist die heutige Umsetzung für dein Sezenario dann nur bedingt geeignet. Aber wenn schon Force beschneiden dann richtig.
Ich könne mir vorstellen das von Fall zu Fall vom Call abhängig zu machen, also auch ggf. das sip_force Attribut mit zu überschreiben
Bsp:
set mySIP call **1 10 !Fenster ist offen 2 & <--- Das hätten wir heute
set mySIP call **1 10 !Fenster ist offen 2 &5 <--- Force beschränkt auf max. 5 Versuche
set mySIP call **1 10 !Fenster ist offen 2 &0,30 <--- die 30 überschreibt zusätzlich das Attribut sip_force, die 0 steht für unendliche Versuche
Ich muss mal schauen ob zwischen Weihnachten und Neujahr etwas Luft zum basteln ist.
Eine selbstprogrammierte Schleife in FHEM könnte die Readings call_state und call_success nutzen.
@wzut: Ich denke für Force fehlt noch ein Reading call_attempt, damit man die Anzahl Versuche auswerten kann.
Hallo,
@Wzut
OT on
Irgendwie habe ich mich mit dem letzten Beitrag geoutet und du hast mich durchschaut, ich arbeite tatsächlich seit über 40 Jahren als Instandhalter. Ist diese Berufsgruppe wirklich fauler als andere? Oder intelligenter, das sie notwendige Arbeiten anderen erledigen lässt. ;)
OT off
Solch eine Funktion mit der Angabe der Rufversuche wäre natürlich toll, wenn sich so etwas umsetzen lassen würde. Sollte sich mit dem Rufbefehl auch gleich noch individuell die Dauer der Pausen zwischen den Rufen überschreiben lassen, so wäre dies eine absolute Komfortlösung.
Ein Punkt würde mich noch interessieren, wirst du wegen dem "leg => $ip" irgend etwas an deinem Modul ändern?
Oder muss ich nach jedem Update deines Moduls, diese Zeile wieder von Hand anpassen?
Ich werde mal im Homematic Board nachfragen, wer auch noch HMCCURPC und SIP auf einem RASPI mit Stretch verwendet, eigentlich sollte es ja hier auch die gleichen Probleme wie bei mir gegeben haben.
@plin
Ich denke auch, dass bei einem Umbau des Device ein Reading in der Form "call_attempt" nicht verkehrt wäre, somit könnte die Anzahl der Rufversuche erkannt und auch ausgewertet werden.
Probleme könnte es ggf. nur mit sehr kurz aufeinander folgenden Rufen (gestackten Rufen) geben, die Zuordnung von "call_attempt" zum dazugehörigen call wird da schon eine Herausforderung.
Schönen ersten Advent, Gruß
Reinhard
ich fang mal hinten an :
call_attempt -> klingt gut, das kleine Problem ist nur das Modul hat keinerlei Gedächnis über bereits gelaufende Versuche. Ich habe das damals aus "Faulheit" ja simpel über das temporäre at gelöst statt über eine eigene Queue zu jedem Call. D.h es ginge heute nur über zusäzliche Parameter im Callstring die dann beim at define quasi mit hochgezählt werden. Ich bin z.Z.noch am überlegen.
leg => $ip -> ja das habe ich schon vorbereitet
Zitat von: Wzut am 03 Dezember 2017, 11:37:02
call_attempt -> klingt gut, das kleine Problem ist nur das Modul hat keinerlei Gedächnis über bereits gelaufende Versuche.
keep it simple - reading call_attempt beim neuen SET CALL auf 0 setzen. Dann bei jedem erneuten Versuch reading auslesen, eins drauf, wieder zurückschreiben??? Da nicht allzuviele Nutzer die Force-Option zu nutzen scheinen ist der weltweite Gesamt-Overhead durch diese Lösung gering ;D
ja ja keep it simple - Das Modul ist inzwischen alles andere als Simple ....
Das merke ich immer wieder wenn ich in den Code schaue und feststelle "Huch da hast ja schon mal dies und das gemacht" , hatte da gerade wieder so ein Ah Ha Erlebnis :
Laut Wiki hängt der User ja heute nur ein einfaches & an , das Modul macht aber daraus beim Temp at definieren bereits ein &300 ( wenn sip_force_interval keinen anderen Wert hat. )
D.h. schon heute ist es machbar das sip_force_interval schon direkt zu ersetzen in dem man die Wiederholzeit einfach an das & direkt anhängt !
Auf der Basis habe ich jetzt einfach mal weitergemacht und wandele das einfache & nicht in &300 sondern in &300,99,0
Die 99 sind die maximal Anzahl an Versuchen, die 0 die bisherigen. Sobald die Anzahl der Versuche größer als max ist wird einfach kein neues Temp at erzeugt und der Spuck hat ein Ende.
Die 99 schrie natürlich förmlich nach einem neuen Attribut sip_force_max , dadurch kann die Anzahl global im Attribut festgelegt werden oder halt vom User nach Bedarf
Bsp set mySIP call **1 5 !Test &120,10 -> maximal 10 Versuche mit einer Frequenz von 2 Minuten
so geht's natürlich auch 8)
So wie bereist versprochen hier eine neue Beta Version zum Testen.
NEU : die vorhin beschriebene Änderung zu Force mit neuem Attribut sip_force_max
FiX: teilweise nicht gesetzte CALL_TIME
UPDATE : Die Random Port Vergabe ( attr sip_port nicht gesetzt oder 0 ) wurde komplett entfernt und wird nun wenn vom User kein fester Port gesetzt ist komplett von Leg.pm übernommen (Problem von Rewe2000 in Verbindung mit dem externen HM RPC Server)
UPDATE : User wie Muschelpuster haben das Problem das die FB nach erreichen der max Time einfach weiterklingelt.
Nachdem Muschelpuster direkten Kontakt mit Steffen Ullrich (dem Autor von Net::SIP) aufgenommen hatte, hat dieser im CPAN eine neue Version (0.812) zur Verfügung gestellt. Allerdings löste diese neue Version das Klingelproblem nocht nicht ganz, das sollte nun hoffentlich hiermit erledigt sein.
ACHTUNG : Diese angehängte V1.70 ist ausführlich mit Net::SIP 0.812 getestet, es kann daher sein das u.U. mit der bisherigen 0.808 neue Probleme enstehen.
Frohes Testen , mit dem svn Update werde ich wieder eine Zeitlang eure (hoffentlich) positiven Rückmeldungen abwarten.
Das erste schnelle Feedback (vor dem Abendessen):
- sip_port gelöscht
- sip_force_interval und sip_force_max gesetzt, CALL mit & abgesetzt, klingeln lassen -> ok, Intervall und Anzahl passen
- sip_force_interval und sip_force_max gelöscht, CALL mit &10,5,0 abgesetzt, klingeln lassen -> ok, Intervall und Anzahl passen
- sip_force_interval und sip_force_max gelöscht, CALL mit &10,5,0 abgesetzt, beim ersten Klingeln abgehoben -> nok
Bei der Rufannahme wurde mir krächzend die DTMF-Folge vorgespielt. Sah also gut aus. Aber call_success stand immer noch auf 0. Und nach dem Intervall gings weiter. Noch ein Anruf. Nimmt man ihn an, wird kein DTMF mehr vorgespielt. Der Anruf dauert bis man ihn aktiv beendet. Das beendet aber nicht den Telefonterror, nach dem nächsten Intervall kommt der nächste Anruf.
hmm komisch , d.h. bei dir passt das was im Temp at steht nicht zu deinem eigentlich abgesetzten Call ?
Kannst du bitte mal von so einem Fall ein verbose 5 Log Abschnitt posten ?
kurze Ergänzung vor dem verbose log:
sip_port auf 5070 gesetzt
sip_force_interval und sip_force_max gesetzt
CALL **622 5 -123 & abgesetzt
2x klingeln lassen,
dritten Anruf angenommen
DTMF wird vorgespielt
Call endet
Anrufserie endet
Und hier das fhem-log zu Call **622 5 -123 &10,5,0
2017.12.03 19:59:11 5: SipTest, listen process 2279 found
2017.12.03 19:59:12 4: SipTest[2279], register new expire : 2017-12-03 20:04:12
2017.12.03 19:59:12 5: SipTest[2279], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2279 set SipTest expire 300 exit
2017.12.03 19:59:40 3: SipTest, force call &10,5,0
2017.12.03 19:59:40 4: SipTest, listen process 2279 must be killed befor we start a new call !
2017.12.03 19:59:40 1: Timeout for SIP_ListenStart reached, terminated process 2279
2017.12.03 19:59:40 4: SipTest, message DTMF = -123
2017.12.03 19:59:40 4: SipTest, SipTest|**622|5|-123|0
2017.12.03 19:59:40 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,0
2017.12.03 19:59:40 5: SipTest, call has pid 2395
2017.12.03 19:59:40 4: SipTest[2395], my parent is 1694
2017.12.03 19:59:40 4: SipTest[2395], trying to use port 5080
2017.12.03 19:59:41 4: SipTest[2395], register new expire : 2017-12-03 20:04:41
2017.12.03 19:59:41 5: SipTest[2395], telnet : set SipTest state calling set SipTest listen_alive PID_2395 set SipTest expire 300 exit
2017.12.03 19:59:41 4: SipTest[2395], CallStart DTMF : 123
2017.12.03 19:59:41 4: SipTest[2395], calling : **622
2017.12.03 19:59:41 5: SipTest[2395], telnet : set SipTest call_state calling **622 exit
2017.12.03 19:59:46 5: SipTest[2395], 0. Ende des ersten Loops
2017.12.03 19:59:46 5: SipTest[2395], 1. rtp_done : 0
2017.12.03 19:59:46 5: SipTest[2395], 2. fi : 0
2017.12.03 19:59:46 5: SipTest[2395], 4. timeout : 1
2017.12.03 19:59:46 5: SipTest[2395], 6. call_established : 0
2017.12.03 19:59:46 5: SipTest[2395], call->cancel
2017.12.03 19:59:46 4: SipTest[2395], cb_final - status : FAIL - final : 487
2017.12.03 19:59:46 5: SipTest[2395], RTP done : 0
2017.12.03 19:59:46 5: SipTest[2395], Timeout : 1
2017.12.03 19:59:46 5: SipTest[2395], Final : 487
2017.12.03 19:59:46 5: SipTest[2395], while : 0
2017.12.03 19:59:46 4: SipTest, CALLDone -> SipTest|1|no answer
2017.12.03 19:59:46 4: SipTest, at_forcecall_622 at +00:00:10 set SipTest call **622 5 -123 *0 &10,5,1
2017.12.03 19:59:46 5: SipTest, fifo is empty
2017.12.03 19:59:46 4: SipTest, try restarting listen process after call ends
2017.12.03 19:59:46 4: SipTest, Listen new PID : 2399
2017.12.03 19:59:46 4: SipTest[2399], my parent is 1694
2017.12.03 19:59:46 4: SipTest[2399], trying to use port 5070
2017.12.03 19:59:48 4: SipTest[2399], register new expire : 2017-12-03 20:04:48
2017.12.03 19:59:48 5: SipTest[2399], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2399 set SipTest expire 300 exit
2017.12.03 19:59:48 3: SipTest[2399], audio file /tmp/myaudio.araw not found, ignoring it
2017.12.03 19:59:48 3: SipTest[2399], audio file /tmp/beep-02-short.alaw not found, ignoring it
2017.12.03 19:59:56 3: SipTest, force call &10,5,1
2017.12.03 19:59:56 4: SipTest, listen process 2399 must be killed befor we start a new call !
2017.12.03 19:59:56 1: Timeout for SIP_ListenStart reached, terminated process 2399
2017.12.03 19:59:56 4: SipTest, message DTMF = -123
2017.12.03 19:59:56 4: SipTest, SipTest|**622|5|-123|0
2017.12.03 19:59:56 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,1
2017.12.03 19:59:56 5: SipTest, call has pid 2403
2017.12.03 19:59:56 4: SipTest[2403], my parent is 1694
2017.12.03 19:59:56 4: SipTest[2403], trying to use port 5080
2017.12.03 19:59:56 4: SipTest[2403], register new expire : 2017-12-03 20:04:56
2017.12.03 19:59:56 5: SipTest[2403], telnet : set SipTest state calling set SipTest listen_alive PID_2403 set SipTest expire 300 exit
2017.12.03 19:59:57 4: SipTest[2403], CallStart DTMF : 123
2017.12.03 19:59:57 4: SipTest[2403], calling : **622
2017.12.03 19:59:57 5: SipTest[2403], telnet : set SipTest call_state calling **622 exit
2017.12.03 20:00:00 4: SipTest[2403], cb_final - Status : OK
2017.12.03 20:00:00 4: SipTest[2403], call established
2017.12.03 20:00:00 5: SipTest[2403], telnet : set SipTest call_state established exit
2017.12.03 20:00:01 5: SipTest[2403], 0. Ende des ersten Loops
2017.12.03 20:00:01 5: SipTest[2403], 1. rtp_done : 0
2017.12.03 20:00:02 5: SipTest[2403], 2. fi : 0
2017.12.03 20:00:02 5: SipTest[2403], 4. timeout : 1
2017.12.03 20:00:02 5: SipTest[2403], 6. call_established : 1
2017.12.03 20:00:02 5: SipTest[2403], call->bye
2017.12.03 20:00:02 5: SipTest[2403], RTP done : 0
2017.12.03 20:00:02 5: SipTest[2403], Timeout : 1
2017.12.03 20:00:02 5: SipTest[2403], while : 0
2017.12.03 20:00:02 4: SipTest, CALLDone -> SipTest|1|timeout
2017.12.03 20:00:02 4: SipTest, at_forcecall_622 at +00:00:10 set SipTest call **622 5 -123 *0 &10,5,2
2017.12.03 20:00:02 5: SipTest, fifo is empty
2017.12.03 20:00:02 4: SipTest, try restarting listen process after call ends
2017.12.03 20:00:02 4: SipTest, Listen new PID : 2407
2017.12.03 20:00:02 4: SipTest[2407], my parent is 1694
2017.12.03 20:00:02 4: SipTest[2407], trying to use port 5070
2017.12.03 20:00:02 4: SipTest[2407], register new expire : 2017-12-03 20:05:02
2017.12.03 20:00:02 5: SipTest[2407], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2407 set SipTest expire 300 exit
2017.12.03 20:00:02 3: SipTest[2407], audio file /tmp/myaudio.araw not found, ignoring it
2017.12.03 20:00:02 3: SipTest[2407], audio file /tmp/beep-02-short.alaw not found, ignoring it
2017.12.03 20:00:12 3: SipTest, force call &10,5,2
2017.12.03 20:00:12 4: SipTest, listen process 2407 must be killed befor we start a new call !
2017.12.03 20:00:12 1: Timeout for SIP_ListenStart reached, terminated process 2407
2017.12.03 20:00:12 4: SipTest, message DTMF = -123
2017.12.03 20:00:12 4: SipTest, SipTest|**622|5|-123|0
2017.12.03 20:00:12 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,2
2017.12.03 20:00:12 5: SipTest, call has pid 2411
2017.12.03 20:00:12 4: SipTest[2411], my parent is 1694
2017.12.03 20:00:12 4: SipTest[2411], trying to use port 5080
2017.12.03 20:00:12 4: SipTest[2411], register new expire : 2017-12-03 20:05:12
2017.12.03 20:00:12 5: SipTest[2411], telnet : set SipTest state calling set SipTest listen_alive PID_2411 set SipTest expire 300 exit
2017.12.03 20:00:13 4: SipTest[2411], CallStart DTMF : 123
2017.12.03 20:00:13 4: SipTest[2411], calling : **622
2017.12.03 20:00:13 5: SipTest[2411], telnet : set SipTest call_state calling **622 exit
2017.12.03 20:00:18 5: SipTest[2411], 0. Ende des ersten Loops
2017.12.03 20:00:18 5: SipTest[2411], 1. rtp_done : 0
2017.12.03 20:00:18 5: SipTest[2411], 2. fi : 0
2017.12.03 20:00:18 5: SipTest[2411], 4. timeout : 1
2017.12.03 20:00:18 5: SipTest[2411], 6. call_established : 0
2017.12.03 20:00:18 5: SipTest[2411], call->cancel
2017.12.03 20:00:18 4: SipTest[2411], cb_final - status : FAIL - final : 487
2017.12.03 20:00:18 5: SipTest[2411], RTP done : 0
2017.12.03 20:00:18 5: SipTest[2411], Timeout : 1
2017.12.03 20:00:18 5: SipTest[2411], Final : 487
2017.12.03 20:00:18 5: SipTest[2411], while : 0
2017.12.03 20:00:18 4: SipTest, CALLDone -> SipTest|1|no answer
2017.12.03 20:00:18 4: SipTest, at_forcecall_622 at +00:00:10 set SipTest call **622 5 -123 *0 &10,5,3
2017.12.03 20:00:18 5: SipTest, fifo is empty
2017.12.03 20:00:18 4: SipTest, try restarting listen process after call ends
2017.12.03 20:00:18 4: SipTest, Listen new PID : 2415
2017.12.03 20:00:18 4: SipTest[2415], my parent is 1694
2017.12.03 20:00:18 4: SipTest[2415], trying to use port 5070
2017.12.03 20:00:18 4: SipTest[2415], register new expire : 2017-12-03 20:05:18
2017.12.03 20:00:18 5: SipTest[2415], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2415 set SipTest expire 300 exit
2017.12.03 20:00:18 3: SipTest[2415], audio file /tmp/myaudio.araw not found, ignoring it
2017.12.03 20:00:18 3: SipTest[2415], audio file /tmp/beep-02-short.alaw not found, ignoring it
2017.12.03 20:00:26 4: ESPEasy EspDev3con: set statusRequest
2017.12.03 20:00:26 4: ESPEasy EspDev3con: presence: absent
2017.12.03 20:00:26 5: ESPEasy EspDev3con: Start internalTimer +304 => 2017-12-03 20:05:30
2017.12.03 20:00:28 3: SipTest, force call &10,5,3
2017.12.03 20:00:28 4: SipTest, listen process 2415 must be killed befor we start a new call !
2017.12.03 20:00:28 1: Timeout for SIP_ListenStart reached, terminated process 2415
2017.12.03 20:00:28 4: SipTest, message DTMF = -123
2017.12.03 20:00:28 4: SipTest, SipTest|**622|5|-123|0
2017.12.03 20:00:28 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,3
2017.12.03 20:00:28 5: SipTest, call has pid 2419
2017.12.03 20:00:28 4: SipTest[2419], my parent is 1694
2017.12.03 20:00:28 4: SipTest[2419], trying to use port 5080
2017.12.03 20:00:28 4: SipTest[2419], register new expire : 2017-12-03 20:05:28
2017.12.03 20:00:28 5: SipTest[2419], telnet : set SipTest state calling set SipTest listen_alive PID_2419 set SipTest expire 300 exit
2017.12.03 20:00:28 4: SipTest[2419], CallStart DTMF : 123
2017.12.03 20:00:28 4: SipTest[2419], calling : **622
2017.12.03 20:00:28 5: SipTest[2419], telnet : set SipTest call_state calling **622 exit
2017.12.03 20:00:32 4: SipTest[2419], cb_final - Status : OK
2017.12.03 20:00:32 4: SipTest[2419], call established
2017.12.03 20:00:32 5: SipTest[2419], telnet : set SipTest call_state established exit
2017.12.03 20:00:33 5: SipTest[2419], 0. Ende des ersten Loops
2017.12.03 20:00:33 5: SipTest[2419], 1. rtp_done : 0
2017.12.03 20:00:33 5: SipTest[2419], 2. fi : 0
2017.12.03 20:00:33 5: SipTest[2419], 4. timeout : 1
2017.12.03 20:00:33 5: SipTest[2419], 6. call_established : 1
2017.12.03 20:00:33 5: SipTest[2419], call->bye
2017.12.03 20:00:34 5: SipTest[2419], RTP done : 0
2017.12.03 20:00:34 5: SipTest[2419], Timeout : 1
2017.12.03 20:00:34 5: SipTest[2419], while : 0
2017.12.03 20:00:34 4: SipTest, CALLDone -> SipTest|1|timeout
2017.12.03 20:00:34 4: SipTest, at_forcecall_622 at +00:00:10 set SipTest call **622 5 -123 *0 &10,5,4
2017.12.03 20:00:34 5: SipTest, fifo is empty
2017.12.03 20:00:34 4: SipTest, try restarting listen process after call ends
2017.12.03 20:00:34 4: SipTest, Listen new PID : 2423
2017.12.03 20:00:34 4: SipTest[2423], my parent is 1694
2017.12.03 20:00:34 4: SipTest[2423], trying to use port 5070
2017.12.03 20:00:34 4: SipTest[2423], register new expire : 2017-12-03 20:05:34
2017.12.03 20:00:34 5: SipTest[2423], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2423 set SipTest expire 300 exit
2017.12.03 20:00:34 3: SipTest[2423], audio file /tmp/myaudio.araw not found, ignoring it
2017.12.03 20:00:34 3: SipTest[2423], audio file /tmp/beep-02-short.alaw not found, ignoring it
2017.12.03 20:00:44 3: SipTest, force call &10,5,4
2017.12.03 20:00:44 4: SipTest, listen process 2423 must be killed befor we start a new call !
2017.12.03 20:00:44 1: Timeout for SIP_ListenStart reached, terminated process 2423
2017.12.03 20:00:44 4: SipTest, message DTMF = -123
2017.12.03 20:00:44 4: SipTest, SipTest|**622|5|-123|0
2017.12.03 20:00:44 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,4
2017.12.03 20:00:44 5: SipTest, call has pid 2427
2017.12.03 20:00:44 4: SipTest[2427], my parent is 1694
2017.12.03 20:00:44 4: SipTest[2427], trying to use port 5080
2017.12.03 20:00:44 4: SipTest[2427], register new expire : 2017-12-03 20:05:44
2017.12.03 20:00:44 5: SipTest[2427], telnet : set SipTest state calling set SipTest listen_alive PID_2427 set SipTest expire 300 exit
2017.12.03 20:00:44 4: SipTest[2427], CallStart DTMF : 123
2017.12.03 20:00:44 4: SipTest[2427], calling : **622
2017.12.03 20:00:44 5: SipTest[2427], telnet : set SipTest call_state calling **622 exit
2017.12.03 20:00:48 4: SipTest[2427], cb_final - Status : OK
2017.12.03 20:00:48 4: SipTest[2427], call established
2017.12.03 20:00:48 5: SipTest[2427], telnet : set SipTest call_state established exit
2017.12.03 20:00:49 5: SipTest[2427], 0. Ende des ersten Loops
2017.12.03 20:00:49 5: SipTest[2427], 1. rtp_done : 0
2017.12.03 20:00:49 5: SipTest[2427], 2. fi : 0
2017.12.03 20:00:49 5: SipTest[2427], 4. timeout : 1
2017.12.03 20:00:49 5: SipTest[2427], 6. call_established : 1
2017.12.03 20:00:49 5: SipTest[2427], call->bye
2017.12.03 20:00:49 5: SipTest[2427], RTP done : 0
2017.12.03 20:00:49 5: SipTest[2427], Timeout : 1
2017.12.03 20:00:49 5: SipTest[2427], while : 0
2017.12.03 20:00:49 4: SipTest, CALLDone -> SipTest|1|timeout
2017.12.03 20:00:49 3: SipTest, at_forcecall_622 max count 5 reached giving up !
2017.12.03 20:00:49 5: SipTest, fifo is empty
2017.12.03 20:00:49 4: SipTest, try restarting listen process after call ends
2017.12.03 20:00:49 4: SipTest, Listen new PID : 2431
2017.12.03 20:00:49 4: SipTest[2431], my parent is 1694
2017.12.03 20:00:49 4: SipTest[2431], trying to use port 5070
2017.12.03 20:00:49 4: SipTest[2431], register new expire : 2017-12-03 20:05:49
2017.12.03 20:00:49 5: SipTest[2431], telnet : set SipTest state listen_echo set SipTest listen_alive PID_2431 set SipTest expire 300 exit
2017.12.03 20:00:49 3: SipTest[2431], audio file /tmp/myaudio.araw not found, ignoring it
2017.12.03 20:00:49 3: SipTest[2431], audio file /tmp/beep-02-short.alaw not found, ignoring it
2017.12.03 20:01:49 5: SipTest, listen process 2431 found
Also das Thema Force und meine dazu gemachten Änderungen sehen gut aus :
2017.12.03 19:59:40 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,0
--snipp--
2017.12.03 20:00:44 4: SipTest, call -> SipTest|**622|5|-123|0|&10,5,4
2017.12.03 20:00:49 3: SipTest, at_forcecall_622 max count 5 reached giving up !
was mir aber in deinem Log negativ auffällt ist das Thema der Änderungen zwischen bye und cancel :
2017.12.03 19:59:46 5: SipTest[2395], call->cancel
2017.12.03 19:59:46 4: SipTest, CALLDone -> SipTest|1|no answer
2017.12.03 20:00:02 5: SipTest[2403], call->bye
2017.12.03 20:00:02 4: SipTest, CALLDone -> SipTest|1|timeout
2017.12.03 20:00:18 5: SipTest[2411], call->cancel
2017.12.03 20:00:18 4: SipTest, CALLDone -> SipTest|1|no answer
2017.12.03 20:00:33 5: SipTest[2419], call->bye
2017.12.03 20:00:34 4: SipTest, CALLDone -> SipTest|1|timeout
2017.12.03 20:00:49 5: SipTest[2427], call->bye
2017.12.03 20:00:49 4: SipTest, CALLDone -> SipTest|1|timeout
D.h. bei meinen Tests hatte ich da immer cancel da der Ruf ja gar nicht angenommen wurde.
Kann es sein das du mit dem Intervall von 10 Sekunden einfach zu schnell warst ? Ich hatte immer mit 60 Sekunden getestet. Wenn da wirklich ein Problem sein sollte werde ich intern einfach keine Wartezeiten kleiner 60 Sekunden zulassen.
Also ein CALL **622 5 -123 &60,5,0 hat auch nichts geändert. Ich habe beim ersten Anruf angenommen, habe die 123 gehört, es wurde aufgelegt und nach 60 Sekunden ging's weiter. Wenn ich den Anruf wegdrücke ändert das auch nichts. call_success bleibt auf 0. Wie gesagt, bei all dem sind weder sip_force_interval noch sip_force_max gesetzt.
Setze ich hingegen sip_force_interval = 10 und sip_force_mx = 5 und wähte **622 5 -123 &, hebe beim ersten Anruf ab geht call_success auf 1 und die Rufreihe endet.
hmmm, jetzt bin ich platt :( und habe auch keine logische Erklärung. Aber anyway werde ich natürlich testen
Hallo Wzut,
das mit der Änderung ging aber absolut flott, sorry ich war seit gestern Abend offline, daher konnte ich erst jetzt testen.
Ich teste mit dem Original Debian "libnet-sip-perl 0.808-1" Modul, denn das neueste würde ich nur über "cpan" installieren wenn ich damit Probleme bekomme.
Das Attribut "attr sip_port" ist bei mir nicht gesetzt!
1. Versuch: "set TelefonClient call **52 30"
Telefon klingelt wie immer und spielt nach dem abheben DMTF Töne vor; call_attempt = 0; call_success = 1; call_state = ok
Meine alles sollte so passen.
2. Versuch: "set TelefonClient call **52 30 !Hallo &60,2"
Anruf wird im Abstand von einer Minute 2 x widerholt, der Ruf wird jedoch nicht angenommen; call_attempt = 2; call_success = 0; call_state = no answer
Nach dem 2. Ruf wird kein at mehr erzeugt. Genau so soll es sein.
3. Versuch: "set TelefonClient call **52 30 !Hallo &60,4"
Anruf wird beim dritten Anruf, nach dem 3. Klingeln angenommen; call_attempt = 2; call_success = 1; call_state = ok
Der Text wird vorgesprochen, nach dem 3. Ruf wird kein at mehr erzeugt. -> OK.
4. Versuch: "set TelefonClient call **52 30 !Hallo &30,10"
Anruf wird nicht angenommen; call_attempt = 10; call_success = 0; call_state = no answer
Nach dem 10. Ruf wird kein at mehr erzeugt. -> OK.
5. Versuch: "set TelefonClient call **52 30 !Hallo, ist da jemand zu Hause &120,5"
Anruf wird nach dem 3. Ruf und beim 3. Klingelzeichen angenommen; call_attempt = 2; call_success = 1; call_state = ok
Nach dem 3. Ruf wird kein at mehr erzeugt. -> OK.
6. Versuch: "set TelefonClient call **52 30 !Hallo, ist da jemand zu Hause &"
Der unter Attribute eingestellte Wert für "sip_force_interval" wird wieder verwendet.
Das "at" muss nach einem "set xx reset" von Hand gelöscht werden, oder der Anruf angenommen werden, damit die Telefone nicht ewig klingeln. Während eines ausgehenden Rufs, wird das "set xxx reset" auch nicht wirksam.
Auch der "sip_force_interval" wird absolut korrekt durch die Angabe nach dem "&" im Befehlsstring übernommen.
Ich wüsste nicht, welche Konstellation ich da noch testen sollte.
Ein Punkt ist mir noch aufgefallen, hab jedoch keine Ahnung wie es "früher" einmal war. Habe ich "&xx,10" Wiederholungen gewählt und führe "set xxxxx reset" aus, so gehen die Rufe noch weiter bis jemand den Ruf annimmt oder die Anzahl an Wiederholungen abgelaufen ist. Kannst du das angelegte "at_forcecall_52" bei "set "reset" irgendwie löschen?
Ergänzung!!!
sip_force_interval = 300 bei allen Versuchen
sip_force_max war nicht definiert
Alle Rufversuche bisher am ISDN Telefon angenommen (ja so etwas aus der Steinzeit gibt es noch! :))
Gruß Reinhard
Ach ja, die Technik. Um es noch etwas komplizierter zu machen: Ich habe gerade hausintern mein DECT-Telefon angerufen, abgenommen und die Welt ist in Ordnung: call_success = 1.
Die bisherigen Tests liefen hausintern mit meiner FritzFonApp!
Da gibt's also Unterschiede im Verhalten.
Der Testanruf aufs Handy verhält sich so wie die FritzFonApp.
Hallo,
@plin:
Irgendwie kurios, bei mir funktioniert es so wie es sein sollte.
Befehl "set TelefonClient call **620 30 !Hallo &60,4,0" Rufannahme nach den ersten klingeln beim ersten Anruf, Text wird vorgelesen und kein weiterer Ruf kommt mehr an.
Habe eben meine Attribute "sip_force_interval" und "sip_force_max" gelöscht (ohne restart SIP) das Verhalten ändert sich bei mir aber nicht.
Egal ob FritzAppPhone oder ISDN Apparat intern (FritzBox 7390).
Was mir noch aufgefallen ist, sporadisch bei Anrufannahme mit dem Handy (FritzAppFone) höre ich die Ansage nicht oder abgebrochen, ich denke aber dies ist kein Problem von SIP sondern ein Verbindungsproblem mit WLAN, am ISDN Anschluss klappt es dagegen immer bestens.
Hab ich da irgenwas verpasst, was genau bedeutet die 3. Dimension nach dem Komma"&60,4,0"?
Gruß Reinhard
ZitatKannst du das angelegte "at_forcecall_52" bei "set "reset" irgendwie löschen?
was genau bedeutet die 3. Dimension nach dem Komma"&60,4,0
Jein, denn das Modul hat ja keine Ahnung das es dieses Temp at überhaupt gibt und kennt daher auch dessen Namen nicht.
Aprpo Namen : Bisher war at_forcecall_ fix danach kam die reduzierte Zielrufnummer. Das hat den Nachteil das es pro Ziel nur ein Force geben darf, da sich die ats sonst gegenseitig überschreiben. Ich habe inzwischen bei mir da noch den Zusatz _xxxx anghängt, wobei xxxx eine CRC Prüfsumme aus DTMF oder .alaw Datei ist.
Die dritte Zahl ist nicht für den User sondern für das at, d.h es reicht &60,4 anzugeben. Schau dir mal ein temp at an dort gibt die letzte Zahl die bereits gelaufenen Versuche an.
Dank erst mal euch beiden fürs testen. Das mit der Fritz App und dem Handy war ein guter Hinweis. Ich denke da brauch gar nicht groß im Modul suchen sondern kann gleich wieder tcpdump und Wireshark anwerfen. U.u. muss mir dann später Muschelpuster noch bei der Auswertung helfen. Ich sehe schon 0.812 wird nicht die letzte Net::SIP Version bleiben.
Hallo,
mir ist da noch etwas augefallen, was ich mir nicht erklären kann.
Der Fehler könnte natürlich auch bei mir liegen, da ich mit Perl nicht so bewandert bin.
Weshalb wird bei Eingabe von "set TelefonClient call **52 30 !Kältewarnung Fenster oder Terassentüre in der Küche bitte schließen der Raum kühlt aus. *2 &60,5" auf der Fhem Eingabezeile das Attribut "sip_force_max" überschrieben?
Ist absolut korrekt so, das will ich ja mit Anhang von ",5" auch erreichen.
Verwende ich den Aufruf dagegen in einem Doif, wird strikt "sip_force_max" beachtet und die Rufe enden nach der Anzahl, welche unter "sip_force_max" eingetragen sind. Die Angabe "...&60,5" bleibt ohne Wirkung.
DEF ([du_temp] == 1 and [Aussentemperatur] < 10)(set TelefonClient call **52 30 !Kältewarnung Fenster oder Terassentüre in der Küche bitte schließen der Raum kühlt aus. *2 &60,5)
Im Doif kommt als Reading:
error 5: Unknown command 5, try help.
Anscheinend macht das Komma im Doif Probleme, oder muss da noch etwas maskiert oder geklammert werden?
Ist dieses Verhalten für euch irgendwie erklärbar?
Die Lösung habe ich selbst gefunden, der set Befehl muss doppelt mit Klammern eingeschlossen werden.
([du_temp] == 1 and [Aussentemperatur] < 10)((set TelefonClient call **52 30 !Kältewarnung Fenster oder Terassentüre in der Küche bitte schließen der Raum kühlt aus. *2 &30,3))
Noch etwas ist mir aufgefallen:
Wird im Befehlsstring "set TelefonClient call **52 30 !Hallo *2 &300,5" ein Wiederholungsfaktor "*nn"zusätzlich mit verwendet
wird der "call_state" nicht mehr mit "ok" sondern mit "peer_hangup" gemeldet und die Anrufe kommen per "at" nun 5 mal zwingend an, wenn bei laufender Ansage aufgelegt wird.
Gruß Reinhard
Zitat von: Wzut am 04 Dezember 2017, 19:30:12
Ich sehe schon 0.812 wird nicht die letzte Net::SIP Version bleiben.
Sehe ich nicht unbedingt so. Bei meinen Tests hat sich unser Modul bei gesetzten Attributen sip_force_intervall und sip_force_max so verhalten wie ich es erwartet habe. Nur die Variante
CALL **622 5 -123 &60,5,0 läuft aus dem Ruder.
Also mal zurück zu den Basics: Der unbeantwortete Call wird jetzt sauber nach der eingestellten Zeit abgebrochen. Jetzt ist also auch meine Fritte mit dem Protokoll soweit zufrieden.
Damit sollte das Problem wohl auch bei allen anderen Betroffenen gelöst sein.
minimalistische Grüße
Niels
Zitat von: Wzut am 04 Dezember 2017, 19:30:12Ich denke da brauch gar nicht groß im Modul suchen sondern kann gleich wieder tcpdump und Wireshark anwerfen. U.u. muss mir dann später Muschelpuster noch bei der Auswertung helfen.
Sag Bescheid - ich helfe im Rahmen meiner bescheidenen Möglichkeiten gerne weiter.
offene Grüße
Niels
Es wird immer undurchsichtiger. Ich habe jetzt einen ganzen Satz von Testcalls gegen meine FritzFonApp abgesetzt:
Durchlauf 1
sip_force_max nicht gesetzt
sip_force_interval nicht gesetzt
**622 10 &15,3,0
1. Anruf angenommen
=> kein call_success = 1
Durchlauf 2
sip_force_max = 5
sip_force_interval nicht gesetzt
**622 10 &15,3,0
1. Anruf angenommen
=> kein call_success = 1
nach 3 Versuchen ist Schluss
Durchlauf 3
sip_force_max = 5
sip_force_interval = 60
**622 10 &15,3,0
1. Anruf angenommen
=> kein call_success = 1
nach 3 Versuchen a 15 Sekunden ist Schluss
Durchlauf 4
sip_force_max = 5
sip_force_interval = 60
**622 10 &15,3
1. Anruf angenommen
=> kein call_success = 1
nach 3 Versuchen a 15 Sekunden ist Schluss
Durchlauf 5
sip_force_max = 5
sip_force_interval = 60
**622 10 &15
1. Anruf angenommen
=> kein call_success = 1
nach 5 Versuchen a 15 Sekunden ist Schluss
Durchlauf 6
sip_force_max = 5
sip_force_interval = 15
**622 10 /opt/fhem/IhrCodeBitte.alaw &
1. Anruf angenommen
=> call_success = 1
nach 1 Versuch ist Schluss
Durchlauf 7
sip_force_max = 5
sip_force_interval = 15
**622 10 /opt/fhem/IhrCodeBitte.alaw &10,5,0
1. Anruf angenommen
=> call_success = 1
nach 1 Versuch ist Schluss
Durchlauf 8
sip_force_max = 5
sip_force_interval = 15
**622 10 /opt/fhem/IhrCodeBitte.alaw &10,5,0
3. Anruf angenommen
=> call_success = 1
nach 3 Versuchen ist Schluss
Durchlauf 8
sip_force_max = 5
sip_force_interval = 15
**622 10 -123 &10,5,0
1. Anruf angenommen
=> call_success = 1
nach 1 Versuch ist Schluss
Durchlauf 9
sip_force_max nicht gesetzt
sip_force_interval = 15
**622 10 -123 &10,5,0
1. Anruf angenommen
=> call_success = 1
nach 1 Versuch ist Schluss
Durchlauf 10
sip_force_max nicht gesetzt
sip_force_interval nicht gesetzt
**622 10 -123 &10,5,0
1. Anruf angenommen
=> call_success = 1
nach 1 Versuch ist Schluss
Gestern hatte CALL **622 10 -123 &10,5,0 nicht funktioniert, heute schon. Selbst CALL **622 5 -123 &60,5,0 funktioniert.
mmmh, gestern hat's bei uns geschneit ...
Also de Hauptgrund für die V1.7 war ja das Thema Weiterklingeln trotz Timeout - wenn ich Niels Feedback richtig lese sollte das in Verbindung mit 0.812 erschlagen sein ?
Dann haten wir das Problem der belegten Ports mit HM RPC Server, auch da hat Reinhard nichts mehr zu geschrieben, also erledigt wenn sip_port nicht gesetzt ist ?
MadMax-FHEM hatte mit stactrace Gemecker wegen nicht vorhandenem CALL_START, Feedback steht noch aus.
und last but not least eine Erweiterung von Force, nur hier scheint es komische Effekte zu geben die aber teilsweise nicht reproduzierbar sind.
Wenn die beiden fehlenden Attribute sip_force da wirklich einen Einflus haben sollten setze ich sie halt ersteinmal im Modul mit Gewalt, denn es stört nicht wenn sie vorhanden sind aber nicht genutzt werden.
@Reinhard, mit dem DOIF bin ich überfragt da ich es nicht nutze. Mit Sicherheit gibt es da eine Möglichkeit das Komma zu maskieren, bitte mal die Gurus im DOIF Forum fragen. Da die Parameter * und & optional sind kann sie zwar der User weglassen, aber vom Modul werden sie immer erzeugt. Sieht man im verbose 4 Log bei den Call Zeilen wo das typische |0|0 anhängt.
Zitat von: Wzut am 05 Dezember 2017, 07:46:32
Also der Hauptgrund für die V1.7 war ja das Thema Weiterklingeln trotz Timeout - wenn ich Niels Feedback richtig lese sollte das in Verbindung mit 0.812 erschlagen sein ?
Jein - das Net::SIP 0.812 behebt einen unsauberen Verbindungsaufbau bei Digest Authentication. Damit war das Problem 'Weiterklingeln' ja nicht erschlagen - der Verbindungsaufbau sah nur sauberer aus. Ich denke, selbst mit SIP:Net 0.808 wird das Weiterklingeln vermutlich mit Modul 96_SIP V1.7 erschlagen sein. Aber es schadet natürlich nicht, beide Komponenten aktuell zu haben ;)
aktuelle Grüße
Niels
Zitat von: Muschelpuster am 04 Dezember 2017, 21:47:30
Also mal zurück zu den Basics: Der unbeantwortete Call wird jetzt sauber nach der eingestellten Zeit abgebrochen. Jetzt ist also auch meine Fritte mit dem Protokoll soweit zufrieden.
Damit sollte das Problem wohl auch bei allen anderen Betroffenen gelöst sein.
Guten Morgen,
leider ist bei mir das Problem nicht gelöst, vielmehr kommt bei mir gar kein Anruf mehr an. So bin ich vorgegangen: ich habe das SIP-modul von Wzut (Antwort #465) installiert und Net::SIP auf 0.812 aktualisiert. Habe ich da etwas vergessen oder falsch gemacht?
Ausschnitt aus der Logdatei:
2017.12.05 10:24:01 5: Cmd: >set FS20_50e000 on<
2017.12.05 10:24:01 3: FS20 set FS20_50e000 on
2017.12.05 10:24:01 5: CUL_0 sending F50e00011
2017.12.05 10:24:01 5: SW: F50e00011
2017.12.05 10:24:01 5: Starting notify loop for FS20_50e000, 1 event(s), first is on
2017.12.05 10:24:01 5: createNotifyHash
2017.12.05 10:24:01 5: Triggering Klingel
2017.12.05 10:24:01 4: Klingel exec set FB_Klingel call **613
2017.12.05 10:24:01 5: Cmd: >set FB_Klingel call **613<
2017.12.05 10:24:01 4: FB_Klingel, calling **613, ringtime: 30 , no message
2017.12.05 10:24:01 4: FB_Klingel, FB_Klingel|**613|30||0
2017.12.05 10:24:01 5: Loading ./FHEM/98_telnet.pm
2017.12.05 10:24:02 3: telnetForBlockingFn_1512465841: port 46159 opened
2017.12.05 10:24:02 5: Starting notify loop for global, 1 event(s), first is DEFINED telnetForBlockingFn_1512465841
2017.12.05 10:24:02 5: createNotifyHash
2017.12.05 10:24:02 5: End notify loop for global
2017.12.05 10:24:02 4: BlockingCall (SIP_CALLStart): created child (19815), uses telnetForBlockingFn_1512465841 to connect back
2017.12.05 10:24:02 4: FB_Klingel, call -> FB_Klingel|**613|30||0|0
2017.12.05 10:24:02 5: FB_Klingel, call has pid 19815
2017.12.05 10:24:02 5: Starting notify loop for FB_Klingel, 2 event(s), first is call_state: invite
2017.12.05 10:24:02 4: FB_Klingel[19815], my parent is 19814
2017.12.05 10:24:02 4: FB_Klingel[19815], using Leg.pm to find a free port
2017.12.05 10:24:02 5: End notify loop for FB_Klingel
2017.12.05 10:24:02 5: End notify loop for FS20_50e000
2017.12.05 10:24:02 4: WEB: /fhem?cmd.FS20_50e000=set%20FS20_50e000%20on&room=all&XHR=1&fwcsrf=csrf_141532236973390&fw_id=54 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.12.05 10:24:02 4: WEB_192.168.180.22_49949 GET /fhem/images/default/FS20.on.png; BUFLEN:0
2017.12.05 10:24:02 4: WEB_192.168.180.22_49949 => 304 Not Modified
2017.12.05 10:24:03 4: Connection accepted from telnetForBlockingFn_1512465841_127.0.0.1_51104
2017.12.05 10:24:03 5: Cmd: >{BlockingStart('1')}<
2017.12.05 10:24:03 5: Cmd: >{SIP_CALLDone('FB_Klingel|0|CallRegister: Failed with code 404')}<
2017.12.05 10:24:03 4: FB_Klingel, CALLDone -> FB_Klingel|0|CallRegister: Failed with code 404
2017.12.05 10:24:03 5: Starting notify loop for FB_Klingel, 7 event(s), first is call: done
2017.12.05 10:24:03 5: End notify loop for FB_Klingel
2017.12.05 10:24:03 5: FB_Klingel, fifo is empty
2017.12.05 10:24:03 5: FB_Klingel, no elbc
2017.12.05 10:24:09 4: WEB_192.168.180.22_49949 POST /fhem?cmd.FS20_50e000=set%20FS20_50e000%20off&room=all&XHR=1&fwcsrf=csrf_141532236973390&fw_id=54; BUFLEN:0
2017.12.05 10:24:09 5: Cmd: >set FS20_50e000 off<
2017.12.05 10:24:09 3: FS20 set FS20_50e000 off
2017.12.05 10:24:09 5: CUL_0 sending F50e00000
2017.12.05 10:24:09 5: SW: F50e00000
2017.12.05 10:24:09 5: Starting notify loop for FS20_50e000, 1 event(s), first is off
2017.12.05 10:24:09 5: End notify loop for FS20_50e000
Ausschnitt aus der fhem.cfg:
define FB_Klingel SIP
attr FB_Klingel sip_dtmf_loop once
attr FB_Klingel sip_dtmf_send audio
attr FB_Klingel sip_dtmf_size 2
attr FB_Klingel sip_elbc yes
attr FB_Klingel sip_from sip:622@fritz.box
attr FB_Klingel sip_ip 192.168.180.21
attr FB_Klingel sip_listen none
attr FB_Klingel sip_registrar fritz.box
attr FB_Klingel sip_ringtime 4
attr FB_Klingel sip_user 622
define Klingel notify FS20_50e000:on set FB_Klingel call **613
Was ist zu tun?
Herzliche Grüße
Heiner
@Heiner, leider ist dein Logabschnitt nicht sehr übersichtlich, du hast vermutlich verbose 5 in global gesetzt und nicht im SIP Modul. Dadurch steht viel Zeug im Log was aber hier nicht von Interesse , daher bitte global verbose 3 und Modul verbose auf 5. Allerdings sehe ich in deinem Log Abschnitt den Fehler 404 und das hatten wir hier schon oft. In der FB hat sich im Laufe der Zeit einiges getan zum Thema Userkennung und Passwort. Bei der Userkennung sehe ich noch die einfache 622. Daher bitte in der FB nachschauen zum Thema Username und auch darauf achten das das Passwort min 8 Zeichen hat und von der FB als stark eingestuft wird.
Zitat von: Wzut am 05 Dezember 2017, 11:39:01
@Heiner, leider ist dein Logabschnitt nicht sehr übersichtlich, du hast vermutlich verbose 5 in global gesetzt und nicht im SIP Modul. Dadurch steht viel Zeug im Log was aber hier nicht von Interesse , daher bitte global verbose 3 und Modul verbose auf 5. Allerdings sehe ich in deinem Log Abschnitt den Fehler 404 und das hatten wir hier schon oft. In der FB hat sich im Laufe der Zeit einiges getan zum Thema Userkennung und Passwort. Bei der Userkennung sehe ich noch die einfache 622. Daher bitte in der FB nachschauen zum Thema Username und auch darauf achten das das Passwort min 8 Zeichen hat und von der FB als stark eingestuft wird.
Sorry, lieber Wzut,
ich hatte versehentlich den Inhalt einer alten externen Backup-Datei in die fhem.cfg kopiert. Jetzt läuft alles wie erwartet. Herzlichen Sank für deine schnelle und kompetente Hilfe.
Gruß Heiner
D.h. du bist auch so ein User wie Muschelpuster bei dem die Fritte ewig weitergeklingelt hat ?
und nun hört sie nach max. Time damit auf ?
Zitat von: Wzut am 05 Dezember 2017, 16:57:05
D.h. du bist auch so ein User wie Muschelpuster bei dem die Fritte ewig weitergeklingelt hat ?
und nun hört sie nach max. Time damit auf ?
Ja, das bin ich. Die FB hört jetzt bei max.Time 4 nach 2x Klingeln auf (Fritz!Fon C5, M2, FritzFon app auf iphone). Alles bestens!
Gruß Heiner
Hallo,
bei mir läuft jetzt das sip-Modul und es kann anrufen. Aber ich habe noch ein Problem mit TEXT2SPEECH, bzw. der Anbindung an das sip-Modul.
Fragen:
1. mit define ttx TEXT2SPEECH default
werden dann von tts nur mp3-Dateien erzeugt? Und wo liegen die dann?
Leider steht dazu im wiki vom TTS rein gar nichts.
2. Wie muss ich die Attribute beim sip-Modul setzen, damit tts angebunden wird?
Vielleicht kann mir ja jemand seine funktionierende Konfig dazu hier posten. Die Suche dazu spuckt leider nichts aus.
Danke.
Elektrolurch
Gleiches Problem bei mir.
Bei tts kommen nur Pieptöne. Welche samplingrate muss eingestellt werden für u-law Codec?
https://wiki.fhem.de/wiki/SIP-Client
ZitatFalls Ihr Text2Speech verwenden wollt
Vorbereitung
SoX installieren
sudo apt-get install sox
mp3 Unterstützung für SoX installieren
sudo apt-get install libsox-fmt-mp3
Text2Speech als Server Device anlegen
define <name z.B myT2S> text2speech none
beim SIP Device dieses Server Device im Attribut T2S_Device eintragen
@Elektrolurch , beachte das none statt deinem default :)
@Decki :
ZitatAnmerkung zum Audioformat
Audiofiles müssen im alaw- oder ulaw-Format vorliegen und können mit folgendem Command erzeugt werden
sox <file>.wav -t raw -r 8000 -c 1 -e a-law <file>.alaw
Hallo Elektrolurch,
anbei meine funktionierende Konfiguration zu SIP und Text2Speech.
Die Module, welche "Wzut" beschrieben hat müssen unbedingt alle geladen werden, einfach genau nach WIKI vorgehen, ist eigentlich sehr gut beschrieben.
Die erzeugten MP3-Dateien befinden sich in dem Verzeichnis, welches du unter "TTS_CacheFileDir" eingestellt hast. Ich habe mir das Verzeichnis am Raspi erst angelegt, die gleichen Rechte wie Fhem gegeben und dann Text2Speech bekannt gemacht. Es gibt auch ein Standardverzeichnis der MP3-Dateien, Ich habe es nicht sofort gefunden, deshalb der "Umweg" über das eigene Verzeichnis.
Anbei die Konfiguration von mir:
SIP-Device:
defmod TelefonClient SIP
attr TelefonClient DbLogExclude .*
attr TelefonClient T2S_Device Text2Speech
attr TelefonClient audio_converter sox
attr TelefonClient room Kommunikation
attr TelefonClient sip_call_audio_delay 1.75
attr TelefonClient sip_dtmf_loop once
attr TelefonClient sip_dtmf_send audio
attr TelefonClient sip_dtmf_size 2
attr TelefonClient sip_elbc yes
attr TelefonClient sip_force_interval 300
attr TelefonClient sip_force_max 5
attr TelefonClient sip_from sip:Anschluss621@192.168.1.13
attr TelefonClient sip_ip 192.168.1.33
attr TelefonClient sip_listen none
attr TelefonClient sip_registrar 192.168.1.13
attr TelefonClient sip_ringtime 3
attr TelefonClient sip_user Anschluss621
attr TelefonClient verbose 5
Text2Speech:
defmod Text2Speech Text2Speech none
attr Text2Speech DbLogExclude .*
attr Text2Speech TTS_CacheFileDir /opt/fhem/temp
attr Text2Speech TTS_Language Deutsch
attr Text2Speech group Multimedia
attr Text2Speech room Kommunikation
Gruß Reinhard
Hallo,
noch etwas ist mir aufgefallen:
Wird der Befehlsstring set TelefonClient call **52 30 !Hallo dies ist ein Test ich spreche dir hier etwas vor nur um Zeit zu gewinnen *3 &300,5
in die Fhem Kommandozeile eingegeben, und der Ruf beim ersten Anruf angenommen und bei laufender Ansage aufgelegt.
So wird "call_state = peer_hangup" und die Anrufe werden zwingend 5 mal wiederholt.
Das Fehlverhalten tritt nur auf, wenn der Angerufene als erster, vor Ansageende auflegt. Höre ich den Text auch beim ersten Anruf bis zum Ende an, so wird "call_success = 1" und "call_state = ok"
Ist das bei euch auch so?
Oder es hängt bei mir mit dem "alten" debian SIP Modul zusammen.
Bei den Tests am Montag, ist es mir nicht aufgefallen, da der Ansagetext so kurz war, dass immer SIP vor mir aufgelegt hatte.
@plin
Ist dieses sehr kuriose und unerklärliche Verhalten etwa bei dir damit zu erklären, wer bei kurzen Ansagetexten als erster auflegt?
Die Konfiguration meines SIP-Device ist in https://forum.fhem.de/index.php/topic,67443.msg726974.html#msg726974 (https://forum.fhem.de/index.php/topic,67443.msg726974.html#msg726974) zu sehen.
Noch ein Kuriosum:
der Ansagetext:
set TelefonClient call **52 30 !Hallo hier spricht deine Waschmaschine mit dir und will dir etwas sagen was dir wahrscheinlich nicht gefallen wird *3 &300,5
Wird nach Waschmaschine und noch vor dem und im Text beendet, aber "*nn" mal wiederholt.
der Ansagetext:
set TelefonClient call **52 30 !Hallo hier spricht deine Waschmaschine mit dir ich will dir etwas sagen was dir wahrscheinlich nicht gefallen wird *3 &300,5
Der Text wird korrekt vorgelesen, und auch "*nn" mal wiederholt.
Schön lagsam glaube ich wieder an den Weihnachtsmann :)
Gruß Reinhard
Zitat von: Rewe2000 am 06 Dezember 2017, 19:54:43
Ist das bei euch auch so?
Oder es hängt bei mir mit dem "alten" debian SIP Modul zusammen.
tja, so ist es halt beim Force. Man muss sich die ganze Geschichte anhören. Die Nachricht MUSS ankommen.
Zitat von: Rewe2000 am 06 Dezember 2017, 19:54:43
@plin
Ist dieses sehr kuriose und unerklärliche Verhalten etwa bei dir damit zu erklären, wer bei kurzen Ansagetexten als erster auflegt?
Ich denke nicht. Ich muss die verschiedenen möglichen Szenarien noch mal komplett durchspielen. Da kommt einiges zusammen:
- sip_dtmf_send als audio/rfc2833
- DTMF, Audiofile oder Textnachricht
- sip_force-Attribute verwenden oder die &aa,bb,cc-Syntax
und das das auch noch in verschiedenen Kombinationen.
Zitat von: Rewe2000 am 06 Dezember 2017, 19:54:43
Das Fehlverhalten tritt nur auf
Works as designed , siehe Wiki :
ZitatWICHTIG: wählt die maxtime groß genug damit das Audiofile auch wirklich komplett abgespielt werden kann, bzw. hört's euch auch bis zum Ende an! Wenn ein priorisierter Anruf vorzeitig endet (quasi NOK) wird er nach 1 Minute wiederholt, und zwar so lange bis er erfolgreich war
Einzig über die 1 Minute kann man jetzt diskutieren da es inzwischen eine Variable ist.
In dem Zusammenhang würde ich auch den Satz etwas darüber beachten mit der neagtiven Wiederholzahl :
ZitatWird als Wiederholungsfaktor ein negativer Wert angegeben (z.B. *-2), passiert folgendes: Die Nachricht wird zwar genau wie bei *2 dreimal abgespielt, allerdings erlaubt das - vor der 2 das die Nachricht nur einmal vollständig übertragen werden muß.
zum Thema des Abbruchs bei Text2Speech :
Ich bin kein T2S Guru, meine aber irgendwo gelesen zu haben das es die Möglichkeit gibt das T2S entweder mehere kleine mp3 Datein erzeugt oder eine große.
Ich vermute bei dem Abbruch handelt es sich um den ersten Fall und die anderen Datein fallen schlichtweg unter den Tisch. Bitte hier mal direkt mit T2S alleine testen bzw ggf. Logs mit höherem verbose Level beim T2S Device beobachten. Bzw. im Sip Log steht ja immer der Filename der mp3 Datei, diese mal runerladen und sich in einem entsprechenden Player extra anhöhren, ist sie da vollständig ?
Edit , aus der T2S command.ref :
ZitatTTS_Delemiter
optional: By using the google engine, its not possible to convert more than 100 characters in a single audio brick. With a delemiter the audio brick will be split at this character. A delemiter must be a single character.!
By default, ech audio brick will be split at sentence end. Is a single sentence longer than 100 characters, the sentence will be split additionally at comma, semicolon and the word and.
Notice: Only available in locally instances with Google engine!
und
ZitatTTS_UseMP3Wrap
Optional: Für eine flüssige Sprachausgabe ist es zu empfehlen, die einzelnen vorher per Google geladenen Sprachbausteine zu einem einzelnen Sprachbaustein zusammenfassen zu lassen bevor dieses per Mplayer ausgegeben werden. Dazu muss Mp3Wrap installiert werden.
apt-get install mp3wrap
Achtung: Nur bei einem lokal definierter Text2Speech Instanz möglich!
Hier mal mein T2S Log zu dem Thema :
2017.12.07 07:41:27 4: myT2S: Auflistung der Textbausteine nach Aufbereitung:
2017.12.07 07:41:27 4: myT2S: 0 => Hallo hier spricht deine Waschmaschine mit dir
2017.12.07 07:41:27 4: myT2S: 1 => und will dir etwas sagen was dir wahrscheinlich nicht gefallen wird,;
2017.12.07 07:41:27 4: Verwende TTS Spracheinstellung: Deutsch
2017.12.07 07:41:27 4: Text2Speech: Textbaustein ist keine direkte MP3 Datei, ermittle MD5 CacheNamen: f622fd00af305c1d0179bde7f06ad90b.mp3
2017.12.07 07:41:27 4: Text2Speech: Verwende Google OnlineResource zum Download
2017.12.07 07:41:27 4: Text2Speech: Hole URL: http://translate.google.com/translate_tts?tl=de&client=tw-ob&q=Hallo%20hier%20spricht%20deine%20Waschmaschine%20mit%20dir
2017.12.07 07:41:27 4: Text2Speech: Schreibe mp3 in die Datei cache/f622fd00af305c1d0179bde7f06ad90b.mp3 mit 14496 Bytes
2017.12.07 07:41:27 4: Text2Speech: Bearbeite jetzt den Text: Hallo hier spricht deine Waschmaschine mit dir
2017.12.07 07:41:27 4: Text2Speech: cache/f622fd00af305c1d0179bde7f06ad90b.mp3 gefunden, kein Download
2017.12.07 07:41:27 4: Verwende TTS Spracheinstellung: Deutsch
2017.12.07 07:41:27 4: Text2Speech: Textbaustein ist keine direkte MP3 Datei, ermittle MD5 CacheNamen: 09c65b7ea15d06edb704eac2127b20ff.mp3
2017.12.07 07:41:27 4: Text2Speech: Verwende Google OnlineResource zum Download
2017.12.07 07:41:27 4: Text2Speech: Hole URL: http://translate.google.com/translate_tts?tl=de&client=tw-ob&q=und%20will%20dir%20etwas%20sagen%20was%20dir%20wahrscheinlich%20nicht%20gefallen%20wird%2C%3B
2017.12.07 07:41:27 4: Text2Speech: Schreibe mp3 in die Datei cache/09c65b7ea15d06edb704eac2127b20ff.mp3 mit 17856 Bytes
2017.12.07 07:41:27 4: Text2Speech: Bearbeite jetzt den Text: und will dir etwas sagen was dir wahrscheinlich nicht gefallen wird,;
2017.12.07 07:41:27 4: Text2Speech: cache/09c65b7ea15d06edb704eac2127b20ff.mp3 gefunden, kein Download
Hallo Reinhard und Liste,
danke für die Info.
etwas stimmt noch nicht:
Der Befehl
set sip call **611 30 !Hallo dies ist ein Test ich spreche dir hier etwas vor nur um Zeit
liefert
external sox or ffmpeg programm not found, please install sox or ffmpeg first and set attr audio_converter
obwohl ich
sudo apt-get install sox
mp3 Unterstützung für SoX installieren
sudo apt-get install libsox-fmt-mp3
installiert habe.
gesetzt ist bei sip:
T2S_Device tts
audio_converter sox
sip_call_audio_delay 1.75
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_force_interval 300
sip_from sip:fhemfhem@fritz.box
sip_ip Speicherknecht
sip_listen none
sip_registrar fritz.box
sip_ringtime 3
sip_user fhemfhem
tts:
TTS_CacheFileDir /hdd/sda4/Sonos/speak
TTS_Language Deutsch
TTS_UseMP3Wrap 1
Internals:
ALSADEVICE
DEF none
MODE SERVER
NAME tts
NR 949
STATE Initialized
TYPE Text2Speech
Das Verzeichnis: /hdd/sda4/Sonos/speak kann (wird schon für Sonos) von fhem geschrieben werden.
Was könnte da noch fehlen?
Elektrolurch
Zitat von: Elektrolurch am 07 Dezember 2017, 11:06:42
external sox or ffmpeg programm not found, please install sox or ffmpeg first and set attr audio_converter
da must du ansetzen , das SIP Modul findet sox nicht. Ich lese bei dir zwischen den Zeilen das du offensichtlich keinen Raspi benutzt, daher könnte sox in einem anderen Verzeichnis liegen als erwartet.
Was gibt denn dein System auf der Konsole bei
which sox
aus ?
Einen Cubie mit jessie. Ich habe jetzt mal einen reboot gemacht - und sie da: Jetzt geht es. Habe ich eigentlich von debian nicht erwartet....
Danke.
Elektrolurch
an der Stelle noch einen Tipp für alle T2S User der nicht im Wiki steht :
wenn ihr eh immer den gleichen Text benutzt ( z.B. via notify) dann werft mal einen Blick ins T2S cache dir ( normal im FHEM Dir /cache) Dort findet ihr zum einen die mp3 Datei von Google als auch die von sox konvertierte .alaw Version.
Kopiert euch die .alaw unter einem griffigen Namen z.B. in einen anderen Ordner (/opt/fhem/sounds/Fenster.alaw)
und verwendet dann beim Call Aufruf statt der !Blabla direkt Pfad/Datei. So spart man sich den ganzen T2S Umweg.
Der Tipp geht auch gut in Verbindung mit dem Thema von heute Morgen und den langen Texten. Einfach von T2S und Mp3Warp die vollständige mp3 Datei erstellen lassen, diese mittels sox in .alaw von Hand wandeln und abspeichern.
sox <mp3 File> -t raw -r 8000 -c 1 -e a-law <alaw File>
Zitat von: plin am 03 Dezember 2017, 19:11:17
Das erste schnelle Feedback (vor dem Abendessen):
- sip_port gelöscht
- sip_force_interval und sip_force_max gesetzt, CALL mit & abgesetzt, klingeln lassen -> ok, Intervall und Anzahl passen
- sip_force_interval und sip_force_max gelöscht, CALL mit &10,5,0 abgesetzt, klingeln lassen -> ok, Intervall und Anzahl passen
- sip_force_interval und sip_force_max gelöscht, CALL mit &10,5,0 abgesetzt, beim ersten Klingeln abgehoben -> nok
Bei der Rufannahme wurde mir krächzend die DTMF-Folge vorgespielt. Sah also gut aus. Aber call_success stand immer noch auf 0. Und nach dem Intervall gings weiter. Noch ein Anruf. Nimmt man ihn an, wird kein DTMF mehr vorgespielt. Der Anruf dauert bis man ihn aktiv beendet. Das beendet aber nicht den Telefonterror, nach dem nächsten Intervall kommt der nächste Anruf.
Habe heute Abend einen Retest durchgeführt: alle drei Fälle wurden diesmal korrekt behandelt. Bis auf Weiteres ziehe ich also meine "Probleme" zurück.
Call it electorinic data processing mysteries ...
@wzut: aus meiner Sicht kann die 1.70er Version eingecheckt werden
Hallo plin, hallo Wzut,
wer lesen kann ist klar im Vorteil!
Viele Module in Fhem sind mittlerweile schon so komplex, dass ein "normaler User" (wie ich), Mühe hat die Erklärungstexte zu verstehen und zu begreifen. Da müssen schon einige Schwierigkeiten im laufenden Betrieb entstehen, damit ein User sich so intensiv mit der Doku beschäftigt. Und das SIP-Device ist in der WIKI wirklich sehr gut beschrieben.
Jetz hab ich auch endlich das mit der "maxtime" begriffen.
Den Abschnitt im WIKI habe ich gelesen, mich hat aber das Wort
Anruf in die Irre geleitet.
Kann es sein, dass sich hier in der Beschreibung ein Fehler eingeschlichen hat?
ZitatWir ein Wiederholunsfaktor in der Form *nn angegeben, wird der Anruf einmal ausgeführt die Nachricht einmal abgespielt und dann nn mal wiederholt.
Wird als Wiederholungsfaktor ein negativer Wert angegeben (z.B. *-2), passiert folgendes: Die Nachricht wird zwar genau wie bei *2 dreimal abgespielt, allerdings erlaubt das - vor der 2 das die Nachricht nur einmal vollständig übertragen werden muß. Der call_state nach dem Call hätte dann z.B. den Wert "ok peer hangup".
Eine Frage drängt sich mir aber dennoch auf.
Ist es technisch nicht möglich den Anruf (mit Ansagetext) bereits nach der Gesprächsannahme durch den Angerufenen als "zugestellt/angenommen" zu behandeln, auch wenn die Ansage nicht bis zum Ende angehört wird, oder gibt es dafür von euch andere Gründe, an welche ich bisher nicht gedacht habe?
Wegen der Probleme bei der Textausgabe mit Text2Speach kann ich damit leben, denn das Verhalten tritt nur bei genau dieser Wortwahl im Satz auf:
set TelefonClient call **52 30 !Hallo hier spricht deine Waschmaschine mit dir und will dir etwas sagen was dir wahrscheinlich nicht gefallen wird *3 &300,5
Ändere ich dagegen das "
und" gegen "
and" wird der Satz in einem Teil übersetzt und korrekt vorgelesen. Kommt mir fast so wie ein unerkannter Bug in der Textwandlung zu MP3 vor. Verwende ich in dieser Buchstabenanreihung "
und" wird der Satz immer geteilt in MP3 gewandelt, dabei aber immer nur der erste Teil vorgelesen. Mit der von Wzut beschriebenen Vorgehensweise (mp3wrap) würde ich auch dieses Verhalten in den Griff bekommen, aber da stelle ich lieber einen Buchstaben um [OT] (Instandhalter sind faul) [/OT] ;).
Das ist aber definitiv kein SIP Fehler!@plin bei dir scheint sich ja auch über Nacht alles zum positiven gewandelt zu haben (draussen wird es wieder kälter ;D )
Gruß Reinhard
Zitat von: Rewe2000 am 07 Dezember 2017, 20:49:53
Ist es technisch nicht möglich den Anruf (mit Ansagetext) bereits nach der Gesprächsannahme durch den Angerufenen als "zugestellt/angenommen" zu behandeln, auch wenn die Ansage nicht bis zum Ende angehört wird, oder gibt es dafür von euch andere Gründe, an welche ich bisher nicht gedacht habe?
Quittieren im Sinne von "ich drücke dann mal die Sterntaste" geht (nach meinem Kenntnisstand) im Net::SIP nicht.
@wzut: Können wir entgegen genommene Anrufe erkennen, auch wenn die Nachricht nicht komplett abgespielt wurde? Dann könnte man zum *-2 noch ein *+2 erfinden??? Oder ein neues Attribut?
Zitat von: plin am 07 Dezember 2017, 21:54:17
Können wir entgegen genommene Anrufe erkennen, auch wenn die Nachricht nicht komplett abgespielt wurde?
Ja, denn ich setze wenn - (Minus) verwendet wurde eine Hilfsvariable nachdem das erste echte Audiofile erfolgreich übertragen wurde.
Bricht der User danach ab übergehe ich einfach die Fehlermeldungen von Net::SIP weil die andern Dateien ( für Net::SIP sind die Wiederholungen einfach auch nur Files) nicht erfolgreich übertragen wurden. Es gibt heute schon einen internen Merker der gesetzt wird sobald das Ereignis "abgenommen" erkannt wird ($cb_callestablished)
Zitat von: Rewe2000 am 07 Dezember 2017, 20:49:53
Mit der von Wzut beschriebenen Vorgehensweise (mp3wrap) würde ich auch dieses Verhalten in den Griff bekommen
habe das gerade getestet :
apt-get install mp3wrap
attribut TTS_UseMP3Wrap auf 1
den langen Satz mit dem und benutzt
und siehe da : T2S meldet unter lastFilename : cache/6508f014e73f90aa5338447c3a7b4b70_MP3WRAP.mp3
Man sieht schon am Namen das es die zusammengebaute Nachricht ist und gnau die bekommt man bei einemCall auch zu hören :)
Hallo,
jetzt klappt es auch mit dem "komischen" Ansagetext von mir und Text2Speech "verschluckt", dank "mp3wrap" nichts mehr.
Danke an euch allen, für die geduldige Hilfe.
Gruß Reinhard
Hallo, habe mal zwei Fragen:
1. Da die Ansage direkt nach dem Abheben kommt, wollte ich zuerst noch einen Ton abspielen mit
set sip call **611 30 /hdd/sda4/Sonos/speak/sounds/Gong.alaw !Das ist eine Mitteilung, die Dir vom Speicherknecht vorgelesen wird.
Der Ton wird abgespielt, jedoch nicht der Text. Was mache ich da falsch?
Der Text alleine ohne Ton kommt.
2. Ich habe alle mp3-Dateien, die ich auch für Sonos als presound verwende, mit
socx $file -t raw -r 8000 -c 1 -e a-law $outfile
umgewandelt. Allerdings bleiben einige Dateien dabei stumm, d.h. die Verbindung wird zwar so lange von sip-client gehalten, so lange wie die Datei sein sollte, man hört aber nichts.
Andere Parameter für die Konversion?
Danke.
Elektrolurch
Hallo Elektrolurch,
die Wartezeit bis zur Sprachansage stelle ich mit dem Attribut
"sip_call_audio_delay" ein:
Zitatsip_call_audio_delay
Damit wird festgelegt wie lange bei einem Call mit dem abspielen des Audiofiles gewartet werden soll nachdem man den Anruf angenommen hat. Gültige Werte sind 0 - 3 in 0.25 (1/4) Sekunden Schritten.
Bei mir steht da 1.75 und es reicht aus, damit der Höhrer das Ohr erreicht. Versuche ggf. mal auch einen etwas größeren Wert, max. 3 ist möglich. Ob zusätlich noch vor der Sprachansage ein Audiofile abgespielt werden kann, glaube ich nicht, aber man lernt ja täglich hinzu.
Zu deiner 2. Frage kann ich leider nichts beitragen, da ich (bisher) keine Soundfiles benutze.
Hörtst du denn etwas, wenn du das Mp3 File mit einen beliebigen MP3 Player anhörst, ev. hat das File ja selbst ein Problem.
Ich denke zu diesem Problem kann dir plin oder Wzut mehr helfen als ich.
Gruß Reinhard
Hallo Reinhard,
Zitat
Hörtst du denn etwas, wenn du das Mp3 File mit einen beliebigen MP3 Player anhörst, ev. hat das File ja selbst ein Problem.
Ja, die verwende ich ja alle für Sonos, funktionieren also.
Bei Sonos kann man die Audiodatien mit |datei> beliebig in den Text einbetten.
Mal eine generelle Anmerkung zur Syntax:
set sonos speak <volume> de |audiofile| TExt, der gesprochen werden soll.
set fritzbox call **611 <duration> say:TExt, der gesprochen werden soll
set sip call **611 <duration> !Text, der gesprochen werden soll
set SBPLAYER sayText Text, der gesprochen werden soll
Wäre ja eigentlich schön, wenn man über alle Module hinweg gleiche Syntax hätte....
Zitat von: Elektrolurch am 09 Dezember 2017, 11:15:29
set sip call **611 30 /hdd/sda4/Sonos/speak/sounds/Gong.alaw !Das ist eine Mitteilung, die Dir vom Speicherknecht vorgelesen wird.
Aktuell wird nur eine Nachricht eines Typs unterstützt (also audiofile, DTMF oder Text). Siehe auch https://wiki.fhem.de/wiki/SIP-Client#Set (https://wiki.fhem.de/wiki/SIP-Client#Set)
Zitat von: Elektrolurch am 09 Dezember 2017, 11:15:29
socx $file -t raw -r 8000 -c 1 -e a-law $outfile
Welche Extension hat denn das erzeugte File? .alaw? Da nur der Wissende alaw und ulaw unterscheiden kann, muss das über die Extension des Files mitgeteilt werden (Das Audioformat hat keinen Header). Siehe auch https://wiki.fhem.de/wiki/SIP-Client#Attribute (https://wiki.fhem.de/wiki/SIP-Client#Attribute)
@Elektrolurch ,
mit deine Pause zu Beginn entweder die im Modul vorgesehene Delay Funktion nutzen (siehe Rewe2000 Posting)
oder von Hand die mp3 Datei bearbeiten das sie eine Zeit X Stille am Anfang hat.
Zu deinem Problem der Konvertierung :
sox <mp3 File> -t raw -r 8000 -c 1 -e a-law <alaw File>
so wird Modul intern eine T2S mp3 Datei gewandelt.
Aufruf Parameter:
Ich versuche mich bei meinen Modulen eigentlich an die FHEM Richtlinien für Entwickler zu halten. Bei meinem MPD Modul war das relativ einfach, da es bestimmte Vorgaben bereits gab, hier schaut das etwas anders aus. Und wenn ich ehrlich bin habe ich mir am Anfang nicht die Mühe gemacht zu erforschen ob andere Module ähnliche Funktionen haben und wie deren Syntax ist. Ich habe kein Problem damit das alles auf den Kopf zu stellen, allerdings mögen das die anderen Autoren mit ihren Modulen dann bitteschön auch tun. Stellt sich nun die Frage welche Syntax wäre die "Richtige" ? say : , sayText: , ?
Hallo Wzut,
Konvertierung: Genauso habe ich es auch gemacht, aber manche mp3 scheinen sich da zu verweigern....
Ja, das mit den Aufrufparametern ist ein leidiges Problem. Hintergrund ist, dass ich mir so ein "Message-System" fürs Haus gebaut habe und je nach dem, wo oder was eingeschaltet ist, gebe ich da Audiomeldungen aus. Umfasst derzeit SONOS, ENIGMA2, SBPLAYER und fritzbox habe ich jetzt durch SIP ersetzt. DA musste ich überall eine TYPE-Abfrage einbauen, um die Geräte richtig anzusprechen. Eigentlich sollte fhem ja gerade das geräteunabhängig leisten....
Die "richtigen" Parameter gibt es ja nicht und das Problem ist, wenn man es ändert, müssten alle user auch Anpassungen durchführen.
Daher wäre ein denkbarer Weg, und das wäre auch einfach zu implementieren, mehrere Möglichkeiten einzubauen. So könntest Du zusätzlich zum "!" für den Beginn der Sprachausgabe auch "say:" und "speak" zu lassen.
Na ja, egal - jetzt habe ich die TYPE - Abfragen eh schon implementiert.
Das SIP-Modul ist schon cool und als nächstes werde ich mal sehen, ob es auch mit der Annahme von Anrufen klapt. Könnte man z.B. den "Hausstatus" über die Eingabe einer Nummer abrufen....
Dazu eine Frage: Wenn die SIP-Instanz auf "Rufe annehmen" steht (wartet), kann sie trotzdem auch Calls absetzen? Oder muss ich hierfür einen zweiten SIP-Klienten definieren?
Elektrolurch
Zitat von: Elektrolurch am 10 Dezember 2017, 10:41:11
Könnte man z.B. den "Hausstatus" über die Eingabe einer Nummer abrufen....
Dazu eine Frage: Wenn die SIP-Instanz auf "Rufe annehmen" steht (wartet), kann sie trotzdem auch Calls absetzen? Oder muss ich hierfür einen zweiten SIP-Klienten definieren?
a. Ja natürlich das war u.a. für mich der Grund überhaupt mit dem Modul anzufangen, FHEM steuern via Telefon und DTMF Tasten
b. Nein, eine SIP Instanz reicht. Das Modul kann beides zur gleichen Zeit. Aleerdings wenn die Platform damit Probleme hat kann mit dem Attribut elbc
automatisch ein Listen Prozess zuvor gestoppt werden und nach dem Call wieder automatisch neu gestartet
Hallo,
jetzt habe ich noch ein Problem, Anrufe anzunehmen. Es kommt immer ein Besetztzeichen, so als wäre der sip-client nicht für das Annehmen von Calls konfiguriert. Die anderen angemeldeten VoIP - Telefone funktionieren.
ich habe mit
set sip listen
auf den listen-Betrieb umgeschaltet.
Die Attribute sind
T2S_Device tts
audio_converter sox
sip_audiofile_call !Zur Zeit können keine Anrufe angenommen werden
sip_audiofile_wfp !°Dieser Anschluß kann derzeit keine Anrufe entgegennehmen.
sip_call_audio_delay 1.75
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_force_interval 300
sip_from sip:fhemfhem@fritz.box
sip_ip Speicherknecht
sip_listen wfp
sip_registrar fritz.box
sip_ringtime 2
sip_user fhemfhem
verbose 1
Internals:
AC /usr/bin/sox
LPID 21776
NAME sip
NOTIFYDEV tts
NR 947
NTFY_ORDER 50-sip
STATE listen_wfp
TYPE SIP
VERSION V1.61 / 30.10.17
helper:
LISTEN_PID:
abortArg
abortFn
arg sip
bc_pid 188
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 21776
timeout
Wenn ich mit nmap einen Portscan durchführe, wird der Port 5900 nicht angezeigt.
Calls vom sip - Klienten funktionieren, nur nicht das Annehmen von calls.
Habe ich da noch was übersehen?
Im ersten Schritt will ich nur eine Textnachricht ausgeben.
Es wird auch kein event generiert, was einen eingehenden Call signalisieren würde. Na ja, wenn der Port nicht offen ist....
P.S.: Firewall ist nicht aktiv.
Elektrolurch
was mir sofort auffällt :
LPID 21776
STATE listen_wfp
d.h. das schaut auf den ersten Blick so aus als ob der Listen Prozess erfolgreich gestartet wurde.
Ein zweiter Blick ist leider unmöglich da du verbose auf 1 hast !
Also :
1. verbose auf 5
2. set <name> reset
3. Client von einem Telefon aus anrufen
4. dem entsprechenden Log Abschnitt hier mit Code Tags posten
Hallo,
eigentlich kann ich nichts auffälliges im log erkennen, jedenfalls keine Signalisierung eines Anrufes:
<code>
2017.12.12 16:14:22 5: sip, listen process 31439 found
2017.12.12 16:15:22 5: sip, listen process 31439 found
2017.12.12 16:15:22 4: sip[31439], register new expire : 2017-12-12 16:20:22
2017.12.12 16:15:22 5: sip[31439], telnet : set sip state listen_wfp set sip listen_alive PID_31439 set sip expire 300 exit
2017.12.12 16:15:22 3: sip_not: sip rd listen_wfp val
2017.12.12 16:15:22 3: sip_not: sip rd listen_alive val PID_31439
2017.12.12 16:15:22 3: sip_not: sip rd expire val 300
</code>
Elektrolurch
Na das mit den Code Tags üben wir aber noch ein bissel ... ( Code Tags haben eckige Klammern nicht spitz)
Leider hast nicht das gemacht (oder gepostet) was ich sehen wollte
In deinem log Abschnitt ist lediglich das refresh des expire zu sehen, mich hätte aber interessiert wie der Ablauf nach dem Reset eines Listen Prozesses ist. U.A. ist dort der Listen Port zu sehen, denn ich weiss nicht wie du auf 5900 kommst.
Hallo, da ich einen Screenreader nutzen muss, kann ich den Button für den code leider nicht verwenden. ok, erde mal die eckigen Klammern versuchen...
Also, verbose auf 5, set sip reset und dann den Anruf auf **623.
Erhalte zwar wieder das Besetztzeichen, aber in der letzen Zeile des logs steht, dass er das File für die Ausgabe der Sprachnachricht verwenden will....
Habe ein notify auf sip:.* laufen, (Ausgae mit sip_not:), da steht aber kein event mit "ring" oder so.
Habe ich da ev. doch noch ein notwendiges Attribut vergessen?
2017.12.13 11:25:25 4: sip, Listen Kill PID : 6898
2017.12.13 11:25:25 1: Timeout for SIP_ListenStart reached, terminated process 6898
2017.12.13 11:25:25 3: sip_not: sip rd listen_alive val no
2017.12.13 11:25:25 4: sip, Reset Listen done
2017.12.13 11:25:25 4: sip, hole °Dieser Anschluß kann derzeit keine Anrufe entgegennehmen.
2017.12.13 11:25:26 4: sip, wait_for_t2s file : /hdd/sda4/Sonos/speak/3a7913361466135975617ed979aec1fa.mp3
2017.12.13 11:25:26 4: sip, new T2S file /hdd/sda4/Sonos/speak/3a7913361466135975617ed979aec1fa.mp3
2017.12.13 11:25:26 5: sip, not converted using /hdd/sda4/Sonos/speak/3a7913361466135975617ed979aec1fa.alaw from cache
2017.12.13 11:25:26 4: sip, Listen new PID : 7896
2017.12.13 11:25:26 4: sip[7896], my parent is 10524
2017.12.13 11:25:26 4: sip[7896], using random port 44512
2017.12.13 11:25:27 4: sip[7896], register new expire : 2017-12-13 11:30:27
2017.12.13 11:25:27 5: sip[7896], telnet : set sip state listen_wfp set sip listen_alive PID_7896 set sip expire 300 exit
2017.12.13 11:25:27 3: sip_not: sip rd listen_wfp val
2017.12.13 11:25:27 3: sip_not: sip rd listen_alive val PID_7896
2017.12.13 11:25:27 3: sip_not: sip rd expire val 300
2017.12.13 11:25:27 4: sip[7896], using /hdd/sda4/Sonos/speak/3a7913361466135975617ed979aec1fa.alaw for audio_wfp
Elektrolurch
Zitat von: Elektrolurch am 13 Dezember 2017, 11:35:17
da ich einen Screenreader nutzen muss
Sorry , dann war meine lässige Bemerkung unangebracht und werde es mir für die Zukunft merken !
Also zu deinem Log :
Das schaut erst einmal gut aus. Da du das Attribut sip_port nicht verwendest wird vom Modul ein Eigener verwendet,
in deinem Fall laut Log : 44512
Wenn du also mit netstat auf die Suche nach offenen Ports gehst, dann ist dieser der Richtige.
Ggf. kannst du natürlich auch einen festen Port nutzen, ich würde dann mit 5060 im Attribut sip_port beginnen.
Noch ein Wort zu deinem Screenreader : Erkennt er das Grad Zeichen (°) vor dem Satz "Dieser Anschluß kann derzeit keine Anrufe entgegennehmen" ? (Ich habe mich schon gefragt für was das gut sein soll, vermutlich ist es durch ein Versehen dahin gewandert)
Hallo,
ich versuche eben meine Türsprechstelle (a/b) an der Fritzbox in TabletUI einzubinden.
(1) Dafür würde ich gerne im Falle, dass des Event "caller_state" ringing kommt ein popup öffnen.
(2) in diesem popup soll es einen Taster geben, der den call annimmt und dann eine DTMF Tastenkombination "#9 - pause - #9 - pause - #9" sendet (zum mehrmaligen Öffnen der Türe)
(3) danach oder nach einem Timer soll das popup automatisch schliessen
was schonmal geht ist:
(1) popup öffnet beim Klingeln (durch event "ringing_2")
(2) der Taster im popup mit "fetch" holt das Gespräch (OK, auch zu hören an Türsprechstelle), aber leider kommen keine DTMF Töne an (und der Türöffner reagiert nicht), da "sip_audiofile_wfp -#9#9#9#9" wohl nicht funktioniert. Geht wohl nur mit "sip_audiofile_wfp !Hallo da draußen", was aber immer noch nicht den Türöffner aktiviert (geht mit "#9").
HAT JEMAND eine Idee, wie ich beim fetch auf wfp auch DTMF senden kann? Evtl sogar mit einer Pause zwischen "#9" und "#9"?
(3) popup schließt nach dem klick auf den Taster, leider noch nicht nach einem time-out
HAT JEMAND eine Idee, wie ich den "klick" und einen timeout zum Schließen verwenden kann?
mein FHEMsip habe ich wie folgt konfiguriert
define mySIP SIP
attr mySIP sip_user FHEMphone
attr mySIP sip_registrar 192.168.178.1
attr mySIP sip_from sip:FHEMphone@192.168.178.1
attr mySIP sip_ip 192.168.178.99
attr mySIP sip_listen wfp
attr mySIP sip_waittime 40
attr mySIP T2S_Device myT2S
attr mySIP audio_converter sox
attr mySIP sip_dtmf_send audio
attr mySIP sip_audiofile_wfp -#9#9#9#9
Mein Tablet-UI code sieht so aus:
<div data-type="popup" data-device="mySIP" data-get="caller_state" data-get-on="ringing_2" data-get-off="off" data-height="500px" data-width="500px">
<div class="dialog">
<header>Anruf von Türsprechstelle</header>
<div data-type="push" data-device="mySIP" data-icon="fa-folder-open-o" data-set-on="fetch" onclick="$('.dialog-close').trigger('click');"></div>
<div data-type="label" class="darker">Türe öffnen - fetch</div>
</div>
wfp kann als Quittung bei Rufannahme DTMF Signale absetzen oder ein Audiofile abspielen, aber es erwartet vom User keine DTMF Eingabe.
Aber IMHO hatten wir hier im Thread schon mal so einen (oder ähnlichen Fall) , ich würde das etwa so lösen.
Lass deinen Listen Prozess wie bisher auf wfp laufen , setze sip_waitime einen sehr großen Wert damit der Ruf gar nicht angenommen wird.
Setze sip_elbc auf yes
Ändere dein Popup so das der Taster zuerst ein set <name> reject macht um das Gebimmel zu stoppen und den Call zu beenden
kleine Pause ( 1 Sekunde ?)
setze dann ein "set <name> call <Rufnummer Tür> 30 -#9--#9--#9" ab (Pause im DTMF String mit Minus - siehe Wiki )
Wenn dein SIP Phone als Türsprechstelle in der FB angelegt ist sollte das klappen.
ZUm Thema TabletUI kann ich nichts sagen , keine Ahnung und nicht bei mir im Einsatz
Zitat von: speedAmaster am 13 Dezember 2017, 18:32:36
HAT JEMAND eine Idee, wie ich beim fetch auf wfp auch DTMF senden kann? Evtl sogar mit einer Pause zwischen "#9" und "#9"?
Wie wär's mit einem generierten Soundfile (z.B. via http://dialabc.com/sound/generate/) das als wfp audiofile hinterlegt wird. Mit einem Sound-Editor kann man auch Pausen einbauen.
klingt auch gut , die Arbeit muss man ja nur einmal machen.
Als Audioformat gleich u-law mono 8000 Hz auswählen ?
Hallo, super Ideen zum Thema (2). Werde ich morgen ausprobieren! Ich melde mich!
Zum Thema (3) automatisches Schließen des popup nach bestimmter Zeit, habe ich das attribut "data-return-time" des popup-Widget gefunden => gelöst
Hallo Wzut,
habe mal den Port nun fix auf 5060 gestelt, aber er erscheint weder bei einem nmap - scan, noch bei netstat.
Das log sieht nach einem Neustart so aus:
2017.12.14 11:40:07 4: sip, hole Dieser Anschluß kann derzeit keine Anrufe entgegennehmen.
2017.12.14 11:40:07 4: sip, wait_for_t2s file : /hdd/sda4/Sonos/speak/467364dc0fc54b072c264ef90ee8ab1a.mp3
2017.12.14 11:40:07 4: sip, new T2S file /hdd/sda4/Sonos/speak/467364dc0fc54b072c264ef90ee8ab1a.mp3
2017.12.14 11:40:07 5: sip, not converted using /hdd/sda4/Sonos/speak/467364dc0fc54b072c264ef90ee8ab1a.alaw from cache
2017.12.14 11:40:07 4: sip, Listen new PID : 2331
2017.12.14 11:40:07 4: sip[2331], my parent is 1289
2017.12.14 11:40:08 4: sip[2331], register new expire : 2017-12-14 11:45:08
2017.12.14 11:40:08 5: sip[2331], telnet : set sip state listen_wfp set sip listen_alive PID_2331 set sip expire 300 exit
2017.12.14 11:40:08 3: sip_not: sip rd listen_wfp val
2017.12.14 11:40:08 3: sip_not: sip rd listen_alive val PID_2331
2017.12.14 11:40:08 3: sip_not: sip rd expire val 300
2017.12.14 11:40:08 4: sip[2331], using /hdd/sda4/Sonos/speak/467364dc0fc54b072c264ef90ee8ab1a.alaw for audio_wfp
Elektrolurch
gelöst!
Hallo an Wzut und plin: vielen Dank für eure Hilfe! Dank eures Zutuns lebt diese community!
Ich habe ein persönliches Ansage-File in wav aufgenommen. Dazu die DTMF-Töne (incl Pause durch " ") über http://dialabc.com/sound/generate/ erzeugt. Beide Dateien zusammengehängt und mittels sox in alaw umgewandelt.
mein TabletUI-code sieht so aus (popup bei Türklingeln, schließt automatisch bei keiner Aktion, öffnet Gartentüre und schließt popup)
<div data-type="popup" data-device="mySIP" data-get="caller_state" data-get-on="ringing_2" data-get-off="off" data-height="500px" data-width="800px" data-return-time="60">
<div class="dialog">
<header>Anruf von Türsprechstelle</header>
<div data-type="push" data-device="mySIP" data-icon="fa-folder-open-o" data-set-on="fetch" onclick="$('.dialog-close').trigger('click');" class="grande" data-off-color="red" data-on-color="red"></div>
<div data-type="label" class="darker grande bold red">Gartentüre öffnen</div>
</div>
</div>
mein SIP device sieht so aus (wartet und erkennt Anruf (Klingeln), spielt bei fetch die kombinierteAnsage+DTMF-Töne ab)
define mySIP SIP
attr mySIP sip_user FHEMphone
attr mySIP sip_registrar 192.168.178.1
attr mySIP sip_from sip:FHEMphone@192.168.178.1
attr mySIP sip_ip 192.168.178.99
attr mySIP sip_listen wfp
attr mySIP sip_waittime 999
attr mySIP sip_elbc yes
attr mySIP T2S_Device myT2S
attr mySIP audio_converter sox
attr mySIP sip_dtmf_send audio
attr mySIP sip_audiofile_wfp ./www/tablet/images/AnsageOpen.alaw
attr mySIP room sysGeneral,zzTelefon
define myT2S text2speech none
attr myT2S room sysGeneral,zzTelefon
@Elektrolurch hmmmm, da benimmt sich wohl dein Cubi wieder etwas anders als mein RasPi oder mein Desktop PC mit Ubuntu.
Ich schaue mir das heute Abend nochmal bei mir mit netstat bzw. nmap an, allerdings könnte ich wetten das
der benutzte Port als offen angezeigt wird.
Gibt es im Netz irgendwelche Hinweise auf dein verwendetes OS das da eventuell eine Firewall oder iptables am Werk sind ?
Zitat von: speedAmaster am 14 Dezember 2017, 12:56:36
Ich habe ein persönliches Ansage-File in wav aufgenommen. Dazu die DTMF-Töne (incl Pause durch " ") über http://dialabc.com/sound/generate/ erzeugt. Beide Dateien zusammengehängt und mittels sox in alaw umgewandelt.
fein aber war die sox Wandlung wirklich nötig ? Ich dachte dailabc kann direkt ulaw ?
Aber anyway , der Erfolg zählt nicht der Weg dahin
Hallo Wzut,
Zitat:
Gibt es im Netz irgendwelche Hinweise auf dein verwendetes OS das da eventuell eine Firewall oder iptables am Werk sind ?
Nein, eigentlich nicht. Auf dem Cubie läuft das aktuelle Jessie. Alle anderen Ports, z.B. ssh, netbios, rsync, fhem usw. liefen ohne das ich etwas an den IP-Tables manipulieren musste.
Das einzige, was ich für Port 443 tcp mal in die IP-Tables eingetragen habe, war ein forwarding für das virtuelle Zwischennetz von openvpn.
Ja, schau mal, was bei Dir nmap bzw. netstat ausspuckt.
Vermutlich macht ja die perl-lib für die Kommunikation mit einem sip-server den Port auf. Ob man da noch etwas mehr infos in das log bekommen könnte?
mir ist da gerade etwas eingefallen : du hast in Antwort 497 deine config des Moduls gepostet.
Du hast bei sip_port keine IP stehen sondern Speicherknecht
Ändere doch bitte mal sip_ip auf die echte IP Adresse unter der FHEM von der Fritzbox aus erreichbar ist.
Hallo Wzut,
das wars. Mit der IP, statt des Namens geht es jetzt und der Text wird auch abgespielt.
Danke.
Ich dachte allerdings, dass es mal in den Modulen von fhem eine größere Umstellung gegeben hat die IPs auch durch die Servernamen ersetzbar zu machen.
Möchte irgendwann mal mein Neztwerk von der 192.168.1.xxx umstellen, da openvpn nur dann funktioniert, wenn das Ausgangsnetz nicht identisch mit dem Zielnetz (192.168.1.x very common) identisch ist.
Und da graust es mir schon davor, überall die IPs zu suchen und zu ändern.... :-)
Ok, Hauptsache es geht erst mal. Danke für die Geduld.
Eigentlich möchte ich beim Anrufen einen dynamischen Text abspielen, z.B. mit den Statusdaten von fhem. Jetzt wird ja per Attribut auf eine Datei verwiesen. Was wäre aus Deiner Sicht der beste Weg, die dynamische Ausgabe der Mitteilung zu generieren? Beim ringing - Event?
Elektrolurch
Dynamische Texte im Listen Prozess für eingehende Anrufe sind nicht so einfach umzusetzen wie beim ausgehenden Ruf.
Eine Möglichkeit wäre du entscheidest dich für eine fixe Audiodatei, z.B. /cache/mytxt.mp3
Im normalen FHEM Prozess must du nun dafür sorgen das mit Text2Speech diese Datei frisch gehalten wird, damit wenn der Anruf kommt diese abgespielt werden kann. D.h. der Name der mp3 Datei bleibt fix, aber deren Inhalt ändert sich quasi ständig. Das Ganze sollte sich mit einer kleinen Sub in der 99_myUtils lösen lassen, etwa in der Art :
1. Dynamischen Text übergeben
2. diesen mit Hilfe von T2S wandeln
3. die von T2S erzeugte Datei aus dem Reading last_filename umkopieren in mytxt.mp3
Update :
Ich habe eben die neue Version als V1.71 hochgeladen (via Update ab morgen erhältlich)
Die Änderungen beziehen sich im wesentlichen auf die hier in den letzten zwei Wochen besprochenen Themen.
( Ref . -> https://forum.fhem.de/index.php/topic,67443.msg725278.html#msg725278 )
Allerdings habe ich intern noch etwas aufgeräumt und die eigene Telnet Verbindung zwischen Kind und Eltern Prozess komplett entfernt und gegen Rudis
BlockingInformParent aus Blocking.pm ersetzt. Ich hoffe alles gründlich durchgetestet zu haben (das ist inzwischen echt schwer geworden), falls es dennoch irgenwo klemmen sollte bitte hier schreien :)
Kurztest der 1.71:
listen_wfp -> geht
call -> geht
fetch -> geht
Hallo Wzut,
habe häufiger folgendes im Log:
2017.12.26 19:13:29 1: Timeout for SIP_ListenStart reached, terminated process 1391
2017.12.26 19:54:44 1: Timeout for SIP_ListenStart reached, terminated process 2420
ohne dass da ein Anruf stattgefunden hat.
Was hat das zu bedeuten? Kann ich da etwas verbessern?
Ist das ein ernstes Problem oder könnte man den Loglevel für diese Meldung auf 2 setzen?
Gruß
Elektrolurch
Die Meldung kommt nicht direkt aus 96_SIP sondern aus Blocking.pm , d.h. den Level kann ich nicht beeinflussen.
Du kannst verbose auf 0 setzen dann ist auch Ruhe, allerdings besagt die Meldung das Blocking.pm der Meinung ist der Start des Listen Prozess dauere zu lange und bricht ihn ab. Das sollte Blocking.pm eigentlich nur tun wenn der Modulautor einen Timeout Wert beim Start mit übergibt - was ich aber nicht tue, denn der Listen Prozess soll ja recht lange laufen. D.h. ich verstehe nicht warum Blocking.pm bei dir der Meinung ist einen Timeout Wert zu haben und die interne Überwachung startet.
Kannst du bitte mal wenn der Listen Prozess wirklich läuft in der Kommandozeile von FHEM blockinginfo eingeben und die Ausgabe hier posten ?
Pid:23934 Fn:SIP_ListenStart Arg:sip Timeout:N/A ConnectedVia:N/A
Da wird wohl kein timeout übergeben.
Konnte bisher auch noch keine Systematik erkennen. Manchmal gibt es diese Meldung 3 x Mal binnen 20 Minuten, sogar mitten in der Nacht (fhem schläft da auch :-)), dann wieder mehrere Stunden ist alles ok....
Elektrolurch
Ok, dann wäre das schon mal abgekärt.
Es gibt noch eine Möglichkeit für diese Meldung : Wenn das 96_SIP selbst der Meinung ist der Listen Prozess müsse neu gestartet werden.
Möglichkeit a : Es werden Attribute geändert die den Listen Prozess direkt betreffen, Neustart erforderlich sonst würde er die Änderung nicht mitbekommen.
Möglichkeit b : Du hast das Attribut sip_elbc auf 1 stehen, dann wird der Listen Prozess beendet bevor der ausgehende Ruf gestartet wird.
Stutzig macht mich aber deine Aussage das es mitten in der Nacht passiert , also scheidet vermutlich a. als auch b. aus
Klarer könnte das Ganze werden wenn du das Modul einfach mal einen Tag mit verbose 4 laufen lässt, bzw. mindestens so lange bis die Timeout Meldung im Log erscheint.
In der Zeilen davor sollte sich dann ein erklärbarer Grund finden lassen.
Hallo Wzut,
ok, das Attribut
sip_elbc
stand auf yes, habe das auf 0 gesetzt. Hatte das von weiter oben übernommen, ohne das ich weiß, welche Funktion es hatte.
Nun sind die sporadischen Meldungen erst einmal weg. Sie kommen nur, wenn über sip ein Anruf ausgelöst wird.
Der Befehl:
set sip call *611 10
(ohne Text oder File) gibt folgendes im log aus:
2017.12.28 10:47:02 1: Timeout for SIP_ListenStart reached, terminated process 6669
2017.12.28 10:47:02 1: PERL WARNING: Use of uninitialized value $a[2] in substitution (s///) at ./FHEM/96_SIP.pm line 817.
2017.12.28 10:47:02 1: PERL WARNING: Use of uninitialized value $a[0] in join or string at ./FHEM/98_Text2Speech.pm line 461.
2017.12.28 10:47:02 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Text2Speech.pm line 894.
2017.12.28 10:47:02 1: PERL WARNING: Use of uninitialized value $file in -e at ./FHEM/98_Text2Speech.pm line 896.
2017.12.28 10:47:02 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Text2Speech.pm line 731.
2017.12.28 10:47:03 1: PERL WARNING: Use of uninitialized value $file in concatenation (.) or string at ./FHEM/98_Text2Speech.pm line 752.
2017.12.28 10:47:03 1: PERL WARNING: Use of uninitialized value $file in concatenation (.) or string at ./FHEM/98_Text2Speech.pm line 754.
2017.12.28 10:47:03 1: PERL WARNING: Use of uninitialized value $file in -e at ./FHEM/98_Text2Speech.pm line 902.
2017.12.28 10:47:03 1: PERL WARNING: Use of uninitialized value $file in concatenation (.) or string at ./FHEM/98_Text2Speech.pm line 912.
Da müsste wohl für den Fall, dass es nur klingeln soll, auf das nicht Vorhandensein des Parameters in @a abgefragt werden.
Gruß
Elektrolurch
Zitat von: Elektrolurch am 28 Dezember 2017, 11:00:43
sip_elbc
stand auf yes, habe das auf 0 gesetzt.
Du meinst auf no , denn 0 gibt es nicht
Sodele dann nochmal elbc bedeutet End Listen Befor Call oder auf deutsch "Beende einen laufenden Listen Prozess vor einem ausgehenden Anruf"
Auf einem Raspberry 3 kann man das meiner Meinung nach ruhig auf no setzen.
Wegen deiner anderen Warnungen im Log : Da meckert nicht nur das SIP Modul sondern auch Text2Speach !
Poste doch bitte nochmal ein vollständiges List deines SIP Device, denn ich habe die Warnungen bei mir nicht und
mich machen auch die angegeben Zeilennummern etwas stutzig, die passen sogar nicht mit meiner aktuellen Version zusammen.
Aktuell wird die V1.71 via Update verteilt.
Das steht im Modul - Kopf:
# $Id:17-10-30 13:41:59Z Wzut $
Mehr gibts nicht per update bei mir.
Internals:
AC /usr/bin/sox
LPID 27924
NAME sip
NOTIFYDEV tts
NR 946
NTFY_ORDER 50-sip
STATE listen_wfp
TYPE SIP
VERSION V1.71 / 16.12.17
READINGS:
2017-12-28 10:50:50 call done
2017-12-28 10:50:50 call_attempt 0
2017-12-28 10:50:50 call_state peer hangup
2017-12-28 10:50:50 call_success 0
2017-12-28 10:50:50 call_time 7
2017-12-28 10:51:38 caller none
2017-12-28 10:51:38 caller_state waiting
2017-12-27 20:53:48 caller_time 0
2017-12-28 12:00:54 expire 300
2017-12-07 11:13:50 last_error sox error signal_Fenster_Offen.on.png
2017-12-28 12:00:54 listen_alive 27924
2017-12-28 12:00:54 state listen_wfp
helper:
LISTEN_PID:
abortArg
abortFn
arg sip
bc_pid 1007
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 27924
timeout
Attributes:
T2S_Device tts
audio_converter sox
sip_audiofile_call !Zur Zeit können keine Anrufe angenommen werden
sip_audiofile_wfp /media/Sonos/speak/report.alaw
sip_call_audio_delay 1.75
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc 0
sip_force_interval 300
sip_from sip:fhemfhem@fritz.box
sip_ip 192.168.1.16
sip_listen wfp
sip_port 5060
sip_registrar fritz.box
sip_ringtime 2
sip_user fhemfhem
verbose 1
sip_elbc setze ich mal auf no.
Gruß
Elektrolurch
OK , du hast wohl die aktuelle V1.71 auch wenn ich nicht weiss warum die Zeilenummern nicht so recht passen.
Konnte auf jeden Fall deinen Fehler jetzt nachstellen, Ursache ist dein hinterlegter Text im Attribut sip_audiofile_call.
Ursprünglich war da eigentlich nur ein echtes Audiofile erlaubt und kein Text und genau da klemmt es wohl bei dir z.Z.
Abhilfe bis zur nächsten Version :
Schau dir bitte mal meine Antwort Nummer 500 hier im Thread an -> https://forum.fhem.de/index.php/topic,67443.msg727413.html#msg727413
Update : Ich habe eben die version 1.75 hochgeladen
Die großen Änderungen :
alle Attribute die mit sip_audiofile_ beginnen dürfen ab sofort einen Inhalt der folgenden Form haben :
a. ein .alw oder .ulaw Filename inklusive Pfad
b. ein .mp3 File + Pfad -> wird dann automatisch zu .ulaw gewandelt , Audio Konverter & Schreibrechte im Pfad sind Pflicht
c. ein Text beginnend mit ! der von Text2Speach in eine .mp3 Datei gewandelt wird, diese wird danach behandelt wie unter Punkt b.
wurde Punkt b. oder c. einmal erfolgreich durchlaufen wird beim nächsten Mal direkt die erzeugte .ulaw Datei verwendet.
Hallo Wzut,
zunächst mal dir und allen Mitlesern alles Gute in 2018.
Bedeutet das jetzt, dass dein Hinweis https://forum.fhem.de/index.php/topic,67443.msg727413.html#msg727413 (https://forum.fhem.de/index.php/topic,67443.msg727413.html#msg727413) der Vergangenheit angehört und SIP jetzt selbst erkennt ob ein Text schon mal übersetzt wurde?
Oder hab ich da etwas falsch verstanden.
Gruß Reinhard
ja und nein :)
wenn du direkt eine mp3 Datei angibst schaut das SIP Modul zuerst nach ob es die unter dem gleichen Namen auch als .alaw gibt, wenn ja spart man sich die erneute Konvertierung mit sox oder ffmeg. Gibt man allerdings einen Text an, so muss immer T2S zuerst gefragt werden wie denn z.B. !Das ist ein test in dieses lange Zahlenformat
übersetzt werden soll , die Antwort ist dann ja eine mp3 Datei und dann gilt wieder das oben geschriebene.
Ich muss mal schauen wie Tobias im T2S Modul aus dem Text diese eindeutige lange Nummer bastelt , wenn ich das "klauen" könnte, dann wäre es möglich direkt ersteimal selbst im cache nachzuschauen ohne zuerst T2S aufzurufen ... hmmm wieder so ne Idee und ich dachte wirklich schon da gibt es nichts mehr am Modul zu schrauben.
Hallo Wzut,
danke für die ausführliche Erklärung.
Da denke ich solltest du dir die Mühe sparen, es besteht ja nach wie vor die Möglichkeit (bei Leistungsschwachen Systemen) die bereits übersetzte .ulaw Datei beim set.. Aufruf zu verwenden.
Ich verwende SIP derzeit auf einem RASPI3 nur mit direkten Textangaben (!Text..), der Raspi übersetzt diesen Text ohne dass ich bisher die Notwendigkeit gesehen habe, auf .ulaw Datei umzustellen.
Aber ich kenne das ja auch, irgendwann sucht man sich immer wieder neue Herausforderungen ;)
Gruß Reinhard
Hallo Wzut,
nach langer Zeit habe ich in meinen alten Thread zum FB_SIP.pm Modul geschaut und war erstaunt, welche Dynamik sich daraus entwickelt hat. Ich benötigte es damals nur für einen Alarmanruf, die nähere Information zum Ereignis hatte ich per Telegram bekommen. Daher der Stillstand.
Ich wünsche dir alles Beste für die Weiterentwicklung.
Liebe Grüße
Werner
Hallo Werner, ja das Thema Dynamik ist wirklich immer wieder erstaunlich bei FHEM.
IMHO bedarf es dafür aber zwei Seiten, auf der einen Seite die User die ständig mit irgendwelchen abgefahrenen Ideen oder Problemen um die Ecke kommen und auf der anderen Seite natürlich Entwickler die verrückt genug sind das auch alles zeitnah umzusetzen. An der Stelle möchte ich nochmal ganz klar betonen das ohne deine Pionierarbeit es das heutige SIP Modul gar nicht geben würde und ohne die aktive Mitarbeit der User schon gar nicht mit diesem Funktionsumfang.
Auch von mir besten Dank. Die letzte "abgefahrene" Idee war, dass ich mein fhem anrufe und der mir einen ausführlichen Report über Fenster, Heizung, Solaranlage, Wetter usw. liefert. Auf Grund der Nummer, die anruft, Uhrzeit und ev. Feiertag, erfolgt die Ansage auch noch personalisiert, zum Staunen aller Computer-Unkundiger!
Gruß
Elektrolurch
@Elektrolurch, da packt mich (und vermutlich noch andere) die Neugier.
Wärst du bitte so nett das mit dem ausführlichen Report etwas mehr im Detail hier zu veröffentlichen ?
ok.
1. Meine sip-Instanz heisst sip, dafür ein notify definieren.
define notify sip_not sip:.* {sip_not($NAME,$EVENT)}
Die sip-Instanz habe ich wie folgt eingestellt:
T2S_Device tts
audio_converter sox
sip_audiofile_call !Zur Zeit können keine Anrufe angenommen werden
sip_audiofile_wfp /media/Sonos/speak/report.alaw
sip_call_audio_delay 1.75
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc no
sip_force_interval 300
sip_from sip:fhemfhem@fritz.box
sip_ip 192.168.1.16
sip_listen wfp
sip_port 5060
sip_registrar fritz.box
sip_ringtime 2
sip_user fhemfhem
verbose 1
Wichtig: ringtime steht auf 2 und es ist für den eingehenden Anruf eine feste Audio-Datei eingestellt, die aber zwischen klingeln und Gespräch annehmen neu generiert wird (sub sip_report)
Das notify führt folgendes aus:
sub sip_not($$)
{
my ($name,$event) = @_;
my ($rd,$val) = split(' ',$event);
($rd) = split(':',$rd);
$val = '' if(!$val);
Log3($name,3,"sip_not: $name rd $rd val $val");
if($rd eq 'caller')
{
return undef if($val eq 'none');
fhem("set tts1 tts " .
sip_report($val));
} # if caller
return undef;
} # end sub sip_not
Die sip_report nimmt nur Anrufe von bekannten Telefonen an:
sub sip_report($)
{
my ($caller) = @_;
my $res = "Guten Tag ";
return "" if($caller eq 'none');
my (undef,$min,$hour) = localtime(time());
# Namen der Anrufer sind bekannt
if($caller =~m/(Tochter|Sohn|Mama|Papa)/)
{
$res = "Guten morgen " if($hour < 11);
$res = "Hallo " if($hour >= 11 && $hour <= 17);
$res = "Guten Abend " if($hour > 17);
$res .= "$caller, hier ist Dein Speicherknecht mit dem Bericht von $hour Uhr$min. ";
my $alarmstatus = Value('Alarm_innen');
$res .= "Die Alarmanlage ist $alarmstatus. ";
if($alarmstatus eq 'scharf')
{
my $sender = ReadingsVal('Alarm_innen','Sender',undef);
$res .= "Es wurde Alarm um " . ReadingsTime('Alarm_innen','Sender',1) . " von " .
"$sender ausgelöst. " if($sender);
} # Alarm ausgelöst
$res .= "Im Garten war jemand um " . ReadingsTime('Ga_Bewegungsmelder','state',1) .
" und an der Haustür um " . ReadingsTime('VG_Bewegungsmelder','state',1) . ". ";
my $anwesend = 0;
# Fenster
my @rooms =map({(ReadingsVal($_,'Window','') eq 'Open') ? (GetRoom($_)):()} devspec2array("TYPE=CUL_FHTTK"));
if(@rooms)
{
$res .= "Im " . HumanList(@rooms) . " sind Fenster offen. ";
}
# Beleuchtung
my %rooms = map({(ReadingsVal($_,'state','') =~m/on/) ? (GetRoom($_),$_):()} devspec2array("group=Beleuchtung"));
@rooms = sort keys %rooms;
if(@rooms)
{
$res .= "Im " . HumanList(@rooms) . " ist das Licht an. ";
$anwesend = 1;
}
# Audio und Video
@rooms = map({(ReadingsVal($_,'state','') eq 'on') ? ($_):()} devspec2array(".._Media"));
if(@rooms)
{
$anwesend = 1;
# Log(1,join(' ',@rooms));
foreach my $r (@rooms)
{
if($r eq 'Ku_Media')
{
$res .= "In der Küche wird " .
ReadingsVal('Ku_Player','favorites','Musik') .
" gehört. ";
}
elsif($r =~m/(Wz|Hb)_Media/)
{
my $receiver = $1 . '_Receiver';
$res .= "Im " . GetRoom($r) . " wird im " .
ReadingsVal($receiver,'channel','nicht gefunden') . " die Sendung " .
ReadingsVal($receiver,'eventname','unbekanntes Programm') . " angeschaut. ";
} # TV
else
{
$res .= "Im " . GetRoom($r) . " wird Musik gehört. ";
} # else
} # foreach
} # Audo und Video
if(!$anwesend)
{
my %bews = map({(ReadingsAge($_,'state',0),GetRoom($_))}
devspec2array("[EO]G.*_Bewegungsmelder.*"));
my $mintime = minNum(999999,(keys %bews));
# Log(1,"mintime $mintime " . join(' ',%bews));
if($mintime > 10000)
{
$res .= "Es scheint niemand zu Hause zu sein. ";
} # niemand da
else
{
$res .= "Den letzten habe ich vor " .
sprintf("%d",$mintime / 60) .
" Minuten im " .
$bews{$mintime} .
" gesehen. ";
}
} # Bewegungsmelder innen
my @persons = split(' ',ReadingsVal('Abwesend','Anwesend',''));
if(@persons)
{
$res .= HumanList(@persons) . " sind seit " .
ReadingsTime('Abwesend','Anwesend',1) . " zu Hause. ";
} # personen mit Handy eingebucht im WLan
@persons = split(' ',ReadingsVal('Abwesend','Abwesend',''));
if(@persons)
{
my $ahash = $defs{Abwesend};
foreach my $p (@persons)
{
$res .= $p . " ist seit " .
HumanTime($ahash->{Abwesend}{$p},1) . ", ";
} # foreach p
$res .= " nicht zu Hause. ";
} # personen mit Handy nicht eingebucht im WLan
# Heizung
my $laufzeit = sprintf("%d",ReadingsVal('HzAnlage','Brennerlaufzeit-heute',0));
my $verbrauch = sprintf("%d", ReadingsVal('HzAnlage','Gas-Verbrauch',0) + 0.5);
my $fehler = ReadingsVal('HzAnlage','Fehler','');
if($fehler ne 'fehlerfrei')
{
$res .= "Die Heizungsanlage meldet $fehler. ";
} # if fehler
my $betriebsart = ReadingsVal('HzAnlage','Hk2-Betriebsart','nicht gefunden');
$res .= "Die Heizung steht auf $betriebsart Betrieb. ";
$res .= "Die Vorlaftemperatur beträgt " . ReadingsVal('HzAnlage','Hk2-Normal-VL-Soll','nicht gefunden') . " Grad. " if($betriebsart eq 'Normal');
$res .= "Der Gasverbrauch beträgt $verbrauch Kubik bei einer Laufzeit von $laufzeit Minuten. " if($verbrauch);
# Solaranlage
my $solarstatus = ReadingsVal('HzAnlage','Status-DTR','nicht gefunden');
if($solarstatus eq 'Ertrag')
{
my $ertrag = sprintf("%d",ReadingsVal('HzAnlage','Tagesertrag',0) + 0.5);
my $kollektor = sprintf("%d",ReadingsVal('HzAnlage','Temp-Kollektor',0) + 0.5);
$res .= "Der Ertrag der Solaranlage beträgt $ertrag Kilowatt bei einer Kollektortemperatur von $kollektor Grad Celsius. ";
} # Solarstatus
# Wetter
$res .= "Das Wetter ist " . ReadingsVal('Wetter','condition','nicht gefunden') . ". ";
$res .= "Die Temperatur Aussen beträgt " .
sprintf("%d",ReadingsVal('Wetter','Temperatur',0) + 0.5) . " Grad Celsius. ";
$res .= "Dabei war das Minimum " .
sprintf("%d",ReadingsVal('Wetter','Min-Temperatur',0) - 0.5) . " und das Maximum " .
sprintf("%d",ReadingsVal('Wetter','Max-Temperatur',-100) + 0.5) . " und ";
$res .= "im Haus ist es " .
sprintf("%d",ReadingsVal('PID','Innentemperatur',0) + 0.5) . " Grad warm. ";
# Tschuess
$res .= "$caller, ";
if($hour < 18)
{
my $t = Value('bayern');
my $tag = 'einen schönen Tag';
if($t ne 'none')
{
if($t =~m/tag/i)
{
$tag = "einen schönen $t";
}
else
{
$tag = "ein schönes $t";
} # else
} # not none
$res .= "ich wünsche Dir noch $tag! ";
} # tag
$res .= "ich wünsche Dir noch einen geruhsamen Abend! " if($hour >= 18 && $hour < 22);
$res .= "ich wünsche Dir eine gute Nacht! " if($hour >= 22 );
} # bekannter Anrufer
else
{
$res = "Zur Zeit kann kein Anruf entgegengenommen werden. ";
} # unknown
# Log(1,"caller $caller\n$res");
return $res;
} # end sub sip_report
#################################
ReadingsTime und Humantime geben Zeit/Datum aus, z.B. jetzt, vor kurzem vor 2 Minuten, vor 3 Stunden, gestern um 13:05 Uhr usw.
HumanList gibt eine Liste aus, wobei die letzten zwei Elemente sprachlich mit einem "und" verbunden werden.
Okay. Soweit zur "Anregung". er Vorführeffekt ist jedenfalls schon mal da....
Hier mal ein Beispiel:
Guten Abend Papa, hier ist Dein Speicherknecht mit dem Bericht von 18 Uhr37. Die Alarmanlage ist aus. Im Garten war jemand um 17 Uhr 45 und an der Haustür um 18 Uhr 16. Im Küche und OG1 ist das Licht an. Mama und Papa sind seit 18 Uhr 29 zu Hause. Die Heizung steht auf Normal Betrieb. Die Vorlaftemperatur beträgt 51 Grad. Der Gasverbrauch beträgt 8 Kubik bei einer Laufzeit von 182 Minuten. Das Wetter ist Schauer. Die Temperatur Aussen beträgt 8 Grad Celsius. Dabei war das Minimum 3 und das Maximum 8 und im Haus ist es 19 Grad warm. Papa, ich wünsche Dir noch einen geruhsamen Abend!
Elektrolurch
WOW , ich bin beeindruckt !
Ich kann mir gut vorstellen das so eine Lösung für dich/euch um ein Vielfaches effektiver ist als eine FHEM Statusseite mit dem Screenreader aufzurufen.
Einen Vorschlag hätte ich für dich allerdings noch, lies dir mal im Wiki den Abschnitt über sip_blocking und sip_filter durch.
Du könntest Anrufer die nicht zu deiner Familie gehören auch gleich im Modul ignorieren.
Hallo Wzut,
Zitat:
sip_blocking und sip_filter durch.
Hatte ich gelesen. Aber ein unerwünschter Anrufer erhält ja bei jmir auch eine Mitteilung, dass der Anruf derzeit nicht angenommen werden kann.
Ich hatte mir die sip-Events angesehen und dabei ja festgestellt, dass die anrufenden Telefonnumern wohl durch die FB mit Hilfe des dort gespeicherten Adressbuches um die Namen ergänzt werden. Da bei uns die NSt, Geschäfts-, Handy und sonstigen Privatnummern in der FB abgelegt sind, war das mit den Namen zu filtern ja auch nur eine Zeile Code.
Elektrolurch
Hallo,
angeregt durch Elektrolurch habe ich das notify etwas anders gestaltet. Lag einfach daran, dass ich nicht erkennen konnte, wie er die mp3 nach alaw konvertiert.
Mein SIP Device heißt: FritzSip
FritzSip:*.* {
my ($rd,$val) = split(' ',$EVENT);
($rd) = split(':',$rd);
$val = '' if(!$val);
Log3 $NAME, 4, "$SELF: $NAME rd $rd val $val";
if($rd eq 'caller' && $val ne 'none') {
my $t2s_name = AttrVal($NAME, "T2S_Device", undef);
# Hier wieder Funktionsaufruf aktivieren
# fhem("set $t2s_name tts " . sip_report($val));
# Das ist nur zum Testen
fhem("set $t2s_name tts " . "Das ist ein super super Test");
# wait a little for being ready
sleep(0.5);
my $file = ReadingsVal($t2s_name, "lastFilename", "");
my $out = AttrVal($NAME, "sip_audiofile_wfp", undef);
my $converter = AttrVal($NAME, "audio_converter", "");
my $res = qx(which $converter);
$res =~ s/\n//;
$res = ($res) ? $res : undef;
my $cmd = $res . " " . $file . " -t raw -r 8000 -c 1 -e a-law " . $out;
Log3 $NAME, 3, "$SELF: calling converter with: $cmd";
my $ret = qx($cmd);
if ($ret) {
Log3 $NAME, 3, "$SELF: error with $converter: $ret";
} else {
$cmd = "rm " . $file;
$ret = qx($cmd);
if ($ret) {
Log3 $NAME, 3, "$SELF: error while deleting: $file";
} else {
Log3 $NAME, 3, "$SELF: deleted: $file";
}
}
} # if caller
}
[Code]
Hoffe es gefällt.
Grüße Jörg
Zitat von: Wzut am 03 Januar 2018, 17:24:13
Ich muss mal schauen wie Tobias im T2S Modul aus dem Text diese eindeutige lange Nummer bastelt , wenn ich das "klauen" könnte, dann wäre es möglich direkt ersteimal selbst im cache nachzuschauen ohne zuerst T2S aufzurufen
Habe es gerade als V1.76 hochgeladen
@Elektrolurch:
ich habe mir erlaubt Dein Werk ins Wiki aufzunehmen und auf den Forumsbeitrag zu verlinken (https://wiki.fhem.de/wiki/SIP-Client#FHEM_Statusberichte)
VG plin
@plin , gutes Stichwort Wiki :
Audioformat : alaw oder ulaw , davon wird im Wiki eigentlich immer ausgegangen. Inzwischen darfs aber ja auch mp3 sein, da die Konvertierung jetzt bei Bedarf automatisch läuft (sox oder ffmepg vorausgesetzt)
Dann bei den Attribut Beschreibungem wo heute überall Audiofile steht darf es inzwischen (wenn TTS vorhanden) auch ein Text sein.
Ich muss jetzt auch mal sehen jetzt endlich die command.ref auf diesen Stand zu bringen, die ist noch ein gutes Stück hinter dem Wiki zurück.
Hallo zusammen,
im Zusammenhang mit dem Modul 96_SIP habe ich Text2Speech eine Funktion spendiert, die Text nur umwandelt ohne den Text via Audio auszugeben. Patch ist hier zu finden: https://forum.fhem.de/index.php/topic,82745.0.html
Ansonsten echt cooles Modul! Frage zu: Wäre es noch denkbar, zukünftige komplexere Szenarien umzusetzen wie z.B. eine Menüsteuerung? Ich denke daran, dass man sich z.B. via PIN authentifiziert bevor man via weiteren Tasten dann Aktionen auslösen kann.
Edit 1: Ach so, noch eine Frage: Jemand eine Idee, wie man Text2Speech so miteinander "verheiraten" kann, dass man mitbekommt wenn eine beauftragte Textumwandlung abgeschlossen ist? Aktuell muss man ja mit sleep ein Delay einbauen, letztendlich wenn aber z.B. MP3 Dateien schon vorliegen, kann man bei einem Anruf auch sofort dran gehen.
Edit 2: Gibt es da noch irgendeinen Bug bei der Verwendung von sip_audiofile_wfp? Setze die Datei auf eine MP3 Datei (/opt/fhem/cache/fbsip.mp3) und dann kommt die Ausgabe:018.01.14 16:32:43.294 4: FBSIP, Reset Listen done
2018.01.14 16:32:43.322 4: FBSIP, Listen new PID : 11173
2018.01.14 16:32:43.333 4: FBSIP[11173], my parent is 10529
2018.01.14 16:32:43.334 4: FBSIP[11173], using Leg.pm to find a free port
2018.01.14 16:32:43.419 4: FBSIP[11173], register new expire : 2018-01-14 16:37:43
2018.01.14 16:32:43.450 4: FBSIP[11173], using /opt/fhem/cache/fbsip.alaw for audio_wfp
FHEM ist auf dem neusten Stand inkl. Neustart! Datei liegt in einem Verzeichnis, wo FHEM Berechtigungen hat drauf zu lesen.
p7
Zitat von: prodigy7 am 14 Januar 2018, 16:18:38
im Zusammenhang mit dem Modul 96_SIP habe ich Text2Speech eine Funktion spendiert, die Text nur umwandelt ohne den Text via Audio auszugeben. Patch ist hier zu finden: https://forum.fhem.de/index.php/topic,82745.0.html
kapier ich nicht , sorry aber Tobias hat damals TTS doch extra für uns geändert - ich sehe nicht was da ja jetzt neu sein soll
Zitat von: prodigy7 am 14 Januar 2018, 16:18:38
z.B. eine Menüsteuerung? Ich denke daran, dass man sich z.B. via PIN authentifiziert bevor man via weiteren Tasten dann Aktionen auslösen kann.
versteh ich auch nicht , wenn dir zwei Tasten zu wenig sind setze dtmf_size halt auf einen größeren Wert
Zitat von: prodigy7 am 14 Januar 2018, 16:18:38
Edit 1: Ach so, noch eine Frage: Jemand eine Idee, wie man Text2Speech so miteinander "verheiraten" kann, dass man mitbekommt wenn eine beauftragte Textumwandlung abgeschlossen ist? Aktuell muss man ja mit sleep ein Delay einbauen, letztendlich wenn aber z.B. MP3 Dateien schon vorliegen, kann man bei einem Anruf auch sofort dran gehen.
mit wem willst du TTS verheiraten ? das Sip Modul nutzt kein sleep oder delay sondern lässt sich via NOTIFYDEV von TT2 sagen wenn es fertig mit der Wandlung ist.
Und wenn die Datei schon im Cache vorhanden ist wird TTS gar nicht erst gefragt. Du kannst immer sofort rangehen, da der Call erst gestartet wird wenn die Sounddatei fertig als .alaw vorliegt.
Zitat von: prodigy7 am 14 Januar 2018, 16:18:38
Edit 2: Gibt es da noch irgendeinen Bug bei der Verwendung von sip_audiofile_wfp? Setze die Datei auf eine MP3 Datei (/opt/fhem/cache/fbsip.mp3)
--- snipp ---
2018.01.14 16:32:43.450 4: FBSIP[11173], using /opt/fhem/cache/fbsip.alaw for audio_wfp
Wo soll da ein Bug sein ? Gewollt ist fbsip.mp3 , abgespielt wird fbsip.alaw , also genau das was das Modul kann und mit sox oder ffmpeg aus der mp3 erzeugt wurde
Setz verbose auf 5 und du wirst es im Log ausführlich lesen können.
Zitat von: Wzut am 14 Januar 2018, 17:34:58
kapier ich nicht , sorry aber Tobias hat damals TTS doch extra für uns geändert - ich sehe nicht was da ja jetzt neu sein soll
Hab ich im entsprechenden Thread kommentiert.
Zitat von: Wzut am 14 Januar 2018, 17:34:58
versteh ich auch nicht , wenn dir zwei Tasten zu wenig sind setze dtmf_size halt auf einen größeren Wert
Ich möchte generell eine via DTMF steuerbare Menüstruktur umsetzen (wenn möglich)
Zitat von: Wzut am 14 Januar 2018, 17:34:58
mit wem willst du TTS verheiraten ? das Sip Modul nutzt kein sleep oder delay sondern lässt sich via NOTIFYDEV von TT2 sagen wenn es fertig mit der Wandlung ist.
Und wenn die Datei schon im Cache vorhanden ist wird TTS gar nicht erst gefragt. Du kannst immer sofort rangehen, da der Call erst gestartet wird wenn die Sounddatei fertig als .alaw vorliegt.
Gut, wenn die "Abhängigkeit" so umgesetzt ist, ist es ja gut. Mangels Unwissenheit an dem Punkt bin ich davon ausgegangen, dass das so nicht umgesetzt ist. Habe nur das Beispiel gesehen wo ein Sleep eingebaut war worauf meine Schlussfolgerung basiert, dass der Sleep die parallele Abarbeitung des Threads kompensieren soll.
Zitat von: Wzut am 14 Januar 2018, 17:34:58
Wo soll da ein Bug sein ? Gewollt ist fbsip.mp3 , abgespielt wird fbsip.alaw , also genau das was das Modul kann und mit sox oder ffmpeg aus der mp3 erzeugt wurde
Setz verbose auf 5 und du wirst es im Log ausführlich lesen können.
Na die Datei fbsip.mp3 ist schon vorhanden. Genau die Datei soll er auch abspielen! Oder verstehe ich an dem Punkt das Attribut falsch? Ich debugge an der Stelle nochmal, melde mich ggf. dazu nochmal.
Zitat von: prodigy7 am 14 Januar 2018, 19:32:53
Ich möchte generell eine via DTMF steuerbare Menüstruktur umsetzen (wenn möglich)
Dann viel Spaß mit dem Net::SIP-Modul. Das wird eine Herausforderung. Vermutlich wäre es hilfreich den Call über eine Asterisk-Instanz zu routen, dort zu ermitteln was man will (Stichwort Menü) und dann einen einzigen fertigen DTMF-String an den SIP-Client zu übermitteln.
Zitat von: prodigy7 am 14 Januar 2018, 19:32:53
Na die Datei fbsip.mp3 ist schon vorhanden. Genau die Datei soll er auch abspielen! Oder verstehe ich an dem Punkt das Attribut falsch? Ich debugge an der Stelle nochmal, melde mich ggf. dazu nochmal.
Net::SIP unterstützt aber nur alaw und ulaw (siehe Wik), deshalb muss on-the-fly MP3 in alaw konvertiert werden.
Zitat von: plin am 14 Januar 2018, 20:12:25
Dann viel Spaß mit dem Net::SIP-Modul. Das wird eine Herausforderung. Vermutlich wäre es hilfreich den Call über eine Asterisk-Instanz zu routen, dort zu ermitteln was man will (Stichwort Menü) und dann einen einzigen fertigen DTMF-String an den SIP-Client zu übermitteln.
Vor langer Zeit gab es mal etwas was sich DTMFBOX für die Fritz!Box, wo man einfach so etwas basteln konnte. Aktuell sind die Sourcen nicht mehr auffindbar, aber ich versuche mal ob ich den Author noch irgendwie erreichen kann. Die Software konnte echt viel und war sehr schlank programmiert. Vielleicht wäre das ja ein passendes Add-On für FHEM. Asterisk schon eine zu große Nummer....
Zitat von: plin am 14 Januar 2018, 20:12:25
Net::SIP unterstützt aber nur alaw und ulaw (siehe Wik), deshalb muss on-the-fly MP3 in alaw konvertiert werden.
Ok. Ich hatte es so aufgefasst, als würde das Modul dann on-the-fly die MP3 ins passende Format umwandeln.
Zitat von: prodigy7 am 14 Januar 2018, 20:23:11
Vor langer Zeit gab es mal etwas was sich DTMFBOX für die Fritz!Box, wo man einfach so etwas basteln konnte. Aktuell sind die Sourcen nicht mehr auffindbar, aber ich versuche mal ob ich den Author noch irgendwie erreichen kann. Die Software konnte echt viel und war sehr schlank programmiert. Vielleicht wäre das ja ein passendes Add-On für FHEM. Asterisk schon eine zu große Nummer....
Ok. Ich hatte es so aufgefasst, als würde das Modul dann on-the-fly die MP3 ins passende Format umwandeln.
Hallo,
ich habe das hier noch gefunden...
Zitat von: JoWiemann am 14 Januar 2018, 20:56:44
Hallo,
ich habe das hier noch gefunden...
cool! Habe es auch eben bei freetz gefunden gehabt. Mal schauen ob sich was damit machen lässt!
Edit: Nach einem ersten Blick würde ich mal vermuten, dass lässt sich auf aktuellen Systemen nicht mehr compilieren ohne weitere Anpassungen. Mangels ausgeprägter C/C++ Kenntnisse werde ich hier wohl nicht weiter kommen...
Zitat von: prodigy7 am 14 Januar 2018, 20:23:11
Ok. Ich hatte es so aufgefasst, als würde das Modul dann on-the-fly die MP3 ins passende Format umwandeln.
Macht es ja auch, aber wenn es im cache bereits eine umgewandelte Version gibt wird diese direkt verwendet und eine erneute Konvertierung eingespart.
Das sollte man immer im Hinterkopf behalten wenn man z.b mp3 Dateien austauscht oder verändert. D.h. ggf. die .alaw Version unbedingt im cache von Hand löschen.
Btw: es ist immer ratsam bei TTS den cache zu verwenden um so wenig wie möglich "echte" Google Anfrage zu schicken um nicht irgendwann mal "banned" zu sein ;)
Guten Morgen zusammen,
ich habe es jetzt innerhalb von 2 Wochen schon 2 mal gehabt, dass FHEM nicht mehr reagiert hat. Schau ich ins Log, scheint das SIP Modul wohl die Herrschaft an sich gerissen zu haben. Lauter
[...], register new expire : 2018-01-29 ...
Meldungen im Abstand von 150 Sekunden, ansonsten ist aber keine einzige andere Logmeldung mehr in dieser oder anderen Logdateien zu finden.
Definition in fhem.cfg sieht aktuell so aus bei mir:
define FBSIP SIP
attr FBSIP T2S_Device TTS
attr FBSIP audio_converter sox
attr FBSIP room Kommunikation | Anrufe
attr FBSIP sip_audiofile_wfp /opt/fhem/cache/fbsip.mp3
attr FBSIP sip_call_audio_delay 1.75
attr FBSIP sip_dtmf_loop once
attr FBSIP sip_dtmf_send audio
attr FBSIP sip_dtmf_size 2
attr FBSIP sip_elbc yes
attr FBSIP sip_force_interval 300
attr FBSIP sip_from sip:fhemvoip@fritz.box
attr FBSIP sip_ip 192.168.100.210
attr FBSIP sip_listen wfp
attr FBSIP sip_registrar 192.168.100.254
attr FBSIP sip_ringtime 1
attr FBSIP sip_user fhemvoip
attr FBSIP verbose 4
Nein das SIP Modul hat nicht die Herrschaft übernommen, dein FHEM Hauptprozess (Parent) hat sich wohl Schlafen gelegt. Was du im Log siehst sind die Meldungen des abgespaltenen Listen Prozesses (Child) - der lebt noch und ist erkennbar an seiner Prozess ID in den eckigen Klammern im Log :)
D.h. du wirst dich wohl oder Übel auf die Suche nach der Ursache machen müssen und nicht dem Symptom die Schuld geben.
Ich danke dir für deine Rückmeldung! Werde mal schauen - in den Zeitraum fällt die Einrichtung vom SIP Modul und ein FHEM Update, vorher lief es lange Zeit gut. Werde mich mal nach und nach durchhangeln mit Trial & Error!
Hallo zusammen,
Erstmal 1000 Dank - dies ist ein cooles Modul! Ich suche dabei eine Möglichkeit, einen begonnen Call abzubrechen. Hintergrund: Ich nutze das Modul, um ein Klingeln an der Haustür per Anruf zu signalisieren. Wenn jemand die Tür öffnet (Summer) soll das Telefon aufhören zu klingeln. Ich konnte aber keine Möglichkeit finden, einen ausgehenden Call der im Status "ringing" ist seitens FHEM zu canceln. Was habe ich übersehen?
Vielen Dank für Eure Unterstützung!
Christian
Übersehn ? -> https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden
Der Türöffner muss natürlich in FHEM verfügbar sein, dann ihn statt des im Wiki verwendeten Türkontaktes benutzen.
Ich glaube ich habe das Problem heute Morgen falsch verstanden um einen aktiven Call im Status ringing zu killen versuch mal set <name> reset
hab gerade mit dem modul eine türklingel an der fritzbox mit video snapshots auf meine c4 telefone eingerichtet. das funktioniert wunderbar.
as einzige was mich nich stört ist das die telefone klingeln. die türklingel alleine reicht aus.
scheinbar gibt es in der fritzbox keine möglichkeit den klingelton für bestimmte nebenstellen zu konfigurieren. hat vielleicht jemand eine idee?
@justme1968:
Hängt Deine Türklingel an einem der FON-Anschlüsse der Fritzbox? Bei mir ist das so. Ich kann unter Telefonie->Telefoniegeräte->Türsprechanlage für jede Klingeltaste das Verhalten konfigurieren. Unter "Klingeln weiterleiten an" habe ich "Rufgruppe" ausgewählt und die lässt sich konfigurieren.
nein. meine klingel hängt an über einen gira aktor und einem hm wired taster eingang an fhem. von dort geht es per notify und sip per voip an die fritzbox.
ich kann auch das klingel verhalten konfigurieren, aber wenn der anruf nicht an die telefone weitergeleitet wird bekomme ich ja auch kein bild.
d.h. die telefone müssen 'klingeln' ich würde aber gerne den ton und/oder die laustärke individuell einstellen. das geht aber nur für alle intern rufe auf einmal. über das telefonbuch zu gehen funktioniert auch nicht weil die internen nummern scheinbar nicht darüber gehen.
@Andre, wenn du (wie ich auch) sowieso Bilder auf das C4 schickst musst du doch auch das Ding als Türsprechanlage in der FB definiert haben ?
Denn nur bei der Türsprechanlage kannst du wie Peter schon schrieb auch den Klingeltton pro Telefon festlegen und die stehen bei mir alle auf lautlos, weil auch bei uns niemand das zusätzliche Klingeln der Telefone zur Hausklingel haben möchte -> siehe Screenshot
oh mann...
ich habe die letzte spalte mit dem klingelton aus irgend einem rund nicht gesehen. wunderbar! danke.
Hi Wzut,
Das "set NAME reset" habe ich bereits gecheckt gehabt - es führt nicht zum gewünschten Ergebnis, da der bereits begonnene Call nicht abgebrochen wird. Hat irgendwer noch weitere Ideen?
Viele Grüße,
Christian
Das hatte ich fast befürchtet, auch wenn man den Prozess killt bekommt die FB davon nicht mit und lässt es munter weiter bimmeln. D.h. z.Z gibt es nur eine Art das Klingeln zu stoppen und das ist ganz simpel "abnehmen". Wobei das nicht unbedingt ein Mensch an einem echten Telefon sein muss, es könnte auch ein anderers SIP Modul sein :)
Achtung das hat nun etwas von "durch den Rücken in die Brust weiter zum Auge ", sollte aber gehen :
a. leg dir in der FB ein zweites IP Telefon an.
b. Sorge dafür das beim Haustür klingeln eine Rufgruppe angerufen wird und das das neue IP Telefon Mitglied dieser Gruppe ist.
c. Lege in FHEM ein zweites Device an , das bekommt die Parameter des zweiten IP Telefons.
Dieses SIP Device lässt du im listen Modus wfp laufen.
Zur Funktion : Wenn es nun klingelt geht der Ruf auch beim zweiten SIP Device ein da es ja Mitglied der Gruppe ist.
Da dieses zweite Device im Modus wfp läuft lauert es nur darauf das Kommando fetch zu empfangen. D.h. sorge nun dafür das wenn jemand den Summer drückt das FHEM dem zweiten SIP Device das fetch Kommando schickt. Dadurch das dieses Device den Ruf annimmt verstummen alle anderen Telefone der Gruppe :)
(siehe dazu auch im Wiki das Beispiel von plin zu wfp )
Hallo,
erstmal vielen Dank für das tolle Modul. Ich habe ein super funktionierendes SIP Device mit meiner Fritzbox.
Jetzt möchte ich ein Zweites mit Sipgate verwenden. Ich habe die entsprechenden Attribute eingetragen. Statt dem Fritzphone Benutzername eben den Sipgate-Benutzernamename usw. Registrar: sipgate.de. Der Standardport sollte mit sipgate auch gehen. Der wird in einer Konfig Anleitung von Sipgate auch verwendet. Leider funktioniert es nicht. Er startet den call und geht in den call_state: "Invite" über und dann passiert nichts. Keine Fehlermeldung oder ähnliches. Die sip_ip steht noch auf der lokalen ip meines Pis, ist das vielleicht das Problem?
Hat es bei Jemand mit sipgate schon funktioniert?
Viele Grüße
Cyzicos
Zitat von: Cyzicos am 14 Februar 2018, 19:20:49
Die sip_ip steht noch auf der lokalen ip meines Pis, ist das vielleicht das Problem?
An der Stelle vermute ich dein Problem, trage da mal deine öffentliche IP ein und sorge mit einer Regel auf der FB dafür das von aussen ankommender Trafic auf deinem verwendetem SIP Port auch 1:1 wieder auf dem Raspi landen.
Stichwort ist STUN Server, (hatten wir hier IMHO schon mal) allerdings wird das STUN Protokoll nicht von Net::SIP unterstützt.
Zitat von: Cyzicos am 14 Februar 2018, 19:20:49
Hat es bei Jemand mit sipgate schon funktioniert?
grundsätzlich sollte es mit sipgate funktionieren.
bis vor kurzem habe ich mich über sipgate quasi von ausserhalb kurz selbst angerufen, damit die fritzfons rot blinken. dazu hatte ich allerdings noch das vorgängermodul laufen.
edit:
hierzu habe ich aber erst in der fritzbox eine sip-rufnummer mit zugangsdaten von sipgate angelegt. dann ein sipgerät in der fritzbox eingerichtet, dass die sipgate rufnummer benutzt. und zuletzt das sipdevice in fhem, welches die zugangsdaten des fritzbox-sip-gerätes hatte.
keine ahnung, ob das den normalen regeln entspricht, aber so lief es sehr lange.
Hallo,
Ich habe dein Modul auch Installiert leider funktioniert es nicht, bekommen den Error : CallRegister: Failed with error 113.
Gib es zu den Meldungen auch eine Liste mit Erklärungen .
Ich habe Device schon mehrere male neu angelegt weil ich dachte das es Falsch konfiguriert ist.
Anbei meine Raw: defmod FhemPhone SIP
attr FhemPhone room Fritzbox
attr FhemPhone sip_dtmf_loop once
attr FhemPhone sip_dtmf_send audio
attr FhemPhone sip_dtmf_size 2
attr FhemPhone sip_elbc yes
attr FhemPhone sip_from MySipPhone:620@fritz.box
attr FhemPhone sip_ip [FhemServerIP]
attr FhemPhone sip_listen none
attr FhemPhone sip_registrar fritz.box
attr FhemPhone sip_ringtime 3
attr FhemPhone sip_user MySipPhone
setstate FhemPhone initialized
setstate FhemPhone 2018-03-07 20:45:59 call done
setstate FhemPhone 2018-03-07 20:45:59 call_attempt 0
setstate FhemPhone 2018-03-07 20:45:59 call_state fail
setstate FhemPhone 2018-03-07 20:45:59 call_success 0
setstate FhemPhone 2018-03-07 20:45:59 call_time 0
setstate FhemPhone 2018-03-07 20:45:59 last_error CallRegister: Failed with error 113
setstate FhemPhone 2018-03-07 20:28:03 listen_alive no
setstate FhemPhone 2018-03-07 20:45:59 state initialized
Kann mit da mal Bitte jemand unter die Arme greifen.
Gruß
Zitat von: Pusemukel am 07 März 2018, 21:01:06
Hallo,
Ich habe dein Modul auch Installiert leider funktioniert es nicht, bekommen den Error : CallRegister: Failed with error 113.
Gib es zu den Meldungen auch eine Liste mit Erklärungen .
Ich habe Device schon mehrere male neu angelegt weil ich dachte das es Falsch konfiguriert ist.
Anbei meine Raw: defmod FhemPhone SIP
attr FhemPhone room Fritzbox
attr FhemPhone sip_dtmf_loop once
attr FhemPhone sip_dtmf_send audio
attr FhemPhone sip_dtmf_size 2
attr FhemPhone sip_elbc yes
attr FhemPhone sip_from MySipPhone:620@fritz.box
attr FhemPhone sip_ip [FhemServerIP]
attr FhemPhone sip_listen none
attr FhemPhone sip_registrar fritz.box
attr FhemPhone sip_ringtime 3
attr FhemPhone sip_user MySipPhone
setstate FhemPhone initialized
setstate FhemPhone 2018-03-07 20:45:59 call done
setstate FhemPhone 2018-03-07 20:45:59 call_attempt 0
setstate FhemPhone 2018-03-07 20:45:59 call_state fail
setstate FhemPhone 2018-03-07 20:45:59 call_success 0
setstate FhemPhone 2018-03-07 20:45:59 call_time 0
setstate FhemPhone 2018-03-07 20:45:59 last_error CallRegister: Failed with error 113
setstate FhemPhone 2018-03-07 20:28:03 listen_alive no
setstate FhemPhone 2018-03-07 20:45:59 state initialized
Kann mit da mal Bitte jemand unter die Arme greifen.
Gruß
Hallo,
hast Du alle Abhängigkeiten, siehe Wiki, Installiert? Z.B. libnet-sip-perl.
Gesendet von iPhone mit Tapatalk
Grüße Jörg
Hallo,
ja habe ich bzw. mir ist beim erneuten "nachinstallieren" zu überprüfen aufgefallen das ich eine Fehlermeldung bei/nach der instalation über den
Befehl:
sudo cpan install Net::SIP
Der Befehl wurde als User root auf einem Ubuntu-server ausgeführt mit folgendem Ergebnis.
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN.pm requires configuration, but most of it can be done automatically.
If you answer 'no' below, you will enter an interactive dialog for each
configuration option instead.
Would you like to configure as much as possible automatically? [yes] yes
Fetching with LWP:
http://www.cpan.org/authors/01mailrc.txt.gz
Reading '/root/.cpan/sources/authors/01mailrc.txt.gz'
............................................................................DONE
Fetching with LWP:
http://www.cpan.org/modules/02packages.details.txt.gz
Reading '/root/.cpan/sources/modules/02packages.details.txt.gz'
Database was generated on Wed, 07 Mar 2018 19:17:03 GMT
.............
New CPAN.pm version (v2.16) available.
[Currently running version is v2.11]
You might want to try
install CPAN
reload cpan
to both upgrade CPAN.pm and run the new version without leaving
the current session.
...............................................................DONE
Fetching with LWP:
http://www.cpan.org/modules/03modlist.data.gz
Reading '/root/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /root/.cpan/Metadata
Running install for module 'Net::SIP'
Fetching with LWP:
http://www.cpan.org/authors/id/S/SU/SULLR/Net-SIP-0.814.tar.gz
Fetching with LWP:
http://www.cpan.org/authors/id/S/SU/SULLR/CHECKSUMS
Checksum for /root/.cpan/sources/authors/id/S/SU/SULLR/Net-SIP-0.814.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring S/SU/SULLR/Net-SIP-0.814.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::SIP
Writing MYMETA.yml and MYMETA.json
SULLR/Net-SIP-0.814.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for S/SU/SULLR/Net-SIP-0.814.tar.gz
SULLR/Net-SIP-0.814.tar.gz
make -- NOT OK <--------------------------------------------------Hier meine ich
root@FhemNUC:/home/xxxxxxxx#
Wo liegt der Fehler ?!
Gruß
CPAN muss nicht sein i.d.R. reicht ein sudo apt-get install libnet-sip-perl völlig aus.
attr FhemPhone sip_from MySipPhone:620@fritz.box
Der User in der FB ist wirklich "MySipPhone:620" ?? oder doch eher "MySipPhone" und hat nur die interne Rufnummer 620 ?
https://wiki.fhem.de/wiki/SIP-Client hast du gelesen ?
Zitatsip_from
Meine SIP-Client-Info. Default ist sip:620@fritz.box für ältere Fritz!OS-Versionen. Ab 6.8 ist das Format sip:Benutzername@fritz.box.
Keine Ahnung welche FW auf deiner Fritte ist , aber ab 6.8 wäre das dann bei dir eher sip_from sip:MySipPhone@fritz.box
Hallo,
@ Wzut
ich hab beides schon probiert die Syntax für die 6.8Ver. und die "alte". Meine Fritze ist 6.83 sollte also mit
attr FhemPhone sip_from MySipPhone:@fritz.box
funktionieren oder ?!
Ja gelesen hab ich den Wiki Artikel , dabei fällt mich gerade auf?
was genau ist damit gemeint ?!
ZitatSIP-Server:
Der SIP-Client muss sich an einem SIP-Server anmelden (Fritzbox, Asterisk, VoIP-Provider). Auf dem SIP-Server, mit dem sich der Client verbinden soll, muss ein User-Account vorhanden sein bzw. angelegt werden.
Welcher User-Account also-->
1. "Richtiger" Box Account mit dem ich mich auch über WEB/LAN bei meiner Fritze anmelden kann
oder
2. Dieser Account der erstellt wird, wenn ich ein neues IP-Telefon angelegt habe
bzw. ich Probier es gleich einfach mal aus 8)
Gruß
Meine FB hat die Version 6.92 und ich nutze folgende Attribute
Attributes:
room SIP
sip_audiofile_dtmf /tmp/myaudio.araw
sip_audiofile_wfp /opt/fhem/MomentBitteMichael.alaw
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsipt@fritz.box
sip_ip 192.168.3.40
sip_listen none
sip_port 5070
sip_registrar 192.168.3.1
sip_ringtime 5
sip_user fhemsipt
fhemsipt taucht auch in meiner User-Liste auf (System->FB-Benutzer).
So gerade getestet,
also ich hatte eien User als "Systemuser" in der Fritze angelegt habe daraufhin noch mal das Password neu gesetzt Fritze/Fhem
dann das ganze noch mal mir einem 8 stelligen Password (keine Sonderzeichen) jedes mal immer error 113.
die Syntax von: dem attribut sip_from einmal mit
Zitatattr FhemPhone sip_from MySipPhone:620@fritz.box
.
Zitatattr FhemPhone sip_from MySipPhone:@fritz.box
geprüft.
Dann nocheinmal überprüft ob was fehlt: sudo apt-get install libnet-sip-perl
alles vorhanden.
defmod FhemPhone SIP
attr FhemPhone room Fritzbox
attr FhemPhone sip_dtmf_loop once
attr FhemPhone sip_dtmf_send audio
attr FhemPhone sip_dtmf_size 2
attr FhemPhone sip_elbc yes
attr FhemPhone sip_from MySipPhone@fritz.box
attr FhemPhone sip_ip 192.168.xxx.xxx <----------Hier die Ip meines Fhem Servers,richtig ?
attr FhemPhone sip_listen wfp
attr FhemPhone sip_registrar fritz.box
attr FhemPhone sip_user MySipPhone
setstate FhemPhone error
setstate FhemPhone 2018-03-08 20:20:17 call done
setstate FhemPhone 2018-03-08 20:20:17 call_attempt 0
setstate FhemPhone 2018-03-08 20:20:17 call_state fail
setstate FhemPhone 2018-03-08 20:20:17 call_success 0
setstate FhemPhone 2018-03-08 20:20:17 call_time 0
setstate FhemPhone 2018-03-08 20:49:52 last_error ListenRegister: Failed with error 113 <------------------ Hier
setstate FhemPhone 2018-03-08 20:49:52 listen_alive no
setstate FhemPhone 2018-03-08 20:49:52 state error
Jemand eine Idee was dieser error 113 bedeutet?
Gruß
Im attr sip_from fehlt das sip:
Zitat von: Wzut am 08 März 2018, 07:29:13
wäre das dann bei dir eher sip_from sip:MySipPhone@fritz.box
einfach meinen Rat befolgen ....
Hallo,
Kaum macht man es Richtig funktioniert es.
Ursache war tatsächlich das ich das sip: nicht vor dem MySipPhone@fritz.box geschrieben hatte.
Habe ich tatsächlich mehrere male überlesen.... :-[
Danke für die Hilfe
Hallo zusammen,
ist es möglich das "dtmf_event" zurück zu setzen? ich würde es gern auswerten, bzw. eine Aktion auslösen, sofern ich eine zweistellige Zahl in meinem Anruf mit # übermittle, aber der Wert bleibt im Reading erhalten und löst somit immer aus.
Wenn ich keine Möglichkeit habe dieses Reading zurückzusetzen oder mit einer anderen Zahl zu überschreiben, bringt mir dtmf herzlich wenig.
Danke und Gruß
Adrian
du musst einfach mit events arbeiten und nicht mit zuständen. egal ob mit notify oder doif.
Hatte ich eigentlich gemacht mit folgender Befehlszeile
[SIP_PHONE:dtmf_events] eq "55"
Wenn das Reading aber aus dem letzten Anruf noch den Wert beinhaltet, dann reagiert meine Schaltung noch bevor ich den #-Code eingegeben habe.
nein, du vergleichst hier den zustand eines readings mit einer zahl.
define n_dtmf notify SIP_PHONE.dtmf_event:.55 set lamp toggle
bei jedem erkennen der dtmfeingabe #55 toggelt die lampe.
Zitat von: frank am 06 April 2018, 00:12:29
bei jedem erkennen der dtmfeingabe #55 toggelt die lampe.
jein ...
a. ist
55 nicht zulässig (siehe Wiki) aber 45 oder 56 sollte gehen
b. hängt der Erfolg natürlich noch davon ab wie die ganzen event-on Attribute am SIP Device selbst vorbelegt sind
Moin,
möchte das tolle Modul nutzen um in meiner eingspeicherten Abwesenheit einen Rufnummernbefehl an meine Telefonanlage zu setzen die meine Türklingel auf Handy umschaltet... Soweit ich das hier sehe müsste das gehen, leider kriege ich das Modul nicht zum laufen.
Die entsprechenden PERL Pakete wurden problemlos installiert.
Setze ich einen Testanruf ab "Set Fritz_SIP Call 0123 45678" kommt immer:
CallRegister: Failed with code 401
als Rückmeldung.
Meine ATTR:
define FRITZ_SIP SIP
attr FRITZ_SIP sip_dtmf_loop once
attr FRITZ_SIP sip_dtmf_send audio
attr FRITZ_SIP sip_dtmf_size 2
attr FRITZ_SIP sip_elbc yes
attr FRITZ_SIP sip_from sip:Andre0909@fritz.box
attr FRITZ_SIP sip_ip 192.168.178.33
attr FRITZ_SIP sip_listen none
attr FRITZ_SIP sip_port 5070
attr FRITZ_SIP sip_registrar 192.168.178.1
attr FRITZ_SIP sip_ringtime 3
attr FRITZ_SIP sip_user 622
Mein Fritzboxanmeldename ist: "Fritzanmeldename"
Das WLAN Telefon (*622) ist angemeldet mit "Andre0909" und "Passwort"
Mit set habe ich das "PAsswort" gesetzt.
192.168.178.1 ist meine Fritzbox. .33 FHEM. fritz.box erreicht ebenfalls meine box.
Box ist eine 7490 mit aktuellster Firmware.
Was mache ich falsch?
Internals:
.oldstate initialized
.reset 0
NAME FRITZ_SIP
NOTIFYDEV global
NR 1014
NTFY_ORDER 50-FRITZ_SIP
STATE initialized
TYPE SIP
VERSION V1.76 / 08.01.18
.attraggr:
.attrminint:
READINGS:
2018-04-29 14:08:06 call done
2018-04-29 14:08:06 call_attempt 0
2018-04-29 14:08:06 call_state fail
2018-04-29 14:08:06 call_success 0
2018-04-29 14:08:06 call_time 0
2018-04-29 14:08:06 last_error CallRegister: Failed with code 401
2018-04-29 13:40:38 listen_alive no
2018-04-29 14:08:06 state initialized
Der 401er bedeutet "unauthorized" (siehe https://de.wikipedia.org/wiki/SIP-Status-Codes).
Dein "Passwort" hat zwar 8 Stellen, aber wurde es von der FritzBox auch als "gut" bewertet (siehe https://wiki.fhem.de/wiki/SIP-Client, Abschnitt "SIP-Server")?
Zitat von: plin am 29 April 2018, 14:13:15
Der 401er bedeutet "unauthorized" (siehe https://de.wikipedia.org/wiki/SIP-Status-Codes).
Dein "Passwort" hat zwar 8 Stellen, aber wurde es von der FritzBox auch als "gut" bewertet (siehe https://wiki.fhem.de/wiki/SIP-Client, Abschnitt "SIP-Server")?
Hatte nur "mittel". Habe ein Sonderzeichen zugefügt jetzt ist es 9 stellig mit "gut".
Neu gesetzt im Device.
Neuer Call, selbes Problem :(
Set mal den sip_user auf Andre0909
Zitat von: plin am 29 April 2018, 14:36:55
Set mal den sip_user auf Andre0909
JAP, das war es . Funzt! Vielen Dank
hab aber noch eine Frage. :)
Möchte folgenenden Ruf abgeben:
**1 *3*1#
warum? Mein Gira TK Gateway schaltet damit eine Rufumleitung der Klingel auf das Handy um. Zeitgesteuert durch FHEM.
Problem. Nach *11 muss erst 2 sekunden der Bestätigungscode abgewartet werden, danach erst *3*1# gewählt werden. Kann man eine Art Pause einfügen?
Würde z.B. funktionieren:
**1 -3*1#
?
Ich würde es mal mit Kommas statt blank probieren. Lt. Doku https://github.com/noxxi/p5-net-sip/blob/master/tools/generate-dtmf.pl müsste alles was nicht DTMF ist als Pause interpretiert werden.
Könnt ihr bitte mal ausprobieren, ob der simple Befehl
set SIP call [Telefonnummer] 30 !Achtung
bei Euch funktioniert?! Ich meine, wirklich nur mit dem Wort "Achtung"
Kein Witz: Hier funktioniert alles, ich kann ganze Romane eingeben, das wird alles korrekt vorgelesen. Nur das Wort "Achtung" darf nicht drin sein, dann gibt es im Verzeichnis "fhem/Cache/" keine *.alaw Datei (wohl aber die *.mp3!) und ich bekomme nur die DTMF-Töne zu hören. Die Fehlermeldung (reading last_error unter SIP) lautet: "audio file Achtung not found"
Mystisch ...
Lustig ... geht bei mir auch nicht. Allerdings schafft verbose 5 da etwas mehr Klarheit :
sox : /usr/bin/sox WARN rate: rate clipped 1 samples; decrease volume?
Was auch immer sox da an dem mp3 File auszusetzen hat :(
Bzw. das würde eigentlich bedeuten das Google da schon Mist zurückliefert ? Werde mich die Tage wohl mal näher damit beschäftigen müssen.
Hallo zusammen,
vorab erst mal ein großes Lob für das Modul und habe großen Respekt vor eurer Arbeit, Energie und Know How die dafür investiert wurde.
Das Modul funktioniert bestens solange ich meine Firewall (fail2ban) auf meinen Raspi 2 abgeschaltet habe.
Sobald ich jedoch die Firewall aktiviere werden keine DTMF-Töne mehr übertragen. Anrufen mit dem Modul funktioniert ohne Probleme, es werden eben keine Töne übertragen.
Die Ports TCP 5060 und UDP 5060 sowie TCP/UDP 53, 80 und weitere sind freigeschaltet.
Da bisher ohne Firewall alles problemlos klappte vermute ich (nach einigen Stunden rätseln und probieren), dass ich noch weitere ports öffnen sollte.
Kurz: Welche Ports TCP/UDP muss ich in der Firewall freischalten, damit ich auch mit aktivierter Firewall das Modul DTMF Töne senden kann?
Für Tipps bin ich sehr dankbar.
Mit Verbose 5 erhalte ich folgende log..
2018.05.16 23:23:31 4: Raspi_SIP, calling **611, ringtime: 30 , no message
2018.05.16 23:23:31 4: Raspi_SIP, Raspi_SIP|**611|30||0
2018.05.16 23:23:31 4: Raspi_SIP, call -> Raspi_SIP|**611|30||0|0
2018.05.16 23:23:31 5: Raspi_SIP, call has pid 2577
2018.05.16 23:23:31 4: Raspi_SIP[2577], my parent is 30280
2018.05.16 23:23:31 4: Raspi_SIP[2577], using Leg.pm to find a free port
2018.05.16 23:23:31 4: Raspi_SIP[2577], register new expire : 2018-05-16 23:28:31
2018.05.16 23:23:31 5: Raspi_SIP, readingS:state Val:calling
2018.05.16 23:23:31 4: Raspi_SIP[2577], CallStart DTMF : ABCD*#123--4567890
2018.05.16 23:23:31 4: Raspi_SIP[2577], calling : **611
2018.05.16 23:23:31 5: Raspi_SIP, readingS:call_state Val:calling **611
2018.05.16 23:23:32 4: Raspi_SIP[2577], cb_final - status : FAIL - final : 481
2018.05.16 23:23:32 5: Raspi_SIP, readingS:call_state Val:ringing
2018.05.16 23:23:37 4: Raspi_SIP[2577], cb_final - Status : OK
2018.05.16 23:23:37 4: Raspi_SIP[2577], call established
2018.05.16 23:23:37 5: Raspi_SIP, readingS:call_state Val:established
2018.05.16 23:24:01 5: Raspi_SIP[2577], 0. Ende des ersten Loops
2018.05.16 23:24:01 5: Raspi_SIP[2577], 1. rtp_done : 0
2018.05.16 23:24:01 5: Raspi_SIP[2577], 2. fi : 0
2018.05.16 23:24:01 5: Raspi_SIP[2577], 4. timeout : 1
2018.05.16 23:24:01 5: Raspi_SIP[2577], 6. call_established : 1
2018.05.16 23:24:01 5: Raspi_SIP[2577], call->bye
2018.05.16 23:24:01 1: PERL WARNING: Use of uninitialized value in subroutine entry at /usr/share/perl5/Net/SIP/Endpoint/Context.pm line 80. ----> DIESE Fehlermeldung kommt nicht immer
2018.05.16 23:24:01 1: PERL WARNING: Use of uninitialized value $uri in pattern match (m//) at /usr/share/perl5/Net/SIP/Endpoint/Context.pm line 180. ----> DIESE Fehlermeldung kommt nicht immer
2018.05.16 23:24:01 5: Raspi_SIP[2577], RTP done : 0 ---> ohne Firewall erscheint hier "OK"
2018.05.16 23:24:01 5: Raspi_SIP[2577], Timeout : 1
2018.05.16 23:24:01 5: Raspi_SIP[2577], while : 0
2018.05.16 23:24:01 4: Raspi_SIP, CALLDone -> Raspi_SIP|1|timeout
2018.05.16 23:24:01 5: Raspi_SIP, fifo is empty
2018.05.16 23:24:01 5: Raspi_SIP, no elbc
Für Tipps bin ich sehr dankbar.
Grüße
Martin
Der default Port 5060 wird verwendet für den Verbindungsaufbau - das scheint bei dir OK zu sein.
Via UDP/RTP werden die Töne bzw. das Gespäch übertragen. Google mal nach RTP Ports , da findet man so einiges zu. Intressant ist das hier oft eine große Range verwendet wird ( 20 - 40 Ports) und das auf dynamischen Ports > 1024 - 65535. Ich habe jetzt mal auf die Schnelle im Net::SIP Paket gesucht und werde an einer Stelle fündig :
/usr/share/perl5/Net/SIP/Util.pm
Util.pm:our $RTP_MIN_PORT = 2000;
Util.pm:our $RTP_MAX_PORT = 12000;
Versuch doch mal our $RTP_MAX_PORT = 2019; und gib diese 20 Ports auf UDP in der Firewall frei.
PERFEKT!
Das war's. Bin von dem Modul und dem raschen Service begeistert.
Vielen Dank
Bei mir fehlt das reading DTMF trotz mehrfacher Resets und FHEM-Neustarts.
Die Anrufe werden in allen sip-listen Modi angenommen (WFP, DTMF,...)
Was kann ich noch tun?
a. ein list von deinem SIP Device und b. ein Logauszug mit verbose 5 posten
Edit : Ich setze natürlich vorraus das https://wiki.fhem.de/wiki/SIP-Client gelesen wurde !
Ich habe in letzter Zeit massive Probleme mit fhem Abstürzen. So ca. 10-15 mal täglich.
Dabei gibt es dann immer folgenden Eintrag im fhem.log
- SIP_Client[7150], can´t find my parent 7126 in process list !
- Died at ./FHEM/96_SIP.pm line 371.
Habe auch FHEM schon komplett neu aufgesetz auf einem neuen Raspi 3. Ohne Verbesserung.
Wo kann ich jetzt ansetzten. ? Liegt es überhaupt am SIP_Client Modul oder am meiner Fritz-Box ? (7560).
Hat jemand noch einen Tipp für mich ?
Gruß Markus aus Dortmund
wir brauchen den üblichen Input
- output von list <deinsipdevice> hier posten
- Das SIP-Device auf verbose 5 setzen
- Nach dem nächsten Absturz einen log-Auszug mit den letzten Zeilen vor dem Absturz posten
Zitat von: SELVE-Elektronik-Entwicklung am 29 Mai 2018, 18:13:14
Dabei gibt es dann immer folgenden Eintrag im fhem.log
- SIP_Client[7150], can´t find my parent 7126 in process list !
- Died at ./FHEM/96_SIP.pm line 371.
Die Meldungen sind nicht die Ursache deiner Abstürze sondern lediglich die Reaktion darauf.
Unter Linux werden Kinder (Listen Prozess) ohne lebende Eltern (FHEM Hauptprozess) zu Zombies.
Um dies zu verhindern müssen die Kinder unbedingt auch sterben, genau das sagen die beiden Log Zeilen -> Eltern nicht gefunden und Kindchen Ruhe sanft.
D.h. du must deine Aufmerksamkeit unbedingt auf die Ereignisse unmittelbar davor lenken.
Da fällt mir noch ein :
Welches System nutzt du und gibt es da den Befehl ps ?
Nicht das du da wegen fehlendem ps in die gleiche Falle wie hier -> https://forum.fhem.de/index.php/topic,18517.msg804889.html#msg804889 tapst.
Ich versuche auch gerade meine Fritzbox zum telefonieren zu bekommen, bekomme aber momentan den Fehler
2018.06.20 23:07:24 5: FritzFonSIP, MD5: Hallo, hier spricht FHEM -> e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.20 23:07:24 5: FritzFonSIP, set call new -> FritzFonSIP call sip:**624\@fritz.box 30 cache/e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.20 23:07:25 4: FritzFonSIP, audio file cache/e64926f23393ab9d341b9ccdac59c0b7.mp3 found
2018.06.20 23:07:25 5: FritzFonSIP, not converted - using cache/e64926f23393ab9d341b9ccdac59c0b7.alaw from cache
2018.06.20 23:07:25 4: FritzFonSIP, FritzFonSIP|sip:**624\@fritz.box|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0
2018.06.20 23:07:25 4: FritzFonSIP, call -> FritzFonSIP|sip:**624\@fritz.box|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0|0
2018.06.20 23:07:25 5: FritzFonSIP, call has pid 31225
2018.06.20 23:07:25 4: FritzFonSIP[31225], my parent is 31034
2018.06.20 23:07:25 4: FritzFonSIP[31225], trying to use port 5080
2018.06.20 23:07:25 4: FritzFonSIP, CALLDone -> FritzFonSIP|0|CallRegister: Failed with code 404
2018.06.20 23:07:25 5: FritzFonSIP, fifo is empty
2018.06.20 23:07:25 5: FritzFonSIP, no elbc
Internals:
.oldstate initialized
.reset 0
AC /usr/bin/sox
NAME FritzFonSIP
NOTIFYDEV TextToSpeech
NR 437
NTFY_ORDER 50-FritzFonSIP
STATE initialized
TYPE SIP
VERSION V1.76 / 08.01.18
.attraggr:
.attrminint:
READINGS:
2018-06-20 22:46:08 call done
2018-06-20 22:46:08 call_attempt 0
2018-06-20 22:46:08 call_state fail
2018-06-20 22:46:08 call_success 0
2018-06-20 22:46:08 call_time 0
2018-06-20 22:46:08 last_error CallRegister: Failed with code 404
2018-06-20 22:31:11 listen_alive no
2018-06-20 22:46:08 state initialized
helper:
Attributes:
T2S_Device TextToSpeech
audio_converter sox
room System
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:625@fritz.box
sip_ip 192.168.178.111
sip_listen none
sip_port 5070
sip_registrar fritz.box
sip_ringtime 3
sip_user 625
verbose 5
Der Benutzername, den ich in der Fritzbox angelegt habe, lautet "fhemsipfon". Aber auch mit diesem als sip_user funktioniert es nicht. Was genau muss ich als sip_user angeben? Die interne Durchwahl dieses Telefons ist **625.
192.168.178.111 ist die IP meines FHEM Servers.
Ich versuche dann mittels
set FritzFonSIP call sip:**624\@fritz.box 30 !Hallo, hier spricht FHEM
einen TTS Text an mein Handy, welches über die Durchwahl **624 erreichbar ist, zu schicken.
Jemand einen Tipp für mich, was ich falsche mache?
Gruß,
Tim
Zitat von: Cruiser79 am 20 Juni 2018, 23:09:35
Ich versuche dann mittels
set FritzFonSIP call sip:**624\@fritz.box 30 !Hallo, hier spricht FHEM
nein, nein
set FritzFonSIP call **624 30 !Hallo, hier spricht FHEM
Zitat von: Wzut am 21 Juni 2018, 17:54:03
nein, nein
set FritzFonSIP call **624 30 !Hallo, hier spricht FHEM
Das bringt die gleiche Fehlermeldung hervor
2018.06.21 21:59:53 5: FritzFonSIP, MD5: Hallo, hier spricht FHEM -> e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.21 21:59:53 5: FritzFonSIP, set call new -> FritzFonSIP call **624 30 cache/e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.21 21:59:53 4: FritzFonSIP, audio file cache/e64926f23393ab9d341b9ccdac59c0b7.mp3 found
2018.06.21 21:59:53 5: FritzFonSIP, not converted - using cache/e64926f23393ab9d341b9ccdac59c0b7.alaw from cache
2018.06.21 21:59:53 4: FritzFonSIP, FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0
2018.06.21 21:59:53 4: FritzFonSIP, call -> FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0|0
2018.06.21 21:59:53 5: FritzFonSIP, call has pid 2289
2018.06.21 21:59:53 4: FritzFonSIP[2289], my parent is 31034
2018.06.21 21:59:53 4: FritzFonSIP[2289], trying to use port 5080
2018.06.21 21:59:53 4: FritzFonSIP, CALLDone -> FritzFonSIP|0|CallRegister: Failed with code 404
2018.06.21 21:59:53 5: FritzFonSIP, fifo is empty
2018.06.21 21:59:53 5: FritzFonSIP, no elbc
Zitat von: Cruiser79 am 20 Juni 2018, 23:09:35
Der Benutzername, den ich in der Fritzbox angelegt habe, lautet "fhemsipfon". Aber auch mit diesem als sip_user funktioniert es nicht.
der fhemsipfon muss aber ins Attribut sip_user wenn er so in der FB angelgt wurde. Wichtig ist auch das die FB das Passwort des Users als "stark" einstuft.
Beim Attribut sip_registrar würde ich "fritz.box" auch noch gegen die echte IP der FB ersetzen da laut https://de.wikipedia.org/wiki/SIP-Status-Codes
der 404 bedeutet :
ZitatDie Gegenstelle wurde nicht gefunden oder existiert nicht
Edit :
du nutzt auch sip_port 5070 , hat diese Wahl einen besonderen Grund ? Wenn nein lösche das Attribut und überlasse es Leg.pm einen freien Port zu finden.
Mist, immer noch kein Erfolg. Es bleibt beim 404
2018.06.22 22:20:48 5: FritzFonSIP, MD5: Hallo, hier spricht FHEM -> e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.22 22:20:48 5: FritzFonSIP, set call new -> FritzFonSIP call **624 30 cache/e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.22 22:20:48 4: FritzFonSIP, audio file cache/e64926f23393ab9d341b9ccdac59c0b7.mp3 found
2018.06.22 22:20:48 5: FritzFonSIP, not converted - using cache/e64926f23393ab9d341b9ccdac59c0b7.alaw from cache
2018.06.22 22:20:48 4: FritzFonSIP, FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0
2018.06.22 22:20:48 4: FritzFonSIP, call -> FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0|0
2018.06.22 22:20:48 5: FritzFonSIP, call has pid 6134
2018.06.22 22:20:48 4: FritzFonSIP[6134], my parent is 31034
2018.06.22 22:20:48 4: FritzFonSIP[6134], using Leg.pm to find a free port
2018.06.22 22:20:49 4: FritzFonSIP, CALLDone -> FritzFonSIP|0|CallRegister: Failed with code 404
2018.06.22 22:20:49 5: FritzFonSIP, fifo is empty
2018.06.22 22:20:49 5: FritzFonSIP, no elbc
Trotz Umstellung auf "fhemsipfon". Passwort war "stark", Registrator auf die IP der Fritzbox geändert und ich habe auch nochmal versucht in sip_from "sip:FHEM@fritz.box" einzutragen, weil der SIP User in meiner Fritzbox FHEM heisst. Bringt leider auch nix.
Momentan sieht es so aus
{
"Arg":"FritzFonSIP",
"Results": [
{
"Name":"FritzFonSIP",
"PossibleSets":"call fetch:noArg listen:noArg password reject:noArg reset:noArg",
"PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 sip_watch_listen sip_ringtime sip_waittime sip_ip sip_port sip_user sip_registrar sip_from sip_call_audio_delay:0,0.25,0.5,0.75,1,1.25,1.5,1.75,2,2.25,2.5,2.75,3 sip_audiofile_call sip_audiofile_dtmf sip_audiofile_ok sip_audiofile_wfp sip_dtmf_size:1,2,3,4 sip_dtmf_send:audio,rfc2833 sip_dtmf_loop:once,loop sip_listen:none,dtmf,wfp,echo sip_filter sip_blocking sip_elbc:yes,no sip_force_interval sip_force_max T2S_Device T2S_Timeout audio_converter:sox,ffmpeg disabled:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr",
"Internals": {
".oldstate": "initialized",
".reset": "0",
"AC": "/usr/bin/sox",
"NAME": "FritzFonSIP",
"NOTIFYDEV": "TextToSpeech",
"NR": "437",
"NTFY_ORDER": "50-FritzFonSIP",
"STATE": "initialized",
"TYPE": "SIP",
"VERSION": "V1.76 / 08.01.18"
},
"Readings": {
"call": { "Value":"done", "Time":"2018-06-22 22:23:43" },
"call_attempt": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"call_state": { "Value":"fail", "Time":"2018-06-22 22:23:43" },
"call_success": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"call_time": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"last_error": { "Value":"CallRegister: Failed with code 404", "Time":"2018-06-22 22:23:43" },
"listen_alive": { "Value":"no", "Time":"2018-06-20 22:31:11" },
"state": { "Value":"initialized", "Time":"2018-06-22 22:23:43" }
},
"Attributes": {
"T2S_Device": "TextToSpeech",
"audio_converter": "sox",
"room": "System",
"sip_dtmf_loop": "once",
"sip_dtmf_send": "audio",
"sip_dtmf_size": "2",
"sip_elbc": "yes",
"sip_from": "sip:FHEM@fritz.box",
"sip_ip": "192.168.178.111",
"sip_listen": "none",
"sip_registrar": "192.168.178.1",
"sip_ringtime": "3",
"sip_user": "fhemsipfon",
"verbose": "5"
}
} ],
"totalResultsReturned":1
}
Zitat von: Cruiser79 am 22 Juni 2018, 22:28:22
Mist, immer noch kein Erfolg. Es bleibt beim 404
2018.06.22 22:20:48 5: FritzFonSIP, MD5: Hallo, hier spricht FHEM -> e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.22 22:20:48 5: FritzFonSIP, set call new -> FritzFonSIP call **624 30 cache/e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.22 22:20:48 4: FritzFonSIP, audio file cache/e64926f23393ab9d341b9ccdac59c0b7.mp3 found
2018.06.22 22:20:48 5: FritzFonSIP, not converted - using cache/e64926f23393ab9d341b9ccdac59c0b7.alaw from cache
2018.06.22 22:20:48 4: FritzFonSIP, FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0
2018.06.22 22:20:48 4: FritzFonSIP, call -> FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0|0
2018.06.22 22:20:48 5: FritzFonSIP, call has pid 6134
2018.06.22 22:20:48 4: FritzFonSIP[6134], my parent is 31034
2018.06.22 22:20:48 4: FritzFonSIP[6134], using Leg.pm to find a free port
2018.06.22 22:20:49 4: FritzFonSIP, CALLDone -> FritzFonSIP|0|CallRegister: Failed with code 404
2018.06.22 22:20:49 5: FritzFonSIP, fifo is empty
2018.06.22 22:20:49 5: FritzFonSIP, no elbc
Trotz Umstellung auf "fhemsipfon". Passwort war "stark", Registrator auf die IP der Fritzbox geändert und ich habe auch nochmal versucht in sip_from "sip:FHEM@fritz.box" einzutragen, weil der SIP User in meiner Fritzbox FHEM heisst. Bringt leider auch nix.
Momentan sieht es so aus
{
"Arg":"FritzFonSIP",
"Results": [
{
"Name":"FritzFonSIP",
"PossibleSets":"call fetch:noArg listen:noArg password reject:noArg reset:noArg",
"PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 sip_watch_listen sip_ringtime sip_waittime sip_ip sip_port sip_user sip_registrar sip_from sip_call_audio_delay:0,0.25,0.5,0.75,1,1.25,1.5,1.75,2,2.25,2.5,2.75,3 sip_audiofile_call sip_audiofile_dtmf sip_audiofile_ok sip_audiofile_wfp sip_dtmf_size:1,2,3,4 sip_dtmf_send:audio,rfc2833 sip_dtmf_loop:once,loop sip_listen:none,dtmf,wfp,echo sip_filter sip_blocking sip_elbc:yes,no sip_force_interval sip_force_max T2S_Device T2S_Timeout audio_converter:sox,ffmpeg disabled:0,1 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr",
"Internals": {
".oldstate": "initialized",
".reset": "0",
"AC": "/usr/bin/sox",
"NAME": "FritzFonSIP",
"NOTIFYDEV": "TextToSpeech",
"NR": "437",
"NTFY_ORDER": "50-FritzFonSIP",
"STATE": "initialized",
"TYPE": "SIP",
"VERSION": "V1.76 / 08.01.18"
},
"Readings": {
"call": { "Value":"done", "Time":"2018-06-22 22:23:43" },
"call_attempt": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"call_state": { "Value":"fail", "Time":"2018-06-22 22:23:43" },
"call_success": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"call_time": { "Value":"0", "Time":"2018-06-22 22:23:43" },
"last_error": { "Value":"CallRegister: Failed with code 404", "Time":"2018-06-22 22:23:43" },
"listen_alive": { "Value":"no", "Time":"2018-06-20 22:31:11" },
"state": { "Value":"initialized", "Time":"2018-06-22 22:23:43" }
},
"Attributes": {
"T2S_Device": "TextToSpeech",
"audio_converter": "sox",
"room": "System",
"sip_dtmf_loop": "once",
"sip_dtmf_send": "audio",
"sip_dtmf_size": "2",
"sip_elbc": "yes",
"sip_from": "sip:FHEM@fritz.box",
"sip_ip": "192.168.178.111",
"sip_listen": "none",
"sip_registrar": "192.168.178.1",
"sip_ringtime": "3",
"sip_user": "fhemsipfon",
"verbose": "5"
}
} ],
"totalResultsReturned":1
}
Bei mir ist nur ein Eintrag anders als bei Dir:
"sip_from": "sip:fhemsipfon@192.168.178.1"
VG
habl
Zitat von: Cruiser79 am 22 Juni 2018, 22:28:22
Trotz Umstellung auf "fhemsipfon". Passwort war "stark", Registrator auf die IP der Fritzbox geändert und ich habe auch nochmal versucht in sip_from "sip:FHEM@fritz.box" einzutragen, weil der SIP User in meiner Fritzbox FHEM heisst. Bringt leider auch nix.
Das verstehe ich leider nicht ..... fhemsipfon oder FHEM ? was denn nun ?
Ich kann bei mir machen was ich will, deinen Fehler 404 bekomme ich nicht nachgestellt.
Zitat von: habl am 23 Juni 2018, 07:21:30
Bei mir ist nur ein Eintrag anders als bei Dir:
"sip_from": "sip:fhemsipfon@192.168.178.1"
Da ist ein mismatch
"Attributes": {
"T2S_Device": "TextToSpeech",
"audio_converter": "sox",
"room": "System",
"sip_dtmf_loop": "once",
"sip_dtmf_send": "audio",
"sip_dtmf_size": "2",
"sip_elbc": "yes",
"sip_from": "sip:
FHEM@fritz.box",
"sip_ip": "192.168.178.111",
"sip_listen": "none",
"sip_registrar": "192.168.178.1",
"sip_ringtime": "3",
"sip_user": "
fhemsipfon",
"verbose": "5"
}
Zitat von: habl am 23 Juni 2018, 07:21:30
Der Benutzername, den ich in der Fritzbox angelegt habe, lautet "fhemsipfon".
Wenn der Benutzer in der Fritzbox fhemsipfon heißt muss auch der sip_suer
sip:fhemsipfon@192.168.178.1 sein.
Zitat von: plin am 23 Juni 2018, 09:01:03
Da ist ein mismatch
"Attributes": {
"T2S_Device": "TextToSpeech",
"audio_converter": "sox",
"room": "System",
"sip_dtmf_loop": "once",
"sip_dtmf_send": "audio",
"sip_dtmf_size": "2",
"sip_elbc": "yes",
"sip_from": "sip:FHEM@fritz.box",
"sip_ip": "192.168.178.111",
"sip_listen": "none",
"sip_registrar": "192.168.178.1",
"sip_ringtime": "3",
"sip_user": "fhemsipfon",
"verbose": "5"
}
Wenn der Benutzer in der Fritzbox fhemsipfon heißt muss auch der sip_suer sip:fhemsipfon@192.168.178.1 sein.
Stimmt, das passte nicht. War von den 2 Namen in der Fritzbox irritiert. Dort gibt es einmal den Namen des angelegten "Telefons" (FHEM) und die Anmeldedaten (fhemsipfon)
Jetzt bin ich wohl auch über den 404 hinaus, bekomme nen neuen Fehler
2018.06.24 14:08:01 4: FritzFonSIP, CALL Kill PID : 6167
2018.06.24 14:08:01 4: FritzFonSIP, Reset Call done
2018.06.24 14:08:11 5: FritzFonSIP, MD5: Hallo, hier spricht FHEM -> e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.24 14:08:11 5: FritzFonSIP, set call new -> FritzFonSIP call **624 30 cache/e64926f23393ab9d341b9ccdac59c0b7.mp3
2018.06.24 14:08:11 4: FritzFonSIP, audio file cache/e64926f23393ab9d341b9ccdac59c0b7.mp3 found
2018.06.24 14:08:11 5: FritzFonSIP, not converted - using cache/e64926f23393ab9d341b9ccdac59c0b7.alaw from cache
2018.06.24 14:08:11 4: FritzFonSIP, FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0
2018.06.24 14:08:11 4: FritzFonSIP, call -> FritzFonSIP|**624|30|cache/e64926f23393ab9d341b9ccdac59c0b7.alaw|0|0
2018.06.24 14:08:11 5: FritzFonSIP, call has pid 12266
2018.06.24 14:08:11 4: FritzFonSIP[12266], my parent is 31034
2018.06.24 14:08:11 4: FritzFonSIP[12266], using Leg.pm to find a free port
2018.06.24 14:08:11 4: FritzFonSIP[12266], register new expire : 2018-06-24 14:13:11
2018.06.24 14:08:11 5: FritzFonSIP, readingS:state Val:calling
2018.06.24 14:08:11 4: FritzFonSIP[12266], CallStart with 1 files - first file : cache/e64926f23393ab9d341b9ccdac59c0b7.alaw - PCMA/8000 , repeat 0
Can't use string ("**624") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Was meint er jetzt schon wieder? Will das Gerät anrufen, welches wie im Anhang zu sehen in der Fritzbox angelegt wurde.
Welche Version von Net::SIP hast Du installiert? Im Zweifelsfalle noch mal installieren/aktualisieren (siehe auch https://wiki.fhem.de/wiki/SIP-Client#FHEM-Server).
Zitat von: Cruiser79 am 24 Juni 2018, 14:16:25
Can't use string ("**624") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Oh, je da ist aber eine uralt Version von Net::SIP installiert. Welche Debian Version nutzt du ?
Zitat von: plin am 24 Juni 2018, 15:14:18
Welche Version von Net::SIP hast Du installiert? Im Zweifelsfalle noch mal installieren/aktualisieren (siehe auch https://wiki.fhem.de/wiki/SIP-Client#FHEM-Server).
Habe es mittels des Wiki Befehls installiert, installiert wurde wohl folgendes:
ii libnet-sip-perl 0.66-1 all framework for SIP modules
Was wäre denn die minimale Version, die ich bräuchte?
Zitat von: Wzut am 24 Juni 2018, 16:48:41
Oh, je da ist aber eine uralt Version von Net::SIP installiert. Welche Debian Version nutzt du ?
Ich habe ein Raspbian GNU/Linux 7 (wheezy) dort laufen.
Also komme ich nur mit einem Rasbianupdate zum Erfolg?
Zitat von: Cruiser79 am 24 Juni 2018, 20:36:58
Also komme ich nur mit einem Rasbianupdate zum Erfolg?
Nein, das Problem hatten vor drei Jahre mehre User und es gab auch eine relativ einfache und gute Lösung :
https://forum.fhem.de/index.php/topic,40219.msg421446.html#msg421446
Da wird zwar noch von der Version 0.687 gesprochen, inzwischen ist Net::SIP allerdings schon bei 0.815
D.h. hole dir hier http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/Net-SIP-0.815.tar.gz das aktuelle Paket und installiere es nach der oben verlinkten Anleitung im alten FB Thread.
Zitat von: Wzut am 25 Juni 2018, 13:50:45
Nein, das Problem hatten vor drei Jahre mehre User und es gab auch eine relativ einfache und gute Lösung :
https://forum.fhem.de/index.php/topic,40219.msg421446.html#msg421446
Da wird zwar noch von der Version 0.687 gesprochen, inzwischen ist Net::SIP allerdings schon bei 0.815
D.h. hole dir hier http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/Net-SIP-0.815.tar.gz das aktuelle Paket und installiere es nach der oben verlinkten Anleitung im alten FB Thread.
Nach dem reboot hat sich leider meine Raspi Kiste ins Nirvana verabschiedet. Verdammtes SD Karten Problem. Nach einer SD Karten Rettung und ein paar Tagen Arbeit ist zum Glück noch einiges gerettet. Habe dann auch gleich mal das aktuellste Stretch aufgespielt. Nun kann ich Anrufe erfolgreich tätigen. Vielen Dank für die Tipps.
Hallo! Ich habe das Problem, dass die Soundausgabe nicht funktioniert. Das initiieren von einem Anruf geht - wenn ich aber rangehe kommt kein Ton. Nach ein paar Sekunden wird einfach wieder aufgelegt.
Kann mir da jemand helfen?
Hier mein Device:
defmod telsip SIP
attr telsip T2S_Device mytts
attr telsip T2S_Timeout 10
attr telsip audio_converter sox
attr telsip sip_dtmf_loop once
attr telsip sip_dtmf_send audio
attr telsip sip_dtmf_size 2
attr telsip sip_elbc yes
attr telsip sip_from sip:*****2@192.168.178.2
attr telsip sip_ip ***
attr telsip sip_listen none
attr telsip sip_port 5060
attr telsip sip_registrar 192.168.178.2
attr telsip sip_ringtime 3
attr telsip sip_user t****
attr telsip verbose 5
setstate telsip initialized
setstate telsip 2018-07-02 11:02:42 call done
setstate telsip 2018-07-02 11:02:42 call_attempt 0
setstate telsip 2018-07-02 11:02:42 call_state ok
setstate telsip 2018-07-02 11:02:42 call_success 1
setstate telsip 2018-07-02 11:02:42 call_time 14
setstate telsip 2018-06-29 12:53:51 caller reject
Hier das Log:
2018.07.02 11:02:28 4: telsip, audio file cache/test.alaw found
2018.07.02 11:02:28 4: telsip, telsip|08****|30|cache/test.alaw|0
2018.07.02 11:02:28 4: telsip, call -> telsip|08****|30|cache/test.alaw|0|0
2018.07.02 11:02:28 5: telsip, call has pid 1100
2018.07.02 11:02:28 4: telsip[1100], my parent is 43
2018.07.02 11:02:28 4: telsip[1100], trying to use port 5070
2018.07.02 11:02:28 4: telsip[1100], register new expire : 2018-07-02 11:07:28
2018.07.02 11:02:28 5: telsip, readingS:state Val:calling
2018.07.02 11:02:28 4: telsip[1100], CallStart with 1 files - first file : cache/test.alaw - PCMA/8000 , repeat 0
2018.07.02 11:02:28 4: telsip[1100], calling : 08*******
2018.07.02 11:02:28 4: telsip[1100], cb_final - status : FAIL - final : 481
2018.07.02 11:02:28 5: telsip, readingS:call_state Val:calling 08*********
2018.07.02 11:02:28 5: telsip, readingS:call_state Val:ringing
2018.07.02 11:02:39 4: telsip[1100], cb_final - status : OK
2018.07.02 11:02:39 4: telsip[1100], call established
2018.07.02 11:02:39 5: telsip, readingS:call_state Val:established
2018.07.02 11:02:42 5: telsip[1100], 0. Ende des ersten Loops
2018.07.02 11:02:42 5: telsip[1100], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], 2. fi : 0
2018.07.02 11:02:42 5: telsip[1100], 4. timeout : 0
2018.07.02 11:02:42 5: telsip[1100], 6. call_established : 1
2018.07.02 11:02:42 5: telsip[1100], call->bye
2018.07.02 11:02:42 5: telsip[1100], RTP done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], Timeout : 0
2018.07.02 11:02:42 5: telsip[1100], while : 0
2018.07.02 11:02:42 5: telsip[1100], Status : OK
2018.07.02 11:02:42 4: telsip, CALLDone -> telsip|1|ok
2018.07.02 11:02:42 5: telsip, fifo is empty
2018.07.02 11:02:42 5: telsip, no elbc
Dein Log Auzug ist unauffällig. Ich würde mich bei der Fehlersuche auf die verwendete Audiodatei konzentrieren, denn laut Log wurde sie abspielt und danach der Anruf beendet.
Woher stammt test.alaw bzw. wie wurde sie erzeugt ?
Hast du dir die Datei zur Kontrolle mal mit einem Mediaplayer angehört ?
Hast du es mal mit einer anderen bzw. mit einer .mp3 versucht ?
@Wzut:
Die Mediendatei ist ok. Hab sie schon mit Medienplayer "geprüft".
Ich habe das Modul jetzt mit einem externen SIP Anbieter getestet. Da funktioniert alles einwandfrei!
Nur mit der Fritzbox (die bei mir auf der IP-Adresse 192.168.178.2 läuft), funktioniert das nicht. Der Anruf wird initiiert - es klingelt auch - nur wenn ich rangehe, wird kein Audio abespielt.
Hast du dazu noch eine Idee??
Dann kann es IMHO nur noch die FB selbst sein. Wenn ich dein Log richtig lese rufst du eine externe Nummer an.
Hast du es mal auf einem internen direkt an der FB angeschlossenen Telefon probiert ?
Wenn kein Telefon Analog/DECT direkt an der FB hängt wäre eventuell ein Smartphone als WLAN Phone auch eine Möglichkeit zum testen. Wenn intern geht aber extern nicht wirst du wohl Wireshark auspacken müssen.
Das hab ich gerade probiert. Leider das gleiche Phänomen. Log sieht genauso aus wie extern.. Irgendwie läuft die Kommunikation zur Fritzbox etwas schief.. Über eine SIP-Android-App auf'm Handy funktioniert die Verbindung zur Fritzbox (über SIP-Prototkoll) tadellos...
mmmh, mein Log sieht anders aus:
2018.07.03 18:08:35 4: SipTest, audio file /opt/fhem/okay.alaw found
2018.07.03 18:08:35 4: SipTest, SipTest|**622|30|/opt/fhem/okay.alaw|0
2018.07.03 18:08:35 4: SipTest, call -> SipTest|**622|30|/opt/fhem/okay.alaw|0|0
2018.07.03 18:08:35 5: SipTest, call has pid 1311
2018.07.03 18:08:35 4: SipTest[1311], my parent is 403
2018.07.03 18:08:35 4: SipTest[1311], trying to use port 5080
2018.07.03 18:08:35 4: SipTest[1311], register new expire : 2018-07-03 18:13:35
2018.07.03 18:08:35 5: SipTest, readingS:state Val:calling
2018.07.03 18:08:35 4: SipTest[1311], CallStart with 1 files - first file : /opt/fhem/okay.alaw - PCMA/8000 , repeat 0
2018.07.03 18:08:35 4: SipTest[1311], calling : **622
2018.07.03 18:08:35 5: SipTest, readingS:call_state Val:calling **622
2018.07.03 18:08:38 4: SipTest[1311], cb_final - status : OK
2018.07.03 18:08:38 4: SipTest[1311], call established
2018.07.03 18:08:38 5: SipTest, readingS:call_state Val:established
2018.07.03 18:08:39 5: SipTest[1311], 0. Ende des ersten Loops
2018.07.03 18:08:39 5: SipTest[1311], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x2de25b8)
2018.07.03 18:08:39 5: SipTest[1311], 2. fi : 0
2018.07.03 18:08:39 5: SipTest[1311], 4. timeout : 0
2018.07.03 18:08:39 5: SipTest[1311], 6. call_established : 1
2018.07.03 18:08:39 5: SipTest[1311], call->bye
2018.07.03 18:08:39 5: SipTest[1311], RTP done : Net::SIP::Simple::Call=HASH(0x2de25b8)
2018.07.03 18:08:39 5: SipTest[1311], Timeout : 0
2018.07.03 18:08:39 5: SipTest[1311], while : 0
2018.07.03 18:08:39 5: SipTest[1311], Status : OK
2018.07.03 18:08:39 4: SipTest, CALLDone -> SipTest|1|ok
2018.07.03 18:08:39 5: SipTest, fifo is empty
2018.07.03 18:08:39 5: SipTest, no elbc
Mir ist in Deinem Log
...
2018.07.02 11:02:28 5: telsip, readingS:state Val:calling
2018.07.02 11:02:28 4: telsip[1100], CallStart with 1 files - first file : cache/test.alaw - PCMA/8000 , repeat 0
2018.07.02 11:02:28 4: telsip[1100], calling : 08*******
2018.07.02 11:02:28 4: telsip[1100], cb_final - status : FAIL - final : 481
...
aufgefallen. Der SIP-Code hat folgende Bedeutung:
481 Call/Transaction Does Not Exist Diese Verbindung existiert nicht (mehr).
Erst dann kommt der erfolgreiche Anruf
...
2018.07.02 11:02:28 5: telsip, readingS:call_state Val:ringing
2018.07.02 11:02:39 4: telsip[1100], cb_final - status : OK
2018.07.02 11:02:39 4: telsip[1100], call established
2018.07.02 11:02:39 5: telsip, readingS:call_state Val:established
2018.07.02 11:02:42 5: telsip[1100], 0. Ende des ersten Loops
2018.07.02 11:02:42 5: telsip[1100], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], 2. fi : 0
2018.07.02 11:02:42 5: telsip[1100], 4. timeout : 0
2018.07.02 11:02:42 5: telsip[1100], 6. call_established : 1
2018.07.02 11:02:42 5: telsip[1100], call->bye
2018.07.02 11:02:42 5: telsip[1100], RTP done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], Timeout : 0
2018.07.02 11:02:42 5: telsip[1100], while : 0
2018.07.02 11:02:42 5: telsip[1100], Status : OK
2018.07.02 11:02:42 4: telsip, CALLDone -> telsip|1|ok
...
aber ohne das Audio-File.
Ja, das ist mir auch schon aufgefallen. Mir kommt es so vor, dass die Antwort von der Fritzbox nicht in Fhem ankommt.
Aber dann versteh' ich nicht, warum das mit einem externen SIP Anbieter problemlos klappt.
Ich glaub, ich geb jetzt auf. Hab schon den ganzen Tag damit rumgespielt... :-/
Zitat von: plin am 03 Juli 2018, 18:14:53
2018.07.02 11:02:28 4: telsip[1100], cb_final - status : FAIL - final : 481
aufgefallen. Der SIP-Code hat folgende Bedeutung:
481 Call/Transaction Does Not Exist Diese Verbindung existiert nicht (mehr).
jein ... du hast eine recht neue Version von Net::SIP da ist das richtig ohne die 481, bei meiner Net::SIP Version 0.6x gibt es auch die 481 und das nutze ich zum anzeigen des status "ringing" , check das mal bei dir da gibt es den status ringing nicht mehr. (oder schau in den Quellcode vom Modul )
Der Wechsel kam bei irgend einer 0.8 Version, damals als wir noch mit Wireshark gekämpft hatten und Steffen Ulrich uns eine Testversion von Net::SIP gemacht hatte.
ok, dann kommt noch die Idee mit einem mp3-File ins Spiel und wir lassen sox oder ffmpeg konvertieren. Dann können wir sicher sein, dass das Audio File ein Format hat das Net::SIP gefällt.
Hallo zusammen,
bei bestimmten 'Alarmen' ruft mein fhem eine definierte Telefonnummer an und spielt einen Audiofile ab, der zu dem jeweiligen Alarm passt. Dazu verwende ich auf einem Raspberry Pi 2B asterisk als 'SIP-Client' in Verbindung mit einer FritzBox.
Mit dem Modul 96_SIP könnte ich nach meinem Verständnis die oben beschriebene Funktion auch umsetzen.
Meine Frage: was ist eure Einschätzung nach die Lösung, die weniger Ressourcen auf dem PI braucht?
Viele Grüße
Wolfgang
Hallo zusammen,
ich habe eine Frage:
Kann man in diesem Modul einen "Outbound-Proxy" definieren?
Ich hoffe dadurch, mein Problem in einer Docker-Umgebung in den Griff zu bekommen, indem ich einen sip-proxy "zwischenschalte"!
Oder hat jemand eine andere Lösung, damit sich das Modul mit der IP des Hosts am SIP-Server registriert und nicht mit der Container IP ?
Liebe Grüße
Ralf
Zitat von: pechnase am 09 Juli 2018, 13:48:18
Meine Frage: was ist eure Einschätzung nach die Lösung, die weniger Ressourcen auf dem PI braucht?
Ich nutze das Module TelegramBot in Verbindung mit der Telegram App
Zitat von: magichand am 09 Juli 2018, 14:18:09
Oder hat jemand eine andere Lösung, damit sich das Modul mit der IP des Hosts am SIP-Server registriert und nicht mit der Container IP ?
Schon mal mit
sip_ip versucht (siehe auch https://wiki.fhem.de/wiki/SIP-Client)?
Zitat von: plin am 09 Juli 2018, 18:20:07
Ich nutze das Module TelegramBot in Verbindung mit der Telegram App
ich glaube das war nicht ganz was pechnase wissen wollte. Du hast doch im Gegensatz zur mir Asterisk Erfahrung auf dem Raspi.
Zitat von: plin am 09 Juli 2018, 18:24:42
Schon mal mit sip_ip versucht (siehe auch https://wiki.fhem.de/wiki/SIP-Client)?
Ja, habe ich. Beide IP-Adressen eingesetzt und sip_listen auf 'wfp' gesetzt:
Bei der Host-IP 192.168.2.226 erhalte ich eine Fehlermeldung: ListenRegister: can't open port 5070 at 192.168.2.226 : Cannot assign requested address
Bei der Container-IP gibt es keine Fehlermeldung, dafür steht in der Registrierung auf dem Server auch die Containter-IP drin...
Viele Grüße
Ralf
Hallo Wzut und plin,
für ein Projekt, bei dem ich die Mobilfunknummer des Anrufers zur Authentifizierung benutzen möchte, wünsche ich mir ein Reading analog zu Caller, welches aber in jedem Fall die Rufnummer zurückliefert. Wenn der Anrufer im Telefonbuch der FritzBox eingetragen ist, liefert Caller derzeit den Klartextnamen.
Wäre toll, wenn das ins Modul eingebaut werden könnte.
Danke & Gruß
Tobias
Zitat von: magichand am 10 Juli 2018, 12:48:10
Bei der Host-IP 192.168.2.226 erhalte ich eine Fehlermeldung: ListenRegister: can't open port 5070 at 192.168.2.226 : Cannot assign requested address
Bei der Container-IP gibt es keine Fehlermeldung, dafür steht in der Registrierung auf dem Server auch die Containter-IP drin...
Ich kann dir bei Docker nicht weiterhelfen da ich davon keine Ahnung habe. Aber wir hatten so einen Fall schon einmal, gehe mal hier im Thread zurück bis Beitrag Nr. 313, da hatte sbiermann geschrieben auf was bei Docker zu achten ist.
Zitat von: tpm88 am 10 Juli 2018, 13:42:57
wünsche ich mir ein Reading analog zu Caller, welches aber in jedem Fall die Rufnummer zurückliefert. Wenn der Anrufer im Telefonbuch der FritzBox eingetragen ist, liefert Caller derzeit den Klartextnamen.
Was in Caller steht bestimmt die FritzBox, d.h. wenn da der Name aus dem Telefonbuch zurück kommt kann ich den im Modul nicht einfach wieder in eine Telefonnummer zurück übersetzen. Hier mußt du selbst aktiv werden mittels notify , userreading und dem Fritz Box Modul.
Zitat von: Wzut am 10 Juli 2018, 15:37:23
Was in Caller steht bestimmt die FritzBox, d.h. wenn da der Name aus dem Telefonbuch zurück kommt kann ich den im Modul nicht einfach wieder in eine Telefonnummer zurück übersetzen. Hier mußt du selbst aktiv werden mittels notify , userreading und dem Fritz Box Modul.
Hallo wzut,
hmm - aber das Modul gleicht die eingehende Rufnummer doch mit dem Attribut sip_filter ab, oder? Bei verbose 5 sehe ich z.B. diese Meldung:
2018.07.09 17:19:42 5: mySIP[23537], SIP_filter : a:"Tobi" <sip:017276xxxxx@fritz.box>;tag=02F221669F86DAA6 | b:Net::SIP::Request=HASH(0x2bb8888)
Lässt sich hierbei nicht die Rufnummer sip:<rufnummer>@fritz.box direkt abgreifen? Auf eine aufwändige Rückübersetzung würde ich eben gerne verzichten...
Gruß
Tobias
Ich schau mir das morgen oder am WE nochmal in Ruhe an und schneide ggf. zwischen : und @
Zitat von: Wzut am 09 Juli 2018, 18:52:10
ich glaube das war nicht ganz was pechnase wissen wollte. Du hast doch im Gegensatz zur mir Asterisk Erfahrung auf dem Raspi.
ok, man sollte sich auf die Wörter konzentrieren die man liest ;-)
Ein neuer Versuch
bei bestimmten 'Alarmen' ruft mein fhem eine definierte Telefonnummer an und spielt einen Audiofile ab, der zu dem jeweiligen Alarm passt.
meine Lösung ist halt Telegram. Wenn der Empfänger ein Smartphone hat ist das eine recht praktikable Lösung die wenig Ressourcen benötigt. TelegramBot ist deutlich stabiler als Yowsup für What'sApp.
Dazu verwende ich auf einem Raspberry Pi 2B asterisk als 'SIP-Client' in Verbindung mit einer FritzBox.
yup, Asterisk habe ich überlesen
Mit dem Modul 96_SIP könnte ich nach meinem Verständnis die oben beschriebene Funktion auch umsetzen.
ja
Meine Frage: was ist eure Einschätzung nach die Lösung, die weniger Ressourcen auf dem PI braucht?
wichtig ist hier das DIE Lösung
Ich habe keine Erfahrung mit Asterisk aus dem raspi. Da Asterisk aber sehr mächtig ist kann ich nur vermuten, dass unser 96_SIP weniger Ressourcen benötigt.
Andererseits: So richtig glücklich wurde ich mit unserem SIP-Modul erst auf einem raspi 3 (Stichwort DTMF-Empfang).
Der Vorteil des SIP-Moduls: Die Texte können via T2S dynamisch erzeugt werden. Die Pflege erfolgt nur zentral in FHEM.
Also: studieren geht über probieren ...
Zitat von: Wzut am 10 Juli 2018, 15:37:23
Ich kann dir bei Docker nicht weiterhelfen da ich davon keine Ahnung habe. Aber wir hatten so einen Fall schon einmal, gehe mal hier im Thread zurück bis Beitrag Nr. 313, da hatte sbiermann geschrieben auf was bei Docker zu achten ist.
meine Suche im Forum nach "Docker" führte zu folgender Passage die passen sollte
"Macht hier das SIP Modul einen eigenen Port auf? Wenn ja muss dieser beim starten des Containers exposed werden, sonst ist der nur lokal innerhalb des Containers verfügbar aber nicht von außen erreichbar.
Wenn man nun in dem Modul den Port 5060 und 5070 eintragen kann als feste Ports und die IP des Wirtrechners (z.B. 192.168.2.110) dann sollte der FHEM Container zusätzlich zu den Webports noch
-p 5060:5060 -p 5070:5070 als Startparameter bekommen um die Ports zu exposen.
Was normalerweise gehen sollte ich das ein Docker Container nach außen in die freie Welt funken darf. Sprich die FritzBox sollte erreichbar sein. Aber auch hier kann es Ausnahmen geben."
Zitat von: plin am 10 Juli 2018, 20:43:19
Was normalerweise gehen sollte ich das ein Docker Container nach außen in die freie Welt funken darf. Sprich die FritzBox sollte erreichbar sein. Aber auch hier kann es Ausnahmen geben."
Hi, das hatte ich auch gelesen und ausprobiert:
Egal, welche Ports ich "expose" oder mit "-p" übergebe, das Modul bindet sich nicht an die HOST-IP -> 'Cannot assign requested address'
Sobald ich die Container-IP in sip_ip eintrage, registriert sich das Modul am SIP-Server, allerdings mit der IP des Containers...
Aus dem Netzwerk kann ich auf die IP des HOSTS und dem Port 5060 zugreifen, also die Kommunikation zum Container und aus dem Container funktioniert...
Ich befürchte, dass es "nur" an der Registrierung des Clients am Server hängt, weil dort die IP des Interfaces übergeben wird, an dem der Dienst gebunden ist...
Ralf
@magichand: Wo hast Du Dein Docker-Image her? Dann kann ich versuchen das Problem nachzustellen.
ok, ich hab's:
Du musst die Ports exportieren, z.B.
docker run -d -p 8083:8083 -p 5060:5060 -p 5070:5070 michaelatdocker/fhem
Dann holst Du dir die IP-Adresse Deines Docker-Containers:
linuxlab:~ # docker exec 0155465c09f6 ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
15: eth0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 scope global eth0
valid_lft forever preferred_lft forever
Als sip_ip gibst Du die Adresse Deines Containers an: 172.17.0.2
Als sip_port kannst Du nun 5060 angeben.
Damit läuft's bei mir.
P.S. Ich musste aber bei dem Docker-Images Net::SIP und das Package procps nachinstallieren. net-tools war auch ganz hilfreich, um zu schauen, ob die Ports im Container geöffnet sind.
Zitat von: tpm88 am 10 Juli 2018, 13:42:57
wünsche ich mir ein Reading analog zu Caller, welches aber in jedem Fall die Rufnummer zurückliefert. Wenn der Anrufer im Telefonbuch der FritzBox eingetragen ist, liefert Caller derzeit den Klartextnamen.
Dann teste mal die angehänte Version :)
Neu : neues Reading caller_nr -> zeigt immer die Telefon Nr. des Anrufers
Das Reading caller_name zeigt den Namen des Anrufers wenn er von der Fritz Box aufgelöst werden kann (Eintrag im Telefonbuch)
Für fehlende Einträge in der FB kann auch ein eigenes Telefonbuch für 96_SIP angelegt werden ( siehe Attribut phonebook)
Neue Attribute :
a. phonebook -> eigenes File mit zeilenweise Nr,Name. Hier kann auch ein bereits vorhandenes File von z.B. FB_Callist eingetragen werden,
wird auch verwendet um bei ausgehenden Rufen einen Namen in der History Liste zu führen.
b. history_size & history_file
Da die Fritzbox keine Anruflisten für interne Rufe führt kann nun eine eigene SIP History Liste im Modul geführt werden.
history_file kann ein beliebiger Datei Name sein, wird ggf. automatisch neu erzeugt. history_size bestimmt die maximale Anzahl von Einträgen in der Liste. Default = 0 , d.h. keine Liste verwenden.
Um sich die Liste in einen Raum zu holen
define <name> weblink htmlCode (SIP_html("<name des SIP Device>")
leider hat weblink mit htmlCode die Eigenart keine Überschrift zu erzeugen, wer aber eine haben möchte kann diese beim define gleich mit angeben :
define <name> weblink htmlCode (SIP_html("<name des SIP Device>","meine SIP Liste")
Ich habe zwar viel getestet, aber inzwischen ist das mit den ganzen Möglichkeiten des Moduls doch recht schwierig und zeitaufwändig, ich würde mich daher über Betatester freuen bevor ich diese Version einchecke.
Hallo Wzut,
Zitat von: Wzut am 16 Juli 2018, 19:59:01
Dann teste mal die angehänte Version :)
Neu : neues Reading caller_nr -> zeigt immer die Telefon Nr. des Anrufers
Das Reading Caller zeigt den Namen des Anrufers wenn er von der Fritz Box aufgelöst werden kann (Eintrag im Telefonbuch)
Für fehlende Einträge in der FB kann auch ein eigenes Telefonbuch für 96_SIP angelegt werden ( siehe Attribut phonebook)
Vielen Dank - genauso habe ich mir das Reading caller_nr vorgestellt.
Der listen_dtmf use case funktioniert für mein Szenario mit dieser Version einwandfrei.
Gruß,
Tobias
Zitat von: plin am 12 Juli 2018, 21:18:56
Als sip_ip gibst Du die Adresse Deines Containers an: 172.17.0.2
Als sip_port kannst Du nun 5060 angeben.
Damit läuft's bei mir.
P.S. Ich musste aber bei dem Docker-Images Net::SIP und das Package procps nachinstallieren. net-tools war auch ganz hilfreich, um zu schauen, ob die Ports im Container geöffnet sind.
Ja, die Net::SIP und procspc sowie die net-tools habe ich mir auch gleich instaliert. Als Grundlage für mein Image habe ich das Projekt von klein0r/fhem-docker benutzt und entsprechend modifiziert danach mit docker-compose erstellt.
Hier mal der Auszug aus der docker-compose.yml
services:
fhem:
restart: always
ports:
- "8083:8083"
- "7072:7072"
- "5060:5060"
- "5070:5070"
build: fhem
privileged: true
volumes:
- ./fhem/core/:/opt/fhem/
networks:
- fhem-network
Bisher war ich der Meinung, daß der "ports"-Abschnitt das -p auf der Commandline umsetzt... Bin ich da im Irrtum?
Ralf
Hallo Wzut,
Zitat von: tpm88 am 16 Juli 2018, 23:01:25
Der listen_dtmf use case funktioniert für mein Szenario mit dieser Version einwandfrei.
Mir ist doch noch etwas aufgefallen. Und zwar legt der SIP Client bei listen_dtmf und sip_dtmf_loop=once nicht immer unmittelbar auf (Hangup), wenn ein dtmf_event gefeuert wird.
Leider kann ich es (noch) nicht zu 100% nachstellen, allerdings scheint der automatische Hangup auszubleiben, wenn zuvor mindestens einmal nach Anruf und Annahme die korrekte Anzahl DTMF Töne gefehlt hat und vom Anrufer aufgehängt wurde.
Hier ein zugehöriger Logauszug:
2018-07-19_22:22:29 mySIP listen_dtmf
2018-07-19_22:22:29 mySIP listen_alive: 21820
2018-07-19_22:22:29 mySIP expire: 300
2018-07-19_22:23:51 mySIP caller: Tobi
2018-07-19_22:23:51 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:23:51 mySIP caller_state: ringing
2018-07-19_22:23:52 mySIP caller_state: established
=> Anrufer legt auf, kein dtmf_event
2018-07-19_22:24:10 mySIP caller: none
2018-07-19_22:24:10 mySIP caller_state: hangup
2018-07-19_22:24:10 mySIP caller_time: 18
2018-07-19_22:24:10 mySIP caller_nr: ---
=> nachfolgender Anruf
2018-07-19_22:24:48 mySIP caller: Tobi
2018-07-19_22:24:48 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:24:48 mySIP caller_state: ringing
2018-07-19_22:24:49 mySIP caller_state: established
2018-07-19_22:24:58 mySIP dtmf_event: 42
=> jetzt sollte eigentlich aufgelegt werden
2018-07-19_22:24:59 mySIP listen_dtmf
2018-07-19_22:24:59 mySIP listen_alive: 21820
2018-07-19_22:24:59 mySIP expire: 300
=> Anrufer legt selbst nach 25 Sekunden auf
2018-07-19_22:25:24 mySIP caller: none
2018-07-19_22:25:24 mySIP caller_state: hangup
2018-07-19_22:25:24 mySIP caller_time: 35
2018-07-19_22:25:24 mySIP caller_nr: ---
=> weiterer Anruf
2018-07-19_22:27:05 mySIP caller: Tobi
2018-07-19_22:27:05 mySIP caller_nr: 01727602198
2018-07-19_22:27:05 mySIP caller_state: ringing
2018-07-19_22:27:06 mySIP caller_state: established
2018-07-19_22:27:26 mySIP dtmf_event: 53
2018-07-19_22:27:29 mySIP listen_dtmf
2018-07-19_22:27:29 mySIP listen_alive: 21820
2018-07-19_22:27:29 mySIP expire: 300
=> erneut kein automatischer Hangup
2018-07-19_22:27:46 mySIP caller: none
2018-07-19_22:27:46 mySIP caller_state: hangup
2018-07-19_22:27:46 mySIP caller_time: 40
2018-07-19_22:27:46 mySIP caller_nr: ---
=> wieder manuell aufgelegt und so weiter
2018-07-19_22:30:00 mySIP listen_dtmf
2018-07-19_22:30:00 mySIP listen_alive: 21820
2018-07-19_22:30:00 mySIP expire: 300
2018-07-19_22:31:17 mySIP caller: Tobi
2018-07-19_22:31:17 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:31:17 mySIP caller_state: ringing
2018-07-19_22:31:18 mySIP caller_state: established
2018-07-19_22:31:29 mySIP dtmf_event: 53
2018-07-19_22:31:47 mySIP caller: none
2018-07-19_22:31:47 mySIP caller_state: hangup
2018-07-19_22:31:47 mySIP caller_time: 29
2018-07-19_22:31:47 mySIP caller_nr: ---
2018-07-19_22:32:30 mySIP listen_dtmf
2018-07-19_22:32:30 mySIP listen_alive: 21820
2018-07-19_22:32:30 mySIP expire: 300
2018-07-19_22:33:56 mySIP caller: Tobi
2018-07-19_22:33:56 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:33:56 mySIP caller_state: ringing
2018-07-19_22:33:57 mySIP caller_state: established
2018-07-19_22:34:04 mySIP dtmf_event: 42
2018-07-19_22:34:21 mySIP caller: none
2018-07-19_22:34:21 mySIP caller_state: hangup
2018-07-19_22:34:21 mySIP caller_time: 24
2018-07-19_22:34:21 mySIP caller_nr: ---
2018-07-19_22:35:00 mySIP listen_dtmf
2018-07-19_22:35:00 mySIP listen_alive: 21820
2018-07-19_22:35:00 mySIP expire: 300
2018-07-19_22:37:12 mySIP caller: Tobi
2018-07-19_22:37:12 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:37:12 mySIP caller_state: ringing
2018-07-19_22:37:13 mySIP caller_state: established
2018-07-19_22:37:23 mySIP dtmf_event: 42
2018-07-19_22:37:30 mySIP listen_dtmf
2018-07-19_22:37:30 mySIP listen_alive: 21820
2018-07-19_22:37:30 mySIP expire: 300
2018-07-19_22:37:34 mySIP caller: none
2018-07-19_22:37:34 mySIP caller_state: hangup
2018-07-19_22:37:34 mySIP caller_time: 21
2018-07-19_22:37:34 mySIP caller_nr: ---
2018-07-19_22:40:00 mySIP listen_dtmf
2018-07-19_22:40:00 mySIP listen_alive: 21820
2018-07-19_22:40:00 mySIP expire: 300
2018-07-19_22:42:27 mySIP caller: Tobi
2018-07-19_22:42:27 mySIP caller_nr: 01727xxxxxx
2018-07-19_22:42:28 mySIP caller_state: ringing
2018-07-19_22:42:29 mySIP caller_state: established
2018-07-19_22:42:30 mySIP listen_dtmf
2018-07-19_22:42:30 mySIP listen_alive: 21820
2018-07-19_22:42:30 mySIP expire: 300
2018-07-19_22:42:35 mySIP dtmf_event: 42
2018-07-19_22:45:00 mySIP listen_dtmf
2018-07-19_22:45:00 mySIP listen_alive: 21820
2018-07-19_22:45:00 mySIP expire: 300
=> selbst nach über drei Minuten kein Hangup
2018-07-19_22:45:47 mySIP caller: none
2018-07-19_22:45:47 mySIP caller_state: hangup
2018-07-19_22:45:47 mySIP caller_time: 198
2018-07-19_22:45:47 mySIP caller_nr: ---
2018-07-19_22:47:31 mySIP listen_dtmf
2018-07-19_22:47:31 mySIP listen_alive: 21820
2018-07-19_22:47:31 mySIP expire: 300
2018-07-19_22:50:01 mySIP listen_dtmf
2018-07-19_22:50:01 mySIP listen_alive: 21820
2018-07-19_22:50:01 mySIP expire: 300
Und hier noch das list des SIP Device:
fhem> list mySIP
Internals:
LPID 21820
NAME mySIP
NOTIFYDEV global
NR 19
NTFY_ORDER 50-mySIP
STATE listen_dtmf
TYPE SIP
VERSION V1.8 / 16.07.18
READINGS:
2018-07-19 22:45:47 caller none
2018-07-19 22:45:47 caller_nr ---
2018-07-19 22:45:47 caller_state hangup
2018-07-19 22:45:47 caller_time 198
2018-07-19 22:42:35 dtmf_event 42
2018-07-19 23:05:02 expire 300
2018-07-19 23:05:02 listen_alive 21820
2018-07-19 23:05:02 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg mySIP
bc_pid 1
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 21820
timeout
Attributes:
history_file ./log/mySIP.sip
history_size 0
room SIP
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_filter 1727xxxxxx,1749yyyyyy
sip_from sip:sipTM621@fritz.box
sip_ip 192.168.8.72
sip_listen dtmf
sip_port 5060
sip_registrar fritz.box
sip_ringtime 1
sip_user sipTM621
verbose 5
@tmp88, kannst du das bitte nochmal wiederholen :
1. anrufen , 2. auflegen, 3.anrufen, 4. dtmf eingeben. Wenn nun wieder kein hangup vom SIP Client kommt setze bitte ein set <name> reset ab.
Nun wieder anrufen , dtmf eingeben, erfolgt jetzt wieder der hangup ? Dann hätte ich zumindest einen Anhaltspunkt an welcher Stelle ich suchen müsste.
Bzw. tritt das Verhalten jetzt nur mit der neuen V1.8 Version auf oder auch schon vorher ?
Ich sehe an deinen Attributen das du ohne die beiden Audiodateien sip_audiofile _dtmf und sip_audiofile_ok arbeitest.
Wäre schön wenn du mal testen könntest mit den beiden, falls Test2Spech installiert ist kannst du da ja direkt einen Text reinschreiben.
Mit sip_audiofile_ok hättest du dann für den Fehlerfall zumindest eine akustische Kontrolle das deine Tastenfolge erkannt wurde
Hallo Wzut,
habe den von dir vorgeschlagenen Test durchgeführt - hier das kommentierte verbose 5 Log dazu:
=> 0. FHEM Neustart
2018.07.20 07:48:49 4: mySIP, Listen new PID : 28118
2018.07.20 07:48:49 4: mySIP[28118], my parent is 28111
2018.07.20 07:48:49 4: mySIP[28118], trying to use port 5060
2018.07.20 07:48:50 4: mySIP[28118], register new expire : 2018-07-20 07:53:50
2018.07.20 07:48:50 5: mySIP, readingB:state Val:listen_dtmf
2018.07.20 07:48:50 5: mySIP, readingB:listen_alive Val:28118
2018.07.20 07:48:50 5: mySIP, readingB:expire Val:300
2018.07.20 07:48:50 5: mySIP, readingB:caller Val:none
2018.07.20 07:48:50 5: mySIP, readingB:caller_state Val:waiting
2018.07.20 07:49:49 5: mySIP, listen process 28118 found
=> 1. Anruf
2018.07.20 07:50:03 5: mySIP[28118], SIP_filter : "Tobi" <sip:01727xxxxxx@fritz.box>;tag=941177940FDE6300
2018.07.20 07:50:03 4: mySIP[28118], SIP_filter: caller Tobi, callnr 01727xxxxxx
2018.07.20 07:50:03 5: mySIP, readingB:caller Val:Tobi
2018.07.20 07:50:03 4: mySIP[28118], cb_create : INVITE
2018.07.20 07:50:03 5: mySIP, readingB:caller_nr Val:01727xxxxxx
2018.07.20 07:50:03 5: mySIP[28118], cb_ivite
2018.07.20 07:50:03 5: mySIP, readingS:caller_state Val:ringing
2018.07.20 07:50:04 5: mySIP[28118], cb_est
2018.07.20 07:50:04 5: mySIP, readingS:caller_state Val:established
2018.07.20 07:50:08 5: mySIP[28118], DTMF Event: # - 949 ms
2018.07.20 07:50:11 5: mySIP[28118], DTMF Event: 4 - 209 ms
2018.07.20 07:50:11 5: mySIP[28118], DTMF: 4 , Anz: 2
2018.07.20 07:50:11 5: mySIP[28118], DTMF Event: 2 - 629 ms
2018.07.20 07:50:11 5: mySIP[28118], DTMF: 42 , Anz: 3
2018.07.20 07:50:11 5: mySIP, readingS:dtmf_event Val:42
2018.07.20 07:50:11 5: mySIP[28118], DTMF Event: 2 - 40 ms
2018.07.20 07:50:12 5: mySIP, readingB:caller Val:none
2018.07.20 07:50:12 5: mySIP, readingB:caller_state Val:hangup
2018.07.20 07:50:12 5: mySIP, readingB:caller_time Val:8
2018.07.20 07:50:12 5: mySIP, readingB:caller_nr Val:---
2018.07.20 07:50:12 5: mySIP[28118], DTMF Event: 2 - 330 ms
=> DTMF korrekt eingegeben, DTMF Event, Auto Hangup OK
2018.07.20 07:50:50 5: mySIP, listen process 28118 found
=> 2. Anruf
2018.07.20 07:51:19 5: mySIP[28118], SIP_filter : "Tobi" <sip:01727xxxxxx@fritz.box>;tag=3C6ECEE184926A99
2018.07.20 07:51:19 4: mySIP[28118], SIP_filter: caller Tobi, callnr 01727xxxxxx
2018.07.20 07:51:19 4: mySIP[28118], cb_create : INVITE
2018.07.20 07:51:19 5: mySIP, readingB:caller Val:Tobi
2018.07.20 07:51:19 5: mySIP, readingB:caller_nr Val:01727xxxxxx
2018.07.20 07:51:19 5: mySIP[28118], cb_ivite
2018.07.20 07:51:19 5: mySIP, readingS:caller_state Val:ringing
2018.07.20 07:51:20 5: mySIP[28118], cb_est
2018.07.20 07:51:20 5: mySIP, readingS:caller_state Val:established
2018.07.20 07:51:20 4: mySIP[28118], register new expire : 2018-07-20 07:56:20
2018.07.20 07:51:20 5: mySIP, readingB:state Val:listen_dtmf
2018.07.20 07:51:20 5: mySIP, readingB:listen_alive Val:28118
2018.07.20 07:51:20 5: mySIP, readingB:expire Val:300
2018.07.20 07:51:24 5: mySIP[28118], DTMF Event: # - 429 ms
2018.07.20 07:51:27 5: mySIP[28118], DTMF Event: 9 - 269 ms
2018.07.20 07:51:27 5: mySIP[28118], DTMF: 9 , Anz: 2
2018.07.20 07:51:30 5: mySIP[28118], SIP_bye : HASH(0x27c1c28)
2018.07.20 07:51:30 5: mySIP, readingB:caller Val:none
2018.07.20 07:51:30 5: mySIP, readingB:caller_state Val:hangup
2018.07.20 07:51:30 5: mySIP, readingB:caller_time Val:10
2018.07.20 07:51:30 5: mySIP, readingB:caller_nr Val:---
=> DTMF falsch eingegeben ( nur 1 Ton ), User legt auf
...
=> 3. Anruf
2018.07.20 07:51:43 5: mySIP[28118], SIP_filter : "Tobi" <sip:01727xxxxxx@fritz.box>;tag=0FEFCE7EC5FA86D9
2018.07.20 07:51:43 4: mySIP[28118], SIP_filter: caller Tobi, callnr 01727xxxxxx
2018.07.20 07:51:43 5: mySIP, readingB:caller Val:Tobi
2018.07.20 07:51:43 4: mySIP[28118], cb_create : INVITE
2018.07.20 07:51:43 5: mySIP, readingB:caller_nr Val:01727xxxxxx
2018.07.20 07:51:43 5: mySIP[28118], cb_ivite
2018.07.20 07:51:43 5: mySIP, readingS:caller_state Val:ringing
2018.07.20 07:51:44 5: mySIP[28118], cb_est
2018.07.20 07:51:44 5: mySIP, readingS:caller_state Val:established
2018.07.20 07:51:48 5: mySIP[28118], DTMF Event: # - 959 ms
2018.07.20 07:51:50 5: mySIP, listen process 28118 found
2018.07.20 07:51:53 5: mySIP[28118], DTMF Event: 4 - 559 ms
2018.07.20 07:51:53 5: mySIP[28118], DTMF: 4 , Anz: 2
2018.07.20 07:51:54 5: mySIP[28118], DTMF Event: 4 - 379 ms
2018.07.20 07:51:54 5: mySIP[28118], DTMF Event: 2 - 559 ms
2018.07.20 07:51:54 5: mySIP[28118], DTMF: 42 , Anz: 3
2018.07.20 07:51:54 5: mySIP, readingS:dtmf_event Val:42
2018.07.20 07:51:55 5: mySIP[28118], DTMF Event: 2 - 59 ms
=> DTMF korrekt eingegeben, DTMF Event, KEIN automatischer Hangup
...
=> manueller Hangup nach 30 Sekunden
2018.07.20 07:52:33 5: mySIP[28118], SIP_bye : HASH(0x27be7f8)
2018.07.20 07:52:33 5: mySIP, readingB:caller Val:none
2018.07.20 07:52:33 5: mySIP, readingB:caller_state Val:hangup
2018.07.20 07:52:33 5: mySIP, readingB:caller_time Val:49
2018.07.20 07:52:33 5: mySIP, readingB:caller_nr Val:---
=> SIP Device reset
2018.07.20 07:52:46 4: mySIP, Listen Kill PID : 28118
2018.07.20 07:52:46 4: mySIP, Reset Listen done
2018.07.20 07:52:46 4: mySIP, Listen new PID : 28440
2018.07.20 07:52:46 4: mySIP[28440], my parent is 28111
2018.07.20 07:52:46 4: mySIP[28440], trying to use port 5060
2018.07.20 07:52:47 4: mySIP[28440], register new expire : 2018-07-20 07:57:47
2018.07.20 07:52:47 5: mySIP, readingB:state Val:listen_dtmf
2018.07.20 07:52:47 5: mySIP, readingB:listen_alive Val:28440
2018.07.20 07:52:47 5: mySIP, readingB:expire Val:300
2018.07.20 07:52:47 5: mySIP, readingB:caller Val:none
2018.07.20 07:52:47 5: mySIP, readingB:caller_state Val:waiting
=> 4. Anruf ( nach Reset )
2018.07.20 07:52:58 5: mySIP[28440], SIP_filter : "Tobi" <sip:01727xxxxxx@fritz.box>;tag=B68B7F4EEE4F5441
2018.07.20 07:52:58 4: mySIP[28440], SIP_filter: caller Tobi, callnr 01727xxxxxx
2018.07.20 07:52:58 5: mySIP, readingB:caller Val:Tobi
2018.07.20 07:52:58 4: mySIP[28440], cb_create : INVITE
2018.07.20 07:52:58 5: mySIP, readingB:caller_nr Val:01727xxxxxx
2018.07.20 07:52:58 5: mySIP[28440], cb_ivite
2018.07.20 07:52:58 5: mySIP, readingS:caller_state Val:ringing
2018.07.20 07:52:59 5: mySIP[28440], cb_est
2018.07.20 07:52:59 5: mySIP, readingS:caller_state Val:established
2018.07.20 07:53:03 5: mySIP[28440], DTMF Event: # - 869 ms
2018.07.20 07:53:05 5: mySIP[28440], DTMF Event: 4 - 689 ms
2018.07.20 07:53:05 5: mySIP[28440], DTMF: 4 , Anz: 2
2018.07.20 07:53:06 5: mySIP[28440], DTMF Event: 2 - 489 ms
2018.07.20 07:53:06 5: mySIP[28440], DTMF: 42 , Anz: 3
2018.07.20 07:53:06 5: mySIP, readingS:dtmf_event Val:42
2018.07.20 07:53:07 5: mySIP, readingB:caller Val:none
2018.07.20 07:53:07 5: mySIP, readingB:caller_state Val:hangup
2018.07.20 07:53:07 5: mySIP, readingB:caller_time Val:8
2018.07.20 07:53:07 5: mySIP, readingB:caller_nr Val:---
=> DTMF korrekt, automatischer HANGUP, OK nach Reset
2018.07.20 07:53:46 5: mySIP, listen process 28440 found
2018.07.20 07:54:46 5: mySIP, listen process 28440 found
2018.07.20 07:55:17 4: mySIP[28440], register new expire : 2018-07-20 08:00:17
2018.07.20 07:55:17 5: mySIP, readingB:state Val:listen_dtmf
2018.07.20 07:55:17 5: mySIP, readingB:listen_alive Val:28440
2018.07.20 07:55:17 5: mySIP, readingB:expire Val:300
2018.07.20 07:55:47 5: mySIP, listen process 28440 found
Ich glaube, das war mit der vorherigen Version 1.7 auch schon so. Wenn es schwer zu finden ist, kann ich aber auch noch einmal mit der alten Version testen.
Am Log sieht man ja auch die DTMF Erkennung - insofern würde ich gerne erst einmal auf Tests mit Audiodateien verzichten, da ich auch kein T2S installiert habe.
Gruß
Tobias
OK, mit dem Audiofiles war ich eh auf dem Holzweg.
Schau dir doch bitte mal den Quelltext des Moduls an (egal welche Version )
so um die Zeilen Nr 1300 müsstest du folgenden Code Block finden :
if (AttrVal($name,"sip_listen", "none") eq "dtmf")
{
$hash->{dtmf} = 0;
$dtmfloop = 0; # Ende-Flag für die DTMF-Schleife
$okloop = 0; # Ende-Flag für die OK-Ansage
$okloopbye = 0; # Ende-Flag für recv_bye während der OK-Ansage
$byebye = 0; # Anrufer hat aufgelegt
#BlockingInformParent("SIP_rBU", [$name, "caller:none|caller_state:waiting"], 0);
while(1)
{
my $call;
$hash->{dtmf} = 0;
$hash->{dtmf_event} = "";
$hash->{old} ="-";
setze da bitte mal $byebye = 0; direkt hinter my $call :
while(1)
{
my $call;
$byebye =0;
$hash->{dtmf} = 0;
speichern , reload 96_SIP , und set <name> reset
Das Problem sollte damit hoffentlich vom Tisch sein
Zitat von: Wzut am 20 Juli 2018, 20:03:17
Das Problem sollte damit hoffentlich vom Tisch sein
Allerdings. Jetzt funktioniert der automatische Hangup zuverlässig.
Danke & Gruß
Tobias
Ich habe die Version im Posting #654 gegen eine nochmal überarbeitete Version 1.85 ausgetauscht.
Es wäre wirklich schön wenn ausser plin sich noch andere User zum testen erbarmen könnten ..... :(
Auch V1.85 arbeitet in meinem Szenario listen_dtmf einwandfrei.
Zitat von: Wzut am 22 Juli 2018, 20:06:14
Ich habe die Version im Posting #654 gegen eine nochmal überarbeitete Version 1.85 ausgetauscht.
Es wäre wirklich schön wenn ausser plin sich noch andere User zum testen erbarmen könnten ..... :(
na ja, es gibt eben User, die nutzen das Modul komplett anders. Seit dem Update legt SIP nicht mehr automatisch auf... Zum Glück öffnet und schließt mein Hof und Garagentor noch nach Anruf der jeweiligen Nummer, nur muss ich aktuell den Anruf von Hand beenden. Das ging vorher automatisch. Da ist die Motivation neue Funktionen zu testen sehr sehr gering, sorry
Zitat von: det. am 30 Juli 2018, 20:25:34
Seit dem Update legt SIP nicht mehr automatisch auf...
Geht es vllt. etwas genauer ? Wann genau bei einem ausgehenden Ruf oder in einem der Listen Modi ? und wenn Listen welcher ?
Ein Log Auszug mit verbose 5 wäre ebenfalls hilfreich.
klar geht es genauer - sorry. SIP lauscht auf ankommenden Anruf von berechtigter Mobilnummer - jeweils eine MSN (Auf/Zu) nur für diesen Zweck reserviert. Daz Ziel ist nur das Event Anruf - danach spielt es das Audio File ab und legte sofort danach automatisch auf - bisher...
defmod TELEFON SIP
attr TELEFON T2S_Timeout 1
attr TELEFON history_file ./log/TELEFON.sip
attr TELEFON history_size 0
attr TELEFON sip_audiofile_wfp ./cache/speech.alaw
attr TELEFON sip_call_audio_delay 2
attr TELEFON sip_dtmf_loop once
attr TELEFON sip_dtmf_send audio
attr TELEFON sip_dtmf_size 1
attr TELEFON sip_elbc no
attr TELEFON sip_filter ***
attr TELEFON sip_from sip:***@fritz.box
attr TELEFON sip_ip ***
attr TELEFON sip_listen wfp
attr TELEFON sip_port 44000
attr TELEFON sip_registrar ***
attr TELEFON sip_ringtime 1
attr TELEFON sip_user ***
attr TELEFON sip_waittime 1
attr TELEFON verbose 0
setstate TELEFON listen_wfp
setstate TELEFON 2017-09-14 18:52:45 call done
setstate TELEFON 2017-09-14 18:52:45 call_state peer hangup
setstate TELEFON 2017-09-14 18:52:45 call_success 0
setstate TELEFON 2017-09-14 18:52:45 call_time 11.7305119037628
setstate TELEFON 2018-07-31 08:48:58 caller none
setstate TELEFON 2018-07-31 08:48:58 caller_name ---
setstate TELEFON 2018-07-31 08:48:58 caller_nr ---
setstate TELEFON 2018-07-31 08:48:58 caller_state hangup
setstate TELEFON 2018-07-31 08:48:58 caller_time 27
setstate TELEFON 2018-07-31 08:52:42 expire 300
setstate TELEFON 2018-07-31 08:52:42 listen_alive 4326
setstate TELEFON 2018-07-31 08:52:42 state listen_wfp
Aufruf mit:defmod Garagecall notify TELEFON:.***.* set TELEFON fetch
bei eingehemden Anruf öffnet (schliesst) das Tor:defmod callGarage DOIF ([CALL:internal_number] eq "***" and [?CALL:external_number] eq "***" and [?rr_***:location] eq "home") (set HofTor auf,set RollTor auf)
attr callGarage DbLogExclude .*
attr callGarage do always
setstate callGarage cmd_1
setstate callGarage 2018-07-31 08:48:58 Device CALL
setstate callGarage 2018-07-31 08:48:58 cmd 1
setstate callGarage 2018-07-31 08:48:58 cmd_event CALL
setstate callGarage 2018-07-31 08:48:58 cmd_nr 1
setstate callGarage 2018-07-31 08:48:58 e_CALL_internal_number ***
setstate callGarage 2018-04-16 09:08:06 mode enabled
setstate callGarage 2018-07-31 08:48:58 state cmd_1
Die einzige LOG Ausgabe dazu nach dem Update:2018.07.30 07:51:56 1: configfile: TELEFON: unknown attribute event-on-change-reading. Type 'attr TELEFON ?' for a detailed list.
OK, ich fang mal hinten an:
unknown attribute event-on-change-reading
ja da ist in Zeile 115 nach phonebook ein Komma statt einem Punkt - sorry mein Fehler ändere ich sofort heute Abend :(
Warum du allerdings nicht mehr im Log siehst liegt an deinem verbose 0 statt 5 :)
OK, Betriebsart listen_wfp mit Ausgabe eines Audiofiles ./cache/speech.alaw nach fetch.
Verwendet wird noch sip_filter ? Ich gehe mal davon aus da steht u.A. deine Handy Nr da sie zu den Berechtigten gehört.
schaue ich mir auch nochmal an obwohl ich denke an wfp (im Gegensatz zu dtmf) nichts geändert zu haben.
Eine Anmerkung noch : ein notify und ein DOIF wäre mir persönlich zu umständlich, ich würde das in einem erledigen.
Zitat von: Wzut am 31 Juli 2018, 11:17:25
...Eine Anmerkung noch : ein notify und ein DOIF wäre mir persönlich zu umständlich, ich würde das in einem erledigen.
Da hast Du recht, allerdings sind das 6 DOIF (eins für jedes berechtigte iPhone (3 Stück) mit Überprüfung der Anwesenheit des Besitzers und der MSN für AUF oder ZU) und 2 notify (für AUF und ZU). Da hatte ich wenig Motivation das besonders schön zu komprimieren.
Fakt ist nur, das es ewig bis zum letzten Update prima funktioniert hat. Wenn ich es jetzt umschreiben muss ist das auch nicht schlimm, aber nach mehrfachem Lesen der Commandref und des WIKI habe ich keine Idee wie...Wenn unbedingt zur Suche nötig kann ich verbose für diesen Fall mal auf 5 setzen.
Zitat von: det. am 31 Juli 2018, 13:59:27
Wenn unbedingt zur Suche nötig kann ich verbose für diesen Fall mal auf 5 setzen.
Wenn es bei mir geht wirst du es wohl tun müssen, aber warten wir mal ab.
Edit :
defmod Garagecall notify TELEFON:.***.* set TELEFON fetch
Könnte es vllt sein das dein notify nicht mehr greift ? Brauchen tust du es ja nur um die das Gespräch zu beenden, da könntest du auch gleich set TELEFON fetch noch als drittes Kommando in dein DOIF packen.
Kannst du das notify bitte mal nicht ganz so schwer lesbar (die ganzen * ) posten ? Wenn da eine Handynr. vorkommt ersetze sie halt durch 0815 oder 4711.
Zitat von: Wzut am 31 Juli 2018, 14:09:16
... um die das Gespräch zu beenden, da könntest du auch gleich set TELEFON fetch noch als drittes Kommando in dein DOIF packen.
Prima, Idee. Gesagt - getan, aber daran lag es nicht. Habe das jetzt eben bei einem Anruf in FHEM beobachtet: fetch erscheint als event, aber der Anruf wird nicht beendet. Habe mal den Eventmonitor aufgezeichnet für einen Anruf:
2018-07-31 16:24:07 DOIF callGarage_ZU cmd_nr: 1
2018-07-31 16:24:07 DOIF callGarage_ZU cmd: 1
2018-07-31 16:24:07 DOIF callGarage_ZU cmd_event: CALL
2018-07-31 16:24:07 DOIF callGarage_ZU cmd_1
2018-07-31 16:24:08 FB_CALLMONITOR CALL event: ring
2018-07-31 16:24:08 FB_CALLMONITOR CALL external_connection: SIP5
2018-07-31 16:24:08 FB_CALLMONITOR CALL call_id: 0
2018-07-31 16:24:08 FB_CALLMONITOR CALL external_number: meine Nummer
2018-07-31 16:24:08 FB_CALLMONITOR CALL external_name: mein Name
2018-07-31 16:24:08 FB_CALLMONITOR CALL direction: incoming
2018-07-31 16:24:08 FB_CALLMONITOR CALL internal_number: MSN für ZU
2018-07-31 16:24:08 SIP TELEFON_ZU caller: mein Name sip:meine Nummer@fritz.box
2018-07-31 16:24:08 SIP TELEFON_ZU caller_nr: meine Nummer
2018-07-31 16:24:08 SIP TELEFON_ZU caller_name: mein Name
2018-07-31 16:24:08 SIP TELEFON_ZU caller_time: 0
2018-07-31 16:24:08 SIP TELEFON_ZU caller_state: calling
2018-07-31 16:24:08 SIP TELEFON_ZU caller_state: ringing 1
2018-07-31 16:24:08 ZWave HofTor power: 433.7 W
2018-07-31 16:24:09 SIP TELEFON_ZU caller_state: ringing 2
2018-07-31 16:24:10 SONOS Sonos LastProcessAnswer: 1533047050.47848
2018-07-31 16:24:10 SIP TELEFON_ZU caller_state: ringing 3
2018-07-31 16:24:11 SIP TELEFON_ZU caller_state: ringing 4
2018-07-31 16:24:13 SIP TELEFON_ZU caller_state: ringing 5
2018-07-31 16:24:13 SIP TELEFON_ZU caller: none
2018-07-31 16:24:13 SIP TELEFON_ZU caller_state: waiting
2018-07-31 16:24:13 SIP TELEFON_ZU caller_nr: ---
2018-07-31 16:24:13 SIP TELEFON_ZU caller_time: 0
2018-07-31 16:24:13 SIP TELEFON_ZU caller_name: ---
2018-07-31 16:24:13 SIP TELEFON_ZU caller: fetch
2018-07-31 16:24:13 DOIF callGarage_ZU cmd_nr: 1
2018-07-31 16:24:13 DOIF callGarage_ZU cmd: 1
2018-07-31 16:24:13 DOIF callGarage_ZU cmd_event: CALL
2018-07-31 16:24:13 DOIF callGarage_ZU cmd_1
2018-07-31 16:24:13 FB_CALLMONITOR CALL event: connect
2018-07-31 16:24:13 FB_CALLMONITOR CALL internal_number: MSN für ZU
2018-07-31 16:24:13 FB_CALLMONITOR CALL internal_connection: VoIP_6
2018-07-31 16:24:13 FB_CALLMONITOR CALL direction: incoming
2018-07-31 16:24:13 FB_CALLMONITOR CALL external_name: mein Name
2018-07-31 16:24:13 FB_CALLMONITOR CALL external_number: meine Nummer
2018-07-31 16:24:13 FB_CALLMONITOR CALL call_id: 0
2018-07-31 16:24:13 FB_CALLMONITOR CALL external_connection: SIP5
2018-07-31 16:24:18 SIP TELEFON_ZU listen_wfp
2018-07-31 16:24:18 SIP TELEFON_ZU listen_alive: 6955
2018-07-31 16:24:18 SIP TELEFON_ZU expire: 300
nach Einspielen der letzten Version vor dem Update geht wieder alles wie gewünscht. Jetzt ohne notify, alles im DOIF....
Eventlog ist ungeeignet um so einen Fehler zu finden. Ein Log mit verbose 5 erzeugt zwar jede Menge Ausgabe, dafür lässt sich dann aber relativ leicht so ein Fehler aufspüren. Ab morgen früh gibt es die V1.91 via update, dann sollte alles wieder passen.
Ok, ich teste mal und werde berichten...
Danke, mit Version 1.91 ist wieder alles so wie gewohnt.
Na wenigstens mal ne gute Nachricht :)
Ich muss mal schaun deine Verwendung schreit eigentlich nach einem vierten listen Modus, in dem der Ruf automatisch angenommen wird , die Audiodatei übertragen und wieder aufgelegt wird. Also ein wfp ohne fetch, das entspräche quasi einem Anrufbeantworter ohne Möglichkeit der Sprach Aufzeichnung.
Ich höre, wenn ich den SIP-Client anrufe, nicht das gewünschte audio file. Merkwürdigerweise wird der Anruf aber genausolange gehalten, wie das audiofile dauert. Nehme ich ein kürzeres File ist der Anruf schneller beendet, als bei einem längeren File.
Das audio file ist aber in Ordnung, da es bei einem "set sipclient call" problemlos am anzurufenden Telefon abgespielt wird.
defmod sipclient SIP
attr sipclient audio_converter sox
attr sipclient T2S_Timeout 1
attr sipclient T2S_Device text2speech
attr sipclient sip_audiofile_wfp /opt/fhem/FHEM/sipaudio/test.alaw
attr sipclient sip_call_audio_delay 2
attr sipclient sip_elbc yes
attr sipclient sip_from sip:90@asteriskpbx.example
attr sipclient sip_listen wfp
attr sipclient sip_port 5060
attr sipclient sip_registrar asteriskpbx.example
attr sipclient sip_ringtime 1
attr sipclient sip_user 90
attr sipclient sip_waittime 2
attr sipclient verbose 5
2018.08.08 19:23:49 4: sipclient, Listen new PID : 834
2018.08.08 19:23:49 4: sipclient[834], my parent is 739
2018.08.08 19:23:49 4: sipclient[834], trying to use port 5060
2018.08.08 19:23:49 4: sipclient[834], register new expire : 2018-08-08 19:38:49
2018.08.08 19:23:49 5: sipclient[834], audio file /opt/fhem/FHEM/sipaudio/test.alaw found
2018.08.08 19:23:49 4: sipclient[834], using /opt/fhem/FHEM/sipaudio/test.alaw for audio_wfp
2018.08.08 19:23:55 5: sipclient, readingB:state Val:listen_wfp
2018.08.08 19:23:55 5: sipclient, readingB:listen_alive Val:834
2018.08.08 19:23:55 5: sipclient, readingB:expire Val:900
2018.08.08 19:24:08 5: sipclient[834], SIP_filter : "WZ" <sip:11@192.168.10.17>;tag=as6c08f0fb
2018.08.08 19:24:08 4: sipclient[834], SIP_filter: caller WZ sip:11@192.168.10.17, caller_nr 11, caller_name WZ
2018.08.08 19:24:08 4: sipclient[834], cb_create : INVITE
2018.08.08 19:24:08 5: sipclient[834], cb_invite_wfp
2018.08.08 19:24:08 4: sipclient[834], SIP_invite -> ringing 1
2018.08.08 19:24:08 5: sipclient, readingB:caller Val:WZ sip:11@192.168.10.17
2018.08.08 19:24:08 5: sipclient, readingB:caller_nr Val:11
2018.08.08 19:24:08 5: sipclient, readingB:caller_name Val:WZ
2018.08.08 19:24:08 5: sipclient, readingB:caller_time Val:0
2018.08.08 19:24:08 5: sipclient, readingB:caller_state Val:calling
2018.08.08 19:24:09 5: sipclient, readingS:caller_state Val:ringing 1
2018.08.08 19:24:09 5: sipclient[834], cb_invite_wfp action fetch
2018.08.08 19:24:09 4: sipclient[834], cb_invite_wfp fetch
2018.08.08 19:24:09 5: sipclient, readingS:caller_state Val:fetching
2018.08.08 19:24:09 5: sipclient[834], cb_est_wfp
2018.08.08 19:24:49 5: sipclient, listen process 834 found
2018.08.08 19:25:49 5: sipclient, listen process 834 found
D.h. es betrifft nur den Listen Modus bei wfp und du verwendst die neuste Version V1.91 ?
Korrekt, es betrifft nur den Listen Modus bei wfp und ich verwende auch die Version 1.91.
OK, ich kann am WE mal eine Version machen die bei wfp noch mehr loggt , die wird dann zwar den Nachteil haben das sie nicht automatisch auflegt nachdem das Audiofile abgespielt wurde, sollte aber zur Fehlersuche egal sein.
Das wäre klasse, vielen Dank!
Zitat von: thunder1902 am 02 Juli 2018, 12:06:15
Hallo! Ich habe das Problem, dass die Soundausgabe nicht funktioniert. Das initiieren von einem Anruf geht - wenn ich aber rangehe kommt kein Ton. Nach ein paar Sekunden wird einfach wieder aufgelegt.
Kann mir da jemand helfen?
Hier mein Device:
defmod telsip SIP
attr telsip T2S_Device mytts
attr telsip T2S_Timeout 10
attr telsip audio_converter sox
attr telsip sip_dtmf_loop once
attr telsip sip_dtmf_send audio
attr telsip sip_dtmf_size 2
attr telsip sip_elbc yes
attr telsip sip_from sip:*****2@192.168.178.2
attr telsip sip_ip ***
attr telsip sip_listen none
attr telsip sip_port 5060
attr telsip sip_registrar 192.168.178.2
attr telsip sip_ringtime 3
attr telsip sip_user t****
attr telsip verbose 5
setstate telsip initialized
setstate telsip 2018-07-02 11:02:42 call done
setstate telsip 2018-07-02 11:02:42 call_attempt 0
setstate telsip 2018-07-02 11:02:42 call_state ok
setstate telsip 2018-07-02 11:02:42 call_success 1
setstate telsip 2018-07-02 11:02:42 call_time 14
setstate telsip 2018-06-29 12:53:51 caller reject
Hier das Log:
2018.07.02 11:02:28 4: telsip, audio file cache/test.alaw found
2018.07.02 11:02:28 4: telsip, telsip|08****|30|cache/test.alaw|0
2018.07.02 11:02:28 4: telsip, call -> telsip|08****|30|cache/test.alaw|0|0
2018.07.02 11:02:28 5: telsip, call has pid 1100
2018.07.02 11:02:28 4: telsip[1100], my parent is 43
2018.07.02 11:02:28 4: telsip[1100], trying to use port 5070
2018.07.02 11:02:28 4: telsip[1100], register new expire : 2018-07-02 11:07:28
2018.07.02 11:02:28 5: telsip, readingS:state Val:calling
2018.07.02 11:02:28 4: telsip[1100], CallStart with 1 files - first file : cache/test.alaw - PCMA/8000 , repeat 0
2018.07.02 11:02:28 4: telsip[1100], calling : 08*******
2018.07.02 11:02:28 4: telsip[1100], cb_final - status : FAIL - final : 481
2018.07.02 11:02:28 5: telsip, readingS:call_state Val:calling 08*********
2018.07.02 11:02:28 5: telsip, readingS:call_state Val:ringing
2018.07.02 11:02:39 4: telsip[1100], cb_final - status : OK
2018.07.02 11:02:39 4: telsip[1100], call established
2018.07.02 11:02:39 5: telsip, readingS:call_state Val:established
2018.07.02 11:02:42 5: telsip[1100], 0. Ende des ersten Loops
2018.07.02 11:02:42 5: telsip[1100], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], 2. fi : 0
2018.07.02 11:02:42 5: telsip[1100], 4. timeout : 0
2018.07.02 11:02:42 5: telsip[1100], 6. call_established : 1
2018.07.02 11:02:42 5: telsip[1100], call->bye
2018.07.02 11:02:42 5: telsip[1100], RTP done : Net::SIP::Simple::Call=HASH(0x46f3fd0)
2018.07.02 11:02:42 5: telsip[1100], Timeout : 0
2018.07.02 11:02:42 5: telsip[1100], while : 0
2018.07.02 11:02:42 5: telsip[1100], Status : OK
2018.07.02 11:02:42 4: telsip, CALLDone -> telsip|1|ok
2018.07.02 11:02:42 5: telsip, fifo is empty
2018.07.02 11:02:42 5: telsip, no elbc
Hast du doppeltes NAT oder eine Firewall?
Hallo,
ich habe mir heute das SIP Modul installiert, bekomme aber keine Verbindung zur Fritzbox.
Der SIP Client wird offenbar an der Fritte nicht registriert. Ich habe eine FB7412 mit OS 6,83.
Das SIP Gerät ist auf der Fritte wie folgt eingerichtet:
Benutzername: SonosPhone
Kennwort: 12345678
Registrar: 172.16.20.10
Telefonname und Benutzername sind gleich.
In fhem sieht es so aus:
defmod SonosPhone SIP
attr SonosPhone history_file ./log/SonosPhone.sip
attr SonosPhone history_size 0
attr SonosPhone sip_dtmf_loop once
attr SonosPhone sip_dtmf_send audio
attr SonosPhone sip_dtmf_size 2
attr SonosPhone sip_elbc yes
attr SonosPhone sip_from sip:SonosPhone@172.16.20.10
attr SonosPhone sip_ip 172.16.30.9
attr SonosPhone sip_listen none
attr SonosPhone sip_port 5060
attr SonosPhone sip_registrar 172.16.20.10
attr SonosPhone sip_ringtime 3
attr SonosPhone sip_user SonosPhone
setstate SonosPhone initialized
setstate SonosPhone 2018-08-14 12:34:15 call 612
setstate SonosPhone 2018-08-14 12:02:57 call_attempt 0
setstate SonosPhone 2018-08-14 12:34:15 call_state invite
setstate SonosPhone 2018-08-14 12:02:57 call_success 0
setstate SonosPhone 2018-08-14 12:02:57 call_time 0
setstate SonosPhone 2018-08-14 12:18:15 caller reject
setstate SonosPhone 2018-08-14 12:02:57 last_error CallRegister: Failed with code 404
setstate SonosPhone 2018-08-14 12:36:20 listen_alive no
setstate SonosPhone 2018-08-14 12:36:20 state initialized
Ich habe weitere SIP Clients in diversen internen SubNetzen laufen aber den fhem Client kriege ich nicht ans Fliegen.
Das Einzige, was im Log steht, wenn ich intern 612 anrufen, ist:
Can't use string ("**612") as a HASH ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Simple.pm line 379.
Hat jemand eine IDee, an welcher Schraube ich drehen muss?
Christian
NACHTRAG:
Habe sip_listen auf wfp gestellt und zumindest werden eingehende Anrufe erkannt. Wie kann ich aber einen Call absetzten?
hatten wir hier schon X-fach , Net::SIP ist zu alt -> https://forum.fhem.de/index.php/topic,80206.msg725755.html#msg725755
Zitat von: plin am 12 Juli 2018, 21:18:56
Als sip_ip gibst Du die Adresse Deines Containers an: 172.17.0.2
Also, das Modul läuft jetzt im Docker-Container... die Ports sind offen und erreichbar...
Leider registriert es sich immer mit der Container-IP beim Server (FreePbx)... und ist damit unerreichbar für diesen...
Kann mir bitte jemand mit einer Fritzbox sagen, mit welcher IP sich das Modul dort registriert? Die Container-IP oder Host-IP ?
Ralf
Moin,
@wzut
naja, ich mag ein wenig blind sein, aber ich habe den ganzen Kram vor zwei Stunden installiert. Und zwar so, wie es im wiki steht:
Für den Remote-Zugang muss das Modul Net::SIP installiert sein; auf einem Raspberry Pi oder unter Ubuntu z. B. mit dem Befehl
sudo cpan install Net::SIP
oder auch
sudo apt-get install libnet-sip-perl
Und ich habe die zweite Option gewählt. Was ist daran falsch? Was habe ich übersehen?
Christian
apt-get ist ok wenn der Unterbau "neu" genug ist ( IMHO ab Jessie ),
Wheezy brachte i.d.R. eine Net::SIP Version 0.6x mit.
Hi,
und wie kriege ich das jetzt raus, welche Version das ist?
Wenn die Version dann zu alt ist, kann ich das dann mit "sudo cpan install Net::SIP" übernudeln?
Danke Dir,
Christian
NACHTRAG:
Ich habe 7.11 und das ist Wheezy. Bleibt die Frage mit dem drübernudeln, oder wie soll ich vorgehen?
Kannst du versuchen, falls cpan install schief geht hilft vllt https://forum.fhem.de/index.php/topic,40219.msg421446.html#msg421446
da geht es zwar noch um die 0.6x Version sollte aber auch mit der aktuellen 0.815 Version so klappen, Download unter https://metacpan.org/raw/SULLR/Net-SIP-0.815/lib/Net/SIP.pm?download=1
@Wzut: Konntest du übers WE schon eine neue Version bereitstellen, welche mehr loggt?
Und wäre es vielleicht auch möglich bei einem set call erweiterte SIP-Header wie z.b. einen Wunsch-Ringtone oder "answer-after=0" mitzusenden?
@Wzur,
sorry, ich bin zu blöd! Ich bekomme eine Datei SIP.PM. Das passt doch nicht zu der Anleitung aus dem link zuvor, oder?
Da geht es doch um eine tar-Datei. Was ist denn die SIP.PM-Datei?
Christian
Zitat von: rrr am 14 August 2018, 16:46:48
@Wzut: Konntest du übers WE schon eine neue Version bereitstellen, welche mehr loggt?
Und wäre es vielleicht auch möglich bei einem set call erweiterte SIP-Header wie z.b. einen Wunsch-Ringtone oder "answer-after=0" mitzusenden?
a. leider nein
b. kann ich dir geistig leider nicht folgen. Was soll was bewirken ?
@Spartacus , ja da hbe ich wohl die falsche Zeile kopiert :
https://cpan.metacpan.org/authors/id/S/SU/SULLR/Net-SIP-0.815.tar.gz
Hallo Wzut,
sorry, aber ich bin da nicht so der Linux-Mensch. hat aber jetzt geklappt, Danke für Deine Hilfe.
Ich würde diese Anleitung ins WIKI aufnehmen, oder zumindest darauf verweisen!
Mir ist auch noch ein weiterer Punkt im Wiki aufgefallen:
Das DOIF funzt bei mir mit diesem Code nicht:
(([HaustuerStatus:state] eq "closed") and ([FhemSipClient:caller_state] eq "ringing.*")
Ich habe es in
...caller_state] =~ "ringing")
abgeändert und dann ging es!
Christian
Zitat von: Wzut am 14 August 2018, 17:46:04
b. kann ich dir geistig leider nicht folgen. Was soll was bewirken ?
@Wzut: In Asterisk wäre bspw. durch "SIPAddHeader(Alert-Info: <http://127.0.0.1/Ringer2)" die Auswahl des Klingeltons Nr. 2 am anzurufenden Telefon möglich.
Es wäre klasse wenn das direkt bei einem "set call" mit dem SIP-Modul funktionieren würde...
also laut Net:SIP Doku gibt es
sip_header: hashref of SIP headers to add
wird gefüttert mit key, value
key wäre dann wohl Alert-Info und value eine URL in der Form http://127.0.0.1/Ringer3
Ich habe keine Ahnung ob die Fritzbox damit klar kommen würde und ob es dann möglich wäre auf einem FritzPhone einen bestimmten Klingelton auszuwählen.
wegen deinem wfp Logging, schau mal ins Modul die entsprechende Zeile ist noch auskommentiert drin
#cb_rtp_done => \&$rtp_done, #sub {Log3 $name, 5, "$logname, wfp cb_rtp_done";}, #ACHTUNG : client legt dann nicht mehr auf !!
kannst sie ja mal übernehmen als
cb_rtp_done => sub {Log3 $name, 5, "$logname, wfp cb_rtp_done";},
danke für das Modul. Konnte das mit einigen, aber überschaubaren Startschwierigkeiten zum Laufen bringen.
Frage: ist es möglich, dass fhem über 96_SIP ein anderen Anschluss (z.B. **610@fritz.box) anruft und dann auf einen DTMF-Code vom angerufenen Telefon wartet?
P.
Könnte man garantiert machen, aber den Anwendungsfall hatten wir hier bisher nicht. Beschreib doch mal genauer was du vorhast vllt. lässt es sich ja auch anders mit Bordmitteln lösen.
BTW: @rrr, wenn du hier noch mitliest : Ich habe das mal mit dem zusätzlichen Alert-Info Header und einem Fritz DECT Fon probiert.
Ging leider nicht. Bevor ich nun Wireshark anwerfe und mich durch Telegramme wühle : Hast du die Ausstattung die mit Sicherheit die Auswahl eines Klingeltons erlaubt ?
Zitat von: Wzut am 15 August 2018, 16:42:43
wegen deinem wfp Logging, schau mal ins Modul die entsprechende Zeile ist noch auskommentiert drin
#cb_rtp_done => \&$rtp_done, #sub {Log3 $name, 5, "$logname, wfp cb_rtp_done";}, #ACHTUNG : client legt dann nicht mehr auf !!
kannst sie ja mal übernehmen als
cb_rtp_done => sub {Log3 $name, 5, "$logname, wfp cb_rtp_done";},
Ich hab die Zeile übernommen, und FHEM neu gestartet, aber dadurch wurde leider auch nicht mehr geloggt...
Zitat von: Wzut am 17 August 2018, 19:32:23
BTW: @rrr, wenn du hier noch mitliest : Ich habe das mal mit dem zusätzlichen Alert-Info Header und einem Fritz DECT Fon probiert.
Ging leider nicht. Bevor ich nun Wireshark anwerfe und mich durch Telegramme wühle : Hast du die Ausstattung die mit Sicherheit die Auswahl eines Klingeltons erlaubt ?
Ich habe keine Fritzbox sondern benutze Asterisk mit snom Telefonen. Ich habe auch bereits zusätzliche Header per Telnet/SSH an den Asterisk-Server gesendet, welche die snom-Telefone dann problemlos auswerten.
Darum ja meine Frage, such mal im Modul die Sub SIP_CallStart
sub SIP_CALLStart($)
{
my ($arg) = @_;
dann ein paar Zeilen runterscrollen und nach my $ph_ok = 0; fügst du den zusätzlichen Header ein
my %header;
$header{'Alert-Info'} = '<http://127.0.0.1/Ringer2>';
oder wie halt dein zusätzlicher Header eben aussehen soll, laut div Anleitungen will Asterisk das als Pseudo Url , Cisco Telephone nur den Namen der Sound Datei
aber das wirst du am besten wissen. Damit der zusätzliche Header bei einem ausgehenden Ruf auch gesendet wird must du weiter im Quelltext runterscrollen bis der Abschnitt $call = $ua->invite( $nr, kommt. Darunter eine neue Zeile einfügen
sip_header => \%header,
dann weiter runter nach ein paar Zeilen kommt nochmal $call = $ua->invite($nr,
auch hier wieder die sip_header => \%header, Zeile einfügen und speichern. Nach einem reload 96_SIP mach einen Versuch mit einem Anruf.
Sollte es nicht klappen muß Wireshark ran und ggf. muß man bei Steffen Ullrich mal anfragen wie genau man den zusätzlichen Header einbauen muß.
Hat schon mal jemand erfolgreich über einen externen SIP-Server "angerufen" (z.B. sipgate.de)? Ich versuch das grad - leider erfolglos ... :(
Ich bekommen im log immer eine der folgenden Fehlermeldungen:
- Can't use string ("favicon") as a HASH ref while "strict refs" in use at /usr/local/share/perl/5.20.2/Net/SIP/Dispatcher.pm line 1108.
- Can't use string ("fhemicon.png") as a HASH ref while "strict refs" in use at /usr/local/share/perl/5.20.2/Net/SIP/Dispatcher.pm line 1108.
und wieder einer ? Eine Seite zurück ab meinem Posting #482 ... und gleiche die Frage : welche Version von Net::SIP ist installiert ?
Zitat von: Wzut am 18 August 2018, 08:09:43
Darum ja meine Frage, such mal im Modul die Sub SIP_CallStart
sub SIP_CALLStart($)
{
my ($arg) = @_;
dann ein paar Zeilen runterscrollen und nach my $ph_ok = 0; fügst du den zusätzlichen Header ein
my %header;
$header{'Alert-Info'} = '<http://127.0.0.1/Ringer2>';
oder wie halt dein zusätzlicher Header eben aussehen soll, laut div Anleitungen will Asterisk das als Pseudo Url , Cisco Telephone nur den Namen der Sound Datei
aber das wirst du am besten wissen. Damit der zusätzliche Header bei einem ausgehenden Ruf auch gesendet wird must du weiter im Quelltext runterscrollen bis der Abschnitt $call = $ua->invite( $nr, kommt. Darunter eine neue Zeile einfügen
sip_header => \%header,
dann weiter runter nach ein paar Zeilen kommt nochmal $call = $ua->invite($nr,
auch hier wieder die sip_header => \%header, Zeile einfügen und speichern. Nach einem reload 96_SIP mach einen Versuch mit einem Anruf.
Sollte es nicht klappen muß Wireshark ran und ggf. muß man bei Steffen Ullrich mal anfragen wie genau man den zusätzlichen Header einbauen muß.
Leider funktioniert es damit nicht. Das Telefon bleibt beim Standard-Ringtone...
Weißt Du schon, warum das Logging nicht mehr Einträge produziert, wenn ich
cb_rtp_done => sub {Log3 $name, 5, "$logname, wfp cb_rtp_done";},
einkommentiere?
Zitat von: rrr am 19 August 2018, 17:50:02
Leider funktioniert es damit nicht. Das Telefon bleibt beim Standard-Ringtone...
Weißt Du schon, warum das Logging nicht mehr Einträge produziert,
a. das hatte ich befürchtet :( , d.h. nun muß Wireshark ran um zu sehen ob der zusätzliche Header überhaupt im Telegramm auftaucht.
Wenn ja , kann nur ein Fehler in der Syntax sein. Wenn nein muß wohl Steffen Ullrich angefragt werden.
b. da sieht dann aus als ob der ganze RTP Teil bei dir gar nicht erst durchlaufen wird, kein Ton und auch keine Log Ausgabe dazu. Sorry hier bin ich dann mit meinem Latein auch am Ende. Hörst du denn etwas wenn du kein sip_audiofile_wfp angibst ? Und welche Hardware verwendest du mit welchem OS und welcher Version von Net::SIP ?
Wenn kein sip_audiofile_wfp Attribut gesetzt ist, ist auch nichts zu hören. Der Anruf wird dann kurz nach Annahme beendet. Merkwürdig ist ja, dass je nach Länge des Audio-Files auch die Haltezeit des Anrufs variiert.
FHEM läuft auf Debian 9.4 (Raspberry 3 B). Net::SIP Version der Distri (libnet-sip-perl) ist 0.808
Hallo,
ist denn auch die Nutzung eines SIP-Anbieters möglich, z.B. SIPGATE? Oder geht das Ganz nur mit der FritzBox? Falls es mit SIPGATE geht: Wie muss man denn dann die Zugangsdaten eintragen?
Vielen Dank
Frank
Ein Thread reicht völlig -> https://forum.fhem.de/index.php/topic,90317.msg828721.html
Zitat von: Kilitom am 19 August 2018, 13:36:51
Ich bekommen im log immer eine der folgenden Fehlermeldungen:
- Can't use string ("favicon") as a HASH ref while "strict refs" in use at /usr/local/share/perl/5.20.2/Net/SIP/Dispatcher.pm line 1108.
- Can't use string ("fhemicon.png") as a HASH ref while "strict refs" in use at /usr/local/share/perl/5.20.2/Net/SIP/Dispatcher.pm line 1108.
poste mal ein list von deinem SIP device, vllt hängst du an der gleichen Stelle wie ich bei sipgate -> https://forum.fhem.de/index.php/topic,90317.msg828799.html#msg828799
Hallo,
habe hier einen "Schönheitsfehler" im Log. Das Modul funktioniert völlig normal. Vielleicht muss ich ja nur noch irgendwo etwas konfigurieren?
Den FQDN des FHEM- Servers habe ich schon "ordentlich gemacht" und "hostname" oder "hostname -f" brigen sinnvolle Ausgaben.
Logausgabe:
10:21:43 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2018.08.28 10:21:43 2: mySIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.
List:
Internals:
AC /usr/bin/sox
NAME mySIP
NOTIFYDEV myTTS
NR 2197
NTFY_ORDER 50-SIP_FMF
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
READINGS:
2018-08-28 10:24:27 call done
2018-08-28 10:24:27 call_attempt 0
2018-08-28 10:24:27 call_state ok
2018-08-28 10:24:27 call_success 1
2018-08-28 10:24:27 call_time 3
2018-08-20 08:59:47 expire 2018-08-20 09:04:45
2018-08-28 10:22:03 listen_alive no
2018-08-28 10:24:27 state initialized
helper:
CALL_BYE ok
CALL_ERROR 1
CALL_NAME unknown
CALL_NR xxxxxxxxxxxxxx
CALL_START xxxxxxxxxxxx
CALL_TIME 3
CALL_TYPE out
Attributes:
T2S_Device myTTS
T2S_Timeout 30
audio_converter sox
history_file ./log/mySIP.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:620@fritz.box
sip_ip 192.168.1.30
sip_listen none
sip_port 5060
sip_registrar 192.168.1.1
sip_ringtime 8
sip_user 620
verbose 1
Vielen Dank für Eure Unterstützung!
hmm, sollte eigentlich gar nicht durchlaufen werden wenn das Attribut sip_ip gesetzt ist
Genau das hatte ich beim Versuch den Code in diesem Bereich zu verstehen auch gedacht, war mir aber nicht sicher.
Was ich noch beobachtet habe: Wenn ich das Attr. "sip_ip" lösche und save + resarte, legt das Modul "sip_ip" mit korrekter IP wieder neu an (löst also den FQDN richtig auf), bringt die Meldung aber trotzdem.
ja mein Fehler, der ganze Block steht einfach an der falschen Stelle,
D.h. einfach zu früh im Code und da ist $attr{$name} noch gar nicht besetzt, fixe ich mit der nächsten Version
THX4Feedback
THX4Fixing ! :)
frage in die Runde:
gemäss Wiki braucht es einen SIP Server. Dies habe ich. Aber ich habe weder Fritzbox noch sonstwas (auch keinen "Telefonhörer"), sondern eine Swisscom Box und einen Raspi3 (resp. 2stk davon). Ich will lediglich Raspi3 via SIP Server dazu nutzen, bei Alarm auf meine Mobile anzurufen. Sonst nix. Ist das mit dem Server IP, Benutzername und PW machbar? Auf Anhieb hat es nicht geklappt.
lg c
Nun ich kenne deine Swisscom Box nicht, aber der SIP Server muss nicht unbedingt eine FB sein.
Alternative 1 : Asterisk auf einem deiner Raspberrys aufsetzen
Alternative 2 : Bei sipgate mit dem kostenlosen Basic Tarif sich eine Rufnummer aus dem Ortsnetz registrieren ( geht IMHO auch für die Schweiz ),
nach Aufladung des Kontos mit 10€ und bestätigung deines Accounts kannst du mit dieser Nr. deine Handys mit dem FHEM Modul anrufen.
Edit : die Swisscom Box sollte es auch können -> https://www.swisscom.ch/de/privatkunden/hilfe/festnetz/sip.html
Zitat von: Wzut am 21 September 2018, 07:48:26
Nun ich kenne deine Swisscom Box nicht, aber der SIP Server muss nicht unbedingt eine FB sein.
Alternative 1 : Asterisk auf einem deiner Raspberrys aufsetzen
Alternative 2 : Bei sipgate mit dem kostenlosen Basic Tarif sich eine Rufnummer aus dem Ortsnetz registrieren ( geht IMHO auch für die Schweiz ),
nach Aufladung des Kontos mit 10€ und bestätigung deines Accounts kannst du mit dieser Nr. deine Handys mit dem FHEM Modul anrufen.
da ich bei Swisscom keine Fixnummer habe, versuche ich es mit Alternative 2. Ich habe das Konto eröffnet, mit 25CHF aufgeladen und das Modul auf meinem Raspi 3 installiert. Es scheint jedoch nicht zu funktionieren. Hier mein Listing:
Internals:
CFGFN
NAME SIP
NOTIFYDEV global
NR 902
NTFY_ORDER 50-SIP
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
lastnr meineHandyNr
READINGS:
2018-09-21 09:33:30 call meine HandyNr
2018-09-20 20:52:26 call_attempt 0
2018-09-21 09:33:31 call_state calling meineHandyNr
2018-09-20 20:52:26 call_success 0
2018-09-20 20:52:26 call_time 0
2018-09-20 20:52:26 last_error CallRegister: Failed with code 403
2018-09-21 09:34:31 listen_alive no
2018-09-21 09:34:31 state initialized
helper:
CALL SIP|0794538540|30||0|0
CALL_BYE CallRegister: Failed with code 403
CALL_ERROR 0
CALL_NAME unknown
CALL_NR 0794538540
CALL_START 1537515210
CALL_TIME 0
CALL_TYPE out
Attributes:
history_file ./log/SIP.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:meineUSERID@free3.voipgateway.org
sip_ip meineRaspiIP
sip_listen none
sip_port 5060
sip_registrar free3.voipgateway.org
sip_ringtime 3
sip_user meineUSERID
verbose 5
im Log kommt folgendes:
2018.09.21 09:33:30 4: SIP, calling meineHandyNr, ringtime: 30 , no message
2018.09.21 09:33:30 4: SIP, SIP|meineHandyNr|30||0
2018.09.21 09:33:30 4: SIP, call -> SIP|meineHandyNr|30||0|0
2018.09.21 09:33:30 5: SIP, call has pid 4846
2018.09.21 09:33:30 4: SIP[4846], my parent is 659
2018.09.21 09:33:30 4: SIP[4846], trying to use port 5070
2018.09.21 09:33:31 4: SIP[4846], register new expire : 2018-09-21 09:34:11
2018.09.21 09:33:31 5: SIP, readingS:state Val:calling
2018.09.21 09:33:31 4: SIP[4846], CallStart DTMF : ABCD*#123--4567890
2018.09.21 09:33:31 4: SIP[4846], calling : meineHandyNr
2018.09.21 09:33:31 5: SIP, readingS:call_state Val:calling meineHandyNr
2018.09.21 09:33:31 4: SIP[4846], cb_final - status : FAIL - final : 488
2018.09.21 09:33:51 4: SIP[4846], register new expire : 2018-09-21 09:35:01
2018.09.21 09:33:51 5: SIP, readingS:state Val:calling
2018.09.21 09:34:01 5: SIP[4846], 0. Ende des ersten Loops
2018.09.21 09:34:01 5: SIP[4846], 1. rtp_done : 0
2018.09.21 09:34:01 5: SIP[4846], 2. fi : 0
2018.09.21 09:34:01 5: SIP[4846], 3. Final : 488
2018.09.21 09:34:01 5: SIP[4846], 4. timeout : 1
2018.09.21 09:34:01 5: SIP[4846], 6. call_established : 0
2018.09.21 09:34:01 5: SIP[4846], call->cancel
2018.09.21 09:34:26 4: SIP[4846], register new expire : 2018-09-21 09:34:56
2018.09.21 09:34:26 5: SIP, readingS:state Val:calling
2018.09.21 09:34:31 4: SIP, CALL Kill PID : 4846
2018.09.21 09:34:31 1: Timeout for SIP_CALLStart reached, terminated process 4846
2018.09.21 09:34:31 4: SIP, Reset Call done
Wenn ich vom Handy meine sipcall Nr anrufe passiert auch nix...
Deine Attribute sehen gut aus, die Anmeldung am SIP Server scheint laut log auch zu klappen.
Telefonieren konnte ich mit meinem sipgate.de Account auch nicht sofort, ich musste drei Tage warten bis per Post der Brief mit dem Freischaltcode kam. Keine Ahnung ob das dein Provider auch so macht, ich kann leider von hier keine einzige Webseite von voipgateway.com öffnen um mal in deren Anleitungen lesen zu können.
Zitat von: Wzut am 21 September 2018, 11:26:32
Deine Attribute sehen gut aus, die Anmeldung am SIP Server scheint laut log auch zu klappen.
Danke Wzut, ich habe mal bei SipCall ein Ticket eröffnet. Mal schauen, wie schnell die reagieren.
Woran erkennst du am Log, dass die Anmeldung beim SIP Server geklappt hat?
lg c
Lade dir doch mal einen SIP Client aufs Handy , wie z.B. linphone dann kannst du recht gut deinen Provider testen und bekommst ggf. auch mehr Unterstützung von ihm als wenn du sagst mein FHEM Modul will nicht :) ( Hatte ich auch gemacht nachdem mein erfster Versuch mit sipgate fehlgeschlagen war)
Das deine User Auth vermutlich klappt sieht man im Log :
2018.09.21 09:33:31 4: SIP[4846], register new expire : 2018-09-21 09:34:11
es gäbe kein expire ohne das der Schritt erfolgreich war. Kannst ja mal testen, setze im Attribut einen falschen Usernamen oder Passwort und schau dann auf den Log Abschnitt, es dürft dann nie zu
2018.09.21 09:33:31 5: SIP, readingS:state Val:calling
kommen
Bzw. was du noch machen kannst wenn dein Provider eine Webseite für dich hat wo du deine Geräte siehst :
Starte mal einen listen Mode in irgend einem Modus. Bei sipgate sieht man dann nach ca. zwei Minuten das dieser User aktiv ist. Und nur dann wäre ein Test bei dem du via Handy diese Nr. anrufst überhaupt möglich.
Herzlichen Dank für deine Mühe. Ich bin ein Schritt weiter.
Der Support hat sich gemeldet:
Wir haben Ihr anliegen analysiert.
Der Grund dafür weshalb die Rufnummer 41meineRufnummer eingehend nicht erreichbar ist besteht darin, dass für diese keine gültige Registration vorhanden ist.
Dadurch können eingehende Anrufe nicht zu Ihrem Endgerät geroutet werden.
Die Letzte Registrationsanfrage erhielten wir von Ihrem Endgerät erhielten wir heute um 09:34 Uhr. Danach kamen keine Registrationsanfragen mehr zu unserem System.
Dies deutet entweder darauf hin, dass das Endgerät schon gar keine solche mehr versendet oder die Pakete jeweils ausgehend in der Firewall hängen bleiben.
Wenn ich nun auf ,,set SIP listen" gehe, dann kann ich auf die Nummer anrufen, das sehe ich im Eventmonitor. Das scheint zu klappen.
Wenn ich doch empfangen kann, sollte es doch auch nach aussen telefonieren können? Irgendwas klappt noch nicht..
Soll ich trotzdem mit einem iPhoneClient linephone versuchen?
linphone auf dem Handy bringt dir IMHO jetzt nichts mehr, der Weg von aussen nach innen steht ja.
Du kannst natürlich jetzt linphone auf einem deiner PCs oder Tablets installieren zum testen der Gegenrichtung. Ich vermute dein Prob aber eher bei deiner Swisscom Box :
Kann es sein das sie SIP von innen nach aussen blockt , Stichwort Firewall ? (bei der FB gibt es so eine versteckte gemeine Option)
Es hat geklappt! ! Yeah..
Und zwar durch eine Fehlmanipulation meinerseits. Ich habe einfach ,,set SIP call meineNr" gemacht, was unvollständig war. Mit ,,set SIP call meineNr 30 !So gehts" hat es funktioniert. Wer lesen kann ist im Vorteill. :)
Wo ich immer noch definitiv anecke, ist, dass nach dem ausgehenden Call immer ein reset danach gemacht werden muss, damit er aus dem calling status rauskommt. Ist das normal? Oder hab ich wieder was überlesen? ;)
Nein normal ist das nicht !
Der einzige Unterschied zwischen set SIP call meineN und set SIP call meineNr 30 !So gehts ist das bei der ersten Variante ein paar DTMF Töne gesendet werden und beim anderen der Text "so gehts". Die Überwachungszeit beträgt jedesmal 30 Sekunden. Klarheit kann hier wieder nur ein verbose 5 Log schaffen.
Ich würde drei Veruuche loggen , nimn jedsmal set SIP call meineNr 10 !Irgend ein Text
1. sofort abnehmen und den Text anhöhren
2. beim ersten Klingeln wegdrücken
3. klingeln lassen bis die 10 Sekunden um sind , d.h. gar nicht rangehen
Hallo zusammen,
Wollte mal fragen ob das Modul hier jemand im Zusammenhang mit dem Gira tk Gateway nutzt. Die Verknüpfung mit den dortigen einstellcodes krieg ich irgendwie nicht hin. Warum das ganze?
Fände es chic wenn ich das Haus verlasse die Einstellungen der hausklibgel zu ändern. Aktuell kriege ich ein Foto und ein Hinweis über Telegram, danach Schellen die Telefone. Wenn ich nicht da bin möchte ich aber statt die Telefone eine Weiterleitung zum Handy. Eine Umschaltung müsste per dmft klappen aber in Verbindung mit dem Modul kriege ich da nicht hin. Falls wer ähnliche Ambitionen hat gerne melden :)
Du müsstest halt schon verraten was du bisher gemacht hast (inkl list vom Device und verbose 5 Log). DTMF senden sollte im Gegensatz zum Empfang kein Problem sein.
Gegensprechanlagen via DTMF umschalten hatten wir hier schon, ggf. muss man mit Pausen vor und zwischen den Tönen arbeiten.
Es gab auch schon Leute die haben die DTMF Tonfolge aufgezeichnet und dann mit dem Modul einfach als Audiofile zur Anlage geschickt.
Moin und hallo!
Zitat von: Wzut am 23 September 2018, 08:17:36
Du müsstest halt schon verraten was du bisher gemacht hast (inkl list vom Device und verbose 5 Log). DTMF senden sollte im Gegensatz zum Empfang kein Problem sein.
Gegensprechanlagen via DTMF umschalten hatten wir hier schon, ggf. muss man mit Pausen vor und zwischen den Tönen arbeiten.
Es gab auch schon Leute die haben die DTMF Tonfolge aufgezeichnet und dann mit dem Modul einfach als Audiofile zur Anlage geschickt.
Dann mal ausführlicher :)
hier im Thread gab es schonmal eine ähnliche Frage.
Ich habe ein Türgateway, auf welches ich mich mit dem Fritzfon einwählen kann.
Dazu wähle ich **2 und warte ca. 1-2 Sekunde auf den "Kommandomoduston".
Ist dieser da kann ich dann Einstellungen vornehmen z.B. Varianten umschalten Nummern ändern etc.
Um z.B. Die Masterumleitungsnummer zu ändern müsste ich dann eingeben *1*01701234567# um auf die Nummer 01701234567 zu ändern.
Gebe ich alles hinternander im Telefon ein also: **2*1*01701234567# funktioniert dies nicht, da wohl die Pause nach **2 nicht eingehalten wird.
Im Thread hier wurde jemand empfohlen beim SIP Modul mit "," Pausen einzufügen, aber das klappt mit dem Modul nicht.
Warum möchte ich das? Weil z.B. je nach An oder Abwesenheit meine Türstation auf andere Nummern weiterleiten soll. Ich muss also irgendwie hinbekommen diesen "call" funktionierend abzusetzen. Alternativ könnte ich einfach eine interne Rufnummer z.B. *504 anrufen und in der Fritzbox dort den "Code" im Telefonbuch hinterlegen, aber dort ist es ebenfalls nicht möglich Pausen einzutragen.
Vielleicht kann mir hier jmd weiterhelfen?
Folgendes hat leider NICHT funktioniert
set SIP call ...
... **2*1*01701234567#
... 10 **2,,,,,*1*01701234567#
... **2,,,,,*1*01701234567#
... **2----*1*01701234567#
... **2-*1*01701234567#
[edit]
habe aus baulichen Gründen den Anschluss des Gateway auf Fon1 gelegt dahr müsste es jetzt immer mit **1 statt **2 anfangen.
Ein Verbose 5 Auszug einer Variante:
2018.09.23 11:25:23.522 4: FRITZ_SIP, calling **1----*1*123456#, ringtime: 30 , no message
2018.09.23 11:25:23.527 4: FRITZ_SIP, FRITZ_SIP|**1----*1*123456#|30||0
2018.09.23 11:25:23.552 4: FRITZ_SIP, call -> FRITZ_SIP|**1----*1*123456#|30||0|0
2018.09.23 11:25:23.553 5: FRITZ_SIP, call has pid 7465
2018.09.23 11:25:23.575 4: FRITZ_SIP[7465], my parent is 10952
2018.09.23 11:25:23.576 4: FRITZ_SIP[7465], trying to use port 5080
2018.09.23 11:25:23.682 4: FRITZ_SIP[7465], register new expire : 2018-09-23 11:30:23
2018.09.23 11:25:23.687 5: FRITZ_SIP, readingS:state Val:calling
2018.09.23 11:25:23.713 4: FRITZ_SIP[7465], CallStart DTMF : ABCD*#123--4567890
2018.09.23 11:25:23.722 4: FRITZ_SIP[7465], calling : **1----*1*123456#
2018.09.23 11:25:23.723 5: FRITZ_SIP, readingS:call_state Val:calling **1----*1*123456#
2018.09.23 11:25:23.739 4: FRITZ_SIP[7465], cb_final - status : FAIL - final : 481
2018.09.23 11:25:23.740 5: FRITZ_SIP, readingS:call_state Val:ringing
2018.09.23 11:25:24.184 4: FRITZ_SIP[7465], cb_final - Status : OK
2018.09.23 11:25:24.184 4: FRITZ_SIP[7465], call established
2018.09.23 11:25:24.186 5: FRITZ_SIP, readingS:call_state Val:established
2018.09.23 11:25:34.193 5: FRITZ_SIP[7465], 0. Ende des ersten Loops
2018.09.23 11:25:34.193 5: FRITZ_SIP[7465], 1. rtp_done : OK
2018.09.23 11:25:34.193 5: FRITZ_SIP[7465], 2. fi : 0
2018.09.23 11:25:34.194 5: FRITZ_SIP[7465], 4. timeout : 0
2018.09.23 11:25:34.194 5: FRITZ_SIP[7465], 6. call_established : 1
2018.09.23 11:25:34.194 5: FRITZ_SIP[7465], call->bye
2018.09.23 11:25:34.217 5: FRITZ_SIP[7465], RTP done : OK
2018.09.23 11:25:34.217 5: FRITZ_SIP[7465], Timeout : 0
2018.09.23 11:25:34.217 5: FRITZ_SIP[7465], while : 0
2018.09.23 11:25:34.218 4: FRITZ_SIP[7465], Calltime : 10
2018.09.23 11:25:34.230 4: FRITZ_SIP, CALLDone -> FRITZ_SIP|1|ok|10
2018.09.23 11:25:34.254 5: FRITZ_SIP, fifo is empty
2018.09.23 11:25:34.254 5: FRITZ_SIP, no elbc
List vom Device:
.oldstate initialized
.reset 0
NAME FRITZ_SIP
NOTIFYDEV global
NR 584
NTFY_ORDER 50-FRITZ_SIP
STATE initialized
TYPE SIP
VERSION V1.9 / 27.07.18
.attraggr:
.attrminint:
READINGS:
2018-09-23 11:25:34 call done
2018-09-23 11:25:34 call_attempt 0
2018-09-23 11:25:34 call_state ok
2018-09-23 11:25:34 call_success 1
2018-09-23 11:25:34 call_time 10
2018-09-22 20:04:06 listen_alive no
2018-09-23 11:25:34 state initialized
helper:
CALL_BYE ok
CALL_ERROR 1
CALL_NAME unknown
CALL_NR **1----*1*123456#
CALL_START 1537694723
CALL_TIME 10
CALL_TYPE out
Attributes:
history_file ./log/FRITZ_SIP.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:xxxxxx@fritz.box
sip_ip 192.168.178.33
sip_listen none
sip_port 5070
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user xxxxxx
verbose 5
dein Aufruf ist falsch , das sieht man auch schön im Log :
Zitat von: Dia81 am 23 September 2018, 11:21:03
2018.09.23 11:25:23.713 4: FRITZ_SIP[7465], CallStart DTMF : ABCD*#123--4567890
2018.09.23 11:25:23.722 4: FRITZ_SIP[7465], calling : **1----*1*123456#
du rufst die Nr **1----*1*123456# an un sendest den default DTMF Code ABCD*#123--4567890
du must aber die **1 anrufen und *01701234567# senden !
Das erste - leitet DTMF ein und jedes weitere erzeugt eine kleine Pause
set call mysip **1 ------*01701234567#
Zitat von: Wzut am 23 September 2018, 11:58:01
dein Aufruf ist falsch , das sieht man auch schön im Log :du rufst die Nr **1----*1*123456# an un sendest den default DTMF Code ABCD*#123--4567890
du must aber die **1 anrufen und *01701234567# senden !
Das erste - leitet DTMF ein und jedes weitere erzeugt eine kleine Pause
set call mysip **1 ------*01701234567#
Danke für deine Antwort aber irgedwie check ich es nicht... das würde doch genau dem Code "**2----*1*01701234567#" entsprechen. Umgesetzt auf den geänderten analogeingang:
**1----*1*01701234567#
Irgendwie sehe ich da gerade kein Unterscheid außer die "Leerzeile" nach dem **1 ...
Versuche ich "
**1 -----*1*487654321#
" meckert Fhem wegen invadlid Maxtime "-----*1*487654321#
Versuche ich
**1 5 -----*1*487654321#
meckert eh nicht aber es klappt auch nicht, die Nummer wird nicht geändert
2018.09.23 12:15:58.616 4: FRITZ_SIP, message DTMF = -----*1*487654321#
2018.09.23 12:15:58.617 4: FRITZ_SIP, FRITZ_SIP|**1|5|-----*1*487654321#|0
2018.09.23 12:15:58.641 4: FRITZ_SIP, call -> FRITZ_SIP|**1|5|-----*1*487654321#|0|0
2018.09.23 12:15:58.642 5: FRITZ_SIP, call has pid 8929
2018.09.23 12:15:58.662 4: FRITZ_SIP[8929], my parent is 10952
2018.09.23 12:15:58.663 4: FRITZ_SIP[8929], trying to use port 5080
2018.09.23 12:15:58.774 4: FRITZ_SIP[8929], register new expire : 2018-09-23 12:20:58
2018.09.23 12:15:58.778 5: FRITZ_SIP, readingS:state Val:calling
2018.09.23 12:15:58.803 4: FRITZ_SIP[8929], CallStart DTMF : ----*1*487654321#
2018.09.23 12:15:58.812 4: FRITZ_SIP[8929], calling : **1
2018.09.23 12:15:58.813 5: FRITZ_SIP, readingS:call_state Val:calling **1
2018.09.23 12:15:58.829 4: FRITZ_SIP[8929], cb_final - status : FAIL - final : 481
2018.09.23 12:15:58.830 5: FRITZ_SIP, readingS:call_state Val:ringing
2018.09.23 12:15:59.235 4: FRITZ_SIP[8929], cb_final - Status : OK
2018.09.23 12:15:59.236 4: FRITZ_SIP[8929], call established
2018.09.23 12:15:59.237 5: FRITZ_SIP, readingS:call_state Val:established
2018.09.23 12:16:03.800 5: FRITZ_SIP[8929], 0. Ende des ersten Loops
2018.09.23 12:16:03.800 5: FRITZ_SIP[8929], 1. rtp_done : 0
2018.09.23 12:16:03.801 5: FRITZ_SIP[8929], 2. fi : 0
2018.09.23 12:16:03.801 5: FRITZ_SIP[8929], 4. timeout : 1
2018.09.23 12:16:03.801 5: FRITZ_SIP[8929], 6. call_established : 1
2018.09.23 12:16:03.801 5: FRITZ_SIP[8929], call->bye
2018.09.23 12:16:03.822 5: FRITZ_SIP[8929], RTP done : 0
2018.09.23 12:16:03.822 5: FRITZ_SIP[8929], Timeout : 1
2018.09.23 12:16:03.823 5: FRITZ_SIP[8929], while : 0
2018.09.23 12:16:03.823 4: FRITZ_SIP[8929], Calltime : 4
2018.09.23 12:16:03.835 4: FRITZ_SIP, CALLDone -> FRITZ_SIP|1|timeout|4
2018.09.23 12:16:03.852 5: FRITZ_SIP, fifo is empty
2018.09.23 12:16:03.853 5: FRITZ_SIP, no elbc
weitere Versuche wie:
**1 10 -------*1--*487654321#
leider ebenfalls erfolglos. Telefontest **1 (kurz warten) *1*487654321# weiterhin erfolgreich
ja die Timeoutzeit muss noch dazwischen, sorry mein Fehler (die Leerzeichen machen den entscheidenden Unterschied zwischen den Varianten)
Deine 5 Sekunden waren zu wenig laut Log, aber dein letztes Beispiel mit den 10 Sekunden schaut so eigentlich gut aus. Ggf kannst du auch noch Pausen nach jedem Zeichen einfügen. Aber auf jeden Fall ruf zu den ersten Tests ein normales Telefon an und höre dir an wie das klingt. bzw nur so erfährst du ob überhaupt DTMF Töne versendet werden. Wie bereits geschrieben bleibt als letzter Ausweg dann immer noch die Option die Tonfolge aufzuzeichen und als komplette Audio Datei an das GW zu schicken.
Zitat von: Wzut am 23 September 2018, 13:13:27
ja die Timeoutzeit muss noch dazwischen, sorry mein Fehler (die Leerzeichen machen den entscheidenden Unterschied zwischen den Varianten)
Deine 5 Sekunden waren zu wenig laut Log, aber dein letztes Beispiel mit den 10 Sekunden schaut so eigentlich gut aus. Ggf kannst du auch noch Pausen nach jedem Zeichen einfügen. Aber auf jeden Fall ruf zu den ersten Tests ein normales Telefon an und höre dir an wie das klingt. bzw nur so erfährst du ob überhaupt DTMF Töne versendet werden. Wie bereits geschrieben bleibt als letzter Ausweg dann immer noch die Option die Tonfolge aufzuzeichen und als komplette Audio Datei an das GW zu schicken.
OK dann teste ich mit den Infos nochmal rum... wieviel Pause macht ein "-" denn ?
Hat sich beantwortet die Frage. Habe mein Telefon angerufen und es kommen ach alle zu erwartenden Töne.
Noch mal EDIT: es klappt jetzt. Super lieben Dank:
**1 20 ------*-1-*-4-8-7-6-5-4-3-2-1-#
Zitat von: Wzut am 22 September 2018, 08:46:32
Nein normal ist das nicht !
Der einzige Unterschied zwischen set SIP call meineN und set SIP call meineNr 30 !So gehts ist das bei der ersten Variante ein paar DTMF Töne gesendet werden und beim anderen der Text "so gehts". Die Überwachungszeit beträgt jedesmal 30 Sekunden. Klarheit kann hier wieder nur ein verbose 5 Log schaffen.
Ich würde drei Veruuche loggen , nimn jedsmal set SIP call meineNr 10 !Irgend ein Text
1. sofort abnehmen und den Text anhöhren
2. beim ersten Klingeln wegdrücken
3. klingeln lassen bis die 10 Sekunden um sind , d.h. gar nicht rangehen
Also, es funktioniert bei mir nun auch. Keine Ahnung wieso. Evtl. Habe ich eine falsche Telnr. gewählt, denn nur da bleibt er auf ,,calling". Ansonsten läufts nun bestens! Danke Wzut, ein wirklich tolles Modul.
Frisst eigentlich dei Modul viel Ressourcen im Listen-Modus?
Schön das es jetzt geht, aber auch bei einer nicht reagierenden Nummer sollte der Timeout greifen und den Call sauber beenden. Was die Belastung des Systems durch einen aktiven Listen Prozess betrifft kann man nur wie Radio Eriwan (https://de.wikipedia.org/wiki/Radio_Eriwan) antworten : "Im Prinzip nein, aber ..."
D.h. es hängt halt von deinem System ab. Hast du nun Blut geleckt ? denn nach deinen ersten Anforderungen war eigentlich kein aktiver Listen Prozess nötig :)
Zitat von: Wzut am 24 September 2018, 10:34:34
Schön das es jetzt geht, aber auch bei einer nicht reagierenden Nummer sollte der Timeout greifen und den Call sauber beenden.
und wie lange dauert der Timeout. Ich habe eine unvollständige Nummer gewählt (also anstelle von 7 nur 6 Nummern). Es steht seit 5 Min auf "calling". Im Eventmonitor zeigt es mir auch jede Minute SIP Calling an. Ich kann timeout nicht konfigurieren, oder?
Was die Belastung des Systems durch einen aktiven Listen Prozess betrifft kann man nur wie [url=https://de.wikipedia.org/wiki/Radio_Eriwan]Radio Eriwan[/url] antworten : "Im Prinzip nein, aber ..."
ok, dann überlege ich mir, ob ich das auf einen zweiten Raspi3 verschiebe, damit mein Hauptraspi möglichst wenig Ressourcen braucht.
Hast du nun Blut geleckt ? denn nach deinen ersten Anforderungen war eigentlich kein aktiver Listen Prozess nötig :)
Mit dem Apetit kommt der Hunger ;) Eigentlich ist meine Anforderung unverändert, aber ich will halt ein bischen rumspielen und sehen, was alles machbar ist... COol ist das Modul auf jedenfall..! Klasse Arbeit, Wzut.. ;)
Zitat von: choetzu am 24 September 2018, 15:02:19
und wie lange dauert der Timeout.
Das bestimmst du (siehe Doku (https://wiki.fhem.de/wiki/SIP-Client#Anruf_t.C3.A4tigen_und_Sound_abspielen)) :) default ist 30 Sekunden
Edit : ok, unvollständige Nr, habe ich selbst nie probiert. Kann daher gut sein das der Timeout nie kommt.
Ok, das hab ich kapiert ;) aber dann liegts eh an der unvollständigen Nummer. Das muss man dann ein set Sip reset machen..
Guten Morgen Zusammen,
ich habe probiert das Modul bei mir einzurichten.
Leider ohne Erfolg.
Ich bekomme Immer den Fehler 110
Kann jemand damit was anfangen.
hier mal noch ein paar Hintergrund infos:
Ich hab eine Gegensprechanlage in der Fritzbox definiert.
Diese hat auch schon mit der Doorpi zum testen funktioniert.
Den Account von der Gegensprechanlage wollte ich zum Anmelden nehmen.
Bei der Gegensprechanlage wird jeder "Klingeltaste" eine Rufnummer zu gewiesen.
So hat die erste "Klingeltaste" die 11, die zweite 12 usw.
Kann mir jemand Kurz erklären wie hier ein Call aussehen würde?
Gruß Robert
Vermutlich zum 50 Mal : ohne list vom SIP Device und ohne verbose 5 Log (in Code Tags) und ohne zu wissen was denn überhaupt gemacht werden soll ist jede weitere Hilfe pure Kaffeesatzleserei.
Es gibt nur wenige Dinge die bei den Attributen zu beachten sind, in erster Linie den Usernamen und das "starke" Passwort dazu (steht aber alles im Wiki (https://wiki.fhem.de/wiki/SIP-Client)) , den Error 110 hatten wir hier (https://forum.fhem.de/index.php/topic,67443.msg632297.html#msg632297) schon einmal. Da es ein I/O Error ist tippe ich wieder auf ein User/Password Problem.
Generell ist die Anmeldung als Türsprechstelle kein Problem, die internen Rufnummern sind dann halt 11,12, usw.
Ist aber wurscht, denn was willst du machen ? Eine Türstation anrufen oder irgend ein anderes internes/externes Telefon ? oder von irgendeinem Telefon FHEM anrufen ?
mit "set call <klingeltaste>" kann ich ein klingeltaste drücken simmulieren, um auf meinen fritzfons ein bildchen anzeigen zu lassen.
Zitat von: Wzut am 26 September 2018, 10:55:56
Vermutlich zum 50 Mal : ohne list vom SIP Device und ohne verbose 5 Log (in Code Tags) und ohne zu wissen was denn überhaupt gemacht werden soll ist jede weitere Hilfe pure Kaffeesatzleserei.
Es gibt nur wenige Dinge die bei den Attributen zu beachten sind, in erster Linie den Usernamen und das "starke" Passwort dazu (steht aber alles im Wiki (https://wiki.fhem.de/wiki/SIP-Client)) , den Error 110 hatten wir hier (https://forum.fhem.de/index.php/topic,67443.msg632297.html#msg632297) schon einmal. Da es ein I/O Error ist tippe ich wieder auf ein User/Password Problem.
Generell ist die Anmeldung als Türsprechstelle kein Problem, die internen Rufnummern sind dann halt 11,12, usw.
Ist aber wurscht, denn was willst du machen ? Eine Türstation anrufen oder irgend ein anderes internes/externes Telefon ? oder von irgendeinem Telefon FHEM anrufen ?
Hier das List.
Nach Setzten von Verbose 5 kommt momentan nichts im FHEM Log an.
Keine Ahnung warum.
Welche Version des SIP Modules sollte man eigentlich bevorzugen CPAN oder debian repo?
Ich hab gestern abend mal die CPAN version installiert vorher war es die repo version.
Internals:
AC /usr/bin/sox
NAME sip.fb1.doorpi
NOTIFYDEV global
NR 1031
NTFY_ORDER 50-sip.fb1.doorpi
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
Helper:
DBLOG:
call:
DBLog:
TIME 1538030813.5134
VALUE done
call_attempt:
DBLog:
TIME 1538030813.5134
VALUE 0
call_state:
DBLog:
TIME 1538030813.5134
VALUE fail
call_success:
DBLog:
TIME 1538030813.5134
VALUE 0
call_time:
DBLog:
TIME 1538030813.5134
VALUE 0
last_error:
DBLog:
TIME 1538030813.5134
VALUE CallRegister
listen_alive:
DBLog:
TIME 1537992099.48676
VALUE no
state:
DBLog:
TIME 1538030813.5134
VALUE initialized
READINGS:
2018-09-27 08:46:53 call done
2018-09-27 08:46:53 call_attempt 0
2018-09-27 08:46:53 call_state fail
2018-09-27 08:46:53 call_success 0
2018-09-27 08:46:53 call_time 0
2018-09-25 12:54:24 caller reject
2018-09-27 08:46:53 last_error CallRegister: Failed with error 110
2018-09-26 22:01:39 listen_alive no
2018-09-27 08:46:53 state initialized
helper:
CALL_BYE CallRegister: Failed with error 110
CALL_ERROR 0
CALL_NAME unknown
CALL_NR 10
CALL_START 1538030751.49861
CALL_TIME 0
CALL_TYPE out
Attributes:
audio_converter sox
history_file ./log/sip.doorpi.sip
history_size 0
room 9.80_Sender
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:620@fritz.box
sip_ip 192.168.1.11
sip_listen none
sip_registrar 192.168.178.1
sip_ringtime 10
sip_user 620
verbose 5
Zitat von: frank am 26 September 2018, 11:39:18
mit "set call <klingeltaste>" kann ich ein klingeltaste drücken simmulieren, um auf meinen fritzfons ein bildchen anzeigen zu lassen.
Danke
Muss die Nummer per **11 oder nur als 11 gewählt werden?
Ob 11 oder **11 ist doch jetzt erst einmal völlig egal.
Zuerst must du den Fehler 110 in den Griff bekommen, mir fällt da als allererstes dein Attribut sip_ip 192.168.1.11 auf
Ist wirklich 192.168.1.11 die IP deines FHEM ? D.h. in einem anderen Subnetz als deine FB mit 192.168.178.1 ?
Wenn ja , ok du wirst dann das Routing schon im Griff haben und weiter zum nächsten Punkt :
Ist da ein Doorpi auch noch aktiv und du willst den SIP User 620 zeitgleich auch mit FHEM nutzen ? Wenn ja : mach das nicht.
Punkt drei : Dein FB OS scheint auch etwas älter zu sein , inzwischen darf man die einfachen Usernamen wie 620 gar nicht mehr vergeben. Leg doch einfach noch ein zusätzliches IP Telefon an mit eigenem User/PW , trage die Parameter am SIP Modul ein und lass die Türsprechstelle ganz links liegen.
Zur Frage CPAN ja /nein : Es kommt drauf wann was debian von Haus aus mitbringt. Wheezy hat auf jeden Fall eine zu alte Version von Net::SIP , aber auch das ist nicht dein Problem da die Fehlermeldungen in dem Fall anderes aussehen.
Zitat von: Wzut am 27 September 2018, 10:20:54
Ob 11 oder **11 ist doch jetzt erst einmal völlig egal.
Zuerst must du den Fehler 110 in den Griff bekommen, mir fällt da als allererstes dein Attribut sip_ip 192.168.1.11 auf
Ist wirklich 192.168.1.11 die IP deines FHEM ? D.h. in einem anderen Subnetz als deine FB mit 192.168.178.1 ?
Wenn ja , ok du wirst dann das Routing schon im Griff haben und weiter zum nächsten Punkt :
Ist da ein Doorpi auch noch aktiv und du willst den SIP User 620 zeitgleich auch mit FHEM nutzen ? Wenn ja : mach das nicht.
Punkt drei : Dein FB OS scheint auch etwas älter zu sein , inzwischen darf man die einfachen Usernamen wie 620 gar nicht mehr vergeben. Leg doch einfach noch ein zusätzliches IP Telefon an mit eigenem User/PW , trage die Parameter am SIP Modul ein und lass die Türsprechstelle ganz links liegen.
Zur Frage CPAN ja /nein : Es kommt drauf wann was debian von Haus aus mitbringt. Wheezy hat auf jeden Fall eine zu alte Version von Net::SIP , aber auch das ist nicht dein Problem da die Fehlermeldungen in dem Fall anderes aussehen.
Die FB und das interen Netz haben andere IP Bereiche.
Das ist leider dem Doppelten NAT geschultet, da mir KabelBW hier nichts liefern will als reines Modem und ich eine OPNsense wegen VPN usw. am laufen habe.
Die OPNSense lässt alle Ports durch.
Da liegt dann auch der Grund das ich eine so fu**ing alte Fritz Version habe, KBW liefert bei der 6360 seit längerem keine Updates aus.
Sorry Kommando zurück, hab mich vertan FHEM läuft auf UBUNTU 16.04 LTS
Die Doorpi ist nicht mehr im Einsatz. Zumindest momentan.
Ich glaube ich lösche mal die Gegensprechanlage und leg die neu an.
Mal schauen was da dann für ne User angezeigt wird.
Das anlegen hat auch nicht gebracht.
Hier mal der LOG auszug:
2018.09.27 11:14:09 5: sip.fb1.doorpi, no elbc
2018.09.27 11:14:09 5: sip.fb1.doorpi, fifo is empty
2018.09.27 11:14:09 4: sip.fb1.doorpi, CALLDone -> sip.fb1.doorpi|0|CallRegister: Failed with error 110|0
2018.09.27 11:13:05 4: sip.fb1.doorpi[28523], using Leg.pm to find a free port
2018.09.27 11:13:05 4: sip.fb1.doorpi[28523], my parent is 1391
2018.09.27 11:13:05 5: sip.fb1.doorpi, call has pid 28523
2018.09.27 11:13:05 4: sip.fb1.doorpi, call -> sip.fb1.doorpi|11|10||0|0
2018.09.27 11:13:05 4: sip.fb1.doorpi, sip.fb1.doorpi|11|10||0
2018.09.27 11:13:05 4: sip.fb1.doorpi, calling 11, ringtime: 10 , no message
Ok, aber dein Fehler Nr. 110 bleibt, Klartext aus der errno.h : Connection timed out
Ich kann den Fehler bei mir leider nicht nachstellen. Falscher User oder Passwort führen zu Fehler Nr. 401 oder 403
Ungültige eigene IP : Cannot assign requested address at /usr/share/perl5/Net/SIP/Leg.pm line 153
Zitat von: no_Legend am 27 September 2018, 10:47:38
Die FB und das interen Netz haben andere IP Bereiche.
Das ist leider dem Doppelten NAT geschultet, da mir KabelBW hier nichts liefern will als reines Modem und ich eine OPNsense wegen VPN usw. am laufen habe.
Die OPNSense lässt alle Ports durch.
"Andere Bereiche" klingt interessant. Wer routet denn zwichen Deinen Netzsegmenten? Oder hast Du das Interface Deines FHEM mit zwei IP-Adressen ausgestattet? Dann musst Du die IP-Adresse aus dem anderen Netzsegment angeben.
Im Zweifelsfalle mal malen bzw. beschreiben wer was wie routet/nattet.
Hi, kurze Frage.
Kann man einen ausgehenden Call mit Timeout von 60 Sekunden gezielt abbrechen?
Z.B. bei nach 15 Sekunden durch einen Befehl?
Danke und Grüße
mi.ke
z.Z. leider nicht, aber schreib doch mal genau was du wie und warum vor hast vllt. fällt mir ja eine elegante Lösung ein :)
Hallo,
irgendwie schaffe ich es nicht den Call zu verlängern.. Es klingelt nicht einmal und dann steht auch noch OK im call_state, obwohl ich nicht abgenommen habe?
Anruf auf Handy und Empfang ist auch dort. In der FritzBox ist der Anruf mit <1min.
Beim Festnetzanruf funktioniert es besser.. Der Aufbau dauert bei Handy ja länger. Kann man das verlängern?
Ich danke für Eure Hilfe,
SteRa
Internals:
.oldstate initialized
.reset 0
NAME FritzBox_SipClient
NOTIFYDEV global
NR 111
NTFY_ORDER 50-FritzBox_SipClient
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
callnr 0xxxxxxxxxxx
forcecall 0
repeat 0
ringtime 30
.attraggr:
.attrminint:
READINGS:
2018-11-09 16:09:44 call done
2018-11-09 16:09:44 call_attempt 0
2018-11-09 16:09:44 call_state ok
2018-11-09 16:09:44 call_success 1
2018-11-09 16:09:44 call_time 10
2018-11-09 15:43:41 last_error audio file ./tada.alaw not found
2018-11-09 12:17:50 listen_alive no
2018-11-09 16:09:44 state initialized
helper:
CALL_BYE ok
CALL_ERROR 1
CALL_NAME unknown
CALL_NR 01xxxxxx
CALL_START 1541776165
CALL_TIME 10
CALL_TYPE out
Attributes:
disabled 0
history_file ./log/FritzBox_SipClient.sip
history_size 0
room 09_Extern
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:FhemSIPTelefon@192.168.188.1
sip_ip 192.168.188.50
sip_listen none
sip_registrar 192.168.188.1
sip_user FhemSIPTelefon
gleiche Antwort wie immer : verbose 5 Log anhängen !
Hallo zusammen,
Super Modul!! Danke!
Kann ich damit auch einen Anruf starten und sobald abgehoben wird, diesen an ein DECT-Telefon meiner Fritzbox 7490 weitergeben? Quasi ähnlich wie die gute alte Wählhilfe der Fritzbox. Wie sähe das aus?
Liebe Grüße
Alex.
Zitat von: alexmetz am 18 November 2018, 16:28:35
Hallo zusammen,
Super Modul!! Danke!
Kann ich damit auch einen Anruf starten und sobald abgehoben wird, diesen an ein DECT-Telefon meiner Fritzbox 7490 weitergeben? Quasi ähnlich wie die gute alte Wählhilfe der Fritzbox. Wie sähe das aus?
Liebe Grüße
Alex.
Die aktuelle Version ist nur als Client ausgelegt. Weitervermitteln kann das Modul nicht.
ja ich meine nicht als Telefonanlage sondern über die Fritzbox. Kann ich ja mit meinem DECT-Telefon auch: "R" dann interne Nr. eingeben. Auflegen. Fertig.
Zitat von: alexmetz am 18 November 2018, 19:10:12
ja ich meine nicht als Telefonanlage sondern über die Fritzbox. Kann ich ja mit meinem DECT-Telefon auch: "R" dann interne Nr. eingeben. Auflegen. Fertig.
tja, welchen DTMF-Code muss ich denn für "R" an die Fritzbox senden? Und der SIP-Client muss während dessen auch durchhalten, d.h. man muss vermutlich in den Code für die Kommunikation mit der Telefonanlage eingreifen.
Da mein Speedport Hybrid wohl kein SIP kann, würde ich gerne das Modul direkt mit dem t-online Server sprechen lassen. Hat das schon einer hinbekommen?
Zitat von: Wzut am 09 November 2018, 18:54:47
gleiche Antwort wie immer : verbose 5 Log anhängen !
Hallo Wzut,
ich habe regelmäßig solche Log Einträge:
xxxx log1:Timeout for SIP_ListenStart reached, terminated process xxxxDas Modul läuft unabhängig davon Perfekt - DANKE.
Wäre es möglich, das Loglevel dafür auf verbose 2 hochzusetzen, dann wären diese Meldungen bei mir weg. Ich könnte das selbst machen, müsste dann aber das Modul vom Updateprozess ausschliessen und das finde ich suboptimal.
Alternativ wäre ich natürlich für Vorschläge offen, wie sich diese Meldungen vermeiden lassen. Aktuell sehe ich sie nur als Schönheitsfehler und kann damit nichts anfangen.
Danke,
@bennebartsch, da wir das vor Wochen erfolgreich mit sipgate.de probiert haben sollte es auch ohne Probleme direkt mit t-online gehen. Trag doch einfach mal die benötigten Daten direkt ein.
@det., aus deinem Posting werde ich nicht richtig schlau. Natürlich kannst du das SIP Device auf verbose 0 setzen
um keine Level 1 Meldungen mehr im Log zu haben. Das wäre dann allerdings wieder mal Symptom statt Ursache behandelt. Du must dir doch selbst die Frage stellen warum der Start des Listen Prozess fehl schlägt bzw. ob du überhaupt einen brauchst ? Denn entweder brauchst du in Wahrheit gar keinen Listen Modus, dann stimmt deine Aussage das es perfekt läuft oder es läuft eben nicht perfekt da der benötigte Listen Prozess nicht gestartet werden kann.
Hallo Wzut,
Hab ich mich vielleicht zu kompliziert ausgedrückt.
Fakt - es funktioniert und
Verbose steht auf 0
Trotzdem kommt: 2018.11.19 13:37:12 1: Timeout for SIP_ListenStart reached, terminated process 30508
Was ich mache: eine Rufnummer von bestimmten Handys anrufen Garagentor und Hoftor geht auf, entsprechend bei einer zweiten Rufnummer geht es wieder zu. Das klappt auch ohne wfp, aber mit wfp legt Sip direkt wieder auf, ohne muss ich am Handy auflegen drücken. Mir ist klar, dass Du für solch eine simple Spielerei das Modul nicht entwickelt hast, aber das ist nun mal meine Verwendung dafür und das schon sehr lange. Es gab bei Dir schon mal die Überlegung, ein Auflegen nach dem x.ten Klingelzeichen einzubauen, aber dafür gab es offenbar zu wenig Interessenten.
Noch was - bei Ankunft (während des Öffnens) spielt es noch ein Audio ,,herzlich Willkommen" ab.
Zitat von: Wzut am 19 November 2018, 13:31:58
@bennebartsch, da wir das vor Wochen erfolgreich mit sipgate.de probiert haben sollte es auch ohne Probleme direkt mit t-online gehen. Trag doch einfach mal die benötigten Daten direkt ein.
Bin leider relativ neu im Thema SIP. Folgende Infos der Telekom nutze ich:
https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true
Muss sip_from jetzt meine E-Mail oder meine Tel. Nr. sein? Gleiche Frage für sip_user.
Muss ich einen Port freigeben und/oder sip_port in FHEM setzten?
Muss sip_ip meine öffentliche IP sein oder die lokale vom NUC/PI?
Sorry für die ganzen Fragen, leider habe ich bis jetzt keine klaren Antworten gefunden. Würde auch gerne meine Konfiguration sobald sie mit der Telekom läuft im Wiki hinzufügen.
Des weiteren hatte ich bei der Installation erst das Problem, das das Modul Net::DNS gefehlt hat. Sollte man das evtl auch in der Wiki erwähnen?
Ob der User simple oder komplexe Anwendungen hat ist mir als Entwickler relativ wurscht, gehen muss es !
Und bei dir sind da wohl gleich zwei Dinge komisch :
a. wieso hast du Level 1 Meldungen im Log obwohl verbose auf 0 steht ?
b. wie kann wfp überhaupt laufen wenn der dazugehörige Prozess gar nicht gestartet werden konnte ?
oder sollte da nochmal ein Start erfolgen obwohl der alte wfp Prozess noch läuft, aber die Überwachung im Hauptprozess anderer Meinung war ?
Was das auflegen nach x mal klingeln betrifft : Aktuelle Versionen von Net::SIP erlauben es mir leider nicht mehr die Anzahl der Klingeltöne zu zählen, erkennt man daran das der Status dort nie auf ringing geht.
Zitat von: bennebartsch am 19 November 2018, 15:04:30
Muss sip_from jetzt meine E-Mail oder meine Tel. Nr. sein? Gleiche Frage für sip_user.
Muss ich einen Port freigeben und/oder sip_port in FHEM setzten?
Muss sip_ip meine öffentliche IP sein oder die lokale vom NUC/PI?
Des weiteren hatte ich bei der Installation erst das Problem, das das Modul Net::DNS gefehlt hat. Sollte man das evtl auch in der Wiki erwähnen?
Ich würde nach der von dir verlinkten t-online Anleitung starten mit :
sip_user :
Authentifizierungsname/Benutzername: Ihre E-Mail-Adresse, z. B. ihr-name@t-online.de
sip_registrar : tel.t-online.de
sip_from : SIP-ID/Benutzer: Ihre Telefonnummer
sip_port : 4060 (kann ggf. überflüssig sein , würde ich aber für erste Tests fest setzen)
sip_ip : die interne IP deines FHEM wie z.B 192.168.1.20 ,
nicht die öffentliche IP von der Telekom
Vielen Dank für die flotte Antwort!
Meinst du wirklich Port 4060 oder evtl 5060? Muss ich dann zwingend die Portweiterleitung einrichten? Btw, FHEM läuft bei mir in Docker, da habe ich erstmal zum testen alle Ports weitergeleitet die mir so einfallen (5060, 5070, 5080).
An meinem Speedport lässt sich Port 5060 allerdings nicht weiterleiten, der Port wird wohl blockiert (bereits vom Speedport genutzt).
Muss ich vor meine E-Mail "sip:" schreiben?
Edit: mit "email@test.de" bekomme ich immer "CallRegister: Failed with error 110"
mit "sip:email@test.de" immer "CallRegister: Failed with code 403"
Edit2: Jetzt bekomme ich folgendes:
2018.11.19 15:59:55 4: sip, calling +491**********, ringtime: 30 , no message
2018.11.19 15:59:55 4: sip, sip|+491**********|30||0
2018.11.19 15:59:55 4: sip, call -> sip|+49151**********|30||0|0
2018.11.19 15:59:55 5: sip, call has pid 19
2018.11.19 15:59:55 4: sip[19], my parent is 7
2018.11.19 15:59:55 4: sip[19], trying to use port 4070
2018.11.19 15:59:55 4: sip[19], register new expire : 2018-11-19 16:10:55
2018.11.19 15:59:55 5: sip, readingS:state Val:calling
2018.11.19 15:59:55 4: sip[19], CallStart DTMF : ABCD*#123--4567890
2018.11.19 15:59:55 4: sip[19], calling : +491**********
2018.11.19 15:59:55 5: sip, readingS:call_state Val:calling +491**********
2018.11.19 15:59:56 4: sip[19], cb_final - status : FAIL - final : 488
2018.11.19 16:00:25 5: sip[19], 0. Ende des ersten Loops
2018.11.19 16:00:25 5: sip[19], 1. rtp_done : 0
2018.11.19 16:00:25 5: sip[19], 2. fi : 0
2018.11.19 16:00:25 5: sip[19], 3. Final : 488
2018.11.19 16:00:25 5: sip[19], 4. timeout : 1
2018.11.19 16:00:25 5: sip[19], 6. call_established : 0
2018.11.19 16:00:25 5: sip[19], call->cancel
Zitat von: Wzut am 19 November 2018, 15:22:00
Ob der User simple oder komplexe Anwendungen hat ist mir als Entwickler relativ wurscht, gehen muss es !
Und bei dir sind da wohl gleich zwei Dinge komisch :
a. wieso hast du Level 1 Meldungen im Log obwohl verbose auf 0 steht ?
b. wie kann wfp überhaupt laufen wenn der dazugehörige Prozess gar nicht gestartet werden konnte ?
oder sollte da nochmal ein Start erfolgen obwohl der alte wfp Prozess noch läuft, aber die Überwachung im Hauptprozess anderer Meinung...
Zu a) im FB_Callmonitor hatte ich verbose bisher vergessen zu setzen - d.h. Global Einstellung verbose 1 greift da, kann es mglw aus der Ecke kommen?
Zu b) offenbar läuft der Prozess für beide definieren SIP Device, wird wohl aber immer mal von selbst neu startet??? Wie kann ich die Log Ausgabe in ein extra File loggen, um Dich mit brauchbaren Informationen zu versorgen?
Zitat von: bennebartsch am 19 November 2018, 15:49:19
2018.11.19 15:59:55 4: sip[19], register new expire : 2018-11-19 16:10:55
2018.11.19 15:59:55 5: sip, readingS:state Val:calling
Das sieht schon mal ganz gut aus , d.h. SIP Server, User & Password stimmen - sonst gäbe es kein new expire :)
Fehler 488 -> https://de.wikipedia.org/wiki/SIP-Status-Codes , versuch doch mal die Rufnummer ganz altmodisch mit 01xx ohne +49
Portweiterleitung : Habe ich bei mir für sipgate.de gar nicht eingerichtet, wie schaut es aus wenn du sie wieder löschst ?
Mit Docker zusammen wird die Fehlersuche jetzt natürlich wesentlich schwerer.
Ah jetzt weiß ich auch wo ich den Fehlercode finde, danke! Habe schon mit 0049, +49 und 0 probiert :/
Ist mein Befehl so überhaupt korrekt?: set sip call +49******* 30
Random Zitat aus einem Forum: "Der SIP-Fehler "488 Not acceptable here" tritt meist auf, wenn versucht wird, einen Codec zu verwenden, der vom Ziel nicht unterstützt wird."
Kann es gleich auch nochmal auf einer zweiten Installation ohne Docker testen.
Edit: auf dem anderem PI ohne Docker bekomme ich folgendes, komisch:
2018.11.19 22:11:01 4: sip, CALLDone -> sip|0|CallRegister: registration error|0
2018.11.19 22:11:01 5: sip, fifo is empty
2018.11.19 22:11:01 5: sip, no elbc
Hallo,
habe eine Fritzbox 7590 mit firmware 7.01.
(https://www.bilder-upload.eu/thumb/53890f-1544815566.jpeg) (https://www.bilder-upload.eu/bild-53890f-1544815566.jpeg.html)
Fhem läuft in einem docker container und ist auf dem neuestem Stand, port 5060 ist nach außen freigegeben.
Eingerichtet habe ich alles nach Anleitung im wiki.
defmod mySIP SIP
attr mySIP history_file ./log/mySIP.sip
attr mySIP history_size 0
attr mySIP room Info
attr mySIP sip_dtmf_loop once
attr mySIP sip_dtmf_send audio
attr mySIP sip_dtmf_size 2
attr mySIP sip_elbc yes
attr mySIP sip_from sip:fhemserver@192.168.178.1
attr mySIP sip_ip 192.168.178.87
attr mySIP sip_listen none
attr mySIP sip_port 5060
attr mySIP sip_registrar 192.168.178.1
attr mySIP sip_ringtime 3
attr mySIP sip_user fhemserver
attr mySIP verbose 4
Hier die Meldung im log:
2018.12.14 20:08:00.953 4: mySIP, calling **610, ringtime: 30 , no message
2018.12.14 20:08:00.954 4: mySIP, mySIP|**610|30||0
2018.12.14 20:08:00.965 4: mySIP, call -> mySIP|**610|30||0|0
2018.12.14 20:08:00.974 4: mySIP[10754], my parent is 6982
2018.12.14 20:08:00.975 4: mySIP[10754], trying to use port 5060
2018.12.14 20:08:00.976 1: mySIP[10754], cannot open port 5060 at 192.168.178.87 : Cannot assign requested address
2018.12.14 20:08:00.991 4: mySIP, CALLDone -> mySIP|0|CallRegister: can't open port 5070 at 192.168.178.87 : Cannot assign requested address|0
libnet-sip-perl ist im dockerfile vorhanden.
Wo könnte der Fehler liegen?
Gruß Holger
Zitat von: The-Holgi am 14 Dezember 2018, 20:19:22
Fhem läuft in einem docker container und ist auf dem neuestem Stand, port 5060 ist nach außen freigegeben.
Ich hatte anfänglich auch Probleme mit Port 5060. Hast Du mal Port 5070 versucht?
VG plin
Hallo,
ja hab bis port 5100 alles probiert. Das Modul versucht dann immer in 10er Schritten den nächst höheren port zu öffnen, natürlich ohne Erfolg.
geh mal ein paar Seiten hier zurück bis Antwort #311 und folgende, da hatten wir das Thema Docker schon einmal.
Danke für die Hilfe.
Nachdem ich beide ports (5060 und 5070) geöffnet habe und die "interne" ip (172.27.0.2) verwende funktioniert es.
Gruß Holger
Hallo,
erstmal: das SIP Modul in kombination mit TTS ist echt cool! Vielen Dank dafür.
Ich denke ich habe im 96_SIP.pm Modul zwei Probleme entdeckt.
1) In Kombination mit SOX kann man mehrere Sätze nicht ausgeben lassen.
2) Bei einem Fehler sollte abgebrochen werden.
Aktuelle Version vom 20.12.2018.
Zunächst meine Config:
defmod MyTTS Text2Speech none
attr MyTTS TTS_Language Deutsch
attr MyTTS TTS_UseMP3Wrap 1
attr MyTTS icon audio_volume_mid
attr MyTTS room SIP-TTS
defmod MySipClient SIP
attr MySipClient T2S_Device MyTTS
attr MySipClient T2S_Timeout 60
attr MySipClient audio_converter sox
attr MySipClient history_file ./log/MySipClient.sip
attr MySipClient history_size 0
attr MySipClient room SIP-TTS
attr MySipClient sip_call_audio_delay 1.25
attr MySipClient sip_dtmf_loop once
attr MySipClient sip_dtmf_send audio
attr MySipClient sip_dtmf_size 2
attr MySipClient sip_elbc yes
attr MySipClient sip_from sip:fhemserver@192.168.1.1
attr MySipClient sip_ip 192.168.1.93
attr MySipClient sip_listen wfp
attr MySipClient sip_port 5060
attr MySipClient sip_registrar 192.168.1.1
attr MySipClient sip_ringtime 2
attr MySipClient sip_user fhemserver
Ich benutze folgendes Kommando um mehrere Sätze zu erzeugen:
set MySipClient call **611 30 !Hallo FHEM Freunde. Das SIP-Modul ist cool.
Im ./cache/ Verzeichnis sieht man dass die einzelnen mp3 teile sowie das *MP3WRAP.mp3 erzeugt werden, jedoch nicht das *MP3WRAP.alaw file.
Scheinbar liegt es daran, dass "SOX" beim convertieren eine Warnung ausgibt: Logfile: "sox output : /usr/bin/sox WARN mp3-util: MAD lost sync"
1) Lösung des ersten Problems:
Diese Ausgabe wird dann von dem Modul als Fehler interpretiert.
Die Warnung kann bei SOX mit der Option "-V1" unterdrückt werden, dann funktioniert es.
$cmd = $hash->{AC}." ".$file." -V1 -t raw -r 8000 -c 1 -e a-law ".$out." 2>&1";
sub SIP_MP3_conv($$$)
...
if ($converter eq "sox")
{
$cmd = $hash->{AC}." ".$file."-V1 -t raw -r 8000 -c 1 -e a-law ".$out." 2>&1";
Log3 $name,5,"$logname, $cmd";
$ret = qx($cmd);
if ($ret)
{
unlink $out;
$ret =~ s/\n//g;
Log3 $name,5,"$logname, sox output : $ret";
}
2. Problem:
Wenn die Warnung von SOX als fehler behandelt wird, dann wird der Call trotzdem ausgefüht.
Anstatt des Textes werden DTMF Töne ausgegeben. (ich glaube das ist der inhalt der Variablen my $dtmf = 'ABCD*#123--4567890'; )
Bei einem Fehler sollte der Call abgebrochen werden und ein Log Eintrag erzeugt werden.
Hier könnte man die Fehlerbhandlung verbessern.
Wäre super wenn das jemand einpflegen kann.
Zitat von: markus1407 am 20 Dezember 2018, 10:07:51
Wäre super wenn das jemand einpflegen kann.
Ich kann alles .... :) Spatz beiseite :
So mag ich Kritik, statt einem simplen "geht nicht", eine echte Fehleranalyse und gleich die passenden Lösungvorschläge dazu.
Da ich die nächsten Tage bis Neujahr mit Sicherheit etwas Zeit habe werde ich mich damit beschäftigen, u.A. hat auch plin noch ein paar Ideen
zum Thema Fehlerbehandlung.
Hi zusammen,
ich hatte bei mir ein kleines NAT-Problem da sich mein FHEM hinter einer Firewall nach der Fritzbox befindet. Also Aufbau:
Fritzbox -> Ubiquiti Unifi Security Gateway (USG) -> FHEM
Die FB vergibt die IP 192.168.0.2 an die USG und die USG vergibt wiederrum intern selbst die IPs, also FHEM hätte dann beispielsweise 192.168.133.7. Eine Portweiterleitung durch die USG auf FHEM ist eingerichtet.
Wenn sich nun FHEM an der FB anmeldet, so meldet FHEM die IP 192.168.133.7 welche die FB dann bei einem Anruf leider nicht erreichen kann:
Daher war mein Gedanke "setze doch einfach sip_ip auf 192.168.0.2" was aber das Modul damit quittiert, dass der Fehler:
ZitatListenRegister: can't open port 5070 at 192.168.133.7 : Cannot assign requested address
auftritt.
Der finale Ansatz war relativ easy mit der Einrichtung einer statischen Route für alles was 192.168.133.x ist auf die 192.168.0.2 (konfiguriert in der FB).
Vielleicht hilfts ja jemandem ;)
Hallo,
SIP habe ich heute Vormittag installiert, da ich aus Modul "ALARM" eine Textnachricht schicken möchte (text-to-speech). In der Fritzbox habe ich das Telefongerät eingerichtet, (LAN/WLAN), 5. Registrar
fritz.box oder 192.168.10.1 Benutzername ist SIP-SERVER, Kennwort vergeben und in set mySip eingetragen. Text2Speech device heisst myT2Speech, habe ich bei T2S-Device eingetragen. Meine interne Nummer in der fritzbox heisst **625, eingetragen in sip_from und modifiziert in sip_user.
Mir ist aufgefallen, dass die Ip-Adresse mit 192.168.10.22 eingetragen ist. Der Raspberry hat aber 192.168.10.59. Woher kommt die 192.168.10.22? Muss ich diese händisch ändern?
Ich setzte den Befehl ab:
Zitat[quote]set mySIP call 0xx73873xx 30 !hier ist fhem[/quote]
nichts passiert, kein Logfile, kein Event
nochmals
set mySIP call 0xx73873xx 30 !hier ist fhem
ich bekomme die Fehlermeldung
there is already a call activ for target 0xx73873xx
Die xx habe ich vorsorglich geixt, Telefonnummer ist aber eine meiner 3 Rufnummern. mySip habe ich einer anderen ankommenden/abgehenden Telefonnummer zugeordnet, eine weitere der 3 Nummern.
Hier noch die list:
Internals:
AC /usr/bin/sox
CPID 996
NAME mySIP
NOTIFYDEV myT2Speech
NR 186
NTFY_ORDER 50-mySIP
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
lastnr 0247387318
READINGS:
2019-01-08 11:50:00 call 0xx73873xx
2019-01-08 11:50:00 call_state invite
2019-01-08 11:27:31 listen_alive no
2019-01-08 11:27:31 state initialized
helper:
CALL mySIP|0xx73873xx|30|cache/69ea7f5d9bb173f0fef70aa9c8f9957c.alaw|0|0
CALL_NR 02xx3873xx
CALL_START 1546944600.77534
CALL_TYPE out
CALL_PID:
abortArg
abortFn
arg mySIP|0xx73873xx|30|cache/69ea7f5d9bb173f0fef70aa9c8f9957c.alaw|0
bc_pid 1
finishFn SIP_CALLDone
fn SIP_CALLStart
pid 996
timeout
Attributes:
DbLogExclude .*
T2S_Device myT2Speech
audio_converter sox
history_file ./log/mySIP.sip
history_size 0
room GERAETE
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:625@fritz.box
sip_ip 192.168.10.22
sip_listen none
sip_registrar fritz.box
sip_ringtime 3
sip_user 625
Internals:
ALSADEVICE
DEF none
MODE SERVER
NAME myT2Speech
NR 185
STATE Initialized
TYPE Text2Speech
READINGS:
2019-01-08 11:23:03 lastFilename cache/69ea7f5d9bb173f0fef70aa9c8f9957c.mp3
2019-01-08 11:23:03 playing 1
helper:
Attributes:
DbLogExclude .*
room GERAETE
Die Änderung des IP Adresse hat nicht geändert, hab auch vor einem neuen Anruf set .. reset gemacht.
Sorry, noch ne Information:
Nach der Umstellung der sip_IP auf die IP meines Raspberries 192.168.10.59:
2019-01-08 12:14:26 Global global ATTR mySIP sip_ip 192.168.10.59
und dem nächsten Versuch bekam ich folgenden Event:
2019-01-08 12:14:54 SIP mySIP initialized
2019-01-08 12:14:54 SIP mySIP listen_alive: no
2019-01-08 12:14:56 SIP mySIP call_state: invite
2019-01-08 12:14:56 SIP mySIP call: 0xx73873xx
ein nochmaliger Versuch brachte:
2019-01-08 12:14:54 SIP mySIP initialized
2019-01-08 12:14:54 SIP mySIP listen_alive: no
2019-01-08 12:14:56 SIP mySIP call_state: invite
2019-01-08 12:14:56 SIP mySIP call: 0xx73873xx
Ich denke, es ist ein von mir übersehene Einstellung
Zitat von: UweUwe am 08 Januar 2019, 12:13:53
modifiziert in sip_user.
Mir ist aufgefallen, dass die Ip-Adresse mit 192.168.10.22 eingetragen ist. Der Raspberry hat aber 192.168.10.59. Woher kommt die 192.168.10.22? Muss ich diese händisch ändern?
Wiki gelesen ? -> https://wiki.fhem.de/wiki/SIP-Client
da steht :
sip_user
User Name des SIP-Clients. Default ist 620. Ab 6.8 ist der Benutzername aus sip_from anzugeben, z.B. meinuser.
Da du schreibst "Benutzername ist SIP-SERVER" ist auch diesen zu verwenden und nicht 625 !
D.h. sip_from und sip_user sind so falsch, bei sip_registrar bitte erst einmal auf Nummer sicher gehen und statt fritz.box lieber die IP der FB eintragen.
Das Modul versucht beim ersten Start die eigene IP zu ermitteln und trägt den Wert in sip_ip ein. Sollte die IP falsch sein ist sie zu ändern, hast du ja schon gemacht.
Sollte es nach den Änderungen von sip_from & sip_user noch immer Probleme geben, bitte wie schon 100 mal geschrieben das Device auf verbose 5 stellen und den entsprechenden Log Abschnitt posten ( die Ziel Ruf Nr. kann dabei mit xxx verstümmelt werden, andere Dinge bitte nicht)
Hallo Wzut,
danke für die schnelle und tolle Hilfe. Das war der Fehler, ich hab nach deinen Anweisungen die beiden Änderungen durchgeführt und auch das Passwort nochmals eingegeben (war zwingend notwendig) und dann funktionierte es direkt. Toll.
Ich bin kein advanced User, das weiss ich. Hab viele viele Schwächen. Diese auszugleichen ist mein Ziel, aber aufgrund der Komplexität auch nur begrenzt möglich.
Ich habe das Wiki gelesen, sehr aufmerksam und bin auch weit gekommen, so meine Einschätzung. Da ich jetzt die Lösung kenne, so muss ich sagen, dass ich auch diese Hürde hätte nehmen können.
Ein ganz kleiner, sehr wohlgemeinter Hinweis sei mir erlaubt: (mit dem Hintergrund, dass > 90% aller user auf Fritz!ios 7.0 sind 8) )
Ich würde den Satz sip_format einfach umstellen: Das fromat ist sip:Benutzername@fritz.box, z.B. meinuser@fritz.box. "meinuser" ist der Benutzername, der bei der Einrichtung des neuen Benutzers gewählt wurde. Für fritzbox Geräte mit fritz!OS älter als 6.8 ist das Format abweichend noch sip:620@fritz.box
Nochmals danke, jetzt mache ich an dem Modul "alarm" weiter, da will ich SIP einsetzen.
Nochmals Danke für die viele Arbeit, die erst hinter dem Modul und dann hinter dem Support streckt. .
Dies ist nur der Hinweis eines "einfachen" Benutzers.
Zitat von: UweUwe am 08 Januar 2019, 19:40:18
(mit dem Hintergrund, dass > 90% aller user auf Fritz!ios 7.0 sind 8) )
ja da hängt das Wiki etwas hinter her, als plin das Wiki schrieb hatte niemand so ein "modernes" OS, daher kam der Nebensatz später dazu als es die erste Version gab wo der Username != der internen Rufnummer war. Inzwischen hat aber wohl kaum noch jemand so ein altes OS .....
@plin : Arbeit :)
Wenn du in die commandref schaust ist es noch krasser:
Zitatsip_user
User Name des SIP-Clients. Default ist 620 (Fritzbox erstes SIP Telefon)
Aber du kannst mir noch einen Hinweis geben, falls es dir nichts ausmacht:
Wenn ich das folgende Kommando in "alarm" "Aktion Setzen" einsetze, so bekomme ich die korrekte Funktion (werde angerufen und man spricht alles.. (hochzufrieden)
{fhem ('set mySIP call 015157805229 40 !Hallo hier ist die Alarmanlage $SHORT *-1')}
Hinweis: $SHORT wird während der Abarbeitung in "alarm" ersetzt durch "$ Short ==> wird durch die vollständige Kurznachricht der Alarmauslösung ersetzt".
Auch die vollständie Kurznachricht bekomme ich.
Das tuts auch gut. Die Ersetzung wird gemacht alles toll, aber :
Kann ich mir alles erklären, aber nicht die *-1 am Ende. Ist das SIP oder alarm syntax..?
==> kommando stammt aus Forum und ich lese gerade die 80 Seiten "alarm".
Hallo,
hab die *-1 gefunden:
ZitatWir ein Wiederholunsfaktor in der Form *nn angegeben, wird der Anruf ausgeführt, die Nachricht einmal abgespielt und dann nn mal wiederholt.
Wird als Wiederholungsfaktor ein negativer Wert angegeben (z.B. *-2), passiert folgendes: Die Nachricht wird zwar genau wie bei *2 dreimal abgespielt, allerdings erlaubt das - vor der 2 das die Nachricht nur einmal vollständig übertragen werden muß. Der call_state nach dem Call hätte dann z.B. den Wert "ok peer hangup".
Wird der Call mit & (force) beendet signalisiert dies, dass er wichtig ist und unbedingt zugestellt werden muss. Der SIP-Client versucht es dann so lange, bis der Anrufer erreicht wird. WICHTIG: wählt die maxtime groß genug damit das Audiofile auch wirklich komplett abgespielt werden kann, bzw. hört's euch auch bis zum Ende an! Wenn ein priorisierter Anruf vorzeitig endet (quasi NOK) wird er nach 1 Minute wiederholt, und zwar so lange bis er erfolgreich war. Wollt Ihr den Ablauf stoppen bitte das von der Wiederholungsschleife gesetzte at löschen, es befindet sich im gleichen Raum wie euer SIP Device. Dabei gibt es folgende Möglichkeiten:
Sorry, mein Fehler, war zu schnell.
Zitat von: Wzut am 08 Januar 2019, 20:35:18
@plin : Arbeit :)
Im Wiki ist der Text angepasst. Konsequenterweise sollte beim define des SIP-Devices als Default sip:xxxxxxxx@fritz.box statt sip:620@fritz.box gesetzt werden. Dann fällt direkt auf, dass da etwas angepasst werden muss.
Super Service. SIP ist prima und hat ne sehr angenehme Stimme. :-* Bin ja gerade beim Alarm Modul und werde schon hin und wieder angerufen .. zu Testzwecken ..
SIP Service ist besser als ALARM Service.. Danke
Nabend,
also alles bisher getestete hat super funktioniert, vielen Dank für die Weiterentwicklung des Moduls. Rausrufen mit Texten und / oder Files klappt wunderbar.
Nach den anfänglichen Schwierigkeiten mit dem Erkennen der DTMF-Töne läuft das ja nun auch stabil.
Wäre jemand mal so nett und könnte mal einen Beispielcode für die Auswertung eines DTMF Codes bereit stellen? Irgendwie finde ich nix und meine Versuche scheitern wohl an meinen Kenntnissen.
So ganz was einfaches:
Anruf kommt an, DTMF Code 56 wird übergeben --> Befehl 1 wird ausgeführt. Kommt ein anderer DTMF Code soll ein anderer Befehl ausgeführt werden.
Irgendwie bin ich zu blöd... :-[
TIPP : Eventmonitor öffenen , anrufen , Tasten drücken , den passenden Event im Monitor markieren und den Create/Modify Device Button drücken :)
Oder so. Vielen Dank, der Tipp hat geholfen. Damit kann ich was anfangen.
Hallo zusammen,
erstmal vielen Dank für das tolle Modul! Mit Hilfe der Wiki habe ich es sehr schnell eingerichtet bekommen. Ich möchte SIP mit sipgate.de als Anbieter laufen lassen. Ich habe leider ein Problem dabei: Der Anruf funktioniert zwar zuverlässig, aber es dauert sehr lange, bis der Rufaufbau erfolgt. Es vergehen teilweise fast zwei Minuten, bis das Telefon auf der Gegenseite klingelt. Wenn ich sipgate mit einer VoIP-App benutze, dauert es nur wenige Sekunden. Im log zeigt sich gar nichts. Ist das normal? Oder gibt es irgendwie eine Möglichkeit wie ich rausfinden kann, woran es hängt?
Edit: Das zeigt der Eventmonitor wenn ich einen Anruf starte.
2019-01-21 21:16:54 SIP SIPGate call_state: invite
2019-01-21 21:16:54 SIP SIPGate call: 02xxxxxxxx
2019-01-21 21:17:12 SIP SIPGate calling
2019-01-21 21:17:40 SIP SIPGate call_state: calling 02xxxxxx
2019-01-21 21:18:10 SIP SIPGate call_state: established
Gruß,
Markus
gleiche Antwort wie immer : list vom Device posten und ein Log Abschnitt vom Vorgang mit verbose 5
Anbei die Informationen. Ich habe einen Call gemacht, diesen aber am Handy nicht angenommen, sondern weggedrückt. Diesmal hat es auch nur ca. eine Minute gedauert. Finde ich aber trotzdem ziemlich lang.
List von meinem SIP Device:
Internals:
AC /usr/bin/sox
CFGFN
NAME SIPGate
NOTIFYDEV TTS_device
NR 268
NTFY_ORDER 50-SIPGate
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
READINGS:
2019-01-22 16:10:23 call done
2019-01-22 16:10:23 call_attempt 0
2019-01-22 16:10:23 call_state canceled
2019-01-22 16:10:23 call_success 0
2019-01-22 16:10:23 call_time 0
2019-01-21 21:41:52 caller fetch
2019-01-21 21:14:04 listen_alive no
2019-01-22 16:10:23 state initialized
helper:
CALL_BYE canceled
CALL_ERROR 1
CALL_NAME unknown
CALL_NR 01514xxxxxxx
CALL_START 1548169761
CALL_TIME 0
CALL_TYPE out
Attributes:
T2S_Device TTS_device
audio_converter sox
history_file ./log/SIPGate.sip
history_size 0
room Sicherheit
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:2594xxxxx@sipgate.de
sip_ip 192.168.0.101
sip_listen none
sip_port 5060
sip_registrar sipgate.de
sip_ringtime 3
sip_user 2594xxxxx
Logfile Verbose 5:
2019.01.22 16:19:17 4: WEB_192.168.0.28_54315 POST /fhem&fw_id=1610&cmd=set+SIPGate+call+01514xxxxxxx; BUFLEN:0
2019.01.22 16:19:17 5: Cmd: >set SIPGate call 01514xxxxxxx<
2019.01.22 16:19:17 4: SIPGate, calling 01514xxxxxxx, ringtime: 30 , no message
2019.01.22 16:19:17 4: SIPGate, SIPGate|01514xxxxxxx|30||0
2019.01.22 16:19:17 4: BlockingCall (SIP_CALLStart): created child (23304), uses telnetForBlockingFn_1547801260 to connect back
2019.01.22 16:19:17 4: SIPGate, call -> SIPGate|01514xxxxxxx|30||0|0
2019.01.22 16:19:17 5: SIPGate, call has pid 23304
2019.01.22 16:19:17 5: Starting notify loop for SIPGate, 2 event(s), first is call_state: invite
2019.01.22 16:19:17 5: createNotifyHash
2019.01.22 16:19:17 4: SIPGate[23304], my parent is 10412
2019.01.22 16:19:17 4: SIPGate[23304], trying to use port 5070
2019.01.22 16:19:17 5: End notify loop for SIPGate
2019.01.22 16:19:35 4: SIPGate[23304], register new expire : 2019-01-22 16:29:35
2019.01.22 16:19:35 4: Connection accepted from telnetForBlockingFn_1547801260_127.0.0.1_56993
2019.01.22 16:19:35 5: Cmd: >{SIP_rSU('SIPGate','state;calling')}<
2019.01.22 16:19:35 5: SIPGate, readingS:state Val:calling
2019.01.22 16:19:35 5: Starting notify loop for SIPGate, 1 event(s), first is calling
2019.01.22 16:19:36 5: End notify loop for SIPGate
2019.01.22 16:19:54 4: SIPGate[23304], CallStart DTMF : ABCD*#123--4567890
2019.01.22 16:20:03 4: SIPGate[23304], calling : 01514xxxxxxx
2019.01.22 16:20:03 5: Cmd: >{SIP_rSU('SIPGate','call_state;calling 01514xxxxxxx')}<
2019.01.22 16:20:03 5: SIPGate, readingS:call_state Val:calling 01514xxxxxxx
2019.01.22 16:20:03 5: Starting notify loop for SIPGate, 1 event(s), first is call_state: calling 01514xxxxxxx
2019.01.22 16:20:03 5: createNotifyHash
2019.01.22 16:20:03 5: End notify loop for SIPGate
2019.01.22 16:20:18 4: SIPGate[23304], cb_final - status : FAIL - final : 486
2019.01.22 16:20:18 5: SIPGate[23304], 0. Ende des ersten Loops
2019.01.22 16:20:18 5: SIPGate[23304], 1. rtp_done : 0
2019.01.22 16:20:18 5: SIPGate[23304], 2. fi : 1
2019.01.22 16:20:18 5: SIPGate[23304], 3. Final : 486
2019.01.22 16:20:18 5: SIPGate[23304], 4. timeout : 0
2019.01.22 16:20:18 5: SIPGate[23304], 6. call_established : 0
2019.01.22 16:20:18 5: SIPGate[23304], RTP done : 0
2019.01.22 16:20:18 5: SIPGate[23304], Timeout : 0
2019.01.22 16:20:18 5: SIPGate[23304], Final : 486
2019.01.22 16:20:18 5: SIPGate[23304], while : 0
2019.01.22 16:20:18 4: SIPGate[23304], Calltime : 0
2019.01.22 16:20:18 5: Cmd: >{BlockingStart('60')}<
2019.01.22 16:20:18 5: Cmd: >{SIP_CALLDone('SIPGate|1|canceled|0')}<
2019.01.22 16:20:18 4: SIPGate, CALLDone -> SIPGate|1|canceled|0
2019.01.22 16:20:18 5: Starting notify loop for SIPGate, 6 event(s), first is call: done
2019.01.22 16:20:18 5: End notify loop for SIPGate
2019.01.22 16:20:18 5: SIPGate, fifo is empty
2019.01.22 16:20:18 5: SIPGate, no elbc
mal als Schnellschuss, ersetze den sip_registrar sipgate.de mal gegen die echte IP -> 217.10.79.9
sip_user und sip_from so lassen.
Zitat von: Wzut am 22 Januar 2019, 16:51:37
mal als Schnellschuss, ersetze den sip_registrar sipgate.de mal gegen die echte IP -> 217.10.79.9
sip_user und sip_from so lassen.
Vielen Dank für den Tipp! Habe es geändert, jetzt dauert es nur noch ein paar Sekunden! :)
So ich hab dann noch mal getestet.
Ich bekomme es einfach nicht hin.
FHEM will per SIP nicht bei der Fritzbox anrufen.
Damit ich weiß ob es überhaupt mit meiner Netzwerk Config funktioniert, habe ich extra einen DoorPi noch mal aufgesetzt.
Hier geht es ohne Probleme.
Mit den gleichen Einstellungen. User Passwort usw.
Soweit ich weiß nimmt Doorpi Linphone, hier auch mal die config von DoorPi.
Weiter unten dann auch noch die aktuelle Config und das LOG von fhem.
Jemand noch eine Idee?
Braucht das Modul / FHEM als User rechte auf ein bestimmtes Programm?
[SIP-Phone]
firewallpolicy = PolicyNoFirewall
audio_codecs = PCMA,PCMU
call_timeout = 30
capture_device = ALSA: USB PnP Sound Device
dialtone = !BASEPATH!/media/ShortDialTone.wav
dialtone_renew_every_start = False
dialtone_volume = 35
echo_cancellation_enabled = False
identity = DoorPi
local_port = 5060
max_call_time = 120
playback_device = ALSA: USB PnP Sound Device
record_while_dialing = False
records = !BASEPATH!/records/%Y-%m-%d_%H-%M-%S.wav
sipphonetyp = linphone
sipserver_password = xyzs1212
sipserver_realm = 192.168.178.1
sipserver_server = 192.168.178.1
sipserver_username = devdoorpi
stun_server =
ua.max_calls = 2
video_codecs = VP8
video_device = StaticImage: Static picture
video_display_enabled = False
video_size = vga
Internals:
FUUID 5c483e55-f33f-abd1-feae-433b0a209ec077c0
NAME sip.fb1.doorpi
NOTIFYDEV global
NR 1082
NTFY_ORDER 50-sip.fb1.doorpi
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
Helper:
DBLOG:
call:
DBLog:
TIME 1548692083.12628
VALUE done
call_attempt:
DBLog:
TIME 1548692083.12628
VALUE 0
call_state:
DBLog:
TIME 1548692083.12628
VALUE fail
call_success:
DBLog:
TIME 1548692083.12628
VALUE 0
call_time:
DBLog:
TIME 1548692083.12628
VALUE 0
last_error:
DBLog:
TIME 1548692083.12628
VALUE CallRegister
state:
DBLog:
TIME 1548692083.12628
VALUE initialized
READINGS:
2019-01-28 17:14:43 call done
2019-01-28 17:14:43 call_attempt 0
2019-01-28 17:14:43 call_state fail
2019-01-28 17:14:43 call_success 0
2019-01-28 17:14:43 call_time 0
2019-01-28 17:14:43 last_error CallRegister: Failed with error 110
2019-01-28 15:46:48 listen_alive no
2019-01-28 17:14:43 state initialized
helper:
CALL_BYE CallRegister: Failed with error 110
CALL_ERROR 0
CALL_NAME unknown
CALL_NR **611
CALL_START 1548692019.11327
CALL_TIME 0
CALL_TYPE out
Attributes:
history_file ./log/sip.fb1.doorpi.sip
history_size 0
room 9.98_Test
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:devdoorpi@192.168.178.1
sip_ip 192.168.1.11
sip_listen none
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user devdoorpi
verbose 5
Log Auszug
2019.01.28 17:14:43 5: sip.fb1.doorpi, no elbc
2019.01.28 17:14:43 5: sip.fb1.doorpi, fifo is empty
2019.01.28 17:14:43 4: sip.fb1.doorpi, CALLDone -> sip.fb1.doorpi|0|CallRegister: Failed with error 110|0
2019.01.28 17:14:16 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/73_AutoShuttersControl.pm line 2220.
2019.01.28 17:13:39 4: sip.fb1.doorpi[7484], using Leg.pm to find a free port
2019.01.28 17:13:39 4: sip.fb1.doorpi[7484], my parent is 1629
2019.01.28 17:13:39 5: sip.fb1.doorpi, call has pid 7484
2019.01.28 17:13:39 4: sip.fb1.doorpi, call -> sip.fb1.doorpi|**611|20||0|0
2019.01.28 17:13:39 4: sip.fb1.doorpi, sip.fb1.doorpi|**611|20||0
2019.01.28 17:13:39 4: sip.fb1.doorpi, calling **611, ringtime: 20 , no message
dein FHEM ist einem anderen Subnetz als die FB ?
Wie sind die Netze verbunden bzw. ist die FHEM IP eine NAT IP ?
Edit : ich sehe gerade wir hatten dein Thema auf Seite 50 schon eimal , damals bist du die Antwort schuldig geblieben wie der Aufbau deines doppelten NATs auschaut und ob die FB unter 192.168.178.1 direkt mit der 192.168.1.11 reden kann.
Zitat von: Wzut am 28 Januar 2019, 17:39:47
Edit : ich sehe gerade wir hatten dein Thema auf Seite 50 schon eimal , damals bist du die Antwort schuldig geblieben wie der Aufbau deines doppelten NATs auschaut und ob die FB unter 192.168.178.1 direkt mit der 192.168.1.11 reden kann.
tja, und für mich war es der Anlass ein wenig zu basteln. Lade Dir bitte mal das angehängte Script runter und führe
chmod a+x SIP_checksettings.pl
./SIP_checksettings.pl sip.fb1.doorpi
aus. Der Output sollte uns mehr Aufschluss geben. Ist ein Jungfernlauf im unbekannten Umfeld, kann also auch in die Hose gehen ;D
Hallo no_Legend,
Zitat von: no_Legend am 27 September 2018, 10:47:38
Die FB und das interen Netz haben andere IP Bereiche.
Das ist leider dem Doppelten NAT geschultet, da mir KabelBW hier nichts liefern will als reines Modem und ich eine OPNsense wegen VPN usw. am laufen habe.
Die OPNSense lässt alle Ports durch.
...
kannst du mal bitte in deiner OPNsense mal folgendes tun:
OPNsense -> Firewall -> Log Files -> Live View
und unter filter die IP-Adresse deiner FritzBox und einmal die IP-Adresse des FHEM-Servers eingeben und die entsprechenden Logs während des SIP-call (am besten rufst du aus FHEM dein Handy an...) aufzeichnen bzw. ein Screenshot erstellen?
Viele Grüße
Mikka
Zitat von: plin am 28 Januar 2019, 18:04:28
tja, und für mich war es der Anlass ein wenig zu basteln. Lade Dir bitte mal das angehängte Script runter und führe
chmod a+x SIP_checksettings.pl
./SIP_checksettings.pl sip.fb1.doorpi
aus. Der Output sollte uns mehr Aufschluss geben. Ist ein Jungfernlauf im unbekannten Umfeld, kann also auch in die Hose gehen ;D
Danke ich weiß eure Arbeit echt zu Schätzen.
Bin leider nicht vor heute dazu gekommen.
sudo ./SIP_checksettings.pl sip.fb1.doorpi
Hole Device-Attribute für 'sip.fb1.doorpi' von FHEM
Prüfe alle erforderlichen Attribute
--------------------------------------------------------------------------------
Prüfe einige gesetzte Attribute
sip_audiofile_dtmf: File - existiert nicht!
sip_audiofile_dtmf: File - existiert nicht!
--------------------------------------------------------------------------------
Prüfe lokale IP-Adresse 192.168.1.11
Use of uninitialized value in subroutine entry at ./SIP_checksettings.pl line 276.
Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./SIP_checksettings.pl line 276.
Zitat von: Mikka am 28 Januar 2019, 20:39:48
Hallo no_Legend,
kannst du mal bitte in deiner OPNsense mal folgendes tun:
OPNsense -> Firewall -> Log Files -> Live View
und unter filter die IP-Adresse deiner FritzBox und einmal die IP-Adresse des FHEM-Servers eingeben und die entsprechenden Logs während des SIP-call (am besten rufst du aus FHEM dein Handy an...) aufzeichnen bzw. ein Screenshot erstellen?
Viele Grüße
Mikka
Hallo Mikka,
wenn ich nach der IP von FHEM Filter kommt garnichts raus.
Wenn ich aber nach der IP Filter von der Fritzbox sehe ich dass der Traffic auf Port 5060 abgelehnt wird.
Er klären kann ich das nicht.
Ich habe den Bogon nd Privat filter auf dem WAN deaktiviert.
Anbei Zwei Screenshots.
Aber warum geht es dann mit DoorPi?
Gruß Robert
Zitat von: no_Legend am 28 Januar 2019, 21:06:34
Hallo Mikka,
wenn ich nach der IP von FHEM Filter kommt garnichts raus.
Wenn ich aber nach der IP Filter von der Fritzbox sehe ich dass der Traffic auf Port 5060 abgelehnt wird.
Er klären kann ich das nicht.
Ich habe den Bogon nd Privat filter auf dem WAN deaktiviert.
Anbei Zwei Screenshots.
Aber warum geht es dann mit DoorPi?
Gruß Robert
192.168.178.20 ist die WAN-IP deiner OPNsense oder?
Die FritzBox baut eine Verbindung Richtung FHEM auf. Wieso das so ist evtl. Wzut beantworten.
Wenn ich einen mit dem Programm Telefon auf einem Mac aus dem gleichen Netz über die FritzBox mein Handy anrufen, baut die FritzBox keine Verbindung Richtung Mac/Telefon auf.
Geh mal unter OPNsense auf:
Firewall -> NAT -> Port Forward und erstelle die neue Regel wie im Screenshot. FHEM kannst du durch "Single host or Network" und die IP erstzen. Oder unter Firewall -> Aliases einen entsprechenden FHEM-host anlegen ;-)
Mikka
Zitat von: Mikka am 28 Januar 2019, 21:24:31
192.168.178.20 ist die WAN-IP deiner OPNsense oder?
Die FritzBox baut eine Verbindung Richtung FHEM auf. Wieso das so ist evtl. Wzut beantworten.
Wenn ich einen mit dem Programm Telefon auf einem Mac aus dem gleichen Netz über die FritzBox mein Handy anrufen, baut die FritzBox keine Verbindung Richtung Mac/Telefon auf.
Geh mal unter OPNsense auf:
Firewall -> NAT -> Port Forward und erstelle die neue Regel wie im Screenshot. FHEM kannst du durch "Single host or Network" und die IP erstzen. Oder unter Firewall -> Aliases einen entsprechenden FHEM-host anlegen ;-)
Mikka
Komm ich heute nicht mehr dazu.
Welche App zum telefonieren vom mac aus nutz du?
Gruß Robert
Gesendet von iPhone mit Tapatalk Pro
Zitat von: no_Legend am 28 Januar 2019, 21:28:57
Komm ich heute nicht mehr dazu.
Welche App zum telefonieren vom mac aus nutz du?
Gruß Robert
Gesendet von iPhone mit Tapatalk Pro
Telefon
Screenshot habe ich soeben angehängt :-)
Viel Erfolg Morgen oder wann auch immer ;-)
Zitat von: Mikka am 28 Januar 2019, 21:34:02
Screenshot habe ich soeben angehängt :-)
Viel Erfolg Morgen oder wann auch immer ;-)
Morgen sollte schon klappen.
An welcher Stelle hast du die Regel? Oder spielt das keine Rolle?
Gesendet von iPhone mit Tapatalk Pro
Zitat von: no_Legend am 28 Januar 2019, 21:37:29
An welcher Stelle hast du die Regel? Oder spielt das keine Rolle?
Wenn du als letze Regel nicht selbst eine block Regel erstellt hast (dann sollte die Regel davor), spielt die Stelle keine Rolle.
Zitat von: Mikka am 28 Januar 2019, 21:24:31
Die FritzBox baut eine Verbindung Richtung FHEM auf. Wieso das so ist evtl. Wzut beantworten.
Warum nein, aber das sie es macht hatten wir hier im Fred schon öfters. Da dies ja wohl z.Z. nicht möglich ist erigbt das dann den Fehler 110 -> Timeout
Warum es mit linphone geht ? Keine Ahnung, aber wenn so gute Analyse Werkzeuge zur Verfügung stehen dann würde ich doch mal mit DoorPi/linphone einen Versuch starten und schauen was dann das Firewall Log sagt.
Eventuell gibt es wenn das UDP Port 5060 Problem mal gelöst ist ein weiteres mit RTP wenn die Sprache übertragen werden muss, das hatten wir hier aber auch schon mal und ggf. ist dann eine weitere FW Rule nötig.
Zitat von: Wzut am 29 Januar 2019, 07:29:48
Warum nein, aber das sie es macht hatten wir hier im Fred schon öfters. Da dies ja wohl z.Z. nicht möglich ist erigbt das dann den Fehler 110 -> Timeout
Warum es mit linphone geht ? Keine Ahnung, aber wenn so gute Analyse Werkzeuge zur Verfügung stehen dann würde ich doch mal mit DoorPi/linphone einen Versuch starten und schauen was dann das Firewall Log sagt.
Eventuell gibt es wenn das UDP Port 5060 Problem mal gelöst ist ein weiteres mit RTP wenn die Sprache übertragen werden muss, das hatten wir hier aber auch schon mal und ggf. ist dann eine weitere FW Rule nötig.
Okay,
ich schau mal nach was bei Doorpi rauskommt und melde mich dann.
Die Firewall Rule von MIkka richte ich heute auch noch ein und berichtet dann.
Gruß Robert
Zitat von: Mikka am 28 Januar 2019, 21:41:38
Wenn du als letze Regel nicht selbst eine block Regel erstellt hast (dann sollte die Regel davor), spielt die Stelle keine Rolle.
Mit dem Portforward ging es nun.
DoorPi geht ohne Probleme.
Interresant.
schön für dich , unbefriedigend für mich ....
Hätte mich wirklich interessiert warum linphone durch die FW Rules kommt und Net::SIP nicht.
Hallo Wzut,
Zitat von: Wzut am 29 Januar 2019, 16:41:38
schön für dich , unbefriedigend für mich ....
Hätte mich wirklich interessiert warum linphone durch die FW Rules kommt und Net::SIP nicht.
ich vermute eher das es an der Firewall-Distribution selbst liegt. Hatte das mal mit IPFire ausprobiert, geht ohne eine NAT-Regel erstellen zu müssen. Werde das mal im Forum der Firewall-Distribution weiter diskutieren :-)
Viele Grüße
Mikka
Ich hab grad mal begonnen mich mit dem 96_SIP.pm modul zu befassen.
Mein FHEM rennt auf einer Sysnology Diskstation und da hab ich erstmal folgenden Fehler bekommen:
SIP_Phone_WM[4112], can´t find my parent 522 in process list !
Died at ./FHEM/96_SIP.pm line 386.
Diesen habe ich behoben indem ich Zeile 383 angepasst habe, weil "ps -e" nur fhem und nicht perl ausgbit.
alt: if (index($result,"perl") == -1)
neu: if (index($result,"fhem") == -1)
Damit funktioniert es nun, micht hat nur nich folgende reading irritiert:
last_error ListenRegister: Failed with code 401
Da meldet eigentlich ein Authentication Fehler, und desshalb habe ich einen TCP dump gemacht und sehe das natürlich der erste Register ohne Authorization Digest mit 401 beantwortet wird, aber danach eine der Register erfolgreicht mit OK von der FB quittiert wird.
Sollter der vorherige 401 dann nicht besser bei erhallt des OK aus dem "last_error" gelöscht werden?
Intressant :) u.A. weil wir gerade gestern auf dem 6.FHEM User Treffen in Karlsruhe das Thema SIP & Synologie hatten.
Läuft FHEM direkt bei dir auf dem NAS oder als Docker Container ? Poste doch bitte mal die vollständige ps -e Zeile für FHEM.
Den 401 Fehler habe ich auf meinen Raspis auch nicht, wird das Reading zyklisch erneuert ? Wenn ja wann ?
Ich möchte last_error eigentlich nicht löschen, dann lieber den 401 erst gar nicht eintragen wenn "normal" beim ersten register Versuch ist.
Hallo,
hatte heute erstmalig folgenden Eintrag im log:
Can't use an undefined value as a symbol reference at /usr/share/perl5/Net/SIP/Dispatcher/Eventloop.pm line 59.
2019.05.04 18:17:53 0: Server shutdown
Kann damit jemand etwas anfangen?
Elektrolurch
Habe ich noch nicht gesehen. Welche Version von Net::SIP nutzt Du?
siehe "our $VERSION = '0.815';" in "/usr/share/perl5/Net/SIP.pm"
Hallo,
beim Abspielen einer Audiodatei im Doorbird bekomme ich bei set Doorbird Transmit_Audio im Log folgende Ausgabe.
/usr/bin/sox: SoX v14.4.1
Input File : '/opt/fhem/audio/big_ben.mp3'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:00:08.57 = 377849 samples = 642.6 CDDA sectors
File Size : 137k
Bit Rate : 128k
Sample Encoding: MPEG audio (layer I, II or III)
Output File : '/opt/fhem/audio/big_ben_tmp.wav'
Channels : 1
Sample Rate : 8000
Precision : 14-bit
Duration : 00:00:08.57 = 68544 samples ~ 642.6 CDDA sectors
Sample Encoding: 8-bit u-law
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
/usr/bin/sox INFO sox: effects chain: input 44100Hz 2 channels
/usr/bin/sox INFO sox: effects chain: channels 44100Hz 1 channels
/usr/bin/sox INFO sox: effects chain: rate 8000Hz 1 channels
/usr/bin/sox INFO sox: effects chain: dither 8000Hz 1 channels
/usr/bin/sox INFO sox: effects chain: output 8000Hz 1 channels
2019.06.05 16:23:01 4: Sip, audio file /opt/fhem/audio/big_ben.ulaw found
2019.06.05 16:23:01 4: Sip, Sip|**620|30|/opt/fhem/audio/big_ben.ulaw|0
2019.06.05 16:23:01 4: Sip, call -> Sip|**620|30|/opt/fhem/audio/big_ben.ulaw|0|0
2019.06.05 16:23:01 5: Sip, call has pid 1595
2019.06.05 16:23:01 4: Sip[1595], my parent is 1556
2019.06.05 16:23:01 4: Sip[1595], using Leg.pm to find a free port
2019.06.05 16:23:01 4: Sip, CALLDone -> Sip|0|CallRegister: Failed with code 400|0
2019.06.05 16:23:01 5: Sip, fifo is empty
2019.06.05 16:23:01 5: Sip, no elbc
Kann mir jemand deuten, was falsch läuft?
Danke und Gruß
Siggi
Zitat von: Isnogud0815 am 05 Juni 2019, 16:34:25
Hallo,
beim Abspielen einer Audiodatei im Doorbird bekomme ich bei set Doorbird Transmit_Audio im Log folgende Ausgabe.
Kann mir jemand deuten, was falsch läuft?
Danke und Gruß
Siggi
Kannst Du bitte den kompletten Set-Befehl so wie Du ihn absetzt posten.
Moin,
der komplette Befehl lautet "set Doorbird Transmit_Audio /opt/fhem/audio/big_ben.mp3".
FhemModul 73_Doorbird.pm
Gruß
Siggi
Hallo Siggi,
Doorbird kenne ich nicht, scheint aber implizit ein SIP-Device aufzurufen.
Kannst Du bitte ein list des Doorbird und des SIP Devices posten.
Hast Du bei beiden Devices verbose 5 gesetzt?
VG plin
Hallo plin:
folgendes habe ich mitgeschnitten:
List Sip
Internals:
FUUID 5ca1f6e3-f33f-0d2d-c950-9e0e20aabff8fc8f
NAME Sip
NOTIFYDEV T2S
NR 345
NTFY_ORDER 50-Sip
STATE initialized
TYPE SIP
VERSION V1.91 / 31.07.18
READINGS:
2019-06-05 16:32:26 call done
2019-06-05 16:32:26 call_attempt 0
2019-06-05 16:32:26 call_state fail
2019-06-05 16:32:26 call_success 0
2019-06-05 16:32:26 call_time 0
2019-06-05 15:55:48 caller reject
2019-06-05 16:32:26 last_error CallRegister: Failed with code 400
2019-06-05 16:22:26 listen_alive no
2019-06-05 16:32:26 state initialized
helper:
CALL_BYE CallRegister: Failed with code 400
CALL_ERROR 0
CALL_NAME unknown
CALL_NR **620
CALL_START 1559745146.78459
CALL_TIME 0
CALL_TYPE out
Attributes:
T2S_Device T2S
history_file ./log/Sip.sip
history_size 0
room Door
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from Doorbird@fritz.box
sip_ip 192.168.0.200
sip_listen none
sip_registrar fritz.box
sip_ringtime 3
sip_user Doorbird
verbose 5
List Doorbird
Internals:
DEF 192.168.0.66 crypt:035a065f050f03025552 crypt:1c7f294023216b05322d
FD 27
FUUID 5cd6dba9-f33f-0d2d-6668-863181cecace9f35
NAME Doorbird
NR 360
RevisonAPI 0.25
STATE connected
TYPE DoorBird
reusePort 1
OLDREADINGS:
READINGS:
2019-06-05 16:22:21 BUILD_NUMBER 15578987
2019-06-07 04:22:20 ContactLostSince
2019-06-05 16:22:21 DEVICE-TYPE DoorBird D101S
2019-06-05 16:22:21 FIRMWARE 000119
2019-06-05 16:22:22 Firmware-Status up-to-date
2019-06-05 16:22:21 RelayAddr_01 1
2019-06-05 16:22:21 WIFI_MAC_ADDR 1CCAE370FF78
2019-06-02 14:15:51 doorbell_button idle
2019-06-07 04:22:21 motion_sensor idle
2019-06-07 04:22:21 motion_snapshot No image data
2019-06-07 04:22:21 state connected
helper:
EventReset 5
HistoryDownloadActive 0
HistoryDownloadCount 0
HistoryTime ????-??-?? ??:??
ImageFileDir /opt/fhem/picture/Doorbird
KeepAliveTimeout 30
MaxHistory 50
PollingTimeout 5
SOX /usr/bin/sox
SessionId 3QNw0z9bX00zzeTcSQWD4hj7GOubLentfeiBiNCrqkP9rTGycMa2fcmMDqoBk
SessionIdSec 540
SipDevice Sip
SipNumber **620
URL 192.168.0.66
UdpDoorbellId 0
UdpKeypadId 0
UdpMessageId 11322
UdpMotionId 1559874133
UdpPort 6524
WaitForHistory 7
debug 0
Images:
LastSnapshotPath /opt/fhem/picture/Doorbird/20190605-163508_snapshot.jpg
History:
doorbell:
motionsensor:
Individual:
Data /9j/4AAQSkZJRgABAgEAYABgAAD/2wCEAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4pLSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk8BDg4OExETJhUVJk81LTVPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT//EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/AABEIAeACgAMBIgACEQEDEQH/3QAEAFT/2gAMAwEAAhEDEQA/AMSZ9iEnqKpGPfaSvk56fj2/WpLx+ijtyabZHek8YySyZA9WHIpPdIzWzZjswxUZODn1p7rhyo7GomPbFMq4oI70O4yoUfjSIhc4FWltwseGGWOaBkOfmHrWlZEDUbfIHUDnvmspmw44zkVp2xK6lbnHR0/nSYI38cUoFKR2pV9KCQxxR9acRijHH44/GgBh6VnaocvCP94/litE1l6k2bpF/ux5/Mn/AAoew1uU/pQKAeKUVgdA08kD8acKb/EacKGCHYxQew9aKVeWJ9OKBjgPUU8CkUd6eKQCcAHNOReMkcmkIyQtSIMnpTAci8VMq01Bk5qeNfyoBikFVAXl24Ht71YiiCqAOlMt1Lt5nrwvPb/69XI03Y9KpEDUiyfan7ARgCrCphSDxx1oIVEMjD5R2HU+1WiWynKpXCpzK/TPYep9qaIVjTYvPqT1J9atiI5Lv/rH6/7PoBQIiT2AHemBT8snqOKiZOc44q80YBPJIqJ0CqXchVA5NAymwAUs5woqMRGQ75AQByqn+Z96tLC0hWSRSoHzRoe3uff+VDDFJjRWZQKicYNTuOKhZfWlcogYdaikIUc1LK+DtXlvT0qHbkkk5NICMgsfn6dhQcU8imkc0hkZpCKcR2xzSdOvWgBpHFN6nAFSbC33uB6U7AHApAQ7O780EelSEetN6dKLiGY9aTGOlPIpCQOtADNvrRgA04knGKbjnnmgBM+gpCD3P4U6kpDG4ApCOeadiigQ3HrSAZpx6Un6UAxMUcd/woz6Cjk+1MBaTIFGPej8KADPoKXJyMUUo60gEwfWjHrTsUYoANox0q9pR26hb++V/Q1Tq1p2Pt9p7vj9DVR3JlsdMoyal4Ebk/3Wz+RqJBgcD3pbhjHaTsBlhE2PyqzFGT4fuGzJavnAwyc8D1H9a15kDxkd+1YVgDHbtcqOY58/8BwM10ACkeYhyCPlPtVMOpndiKraiPNsjCDhppEjH4n/AOtV6ZNkh475FVZE8y+sYiOPNMh/4CMj+tAGZq7K2sTq2VRAq8fQf403QbGO9nnluFLwRfKq9mY/4D+dRau4+33m48mU4H4Ctzw/AIdFhOMNMTK349P0AqEru5tKVoWQ240CwmH7tGgbPJU54+lWbCzisoDBCGxnLM3VjU808UBXzW27uAe1PVcMcknNWlYxcm9GNYZHFAAFO70MMkU0ScjcPliT1p+nS+XdxvnHPP0qvK2TSRko361C11LSsMvo/s9+6joDx9Bx/SqLr85FbWupmSC5GSJVBJ98dP8Ax2sqddp47jNaMmI6yXLMTV2bCyAegBqvp65DfUVLdNm92/8ATIfzNCHIoSrh/TaSKuCUxzJMFDFcNg+o5qpdcsT7g1KCTECeuKTGtjrI38xUkUYDqGA9MjNSAVWsjmxtT/0xT+VWv0pEtajZGCoWJwFBJqlpwZxNOxI3Y+Xtzz+nFO1J9sAj7yHH4Dk/0/OpbNdtsU9wf50DXclbpWNqDZvGx2jUfz/xrXY8VjXp/wBNm+q/+giiWw47kOaAaSjOFrE3EXkk+9PFNXpTqGCHAUqdMmmHp9akUdqQyRafTV6UpOF479KQxU5y3rwKlQcUxQAAB0FTIMDNNgSIOafjcRGP4vvH0FNGACzdBU1uvG5vvNz9PSi4mW4lHYfhVyJRnHtmq8Kk8jrV2IYGB+NUiGORCxpAPNfzB/q1OI/f/a/wqRl3nyhwDy59vT8amCHsv0Aq0QQeWM46n+VNCHb83U9atBcKcALmm7Cx4qgKpQcknAAyTUQgMrCSQfu1/wBWnqf7x/oKuLCJ9pIJhB4H98+v0qR06mkMzpE79zVOQc8VpSrzgVTkTHNSykU2GBk1UkYsSqdup7CrcgMn3chO5/vfSonQKvoB0FTcoqFdowKiPHAqVyd2KYw4oTGRkH60EY4pxwo5yaNjHlzj2obAiClvu/maXaFHqfWpW9BTG470gGkZppFO6/Sk4HNIBuM9aaSBSkk9OKTAH1pgMOT04FJt5z3px5puKLgIaTtzTsUH8qQDcUnNKT7UnWgBM4pCfSnYpCKYEanOc9QelLgelI2FkB7HinGgQnWjHrRR+NAxKWjIzSZ9BQIXqelKKbn8KXn1oAdntRketIADzS8YoAXcMVb07/j/ALX/AH8fmD/jVQdKs2BxfWmOnmj+tOO5MtjqFPIApuoMF0u7buIj+vFOXHFJexGbTriME5KZAHfHatGZLczNKUNp+1+jM+R7ZxWhpjk2pib70LFD7+n9apaZxptuT1ILH8Sf8asQnydTAzhbhCMf7Qo6g9i1dJlA47cGqMC79ZAxxFblvxJx/I1oyKXhKjjPFU9PTNzezHoXWNf+AjB/WgT2MjXtKuZtTDQIzrckDIH3TwOfb/Ct+NFiVYUxtjUKv0AxUxJXoTimgcgjk0Dk7mdqUbXTPapyFiMhx/e7Cp9NuDc2McjHLgbX+oqOwUb7mUZO6UqCe4Hf8yahs/8ARNXntOkcw82Me/8A+rNWQzTNHQUtJSA4dmy9TzpsKHHUYNUmY76na4kESpcKcH7j4/zmktC2X7lftGgo3Ja3kKjjgA8/zAH41m3Ef+hxzgjltje/Bx/6Cav6dG960lpG+FlXJX+9t5qkPms7iE4JjO4fhzkfgD+dUiXoO08fu8n1qvqDMNSfYcEKP5f/AF6t2H+rH1qreLjUpyBxgc/8BFA3uVckpyc1NGcwnFQqO3tUkR/dNSHY/9DJ0vnTLbJ6JirdUtHOdLi5zjI/WrcjiKNpG6INx/CgmW5n3B8/UCvVYvl/HqauQcxt9RWbExitpJ35bGfx/wD1mtGA/IwNINkK3SsS5ObmU+rf0ArakPFYcxBnl9pG/maUti47jaQ/dIooJ6VmaiYZejfnS7iOq/iKKUGkMVSGYYOcVMtRLyxNSr1oYIkFA5cf7NApEYEdeTSAmQZJqZeoAqKPhenNTKQq7j0FAxxG9hH26t71biye9VYgQCW4ZuTVuIHovWgVi7D0AAxmriHy03AZY8KPU1BAAfTA7mrNuN58z+Ej5M+nr+NNEMsQxbV27skn5m9TUwHyAYxmiPaYyV68gnvT8cAfgK0RDI9pZsKOe1N8oTApz5QPzH+/7A+lSspY+Sh2n/lo4/hHoPc1OqBVAUAKBgAdhTAjK+wHYYqBxzgVaIycCmOAqknoOp9KQzPlUKp6dOfaqEiGUZbIj7DoW+vtWo0JkIeUYUcqh7+5qvOOpqWUjMkUD2HaqsoznPSrswyTVSVSyORII9o4Zh37AD1qdy+hRlAXlmVR/tED+dVmuYQ2wTRZ/wB4Yq59miIVzCrHu8uWLfgeB+VQuiA/6mLH/XNf8KashajI2hOSk0Tt3O8f41FcXUUJxI2D6CmzQ2rLua3j47gYx+VZkqwDJUnjJ2kk4qlFPYlytuXPt6OfkB/GpVDPyeBVC1jRJo3uMojflkjjJ/Wtfy9owTn0pSSQ4u5Hgnp+dNKjOTyalPGabUXLIye9JjPankdKQkDjvQBGRg0hIHU05sn2pNo7UAR8kcDFG3PXmpCKaRQKwwikxTyKYSKBCHr1pDS4pCuTk0AMkAZcdTRk46c0/HakpgN57GjHelNJ9OaACkpTSUAFKKQkUZoAdS00ZxS96BDvpVix/wCP21x/z1/xqsBmrOnqDeWv/XT+hpx3FLY6iPuPTmp42C81BEMnPrUwFaMxKXlCBfLX7qcAUy73LCJUALQurj8+at3AG/NRABsqc4bIP0pFFxSGUMn3WAYfjQAAoCgAdcAVV0tybPym+/Axjb+n6VbPWqJGkZpr8LxwelP78VHJ94CmJldFW1tdo6Rgn685/rVPVVeOO3vlALwON/uCauyjdsjxnLZP0FOuIlnt5In6MpFV0EiYEMu5eh5FJVLSJml09Fc/PF8p+nb/AD7VdpAtDz8N8/Nbdq0c9ntRSUBwVbnBrBB+atLSZcTtETxIOPr2/rSLYsMrWdxviwGjbjPTH/6qjvrd7XUCjADzMtgdBznH5EVPqUYE6dg+QfwqxrG6fSbLUACzw/un9BjoPqeCfpVEbop2K7VC9wxH5VUu3AvLpW/iXH44GK0isY1qPLZinKuO3B+XP6ZrKvo3F9cjaxCSlN2OOOKLWRUdbWK+R5v5U+H+NCcU2QgMpAA47UqHEpxxkVIzrNICiwj24wURvxI5/UGm6lIPLEOc72yR7Dn+eKNHJ/s+PPZQv5En/wBmFRTnztRYZBEYC5/U/wCH4UCtqVNTbZbxQjucsPp/9c/pWtCQd31rCv38y8kX+58tbNu2UJ9QDSRXQfIeDWG5zK59XY/rW25wRXPocqp9qUthx3H0HqKSlP3qzNRacPem0pPWgBydPrUi9KjWpF6Uhjzzx60/YpHIBqNTls1KMUAhQrg/K/4NyKlDFiFZcY5PPBpq8DJ6d6emep780DsWE5OauQdRVOPO7irsJCLu9Og9fapAuxqGxFnjGX/wq/Fjdj2zjtWbbTxjajZSRjkq42lj7HvWnGDxnIpozepZjGByOTyfrUnIIC8uent71EGCLlsnnAA6k+lW4Yyoy3Ltyfb2rREiIgRcD8yeTTjTyKacKCWOAOp9KoQhwqkkgADk0zyi3zSDgHKqf5n/AAqRIy5DyDAHKr/U06Q5z1pDKs3I+vWs+deSDxir8uQDk81QuAc7Y1yx5yeg+tS2UjOlGQQfvenc+1Y+rJOt5p6CYQu8jsMn5RheMjvnpWzc2TzLgOSUPJzjII6/hXPXXh2SWdibxdh4yyszH368Uo23uN3eiLEl+sXy38Mts46naWQ/QioG1LTj/wAvSn6I3+Faoj2RrGGLKoC885xUeOfkVeOCQoqLxLSkZ4SC9jbdHMlvH8zMw2eZ7euKo6jbWdraAW6OfOB5LZxjB5PoP610NuqfaEWbDRuQH3dCP6VHdWUHlSDyVMIn/dg8gDnH6YrSDVrmck72MbTX8+wZZIk2Bivs/vQF+xOFLFrVjgFjzEfTPpWiULADjA6e1RyKjRtG4yrjBFRzXZfLoRsuDj0pjYHA5NFtvaHY7ZaJjGx9SOP5YqTaB0FLYa1RAQx68U3bipytMIouFiLFJ34p5puCfamAw9MU36VJgDtSGgCIr6mginmmYouIbj1pMU4+wpKYhhHvSE4706kZcqRQA0mmk0gJxz1pfegBMmiiigAo70UYoAUEYp4x0pqgmnAGncQuDiremf8AH/a5/vn/ANBNVgp9at6WCL+346FiP++TTjuKWx0Uf86fHOj3M1uv3oAuffIzTYRucL71iaRdmTxPfCRi3nltpx2UkD9MVoY26m/MpIzx0qBRz+FW8c4PNVGPl/ngVJSI4SY9RdP4Zl3/AEI61oVStlEmqSn/AJ4Qqv4sc/yq9jnpVIliEc4qFjlye3apS22Ms3aqguF3zKBzF+px/jVITFUAzuf7uF/xqUVHAhjhUN97qfqakA61RJn24FrrM0AP7udA6567h/k1bu7lLSxnuX4ESEj3PQD86raqDELa8XrBKNx9jWX4vugqQWUbfe/eyfToo/nUspK7OdU8mpY5WimV1OGUgio4xlwCcA05xtYgHOD1pDNu6AuoTcR/dCgpn+X9KdZSLcWF3ZeW8hdfMTaPukcE/XBqDSlW5gaOViwiOQnbB/8Ar1LZy/2dqSuCQsT5z/sHr+hNO4ktbGZJdFbaJHyZYCUx7dP/AGUfrVV7qWZnaRiS5y3ufWrGt2/2fV7m3C7QjjAH93Ax+mKpAYbGOaH2KgtRZsvMScevFOXJAYfw0spAYOOoAFOiO2YehpDludJpFxHHA0UhAZR5i5/iGAD/ACH51FbHEUk8nU/Of5mqMbHzIQvfKf0q5efu7JUGf3hA49Ov9P1oYrdTMRi0hLHknJ+tbtmcxrn/AJ5r/KsQRtGRkYzyK2bFj5a9PuCpRUkSSn6k1gIcInf5RW5OTyPWufWQAKGPOBTlsEdycGjPJpqsMDkH0pQc1maH/9HjRS9SKaDxTgeeaysajx0p2cU0EUvegZInQetSqeahB+apFP6UWGiXI4H51NHVZDk5NToealoaLUfOKuQHL+y8L9e5qkhIGAeT+lXIMDA/CoYzSjCsmxlVlPUMMirEcHlr+4lMYHO1/mT/ABH51Wg6DNWkIkfb/AOW9/ahMlouWYaTbNKoU4+Vc5wPX8avDgVXiNWF5FaJmbQp4GScY6+1NjTzGDsCEHKg9/c00tvIYxO0A/iXnJ+nXFTLIsib0ZXU/wAQOaokVv51FJkL7mn5Ocj8feomzITtJC/3vX6U2xlZ9zEon0LelV5FWNSFGMnJPqauSYVcKMAVTlOee1ZsuJSfr+lVZAFGTVuQ87VGT/KovL28n5m9aybNEVDGW5cYH92mMOwwKssvPWo2AxmpuWVmX1prkn75J+pqVgTwo/E0zZg89ad7BYrkM3sKbs5wB1qwV7DmqN/cNFbStCqSbCFkz/CDkdvfAqoq+iJk7ajvL2PLz1f+gFI3SmWMezT7dVB/1YJJ9Tz/AFqUqO/NU9xLYhPPQU0r61MaYQaAIj06CmGpD35pnNAhh6Uh+lPwKQjmmgIyD34ppFSkdaYeOtAiPGaQink+gpvNADTSHHNKR60mMUxERXDkjoaNvFSH0ptADcUYHpS0ZzQAnTp1opeaMUAKKcDTQOacBxQA4H0q9pC51CPOeFc/pVEdK0NFH+mg/wDTJv5iqitSZPQ3ofllB7A5rirW4+z6pb3XYS5P0J/+vXZSsEtZ5P7sTn9DXCyrug46gcVb3REVdM9F459D0qvKo8zHXJBFNsZ/tOlwXAOS6DJPrReuYrV5RxtU4PoT0/U0NEoXSgXtpLk4zcSFh7KOAP0NW+hptvD9nto4O8aBTj17/rmnUxEcu0D58YX5ifTFYNtOv9sFVIMM3TPt/k1vzIskbK33SCD9MVysaSfaYRCDvLgKOhxn/CmgSudITh9vtk+wpisXCYG0H5vw7UsoLNszzKccdlHWmk4QFQcyNtX2AqyB1zGk1rLHIQEKEkntjvXnlzcPcStNK2WbH5dhXX+JrryNNFqhxJc8Hnog6/meK4tvv49KmW5cNiwgDDBz9aTPUHgjrmpbSQRSiQjhSCaL65S6u2ljQqCAP97Hegdyxo8wi1CPc21XyhPbnpn8cVuzWAuJNwfy3AwcrnNcopAbmuolvc6C12pPmbdh5539M/rmhdiZbXOaupJZbgyStuB4RvVQSBUR4YHtW7qtj5ei2+AN1qBu57N1/XFYJGUPbFA1oOxwR6jigHG1s9KEboauabBHLcFHUsdpZR6kY4/LNJFPuPhlXzouT8rgnFaOon/SFjH8C5/M/wD1qz9QhUSwywDyzIg5HAZgSCf5UxryUTFrtCW6bl744oaEjRuBjyxxwMfoKtWh/dR/7pH61nSX1pKy7JCB33KRirFreWiIm+5iXGQRmlYdye4Py+tZn2UYwD+dTXGo2zDEbO30TA/WooHmuZVA2wRHrI6k8f402gTGG0OflGfpxTfIde5H1FXyqBysUjOg4Dsu0njrjtS49KmxSZnjeOoBpyvgncCPrV4qrfeUGm+ShGeR2pco+YgBBHBpQeae1tg/LimGJk45/Giw7jx0FBOOKYN46rmlBBbBOPrRYdyZG7VPG3NVACKerEcGk0UmX0fnP4D6VdhbkVmRNV2KTAzWckWjWjkIwoPzH9KuwYUBV6Vl257nqf8AOKvRSAniswsasLZFWFPmkr/AOG9z6VnwyFiEU9PvH0q8jAKFX7qjiqTM2iyGoZEZ/MIKyY++pwfx9fxqJXFOU7+o+UHoe9UpEtCqGZfnYMvY7cbqR3wMCnO/YVA7BQSxqriSI5Peqb5f7pwvr6/SpZZTuzJGTFjovJHuR6U0usi70YMvtWcmaJFcqFBAGBUbipXIAyelQNlj6D9ayNCKQgZwMn+VUmurI8ve2w9jIP5Vo/cIK8YPFVHtbUBmWwt5HwSFEa5Y+lONuonfoVZNQ0+MZa+t/wDgLbv5VXOoxS5FpBc3J7bU2r+JPSk0Exf2VG0MSK6sysdoyDnOM9ehFX2yxyzFvqa0ajF2Em2rmcY725yLh0toT1jiOWYehapGjiitZIdp8pkKMB6GrJ5FRuquNrkhTwSBkgU+YOUoqgsZvsAd5NhwSw6E85BHbnp2zUxFWbp0lu5Zo4xGsnQdOAPSoSopzavoKKdiAj0FMIz1qdhUbDvUoZERimFfWpCeKYQT3piGHAFNJ9KdgA+tNPFOwDTnvTCBTyaaQT2piGnimnk+9P2+tN2igBhP40mDUmKQigRGQcUxeQc1MfrUZX5iR0NFgGkYNFLijFMBDRS4FGKAuApf5UZFG4etIB3OK1NDUG5kJ7RD9SP8KyDIoB5ra0IZadv9hB/OrjuRN6F3U28vRrw/9Mto+pIFciwytdR4gk2aQy85kkRfyyf6VzABpyFHY6bwpMJdIMJOTC5H8/6YrYCqQFdQwyDg/pXMeEpdl/c256SIGH1H/wBauoJ5FUR1sSDnOaRhxmlUg1n69qL6XpnnxKDI8gRcjPuf0FMC9gHhuh4NYkUcn9ohkj/eI5jLnoAc8/ln862YX8yFH/vKD1ppQAvtGNxLH3NCQr6EDAmQkZBPyD6dzSxpvmJzhV+Vf6n/AD70SFhuZfvfcT3Pr/n0qhrtwLHSPJjbEk/7tT32/wAR/p+NWQlc5rWL77Xfy3AP7sfLEP8AZHT8+v41lDOMnqalf55Av8K8mlKCoNRUxhuM1D06VNFjDVBQIkBGBzWhppe4lisiQYZJQ7Ke+B/gKzFPPNTJI0TpLG210YMp9CKNhnbNGk0MiSgbJAVb6HrXGPBJDI6SYzGxRvqKvXGv3sjv5DrFG33RsGV49azZJp5neR3LsxyxPemQtxdnHyjkVPbMYXS5VuUbn6dD+hqOHOSQ4+VSdv8Aep6lUkYNxFIM0i09Bz3Hm7Yz/wAsicfjj/AVfgAMhDbQmcnd0rHBCSNsywzhT6+lX4LWW6YC4kMcfXavU8UNCFup7N5dtpaxyEdSiYFSxaTJIN87JAOmxBk/4CpRDHHKIYk2rwD6n6mtFjiPOPvEmi4zO+zQQNiKPJH8bctUgyetDcuaBSY0ApwoA55pSDnigAwKMDrTgPWlx0oGNx81KV55pcc+9KBQBDLhVB2k5OOO1RkALuJyO+RVlkyCp6GmiL+9z7U7AMSIMQyH/vk1OkbkncEf1zwaqToI3TYhUscbhxUyTSKwGd2P73NS0Umf/9LEWFMhTmJj2cf1qdLaYfMoDqO4NNgvQBtdHAPB/iH5VoWwtJjmB9jdzE2z81PH6Vk0bqRDHIR8pGDVyOUnCryT+lSi3kYHmGf2YeW3+BqPyEiXMgltpWP/AC0Hyn6EZFQ0VzIvwyKgVVP596trJgcdqzMTRD5lEinncpp8U8cnG9kA6Bx1qbAakbb+SPlB4B71YEmelZyOwHTj1BqQThThTk/ypCaLryBV6ZPYVXLZO5uvp6VEZeeuT60B+pJouHKOJzVaVAXJTKyf3l6/j61MW3DjIHrTCRipbGkRlTkFiGIHXGKYxx9ac7gDJOKryuxBCnbnvUlA7AfWodxDBuhByPrTfNCkLIMf7Q5B/wAKRiOufyppAUmh+y3vnWysy3rCV4x0T1/MnrVluvNTSzB44l2kFF2gnnA9BUBPpWk3cmCaGn26Uwink8c0xm5qUWNIpjYA9aU80xjTEMbk1G2O9PJzTGBqrEkZPpTD1qUrSEYpgQ7Tik21IaaSPrQIYRTacTTTQIaaaTxxQ0ijjOTTSzY4Q49TTsAU0/WnpBPMcRozf7ik/rUyaXcOSHUrj/no2P5U7E3KhYDqabvHQc1qLpCjBeUD/dTP6mphp9svUSPj+8/9BTUWJyRiZb+7+dOSKaQfIjN9ATW6sMMf3IY1PstPYk4BJxT5SecxFsLth/q2H1wKkXS5WGSyqPdv8K1eOaQnaOhJzjFPlDmZnLpeD80o/Bc1L/ZkKj7zE/7oFXR60vemkHMyothbgc7z7bq0NPgihWQRoQSQSSc/hTFXmrNtjefcdKaRLbKPiFs29tHjq7N+QA/rWFtAJrX8Qtm7gjyPkiz+ZP8AhWUetSylsP0mQW/iG2bgCQFD+I/+tXaEENz2rgbhvKngmA/1bqcfjXeht8asQQWUEiqWxMtx0YxxXMeKZTe6jFZQgsIIizD3PJ/QD866bekMck0pxHGpdvoK5jR2kv7681C55aTEY44GeSPwG2h6IEavhyYT6HbHvGDGfwrQJYyED7uOD6GsLwc2yK+s2Ykwy5H8v6V0FURa10MRC0oGPlThc9yep/z71xOvagt5fySocwx/u4voO/4nNdNr96bLTGEZxNcZjT1A/iP5cfjXDH55Ao+6tNvoOPcEXC5b7x5NKaU0lQMSEE5xUDfWrMR/0eU+mM/nUVzE8TjzI3QOoZdwxketMCLODkVNKASCuNrDI/wqCrEWTEYyBgnIz2p2uA2NMj1pygu21QT9O9LnI5+UVIkxT5bf5Ser98U3sJasR4jEWR+HGOh6Uz92FJBJYdqXarNsDEKo5b3qMjEhAIKg8Ed6lmidiWVIluGSCRinVSRz0zzWnYMWjViQDjn86z4jHvXzvlU4ywGcVorD9gmaB5UlTG+ORDkMp/8A1Ubq4noyzAuZ2bFWpsquPQVBaEOSR0JxTrpwB9TgUkJkAGTTu1MXpTxQMcBSikFOxQAqilApARux3p4oGAHNLtoHWnAUAJtpQuTxTwM04CgZBNHmIjp0/nUXlP5nC5yKtyDKrj15qxBF904zgE8+2alspGfAoKkNxlu9WreOKTbuKkDOTV/T7FJ7PMiFssSPzxXSXGlQJDHLHbQtIqnquAQeOfX1qXLUbaRycD3SsRHM20sBtb5h+taNvqM6yeV5Dsf+mZzu/wCAmrC+HrsSrNHcx7JDnJXkE89BxRY2ssOvhJY3fYGb5R98BcZH40XTEEb2M5IQeU5PPlExHPup4NPe1kYEFopz6OPLf6eh/SrH2Az3jrd2pCSM5XzBkHJ4H5VDfWRsBGLaZ41YNmItvUYGeAenWqcSeZorMhtmCxySQSN0Eq4H59DQZZI/9fGSP7y/5xVote26sJrcSoPvGE7vzRv6VDG9rKcW7CJifurxn/gDf0rOUC1Mb569VcN7dD+VOE2T82B7ZqGaBgctEJPV4jhh9VP9KpMecRSbsdUPDD8DzWbiaJo1fPGaja4HQEZrHa6ZSVfI9jSrdAng4qeRlGi0mTk0xm454FVBcDt+dJ5wPfNHKBZLfh/WmZC8LgCoTKPWmNL70WAmZgByRTS5qAyBhz0pm5l4B3D36imkJk5b3ppeo8+vWjPOadguKcmkx3pc00n1piuFMNBPHWoy4zxlvoM0xCk80w0qpLK22NGJ9FBY/pVlNKuHOZMID/fbp+AqkmS2ig7gd+aaWbqFI9zxW3HpNunLu7+wAUH+v61Zjt7eEfuoI198ZP5mmokuaOdjtLmc/u43Puq/1NTppMjDMromOzEsf04reYsQcsT9TUJUen1qlFEubKUel2yD52kcenCj9KmW2t4j+7gQe5G4/masEUz8KqyJuxGPAAPA4AqNhxxTyMHI5ppHtTEMI45pMZNLj5856Cjrk0AMIHpmm9+elPxn60BGP8J/KgCMY56UmAfzp7KsfMjIn+8wFQPd2UTfPeQD2D5/lQBKRzwaX61QbWNNUnF1u/3Y2/wp9tqlpcy+VD5u7r8yYoAvDr9anhO2RcdzzUP0qROGB9KBGTrTbtVm4+6FX8lH+NUGHetLXE26ixH8aK36Y/pWWzHGallrYhvF3Wz+wrs9Kl+0aXbS5BylcZIxKEe1dP4Vl36KqsR+7Yr+FOIpjfFVw8WlJCgyLiTa30HOPxOPyqBIvsNvbWyD59waQ56t3/z7Vp6qit9jZ1yEnyPY44/lWRv+0O7NwvX8aUn0BBo7fZ/F93B/DOhP48H+prpsFmAFcjdyC38XWNwS2HCDPrnI/wAK2/Et8bGwMMbYmuSUBHZB94/0/GrXwolr3jmNe1D7dfySocwp+7hHsO/4nms9V2qAevU00fPISPurwBT6AEpuKcaQ9KALOkKsly8bruV0IIrTvYTe2whmfc0ahYnYfdx2+h6fl6Vi2WTMQuQxU4x1raglM9ssr43EYbHciqiTI5wRlWIcEMpwVPUGnj5fmPXtWhqMJk3XCcui/OPUev4fyrKZix60bDWorOSfWlSQhWUY+bvSxJuYLt3FuB/SppQAzZUZHHTpUvUuKJYod0KoijnJdm4/yKQwrGFy6HORhWzgioFlcM4LE5Ur9BSJHtdWYYB6Gi19x83YlztG7yyVPGRV7TG0+aYQzzPabuFfblQff2rPLMpXZ0zkCnQAkjOBzmlsVzX0OisojDEUbG5SwJHIJzjiobr+HPXNWoV2QADsABVO4P70D0pmb3EFVbm4njnCQMoG3JDDOeatjpWfKc3cpPbC1I0rskF/cj71vG3+4SDTxqaDiWGVD9QarMSvIPNIH2yBmjVwRgZ7UJlcpox39qxH77af9pSP1qzHLG+Nksb/AO64NZLRD7J54GMuVxjoO1RpDGRyoJz1piN8AjrnmnLzWKiSRj93NImP9ritHTZJpfNE0nmBCApwB6//AFqASLoHHWnKMkU3GakjHPvSZSFdcuoxjqav28P7pnx0QH+VVCuZB67P6/8A1q2xDi1mwOvA/M/4Vmx7FrQrX/iXQkj7z/mN5rpHiymMZwmKq6VbCLTbQY5Chj+IJ/rV+iMG7tkydyuIQoQAfdWmxRbbzOBxEBnvyf8A61WqQD5ifUAVahqTcZLCk0ZSQblJ5BqleaVbTRoixbWyfmU4PTmtGirsBkPb3hDARxTDpknaT9ayhpkaEw6nAo3kBS3I6dm7HmuspjRq5G7BGc4IzSsFz//TrwTXKo3lzMwRAwWT5h3/ABoe6WaMm6h4T+IHOPoeorZuNDaG0zbO8kjh02HoeSPwrGubaWG0kFxDJHk8Erxntz9RWbszRMqucr+7kEqejnOPx6/nVOTaD3jI7E5H51K0WLYygjAbYcHv1qsWZgu7kmiw7sUTFepqRZyRycVTfO7A3Ix/hI4NIGZPvqQPUcik4jUi+Js+tKJc+9VFcMMqwI9jTg5FTYq5bD0b/eq4elMigfMwFKw7lnfSFyOT09R2qBXdztjjJP8AntV2HTbmUAylYx/tH+nWnZibSIPNXoDk+3NKizTPtiQk+wzWtDptrEPumQ/7XC/kKvRrsTagCrnO1RgU1Eh1DIh0eZzm4cRj0Y5P5D/GrsenWsXLK0p/2+n5CruKQj8qtRRDk2RgBE2IoRf7qjAppFSEelNIpkkeKQjninkYNJjvQBEzDOO9Ic4qQr3puOBQBEwOODTcevWpCMmmlaAIyCAMCmnlfepTwB6U00wI+2aztWvJ7KGJrdYi0kmwmQZxxWmRwRWT4hH/ABLFkH/LOdG/mP60DRQe71Nnw+oBN3QRxgfrio5EkkYLLfXbk848zAqZlyckcjp7U3aBkgVlzs1UEQx6fbs21YvMbGcsx/pU406KNGYm3TC52nqfzpOSDg4yMcUkidFXlccHFawTktzKpLlegxcbRhVGfRQKSJhHqUTZA3KR/WkiPyYPY4pJPlnt39HIP4is18Ro9YnTdqeOKji+4CT15p456VoYlPX1y1rJjloyPyP/ANesRuhrotbXOm2785STB+hB/wAK55hnOKmRcdiI4xWx4Qk/4/IMn7wbH4f/AK6ylQv93Bx71f8ADDFNYmiPBZAcd+D/APXojvYJ7HQ6oMafv/55yo364/rWQYtjSEngO27HTNbmoJv025XGf3ZP5c/0rEuHXzZpeRGNrn8QKJiiZevsVXTblc5UHkdsEH/GquralJqd405yC4CIv91R/kmrOuzg2dpC4Hm8ybR/Ap6CsaNtpLE9acQZOAEXaKOM0wNuwBTG4bvVEktJSA9MnrTuDQAunuEvojkY3CtxZIGVjC6kbucdmNc7C4jmVj0B5q9aRMjXI4BTgrnkjOQR/nvTTsJq4t3cyQSbomwQ3eqEwhM5MGQjc7SPun0qe9bcu73qqvJApDSHxfLIecY5qaIg/M7BiuAwPp61ERiSoSfmODSvqX0LCRIXnKtlERip9fSrFlbeYGmlUtDCpdlB+9gdKht48qCOQ3BFbV+gTTkuEjWJXjKOqDgEjg49/wDCqJ2RnSwuttHcNEFjkBKkHOMk8etIi7JYM+wP41ozRFdNmt2G7aEUfUhf6mqEgLWczhgDAwOO+CcfzIpNXKi/eN9xtTHvWfJzJWjcHGfzrMJy1HQnqP7VmL8zyN/ecn9a0mO1CT0ArMhGIkz6c1L2KjuJIeQO9Kw3Rkd+opsud3Q0isNx3ZoS0K6mjEm/Tgh6cn8ef8KrxjJ4NWLZw0ezOB39RVeJBHkBshTjOOtUiGWY0WQkM2O/1q3pI/cSMf4pDz9Bj/GqexhDvxxk81oaaMWEPvk/+PGhlLYtgetSxrk1GOtSxdRgdTUsZatot94inBDMq/rW9MmNPb1JH8gP51laYm6+X2br9ATXQTRb4YkPG9wPzIqFuJs2Y0EcaoOigAU6iitSQooopgFFFFABRRRQBWeEHZx0Zj/Os7UbZWtpVdAy7GOD64OK2qguog8EnH8DfyrKUeoHB6rpkMOlwSxgqxYAknrnNYxgIG4HocV2OuwkaRapgZLj/wBBrnniwzDtxmlctGbJEWUY/DNNjgALZ5Jq8IwU5phj2niruIoTWyg5U4JquwkjPPNaMiZqMR/OpPqKQ7kEVvPN22r6nirsGnxJzIS7e3AqdF4qwoxiiwuZk9tGIkwihfXFWFBzzTEHAqdBxyKZLFUZqQDikRQOlPxzQIaBRjmn4pCKAImHHy9aTBBOakIpp6c0CIzSEc4p3XNI3SgYwjio+Q2McetS8YzTdvegBhHXAppBHXNSnAVupIUkAdSQKxr+8uEMY2tCrg/Kx5Pv29aANAsuetCjPA5I61S0xDOrufMdkIwq45z7mszVdQCWrOscKTO/luoly3HBJA7cY/Kmh2NmWeOM4Zhn0z0rN1mUSaPdKO20/wDjwqhHKCm5eafcOXsLhf8Apmf8f6UrhYaFaSIbQeVHQdKhmV9irGWPy5GP4j6fWp7a9EGnRM4yCBwO/wDnFVlum82NwS0bSEkEc/Sosaxd3Yesi/a1t1YjnaZO2e9TrBag/vL3g/3SD/jWeECXE0a5OzcE9x2/Q1fs40LKoA4wBV83LoiJQvqyDy/LmfbuMTMdjN/EKjueI1bGdrg/rWre7FiCMACrAk/pWZqKYtC68c4P5H/Cob1uNPSx0Vsc26EZ6d6mTqKqae4ktlIP+ev9auKcckitDMbqi7tEcj+CVf8AP61zEhUfKwJ44AOOa6y5j83SrtM9E3A+45rlZFD8ng0mNbDEDwsGVRk9BVzS5f8AicQybdrHK/yqnHuWRSD93pmpYH2XdrM5JeSbk9h/nNPQTTsdvIoeORR/EjD8wa5W9HlwpM/yxJEhcf327Cuvj5dffFcBqFy8+yz24jt2IOf4myRn8O1DXQImdeO0yrKw+Zj8zevsPYVA3Sr16GNsucYU4HrVA9KdrBcdESGBPSpHIz2qAMwHBoyTk5oESFgO9OVge9QdqVGwaAF6Ves51GVcZYgAMev0qhUiLld2fY0XHYmuvuGq0f3hU9viV/LkYDPAJqB4zHKyHIKnvQItTNGZMwnOF+YHseapqOMnpT0/1bn2phznmi5VtEW7J+SO3XFbk0xuIbSxjwWndS464UH/AD+Vc9a7zMNiMx9FGa39NtZorWa+8sLeKypEsy4ABOCf1NAPbUftkZUicfvPtGGXvhQGP64/Oql3DskuwAAJIwxXHQ7h/UZ/Gn6haJPI2fMSJDvY5yULYGD/AN8frUENnG8IExkbPfdgkds02Qu5q3t5aq7j7VFuBPAbP8qzhdW/H7z9DTRptrjAMw+jj/Cj+y7c9JZx9SD/AEpDFnnhe3dY5AWKnA561XXoB6Cpv7JTtdOPqg/xo/sqQf6u7Q+m5CP5UmrlJ2GxxPJnaORyam+yS8bguDx64ohtdQhYmOa3OeCCx5/MVpW1tfT2txO8ClLcAytG2QoJPP6UJD5ii9oyRM5kU4GcAHmoUYIPunk+tahVShR8EEcg96hWOFJVAAXcMBh2oGtdytcnEfCsi7cbSa0bUFbaEHH+rX+VVL0EWcuf4RwPrWiF2jb1A4pgSDmrES4qg0jI4wAecfStVoxHMyKSQDikwNTRkJuyfYn8NuK3ApL2qn++D/X+lZWirm6f18tj/KtxQPtNvkdBn9D/AI1KEy7RRRWggooooAKKKKACiiigApHGUYeoNLR2oAx9bhEkNoh/v/0rnorbe7HGeTXV6mu42/s5/lWTYRBjKMcgNj25H+NYSXQaZy7JtLAdmI/WmEDqat3abLudcYxK/wDM1UY84HerQyMrmoyvzDHrUgdGJVXDEcHHY0Y+cfWmI//UqIuBzUyg5GKagGKnRRgGpuUWUAxU6j16VHGMjpUyjnnmgkXp1pygtwATShSQQpAPbNTIhLDJ79hTE2V4iJEDr0PT88UpXtS2ynyVGCMM3/oRqXb3xRYE9CArgetMPSp2ACZ6DNRN7UgI8U0inkgED1OMnpmg7VyGdVIOMFsc9hQBGcAc9+KhknTzUiikhDq37xHb5tuARgVLMQF2EgNnkZ5qnb2uzUpb8MjRyRhFUdQRwTn/AD1oGVLi+2hHLRopdNvYk9/51WlvI2DN5sSMuVBYg4/zg/kayfEE/nazOGXAWU5XOenH9KpIwjhkdMD5sfpTKR1+nXCre3SnqfLIx34P/wBauZ1S0XztRuTOgZbghYu7ZOf61QgZXmVJPNePnKxk56f40q6febolNpIpkO1C67QT6ZNMlly2bMCEDHFW4XCg7lVgASQeh9qpKssFw8EsZRlPSpHbEbVD3K6DLqQzcSbUIA27Rx+VV0yI3jPDKdy/1qZ1aRAwU4x1pir+8B705tIdN9xwUyOJQTlgD+PSrVu2ydG7Z5qujIoHHvjPT2qwsFw7hFgl3N0G2s9bmjdzXvoRcW7rIwAjBOfbryfTvWHOxlsH3DkY59feta2uYxA32yYB+UYNy3cHgVkqG+xSqwPC1U3oZw31NXRDmxT/AHQf0rUX6Vj+H2LWQGenb8TWuBg+taGZZhXfHLH03IR+hrkB9xfpXYWjE3AUjrxXJyJsdk/usR+tSyokH8dMeQoqL2Eqtnv1qQj5hVe6B8p/oalPUprQ9GgO7ym9QDXCXsXlahPhh80zN9OTXaadKs+nwTIcq68H2rkdZXy9bvFGABMefwFa9TJbFC6GbeToPr1NZeOBWvKMxyZHVcZPWskdKJDQ5IweCalMC9qhWTaeKcZmyRxSASWLYOOlRjrUu4ycGmFSCDQADrT4j8pFR05DgmkMVRzRIxdhnnjGaF60j9aYAy7UYGmoSSABknpT85GG5wKdbfIXmI/1YyPqelIollna3H2eBtrf8tHHUn0+lXItQngR9jZ3AHLEnHfp0rH68knJ61diIaBRjliV/kapEu5dF5JNE8e1UWTG5QPQk4z6ZNWY23ICePaq1xbywQwXDlXjmXIIz8vsangH7lCe6g0CJR704etNFOFIA34OMfhQJiBzG3vilwCelPAAIwMUwGrMpYLtYE113hqHPhvW5OgkjZPyQ/41ywz3rrdJLQ+Br2TJHmSn8iVU/wBaaQdGzkSzGB5BjeyZ6e1Iy7ogdo3Hpz3pJJAlqNykgjHyinsFkaKQMQSMrj0Iz/hUlFVopGgAZhhnUYz15/8ArVqg5Yn1rPZw7xqisNlwo5HpWgvvQwRNDhW5VSMgnIq2jF3LHksf61SU81bg96TGdFoC5uZG9I2/pW1Gv+lL/sp/h/jWRoI5uWPZMVsxj/SmP+yf6UkJliiiirAKKKKACiiigAooooAKKKKAKl+MmHPZj/I1n6aP9IcdC0sgx+AP9K0b7GI89Mn+VULT5bv/ALeXX9P/AK1ZS3Ec5qabdRulI/5at/Osa8tZ5WBhL7QCXCAkj0xXR+IE26xcY/i2n/x0VlHK8qSPpTQ+hk2MhSJIZIJIwowj4+V/8CeatrywqQgEYxxQq5kUepoGieNNyAVaRcYqGIdAatKp3ACgCeNflqULSRrxUoXBpkixr834VYRPmGM9ajhXMoHsavxRMrrhCT1A9apEszrZEZmhSWNpEdtyhhkfMe1Mlu7aK/jsHl/0iVC8a46gZ7/gapaXpVrfaZBNcIftLs7tOrbXzubvWFrthqsWvW1xbySXTW6DZK2F2jLfKSTgnmiwLyOu8th/CTg54qlPIIwzSEKB1J4xXCnSbprmWea+igkZicmbc5JPfbn3rSheO3tzFcancXS7lZVERGCPQmlp3KszS8TrK2iSCCNnfzFJ2gkgc5OP0/Guf0qZLkI+rSySRSTNGXZ/4iqhSTVz+2J0uWkW4XaT9yQknAGOcfnVH7EE8ORzCXejX+1yRjACj/CmtUOx0troq24LSzPIeqkPhsds1LEiQDI4+pyarQXWo3cYkiV/LPCjZxj1561T1b+1bK0M9u6fLky7lQ+gGB+NK4WZl+I9Ols7mO7nlR2u3csEB2oeDjJ69azrdFkifeGKK4LgHHGDmui8SLJP4Wsrll/55SFvqmD/ADqho1nB/Z8NzLMBK90F8sg8qMcY75NWkK90dNusLIFrYRQhv4twGaqPrVgG2yX0WBzgZasLXzv8RXhEAHyx4XA+X5RVBXbz03qAMEdc0uS6uItTSRyys9vIJImdiCPr+dRMPkIqrbKIrhkVsg859at9R9azehaGxeYYgMlRzUcYJuEjcDBcKfcE4qASzlmBkbCEqADjAzUyxShg7MDjDZJznmh7jWiN22ihjkUiGMY/2alt1cKQASVYjp1xTAQGJ7c1kZMmozhmcpvJ2ljgZ5/rVbE2uST4F3cAf89X/maiiIM10MnPlH+VLNth5PTFNhGbgEgHeCPqMVjJXuaIueHWPlOoI4JH65/rW4OxrnvDrEO465b+ldAM5rcye5YtjiZT71zmoLsv7lAOkrfzreaaK2UTXDhIwQM9c/h3rn9Subee+nlgYsjtkEqR296TCJWaoZh8jfSpGkU9M1GWDVm0zS51nhKQvoCIesUjL+BwQfyNY2vgL4gu+x3Bs/VRSaXrEumQtHDbxybkRTvYjlQRnj6/pVTUb2a8upbx1RZHx8qdBxitjIjkbYA23JYgZPasqVdsjL2BNat9KixiJcrsfcc9RxWSzbjnnmhglYYOtLijFSRcHkUgGoMMKkA3DBIGKlYArwOtRMAFPHSmBDilB55pKOAcmpGPIwfrSGgMCAKD1oARenNSSApbKv8AfYn8v/11H0alYM4UZPHHNBW6I1BZgByScD3qcRuEXkjJPHvVzSm+z3jxOkcgeMgqwyGHBxnqOM1pXFgs4e4sSS7u4aI9U3Lx+G4cH39qpIhuxkZd4UQOW3BQq579MfrWoi7UVOPlUDj2FRaHbLJMs7FSkRyVPctnH5dalj+6pJ5wKQ2SClFNFOFBI4gkcHBpVD92Yj0wKTaSufenoD1zx60xj05rqXk+zfD6FwceZIzN6HBY/wDsorl1roNZbyfAthDxhoZJPxAP/wAVTW4pO0Wckl4+wAxrwB3PFSpdb3UGMAjvu6fpVOIB2YngDHSnkbWwCeBUM1STLZm828giA6Etuz1wDxV9TxWVZc6gn+zG3+H9a1l600IlTg1atjznHPaqyYq5bL8w+tIDptCX91cntj/GteHmRzWToJ/c3fsQP51rW/V/wpITJqKKKsAooooAKKKKACiiigAooooAq3wyqexJ/IVmxnbf7R2vP5g1p3vRB7N/6CaynONXcdvtEZ/z+dZy3EUvEyY1QMP4owf1xWG2cc10Xipf9Lt2HdCP1rAbrQNEB+lIgzKvbmnH+tEY/ermgZbhHzge3FWwvzCq8HLrVwKd4wrNxk7RkgevFCEydEIGD1qQjnIH1qnY6nY3zBLGf7TMRxEoIY/n0pbXWLW8kmgtIriW4tyfNhCjcADgkc4PPbrV8rsTc0IYyd7BirAgAj3z2/CpwJPtMPmTSsfMU4ZuBz6VlR6pY3ErRW92onU4aJ/kcEdeDWjakC4hVl+fcpz3oQjJlbU4bLy7OyW4hwylUlCsBuPbH8jXOz36rEyx2MMdwpwVnjLkH/gRIH5V1sF/ZJdpaS3KrKXlTYcjkFjjPTuKl1M7/D17IiI7MAqsMHPIHXv1p3G7I//Vy7r7SCYpnnh80geWIvLDH8AB+Gar2mg3Op3r2lqXWdY/NHn8LtzjqMnvXdaq/wBo1bT7eNlibzXcNt3fdU9vxqXRoWPiK/llkWR4YIowypt4bLdPwFGt9Qi1Y8/t/C+oTpcncim1laF9oyuVAJ5JBxz6Va+xH/hXsMhYAyXbTdegCHI/8dP5iuna1gbSdZuJI9xNxcyKdx4wPb6VmXNvDH8NrUCNQCGc8dWMTHP16flV30CO5g2OrWvlwwyW0h2IFyWLdB6Vd1GS2utPmijjaLapkDKuM7RnB9RXN2UE5K+XsJzjDZ7/AErblD2+n3LTzwsfJKeWqFSSeOpP1rF3voaJLqQaPrUmmvIt0j3UQVBEpcYQAHpn6itu9MmsfZbseTEbSYMiBi2TuA5OBjp2rixID8z8AFeD6Cuk026gTTpU85Q2Q2O5GQc/lmruZPuWxo1tqF5d3l3NMJGkC7YiFXAUeozWbr+l2ti9s1qZBuDZDPuzjH+NdBHPCImLbV2nLHHX39+1ZPicBktZUXAXcjfjgj+tVfQS3OYWPbOSDkZ/SrY6VXOQ/HXP51YrNmhnf8tJR/tn+dXxzAM/3R/KqL/8fEv+8avQn9wnB+7UlF+PfI43SEjPI9azbViZAzMWZs5JOSavwyYYfWqFrbyRqkhxt579Kb2JiSXShyqnuKjQFXBUkFRgGp3iEjZJPyjio2VczRqxyBx6+uKnVIuNmybRRsvplHZgQPqD/hXQ5xXO2pYXkgZhvCIGx681uW7swG7mtIu6In8TKmuci39t/wDSsUpXQaypa3hPcOR+Y/8ArVjOhUjdxkZFBJDsFKE5qTA7UUANCCmz4S3YkdMfzqYVc0qSOLVbWSUZRXJIxn+E0AVdB8Pz6w63F1uhsVb8ZPYf1NVfElpFZa7cW8CBIlClVA6AqK76yuvtEk2BtQYKL6ZzXG+NV2+IS2Sd8KE/kRVMFrc5/HNKvB5pOlGcUgLBbB61C7DmkLZ5qMkdqBB9aWijtQMGx1pAcdeRWjpLRi8USojhwV+YZHQ08WME7yuWMagSSfL0ADYHHp1oBmZkEg1Kzr8pGPu4NMSKRwNik5zj3wM1HSsNMux3AWZJQAWQ/mO4q82ohPntTLHMBgEgDGfxrFBI707cfWnqh+69zTs7iG0kDIX2lAjDHXjr+Y/I1Mt5AAMmT/visgFyalVXPUgUtQtA0zewgZAdvbGKYdQyfkiwOxY5qltwOpq3YWS3Um2SYxjpwuSaNSkoEpumwGDn1OBV6KSWSLLjAU8buvPNTXmijTypR3lIO1g4AwcZHH0zVSWaaIAiESDv82MU1dbkylHoWexxW54kcroFnET8i6eHH1bg/wAhXLRakkjeW8TRMR0Y5rc8SzySaJAzKu1rKONGQ5DbXwefXkZFWkQ/hZz0I++AM9M0yZz5xU8HFO8sLa20oLhpg5PYcHHFIyI0SEbvMBO4k5yO1Q9NGa2s7ljTMm8JJ6RH+YrXGeoGTmsnSx/pUpPaMfzH+Fa6cChEy3JYskcir9ry69+aoJ1q/affUUMk6Lw6cw3nBHzD+RrZg6vWR4fwLe8bv5h/lWtb/wAX4VKAmoooqxhRRTJZViUMwcjOPlUnH5UAPpqMGXjtxSo6yIHRgysMgjvVTTpBIJCAQBgDPU+/5miwupcooooGFFFFAFS9++o9jWZNxrsi/wDTSM/yrRumAn55GP58Vn3H/Idl9AEP/oNZyEReKVP+ivjjDD/P5Vzr/Wuo8TANp8DdxNx9MGuVkyOlAIjPBOPSiL/Wr/ntQe9JCf3y8+v8qCjQtsmVcYzWxpx23U5PUWzn9RWRaczpWrAQgvGPazkJ/SqiSzlvhnhdXncj/lmyk+gyDVj4bQpcXWrXcw3MSsZz0wSzH+Qqp4FdorfVrlc5itJGB9DhSP5VoeF2Nj8PL+6b5GlaUow9doQfrmt5bMzOZGly61LNdRMqTTySzYc/KEz19ck5H4Vv+GLe5g8Rppl7dl/shVz+8LDIAwoP1bp7VJoMMcQEkxKx2yhmIH8MYyx+hc1V8Ih7rVJtVnwGnu0VcD+IvuP6ZFYxbbfY2asvMW/tYZtZ1CS7CNCkjkBm2/O0hHX6KPzrc8PRpb+HHjBDQyahtQZz8u5R1/A1T8SIn/CM6y5HLamQP/HR/jVjw5JAng3TFLjcJHcjuP8AWYP6VUmuWxk07t3LUQE2uwyE8wwyOPYtha09EiI1TVZ/4XeJB9VQZ/nXPRahBbanJPMXZHt1VTGN2cuTn8cCr2ha3bLZXsjyENPdTNFkdQFB/lUt6scIu17EdvIZPA9zK3V4blvzZ6p37JH4AsjICUBj3e2Yuv61Tm1gWvhBrH7OxZrYnzN3ADnI4/Go9Vu5JPA8sLouyGaONSPQKRz+Cj86pKxaRzMUr2lwQEVcdBkkf/qqWSb7WoSRWxvBIUH0PrTLWA3VqY1OZIwTGc9QP4aiiWSZmgDbFI+b3H+TWPL71zZtqFiO6txhvKHyqMtucUhQRyRHo23BxSS2ywpICeQm7J/3sU66CrFDngGEEj6lq0Mehds5oEWUSTogyOGkA9auavPA1koRlOXBB3ZJGD/n8ax4LV7jaq2dwBnmQKcAfTFTyRw2ml3Mcp/eyP8AuA684VhyOO/NTfUlQ1uQKP3mO9Tdqj1a2l07UzBKu2SPAYZzweRT/Y0NWLRQkB+0S/WpreJ5QxEjAJ0HJBqGT/j5l+o/lVyyVzaXLI+11VnBxn7oBpdSugsktxAoc+UwJ9DVmydfIDKRtGc5PFZT+ZOgZ5JHHbJAFVzbsfvMKqxN0ab3YinuVR48O+MscgAelVhdxCRpCxJPoOlVPIx3oMYA5NFrgpW1Rbtr+OG5klMTsrgALkD8zWgviUooEdimR3aUn+QrE2D0oCgU7WE3d3OhtdYm1OZ4ZooURF3gIDycgd/rUN0c3MnGMHaB9OKq6CB/aDZ6GM5/NalZt7lj1Ykn8aGJEkEEk6TSIBsgXdIx7eg+tJge9dPAiDwOwjULugMj4/ibdyT+VcwTzTsCEyPenRy+XKrgZKnPJpppppCNK21u5glHlwQASFUOSTwTj+tVPF+H1SBwScxAZ+h/+vVfPKn0IP5HNSeJZC9zAc9FIyPrTBLUxD1NJxml9aTrSGHXimkYFOpD0oAT3o6UdKKAJoJPLkVx1Rgf1q/E5Wwncc4hCf8AfRP+NZiVpwJFJCodMjGCMnnFFwa0IbdgiA71G2Mnr3Lf4CqbhRK2DkZyDWuLSz724/77b/GlFpZf8+w/77b/ABoFoY42inB1HRc1sCzse9t/4+3+NH2KxI/49z/38agZkeaf7oq1b2z3MfmCVU+bbjaT/nrV77DYY/1Df9/DSiytBwqzKPQSGgNBkdlAf3TS7ZAMl3bA/KltJktjvjDdiM88jn+dTNb20igOrnAwMHFH2S2xjMv/AH0P8KBGjPrjahc7rlIovNdSSowFONuevStBbRIrVp5prRowQMF+Dz39654WdsFIDS8+pB/pVlfLUAbIioPQxrz+lO/cTS6HTWXhGDVYPMuEjiXhlAOTgjI47VZvvBDPpTWNteybAd8YcBgp649cEgVl2HiSaxszbx2sIPy4kRyh4GOeDmrlt40u4nxNbrNF6F8MPxx/MVQ7HGa7aXGl6gmmTSq7WkSj5Pu5b5jjPtiq8OXt5JiQBGyqR65rZ1pxqmr3Oo+Uq+eVPlsQduEC9e/SseWGSLI+6rMDgdOOlJ2buy4PuW9Mz50zdOF7fWtRSaz9PSNU3xuTvUbwTyrDOfoDmr680kKW48zLEN8jBVHc1f06eOYRmMucoCSUIGcc81Q8tZVKOAQeCKv2KrEkca8KgwuTnjJP9aGTc6fw8w+z36nGVcn9DWraHO/8P61haEwF1eRbuZFbj34/xrbsGDK/4VCGW6KK5fxP4iS3SSxspcXAfZIdvRcZOD09vXrVpXA6Z5EjAMjqgJwCxxk1Cb6zBIN5bgjr+9X/ABryuS7klYmWV3PqTmojJxVqC7ibPVJ9X02LAlv7cZ54kB/lVXS7+yZ9iXtu5bhQHGT/AJ5rzLeM+tSRuAQeM0+VIXmewYory2DUZ4R+6nlXvkOauw6/fQtlLuTHozbh+oqXG3Uo9ForgH8V6mo4nB/4Av8AhVY+MNZjfd58TgfwtEMH8sGlyhc7i7bF0Se2Kzrhsa0GOcOqH+X+Fcuvja7aTN5ZQSKeCYyVb+Zrce7hvJrW7t2JikjXB7g8jB9xWUk03cZpa+P+JQcn/Vyqf1I/rXKScduldPq0ivodzjqpU8/74rlZGyaFsJDCeTk0Rn96v4/yqN2GOtNhYeapyOMk5PtTGa1nkzx7cZz3q7fvPFp97LbsFAt5FYlc8bScfXiqGnuHuYypUjPY5FbF2N+h3MAJDXDmIcE9UP8AIZNOJMjzzRrmeHRNWaGUoojRGUD7wYMuP1H5VLp91dR6SLZJ5PIZi5i6rw2R+oX/ACa6vTfDekWuky2l3cXkpmYM5jt3XGMcdDnpUkdr4T02WJS135ikMiyRyAnn3Ud66JK60JjvqZOrsNO8MXEakrLOy2q9jhfmdvxJIrSsLf8Asuw0GzYHfLNHI46FXZgRn8Nwqlq+q+Hrm6iSayv51hztAYKMk5Jx65q9bapp11f2WyzmaTzU2NNeDK88ccnv0rOMOVK5bnd3MrxXqGLHUNP2YB1IyF89vm7f8Bq/pFtFBoFi5T941sATn+EknH/j1UfEMsE9zdqunWrhZ3LmSSUlmDEZwMAfn3rLn1nWobZVjiiS2gUKu0NtA4GOufTrWdSLmkoitZNFvUWVZmjRQqoFQD2ABH861tPXZ4MaQIP9VO2cd8sOv4Vyslzq0iiWSMIZFD5aMLuHYgnrTAdaZhbiWUEnAhB69/ugfjWbpSasjaFSKpqJo6mGbw6nBJNvF/7JWlEscvh68SbAT7bHjPTkEfyOa5rytVMjKZJt8Yy6NnKj3BFdL4QtvtWm30V+TOhkjZRuODhWbt9K63K79DGHupruZNjG0akBY1cKcNzjPHQiq5RBeXMkhZSyuFZF4Lbsj8DXZNYWNudiaUj4Gflj3Y+uTTNkIRzFpaRsoJAaFRuPoKxK5jg7633A+S25cnBYhc8555/ziopUd3gO6EeVGqcyAZwSa2/GEYaa0YxLHuhyUAxhs8iufjsGfbh0BbsTjFFwR//W5OO8nRoj9riHls5++P4hiqkzI8MayXUbmJNowSe+fSnnRrkRvIVjKoCTiQEn6DFU54fKDLIjI4HIbgihWKuzo/GQE3iq6YKdpSPGP9wVjrINoJYdK6LW1WTxBKSCSYo8L68d6q2lmtvavcNEhDybF4ztxnOPxzz7U5Ru7ibtoc/MkvnSSCNiOO3tVrTN8j/ZkQ+ZIsgwR221evb+3DCOGLpwTvzmn6HbofENs0ZzkONuP9hqUd7juY8PNun0prilhP8Ao0f0pGpvcgjPrTSacetMPWkMTGTTT9aX1FJTA0/D0Sz6ukLMVDo4yOvSr0NvbHBlLAYyTuxWf4dI/t22zzw//oJrWgj3YbnpinYRuWg/4oyQcHbBKPyY1yp4rq7IbvCs6j/nnMP1NcoOgpsURDTTnrTiM0hHNSUN65zUGryea0bHr3qwB2qnfnMaZ9aART7nNJ0NL1JpKQBSN0paAM8UCFnUJPIgzhWIH50yrGoMDeyFPu8D8hiqxpvRgndDlODWhZPlWX0NZ46VasnxMP8Aa4qRmmKdTBTxTJHD3pe1IKXPNAC96WkHNHSgBaUUlLTAWlFIKBQFx3vTgaZTgaAHDrUM28xMI1DN2BNSg0xT8/40wCzR03+ZH5ecdwc9fSrqcd6gBqRTQUWYzirts2DzWehyOOauwEZ56UmSbmmS+XrkW8nDZX/xwY/ka3NHffCD6oD+YFcrLK1vd2Fw5+Vjn8jz/wChV0HhyTzIsekMf8v/AK1R1KNuvINVuFl1W8lQ/LJcSMPpuNeuySJFG0kjBUQFmJ7AV4g0m4Z9STz9a1iJvUm3/pRvqDdigvVBcm3+hpRJzVfdRu70XAtCX3p3nH1qnvpd/HWkBYeUnvUTPUZemFqAHlq6DwxcZtri3OMxOJR9CMH9QPzrmi2a0fD8zR6sq8bZI3Vvy3fzUVE9UCPQLxgdIvFzwy7g34g4rmnPetiebOhyHPUAf+PCsN2rOOwyCViOtZOqTNsSI8Rvkt74xxWpLyOtQCKOb93Ku5GPIzj9apDG+FLgx6lHF/yyY/d9CeM10Pi6We0023ntriaKR7jnaeAQrDI/Cs3SrSCC/i8tSqqSSS2STjHJ/Gr/AI2IOh6cc/emk/TdVrVmdR2I4LrUpvB15qUl1OZoioWVJtoXO04wOv3qd4ljurTTbS7UXy3LMsZkmZXXBGSB1IyRmptLiL/Da8iUFi0iAD/v3XdT2dtcIiXEKSqjBgGGeR3p6ILXOQ1PTUhl0S1EMa+beBpAq4+6FDD6E5NLrNuD8RtISKMbfJ3so4HBfmuve2gklileJWeIkoSPuk9TULWFo2opqDQk3SLsV9x4HpjOO9F0U1oedrZRXGu+IXlRpI45x8oYjkseePxramsrSP4eyTpAqyMjFXx83zSYHPfgit9dD05XujHHIhu2DykP94g5HX61LcadDPpSaaWkW3VUXIxuIXBGfypoTldWMbxFp1slnpFj5Yw13BA2O6Ac/wAhVu4sbSXxdYmKBFeGCWWT5cBgcIOPXrV27gguLu1uLnObeQtEu7AZyMDPqeOKwW1qDS/FFw+rSltsQhWUJjaCQ/IHXr19qLkW7GZf23neLPEksSrsisCn0Yov+BrUhgubfSbezkSJHAt/mHBHytnJH+6a55r+KRfETJOPPv5o/sw7uu8/0IrqL68i/toWYP7xTE3HYYlNDGtzG01rtraOC3unZxHvK+QCRzk8nryaddjVwkb288xXJWTMaLgjHAB68Zp0rj7FAZC3lFScAnp5TE4/Oi1mifwzAVV/llkK4BKjqOT+NQldFRdjmNYnjvZxHcXMzTopVRJHjaepPAxin2MUIjUxThyANxcbcn8aZqTiXVoxhlAjlxuGM/usZ+nFSy20LaC0hDFgsZ5Y46r2pOOhpzJ7l0MYsBZokJ5x8uaxdbjSaNpkczSBtjsq8Zx0J9elWLm3gEyL5QxtyeT61AFCaZchQAFvXXA7ADj+lJxcdSqSjOVjb1i0/tLU5rmwlgMcdtECTk5zkcY9MVzs81xaXj6eXLBWwcMdoyM5Arc8NShdNvHbGFjjHXH8Tisjy0ufFqJKvmRvNgg9xtrRu7Iluyq93eK4ij8pckcBfX6mtfw4058UafDI+8tvYAKAPuMPrVPU47aK6AtoFiImZSAc5A4/nUlhetpupxajEA01ujbFboc5B/Q1N9dBIyIf9QAeoyP1oakibMWTjJJJ/OkY0PcBjetMNPNMNADals4lmu44pM7WznH0NRGlR2jkWSM4ZTkUWAv6EpTX7dHHKl1P12mrnkyNqME4YBIxgjd9eMVRs5ne6M6RRo65YspIOSCO+ary2boGkIjCKM4DZ/CmI7nSZN+g3UXAIEw61zyp8o47VgC5dWDphHXkFe1S/wBo3n/PxJ+dF7gkbJQ+mabsJOMGsY390es8v/fZppu5jnMj/wDfZpDNhgVyMVQvjmJT71V+1TdN7Y7gnrRNcvKoQqqgc8CkwQg6mg9KiyaMn1oAloBxUWTigk0AWJVJgSQjkk8+tQ1pXoSRD5bBlA42nI4rMFAkxakjYo6sOxzUfenKeaGM2kORmnjGarWjboR6jirAoEx4pRTRTu1Ahc+lKKQUtMBaWkooAWlpKUUALS/Skx0pR1oAUdKjB+c/U1J9aiGBIc+ppgTA09Cc81EDjpT1P4UhlhDirkDfMOaz0PPNWYpApGaBM0tXLDTbKUD5UaRD9Tg4/Q1s+E5y0iKe9ulY+qMG8KxFfmIvPmI7ZQj/AAo8K3QW/gBPGxQfyP8An8KTC5teNdYNpZSadGjLLcR8uTwFPp65wRXmLHjHpXc+NbC3A/tRCymU+WyYGAQpIx+VcCzcGtE9BJ3ZJupC1R7vSjdSKH7qXNR5ozQBJuozUYalzTAcWpN3FNJ4pCeKQC59KltZpILlJoiBImSuRkdD1qAmnRH94o96QHbC8FxoMUqgqJWAx6EE5H5is6R8DJq/4R0iXVdIl2vGEiuTgMx67V7AdPxqbVdAezlaWfWbCNAQfLYFcY9AMmhQFfqc9LcjoEc/QUkV0POVSCMnj/CqV5MYbkw20yTgDqsbD9GANJaXEsUwluLeRxHyg2kZbtn2qWika8crswbOAcgfL1Gan8RXkc3hjSYldXeN33gdid3b86oPerdASukkTFQMbS2SD2pdaK/2DpjbdpZpMkjBIBOM/n+tOBlW0t6nWeDtQthoMUHmAtJeqiqRySNn+FdirSDPmZHPGFyMfhXnfgO3eUWLNExjFzI5fbwDtOOfqBx9K9Gcv8oQqCT1Iz2pyVtTRPcEfIJLDA/2Sv8AOhnA29SCcZFMZn2ndHuI7xnP6GhZYtoQvtYjOG+U/lSE2OJ4zTD65wOtK7DZkEfjTEkBk+6wX1681SEyB5oicsrHa2R8m7BHevOvGTqfEdwvJUxxH/x0V3kU0jysPLjCZYll6+2a898Zsf8AhKb0dlWNT/3wKJbF0VeRQtpo47+zc/LieMnPQAMCf5Vsvqkb+I572OSNyXX7pyOIiOvpk1yszn5d1OtGVvNBAAOePzqE9CqkbSOta5EtjZQ5fmI52DJz5ZXikhunTSUgLSZLuOWIyMHGQOPTrWIZZBbW6W4UMmRg84GDUsEjNbbZkUPvY5UYwNoH+NNS0JUdR1tcMfEltKrDKROQc5H+rqXUJd2nXbZHMg57f6wdqyNIkabWEZ8Dcrk4H+yf8amu5f3V0hJ+aQDkdfn6/pVCsWLmQGZSDjaOv41ECP7Ju9pzm9bH5Cq0ku5lJ9OaejA6XOD1N0T/AOOilUfumuGVpo0/D5H9lagCM8RjH/AmIrPhfPie2ZRnFwB/P/69WNGumg0+7CpneBk5xwN9Z1rOkOsQXE7BEWbcxwTjrST1FKLs2XtWOycuAATNIvA6DNVJs4ZgSMJxge9P1K4t7i4HkS+Zh3ckIVGCR2P0pYbZr2SSGFS03k5UZwOuOfzFLqT0MyI/uhQa3IvDEwTE19Ep/wCmcZb+eKm/4Ry0A+e6uWP+yFWqsTc//9fz0nuKaQa6dNC04H5vtDj/AGpP8BTpNIsI+VtFYf7Tsf61VhXOUpO9dWunWxPFlB/3zxTjp1ptw9lbj6LRYLmDpmwQ3O/Gfkx/49TpwotJyOygcfWr17aW1sI/s8Ij3k5wxOcY9T71QuRi2k9x/WnsIyqAMijrRnipKAijvRk0meKQC4pO9FFABSUUtACUUUUAaUHMH41QYbHZfQ1etTmHp0Peq92u2UN/eoF1IaUU2lBoGX7F+Sv41eFZNu+yVT781qqeOKBMfninduaaOlL3oEOB4paaKWgB1L1ptLTAWl6UlLQAx8ZPyuTgdPrRhSD+7fuOTQ55P7xl+XoB79aQlNzfvH4Ldvb+nagCYdBkEHFQlgHJwTz0AyalH3RjJ4qTT44ZdUijuDiNi2Tu2/wkjn64poCJZOf9VN9NhpwkH/POX/v2at6kkNqd0EkBUDOz7Rlm9xxVAX47Qt/30KWw73LAlXP3JfxjNL5i4x+8GP8AYNVxqI/54N/33R/aSmVYzARvIGd/TP4UCIzI/mv+8k2E8ruOCfXFaGi3Pl30ZPZTn/vk1m3BKzkjOCAfrVjT4LppRNDAzqo/hI+nShodzrPFv7vw9aQDJkLh3/I//X/KvO2biuqvNTt9X01I7dLgXiShnEhBXbtI4/E+lcjuyuR0NVsiIprceGozzTAeKXtSLH54ozTMmjOTQA/OaM5puaTNMB+RRmmZoJ6UXEOJpUOHU+hzTM4FGaQGla3N7FFJFaXE0cbnLqrYUn3FKkc4kEu7Dg5DEZwfxqtFKyE7GxmrGJW5d/8Ax6mpMZq6hDHJZ2xXUxI8ihmCx58o9xz/ACqrDaQdHurhz3xhR/WgyRNGpJ27FwSO/NKZEh581BkfWk9RojWHV7OaA2eoSqJplijKSkct/wACPFaeqWuuWdhF/al/5kk8pCiVi/Az1BBHXBqnLfSwR2ctxAj28MyyRlk2ByueM45GM07WNc/thLfZZrawxMfLw2QSTzjin0JirvU6vwTqOoeemlTC3aCOJnDRrtIAI7DA6sK7FhmVAecZP+fzrhPBEobX5yccWrf+hLXcecpnEefm2FvwyBSTukzTERjTm4rYeu7AHoeaRzG6lWCsAMkEZpjuBuC/eIz9BTeiOx6bcj8qdjG409OaZ5qRtGrMA0jfKMHnGPT605iSM9s4qKcQt5KSsyyMH8tgPukDJP6D8qokrxQGKU/uGG7K7w+QAef6V5t4nlaTxJqeAT+/K5+mB/SvU4Nu9I3n82QjdkDGR64rynWJd2t6g4I2NcSHP/AjUz2NaLtK5kzBWI8zepHTAzmmxNHCGZSzeu4YxUssjEomxGB7+n0qDaMSDJxxWa2NZNt3LMV4m/DdD/hUwvYQFxIuD6g/4VlmMF1VGyWIGfSlnhaLaCQ2eBg0WEyzZOlrciUyocKVGG65pJJ1ZWAYctnOffpVcQN55ic4IHUGpFtsoeec9aGyou2xL56CRWGCB2NKJ4/IKFvmLlv5VAtq7Rll5wTQluXj3Drmk7W1LVRou2syxWbRtjcxBHI9/wDGqZU+ZliCM54NPNuXCcgY46UbeSKate5Dm2rCAN5+8AKvsa6DR7af7aLzAW2MJjy3BbJyMe3A5rCjheU4iVnYdlQt/Kuxtp/tNuspiaM9GRhgqR2q0ru5lJjUu4rgP9nbcI22scY59vajqME5YDIpSRGfLwAjcgAYGagO4SYXO7NaWIY4sMHsKcgbZ82CpHFKIwGyccinK3J75pgRZPIUYA71WkJJ+XmrkybVyPung/WqjgRg5HFJhcz9SQiONifuk/0rNuv+PWTnHA/nV/Uix8pmzg7sfpWfdf8AHo/4fzFQxmWOtJSr3+lIagoO9JRRQAUUe9FACUUUUAFFFFAGx5qzDepP49qrXi7os4+7zTrTcYyWUjnjI61K4ypHrQSzLoFBBViD2OKPrQUPU1q277ogT6Vkg4q9YvyyfiKQMvinCoxTx1pkjh1pe9NFKDTAdS00GlzQA7NFJRQAj5wdrKvynBPb3pSx3/61cbumO2On9aRgxyVjVuD19ewo+bf91cE8ep4oAehyiktu4HOOtV5+GcgmrCklRkjJ9OlQlFkuBG7FUdgCRxgHFNAVV244xk07I2genWrOoWUVoUkt5vNjYhTuOWDck9sYwKp96TGLnA6Hiolc+crHg7h+FSk9BmoLjAZfU+lJAXXO925xxxTNOv7i0lHlsSM9M9D6ikc4kJ6cVFCQJ2J6Z4piNvUfEEM9iqOrpeq43bI8Blz69jXNdMgdBV25KzalDiJVBAyvY4JqnKMTyKOAHYY/GmCQgPFLmmqeKOpoGOpc00UA0AOopM8deKM0AOz70hzmk6UH86ACjNJRmgC/ZQJNud2dSmMbSB6+3tUk0EaRkqXJ92NVLe4aJdoIAPWnyXEzH5QCtIB1tLDHOnnLlQ2Wz0IwasadNbJHAshjDicliwHTaf8A61UMknlQD707y4h82/n0xxTCxp+Ir46jd21rbkOsCLDHjozngn+Q/A07WxDDPb2UQ+W0iSMnsz4yW/Wsq0RJJWaRwu0DYucZP/1sfrRI5ZskEEvnB4obCL96x1XhG68nWJ3JP+o2fmwP9K7eKXfqZkQEsLcJ7csT/SvMNKuFgvSzMAcD8smuxe0tL9BNLGHk2bUk3NtHpwDzyaIOyLxK5ptnWKjliSpOV25oudyW7thgoULj2yK4SLSdUFyHjsrcxgYwJjtb8zmuistOgVY5Z7JYJ0bPyzFwf1rRWZztNG0hAjUZJ6H9c015CCQFJ6nHqc9M1Er4FNm84hjHIFyONy5FFhE8DZkRigVu/HT2zXjknltI0mAS7E/rXrXnNCLiaVQIo4y6kdeFJOfyFeQgjEXuMmonsbUFqRSEC4UL60Kcs3uaiZs3PHrUifeP1rM1e4kgzdxAD0pbgZurdVPv+v8A9akYgXaZIAAzk/Snn5tQjAIOEPv6/wCNCEwjQPc3DHouAD/n6U4fKppICDbyuP45CRSsMpgdTxUvcuGw8Dy7UNnBC5/E/wD66nsdPe7TbFw8abic+/A/M1BcEFAg/iYD8K6bwksvmzmODzVDJlc9wCF+gy2c9ttXFXZLdkYy6dNGh8wxsytjYrfe+hqGe2e2kKXFtNBz1cZH5iu3utMjsgFwrzlgGBGeg/z+dZ2uW/8AxKJGlceYw3LGDyNp6n8SBitOVGXMznJNdaEeTawIdoADbjt/LrT7HVmj1JBcTM8MwCszfwHsfpknP/1qxZzsuGNWrv7TdJGqxNIkSBRsTOB74pLQbR180ZIK9CKCBncRz61maBf/AG2z+zyMTcW4wc9WToD9R0NX9uGZtzHcehPA+lWSK7hFZ2+6oyarW9y0kpR1Ucbgy56ehzUlxH58RUOVzzn/ABqtDFJGN5Qb+mN39aLi6Gkjq2UPp0NVblUjiaSdgkacsx6ClEscY82Zwirklj/nmuc1bVTfT/KpWGM/u4z3P94+/wDKm2CQt1fm6nGI9kSghM9T7n/Cq10R9kb3x/OqwkYyZbr6VJcNm2Iz3FZXK6lId6SnDvSVIz//0PM6Sl7cUhxQAGiigHHNAAVZRkgjNJTgTyD3ptABRRRQBssct1pp60ucmg0EmfdJtlz2YVCKu3aZiyO3NUu3FA0KDU0DbJVbPSoM09Tg0DNlTkU+q1o++IZ6jirA9qBDs5/CnU3OO9LQIXP6UvekzmlFAC0opuaX1oGNdQxG5S3UcfShVwQRF0K9T7f0oYjcuS3JxxTQVxwJTwO/of8AP4UCJYxhANu3Hb0qJ1L3AQAZYgDPvxUicLjBABPBPvUU7FZAwOCBkY7VSALuYvGsDbg0b5II9j3/ABqruGOeKva3E0p+1ITuTCSA9xnAP4E4rGBznJ6US3BalkSJnGfyqu7bmLHj0p8KhlYnpTDjJz2oSQXLUx5U+tRIpaVn5Kj9KfL/AKqM57D+VPsm5lQ9Dgn8/wD69IZHbkm+QkkkBv5GoJ+bmX/fJ/Wp7bIvXU/wqRUN0MXb++D+goERryKAaap60o69aYx2eaKTPGKMnFIBc0fWk60Z44pgOzSZ9aQnmjNIBe/NGaTNJmmBInzbV7k4p5R1cJ1JHaogSvI6jpTopCJcthuO9JgSiF8ckfialjti/wBwlvXaCai+0yAfKI09wg/mamSK5uFBe74HbcTj8B0oAU27oORtP+0QP50gjjLHzXfHUFADk/jVWSPypGG4Eg4LDvUkUoCBXJ3Z70XGbWmXKiZleFDuXJymR2GP8+lbNtb2iuZbaSa2Y9fJfK/ka5iC4aFgwwy+1bdhf2k7BQ6iT+63Dfl/hSWmg23e6OgtJr2JQglgulHQyExuf5itFL4KcT208P8AtFdy/wDfQyKxIZGDADhs45q9FPLHggZPqjYP+fxq15GbfdGml7a+WZGuY0QdSzYFNhW4eVrq2vVntZeVXkgDPbtxgiuf1m+zBPG0G+dUVw0sasBlgBz3zzWA9/eRR7YbiW3GdwETFQD9KOa24clztL9podL1eWYttMEmzLccgjp26ivMyxUKem0YrXn17Vp7OW0nuVmilXaxZBux9RWFI+yTYT07VMtdjWl7t7kbEic469qcrspdupyKarEyA4xQAcP9RUlbiTMXYMQKdBL5EpYKDxio26j2pMZbA7nFNbBLcuwsBCqbvujkenel8xRskHK5zmnlcMAAKif7wA6elZJ3ZaRMrie4iCDPU4/z+ddtbWbaNpO6QyR3Mg8s4Bw+7nA98k/lXHaXdxWMpmKu0u5duFyAAc/qf5VsSeJp7p4lmnuZFSVZERgMqw6YOff0raDSZlUT6HYXd5ItvH59uY5IUbqMZXrgew24rmdWuRNEttHMqyszDIPCoD1I756Ypl1q95qEks8sjjaCNjLtCDr17nFYtpBLezu7S/Zo5OuFJYrjAAAH61bRmkWf7IbyC63UkhkyRhAB0wM9f0qx4flfR9TS5ul82NeG2L84HPTPHp70ya1tUtkSDXZ4yBgBpePpjilQ28dsoTVzPKB8ySsGVj7HqKLDUrMjvb37RqZ1G0gmdjIzjPpnpx2xxitUz2kpDQTqVfJCHO4Y6giq0eu6ebOOG9t5WMYADQja6Dp6/N2qeWILF9ptp1urZl3iReqrz1H4Hn27URVipzUraWKZvIkco/mY/wB3oPWnC5TcFf5cHB705Z40lEgVSw6N3x9ajvkVnFxDyjD5j7+v9Pw96oge7FbjdGImdSNrPyF9xWJrdt5WpSOgG2TEi/U9R+YP51djmkRwrHI+gqPVsz2W9c7oTnH+yeD/AENS9UBiOMPnNJN/qcZ70KrytlF49e1NkPyD61BRCPunFIevWndqaeaQxOTSd6U9KcAGQkfeXqPUUCGfSiiigAHWkpRSdqACiiigDTWVTN5YOTipT0rPtT/pC+5rQNIljGGQQazWUozKeoOK1DVG7XDhgOvBpgiClFNpRxQUXbOTa4U9GrQFYyNtYEHpWtG4ZQw7igGS0oNNB6UooJHfWlzxSZozQAvelpM8UtMBGPA+YDkZz3pjMNp3Sv8AdYkgc8HrTmztJ4GPXpSFiAf3oXr0HTj+lAEi4BbBY/Mevb6e1QXXUe4NSqcsRuJ6Hp0qO5HC9utCA0HWKaGRLgHy3Izg4PYjn8qwLqAQ3DLGWMTcoW649D7ittrwx2wkhKSFYVJSRcjcOTj8P1FVjqthekRXdiQxHDxv9046ine4WaZlByq7R603bld2e+K0NJ0eS6jW6utywH7qA4aT/AVoz6XpcaZMU4z2SQmgNEY8nNnGfpzUcDYm56YIrXGladLkRyX+QOhI/qKm0vwxJeTzM8zQ29upaSQ4JHGcdOvSizYXMWE/6fMc5qG9H+kZ9VB/p/StBNOlhn5lVnbkrjkVSvwA0Z7kEce3/wCugCt3Io4zSA80uaQxaKTrRmmAo+tHfFJmj+VACg8UUmaKQC0cUmaKAHoN7bQcZoSMrLtchPc9KRCBIp96lnkTC/OOtAxWECH5pXb/AHFx+p/wpXuUchVieRug8yQt+gxVZmU9xVoX7oipAqxgDrnJ/TFFhERkZlwAF7YUYphbnB5pWkaRi7tlick+tMbrSGTwzCNvn5Ht2qyn9nTDEhCE/wC0VrOUEninEjO3jNJxuB0Nms8YBsNRkK9NrESL/PitBNavrQkXdosq5zviOP0Ncc6rwehqZJ7iFcxXMqgfw7sj8qVpIDpdW1y2v7fyLaKVZ5AEZ5BtwoO7HX1H86wlhnGVBHy9fn6U2CaWWVWlYMVyQdoHbmrBdAchsA5zmm/Ma0IlWYn5efxFNaPO55E6DJJFToUVgd6nt1qvcuJoGjXIJfd+hpFEl5ol/ZxxzTxoscvKFZAc8Z6VU8qZQQGBI9+ldBq91PexwTlVESQYRFbO3jJz78AfhWRNKqorBBzVy0ZK2KYmcdQp+opRMh+9bofoSKSRRuYgcdaFAEYJHJqS2iU3EZIJjkUjgYfP9KPNjLbvMdf+Ag1E3pSqoc4I/SlZDs0So8YJxJnPPIxVuC2nmiM0MbGNRnzOgyPQ+ucVUhs5LqUxQgH8cfQfWu7tZXbT4Yx5LARhWjdcYwMEY/OtFG5E5WOdur67t7R7e4tlimljOX3jhc4zgZxnpWa5vklV5JLqB2HyElkz7D8/1q5qU0P22cRIY5EJiwRkDbkY57EfrUa6xeGIw3AS5iIxiRRmmyUih5JYOzK5Zep6/nUYC5G4DH0rW0250gTgapFf+SsRGICuS3b8Ov6VkqTtVfTrmhoLliIIWJ2jcoPDNwRW1o1/DbRHbEzxqwZVD7dhPUZ9DxxWPY2Ml8JhEHZogGwMf57Vo2umRlMzXCptU9BgZ9yeO9CE7Ff7SA+xYZCe20ginNOdhB81Aeozwf1q6qWqyBVkjweNycgfWnxQQMj7uXVuSOwp7CuZTXEq/dYHHZhVixe4vZnRlj+Vc7cY39sfrSz2qtjapB9R3qaCKSyVJXXClvv8HjHT2pLUGRX6qsckKKcqvGBgDAyABWC5yoNdNqCyTAS/KAxLKwOQfXpXPSQbSeQcE4ApSHErfw8UhHrU5JAwMe9Mye/NSMhpQcNntQ3BNJQAMMMRSfWlPODSUAA6E0ClJxxSe4oASlFJS54oA//R84gXEisexrRPWqC8NxV4HIz7UCeoH2qGdN8RHfHFT00igRlCl7U+dNkpA6HkVHQO48Gr9lJkFPTms4VNDJscNzxQM1wacPSo1IIyKeKCR1L2pveloGLS039KXNAgb7pxg/Wk+bcOEX5vx6fzpeoOe9MVcAHylU4UnJ6f/qoAejZxlweAeP5025+4CPWlUkMASgHIwPrSXH+pJ9CKEBCoITKEhu1XruTSJLeYWtsnmAlxx/EPUenX2qgqOAXA4qlKHFw20MS2DgdTTuP1NddXuwcnyW4A/wBXjp9DT3165SPJt4CM9FLD+tZYPAPahwrKwc4B7+lAjWj8SXBUgWsWSMcyMcVt6d4qtrXSDZtZSQlixdo8OJM+ueRiuVh065bB2mFM/fkUjIPoO9bljYW0YV5V83GBl+n1x9KuMW9iZSityK9v7JoB5ChpZDgHZtKD69/SsG+H7lMfwtj/AD+VejJ4e0prF7q+0llcr+6VHZCfwzx1rlde0BbTTJrmCdysRBKSYJ+9t/rTcGJVI7HLE9KXtSHp9KBWZoLnniikooAWjNFB5oGAo6UlFAh1Jn160lHQUDFJ4961Idee3jCW2madHj+LyiWP4k1lUo4VvehOwM1z4kuXG2W1tSD/AHVK1C2oWc5zLaCNu5Cgj/Gs9ELHODtHBOOKc8RDgDoehouKxc228g/dsMfnTI7CaeXESrIT0AYD+dRPaMvzRNn26GozI6nDjBpJ9h2OlTRbGNyT5sygY2M2APxGCadqEdqNKlRLeNVQblRE5DdAc/z9qzLTWZQBHcSOydm7j6+oq4upJbHe0ZYk5VlcBfxNAWMMAuGdYWeNeWKKcKPc0jGFk+8yH6ZrqPPvr1dks5hiPURr19snmsWbQ7ldojlikB+8T8u3/EUwKqERjdHIrHPbt+dK8jPjdjio0QpuR/vKxBoJZe2RUspDv5UMSBkdccUwPkcK2aUZ7/hUlHRiWGKJG2jygo4Azxj/AD1rAfyxbiMSA46Gie6muMCWQlR0QcKPwFQfKSB3NXe45U1DYcfmbG4dKURvIfkHAqInZIc9qmjlK9MkHtSZSs0NkiaPG7B+lPtzhmPtUr7WbpTkjKZ4ye9BDkNRmyVUkAnPHY106XphijkdYTCcHdISh59+9c7Gh8zlQPc1YOmSXciTTXKxxEbIwTuY47AdhVxZnLXcoy3Mt1M9xOw8yU7jxjFM8wo2MVEQSckYwcH60d6HqUT78LuI46Yz1pjqokOFOzsM0gWRxlEZlBxwM1oRTGNXQxbiuO3fAosSQWt2bcyiHEfnJ5bNjnB9K6Hw9d2Uli2mXqjdJIzKzniQntnse3vWK0tjj98iqe5Iqm8lu0uLdiI26h+n4e1NE2Oiv9JuNMdjbCOW1c4HmEAxn61SiaOFvM8wu4HKrwp9uetQ3Wr3M2npZ3OJPLkDB2PzDAIwfXr1qhHKzn5z8ppMa2NJLh53MSnbuPBzWmoknhkij8sHaF2vyOOM/X0rnHZ0cAHFaY1BVMbRxsGIAYhv5U4iZF9oaMFBx7dqozKS5O4c+1OupovPZEPC8dc5qAyjsaTYyKRWB5qPnvVkvle1RkA81IysT8xpKeyFe3FMoGA+6c0DqKMcHPejvxTEOde/rTDweeKlWTOA3WlkUP0+9QIhooIwcHil60hkw4NXYjmFT7Vns2BgdauWhzB9DQLoTUGjFBoEVruPdHuHVeapVpsOMGs6RSjlT2/lQCG09T70ylFBRpWcm6PaTyv8qtg1lW8mxwT06GtNTxSQmPpabS0wFpc+tJRmgB1RFRg/IWGCOT15p/ak2gnJJPXvQIUDDdEHJ6e9EvMLZ7DNAVR0UUrcoR6igChNczQoqxMV5yff8KjF3KZvN3LG6LjKjGRTp1LRMwHRf6j+matWE9naKu+3Z5MhvMIDYP07UxoSz026uVDACGLjDyZ5HsOprYhtrLTgGCNLMfus/LH6DoKZHfx3MgENwjMexOD+Rpkr3Cuclx6sOCfyoQmaEF08r/eQA9mJZh+C/wBa29KgSSZMxqxBzvK4KkenNYOnRh5FALA56Dqa7LR7aMvucO2BitIqxEtTWuYmlXY5LeuSM1iatpRuNIv440MrtbuAuO+CR+uPyroNwA8tQAn61la14l0zQIyJZFluTgCFGGfxPYU+Z2sRyXdzxMcjPqKByKUoUOD69qTpWT3N+gveik57GgUAL3opKKAFPSik/GjNAxe1JS0BWdgqjLE4AoATinKAevQVfjs4FQrKGdj1YEjH0qvcWskClxl4j/GB09j6GldMLAkoCMqgKG6j1pFYn5Wzx0PpVcdM1LG6nCvnHTNDQFyKTfkH7w6/40TKjR4cA46H0qGJC1wsaN1yVb8OlX7aURXASRBlwRkjOCP8moaKuZs9pPaqHkQ+WTgN2NOtbrynQyRrNGGyUfoa2ZpMqYyNyuCCD3rFurUwYkXmJjgex9DVkmzca2FbFpbKQQDvlJ9OmB6VnXF/cT/62Xj+6vyiqatkbT0oABYBjgdzVxsJos20aT7y7MoGPu082pz8r5HoRTbLafN2A446/jVtamTGkMisHkTcJUUn+E9arzQSJc+QuHfH8P54/Kpp48P5m45wFxVWdmjuWdDgqwwR9KixaY0rtJUjBGQRUGQD71NNIzOXY/f5PHeoihwD19aEaTd0hJGLsWAwDU0QyvNRGTnFTxgoozjPWqSMmy1bx8gv+Aq0AvaqQuCDkrUi3UZHzK4+nNMktlRjmoZAyEvHI6EDqDihLmE/8tMfUEUrtG5ILZRhgkGgDPlZ5JGaRiXPJJqIg1NcP5svmFQDgBgvTIGKYGweB+dMEaltMkVvEnlrgKCT7nk/rTIpSLmVxwC5/HkmqDl2/wBY5P0NWoU5YLcRYBxgsBnjqM0CNIXMJ+8mfqAf51BcJDLCViWJXzwxQDA/CmNbXITeEyPY5qMLKHwyMBjPI4pAFzb273CKrMPk4wPQ1G6rBLhVVwACMjIqOWZVuPXAxxSCcbtzAkd6YCTFmC4XpTvM3R7fu/zpTcxdo2JPTnpUckqttCqFI6t1pAMMKdjTTAB/FSM57HvTQWPG7rwaBiMm0cMDRGGPA544qWONfLPf/wCtTEysq9gTSAa2R1FRuATnvV1vl5x/9aqTrt6ngnigBnelVGPQUhHAwasIhCjjJxTE2VypBORTlJXrz6VJJnr6UBFEO/zFz02HrSAayhxkdaj2Y5c7R+tOyR04odcjIOTTAjJ5q5YnhlqlVmzbEuPUVLGXqKM0fWgkQiql3HwHHbrVs1G4DAg96AM6ilZSjFT1FJmgo//S81U1o2kgePBPI4rMBqxbSbJAex4NIDTB/OnZwKiEijqwH40huIh1cfSmImozVOa82j91z6kiqz3Erg7nP4cUgsapZVGSwA9SadkEcYI9awyxNaNnITAAeoOKdwsW6dz1pgP40uaAK6KX82EAEurKoPr2qgh4BBIOKvg7bwc4+bNVbqMQ3Logwmcrx2PP/wBb8Kb2BCMqsOQPr6Vag1C6tlClhPEP4ZOoHsapryT7U48hgeeKm4ztPD93p2pShJJ/s83H7ljgv9G9K6wX9vZWe+aeNIIxz2//AFGvHVZWXB7d6s3F1PcBPOcyMowM9Bjv9ferUhOKOs1zxrNODDpIa3j7zNyzD2HauNnZpFZ2YljyWbkk/Wn9Mbjk9aYSSn40uZiskVd5B9RRwelNxyR6UA4/pSKF70YpQc/WigBKKUikoAO9AozzxQBQAo5OKvWkTW8pM8eC4wjdR78+tUOlaMY+Vd2WGASPWk3oNF9EQgkjaoH4k0mcdQMHqD3FIWzh1O5PfqPrS/eGSeKgspXGnZHmWoyP+efU/h6/SqBxzW6CQcgYxSXFtBdjLny5f+egHX6jvVqXcloxEkeNsoeRVlb35g0ijPWorm1ntZAsqEA8Kw+630NRAeo4qrXJNZ7uF8Mj5H05HWoZ54mtTGGJJPIxWceDxkUZOME0WHpYAcNilbpRJG6xrKUYIx+UkdfpTCeKHoIFZlHyswPsa3onsvLCPO6SkDtkdKwO9W2bcc9OKllIvM0JOPtKMOvIqvMkTsSZ0yxqszBTz1pkhDAEGpsMe2Ps5GRuQ1GrkDrQv3Dj1FTGNQ4cAY9KqwriRx4+Zhz2qTNGabnimIXNJ1ozRQAZ9qPrSUGgBpBzkGkLN3p2efeimIV2iMa+WJVk4DZxg/Sjfnnr65FJwBS4HagYeZt+6uD6qcU97ubYY/OkKnqCxIqPHFBHemnYQ5VDID3NOIUDkc5657fSgEAAdKSQ/P8AjQxByQSB+OKTjaCME89qB07daTnYM5xzSGKTk88kjvzSA4J6+vvSKQcDA/Dr+NJ0YZ9x1oAkRwsntnOCaicHO5TyDke1SQouSzAnH6/54qFH3cNSC48SMQd5YnvxxUUv3geoxQZWU7QeB04oVg5IIx3oAYo3NwPercR3LgnBHrVViAx2nigsMcHmmJoszFUOByx5+lQ7R1JyaajYyAM04gY65oEJnnPU0vbnrSBhnBGKXeMUDItpJp0RKSK3oaTNJuyc0gLv2tf7pNH2n0Wqe8elL5lILFk3JPAUfnTTcMe1V/M9BRvPoKAFlYs2TTKUsSKSgYU5evBptGaYEuR1PWjeBzmovrRSAeWBHBpOO9NozTAfkCrdm+Nwz6GqXPpUkW7cB0zQBqCUDvS+d6KT6VTHnZwkiov0yatWwMQIdjISQSWoRI8RbpDLIGDKMgZ4/Gq92gkhV0BYo21sAk4PI/XP51cMgLbgoBxSec38JwPbiq0BMzljlVSWjdcDJyMcetA6elXnm2FZcbmQ5I9R3H5VQumWG5ZUGYW+aM4/hPI/w/CpsNEBO0tjrmrMbfusj1qu2HJZOSakjBCYNAyXPz8dKY7Kg+Y02SYIMLy38qrEljljkmgQpOWJ9aSg8HmkzQA7tmnA5pn0qa3RWJLjIHShsY0GkYdx27Vb2RZyEANAVAcbBSuOxSp4xt+tX7e0kuWIt7ZWx1JwFH4mpZrGe2j3TW6CMHG5SCMn9aLisZeN5AHf9a0aruI2lXAIOenarAI/ClIcR6sVORUqHI3J27elQ0AlSCDg1LLLaNuHHSnLyc8VArh/9lv51IHJ+QjHrQBN5oMZRgHRuNrDINUbnS1kO6zbknJjY/yP+NWSwzwOKQMQevvTTsK1zCkVkkKyKyMOqsMEVLBLFA3mSRCZv4UY/L9T6/StiUQXEZF0gbA+9/EPoaxrm3MLBgS0bHAPcexq1IloLy8uL6XzLh9xHCgDAUe1QZFHSkoEKTVkciqvenb2H8XSgpMklwXGTxTeiKfemFj1J5qeGMgB3/4Cv9aQMWOM9WGM84qTNBbuec0lMQH60E96TNJn1oELnmk70Z70mcUDF+lBPYUlFABn0o7UlGaAFzS5puaXOTQAvXNL1po6+tKAcimIfnLD0pjHJ/Gl6HPXjNN2tuG4DnmgBwOFxwOfTmkHK9M89c0uRggBQM596YuNv3WJz17UAKG+XGR16Y5pOj4wBzQoJBIKgA/ifpSMOQQvGO9AEsbhHyQxHfHYVWGD+BqZgzL8pAGD1q/ONNhjkihtpJWxt812x26igRlSAbRimo2xw3oakwNh21EKBiuAsjAdM8fSkBwaCc9etJSAeD3FPzuGO9RA0ueaYhzDn5qTApc5AzSdqAI+9FPCZpfL+tICOipPL7UojFAEVFShB3FLtHoKVwIaOalKgU3NADcGgKadTlGaAGBCacIz3qUcDA6UtAEYiFKIu/GKfml7UANCYHWnqoHvTaUGgZ//0+BDDuakEm0cVXyO9G7gUhWLJlz3pu8nvUG7B5o3+9FxpE+7saqTHdEo4zGSPw/z/OpN3NRSH5j6EUJgQ5I5FP8ANfGM/jTBg9aMe1MBcdPegcUCpY03GgCI9qSp53TYI1GSDkmoO9AhRVmAbYx7mqtXUAWNQR2FJlId1ozikJ9BSE5qCjR0e68m5+zu2I5jgez9vz6flW3IiujRyjKMCrD2rkWwQQa6PTLz7bbfOczxDEn+0Ozf571SYpIwby1ktL4xv8y9Ub+8tPQ8VuXlut1EUkO0jlG/un/CsEq0UjRyLtdDgilIUWTdhRTQead7UiwGQalWQN988+tQ9aT2pAWsspAcfSlHTJ7VXWUrweR71IrB1wGAA657UwGSNngH3qK4G61I7k5p2OfrUNycIB3/AKULVieiKpjAwW3J74yKa8RUZDKw9VNWEkI+lKwQ8lR+FaszRSpakZRn2qWOJYyHf5m/hWkMSKIAB5BnP3V9frUmTyScmjknJOTSUABNB6Ue1J9KACkNB5pDSGGaM0GkzTEL26/jRmkPWj6UDDPNGaSigQtLmm0UDHZwKVfvHNMpwOFzjvQIkxkEk4HSkk2BsI7OMdSMUmVC/NzzSsVZyY0KjHSmAxASwAH40ALjJbnPShsBl+bIpASuRs9DyOlIAHVsLu4/L3oYKMbmb3pSMMfm25FNJJwEXPGaAHAjbnsKRyzOeqqTwvoKarZzmlIxhiwOR+VACqoUdahfhjUpOBTJB0NAEdJS0GgApw5FMpw60CY5TQeCeabnBpd2egNMB+efl4pxYgdjUeaKkB5cEUZ78Uz3FGcGgB/0pCaTOTnpQTQAhoopaAAD1p46U0YApw5NIBaB3opCaLjsLnikz+tJnPNGeKAHZx9aM80zNGT2oAfkUZ54pgODS5oBC55pOT04pQrHtinbABktQMbmmsCR9KeXjUcc0158jAFMTIW60ZoPNJTAUHH0p28gYQ49aZ2ooAWiijtQAAZYD1NXm68VSQ7ZFPoRVw8HBqWOIEnFNY96XNNY8GkUPKxqQJFIBGcg1NbyR286zW8u2Remf5H2oeMSRbeM4yD71SYYJBGCODTsTc62C4ju4fNixjoy5ztPpVbUbT7RHvjH75On+0PT/CsG0u57OUyW77c8MpGQw9CK27bWLaYATKbeT80/PqPxpit2MlWyMipAcirepWfW7gwyHmTbz/wIY/WqCn05qGrFp3JO9GaQGkoQw75pM5GO1GeKD+tAhVbbw3Q1BIfm65FTcDr0FV2IyaqKFIbnJpc03GcY60/G0+pqiRVATluX7D0pRnOTyT3pB69aOOuKACjNJnFGaQBRmj60me4pgBPNIc0UmewoAX6Un0NGaSgBc560UlGaACik+lFAC9e9GfWkxS0AHalPAApuaf0bnoOtAC+YABgcg5pTIXZ3PU9TUeU25BO7P6UFgFPuelAC55GKaxJPJ9qQNznFJu56UAPypBznPakDEYINNyfSjLY6UAKDh+RmpDCyIJHI2nGKj2srfOMEdRU2xXRizkEDIWgTGhcnBH0PY02QfIakBzEMdjTSefrTArUtDDDEUlIYU4dOKbSg8fSgB2MijpSqrN0HA70jEDIXn3piHYpcCjBzSH0qQADJoI5penNJigBD70YpcUBTnFIYUd6cENKE5welADBTl+6aeEwM0YGeooAZSdqdlBRvQdqAGnnilAPpSGZQOFppmY+1FgHhT+dGF7tUJZj1NJTsBOWjHOM00zHHAqKiiwEhkdu/FMyT1OaAaKAEooopgFFFFAH/1PMqSiigApaKSgB6fM6g8ZIqwWy1VVOGB96sSDbIw981LGhxb2ppNJmkPSlYovKeBUVzFuHmgezf409Dk1KuMdM/WmiDM6Ej0qQcc5ouYvKfI+6ehpin8qYy1bvLE37h2QnnCnA/LpUvkSZz8oz7023GxNx6np9KkMgo3C9gELDq4qPPNPaTCmoMipY02yQUU0E/WlzjtSGI3Cn3qA8nAGSasDk4qN02j5Rx61a2IZGPlAA5Y1aitMLum6/3abYxhpwCee3erd3KikpGpwO5PWqS0JbIT5a8BQKYxz2WoHkJPSo9598UhpEzbc8rg0wqPWo9/rQXx60DHEEDmm0eaO4NKAGHFIBKT60EEUme1AC0naijNMA7e9FJS0gDrRSUDkUwFoxRR+tACry4pc/eJ9KRehPcDiml8IR3oAVnQquEAx39aUOm45XOenPSmu5cj5QOAOKTA9qAFHX2xSlsxhdv3T19aQEDOaUyZhCbfuknPrQA9WKM+1c7lwfb3pvOOOOaek2x2KjO5Sp+lMJOCAtAhZVkWQ+bw2eafEkT5MrbcY71GzPJ985PHNAjZ2CjHtQAI2Bj8KcaaoC8DrS55pgRSDnNMqSTkZ9KjpDDoaeJMfwLn1IplFAD2kZhyePSmikpaBEm4etG5aaUHrSEDtSsA8OKN6+lRYooAl80DtSebjoKjpKLATec1IZXPeo6KBji7HvSZJ70lKOtMCxFahoGlkkKgdsdagIAxwa0JMJYqB1I496pwR+ZcbH4HOfwBp2JT1ECEdRjIyKiIwcVf+zoMkP+dVJ1CykA5FJod9SOiiigYUUUUAFFFL3oAVwPlKjgj9abUq5eIjqF5x6VEBQAUUUdaACiiigAooooAB1FWp/vK3qKq1dkXdB7jmkwRBniim5FGaRRcQ1MpyKqoRU4bgn2zQSyR0WWMoxwD0PoaoxxkSFXBypxgdTW8sEKZwgbHduak3kLtXge3FVYVzJENy5+WCTHupA/WnrZXB++UT/gWf5Vo7jSdaLBdlMWKD/WSs3+6MVHdQRRW26JMEMMnJPHP9cVeNQzr5kMiDqVOPr1H64pDRnqeBTs8VGhyuR0p2eKgsU/lSOQI+vehSCnFNkyFx71aIZGshSTKtg0PKTUUo4B9DTAaYiTdzRnvTM0oI+lIYueKM0nalzQAYBpC5BHHApc0tAAJc/epTjAIpmB2GKXpQAtJR1pCQOtMBaKZvPaj5jSAfR3pnNKCR1pgPqayiimvIop3ZEdsEr1z2/XFQds+tKrlGDLwVOQaAHEFYyD1zj8qaoyTkdBT53Lvub7zZY/U80xR8rH8KOoMcxiEnyrldoHfk+tIFQREk/PxjmmHAGaVwFyCDuHegQoC56duaBtBbg47c9KCEy2zdjHemqFGQ2Se2KBkrFPL4+/np7YpA2c8Y46U19oGCp3YGDnpTvlY/Ku35eeaBC+aBCy7efWmrk8Dkk00dO2KEbHPtmgAYMspVxgjg1IVAJAOR1qJ2Zmyc5POT3qVRyAO4oGiNjlTUaozuERSWPAAqXqeakgbybeaUAb2OxT6etJvQPIPsRxgzxeZ/czVd0aNirjBFJyW4zmrexruJeD5ynaeOoqbtbjsU6XBxnHFSlNgBKEbhkZHalWPfFncA+7GzHbHXNXYm4w0g9qU9KQUAFI2APc04elNkOWx6UAMooooGFLSUtAgoooHWgCbefJxnoaajbeWGRQOmfagkEEUMROsiBRgHkVBK27GBjFOA+QVI9u/wBm87A2F9mc98Zp2Aq0UUUhhRS0lAwpaKSkImt/9aBnrTJU8uRk646UI2xww6g5FXtTtwipOn3WOP6g/wA6YzPPSkpcUlABQKOtFABRRRQAVoI3I71n1eQ/KpFAFeaMxSFT07fSmZq9cx+dCrr99f1FUOODSC5//9XzpDUwPyn6VXU1Mp+U59DUjNtj87fWkoJO4/WkzVki0Z4wKQn1pM80gFNMPSnU00AZTKI5nj/unj6UpPympL1ds6uBw68+5H/1sVC5+X61D3LWw0MVPFLIwOMHimU04FWSJJ93FRVKxqI8GgQUUlFAxc4pdx9qbS96AHbqUMPWmUUgJODSMenamfSlHvQAZ+tGOSTRilzQAYpe1FApgFHajigUAOT7jqfqKRRuZQO5oT73Hof5URcFm/urTELIdzsaVUVl+Y7eC31pvYk0sgIwGPQUgGqucAZyTg0+WPARy33yfwxTFO1gacS74Xk+goAVYyWKBxyQM9qYqhlYlwuBwPWnYIRgRjnFNwT6UASMhMRl3EkELjFIAnG1i2V54xg0hZiCASAeopQrKR2yMigBqkBhuXI9KB97AHShRlgCevFGMN15zQAsshfGe3FC5xu9DQxGwLtAIzz601WOKBjnBDcdKdMf9EgHruPHfmmud3NSOMxQ+wP86lj3ZExEShV+8R8xp9vO6yAhiCDwagY5OaWMHf8ALTHe2hYlfJA7Akj2zTkVJUkJkVHG3auPvc8/lUksCm0jmQ/Nk7x/I1X53Fxx7VV+5nbU/9k=
Timestamp 2019-06-05 16:35:08
RelayAdresses:
1
Attributes:
ImageFileDir /opt/fhem/picture/Doorbird
SipDevice Sip
SipNumber **620
room Door
verbose 5
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said PeerHost : 192.168.0.66
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said buf : 11331:ghbogm:1559912925
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said data : 31313333313a6768626f676d3a31353539393132393235
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP datagram transmitted by valid PeerHost.
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessage is : Still Alive Message
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessageIdLast : 11330
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessageIdCurrent : 11331
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP datagram transmitted is new - Working on it.
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read _____________________________________________________________________
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said PeerHost : 192.168.0.66
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said buf : 11331:ghbogm:1559912925
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP Client said data : 31313333313a6768626f676d3a31353539393132393235
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP datagram transmitted by valid PeerHost.
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessage is : Still Alive Message
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessageIdLast : 11331
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UdpMessageIdCurrent : 11331
2019.06.07 15:08:46 5: Doorbird : DoorBird_Read - UDP datagram transmitted is NOT new - Ignoring it.
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set _______________________________________________________________________
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set - name : Doorbird
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set - command : Transmit_Audio
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set - option : /opt/fhem/audio/big_ben.mp3
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set - RelayAdresses : 1
2019.06.07 15:08:47 5: Doorbird : DoorBird_Set - usage : Unknown argument, choose one of Live_Video:on,off Open_Door:1 Light_On:noArg Restart:noArg Live_Audio:on,off Transmit_Audio
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - ---------------------------------------------------------------
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - Original Path exists : /opt/fhem/audio/big_ben.mp3
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - Temp Path created : /opt/fhem/audio/big_ben_tmp.wav
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - New Path created : /opt/fhem/audio/big_ben.ulaw
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - Sox System-Command : /usr/bin/sox -V /opt/fhem/audio/big_ben.mp3 -r 8000 -b 8 -c 1 -e u-law /opt/fhem/audio/big_ben_tmp.wav
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - SipDeviceAttribute : Sip
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - SipNumber : **620
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - ListSipDevices : $VAR1 = 'Sip';
/usr/bin/sox: SoX v14.4.1
Input File : '/opt/fhem/audio/big_ben.mp3'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:00:08.57 = 377849 samples = 642.6 CDDA sectors
File Size : 137k
Bit Rate : 128k
Sample Encoding: MPEG audio (layer I, II or III)
Output File : '/opt/fhem/audio/big_ben_tmp.wav'
Channels : 1
Sample Rate : 8000
Precision : 14-bit
Duration : 00:00:08.57 = 68544 samples ~ 642.6 CDDA sectors
Sample Encoding: 8-bit u-law
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
/usr/bin/sox INFO sox: effects chain: input 44100Hz 2 channels
/usr/bin/sox INFO sox: effects chain: channels 44100Hz 1 channels
/usr/bin/sox INFO sox: effects chain: rate 8000Hz 1 channels
/usr/bin/sox INFO sox: effects chain: dither 8000Hz 1 channels
/usr/bin/sox INFO sox: effects chain: output 8000Hz 1 channels
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - New Filesize : 68394
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - rename response message : 1
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - Attribute for SIP device: Sip
2019.06.07 15:08:47 5: Doorbird : DoorBird_Transmit_Audio - SIP device in Attribute exists
2019.06.07 15:08:47 4: Sip, audio file /opt/fhem/audio/big_ben.ulaw found
2019.06.07 15:08:47 4: Sip, Sip|**620|30|/opt/fhem/audio/big_ben.ulaw|0
2019.06.07 15:08:47 4: Sip, call -> Sip|**620|30|/opt/fhem/audio/big_ben.ulaw|0|0
2019.06.07 15:08:47 5: Sip, call has pid 18414
2019.06.07 15:08:47 4: Sip[18414], my parent is 1556
2019.06.07 15:08:47 4: Sip[18414], using Leg.pm to find a free port
2019.06.07 15:08:47 4: Sip, CALLDone -> Sip|0|CallRegister: Failed with code 400|0
2019.06.07 15:08:47 5: Sip, fifo is empty
2019.06.07 15:08:47 5: Sip, no elbc
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read _____________________________________________________________________
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said PeerHost : 192.168.0.66
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said buf : 11332:ghbogm:1559912933
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said data : 31313333323a6768626f676d3a31353539393132393333
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP datagram transmitted by valid PeerHost.
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessage is : Still Alive Message
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessageIdLast : 11331
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessageIdCurrent : 11332
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP datagram transmitted is new - Working on it.
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read _____________________________________________________________________
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said PeerHost : 192.168.0.66
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said buf : 11332:ghbogm:1559912933
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP Client said data : 31313333323a6768626f676d3a31353539393132393333
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP datagram transmitted by valid PeerHost.
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessage is : Still Alive Message
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessageIdLast : 11332
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UdpMessageIdCurrent : 11332
2019.06.07 15:08:53 5: Doorbird : DoorBird_Read - UDP datagram transmitted is NOT new - Ignoring it.
Hoffe, du hast eine schlaue Idee.
Gruß
Siggi
Hallo Siggi,
Der Code bedeutet:
400 Bad Request Die SIP-Anfrage ist fehlerhaft.
Mir fällt auf, dass das Attribut sip_from die falsche Syntax hat (vgl. https://wiki.fhem.de/wiki/SIP-Client#Attribute). Das Attribut muss wie folgt gesetzt sein:
sip_from sip:Doorbird@fritz.box
Das steht zwar im Wiki, aber in meinem Beispiel hatte ich tatsächlich das "sip:" vergessen ...
VG plin
Ok, ich habs nun (fast).
mit **620 am FritzFon kan ich das Doorbird (das steckt hinter der SIP **620) anrufen. Verbindung wird aufgebaut, Kommunikation ist möglich.
Folgendes passiert aber umgekehrt: Wenn ich das Doorbird betätige (den Klingelknopf), dann klingelt das Fritzfon, das Bild des Doorbird wird am Fritzfon auch angezeigt. Wenn ich dann aber das Fritzfon abnehme, dann wird eine komische Tonreihenfolge zweimal abgespielt und anschließend wieder aufgelegt.
Das gleiche passiert, wenn ich aus FHEM heraus beim SIP Device das Fritzfon anrufe (set SIP call **612). Ein anderes Fon ebenso auch diese komischen Töne ab (set SIP call **611)
Wie kann man das erklären bzw. beheben?
works as desigend :) siehe Wiki
Wenn etwas anderes nach der Rufannahme passieren soll must das schon beim set call Aufruf mit übergeben
Ich spiele in dem Fall ein simples "Willkommen" ab.
Hallo zusammen,
ich nutze FHEM aus einem Docker-Container auf einer Syno.
Ein FileLog für den DutyCycle der CCU3 funktioniert mit dem folgenden Attribut currentlogfile
./log/DutyCycle-2019.log
Im SIP-Modul habe ich history_file analog gesetzt
./log/sip_fhem.sip
history_size auf
100
Fehlermeldung:
sip_fhem, history file ./log/sip_fhem.sip, Can't open ./log/sip_fhem.sip: No such file or directory
Sollte das File nicht angelegt werden, wenn es nicht vorhanden ist?
Falls ich was übersehen, wäre ich Euch für einen Tipp dankbar.
Danke und ein schönes Wochenende
Dirk
Hast du Meldung auch noch wenn mal erfolgreich ein Ruf rein oder raus ging ?
Beim ersten Aufruf (lesen) stimmt die Meldung, da das File "noch" nicht vorhanden ist.
Angelegt wird es eigentlich automatisch beim schreiben, jedoch nicht beim lesen.
BTW : Hast du dir den weblink für die Liste auch angelegt ?
Mein Doorbird wird von Fhem angerufen, die Verbindung funktioniert und die Ausgabe kommt auch.
Bei jedem Anruf wird die Meldung ins Log geschrieben, ja.
Welchen Weblink für die Liste meinst Du?
Habe ich was vergessen?
OK, dann muss ich das bei mir nochmal testen wenn die Datei noch nicht vorhanden ist.
Bis dahin kannst du sie aber selbst erzeugen ( touch /opt/fhem/log/sip_fhem.sip und chown fhem.dialout /opt/fhem/log/sip_fhem.sip )
Weblink :
ja wenn man eine Anrufer Liste denn mal hat in sip_fhem.sip, dann will man sie sich vllt. auch ansehen können ?
Ähnlich wie die FB Calllist , allerdings bis jetzt nur als weblink :
define SIPList weblink htmlCode {SIP_html('sip_fhem','SIPCalllist')}
wobei ich weblinks eigentlich nicht mag und schon die ganze Zeit da was machen wollte, habe da die letzten Wochen einiges von DS_Starter zu dem Thema gelernt.
Die Datei habe ich manuell angelegt, damit ist die Meldung aus dem Log verschwunden.
Den Weblink hatte ich aktuell nicht vermisst, ich hatte die Einträge in der Datei zur Fehlersuche genutzt und dabei direkt auf das File zugegriffen.
Hallo Wzut,
Ich hoffe, ich bin hier richtig, um einen Fehler im Modul 96_SIP zu melden?!
Bei mir kommt in Log das:
Telefon[2582], can´t find my parent 5597 in process list !
Died at ./FHEM/96_SIP.pm line 386.
Durch einen kurzen Blick in den Code, habe ich die Ursache gefunden: der "ps -e" liefert z.B. nur das:
ps -e | grep 5597
5597 ? 00:24:07 fhem.pl
Richtig wäre aber m.E.:
ps -efww | grep 5597
fhem 5597 1 0 Jul25 ? 00:24:07 /usr/bin/perl ./fhem.pl fhem.cfg
fhem 5640 5597 0 Jul25 ? 00:03:31 /usr/bin/perl ./fhem.pl fhem.cfg
fhem 5641 5597 0 Jul25 ? 00:02:03 /usr/bin/perl ./fhem.pl fhem.cfg
fhem 5642 5597 0 Jul25 ? 00:01:52 /usr/bin/perl ./fhem.pl fhem.cfg
Durch folgende Änderung ist das Problem behoben:
--- 96_SIP.pm.ORIG 2019-07-31 22:21:55.715699993 +0200
+++ 96_SIP.pm 2019-07-31 22:31:03.222362184 +0200
@@ -378,7 +378,7 @@
$sub_register = sub
{
my $expire = $ua->register(registrar => $registrar ) || return "registration failed: ".$ua->error;
- my $cmd = "ps -e | grep '".$hash->{parent}." '";
+ my $cmd = "ps -efww | grep '".$hash->{parent}." '";
my $result = qx($cmd);
if (index($result,"perl") == -1)
{
Würdest du das bitte übernehmen (oder gerne auch anders lösen)?
Und auf jeden Fall Danke für das coole SIP Modul! :)
LG,
Stephan.
bei mir (und vermutlich fast allen anderen Modul Usern )
ps -e | grep 587
587 ? 01:55:33 perl
d.h. genau das was auch erwartet wird -> perl
bei ps -efw | grep 587
fhem 587 1 3 Jul31 ? 01:55:36 /usr/bin/perl fhem.pl fhem.cfg
fhem 669 587 0 Jul31 ? 00:00:00 /usr/bin/perl fhem.pl fhem.cfg
root 18724 18644 0 08:08 pts/0 00:00:00 grep 587
d.h. zuviele Treffer , denn die Kinder (bzw das Kind 669) sind keine Aussage das der FHEM Hauptprozess noch läuft.
Wir haben es hier eher mit einem Problem der ps Version zu tun. Unter welchem OS läuft denn dein FHEM ?
Mein FHEM läuft unter einem relativ aktuellen Gentoo.
ps stammt aus dem ebuild sys-process/procps Version 3.3.15.
Wenn es allerdings an der Codestelle nur darum geht, zu prüfen, ob $hash->{parent} noch läuft, dann wäre es eleganter das mit Perls kill Funktion zu machen: Wenn du Signal 0 sendest, kannst du testen, ob der Prozess läuft. Folgendes läuft bei mir:
--- 96_SIP.pm.ORIG 2019-07-31 22:21:55.715699993 +0200
+++ 96_SIP.pm 2019-08-03 21:03:52.083376938 +0200
@@ -378,9 +378,7 @@
$sub_register = sub
{
my $expire = $ua->register(registrar => $registrar ) || return "registration failed: ".$ua->error;
- my $cmd = "ps -e | grep '".$hash->{parent}." '";
- my $result = qx($cmd);
- if (index($result,"perl") == -1)
+ unless (kill 0, $hash->{parent})
{
Log3 $name,1,"$logname, can´t find my parent ".$hash->{parent}." in process list !";
die;
Was sagst du dazu?
LG,
Stephan.
Zitat von: loescher am 03 August 2019, 21:07:45
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 ;)
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?
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) :
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 :
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
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....
Die Kür wäre dann auch noch eine sogenannte strukturierte Notrufabfrage, aber jetzt bin ich schon etwas weit abgehoben.... ;-)
@Papaloewe: wenn Du viele komplizierte Dinge mit dem Telefon tun möchtest bietet sich asterisk an. Das gibts mittlerweile auch als docker image.
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.
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.
Zitat von: Wzut am 11 August 2019, 08:21:01
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.
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 :)
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
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.
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
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
Danke, habe ihm mal geschrieben.
vG netbus
Hier die Antwort:
man kann mit dem Modul direkte Verbindungen zwischen SIP-Endgeräten
aufbauen. Das ist sogar der einfacherer Fall, weil hier keine Vermittlung
über einen Registrar+Proxy erfolgen muß. Siehe z.B. t/04_call_with_rtp.t in
der Distribution, welches zwei UserAgents baut und zwischen denen Daten
austauscht.
Es wird allerdings keinerlei Behandlung von NAT etc vorgenommen, d.h. die
beiden "Telefone" müssen direkt miteinander sprechen können, ohne das man
STUN, TURN o.ä. involvieren muß.
Oh das ging ja fix.
OK dann muss ich mir sein t/04_call_with_rtp.t Beispiel mal genau ansehen.
Zum besseren Verständnis, kannst du mal genauer erklären was du so im Detail vor hast und vor allem soll der Rufaufbau von FHEM ausgehen ?
Ich möchte von Fhem (Sipclient) einen Call auf Doorbird (Sipclient) machen.
Beide befinden sich im selben LAN.
also ich habe mir das Beispiel jetzt mal angeschaut , eigentlich sollte es machbar sein den Part noch ins Modul zu packen.
Was mir aber noch immer unklar ist :
Was willst du Doorbird senden , Sprachnachricht oder DTMF Töne ? und warum ?
Da ich keinen Doorbird besitze ist mir ebenfalls noch unklar wie ich testen soll bzw. welche Parameter dort wie zu besetzen sind.
genau, eine Sprachnachricht oder kurze Wartemusik.
Also jemand klingelt und fhem macht einen Call zum Doorbird, Doorbird hebt sofort ab und spielt die Musik ab.
wäre es nicht viel einfacher dem Doorbird diese Nachricht via http POST zu senden ?
Laut Doorbird Doku lan-api :
LIVE AUDIO TRANSMIT
Transmit audio (G.711 μ-law) from your mobile device (e.g. Home Automation tablet)
to the device. Only one consumer can transmit audio (talk) at the same time. The
second consumer will be rejected.
When the request is correct, but the requesting user has no permission to view the
live stream at the moment, the request is answered with a return code 204. This
usually happens for users without "watch-always" permission when there was no ring
event in the past 5 minutes.
Please note, that the audio connection can get interrupted at any time, when the
official DoorBird App requests the stream. It has precedence over users of the LAN-
API.
Method:
POST
Required permission:
valid user, "watch always" or ring event in the past 5 minutes for the requesting user
Syntax:
http://<device-ip>/bha-api/audio-transmit.cgi
Example 1:
Singlepart audio data transmit with G.711 μ-law (authorization omitted).
POST /bha-api/audio-transmit.cgi HTTP/1.0\r\n
Content-Type: audio/basic\r\n
Content-Length: 9999999\r\n
Connection: Keep-Alive\r\n
Cache-Control: no-cache\r\n
\r\n
<AUDIO DATA>
<AUDIO DATA>
<AUDIO DATA>
Das funktioniert leider nicht (Herstellerseitig) obwohl in der API dokumentiert.
Daher der SIP workaround
ja ich habe die Antwort von Sailor heute Morgen im Doorbird Fred gelesen.
IMHO sollten wir ihn mit ins Boot holen da er ja scheinbar Ahnung von Doorbird hat.
Ich habe das 04_call_with_rtp.t in zwei Teile zerlegt und würde dir bevor ich das SIP Modul durchwürfle erst einmal ein mini Prg geben das ein Audiofile zu deinem Doorbird schickt.
Dazu benötige ich unbedingt noch Infos von dir und/oder Sailor :
a. welche IP hat dein Doorbird ?
b. welcher Port ist offen für SIP ?
c. Transport udp oder tcp ?
d. welche Domain bzw. Domainname soll verwendet werden ? example.com ?
Hallo Wzut,
Ich hatte vor ein paar Monaten in diesem Thread eine kleine Verbesserung bzgl. "ps" vorgeschlagen.
Beim heutigen Update habe ich aber gesehen, dass du das noch nicht übernommen hast.
Gibt es dafür einen Grund?
Funktioniert es bei dir nicht?
Wenn ich noch etwas helfen kann, lass es mich bitte wissen!
Hier nochmal der Patch:
--- 96_SIP.pm.ORIG 2019-11-29 21:52:12.638690240 +0100
+++ 96_SIP.pm 2019-11-29 21:53:48.691695431 +0100
@@ -378,9 +378,7 @@
$sub_register = sub
{
my $expire = $ua->register(registrar => $registrar ) || return "registration failed: ".$ua->error;
- my $cmd = "ps -e | grep '".$hash->{parent}." '";
- my $result = qx($cmd);
- if (index($result,"perl") == -1)
+ unless (kill 0, $hash->{parent})
{
Log3 $name,1,"$logname, can´t find my parent ".$hash->{parent}." in process list !";
die;
LG,
Stephan.
Zitat von: loescher am 30 November 2019, 21:31:40
Gibt es dafür einen Grund?
ja, leider : mein Alter ..... ich habe es einfach glatt vergessen :(
Zitat von: Wzut am 11 August 2019, 14:38:27
Sodle , das hat mir doch keine Ruhe gelassen .... eine kleine Änderung an der Call Funktion und schon kann man DTMF auch bei ausgehendem .
Welche Änderung hast du denn vorgenommen? Ich wäre ander Funktion intersssiert, auf einen Anruf mit Tastendruck zu reagieren.
Das war nur quick & dirty. Ich hoffe das ich zwischen Weihnachten und Neujahr etwas Zeit finde um zum einen endlich das ps Thema vom Tisch zu bekommen
und ich werde das reagieren auf DTMF mal sauber mit aufnehmen - ggf. per Attribut
oder : @plin hast du im Moment dafür Zeit ? Meine neue Baustelle MAX Module erfordern akuell recht viel Zeit.
Zitat von: Wzut am 15 Dezember 2019, 19:19:16
@plin hast du im Moment dafür Zeit ? Meine neue Baustelle MAX Module erfordern akuell recht viel Zeit.
Mal schaun, bin im Vorweihnachtsstress, evtl. am Freitagvormittag ...
Hallo,
ich nutze seit einiger Zeit auch dieses Modul und bin zufrieden. Vielen Dank an die Entwickler.
Ich habe eine Fritzbox 7490 und eine Auerswald TFS-Universal plus. An der Auerswald sind 2 Klingelknöpfe aktiv. Die Klingelknöpfe sind mit jeweils einer Kurzwahlnummer aus dem Telefonbuch der Fritzbox belegt. Im Fritzbox-Telefonbuch werden die Telefone (DECT, LAN-IP, Handy) der jeweiligen Kurzwahlnummer zugeordnet.
Für Klingelknopf 1 habe ich über das SIP-Modul eine Rufumleitung auf die Telefone des 2. Klingelknopfes eingerichtet. Wenn wir nicht zu Hause sind, erreicht die Post trotzdem jemanden.
Wenn wir aber zu Hause sind und an die Türsprech gehen, werden leider die anderen Telefone nicht abgeschaltet, sie klingeln bis zum Ende und es geht unter Umständen jemand ran und bekommt die Textnachricht vorgelesen.
Jetzt meine Frage:
Wie bekomme ich mit das das Gespräch von der Tür entgegengenommen wurde ?
Wie kann ich die anderen Telefone die ich über das SIP-Modul benachrichtige habe auflegen lassen ?
Ich meine schon mal hier im Forum dazu etwas gelesen zu haben, finde es aber jetzt nicht wieder.
SIP Notify für Rufweiterleitung
defmod Tur2Ruf notify sipfritz:caller_nr:.\*\*1 set sipfritz call **772 30 !Es ist jemand an der Tür
Ich wünsche allen noch ein gesundes neues Jahr.
pejonp
Moin,
ich habe da ein paar Fragen:
- Wieso verwendest Du zwei Türklingeln?
- Haben die unterschiedliche Beschriftungen?
- Deine "Rufweiterleitung" per SIP-Modul ist keine Weiterleitung sondern ein parallel abgesetzter Anruf?
- Wieso hast Du nicht eine interne Gruppe von Telefonen in der das SIP-Modul als ein Teilnehmer eingerichtet ist (vgl. https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden (https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden))?
Zitat von: plin am 02 Januar 2020, 07:51:58
Moin,
ich habe da ein paar Fragen:
- Wieso verwendest Du zwei Türklingeln?
- Haben die unterschiedliche Beschriftungen?
- Deine "Rufweiterleitung" per SIP-Modul ist keine Weiterleitung sondern ein parallel abgesetzter Anruf?
- Wieso hast Du nicht eine interne Gruppe von Telefonen in der das SIP-Modul als ein Teilnehmer eingerichtet ist (vgl. https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden (https://wiki.fhem.de/wiki/SIP-Client#Fritzbox_.2B_Doorline_-_Telefonklingeln_beenden))?
Hallo plin,
Jede Wohung hat seine Klingel, deshalb zwei Klingeln mit unterschiedlicher Beschriftung. Das sip-device zur rufabsetzung ist in der 1.Klingel (Tefonbuch fritzbox) mit hinterlegt. Deshalb funktioniert es.
Das sip-device ist in der 1.Klingel hinterlegt damit es den Anruf von der türsprech mitbekommt und darauf reagiert.
Vielleicht habe ich auch einen Denkfehler in meiner Aufstellung.
Pejonp
Hallo pejonp,
dann lass uns das mal sortieren:
Zitat von: pejonp am 01 Januar 2020, 21:41:57
Ich habe eine Fritzbox 7490 und eine Auerswald TFS-Universal plus. An der Auerswald sind 2 Klingelknöpfe aktiv. Die Klingelknöpfe sind mit jeweils einer Kurzwahlnummer aus dem Telefonbuch der Fritzbox belegt. Im Fritzbox-Telefonbuch werden die Telefone (DECT, LAN-IP, Handy) der jeweiligen Kurzwahlnummer zugeordnet.
Für Klingelknopf 1 habe ich über das SIP-Modul eine Rufumleitung auf die Telefone des 2. Klingelknopfes eingerichtet. Wenn wir nicht zu Hause sind, erreicht die Post trotzdem jemanden.
Fragen
- Hängt am Klingelknopf 1 nur das SIP-Modul oder auch weitere Endgeräte?
- "Wenn wir nicht zu Hause sind, erreicht die Post trotzdem jemanden." bedeutet "Ihr" seid "Klingelknopf 1" und "Klingelknopf 2" ist jemand anders?
Zitat von: pejonp am 01 Januar 2020, 21:41:57
Jetzt meine Frage:
Wie bekomme ich mit das das Gespräch von der Tür entgegengenommen wurde ?
Wie kann ich die anderen Telefone die ich über das SIP-Modul benachrichtige habe auflegen lassen ?
Das kriegt die Fritzbox mit wenn alle Telefone in derselben Gruppe sind und ein Endgerät der Gruppe das "Gespräch" annimmt.
Zusatzfrage
- Woran erkennst Du ob "Ihr" zu Hause seid?
- Gehören beide Wohnungen derselben Familie, d.h. wäre es denkbar den SIP-Client in beide Endgerätegruppen aufzunehmen?
VG plin
sipfritz: **628 sipfritz ist als Türsprech eingerichtet und kann noch eine IP-Cam aufs Fritzfon schalten.
Türsprech: **1
Klingel 1: ist die Gruppe **771 zugeordnet (**610#611#612#613#625#623#628#627) sipfritz (**628) enthalten
Klingel 2: ist die Gruppe **772 zugeordnet (**614#615#625)
Wenn wir nicht zu Hause sind, erreicht die Post trotzdem jemanden ?
- ja wenn jemand unter "Klingelknopf 2" zu Hause ist
- bedeutet wir sind "Klingelknopf 1" und "Klingelknopf 2" sind die Eltern
- Ansonsten ist es so als wenn keiner zu Hause ist. Post zum anderen Nachbarn oder Packetstation.
Woran erkennst Du ob "Ihr" zu Hause seid?
- wenn die Tür klingelt und wir als erster abnehmen, die "Rufweiterleitung" ist immer aktiv
Gehören beide Wohnungen derselben Familie, d.h. wäre es denkbar den SIP-Client in beide Endgerätegruppen aufzunehmen?
- der SIP-Client kann überall eingetragen werden, macht es Sinn den SIP-Client in beide Gruppen einzutragen,
- der SIP-Client würde sich ja dann selber anrufen und er wurde ja schon von der Tür angerufen und müsste eigentlich noch besetzt sein.
- Vielleicht 2. Sip-Client anlegen und der überwacht dann was auch immer
Ich glaube ja, so einen Vorschlag hier im Forum schon gesehen zu haben, kann ihn aber nicht mehr finden.
pejonp
mmh, ok. Also das Kernproblem ist die Anwesenheitserkennung, die aber auch nicht zuverlässig feststellt, ob ihr nicht nur anwesend seid sondern auch das klingeln gehört habt. Dann könnte man den jetzigen Anrufautomaten gezielt steuern.
Alternative 1: den laufenden Anruf des Anrufautomaten stornieren
@wzut: So etwas haben wir aktuell nicht drin.
Plan B:
- 2. SIP-Client in die Gruppe der Eltern reinhängen
- Wenn das klingeln in der Gruppe Türklingel 1 beendet wird kann der 2. SIP-Client das Gespräch des 1. annehmen und beendet damit den Telefonterror. DOIF ist da etwas leistungsfähiger als NOTIFY.
Du musst Dir natürlich den Status "ringing" zwischenspeichern, damit Du den alten und den aktuellen Status vergleichen kannst.
Zitat von: plin am 02 Januar 2020, 15:35:37
@wzut: So etwas haben wir aktuell nicht drin.
jein ... Der laufende Ruf ist ja im Child Prozess, hier geht es darum das die Eltern auf Userwunsch das Kind töten.
Als set Kommando gibt es das nicht , als Code im Modul schon : immer wenn das Attribut sip_listen geändert wird gibt es einen kill des aktuellen.
D.h. man müsste den Ablauf auf ein Set Kommando legen und nicht den Listen Prozess abschiessen sondern den gerade gestarteten Call.
Bsp: set <name> kill_activ_call
Hallo,
wäre es möglich das SIP-Modul so zu erweitern, dass es eine USB-Soundkarte für Audio-In/-Out verwendet?
Dann könnte man das Modul für eine Türsprecheinrichtung direkt, also ohne baresip/linphone... verwenden.
Der Rest wie starten eines Anrufes und DTMF-Erkennung gehen ja schon.
Grüße
Newti64
Zitat von: Newti64 am 17 Januar 2020, 21:52:12
Hallo,
wäre es möglich das SIP-Modul so zu erweitern, dass es eine USB-Soundkarte für Audio-In/-Out verwendet?
Dann könnte man das Modul für eine Türsprecheinrichtung direkt, also ohne baresip/linphone... verwenden.
Der Rest wie starten eines Anrufes und DTMF-Erkennung gehen ja schon.
Grüße
Newti64
mmh, und was erwartest Du soll passieren wenn jemand in das an deine Sound-Karte angeschlossene Mikro spricht? Speach to Text? Was dann?
Für die Ausgabe kannst Du einfach T2S nutzen. Das nutze ich für meine Sprachausgabe auf einen kleinen Bluetooth-Lautsprecher.
Zitat von: plin am 17 Januar 2020, 22:39:48
mmh, und was erwartest Du soll passieren wenn jemand in das an deine Sound-Karte angeschlossene Mikro spricht? Speach to Text? Was dann?
Für die Ausgabe kannst Du einfach T2S nutzen. Das nutze ich für meine Sprachausgabe auf einen kleinen Bluetooth-Lautsprecher.
Man könnte das Modul für eine Türsprechstelle nutzen.
Die Abfrage (DOIF) einer Klingeltaste (RPI-GPIO) startet das SIP-Modul mit einem Anruf an eine Nebenstelle der Fritzbox und wenn man abhebt kann man mit dem Besucher über das Mikro/Lautsprecher der Soundkarte sprechen. Wäre eine feine Sache für DoorFHEM.
Grüße
Newti64
Das gibt es schon , nennt sich DoorPi -> https://forum.fhem.de/index.php/topic,49877.0.html
bzw wenn pah Zeit & Lust hat Door-FHEM -> https://forum.fhem.de/index.php/topic,101299.msg947413.html#msg947413
Zitat von: Wzut am 18 Januar 2020, 08:03:57
Das gibt es schon , nennt sich DoorPi -> https://forum.fhem.de/index.php/topic,49877.0.html
bzw wenn pah Zeit & Lust hat Door-FHEM -> https://forum.fhem.de/index.php/topic,101299.msg947413.html#msg947413
DoorPi-Modul (FHEM) baut auf die DoorPi Hardware mit Display, Kamera an der Türstation und der sehr umfangreichen Software auf. DoorPi wird aber nicht mehr weiter entwickelt.
Door-FHEM soll eigenständig laufen, ohne DoorPi im Hintergrund. Da wird gerade an der Einbindung eines SIP-Clients gearbeitet.
Deshalb kam ich auf die Idee, warum nicht das SIP-Modul nehmen, das kann schon alles, nur der Live-Sound fehlt noch. Ein paar DOIFs oder Notifys dazu und fertig ist die Türsprechanlage. Zumindest Softwareseitig :-)
Grüße
Newti64
Zitat von: Newti64 am 18 Januar 2020, 09:43:25
das kann schon alles
nein kann es nicht weil weder die direkt Ausgabe auf das Audio Device im Unterbau Net::SIP vorhanden ist noch der Input via MIC.
Aber du kannst ja gern Steffen Ullrich anschreiben und ihn bitten das noch nachzuholen :)
Zitat von: Wzut am 18 Januar 2020, 15:08:10
nein kann es nicht weil weder die direkt Ausgabe auf das Audio Device im Unterbau Net::SIP vorhanden ist noch der Input via MIC.
Aber du kannst ja gern Steffen Ullrich anschreiben und ihn bitten das noch nachzuholen :)
Hallo Wzut,
ok, jetzt hast du mich überzeugt :D , wenn im Net::SIP, auf das du ja aufbaust, kein Audio-Device für IN/OUT vorhanden ist, ist der Aufwand das extra einzubringen zu groß.
Ich hatte mir die Net::SIP Library "als Laie" schon ein bisschen durchgesehen und auch nix gefunden, hatte aber noch die Hoffnung, dass du die Library besser kennst und eine Aussage dazu machen kannst.
Danke noch für deine Bemühungen und deine super Arbeit am FHEM SIP-Modul.
Grüße
Newti64
pah hat demnächst hoffentlich wieder etwas Zeit ...
LG
pah
Hallo und erstmal danke für das Modul! Habe es nun schon länger im Einsatz und lasse mich z.B. bei einem Stromausfall von FHEM anrufen! Leider bricht die Verbindung bei längeren TTS Ansagen ab bevor alles gesprochen wurde.
Bei folgendem Beispiel bricht die Verbindung immer beim Komma ab:
attr sip T2S_Device t2s
attr sip T2S_Timeout 15
attr sip audio_converter sox
attr sip_audiofile_call !Stromausfall Dortmund von 13 Uhr 50 bis 13 Uhr 51 Strom ist wieder stabil bei 230,4 Volt
Jemand ne Idee woran das liegen könnte?
timeout beim set Aufruf zu kurz gesetzt ? dann legt SIP auf bevor der Text durch ist :)
Hatte keinen timeout gesetzt. Aber auch mit einem timout von 60 wird das Gespräch nach 11 Sekunden beendet. Das Reading call_state steht danach auf timeout.
set sip call ******** 60
ok, dann must du dir mal die mp3 Datei selbst vornehmen, d.h. kopieren und mit einem anderen Gerät abspielen ob sie wirklich die volle Länge hat oder zu kurz ist. Falls sie zu kurz ist schau dir mal bei T2S Device das mit dem mp3wrap an
Edit : ich habe das mit dem Komma überlesen :
ZitatAttribute
TTS_Delimiter
Optional: Wird ein Delimiter angegeben, so wird der Sprachbaustein an dieser Stelle geteilt. Als Delimiter ist nur ein einzelnes Zeichen zulässig. Hintergrund ist die Tatsache, das die einige Sprachengines nur eine bestimmt Anzahl an Zeichen (zb. Google nur 100Zeichen) zulässt.
Im Standard wird nach jedem Satzende geteilt. Ist ein einzelner Satz länger als 100 Zeichen, so wird zusätzlich nach Kommata, Semikolon und dem Verbindungswort und geteilt.
lass mal das Komma in deinem Satz weg :)
Ohne Komma hab ichs schon versucht, leider keine Besserung. Auch die mp3 Datei ist in Ordnung.
Edit: logs mit verbose 5:
2020.01.23 17:04:03 5: sip, MD5: Stromausfall Dortmund von 13 Uhr 50 bis 16 Uhr 12 Strom ist wieder stabil bei 2332 Volt test -> d3fc873bff77fb26fa03739d7c7d86f6.mp3
2020.01.23 17:04:03 5: sip, set call new -> sip call ******* 60 cache/d3fc873bff77fb26fa03739d7c7d86f6.mp3
2020.01.23 17:04:03 4: sip, audio file cache/d3fc873bff77fb26fa03739d7c7d86f6.mp3 found
2020.01.23 17:04:03 5: sip, not converted - using cache/d3fc873bff77fb26fa03739d7c7d86f6.alaw from cache
2020.01.23 17:04:03 4: sip, sip|***************|60|cache/d3fc873bff77fb26fa03739d7c7d86f6.alaw|0
2020.01.23 17:04:03 4: sip, call -> sip|***********|60|cache/d3fc873bff77fb26fa03739d7c7d86f6.alaw|0|0
2020.01.23 17:04:03 5: sip, call has pid 1894754
2020.01.23 17:04:03 4: sip[1894754], my parent is 7593
2020.01.23 17:04:03 4: sip[1894754], trying to use port 4070
2020.01.23 17:04:03 4: sip[1894754], register new expire : 2020-01-23 17:15:03
2020.01.23 17:04:03 5: sip, readingS:state Val:calling
2020.01.23 17:04:03 4: sip[1894754], CallStart with 2 files - first file : CODE(0x55c00092ff60) - PCMA/8000 , repeat 0
2020.01.23 17:04:03 4: sip[1894754], calling : *********
2020.01.23 17:04:03 5: sip, readingS:call_state Val:calling **********
2020.01.23 17:04:10 4: sip[1894754], cb_final - status : OK
2020.01.23 17:04:10 4: sip[1894754], call established
2020.01.23 17:04:10 5: sip, readingS:call_state Val:established
2020.01.23 17:04:10 5: sip[1894754], 0. Ende des ersten Loops
2020.01.23 17:04:10 5: sip[1894754], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x55c000a151a8)
2020.01.23 17:04:10 5: sip[1894754], 2. fi : 0
2020.01.23 17:04:10 5: sip[1894754], 4. timeout : 0
2020.01.23 17:04:10 5: sip[1894754], 6. call_established : 1
2020.01.23 17:04:10 4: sip[1894754], next file : cache/d3fc873bff77fb26fa03739d7c7d86f6.alaw
2020.01.23 17:04:11 4: sip[1894754], cb_final - status : OK
2020.01.23 17:05:03 5: sip[1894754], call->bye
2020.01.23 17:05:03 1: PERL WARNING: Use of uninitialized value in subroutine entry at /usr/local/share/perl/5.28.1/Net/SIP/Endpoint/Context.pm line 80.
2020.01.23 17:05:03 1: PERL WARNING: Use of uninitialized value $uri in pattern match (m//) at /usr/local/share/perl/5.28.1/Net/SIP/Endpoint/Context.pm line 181.
2020.01.23 17:05:03 5: sip[1894754], Timeout : 1
2020.01.23 17:05:03 5: sip[1894754], while : 0
2020.01.23 17:05:03 5: sip[1894754], Status : OK
2020.01.23 17:05:03 4: sip[1894754], Calltime : 53
2020.01.23 17:05:03 4: sip, CALLDone -> sip|1|timeout|53
2020.01.23 17:05:03 5: sip, fifo is empty
2020.01.23 17:05:03 5: sip, no elbc
Edit2: Die .alaw Datei ist auch okay
Hallo bennebartsch.
Zitat von: bennebartsch am 23 Januar 2020, 16:15:21
...wird das Gespräch nach 11 Sekunden beendet...
und im Log fällt mir auf:
Zitat von: bennebartsch am 23 Januar 2020, 17:03:07
2020.01.23 17:04:03 5: sip, MD5: Stromausfall Dortmu ...
2020.01.23 17:04:03 4: sip[1894754], register new expire : 2020-01-23 17:15:03
Also Start 17:04:03 und Expire 17:15:03 = 11sec.
Wäre vielleicht wichtig zu wissen, warum die Registrierung expired. Bei Asterisk kann ich sowas konkret festlegen (z.B. defaultexpirey = 3600). Was für einen Registrar verwendest Du (Fritzbox, Asterisk etc.)? Ließe sich testweise ein expirey höher setzen?
Viele Grüße
rob
das sind doch 11 minuten.
lol, Du hast völlig Recht! Ist wohl schon zu spät für mich - vergesst, was ich schrieb, ich nehm alles zurück und behaupte das Gegenteil ;D
VG
rob
nachdem nun die einfachen Dinge durch sind wird es langsam schwierig und mir gehen dann auch die Ideen aus.
Was mir aber absolut nicht gefällt sind die beiden Zeilen im Log:
020.01.23 17:05:03 1: PERL WARNING: Use of uninitialized value in subroutine entry at /usr/local/share/perl/5.28.1/Net/SIP/Endpoint/Context.pm line 80.
2020.01.23 17:05:03 1: PERL WARNING: Use of uninitialized value $uri in pattern match (m//) at /usr/local/share/perl/5.28.1/Net/SIP/Endpoint/Context.pm line 181.
Auf welcher Plattform läuft hier das SIP Modul und welche Versionen sind im Einsatz - ich sehe Perl 5.28 -> ergo Raspi 4 mit Buster ?
Wenn Buster : Welche Version des Net::SIP bringt Buster mit ? ( ich habe noch keines im Einsatz, mein Testystem ist z.Z. durch die MAX Weiterentwicklung blockiert )
Kann jemand mit dieser Hardware Ausstattung den Text fehlerfrei übertragen ?
Bricht der Call auch bei Anruf eines internen Teilnehmers an der gleichen Stelle ab ?
Lassen sich die 11 Sekunden mit einer anderen Datei/ Text und ggf. durch setzen des Wiederholungs Parameter in die Länge ziehen ?
( Wir haben hier User die sich halbe Romane mit dem Modul vorlesen lassen )
Danke erstmal für die Unterstützung!
Ich habe noch ein paar Tests gemacht, je nach Text bricht die Wiedergabe an unterschiedlichen Stellen ab, mal 4 Sek, mal 7 Sek, mal 11 Sek. Aber, jetzt wird es interessant: Text x bricht immer nach y Sekunden ab, nie an unterschiedlichen stellen! Es macht auch keinen Unterschied ob ich den Text ins Reading schreibe oder direkt per set sip call mitgebe. Mit dem Wiederholungs Parameter kann ich mich auch ohne Probleme über 30 Sek vollquatschen lassen.
Ein paar Infos zu meinem System:
Ich nutze einen Intel NUC auf dem mehrere Docker Instanzen von FHEM laufen. Hierzu nutze ich das aktuelle Image von https://github.com/fhem/fhem-docker
Das Modul verbindet sich direkt mit den SIP Servern der Telekom, es ist keine eigene Anlage dazwischen geschaltet. Deshalb kann ich leider keinen Test mit internen Teilnehmern machen. Vielleicht komme ich die Tage dazu eine Telefonanlage einzurichten und dies mal zu testen.
cpan -D Net::SIP
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.822.tar.gz
/usr/local/share/perl/5.28.1/Net/SIP.pm
Installed: 0.822
CPAN: 0.822 up to date
perl -v
This is perl 5, version 28, subversion 1 (v5.28.1) built for x86_64-linux-gnu-thread-multi
rawdef:
defmod sip SIP
attr sip T2S_Device t2s
attr sip T2S_Timeout 15
attr sip audio_converter sox
attr sip history_file ./log/sip.sip
attr sip history_size 0
attr sip sip_audiofile_call !Hallo dies ist ein test ich hoffe ich komme über 11 sekunden *10
attr sip sip_call_audio_delay 0.75
attr sip sip_dtmf_loop once
attr sip sip_dtmf_send audio
attr sip sip_dtmf_size 2
attr sip sip_elbc yes
attr sip sip_from +********************
attr sip sip_ip *************
attr sip sip_listen none
attr sip sip_port 4060
attr sip sip_registrar tel.t-online.de
attr sip sip_ringtime 10
attr sip sip_user sip:*****************
setstate sip initialized
setstate sip 2020-01-24 12:56:48 call done
setstate sip 2020-01-24 12:56:48 call_attempt 0
setstate sip 2020-01-24 12:56:48 call_state timeout
setstate sip 2020-01-24 12:56:48 call_success 0
setstate sip 2020-01-24 12:56:48 call_time 26
setstate sip 2020-01-24 12:54:56 last_error audio file 10 not found
setstate sip 2020-01-24 02:41:27 listen_alive no
setstate sip 2020-01-24 12:56:48 state initialized
was da sofort auffällt und auch die Perl Fehler erklären könnte :
attr sip sip_from +********************
das sieht nicht SIP konform aus , sip:620@fritz.box sip:bla@fasel.com , etc
D.h. hier solltest du auch nochmal schauen wie dein Provider Telekom gern den Absender String hätte , finden sich im Netz ja bestimmt Beispiele für irgendwelche anderen SIP Phones.
So wenn ich dich nun richtig verstehe gelingt es dir eigentlich nie eine Audio Datei vollständig zu übertagen ?
Kannst aber den Ruf am Leben erhalten die dem du die unvollständige Datei mehrfach abspielst ?
Ich würde jetzt so weitermachen :
a. den sip_from anpassen und immer im Log schauen ob die Perl Warnings weg sind.
b. im Netz mal eine kleine mp3 Musik Datei suchen und diese versuchen zu übertragen
c. alternativ zu b. im Netz nach Anrufbeantworter Nachrichten suchen die gibt es oft auch schon als .alaw , besser man hat sie gleich als mp3 & .alaw
dann wäre die Fehlerquelle sox auch raus.
Zitat von: bennebartsch am 23 Januar 2020, 17:03:07
Ohne Komma hab ichs schon versucht, leider keine Besserung. Auch die mp3 Datei ist in Ordnung.
Edit2: Die .alaw Datei ist auch okay
Wie groß sind die beiden Dateien?
Änderung von sip_from macht leider keinen Unterschied, die Warnings bleiben.
Andere mp3 Dateien werde ich morgen mal probieren, danke!
Zitat von: plin am 24 Januar 2020, 17:30:07
Wie groß sind die beiden Dateien?
Alle lassen sich problemlos lokal abspielen.
-rw-r----- 1 fhem fhem 88K 23. Jan 16:10 034a2255a6836b5656e42d5bd695dbf3.alaw
-rw-r----- 1 fhem fhem 44K 23. Jan 16:10 034a2255a6836b5656e42d5bd695dbf3.mp3
-rw-r----- 1 fhem fhem 86K 30. Apr 2019 05a249ead294db15bfd0c964b126da9c.alaw
-rw-r----- 1 fhem fhem 43K 30. Apr 2019 05a249ead294db15bfd0c964b126da9c.mp3
-rw-r----- 1 fhem fhem 42K 30. Apr 2019 05c8a5a6a586fdae33d87245a14d04f5.alaw
-rw-r----- 1 fhem fhem 22K 30. Apr 2019 05c8a5a6a586fdae33d87245a14d04f5.mp3
-rw-r----- 1 fhem fhem 87K 30. Apr 2019 05e75e2f6994257ed63b32df0ad53109.alaw
-rw-r----- 1 fhem fhem 44K 30. Apr 2019 05e75e2f6994257ed63b32df0ad53109.mp3
Zitat von: Wzut am 24 Januar 2020, 14:45:06
was da sofort auffällt und auch die Perl Fehler erklären könnte :
attr sip sip_from +********************
das sieht nicht SIP konform aus , sip:620@fritz.box sip:bla@fasel.com , etc
D.h. hier solltest du auch nochmal schauen wie dein Provider Telekom gern den Absender String hätte , finden sich im Netz ja bestimmt Beispiele für irgendwelche anderen SIP Phones.
Das scheint laut https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true (https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true) so zu passen.
Außerdem würde ich die Probleme dann beim Verbindungsaufbau erwarten und nicht erst nach xx Sekunden.
@bennebartsch: Ich vermute Du sitzt in einem Netzwerk hinter einem Internet-Router?
@wzut: Bräuchte er eine Port-Freischaltung und Umleitung auf den SIP-Client?
Ich habe verschiedene Werte für sip_from versucht, alle funktionieren anscheinend. Hatte die +49 auch aus dieser Diskussion "geklaut". Denke auch nicht das es daran liegt, entweder man ist authentifiziert oder halt nicht.
Zitat von: plin am 25 Januar 2020, 10:18:08
@bennebartsch: Ich vermute Du sitzt in einem Netzwerk hinter einem Internet-Router?
@wzut: Bräuchte er eine Port-Freischaltung und Umleitung auf den SIP-Client?
Ja richtig, ich sitze hinter einem Speedport Hybrid. In diesem sind Ausnahmeregelungen definiert, die SIP Traffic nur über die DSL Leitung schicken. Habe es aber auch schon mit LTE komplett deaktiviert getestet, leider keine Änderung. Mit/Ohne Port-Freischaltung macht auch keinen Unterschied.
Zitat von: plin am 25 Januar 2020, 10:18:08
@wzut: Bräuchte er eine Port-Freischaltung und Umleitung auf den SIP-Client?
IMHO nein. Zumindest als ich die Versuche mit sipgate.de gemacht habe hatte ich keine bei mir drin. Trotzdem ist das SIP Phone von aussen auch anrufbar, da es ja selbst die registar Verbindung hergestellt hat ( D.h. hier beim Modul durch den aktiven listen Mode )
Hallo zusammen,
ich hoffe ich bin richtig hier mit meinem Problem.
Bisher habe ich sehr erfolgreich das SIP Modul zusammen mit einem Raspberry Pi und "Debian" Jessie genutzt.
Bedingt durch einen Systemausfall muss ich mein System neu aufsetzen. Glücklicherweise konnte ich beim FHEM Backup nutzen und musste daher nicht alles neu anlegen.
Nun nutze ich Debian Buster zusammen mit Fhem auf einer VM.
Jetzt aber zu meinem Problem:
Ich bekomme seit dem Umzug keine Verbindung mehr zur Telefonanlage (FreePBX/Asterisk).
Die Fehlermeldungen sind dürftig. (Error 110)
Ich habe alle Einstellungen übernommen. Telefonanlage läuft einwandfrei und lässt sich auch mit anderen SIP-Clients ansprechen.
Von daher gehe ich entweder von einem Problem im Zusammenspiel von FHEM zu Debian Buster aus oder von Debian zur Telefonanlage.
Net::SIP habe ich per CPAN installiert.
Im Anhang habe ich mal meine Attribute angehangen. Zusätzlich hier noch der Ausschnitt aus der Logfile:
2020-01-25 22:53:34 SIP System.Dienst.Sip call_state: invite
2020-01-25 22:53:34 SIP System.Dienst.Sip call: 703
2020-01-25 22:54:36 SIP System.Dienst.Sip call: done
2020-01-25 22:54:36 SIP System.Dienst.Sip call_time: 0
2020-01-25 22:54:36 SIP System.Dienst.Sip last_error: CallRegister: Failed with error 110
2020-01-25 22:54:36 SIP System.Dienst.Sip call_state: fail
2020-01-25 22:54:36 SIP System.Dienst.Sip call_success: 0
2020-01-25 22:54:36 SIP System.Dienst.Sip call_attempt: 0
2020-01-25 22:54:36 SIP System.Dienst.Sip initialized
Kann mir jemand noch ein paar Tipps geben, wo ich den Fehler weiter eingrenzen kann?
Bzw. hat jemand ähnliche Probleme gehabt?
Besten Dank...
Gruß Tobias
den Fehler 110 hatten wir hier schon öfters, das SIP Modul kann nicht mit der PBX reden. Bei den Docker Usern lag es immer an irgendwelchen Ports die von A nach B nicht durchkamen. Keine Ahnung wie das bei deiner VM ausschaut. Firewall in irgend einer Form ?
Du verwendest ja unterschiedliche Sub Netze ( 172.20.10.x & 172.20.16 ) , wer kümmert sich um das Routing zwischen den Netzen ?
Hattest vor deinem Umzug das auch schon auf einer VM laufen ?
Hallo,
das Routing übernimmt eine Sophos Firewall.
Ich habe testweise die VM direkt in das gleiche Netz gehangen, wie die TK Anlage.
Also mit 172.20.16.x IP.
Jetzt bekomme ich nach dem call Befehl die Fehlermeldung ,,Can't open Port 5080 on 172.20.16.x"
Das ganze ist sehr merkwürdig weil ich nach Attribut den Port 5060 nutze.
Ändere ich diese Einstellung auf Port 5080 dann kommt die gleiche Meldung mit dem Hinweis dass Port 5100 nicht geöffnet werden kann.
Die Trennung der Netzte hatte ich vorher schon.
Fhem lief da aber noch auf einem Raspberry Pi.
Gruß Tobias
Zitat von: Tobbi am 26 Januar 2020, 12:17:21
Jetzt bekomme ich nach dem call Befehl die Fehlermeldung ,,Can't open Port 5080 on 172.20.16.x"
Das ganze ist sehr merkwürdig weil ich nach Attribut den Port 5060 nutze.
nein das ist nicht merkwürdig, es wird mehr als ein Port benötigt , das Attribut legt die Basis fest und dann geht es in 10er Schritten weiter.
Das ist aber erst der Anfang, sprich Rufaufbau. Wenn die Verbindung steht und es soll Audio übertragen werden kommt nochmal was dazu, hatten wir hier schon mal, das war irgendwo in den Tiefen von Net::SIP saublöd vergraben.
(@plin erinnerst dich noch an diese Monster Range ? den Punkt haben wir glaube ich auch nie im Wiki verewigt ? )
Zitat von: Wzut am 26 Januar 2020, 13:03:51
(@plin erinnerst dich noch an diese Monster Range ? den Punkt haben wir glaube ich auch nie im Wiki verewigt ? )
Ich glaube indirekt haben wir's doch im Wiki verewigt, bei der Nutzung von docker:
docker run -d -p 7072:7072 -p 8083:8083 -p 5060:5060 -p 5070:5070 -p 2000-2019:2000-2019 fhem/fhem
Da taucht noch eine Port-Range 2000-2019 auf.
hmm IMHO war die aber im Urzustand größer und der User hatte sie auf unseren Rat verkleinert weil er nicht hunderte von Ports via Rule in seiner Firewall zuweisen wollte.
Ich setze mich heute Mittag nochmal hin und suche den Teil hier im Thread
Edit : gefunden 17 Mai 2018 -> https://forum.fhem.de/index.php/topic,67443.msg802980.html#msg802980
Default ist UDP Port 2000 - 12000 für RTP :(
Hi,
ich brauche leider etwas Unterstützung:
folgender Usecase:
1. SIP-Türsprechstelle klingelt auf allen internen Telefonen, funktioniert auch, allerdings werden interne Anrufe nicht geloggt in der Fritzbox.
2. Raspi mit SIP Modul, allerdings ohne T2S Modul soll Anrufsignalisierung der TFE (Gruppenruf) loggen und ggf. eine Pushover Nachricht senden.
Das Modul läuft soweit und macht auch das was es soll bis auf die Tatsache, dass Anrufe durch den raspi nach 3 maligen ringing entgegen genommen werden und kurz bevor der Call durch den pi beendet wird, erhalte ich noch einen komischen Ton im Telefon.
sip_listen ist auf wfp gesetzt und ich hatte den state so verstanden, dass der pi nur "lauscht" und darauf wartet das man eine "action" ausführt. Irgendwie scheint der Pi hier selber tätig zu werden :-?
Danke und Gruß Christ
Zitat von: bown am 01 Februar 2020, 20:14:24
Hi,
ich brauche leider etwas Unterstützung:
folgender Usecase:
1. SIP-Türsprechstelle klingelt auf allen internen Telefonen, funktioniert auch, allerdings werden interne Anrufe nicht geloggt in der Fritzbox.
2. Raspi mit SIP Modul, allerdings ohne T2S Modul soll Anrufsignalisierung der TFE (Gruppenruf) loggen und ggf. eine Pushover Nachricht senden.
Das Modul läuft soweit und macht auch das was es soll bis auf die Tatsache, dass Anrufe durch den raspi nach 3 maligen ringing entgegen genommen werden und kurz bevor der Call durch den pi beendet wird, erhalte ich noch einen komischen Ton im Telefon.
sip_listen ist auf wfp gesetzt und ich hatte den state so verstanden, dass der pi nur "lauscht" und darauf wartet das man eine "action" ausführt. Irgendwie scheint der Pi hier selber tätig zu werden :-?
Danke und Gruß Christ
Wie fängst Du den Call ab bzw. erkennst ihn? Notify oder DOIF? Kannst Du uns den Command anlisten. Falls Du den Call mit 'fetch' annimmst wird das hinterlegte Audiofile abgespielt.
ich habe da eher den Verdacht das er sip_waittime gesetzt hat :
Zitatsip_waittime
Maximale Wartezeit im Status listen_for_wfp bis das Gespräch automatisch angenommen wird.
aber wie so oft : warum müssen wir raten , ist es so schwer ein list zu posten ?
Zitat von: Wzut am 26 Januar 2020, 13:45:27
hmm IMHO war die aber im Urzustand größer und der User hatte sie auf unseren Rat verkleinert weil er nicht hunderte von Ports via Rule in seiner Firewall zuweisen wollte.
Ich setze mich heute Mittag nochmal hin und suche den Teil hier im Thread
Edit : gefunden 17 Mai 2018 -> https://forum.fhem.de/index.php/topic,67443.msg802980.html#msg802980
Default ist UDP Port 2000 - 12000 für RTP :(
Ich habe die letzten Tage noch einige Stellschrauben gedreht.
Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.
So ganz bin ich dem Thema nicht auf die Schliche gekommen.
Es liegt aber wohl an der Netzwerkkonfiguration.
Gruß Tobias
Zitat von: Tobbi am 02 Februar 2020, 19:09:39
Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.
OK, da must du mit deiner Firewall klar kommen , aber was macht das Port Thema ?
Zitat von: Tobbi am 02 Februar 2020, 19:09:39
Ich habe die letzten Tage noch einige Stellschrauben gedreht.
Es scheint tatsächlich Probleme mit dem Routing zwischen den Netzwerken zu geben.
So ganz bin ich dem Thema nicht auf die Schliche gekommen.
Es liegt aber wohl an der Netzwerkkonfiguration.
Gruß Tobias
Um das Problem auf der docker-Seite ein- bzw. auszugrenzen könntest Du den docker container mit der option
--net=host statt expliziten Port-Freigaben starten. Dann siehst Du zumindest, ob's an dem Übergang in den container und den freigeschalteten Port-Ranges oder an der FW liegt.
Zitat von: Wzut am 02 Februar 2020, 19:35:07
OK, da must du mit deiner Firewall klar kommen , aber was macht das Port Thema ?
Ja das stimmt.
Es scheint so, als wenn iptables Problem mit den UDP Paketen gehabt hat. Also zumindest auf der Schnittstelle, die direkt zum TK Server gehen. Habe eine Ausnahme hinzugefügt und es klappte auf Anhieb.
Das vorherige Problem scheint in der Netzwerkfirewall zu liegen. Also Modul läuft wie aus der Vergangenheit bekannt.
@Plin: Danke für deinen Tipp. Ich nutze allerdings eine VMware Umgebung. Daher kommt der Tipp für mich leider nicht in Frage.
Wie zuvor schon erwähnt, schätze ich dass die Probleme in der Netzwerkfirewall liegen.
Zitat von: plin am 01 Februar 2020, 20:27:26
Wie fängst Du den Call ab bzw. erkennst ihn? Notify oder DOIF? Kannst Du uns den Command anlisten. Falls Du den Call mit 'fetch' annimmst wird das hinterlegte Audiofile abgespielt.
Hi, noch habe ich kein notify oder DOIF gebaut. Darum sollte der Raspi doch noch keiner keinerlei Aktionen durchführen, oder?
Anbei ein List:
Internals:
FUUID 5e35ae1e-f33f-2825-987d-32a997d8d21297b4
LPID 892
NAME mySIP
NOTIFYDEV global
NR 160
NTFY_ORDER 50-mySIP
STATE listen_wfp
TYPE SIP
VERSION V1.91 / 31.07.18
callnr 015154705706
forcecall 0
repeat 0
ringtime 30
READINGS:
2020-02-01 19:48:44 call done
2020-02-01 19:48:44 call_attempt 0
2020-02-01 19:48:44 call_state canceled
2020-02-01 19:48:44 call_success 0
2020-02-01 19:48:44 call_time 0
2020-02-03 10:39:54 caller none
2020-02-03 10:39:54 caller_name ---
2020-02-03 10:39:54 caller_nr ---
2020-02-03 10:39:54 caller_state hangup
2020-02-03 10:39:54 caller_time 0
2020-02-03 12:10:04 expire 300
2020-02-03 12:10:04 listen_alive 892
2020-02-03 12:10:04 state listen_wfp
helper:
CALL_BYE canceled
CALL_ERROR 1
CALL_NAME unknown
CALL_NR done
CALL_START 1580582923
CALL_TIME 0
CALL_TYPE out
LISTEN_PID:
abortArg
abortFn
arg mySIP
bc_pid 19
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 892
timeout
Attributes:
history_file ./log/mySIP.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:raspiSIP@fritz.box
sip_ip 192.168.0.150
sip_listen wfp
sip_registrar 192.168.0.1
sip_ringtime 30
sip_user raspiSIP
Zitat von: bown am 03 Februar 2020, 12:14:24
Darum sollte der Raspi doch noch keiner keinerlei Aktionen durchführen, oder?
eigentlich nein, aber du bist wie ich vermutet habe in die sip_waittime Falle getappt.
D.h. du hast es nicht gesetzt aber dann wird der default Wert von 10 Sekunden genommen.
Lösung : setzte sip_waittime auf einen hohen Wert wie z.B. 60 oder 120
Zitat von: Wzut am 03 Februar 2020, 12:32:50
eigentlich nein, aber du bist wie ich vermutet habe in die sip_waittime Falle getappt.
D.h. du hast es nicht gesetzt aber dann wird der default Wert von 10 Sekunden genommen.
Lösung : setzte sip_waittime auf einen hohen Wert wie z.B. 60 oder 120
Vielen Dank für den Lösungsansatz! Ich werde die Werte verändern und testen.
Gruß Chris
Mal eine Frage in die User Runde :
Wie sind eure Erfahrungen mit dem Modul unter buster ?
bzw. wer kann mir sagen welche Version von Net::SIP mit buster ausgeliefert wird ?
Ich lese hier im Forum so teilweise zwischen den Zeilen das sich wohl der Unterbau Net::SIP inzwischen an einigen Stellen anders verhält als früher unter stretch.
Hi!
Ich habe zwar kein Debian, aber auf meinem (aktuellen) Gentoo habe ich Net::SIP 0.822 und damit läuft alles einwandfrei!
BTW:
Könntest du bitte noch das "ps -e" durch den perl kill ersetzen?
Siehe: https://forum.fhem.de/index.php/topic,67443.msg998094.html#msg998094 (https://forum.fhem.de/index.php/topic,67443.msg998094.html#msg998094)
LG,
Stephan.
Hi,
Gestern Buster installiert, gerade das SIP-Modul. Einwandfrei.
Installierte Version via apt-get: libnet-sip-perl/stable,now 0.820-1 all [installed]
VG Tom
Zitat von: loescher am 30 November 2019, 21:31:40
Ich hatte vor ein paar Monaten in diesem Thread eine kleine Verbesserung bzgl. "ps" vorgeschlagen.
Beim heutigen Update habe ich aber gesehen, dass du das noch nicht übernommen hast.
Bedingt durch die aktuelle Situation mit viel mehr Freizeit als gewöhnlich :
Ist eingecheckt und die commanref etwas umgestellt (direkte Ausgabe der Attribut Hilfetexte in der Detail Ansicht)
Super! Vielen Dank!
LG,
Stephan.
HAllo Wzut,
ichhabe aktuell das "Problem", dass das Modul auf einem raspberry (Buster) mit der Eingabe des Hostnamen funktioniert (hier die Definition)
defmod FB_SIP SIP
attr FB_SIP T2S_Device FhemT2S
attr FB_SIP audio_converter sox
attr FB_SIP devStateIcon initialized:it_telephone@black calling:phone_ring_out@black
attr FB_SIP devStateStyle style="text-align:right"
attr FB_SIP group SIP
attr FB_SIP history_file ./log/FB_SIP.sip
attr FB_SIP history_size 0
attr FB_SIP icon it_telephone@black
attr FB_SIP room SIP
attr FB_SIP sip_dtmf_loop once
attr FB_SIP sip_dtmf_send audio
attr FB_SIP sip_dtmf_size 2
attr FB_SIP sip_elbc no
attr FB_SIP sip_from sip:FHEM-SIP@fritz.box
attr FB_SIP sip_ip raspberrypi
attr FB_SIP sip_listen none
attr FB_SIP sip_registrar fritz.box
attr FB_SIP sip_ringtime 10
attr FB_SIP sip_user FHEM-SIP
und auf dem zweiten raspberry (ebenfalls mit Buster) nur die Eingabe einer IP-Adresse hilft. Auch hier die Definition
defmod FB_SIP SIP
attr FB_SIP T2S_Device FhemT2S
attr FB_SIP audio_converter sox
attr FB_SIP devStateIcon initialized:it_telephone@black calling:phone_ring_out@black
attr FB_SIP devStateStyle style="text-align:right"
attr FB_SIP group SIP
attr FB_SIP history_file ./log/FB_SIP.sip
attr FB_SIP history_size 0
attr FB_SIP icon it_telephone@black
attr FB_SIP room SIP
attr FB_SIP sip_dtmf_loop once
attr FB_SIP sip_dtmf_send audio
attr FB_SIP sip_dtmf_size 2
attr FB_SIP sip_elbc no
attr FB_SIP sip_from sip:FHEM-SIP@fritz.box
attr FB_SIP sip_ip 192.168.70.61
attr FB_SIP sip_listen none
attr FB_SIP sip_registrar fritz.box
attr FB_SIP sip_ringtime 10
attr FB_SIP sip_user FHEM-SIP
Bei der Eingabe des Hostnamen "raspberrypi3b" erhalte ich die Meldung
Can't use string ("0") as an ARRAY ref while "strict refs" in use at /usr/share/perl5/Net/SIP/Dispatcher.pm line 910.
Viele Grüße
Jürgen
Das Attribut hat aus gutem Grund den Namen sip_ip ..... denn es erfordert eine IP und kein Namen !
Hintergrund ist das ein System mehrere Interfaces haben kann und der SIP Registrar (bei dir die FB) addressiert so sein Ziel.
Ich selbst habe auch noch nie versucht an der Stelle einen Namen einzutragen, werd ich wohl beim nächsten Update eine Prüfung auf echte IP einbauen,
Danke für die Info. Ich habe nun überall die IP-Adresse eingetragen.
Eine Erweiterung auf den Host-Namen wäre aber nicht schlecht. Wäre mal ein Wunsch 8)
Viele Grüße
Jürgen
dann must du den Wunsch an Steffen Ullrich richten , den Autor von Net::SIP.
Deine Fehlermeldung zeigt ja das Dispatcher.pm keinen Namen mag :)
Hallo,
habe heute diese Fehlermeldung nach einem Update gefunden:
2020.05.16 20:01:23 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2020.05.16 20:01:23 2: FB_SIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.
Habe ich vergessen etwas zu definieren?
Viele Grüße
Jürgen
Hast du denn das Attribut sip_ip richtig gesetzt ?
An der Stelle wird versucht bei fehlendem Attribut die IP automatisch zu erkennen, aber das schlug bei dir dann auch fehl.
Ja, IP-Adresse ist aus meiner Sicht korrekt gesetzt.
Hier meine Definition:
defmod FB_SIP SIP
attr FB_SIP T2S_Device FhemT2S
attr FB_SIP audio_converter sox
attr FB_SIP devStateIcon initialized:it_telephone@black calling:phone_ring_out@black
attr FB_SIP devStateStyle style="text-align:right"
attr FB_SIP group SIP
attr FB_SIP history_file ./log/FB_SIP.sip
attr FB_SIP history_size 0
attr FB_SIP icon it_telephone@black
attr FB_SIP room SIP
attr FB_SIP sip_dtmf_loop once
attr FB_SIP sip_dtmf_send audio
attr FB_SIP sip_dtmf_size 2
attr FB_SIP sip_elbc no
attr FB_SIP sip_from sip:FHEM-SIP@fritz.box
attr FB_SIP sip_ip 192.168.70.61
attr FB_SIP sip_listen none
attr FB_SIP sip_registrar fritz.box
attr FB_SIP sip_ringtime 10
attr FB_SIP sip_user FHEM-SIP
Es funktioniert ja auch.
Viele Grüße
Jürgen
Hallo Wzut,
ich nutze schon länger Debian 10 und habe beim SIP-Modul keine Aufälligkeiten gemerkt.
Ich nutze das Modul bisher, um meine Telefone beim Haustürklingeln zusätzlich läuten zu lassen.
Mich hat folgendes aus dem Wiki-Beitrag neugierig gemacht:
ZitatNervende Werbeanrufe
Ihr kennt das sicher: Unbekannte Rufnummer, man nimmt das Gespräch an und hat entweder irgendwas gewonnen, einen Werber oder ein "Umfrage" dran. Unterm Strich - man will Dir was verkaufen.
Phase 1: Fritzbox, Rufbehandlung, neue Rufnummernsperre, Nummer eintragen.
Phase 2: Derselbe Werber taucht unter einem ganzen Kontingent von Rufnummern auf. Blocken alleine reicht dir nicht mehr, du willst Rache.
Phase 3:
Du definierst in FHEM den SIP-Client und startest ihn im listen-Modus echo.
In der Fritzbox leitest du alle eingehenden Anrufe auch an den SIP-Client weiter.
Dem SIP-Client gibst du über sip_filter die Werber-Rufnummer als Filterarguiment mit.
Der SIP-Cleint ist schneller als die Familienmitglieder und nimmt den Anruf an.
Phase 4: Jetzt bin ich (der Autor dieses Anwendungsfalles) neugierig. Postet Eure Erfahrung mit diesem Modus gerne im Forums-Thread.
Ich würde gerne die Phase 3 einleiten, bräuchte aber noch ein wenig Beratung.
Ich gehe davon aus, dass es klingelt, aber nur kurz, weil der SIP-Client das Telefonat annimmt und den Anrufer beharrlich anschweigt - wie lustig :) oder hört der dann sein Echo wie bei einer schlechten Leitung? Noch lustiger :) :). Als Angerufener kriegt man das meistens nicht hin, oder andere zeitraubende Strategien, wie z.B. Nachschauen, ob der Angerufene da ist (dauert 1 Minute) ... ja, ist da ..., dann sich das Anliegen schildern lassen und es dem Angerufenen übermitteln (dauert wieder 1 Minute) ... und so weiter, finde ich auch lustig, habe ich aber noch nie geschafft, man ist einfach nicht darauf vorbereitet.
Wie verhält es sich mit normalen Anrufen? Gibt es eine Zeitverzögerung, bis die normalen Telefone klingeln?
ZitatIn der Fritzbox leitest du alle eingehenden Anrufe auch an den SIP-Client weiter.
Ich nehme an, dass es sich um die Rufumleitung (als Parallelanruf) handelt. Eine Zeitverzögerung sollte es dann nicht geben, da alle Telefone klingeln, aber der SIP-Client ist schneller dran als jeder Mensch.
Wenn ich in Phase 4 bin, werde ich pflichtschuldigst über meine Erfahrungen berichten - ich freue mich jetzt schon wie ein Schneekönig :).
Viele Grüße Gisbert
Zitat von: Gisbert am 26 Juli 2020, 13:26:46
Ich gehe davon aus, dass es klingelt, aber nur kurz
Bei mir nicht , der SIP Client ist so schnell das die normalen Telefone nicht zum klingeln kommen :)
Zitat von: Wzut am 26 Juli 2020, 14:15:37
Bei mir nicht , der SIP Client ist so schnell das die normalen Telefone nicht zum klingeln kommen :)
Hallo Wzut,
ich hab den Werbeblocker eingerichtet und getestet (mit meiner Mobilfunknummer), man hört das eigene Echo, sehr cool 8).
Mit sip_ringtime 0.1 bekomme ich kein Klingeln bei den normalen Telefonen, d.h. man bekommt dann in der Regel nichts von den Werbeanrufen auf der white-list mit.
Da ich noch einen Callmonitor habe, kann ich sehen, nach welcher Zeit diese korrupte Bande aufgegeben hat.
Vermutlich werden Sie diese Methode kennen und legen dann rasch auf.
Was passiert eigentlich, wenn die Gegenseite nicht auflegt?
Ist dann meine Rufnummer blockiert, bis aufgelegt wurde?
Ich denke, dass das nicht lange dauern wird, aber nur für den Fall der Fälle, kann der SIP-Client ein laufendes Telefonat selbst beenden?
Was müsste ich tun?
Viele Grüße Gisbert
Hallo Wzut,
ich hatte die ganze Zeit noch vergessen zu fragen, ob man auch mit der Methode Anrufe mit unterdrückter Nummer zum SIP-Client umbiegen kann.
Ich habe in sip_filter als Nummer ein Leerzeichen, gefolgt von einem Komma (und dann die weiteren Werbenummern) eingetragen.
Ist das der beste Weg, oder gibt es noch andere Tricks?
Viele Grüße Gisbert
k.A. da muß plin was dazu sagen, von ihm ist auch der Abschnitt im Wiki
Den Filter habe ich auch noch nie mit unterdrückter Rufnummer getestet, also auch kein Plan ob der dann überhaupt greift.
Hallo Gisbert,
Zitat von: Gisbert am 26 Juli 2020, 17:48:19
ich hatte die ganze Zeit noch vergessen zu fragen, ob man auch mit der Methode Anrufe mit unterdrückter Nummer zum SIP-Client umbiegen kann.
da muss ich mich ein wenig in puncto gesetzten und nicht gesetzten Readings schlau machen (=testen).
Zitat von: Gisbert am 26 Juli 2020, 17:48:19
Ich habe in sip_filter als Nummer ein Leerzeichen, gefolgt von einem Komma (und dann die weiteren Werbenummern) eingetragen.
Den Werbeanrufern habe ich in meiner Fritzbox ein eigenes Telefonbuch und eine eigene Voice-Mailbox gegönnt. Diese 2. Voice-Mailbox nimmt die Anrufe aller im Telefonbuch SPAM gelisteten Kontakte entgegen. Da gibt es dann noch eine freundliche Ansage "Sie wurden als Werbeanruf erkannt ...". Jede neue zu blockende Nummer kriegt einen Eintrag im SPAM-Telefonbuch. Das geht ganz einfach.
Ciao
Peter
Hallo Gisbert,
ich habe heute einen Test mit unterdrückter Rufnummer durchgeführt. Im Log erscheint:
2020.08.02 17:26:53 5: SipTest[3604], SIP_filter : <sip:anonymous@fritz.box>;tag=1C8666642B926E94
2020.08.02 17:26:53 4: SipTest[3604], SIP_filter: caller sip:anonymous@fritz.box, caller_nr anonymous, caller_name
2020.08.02 17:26:53 5: SipTest, readingB:caller Val:sip:anonymous@fritz.box
2020.08.02 17:26:53 5: SipTest, readingB:caller_nr Val:anonymous
2020.08.02 17:26:53 5: SipTest, readingB:caller_name Val:unknown
2020.08.02 17:26:53 5: SipTest, readingB:caller_time Val:0
2020.08.02 17:26:53 5: SipTest, readingB:caller_state Val:calling
Ich habe dann anonymous in sip_filter eingetragen. Die unbekannten Anrufer führen wieder zu Merldungen 'ringing n', während Anrufe mit bekannter Rufnummer gesehen aber ignoriert werden.
VG Peter
Zitat von: plin am 26 Juli 2020, 18:37:29
Den Werbeanrufern habe ich in meiner Fritzbox ein eigenes Telefonbuch und eine eigene Voice-Mailbox gegönnt. Diese 2. Voice-Mailbox nimmt die Anrufe aller im Telefonbuch SPAM gelisteten Kontakte entgegen. Da gibt es dann noch eine freundliche Ansage "Sie wurden als Werbeanruf erkannt ...". Jede neue zu blockende Nummer kriegt einen Eintrag im SPAM-Telefonbuch. Das geht ganz einfach.
Mein Problem ist z.Zt. das John, Robert oder Thomas von Microsoft täglich mehrmals bei uns anruft. Leider benutzen die Scammer unterschiedliche "Fake" Telefonnummern. Vor einigen Monaten begannen diese (deutschen Vorwahlnummern) alle mit 04, so das ich temporär einfach diesen Nummern Block in der Fritzbox gesperrt hatte. Nun aber mit 09, 05 ... sprich quasi alles. Ein Sperren oder ein Eintrag in ein Spam Adressbuch funktioniert leider so nicht mehr zielführend.
Mit schwebt nun folgendes vor.
1.) Raspberry als SIP in der Fritzbox nimmt Anruf nach 0 sec (also sofort) entgegen.
2 a.) ist die Telefonummer in der Fritzbox im "normalen" Telefonbuch (nicht Spam Telefonbuch), dann
3. klingeln die "richtigen" Telefone (ohne Raspberry) und der Anruf kann entgegen genommen werden. (Anrufweiterleitung?)
2 b.) ist der Anrufer unbekannt dann Bandansage mit Aufforderung eine Taste zu drücken "Was ergibt 4+3? Drücken sie # und diese Taste"
3.) Anrufer drückt #7 --> erst jetzt klingeln die "richtigen" Telefone.
Wäre so etwas zu realisieren?
Mit einer echten PBX wie Asterisk bestimmt, aber das SIP Modul ist dafür garantiert das falsche Werkzeug
Zitat von: Wzut am 11 August 2020, 18:56:57
Mit einer echten PBX wie Asterisk bestimmt, aber das SIP Modul ist dafür garantiert das falsche Werkzeug
mmhh, im SIP-Modul nicht, wohl aber in FHEM. Das SIP-Modul wird mit listen_wfp gestartet. Als Ansagetext ist etwas in der Art "Sie rufen von einer unbekannten Nummer an" hinterlegt. Kommt ein Anruf rein, werden die Readings caller, caller_name und caller_nr gesetzt:
caller im Format
Name sip:nummer@fritz.boxcaller_name
Namecaller_nr
nummerEin kurzer Test mit einem nicht im Telefonbuch hinterlegten Handy zeigt caller_name
unknown.Man könnte in FHEM ein DOIF-Device anlegen das bei caller_name "unknown" das Telefonat mittels "fetch" annimmt. So etwas in der Art
define ACT_ON_unknown DOIF (([FritzSipClient:caller_state] eq "ringing 1") and ([FritzSipClient:caller_name] eq "unknown")) (set FritzSipClient fetch)
Und dann fehlt noch die Anweisung an die Familie bei unbekannten Rufnummern erst mal klingeln lassen
@Peter, klar mit wfp geht so manches ( ist ja sowieso dein Baby :) ) aber ich sehe da noch nicht die Umsetzung seiner Punkte 2b & 3
Bzw. wie ein bereits angenommen Ruf wieder als neue ausgehende Verbindung aufbauen ?
Ich bin mir ziemlich sicher das Steffen Ullrich als er sein Net::SIP schrieb nicht im Traum daran gedacht hat was wir inzwischen unter FHEM damit treiben.
Aber ich denke wenn man ihm das irgendwie alles vollständig rüber bringen könnte, dann wären für ihn bestimmt auch Punkte wie Verbinden oder Soundumleitung (Stichwort Türsprechstelle) umsetzbar.
Danke für die Info's. PBX Asterisk mit IVR (Interactive Voice Response) war mir bis gestern noch unbekannt.
Zitat von: plin am 11 August 2020, 20:59:46
Und dann fehlt noch die Anweisung an die Familie bei unbekannten Rufnummern erst mal klingeln lassen
es gibt doch sicherlich auch eine möglichkeit, das klingeln erst einzuschalten, wenn es sich lohnt. ;)
Zitat von: Wzut am 12 August 2020, 09:21:07
@Peter, klar mit wfp geht so manches ( ist ja sowieso dein Baby :) ) aber ich sehe da noch nicht die Umsetzung seiner Punkte 2b & 3
Bzw. wie ein bereits angenommen Ruf wieder als neue ausgehende Verbindung aufbauen ?
ja, das war ein erster Wurf - quasi als "Ansatz" gedacht.
Konkret:
1) wenn das SIP-Modul das Telefonat entgegen nimmt ist es für die anderen Telefone weg. Also muss man nur schauen wenn anruft und aktiv entscheiden, ob das SIP-Modul annimmt oder nicht.
2a) Das könnte man lösen, indem alle Namen im SPAM-Telefonbuch z.B. mit "SPAM-" beginnen. Wenn der caller_name SPAM-.* oder "unknown" ist nimmt der SIP-Client an.
3. Das erfordet dann wirklich eine Änderung am NET::SIP oder Asterisk. DOIF sollte aber (hoffentlich) schnell genug sein und beim ersten Klingeln reagieren. Dann kann der eingehende Anruf direkt an alle relevanten Telefone weitergeleitet werden.
2b/3.) Hier würde ich tatsächlich auf Asterisk setzen. (siehe mein nächstes Posting im Thread).
Mit dem SIP-Modul und FHEM hat man also einen Baukasten mit dem man rumspielen kann. Ein paar Kompromisse muss man eingehen, aber man kriegt einiges hin.
Ciao, Peter
Zitat von: aHome77 am 12 August 2020, 10:33:27
Danke für die Info's. PBX Asterisk mit IVR (Interactive Voice Response) war mir bis gestern noch unbekannt.
So hat's bei mir angefangen. Anrufe unbekannter Teilernehmer werden angenommen, der Automat sagt "Willkommen bei Familie .." und geht in eine Schleife "mit wem möchten Sie sprechen? 1 für Peter, 2 für Eva oder 3 für Anna? Bei Peterkommt die Rückfrage "Wollen sie mit Peter persönlich sprechen oder kann auch ein anderes Familienmitglied helfen?" ("spreche ich mit "Peter persönlich?" war bei Werbeanruferns damals sehr beliebt). Erst dann wurde der Anrufer an mich durchgestellt.
Mit Asterisk geht so etwas. Mittlerweile gibt's das auch als docker image.
Zitat von: frank am 12 August 2020, 11:08:34
es gibt doch sicherlich auch eine möglichkeit, das klingeln erst einzuschalten, wenn es sich lohnt. ;)
Das muss dann ein Feature der Fritzbox sein das man über die API einschalten kann ...
Zitat von: plin am 11 August 2020, 20:59:46
define ACT_ON_unknown DOIF (([FritzSipClient:caller_state] eq "ringing 1") and ([FritzSipClient:caller_name] eq "unknown")) (set FritzSipClient fetch)
Alle 2,5 min (150sec) taucht jetzt folgendes im LOG File auf:
2020.08.13 12:08:18.604 1: readingsUpdate(,expire,300) missed to call readingsBeginUpdate first.
2020.08.13 12:08:18.604 1: stacktrace:
2020.08.13 12:08:18.604 1: main::readingsBulkUpdate called by ./FHEM/96_SIP.pm (1933)
2020.08.13 12:08:18.604 1: main::SIP_rBU called by (eval 4554788) (1)
2020.08.13 12:08:18.604 1: (eval) called by fhem.pl (1149)
2020.08.13 12:08:18.605 1: main::AnalyzePerlCommand called by fhem.pl (1178)
2020.08.13 12:08:18.605 1: main::AnalyzeCommand called by fhem.pl (1105)
2020.08.13 12:08:18.605 1: main::AnalyzeCommandChain called by ./FHEM/98_telnet.pm (255)
2020.08.13 12:08:18.605 1: main::telnet_Read called by fhem.pl (3806)
2020.08.13 12:08:18.605 1: main::CallFn called by fhem.pl (762)
An was könnte dies liegen?
SIP Device ohne listen mode ? List vom Device zeigen
Ich denke das Problem lag daran, dass ich mein SIP Device umbenannt habe. Habe dann danach das Passwort nochmal gesetzt. Fehler sind jetzt weg.
defmod FritzboxSipClient SIP
attr FritzboxSipClient DbLogExclude .*
attr FritzboxSipClient T2S_Device myText2spech
attr FritzboxSipClient T2S_Timeout 60
attr FritzboxSipClient alias SIP Client
attr FritzboxSipClient audio_converter sox
attr FritzboxSipClient disabled 1
attr FritzboxSipClient group Telefonie
attr FritzboxSipClient history_file ./log/SIP_phone.sip
attr FritzboxSipClient history_size 0
attr FritzboxSipClient room Fritzbox
attr FritzboxSipClient sip_audiofile_call !Zur Zeit können keine Anrufe angenommen werden
attr FritzboxSipClient sip_audiofile_dtmf !Hallo lieber John, Robert oder Thomas von Microsoft
attr FritzboxSipClient sip_audiofile_wfp !Hello my friend from Microsoft
attr FritzboxSipClient sip_dtmf_loop once
attr FritzboxSipClient sip_dtmf_send audio
attr FritzboxSipClient sip_dtmf_size 2
attr FritzboxSipClient sip_elbc yes
attr FritzboxSipClient sip_from sip:raspi@fritz.box
attr FritzboxSipClient sip_ip 192.168.178.111
attr FritzboxSipClient sip_listen echo
attr FritzboxSipClient sip_registrar fritz.box
attr FritzboxSipClient sip_ringtime 3
attr FritzboxSipClient sip_user raspiSIP
setstate FritzboxSipClient listen_echo
setstate FritzboxSipClient 2019-01-26 22:16:18 call done
setstate FritzboxSipClient 2019-01-26 22:16:18 call_attempt 4
setstate FritzboxSipClient 2019-01-26 22:16:18 call_state ok
setstate FritzboxSipClient 2019-01-26 22:16:18 call_success 1
setstate FritzboxSipClient 2019-01-26 22:16:18 call_time 4
setstate FritzboxSipClient 2020-08-14 09:36:18 caller none
setstate FritzboxSipClient 2020-08-14 09:36:18 caller_name ---
setstate FritzboxSipClient 2020-08-14 09:36:18 caller_nr ---
setstate FritzboxSipClient 2020-08-14 09:36:18 caller_state hangup
setstate FritzboxSipClient 2020-08-14 09:36:18 caller_time 23
setstate FritzboxSipClient 2020-08-14 09:51:32 expire 300
setstate FritzboxSipClient 2020-08-13 12:56:06 last_error ListenRegister: Failed with code 401
setstate FritzboxSipClient 2020-08-14 09:51:32 listen_alive 6352
setstate FritzboxSipClient 2020-08-14 09:51:32 state listen_echo
attr FritzboxSipClient disabled 1
so kann es auch keine fehler geben, oder?
Zitat von: frank am 14 August 2020, 10:00:14
attr FritzboxSipClient disabled 1
so kann es auch keine fehler geben, oder?
Ohh, das hatte ich gestern nicht mehr rausgenommen. Als ich vorher mit dieser Einstellung sip_listen echo, wft und dtmf getestet habe, hat das sip Modul ohne Probleme funktioniert. disabled hat hier wohl keine Auswirkung.
Wird Zeit das ich Urlaub habe...
Hallo,
ich bekomme auch den bekannten Fehler 401, finde aber keinen Ansatz, mich der Lösung zu nähern.
Code:
------------------------
Internals:
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 31995
NAME MySipClient
NOTIFYDEV global
NR 141
NTFY_ORDER 50-MySipClient
STATE error
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-20 09:03:33 last_error ListenRegister: Failed with code 401
2020-08-20 09:03:33 listen_alive no
2020-08-20 09:03:33 state error
helper:
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 788
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 31995
timeout
Attributes:
history_file ./log/MySipClient.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5060
sip_registrar fritz.box
sip_ringtime 3
sip_user 621
-------------------------
Irgendwelche Ideen?
Danke und Gruß,
Kurt
Hallo Kurt,
der 401 bedeutet "401 Unauthorized Die Autorisierung ist fehlerhaft."
Ist nehme an, Du hast das Passwort des Users fhemsip1@fritz.box via set MySipClient password xxxx gesetzt. Dann kann es an der Passwort-Komplexität liegen. Die neueren FritzOS-Versionen sind da wenig tolerant.
Tipps für starke Kennwörter(Passwörter)
Das Kennwort(Passwort) sollte mindestens 8 Zeichen lang sein.
Verwenden Sie für ein starkes Kennwort eine Kombination aus folgenden Zeichen:
Großbuchstaben
Kleinbuchstaben
Zahlen
Sonder- und Satzzeichen
sowie
Verfügbare(erlaubte) Zeichen
Buchstaben von a bis z in Groß- und Kleinschreibung
Ziffern 0 bis 9
Leerzeichen
Sonderzeichen:
_ - ! " # $ % & ' ( ) * + , . / : ; < = > ? @ [ \ ] ^ ` { | } ~
VG plin
Hallo Plin,
danke, aber das PW kann nicht das Problem sein. Das PW ist 11 Zeichen lang und enthält Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen und die Fritzbox stuft dieses PW als "stark" ein.
Bin ratlos.
Gruß Kurt
Zitat von: Kurt77 am 20 August 2020, 10:31:24
danke, aber das PW kann nicht das Problem sein. Das PW ist 11 Zeichen lang und enthält Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen und die Fritzbox stuft dieses PW als "stark" ein.
"stark" reicht glaube ich nicht. Mein Passwort ist mittlerweile 17 Zeichen lang und wird als "sehr stark" eingestuft.
mein password ist schon uralt und fb sagt mittlerweile, seit es die qualifizierung gibt, beim manuellen einloggen => "schwach".
allerdings macht das password nirgends probleme.
ich könnte dieses password nur heutzutage nicht mehr anlegen.
Das Passwort meines Prod-FHEM ist auch noch kurz. Bei meinem Dev-FHEM ging das schon nicht mehr durch. Anscheinend erfolgt die Prüfung nur beim ersten Login.
Hallo Plin,
ich habe jetzt also das Telefon in der FB gelöscht, danach neu angelegt und mit einem (wilden) 30-stelligen Passwort versehen. Nach "Shutdown Restart" kommt wieder Fehler 401.
Übrigens scheint meine FB7490 keine Passwort-Einstufung "sehr stark" zu kennen. Wieder ist die Einstufung "stark". Das könnte aber auch an der relativ alten FW 6.83 liegen.
Hast Du weitere Ideen?
Danke und Gruß,
Kurt
sip_user 621 , sicher das das stimmt ?
ganz früher war mal die erste SIP Nr 621 und so war dann auch der User Name, aber als die das mit der PW Prüfung und den farbigen Balken eingeführt haben wurden doch auch diese kurzen User Namen ungültig ?
bei sip_from steht ja auch fhemsip1 , ist das nicht eher der benutzte Username in der FB ?
Hallo wzut,
unser Wiki hat unter https://wiki.fhem.de/wiki/SIP-Client#Fehler_bei_der_Registrierung_an_der_Fritzbox (https://wiki.fhem.de/wiki/SIP-Client#Fehler_bei_der_Registrierung_an_der_Fritzbox) einige Vorschläge die in den Bereihc des FritzOS 6.83 fallen.
Die Attribute in meinem Prod-FHEM sehen so aus (für FritzOS 7.12):
Attributes:
T2S_Device T2S
T2S_Timeout 30
audio_converter ffmpeg
history_file ./log/FritzSipClient.sip
history_size 0
room Diele,Interfaces,Vorratskeller
sip_audiofile_wfp !Willkommen
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:620@fritz.box
sip_ip 192.168.3.10
sip_listen wfp
sip_port 5070
sip_registrar 192.168.3.1
sip_ringtime 40
sip_user 620
sip_waittime 40
verbose 5
VG plin
Ok du hast auch noch den alten kurzen Usernamen, hatte ich früher ja auch. Aber seit einem Systemwechsel ist das bei mir nun sip621fb weil halt die alten Namen nicht mehr gingen.
Hallo,
nach Änderung des sip_user kommt jetzt Fehler 110.
Code:
-------------------------
Internals:
CPID 2740
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
NAME MySipClient
NOTIFYDEV global
NR 141
NTFY_ORDER 50-MySipClient
STATE error
TYPE SIP
VERSION V1.92 / 21.03.2020
lastnr **611
READINGS:
2020-08-20 14:29:38 call **611
2020-08-20 14:22:08 call_attempt 0
2020-08-20 14:29:38 call_state invite
2020-08-20 14:22:08 call_success 0
2020-08-20 14:22:08 call_time 0
2020-08-20 14:22:08 last_error CallRegister: Failed with error 110
2020-08-20 14:29:38 listen_alive no
2020-08-20 14:22:08 state error
helper:
CALL MySipClient|**611|30||0|0
CALL_BYE CallRegister: Failed with error 110
CALL_ERROR 0
CALL_NAME unknown
CALL_NR **611
CALL_START 1597926578
CALL_TIME 0
CALL_TYPE out
CALL_PID:
abortArg
abortFn
arg MySipClient|**611|30||0
bc_pid 18
finishFn SIP_CALLDone
fn SIP_CALLStart
pid 2740
timeout
Attributes:
history_file ./log/MySipClient.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsip1@192.168.178.1
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5070
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
---------------------
Danke und Gruß,
Kurt
gibt es denn bei dir ein Gerät mit der Nr 611 ?
edit : warum hast du nun sip_from auf ip umgestellt ? Lass da mal die fritz.box nach dem @
Hallo Wzut,
sip_from wieder auf Fritz.box geändert und ja, es gibt ein Gerät 611. Habe auch mein Handy angerufen: Gleiches Fehlerbild.
Weiterhin kommt Fehler 110.
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 20 August 2020, 15:40:52
Hallo Wzut,
sip_from wieder auf Fritz.box geändert und ja, es gibt ein Gerät 611. Habe auch mein Handy angerufen: Gleiches Fehlerbild.
Weiterhin kommt Fehler 110.
Danke und Gruß,
Kurt
Hallo Kurt,
ab FrizOS 6.8 saollte das Format für sip_from
sip:fhemsip1@fritz.box sein (siehe Wiki). Der sip_user sollte dann
fhemsip1 sein. Bei der Combination mit dem gesetzten Passwort kriegst Du doch keinen Error 401 mehr?
Meine Dev-Instanz hat folgende Attribute
Attributes:
history_file ./log/SipTest.sip
history_size 0
room SIP
sip_audiofile_dtmf /opt/fhem/MomentBitteMichael.alaw
sip_audiofile_wfp /opt/fhem/MomentBitteMichael.alaw
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsipt@fritz.box
sip_ip 192.168.3.38
sip_listen wfp
sip_port 5070
sip_registrar 192.168.3.1
sip_ringtime 5
sip_user fhemsipt
verbose 5
VG plin
Hallo Plin,
Fehler 401 ist verschwunden.
Weitere Ideen?
Danke und Gruß,
Kurt
Dann
setze doch mal das Attribut listen auf echo
führe einen set MySipClient reset durch
Der Status des MySipClient sollte dann auf listen_echo stehen.
Nun kannst Du von Deinem **611er Telefon aus Deinen MySipClient anrufen und sollte das was Du sagst als Echo hören.
Hallo Plin,
611 kann 621 nicht erreichen. D.h., dass nicht verbunden wird.
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 20 August 2020, 16:17:00
Weitere Ideen?
aber sicher, stell mal dein SIP Device auf verbose 5 und starte einen Call.
Ich kann deinen Fehler 110 nachstellen wenn ich eine nicht existierende interne Nummer anrufen möchte , hier mal ein Beispiel beim Versuch die **633 anzurufen :
2020.08.20 17:11:45 4: mySIP, calling **633, ringtime: 30 , no message
2020.08.20 17:11:45 4: mySIP, mySIP|**633|30||0
2020.08.20 17:11:45 4: mySIP, call -> mySIP|**633|30||0|0
2020.08.20 17:11:45 5: mySIP, call has pid 15552
2020.08.20 17:11:45 4: mySIP[15552], my parent is 588
2020.08.20 17:11:45 4: mySIP[15552], trying to use port 6010
2020.08.20 17:11:45 4: mySIP[15552], register new expire : 2020-08-20 17:16:45
2020.08.20 17:11:45 4: mySIP[15552], CallStart DTMF : ABCD*#123--4567890
2020.08.20 17:11:45 5: mySIP, readingS:state Val:calling
2020.08.20 17:11:45 4: mySIP[15552], calling : **633
2020.08.20 17:11:45 5: mySIP, readingS:call_state Val:calling **633
2020.08.20 17:11:45 4: mySIP[15552], cb_final - status : FAIL - final : 481
2020.08.20 17:11:45 5: mySIP, readingS:call_state Val:ringing
2020.08.20 17:11:49 4: mySIP[15552], cb_final - status : FAIL - final : 486
2020.08.20 17:11:49 5: mySIP[15552], 0. Ende des ersten Loops
2020.08.20 17:11:49 5: mySIP[15552], 1. rtp_done : 0
2020.08.20 17:11:49 5: mySIP[15552], 2. fi : 1
2020.08.20 17:11:49 5: mySIP[15552], 3. Final : 486
2020.08.20 17:11:49 5: mySIP[15552], 4. timeout : 0
2020.08.20 17:11:49 5: mySIP[15552], 6. call_established : 0
2020.08.20 17:11:49 5: mySIP[15552], RTP done : 0
2020.08.20 17:11:49 5: mySIP[15552], Timeout : 0
2020.08.20 17:11:49 5: mySIP[15552], Final : 486
2020.08.20 17:11:49 5: mySIP[15552], while : -1
2020.08.20 17:11:49 4: mySIP[15552], Calltime : 0
2020.08.20 17:11:49 4: mySIP, CALLDone -> mySIP|1|canceled|0
2020.08.20 17:11:49 5: mySIP, Phonebook: ./phonebook, **633, 100
2020.08.20 17:11:49 5: mySIP, read 3 lines from phonebook
2020.08.20 17:11:49 3: mySIP, no entry found in phonebook for number **633
2020.08.20 17:11:49 4: mySIP, read 100 lines from history file ./log/mySIP.sip
2020.08.20 17:11:49 5: mySIP, fifo is empty
2020.08.20 17:11:49 5: mySIP, no elbc
und die Readings dazu mit Fehler 110 :
READINGS:
2020-08-20 17:11:49 call done
2020-08-20 17:11:49 call_attempt 0
2020-08-20 17:11:49 call_state canceled
2020-08-20 17:11:49 call_success 0
2020-08-20 17:11:49 call_time 0
2020-08-14 08:03:15 caller fetch
2019-07-21 08:37:06 caller_name ---
2019-07-21 08:37:06 caller_nr ---
2019-07-21 08:37:06 caller_state hangup
2019-07-21 08:37:06 caller_time 5
2019-07-20 18:50:52 dtmf_event 5
2019-07-21 08:39:03 expire 300
2020-08-20 17:11:49 history_lines 100
2019-07-20 17:11:49 last_error CallRegister: Failed with error 110
2020-08-09 03:57:49 listen_alive no
2020-08-20 17:11:49 state initialized
Hallo Wzut,
bin sehr gespannt darauf, was du hier siehst.
Danke und Gruß,
Kurt
Code:
--------------------------------------
2020.08.20 17:34:09 5: MySipClient, listen process 4780 found
2020.08.20 17:34:09 1: Timeout for SIP_ListenStart reached, terminated process 4780
2020.08.20 17:34:11 4: MySipClient, Listen new PID : 4792
2020.08.20 17:34:11 4: MySipClient[4792], my parent is 3437
2020.08.20 17:34:11 4: MySipClient[4792], trying to use port 5070
2020.08.20 17:34:14 4: MySipClient, listen process 4792 must be killed befor we start a new call !
2020.08.20 17:34:14 1: Timeout for SIP_ListenStart reached, terminated process 4792
2020.08.20 17:34:14 4: MySipClient, calling **621, ringtime: 30 , no message
2020.08.20 17:34:14 4: MySipClient, MySipClient|**621|30||0
2020.08.20 17:34:14 4: MySipClient, call -> MySipClient|**621|30||0|0
2020.08.20 17:34:14 5: MySipClient, call has pid 4793
2020.08.20 17:34:14 4: MySipClient[4793], my parent is 3437
2020.08.20 17:34:14 4: MySipClient[4793], trying to use port 5080
ich sehe :
a. das Log ist zu kurz , da musste noch mehr kommen
b. warum bitte soll jetzt Nr. 621 angerufen werden und nicht mehr die 611 ?
Nach deinen anderen lists ist doch 621 die eigene Nr des SIP Device ?
Sorry Wzut,
da habe ich mit der 621 Blödsinn gemacht.
Hier kommt also das log, das übrigens tatsächlich so kurz ist, für **611.
Danke und Gruß,
Kurt
Code:
-----------------------
2020.08.20 19:19:47 5: MySipClient, listen process 5880 found
2020.08.20 19:19:47 1: Timeout for SIP_ListenStart reached, terminated process 5880
2020.08.20 19:19:49 4: MySipClient, Listen new PID : 5889
2020.08.20 19:19:49 4: MySipClient[5889], my parent is 3437
2020.08.20 19:19:49 4: MySipClient[5889], trying to use port 5070
2020.08.20 19:19:58 4: MySipClient, listen process 5889 must be killed befor we start a new call !
2020.08.20 19:19:58 1: Timeout for SIP_ListenStart reached, terminated process 5889
2020.08.20 19:19:58 4: MySipClient, calling **611, ringtime: 30 , no message
2020.08.20 19:19:58 4: MySipClient, MySipClient|**611|30||0
2020.08.20 19:19:58 4: MySipClient, call -> MySipClient|**611|30||0|0
2020.08.20 19:19:58 5: MySipClient, call has pid 5891
2020.08.20 19:19:58 4: MySipClient[5891], my parent is 3437
2020.08.20 19:19:58 4: MySipClient[5891], trying to use port 5080
2020.08.20 19:21:02 4: MySipClient, CALLDone -> MySipClient|0|CallRegister: Failed with error 110|0
2020.08.20 19:21:02 5: MySipClient, fifo is empty
2020.08.20 19:21:02 4: MySipClient, try restarting listen process after call ends
2020.08.20 19:21:02 4: MySipClient, Listen new PID : 5924
2020.08.20 19:21:02 4: MySipClient[5924], my parent is 3437
2020.08.20 19:21:02 4: MySipClient[5924], trying to use port 5070
ok, was bei dir auffällig ist :
2020.08.20 19:19:58 4: MySipClient[5891], trying to use port 5080
2020.08.20 19:21:02 4: MySipClient, CALLDone -> MySipClient|0|CallRegister: Failed with error 110|0
Zwischen diesen beiden Meldungen liegt eine halbe Ewigkeit, eigentlich sollte direkt nach der ersten Meldung eine kommen die etwa so aussieht :
2020.08.20 19:19:58 4: MySipClient[5891], register new expire : 2020-08-20 19:24:58
( also mit einer Datum/Zeit Angabe die 300 Sekunden in der Zukunft liegt )
Diese Zeile fehlt auch an anderer Stelle in deinem Log, z.B. nach dem Versuch einen Listen Prozess zu starten.
Das sieht für mich aus als ob du auf deinem System ein Problem mit den Ports hast, bzw. die FritzBox keine Verbindung über diesen Port mit deinem SIP Device aufbauen kann. Typisch ist so ein Verhalten z.B. in einer Docker Umgebung oder wenn zusätzliche Firewalls im Spiel sind.
D.h. du wirst uns schon etwas mehr über dein System und Umfeld verraten müssen.
Tipp : Es wird nicht umsonst empohlen in der eigenen Signatur etwas sein System zu beschreiben, das erspart denen die hlefen möchten oft so manche Kaffesatz Leserei :)
siehe auch: https://wiki.fhem.de/wiki/SIP-Client#Docker (https://wiki.fhem.de/wiki/SIP-Client#Docker)
Hallo Wzut,
hier läuft Raspian (Debian Version 8.0) auf einem Raspi 3b. Welche Informationen brauchst Du noch?
Danke und Gruß,
Kurt
ok, dann versuchen wir es mal mit folgenden Aussagen:
- Die FritzBox und Dein Raspberry Pi befinden sich in einem Netzsegment 192.168.178.0/24
- Dein Raspberry Pi hat die IP-Adresse 192.168.178.33
- Die Fritzbox hat die IP-Adresse 192.168.178.1
- Auf Deinem Raspberry läuft keine Firewall
und ein paar Tests/Fragen:
- Der Befehl host fritz.box liefert auf Deinem Raspberry PI das Ergebnis 192.168.178.1?
- Wie sieht der output von ip addr auf Deinem Raspberry aus?
- Wie sieht der output von ip route auf Deinem Raspberry aus?
- Wie sieht der output von traceroute 192.168.178.1 auf Deinem Raspberry aus?
Vielleicht ist es auch der Hostname:
mal als Schnellschuss, ersetze den sip_registrar fritz.box mal gegen die echte IP -> 192.168.178.1
sip_user und sip_from so lassen.
Zitat von: plin am 21 August 2020, 09:28:01
ok, dann versuchen wir es mal mit folgenden Aussagen:
- Die FritzBox und Dein Raspberry Pi befinden sich in einem Netzsegment 192.168.178.0/24
- Dein Raspberry Pi hat die IP-Adresse 192.168.178.33
- Die Fritzbox hat die IP-Adresse 192.168.178.1
- Auf Deinem Raspberry läuft keine Firewall
und ein paar Tests/Fragen:
- Der Befehl host fritz.box liefert auf Deinem Raspberry PI das Ergebnis 192.168.178.1?
- Wie sieht der output von ip addr auf Deinem Raspberry aus?
- Wie sieht der output von ip route auf Deinem Raspberry aus?
- Wie sieht der output von traceroute 192.168.178.1 auf Deinem Raspberry aus?
Vielleicht ist es auch der Hostname:
mal als Schnellschuss, ersetze den sip_registrar fritz.box mal gegen die echte IP -> 192.168.178.1
sip_user und sip_from so lassen.
Hallo Plin,
Deine ersten 4 Aussagen sind korrekt. der Befehl host Fritz.box liefert 192.168.178.1.
Änderung des Registrars hat nichts gebracht.
Output ip addr:
Code:
----------------------------------
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:40:6e:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.33/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::b429:9dc5:4978:6bd9/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:15:3b:ed brd ff:ff:ff:ff:ff:ff
inet6 fe80::467d:d6f0:74cc:4d78/64 scope link tentative
valid_lft forever preferred_lft forever
----------------------------------------------------------
Output von ip route:
Code:
--------------------------------------
default via 192.168.178.1 dev eth0 metric 202
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.33 metric 202
-------------------------------------------------
Output von traceroute 192.168.178.1:
Code:
------------------------------------------------
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
1 fritz.box (192.168.178.1) 0.742 ms 0.806 ms 0.874 ms
----------------------------------
Danke und Gruß,
Kurt
Das sieht netzwerktechnisch alles gut aus. Also müssen wir mal auf die andere Seite schauen - die FritzBox.
Finden sich unter System->Ereignsse irgendwelche Fehlermeldungen? Ich habe eben mit einem falschen Passwort getestet und die Meldung "Anmeldung für IP-Telefoniegerät "fhemsipt" von IP-Adresse 192.168.3.33 nicht erfolgreich." erhalten.
Unter Telefonie-> Telefoniegeräte ist Dein SIP-Client an Anschluss LAN/WLAN mit der internen Nummer **621 gelistet?
Wenn Du dieses Gerät editierst ist dem auch der User fhemsip1 zugeordnet?
Ist unter System->FRITZ!Box-Benutzer->fhemsip1 -> Berechtigungen
a) das Benutzerkonto aktiv
b) der Bullit
"Sprachnachrichten, Faxnachrichten, FRITZ!App Fon und Anrufliste
Sprachnachrichten, empfangene Faxe und die Anrufliste können abgehört bzw. angesehen werden. FRITZ!App Fon kann genutzt werden."
getickert?
nun gehen mir allerdings die Ideen aus. Flaches Netz, kein Docker, keine FW.
Entweder kann die FB nicht mit dem Raspi reden oder sie will nicht, das ist jetzt so ein Punkt wo einem vermutlich nur Wireshark mehr sagen könnte.
Wie ist denn das SIP Telefon 621 in der FB eingerichtet, als normales IP Phone oder als Türsprechstelle ?
Zitat von: Wzut am 21 August 2020, 14:19:58
Wie ist denn das SIP Telefon 621 in der FB eingerichtet, als normales IP Phone oder als Türsprechstelle ?
Ein paar Fragen habe ich gerade eben in meinem letzten Post vor Deinem gestellt https://forum.fhem.de/index.php/topic,67443.msg1079684.html#msg1079684 (https://forum.fhem.de/index.php/topic,67443.msg1079684.html#msg1079684) ;)
Hallo Wzut,
Normales IP Phone.
Gruß Kurt
Das sieht netzwerktechnisch alles gut aus. Also müssen wir mal auf die andere Seite schauen - die FritzBox.
Finden sich unter System->Ereignsse irgendwelche Fehlermeldungen? Ich habe eben mit einem falschen Passwort getestet und die Meldung "Anmeldung für IP-Telefoniegerät "fhemsipt" von IP-Adresse 192.168.3.33 nicht erfolgreich." erhalten.
Unter Telefonie-> Telefoniegeräte ist Dein SIP-Client an Anschluss LAN/WLAN mit der internen Nummer **621 gelistet?
Wenn Du dieses Gerät editierst ist dem auch der User fhemsip1 zugeordnet?
Ist unter System->FRITZ!Box-Benutzer->fhemsip1 -> Berechtigungen
a) das Benutzerkonto aktiv
b) der Bullit
"Sprachnachrichten, Faxnachrichten, FRITZ!App Fon und Anrufliste
Sprachnachrichten, empfangene Faxe und die Anrufliste können abgehört bzw. angesehen werden. FRITZ!App Fon kann genutzt werden."
getickert?
Zitat von: plin am 21 August 2020, 16:15:56
Das sieht netzwerktechnisch alles gut aus. Also müssen wir mal auf die andere Seite schauen - die FritzBox.
Finden sich unter System->Ereignsse irgendwelche Fehlermeldungen? Ich habe eben mit einem falschen Passwort getestet und die Meldung "Anmeldung für IP-Telefoniegerät "fhemsipt" von IP-Adresse 192.168.3.33 nicht erfolgreich." erhalten.
Plin, mich trifft der schlag!
Code:
--------------------------------------------------------
Anmeldung für IP-Telefoniegerät "621" von IP-Adresse 192.168.178.33 nicht erfolgreich. [10 Meldungen seit 20.08.20 08:59:31]
----------------------------------------------------------------
Kann ich mir nicht wirklich erklären. Das zugehörige PW steht in einer Textdatei und wurde über die Zwischenablage sowohl in der FB als auch in Fhem eingefügt.
Also lösche ich dieses Telefon jetzt und stelle es wieder neu hin.
Was aber erzwingt nach der Neueinrichtung die Anmeldung von 192.168.178.33 an der FB?
Danke und Gruß,
Kurt
Hallo Plin,
Telefon fhemsip1 neu eingerichtet, PW erneut in fhem eingegeben ("Successfully") und danach einen reset in fhem durchgeführt.
Du glaubst es nicht: Set MysipClient call **611 lässt das Gerät klingeln!
Ganz herzlichen Dank! Ich tüftele weiter.
Also erstmal kein weiterer Handlungsbedarf von Dir und Wzut.
Danke nochmal und Gruß,
Kurt
schön, ein zuriedener Kunde mehr :)
Zitat von: Kurt77 am 21 August 2020, 16:42:27
Das zugehörige PW steht in einer Textdatei und wurde über die Zwischenablage sowohl in der FB als auch in Fhem eingefügt.
ohne dir da jetzt zu nahe treten zu wollen, aber vermutlich ging dabei etwas schief. Ein Zeichen zu wenig eines zuviel, was auch immer, aber du wirst da genug Erfahrung mit deinen Hilfsmitteln haben und das bestimmt öfters/immer so handhaben.
Mich wundert es aber schon, da am Anfang ja eine 400er Fehlermeldung kam und dann die relativ versteckte 110.
Mal schauen ob wir zukünftig nicht die einfachen nachstellbaren Fehler besser im Modul abfangen können und direkte Klartext Fehlerausgaben einbauen.
Sorry, ich schon wieder.
leider gibt es bei mir kein Reading "dtmf" und ich bekomme schon wieder einen fehler 404.
Im Logfile sehe ich aber in 2 aufeinander folgenden Zeilen dtmf Events.
Gebe ich z.B. ein "#45", erscheint in den Zeilen "#" und danach "4". Bei eingabe von "45" (also ohne #) sehe ich im log "4" und "5".
Code:
-----------------------------------
Internals:
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 20956
NAME MySipClient
NOTIFYDEV mytext2speech
NR 141
NTFY_ORDER 50-MySipClient
STATE listen_dtmf
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-21 17:05:11 call done
2020-08-21 17:05:11 call_attempt 0
2020-08-21 17:05:11 call_state no answer
2020-08-21 17:05:11 call_success 0
2020-08-21 17:05:11 call_time 0
2020-08-21 21:09:47 caller none
2020-08-21 21:09:47 caller_name ---
2020-08-21 21:09:47 caller_nr ---
2020-08-21 21:09:47 caller_state hangup
2020-08-21 21:09:47 caller_time 9
2020-08-21 21:11:32 expire 300
2020-08-21 16:53:41 last_error ListenRegister: Failed with code 404
2020-08-21 21:11:32 listen_alive 20956
2020-08-21 21:11:32 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 7
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 20956
timeout
Attributes:
T2S_Device mytext2speech
disabled 0
history_file ./log/MySipClient.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5070
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
verbose 5
-------------------------
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 21 August 2020, 21:23:26
leider gibt es bei mir kein Reading "dtmf" und ich bekomme schon wieder einen fehler 404.
Im Logfile sehe ich aber in 2 aufeinander folgenden Zeilen dtmf Events.
Gebe ich z.B. ein "#45", erscheint in den Zeilen "#" und danach "4". Bei eingabe von "45" (also ohne #) sehe ich im log "4" und "5".
a. dein Fehler 404 ist aber schon etwas älter laut Timestamp, wäre der noch aktuell könntest du das SIP Device gar nicht anrufen, bzw. du hättest gar keine Chance Tasten einzugeben.
b. die Raute # ist das Startzeichen und wird zur Auswertung nicht mitgezählt (siehe Wiki) , wenn nach der 4 die 5 nicht im Log erscheint wurde sie nicht erkannt. In diesem Fall die Eingabe wiederholen oder mal eine andere Taste probieren. Sobald die zweite Taste erkannt wurde gibt es auch das Reading DTMF und für dich vllt. besonders wichtig eine akustische Quittung (siehe Attribut sip_audiofile_dtmf). Generell hatten wir (bzw die User) von Anfang an Probleme mit der DTMF Erkennung auf dem Raspberry. Versuch zu Beginn ersteinmal mit sip_dtmf_size 1 zu arbeiten, dann benötigst du nur eine erkannte Taste nach der Raute.
Zitat von: Wzut am 22 August 2020, 07:09:16
Generell hatten wir (bzw die User) von Anfang an Probleme mit der DTMF Erkennung auf dem Raspberry.
@wzut: Das war beim Raspberry Pi 1 der Fall, ab dem 2er sollte es gehen. Ich habe gerade auf meinem BananaPi in Verbindung mit der FritzFon App getestet, da gab es keine Probleme
Hallo,
ich sehe jetzt tatsächlich ein Reading dtmf_event, das sich aber nicht ändert.
Ich glaube, dass das nicht zuverlässig funktioniert, weil ich nach Eingabe # + Ziffer keinen Quittungston höre.
Gruß Kurt
Was nutzt Du als Device für den Anruf?
Hallo Plin,
ein Fritzfon M2. Übrigens wird immer ein dtmf_event erkannt. Das sehe ich daran, dass die Zeit nach # gefolgt von Ziffer immer aktualisiert wird.
Danke und Gruß,
Kurt
Bei meinem FritzFON C5 höre ich weder die Ansage noch den Quittungston am Ende.
Wenn ich ein T2S Device anlege und die Attribute
- sip_audiofile_dtmf !Ihre Eingabe bitte
- sip_audiofile_ok !Danke
belege kriege ich auch Ansagen.
attribut sip_audiofile_dtmf = !Das ist Test ergibt bei mir auch nur einen kurzen Pfeifton (warum auch immer)
aber attribut sip_audiofile_ok = !alles klar ist das zu hören - getestet mit FRITZ DECT mit dem bunten Display
@Kurt77 wie hast du denn die beiden Attribute vorbesetzt ? Bzw. wenn du wie wir Text einsetzt muß sowohl sox als auch Text2Speach installiert sein !
Hallo,
nachdem ich also jetzt die beiden Audio-Attribute gesetzt habe, höre ich den Pfeifton nicht mehr, die Texte allerdings auch nicht.
Was bitte heißt "text2speech installiert? Ich habe ein t2s-Device mit text2speech angelegt. Sieht man ja auch im list.
Sicher kann ich nur eines sagen: Bei jedem Anruf wird die Zeit bei dtmf_event aktualisiert und zwar unabhängig davon, ob ich #Ziffer eingebe oder nicht.
Code:
-----------------------------------
Internals:
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 29746
NAME MySipClient
NOTIFYDEV mytext2speech
NR 141
NTFY_ORDER 50-MySipClient
STATE listen_dtmf
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-21 21:47:33 call done
2020-08-21 21:47:33 call_attempt 0
2020-08-21 21:47:33 call_state declined
2020-08-21 21:47:33 call_success 0
2020-08-21 21:47:33 call_time 0
2020-08-22 11:49:21 caller Buero sip:**610@fritz.box
2020-08-22 11:49:21 caller_name Buero
2020-08-22 11:49:21 caller_nr **610
2020-08-22 11:49:25 caller_state established
2020-08-22 11:49:21 caller_time 0
2020-08-22 11:46:06 dtmf_event 5
2020-08-22 11:49:44 expire 300
2020-08-21 16:53:41 last_error ListenRegister: Failed with code 404
2020-08-22 11:49:44 listen_alive 29746
2020-08-22 11:49:44 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 3
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 29746
timeout
Attributes:
T2S_Device mytext2speech
disabled 0
history_file ./log/MySipClient.sip
history_size 0
sip_audiofile_dtmf Eingabe
sip_audiofile_ok danke
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 1
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
verbose 5
----------------------------------------------
Danke und Gruß,
Kurt
Hallo,
neue Erkenntnis: Nach einem reset funktioniert es zuverlässig immer genau 1-mal.
Hilft das bei der Fehlereingrenzung?
Danke und Gruß,
Kurt
@Kurt77 :
sip_audiofile_dtmf Eingabe
sip_audiofile_ok danke
Kann nicht klappen, da fehlt etwas.
a. wenn du fertige RAW Audio Files hast muss da die Endung dran , z.B. Eingabe.alaw
b. wenn du fertige MP3 Dateien hast : um mp3 in RAW wandeln zu können muss sox oder ffmeg installiert sein (siehe Wiki) , der installierte Audikonverter muss mit dem Attribut audio_converter festgelegt werden ( ich empfehle sox zu benutzen )
c. Wenn du freie Texte ausgeben möchtest muss Text2Speach als Device vorhanden sein , wäre dann bei dir das Device mytext2speech
Das Device mytext2speech hat als DEF none ? Es soll ja keine Audioausgabe machen sondern nur MP3 Dateien erzeugen.
Und um diese dann später in alaw konvertieren zu können wird wieder der Konverter sox oder ffmeg benötigt wie unter Punkt B
Bitte beachte die Hinweise in der command.ref zum installieren von sox :
Zitataudo_converter
sox oder ffmpeg, default sox
Ist für Text2Speech unbedingt erforderlich um die mp3 Dateien in Raw Audio umzuwandeln.
Installation z.B. mit sudo apt-get install sox und die mp3 Unterstützung mit sudo apt-get install libsox-fmt-mp3
Sodele und nun ganz wichtig : Wenn du einen freien Text als Audiodatei einträgst muss dieser unbedingt mit einem Ausrufezeichen beginnen.
Nochmal zurück zu deinen Attributen wäre dann richtig :
sip_audiofile_dtmf !Eingabe
sip_audiofile_ok !danke
Sowohl plin als auch ich hatten das so in unseren Beispielen auch geschrieben, pass also bitte auf das dein Screenreader dieses wichtige Ausrufezeichen nicht unterschlägt.
Was bitte geht einmal ?
Beim testen und durchsehen des Quellcodes habe ich einen kleinen Bug gefunden wenn listen_type dtmf verwendet wird
und beide Attribute sip_audiofile_dtmf und sip_audiofile_ok einen Text2Speach Text enthalten.
Problem : Sind beide Audiodateien noch nicht im Cache müssen sie zuerst geholt werden, das klappt aber nur für die zweite fehlende Datei,
da die erste laufende Anfrage durch die direkt darauf folgende zweite überschrieben wird.
Abhilfe : Zuerst nur an einem Attribut den Text setzen. Sobald der Prozess gestartet ist kann auch das zweite Attribut auf Text gesetzt werden und mit set reset der listen Prozess neu gestartet werden.
Der Fehler tritt dann nicht mehr auf da die erste Datei nun bereits im Cache ist und nur die zweite neu geholt werden muß.
Danach tritt das Problem gar nicht mehr auf solange man die beiden Dateien zusammen nicht aus dem Cache löscht.
Hallo Wzut,
danke, aber ich glaube, ich muss den Versuch, dieses Modul zum Laufen zu bekommen, langsam abbrechen.
Habe also die von Dir vorgschlagenen Änderungen vorgenommen und sehe nach einem shtdown Restart und folgendem Anruf einen erro im log.
Dann habe ich mir mal das Ereignisprotokoll in meiner FB angesehen und sehe folgendes.
Code:
---------------------------------------------
23.08.20
17:37:36
Internettelefonie mit fhemsip1@192.168.178.33:5060 über 192.168.178.33:5060 war nicht erfolgreich. Ursache: (408) [2 Meldungen seit 23.08.20 17:36:30]
--------------------------------------------------
Danke und Gruß,
Kurt
Hallo,
Jetzt habe ich wieder den gleichen Effekt wie unter #976 beschrieben.
Es funktioniert nach einem reset zuverlässig genau 1-mal. Damit meinte ich, dass die dtmf-Erkennung nach einem Reset genau einmal korrekt funktioniert. Bei weiteren Eingaben keine Erkennung mehr.
Jetz habe ich das gleiche Phänomen mit der Sprachausgabe: Ich höre nach einem Reset genau einmal das wort "Eingabe". Der nachfolgend eingegebene dtmf-Code wird nicht erkannt.
Code:
-------------------------------------
Internals:
AC /usr/bin/sox
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 17727
NAME MySipClient
NOTIFYDEV mytext2speech
NR 141
NTFY_ORDER 50-MySipClient
STATE listen_dtmf
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-21 21:47:33 call done
2020-08-21 21:47:33 call_attempt 0
2020-08-21 21:47:33 call_state declined
2020-08-21 21:47:33 call_success 0
2020-08-21 21:47:33 call_time 0
2020-08-23 18:26:44 caller none
2020-08-23 18:26:44 caller_name ---
2020-08-23 18:26:44 caller_nr ---
2020-08-23 18:26:44 caller_state hangup
2020-08-23 18:26:44 caller_time 8
2020-08-22 14:03:04 dtmf_event 12
2020-08-23 18:26:14 expire 300
2020-08-23 17:40:44 last_error attr audio_converter not set
2020-08-23 18:26:14 listen_alive 17727
2020-08-23 18:26:14 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 7
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 17727
timeout
Attributes:
T2S_Device mytext2speech
audio_converter sox
disabled 0
history_file ./log/MySipClient.sip
history_size 0
sip_audiofile_dtmf ! Eingabe
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
verbose 5
-----------------------------------------
danke und Gruß,
Kurt
sip_audiofile_dtmf ! Eingabe , bitte prüfe das mal. Das Ausrufezeichen ist jetzt da, allerdings ist zwischen ihm und dem Wort Eingabe ein Leerzeichen.
(Ich habe bis jetzt nicht geprüft was T2S damit macht , aber zur Sichheit nimm es bitte raus)
Da du eh ständig mit verbose 5 arbeitest wäre jetzt der betreffende Abschnitt aus der Log Datei hilfreicher als das List vom Device
Guter Abschnitt wäre : du startest neu damit es einmal geht und sofort danach rufst du wieder an tippst ein paar Tasten und legst wieder auf.
Poste nun alle Zeilen mit deinem Sip Device
Hallo Wzut,
Code:
---------------------------------------------
2020.08.23 19:36:42 5: MySipClient[18482], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=24AF83BE8A440C55
2020.08.23 19:36:42 4: MySipClient[18482], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.23 19:36:42 4: MySipClient[18482], cb_create : INVITE
2020.08.23 19:36:42 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.23 19:36:42 5: MySipClient, readingB:caller_nr Val:**610
2020.08.23 19:36:42 5: MySipClient, readingB:caller_name Val:Buero
2020.08.23 19:36:42 5: MySipClient, readingB:caller_time Val:0
2020.08.23 19:36:42 5: MySipClient, readingB:caller_state Val:calling
2020.08.23 19:36:42 5: MySipClient[18482], cb_invite_dtmf
2020.08.23 19:36:42 5: MySipClient, readingS:caller_state Val:ringing
2020.08.23 19:36:43 5: MySipClient, listen process 18482 found
2020.08.23 19:36:45 5: MySipClient[18482], cb_est_dtmf
2020.08.23 19:36:45 5: MySipClient[18482], while dtmf_loop : start reinvite1
2020.08.23 19:36:45 5: MySipClient, readingS:caller_state Val:established
2020.08.23 19:36:47 5: MySipClient[18482], DTMF Event: # - 806 ms
2020.08.23 19:36:48 5: MySipClient[18482], DTMF Event: # - 83 ms
2020.08.23 19:36:48 5: MySipClient[18482], DTMF Event: 4 - 873 ms
2020.08.23 19:36:48 5: MySipClient[18482], DTMF: 4 , Anz: 2
2020.08.23 19:36:50 5: MySipClient[18482], SIP_bye : HASH(0x52430f0)
2020.08.23 19:36:50 5: MySipClient, readingB:caller Val:none
2020.08.23 19:36:50 5: MySipClient, readingB:caller_state Val:hangup
2020.08.23 19:36:50 5: MySipClient[18482], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.23 19:36:50 5: MySipClient, readingB:caller_time Val:5
2020.08.23 19:36:50 5: MySipClient[18482], aufgelegt
2020.08.23 19:36:50 5: MySipClient, readingB:caller_nr Val:---
2020.08.23 19:36:50 5: MySipClient[18482], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.23 19:36:50 5: MySipClient, readingB:caller_name Val:---
2020.08.23 19:36:50 5: MySipClient[18482], end while dtmf_loop, byebye : 1
2020.08.23 19:36:50 5: MySipClient[18482], while(1)
2020.08.23 19:37:11 5: MySipClient[18482], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=C570F384FE0620A5
2020.08.23 19:37:11 4: MySipClient[18482], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.23 19:37:11 4: MySipClient[18482], cb_create : INVITE
2020.08.23 19:37:11 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.23 19:37:11 5: MySipClient, readingB:caller_nr Val:**610
2020.08.23 19:37:11 5: MySipClient, readingB:caller_name Val:Buero
2020.08.23 19:37:11 5: MySipClient, readingB:caller_time Val:0
2020.08.23 19:37:11 5: MySipClient, readingB:caller_state Val:calling
2020.08.23 19:37:11 5: MySipClient[18482], cb_invite_dtmf
2020.08.23 19:37:11 5: MySipClient, readingS:caller_state Val:ringing
2020.08.23 19:37:14 5: MySipClient[18482], cb_est_dtmf
2020.08.23 19:37:14 5: MySipClient, readingS:caller_state Val:established
2020.08.23 19:37:14 5: MySipClient[18482], while dtmf_loop : start reinvite1
2020.08.23 19:37:15 5: MySipClient[18482], DTMF Event: # - 517 ms
2020.08.23 19:37:16 5: MySipClient[18482], DTMF Event: 5 - 705 ms
2020.08.23 19:37:16 5: MySipClient[18482], DTMF: 5 , Anz: 2
2020.08.23 19:37:17 5: MySipClient[18482], DTMF Event: 6 - 835 ms
2020.08.23 19:37:17 5: MySipClient[18482], DTMF: 56 , Anz: 3
2020.08.23 19:37:17 5: MySipClient, readingS:dtmf_event Val:56
2020.08.23 19:37:19 5: MySipClient[18482], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.23 19:37:19 5: MySipClient[18482], while dtmf_loop : reinvite2
jump to the top
----------------
Danke und Gruß,
Kurt
Ich sehe jetzt gerade, dass er beim 2. Anruf doch den dtmf-Code erkannt hat ("56").
Also beim ersten Anruf nur Ausgabe des wortes "Eingabe", danach die eingabe dtmf-Code wird nicht erkannt.
Beim 2. Anruf wird "eingabe" nicht gesprochen, dafür aber der dtmf-Code.
Der dritte anruf (ist hier nicht dokumentiert) spricht weder "Eingabe" noch wird der dtmf-Code erkannt.
Zitat von: Kurt77 am 23 August 2020, 18:36:32
Es funktioniert nach einem reset zuverlässig genau 1-mal. Damit meinte ich, dass die dtmf-Erkennung nach einem Reset genau einmal korrekt funktioniert. Bei weiteren
@Kurt: Du hast aktuell
sip_dtmf_loop once konfiguriert: Ein Anruf, eine Nummerneingabe, Telefonat beendet. Du kannst dann wieder neu anrufen und das Spielchen wiederholen.
Wenn Du mehrere Eingaben durchführen und selber aktiv auflegen möchtest, musst du
sip_dtmf_loop loop einstellen.
@Wzut: bei sip_dtmf_loop once kommt bei mir der Ansagetext nur einmal. Beim 2. Anruf kommt der OK-Text als Ansage und nach erfolgter Eingabe.
Zitat von: plin am 23 August 2020, 20:41:17
@Kurt: Du hast aktuell sip_dtmf_loop once konfiguriert: Ein Anruf, eine Nummerneingabe, Telefonat beendet. Du kannst dann wieder neu anrufen und das Spielchen wiederholen.
Hallo Plin,
und genau das wollte ich tun. Anrufen, dtmf-Code eingeben, wieder anrufen und wieder dtmf-Code eingeben.
Die Situation ist, wie oben schon beschrieben, Anruf "Eingabe" Code-Eingabe, keine Änderung im dtmf_event. 2. Anruf Kein "Eingabe", danach eingegebener dtmf-Code erscheint im dtmf-event. Der dritte und jeder weitere Anruf bringt weder "Eingabe" noch ein dtmf_event. Erst nach einem reset geht das spiel wieder von vorne los.
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 23 August 2020, 19:53:44
Ich sehe jetzt gerade, dass er beim 2. Anruf doch den dtmf-Code erkannt hat ("56").
Also beim ersten Anruf nur Ausgabe des wortes "Eingabe", danach die eingabe dtmf-Code wird nicht erkannt.
Beim 2. Anruf wird "eingabe" nicht gesprochen, dafür aber der dtmf-Code.
Der dritte anruf (ist hier nicht dokumentiert) spricht weder "Eingabe" noch wird der dtmf-Code erkannt.
Beim ersten Anruf hast du zu früh aufgelegt , die Raute wurde zweimal erkannt aber einmal verworfen, danach die Ziffer 4 und da hast du dann leider aufgelegt.
Intressant wäre nun der dritte Anruf gewesen bei dem es ja nach deiner Aussage dann nicht mehr geht.
D.h. man muss einen erfolgreichen Ruf einem nicht erfolgreichen direkt gegenüberstellen um die Unterschiede sehen zu können.
Und Kurt77 wenn du von reset sprichst dann meinst du den Reset mittels Set Kommando oder einen Neustart von FHEM ?
Das spricht dann eigentlich dafür das der erfolgreiche Anruf irgendwie nicht sauber beendet wurde und daher die nachfolgenden Versuche fehlschlagen.
Ich kann auch das Verhalten das plin beschreibt mit der Ansage so noch nicht ganz nachvollziehen, da es bei mir einwandrei ging.
Halloo Wzut,
ja, mit "reset" meine ich den set-Befehl.
Hier wieder ein Auszug aus meinem Log. Der erste Anruf nach einem Reset sagte mir "Eingabe an, dtmf-Code wurde nicht erkannt. Der zweit hat weder "Eingabe" angesagt noch einen dtmf-Code erkannt.
Code:
-----------------------------------------
2020.08.24 09:08:26 5: MySipClient, listen process 26431 found
2020.08.24 09:08:50 5: MySipClient[26431], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=40DF946B13C23F9A
2020.08.24 09:08:50 4: MySipClient[26431], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.24 09:08:50 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.24 09:08:50 5: MySipClient, readingB:caller_nr Val:**610
2020.08.24 09:08:50 5: MySipClient, readingB:caller_name Val:Buero
2020.08.24 09:08:50 5: MySipClient, readingB:caller_time Val:0
2020.08.24 09:08:50 5: MySipClient, readingB:caller_state Val:calling
2020.08.24 09:08:50 4: MySipClient[26431], cb_create : INVITE
2020.08.24 09:08:50 5: MySipClient[26431], cb_invite_dtmf
2020.08.24 09:08:50 5: MySipClient, readingS:caller_state Val:ringing
2020.08.24 09:08:53 5: MySipClient[26431], cb_est_dtmf
2020.08.24 09:08:53 5: MySipClient, readingS:caller_state Val:established
2020.08.24 09:08:53 5: MySipClient[26431], while dtmf_loop : start reinvite1
2020.08.24 09:08:59 5: MySipClient[26431], DTMF Event: 9 - 27 ms
2020.08.24 09:09:06 5: MySipClient[26431], SIP_bye : HASH(0x4be3340)
2020.08.24 09:09:06 5: MySipClient, readingB:caller Val:none
2020.08.24 09:09:06 5: MySipClient, readingB:caller_state Val:hangup
2020.08.24 09:09:06 5: MySipClient, readingB:caller_time Val:13
2020.08.24 09:09:06 5: MySipClient, readingB:caller_nr Val:---
2020.08.24 09:09:06 5: MySipClient, readingB:caller_name Val:---
2020.08.24 09:09:06 5: MySipClient[26431], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.24 09:09:06 5: MySipClient[26431], aufgelegt
2020.08.24 09:09:06 5: MySipClient[26431], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.24 09:09:06 5: MySipClient[26431], end while dtmf_loop, byebye : 1
2020.08.24 09:09:06 5: MySipClient[26431], while(1)
2020.08.24 09:09:22 5: MySipClient[26431], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=3FB69C9FE0EB5D7F
2020.08.24 09:09:22 4: MySipClient[26431], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.24 09:09:22 4: MySipClient[26431], cb_create : INVITE
2020.08.24 09:09:22 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.24 09:09:22 5: MySipClient, readingB:caller_nr Val:**610
2020.08.24 09:09:22 5: MySipClient, readingB:caller_name Val:Buero
2020.08.24 09:09:22 5: MySipClient, readingB:caller_time Val:0
2020.08.24 09:09:22 5: MySipClient, readingB:caller_state Val:calling
2020.08.24 09:09:22 5: MySipClient[26431], cb_invite_dtmf
2020.08.24 09:09:22 5: MySipClient, readingS:caller_state Val:ringing
2020.08.24 09:09:25 5: MySipClient[26431], cb_est_dtmf
2020.08.24 09:09:25 5: MySipClient, readingS:caller_state Val:established
2020.08.24 09:09:25 5: MySipClient[26431], while dtmf_loop : start reinvite1
2020.08.24 09:09:26 5: MySipClient[26431], DTMF Event: # - 129 ms
2020.08.24 09:09:26 5: MySipClient, listen process 26431 found
2020.08.24 09:09:27 5: MySipClient[26431], DTMF Event: 8 - 201 ms
2020.08.24 09:09:27 5: MySipClient[26431], DTMF: 8 , Anz: 2
2020.08.24 09:09:28 5: MySipClient[26431], DTMF Event: 9 - 73 ms
2020.08.24 09:09:28 5: MySipClient[26431], DTMF Event: 9 - 28 ms
2020.08.24 09:09:37 5: MySipClient[26431], SIP_bye : HASH(0x529bd30)
2020.08.24 09:09:37 5: MySipClient, readingB:caller Val:none
2020.08.24 09:09:37 5: MySipClient, readingB:caller_state Val:hangup
2020.08.24 09:09:37 5: MySipClient, readingB:caller_time Val:12
2020.08.24 09:09:37 5: MySipClient, readingB:caller_nr Val:---
2020.08.24 09:09:37 5: MySipClient[26431], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.24 09:09:37 5: MySipClient[26431], aufgelegt
2020.08.24 09:09:37 5: MySipClient, readingB:caller_name Val:---
2020.08.24 09:09:37 5: MySipClient[26431], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.24 09:09:37 5: MySipClient[26431], end while dtmf_loop, byebye : 1
2020.08.24 09:09:37 5: MySipClient[26431], while(1)
2020.08.24 09:09:56 4: MySipClient[26431], register new expire : 2020-08-24 09:14:56
2020.08.24 09:09:56 5: MySipClient, readingB:state Val:listen_dtmf
2020.08.24 09:09:56 5: MySipClient, readingB:listen_alive Val:26431
2020.08.24 09:09:56 5: MySipClient, readingB:expire Val:300
2020.08.24 09:10:26 5: MySipClient, listen process 26431 found
jump to the top
----------------------------
Danke und Gruß,
Kurt
Was man bei beiden Versuchen schön sehen kann :
Du bist zu ungedultig und legst jedesmal selbst auf, da kann niemals eine gültige Auswertung dabei rauskommen.
Du must in jedem Fall den Call von der Gegenseite beenden lassen !
Was mir noch auffällt : deine Event Zeiten für eine Ton sind recht kurz. Events unter 90ms werden verworfen um Tastenprellen zu verhindern.
Was du immer problemlos machen kannst : Drücke die Raute Taste ruhig öfters (2-3 mal) und auch jede Taste kannst du öfters drücken. Wie geschrieben werden die zu kurzen verworfen, aber auch doppelte werden nur einmal gezählt. Wenn also der Call nicht automatisch beeendet wird dann wurde einfach bisher nicht genug gültiges Material empfangen. Kannst du den Test mal mit einem anderen Telefon machen um zu sehen ob die Event Zeiten dann größer sind ?
Und wie ich schon einmal geschrieben habe, du machst dir (und uns) in dieser Phase das Leben wesentlich leichter wenn du mit sip_dtmf_size ersteinmal auf 1 runter gehst.
einen habe ich noch :
du kannst statt der Raute Taste auch die Stern Taste zum Start benutzen. Die Raute hat beim FRITZ DECT den Anchteil das wenn man sie zu lange dückt im Display die Meldung erscheint das die Tastatur nun gesperrt ist ! Und mit gesperrter Tastatur kommst du natürlich auch nie ans Ziel.
Hallo Wzut,
jetzt habe ich all Deine Ratschläge befolgt, aber ich kann machen, was ich will: Dtmf-Codes werden nicht erkannt. Hier ein List ohne vorhergehendes reset.
Code:
----------------------------------------------------
2020.08.24 20:37:46 5: MySipClient, listen process 655 found
2020.08.24 20:38:15 4: MySipClient[655], register new expire : 2020-08-24 20:43:15
2020.08.24 20:38:15 5: MySipClient, readingB:state Val:listen_dtmf
2020.08.24 20:38:15 5: MySipClient, readingB:listen_alive Val:655
2020.08.24 20:38:15 5: MySipClient, readingB:expire Val:300
2020.08.24 20:38:33 5: MySipClient[655], SIP_filter : "Wohnzimmer" <sip:**611@fritz.box>;tag=2FAFEEDC3AF3153C
2020.08.24 20:38:33 4: MySipClient[655], SIP_filter: caller Wohnzimmer sip:**611@fritz.box, caller_nr **611, caller_name Wohnzimmer
2020.08.24 20:38:33 5: MySipClient, readingB:caller Val:Wohnzimmer sip:**611@fritz.box
2020.08.24 20:38:33 5: MySipClient, readingB:caller_nr Val:**611
2020.08.24 20:38:33 5: MySipClient, readingB:caller_name Val:Wohnzimmer
2020.08.24 20:38:33 5: MySipClient, readingB:caller_time Val:0
2020.08.24 20:38:33 5: MySipClient, readingB:caller_state Val:calling
2020.08.24 20:38:33 4: MySipClient[655], cb_create : INVITE
2020.08.24 20:38:33 5: MySipClient[655], cb_invite_dtmf
2020.08.24 20:38:33 5: MySipClient, readingS:caller_state Val:ringing
2020.08.24 20:38:36 5: MySipClient[655], cb_est_dtmf
2020.08.24 20:38:36 5: MySipClient, readingS:caller_state Val:established
2020.08.24 20:38:46 5: MySipClient, listen process 655 found
2020.08.24 20:39:26 5: MySipClient[655], SIP_filter : "Wohnzimmer" <sip:**611@fritz.box>;tag=0DC61AC9E6FD6EDB
2020.08.24 20:39:26 4: MySipClient[655], SIP_filter: caller Wohnzimmer sip:**611@fritz.box, caller_nr **611, caller_name Wohnzimmer
2020.08.24 20:39:26 5: MySipClient, readingB:caller Val:Wohnzimmer sip:**611@fritz.box
2020.08.24 20:39:26 5: MySipClient, readingB:caller_nr Val:**611
2020.08.24 20:39:26 5: MySipClient, readingB:caller_name Val:Wohnzimmer
2020.08.24 20:39:26 5: MySipClient, readingB:caller_time Val:0
2020.08.24 20:39:26 5: MySipClient, readingB:caller_state Val:calling
2020.08.24 20:39:26 4: MySipClient[655], cb_create : INVITE
2020.08.24 20:39:27 5: MySipClient[655], cb_invite_dtmf
2020.08.24 20:39:27 5: MySipClient, readingS:caller_state Val:ringing
2020.08.24 20:39:30 5: MySipClient[655], cb_est_dtmf
2020.08.24 20:39:30 5: MySipClient, readingS:caller_state Val:established
2020.08.24 20:39:46 5: MySipClient, listen process 655 found
---------------------------------------
Danke und Gruß,
Kurt
Hallo Kurt,
Kannst Du mal probieren, die Code Tags zu nehmen, wenn Du deine Logs postest? Das ist der ,,#" button in der unteren Reihe über dem Eingabefenster, damit muss man nicht endlios scrollen wenn man die Antwort lesen will.
Hallo Kurt,
Zitat von: Kurt77 am 24 August 2020, 20:49:15
jetzt habe ich all Deine Ratschläge befolgt, aber ich kann machen, was ich will: Dtmf-Codes werden nicht erkannt. Hier ein List ohne vorhergehendes reset.
Auch diesen Vorschlag?
Zitat von: Wzut am 24 August 2020, 17:31:57
Kannst du den Test mal mit einem anderen Telefon machen um zu sehen ob die Event Zeiten dann größer sind ?
Zum Vergleich kann man gut die FritzFON-App hernehmen. Dann kriegen wir raus, ob es an Deiner FHEM-Insrtanz oder am Client-Telefon liegt.
VG plin
Hallo plin,
ich hatte beim letzten log mit einem Telefon"Wohnzimmer" statt mit "Buero" telefoniert.
Jetzt habe ich's nochmal, Deinem Rat folgend, mit der fritzappfon (auf einem IPhone) getestet. Auch mit der App wird kein dtmf-Code erkannt.
@Jamo:
Ich versuche es mal, aber ich glaube es wird schiefgehen.
define irgendwas irgendwas
Sieht das für Dich gut aus?
Danke und Gruß,
Kurt
Du musst deinen code zwischen dem [ code ] und (also HIER) dem [ \code ] reinkopieren, dann siehts so aus:
Du musst deinen code zwischen dem und (also HIER) dem reinkopieren, dann siehts so aus:
Hallo Jamo,
versuchen wir es nochmal.
define irgendwas irgendwas
Passt das jetzt so?
Danke und Gruß,
Kurt
Ja, sieht gut aus. Danke!
@plin : schau dir mal den Teil von Kurt an :
2020.08.24 20:38:36 5: MySipClient[655], cb_est_dtmf
2020.08.24 20:38:36 5: MySipClient, readingS:caller_state Val:established
2020.08.24 20:38:46 5: MySipClient, listen process 655 found
eigentlich müsste direkt nach dem cb_est_dtmf ein while dtmf_loop : start reinvite1 kommen
Da dieses fehlt sieht das für mich aus als ob das Programm noch in der darüberliegenden $ua->loop(\$call) festhängt und dann nicht in die while($dtmf_loop) Schleife geht.
Das würde auch erklären warum er dann die Ansage von $msg1 durch $call->reinvite nicht bekommt.
Da es nach einem Reset geht, muß das doch bedeuten das nach Ende des ersten Calls irgendeine Variable nicht zurück gesetzt wird innerhalb der großen while(1) Schleife. Ich vermute jetzt fast es hat was mit der Perl Version unter Buster auf sich und vllt. sollte man nochmal an das ToDo im Kommentar gehen : "Was kann davon noch nach while(1) ?"
denn vermutlich ist es jetzt kein "kann" mehr sondern ein "muß" ?
Mir graut etwas davor mein Testsystem komplett auf Buster umzustellen, da ich aktuell noch mit den MAX Modulen einige Baustellen habe, aber über kurz oder lang wird da wohl kein Weg daran vorbeiführen.
[OT on]
@Jamo, lass ihn. Wenn du mit seiner Hardware klar kommen müsstest würden deine Post garantiert noch schlimmer aussehen ....
Ich habe den Fehler einmal gemacht bzw. den Fettnapf gefunden und bei Elektrolurch wegen seiner falsch gesetzten Code Tags mal als Antwort geschrieben "na na, das übern wir aber noch ein bissel"
[OT off]
Hi,
ein paar Tests von meiner Seite.
Ich habe eine SD-Karte mit einem Debian Buster auf armbian erzeugt die in meinem BananaPi halbswegs funktioniert.
- sip_audiofile_dtmf = !Ihre Eingabe bitte
- sip_audiofile_ok = !Danke
- Test mit einem FritzFON C5
1. Anruf: gekrächzte Ansage, #, 6, 6, 6, 6, (alle Tasten werden lt. og erkannt), 7, dtmf_event=67, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1, 2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2, 3, dtmf_event=23, Danke, SIP-Client legt auf
Wiederholung mit dem alten Raspbian Stretch
1. Anruf: gekrächzte Ansage, #, 6, 6, 6, 6, (alle Tasten werden lt. og erkannt), 7, dtmf_event=67, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1, 2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2, 3, dtmf_event=23, Danke, SIP-Client legt auf
reset des listen_dtmf
1. Anruf: gekrächzte Ansage, #, 3, 4, dtmf_event=34, Danke, SIP-Client legt auf
2. Anruf: Danke, #, 1, 2, dtmf_event=12, Danke, SIP-Client legt auf
3. Anruf: Danke, #, 2, 3, dtmf_event=23, Danke, SIP-Client legt auf
Mittels T2S ein Audiofile IhreEingabeBitte.mp3 erzeugt und umbenannt
- sip_audiofile_dtmf = IhreEingabeBitte.mp3
- sip_audiofile_ok = !Danke
1. Anruf: Ihre Eingabe bitte, #, 3, 4, dtmf_event=34, Danke, SIP-Client legt auf
2. Anruf: Ihre Eingabe bitte, #, 1, 2, dtmf_event=12, Danke, SIP-Client legt auf
Fazit
- Debian Strech und Buster machen keinen Unterschied
- Bei Textvorgabe und Nutzung von T2S klappt's nur einem nach einem reset
- Bei file für die Anage und Nutzung von T2S für's OK klappt's jedes Mal
VG plin
Zitat von: plin am 25 August 2020, 18:43:08
- Debian Strech und Buster machen keinen Unterschied
- Bei Textvorgabe und Nutzung von T2S klappt's nur einem nach einem reset
- Bei file für die Anage und Nutzung von T2S für's OK klappt's jedes Mal
OK, THX , damit wäre das Thema Buster vs. Stretch erste inmal vom Tisch.
Die anderen beiden Punkte hatte ich ja auch schon beschrieben, da werde ich auf jeden Fall nachbessern.
BTW: man muss die Datei von T2S nicht unbedingt umbennen, ich habe sie bei mir einfach direkt eingetragen :
attr sip sip_audiofile_dtmf cache/d15c45ea5f2d96592ed16b06899fcf5b.mp3
attr sip sip_audiofile_ok cache/f9757ae70d3bb25d746ee1fa4f8d08a9.mp3
Zitat von: Wzut am 25 August 2020, 19:21:32
BTW: man muss die Datei von T2S nicht unbedingt umbennen, ich habe sie bei mir einfach direkt eingetragen :
mmmh, was sagt Dir "d15c45ea5f2d96592ed16b06899fcf5b"? Ich finde da "IhreEingabeBitte" deutlich transparenter (sozusagen WYSIWYG) :).
Hallo,
danke für die Mühen, aber mir hilft das leider nicht.
Immer das gleiche Fehlerbild auch wenn ich Dateien einbinde.
Gruß Kurt
Das ist mir schon klar, aber du hast ein Fehlerbild das wir z.Z. nicht nachstellen können.
Könnten wir es würden wir garantiert auch eine Lösung aus dem Hut zaubern.
Ich bin z.Z. dabei intern im Modul etwas aufzuräumen ( Stichwort PBP ) daher kann ich dir im Moment nur anbieten die nächsten Tage eine Betaversion hier reinzustellen mit noch mehr Log Ausgaben.
Achso : eine Idee um dein Problem quick und dirty zu umgehen hätte ich noch, dazu musst du aber verraten was du mit den erkannten DTMF Reading machen willst.
@Kurt: Welche Net::SIP-Version nutzt Du? Ich bin bei our $VERSION = '0.808';
@plin, ich dachte Buster liefert 0.820 aus ? Auf CPAN ist er inzwischen bei 0.823
Zitat von: Wzut am 26 August 2020, 09:58:13
@plin, ich dachte Buster liefert 0.820 aus ? Auf CPAN ist er inzwischen bei 0.823
Das ist die in meinem FHEM-Dev aktive Version mit der ich die oben genannten Tests unter Stretch durchgeführt habe. Buster muss ich erst mal wieder reinstecken/hochfahren.
@Wzut: ich will damit Sonos steuern: Titel vorZZurück, Playlist starten, Radiosender starten, Player gruppiren.
@plin: Wie ermittle ich die Version?
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 26 August 2020, 12:31:26
@plin: Wie ermittle ich die Version?
cpan -D Net::SIP
Unter Buster sollte dann
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.823.tar.gz
/usr/share/perl5/Net/SIP.pm
Installed: 0.820
CPAN: 0.823 Not up to date
Steffen Ullrich (SULLR)
Steffen_Ullrich@genua.de
ausgegeben werden.
Zitat von: plin am 26 August 2020, 13:17:36
cpan -D Net::SIP
Unter Buster sollte dann
Net::SIP
-------------------------------------------------------------------------
(no description)
S/SU/SULLR/Net-SIP-0.823.tar.gz
/usr/share/perl5/Net/SIP.pm
Installed: 0.820
CPAN: 0.823 Not up to date
Steffen Ullrich (SULLR)
Steffen_Ullrich@genua.de
ausgegeben werden.
Hallo plin,
diesen Bildschirm erhalte ich auch.
Es gibt einen Unterschied:
Installed: 0.687
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 26 August 2020, 14:03:08
Es gibt einen Unterschied:
Installed: 0.687
hast Du die mittels
sudo cpan install Net::SIP
oder
sudo apt-get install libnet-sip-perl
installiert?
Probier's mal mit einem Update.
langsam : er schrieb Debian 8.0 und das wäre dann Jessie !
9 = Stretch
10 = Buster
und zu Jessie würde auch diese uralt 0.6x Version von Net::SIP passen.
Wieso war ich die ganze Zeit bei Buster??? Ich gestern mein FHEM-Dev auf Buster hochgezogen damit ich Vergleichstests durchführen kann???
Update Jow, habe gerade noch mal zurück geblätter.t Gab es da vor langer Zeit nicht mal Probleme mit Net::SIP und der DTMF-Erkennung? Wir könnten jetzt Microsoft spielen und fragen "Haben sie die aktuellste Version installiert?"
Update2 Ich hätte noch ein 2016-07-13-raspbian-jessie-bpi-m1-m1p-r1.img.zip Image ...
ja sorry, ich war geistig irgendwie bei Buster. Habs dann aber auch nochmal gelesen und die Debian 8.0 gesehen
(Kurt hätte ja auch mal Einspruch einlegen können ... )
Anyway , ich sehe da jetzt zwei Lösungen :
a. wenn es beim erstenmal klappt , muß sowieso ein notify her das den Dispatcher spielt um die verschiedenen Sonos Kommandos abzusetzen. Da würde ich am Ende einfach ein reset dazu packen, dann ist jedes nächste Mal wieder das erste Mal.
b. Kurt ich habe ja keine Ahnung wie fit du mit dem Telefon bist, aber wäre es nicht viel einfacher statt einem Client und zig DTMF Kommandos einfach pro Kommando einen Client zu definieren ?
BSP jetzt : wählen **620 , warten, stern, zwei Zahlen macht in Summe min 7 Tasten bis Sonos das macht was es soll
oder **620 und ringtime runter auf 1 , Sonos macht X , **621 Sonos macht Y , d.h. nur 4 Tasten und wesentlich schnellere Umsetzung
Zitat von: Kurt77 am 26 August 2020, 12:31:26
@Wzut: ich will damit Sonos steuern: Titel vorZZurück, Playlist starten, Radiosender starten, Player gruppiren.
In Verbindung mit dem SONOS-Modul? Ich habe mir für's Wohnzimmer mal ein kleines 7" Tab im Angebot für 50 EUR gekauft. Damit ist die Steuerung etwas eleganter als mit 89 DTMF-Codes (die man sich ja auch noch merken muss).
Es gibt dann auch noch die Homebridge-Variante für Apple/iPhone, um FHEM via Siri zu steuern.
Hallo,
also ich würde die Steurung über die dtmf-Codes und damit über physische Knöpfe bevorzugen.
@plin: Siri wäre natürlich eine Möglichkeit, aber ich ziehe das Drücken dem Quatschen vor.
@Wzut: Wieviele "Telefone" soll ich denn da implementierern! Ich drücke auch nicht 7-mal, sondern lege mir die **621 auf eine Kurztaste.
Und "Buster" ist mir nicht aufgefallen: Ich dachte Buster wäre das Release vor Jessie gewesen.
Steckt jetzt bitte keine Arbeit mehr hier rein. Ich beschäftige mich jetzt mal mit einr Migration von Jessie nach Buster und melde mich dann wieder.
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 26 August 2020, 16:41:22
Steckt jetzt bitte keine Arbeit mehr hier rein. Ich beschäftige mich jetzt mal mit einr Migration von Jessie nach Buster und melde mich dann wieder.
Ich habe da eben diese ganz schwache Erinnerung, dass wir am Anfang einige Probleme mit einer frühen Version des Net::SIP hatten. Also: viel Erfolg.
Zitat von: Kurt77 am 26 August 2020, 16:41:22
Steckt jetzt bitte keine Arbeit mehr hier rein. Ich beschäftige mich jetzt mal mit einr Migration von Jessie nach Buster und melde mich dann wieder.
Ach ja
- Debian 8 = Jessie
- Debian 9 = Stretch
- Debian 10 = Buster
Du musst als 2 Releases weiter. Ich würde eine neue SD-Karte nehmen, darauf Debian Buster + FHEM installieren und dann dein FHEM rüberziehen.
ja neue SD ist auf jedenfall entspannter als das bisherige System gleich auf den Kopf zu stellen. Für jemand der nicht so fit ist auch eine gute Gelegenheit gleich mal FHEM Backup & Restore zu üben.
Ich als bekennender Gegner des weit verbreiteten Update Wahnsinns habe bis vor ein Wochen mein aktuelles System auf einem Debian (7) Wheezy mit uralte FHEM gefahren, allerdings mit einer Net::SIP Version 0.810
Ich würde daher ersteinmal versuchen mittels CPAN die alte Net:SIP auf die aktuelle zu bringen ohne gleich den ganzen Unterbau und FHEM umzukrempeln.
Zitat von: Wzut am 27 August 2020, 08:49:28
Ich würde daher ersteinmal versuchen mittels CPAN die alte Net:SIP auf die aktuelle zu bringen ohne gleich den ganzen Unterbau und FHEM umzukrempeln.
Hallo Wzut,
das will ich gerne nochmal versuchen. Aber wie mache ich das?
Es gibt im Wiki einen Link, der auf einen Forenbeitrag aus 2016 verweist. Ist das noch aktuell?
Danke und Gruß,
Kurt
in der Regel am einfachsten mit : cpan install Net::SIP
ja im Wiki gibt es den alten Link, damals hatten viele User Probleme ihr Paket mit cpan auf den aktuellen Stand zu bingen.
Der dort beschrieben Weg zu Fuß sollte auch heute noch gehen allerdings muß immer wenn dort
0.687 auftaucht das durch die aktuelle Versionsnr erzsetzt werden. Aktuell ist die Version 0.823 vom 15 Juli 2020 -> https://cpan.metacpan.org/authors/id/S/SU/SULLR/Net-SIP-0.823.tar.gz
Hallo Wzut,
0.823 ist jetzt installiert. Keine Änderung.
Gruß Kurt
Hallo Kurt,
welches Raspberry Pi Modell hast Du?
VG plin
wird diese version denn auch wirklich benutzt?
wenn ich es einigermassen verstanden habe, gibt es eine "path" variable (INC oder so), nach der perl zusätzliche perlmodule sucht.
wenn es mehrere dateien in unterschiedlichen pfaden gibt, "gewinnt" der erste.
damals bei meinem jessie hatte ich 2 sip dateien gefunden und hatte mich immer gefragt, welche genutzt wird. da ich keinerlei probleme hatte, habe ich es nie wirklich untersucht.
ich glaube cpan und apt-get hatten unterschiedliche pfade genutzt.
ich denke, es wäre ganz hilfreich, wenn das sipmodul die genutzte version in einem internal speichern würde.
Hallo Frank,
das ist, wie ich finde, ein guter Punkt.
Habe nämlich tatsächlich beide Kommandos ausgeführt.
Wenn ich aber in der Konsole
find / NET::SIP*
eingebe, finde ich nichts.
Gruß Kurt
P.s.: @plin: Model 3b.
Zitat von: Kurt77 am 27 August 2020, 12:58:03
P.s.: @plin: Model 3b.
ok, dann können wir Performance-Probleme ausschließen (die gab's nur beim Modell 1)
Zitat von: frank am 27 August 2020, 12:27:49
wenn ich es einigermassen verstanden habe, gibt es eine "path" variable (INC oder so), nach der perl zusätzliche perlmodule sucht.
perl -e "print qq(@INC)"
Zitat von: Kurt77 am 27 August 2020, 12:58:03
find / NET::SIP*
eingebe, finde ich nichts.
ist klar , weil es das so nicht gibt !
Hangelt man sich aber den Suchpfad entlang findet sich irgendwo unterhalb von Net ein Verzeichniss SIP
wenn also mittels find gesuchen wird dann direkt nach SIP.pm oder SIP.pod suchen
Es geht auch so
perl -MNet::SIP -e 'print $Net::SIP::VERSION ."\n";'
@Wzut: Vielleicht sollten wir die Net::SIP-Version noch unter INTERNALS ausweisen. Das erspart dann Rückfragen.
dein Wunsch ist mir Befehl, in der nächsten Version :)
Ich habe eh noch vor Loredos Installer direkt zu unterstützen , dann wird das Updaten von Net::SIP auch einfacher.
Zitat von: plin am 27 August 2020, 14:46:51
Es geht auch so
perl -MNet::SIP -e 'print $Net::SIP::VERSION ."\n";'
Hallo plin,
und diese Abfrage bringt als Ergebnis 0.823.
Gruß Kurt
tja, eigentlich wollte ich Kurt einen Zugang zu meiner FHEM-Dev-Instanz einrichten, damit wir sein Endgerät FirtzFON M als Ursache ausschließen können. Aber es kam Erkenntnisreicher.
Internes FritzFON C52020.08.27 19:55:50 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=537B17B40BA06728
2020.08.27 19:55:50 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:55:50 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:55:50 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:55:50 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:55:50 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:55:50 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:55:50 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:55:50 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:55:51 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:55:55 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:55:55 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:55:55 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:55:58 5: SipTest[2726], DTMF Event: # - 368 ms
2020.08.27 19:55:58 5: SipTest[2726], DTMF Event: # - 38 ms
2020.08.27 19:55:59 5: SipTest[2726], DTMF Event: 1 - 67 ms
2020.08.27 19:55:59 5: SipTest[2726], DTMF Event: 1 - 39 ms
2020.08.27 19:55:59 5: SipTest[2726], DTMF Event: 2 - 609 ms
2020.08.27 19:55:59 5: SipTest[2726], DTMF: 2 , Anz: 2
2020.08.27 19:55:59 5: SipTest[2726], DTMF Event: 2 - 54 ms
2020.08.27 19:56:05 5: SipTest[2726], DTMF Event: 6 - 18 ms
2020.08.27 19:56:07 5: SipTest[2726], DTMF Event: # - 204 ms
2020.08.27 19:56:07 5: SipTest[2726], DTMF Event: # - 20 ms
2020.08.27 19:56:29 5: SipTest[2726], DTMF Event: 5 - 878 ms
2020.08.27 19:56:29 5: SipTest[2726], DTMF: 5 , Anz: 2
2020.08.27 19:56:30 5: SipTest[2726], DTMF Event: 4 - 889 ms
2020.08.27 19:56:30 5: SipTest[2726], DTMF: 54 , Anz: 3
2020.08.27 19:56:30 5: SipTest, readingS:dtmf_event Val:54
2020.08.27 19:56:31 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:56:31 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:56:31 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:56:32 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:56:32 5: SipTest, readingB:caller Val:none
2020.08.27 19:56:32 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 19:56:32 5: SipTest, readingB:caller_time Val:37
2020.08.27 19:56:32 5: SipTest, readingB:caller_nr Val:---
2020.08.27 19:56:32 5: SipTest, readingB:caller_name Val:---
2020.08.27 19:56:32 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:56:32 5: SipTest[2726], while(1)
2020.08.27 19:56:46 5: SipTest, listen process 2726 found
2020.08.27 19:56:46 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=D7DE7E9A7CA68E07
2020.08.27 19:56:46 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:56:46 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:56:46 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:56:46 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:56:46 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:56:46 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:56:46 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:56:46 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:56:47 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:56:51 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:56:51 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:56:51 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:56:54 5: SipTest[2726], DTMF Event: # - 884 ms
2020.08.27 19:56:55 5: SipTest[2726], DTMF Event: # - 40 ms
2020.08.27 19:56:55 5: SipTest[2726], DTMF Event: 5 - 824 ms
2020.08.27 19:56:55 5: SipTest[2726], DTMF: 5 , Anz: 2
2020.08.27 19:56:56 5: SipTest[2726], DTMF Event: 5 - 40 ms
2020.08.27 19:56:56 5: SipTest[2726], DTMF Event: 6 - 562 ms
2020.08.27 19:56:56 5: SipTest[2726], DTMF: 56 , Anz: 3
2020.08.27 19:56:56 5: SipTest, readingS:dtmf_event Val:56
2020.08.27 19:56:56 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:56:56 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:56:56 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:56:57 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:56:57 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:56:57 5: SipTest, readingB:caller Val:none
2020.08.27 19:56:57 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 19:56:57 5: SipTest, readingB:caller_time Val:6
2020.08.27 19:56:57 5: SipTest, readingB:caller_nr Val:---
2020.08.27 19:56:57 5: SipTest, readingB:caller_name Val:---
2020.08.27 19:56:57 5: SipTest[2726], while(1)
2020.08.27 19:57:12 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=90A634458E3D3B07
2020.08.27 19:57:12 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:57:12 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:57:12 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:57:13 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:57:13 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:57:13 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:57:13 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:57:13 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:57:13 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:57:18 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:57:18 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:57:18 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:57:21 5: SipTest[2726], DTMF Event: # - 480 ms
2020.08.27 19:57:23 5: SipTest[2726], DTMF Event: 2 - 118 ms
2020.08.27 19:57:23 5: SipTest[2726], DTMF: 2 , Anz: 2
2020.08.27 19:57:23 5: SipTest[2726], DTMF Event: 2 - 39 ms
2020.08.27 19:57:23 5: SipTest[2726], DTMF Event: 3 - 700 ms
2020.08.27 19:57:23 5: SipTest[2726], DTMF: 23 , Anz: 3
2020.08.27 19:57:23 5: SipTest, readingS:dtmf_event Val:23
2020.08.27 19:57:23 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:57:23 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:57:23 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:57:23 5: SipTest[2726], DTMF Event: 3 - 42 ms
2020.08.27 19:57:24 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:57:24 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:57:24 5: SipTest, readingB:caller Val:none
2020.08.27 19:57:24 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 19:57:24 5: SipTest, readingB:caller_time Val:6
2020.08.27 19:57:24 5: SipTest, readingB:caller_nr Val:---
2020.08.27 19:57:24 5: SipTest, readingB:caller_name Val:---
2020.08.27 19:57:24 5: SipTest[2726], while(1)
2020.08.27 19:57:43 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=775B66FB048503F3
2020.08.27 19:57:43 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:57:43 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:57:43 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:57:43 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:57:43 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:57:43 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:57:43 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:57:43 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:57:43 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:57:48 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:57:48 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:57:49 5: SipTest, listen process 2726 found
2020.08.27 19:57:49 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:57:51 5: SipTest[2726], DTMF Event: # - 47 ms
2020.08.27 19:57:51 5: SipTest[2726], DTMF Event: 4 - 633 ms
2020.08.27 19:57:52 5: SipTest[2726], DTMF Event: 5 - 233 ms
2020.08.27 19:57:52 5: SipTest[2726], DTMF Event: 5 - 27 ms
2020.08.27 19:57:59 5: SipTest[2726], DTMF Event: # - 773 ms
2020.08.27 19:57:59 5: SipTest[2726], DTMF Event: # - 19 ms
2020.08.27 19:58:04 5: SipTest[2726], DTMF Event: 4 - 453 ms
2020.08.27 19:58:04 5: SipTest[2726], DTMF: 4 , Anz: 2
2020.08.27 19:58:04 5: SipTest[2726], DTMF Event: 4 - 19 ms
2020.08.27 19:58:05 5: SipTest[2726], DTMF Event: 5 - 393 ms
2020.08.27 19:58:05 5: SipTest[2726], DTMF: 45 , Anz: 3
2020.08.27 19:58:05 5: SipTest, readingS:dtmf_event Val:45
2020.08.27 19:58:05 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:58:05 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:58:05 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:58:06 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:58:06 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:58:06 5: SipTest, readingB:caller Val:none
2020.08.27 19:58:06 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 19:58:06 5: SipTest, readingB:caller_time Val:18
2020.08.27 19:58:06 5: SipTest, readingB:caller_nr Val:---
2020.08.27 19:58:06 5: SipTest, readingB:caller_name Val:---
2020.08.27 19:58:06 5: SipTest[2726], while(1)
2020.08.27 19:58:13 4: SipTest[2726], register new expire : 2020-08-27 20:03:13
2020.08.27 19:58:13 5: SipTest, readingB:state Val:listen_dtmf
2020.08.27 19:58:13 5: SipTest, readingB:listen_alive Val:2726
2020.08.27 19:58:13 5: SipTest, readingB:expire Val:300
2020.08.27 19:58:29 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=F06305397E0B5558
2020.08.27 19:58:29 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:58:29 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:58:29 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:58:29 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:58:29 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:58:29 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:58:29 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:58:29 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:58:29 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:58:34 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:58:34 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:58:34 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:58:37 5: SipTest[2726], DTMF Event: 9 - 20 ms
2020.08.27 19:58:37 5: SipTest[2726], DTMF Event: # - 693 ms
2020.08.27 19:58:38 5: SipTest[2726], DTMF Event: 7 - 254 ms
2020.08.27 19:58:38 5: SipTest[2726], DTMF: 7 , Anz: 2
2020.08.27 19:58:38 5: SipTest[2726], DTMF Event: 7 - 39 ms
2020.08.27 19:58:38 5: SipTest[2726], DTMF Event: 8 - 674 ms
2020.08.27 19:58:38 5: SipTest[2726], DTMF: 78 , Anz: 3
2020.08.27 19:58:38 5: SipTest, readingS:dtmf_event Val:78
2020.08.27 19:58:38 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:58:38 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:58:38 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:58:38 5: SipTest[2726], DTMF Event: 8 - 20 ms
2020.08.27 19:58:39 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:58:39 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:58:39 5: SipTest, readingB:caller Val:none
2020.08.27 19:58:39 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 19:58:39 5: SipTest, readingB:caller_time Val:5
2020.08.27 19:58:39 5: SipTest, readingB:caller_nr Val:---
2020.08.27 19:58:39 5: SipTest, readingB:caller_name Val:---
2020.08.27 19:58:39 5: SipTest[2726], while(1)
2020.08.27 19:58:52 5: SipTest, listen process 2726 found
2020.08.27 19:58:58 5: SipTest[2726], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=567DAA2F66B58FBD
2020.08.27 19:58:58 4: SipTest[2726], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.08.27 19:58:58 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.08.27 19:58:58 5: SipTest, readingB:caller_nr Val:**611
2020.08.27 19:58:58 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.08.27 19:58:58 5: SipTest, readingB:caller_time Val:0
2020.08.27 19:58:58 4: SipTest[2726], cb_create : INVITE
2020.08.27 19:58:58 5: SipTest, readingB:caller_state Val:calling
2020.08.27 19:58:58 5: SipTest[2726], cb_invite_dtmf
2020.08.27 19:58:58 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 19:59:03 5: SipTest[2726], cb_est_dtmf
2020.08.27 19:59:03 5: SipTest, readingS:caller_state Val:established
2020.08.27 19:59:03 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 19:59:05 5: SipTest[2726], DTMF Event: # - 536 ms
2020.08.27 19:59:06 5: SipTest[2726], DTMF Event: 1 - 77 ms
2020.08.27 19:59:06 5: SipTest[2726], DTMF Event: 2 - 496 ms
2020.08.27 19:59:06 5: SipTest[2726], DTMF: 2 , Anz: 2
2020.08.27 19:59:06 5: SipTest[2726], DTMF Event: 2 - 40 ms
2020.08.27 19:59:11 5: SipTest[2726], DTMF Event: 1 - 897 ms
2020.08.27 19:59:11 5: SipTest[2726], DTMF: 21 , Anz: 3
2020.08.27 19:59:11 5: SipTest, readingS:dtmf_event Val:21
2020.08.27 19:59:11 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 19:59:11 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 19:59:12 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 19:59:12 5: SipTest[2726], DTMF Event: 1 - 5 ms
2020.08.27 19:59:12 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 19:59:12 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 19:59:13 5: SipTest[2726], while(1)
2020.08.27 19:59:13 5: SipTest, readingB:caller Val:none
2020.08.27 19:59:13 5: SipTest, readingB:caller_state Val:hangup
FritzFON App auf dem iPhone2020.08.27 20:05:33 5: SipTest[2726], SIP_filter : "iPhone von Peter" <sip:**626@fritz.box>;tag=6923EED00BF11E4D
2020.08.27 20:05:33 4: SipTest[2726], SIP_filter: caller iPhone von Peter sip:**626@fritz.box, caller_nr **626, caller_name iPhone von Peter
2020.08.27 20:05:33 5: SipTest, readingB:caller Val:iPhone von Peter sip:**626@fritz.box
2020.08.27 20:05:33 5: SipTest, readingB:caller_nr Val:**626
2020.08.27 20:05:33 5: SipTest, readingB:caller_name Val:iPhone von Peter
2020.08.27 20:05:33 5: SipTest, readingB:caller_time Val:0
2020.08.27 20:05:33 5: SipTest, readingB:caller_state Val:calling
2020.08.27 20:05:33 4: SipTest[2726], cb_create : INVITE
2020.08.27 20:05:33 5: SipTest[2726], cb_invite_dtmf
2020.08.27 20:05:33 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 20:05:38 5: SipTest[2726], cb_est_dtmf
2020.08.27 20:05:38 5: SipTest, readingS:caller_state Val:established
2020.08.27 20:05:38 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 20:05:40 5: SipTest[2726], DTMF Event: # - 20 ms
2020.08.27 20:05:44 4: SipTest[2726], register new expire : 2020-08-27 20:10:44
2020.08.27 20:05:44 5: SipTest, readingB:state Val:listen_dtmf
2020.08.27 20:05:44 5: SipTest, readingB:listen_alive Val:2726
2020.08.27 20:05:44 5: SipTest, readingB:expire Val:300
2020.08.27 20:05:44 5: SipTest[2726], DTMF Event: 9 - 59 ms
2020.08.27 20:05:47 5: SipTest[2726], DTMF Event: # - 344 ms
2020.08.27 20:05:47 5: SipTest[2726], DTMF Event: 8 - 663 ms
2020.08.27 20:05:47 5: SipTest[2726], DTMF: 8 , Anz: 2
2020.08.27 20:05:47 5: SipTest[2726], DTMF Event: 9 - 949 ms
2020.08.27 20:05:47 5: SipTest[2726], DTMF: 89 , Anz: 3
2020.08.27 20:05:47 5: SipTest, readingS:dtmf_event Val:89
2020.08.27 20:05:48 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 20:05:48 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 20:05:48 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 20:05:49 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 20:05:49 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 20:05:49 5: SipTest, readingB:caller Val:none
2020.08.27 20:05:49 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 20:05:49 5: SipTest, readingB:caller_time Val:11
2020.08.27 20:05:49 5: SipTest, readingB:caller_nr Val:---
2020.08.27 20:05:49 5: SipTest, readingB:caller_name Val:---
2020.08.27 20:05:49 5: SipTest[2726], while(1)
2020.08.27 20:06:13 5: SipTest, listen process 2726 found
2020.08.27 20:06:18 5: SipTest[2726], SIP_filter : "iPhone von Peter" <sip:**626@fritz.box>;tag=CB4B8B914C2B6F89
2020.08.27 20:06:18 4: SipTest[2726], SIP_filter: caller iPhone von Peter sip:**626@fritz.box, caller_nr **626, caller_name iPhone von Peter
2020.08.27 20:06:18 5: SipTest, readingB:caller Val:iPhone von Peter sip:**626@fritz.box
2020.08.27 20:06:18 5: SipTest, readingB:caller_nr Val:**626
2020.08.27 20:06:18 5: SipTest, readingB:caller_name Val:iPhone von Peter
2020.08.27 20:06:18 5: SipTest, readingB:caller_time Val:0
2020.08.27 20:06:18 5: SipTest, readingB:caller_state Val:calling
2020.08.27 20:06:18 4: SipTest[2726], cb_create : INVITE
2020.08.27 20:06:18 5: SipTest[2726], cb_invite_dtmf
2020.08.27 20:06:19 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 20:06:23 5: SipTest[2726], cb_est_dtmf
2020.08.27 20:06:24 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 20:06:24 5: SipTest, readingS:caller_state Val:established
2020.08.27 20:06:26 5: SipTest[2726], DTMF Event: 9 - 43 ms
2020.08.27 20:06:26 5: SipTest[2726], DTMF Event: # - 866 ms
2020.08.27 20:06:27 5: SipTest[2726], DTMF Event: 5 - 148 ms
2020.08.27 20:06:27 5: SipTest[2726], DTMF: 5 , Anz: 2
2020.08.27 20:06:27 5: SipTest[2726], DTMF Event: 2 - 364 ms
2020.08.27 20:06:27 5: SipTest[2726], DTMF: 52 , Anz: 3
2020.08.27 20:06:27 5: SipTest, readingS:dtmf_event Val:52
2020.08.27 20:06:27 5: SipTest[2726], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.27 20:06:27 5: SipTest[2726], while dtmf_loop : reinvite2
2020.08.27 20:06:27 5: SipTest[2726], while dtmf_loop : after reinvite2 0 , 0
2020.08.27 20:06:28 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.08.27 20:06:28 5: SipTest[2726], end while dtmf_loop, byebye : 0
2020.08.27 20:06:28 5: SipTest, readingB:caller Val:none
2020.08.27 20:06:28 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 20:06:28 5: SipTest, readingB:caller_time Val:5
2020.08.27 20:06:28 5: SipTest, readingB:caller_nr Val:---
2020.08.27 20:06:28 5: SipTest, readingB:caller_name Val:---
2020.08.27 20:06:28 5: SipTest[2726], while(1)
2020.08.27 20:06:43 5: SipTest[2726], SIP_filter : "iPhone von Peter" <sip:**626@fritz.box>;tag=89A4399E862215C1
2020.08.27 20:06:43 4: SipTest[2726], SIP_filter: caller iPhone von Peter sip:**626@fritz.box, caller_nr **626, caller_name iPhone von Peter
2020.08.27 20:06:43 4: SipTest[2726], cb_create : INVITE
2020.08.27 20:06:43 5: SipTest[2726], cb_invite_dtmf
2020.08.27 20:06:43 5: SipTest, readingB:caller Val:iPhone von Peter sip:**626@fritz.box
2020.08.27 20:06:43 5: SipTest, readingB:caller_nr Val:**626
2020.08.27 20:06:43 5: SipTest, readingB:caller_name Val:iPhone von Peter
2020.08.27 20:06:43 5: SipTest, readingB:caller_time Val:0
2020.08.27 20:06:43 5: SipTest, readingB:caller_state Val:calling
2020.08.27 20:06:43 5: SipTest, readingS:caller_state Val:ringing
2020.08.27 20:06:48 5: SipTest[2726], cb_est_dtmf
2020.08.27 20:06:48 5: SipTest, readingS:caller_state Val:established
2020.08.27 20:06:48 5: SipTest[2726], while dtmf_loop : start reinvite1
2020.08.27 20:06:54 5: SipTest[2726], DTMF Event: # - 19 ms
2020.08.27 20:06:55 5: SipTest[2726], DTMF Event: 5 - 450 ms
2020.08.27 20:06:56 5: SipTest[2726], DTMF Event: 6 - 770 ms
2020.08.27 20:06:57 5: SipTest[2726], DTMF Event: 8 - 40 ms
2020.08.27 20:07:02 5: SipTest[2726], DTMF Event: 4 - 20 ms
2020.08.27 20:07:05 5: SipTest[2726], DTMF Event: 5 - 877 ms
2020.08.27 20:07:06 5: SipTest[2726], DTMF Event: 6 - 116 ms
2020.08.27 20:07:08 5: SipTest[2726], SIP_bye : HASH(0x3c174b0)
2020.08.27 20:07:08 5: SipTest, readingB:caller Val:none
2020.08.27 20:07:08 5: SipTest[2726], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.27 20:07:08 5: SipTest[2726], aufgelegt
2020.08.27 20:07:08 5: SipTest[2726], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.27 20:07:08 5: SipTest[2726], end while dtmf_loop, byebye : 1
2020.08.27 20:07:08 5: SipTest[2726], while(1)
2020.08.27 20:07:08 5: SipTest, readingB:caller_state Val:hangup
2020.08.27 20:07:08 5: SipTest, readingB:caller_time Val:20
2020.08.27 20:07:08 5: SipTest, readingB:caller_nr Val:---
2020.08.27 20:07:08 5: SipTest, readingB:caller_name Val:---
2020.08.27 20:07:16 5: SipTest, listen process 2726 found
2020.08.27 20:08:14 4: SipTest[2726], register new expire : 2020-08-27 20:13:14
2020.08.27 20:08:14 5: SipTest, readingB:state Val:listen_dtmf
2020.08.27 20:08:14 5: SipTest, readingB:listen_alive Val:2726
2020.08.27 20:08:14 5: SipTest, readingB:expire Val:300
2020.08.27 20:08:19 5: SipTest, listen process 2726 found
Ergebnis: Tastendruck ist nicht gleich Tastendruck. Hat Wzut ja auch so programmiert, um Tastenpreller, Pseudo-Tastendrücke etc. zu unterdrücken. Tastendrücke mit Zeiten < 90 msec werden ignoriert.
Meine Erkenntnis von heute
- phys. Telefone geben die Tastendrücke so weiter wie man sie drückt (kurz/lang)
- Smartphones geben die Tastendrücke mit eher festen Dauern weiter - egal ob man kurz oder lang drückt
Effekt: Beim iPhone klappt das mit der Übermittlung der DTMF-Töne fast immer.
Beim FritzFON kommt es nun auf die Tastenkombination an und wieviel Wegstrecke mein Daumen dabei zurücklegen muss. So etwas wie 12 geht zu flüssig von der Hand. Die Tastendrücke werden zu kurz.
Bezogen auf @Kurt: Du hast erwähnt, dass Du die Steuerkombinationen auf Kurzwahltasten legen willst. Ich schätze dabei kommen vorhersagbar lange Tastendrücke bei raus. Es wäre jetzt interessant, wenn Du mal eine Kombination programmieren, an FHEM übermitteln und uns das Log zukommen lassen kannst. Dann sehen wir wie lange die Tastendrücke ausfallen und ob wir die Minimaldauer vielleicht als Attribut vorgeben müssen.
VG plin
sicher die heutige Zeit von min 90ms könnte man leicht via zusätzlichem Attriut ändern, Prellen ist eigentlich sowieso unkritisch da eh immer unterschiedliche Tasten gedrückt werden müssen. Aber IMHO löst das nicht Kurts Grundproblem das ich in Antwort #966 angesprochen habe. Ich denke allerdings immer noch mit dem zusätzlichen Reset des Listen Prozess am Ende des auswertenden notifys würde sich das erst einmal umgehen lassen.
Ich denke Kurt hatte sich zu zwei Problemen geäußert
- der Ansagetext beim n-ten Anruf
- die unsichere Erkennung der Zahlen
Beim Ansagetext hilft der reset. Ich habe noch ein wenig rumgespielt und festgestellt, dass bei Vorgabe eines mp3 oder alaw Files die Ansage bei mir jedes Mal kommt. Nur bei der Version mit Text und T2S hatte ich Probleme.
Bei der Tastenerkennung spielen die Dauer der DTMF-Töne aber auch die Abstände dazwischen bei mir eine Rolle. Davon hängt es ab, ob die Tasten-Kombi erkannt wird oder nicht.
P.S. ich habe
sip_audiofile_dtmf !Zahlen Zahlen Zahlen
sip_audiofile_ok !Danke
gesetzt und sehe im Log
2020.08.28 10:32:53 5: SipTest, readingB:expire Val:300
2020.08.28 10:32:53 5: SipTest[5724], not converted - using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw from cache
2020.08.28 10:32:53 5: SipTest[5724], audio file cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw found
2020.08.28 10:32:53 5: SipTest[5724], not converted - using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw from cache
2020.08.28 10:32:53 5: SipTest[5724], audio file cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw found
2020.08.28 10:32:53 5: SipTest[5724], audio file /opt/fhem/MomentBitteMichael.alaw found
2020.08.28 10:32:53 4: SipTest[5724], using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw for audio_dtmf
2020.08.28 10:32:53 4: SipTest[5724], using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw for audio_ok
2020.08.28 10:32:53 4: SipTest[5724], using /opt/fhem/MomentBitteMichael.alaw for audio_wfp
Da scheint es ein Problem zu geben was dazu führt, dass der OK-Text als Ansage erscheint.
das Problem ist in der nächsten Version gefixt
Zitat von: Wzut am 28 August 2020, 14:30:12
das Problem ist in der nächsten Version gefixt
prima, dann müssen wir jetzt schauen wie Kurt mit dem Tastentiming zurecht kommt
Hallo,
nachdem jetzt v. 0.823 läuft, hat sich die Situation verschlechtert.
- Ganz selten und eher zufällig werden dtmf-Codes erkannt,
- Ein reset bewirkt nur noch, dass eine MP3-Datei (Audio_dtmf) nur kurz angespielt und der Rest abgeschnitten wird.
- Die MP3-Datei sip_audiofile_ok ist noch nie abgespielt worden.
Hier ist der wurm drin.
Gruß Kurt
@Kurt , nochmal : das ist für uns extrem schwierg da wir keine Ahnung haben was bei dir passiert.
Du hast bist jetzt noch kein Log Abschnitt gepostet der vollständig war, entweder du hast von selbst aufgelegt oder du schneidest oben und unten zuviel ab.
Mach doch bitte mal folgendes :
1. stelle listen_type auf none und mache einen reset.
2. setze jetzt wieder listen_type auf dtmf
3. merke dir die uhrzeit und setze set listen -> schau nun ins Log ab diesem set Kommando brauchen wir das Log
4. rufe nun an und drücke solange Tasten bis der Client von sich aus auflegt - auf keinen Fall lege du zuerst auf !
5. schau wieder ins Log , das sind die letzten Zeilen die du posten must
d.h. lieber zuviel posten als zu wenig, wenn das Log zu groß wird pack es in eine Textdatei und hänge die einfach als Attachment an.
Und schneide mehrere Anrufe auf diese Weise mit. Neben der Dauer ist auch der Absatand zwischen den Tastendrücken interessant.
Pack am Besten auch noch ein list des Devices mit dazu, damit wir sehen was aktuell eingestellt ist.
Hallo plin,
hier das log:
2020.08.28 21:35:57 4: MySipClient, Listen new PID : 19168
2020.08.28 21:35:57 4: MySipClient[19168], my parent is 901
2020.08.28 21:35:57 4: MySipClient[19168], trying to use port 5060
2020.08.28 21:35:57 4: MySipClient[19168], register new expire : 2020-08-28 21:40:57
2020.08.28 21:35:57 5: MySipClient[19168], not converted - using cache/de901947c29afa3f195b50e87289aa4c.alaw from cache
2020.08.28 21:35:57 5: MySipClient[19168], audio file cache/de901947c29afa3f195b50e87289aa4c.alaw found
2020.08.28 21:35:57 5: MySipClient[19168], not converted - using cache/ab7acf820e3b2e2fc76c4012a5c7a991.alaw from cache
2020.08.28 21:35:57 5: MySipClient[19168], audio file cache/ab7acf820e3b2e2fc76c4012a5c7a991.alaw found
2020.08.28 21:35:57 4: MySipClient[19168], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.08.28 21:35:57 4: MySipClient[19168], using cache/ab7acf820e3b2e2fc76c4012a5c7a991.alaw for audio_ok
2020.08.28 21:35:57 5: MySipClient, readingB:state Val:listen_dtmf
2020.08.28 21:35:57 5: MySipClient, readingB:listen_alive Val:19168
2020.08.28 21:35:57 5: MySipClient, readingB:expire Val:300
2020.08.28 21:36:18 5: MySipClient[19168], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=ACD3D105C3B5C8B4
2020.08.28 21:36:18 4: MySipClient[19168], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.28 21:36:18 4: MySipClient[19168], cb_create : INVITE
2020.08.28 21:36:18 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.28 21:36:18 5: MySipClient, readingB:caller_nr Val:**610
2020.08.28 21:36:18 5: MySipClient, readingB:caller_name Val:Buero
2020.08.28 21:36:18 5: MySipClient, readingB:caller_time Val:0
2020.08.28 21:36:18 5: MySipClient, readingB:caller_state Val:calling
2020.08.28 21:36:18 5: MySipClient[19168], cb_invite_dtmf
2020.08.28 21:36:18 5: MySipClient, readingS:caller_state Val:ringing
2020.08.28 21:36:21 5: MySipClient[19168], cb_est_dtmf
2020.08.28 21:36:21 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:36:21 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:28 5: MySipClient[19168], DTMF Event: 9 - 86 ms
2020.08.28 21:36:42 5: MySipClient[19168], SIP_bye : HASH(0x4c4bdd8)
2020.08.28 21:36:42 5: MySipClient, readingB:caller Val:none
2020.08.28 21:36:42 5: MySipClient, readingB:caller_state Val:hangup
2020.08.28 21:36:42 5: MySipClient, readingB:caller_time Val:21
2020.08.28 21:36:42 5: MySipClient, readingB:caller_nr Val:---
2020.08.28 21:36:42 5: MySipClient, readingB:caller_name Val:---
2020.08.28 21:36:42 5: MySipClient[19168], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.28 21:36:42 5: MySipClient[19168], aufgelegt
2020.08.28 21:36:42 5: MySipClient[19168], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.28 21:36:42 5: MySipClient[19168], end while dtmf_loop, byebye : 1
2020.08.28 21:36:42 5: MySipClient[19168], while(1)
2020.08.28 21:36:55 5: MySipClient[19168], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=A520D2519865B942
2020.08.28 21:36:55 4: MySipClient[19168], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.28 21:36:55 4: MySipClient[19168], cb_create : INVITE
2020.08.28 21:36:55 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.28 21:36:55 5: MySipClient, readingB:caller_nr Val:**610
2020.08.28 21:36:55 5: MySipClient, readingB:caller_name Val:Buero
2020.08.28 21:36:55 5: MySipClient, readingB:caller_time Val:0
2020.08.28 21:36:55 5: MySipClient, readingB:caller_state Val:calling
2020.08.28 21:36:55 5: MySipClient[19168], cb_invite_dtmf
2020.08.28 21:36:55 5: MySipClient, readingS:caller_state Val:ringing
2020.08.28 21:36:57 5: MySipClient, listen process 19168 found
2020.08.28 21:36:58 5: MySipClient[19168], cb_est_dtmf
2020.08.28 21:36:58 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:58 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:37:06 5: MySipClient[19168], DTMF Event: 8 - 28 ms
2020.08.28 21:37:13 5: MySipClient[19168], SIP_bye : HASH(0x4dc3028)
2020.08.28 21:37:13 5: MySipClient, readingB:caller Val:none
2020.08.28 21:37:13 5: MySipClient, readingB:caller_state Val:hangup
2020.08.28 21:37:13 5: MySipClient, readingB:caller_time Val:15
2020.08.28 21:37:13 5: MySipClient, readingB:caller_nr Val:---
2020.08.28 21:37:13 5: MySipClient, readingB:caller_name Val:---
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.28 21:37:13 5: MySipClient[19168], aufgelegt
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.28 21:37:13 5: MySipClient[19168], end while dtmf_loop, byebye : 1
2020.08.28 21:37:13 5: MySipClient[19168], while(1)
2020.08.28 21:37:35 5: MySipClient[19168], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=0DC3A1127E8E218D
2020.08.28 21:37:35 4: MySipClient[19168], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.28 21:37:35 4: MySipClient[19168], cb_create : INVITE
2020.08.28 21:37:35 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.28 21:37:35 5: MySipClient, readingB:caller_nr Val:**610
2020.08.28 21:37:35 5: MySipClient, readingB:caller_name Val:Buero
2020.08.28 21:37:35 5: MySipClient, readingB:caller_time Val:0
2020.08.28 21:37:35 5: MySipClient, readingB:caller_state Val:calling
2020.08.28 21:37:35 5: MySipClient[19168], cb_invite_dtmf
2020.08.28 21:37:35 5: MySipClient, readingS:caller_state Val:ringing
2020.08.28 21:37:38 5: MySipClient[19168], cb_est_dtmf
2020.08.28 21:37:38 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:37:38 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 377 ms
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 113 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 82 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 85 ms
2020.08.28 21:37:51 5: MySipClient[19168], SIP_bye : HASH(0x4db5cb0)
2020.08.28 21:37:51 5: MySipClient, readingB:caller Val:none
2020.08.28 21:37:51 5: MySipClient, readingB:caller_state Val:hangup
2020.08.28 21:37:51 5: MySipClient, readingB:caller_time Val:13
2020.08.28 21:37:51 5: MySipClient, readingB:caller_nr Val:---
2020.08.28 21:37:51 5: MySipClient, readingB:caller_name Val:---
2020.08.28 21:37:51 5: MySipClient[19168], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.28 21:37:51 5: MySipClient[19168], aufgelegt
2020.08.28 21:37:51 5: MySipClient[19168], while dtmf_loop, okloopbye : 0 , byebye : 1
2020.08.28 21:37:51 5: MySipClient[19168], end while dtmf_loop, byebye : 1
2020.08.28 21:37:51 5: MySipClient[19168], while(1)
2020.08.28 21:37:57 5: MySipClient, listen process 19168 found
2020.08.28 21:38:11 5: MySipClient[19168], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=4CEAC09AA82E4A5F
2020.08.28 21:38:11 4: MySipClient[19168], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.08.28 21:38:11 4: MySipClient[19168], cb_create : INVITE
2020.08.28 21:38:11 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.08.28 21:38:11 5: MySipClient, readingB:caller_nr Val:**610
2020.08.28 21:38:11 5: MySipClient, readingB:caller_name Val:Buero
2020.08.28 21:38:11 5: MySipClient, readingB:caller_time Val:0
2020.08.28 21:38:11 5: MySipClient, readingB:caller_state Val:calling
2020.08.28 21:38:11 5: MySipClient[19168], cb_invite_dtmf
2020.08.28 21:38:11 5: MySipClient, readingS:caller_state Val:ringing
2020.08.28 21:38:14 5: MySipClient[19168], cb_est_dtmf
2020.08.28 21:38:14 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:38:14 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:38:14 5: MySipClient[19168], DTMF Event: * - 901 ms
2020.08.28 21:38:17 5: MySipClient[19168], DTMF Event: 6 - 331 ms
2020.08.28 21:38:17 5: MySipClient[19168], DTMF: 6 , Anz: 2
2020.08.28 21:38:17 5: MySipClient, readingS:dtmf_event Val:6
2020.08.28 21:38:17 5: MySipClient[19168], DTMF Event: 6 - 28 ms
2020.08.28 21:38:20 5: MySipClient[19168], DTMF Event: 6 - 28 ms
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : reinvite2
2020.08.28 21:38:29 4: MySipClient[19168], register new expire : 2020-08-28 21:43:29
2020.08.28 21:38:29 5: MySipClient, readingB:state Val:listen_dtmf
2020.08.28 21:38:29 5: MySipClient, readingB:listen_alive Val:19168
2020.08.28 21:38:29 5: MySipClient, readingB:expire Val:300
jump to the top
Und hier das List:
Internals:
AC /usr/bin/sox
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 19168
NAME MySipClient
NOTIFYDEV mytext2speech
NR 141
NTFY_ORDER 50-MySipClient
STATE listen_dtmf
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-21 21:47:33 call done
2020-08-21 21:47:33 call_attempt 0
2020-08-21 21:47:33 call_state declined
2020-08-21 21:47:33 call_success 0
2020-08-21 21:47:33 call_time 0
2020-08-28 21:38:11 caller Buero sip:**610@fritz.box
2020-08-28 21:38:11 caller_name Buero
2020-08-28 21:38:11 caller_nr **610
2020-08-28 21:38:14 caller_state established
2020-08-28 21:38:11 caller_time 0
2020-08-28 21:38:17 dtmf_event 6
2020-08-28 21:43:29 expire 300
2020-08-23 17:40:44 last_error attr audio_converter not set
2020-08-28 21:43:29 listen_alive 19168
2020-08-28 21:43:29 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 488
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 19168
timeout
Attributes:
T2S_Device mytext2speech
audio_converter sox
disabled 0
history_file ./log/MySipClient.sip
history_size 0
sip_audiofile_dtmf cache/de901947c29afa3f195b50e87289aa4c.mp3
sip_audiofile_ok cache/ab7acf820e3b2e2fc76c4012a5c7a991.mp3
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 1
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
verbose 5
Interessant ist diesmal, dass die "6" tatsächlich meine letzte Eingabe war.
Was is eigentlich mit meinen Code-Tags. Passt das jetzt?
Danke und Gruß,
Kurt
Ja, mit deinen code tags sieht es jetzt super aus und man kann deine Beiträge gut lesen. Danke!
@Kurt, ich drösel dein Log mal etwas auf :
2020.08.28 21:35:57 4: MySipClient[19168], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.08.28 21:35:57 4: MySipClient[19168], using cache/ab7acf820e3b2e2fc76c4012a5c7a991.alaw for audio_ok
das wollte ich sehen, das Modul erkennt zwei gültige Audio Dateien : gut/ok
2020.08.28 21:36:21 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:28 5: MySipClient[19168], DTMF Event: 9 - 86 ms
2020.08.28 21:36:42 5: MySipClient[19168], SIP_bye : HASH(0x4c4bdd8)
mit reinvite1 sollte deine Eingabe Nachricht abgespielt worden sein, gut. Aber dann wurden innnerhalb von 21 Sekunden nur eine Taste erkannt und diese auch noch zu kurz.
und nicht der Client hat aufgelegt sondern du : schlecht
020.08.28 21:36:58 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:58 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:37:06 5: MySipClient[19168], DTMF Event: 8 - 28 ms
2020.08.28 21:37:13 5: MySipClient[19168], SIP_bye : HASH(0x4dc3028)
fast das gleiche beim nächsten Versuch, wieder kam das Ende von dir.
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.28 21:37:13 5: MySipClient[19168], aufgelegt
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop, okloopbye : 0 , byebye : 1
Hier hoffe ich ist dir nur ein Fehler bei copy & paste unterlaufen, (erste und dritte Zeile gleich) das steht so hoffentlich nicht im Log. Bitte mal prüfen
Aber beim nächsten Fehlversuch mit der gedrückten 7 findet sich das so nochmal.
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : reinvite2
das ist nun dein letzter Versuch bei dem die Taste 6 erfolgreich erkannt wurde und mit reinvite2 eigentlich die OK Ansage abgespielt wurde. Hast du die gehört ?
Leider endet dein Log hier, die intressanten Zeilen wären danach gekommen bis zum while(1) .
Wenn die Datei noch vorhanden ist liefere bitte den Rest nach. Bzw nun wäre es wirklich intressant geworden mit einem weiteren Anruf.
Fazit : wurden die Fehlversuche wirklich von dir beendet obwohl ich extra geschrieben hatte das sollst du nicht tun ?
und gibt es im Log nach dem Ende deines Abschnittes einen weiteren Versuch ohne Reset ?
Zitat von: Wzut am 29 August 2020, 08:01:15
@Kurt, ich drösel dein Log mal etwas auf :
2020.08.28 21:35:57 4: MySipClient[19168], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.08.28 21:35:57 4: MySipClient[19168], using cache/ab7acf820e3b2e2fc76c4012a5c7a991.alaw for audio_ok
das wollte ich sehen, das Modul erkennt zwei gültige Audio Dateien : gut/ok
2020.08.28 21:36:21 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:28 5: MySipClient[19168], DTMF Event: 9 - 86 ms
2020.08.28 21:36:42 5: MySipClient[19168], SIP_bye : HASH(0x4c4bdd8)
mit reinvite1 sollte deine Eingabe Nachricht abgespielt worden sein, gut. Aber dann wurden innnerhalb von 21 Sekunden nur eine Taste erkannt und diese auch noch zu kurz.
und nicht der Client hat aufgelegt sondern du : schlecht
020.08.28 21:36:58 5: MySipClient[19168], while dtmf_loop : start reinvite1
2020.08.28 21:36:58 5: MySipClient, readingS:caller_state Val:established
2020.08.28 21:37:06 5: MySipClient[19168], DTMF Event: 8 - 28 ms
2020.08.28 21:37:13 5: MySipClient[19168], SIP_bye : HASH(0x4dc3028)
fast das gleiche beim nächsten Versuch, wieder kam das Ende von dir.
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop : dtmfloop : 0 , byebye : 1
2020.08.28 21:37:13 5: MySipClient[19168], aufgelegt
2020.08.28 21:37:13 5: MySipClient[19168], while dtmf_loop, okloopbye : 0 , byebye : 1
Hier hoffe ich ist dir nur ein Fehler bei copy & paste unterlaufen, (erste und dritte Zeile gleich) das steht so hoffentlich nicht im Log. Bitte mal prüfen
Aber beim nächsten Fehlversuch mit der gedrückten 7 findet sich das so nochmal.
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.08.28 21:38:29 5: MySipClient[19168], while dtmf_loop : reinvite2
das ist nun dein letzter Versuch bei dem die Taste 6 erfolgreich erkannt wurde und mit reinvite2 eigentlich die OK Ansage abgespielt wurde. Hast du die gehört ?
Leider endet dein Log hier, die intressanten Zeilen wären danach gekommen bis zum while(1) .
Wenn die Datei noch vorhanden ist liefere bitte den Rest nach. Bzw nun wäre es wirklich intressant geworden mit einem weiteren Anruf.
Fazit : wurden die Fehlversuche wirklich von dir beendet obwohl ich extra geschrieben hatte das sollst du nicht tun ?
und gibt es im Log nach dem Ende deines Abschnittes einen weiteren Versuch ohne Reset ?
Hallo Wzut,
ja, ich habe aufgelegt, weil nicht automatisch aufgelegt wird und zwar in keienem Fall! Es gibt nach dem kopierten Abschnitt keinen weiteren Anruf ohne reset.
Kopier fehler sind auch auszuschließen, weil ich den gesamten Code in einem Rutsch in den Forenbeitrag kopiert habe.
Die abschließende Audiodatei hab ich nicht gehört.
Es feht kein Code. - Ich habe alles geliefert, was im Log gezeigt wurde.
Gruß Kurt
Zitat von: Kurt77 am 29 August 2020, 11:54:11
ja, ich habe aufgelegt, weil nicht automatisch aufgelegt wird und zwar in keienem Fall! Es gibt nach dem kopierten Abschnitt keinen weiteren Anruf ohne reset.
Hallo Kurt,
Du musst in dem Fall einfach weiter Tasten betätigen. Und zwar so lange, bis zwei davon lang genug gedrückt wurden, um einen 2stelliger Code zu erkennen. Dann sollte der SIP-Client auch auflegen. Spiel ruhig 5 Anrufe auf diese Art durch, damit wir etwas Futter haben wie das Timing aussieht.
Events wie
2020.08.28 21:36:28 5: MySipClient[19168], DTMF Event: 9 - 86 ms
2020.08.28 21:37:06 5: MySipClient[19168], DTMF Event: 8 - 28 ms
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 377 ms
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 113 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 82 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 85 ms
2020.08.28 21:38:14 5: MySipClient[19168], DTMF Event: * - 901 ms
2020.08.28 21:38:17 5: MySipClient[19168], DTMF Event: 6 - 28 ms
2020.08.28 21:38:20 5: MySipClient[19168], DTMF Event: 6 - 28 ms
sind zu kurz (valide Tastenanschläge beginnen bei 90 ms), um als valide durchzugehen. Die werden dann unterdrückt.
VG plin
Zur Info , da wir ja das Thema Net:SIP update via CPAN erst die Tage hatten :
Ich habe meine Testsystem hochgezogen von 0.808 auf die aktuelle 0.823
Wichtig : Debian/Raspian installiert Net/SIP in einem anderem Verzeichniss als CPAN !
CPAN : /usr/local/share/perl/5.24.1/Net/ ( bei mir , ich bin noch 5.24 unter Stretch unterwegs )
Debian : /usr/share/perl5/Net/
Da ich inzwischen die Net:SIP Version im Modul anzeige sah man auch schön das sich nach dem Update an der Anzeige 0.808 nichts geändert hat.
Ich habe dann das /usr/share/perl5/Net/ in /usr/share/perl5/Net_old/ umbennant und /usr/local/share/perl/5.24.1/Net/ dann als /usr/share/perl5/Net/ rüber kopiert.
Und nach einem (zur Sicherheit) reboot hatte ich dann auch meine aktuelle Anzeige im Modul.
hatte cpan seinen pfad nicht in INC eingetragen?
oder ist die position des pfades ungünstig?
ich habe bei mir als letztes ein upgrade auf buster gemacht. dabei wurde INC scheinbar ordentlich aufgeräumt.
somit ist zur zeit die buster version 820 aktiv.
ich schaue demnächst vielleicht mal, was bei mir passiert, wenn ich nun noch mal cpan aktiviere.
Zitat von: plin am 30 August 2020, 09:59:44
Hallo Kurt,
Du musst in dem Fall einfach weiter Tasten betätigen. Und zwar so lange, bis zwei davon lang genug gedrückt wurden, um einen 2stelliger Code zu erkennen. Dann sollte der SIP-Client auch auflegen. Spiel ruhig 5 Anrufe auf diese Art durch, damit wir etwas Futter haben wie das Timing aussieht.
Events wie
2020.08.28 21:36:28 5: MySipClient[19168], DTMF Event: 9 - 86 ms
2020.08.28 21:37:06 5: MySipClient[19168], DTMF Event: 8 - 28 ms
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 377 ms
2020.08.28 21:37:39 5: MySipClient[19168], DTMF Event: # - 113 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 82 ms
2020.08.28 21:37:42 5: MySipClient[19168], DTMF Event: 7 - 85 ms
2020.08.28 21:38:14 5: MySipClient[19168], DTMF Event: * - 901 ms
2020.08.28 21:38:17 5: MySipClient[19168], DTMF Event: 6 - 28 ms
2020.08.28 21:38:20 5: MySipClient[19168], DTMF Event: 6 - 28 ms
sind zu kurz (valide Tastenanschläge beginnen bei 90 ms), um als valide durchzugehen. Die werden dann unterdrückt.
VG plin
Hallo plin,
habe gerade eben 5 Minuten lang nach einem Anruf (**621) auf der Telefontastatur rumgedrückt. Es wird kein dtmf-Code erkannt und es wird auch nicht aufgelegt.
Was tun?
Gruß Kurt
ja das ist für dich vermutlich etwas schwierig , ich lass dabei den Event Monitor laufen und setze den Log Haken,
oder ich mach ein extra Fenster auf in dem ein tail -f aufs Log läuft und dann "sieht" man halt sofort was fehlt.
Anyway, ich kann heute Abend meine aktuelle Beta Version hier einstellen mit dem neuen Attribut um die 90ms kleiner zu machen.
Hallo Wzut,
also habe ich jetzt auch mal den event-monitor aufgemacht. Das Problem ist eben gerade, dass nichts passiert.
Code:
------------------------------------------
20.08.31 11:17:03 5 : MySipClient, listen process 19168 foun
-----------------------------------------
Diese Zeile steht da und wird auch bei Tastendruck nicht aktualisiert. Das einzige ist, dass diese Zeile in regelmäßigen abständen erneut auf dem Bildschirm erscheint.
Gruß Kurt
Das ganze Thema Logging ist bei dir offensichtlich schon sehr merkwürdig, normal sieht man direkt wenn man den Client anwählt und dieser den Ruf annimmt.
Ich vermute fast im Moment nimmt der gar keine Rufe an und in deiner Fritte unter System Ereignisse Telefon hast du Meldungen mit Code 408 ?
Hallo Wzut,
keine Fehlermeldungen im Ereignisprotokoll. Anrufe mit call kommen durch.
Gruß Kurt
Zitat von: Kurt77 am 31 August 2020, 11:49:04
keine Fehlermeldungen im Ereignisprotokoll. Anrufe mit call kommen durch.
Hast Du mal geschaut was im fhem-2020-08.log passiert?
@Wzut: ich habe nach DTNF und Dauer geggoelt und einen Wikipedia-Eintrag gefunden: https://de.wikipedia.org/wiki/Mehrfrequenzwahlverfahren (https://de.wikipedia.org/wiki/Mehrfrequenzwahlverfahren)
Demnach wird bei < 23 ms die Funktion verweigert, bei > 40 ms Signaldauer soll es eine gültige Funktion sein. Da nähern wir uns den Zeiten die das FritzFON M erzeugt.
Da steht aber auch "Für die Dauer eines Tones wird meist (wie bei ZVEI-Tönen) 70 Millisekunden gewählt, damit die Vermittlungseinrichtung den empfangenen Ton sicher erkennen kann. Empfohlen wird eine Dauer von 50–100 ms mit Pausen von 20–50 ms zwischen den Tönen bei Ton- beziehungsweise Ziffernfolgen."
Bei meinem FritzFON C5 sieht es so aus (die Tasten der Reihe nach nur einmal betätigt):
< ohne Eingabe von #>
2020.08.31 13:18:49 5: SipTest[1639], DTMF Event: 1 - 344 ms
2020.08.31 13:18:49 5: SipTest[1639], DTMF Event: 1 - 39 ms
2020.08.31 13:18:51 5: SipTest[1639], DTMF Event: 2 - 744 ms
2020.08.31 13:18:51 5: SipTest[1639], DTMF Event: 2 - 59 ms
2020.08.31 13:18:54 5: SipTest[1639], DTMF Event: 3 - 124 ms
2020.08.31 13:18:54 5: SipTest[1639], DTMF Event: 3 - 60 ms
2020.08.31 13:18:55 5: SipTest[1639], DTMF Event: 4 - 964 ms
2020.08.31 13:18:57 5: SipTest[1639], DTMF Event: 5 - 544 ms
2020.08.31 13:18:59 5: SipTest[1639], DTMF Event: 6 - 244 ms
2020.08.31 13:19:01 5: SipTest[1639], DTMF Event: 7 - 45 ms
2020.08.31 13:19:01 5: SipTest[1639], DTMF Event: 7 - 40 ms
2020.08.31 13:19:02 5: SipTest[1639], DTMF Event: 8 - 524 ms
2020.08.31 13:19:02 5: SipTest[1639], DTMF Event: 8 - 60 ms
2020.08.31 13:19:04 5: SipTest[1639], DTMF Event: 9 - 245 ms
2020.08.31 13:19:04 5: SipTest[1639], DTMF Event: 9 - 60 ms
2020.08.31 13:19:05 5: SipTest[1639], DTMF Event: 0 - 963 ms
2020.08.31 13:19:06 5: SipTest[1639], DTMF Event: 0 - 22 ms
2020.08.31 13:19:07 5: SipTest[1639], DTMF Event: 1 - 684 ms
2020.08.31 13:19:07 5: SipTest[1639], DTMF Event: 1 - 79 ms
2020.08.31 13:19:08 5: SipTest[1639], DTMF Event: 1 - 100 ms
2020.08.31 13:19:09 5: SipTest[1639], DTMF Event: 2 - 184 ms
2020.08.31 13:19:09 5: SipTest[1639], DTMF Event: 2 - 79 ms
2020.08.31 13:19:10 5: SipTest[1639], DTMF Event: 3 - 732 ms
2020.08.31 13:19:10 5: SipTest[1639], DTMF Event: 3 - 34 ms
2020.08.31 13:19:12 5: SipTest[1639], DTMF Event: 4 - 164 ms
2020.08.31 13:19:13 5: SipTest[1639], DTMF Event: 5 - 564 ms
2020.08.31 13:19:14 5: SipTest[1639], DTMF Event: 6 - 964 ms
2020.08.31 13:19:16 5: SipTest[1639], DTMF Event: 7 - 384 ms
2020.08.31 13:19:16 5: SipTest[1639], DTMF Event: 7 - 60 ms
2020.08.31 13:19:17 5: SipTest[1639], DTMF Event: 8 - 624 ms
2020.08.31 13:19:18 5: SipTest[1639], DTMF Event: 9 - 984 ms
2020.08.31 13:19:20 5: SipTest[1639], DTMF Event: 0 - 224 ms
2020.08.31 13:19:21 5: SipTest[1639], DTMF Event: # - 544 ms
2020.08.31 13:19:22 5: SipTest[1639], DTMF Event: 1 - 704 ms
< hier wurde jetzt ein # eingegeben>
2020.08.31 13:19:22 5: SipTest[1639], DTMF: 1 , Anz: 2
2020.08.31 13:19:22 5: SipTest[1639], DTMF Event: 1 - 59 ms
2020.08.31 13:19:23 5: SipTest[1639], DTMF Event: 1 - 59 ms
2020.08.31 13:19:23 5: SipTest[1639], DTMF Event: 2 - 684 ms
2020.08.31 13:19:23 5: SipTest[1639], DTMF: 12 , Anz: 3
Da sind auch einige recht lange Tastenpreller mit dabei (z.B. das DTMF Event: 1 - 39 ms).
Die Auslagerung des Schwellwertes in ein Attribut erscheint mir sinnvoll. Wenn die Grenze von 40 ms der Spezifikation entspricht, könnte man den Wert als Default nehmen.
kein Problem, ich habe z.B. ganz am Anfang einen erkannten Stern mit 9ms ohne das ich überhaupt ne Taste gedrückt habe ....
@Kurt
in der fritzbox unter "Telefonie > Telefoniegeräte > edit beim jeweiligen fon > Merkmale des Telefoniegerätes"
gibt es eine reihe von einstellungen, die den "klang" beeinflussen können.
hast du hier eventuell etwas "optimiert"?
ganz unten hinter störfilter gibt es dort bei mir noch folgenden hinweis:
"Beachten Sie bitte, dass ein aktivierter USB 3.0 Anschluss eine Störung der DECT-Übertragung zur Folge haben kann."
trifft das eventuell zu?
Zitat von: frank am 31 August 2020, 15:07:58
@Kurt
in der fritzbox unter "Telefonie > Telefoniegeräte > edit beim jeweiligen fon > Merkmale des Telefoniegerätes"
gibt es eine reihe von einstellungen, die den "klang" beeinflussen können.
hast du hier eventuell etwas "optimiert"?
ganz unten hinter störfilter gibt es dort bei mir noch folgenden hinweis:
"Beachten Sie bitte, dass ein aktivierter USB 3.0 Anschluss eine Störung der DECT-Übertragung zur Folge haben kann."
trifft das eventuell zu?
Hallo Frank,
"Merkmale des Telefoniegerätes" gibt es hier nicht.
Ich sehe nur die Reiter "Anmeldedaten" und "IP-Telefon".
Gruß Kurt
@plin: Was soll ich mir denn in der "fhem-2020-08.log genau angucken? Ich sehe keine Auffälligkeiten.
Zitat von: Kurt77 am 31 August 2020, 16:27:32
@plin: Was soll ich mir denn in der "fhem-2020-08.log genau angucken? Ich sehe keine Auffälligkeiten.
Du schreibst Du hättest 5 Minuten lang diverse Tasten betätigt und keine Events gesehen und der SIpClient hat auch nicht aufgelegt. Ich würde erwarten zumindest Log-Einträge vom Typ
2020.08.31 13:18:49 5: SipTest[1639], DTMF Event: 1 - 34 ms
zu sehen, bei denen die Zeiten alle kleiner als 90 ms sind.
Zitat von: Kurt77 am 31 August 2020, 16:27:32
Ich sehe nur die Reiter "Anmeldedaten" und "IP-Telefon".
Du bist am falschen Gerät , so sparsam schaut das bei LAN/WLAN Telefonen aus.
Du sollst aber dein DECT Telefon auswählen mit dem du immer testest, da hast ein paar Reiter mehr.
Zitat von: plin am 31 August 2020, 16:57:41
Du schreibst Du hättest 5 Minuten lang diverse Tasten betätigt und keine Events gesehen und der SIpClient hat auch nicht aufgelegt. Ich würde erwarten zumindest Log-Einträge vom Typ
2020.08.31 13:18:49 5: SipTest[1639], DTMF Event: 1 - 34 ms
zu sehen, bei denen die Zeiten alle kleiner als 90 ms sind.
Hallo plin,
ich habe jetzt nochmal 3 Telefongespräche durchgeführt und habe jeweils aufgelegt, weil nicht automatisch aufgelegt wurde.
Hier ist meine fhem-2020-09.log
2020.09.01 10:54:21 5: MySipClient[18029], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=A014DDB29AAA6CE5
2020.09.01 10:54:21 4: MySipClient[18029], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.09.01 10:54:21 4: MySipClient[18029], cb_create : INVITE
2020.09.01 10:54:21 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.09.01 10:54:21 5: MySipClient, readingB:caller_nr Val:**610
2020.09.01 10:54:21 5: MySipClient, readingB:caller_name Val:Buero
2020.09.01 10:54:21 5: MySipClient, readingB:caller_time Val:0
2020.09.01 10:54:21 5: MySipClient, readingB:caller_state Val:calling
2020.09.01 10:54:21 5: MySipClient[18029], cb_invite_dtmf
2020.09.01 10:54:21 5: MySipClient, readingS:caller_state Val:ringing
2020.09.01 10:54:24 5: MySipClient[18029], cb_est_dtmf
2020.09.01 10:54:24 5: MySipClient, readingS:caller_state Val:established
2020.09.01 10:54:25 4: MySipClient[18029], register new expire : 2020-09-01 10:59:25
2020.09.01 10:54:25 5: MySipClient, readingB:state Val:listen_dtmf
2020.09.01 10:54:25 5: MySipClient, readingB:listen_alive Val:18029
2020.09.01 10:54:25 5: MySipClient, readingB:expire Val:300
2020.09.01 10:54:35 5: MySipClient, listen process 18029 found
2020.09.01 10:54:37 5: MySipClient[18029], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=B80E4B7ADE072BA6
2020.09.01 10:54:37 4: MySipClient[18029], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.09.01 10:54:37 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.09.01 10:54:37 5: MySipClient, readingB:caller_nr Val:**610
2020.09.01 10:54:37 5: MySipClient, readingB:caller_name Val:Buero
2020.09.01 10:54:37 5: MySipClient, readingB:caller_time Val:0
2020.09.01 10:54:37 5: MySipClient, readingB:caller_state Val:calling
2020.09.01 10:54:37 4: MySipClient[18029], cb_create : INVITE
2020.09.01 10:54:37 5: MySipClient[18029], cb_invite_dtmf
2020.09.01 10:54:37 5: MySipClient, readingS:caller_state Val:ringing
2020.09.01 10:54:40 5: MySipClient[18029], cb_est_dtmf
2020.09.01 10:54:40 5: MySipClient, readingS:caller_state Val:established
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_3 Get called. Relay state: 0, RSSI: -53
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_3 Updating readings
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_3 Get end
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_2 Get called. Relay state: 1, RSSI: -61
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_2 Updating readings
2020.09.01 10:54:50 3: TPLinkHS110: dWohnzimmerstecker_2 Get end
2020.09.01 10:54:51 3: TPLinkHS110: dWohnzimmerstecker_1 Get called. Relay state: 0, RSSI: -58
2020.09.01 10:54:51 3: TPLinkHS110: dWohnzimmerstecker_1 Updating readings
2020.09.01 10:54:51 3: TPLinkHS110: dWohnzimmerstecker_1 Get end
2020.09.01 10:55:35 5: MySipClient, listen process 18029 found
2020.09.01 10:56:11 5: MySipClient[18029], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=D23E4588DB24BEEC
2020.09.01 10:56:11 4: MySipClient[18029], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.09.01 10:56:11 4: MySipClient[18029], cb_create : INVITE
2020.09.01 10:56:11 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.09.01 10:56:11 5: MySipClient, readingB:caller_nr Val:**610
2020.09.01 10:56:11 5: MySipClient, readingB:caller_name Val:Buero
2020.09.01 10:56:11 5: MySipClient, readingB:caller_time Val:0
2020.09.01 10:56:11 5: MySipClient, readingB:caller_state Val:calling
2020.09.01 10:56:11 5: MySipClient[18029], cb_invite_dtmf
2020.09.01 10:56:11 5: MySipClient, readingS:caller_state Val:ringing
2020.09.01 10:56:14 5: MySipClient[18029], cb_est_dtmf
2020.09.01 10:56:14 5: MySipClient, readingS:caller_state Val:established
2020.09.01 10:56:35 5: MySipClient, listen process 18029 found
2020.09.01 10:56:38 3: d_netatmo_wohnzimmer: poll (DEVICE)
2020.09.01 10:56:38 3: d_netatmo_wohnzimmer: requestDeviceReadings (Temperature,CO2,Humidity,Noise,Pressure)
2020.09.01 10:56:38 3: d_netatmo_wohnzimmer: next dynamic update (Temperature,CO2,Humidity,Noise,Pressure) at 2020-09-01 11:06:55
2020.09.01 10:56:55 4: MySipClient[18029], register new expire : 2020-09-01 11:01:55
2020.09.01 10:56:55 5: MySipClient, readingB:state Val:listen_dtmf
2020.09.01 10:56:55 5: MySipClient, readingB:listen_alive Val:18029
2020.09.01 10:56:55 5: MySipClient, readingB:expire Val:300
2020.09.01 10:57:24 5: MySipClient[18029], SIP_filter : "Buero" <sip:**610@fritz.box>;tag=B889FD7FD986B631
2020.09.01 10:57:24 4: MySipClient[18029], SIP_filter: caller Buero sip:**610@fritz.box, caller_nr **610, caller_name Buero
2020.09.01 10:57:24 5: MySipClient, readingB:caller Val:Buero sip:**610@fritz.box
2020.09.01 10:57:24 5: MySipClient, readingB:caller_nr Val:**610
2020.09.01 10:57:24 5: MySipClient, readingB:caller_name Val:Buero
2020.09.01 10:57:24 5: MySipClient, readingB:caller_time Val:0
2020.09.01 10:57:24 5: MySipClient, readingB:caller_state Val:calling
2020.09.01 10:57:24 4: MySipClient[18029], cb_create : INVITE
2020.09.01 10:57:24 5: MySipClient[18029], cb_invite_dtmf
2020.09.01 10:57:24 5: MySipClient, readingS:caller_state Val:ringing
2020.09.01 10:57:27 5: MySipClient[18029], cb_est_dtmf
2020.09.01 10:57:27 5: MySipClient, readingS:caller_state Val:established
2020.09.01 10:57:35 5: MySipClient, listen process 18029 found
2020.09.01 10:58:35 5: MySipClient, listen process 18029 found
2020.09.01 10:59:25 4: MySipClient[18029], register new expire : 2020-09-01 11:04:25
2020.09.01 10:59:25 5: MySipClient, readingB:state Val:listen_dtmf
2020.09.01 10:59:25 5: MySipClient, readingB:listen_alive Val:18029
2020.09.01 10:59:25 5: MySipClient, readingB:expire Val:300
2020.09.01 10:59:35 5: MySipClient, listen process 18029 found
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_3 Get called. Relay state: 0, RSSI: -56
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_3 Updating readings
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_3 Get end
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_2 Get called. Relay state: 1, RSSI: -63
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_2 Updating readings
2020.09.01 10:59:50 3: TPLinkHS110: dWohnzimmerstecker_2 Get end
2020.09.01 10:59:51 3: TPLinkHS110: dWohnzimmerstecker_1 Get called. Relay state: 0, RSSI: -60
2020.09.01 10:59:51 3: TPLinkHS110: dWohnzimmerstecker_1 Updating readings
2020.09.01 10:59:51 3: TPLinkHS110: dWohnzimmerstecker_1 Get end
2020.09.01 11:00:36 5: MySipClient, listen process 18029 found
2020.09.01 11:01:36 5: MySipClient, listen process 18029 found
2020.09.01 11:01:55 4: MySipClient[18029], register new expire : 2020-09-01 11:06:55
2020.09.01 11:01:55 5: MySipClient, readingB:state Val:listen_dtmf
2020.09.01 11:01:55 5: MySipClient, readingB:listen_alive Val:18029
2020.09.01 11:01:55 5: MySipClient, readingB:expire Val:300
2020.09.01 11:02:36 5: MySipClient, listen process 18029 found
Danke und Gruß,
Kurt
@Kurt: Was ist denn mit den DTMF Events? Steht das Attribut verbose immer noch auf 5?
Hallo plin,
hier ist das list.
Gruß Kurt
Internals:
AC /usr/bin/sox
FUUID 5f3d5a11-f33f-7695-cdae-b046c5875ba9a078
LPID 18029
NAME MySipClient
NOTIFYDEV mytext2speech
NR 141
NTFY_ORDER 50-MySipClient
STATE listen_dtmf
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2020-08-31 11:46:38 call done
2020-08-31 11:46:38 call_attempt 0
2020-08-31 11:46:38 call_state declined
2020-08-31 11:46:38 call_success 0
2020-08-31 11:46:38 call_time 0
2020-09-01 10:57:24 caller Buero sip:**610@fritz.box
2020-09-01 10:57:24 caller_name Buero
2020-09-01 10:57:24 caller_nr **610
2020-09-01 10:57:27 caller_state established
2020-09-01 10:57:24 caller_time 0
2020-08-31 17:09:38 dtmf_event 5
2020-09-01 12:26:56 expire 300
2020-08-23 17:40:44 last_error attr audio_converter not set
2020-09-01 12:26:56 listen_alive 18029
2020-09-01 12:26:56 state listen_dtmf
helper:
CALL_BYE declined
CALL_ERROR 1
CALL_NAME unknown
CALL_NR **611
CALL_START 1598867170
CALL_TIME 0
CALL_TYPE out
LISTEN_PID:
abortArg
abortFn
arg MySipClient
bc_pid 1363
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 18029
timeout
Attributes:
T2S_Device mytext2speech
audio_converter sox
disabled 0
history_file ./log/MySipClient.sip
history_size 0
sip_audiofile_dtmf cache/de901947c29afa3f195b50e87289aa4c.mp3
sip_audiofile_ok cache/ab7acf820e3b2e2fc76c4012a5c7a991.mp3
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 1
sip_elbc yes
sip_from sip:fhemsip1@fritz.box
sip_ip 192.168.178.33
sip_listen dtmf
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 3
sip_user fhemsip1
verbose 5
Ich wiederhole mich ja nur ungern, aber IMHO wird das so nichts -> 2020.09.01 10:57:27 5: MySipClient[18029], cb_est_dtmf
nie kommt da der nächste Schritt mit reinvite1 und das war vor Tagen schon mal anderes.
Aber wohl seit dem Net::SIP Update läuft da was gründlich schief.
@Wzut: bedeutet neben der Net::SIP-Version sollten wir vielleicht auch den perl-Library path unter INTERNALS mit ausweisen?
perl -e "print qq(@INC)"
Na das kann er ja mal auf der Konsole eingeben.
Hier ersteinmal wie versprochen meine aktuelle Beta, die dtmf Erkennung ist jetzt runter auf 45ms und das Logging etwas angepasst.
Da ich wegen PBP und perlcritic extrem viel geändert habe darf ruhig auch derjenige mit testen der z.Z. keine Probleme hat, denn ich habe bis jetzt nicht alle Varianten die das Modul z.Z. bietet durch.
neue Beta-Version:
listen_DTMF klappt auch wenn ich über die Tasten husche
Der Ansagetext für sip_audiofile_wfp wird nicht korrekt aufbereitet. Ich habe "!Willkommen" eingetragen. Raus kommt ein Löwe der langsam "Danke" sagt. Den Text mittels T2S generiert und das Audiofile hinterlegt. Klappt, es ist "Danke" zu hören. Text auf "!Herzlich Willkommen" geändert. Es ist immer noch "Willkommen" (wie im mp3-File) zu hören.
2020.09.01 13:38:20 5: SipTest , SIP_Attr : set, sip_audiofile_wfp, !Sehr herzlich Willkommen
2020.09.01 13:38:20 5: SipTest , SIP_Attr : reset
2020.09.01 13:38:20 5: SipTest, updateConfig
2020.09.01 13:38:20 4: SipTest, Listen Kill PID : 4289
2020.09.01 13:38:20 4: SipTest, Reset Listen done
2020.09.01 13:38:20 5: SipTest, MD5: Herzlich Willkommen -> b94ca62a54098120fbc64e462c22cc7c.mp3
2020.09.01 13:38:20 5: SipTest, mp3 File file not found in cache
2020.09.01 13:38:20 4: SipTest, hole Herzlich Willkommen
2020.09.01 13:38:20 5: SipTest, Notify T2S , playing: 1
2020.09.01 13:38:20 5: SipTest, Notify T2S , duration: 2
2020.09.01 13:38:21 5: SipTest, Notify T2S , endTime: 00:00:00
2020.09.01 13:38:23 5: SipTest, Notify T2S , lastFilename: cache/b94ca62a54098120fbc64e462c22cc7c.mp3
2020.09.01 13:38:23 4: SipTest, wait_for_t2s file : cache/b94ca62a54098120fbc64e462c22cc7c.mp3
2020.09.01 13:38:23 4: SipTest, new T2S file cache/b94ca62a54098120fbc64e462c22cc7c.mp3
2020.09.01 13:38:23 5: SipTest, /usr/bin/sox cache/b94ca62a54098120fbc64e462c22cc7c.mp3 -t raw -r 8000 -c 1 -e a-law cache/b94ca62a54098120fbc64e462c22cc7c.alaw 2>&1
2020.09.01 13:38:24 4: SipTest, Listen new PID : 4577
2020.09.01 13:38:24 4: SipTest[4577], my parent is 3780
2020.09.01 13:38:24 4: SipTest[4577], trying to use port 5070
2020.09.01 13:38:24 5: SipTest, Notify T2S , playing: 0
2020.09.01 13:38:24 4: SipTest[4577], register new expire : 2020-09-01 13:43:24
2020.09.01 13:38:24 5: SipTest, readingB:state Val:listen_wfp
2020.09.01 13:38:24 5: SipTest, readingB:listen_alive Val:4577
2020.09.01 13:38:24 5: SipTest, readingB:expire Val:300
2020.09.01 13:38:24 3: SipTest[4577], Text : !Eine zweistellige Zahl bitte found, ignoring it
2020.09.01 13:38:24 3: SipTest[4577], Text : !Danke found, ignoring it
2020.09.01 13:38:24 5: SipTest[4577], audio file cache/b94ca62a54098120fbc64e462c22cc7c.alaw found
2020.09.01 13:38:24 4: SipTest[4577], using cache/b94ca62a54098120fbc64e462c22cc7c.alaw for audio_wfp
Zitat von: Wzut am 01 September 2020, 13:17:25
Na das kann er ja mal auf der Konsole eingeben.
Hat er eingegeben.
/etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .
Gruß Kurt
Dann könnte man jetzt noch ein
find /usr/ -name "SIP.pm"
hinterherschieben, um zu sehen, ob es das File mehrfach gibt.
Hallo plin,
das ist das Ergebnis von "find...":
/usr/share/perl5/Net/SIP.pm
/usr/local/share/perl/5.20.2/Net/SIP.pm
Und es gibt die Datei sogar noch ein drittes Mal unter /opt/fhem/FHEM.
Dahin habe ich gerade Wzut's Testversion hinkopiert. Gehört sie da nicht hin?
Danke und Gruß,
Kurt
Zitat von: Kurt77 am 01 September 2020, 16:10:33
es gibt die Datei sogar noch ein drittes Mal unter /opt/fhem/FHEM.
Dahin habe ich gerade Wzut's Testversion hinkopiert. Gehört sie da nicht hin?
nein, nein - meine Testversion hat eine 96 und ein Unterstrich vor dem SIP.pm also keine Namensgleichheit mit dem CPAN Modul !
Und ja sie gehörtwie alle FHEM Module unter /opt/fhem/FHEM und nach einem reload 96_SIP oder FHEM Neustart wird die dann auch benutzt und danach hast ein neues Internal NetSIP das verrät welche Version von deinen beiden Net:SIPs aktiv benutzt wird.
Hallo Wzut,
ja, sorry, die fehlelnden Zeichen "96_" hatte ich übersehen.
Deine Testversion zeigt jedenfalls jetzt:
NetSIP 0.823
Gruß Kurt
Zitat von: plin am 01 September 2020, 13:37:30
Raus kommt ein Löwe der langsam "Danke" sagt.
Kannst du mir das mit dem Löwe übersetzen ? Ich steh da gerade voll auf dem Schlauch.
Bei mir wird sowohl bei wfp die richtige Datei gespielt , als auch die beiden anderen bei dtmf
nternals:
AC /usr/bin/sox
FUUID 5f4e56f7-f33f-9e6a-a5bb-9b5a317abee6bfd5
FVERSION 96_SIP.pm:?-s17070/2020-08-31
LPID 2605
NAME sip
NOTIFYDEV myTTS
NR 17
NTFY_ORDER 50-sip
NetSIP 0.812
STATE listen_dtmf
TYPE SIP
VERSION 4711
READINGS:
2020-09-01 17:03:51 caller none
2020-09-01 17:03:51 caller_name ---
2020-09-01 17:03:51 caller_nr ---
2020-09-01 17:03:51 caller_state hangup
2020-09-01 17:03:51 caller_time 7
2020-09-01 17:03:50 dtmf_event 61
2020-09-01 17:04:26 expire 300
2020-09-01 17:04:26 listen_alive 2605
2020-09-01 17:04:26 state listen_dtmf
helper:
LISTEN_PID:
abortArg
abortFn
arg sip
bc_pid 16
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 2605
timeout
Attributes:
T2S_Device myTTS
audio_converter sox
history_file ./log/sip.sip
history_size 10
room SIP
sip_am_maxtime 10
sip_audiofile_am ab.al
sip_audiofile_dtmf !Bitte DTMF Eingabe
sip_audiofile_ok !Alles klar Joe
sip_audiofile_wfp !Herzlich Willkommen
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_filter 611
sip_from sip:raspitest@fritz.box
sip_ip 192.168.0.1
sip_listen dtmf
sip_registrar 192.168.0.253
sip_ringtime 3
sip_user raspitest
verbose 5
Beim ersten DTMF Anruf waren beide Textdatein noch nicht da, wurden aber brav beider direkt erzeugt und verwendet ( Thema der von mir beschriebene Bug gefixt)
Zitat von: Wzut am 01 September 2020, 17:15:24
Kannst du mir das mit dem Löwe übersetzen ? Ich steh da gerade voll auf dem Schlauch.
Stelle Dir vor die Ansage wird mit einem Bruchteil der eigentlichen Tonfrequenz abgespielt. Das klang dann wie ein Löwe statt eines Menschen.
Wo hinterlegst Du die Kombination Text->mp3-File? Oder gehst Du nur über den Wert des Attributes?
Ich teste mit den Texten noch mal systematisch durch.
Update:root@bananapi:/opt/fhem/log# tail -f fhem-2020-09.log | grep SipTest
2020.09.01 18:35:43 5: SipTest, readingB:caller_time Val:5
2020.09.01 18:35:43 5: SipTest, readingB:caller_nr Val:---
2020.09.01 18:35:43 5: SipTest, readingB:caller_name Val:---
2020.09.01 18:35:43 5: SipTest[2361], while(1)
2020.09.01 18:36:13 5: SipTest, listen process 2361 found
2020.09.01 18:36:57 5: SipTest , SIP_Attr : set, sip_audiofile_dtmf, !Ihre Eingabe bitte
2020.09.01 18:36:57 5: SipTest , SIP_Attr : reset
2020.09.01 18:36:57 5: SipTest, updateConfig
2020.09.01 18:36:57 4: SipTest, Listen Kill PID : 2361
2020.09.01 18:36:57 4: SipTest, Reset Listen done
2020.09.01 18:36:57 4: SipTest, Listen new PID : 2533
2020.09.01 18:36:57 4: SipTest[2533], my parent is 477
2020.09.01 18:36:57 4: SipTest[2533], trying to use port 5070
2020.09.01 18:36:57 4: SipTest[2533], register new expire : 2020-09-01 18:41:57
2020.09.01 18:36:57 5: SipTest, readingB:state Val:listen_dtmf
2020.09.01 18:36:57 5: SipTest, readingB:listen_alive Val:2533
2020.09.01 18:36:57 5: SipTest, readingB:expire Val:300
2020.09.01 18:36:57 5: SipTest[2533], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:36:57 5: SipTest[2533], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:36:57 5: SipTest[2533], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:36:57 5: SipTest[2533], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:36:57 5: SipTest[2533], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:36:57 5: SipTest[2533], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:36:57 4: SipTest[2533], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_dtmf
2020.09.01 18:36:57 4: SipTest[2533], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_ok
2020.09.01 18:36:57 4: SipTest[2533], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_wfp
kein neues File im cache, erster Testanruf, Ansage ist schwer verständlich
2020.09.01 18:37:57 5: SipTest, listen process 2533 found
2020.09.01 18:38:33 5: SipTest[2533], SIP_filter : "Arbeitszimmer" <sip:**611@fritz.box>;tag=081FCF34D0EC5ED7
2020.09.01 18:38:33 4: SipTest[2533], SIP_filter: caller Arbeitszimmer sip:**611@fritz.box, caller_nr **611, caller_name Arbeitszimmer
2020.09.01 18:38:33 5: SipTest, readingB:caller Val:Arbeitszimmer sip:**611@fritz.box
2020.09.01 18:38:33 5: SipTest, readingB:caller_nr Val:**611
2020.09.01 18:38:33 5: SipTest, readingB:caller_name Val:Arbeitszimmer
2020.09.01 18:38:33 5: SipTest, readingB:caller_time Val:0
2020.09.01 18:38:33 4: SipTest[2533], cb_create : INVITE
2020.09.01 18:38:33 5: SipTest, readingB:caller_state Val:calling
2020.09.01 18:38:33 5: SipTest[2533], cb_invite_dtmf
2020.09.01 18:38:33 5: SipTest, readingS:caller_state Val:ringing
2020.09.01 18:38:38 5: SipTest[2533], cb_est_dtmf
2020.09.01 18:38:38 5: SipTest, readingS:caller_state Val:established
2020.09.01 18:38:38 5: SipTest[2533], while dtmf_loop : start reinvite1
2020.09.01 18:38:39 5: SipTest[2533], rtp_done 1
2020.09.01 18:38:42 5: SipTest[2533], DTMF Event: # - 454 ms (good)
2020.09.01 18:38:42 5: SipTest[2533], DTMF: START
2020.09.01 18:38:43 5: SipTest[2533], DTMF Event: 8 - 178 ms (good)
2020.09.01 18:38:43 5: SipTest[2533], DTMF: 8 , Anz: 2
2020.09.01 18:38:43 5: SipTest[2533], DTMF Event: 8 - 19 ms (too short)
2020.09.01 18:38:43 5: SipTest[2533], DTMF Event: 9 - 494 ms (good)
2020.09.01 18:38:43 5: SipTest[2533], DTMF: 89 , Anz: 3
2020.09.01 18:38:43 5: SipTest[2533], DTMF: 89 (done)
2020.09.01 18:38:43 5: SipTest, readingS:dtmf_event Val:89
2020.09.01 18:38:43 5: SipTest[2533], while dtmf_loop : dtmfloop : 1 , byebye : 0
2020.09.01 18:38:43 5: SipTest[2533], while dtmf_loop : reinvite2
2020.09.01 18:38:43 5: SipTest[2533], DTMF Event: 9 - 65 ms (good)
2020.09.01 18:38:43 5: SipTest[2533], while dtmf_loop : after reinvite2 0 , 0
2020.09.01 18:38:44 5: SipTest[2533], rtp_done 1
2020.09.01 18:38:44 5: SipTest[2533], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.09.01 18:38:44 5: SipTest, readingB:caller Val:none
2020.09.01 18:38:44 5: SipTest, readingB:caller_state Val:hangup
2020.09.01 18:38:44 5: SipTest, readingB:caller_time Val:6
2020.09.01 18:38:44 5: SipTest, readingB:caller_nr Val:---
2020.09.01 18:38:44 5: SipTest, readingB:caller_name Val:---
2020.09.01 18:38:44 5: SipTest[2533], end while dtmf_loop, byebye : 0
2020.09.01 18:38:44 5: SipTest[2533], while(1)
Attribut erneut gesetzt
2020.09.01 18:38:44 5: SipTest[2533], while dtmf_loop, okloopbye : 0 , byebye : 0
2020.09.01 18:38:44 5: SipTest, readingB:caller Val:none
2020.09.01 18:38:44 5: SipTest, readingB:caller_state Val:hangup
2020.09.01 18:38:44 5: SipTest, readingB:caller_time Val:6
2020.09.01 18:38:44 5: SipTest, readingB:caller_nr Val:---
2020.09.01 18:38:44 5: SipTest, readingB:caller_name Val:---
2020.09.01 18:38:44 5: SipTest[2533], end while dtmf_loop, byebye : 0
2020.09.01 18:38:44 5: SipTest[2533], while(1)
2020.09.01 18:38:57 5: SipTest, listen process 2533 found
2020.09.01 18:39:27 4: SipTest[2533], register new expire : 2020-09-01 18:44:27
2020.09.01 18:39:27 5: SipTest, readingB:state Val:listen_dtmf
2020.09.01 18:39:27 5: SipTest, readingB:listen_alive Val:2533
2020.09.01 18:39:27 5: SipTest, readingB:expire Val:300
2020.09.01 18:39:49 5: SipTest , SIP_Attr : set, sip_audiofile_dtmf, !Ihre Eingabe bitte
2020.09.01 18:39:49 5: SipTest , SIP_Attr : reset
2020.09.01 18:39:49 5: SipTest, updateConfig
2020.09.01 18:39:49 4: SipTest, Listen Kill PID : 2533
2020.09.01 18:39:49 4: SipTest, Reset Listen done
2020.09.01 18:39:49 5: SipTest, MD5: Ihre Eingabe bitte -> de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:39:49 5: SipTest, mp3 File file not found in cache
2020.09.01 18:39:49 4: SipTest, hole Ihre Eingabe bitte
2020.09.01 18:39:49 5: SipTest, Notify T2S , playing: 1
2020.09.01 18:39:50 5: SipTest, Notify T2S , duration: 2
2020.09.01 18:39:50 5: SipTest, Notify T2S , endTime: 00:00:00
2020.09.01 18:39:55 5: SipTest, Notify T2S , lastFilename: cache/de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:39:55 4: SipTest, wait_for_t2s file : cache/de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:39:55 4: SipTest, new T2S file cache/de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:39:55 5: SipTest, /usr/bin/sox cache/de901947c29afa3f195b50e87289aa4c.mp3 -t raw -r 8000 -c 1 -e a-law cache/de901947c29afa3f195b50e87289aa4c.alaw 2>&1
2020.09.01 18:39:55 4: SipTest, Listen new PID : 2795
2020.09.01 18:39:55 4: SipTest[2795], my parent is 477
2020.09.01 18:39:55 4: SipTest[2795], trying to use port 5070
2020.09.01 18:39:55 5: SipTest, Notify T2S , playing: 0
2020.09.01 18:39:55 4: SipTest[2795], register new expire : 2020-09-01 18:44:55
2020.09.01 18:39:55 5: SipTest, readingB:state Val:listen_dtmf
2020.09.01 18:39:55 5: SipTest, readingB:listen_alive Val:2795
2020.09.01 18:39:55 5: SipTest, readingB:expire Val:300
2020.09.01 18:39:55 5: SipTest[2795], audio file cache/de901947c29afa3f195b50e87289aa4c.alaw found
2020.09.01 18:39:55 5: SipTest[2795], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:39:55 5: SipTest[2795], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:39:55 5: SipTest[2795], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:39:55 5: SipTest[2795], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:39:55 4: SipTest[2795], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.09.01 18:39:55 4: SipTest[2795], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_ok
2020.09.01 18:39:55 4: SipTest[2795], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_wfp
neue Files im cache
-rw-r--r-- 1 fhem dialout 7200 Sep 1 18:39 de901947c29afa3f195b50e87289aa4c.mp3
-rw-r--r-- 1 fhem dialout 14208 Sep 1 18:39 de901947c29afa3f195b50e87289aa4c.alaw
2. Testanruf: Ansage ist klar zu verstehen
Text für sip_dtmf_ok ändern
2020.09.01 18:42:55 5: SipTest, listen process 2795 found
2020.09.01 18:43:50 5: SipTest , SIP_Attr : set, sip_audiofile_ok, !Danke
2020.09.01 18:43:50 5: SipTest , SIP_Attr : reset
2020.09.01 18:43:50 5: SipTest, updateConfig
2020.09.01 18:43:50 4: SipTest, Listen Kill PID : 2795
2020.09.01 18:43:50 4: SipTest, Reset Listen done
2020.09.01 18:43:50 5: SipTest, MD5: Ihre Eingabe bitte -> de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:43:50 4: SipTest, Listen new PID : 3006
2020.09.01 18:43:50 4: SipTest[3006], my parent is 477
2020.09.01 18:43:50 4: SipTest[3006], trying to use port 5070
2020.09.01 18:43:50 4: SipTest[3006], register new expire : 2020-09-01 18:48:50
2020.09.01 18:43:50 5: SipTest[3006], not converted - using cache/de901947c29afa3f195b50e87289aa4c.alaw from cache
2020.09.01 18:43:50 5: SipTest[3006], audio file cache/de901947c29afa3f195b50e87289aa4c.alaw found
2020.09.01 18:43:50 5: SipTest[3006], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:43:50 5: SipTest[3006], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:43:50 5: SipTest[3006], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:43:50 5: SipTest[3006], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:43:50 4: SipTest[3006], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.09.01 18:43:50 4: SipTest[3006], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_ok
2020.09.01 18:43:50 4: SipTest[3006], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_wfp
2020.09.01 18:43:50 5: SipTest, readingB:state Val:listen_dtmf
2020.09.01 18:43:50 5: SipTest, readingB:listen_alive Val:3006
2020.09.01 18:43:50 5: SipTest, readingB:expire Val:300
kein neues mp3-File im cache, alter Text wird angesagt
Attribut neu setzen mit "set" statt <Enter>
2020.09.01 18:44:50 5: SipTest, listen process 3006 found
2020.09.01 18:45:04 5: SipTest , SIP_Attr : set, sip_audiofile_ok, !Danke
2020.09.01 18:45:04 5: SipTest , SIP_Attr : reset
2020.09.01 18:45:04 5: SipTest, updateConfig
2020.09.01 18:45:04 4: SipTest, Listen Kill PID : 3006
2020.09.01 18:45:04 4: SipTest, Reset Listen done
2020.09.01 18:45:04 5: SipTest, MD5: Ihre Eingabe bitte -> de901947c29afa3f195b50e87289aa4c.mp3
2020.09.01 18:45:04 5: SipTest, MD5: Danke -> a212affd2bf2d01dde56fedc7a2bde6f.mp3
2020.09.01 18:45:04 4: SipTest, Listen new PID : 3066
2020.09.01 18:45:04 4: SipTest[3066], my parent is 477
2020.09.01 18:45:04 4: SipTest[3066], trying to use port 5070
2020.09.01 18:45:04 4: SipTest[3066], register new expire : 2020-09-01 18:50:04
2020.09.01 18:45:04 5: SipTest[3066], not converted - using cache/de901947c29afa3f195b50e87289aa4c.alaw from cache
2020.09.01 18:45:04 5: SipTest[3066], audio file cache/de901947c29afa3f195b50e87289aa4c.alaw found
2020.09.01 18:45:04 5: SipTest[3066], not converted - using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw from cache
2020.09.01 18:45:04 5: SipTest[3066], audio file cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw found
2020.09.01 18:45:04 5: SipTest[3066], not converted - using cache/71ce4185214eb43202358604a63cdcab.alaw from cache
2020.09.01 18:45:04 5: SipTest[3066], audio file cache/71ce4185214eb43202358604a63cdcab.alaw found
2020.09.01 18:45:04 4: SipTest[3066], using cache/de901947c29afa3f195b50e87289aa4c.alaw for audio_dtmf
2020.09.01 18:45:04 4: SipTest[3066], using cache/a212affd2bf2d01dde56fedc7a2bde6f.alaw for audio_ok
2020.09.01 18:45:04 4: SipTest[3066], using cache/71ce4185214eb43202358604a63cdcab.alaw for audio_wfp
2020.09.01 18:45:04 5: SipTest, readingB:state Val:listen_dtmf
2020.09.01 18:45:04 5: SipTest, readingB:listen_alive Val:3066
2020.09.01 18:45:04 5: SipTest, readingB:expire Val:300
kein neues File im cache
Vielleicht kommen die Ansagen nur nicht klar rüber?
kopiere oder benne alles was .alaw ist in .al
dann spiel es mit play ab . z.B.
root@X2:/opt/fhem/cache# play -r 8000 -c 1 128e53ac717d66f92dd08fb37b3f59a2.al
128e53ac717d66f92dd08fb37b3f59a2.al:
File Size: 14.0k Bit Rate: 64.0k
Encoding: A-law
Channels: 1 @ 13-bit
Samplerate: 8000Hz
Replaygain: off
Duration: 00:00:01.75
In:100% 00:00:01.75 [00:00:00.00] Out:14.0k [ | ] Hd:3.4 Clip:0
Done.
Die Qualität ist nicht wesentlich schlechter als wenn man die .mp3 direkt abspielt.
Beim FRITZ DECT ist sie ebenfalls sehr gut nur fehlt irgendwie am Anfang eine Winzigkeit. Müsste mich mal mehr mit T2S beschäftigen um die Nachricht quasi mit 0,5 Sekunden Pause beginnen zu lassen. Oder da wir ja eh Rohaudio ohne Header haben könnte man vllt. direkt nach der sox mp3 - alaw Konvertierung ne halbe Sekunde Sound of Silence dazupacken.
1.) Die eingegebenen sip_audiofile-Texte werden korrekt an der richtigen Stelle abgespielt.
2.) Man kann die alaw-Dateien mergen.
3.) 200 ms Stille reichen schon aus, um den Start ausreichend zu verzögern.
4.) Stille hinterher (zumindest 200 ms) ist eher schädlich, weil dann die #-Taste möglicherweise zu früh gedrückt wird.
5.) Der play-Command spielt den Text teilweise unvollständig ab, mplayer macht einen besseren Job.
ok, zu Punkt 3 werd ich heute Abend mal bissel testen. BTW nicht wundern über die neuen Attribute mit _am
am = answering machine , ich habe mir da was gebastelt. Z.z. habe ich einen HM Funkgong der mir ab und an wichtige Infos ins Büro brüllt. Doof ist da nur das er nur abspielen kann was auf der interen SD bereits vorhanden ist. Nun kann man natürlich Audio auf 100 Wegen von eiinem Device zum anderen schicken, aber wenn man doch das schöne Modul hat .... Jetzt schicke ich meinem Testsystem mit der FHEM Hauptinstanz via SIP eine Nachricht und das Ding spielt sie sofort nach dem Empfang via play ab.
Ist noch etwas Beta klappt aber schon ganz gut.
Ich habe mir dafür so eine Art halbe Alexa gebaut (reine Sound-Ausgabe). Im EG läuft eine FHEM-Instanz für die Rolladensteuerung. Darauf sammele ich Nachrichten in Kategorien (z.B. Anrufe in Abwesenheit). Wenn ich nach Abwesenheit wieder nach Haus komme, werden die dort gesammelten Texte der Reihe nach via T2S, alsaplayer und angeschlossenem Lautsprecher abgespielt.
Zitat von: plin am 02 September 2020, 08:07:20
5.) Der play-Command spielt den Text teilweise unvollständig ab, mplayer macht einen besseren Job.
Hast du mal die passende Kommandline zur Hand ? Bei mir klingt mplayer mit raw Audio immer grausam :(
Ich würde gern in die nächste Version noch ein set play Kommando einbauen, dann kann man schnell mal den gesammelten T2S cache durchhören.
Thema deine halbe Alexa : Da würd ich an deiner Stelle mal ein paar Zeilen mehr schreiben und das Ganze in Codeschnipsel vorstellen.
Ich kann mir vorstellen das würde doch mehr als einen hier interessieren.
Zitat von: Wzut am 03 September 2020, 07:28:05
Hast du mal die passende Kommandline zur Hand ? Bei mir klingt mplayer mit raw Audio immer grausam :(
Ich habe nur mp3-Files abgespielt - und das auf einem 2 Core Banana Pi. Ich muss das mal auf einem schnelleren Pi testen.
Zitat von: Wzut am 03 September 2020, 07:28:05
Thema deine halbe Alexa : Da würd ich an deiner Stelle mal ein paar Zeilen mehr schreiben und das Ganze in Codeschnipsel vorstellen.
Ich kann mir vorstellen das würde doch mehr als einen hier interessieren.
Hi Wzut,
anbei zwei Files:
- ein paar Informationen zu meiner FHEM-Landschaft nebst MsgQueue-Modul
- Das MsgQueue-Modul
Ich habe mir damals das MSG-Modul angeschaut. Das war mir aber zu komplex/kompliziert für das was ich eigentlich brauche. Danach entstand dann das eigene Modul.
Viele Grüße
Peter
Vorhin ist die 19€ mini USB Soundbar gekommen - ich bin begeistert. T2S mp3 nach a-law gewandelt und an den anderen SIP Client als Anruf geschickt klingt echt gut.
Selbst aufgezeichnetes mit dem Fritz DECT Telfon klingt dagegen mehr als bescheiden, da ist wohl jeder echte 10€ AB um Längen besser.
Aber anyway, ich wollte ja einen "kommt Anruf in den Raum Brüller" und den habe ich nun und bin nicht nicht mehr auf die statisch hinterlegten des Texte des HM Funkgong angewiesen.
Zitat von: Wzut am 05 September 2020, 14:19:17
Vorhin ist die 19€ mini USB Soundbar gekommen - ich bin begeistert. T2S mp3 nach a-law gewandelt und an den anderen SIP Client als Anruf geschickt klingt echt gut.
Selbst aufgezeichnetes mit dem Fritz DECT Telfon klingt dagegen mehr als bescheiden, da ist wohl jeder echte 10€ AB um Längen besser.
Aber anyway, ich wollte ja einen "kommt Anruf in den Raum Brüller" und den habe ich nun und bin nicht nicht mehr auf die statisch hinterlegten des Texte des HM Funkgong angewiesen.
Klingt als hättest Du Spaß :).
Wenn Du mit meinem MsqQueue-Modul Texte sammeln willst, kannst Du Dir die mittels
get zusammenbauen lassen. Das Reading
lastmessage kannst Du dann auch als Text für einen Anruf verwenden.
Ich habe mir übrigens die Mühe gemacht mein Geraffel mal ansatzweise zu beschreiben https://wiki.fhem.de/wiki/Benutzer:Plin53177 (https://wiki.fhem.de/wiki/Benutzer:Plin53177).
Zitat von: plin am 05 September 2020, 15:20:22
Klingt als hättest Du Spaß :).
Kann man so sagen, nun geht es an das umschreiben des Moduls auf packages. Das gibt nochmal eine Riesengaudi weil dann bei jeder nicht richtig angepassten Sub oder Funktionsaufruf gleich FHEM komplett unten ist, das wird wie bei meinen anderen Modulen auch ne schöne perl ./fhem.pl .fhem.cfg Orgie ..... und die command.ref hinkt auch schon wieder hinterher :(
Zitat von: plin am 01 September 2020, 13:37:30
Ich habe "!Willkommen" eingetragen. Raus kommt ein Löwe der langsam "Danke" sagt.
@Peter, beim durchsehen des Codes bin ich über folgende Zeile gestolpert beim set call :
#rtp_param => [0, 160, 160/8000, 'PCMU/8000'], hier unbedingt weglassen ! fuehrt zu Verzerrungen bei der Wiedergabe
rtp_param wird aber aktiv gesetzt bei listen_dtmf und listen_wfp. Da ich das Problem nicht nachstellen kann, könntest du bitte mal die beiden Zeilen rauswerfen und nochmal testen ob der Löwe dann verschwunden ist ?
edit : vermutlich haben wird da einen copy & paste Fehler ->
8,160,160/8000 , default ist aber
0,160,160/8000
Zitat von: Wzut am 09 September 2020, 07:18:17
rtp_param wird aber aktiv gesetzt bei listen_dtmf und listen_wfp. Da ich das Problem nicht nachstellen kann, könntest du bitte mal die beiden Zeilen rauswerfen und nochmal testen ob der Löwe dann verschwunden ist ?
Ich habe zwei rtp_param-Statements im dtmf-Teil entfernt und getestet. Das klingt deutlich schlimmer als in der Variante mit
8,160,160/8000.
Aber der "Löwe" ist weg.
Ich werde im nächsten Schritt mal rtp_param komplett verbannen, denn in Call.pm steht eh :
$param->{rtp_param} ||= [ 0,160,160/8000 ]; # PCMU/8000: 50*160 bytes/second
Edit Kommando zurück , jetzt wird mir so einiges klar :
https://en.wikipedia.org/wiki/RTP_payload_formats
die 0 ist ITU-T G.711 PCM μ-Law audio 64 kbit/s , wir in Europa nutzen aber eigentlich 8 = ITU-T G.711 PCM A-Law audio 64 kbit/s !!!
D.h. eigentlich müsste jetzt sogar rtp_param überall gesetzt werden und das eben mit der 8
Zitat von: Wzut am 09 September 2020, 19:27:40
D.h. eigentlich müsste jetzt sogar rtp_param überall gesetzt werden und das eben mit der 8
Auch die Zeile 511
so ich habe das Modul komplett auf package umgestellt und mich nochmal intensiv mit dem Thema Audio beschäftigt.
Was ich feststellen konnte : ist ist egal ob man ulaw oder alaw verwendet, nur sollte man beides nicht mischen und die entsprechendne Werte bei rtp_param müssen unbedingt passen ! Default bei Net::SIP ist ulaw, ich habe das jetzt auch so übernommen. Der User hat aber die Freiheit alaw zu verwenden dazu dient das neue Attribut audio_codec ( Default, d.h. nicht gesetzt PCMU = ulaw) aber auch das läst sich nochmal überstimmen wenn man direkt bei sip_audiofile_xxx eine Datei mit der Endung .al/.alaw oder .ul/.ulaw angibt.
Wäre schön wenn sich ein paar Tester finden bevor ich die Version einchecke.
Zitat von: Wzut am 13 September 2020, 18:53:26
Wäre schön wenn sich ein paar Tester finden bevor ich die Version einchecke.
Call (FritzBox, asterisk) -> ok
listen_echo -> ok
listen_dtmf (once, loop) -> ok
listen_wfp (fetch, reject) -> ok
Passwort habe ich nicht geändert/gesetzt.
Bei listen_dtmf ist es nach wie vor so, dass die aus Text generierte Ansage Aussetzer hat, insbesondere beim ersten Abspielen.
get <device> play ...
Welcher Text steckt hinter dem mp3-File? Eine Lookup-Tabelle wäre gut. Der Name des mp3-Files ergibt sich ja aus dem Text. Also brauchen wir ein Index-File md5->Text.
Es fehlen Hinweise für die Einrichtung (Eintrag in die /etc/sudoers).
Was passiert beim get/play? Lokale Wiedergabe?
VG plin
THX
a. zum Thema DTMF und Aussetzer : keine Idee , tritt bei mir auch nicht auf
b. ja kein Problem ich kann auch noch eine Übersetzungstabelle machen und anzeigen
c. Thema fhem und sudo Rechte ohne Passwort :
Das gibt es mehrfach das Module (z.b. Text2Speach mit mplayer) den fhem User einen Befehl mit sudo ausführen lassen. Ich habe die Datei /etc/sudoers nicht geändert, bei mir gab es bereits eine mit Namen fhem in /etc/sudoers.d/ , der z.Z. aktuelle Inhalt :
fhem ALL=(ALL) NOPASSWD: /usr/bin/play
Ich wollte zuerst auf den sudo Einsatz verzichten und dem fhem User entsprechende Rechte geben, bin aber gescheitert egal in welche Gruppe (audio , dsp) ich den User mit usermod aufgenommen habe. Und ja die Datei wird über die default Audioausgabe abgespielt. Und ja die Funktion ist eigentlich ein Gimmick um einfach mal schnell zu sehen (bzw hören) was sich da alles so unter /cache angesammelt hat und das äufräumen etwas erleichtert. Ausser beim Listen Mode am, da wird das play verwendet um ggf. die gerade aufgenommene Nachricht sofort abzuspielen.
Da fällt mir noch ein die Funktion der Call Listen bzw history Datei ist auch irgendwie unter gegangen. Aktuell schaut die Definition als weblink bei mir so aus :
define SipCallList weblink htmlCode {FHEM::SIP::html(mysip')}
Ich habe soweit auch alles installiert incl. NET::SIP. Aber das nowendige Paket libnet-sip-perl lässt sich unter Perl 5.20.3 nicht installieren.
cpan[4]> install libnet-sip-perl
Warning: Cannot install libnet-sip-perl, don't know what it is.
Try the command
i /libnet-sip-perl/
to find objects with matching identifiers.
20.3 ist meine perlbrew Installation auf der fhem läuft.
du verwechselst da Äpfel mit Birnen.
libnet-sip-perl ist mit Sicherheit ein Debian Paket und die werden mit apt-get install installiert.
CPAN Module wie Net::SIP mit cpan
D.h. wenn man ein Debian basiertes System hat (Ubuntu, Raspian, etc) würde ich immer den leichten Weg via apt-get install wählen.
Ausnahme : Man will unbedingt die neueste Version von Net::SIP, dann kann (bzw. muß) man den anderen Weg gehen, macht aber für mich aus User Sicht keinen Sinn, da die heutigen aktuellen Debian Pakete für den normalen Betrieb völlig ausreichend sind, das war vor zwei Jahren noch etwas anderes.
Aber wenn das Paket ein Debian ist, warum sollte es für fhem dann laut wiki für net:sip installiert werden ?
https://wiki.fhem.de/wiki/SIP-Client#FHEM-Server
(https://wiki.fhem.de/wiki/SIP-Client#FHEM-Server)
woran seh ich denn ob das Paket installiert ist ?
Normalerweise wird es über sudo apt-get install libnet-sip-perl in die aktuelle perl Version 5.24 installiert. Da ich aber über perlbrew für fhem eine 5.20.3 laufen habe muss das Paket auch da hinkopiert werden.
Dafür habe ich...
perlbrew use perl-5.20.3
perl -v
This is perl 5, version 20, subversion 3 (v5.20.3) built for armv7l-linux
sudo apt-get install -y libnet-sip-perl
Paketlisten werden gelesen... Fertig
Abh▒ngigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
libnet-sip-perl ist schon die neueste Version (0.808-1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Ist damit das Paket auch für 5.20.3 installiert ? Nur irgendwie lässt sich dann sip nicht installieren.
Der Satz im wiki stammt noch aus einer Zeit da die Debian Pakete uralte Net::SIP Versionen hatten und man unbedingt die aktuelle via CPAN installieren musste, wie ich aber bereits schrieb ist das heute i.d.R. nicht mehr der Fall.
ZitatNur irgendwie lässt sich dann sip nicht installieren.
den Satz verstehe ich nicht, welche Fehler hast du denn im Log wenn du das Modul mittels define einbindest ?
Ok, also NET::Sip habe ich installiert und auch ein define mySIP erstellt. Auf der FritzBox habe ich ein Gerät namens Fhem eingerichtet mit dem user fhemcall und einem PW, welches ich in fhem selbst mit set eingetragen habe. Dennoch passiert bei set mySIP call +4917... 30 !Alarm Alarm Alarm nichts.
Hier mal mein list...
Internals:
CPID 28500
FUUID 5f85af20-f33f-e9d9-6cd2-b369dd88f85b5bc0
NAME mySIP
NOTIFYDEV myT2S
NR 1378
NTFY_ORDER 50-mySIP
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
lastnr +4917...
READINGS:
2020-10-15 07:48:10 call +4917...
2020-10-15 07:48:10 call_state invite
2020-10-15 07:31:40 caller fetch
2020-10-15 07:48:10 listen_alive no
2020-10-13 15:44:05 state initialized
helper:
CALL mySIP|+4917...|30|cache/f9d0d2049d78964ae56a2397c246ce59.alaw|0|0
CALL_NR +4917...
CALL_START 1602740890
CALL_TYPE out
CALL_PID:
abortArg
abortFn
arg mySIP|+4917...|30|cache/f9d0d2049d78964ae56a2397c246ce59.alaw|0
bc_pid 5554
finishFn SIP_CALLDone
fn SIP_CALLStart
pid DEAD:28500
timeout
Attributes:
T2S_Device myT2S
group FritzBox
history_file ./log/mySIP.sip
history_size 0
room System->Fritzbox
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:fhemcall@fritz.box
sip_ip 192.xxx.xxx.xx
sip_listen dtmf
sip_registrar fritz.box
sip_ringtime 3
sip_user sip:fhemcall@fritz.box
versuch ich dann erneute dieses set abzuschicken, kommt...
there is already a call activ for target +4917...
auch dir kann ich da nur die übliche Antwort geben : verbose 5 am Device setzen und einen neuen Versuch starten ggf. mit einem anderen Ziel oder FHEM zuvor neu starten. Log posten, da sollte dann schon recht genau stehen was da so läuft bzw. eben nicht.
Und noch der Standart Tipp : nicht sip:fhemcall@fritz.box nutzen sondern sip:fhemcall@192.x.y.z d.h. die IP der Fritte
sip_ip 192.xxx.xxx.xx , dahinter versteckt sich die FHEM IP ?
hast du statt der +4917... auch mal 017... versucht ?
Edit :
sip_user sip:fhemcall@fritz.box , das ist falsch : sip_user fhemcall
Zunächst habe ich mal auf sip:fhemcall@192.x.y.z umgestellt. Ja, unter der sip_ip steht meine Ip worauf fhem erreichbar ist.
Zitatsip:fhemcall@fritz.box , das ist falsch : sip_user fhemcall
...angepasst.
So und verbose sagte mir dann noch...
cannot create resolver: Net::DNS not available?: Can't locate Net/DNS.pm in @INC (you may need to install the Net::DNS module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /opt/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/armv7l-linux /opt/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3 /opt/perlbrew/perls/perl-5.20.3/lib/5.20.3/armv7l-linux /opt/perlbrew/perls/perl-5.20.3/lib/5.20.3) at /opt/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/Net/SIP/Dispatcher.pm line 1164.
Aber das Modul ist installiert...
pi@raspberrypi:/opt/perlbrew/perls/perl-5.20.3/bin $ perlbrew use perl-5.20.3
A sub-shell is launched with perl-5.20.3 as the activated perl. Run 'exit' to finish it.
pi@raspberrypi:/opt/perlbrew/perls/perl-5.20.3/bin $ cpan
Terminal does not support AddHistory.
cpan shell -- CPAN exploration and modules installation (v2.05)
Enter 'h' for help.
cpan[1]> install Net::DNS Reading '/home/pi/.cpan/Metadata' Database was generated on Fri, 16 Oct 2020 03:56:00 GMT Net::DNS is up to date (1.27).
gib doch mal in der shell ein :
find / -name DNS.pm
im Normalfall ergibt das /usr/share/perl5/Net/DNS.pm
Bei dir müssten aber Treffer im Perl Suchpfad sein da wo auch Net::SIP gefunden wird:
/opt/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/Net/
Aber aus Neugier mal ne Ketzerfrage : Warum tust du dir alles mit perlbrew an ? und dann noch 5.20 ?
Eine Installation mittels apt-get wird eher die Standard-Pfade nutzen => /usr/share/perl5/Net/DNS.pm
Wieso sucht FHEM überhaupt in den div. perlbrew-Pfaden?
perl 5.20.3 ist eine perl version ohne memory leaks.
/usr/share/perl5/Net/DNS.pm
/usr/local/share/perl/5.24.1/Net/DNS.pm
/home/pi/perl5/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/Net/DNS.pm
Naja und warum 5.20.3 und perlbrew, wurde ja schon beantwortet. Ohne Speicherprobleme wäre auch auch bei 5.24 geblieben und müsste nicht alles wieder zurückdrehn.
Aktuell mit Buster ist v5.28.1 und bei mir (und auch soweit ich im "Speicher-Leak-Thread" mitbekommen habe) auch ok...
...ich habe den Perl-Brew-Amok bewusst ausgelassen...
(ich halte nichts von "Teil-Updates", weder fhem noch OS)
Gruß, Joachim
über apt update && apt full-upgrade ist scheinbar perl 5.28.x nicht verfügbar
Hast du Buster?
Ich habe es ganz normal mittels apt-get installiert/upgedated bekommen.
Auf Stretch ist noch 5.24 aktuell (und wird es verm. auch bleiben).
Gruß, Joachim
Raspian Buster ? Nein...
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
also bleibt uns nur perlbrew...
Zitat von: en-trust am 16 Oktober 2020, 11:41:27
also bleibt uns nur perlbrew...
Nein: update auf Buster...
Steht eh irgendwann an, da ja Stretch auch (irgendwann) "ausläuft"...
Ich versuche mein(e) System(e) aktuell zu halten...
EDIT: ist aber jetzt (langsam) OT...
Gruß, Joachim
Hmm, ein OS-update könnte man schon überlegen, aber über Perlbrew sollte es doch auch möglich sein, neuere Versionen zu aktivieren, oder?
Damit müßte 5.28 gehen, und du kannst dann auch gleich austesten, wie wie es denn unter Perl 7 (https://forum.fhem.de/index.php/topic,112420.0.html) liefe (basiert auf 5.32) :P ...
Zitat von: en-trust am 16 Oktober 2020, 10:16:41
/home/pi/perl5/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/Net/DNS.pm
vs
Zitat von: Wzut am 16 Oktober 2020, 08:16:23
Bei dir müssten aber Treffer im Perl Suchpfad sein da wo auch Net::SIP gefunden wird:
/opt/perlbrew/perls/perl-5.20.3/lib/site_perl/5.20.3/Net/
siehts den Unterschied ? deine Installation unter /home/pi ist gar nicht im Suchpfad !
Hallo,
heute Nacht hat das Modul von 2:00 bis 2:59 im Minutentakt timeout gemeldet.
Ich vermute, dass das ein "Opfer" der Zeitumstellung war. Mit der Rückstellung der Zeit stimmten wohl nich mehr die Zeitstempel zwischen fhem und sip-subprozess mehr überein.
Elektrolurch
In meinem Log steht nur
2020.10.25 02:02:02 1: Timeout for SIP_ListenStart reached, terminated process 28942
Kann also sein, dass der Restart sonstige Meldungen vermieden hat.
Da ich ja auf 5.28 Buster gewechselt bin und alles komplett neu installiert habe, sieht meine Speicherausnutzung von fhem mit 57% schlecht aus.
pi@SmartHome:~ $ top
top - 10:16:55 up 6 days, 18:52, 3 users, load average: 0,25, 0,19, 0,18
Tasks: 141 total, 1 running, 140 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,8 us, 0,3 sy, 0,0 ni, 97,7 id, 0,1 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 925,9 total, 200,6 free, 532,0 used, 193,3 buff/cache
MiB Swap: 100,0 total, 9,4 free, 90,6 used. 337,2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22102 fhem 20 0 [b]535112[/b] 490024 7500 S 7,0 51,7 112:18.10 perl
6516 pi 20 0 10296 2916 2540 R 1,0 0,3 0:00.34 top
und wo ist da jetzt das SIP Problem ?
IMHO sieht da gar nichts schlecht aus , auch die 57% sind kein Problem, das hatte Rudi im entsprechenden Memory Thread schön erklärt.
Ich habe zwar die Suchfunktion in diesem Thread verwendet aber leider nichts entsprechendes für meine eigentlich einfache Frage gefunden.
Ist es irgendwie möglich einen laufenden ausgehenden Anruf auch vor der Annahme durch den Partner wieder zu beenden?
Die CommandRef gibt auch nichts entsprechendes her, so dass ich davon ausgehe, dass diese Funktion einfach nicht vorgesehen ist oder habe ich nur einfach nichts gefunden?
versuch mal set <name> reset, dass killt einen aktiven Child Prozess.
Zitat von: Wzut am 27 Oktober 2020, 17:15:05
versuch mal set <name> reset, dass killt einen aktiven Child Prozess.
Das hab ich natürlich probiert, aber leider läuft der Anruf weiter. Im "call_state" steht dann weiterhin "calling <Rufnummer>" und im "state" steht "initialized". :-[
dann hat die FB bzw dein SIP Server schon komplett das Heft in der Hand und lässt es sich so einfach nicht mehr abnehmen.
Ah, ok. Aber nur für mein Verständnis; wie muss ich mir das vorstellen? Das FHEM SIP-Device ist ja in der FB als "LAN-Telefon" eingerichtet. Von dort geht der Callaufbau dann zu meinem VOIP-Anbieter. Wenn ich mit meinem DECT-Telefon an der FB eine Verbindung über meinen VOIP-Anbieter aufbaue ist das ja eigentlich der gleiche Weg über die gleichen Komponenten (FB -> SIP Server). Wenn ich aber an meinem DECT-Telefon nach Rufaufbau die rote Taste drücke, dannn wird der Rufaufbau beendet. Welche Befehle/Protokolle da im Hintergrund wie zusammenarbeiten, weiß ich natürlich nicht.
Warum funktioniert das mit dem SIP-Device nicht bzw. ist die Funktionalität der "roten Taste" hier nicht möglich?
Ich schrieb "so einfach" im Sinne von einfach den Prozess weghauen und nicht "gar nicht".
Man kann bestimmt der FB die rote Taste unterschieben ( $call->cancel ? ) aber das haben wir im Modul so nicht drin und ich habe es persönlich auch noch nie probiert.
Alles klar; entschuldige bitte das Verständnisproblem. :D
Dürfte ich denn das als Featurerequest vortragen?
Zum Hintergrund:
Ich möchte gerne das SIP-Modul als Alarmierungsmöglichkeit im Zusammenhang mit dem Alarmmodul benutzen. Grundsätzlich funktioniert das auch sehr gut. Wenn jetzt aber ein Fehlalarm (z.B. durch falsches Betreten oder eine Störung) erfolgt und dieser mittels eines Alarm-Resets wieder beendet wird, dann soll natürlich auch die Alarmierung mittels eines Anrufs über das SIP-Modul nicht mehr erfolgen. Dazu muss aber der Anruf abgebrochen werden, weil er sonst trotzdem rausgeht.
Gruß
Wolle
Zitat von: Wolle02 am 28 Oktober 2020, 07:51:35
Dürfte ich denn das als Featurerequest vortragen?
na sicher wünschen darf man sich immer :) Wir haben auf Userwunsch schon einige Dinge im Modul umgesetzt die wir selbst gar nicht brauchen.
Das Problem sehe ich für mich momentan in der freien Zeit, wird sich vllt. ab Januar 2021 ändern wenn ich endlich in Rente bin,
aber eventuell hat ja Peter (plin) Luft sich das mal zur Brust zu nehmen .....
Zitat von: Wzut am 28 Oktober 2020, 08:18:29
na sicher wünschen darf man sich immer :) Wir haben auf Userwunsch schon einige Dinge im Modul umgesetzt die wir selbst gar nicht brauchen.
Das Problem sehe ich für mich momentan in der freien Zeit, wird sich vllt. ab Januar 2021 ändern wenn ich endlich in Rente bin,
aber eventuell hat ja Peter (plin) Luft sich das mal zur Brust zu nehmen .....
Ich kann am Wochenende mal schauen was das Net::SIP Modul dafür ein petto hat.
Hallo!
Ich komme nicht weiter ...
Habe Fhem im Raspberry-Docker am Laufen, und bekomme bei einem initiiertem Anruf mit "call **621 30 !Hallo Test" nichts angesagt.
Wenn ich den Anruf starte, klingelt auch das Telefon. Nur die Ansage wird nicht ausgeführt.
Mein Device sieht so aus:
defmod telsip2 SIP
attr telsip2 T2S_Device mytts
attr telsip2 T2S_Timeout 10
attr telsip2 audio_converter sox
attr telsip2 disabled 1
attr telsip2 history_file ./log/telsip2.sip
attr telsip2 history_size 0
attr telsip2 room SIP
attr telsip2 sip_dtmf_loop once
attr telsip2 sip_dtmf_send audio
attr telsip2 sip_dtmf_size 2
attr telsip2 sip_elbc yes
attr telsip2 sip_from sip:telefon@192.168.178.1
attr telsip2 sip_ip 172.17.0.9
attr telsip2 sip_listen none
attr telsip2 sip_port 5060
attr telsip2 sip_registrar 192.168.178.1
attr telsip2 sip_ringtime 3
attr telsip2 sip_user telefon
attr telsip2 sip_waittime 5
attr telsip2 verbose 5
Was mir noch aufgefallen ist, dass die angegebene Log Datei "history_file ./log/telsip2.sip" auch nicht erstellt wird.
Eine statische Route habe ich bereits in meiner Fritzbox erstellt - sowie auch die anderen Maßnahmen, die in https://forum.fhem.de/index.php?topic=102206.0 (https://forum.fhem.de/index.php?topic=102206.0) diesem Thread beschrieben sind.
Die Audiodateien werden im cache-Verzeichnis erstellt.
Hier noch der gesamte Log, der in der Log-Datei steht:
2020.11.16 18:35:17 5: telsip2, MD5: Dies ist ein Test -> a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 5: telsip2, mp3 File file not found in cache
2020.11.16 18:35:17 4: telsip2, wait_for_t2s file : cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 4: telsip2, new T2S file cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3
2020.11.16 18:35:17 5: telsip2, /usr/bin/sox cache/a2dab4b2ac2ad4f047e943a077de79ec.mp3 -t raw -r 8000 -c 1 -e a-law cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw 2>&1
2020.11.16 18:35:17 4: telsip2, audio file cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw found
2020.11.16 18:35:17 4: telsip2, telsip2|**621|30|cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw|0
2020.11.16 18:35:17 4: telsip2, call -> telsip2|**621|30|cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw|0|0
2020.11.16 18:35:17 5: telsip2, call has pid 22412
2020.11.16 18:35:17 4: telsip2[22412], my parent is 57
2020.11.16 18:35:17 4: telsip2[22412], trying to use port 5070
2020.11.16 18:35:17 4: telsip2[22412], register new expire : 2020-11-16 18:40:17
2020.11.16 18:35:17 5: telsip2, readingS:state Val:calling
2020.11.16 18:35:17 4: telsip2[22412], CallStart with 1 files - first file : cache/a2dab4b2ac2ad4f047e943a077de79ec.alaw - PCMA/8000 , repeat 0
2020.11.16 18:35:17 4: telsip2[22412], calling : **621
2020.11.16 18:35:17 5: telsip2, readingS:call_state Val:calling **621
2020.11.16 18:35:21 4: telsip2[22412], cb_final - status : OK
2020.11.16 18:35:21 4: telsip2[22412], call established
2020.11.16 18:35:21 5: telsip2, readingS:call_state Val:established
2020.11.16 18:35:23 5: telsip2[22412], 0. Ende des ersten Loops
2020.11.16 18:35:23 5: telsip2[22412], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x47f8700)
2020.11.16 18:35:23 5: telsip2[22412], 2. fi : 0
2020.11.16 18:35:23 5: telsip2[22412], 4. timeout : 0
2020.11.16 18:35:23 5: telsip2[22412], 6. call_established : 1
2020.11.16 18:35:23 5: telsip2[22412], call->bye
2020.11.16 18:35:23 5: telsip2[22412], RTP done : Net::SIP::Simple::Call=HASH(0x47f8700)
2020.11.16 18:35:23 5: telsip2[22412], Timeout : 0
2020.11.16 18:35:23 5: telsip2[22412], while : 0
2020.11.16 18:35:23 5: telsip2[22412], Status : OK
2020.11.16 18:35:23 4: telsip2[22412], Calltime : 2
2020.11.16 18:35:23 4: telsip2, CALLDone -> telsip2|1|ok|2
2020.11.16 18:35:23 5: telsip2, fifo is empty
2020.11.16 18:35:23 5: telsip2, no elbc
Kann mir jemand helfen??
Zitat von: thunder1902 am 16 November 2020, 18:36:59
attr telsip2 history_file ./log/telsip2.sip
attr telsip2 history_size 0
size ungleich 0 stellen , ist die max Anzahl von Einträgen.
Docker & RTP -> https://wiki.fhem.de/wiki/SIP-Client#Docker
Zitat von: plin am 28 Oktober 2020, 18:10:49
Ich kann am Wochenende mal schauen was das Net::SIP Modul dafür ein petto hat.
Guten Morgen plin,
hast du hier eventl schon etwas herausbekommen?
Gruß
Wolle
@wzut:
Schau Dir mal im Net/SIP/Request.pm die Passage
###########################################################################
# Create cancel for request
# Args: $self
# Returns: $cancel
# $cancel: Net::SIP::Request containing CANCEL for $self
###########################################################################
sub create_cancel {
my Net::SIP::Request $self = shift;
# CANCEL uses cseq from request
$self->cseq =~m{(\d+)};
my $cseq = "$1 CANCEL";
my %auth;
for (qw(authorization proxy-authorization)) {
my $v = scalar($self->get_header($_)) or next;
$auth{$_} = $v;
}
my $header = {
'call-id' => scalar($self->get_header('call-id')),
from => scalar($self->get_header('from')),
# unlike ACK the 'to' header is from the original request
to => [ $self->get_header('to') ],
via => [ ($self->get_header( 'via' ))[0] ],
route => [ $self->get_header( 'route' ) ],
cseq => $cseq,
%auth
};
return Net::SIP::Request->new( 'CANCEL',$self->uri,$header );
}
an. Mittels Net::SIP::Request->new( 'CANCEL',$self->uri,$header ) könnte da evtl. etwas gehen.
VG plin
ja ok, da ist offensichtlich etwas da um einen laufenden Call mit CANCEL zu beenden.
Die gute Frage ist aber nun wie bindet man das sinnvoll ein und vor allem wo ?
Wo dreht das seine Runden sobald der Call raus ist ? -> $ua->loop( ? und da noch eine Variable $cancel als Abbruchmöglichkeit ?
Und dann die Frage, wie kommt die Info das abgebrochen werden soll vom Parent zum Child ?
Wir haben bisher nur die Gegenrichtung mit BlockingInforParent.
Beim lesen des Codes kam mir noch eine andere Idee : Wir starten doch mit $ua->add_timer($ringtime,\$stopvar) eine max Call Zeit.
Wenn man nun nachträglich diesen laufenden Timer so manipulliert könnte das er abgelaufen ist, dann sorgt doch die bestehende Kette für ein sauberes Ende des Calls ?
Zitat von: Wzut am 21 November 2020, 18:05:24
ja ok, da ist offensichtlich etwas da um einen laufenden Call mit CANCEL zu beenden.
Die gute Frage ist aber nun wie bindet man das sinnvoll ein und vor allem wo ?
Wo dreht das seine Runden sobald der Call raus ist ? -> $ua->loop( ? und da noch eine Variable $cancel als Abbruchmöglichkeit ?
Und dann die Frage, wie kommt die Info das abgebrochen werden soll vom Parent zum Child ?
Ich habe CANCEL-Requests gesehen bei denen man die kompletten Call-Informationen mitgibt. Vielleicht wird so der Call identifiziert.
Zitat von: Wzut am 21 November 2020, 18:05:24
Beim lesen des Codes kam mir noch eine andere Idee : Wir starten doch mit $ua->add_timer($ringtime,\$stopvar) eine max Call Zeit.
Wenn man nun nachträglich diesen laufenden Timer so manipulliert könnte das er abgelaufen ist, dann sorgt doch die bestehende Kette für ein sauberes Ende des Calls ?
Die Idee hatte ich auch schon. Kommt man da noch dran? Schaut der ausgehende Call immer wieder auf die Variable?
Ich habe mein Glück mal auf Basis des samples/invite_and_send.pl versucht. Puh. Während des ausgehenden Calls wartet das Script. Ein Versuch parallel dazu den CANCEL wie in 3pcc.pl abzussetzen hat bisher auch noch nicht gefruchtet.
Wie wär's mit einem FHEM shutdown restart? Der ist einfacher zu realisieren :).
Moin,
Ihr kennt das sicher, diese nervigen Werbeanrufe und sonstiger Müll. Da das bei mir in letzter Zeit immer schlimmer wird, bin ich bei der Suche nach einer Lösung auf dieses Modul gestoßen. Super Sache, danke an den Entwickler und alle Mitwirkenden !! :) :)
Mit einer Sperre über eine Blacklist kommt man nicht richtig weiter, weil diese Leute offensichlich große Rufnummernkontingente besitzen. Also, mein Konzept, alle Anrufe zurückweisen, die nicht in einer Whitelist (Telefonbuch der Fritz!Box) enthalten sind. Das ist zwar ne heftige Lösung, weil neue Kontakte nicht immer sofort im Telefonbuch eingepflegt sind. Aber mal versuchen und über ein userReading filtern, caller_nr ohne caller_name per set <sip_client> reject abweisen.
userReadings promotion:(caller_state.*) {stop_sales_promotion($name)}
und dann in einer sub
if ($caller_state eq "calling" and $caller_name eq "unknown") => reject
Allerdings habe ich mir mit diesem Prinzip teilweise FHEM-Loops bis hin zu Abstürzen des Raspi eingehandelt. Die Lösung war dann ein verzögertes reject mit einem AT.
sub stop_sales_promotion_01 ($){
my($name) = @_;
my$sub_name = "stop_sales_promotion_01";
Log3 $name, 2, "$name $sub_name: start";
fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client reject");
#fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client fetch"); #funktioniert
Log3 $name, 2, "$name $sub_name: end";
return;
};
Funktioniert teilweise, allerding beendet der sip_client NICHT das Gespräch, obwohl nach Lage der readings in der Weboberfläche alles klar ist.
Ich bin ratlos, was mache ich falsch ? :(
Oder gibt es eine bessere Lösung ?
Bin für jeden Tipp dankbar
Moin
Bernd
Zitat von: pwlr am 08 Februar 2021, 18:03:44
Moin,
Ihr kennt das sicher, diese nervigen Werbeanrufe und sonstiger Müll. Da das bei mir in letzter Zeit immer schlimmer wird, bin ich bei der Suche nach einer Lösung auf dieses Modul gestoßen. Super Sache, danke an den Entwickler und alle Mitwirkenden !! :) :)
Mit einer Sperre über eine Blacklist kommt man nicht richtig weiter, weil diese Leute offensichlich große Rufnummernkontingente besitzen. Also, mein Konzept, alle Anrufe zurückweisen, die nicht in einer Whitelist (Telefonbuch der Fritz!Box) enthalten sind. Das ist zwar ne heftige Lösung, weil neue Kontakte nicht immer sofort im Telefonbuch eingepflegt sind. Aber mal versuchen und über ein userReading filtern, caller_nr ohne caller_name per set <sip_client> reject abweisen.
userReadings promotion:(caller_state.*) {stop_sales_promotion($name)}
und dann in einer sub
if ($caller_state eq "calling" and $caller_name eq "unknown") => reject
Allerdings habe ich mir mit diesem Prinzip teilweise FHEM-Loops bis hin zu Abstürzen des Raspi eingehandelt. Die Lösung war dann ein verzögertes reject mit einem AT.
sub stop_sales_promotion_01 ($){
my($name) = @_;
my$sub_name = "stop_sales_promotion_01";
Log3 $name, 2, "$name $sub_name: start";
fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client reject");
#fhem("define stop_sales_promotion_at_01 at +00:00:00 set sip_client fetch"); #funktioniert
Log3 $name, 2, "$name $sub_name: end";
return;
};
Funktioniert teilweise, allerding beendet der sip_client NICHT das Gespräch, obwohl nach Lage der readings in der Weboberfläche alles klar ist.
Ich bin ratlos, was mache ich falsch ? :(
Oder gibt es eine bessere Lösung ?
Bin für jeden Tipp dankbar
Moin
Bernd
na ja, es gibt als Alternative den echo-Modus (siehe https://wiki.fhem.de/wiki/SIP-Client#Nervende_Werbeanrufe) oder Du spielst dem Anrufer einen kleinen Text vor (die synthetische Stimme schreckt die direkt ab). Die legen dann schon von alleine auf.
Ich nutze nicht mehr den SIP-Client sondern ein Blacklist-Telefonbuch in der FritzBox. Dort trage ich sukzessive alle Werbeanrufer ein. Anrufer aus dieser Liste werden automatisch an einen separaten Arufbeantworter mit entsprehender Ansage geleitet. Alle bekannten Rufnummern von Freunden etc. sind in meinem Telefonbuch und werden somit mit Namen angzeigt. Anrufe neuer Rufnummern nehmen wirst meist nicht an und ich googele ich erst mal ob es sich um SPAM handelt.
Moin,
ZitatIch nutze nicht mehr den SIP-Client sondern ein Blacklist-Telefonbuch in der FritzBox. Dort trage ich sukzessive alle Werbeanrufer ein.
Ja, hab ich bisher auch immer so gemacht. Aber nachdem mich neulich ein Werber aus dem Schlaf geklingelt hat, ist nun Schluß mit meiner Geduld.
Ansonsten,
ZitatFunktioniert teilweise, allerding beendet der sip_client NICHT das Gespräch, obwohl nach Lage der readings in der Weboberfläche alles klar ist.
ich nehme alles zurück, das Modul funktioniert ! Das Hängen der Verbindung wird durch eine von der Fritte parallel angesteuerten ISDN-Nebenstellenanlage verursacht.
Ich arbeite jetzt zur Umgehung dieses Problems mit fetch und damit scheint alles ok zu sein.
Das Blockieren kann durch ein Attribut aktiviert/deaktiviert werden und ich habe noch einen freien Rufnummernbereich definiert - in der Hoffnung, das keine Werber im Umkreis aktiv sind.
Die Aktionen werden mit DbLogInclude dokumentiert und ich schicke mir ne Mail mit der geblockten Nummer. Damit sollte ich dann wohl sehen, ob der ganze Kram funktioniert.
Der Testbetrieb hat begonnen.... Ich bin gespannt.
Moin
Bernd
Hallo wzut,
ich habe eine Anmerkung und eine Frage:
a) Bin gerade dabei mein Netzwerk umzustellen, da ich die (blöde) IP 192.168.1.0 verwendet habe und da die sehr weit verbreitet ist, gibt es aus manchen Netzwerken heraus Probleme mit dem Routing, wenn man einen VPN-Tunnel aufbaut.
Bei den Umbauten stelle ich u.a. auf dnsmasq um, dabei hat nicht alles geklappt und ich hatte Probleme mit fhem.
Dabei ist mir aufgefallen, dass das sip - Modul kein Atribut "disable" unterstützt, fhem konnte die Namen nicht auflösen und so hat das sip - Modul ständig Fehler gebracht.
Ein "disable" wäre da hilfreich gewesen, da ansonsten das log-file voll gemüllt wird.
Könntest Du das noch "nachrüsten"? Danke.
b) Ich habe mittlerweile einen "odroid H2" im Einsatz. Der hat zwei Netzwerkkarten und den möchte ich als Firewall verwenden.
Jetzt soll also das sip-Modul nur auf einer bestimmten Netzwerkkarte lauschen. Reicht es dafpür, dass Attribut "sip_ip" auf die IP der Karte zu setzen?
Welche Ports muss ich freigeben? (ip-tables)
Elektrolurch
disable : kein Problem, komisch das ich das bisher völlig übersehen habe... man wird eben alt :)
Ports :
Generell : der Unterbau Net::SIP verwendet eine realtiv große Range für Audio, man kann sie aber auch stark einschränken um z.B. auch bei Docker nicht riesen Bereiche freigeben zu müssen, siehe Wiki -> https://wiki.fhem.de/wiki/SIP-Client#Docker
Bei deinen Firewall Listen kannst aber schon mal beim Attribut sip_port ansetzen - default 5060 und dann noch einen zweiten Port um zehn mehr , also default 5070
Hallo wzut,
jetzt ist alles ein paar Tage einwandfrei gelaufen und heute habe ich zwei Dinge getan:
a) fhem aktualisiert, dabei haben sich die http_utils geändert, hosts mit domain-Namen in der /etc/hosts wurden in der Vergangenheit falsch erkannt.
b) Ich habe das zweite Netzwerkinterface aktiviert. Es hängt am Gastzugang (LAN4) der fritzbox und wird von dieser per dhcp konfiguriert.
Daran kann es eigentlich nicht liegen, da:
sip_ip 192.168.1.16
auf das korekte Interface 1 zeigen sollte.
Im log bekomme ich jedoch:
2021.03.15 16:26:36 1: Timeout for SIP_ListenStart reached, terminated process 671
2021.03.15 16:27:38 1: Timeout for SIP_ListenStart reached, terminated process 678
2021.03.15 16:28:40 1: Timeout for SIP_ListenStart reached, terminated process 685
2021.03.15 16:29:42 1: Timeout for SIP_ListenStart reached, terminated process 694
2021.03.15 16:30:44 1: Timeout for SIP_ListenStart reached, terminated process 721
2021.03.15 16:31:46 1: Timeout for SIP_ListenStart reached, terminated process 727
2021.03.15 16:32:48 1: Timeout for SIP_ListenStart reached, terminated process 733
2021.03.15 16:33:50 1: Timeout for SIP_ListenStart reached, terminated process 739
Woran könnte das liegen?
verbose 5 liefert auch keine Hinweise:
2021.03.15 16:36:56 1: Timeout for SIP_ListenStart reached, terminated process 758
2021.03.15 16:36:58 4: sip, Listen new PID : 766
2021.03.15 16:36:58 4: sip[766], my parent is 616
2021.03.15 16:36:58 4: sip[766], trying to use port 5060
Elektrolurch
Zitat von: Elektrolurch am 15 März 2021, 16:39:23
Es hängt am Gastzugang (LAN4) der fritzbox
sicher das Gäste SIP machen dürfen ? Ich habe da so meine Zweifel, kann es aber nicht testen da es bei mir keinen Gastzugang gibt.
Dein Log sieht sehr danach aus als ob das SIP Modul keine Antwort von der FB bekommt.
Es hängt am Gastzugang (LAN4) der fritzbox
Beim Gastzugang müssen dann wahrscheinlich alle Protokolle erlaubt werden. Gast kann ja eigentlich nur Mail und Internet.
pejonp
Hallo Wzut,
vielleicht habe ich mich etwas "unscharf" ausgedrückt:
Lan 1 ist mit 192.168.1.16 weiterhin konfiguriert und über einen switch mit der FB (192.168.1.254) verbunden. Damit hat das auch alles funktioniert, weder das Kabel, noch die Lan 1 Konfig wurden geändert.
Neu ist lediglich: Lan 2 Anschluss wurde jetz mit einem Kabel an den Lan 4 Anschluß der FB gesteckt, das Lan 2 Interface auf dhcp gestellt und bekommt die Adresse für ein Gäste-Lan mit 192.168.169.1 und Gateway .24.
Es ist noch keine Rute und kein IP-forwarding definiert.
Eigentlich sollte also das sip - Modul weiterhin den Lan 1 - Anschluß verwenden, so wie es der Server auch für die Verbindung zun lokalen Lan verwendet, über den dann auch die FB (wie bisher) zu erreichen ist.
attr sip sip_ip 192.168.1.16 = Lan 1 Interface
Die anderen Module, die die FB verwenden, wie der CallMonitor, die dect200 - Steckdosen oder das Fritzbox - Modul funktionieren ja weiterhin.
Es könnte auch an dem heutigen Update der http-utils liegen....? Denn das nun zusätzlich aktivierte Lan Interface 2 sollte ja vom sip - Modul nicht verwendet werden, da es ja nicht die IP 192.168.1.16 hat und die bisherige Verbindung sowohl physikalisch, als auch logisch wie bisher existiert.
Leider gibt verbose 5 keine Auskunft darüber, wohin die Kommunikation gehen soll.
Was macht dieser sub-Prozess überhaupt, der gem. log terminiert wird?
Wie werden die Adressen aufgelöst? Über die http-utils oder über das OS?
Derzeit habe ich in der /etc/hosts für die FB:
192.168.1.254 fritz.box Router
stehen.
Gruß
Elektrolurch
Hallo,
bei mir sind FHEM und die Fritzbox in unterschiedlichen VLANs. Damit scheint es auch nicht zu funktionieren. Gibt es da eine Chance?
Viele Grüße
Jürgen
und wer stellt die Verbindung der unterschiedlichen Vlans untereinander her ?
Müsste ja ein Router oder anderes Layer 3 Device sein und der sollte mit richtiger Config den Job machen.
Hallo Wzut,
ja da hängt ein CISC SG-250 als Switch dazwischen. Ich habe mich aber noch nie mit VOIP-Protokollen beschäftigt. Hast Du einen Tipp für mich? Ansonsten muss ich Dr. Google fragen 8)
Viele Grüße
Jürgen
Zitat von: Elektrolurch am 15 März 2021, 19:16:55
Hallo Wzut,
vielleicht habe ich mich etwas "unscharf" ausgedrückt:
...
Gruß
Elektrolurch
Was braucht der Mensch?
FHEM
- list des devices
Commandline:
- ip a
- ip route
- traceroute 192.168.1.254
Dann sehen wir weiter.
Zitat von: Elektrolurch am 15 März 2021, 19:16:55
Leider gibt verbose 5 keine Auskunft darüber, wohin die Kommunikation gehen soll.
Was macht dieser sub-Prozess überhaupt, der gem. log terminiert wird?
Wie werden die Adressen aufgelöst? Über die http-utils oder über das OS?
a. wie plin schrieb : list des SIP Device bitte
b. der Prozess ist dafür verantwortlich das die Fritte das Modul jederzeit direkt ansprechen kann.
c. idealerweise gar nicht, wenn man sich nur auf IPs beschränkt und keinerlei Namen benutzt, daher raten wir auch immer von Einträgen wie fritz.box in den Attributen ab.
@juemuc, so ein kleiner Cisco ist doch ein reines Layer 2 Device und kann kein Routing. Daher die Frage : wer macht das Routing in deinem Netz ?
Vermutlich wirst du da etwas ausführlicher werden müssen um als Ausenstehender die Topologie zu verstehen und auch warum man sich im Heimnetz unterschiedliche Vlans antut.
An den Internals kann ich nicht erkennen, was da schief läuft:
Internals:
AC /usr/bin/sox
FUUID 6048f70f-f33f-c8c3-05aa-621b2c68644767f0
LPID 3939
NAME sip
NOTIFYDEV tts
NR 904
NTFY_ORDER 50-sip
STATE defined
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2021-03-16 09:24:58 call done
2021-03-16 09:24:58 call_attempt 0
2021-03-16 09:24:58 call_state fail
2021-03-16 09:24:58 call_success 0
2021-03-16 09:24:58 call_time 0
2021-03-15 11:22:55 caller none
2021-03-15 11:22:55 caller_name ---
2021-03-15 11:22:55 caller_nr ---
2021-03-15 11:22:55 caller_state hangup
2021-03-15 11:22:55 caller_time 0
2021-03-15 15:57:54 expire 300
2021-03-16 09:24:58 last_error CallRegister: Failed with error 110
2021-03-15 16:01:26 listen_alive no
2021-03-16 09:24:58 state listen_wfp
helper:
LISTEN_PID:
abortArg
abortFn
arg sip
bc_pid 9
finishFn SIP_ListenDone
fn SIP_ListenStart
pid 3939
timeout
Attributes:
T2S_Device tts
audio_converter sox
event-on-change-reading .*
history_file ./log/sip.sip
history_size 0
sip_audiofile_wfp /media/Sonos/speak/report.alaw
sip_call_audio_delay 1.75
sip_dtmf_loop once
sip_dtmf_send audioattr sip sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc no
sip_force_interval 300
sip_from sip:fhemfhem@fritz.box
sip_ip 192.168.1.16
sip_listen wfp
sip_port 5060
sip_registrar fritz.box
sip_ringtime 2
sip_user fhemfhem
verbose 1
Jetzt habe ich mal die zwei Attribute durchgespielt, die den Hostnamen enthalten.
Ersetze ich beim registrar den Hostnamen durch eine IP, geht es wieder.
Setze ich wieder die IP in das Attribut, so steht im log:
2021.03.16 11:24:32 5: sip , SIP_Attr : reset
2021.03.16 11:24:33 4: sip, Listen Kill PID : 4017
2021.03.16 11:24:33 1: Timeout for SIP_ListenStart reached, terminated process 4017
2021.03.16 11:24:33 3: sip_not: sip rd listen_alive val no
2021.03.16 11:24:33 4: sip, Reset Listen done
2021.03.16 11:24:33 4: sip, Listen new PID : 4045
2021.03.16 11:24:33 4: sip[4045], my parent is 3889
2021.03.16 11:24:33 4: sip[4045], trying to use port 5060
2021.03.16 11:25:33 5: sip, listen process 4045 found
2021.03.16 11:25:33 1: Timeout for SIP_ListenStart reached, terminated process 4045
[code]
Da ist also nichts zu sehen. Wenn ich das aber nun richtig verstehe, so kann der sub-Prozess sich nicht an der FB registrieren, wenn der den Hostnamen mitbekommt.
Der sub-Prozess erzeugt wohl auch keine Ausgaben ins fhem-log, so dass man das nicht nachvollziehen kann.
Elektrolurch
Der Knackpunkt den wir schon oft hatten ist sip_registrar. Wenn du da einen Namen benutzt muss der von wem auch immer richtig aufgelöst werden.
Wenn du dann noch mehr als eine NIC hast kann das schon gut sein das das Paket zur Fritte aus dem falschen Interface fällt. Selbst User mit nur einer NIC sind hier schon oft gescheitert weil es eben mit der Namensauflösung irgendwie und irgendwo nicht klappte. Daher raten wir immer : Macht euch das Leben nicht unnötig schwer, tragt die IP ein und gut ist es.
Das Attribut sip_from sollte realtiv unkritsch sein (kannst ja mal testen, ich lasse mich da gern eines Besseren belehren),
da hier eigentlich keine direkte Namensauflösung vorgenommen wird und es sich mehr um eine Information handelt und der korrekte Aufbau mit sip: und @ aber extrem wichtig ist.
Der sub Prozess kann an diesem Punkt noch keine Log Ausgaben erzeugen da Net::SIP hier noch am werkeln ist und das müsste seine Probleme kund tun. Da es aber dies nicht tut kann der FHEM Hauptprozess nur feststellen das sein Child Prozess nicht so reagiert wie gewünscht und zieht mit Kindsmord (kill) die Notbremse.
Zitat von: Wzut am 16 März 2021, 07:56:20
@juemuc, so ein kleiner Cisco ist doch ein reines Layer 2 Device und kann kein Routing. Daher die Frage : wer macht das Routing in deinem Netz ?
Vermutlich wirst du da etwas ausführlicher werden müssen um als Ausenstehender die Topologie zu verstehen und auch warum man sich im Heimnetz unterschiedliche Vlans antut.
Hallo Wzut,
nein, das ist ein L3-Switch 8) Das Routing übernimmt die FB7490. Sonst könnten das mit den VLANs ja nicht funktionieren.
Viele Grüße
Jürgen
Hallo Wzut,
das Problem ist gelöst. Es war die Namensauflösung. Die FB ist nicht mehr unter Fritz.Box sonder nur noch unter FritzBox erreichbar. Nachdem ich die Einträge angepasst hatte, ist wieder alles ok.
Viele Grüße
Jürgen
Hallo Wzut,
auch bei mir konnte ich die Ursache feststellen:
Das 2. Interface stand auf dhcp und hat vom LAN 4 - Anschluss der FB auch den DNS - Eintrag bekommen. Der lag natürlich auf dem Gast-Anschluß.
Normalerweise würde man ja sagen, wenn der Anschluss deaktiviert wird, sollte das ja nichts machen, da in der /etc/resolv.conf ja ein im Netz funktionierender DNS-Server eingetragen ist.
Wie und wer da den über DHCP am 2. Interface zugewiesenen DNS-Server eingetragen hat, ist mir noch nicht klar.
Aber korriegiert und es geht wieder.
Elektrolurch
@Elektrolurch, schön das es nun geklärt ist. Da du aber gerade mitliest :
Hast du eigentlich mitbekommen das ich vor Monaten eine neue Funktion im Modul hatte, besser gesagt einen neuen listen Mode mit Namen am für answering machine ? Mit angeschlossenen Lautsprechern spielt der Modus nach Anrufende die Nachricht sofort ab. Ich nutze den Modus zur Zeit anstelle eines Homematic Funkgongs, da mich dort gestört hat das ich die Ansagetexte erst auf der SD hinterlegen muß.
Ich habe noch im Hinterkopf das du das Modul stark zusammen mit Text to speach nutzt, daher wäre der Modus vielleicht eine Opton für dich.
Hallo Wzut,
danke für die Info. Ist mir allerdings tatsächlich entgangen.
Aber mein Server ist zusammen mit der FB und Switchen auf dem Dachboden gelandet, so dass dort ein Lautsprecher für mich nicht so recht Sinn macht.... Höchstens und die Mitbewohner zu erschrecken... :-)
Aber ich habe etwas anderes realisiert, über den CallMonitor:
Wenn ein Anruf eingeht, wird dieser entweder über das lokale Adressbuch oder dem Internet auf den anrufenden Namen aufgelöst und dann per Sprachausgabe auf ein eingeschaltetetes Radio (Sonos oder SB) ausgegeben.
Ist kein Radio eingeschaltet, so erfolgt die Ansage, wenn ein Radio eingeschaltet wird (Komme nach Hause und bekomme die Info, wer versucht hat anzurufen)
Elektrolurch
ahh ok, Lösungen wie Sonos hatte ich überhaupt nicht auf den Radar, da ich selbst sowas nicht besitze.
Aber das ist ja schöne bei FHEM, viele Wege führen nach Rom und jeder kann sich seinen Lieblingsweg selbst ausuchen.
Hallo Zusammen,
habe das Modul installiert und es funktioniert auch soweit.
Was ich möchte:
Jemand klingelt an der ring doorbell und die fritzbox soll einen Anruf bei der eingerichteten Türsprechanalage erhalten.
Dann würde die Fritbox das Handteil klingeln lassen und ein Kamerabild anzeigen.
Was ich habe:
Kamerastrem ist vorhanden.
mit dem fhem ring modul kann ich ermitteln wenn jemand klingelt.
Das SIP Modul habe ich installiert und entsprechend eine Türsprechanlage in der fritzbox eingerichtet. Wenn ich diese anrufe sehe ich auch den caller_state usw. in fhem.
Gibt es eine Möglichkeit einen Klingelknopf zu simulieren? Wenn im ring modul ein Klingeln erkannt wird möchte ich über SIP der fritbox suggerieren, das er Caller sip:**11\@fritz.box geklingelt hat.
Danke und Gruß
Tja, was fällt mir so spontan ein?
Der vorgegaukelte "Anrufer" (hier das SIP-Modul) braucht einen Eintrag im Telefonbuch der Fritzbox. Als Name kann man vermutlich so etwas wie "**11@fritzbox" vorgaukeln.
Dann:
- Ein Besucher drückt den Klingelknopf.
- Das wird erkannt und triggert die Folgemaßnahmen.
- Ein Schnappschuss der Kamera muss als Foto abgelegt werden.
- Dem Eintrag im Telefonbuch wird das Foto untergejubelt.
- Das SIP-Modul startet einen Rundruf wie bei der Türklingel.
- Das Fritz-Telefon erkennt den Anrufer (SIP), zeigt aufgrund des Telefonbuchs das Foto und den dort hinterlegten Anrufernamen an.
@plin:
Danke für deine Überlegungen. Dein Ansatz ist evtl. auch möglich, dann muss der Anrufer aber nicht 11\@fritz.box heißen, sondern irgendwie. Der SIP server in der Fritzbox wäre dann auch keine Türsprechanlage sondern ein normales Telefon. Das Problem wäre das Foto im Telefonbuch zu ändern und das ganze auch noch zeitnah.
Bei meiner Überlegung habe ich das SIP Modul ja mit einer Türsprechanlage in der FritzBos verbunden. Wenn man in der Fritzbox eine Türsprechanlage anlegt, dann kann man dort auch eine Video Stream URL angeben, die muß noch nicht mal von der Türklingel stammen. Deshalb wäre das Bildproblem automatisch gelöst. Auch kann man dann einstellen welche Handgeräte klingeln sollen. Allerdings werden dort Klingelknöpfe ausgewertet. Türsprechanlagen wie die von Telegärtner melden sich der Fritzbox dann mit der Caller sip:**11\@fritz.box und die Box weiß welcher Knopf gedrückt wurde, so denke ich jedenfalls.
Vielleicht kann ich ein zweites SIP Device in fhem erstellen und einen weitern SIP Server in der Fritbox mit dem User 11, der dann die Türsprechanlage anruft. Ich glaube aber die SIP usernamen in der Fritzbox müssen mind 6 Zeichen haben, außerdem wird bei caller dann wohl die Rufnummer und nicht der User übertragen.
Unter http://www.oppermann-telekom.de/pdf/doorline-m03.pdf habe ich folgende Textpassage gefunden:
"Wird auf eine der Klingeltasten der TFE gedrückt, so wird das anstehende Spannungssignal ausgewertet und die entsprechende Signalisierung an die 2- Draht Schnittstelle abgegeben. Dabei erzeugen die Klingeltasten 1 bis 4 die Wahl der Ziffern '2' bis '5'. Als Wahlverfahren der DoorLine M 03 wird entweder ein IWV-oder ein MFV- Signal ausgesandt."
Die klassische Doorline wird ja an die a/b-Anschlüsse der FB angeschlossen. Über 2 Drähte kann man nicht viel kommunizieren, außer über MFV-Signale.
Probiert doch mal einen Anruf via SIP-Client (den Du ja als Telefonanlage konfiguriert hast) an die Rufnummer 2, die würde demnach der Taste 1 entsprechen.
Tatsächlich hat es so ähnlich funktioniert.
Die Klingeltastennummer kann man in der Fritzbox einstellen. Bei mir 11. Ich habe also mit dem SIP Client die Nummer 11 angerufen. Also sich selbst mit Klingelnummer anstelle der Rufnummer, so wie du es auch vorschlägst.
Tja und das geht. Das Fritzpohne klingelt.
Danke für die Hilfe
Zitat von: markus1407 am 20 Dezember 2018, 10:07:51
Hallo,
erstmal: das SIP Modul in kombination mit TTS ist echt cool! Vielen Dank dafür.
Ich denke ich habe im 96_SIP.pm Modul zwei Probleme entdeckt.
1) In Kombination mit SOX kann man mehrere Sätze nicht ausgeben lassen.
2) Bei einem Fehler sollte abgebrochen werden.
Aktuelle Version vom 20.12.2018.
Zunächst meine Config:
[...]
Ich benutze folgendes Kommando um mehrere Sätze zu erzeugen:
set MySipClient call **611 30 !Hallo FHEM Freunde. Das SIP-Modul ist cool.
Im ./cache/ Verzeichnis sieht man dass die einzelnen mp3 teile sowie das *MP3WRAP.mp3 erzeugt werden, jedoch nicht das *MP3WRAP.alaw file.
Scheinbar liegt es daran, dass "SOX" beim convertieren eine Warnung ausgibt: Logfile: "sox output : /usr/bin/sox WARN mp3-util: MAD lost sync"
1) Lösung des ersten Problems:
Diese Ausgabe wird dann von dem Modul als Fehler interpretiert.
Die Warnung kann bei SOX mit der Option "-V1" unterdrückt werden, dann funktioniert es.
$cmd = $hash->{AC}." ".$file." -V1 -t raw -r 8000 -c 1 -e a-law ".$out." 2>&1";
sub SIP_MP3_conv($$$)
...
if ($converter eq "sox")
{
$cmd = $hash->{AC}." ".$file."-V1 -t raw -r 8000 -c 1 -e a-law ".$out." 2>&1";
Log3 $name,5,"$logname, $cmd";
$ret = qx($cmd);
if ($ret)
{
unlink $out;
$ret =~ s/\n//g;
Log3 $name,5,"$logname, sox output : $ret";
}
2. Problem:
Wenn die Warnung von SOX als fehler behandelt wird, dann wird der Call trotzdem ausgefüht.
Anstatt des Textes werden DTMF Töne ausgegeben. (ich glaube das ist der inhalt der Variablen my $dtmf = 'ABCD*#123--4567890'; )
Bei einem Fehler sollte der Call abgebrochen werden und ein Log Eintrag erzeugt werden.
Hier könnte man die Fehlerbhandlung verbessern.
Wäre super wenn das jemand einpflegen kann.
Habe exakt das gleiche Problem (Google TTS größer 100 Zeichen, mp3filewrap) mit exakt den selben Symptomen (abgehackte Wiedergabe mit DTMF-Fragmenten). Warum wurde das noch immer nicht wie vorgeschlagen gefixt?![/code]
Zitat von: kunksmuhme am 11 April 2021, 23:11:17
Warum wurde das noch immer nicht wie vorgeschlagen gefixt?
Vermutlich weil die Modul Autoren träge Idoten sind und sehnsüchtig auf so ein fixes Kerlchen wie dich gewartet haben ....
Zitat von: Wzut am 12 April 2021, 06:57:41
Vermutlich weil die Modul Autoren träge Idoten sind und sehnsüchtig auf so ein fixes Kerlchen wie dich gewartet haben ....
Welchen SLA hatten wir doch noch bei diesem Tagessatz vereinbart?
Hallo zusammen,
hat jemand eine Idee, weshalb ein am SIP-Client ankommender Anruf von (verschiedenen) Android-Handys im listen_DTMF-Mode nach dem 2. Klingeln abgewiesen wir, während Anrufe von der 2. Telekomnummer an selben Anschluss vom SIP-Client (Raspberry Pi 4B+) angenommen werden und auch der listen_wfp-Mode keine Probleme bereitet?
Ich weiß nicht mehr, wo ich noch nach Hinweisen suchen sollte.
Hier das list -r des SIP-Devices:
define SIP_CLIENT SIP
attr SIP_CLIENT DbLogExclude .*
attr SIP_CLIENT T2S_Device t2s_device
attr SIP_CLIENT T2S_Timeout 15
attr SIP_CLIENT alias SIP_CLIENT
attr SIP_CLIENT audio_converter sox
attr SIP_CLIENT history_file ./log/SIP_DEVICE_CLIENT.sip
attr SIP_CLIENT history_size 200
attr SIP_CLIENT room 85_MESSAGES,99_SYSTEM->HILFSMODULE
attr SIP_CLIENT sip_call_audio_delay 0.75
attr SIP_CLIENT sip_dtmf_loop loop
attr SIP_CLIENT sip_dtmf_send audio
attr SIP_CLIENT sip_dtmf_size 4
attr SIP_CLIENT sip_elbc yes
attr SIP_CLIENT sip_from xxxxxxx
attr SIP_CLIENT sip_ip 172.16.0.xxx
attr SIP_CLIENT sip_listen dtmf
attr SIP_CLIENT sip_registrar tel.t-online.de
attr SIP_CLIENT sip_user sip:xxx.xxxxx@t-online.de
attr SIP_CLIENT verbose 5
und ein Auszug aus dem Eventmanager mit Log-File-Einträgen:
2021.04.20 19:27:43.669 5 : SIP_CLIENT, readingB:caller Val:sip:+49160xxxxxxx@ims.vodafone.de
2021.04.20 19:27:43.670 5 : SIP_CLIENT, readingB:caller_nr Val:+49160xxxxxxx
2021.04.20 19:27:43.670 5 : SIP_CLIENT, readingB:caller_name Val:unknown
2021.04.20 19:27:43.670 5 : SIP_CLIENT, readingB:caller_time Val:0
2021.04.20 19:27:43.671 5 : SIP_CLIENT, readingB:caller_state Val:calling
2021-04-20 19:27:43.686 SIP SIP_CLIENT caller: sip:+49160xxxxxxx@ims.vodafone.de
2021-04-20 19:27:43.686 SIP SIP_CLIENT caller_nr: +49160xxxxxxx
2021-04-20 19:27:43.686 SIP SIP_CLIENT caller_name: unknown
2021-04-20 19:27:43.686 SIP SIP_CLIENT caller_time: 0
2021-04-20 19:27:43.686 SIP SIP_CLIENT caller_state: calling
2021.04.20 19:27:43.687 5 : SIP_CLIENT, readingS:caller_state Val:ringing
2021-04-20 19:27:43.695 SIP SIP_CLIENT caller_state: ringing
2021.04.20 19:27:46.805 5 : SIP_CLIENT, readingS:caller_state Val:established
2021-04-20 19:27:46.811 SIP SIP_CLIENT caller_state: established
2021.04.20 19:27:47.174 5 : SIP_CLIENT, readingB:caller Val:sip:+49160xxxxxxx@ims.vodafone.de
2021.04.20 19:27:47.174 5 : SIP_CLIENT, readingB:caller_nr Val:+49160xxxxxxx
2021.04.20 19:27:47.175 5 : SIP_CLIENT, readingB:caller_name Val:unknown
2021.04.20 19:27:47.175 5 : SIP_CLIENT, readingB:caller_time Val:0
2021.04.20 19:27:47.175 5 : SIP_CLIENT, readingB:caller_state Val:calling
2021-04-20 19:27:47.186 SIP SIP_CLIENT caller: sip:+49160xxxxxxx@ims.vodafone.de
2021-04-20 19:27:47.186 SIP SIP_CLIENT caller_nr: +49160xxxxxxx
2021-04-20 19:27:47.186 SIP SIP_CLIENT caller_name: unknown
2021-04-20 19:27:47.186 SIP SIP_CLIENT caller_time: 0
2021-04-20 19:27:47.186 SIP SIP_CLIENT caller_state: calling
2021.04.20 19:27:47.187 5 : SIP_CLIENT, readingS:caller_state Val:ringing
2021-04-20 19:27:47.196 SIP SIP_CLIENT caller_state: ringing
Vielen Dank und viele Grüße
Frank
Zitat von: trabantp60 am 20 April 2021, 20:28:49
und ein Auszug aus dem Eventmanager mit Log-File-Einträgen:
Bitte nicht, poste bitte den betreffenden Abschnitt direkt aus der Log Datei (im Event Monitor steht nicht immer alles)
und schneide bitte das Log nicht zu früh ab. In deinem Post hat der Client ja noch gar nicht aufgelegt.
Sorry,
ich hoffe, so ist's besser:
2021.04.20 19:24:21.136 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:25:20.995 4: SIP_CLIENT[10710], register new expire : 2021-04-20 19:36:20
2021.04.20 19:25:20.997 5: SIP_CLIENT, readingB:state Val:listen_dtmf
2021.04.20 19:25:20.997 5: SIP_CLIENT, readingB:listen_alive Val:10710
2021.04.20 19:25:20.997 5: SIP_CLIENT, readingB:expire Val:660
2021.04.20 19:25:21.241 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:26:21.323 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:27:21.374 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:27:43.666 5: SIP_CLIENT[10710], SIP_filter : <sip:+49160XXXXXXX@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65554t1618939663m593389c126153s1_3280994596-545925051
2021.04.20 19:27:43.667 4: SIP_CLIENT[10710], SIP_filter: caller sip:+49160XXXXXXX@ims.vodafone.de, caller_nr +49160XXXXXXX, caller_name
2021.04.20 19:27:43.668 4: SIP_CLIENT[10710], cb_create : INVITE
2021.04.20 19:27:43.669 5: SIP_CLIENT, readingB:caller Val:sip:+49160XXXXXXX@ims.vodafone.de
2021.04.20 19:27:43.670 5: SIP_CLIENT, readingB:caller_nr Val:+49160XXXXXXX
2021.04.20 19:27:43.670 5: SIP_CLIENT, readingB:caller_name Val:unknown
2021.04.20 19:27:43.670 5: SIP_CLIENT, readingB:caller_time Val:0
2021.04.20 19:27:43.671 5: SIP_CLIENT, readingB:caller_state Val:calling
2021.04.20 19:27:43.674 5: SIP_CLIENT[10710], cb_invite_dtmf
2021.04.20 19:27:43.687 5: SIP_CLIENT, readingS:caller_state Val:ringing
2021.04.20 19:27:46.804 5: SIP_CLIENT[10710], cb_est_dtmf
2021.04.20 19:27:46.805 5: SIP_CLIENT, readingS:caller_state Val:established
2021.04.20 19:27:47.172 5: SIP_CLIENT[10710], SIP_filter : <sip:+49160XXXXXXX@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65554t1618939663m593389c126153s1_3280994596-545925051
2021.04.20 19:27:47.172 4: SIP_CLIENT[10710], SIP_filter: caller sip:+49160XXXXXXX@ims.vodafone.de, caller_nr +49160XXXXXXX, caller_name
2021.04.20 19:27:47.173 4: SIP_CLIENT[10710], cb_create : INVITE
2021.04.20 19:27:47.174 5: SIP_CLIENT, readingB:caller Val:sip:+49160XXXXXXX@ims.vodafone.de
2021.04.20 19:27:47.174 5: SIP_CLIENT, readingB:caller_nr Val:+49160XXXXXXX
2021.04.20 19:27:47.175 5: SIP_CLIENT, readingB:caller_name Val:unknown
2021.04.20 19:27:47.175 5: SIP_CLIENT, readingB:caller_time Val:0
2021.04.20 19:27:47.175 5: SIP_CLIENT, readingB:caller_state Val:calling
2021.04.20 19:27:47.178 5: SIP_CLIENT[10710], cb_invite_dtmf
2021.04.20 19:27:47.187 5: SIP_CLIENT, readingS:caller_state Val:ringing
2021.04.20 19:28:21.427 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:29:21.528 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:30:21.616 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:30:51.273 4: SIP_CLIENT[10710], register new expire : 2021-04-20 19:41:51
2021.04.20 19:30:51.432 5: SIP_CLIENT, readingB:state Val:listen_dtmf
2021.04.20 19:30:51.433 5: SIP_CLIENT, readingB:listen_alive Val:10710
2021.04.20 19:30:51.433 5: SIP_CLIENT, readingB:expire Val:660
2021.04.20 19:31:21.683 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:32:21.734 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:33:21.823 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:34:21.904 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:35:21.989 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:36:21.564 4: SIP_CLIENT[10710], register new expire : 2021-04-20 19:47:21
2021.04.20 19:36:21.567 5: SIP_CLIENT, readingB:state Val:listen_dtmf
2021.04.20 19:36:21.569 5: SIP_CLIENT, readingB:listen_alive Val:10710
2021.04.20 19:36:21.569 5: SIP_CLIENT, readingB:expire Val:660
2021.04.20 19:36:22.096 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:37:22.198 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:38:22.253 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:39:22.304 5: SIP_CLIENT, listen process 10710 found
2021.04.20 19:40:22.361 5: SIP_CLIENT, listen process 10710 found
Der Raspi werkelt im Übrigen mit statischer IP hinter einem Unifi USG 3 als PPPoE-Client (SIP ALG deaktiviert), hinter einem Draytek Vigor 165 Modem.
Ich habe soeben auch noch einen zweiten Festnetzanschluss getestet, der die selbe (Nicht-) Reaktion zeigt.
hmm schon komisch :
2021.04.20 19:27:47.178 5: SIP_CLIENT[10710], cb_invite_dtmf
2021.04.20 19:30:51.273 4: SIP_CLIENT[10710], register new expire : 2021-04-20 19:41:51
nach dem invite kommt lange nichts mehr, muss ichmal suchen wo der sich so stumm rumtreiben könnte,
denn eigentlich sollte das Ende des Calls auch im Log stehen
Ich hab ein Problem, das mich jetzt schon länger beschäftigt. Trotz intensiver Suche bin ich noch nicht dahinter gekommen, was das Problem ist.
Es passiert sporadisch, dass bei einem Anruf, den das Modul tätigt, der Status in einem "timeout" endet, obwohl der Anruf korrekt angenommen wurde. Das hat zur Folge, dass der Anruf nach der eingestellten Zeit wiederholt wird.
Und nicht entgegengenomme Anrufe enden korrekterweiße mit dem Status "no answer"
Langsam bin ich am verzweifeln, weil ich schon zig Varianten probiert habe. Wäre cool, wenn mal jemand drüberschauen könnte :)
So sieht der Aufruf aus:
set SIP_Device call 09811234567 120 !Nachricht *-2 &600
Und so meine Konfig:
define SIP_Device SIP
setuuid SIP_Device 5dfa2ab1-f33f-fbfd-86ce-1a4856d22c14b30f
attr SIP_Device T2S_Device myT2S
attr SIP_Device T2S_Timeout 60
attr SIP_Device audio_converter sox
attr SIP_Device history_file ./log/sip_device.log
attr SIP_Device history_size 50
attr SIP_Device sip_call_audio_delay 2
attr SIP_Device sip_dtmf_loop once
attr SIP_Device sip_dtmf_send audio
attr SIP_Device sip_dtmf_size 2
attr SIP_Device sip_elbc yes
attr SIP_Device sip_force_interval 600
attr SIP_Device sip_from sip:fhem-sip-device@192.168.2.1
attr SIP_Device sip_ip 192.168.2.34
attr SIP_Device sip_listen none
attr SIP_Device sip_registrar 192.168.2.1
attr SIP_Device sip_ringtime 3
attr SIP_Device sip_user fhem-sip-device
sip_device.log:
2021-05-04 02:33:50|out|unknown|09811234567|timeout|0| -> wieso passiert das? Der Anruf wurde korrekt entgegen genommen!
2021-05-04 02:45:50|out|unknown|09811234567|timeout|0| -> wieso passiert das? Der Anruf wurde korrekt entgegen genommen!
2021-05-04 02:57:50|out|unknown|09811234567|ok|19| -> Passt! Aber erst beim 3. Anlauf geht der Status auf OK
2021-05-04 08:59:28|out|unknown|09811234567|ok|14| -> Passt!
2021-05-04 12:15:13|out|unknown|09811234567|ok|11| -> Passt!
2021-05-04 21:18:28|out|unknown|09811234567|no answer|0| -> Passt!
2021-05-04 21:25:28|out|unknown|09811234567|ok|12| -> Passt!
2021-05-04 21:27:41|out|unknown|09811234567|ok|13| -> Passt!
Und hier der FHEM-Log
2021.05.04 02:33:50 3: SIP_Device, force call &600
2021.05.04 02:33:50 4: SIP_Device, msg will be repeat -2 times
2021.05.04 02:33:50 5: SIP_Device, MD5: Melkroboter Alarm - Mehrere unvollständige Gemelke hintereinander -> 77c6f70923e18bc98ff4c5172bbef660.mp3
2021.05.04 02:33:50 5: SIP_Device, mp3 File file not found in cache
2021.05.04 02:33:50 4: SIP_Device, wait_for_t2s file : cache/a709e0302dab642872e7f54bfe05b8dd.mp3
2021.05.04 02:33:50 4: SIP_Device, new T2S file cache/a709e0302dab642872e7f54bfe05b8dd.mp3
2021.05.04 02:33:50 5: SIP_Device, not converted - using cache/a709e0302dab642872e7f54bfe05b8dd.alaw from cache
2021.05.04 02:33:50 3: SIP_Device, force call &600,99,0
2021.05.04 02:33:50 4: SIP_Device, msg will be repeat -2 times
2021.05.04 02:33:50 4: SIP_Device, audio file cache/a709e0302dab642872e7f54bfe05b8dd.alaw found
2021.05.04 02:33:50 4: SIP_Device, SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2
2021.05.04 02:33:50 4: SIP_Device, call -> SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2|&600,99,0
2021.05.04 02:33:50 5: SIP_Device, call has pid 15858
2021.05.04 02:33:50 4: SIP_Device[15858], my parent is 842
2021.05.04 02:33:50 4: SIP_Device[15858], using Leg.pm to find a free port
2021.05.04 02:33:50 4: SIP_Device[15858], register new expire : 2021-05-04 02:38:50
2021.05.04 02:33:50 5: SIP_Device, readingS:state Val:calling
2021.05.04 02:33:50 4: SIP_Device[15858], CallStart with 4 files - first file : CODE(0x559e696b4ae0) - PCMA/8000 , repeat 2
2021.05.04 02:33:50 4: SIP_Device[15858], calling : 09811234567
2021.05.04 02:33:50 5: SIP_Device, readingS:call_state Val:calling 09811234567
2021.05.04 02:35:50 5: SIP_Device[15858], 0. Ende des ersten Loops
2021.05.04 02:35:50 5: SIP_Device[15858], 1. rtp_done : 0
2021.05.04 02:35:50 5: SIP_Device[15858], 2. fi : 0
2021.05.04 02:35:50 5: SIP_Device[15858], 4. timeout : 1
2021.05.04 02:35:50 5: SIP_Device[15858], 6. call_established : 0
2021.05.04 02:35:50 5: SIP_Device[15858], call->cancel
2021.05.04 02:35:50 5: SIP_Device[15858], RTP done : 0
2021.05.04 02:35:50 5: SIP_Device[15858], Timeout : 1
2021.05.04 02:35:50 5: SIP_Device[15858], while : -1
2021.05.04 02:35:50 4: SIP_Device[15858], Calltime : 0
2021.05.04 02:35:50 4: SIP_Device, CALLDone -> SIP_Device|1|timeout|0
2021.05.04 02:35:50 4: SIP_Device, read 50 lines from history file ./log/sip_device.log
2021.05.04 02:35:50 4: SIP_Device, at_forcecall_09811234567_3300 at +00:10:00 set SIP_Device call 09811234567 120 cache/a709e0302dab642872e7f54bfe05b8dd.alaw *-2 &600,99,1
2021.05.04 02:35:50 5: SIP_Device, fifo is empty
2021.05.04 02:35:50 5: SIP_Device, no elbc
2021.05.04 02:45:50 3: SIP_Device, force call &600,99,1
2021.05.04 02:45:50 4: SIP_Device, msg will be repeat -2 times
2021.05.04 02:45:50 4: SIP_Device, audio file cache/a709e0302dab642872e7f54bfe05b8dd.alaw found
2021.05.04 02:45:50 4: SIP_Device, SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2
2021.05.04 02:45:50 4: SIP_Device, call -> SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2|&600,99,1
2021.05.04 02:45:50 5: SIP_Device, call has pid 15859
2021.05.04 02:45:50 4: SIP_Device[15859], my parent is 842
2021.05.04 02:45:50 4: SIP_Device[15859], using Leg.pm to find a free port
2021.05.04 02:45:50 4: SIP_Device[15859], register new expire : 2021-05-04 02:50:50
2021.05.04 02:45:50 5: SIP_Device, readingS:state Val:calling
2021.05.04 02:45:50 4: SIP_Device[15859], CallStart with 4 files - first file : CODE(0x559e69862698) - PCMA/8000 , repeat 2
2021.05.04 02:45:50 4: SIP_Device[15859], calling : 09811234567
2021.05.04 02:45:50 5: SIP_Device, readingS:call_state Val:calling 09811234567
2021.05.04 02:47:50 5: SIP_Device[15859], 0. Ende des ersten Loops
2021.05.04 02:47:50 5: SIP_Device[15859], 1. rtp_done : 0
2021.05.04 02:47:50 5: SIP_Device[15859], 2. fi : 0
2021.05.04 02:47:50 5: SIP_Device[15859], 4. timeout : 1
2021.05.04 02:47:50 5: SIP_Device[15859], 6. call_established : 0
2021.05.04 02:47:50 5: SIP_Device[15859], call->cancel
2021.05.04 02:47:50 5: SIP_Device[15859], RTP done : 0
2021.05.04 02:47:50 5: SIP_Device[15859], Timeout : 1
2021.05.04 02:47:50 5: SIP_Device[15859], while : -1
2021.05.04 02:47:50 4: SIP_Device[15859], Calltime : 0
2021.05.04 02:47:50 4: SIP_Device, CALLDone -> SIP_Device|1|timeout|0
2021.05.04 02:47:50 4: SIP_Device, read 50 lines from history file ./log/sip_device.log
2021.05.04 02:47:50 4: SIP_Device, at_forcecall_09811234567_3300 at +00:10:00 set SIP_Device call 09811234567 120 cache/a709e0302dab642872e7f54bfe05b8dd.alaw *-2 &600,99,2
2021.05.04 02:47:50 5: SIP_Device, fifo is empty
2021.05.04 02:47:50 5: SIP_Device, no elbc
2021.05.04 02:57:50 3: SIP_Device, force call &600,99,2
2021.05.04 02:57:50 4: SIP_Device, msg will be repeat -2 times
2021.05.04 02:57:50 4: SIP_Device, audio file cache/a709e0302dab642872e7f54bfe05b8dd.alaw found
2021.05.04 02:57:50 4: SIP_Device, SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2
2021.05.04 02:57:50 4: SIP_Device, call -> SIP_Device|09811234567|120|cache/a709e0302dab642872e7f54bfe05b8dd.alaw|-2|&600,99,2
2021.05.04 02:57:50 5: SIP_Device, call has pid 15860
2021.05.04 02:57:50 4: SIP_Device[15860], my parent is 842
2021.05.04 02:57:50 4: SIP_Device[15860], using Leg.pm to find a free port
2021.05.04 02:57:50 4: SIP_Device[15860], register new expire : 2021-05-04 03:02:50
2021.05.04 02:57:50 5: SIP_Device, readingS:state Val:calling
2021.05.04 02:57:50 4: SIP_Device[15860], CallStart with 4 files - first file : CODE(0x559e69702a18) - PCMA/8000 , repeat 2
2021.05.04 02:57:50 4: SIP_Device[15860], calling : 09811234567
2021.05.04 02:57:50 5: SIP_Device, readingS:call_state Val:calling 09811234567
2021.05.04 02:58:12 4: SIP_Device[15860], cb_final - status : OK
2021.05.04 02:58:12 4: SIP_Device[15860], call established
2021.05.04 02:58:12 5: SIP_Device, readingS:call_state Val:established
2021.05.04 02:58:14 5: SIP_Device[15860], 0. Ende des ersten Loops
2021.05.04 02:58:14 5: SIP_Device[15860], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x559e6973de78)
2021.05.04 02:58:14 5: SIP_Device[15860], 2. fi : 0
2021.05.04 02:58:14 5: SIP_Device[15860], 4. timeout : 0
2021.05.04 02:58:14 5: SIP_Device[15860], 6. call_established : 1
2021.05.04 02:58:14 4: SIP_Device[15860], next file : cache/a709e0302dab642872e7f54bfe05b8dd.alaw
2021.05.04 02:58:15 4: SIP_Device[15860], cb_final - status : OK
2021.05.04 02:58:20 4: SIP_Device[15860], loop rtp_done : Net::SIP::Simple::Call=HASH(0x559e6973de78)
2021.05.04 02:58:20 4: SIP_Device[15860], next file : cache/a709e0302dab642872e7f54bfe05b8dd.alaw
2021.05.04 02:58:20 4: SIP_Device[15860], cb_final - status : OK
2021.05.04 02:58:25 4: SIP_Device[15860], loop rtp_done : Net::SIP::Simple::Call=HASH(0x559e6973de78)
2021.05.04 02:58:25 4: SIP_Device[15860], next file : cache/a709e0302dab642872e7f54bfe05b8dd.alaw
2021.05.04 02:58:25 4: SIP_Device[15860], cb_final - status : OK
2021.05.04 02:58:31 4: SIP_Device[15860], loop rtp_done : Net::SIP::Simple::Call=HASH(0x559e6973de78)
2021.05.04 02:58:31 5: SIP_Device[15860], call->bye
2021.05.04 02:58:31 5: SIP_Device[15860], RTP done : Net::SIP::Simple::Call=HASH(0x559e6973de78)
2021.05.04 02:58:31 5: SIP_Device[15860], Timeout : 0
2021.05.04 02:58:31 5: SIP_Device[15860], while : 2
2021.05.04 02:58:31 5: SIP_Device[15860], Status : OK
2021.05.04 02:58:31 4: SIP_Device[15860], Calltime : 19
2021.05.04 02:58:31 4: SIP_Device, CALLDone -> SIP_Device|1|ok|19
2021.05.04 02:58:31 4: SIP_Device, read 50 lines from history file ./log/sip_device.log
2021.05.04 02:58:31 5: SIP_Device, fifo is empty
2021.05.04 02:58:31 5: SIP_Device, no elbc
a. so muß eine Fehlerbeschreibung aussehen ! Alle notwendigen Infos gleich vorhanden ohne erst nachfragen zu müssen!
b. aber :
Zitat von: hansdepp am 04 Mai 2021, 22:33:52
Es passiert sporadisch
ist etwas was man als Modulautor gar nicht lesen möchte .... :(
Ok, beim lesen des Logs fällt auf :
2021.05.04 02:33:50 4: SIP_Device[15858], calling : 09811234567
2021.05.04 02:35:50 5: SIP_Device[15858], 0. Ende des ersten Loops
<--snipp-->
2021.05.04 02:45:50 4: SIP_Device[15859], calling : 09811234567
2021.05.04 02:47:50 5: SIP_Device[15859], 0. Ende des ersten Loops
<--snipp-->
2021.05.04 02:57:50 4: SIP_Device[15860], calling : 09811234567
2021.05.04 02:58:12 4: SIP_Device[15860], cb_final - status : OK
Bei den ersten beiden Versuchen wird bereits nach 2 Sekunden im Modul weitergearbeitet obwohl das eigentlich nicht sein kann.
D.h. auch hier haben wir eine ähnliche Situation wir beim Problem von trabantp60, das Logging kann leider nicht in die Tiefen von Net::SIP abtauchen.
@hansdepp, da du dir die Nachricht eh mehrfach vorsagen lässt : lösch doch bitte mal das Attribut attr SIP_Device sip_call_audio_delay 2
Kann purer Zufall sein das die 2 Sekunden so schön mit dem Fehlerbild zusammen passen.
Aber ich muß doch nochmal nachfassen :
Obwohl schon nach 2 Sekunden das Modul seine Arbeit einstellt, wird quasi im Hintergrund der Anruf weiter fortgesetzt und komplett inklusive Wiederholung durchgeführt ?
ZitatObwohl schon nach 2 Sekunden das Modul seine Arbeit einstellt, wird quasi im Hintergrund der Anruf weiter fortgesetzt und komplett inklusive Wiederholung durchgeführt ?
Ich meine eher, dass es 2 Minuten sind, die verstreichen. Während dieser Zeit wird das Telefonat angenommen und die Nachricht komplett abgehört. Irgendwie registriert das Modul dies aber nicht!
Die 2 Minuten würden eher mit den 120 Sek im Befehlsaufruf korrespondieren, die die maximale Nachrichtenlänge angeben soll, wenn ich es richtig verstanden habe. Das reicht für meine Nachrichtenlängen locker aus. Trotzdem habe ich diese Zeit jetzt auch mal auf 300 Sek erhöht. Allerdings habe ich jetzt noch kein Ergebnis dieses Tests.
Zitat@hansdepp, da du dir die Nachricht eh mehrfach vorsagen lässt : lösch doch bitte mal das Attribut attr SIP_Device sip_call_audio_delay 2
Ich habe schon sämtliche Attribute variiert oder auch weggelassen.
Ja hast natürlich Recht mit deinen 2 Minuten, war ich wohl gestsern doch noch nicht richtig wach.
Bei den Anrufen : Bist du wirklich ganz sicher das du auf jeden Fall das Modul "auflegen" lässt nachdem es alle Wiederholungen durch hat ?
Oder kann es auch auch passieren das du auflegst ?
Laut deinem Log und Aussage geht es immer zweimal schief und beim dritten Mal klappt es. Da ein Versuch selbst keine Ahnung hat ob er der erste zweite oder letzte ist :
Gibt es auch Varianten wo nur einmal wiederholt wird oder alle drei Versuche nicht erfolgreich sind ?
Sorry, meine Informationen waren auch nicht alle richtig.
ZitatBei den Anrufen : Bist du wirklich ganz sicher das du auf jeden Fall das Modul "auflegen" lässt nachdem es alle Wiederholungen durch hat ?
Nein. Ich hab nochmal nachgefragt, wie es wirklich war. Und zwar ist überhaupt keine Ansage zu hören. D.h. das Telefonat wird zwar hergestellt (sieht man im FB_Callmonitor oder in der Fritzbox), aber dann nur Stille. Nach ca. 20 Sekunden hatte die Person dann wieder aufgelegt. Und nach 2 Minuten lief das Modul dann in einem Timeout. Zu diesem Zeitpunkt war das Telefonat aber schon beendet.
Bei meinen provozierten Tests hat es immer ohne Probleme funktioniert, deshalb musste ich mich auf die Informationen von jemand anderes verlassen... Sorry nochmal, das war in meiner ursprünglichen Nachricht nicht ganz richtig dargestellt.
ZitatGibt es auch Varianten wo nur einmal wiederholt wird oder alle drei Versuche nicht erfolgreich sind ?
Meistens klappt es beim 1. Versuch. Bei ca. 20% ist ein 2. Versuch notwenig. Und 3 Versuche kommen ganz ganz selten vor.
Ok, das macht das Ganze in Bezug zum Logfile wenigstens logischer.
D.h. das Modul bzw Net::SIP bekommt nicht mit das abgenommen wurde und startet daher erst gar nicht die nachfolgende Kette sondern wartet brav bis zum 120 Sekunden Timeout.
Das ist jetzt so ein Fall wo man mit Wireshark auf die Netzwerebene runter müsste um zu sehen warum die Info Gegenstelle hat abgenommen nicht durchkommt.
09811234567 heißt Du rufst auf einem Endgerät im Festnetz an? Was hängt denn da am anderen Ende? Analog, ISDN, SIP, Telefonanlage???
FHEM bzw. das SIP-Modul ruft auf einem analogen Telefon an, das über eine Eumex504-Telefonanlage über den Fon-S0-Anschluss (ISDN) an die Fritzbox angeschlossen ist. Es ist übrigens dieselbe Fritzbox mit der sich auch FHEM verbindet.
Da es sporadisch auftritt (zumindest ist derzeit kein Zusammenhang erkennbar), macht es natürlich nochmals schwieriger.
Aber vielleicht hängt es damit zusammen, dass alles auf dem gleichen Anschluss passiert. Die Anrufe, bei denen ich zum Testen an einem anderen Telekom-Anschluss angerufen habe, haben nämlich keine Probleme gemacht. Kann aber auch Zufall sein, da ich es evtl. noch nicht oft genug versucht habe.
Zitat von: Wzut am 07 Mai 2021, 07:21:59
Das ist jetzt so ein Fall wo man mit Wireshark auf die Netzwerebene runter müsste um zu sehen warum die Info Gegenstelle hat abgenommen nicht durchkommt.
@wzut: Eine Alternative wäre
use Net::SIP::Debug '50';
use Net::SIP::Debug qw( Net::SIP*=50 Registrar=1 );
Wenn wir denn das was im Log steht verstehen ;D
Zitat von: hansdepp am 07 Mai 2021, 16:28:25
FHEM bzw. das SIP-Modul ruft auf einem analogen Telefon an, das über eine Eumex504-Telefonanlage über den Fon-S0-Anschluss (ISDN) an die Fritzbox angeschlossen ist. Es ist übrigens dieselbe Fritzbox mit der sich auch FHEM verbindet.
Wieso musst Du dann eine externe Rufnummer verwenden?
Ich hatte heute aus Verzweiflung alle (mir bekannten - sind nicht viele) Mögichkeiten ausprobiert, das Net::SIP Modul neu zu installieren.
Die Installation lief auch fast durch - halt nur fast:
pi@FHEMPI4:~ $ sudo perl -MCPAN -e shell
Terminal does not support AddHistory.
cpan shell -- CPAN exploration and modules installation (v2.20)
Enter 'h' for help.
cpan[1]> install Net::SIP
Reading '/root/.cpan/Metadata'
Database was generated on Thu, 06 May 2021 18:29:03 GMT
Running install for module 'Net::SIP'
Checksum for /root/.cpan/sources/authors/id/S/SU/SULLR/Net-SIP-0.829.tar.gz ok
Scanning cache /root/.cpan/build for sizes
............................................................................DONE
Configuring S/SU/SULLR/Net-SIP-0.829.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::SIP
Writing MYMETA.yml and MYMETA.json
SULLR/Net-SIP-0.829.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for S/SU/SULLR/Net-SIP-0.829.tar.gz
cp lib/Net/SIP/Request.pod blib/lib/Net/SIP/Request.pod
cp lib/Net/SIP/NATHelper/Server.pm blib/lib/Net/SIP/NATHelper/Server.pm
cp lib/Net/SIP/NATHelper/Base.pm blib/lib/Net/SIP/NATHelper/Base.pm
cp lib/Net/SIP/Debug.pod blib/lib/Net/SIP/Debug.pod
cp lib/Net/SIP/Packet.pod blib/lib/Net/SIP/Packet.pod
cp lib/Net/SIP/ReceiveChain.pod blib/lib/Net/SIP/ReceiveChain.pod
cp lib/Net/SIP/Authorize.pod blib/lib/Net/SIP/Authorize.pod
cp lib/Net/SIP/Dropper/ByIPPort.pm blib/lib/Net/SIP/Dropper/ByIPPort.pm
cp lib/Net/SIP/Redirect.pod blib/lib/Net/SIP/Redirect.pod
cp lib/Net/SIP/Registrar.pm blib/lib/Net/SIP/Registrar.pm
cp lib/Net/SIP/Packet.pm blib/lib/Net/SIP/Packet.pm
cp lib/Net/SIP.pod blib/lib/Net/SIP.pod
cp lib/Net/SIP/Request.pm blib/lib/Net/SIP/Request.pm
cp lib/Net/SIP/Debug.pm blib/lib/Net/SIP/Debug.pm
cp lib/Net/SIP/Dropper/ByField.pm blib/lib/Net/SIP/Dropper/ByField.pm
cp lib/Net/SIP/NATHelper/Base.pod blib/lib/Net/SIP/NATHelper/Base.pod
cp lib/Net/SIP/DTMF.pm blib/lib/Net/SIP/DTMF.pm
cp lib/Net/SIP.pm blib/lib/Net/SIP.pm
cp lib/Net/SIP/Endpoint.pod blib/lib/Net/SIP/Endpoint.pod
cp lib/Net/SIP/Endpoint/Context.pm blib/lib/Net/SIP/Endpoint/Context.pm
cp lib/Net/SIP/ReceiveChain.pm blib/lib/Net/SIP/ReceiveChain.pm
cp lib/Net/SIP/NATHelper/Server.pod blib/lib/Net/SIP/NATHelper/Server.pod
cp lib/Net/SIP/Dispatcher.pm blib/lib/Net/SIP/Dispatcher.pm
cp lib/Net/SIP/Dropper.pm blib/lib/Net/SIP/Dropper.pm
cp lib/Net/SIP/Blocker.pod blib/lib/Net/SIP/Blocker.pod
cp lib/Net/SIP/NATHelper/Client.pod blib/lib/Net/SIP/NATHelper/Client.pod
cp lib/Net/SIP/NATHelper/Local.pod blib/lib/Net/SIP/NATHelper/Local.pod
cp lib/Net/SIP/Dispatcher.pod blib/lib/Net/SIP/Dispatcher.pod
cp lib/Net/SIP/Leg.pm blib/lib/Net/SIP/Leg.pm
cp lib/Net/SIP/NATHelper/Client.pm blib/lib/Net/SIP/NATHelper/Client.pm
cp lib/Net/SIP/Dispatcher/Eventloop.pod blib/lib/Net/SIP/Dispatcher/Eventloop.pod
cp lib/Net/SIP/Endpoint.pm blib/lib/Net/SIP/Endpoint.pm
cp lib/Net/SIP/Dispatcher/Eventloop.pm blib/lib/Net/SIP/Dispatcher/Eventloop.pm
cp lib/Net/SIP/Registrar.pod blib/lib/Net/SIP/Registrar.pod
cp lib/Net/SIP/Leg.pod blib/lib/Net/SIP/Leg.pod
cp lib/Net/SIP/DTMF.pod blib/lib/Net/SIP/DTMF.pod
cp lib/Net/SIP/Authorize.pm blib/lib/Net/SIP/Authorize.pm
cp lib/Net/SIP/Blocker.pm blib/lib/Net/SIP/Blocker.pm
cp lib/Net/SIP/NATHelper/Local.pm blib/lib/Net/SIP/NATHelper/Local.pm
cp lib/Net/SIP/Redirect.pm blib/lib/Net/SIP/Redirect.pm
cp lib/Net/SIP/Endpoint/Context.pod blib/lib/Net/SIP/Endpoint/Context.pod
cp lib/Net/SIP/Response.pm blib/lib/Net/SIP/Response.pm
cp lib/Net/SIP/Simple/Call.pm blib/lib/Net/SIP/Simple/Call.pm
cp lib/Net/SIP/Util.pod blib/lib/Net/SIP/Util.pod
cp lib/Net/SIP/Response.pod blib/lib/Net/SIP/Response.pod
cp lib/Net/SIP/SDP.pod blib/lib/Net/SIP/SDP.pod
cp lib/Net/SIP/Simple.pm blib/lib/Net/SIP/Simple.pm
cp lib/Net/SIP/Simple/RTP.pm blib/lib/Net/SIP/Simple/RTP.pm
cp lib/Net/SIP/SDP.pm blib/lib/Net/SIP/SDP.pm
cp lib/Net/SIP/StatelessProxy.pm blib/lib/Net/SIP/StatelessProxy.pm
cp lib/Net/SIP/Simple.pod blib/lib/Net/SIP/Simple.pod
cp lib/Net/SIP/SocketPool.pm blib/lib/Net/SIP/SocketPool.pm
cp lib/Net/SIP/Simple/Call.pod blib/lib/Net/SIP/Simple/Call.pod
cp lib/Net/SIP/Util.pm blib/lib/Net/SIP/Util.pm
cp lib/Net/SIP/SocketPool.pod blib/lib/Net/SIP/SocketPool.pod
cp lib/Net/SIP/StatelessProxy.pod blib/lib/Net/SIP/StatelessProxy.pod
cp lib/Net/SIP/Simple/RTP.pod blib/lib/Net/SIP/Simple/RTP.pod
Manifying 30 pod documents
SULLR/Net-SIP-0.829.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01_load.t ............................. ok
t/02_listen_and_invite.t ................ 1/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ 9/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ 19/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ 29/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ 41/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ 49/60 # call created
# got ringing
# call established
# call cleaned up
t/02_listen_and_invite.t ................ ok
t/03_forward_stateless.t ................ ok
t/04_call_with_rtp.t .................... ok
t/05_call_with_stateless_proxy.t ........ ok
t/06_call_with_reinvite.t ............... ok
t/07_call_on_hold.t ..................... ok
t/08_register_with_auth.t ............... ok
t/11_invite_timeout.t ................... ok
t/12_maddr.t ............................ 1/48 # call established
# call cleaned up
t/12_maddr.t ............................ 7/48 # call established
# call cleaned up
t/12_maddr.t ............................ 15/48 # call established
# call cleaned up
t/12_maddr.t ............................ 23/48 # call established
# call cleaned up
t/12_maddr.t ............................ 31/48 # call established
# call cleaned up
t/12_maddr.t ............................ 39/48 # call established
# call cleaned up
t/12_maddr.t ............................ ok
t/13_maddr_proxy.t ...................... ok
t/14_bugfix_0.51.t ...................... # UAS on 127.0.0.1:5062
# UAC on 127.0.0.1:5060
# PROXY on 127.0.0.1:5063
t/14_bugfix_0.51.t ...................... ok
t/15_block_invite.t ..................... ok
t/16_drop_invite.t ...................... ok
t/17_call_with_reinvite_and_auth.t ...... ok
t/18_register_with_auth_step_by_step.t .. ok
t/19_call_with_dtmf.t ................... # UAS on 127.0.0.1:59397
# UAC on 127.0.0.1:48097
t/19_call_with_dtmf.t ................... 1/108 # call created
# call established
t/19_call_with_dtmf.t ................... 5/108 # call cleaned up
# received=468 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on 127.0.0.1:35950
# UAC on 127.0.0.1:39145
# call created
# call established
t/19_call_with_dtmf.t ................... 14/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:38506
# UAC on [::1]:38164
# call created
# call established
t/19_call_with_dtmf.t ................... 23/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:40189
# UAC on [::1]:39656
# call created
# call established
t/19_call_with_dtmf.t ................... 32/108 # call cleaned up
# received=464 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on 127.0.0.1:36151
# UAC on 127.0.0.1:57203
# call created
# call established
t/19_call_with_dtmf.t ................... 41/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on 127.0.0.1:50309
# UAC on 127.0.0.1:58517
# call created
# call established
t/19_call_with_dtmf.t ................... 50/108 # call cleaned up
# received=464 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:43475
# UAC on [::1]:57193
# call created
# call established
t/19_call_with_dtmf.t ................... 59/108 # call cleaned up
# received=465 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:36591
# UAC on [::1]:42437
# call created
# call established
t/19_call_with_dtmf.t ................... 68/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on 127.0.0.1:52497
# UAC on 127.0.0.1:46251
# call created
# call established
t/19_call_with_dtmf.t ................... 77/108 # call cleaned up
# received=465 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on 127.0.0.1:57713
# UAC on 127.0.0.1:41761
# call created
# call established
t/19_call_with_dtmf.t ................... 86/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:49721
# UAC on [::1]:48029
# call created
# call established
t/19_call_with_dtmf.t ................... 95/108 # call cleaned up
# received=467 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
# UAS on [::1]:46209
# UAC on [::1]:45605
# call created
# call established
t/19_call_with_dtmf.t ................... 104/108 # call cleaned up
# received=466 lost=0 expect ca. 467.5 packets, events='1 2 D # 3 4 B *'
t/19_call_with_dtmf.t ................... ok
t/20_channel_on_hold.t .................. ok
t/21_channel_on_hold_stateless_proxy.t .. ok
t/22_stateless_proxy_ack_on_error.t ..... ok
t/23_valid_message.t .................... ok
t/24_dtmf_audio.t ....................... ok
t/25_register_tcp_timeout.t ............. 1/4
# Failed test at t/25_register_tcp_timeout.t line 17.
# got: '101'
# expected: '110'
# Looks like you failed 1 test of 4.
t/25_register_tcp_timeout.t ............. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
Test Summary Report
-------------------
t/25_register_tcp_timeout.t (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 3
Non-zero exit status: 1
Files=23, Tests=1869, 300 wallclock secs ( 1.87 usr 0.25 sys + 77.87 cusr 18.14 csys = 98.13 CPU)
Result: FAIL
Failed 1/23 test programs. 1/1869 subtests failed.
make: *** [Makefile:978: test_dynamic] Fehler 1
SULLR/Net-SIP-0.829.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports SULLR/Net-SIP-0.829.tar.gz
Failed during this command:
SULLR/Net-SIP-0.829.tar.gz : make_test NO
Welche Ports muss die USG Firewall weiterleiten?
Zitat von: trabantp60 am 07 Mai 2021, 22:10:09
Ich hatte heute aus Verzweiflung alle (mir bekannten - sind nicht viele) Mögichkeiten ausprobiert, das Net::SIP Modul neu zu installieren.
...
Wie schaut's denn mit der Variante
sudo su -
cpan install Net::SIP
aus?
ZitatWieso musst Du dann eine externe Rufnummer verwenden?
Weil ich es kann ;D 8)
Scherz beiseite: Weil an der Eumex mehrere Telefone dranhängen, die gleichzeitig klingen sollen. Ich wüsste jetzt nicht, wie ich es anders machen sollte. In der Fritzbox haben nur die direkt oder per SIP angeschlossenen Telefone eine interne Nummer. Somit bleibt meiner Ansicht nur die externe Nummer. Oder übersehe ich etwas?
Hallo zusammen,
ich hoffe, ihr könnt mir bei meinem Problem weiterhelfen:
Ich habe das SIP Modul an meiner FritzBox erfolgreich eingerichtet und ich kann auch intern damit telefonieren. Folgender Spezialfall schlägt allerdings sporadisch fehl:
Ich möchte die Beleuchtung der Eingangstür damit steuern. Meine Türsprechanlage läuft als a/b-Telefon über die Fritzbox. Ich kann von meinem Handtelefon (DECT) bei aktiver Sprechverbindung zur Türsprechanlage (interne Nummer **1) durch Drücken von "##8" das Licht anschalten. Dies funktioniert stets zuverlässig.
Wenn ich dasselbe Manöver nun von FHEM auf dem RaspberryPi starte, kommt zwar ein Anruf zur Türsprechanlage zu Stande, aber das Licht schaltet sich nur sporadisch ein. Manchmal scheint er die Doppelraute 8 nicht korrekt zu erkennen und die Verbindung legt einfach ohne Betätigung des Lichts wieder auf.
Ich habe bereits beim Attribut "sip_dtmf_send" sowohl die Werte "audio" und "rfc2833" getestet: Bei rfc2833 funktioniert es nie, bei audio funktioniert es sporadisch, aber nicht zuverlässig.
Ich schicke folgenden Befehl zum Aufbau der Telefonats:
set FritzSIP call **1 10 -##8
Die 10s Wartezeit habe ich auch schon unterschiedlich getestet ohne Unterschied. Habt ihr noch eine Idee, was ich versuchen könnte?
sagt mal,
das
Zitatsip_ringtime
ist ja für eingehende Anrufe.
Gibts auch etwas für
ausgehende Anrufe, dass ich sage ich will es beim Empfänger nur 4 mal klingeln lassen?
Viele Grüße,
Frood
Leider nein, das Klingeln auf der Gegenseite können wir bzw. das Modul nicht direkt zählen.
Ich verwende dafür bei mir die Wartezeit in Sekunden, wenn du da etwas testest kommt das der Klingelanzahl i.d.R. recht nahe.
Okay, das klingt gut.
Wo ist bei
set <device> call <nummer> [<dauer>] [<audiofile oder Textnachricht>]
die Wartezeit?
Bei der [<dauer>] dachte ich bisher an Verbindungsdauer.
Das ist echt verwirrend - auf der ersten Seite steht:
Zitat
2. set mysip call **610 30 ( statt attr sip_ringtime wird nun 30 Sekunden geklingelt und zu hören bekommt man ein paar DTMF Signale)
und laut Wiki ist set mysip call:
Zitat
Anruf tätigen und DTMF-Töne senden
Den Anruf initiieren
set <device> call <nummer> <dauer> <-tastenkombination>
Und im CommandRef steht
sip_ringtime
Klingelzeit für eingehende Anrufe bei listen_for_dtmf
Ist nun
sip_ringtime für eingehende, ausgehende Anrufe oder für beides?
Viele Grüße, Frood
Hi, ich verwende das Modul schon sehr lange erfolgreich in Verbindung mit einer Doorbird Videotürklingel.
Nun wollte ich den SIP-Client ebenfalls nutzen, um DTMF Signale zu empfangen und auszuwerten.
Was mir nach einigen Tests eben dabei auffiel:
Es funktioniert nur, wenn ich #+Code (4stellig) ganz langsam eintippe.
Eine Telefonnummer samt DTMF Code abzuspeichern geht deswegen nicht.
Mache ich etwas falsch? Gibt es dafür irgendwo ein Attribut?
Ich nutze folgende Settings:
attr SIP sip_dtmf_loop loop
attr SIP sip_dtmf_send audio
attr SIP sip_dtmf_size 4
attr SIP sip_elbc yes
attr SIP sip_filter 17912****
attr SIP sip_listen dtmf
attr SIP sip_registrar fritz.box
attr SIP sip_ringtime 1
attr SIP sip_waittime 1
Danke für die Unterstützung!
Ronny
Zitat von: Frood42 am 16 September 2021, 12:12:25
Ist nun sip_ringtime für eingehende, ausgehende Anrufe oder für beides?
Hi, aus meiner Sicht für eingehende Anrufe:
sip_ringtime
listen: legt fest wie lange das Modul warten soll bis es den Anruf annimmt. Defaultwert ist 2, das entspricht ca. 1x klingeln.
https://wiki.fhem.de/wiki/SIP-Client
Hallo,
sorry für die Anfängerfrage aber ich bin wahrscheinlich zu doof. Wiki-Einrag gelesen und keinen Plan.
Problemstellung:
Ich möchte gerne, dass bei Anruf auf einer extern erreichbaren Nummer auf meiner Fritzbox und dem Übermitteln von diversen DTMF-Tönen verschiedene Schalthandlungen ausgeführt werden. Beispiel:
Ich rufe von unterwegs die Nummer xxxxxx an. Die Fritzbox nimmt den Anruf entgegen. Ich übermittle 123# über die bestehende Verbindung. FHEM schaltet das Licht im Garten an. Gespräch wird automatisch danach beendet.
Wenn ich die gleiche Nummer nochmal anrufe, aber dann die 222# übermittle, soll die Flurlampe angehen. Sonst alles gleich.
Jetzt scheitere ich schon daran, die richtigen Daten im SIP-Modul einzutragen.
Was habe ich? Eine Fritzbox. Eine VOIP(SIP)-Rufnummer von sipgate. Die Rufnummer ist in der Fritzbox eingerichtet und kann auch angerufen werden.
So. Und ab jetzt komme ich nicht mehr weiter.
Eingetragen in der FB:
- Unter eigene Rufnummern die Rufnummer xxxx (Anschluss Internet, Anbieter sipgate, Vorauswahl *124#)
Was muss ich jetzt im SIP-Modul einrichten? Was ist notwendig, um dem oben genannten Ziel näher zu kommen?
Vielen Dank im Voraus für jede Hilfe!
Grüße Frank
PS: Wenn ich vorhätte, nur eine einzige Aktion ausführen zu wollen, könnte ich das über den CallMonitor und ein notify lösen. Ich möchte aber eine Rufnummer, mit der ich verschiedene Aktionen auslösen kann, abhängig vom übermittelten DTMF-Code.
Nachtrag:
Problem ist gelöst, ich habe das nun nicht mehr direkt über das SIP-Modul und direkt zum SIP-Provider gemacht sondern über die Fritzbox, analog dem WIKI.
Und hat funktioniert. Nur das mit dem zuverlässigen Erkennen von DTMF-Tönen von unterschiedlichen Endgeräten (Festnetz, Handy) ging nicht. Mal ging es mal nicht.
Hallo!
Wie mache ich im TTS-Befehl eine Pause?
z.B. set telsip call **9 20 !Hallo <Pause> dies ist ein Test
Kann mir da jemand einen Tip geben?
Zitat von: frankreed am 06 Oktober 2021, 15:42:36
Ich rufe von unterwegs die Nummer xxxxxx an. Die Fritzbox nimmt den Anruf entgegen. Ich übermittle 123# über die bestehende Verbindung. FHEM schaltet das Licht im Garten an. Gespräch wird automatisch danach beendet.
Der SIP-Client nimmt den Anruf entgegen, nicht die Fritzbox, d.h. Du musst die Fitzbox so konfigurieren, dass Dein SIP-Client auf Anrufe bei Deiner VOIP-Nummer reagiert. Wenn's bei dem klingelt hast Du verschiedene Optionen der DTMF-Annahme, danach kannst Du die als Reading auswerten und irgendetwas schalten.
Zitat von: frankreed am 06 Oktober 2021, 15:42:36
Was muss ich jetzt im SIP-Modul einrichten? Was ist notwendig, um dem oben genannten Ziel näher zu kommen?
Was hast Du denn schon eingerichtet? Poste mal ein list Deines FHEM SIP-Devices (Passwörter/Rufnummern ausgeixxt).
VG plin
Zitat von: thunder1902 am 07 Oktober 2021, 20:17:21
Hallo!
Wie mache ich im TTS-Befehl eine Pause?
z.B. set telsip call **9 20 !Hallo <Pause> dies ist ein Test
Kann mir da jemand einen Tip geben?
ich habe nur das hier gefunden https://stackoverflow.com/questions/59819936/adding-a-pause-in-google-text-to-speech
Guten Abend zusammen,
ich nutze das SIP Modul in FHEM nun seit einigen Wochen um mich bei bsp. Auslösen der Alarmanlage zusätzlich per Anruf zu Infomieren, dass klappt soweit auch.
Gibt es aber die möglichkeit, das ich einen Auruf bekomme und dann im selben Anruf auf DTMF Befehle (um bsp. den Alarm auszuschalten) senden kann?
Zitat von: Fillip am 16 Oktober 2021, 23:13:16
Gibt es aber die möglichkeit, dass ich einen Auruf bekomme und dann im selben Anruf auf DTMF Befehle (um bsp. den Alarm auszuschalten) senden kann?
nein, die gibt es bisher nicht
P.S. Ich nutze für die Alarmierung den TelegramBot. Dann kann man auch Statusnachrichten ohne großen Aufwand versenden.
Zitat von: Fillip am 16 Oktober 2021, 23:13:16
Gibt es aber die möglichkeit, das ich einen Auruf bekomme und dann im selben Anruf auf DTMF Befehle (um bsp. den Alarm auszuschalten) senden kann?
DTMF und VoIP ist nicht ganz trivial. Es gibt die Möglichkeit DTMF Inband, also als reine Töne zu schicken, welche dann ausgewertet werden müssen. Das ist doppelt problematisch, zum Einen die reine Auswertung, und auch die Verfälschung der Töne durch die Codierung in VoIP-Paketen erschwert die Auswertung. In Hardware machen das die verbauten DSPs recht gut, in Software muss da etwas mehr Aufwand getrieben werden. Dann gibt es Outband-DTMF, wo die Töne als besondere Datenpakete übertragen werden. Hier ist die Auswertung sehr einfach, jedoch entscheidet IMHO der Anrufer, welche Übertragung gewählt wird. Und dann ist da noch die Option der redundanten Übertragung auf beiden Wegen...
Niels
Zitat von: Muschelpuster am 18 Oktober 2021, 07:59:46
DTMF und VoIP ist nicht ganz trivial. Es gibt die Möglichkeit DTMF Inband, also als reine Töne zu schicken, welche dann ausgewertet werden müssen. Das ist doppelt problematisch, zum Einen die reine Auswertung, und auch die Verfälschung der Töne durch die Codierung in VoIP-Paketen erschwert die Auswertung. In Hardware machen das die verbauten DSPs recht gut, in Software muss da etwas mehr Aufwand getrieben werden. Dann gibt es Outband-DTMF, wo die Töne als besondere Datenpakete übertragen werden. Hier ist die Auswertung sehr einfach, jedoch entscheidet IMHO der Anrufer, welche Übertragung gewählt wird. Und dann ist da noch die Option der redundanten Übertragung auf beiden Wegen...
Niels
Was will uns dieser Post sagen? Hast Du das Modul im Einsatz???
Zitat von: plin am 18 Oktober 2021, 18:37:35
Was will uns dieser Post sagen?
Nur, das es IMHO keine gute Idee ist über eine Implementierung nachzudenken.
Zitat von: plin am 18 Oktober 2021, 18:37:35Hast Du das Modul im Einsatz???
Zu Hause nein, aber bei meiner Mutter leistet es gute Dienste, auch wenn es nur die Türklingel ,verstärkt'.
Niels
Zitat von: Muschelpuster am 18 Oktober 2021, 20:32:20
Nur, das es IMHO keine gute Idee ist über eine Implementierung nachzudenken.
Das Modul kann schon
- einen Anruf absetzen und dem Angerufenen DTMF-Töne vorspielen
- auf einen Anruf warten/entgegennehmen, DTMF-Töne auswerten und diese in einem Reading speichern
Das "drüber nachdenken" in puncto anrufen, etwas abspielen und dann auf DTMF-Eingaben warten hapert schlicht und einfach am Perl-Modul Net::SIP. Es gibt einige mitgelieferte Beispiele, aber die Dokumentation ist nicht sooo aussagekräftig, dass man gerade mal nebenbei den gewünschten Use Case realisieren kann. Das ist mit viel Tüftelei (aka try & error) verbunden ...
Erstmals vielen Dank an die Modulentwickler! Gemäß WIKI eingerichtet und funktioniert.
Gerne hätte ich eine Funktion "Anruf tätigen und DTMF-Töne empfangen" realisiert. FHEM SIP ist in der Fritzbox als IP-Türsprechanlage eingerichtet. Klingeltaste (ein RASPI GPIO) löst über das SIP Modul einen Anruf auf eine Rufgruppe (AVM DECT-Telefone) aus. Das funktioniert. Vom Telefon aus könnte man den einen Türöffner durch senden von DTMF Tönen betätigen. Diese Tonfolge möchte ich als Reading weiter verarbeiten. Durch lesen und "probieren" ist mir das bisher nicht gelungen. Das im WIKI beschrieben Reading "dtmf: Die via Tonwahl (DTMF) eingegebenen Zahlen" taucht bei mir nicht auf.
Daher meine Frage: Kann dass das Modul bzw. was mache ich falsch und wie müsste die Konfiguration dafür aussehen?
Danke, Michael
Internals:
FUUID 6163ef83-f33f-c76d-9b08-cabf37a4c409f3d2
NAME FHEM_SIP
NOTIFYDEV global
NR 455
NTFY_ORDER 50-FHEM
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
READINGS:
2021-11-12 18:05:05 call done
2021-11-12 18:05:05 call_attempt 0
2021-11-12 18:05:05 call_state timeout
2021-11-12 18:05:05 call_success 0
2021-11-12 18:05:05 call_time 2
2021-11-06 18:11:23 caller reject
2021-11-12 18:04:52 expire 300
2021-11-12 11:15:33 last_error ListenRegister: Failed with code 401
2021-11-12 18:04:52 listen_alive 10010
2021-11-12 18:05:05 state initialized
helper:
CALL_BYE timeout
CALL_ERROR 1
CALL_NAME unknown
CALL_NR 11
CALL_START 1636736692
CALL_TIME 2
CALL_TYPE out
Attributes:
history_file ./log/FHEM.sip
history_size 0
sip_dtmf_loop once
sip_dtmf_send rfc2833
sip_dtmf_size 2
sip_elbc no
sip_from sip:FHEMSipClient@10.152.52.254
sip_ip 10.152.52.111
sip_listen dtmf
sip_registrar 10.152.52.254
sip_ringtime 3
sip_user FHEMSipClient
sip_waittime 2
Zitat von: tremichl am 12 November 2021, 18:32:47
Gerne hätte ich eine Funktion "Anruf tätigen und DTMF-Töne empfangen" realisiert.
Daher meine Frage: Kann dass das Modul bzw. was mache ich falsch und wie müsste die Konfiguration dafür aussehen?
Hallo Michael,
das Modul bietet diese Funktion nicht an.
VG Peter
Danke für die Info! Schade.
Im Prinzip wäre ja im Modul schon alles dafür notwendige vorhanden wie z.B. DTMF-Auswertung und Ruf-Auslösung. Wäre diese Funktion mit vertretbarem Aufwand machbar? Die Konstellation Fritz-Box, FHEM, Türklingel/Türöffner ist sicher öfter gegeben.
LG, Michael
Zitat von: tremichl am 13 November 2021, 12:08:38
Im Prinzip wäre ja im Modul schon alles dafür notwendige vorhanden wie z.B. DTMF-Auswertung und Ruf-Auslösung. Wäre diese Funktion mit vertretbarem Aufwand machbar? Die Konstellation Fritz-Box, FHEM, Türklingel/Türöffner ist sicher öfter gegeben.
Ja, so hat alles angefangen. Aber dann stelle ich mir die Frage wie der Prozess aussehen soll? Kannst Du den mal beschreiben.
Hallo Peter!
Das wäre der Wunsch:
für Türklingel: Modul baut einen Anruf auf (zB über ein notify) löscht DTMF Reading, wartet auf Rufannahme und beendet diesen nach einer vorgegeben Zeit wenn Ruf nicht angenommen wird (das funktioniert ja schon)
für Türöffner: Nach Rufannahme der Gegenstelle wartet Modul eine vorgegebene Zeit auf z.B. 2 bis 4 DTMF Signale, dekodiert diese und befüllt ein DTMF Reading und trennt danach die Verbindung.
Im Grunde "Anruf tätigen und DTMF-Töne empfangen". Das wäre eine elegante Möglichkeit AVM DECT Telefone nicht nur als verlängerte Türklingel, sondern auch für den Türöffner benutzen zu können.
LG, Michael
Zitat von: tremichl am 13 November 2021, 17:14:55
Hallo Peter!
Das wäre der Wunsch:
für Türklingel: Modul baut einen Anruf auf (zB über ein notify) löscht DTMF Reading, wartet auf Rufannahme und beendet diesen nach einer vorgegeben Zeit wenn Ruf nicht angenommen wird (das funktioniert ja schon)
für Türöffner: Nach Rufannahme der Gegenstelle wartet Modul eine vorgegebene Zeit auf z.B. 2 bis 4 DTMF Signale, dekodiert diese und befüllt ein DTMF Reading und trennt danach die Verbindung.
Im Grunde "Anruf tätigen und DTMF-Töne empfangen". Das wäre eine elegante Möglichkeit AVM DECT Telefone nicht nur als verlängerte Türklingel, sondern auch für den Türöffner benutzen zu können.
LG, Michael
mmhh, jetzt hast Du beschrieben was Du haben möchtest, aber nicht wie der Gesamtablauf aussehen soll und wie das zugehörige Umfeld aussieht.
Wenn ich das richtig sehe möchtest Du
- jemand klingelt an der Tür
- Welche Hardware nutzt Du hier? Eine Doorline?
- die Fritzbox leitet den Anruf von **11 an Telefone weiter (nur das SIP-Modul oder auch andere interne Telefone?)
- Was macht das SIP-Modul jetzt wenn's klingelt?
- dann soll das SIP-Modul jemanden anrufen (intern oder extern?)
- der Angerufene tippt den DTMF-Code für das Öffnen des Türschließers ein
- Ist der Türöffner an die Klingel angeschlossen oder ein separates Teil?
- die Tür öffnet sich für den Menschen vor der Tür
Ist das der gedachte Ablauf???
VG Peter
ja, ich habe der Einfachheit halber nur beschrieben was das SIP Modul machen soll. Hier der gesamte Vorgang:
- jemand klingelt an der Tür (ein Taster an einem RPI GPIO)
- ein notify löst einen Anruf über das SIP Modul (eingebunden in der Fritzbox als Türsprechanlage) aus (set FHEM_SIP call 11 13), DECT Telefone läuten und zeigen ein Bild der Haustür-CAM (Dahua) an, Sonos Lautsprecher geben über speak ein Klingeln aus, ein CAM-Snapshot wird gemacht und per E-Mail verschickt und an einem Tablet öffnet sich für 30 Sekunden ein Fenster mit dem Bild der Haustür-CAM
- am DECT Telefon gibt es eine Taste "ÖFFNEN" diese nimmt den Anruf an und sendet eine Sequenz DTMF Töne (konfigurierbar in der Fritzbox/Türsprechanlage)
- das SIP-Modul soll die DTMF Töne auswerten und in ein Reading schreiben.
- ein notify nützt diese Reading um einen Türöffner (hängt an einem RPI GPIO) zu betätigen
- die Tür öffnet sich
Die letzten 3 Punkte fehlen mir noch. An Hardware gibt es an der Tür einen Klingeltaster, einen magnetischen Türöffner, und eine IP-CAM. Bisher war eine analoge Türsprechstelle dran, die ich auf diesem Weg teilweise ersetzen möchte. Auf eine Sprechverbindung wird verzichtet.
Danke
LG, Michael
Zitat von: hansdepp am 04 Mai 2021, 22:33:52
Ich hab ein Problem, das mich jetzt schon länger beschäftigt. Trotz intensiver Suche bin ich noch nicht dahinter gekommen, was das Problem ist.
Es passiert sporadisch, dass bei einem Anruf, den das Modul tätigt, der Status in einem "timeout" endet, obwohl der Anruf korrekt angenommen wurde. Das hat zur Folge, dass der Anruf nach der eingestellten Zeit wiederholt wird.
Und nicht entgegengenomme Anrufe enden korrekterweiße mit dem Status "no answer"
Zitat von: plin am 07 Mai 2021, 20:38:32
@wzut: Eine Alternative wäre
use Net::SIP::Debug '50';
use Net::SIP::Debug qw( Net::SIP*=50 Registrar=1 );
Wenn wir denn das was im Log steht verstehen ;D
So wie es aussieht, scheint das Rätsel gelöst zu sein. Schuld war die Firewall bzw. derjenige der sie konfiguriert hat (also ich :-[ )
Als ich mir das Log-File (danke für den Tip) etwas näher angeschaut habe und die verwendeten Ports und Protokolle gesehen habe, dämmerte es mir.
FHEM läuft bei mir in einer VM unter Proxmox und SIP wird nur für ausgehende Anrufe verwendet. In den Firewallregeln habe ich den Zugriff auf das Notwendige beschränkt. Leider hatte ich nicht an die SIP-Geschichte gedacht. Gemeinerweise hat es ja grundsätzlich auch funktioniert, nur eben nicht immer. Das war anscheinend abhängig davon, wie schnell der Anruf angenommen wurde, wie sich jetzt im Nachhinein herausgestellt hat. Der Verbindungsaufbau läuft nämlich per UDP. Wenn es zu lange dauert, bis das Telefonat angenommen wird, dann "vergisst" die Firewall die Verbindung und das eingehende UDP Paket, welches die Anrufannahme signalisieren sollte, kam nicht mehr durch. Das ist zumindest meine Interpretation, zumal UDP ja eigentlich ein verbindungsloses Protokoll ist. Bei meinen Testanrufen hat es immer funktioniert, weil ich da das Telefonat natürlich ohne große Wartezeit angenommen hatte.
Seitdem ich in der Firewall jetzt grundsätzlich alles freigegeben habe, was als Absender die Fritzbox hat, funktioniert es seitdem ohne einen einzigen Timeout.
Also nochmal Danke für eure Hilfe und an die Entwickler für dieses Modul! Und natürlich frohe Weihnachten!
Hallo,
ich möchte mit einem SIP-Client nacheinander mehrere Anrufe absetzen. Bisher habe ich für 2 Anrufe 2 SIP-Clients benutzt. Hier das Notify, das das macht:
Internals:
CFGFN
DEF Ei_Feuer_Warnung:.* set WasserTerrasse $EVENT;set Warnmeldung call **610* 60 !Achtung! Feuer gemeldet;set Ei_Alarm $EVENT;set Telefonmeldung call **611* 60 !Achtung! Feuer gemeldet;
FUUID 62684e34-f33f-2df7-6cb2-2b9184198307ff29
NAME n_Feuerwarnung
NOTIFYDEV Ei_Feuer_Warnung
NR 593
NTFY_ORDER 50-n_Feuerwarnung
REGEXP Ei_Feuer_Warnung:.*
STATE 2022-04-27 00:41:47
TRIGGERTIME 1651012907.69629
TYPE notify
READINGS:
2022-04-27 00:41:14 state active
2022-04-27 00:41:47 triggeredByDev Ei_Feuer_Warnung
2022-04-27 00:41:47 triggeredByEvent Longpress: off
Attributes:
room Gefahrenmelder
Benutze ich nur denselben SIP-Client, dann wird nur der letzte Aufruf ausgeführt.
Welchen Denkfehler habe ich hier gemacht?
Nun der Client soll die 610 und die 611 anrufen, das geht aber auf keinen Fall zur gleichen Zeit sondern nur nacheinander !
D.h. dir fehlt zwischen de beiden sein sleep das so lange sein muß wie der erste Anruf maximal dauert.
Und aus reiner Neugier : Warum haben bei dir die beiden internen Rufnummern 610 und 611 noch sein Sternchen am Ende 610* bzw 611* ?
Hallo zusammen,
ich hab ein Problem, welches mit dem Wechsel mit meiner Fritzbox zu tun hat.
Ich hab jetzt einen DSL-Vertrag mit einer Telefonnummer, vorher hatte ich einen Kabelvertrag mit drei Telefonnummern.
Der SIP-Client, den ich definiert habe, funktioniert nachgewiesenermaßen.
Ich kann mit dem SIP-Client andere interne Nummern anwählen, d.h. die entsprechenden Mobilteile/DECT-Telefone klingeln.
Es funktioniert das folgende:
set blockCallcenter **610 10
Der SIP-Client blockCallcenter ruft das Gerät **610 (ein DECT-Telefon) an und dieses klingelt. Daraus schließe ich, dass ich den SIP-Client blockCallcenter richtig in der Fritzbox als auch in Fhem angelegt habe.
Ich hab den SIP-Client blockCallcenter angelegt, um Callcentern ihr Echo vorzuspielen.
Das hat bisher mit dem Kabelvertrag und drei Telefonnummern gut funktioniert.
ZitatPhase 3:
Du definierst in FHEM den SIP-Client und startest ihn im listen-Modus echo.
In der Fritzbox leitest du alle eingehenden Anrufe auch an den SIP-Client weiter.
Dem SIP-Client gibst du über sip_filter die Werber-Rufnummer als Filterarguiment mit.
Der SIP-Cleint ist schneller als die Familienmitglieder und nimmt den Anruf an.
Phase 4: Jetzt bin ich (der Autor dieses Anwendungsfalles) neugierig. Postet Eure Erfahrung mit diesem Modus gerne im Forums-Thread.
Meine Hauptfrage ist, kann das Konstrukt Callcenter zu blockieren (Echo vorspielen) mit einer Rufnummer funktionieren, oder braucht man dazu mehr als eine Rufnummer?
Hier nur zur Ergänzung meine Defintion des blockCallcenters:
defmod blockCallcenter SIP
attr blockCallcenter history_file ./log/blockCallcenter.sip
attr blockCallcenter history_size 0
attr blockCallcenter sip_dtmf_loop once
attr blockCallcenter sip_dtmf_send audio
attr blockCallcenter sip_dtmf_size 2
attr blockCallcenter sip_elbc yes
attr blockCallcenter sip_filter <blockierte Rufnummern>,unbekannt,Unbekannt,unknown,Unknown,anonymous,Anonymous
attr blockCallcenter sip_from sip:blockCallcenter@fritz.box
attr blockCallcenter sip_ip 192.168.1.xx
attr blockCallcenter sip_listen echo
attr blockCallcenter sip_registrar 192.168.178.1
attr blockCallcenter sip_ringtime 0.5
attr blockCallcenter sip_user blockCallcenter
Viele Grüße Gisbert
Hallo zusammen,
ich habe jetzt ein längeres Passwort benutzt, nachdem ich mir dies hier genauer durchgelesen und nicht nur überflogen habe (Auszug aus dem Wiki):
ZitatFehler bei der Registrierung an der Fritzbox
Fritzbox
Ist das Device für den SIP-Client in der Fritzbox unter Telefonie > Telefoniegräte gelistet?
Geräteeinstellungen ändern: Ist für das Device unter 'Anmeldedaten' die Durchwahl als Benutzername angegeben?
Ist der in dieser Ansicht angegebene 'Registrar' mit der im Attribut sip_registrar identisch? Im Zweifelsfalle die IP-Adresse statt 'fritz.box' verwenden.
FitzOS ab 6.80: Wurde nach Definition des Gerätes an einem anderen bekannten Gerät der Bestätigungscode eingegeben?
Wurde in der Fritzbox ein Passwort von mind. 8 Stellen und Sicherheitsstufe 'gut' vergeben? Andernfalls kann es zu einem Registrierungsfehler 404 kommen.
FritzOS 6.90: Registrierungsfehler 404 konnte erst mit folgenden Angaben gelöst werden
sip_from = sip:mymyuser@fritz.box (wobei dies der mymyuser ist der beim Telefoniegrät als Benutzername angegeben wurde,
bitte die von der FritzBox geforderte Mindestlänge beachten)
sip_user = myuser (statt der Nebenstellennummer)
Der Parallelruf funktioniert damit, auch bei nur einer amtlichen Telefonnummer.
Anstatt der in der Fritzbox-Einstellung vorgeschlagenen internen Nummer 620 habe ich **620 genommen; zumindest funktioniert es damit.
Viele Grüße Gisbert
Zitat von: Gisbert am 18 Juli 2022, 20:28:56
Meine Hauptfrage ist, kann das Konstrukt Callcenter zu blockieren (Echo vorspielen) mit einer Rufnummer funktionieren, oder braucht man dazu mehr als eine Rufnummer?
Hallo Gisbert,
Die "echo" Funktion benötigt nur eine Rufnummer.
Die Echo-Funktion ist ja durch meinen "Bedarf" entstanden. Ich bin mittlerweile bei einer anderen Lösung angekommen. Die Fritzbox bietet die Möglichkeit alle Anrufer, die in einem Telefonbuch gelistet sind, auf einen Anrufbeantworter umzuleiten.
Ich habe mir ein Telefonbuch namens "SPAM" angelegt. Dort landen sukzessive die Werbeanrufer die ich blocken möchte. Alle SPAMer werden auf einen Anrufbeantworter mit einer entsprechenden Ansage "Sie wurden als Werbeanruf identifiziert ..." umgeleitet.
Viele Grüße
Peter
Hallo zusammen,
ich glaube hier mal wieder ein klassisches Docker-Problem zu haben. Das Wiki zum Thema habe ich bereits gelesen, komme aber nicht weiter bzw. brauche eure Experten-Meinung.
- Ich habe FHEM von dedizierter Harware in ein Docker-Image umgezogen. Es läuft soweit alles, außer SIP.
- Das Docker-Image wird in einem Kubernetes auf einem Truenas Scale gehostet.
- Kubernetes erlaubt mir nicht die Nutzung von Ports kleiner 9000
- sip_ip ist gesetzt auf die IP-Adresse des Gastes, hier 172.16.0.194. Das Binding funktioniert.
- sip_port ist gesetzt auf 9060
- im Docker-Container ist Port 9060(TCP) und 9070 (UDP) weitergeleitet (9060:9060 bzw. 9070:9070)
- Die im Wiki genannten Ports 2xxx habe ich nicht weitergeleitet. Kann ich aufgrund der Port-Einschränkung von Kubernetes auch nicht.
- in der Fritzbox wurde eine statische Route für das Kubernetes-Netz gepflegt. Ich kann aus meinem regulären Heimnetz auch den Gast über seine Adresse erreichen
Beim ausgehenden Call passiert folgendes:
Zitat2022.08.11 19:47:50 4: mySIP, calling 0175xxxxxx, ringtime: 30 , no message
2022.08.11 19:47:50 4: mySIP, mySIP|0175xxxxxx|30||0
2022.08.11 19:47:50 4: mySIP, call -> mySIP|0175xxxxxx|30||0|0
2022.08.11 19:47:50 5: mySIP, call has pid 10348
2022.08.11 19:47:50 4: mySIP[10348], my parent is 6824
2022.08.11 19:47:50 4: mySIP[10348], trying to use port 9070
2022.08.11 19:48:52 4: mySIP, CALLDone -> mySIP|0|CallRegister: Failed with error 110|0
2022.08.11 19:48:52 5: mySIP, fifo is empty
2022.08.11 19:48:52 5: mySIP, no elbc
Ein netstat im Container ergibt folgendes:
Zitat
root@fhemsignal-ix-chart-64fdc4fdd8-8sjrq:/tmp# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 6061 21271590 -
tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 6061 21271591 -
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN 6061 21271592 -
tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN 6061 21271631 -
tcp 0 0 127.0.0.1:7072 0.0.0.0:* LISTEN 6061 21268714 -
udp 0 0 172.16.0.194:9070 0.0.0.0:* 6061 21436491 -
Auffällig: Es wird port 9070 UDP gebunden aber der state ist nicht "LISTEN"
Stelle ich auf Host-Networking um, Container ist also mit eigener IP-Adresse nach außen offen, funktioniert es genau so wie auf der alten dedizierten Maschine.
Die Fragen, die sich mir ergeben:
1) Kann ich überhaupt von Port 5060 abweichen und muss dieser in jedem Fall am Host exposed sein?
2) Warum funktioniert eine ausgehende Verbindung zu Fritzbox nicht? Das hat ja weder etwas mit Portweiterleitung oder Firewall zu tun? Hier verstehe ich schlicht nicht, wie SIP-funktioniert. Ist Port 9060 ausgehend während 9070 der dann eingehende ist?
3) Fall es auch mit meinen Ports funktionieren müsste: Braucht es TCP oder UDP? Kubernetes wil das spezifiziert haben
4) Brauche ich die 2xxx Ports?
Danke schon mal für jeglichen Support!
Chris
IMHO sind die Ports 50xx nicht dein Problem, bzw lassen sich ja relativ leicht nach oben (9000+) verschieben.
Knackpunkt werden aktuell die Ports RTP Ports 20xx sein, aber auch die lassen sich wie im Wiki https://wiki.fhem.de/wiki/SIP-Client#Docker beschrieben irgendwo nach weiter oben legen.
Konkret: In der Util.pm kannst Du
our $RTP_MIN_PORT = 2000;
our $RTP_MAX_PORT = 12000;
nach oben legen
Danke für eure Hinweise. Ich habe nun testweise die RTP-Ports auf 20000-20007 gelegt:
- Ports weitergeleitet
- Ports in Util.pm angepasst
- FHEM neugestartet
Hängt leider mit dem selben Fehlerbild. Müsste ich nicht auch irgendeine Aktivität in der Fritzbox sehen? Da kommt im Ereignislog nichts an.
So, Dank tcpdump die Ursache gefunden: Der Server hat zwei Ethernet-Schnittstellen. Ausgehende-Kubernetes-Pakete gingen über en01, aber die Portweiterleitung in die Container funktioniert nur über eno2.
Darüber hinaus:
- Die Portrange für die Calls (5060..) ist UDP
- Die RTP-Ports (2000.. UDP) werden nicht für die Anrufsignalisierung benötigt.
- Der unter sip_port angegegebene Port ist einerseits die Startnummer für die Anrufsignalisierung und wird darüber hinaus für "listen" verwendet, falls sip_listen konfiguriert ist. Dieser muss also auch nur weitergeleitet werden, falls man listening benötigt.
- Für ausgehende Calls wird dann sip_port + 10 verwendet. Dieser muss weitergeleitet werden, falls man anrufen möchte
Ich habe die Doku im Wiki in diesem Rahmen etwas präzisiert.
Es bleiben aber noch zwei Fragen:
1) Wie persistiere ich am besten die Änderung an /usr/share/perl5/Net/SIP/Util.pm?
2) Der Docker-Container bekommt mit jedem Start eine neue interne IP, die SIP-Client benötigt. Wie kann ich das geschickt lösen?
Danke!
Hi.
Zitat von: Flachzange am 14 August 2022, 20:07:15
...
1) Wie persistiere ich am besten die Änderung an /usr/share/perl5/Net/SIP/Util.pm?
2) Der Docker-Container bekommt mit jedem Start eine neue interne IP, die SIP-Client benötigt. Wie kann ich das geschickt lösen?
...
1) ggf. mit den Skripten arbeiten: das gewünschte rauspicken und damit die Änderung automatisieren lassen (https://github.com/fhem/fhem-docker#make-any-other-changes-during-container-start (https://github.com/fhem/fhem-docker#make-any-other-changes-during-container-start)) - vielleicht hat da schon jmd. was fertiges; oder die geänderte Util.pm von außen in den Container hineinreichen (-v /hostpath/Util.pm:/containerpath/Util.pm:ro ) - habe aber beides nicht gebraucht/ versucht, deshalb nur als möglicher Ansatz ohne Gewähr :)
2) Du könntest ein Docker-Netzwerk anlegen, sofern noch nicht geschehen, und lässt FHEM Mitglied sein + gibst FHEM einen net-alias z.B. myfhem - diesen Alias trägst Du in "sip_ip" ein
Bsp.:
...
--net testnet
--name fhem
--network-alias myfhem
...
Über den Namen aus "--name fhem" müsste es auch gehen, ich finde es mit alias halt leichter zu handhaben. Mit dem Namen/Alias auf andere Container zuzugreifen ist imho der Standardweg lt. Docker (bspw. Zugriff Webserver --> SQL-Backend etc. pp.), weil sich eben die IPs ändern können.
Läuft bei mir zwar mit Asterisk, sollte aber im Zusammenspiel mit der Fritte auch keinen Unterschied machen.
VG
rob
Danke für den Input!
zu 2). Das funktioniert in meiner Kubernetes-Umgebung (scheinbar) nicht. Dort gibt es Services, die es mir erlauben zwischen Containern zu kommunizieren (analog dem network alias). Diese Services liegen bei Kubernetes aber in einem anderen Subnetz und ich kann gegen diese IP dann logischerweise keinen Port binden.
Was ich nicht verstehe: Warum gehört das überhaupt zusammen? Warum wird der Port nicht an 0.0.0.0 gebunden und dem Registrar erklärt, dass man unter w.x.y.z zu erreichen ist?
Ich habe mir dazu mal die Methodenaufrufe angeschaut und folgenden Anpassungvorschlag in SIP_Register[338-368]:
if ($port)
{
$port +=10 if ($type eq "calling");
Log3 $name,4,"$logname, trying to use port $port";
$leg = IO::Socket::INET->new(Proto => 'udp', LocalPort => $port);
# if port is already used try another one
if (!$leg)
{
Log3 $name,1,"$logname, cannot open port $port at $ip : ".$!;
$port += 10;
$leg = IO::Socket::INET->new(Proto => 'udp', LocalPort => $port) || return "can't open port $port at $ip : ".$!;
Log3 $name,2,"$logname, using secundary port $port with IP $ip";
}
close($leg);
#$leg = $ip.":".$port;
$leg = Net::SIP::Leg->new(
addr => '0.0.0.0',
host => $ip,
port => $port);
}
else
{
#$leg = $ip;
$leg = Net::SIP::Leg->new(
addr => '0.0.0.0',
host => $ip);
Log3 $name,4,"$logname, using Leg.pm to find a free port";
}
Damit wird der Port an 0.0.0.0 gebunden und die unter sip_ip angegebene Adresse als externe Adresse announced. Das funktioniert in einem ersten Test bei mir und ich umgehe viele Probleme.
Any thoughts?
Naja schade eigentlich. Mir scheinen die Küberneten-Dinger damit unnötig umständlich zu funktionieren, wenn man keine Aliase nehmen kann. Dann wäre für jeden Dienst irgendein Workaround nötig - den Du für Dich schon gefunden zu haben scheinst. Wie sich der Vorschlag auf andere Installationen auswirkt, kann ich nicht beurteilen.
Ansonsten hätte ich noch versucht die Host-IP zu binden, weil die Ports ja zum Host nach außen gemappt werden. Bei manchen Diensten klappt das, wenn sie z.B. den Alias nicht auflösen wollen.
Ein anderer grob gedachter Workaround wäre ggf. ein notify, das auf den FHEM-Neustart triggert, sich die aktuelle IP im Container holt (sysmon-reading oder {qx(hostname -I)}), mit sip_ip vergleicht und neu reinschreibt, falls abweichend. Man müsste nur drauf achten, dass z.B. sysmon bereits aktualisiert ist - also ggf. durch ein at etwas später auslösen. Müsste ggf. weiter ausgefeilt werden, aber so müsste nichts weiter an Modulen geändert werden. Ganz ohne basteln geht es wohl nicht ;)
Mein Punkt ist ja eher, dass die Art und Weise wie der Port an sip_ip gebunden wird, nicht ideal ist, da sip_ip ja eigentlich einen anderen Zweck hat. Mit der Anpassung oben (entfallen) möglicherweise diverse Workaroundüberlegungen. Bei mir funktioniert es jetzt jedenfalls so.
wzut ...
Zitat von: Flachzange am 16 August 2022, 06:19:23
Warum wird der Port nicht an 0.0.0.0 gebunden
weil vermutliche damals die Beispiele von Net::SIP es auch nicht getan haben und wir/ich es auch nicht besser wussten bzw. bis heute kein Grund vorhanden war das in irgend einer Weise in Frage zu stellen.
Ich habe kein Problem damit das in der vorgeschlagenen Art zu übernehemen, allerdings hätte ich gern noch Rückmeldung von jemand der das Modul in einem System einsetzt wo mehr als eine IP bzw. mehr als ein Netzwerkinterface vorhanden ist.
Mein Test war nicht erfolgreich. Ich habe die Änderung eingebaut und aktiviert. Wenn ich die FritzFon App anrufe und den Anruf annehme höre ich "die Verbindung wird gehalten". Mit dem Original-Modul kann ich DTMF-Töne in der App hören.
x86 Server mit OpenSUSE und
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
veth40a1b93: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
veth43be765: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
vethc647e20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
vethd6e55a3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Eigentlich nicht wirklich verständlich ...
Gleicher Effekt beim Fritz!FON C5.
Zitat von: plin am 20 August 2022, 12:40:59
Mein Test war nicht erfolgreich. Ich habe die Änderung eingebaut und aktiviert. Wenn ich die FritzFon App anrufe und den Anruf annehme höre ich "die Verbindung wird gehalten". Mit dem Original-Modul kann ich DTMF-Töne in der App hören.
In der Tat ist das bei mir genauso. Ich hatte es darauf geschoben dass ich die RTP-Ports nicht durchgereicht habe. Da ich nur die Anrufsignalisierung brauche, habe ich jetzt auch nicht weiternachgeschaut. Jedenfalls brachte auch die Änderung der Ports in der Util.pm nichts.
Vielleicht könnte es noch jemand testen, der mit einem nativen Interface arbeitet und nicht über NAT o.ä. im Docker oder bei dem es definitv vorher funktionierte mit den RTP-Ports.
Ich habe gerade SIP und T2S eingerichtet um meine Fritz Telefone als Ausgabegeräte für Mitteilungen zu nutzen. (z.B. "Das Fenster im Bad ist offen") Jetzt hab ich ein kleines Problem und eine Grundsatzfrage.
1. Ist es überhaut möglich Text am Telefon auszugeben ohne das es klingelt und man abheben muss?
2. SOC erstellt nur eine mp3 Date und wandelt diese dann nicht um (siehe log) Wenn Punkt eins nicht geht hat es sich erledigt, da es für meine Zwecke dann nicht geeignet ist.
2022.08.31e] 09:34:22 4: FritzSprecher, wait_for_t2s file : mp3/d742838fdcc54447e89ca66f9d75f007.mp3
2022.08.31 09:34:22 4: FritzSprecher, new T2S file mp3/d742838fdcc54447e89ca66f9d75f007.mp3
2022.08.31 09:34:22 5: FritzSprecher, /usr/bin/sox mp3/d742838fdcc54447e89ca66f9d75f007.mp3 -t raw -r 8000 -c 1 -e a-law alaw/d742838fdcc54447e89ca66f9d75f007.mp3 2>&1
2022.08.31 09:34:22 5: FritzSprecher, sox output : /usr/bin/sox FAIL formats: can't open output file `alaw/d742838fdcc54447e89ca66f9d75f007.mp3': No such file or directory
Zitat von: amehl am 31 August 2022, 09:50:48
Ist es überhaut möglich Text am Telefon auszugeben ohne das es klingelt und man abheben muss?
Das ist keine Job für das Modul sondern für das benutzte Telefon.
Ich kenne z.b. kein Telefon das so etwas machen würde, das ist eher ein Job für einen echten Anrufbeantworter.
Bei mir läuft das mit zweimal FHEM - FHEM 1 ist das Hauptsystem im Keller und ruft FHEM 2 an. FHEM 2 ist ein Raspi in meiner Wohnung mit USB Lautsprechern.
Das SIP Modul läuft da mit attr sip_listen am.
Danke für die Info. Ich hab noch einen alten Raspi rumliegen, vielleicht löse ich es auch so.
Grüße
Andi
Ich hab mir jetzt einen Leck Sensor installiert und will mich am Handy anrufen lassen wenn Wasser austritt. Ich kriege das mit dem TS2 leider nicht in den Griff. TS2 ist als SERVER angelegt.
Evtl. irgend ein Rechte Problem - ich komme aber nicht drauf. Für Hilfe wäre ich dankbar.
Exiting... (End of file)
2022.10.15 21:52:53 4: TS2: Es wurden alle Teile ausgegeben und der Befehl ist abgearbeitet.
2022.10.15 21:56:54 4: TS2: ermittelte CodePage: ascii , konvertiere nach UTF-8
2022.10.15 21:56:54 4: TS2: MaxChar = 200, Delimiter = (?<=[\.!?])\s*, ForceSplit = 0, AddDelimiter =
2022.10.15 21:56:54 4: TS2: Auflistung der Textbausteine nach Aufbereitung:
2022.10.15 21:56:54 4: TS2: 0 => Wasserschaden
2022.10.15 21:56:54 4: TS2: Verwende TTS Spracheinstellung: Deutsch
2022.10.15 21:56:54 2: TS2: Angegebenes Verzeichnis cache konnte erstmalig nicht angelegt werden.
2022.10.15 21:56:54 1: ERROR evaluating {Text2Speech_Done()}: Not enough arguments for main::Text2Speech_Done at (eval 2814) line 1, near "()"
2022.10.15 21:56:59 3: Melder, timeout waiting for T2S
2022.10.15 21:57:01 4: TS2: ermittelte CodePage: ascii , konvertiere nach UTF-8
2022.10.15 21:57:01 4: TS2: MaxChar = 200, Delimiter = (?<=[\.!?])\s*, ForceSplit = 0, AddDelimiter =
2022.10.15 21:57:01 4: TS2: Auflistung der Textbausteine nach Aufbereitung:
2022.10.15 21:57:01 4: TS2: 0 => Wasserschaden
Klingt so, als ob es das Verzeichnis /opt/fhem/cache/ nicht gibt, TTS dieses anlegen wollte aber nicht konnte. Wer ist der owner von /opt/fhem? Das sollte dem fhem-User gehören.
Vielen Dank das war es - frage mich nur warum der Ordner nur auf owner pi war???
Zitat von: Wzut am 10 Mai 2018, 18:49:19
Lustig ... geht bei mir auch nicht. Allerdings schafft verbose 5 da etwas mehr Klarheit :
sox : /usr/bin/sox WARN rate: rate clipped 1 samples; decrease volume?
Was auch immer sox da an dem mp3 File auszusetzen hat :(
Bzw. das würde eigentlich bedeuten das Google da schon Mist zurückliefert ? Werde mich die Tage wohl mal näher damit beschäftigen müssen.
Das Problem ist wohl, dass der sox Converter glaubt, der Sound sei übersteuert.
Das habe ich gerade bei ein paar krassen Halloween Sounds für unseren Klingellautsprecher eben auch bemerkt.
2022.10.30 21:01:43.894 4 : SIP, audio file /opt/fhem/audio/Halloween55.mp3 found
2022.10.30 21:01:43.894 5 : SIP, /usr/bin/sox /opt/fhem/audio/Halloween55.mp3 -t raw -r 8000 -c 1 -e a-law /opt/fhem/audio/Halloween55.alaw 2>&1
2022.10.30 21:01:43.931 5 : SIP, sox output : /usr/bin/sox WARN rate: rate clipped 1875 samples; decrease volume?/usr/bin/sox WARN dither: dither clipped 1666 samples; decrease volume?
Hier hilft der sox Schalter
-G, um Clipping zu vermeiden.
--norm wäre noch besser, da auch zu leise Sounds korrigiert werden, hat bei mir aber nicht funktioniert. Es wurde dann gar kein Output generiert.
Um nun wenigsten automatisch "nach unten" zu normalisieren, habe ich mal das Attribut
audio_normalize eingebaut.
Die Datei befindet sich im Anhang. Ggf. könnte das ja mit in den Standard.
Hallo Wzut,
mein SIP-Device will nicht mehr.
Interne Anrufe von einem Telefon zu einem anderen funktionieren, was mich veranlasst zu vermuten, dass die Telefoniegeräte in der Fritzbox an sich funktionieren.
Wenn ich einen Anruf im SIP-Device absetze, kommt es zu einem Fehler, siehe das list:
Internals:
CFGFN ./FHEM/FritzboxUniFiAnwesenheit.cfg
FUUID 5c93df13-f33f-e986-0dbd-b8d6ee5046144693
NAME Tuerklingel
NOTIFYDEV global
NR 109
NTFY_ORDER 50-Tuerklingel
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
eventCount 11
READINGS:
2022-11-22 20:53:14 call done
2022-11-22 20:53:14 call_attempt 0
2022-11-22 20:53:14 call_state fail
2022-11-22 20:53:14 call_success 0
2022-11-22 20:53:14 call_time 0
2022-11-22 20:53:14 last_error CallRegister: Failed with code 401
2022-11-22 19:52:00 listen_alive no
2022-11-22 20:53:14 state initialized
helper:
CALL_BYE CallRegister: Failed with code 401
CALL_ERROR 0
CALL_NAME unknown
CALL_NR **611
CALL_START 1669146794.60982
CALL_TIME 0
CALL_TYPE out
bm:
SIP_Attr:
cnt 19
dmx -1000
dtot 0
dtotcnt 0
mTS 22.11. 19:51:42
max 7.58171081542969e-05
tot 0.00032353401184082
mAr:
set
Tuerklingel
alias
Türklingel
SIP_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 22.11. 19:51:42
max 0.000669002532958984
tot 0.000669002532958984
mAr:
HASH(0x55bdae4103e0)
Tuerklingel SIP
SIP_Notify:
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 22.11. 21:08:32
max 7.70092010498047e-05
tot 0.00011897087097168
mAr:
HASH(0x55bdae4103e0)
HASH(0x55bdcaa91fc8)
SIP_Set:
cnt 39
dmx -1000
dtot 0
dtotcnt 0
mTS 22.11. 19:53:43
max 0.151061058044434
tot 0.680599212646484
mAr:
HASH(0x55bdae4103e0)
Tuerklingel
call
**701
6
Attributes:
alias Türklingel
devStateIcon .*:fts_shutter_1w_0
group FRITZBOX
history_file ./log/Tuerklingel.sip
history_size 0
icon it_telephone
room Network
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:blockCallcenter@fritz.box
sip_ip 192.168.1.46
sip_listen none
sip_port 5060
sip_registrar 192.168.178.1
sip_ringtime 30
sip_user blockCallcenter
Das ganze hat schonmal funktioniert, 100%ig Ende August, als ich es eingerichtet hab. Ab wann ich die jetzige Situation hab, weiß ich allerdings nicht.
Viele Grüße Gisbert
Hallo Gisbert,
Kannst Du bitte mal verbose auf 5 setzen, den Vorgang wiederholen und den Log-Auszug posten.
VG Peter
SIP Fehler 401 = Unauthorized ! D.h hier würde ich mir Username und Passwort auf beiden Seiten mal zur Brust nehmen. FB will nur "starke" PWs !
Das FHEM und die FB in unterschiedlichen Netzen liegen (192.168.1.x / 192.168.178.x) ist bekannt und eine passende Layer 3 Routing Instanz ist auch vorhanden ?
Hallo plin,
hallo Wzut,
ich habe gerade etwas getestet und wollte schreiben, dass ich das Problem gelöst habe.
Gestern war es wohl schon zu spät, so dass ich nicht bemerkt habe, dass die beiden Attribute sip_from und sip_user ein anderes Telefoniegerät anzeigten. Das habe ich geändert (d.h. das richtige Telefoniegerät eingetragen), und nun läuft es wieder wie erwartet.
Viele Grüße Gisbert
Hi,
ich habe mir am Wochenende das SIP Modul mit meiner Fritzbos und Text2Speech eingerichtet. Funktioniert auch einwandfrei mit dem Telefonanruf. Allerdings wird die Nachricht (unmittelbar vor dem Anruf) auch an meinem lokal an dem Raspberry PI angeschlossenem Lautsprecher ausgegeben. Letzteren Nutze ich für allgemeine Hinweise z.B. Wetterbericht.
d.h. der Aufruf:
set mySip call 081547111 30 !Hier ist dein FHEM Server
bzw. bei mir
set FritzPhone call 01792293579 60 !Hier ist dein FHEM Server
Gibt "Hier ist dein FHEM Server" unmittelbar vor dem Anruf auch auf meinem Lokalen Lautsprecher aus. Letzteres würde ich gerne unterbinden. Aber wie? Der -Lautsprecher soll natürlich für alle weitere Text2Speech ausgaben funktionieren
Danke
MArk
Du benötigst 2 Text2Speech Devices: eines mit none als Audio-Gerät für die Sip-Calls und eines mit Angabe d. Audio-Hardware für die lokale Ausgabe.
Nur das erste Device wird im SipCaller angegeben im Attribut T2S_Device.
VG
rob
Danke Rob, genau das hat funktioniert.
Hallo,
ich benutze das Modul , damit Fhem soch tel. meldet, wenn bestimmte Ereignisse wie Wasser/Feuer/etc. Alarm eintritt. Die Anrufe gehen bis zum B-Teilnehmer (hier Mobiltelefon) durch, und es sollte die Art des Alarms per TTS als Audio zum Angerufenen übertragen werden.
Das Modul hat, bevor ich fhem in einen Docker-Container umgezogen habe, einwandfrei funktioniert, inkl. Audio Übertragung.
Im Docker funktioniert der Verbindungsaufbau, aber Sprache geht nicht durch.
Erstmal die SIP Def.:
Internals:
AC /usr/bin/sox
CFGFN ./FHEM/00_config_Alarmanlage.conf
FUUID 5cdeb681-f33f-5615-f5c1-bae975633b2af415
NAME SIP_call
NOTIFYDEV SIP_TTS
NR 887
NTFY_ORDER 50-SIP_call
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
eventCount 52
forcecall 0
repeat 0
READINGS:
2023-03-04 17:09:24 call done
2023-03-04 17:09:24 call_attempt 0
2023-03-04 17:09:24 call_state ok
2023-03-04 17:09:24 call_success 1
2023-03-04 17:09:24 call_time 2
2023-03-04 16:57:08 last_error
2023-03-04 14:16:50 listen_alive no
2023-03-04 17:09:24 state initialized
helper:
CALL_BYE ok
CALL_ERROR 0
CALL_NAME unknown
CALL_NR 0151XXXXXXX
CALL_START 1677946157.82772
CALL_TIME 2
CALL_TYPE out
Attributes:
DbLogExclude .*
T2S_Device SIP_TTS
T2S_Timeout 8
audio_converter sox
history_file ./log/SIP_call.sip
history_size 0
icon phone_call_out
room System
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_force_interval 4
sip_from sip:620ipfhem@fritz.box
sip_ip 172.19.0.6
sip_listen none
sip_port 5060
sip_registrar fritz.box
sip_ringtime 3
sip_user 620ipfhem
verbose 5
Das Log sieht m. E. okay aus:
2023.03.04 18:13:10.343 5: SIP_call, MD5: Hier spricht fhem -> c0cebea98dd40d2671d733bc27787431.mp3
2023.03.04 18:13:10.344 5: SIP_call, mp3 File file not found in cache
2023.03.04 18:13:10.408 4: SIP_call, wait_for_t2s file : cache/7406ae8c4853550fde3149a9a364d94d.mp3
2023.03.04 18:13:10.408 4: SIP_call, new T2S file cache/7406ae8c4853550fde3149a9a364d94d.mp3
2023.03.04 18:13:10.409 5: SIP_call, not converted - using cache/7406ae8c4853550fde3149a9a364d94d.alaw from cache
2023.03.04 18:13:10.410 4: SIP_call, audio file cache/7406ae8c4853550fde3149a9a364d94d.alaw found
2023.03.04 18:13:10.410 4: SIP_call, SIP_call|015120177388|40|cache/7406ae8c4853550fde3149a9a364d94d.alaw|0
2023.03.04 18:13:10.427 4: SIP_call, call -> SIP_call|015120177388|40|cache/7406ae8c4853550fde3149a9a364d94d.alaw|0|0
2023.03.04 18:13:10.428 5: SIP_call, call has pid 276034
2023.03.04 18:13:10.454 4: SIP_call[276034], my parent is 6384
2023.03.04 18:13:10.455 4: SIP_call[276034], trying to use port 5070
2023.03.04 18:13:10.672 4: SIP_call[276034], register new expire : 2023-03-04 18:18:10
2023.03.04 18:13:10.676 5: SIP_call, readingS:state Val:calling
2023.03.04 18:13:10.729 4: SIP_call[276034], CallStart with 1 files - first file : cache/7406ae8c4853550fde3149a9a364d94d.alaw - PCMA/8000 , repeat 0
2023.03.04 18:13:10.735 4: SIP_call[276034], calling : 015120177388
2023.03.04 18:13:10.737 5: SIP_call, readingS:call_state Val:calling 015120177388
2023.03.04 18:13:18.862 4: SIP_call[276034], cb_final - status : OK
2023.03.04 18:13:18.862 4: SIP_call[276034], call established
2023.03.04 18:13:18.870 5: SIP_call, readingS:call_state Val:established
2023.03.04 18:13:21.618 5: SIP_call[276034], 0. Ende des ersten Loops
2023.03.04 18:13:21.619 5: SIP_call[276034], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x5576b36360)
2023.03.04 18:13:21.619 5: SIP_call[276034], 2. fi : 0
2023.03.04 18:13:21.619 5: SIP_call[276034], 4. timeout : 0
2023.03.04 18:13:21.619 5: SIP_call[276034], 6. call_established : 1
2023.03.04 18:13:21.619 5: SIP_call[276034], call->bye
2023.03.04 18:13:21.633 5: SIP_call[276034], RTP done : Net::SIP::Simple::Call=HASH(0x5576b36360)
2023.03.04 18:13:21.634 5: SIP_call[276034], Timeout : 0
2023.03.04 18:13:21.634 5: SIP_call[276034], while : 0
2023.03.04 18:13:21.634 5: SIP_call[276034], Status : OK
2023.03.04 18:13:21.634 4: SIP_call[276034], Calltime : 2
2023.03.04 18:13:21.643 4: SIP_call, CALLDone -> SIP_call|1|ok|2
2023.03.04 18:13:21.658 5: SIP_call, fifo is empty
2023.03.04 18:13:21.658 5: SIP_call, no elbc
Die interne IP des fhem Containers ist 172.19.0.6
In der yaml-Def. vom fhem docker-container sind die Ports 5060 -5080 definiert, wie gesagt, Anruf funktioniert, aber ohne Ton.
Ich habe irgendwo gelesen, dass man eine statische Route in der FB eintragen muss, was ich getan habe.
Die stat. Route in der FB sieht so aus: (Anlage).
Ein Paketmitschnitt der FB lässt RTP-Pakete erkennen, die vom SIP-Client stammen (Anlage).
So und jetzt bin ich mit meinem Latein am Ende. Vielleicht hat jemand noch eine Idee.
Danke und
VG
Alex
Bitte Wiki lesen, da steht schon lange die Lösung für Docker und RTP Ports !
Hallo,
okay ich habe das mit den RTP-Ports gestern übersehen und gemäß WIKI durchgeführt.
Ich habe die Ports 2000-2019 gewählt:
Auszug aus Utils.pm
our %EXPORT_TAGS = ( all => [ @EXPORT_OK, @EXPORT ] );
our $RTP_MIN_PORT = 2000;
our $RTP_MAX_PORT = 2019;
und das Docker-composefile angepasst und den Container neu gestartet.
Auszug Ports aus yml-Dockerfile:
image: fhem/fhem:latest
restart: always
container_name: fhem
hostname: FHEM-Docker
privileged: true
ports:
- "8083:8083"
- "8084:8084"
- "7072:7072"
- "5987:5987"
- "5060:5060"
- "5070:5070"
- "5080:5080"
- "139:139"
- "445:445"
- "1000:1000"
- "3033:3033"
- "55054:55054"
- "9522:9522"
- "2000-2019:2000-2019"
Und ebenfalls nochmals die statische Route in der FB überprüft:
Netzwerk: 172.19.0.0
Subnetzmaske: 255.255.0.0
Gateway: 192.168.3.20
Um auszuschließen dass "Fritz.box" nicht richtig aufgelöst werden, habe ich die IP der FB in der Def. genommen.
List:
Internals:
AC /usr/bin/sox
CFGFN ./FHEM/00_config_Alarmanlage.conf
FUUID 5cdeb681-f33f-5615-f5c1-bae975633b2af415
NAME SIP_call
NOTIFYDEV SIP_TTS
NR 887
NTFY_ORDER 50-SIP_call
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
eventCount 71
OLDREADINGS:
READINGS:
2023-03-06 20:15:35 call done
2023-03-06 20:15:35 call_attempt 0
2023-03-06 20:15:35 call_state ok
2023-03-06 20:15:35 call_success 1
2023-03-06 20:15:35 call_time 1
2023-03-06 12:30:51 listen_alive no
2023-03-06 20:15:35 state initialized
helper:
CALL_BYE ok
CALL_ERROR 1
CALL_NAME unknown
CALL_NR 0151201XXXX
CALL_START 1678130127.02571
CALL_TIME 1
CALL_TYPE out
Attributes:
DbLogExclude .*
T2S_Device SIP_TTS
T2S_Timeout 8
audio_converter sox
comment Objekt zur Realisierung von Alarm-Telefonanfufen aus fhem heraus via Fritzbox.
Als SIP Adresse muss die Fhem-Container Adresse angegeben werden.
Damit die Sprachansagen am Telefon abgespielt werden, muss eine statische Route in der FB eingetragen werden:
Subnetz: 172.19.0.0/16
Mask: 255.255.0.0
Gateway: 192.168.3.20
group SIP
history_file ./log/SIP_call.sip
history_size 0
icon phone_call_out
room System
sip_dtmf_loop once
sip_dtmf_send rfc2833
sip_dtmf_size 2
sip_elbc yes
sip_force_interval 4
sip_from sip:620ipfhem@192.168.3.1
sip_ip 172.19.0.5
sip_listen none
sip_port 5060
sip_registrar 192.168.3.1
sip_ringtime 3
sip_user 620ipfhem
verbose 5
Leider funktioniert die Audioübertragung immer noch nicht.
Hat vielleicht noch jemand eine Idee?
Vielen Dank vorab!
Gruß
Alex
Zitat von: Homalix99 am 06 März 2023, 20:23:19
Leider funktioniert die Audioübertragung immer noch nicht.
Hat vielleicht noch jemand eine Idee?
Hi Alex, ich denke ein neuer Mitschnitt wäre gut.
Hallo,
anbei ein neuer Mitschnitt.
1. Log:
2023.03.07 11:09:50.621 3: alarm_out: Alarm_Test: off
2023.03.07 11:16:29.122 4: SIP_call, msg will be repeat 2 times
2023.03.07 11:16:29.122 5: SIP_call, MD5: !Dies ist ein Testalarm von Fheem -> bc093fb936b9c340455bf49fa8e8f127.mp3
2023.03.07 11:16:29.122 5: SIP_call, mp3 File file not found in cache
2023.03.07 11:16:29.161 3: alarm_out: Alarm_Test Alarm: on, Alarmtext: !Dies ist ein Testalarm von Fheem, Rufnummer_1: 015120177388
2023.03.07 11:16:29.162 3: alarm_out: Alarm: Kann keine Rufverbindung zum Anschluss 015120771207 aufbauen, da der Alarmruf fuer Test Alarm deaktiviert ist
2023.03.07 11:16:29.162 3: alarm_out: Alarm: Kann keine Mail zur e-mail al.zeit@t-online.de senden, da Alarmmail fuer Test Alarm deaktiviert ist
2023.03.07 11:16:29.162 3: alarm_out: Alarm: Kann keine Mail zur e-mail zeitlerab@t-online.de senden, da Alarmmail fuer Test Alarm deaktiviert ist
2023.03.07 11:16:29.472 4: SIP_call, wait_for_t2s file : cache/62d1a2142d218979d742cd67dd9c059e.mp3
2023.03.07 11:16:29.472 4: SIP_call, new T2S file cache/62d1a2142d218979d742cd67dd9c059e.mp3
2023.03.07 11:16:29.473 5: SIP_call, not converted - using cache/62d1a2142d218979d742cd67dd9c059e.alaw from cache
2023.03.07 11:16:29.474 4: SIP_call, msg will be repeat 2 times
2023.03.07 11:16:29.474 4: SIP_call, audio file cache/62d1a2142d218979d742cd67dd9c059e.alaw found
2023.03.07 11:16:29.474 4: SIP_call, SIP_call|015120177388|40|cache/62d1a2142d218979d742cd67dd9c059e.alaw|2
2023.03.07 11:16:29.491 4: SIP_call, call -> SIP_call|015120177388|40|cache/62d1a2142d218979d742cd67dd9c059e.alaw|2|0
2023.03.07 11:16:29.493 5: SIP_call, call has pid 1561182
2023.03.07 11:16:29.537 4: SIP_call[1561182], my parent is 6392
2023.03.07 11:16:29.538 4: SIP_call[1561182], trying to use port 5070
2023.03.07 11:16:29.601 4: SIP_call[1561182], register new expire : 2023-03-07 11:21:29
2023.03.07 11:16:29.605 5: SIP_call, readingS:state Val:calling
2023.03.07 11:16:29.626 4: SIP_call[1561182], CallStart with 3 files - first file : cache/62d1a2142d218979d742cd67dd9c059e.alaw - PCMA/8000 , repeat 2
2023.03.07 11:16:29.632 4: SIP_call[1561182], calling : 015120177388
2023.03.07 11:16:29.633 5: SIP_call, readingS:call_state Val:calling 015120177388
2023.03.07 11:16:33.809 4: SIP_call[1561182], cb_final - status : OK
2023.03.07 11:16:33.809 4: SIP_call[1561182], call established
2023.03.07 11:16:33.810 5: SIP_call, readingS:call_state Val:established
2023.03.07 11:16:37.046 5: SIP_call[1561182], 0. Ende des ersten Loops
2023.03.07 11:16:37.046 5: SIP_call[1561182], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x55a0a7a1f8)
2023.03.07 11:16:37.046 5: SIP_call[1561182], 2. fi : 0
2023.03.07 11:16:37.046 5: SIP_call[1561182], 4. timeout : 0
2023.03.07 11:16:37.047 5: SIP_call[1561182], 6. call_established : 1
2023.03.07 11:16:37.048 4: SIP_call[1561182], next file : cache/62d1a2142d218979d742cd67dd9c059e.alaw
2023.03.07 11:16:37.198 4: SIP_call[1561182], cb_final - status : OK
2023.03.07 11:16:40.436 4: SIP_call[1561182], loop rtp_done : Net::SIP::Simple::Call=HASH(0x55a0a7a1f8)
2023.03.07 11:16:40.436 4: SIP_call[1561182], next file : cache/62d1a2142d218979d742cd67dd9c059e.alaw
2023.03.07 11:16:40.585 4: SIP_call[1561182], cb_final - status : OK
2023.03.07 11:16:43.822 4: SIP_call[1561182], loop rtp_done : Net::SIP::Simple::Call=HASH(0x55a0a7a1f8)
2023.03.07 11:16:43.822 5: SIP_call[1561182], call->bye
2023.03.07 11:16:43.837 5: SIP_call[1561182], RTP done : Net::SIP::Simple::Call=HASH(0x55a0a7a1f8)
2023.03.07 11:16:43.837 5: SIP_call[1561182], Timeout : 0
2023.03.07 11:16:43.837 5: SIP_call[1561182], while : 2
2023.03.07 11:16:43.837 5: SIP_call[1561182], Status : OK
2023.03.07 11:16:43.837 4: SIP_call[1561182], Calltime : 10
2023.03.07 11:16:43.843 4: SIP_call, CALLDone -> SIP_call|1|ok|10
2023.03.07 11:16:43.851 5: SIP_call, fifo is empty
2023.03.07 11:16:43.851 5: SIP_call, no elbc
2023.03.07 11:16:49.169 3: alarm_out: Alarm_Test: off
2. Wireshark, ab Paket 29: Im Anhang
Es laufen RTP Pakete im angegebenen Portbereich, aber es ist nichts zu hören.
VG
Alex
Mmmh, merkwürdig. Laut IP Trace gibt es einen Austausch von RTP Daten auf Port 2008. Sieht also prinzipiell gut aus.
Hast Du mal versucht eoinen internen Teilnehmer anzurufen?
Wie lange dauert der Anruf bis der SIP-Client auflegt?
Hast Du Dir mal das Audiofile cache/62d1a2142d218979d742cd67dd9c059e.mp3 auf Deinen PC kopiert und angehört (Stichwort Lautstärke)?
Guten Abend,
also bei internem Teilnehmer (es kommt auch kein Audio) wird die Verbindung nach 4 Sek. nach Abheben beendet.
Ein Trace (Anhang) läuft von Sek. 3.40 (SIP Request: Invite) bis Sek. 8.95 (SIP Request: Bye)
Sieht m. E. gut aus.
Log dazu:
2023.03.07 22:00:28.790 4: SIP_call, audio file ./cache/62d1a2142d218979d742cd67dd9c059e.mp3 found
2023.03.07 22:00:28.790 5: SIP_call, not converted - using ./cache/62d1a2142d218979d742cd67dd9c059e.alaw from cache
2023.03.07 22:00:28.790 4: SIP_call, SIP_call|**52|30|./cache/62d1a2142d218979d742cd67dd9c059e.alaw|0
2023.03.07 22:00:28.818 4: SIP_call, call -> SIP_call|**52|30|./cache/62d1a2142d218979d742cd67dd9c059e.alaw|0|0
2023.03.07 22:00:28.820 5: SIP_call, call has pid 2294364
2023.03.07 22:00:28.857 4: SIP_call[2294364], my parent is 6392
2023.03.07 22:00:28.858 4: SIP_call[2294364], trying to use port 5070
2023.03.07 22:00:28.908 4: SIP_call[2294364], register new expire : 2023-03-07 22:05:28
2023.03.07 22:00:28.913 5: SIP_call, readingS:state Val:calling
2023.03.07 22:00:28.935 4: SIP_call[2294364], CallStart with 1 files - first file : ./cache/62d1a2142d218979d742cd67dd9c059e.alaw - PCMA/8000 , repeat 0
2023.03.07 22:00:28.941 4: SIP_call[2294364], calling : **52
2023.03.07 22:00:28.942 5: SIP_call, readingS:call_state Val:calling **52
2023.03.07 22:00:31.258 4: SIP_call[2294364], cb_final - status : OK
2023.03.07 22:00:31.258 4: SIP_call[2294364], call established
2023.03.07 22:00:31.260 5: SIP_call, readingS:call_state Val:established
2023.03.07 22:00:34.495 5: SIP_call[2294364], 0. Ende des ersten Loops
2023.03.07 22:00:34.495 5: SIP_call[2294364], 1. rtp_done : Net::SIP::Simple::Call=HASH(0x55a0a33970)
2023.03.07 22:00:34.495 5: SIP_call[2294364], 2. fi : 0
2023.03.07 22:00:34.495 5: SIP_call[2294364], 4. timeout : 0
2023.03.07 22:00:34.495 5: SIP_call[2294364], 6. call_established : 1
2023.03.07 22:00:34.495 5: SIP_call[2294364], call->bye
2023.03.07 22:00:34.511 5: SIP_call[2294364], RTP done : Net::SIP::Simple::Call=HASH(0x55a0a33970)
2023.03.07 22:00:34.511 5: SIP_call[2294364], Timeout : 0
2023.03.07 22:00:34.511 5: SIP_call[2294364], while : 0
2023.03.07 22:00:34.511 5: SIP_call[2294364], Status : OK
2023.03.07 22:00:34.511 4: SIP_call[2294364], Calltime : 3
2023.03.07 22:00:34.520 4: SIP_call, CALLDone -> SIP_call|1|ok|3
2023.03.07 22:00:34.529 5: SIP_call, fifo is empty
2023.03.07 22:00:34.529 5: SIP_call, no elbc
Extern dauert es knappe 10 Sek.
Das Audio File hat am PC normale Lautstärke genauso laut wie andere am PC vorhandene mp3-Files.
Ich bin echt ratlos.
VG
Alex
Tja, merkwürdig.
Ich habe gerade ganz frisch einen Docker-Container mit fhem angelegt, SIP und TexttoSpeech eingerichtet, die Ports angepasst und bei mir funktioniert die Sprachausgabe, sowohl intern als auch extern.
Da muss mein Hinterstübchen jetzt mal etwas grübeln ...
Kannst Du eigentlich DTMF-Töne übermitteln?
Hallo,
Du meinst der SIP Client soll der Angerufene sein.
Nein, Verhalten so als ob der Client gar nicht da wäre, auch am Ethernet-Trace nichts sichtbar.
Ich habe zu Testzwecken den SIP Client mit Attr. disable deaktiviert, auf einem Laptop (IP: 192.168.3.30) einen SIP Client installiert und mit den Zugangsdaten erfolgreich interne und externe calls (incoming + outgoing) aufbauen können. Mein Verdacht war vor dem Test nämlich die FB, aber mit dem MicroSIP Client am Laptop funktioniert alles perfekt.
Komisch, dass der Eth.-Trace (outgoing von fhem) eigentlich gut aussieht. Leider kann man auf der FB keinen Paketmitschnitt auf der WAN-If zum Netzprovider anfertigen.
Gruß
Alex
Zitat von: Homalix99 am 08 März 2023, 18:43:45
Du meinst der SIP Client soll der Angerufene sein.
Hallo Alex, nein, ich meinte wirklich vom SIP Client zum Angerufenen übermitteln. Statt !Text gibst Du z.B.
-#47 an. Das "-" steht für DTMF-Übermittlung. Da Du rfc2833 als Format gewählt hast wird es nur knacksen, aber dann wissen wir, dass wenigstens etwas rüber geht.
VG Peter
Hallo Peter,
habe ich gerade probiert, leider Fehlanzeige.
In den Traces sieht man zwar RTP Pakete, die sind aber alle von der FB zu fhem. Vom clientz kommt nichts.
Gruß
Alex
Zitat von: Homalix99 am 08 März 2023, 20:09:17
In den Traces sieht man zwar RTP Pakete, die sind aber alle von der FB zu fhem. Vom clientz kommt nichts.
Dem muss ich widersprechen. Ich habe den zweiten RTP Thread (192.168.3.20->192.168.3.1) rausgefiltert, in Wireshark auf den RTP-Stream gefiltert und exportiert, in Audacity importiert und höre beim Abspielen ein sehr krächzendes "Dies ist ein Testalarm von Fheem".
Okay,
das klingt ja schon mal nicht nach einem fhem Problem.
Vielen Dank für die aufwendige Analyse. Aber was kann es sonst sein?
ok, dann probier doch mal folgendes: Richte einen weiteren FritzBox-User für Deinen MicroSIP Client am Laptop ein. Sende die Alarm-Nachrticht an diesen Client und schneide das ganze mit. Dann sehen wir, ob die RTP-Pakete in brauchbarer Form an den Client weitergeleitet werden.
Hallo Peter,
also:
Master FB: 192.168.3.1
Laptop, IP: 192.168.3.30 (WLAN, an Slave FB als Mesh)
Docker-Host: 192.168.3.20 (LAN 3, eth2, direkt an der Master FB)
Fhem-Container: 172.19.0.5
Fhem-IP-Telefonnummer: 620
Fhem: Aufbau Testanruf (zur Nummer: **621) zum MicroSIP Client
Zwei Tracedateien vom einzigen Anruf zum MicroSIP Client im Anhang:
1. iad-if-eth2_09.03.23_1611.eth (Interface eth2 der Master FB)
2. iad-if-wlan_09.03.23_1611.eth (Interface WLAN der Slave FB)
Hinweis: Vom Laptop Richtung Fhem werden in den RTP Paketen die Geräusche vom Laptop Micro übertragen.
Tja, auf dem Weg 192.168.3.1->192.168.3.30 sehe ich auf den ersten Blick als Payload quasi nur alles x'd5, obwohl laut Wireshark in beiden Fällen PCMA gesprochen wird.
Was veranlasst die Fritzbox dazu den Audiostream zu nullen?
Ich habe gerade noch mal meine FHEM-Instanz im Docker-Container gestartet und eine Session mitgeschnitten. Bei mir läuft die RTP-Session zwischen der internen IP-Adresse des Containers und der 192.168.3.1. Bei Dir ist die Sender-IP die des Docker-Hosts (192.168.3.20).
Keine Ahnung, ob's einen Unterschied macht.
Guten Abend Peter,
danke für den Hinweis. Ich habe mir schon gedacht, dass das ein Problem sein kann. Die RTP Pakete zur Fritzbox haben die IP des Docker-Host und zu fhem hin die IP des Fhem Containers.
Aber wo stellt man das richtig?
Könnte das was bringen, den SIP-Client in fhem zu löschen und neu zu definieren?
Hast Du Docker mit NATing eingerichtet???
Schick doch mal ip addr und ip route von innerhalb des Containers und vom Host.
IP-addr (HOST):
root@RPI-Docker:/pi-hole-docker# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:ea:33:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.20/24 brd 192.168.3.255 scope global dynamic noprefixroute eth0
valid_lft 812716sec preferred_lft 704716sec
inet6 2003:f6:f722:e700:d9b3:4da:978:afa7/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6958sec preferred_lft 1071sec
inet6 fe80::5638:6cc2:c7e8:aa26/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether dc:a6:32:ea:33:43 brd ff:ff:ff:ff:ff:ff
4: br-2e1cc9ea428a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:72:03:ad:f4 brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-2e1cc9ea428a
valid_lft forever preferred_lft forever
inet6 fe80::42:72ff:fe03:adf4/64 scope link
valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:e4:02:11:72 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
6: br-9f222dfd7a06: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:3c:0b:15:ae brd ff:ff:ff:ff:ff:ff
inet 172.20.0.1/16 brd 172.20.255.255 scope global br-9f222dfd7a06
valid_lft forever preferred_lft forever
inet6 fe80::42:3cff:fe0b:15ae/64 scope link
valid_lft forever preferred_lft forever
7: br-29f0a168d3f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:f2:22:19:c3 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-29f0a168d3f3
valid_lft forever preferred_lft forever
inet6 fe80::42:f2ff:fe22:19c3/64 scope link
valid_lft forever preferred_lft forever
9: vethf03cefd@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
link/ether 22:9b:c4:dc:b5:4c brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet 169.254.41.187/16 brd 169.254.255.255 scope global noprefixroute vethf03cefd
valid_lft forever preferred_lft forever
inet6 fe80::e36:c2fe:b1c4:bc62/64 scope link
valid_lft forever preferred_lft forever
11: vethab0edfc@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
link/ether 92:2a:15:c2:09:37 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet 169.254.195.163/16 brd 169.254.255.255 scope global noprefixroute vethab0edfc
valid_lft forever preferred_lft forever
inet6 fe80::af57:3915:267:41e5/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::902a:15ff:fec2:937/64 scope link
valid_lft forever preferred_lft forever
13: vethb07b911@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-9f222dfd7a06 state UP group default
link/ether e6:b6:cb:82:42:b8 brd ff:ff:ff:ff:ff:ff link-netnsid 4
inet 169.254.224.252/16 brd 169.254.255.255 scope global noprefixroute vethb07b911
valid_lft forever preferred_lft forever
inet6 fe80::677a:ec8a:b960:97c2/64 scope link
valid_lft forever preferred_lft forever
15: veth0a0617b@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
link/ether 9a:a2:d2:6d:2a:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 169.254.79.0/16 brd 169.254.255.255 scope global noprefixroute veth0a0617b
valid_lft forever preferred_lft forever
inet6 fe80::e8d6:7e76:1717:d8f2/64 scope link
valid_lft forever preferred_lft forever
17: vetha5ea5e2@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
link/ether 26:65:0f:aa:5c:ba brd ff:ff:ff:ff:ff:ff link-netnsid 6
inet 169.254.3.36/16 brd 169.254.255.255 scope global noprefixroute vetha5ea5e2
valid_lft forever preferred_lft forever
inet6 fe80::82d4:8f4a:d2ed:2c99/64 scope link
valid_lft forever preferred_lft forever
19: veth236be53@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
link/ether 2e:b2:73:fa:04:f3 brd ff:ff:ff:ff:ff:ff link-netnsid 7
inet 169.254.61.226/16 brd 169.254.255.255 scope global noprefixroute veth236be53
valid_lft forever preferred_lft forever
inet6 fe80::a714:fbeb:8a42:74c0/64 scope link
valid_lft forever preferred_lft forever
21: veth33fff10@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
link/ether 12:47:fb:e0:0d:67 brd ff:ff:ff:ff:ff:ff link-netnsid 5
inet 169.254.188.213/16 brd 169.254.255.255 scope global noprefixroute veth33fff10
valid_lft forever preferred_lft forever
inet6 fe80::a131:55f4:1a6e:a9c1/64 scope link
valid_lft forever preferred_lft forever
23: vethd1294b6@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
link/ether ea:be:69:eb:9c:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 3
inet 169.254.125.134/16 brd 169.254.255.255 scope global noprefixroute vethd1294b6
valid_lft forever preferred_lft forever
inet6 fe80::c61e:daaa:1e35:a42/64 scope link
valid_lft forever preferred_lft forever
27: veth8c35ddb@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
link/ether 36:60:4f:cd:75:ba brd ff:ff:ff:ff:ff:ff link-netnsid 8
inet 169.254.142.190/16 brd 169.254.255.255 scope global noprefixroute veth8c35ddb
valid_lft forever preferred_lft forever
inet6 fe80::5d71:39c6:949e:1de/64 scope link
valid_lft forever preferred_lft forever
28: br-a3ed05ad371c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:03:66:5b:7d brd ff:ff:ff:ff:ff:ff
inet 172.21.0.1/16 brd 172.21.255.255 scope global br-a3ed05ad371c
valid_lft forever preferred_lft forever
inet6 fe80::42:3ff:fe66:5b7d/64 scope link
valid_lft forever preferred_lft forever
40: veth9e0281d@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
link/ether 1e:32:99:70:fe:14 brd ff:ff:ff:ff:ff:ff link-netnsid 9
inet 169.254.49.225/16 brd 169.254.255.255 scope global noprefixroute veth9e0281d
valid_lft forever preferred_lft forever
inet6 fe80::1c32:99ff:fe70:fe14/64 scope link
valid_lft forever preferred_lft forever
ip route (HOST)
root@RPI-Docker:/fhem-docker# ip route
default via 192.168.3.1 dev eth0 proto dhcp src 192.168.3.20 metric 202
169.254.0.0/16 dev vethf03cefd scope link src 169.254.41.187 metric 209
169.254.0.0/16 dev vethab0edfc scope link src 169.254.195.163 metric 211
169.254.0.0/16 dev vethb07b911 scope link src 169.254.224.252 metric 213
169.254.0.0/16 dev veth0a0617b scope link src 169.254.79.0 metric 215
169.254.0.0/16 dev vetha5ea5e2 scope link src 169.254.3.36 metric 217
169.254.0.0/16 dev veth236be53 scope link src 169.254.61.226 metric 219
169.254.0.0/16 dev veth33fff10 scope link src 169.254.188.213 metric 221
169.254.0.0/16 dev vethd1294b6 scope link src 169.254.125.134 metric 223
169.254.0.0/16 dev veth8c35ddb scope link src 169.254.142.190 metric 227
169.254.0.0/16 dev veth9e0281d scope link src 169.254.49.225 metric 240
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-29f0a168d3f3 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-2e1cc9ea428a proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-9f222dfd7a06 proto kernel scope link src 172.20.0.1
172.21.0.0/16 dev br-a3ed05ad371c proto kernel scope link src 172.21.0.1 linkdown
192.168.3.0/24 dev eth0 proto dhcp scope link src 192.168.3.20 metric 202
Die ip cmds sind im Container nicht verfügbar.
Weißt Du wie ich das dazudefinieren kann?
IP addr (Fhem Container):
oot@FHEM-Docker:/opt/fhem# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
53: eth0@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:13:00:05 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.19.0.5/16 brd 172.19.255.255 scope global eth0
valid_lft forever preferred_lft forever
root@FHEM-Docker:/opt/fhem#
ip route (fhem-Container):
root@FHEM-Docker:/opt/fhem# ip route
default via 172.19.0.1 dev eth0
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.5
root@FHEM-Docker:/opt/fhem#
Das sieht alles normal aus. Da Daten via RTP übertragen werden sollte die Sender-IP keinen großen Unterschied machen.
Im IP-Phone-Forum hat jemand mit Audio-Problemen die FritzBox neu durchgestartet ...
Hallo Peter,
ich denke, dass die FB als SIP Server damit schon ein Problem hat.
Ich würde gerne erreichen wollen, dass die Sender-IP die des Containers ist, da die FB von einem Telefon (intern oder extern) mit dem MicroSIP ja tadellos ihren Dienst verrichtet
und die unterschiedlichen IP's ja erstmal der einzige Unterschied sind, warum es nicht funktionieren könnte.
Wie hast Du es geschafft, dass der Versuchsaufbau bei Dir die Sende-IP des Containers ist?
Zitat von: Homalix99 am 10 März 2023, 13:32:05
Wie hast Du es geschafft, dass der Versuchsaufbau bei Dir die Sende-IP des Containers ist?
einfach cut&paste. Ich habe mein Test-FHEM mit dem Command-Beispiel aus dem Wiki angelegt
docker run -d -p 7072:7072 -p 8083:8083 -p 5060:5060 -p 5070:5070 -p 2000-2019:2000-2019 fhem/fhem
Dann nur noch die Utils.pm angepasst, SIP und TexttoSpeech installiert/konfiguriert und los ging's.
Ich habe auch kein Docker-Config-File gefunden in dem ich irgendwas vorgebe.
Ich habe diesen Artikel hier zu Docker und Proxy gefunden: https://deavid.wordpress.com/2019/06/15/how-to-allow-docker-containers-to-see-the-source-ip-address/
Nutzt Du den Container fhem/fhem?
Bei mir ist als image fhem/fhem:latest definiert.
Den Artikel habe ich gelesen, kann ich ja demnächst mal ausprobieren.
Ich habe auch noch einen Artikel
https://forum.fhem.de/index.php?topic=114284.0 (https://forum.fhem.de/index.php?topic=114284.0)
entdeckt, die arbeiten mit Macvlan.
Damit habe ich ganz zu Beginn mal rumgespielt und nach jedem Docker Start plötzlich n x IP-Adressen in der FB sichtbar (n = Anzahl der Container)
Habs dann bleiben gelassen und brav den Standardweg mit bridge gewählt und bislang ja keinerlei Probleme gehabt.
Und auch gelesen, dass ein "Mischbetrieb" zwischen host und bridged Containern von d.-compose abgelehnt wird.
Werde bei Gelegenheit mal einen Freund kontraktieren, der sich mit Netzwerk besser auskennt.
VG
Alex
Mal schauen wann sich wzut einklinkt. Vielleicht hat der noch eine Idee.
Vielen, vielen Dank erstmal für Deine Unterstützung.
Irgendwie scheint es öfters Probleme mit RTP im Docker Container zu geben https://www.google.com/search?client=firefox-b-d&q=docker+rtp+no+audio
Hast Du die Möglichkeit auf einem freien Rechner einfach mal docker zu installieren (ohne Modifikation ) und dann FHEM mit SIP+TexttoSpeech einzurichten?
Zitat von: plin am 11 März 2023, 10:05:40
Mal schauen wann sich wzut einklinkt.
Ich lese immer mit, aber beim Thema Docker habe ich bis heute nicht kapiert wozu man das überhaupt brauch bzw. warum sich Leute so etwas freiwillig antun ->
Zitat von: Homalix99 am 04 März 2023, 18:01:59
Das Modul hat, bevor ich fhem in einen Docker-Container umgezogen habe, einwandfrei funktioniert, inkl. Audio Übertragung.
Alex, frag doch mal matrois was er damals gemacht hat https://forum.fhem.de/index.php/topic,102206.msg958302.html#msg958302
Hallo.
Eine Lösung kann ich zwar nicht bieten, aber vielleicht hilft ein Vergleich auch weiter.
Ich hab das mir so ähnlich am Laufen: FHEM ruft mich an, wenn was anliegt. FHEM rennt in Docker. Alles supi. Um SIP kümmert sich bei mir zwar Asterisk, aber das sollte nicht den riesigen Unterschieden machen.
Wenn ich einen Testcontainer starte:
docker run -d -p 8089:8083 --name fhemtest fhem/fhem
und dann die tts + sip Devices anlege, kann ich bereits outbound anrufen lassen. Richtig, obwohl keine Ports 5060 usw. nach außen gemappt sind und es keine statische Route gibt. Im Attribut "sip_ip" steht auch nur, was mir
docker inspect fhemtest
unter "IPAddress" anzeigt --> 172.17.0.2. (In meinem produktiven FHEM läuft der Container in einem Docker-Netz mit Net-Alias, wodurch ich im Attribut "sip_ip" keine IP eintragen muss, sondern nur den alias (bei mir "myfhem"). Ist hier aber nebensächlich :) )
Inbound calls sind freilich ein anderes Thema. Da reicht obiger Schmalspuraufruf nicht.
Im Post #1246 fällt auf, dass Du mehrere Bridges hast. Docker liegt mit docker0 im Adressbereich 172.17.0.1/16 mit linkdown, trotzdem wird bei Dir alles auf 172.19.0.5 gemünzt.
Im Vergleich bei Dir:
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:e4:02:11:72 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
und bei mir (Raspi und PC gleich):
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:2e:0c:e2:e9 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
Docker liegt doch eigentlich immer in 172.17.0.0/16. Schaut für mich so aus, als gäbe es einen Knoten in der Netzwerkkonfig. Macht hier ggf. die Bridge den Ärger? Hast Du die Möglichkeit auf einem PC/ Laptop Docker mit obigem Schmalspuraufruf zu starten, wo keine "Netzwerk-Besonderheiten" sind?
Wäre mal interessant, welchen Adressbereich Docker dort bekommt und ob von dort der Anruf klappt.
VG
rob
Hallo an alle!
Erstmal noch vielen Dank für die riesige Unterstützung.
Ich habe das Problem letzendlich gelöst, indem Docker vom Bridge-mode auf ipvlan umgestellt wurde. Jetzt hat fhem und alle weiteren Container eine ip-Adresse aus dem Fritzbox-Bereich (non DHCP-Bereich), damit sind Sende- und Empfangs-Adresse für die RTP-Pakete jetzt gleich und somit leitet die FB die RTP-Pakete richtig weiter.
VG
Alex
Hi
Hatte heute erstmalig folgende Meldung im Log:
(nach FHEM-Update - 96_SIP.pm war nicht dabei)
Zitat2023.04.03 19:40:00.473 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2023.04.03 19:40:00.476 2: Fhem_SIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.
Mein define des Device ist:
define Fhem_SIP SIPWelchen FQDN meint die Meldung? Meine FritzBox als SIP-Server ist mit der IP definiert.
Zitat von: RalfRog am 03 April 2023, 20:00:44Hi
Hatte heute erstmalig folgende Meldung im Log:
(nach FHEM-Update - 96_SIP.pm war nicht dabei)
Zitat2023.04.03 19:40:00.473 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2023.04.03 19:40:00.476 2: Fhem_SIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.
Hallo,
nachdem Ralf gepostet hat, habe ich mal nachgesehen. Die Meldung kommt regelmäßig, wenn ich beim PI ein shutdown -r now mache.
Grüße Jörg
Zitat von: RalfRog am 03 April 2023, 20:00:44Hi
Hatte heute erstmalig folgende Meldung im Log:
(nach FHEM-Update - 96_SIP.pm war nicht dabei)
Zitat2023.04.03 19:40:00.473 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/96_SIP.pm line 143.
2023.04.03 19:40:00.476 2: Fhem_SIP, please check your FQDN hostname -> Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at ./FHEM/96_SIP.pm line 143.
Mein define des Device ist:
define Fhem_SIP SIP
Welchen FQDN meint die Meldung? Meine FritzBox als SIP-Server ist mit der IP definiert.
Dann gib doch am command prompt des Servers auf dem FHEM läuft mal
hostname
hostname -f
ip a
ein und schick das Ergebnis.
Zitat von: plin am 03 April 2023, 20:47:58Dann gib doch am command prompt des Servers auf dem FHEM läuft mal
hostname
hostname -f
ip a
ein und schick das Ergebnis.
Hallo,
anbei die Ausgaben:
pi@raspberrypi:~ $ hostname
raspberrypi
pi@raspberrypi:~ $ hostname -f
raspberrypi
pi@raspberrypi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP gr oup default qlen 1000
link/ether b8:27:eb:80:58:33 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.30/24 brd 192.168.0.255 scope global dynamic noprefixroute et h0
valid_lft 861717sec preferred_lft 753717sec
inet6 2003:c2:5723:be00:c414:5575:87ba:da02/128 scope global dynamic noprefi xroute
valid_lft 6716sec preferred_lft 3116sec
inet6 fd00::40f5:269f:f144:2384/64 scope global dynamic mngtmpaddr noprefixr oute
valid_lft 6802sec preferred_lft 3202sec
inet6 2003:c2:5723:be00:a470:1388:4285:78a9/64 scope global dynamic mngtmpad dr noprefixroute
valid_lft 6802sec preferred_lft 1402sec
inet6 fe80::c414:5575:87ba:da02/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group defau lt qlen 1000
link/ether b8:27:eb:d5:0d:66 brd ff:ff:ff:ff:ff:ff
pi@raspberrypi:~ $
Grüße Jörg
Mmmh, habe das hier gefunden: https://bugs.launchpad.net/ubuntu/+source/libhttp-daemon-perl/+bug/1904907
Welche OS-Version hast Du im Einsatz?
Zitat von: plin am 03 April 2023, 21:23:23Welche OS-Version hast Du im Einsatz?
Raspbian GNU/Linux 11 (bullseye)
War aber auch mit Buster schon so.
Grüße Jörg
Häng was hinterher...
Bei mir ist es ebenfalls Buster und die Ausgaben (hostname, hostname -f, ip a) analog zu Jo
Ich kann bei mir unter openSUSE Leap 15.4 im fhem-log überhaupt keine dieser Meldungen finden...
Sorry fasse die letzten drei Beiträge zusammen (und lösch sie dann) weil es sonst zu unübersichtlich ist.
Die Funktion aus dem Log ist so beschrieben:
inet_ntoa (addr_string)
Translates a four-byte address string (as returned by inet_aton) into a string with the dotted-quad form of IP address.
Auf der Kommandozeile im Webinterface läßt sich die Ausgabe wiederholen
Aufruf: inet_ntoa(scalar(gethostbyname(hostfqdn())))
Ergebnis: Bad arg length for Socket::inet_ntoa, length is 0, should be 4 at (eval 1637) line 1.
Das jetzt mal schrittweise auf der Kommandozeile im Webinterface:
1. {hostfqdn()} = raspi.fritz.box
2. {gethostbyname(hostfqdn())} = da passiert "nix" und es kommt auch kein Eintrag ins Logfile
In der Konsole:
pi@raspi:/opt/fhem $ hostname
raspi
pi@raspi:/opt/fhem $ hostname -f
raspi
pi@raspi:/opt/fhem $ ping raspi.fritz.box
ping: raspi.fritz.box: Der Name oder der Dienst ist nicht bekannt
Das sieht aus als klemmt es da eventuell an der Namensauflösung?
Wenn ich in der /etc/hosts "10.20.30.41 raspi.fritz.box" zusätzlich eintrage: kein Fehler mehr auf der Kommandozeile im Webinterface.
==> {inet_ntoa(scalar(gethostbyname(hostfqdn())))} -> ergibt 10.20.30.41
Also letztlich Thema Namensauflösung.... hmmm ich bekomme es nicht ganz auf die Reihe wer denn die Namen auflösen müsste
PiHole? FritzBox?
Gruß Ralf
Zitat von: RalfRog am 03 April 2023, 23:19:30Also letztlich Thema Namensauflösung.... hmmm ich bekomme es nicht ganz auf die Reihe wer denn die Namen auflösen müsste
PiHole? FritzBox?
Die Antwort gibt Dir
cat /etc/resolv.conf
VG Peter
Zitat von: plin am 04 April 2023, 09:19:32Die Antwort gibt Dir
cat /etc/resolv.conf
Jep, ok.
Der Eintrag im Log hätte eigentlich schon "länger" kommen müssen - keine Ahnung warum nicht.
Ich verwende aktuell einen WLAN-Stick am RaspiV1 der (weil woanders verwendet) in der FritzBox (und damit PiHole) ganz anders (EdiWLAN) heisst als ich den Raspberry im Hostnamen (raspi) genannt habe.
Der Eintrag in der /etc/hosts ist so denke ich ein valider Workaround.
Danke und Gruß Ralf
Ich muss jetzt auch mal Hilfe bei euch holen, sonst ist der ganze Samstag pfutsch und ich finde den Fehler einfach nicht.
Als ich bin gerade vom Ur Sip Modul umgestiegen und habe alle Werte eigentlich korrekt gesetzt und zig mal geprüft.
Ich bekomme aber keinen call zu Stande.
Im Log steht...
2023.04.15 15:05:57 4: SipCall, calling +493523533489, ringtime: 30 , no message
2023.04.15 15:05:57 4: SipCall, SipCall|+493523533489|30||0
2023.04.15 15:05:57 4: SipCall, call -> SipCall|+493523533489|30||0|0
2023.04.15 15:05:57 5: SipCall, call has pid 15385
2023.04.15 15:05:57 4: SipCall[15385], my parent is 15327
2023.04.15 15:05:57 4: SipCall[15385], trying to use port 5100
Expected 'PeerHost' at /usr/share/perl5/Net/SIP/Util.pm line 40.
Einen weiteren Error gibts da nicht und der Call Prozess scheint endlos im Modul zu verweilen, da andere Versuche eines erneuten Anrufs in die Warteschleife geschoben werden.
Ich verwende die CPAN Sip in der Version 0.808
nternals:
CPID 15385
FUUID 643a88dd-f33f-c725-1e88-918beb45bb3ab603
NAME SipCall
NOTIFYDEV global
NR 55
NTFY_ORDER 50-SipCall
STATE initialized
TYPE SIP
VERSION V1.92 / 21.03.2020
eventCount 2
lastnr +49------
READINGS:
2023-04-15 15:05:57 call +49------
2023-04-15 15:05:57 call_state invite
2023-04-15 14:59:12 listen_alive no
2023-04-15 14:59:12 state initialized
helper:
CALL SipCall|+49------|30||0|0
CALL_NR +49------
CALL_START 1681563957.71415
CALL_TYPE out
CALL_PID:
abortArg
abortFn
arg SipCall|+49--------|30||0
bc_pid 5
finishFn SIP_CALLDone
fn SIP_CALLStart
pid DEAD:15385
timeout
Attributes:
history_file ./log/SipCall.sip
history_size 0
room System
sip_dtmf_loop once
sip_dtmf_send audio
sip_dtmf_size 2
sip_elbc yes
sip_from sip:Alarmraspi@192.168.222.1
sip_ip 192.168.222.245
sip_listen none
sip_registrar 192.168.222.1
sip_ringtime 3
sip_user Alarmraspi
verbose 5
Ich habe auch V1.92 / 21.03.2020.
Ich hatte gestern eine Sicherung in meine FB zurückgespielt, daher ging mein SIP auch nicht mehr.
Nachdem ich den fehlenden Name/Benuter/Passwort in der FB eingegeben habe und die Werte neben der RASPI IP im Modul ebenfall nochmal, war das Ding auch bockig.
Ich bin dann mal in den Listen-Mode (set listen) gegangen (mit Attribut sip_listen dtmf).
Da hat der State auf "listen_dtmf" gewechselt.
Danach ging es wieder.
Zitat von: Navigator am 15 April 2023, 15:20:35Expected 'PeerHost' at /usr/share/perl5/Net/SIP/Util.pm line 40.
Welche Version von Net::SIP hast Du im Einsatz?
Zitat von: plin am 15 April 2023, 21:04:19Welche Version von Net::SIP hast Du im Einsatz?
Es ist die 0.808 aus CPAN installiert. Aber verwende ich auch diese??? :o
Bei mir ist die
Installed: 0.822
installiert.
Upate: bin jetzt bei: Installed: 0.835
Hab jetzt auch die 0.822 und es funktioniert nun, Danke. ;)
Die 0.835 konnte ich nicht installieren, dort schmeißt CPAN einen Fehler unter Jessie. Habs jetzt aber nicht weiter verfolgt.
Zitat von: FHEMAN am 30 Oktober 2022, 21:16:30Zitat von: Wzut am 10 Mai 2018, 18:49:19Lustig ... geht bei mir auch nicht. Allerdings schafft verbose 5 da etwas mehr Klarheit :
sox : /usr/bin/sox WARN rate: rate clipped 1 samples; decrease volume?
Was auch immer sox da an dem mp3 File auszusetzen hat :(
Bzw. das würde eigentlich bedeuten das Google da schon Mist zurückliefert ? Werde mich die Tage wohl mal näher damit beschäftigen müssen.
Das Problem ist wohl, dass der sox Converter glaubt, der Sound sei übersteuert.
Das habe ich gerade bei ein paar krassen Halloween Sounds für unseren Klingellautsprecher eben auch bemerkt.
2022.10.30 21:01:43.894 4 : SIP, audio file /opt/fhem/audio/Halloween55.mp3 found
2022.10.30 21:01:43.894 5 : SIP, /usr/bin/sox /opt/fhem/audio/Halloween55.mp3 -t raw -r 8000 -c 1 -e a-law /opt/fhem/audio/Halloween55.alaw 2>&1
2022.10.30 21:01:43.931 5 : SIP, sox output : /usr/bin/sox WARN rate: rate clipped 1875 samples; decrease volume?/usr/bin/sox WARN dither: dither clipped 1666 samples; decrease volume?
Hier hilft der sox Schalter -G, um Clipping zu vermeiden. --norm wäre noch besser, da auch zu leise Sounds korrigiert werden, hat bei mir aber nicht funktioniert. Es wurde dann gar kein Output generiert.
Um nun wenigsten automatisch "nach unten" zu normalisieren, habe ich mal das Attribut audio_normalize eingebaut.
Die Datei befindet sich im Anhang. Ggf. könnte das ja mit in den Standard.
ich muss hier mal nachbohren... da ich jetzt das selbe Problem habe mit
set fhemphone call ***95 120 !Einbruch Alarm
sox : /usr/bin/sox WARN rate: rate clipped 1 samples; decrease volume?/usr/bin/sox WARN dither: dither clipped 1 samples; decrease volume?
da scheint er zu übersteuern
habe jetzt als audio converter ffmpeg installiert, damit scheint es zu gehen.
Aber wird sox überhaupt noch gepflegt ?
Zitat von: plin am 13 November 2021, 10:23:00Zitat von: tremichl am 12 November 2021, 18:32:47Gerne hätte ich eine Funktion "Anruf tätigen und DTMF-Töne empfangen" realisiert.
Daher meine Frage: Kann dass das Modul bzw. was mache ich falsch und wie müsste die Konfiguration dafür aussehen?
Hallo Michael,
das Modul bietet diese Funktion nicht an.
VG Peter
Hallo zusammen,
ich habe auch sehr großes Interesse an der Funktion "Anruf tätigen und DTMF-Töne empfangen".
Gibt es dazu mittlerweile vielleicht eine Lösung ?
Danke Euch !
Grüße
Onkel Tom
Zitat von: Onkel.Tom am 07 März 2024, 16:59:49Hallo zusammen,
ich habe auch sehr großes Interesse an der Funktion "Anruf tätigen und DTMF-Töne empfangen".
Gibt es dazu mittlerweile vielleicht eine Lösung ?
Danke Euch !
Grüße
Onkel Tom
von meiner Seite nicht